From suzannew@cs.pdx.edu Fri Sep 30 23:59:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 00:00:08 -0700 (PDT) Received: from lead.cat.pdx.edu (lead.cat.pdx.edu [131.252.208.91]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j916xqO0001096 for ; Fri, 30 Sep 2005 23:59:52 -0700 Received: from rastaban.cs.pdx.edu (root@rastaban.cs.pdx.edu [131.252.209.214]) by lead.cat.pdx.edu (8.13.1/8.13.1) with ESMTP id j916uhhT009703 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 30 Sep 2005 23:56:43 -0700 (PDT) Received: from rastaban.cs.pdx.edu (suzannew@localhost [127.0.0.1]) by rastaban.cs.pdx.edu (8.12.10/8.12.6) with ESMTP id j916uhUL007411; Fri, 30 Sep 2005 23:56:43 -0700 (PDT) Received: (from suzannew@localhost) by rastaban.cs.pdx.edu (8.12.10/8.12.6/Submit) id j916ufhT007410; Fri, 30 Sep 2005 23:56:41 -0700 (PDT) Date: Fri, 30 Sep 2005 23:56:41 -0700 (PDT) From: Suzanne Wood Message-Id: <200510010656.j916ufhT007410@rastaban.cs.pdx.edu> To: herbert@gondor.apana.org.au Cc: Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, suzannew@cs.pdx.edu, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections X-archive-position: 3711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: suzannew@cs.pdx.edu Precedence: bulk X-list: netdev Many thanks for addressing this issue. ----- Original Message ----- > From: Herbert Xu > Date: Sat, 1 Oct 2005 11:13:12 +1000 > > On Thu, Sep 29, 2005 at 06:06:50PM -0700, Suzanne Wood wrote: >> >> Are there three cases then? RCU protection with refcnt, RCU without refcnt, >> and the bare cast of the dereference? > > Correct. > > The following patch renames __in_dev_get() to __in_dev_get_rtnl() and > introduces __in_dev_get_rcu() to cover the second case. > > 1) RCU with refcnt should use in_dev_get(). > 2) RCU without refcnt should use __in_dev_get_rcu(). > 3) All others must hold RTNL and use __in_dev_get_rtnl(). > The naming to indicate purpose looks good and the leading underscores in the prior work did seem to imply wrapping to add functionality. But it is interesting to have discarded what was developed yesterday to minimize rcu_dereference impact: >> ----- Original message ----- >> From: Herbert Xu >> Date: Fri, 30 Sep 2005 11:19:07 +1000 >> >> On Thu, Sep 29, 2005 at 06:16:03PM -0700, Paul E. McKenney wrote: >>> >>> OK, how about this instead? >>> >>> rcu_read_lock(); >>> in_dev = dev->ip_ptr; >>> if (in_dev) { >>> atomic_inc(&rcu_dereference(in_dev)->refcnt); >>> } >>> rcu_read_unlock(); >>> return in_dev; >> >> Looks great. while adding a function call level by wrapping __in_dev_get_rcu with in_dev_get as suggested here. > -- > diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h > --- a/include/linux/inetdevice.h > +++ b/include/linux/inetdevice.h > @@ -142,13 +142,21 @@ static __inline__ int bad_mask(u32 mask, > > #define endfor_ifa(in_dev) } > > +static inline struct in_device *__in_dev_get_rcu(const struct net_device *dev) > +{ > + struct in_device *in_dev = dev->ip_ptr; > + if (in_dev) > + in_dev = rcu_dereference(in_dev); > + return in_dev; > +} > + > static __inline__ struct in_device * > in_dev_get(const struct net_device *dev) > { > struct in_device *in_dev; > > rcu_read_lock(); > - in_dev = dev->ip_ptr; > + in_dev = __in_dev_get_rcu(dev); > if (in_dev) > atomic_inc(&in_dev->refcnt); > rcu_read_unlock(); > @@ -156,7 +164,7 @@ in_dev_get(const struct net_device *dev) > } > > static __inline__ struct in_device * > -__in_dev_get(const struct net_device *dev) > +__in_dev_get_rtnl(const struct net_device *dev) > { > return (struct in_device*)dev->ip_ptr; > } The other thing I'd hoped to address in pktgen.c was removing the __in_dev_put() which decrements refcnt while __in_dev_get_rcu() does not increment. > diff --git a/net/core/pktgen.c b/net/core/pktgen.c > --- a/net/core/pktgen.c > +++ b/net/core/pktgen.c > @@ -1667,7 +1667,7 @@ static void pktgen_setup_inject(struct p > struct in_device *in_dev; > > rcu_read_lock(); > - in_dev = __in_dev_get(pkt_dev->odev); > + in_dev = __in_dev_get_rcu(pkt_dev->odev); > if (in_dev) { > if (in_dev->ifa_list) { > pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; pkt_dev->saddr_max = pkt_dev->saddr_min; } - __in_dev_put(in_dev); } rcu_read_unlock(); Thank you very much again for resolving this by clarifying both the RCU and RTNL usages. From herbert@gondor.apana.org.au Sat Oct 1 00:16:09 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 00:16:23 -0700 (PDT) Received: from arnor.apana.org.au (22.107.233.220.exetel.com.au [220.233.107.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j917G7O0004035 for ; Sat, 1 Oct 2005 00:16:08 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.36 #1 (Debian)) id 1ELbYD-0001qw-00; Sat, 01 Oct 2005 17:12:53 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1ELbY8-0004EW-00; Sat, 01 Oct 2005 17:12:48 +1000 Date: Sat, 1 Oct 2005 17:12:48 +1000 To: Suzanne Wood Cc: Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections Message-ID: <20051001071248.GA15990@gondor.apana.org.au> References: <200510010656.j916ufhT007410@rastaban.cs.pdx.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <200510010656.j916ufhT007410@rastaban.cs.pdx.edu> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 3712 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 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 30, 2005 at 11:56:41PM -0700, Suzanne Wood wrote: > > But it is interesting to have discarded what was developed yesterday > to minimize rcu_dereference impact: > > >> ----- Original message ----- > >> From: Herbert Xu > >> Date: Fri, 30 Sep 2005 11:19:07 +1000 > >> > >> On Thu, Sep 29, 2005 at 06:16:03PM -0700, Paul E. McKenney wrote: > >>> > >>> OK, how about this instead? > >>> > >>> rcu_read_lock(); > >>> in_dev = dev->ip_ptr; > >>> if (in_dev) { > >>> atomic_inc(&rcu_dereference(in_dev)->refcnt); > >>> } > >>> rcu_read_unlock(); > >>> return in_dev; > >> > >> Looks great. > > while adding a function call level by wrapping __in_dev_get_rcu > with in_dev_get as suggested here. It might look different, but it should compile to the same result. GCC should be smart enough to combine the two branches and produce a memory barrier only when in_dev is not NULL. > The other thing I'd hoped to address in pktgen.c was > removing the __in_dev_put() which decrements refcnt > while __in_dev_get_rcu() does not increment. Well spotted. Here is a patch on top of the last one to fix this bogus decrement. Signed-off-by: Herbert Xu Thanks, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p diff --git a/net/core/pktgen.c b/net/core/pktgen.c --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -1673,7 +1673,6 @@ static void pktgen_setup_inject(struct p pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; pkt_dev->saddr_max = pkt_dev->saddr_min; } - __in_dev_put(in_dev); } rcu_read_unlock(); } --2fHTh5uZTiUOsy+g-- From rmk+netdev=oss.sgi.com@arm.linux.org.uk Sat Oct 1 06:38:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 06:38:39 -0700 (PDT) Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [212.18.232.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91DcTO0005828 for ; Sat, 1 Oct 2005 06:38:34 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.52) id 1ELhWM-0004gy-LI for netdev@oss.sgi.com; Sat, 01 Oct 2005 14:35:23 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.52) id 1ELhWJ-00058r-HZ for netdev@oss.sgi.com; Sat, 01 Oct 2005 14:35:19 +0100 Date: Sat, 1 Oct 2005 14:35:18 +0100 From: Russell King To: netdev@oss.sgi.com Subject: [PATCH] sysctl_net.c:36: error: 'core_table' undeclared here Message-ID: <20051001133518.GA11254@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 3714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rmk@arm.linux.org.uk Precedence: bulk X-list: netdev Content-Length: 1044 Lines: 41 During the build for ARM machine type "fortunet", this error occurred: CC net/sysctl_net.o net/sysctl_net.c:36: error: 'core_table' undeclared here (not in a function) The ARM configuration which produced this error can be found in: arch/arm/configs/fortunet_defconfig where the relevant options are: CONFIG_SYSCTL=y CONFIG_NET=y # CONFIG_INET is not set core_table appears to be declared in net/sock.h. if CONFIG_INET were defined, net/sock.h would have been included via: sysctl_net.c -> net/ip.h -> linux/ip.h -> net/sock.h so include it directly. Signed-off-by: Russell King (This patch is completely untested atm; we're waiting for the machine to complete an existing build run. However, I think this is fairly obviously correct.) diff --git a/net/sysctl_net.c b/net/sysctl_net.c --- a/net/sysctl_net.c +++ b/net/sysctl_net.c @@ -16,6 +16,8 @@ #include #include +#include + #ifdef CONFIG_INET #include #endif -- Russell King From mbellion@hipac.org Sat Oct 1 08:41:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 08:41:28 -0700 (PDT) Received: from justus.rz.uni-saarland.de (justus.rz.uni-saarland.de [134.96.7.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91FfEO0019723 for ; Sat, 1 Oct 2005 08:41:15 -0700 Received: from e135.stw.stud.uni-saarland.de (e135.stw.stud.uni-saarland.de [134.96.65.150]) by justus.rz.uni-saarland.de (8.12.10/8.12.10) with ESMTP id j91FcI2611809752; Sat, 1 Oct 2005 17:38:19 +0200 (CEST) From: Michael Bellion To: Harald Welte Subject: Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0 Date: Sat, 1 Oct 2005 17:38:16 +0200 User-Agent: KMail/1.8.1 Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com References: <200509260445.46740.mbellion@hipac.org> <20050930123334.GW4168@sunbeam.de.gnumonks.org> In-Reply-To: <20050930123334.GW4168@sunbeam.de.gnumonks.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510011738.18173.mbellion@hipac.org> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.1 (justus.rz.uni-saarland.de [134.96.7.31]); Sat, 01 Oct 2005 17:38:19 +0200 (CEST) X-AntiVirus: checked by AntiVir Milter 1.0.6; AVE 6.32.0.6; VDF 6.32.0.54 X-archive-position: 3717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbellion@hipac.org Precedence: bulk X-list: netdev Content-Length: 551 Lines: 14 Hi > > I am happy to announce the release of nf-HiPAC version 0.9.0 > > Looking forward to talking to you about it next week! Yes, I am looking forward to meet you and the rest of the netfilter developers again at the workshop next week too. The workshop has always been a lot of fun with a lot of interesting discussions. With the 2 days of the workshop and the 2 extra days of hacking on code there will probably be plenty of time to talk about the current state and future directions of the HiPAC project. See you next week Michael Bellion From suzannew@cs.pdx.edu Sat Oct 1 11:03:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 11:04:12 -0700 (PDT) Received: from iron.cat.pdx.edu (iron.cat.pdx.edu [131.252.208.92]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91I3rO0030140 for ; Sat, 1 Oct 2005 11:03:53 -0700 Received: from rastaban.cs.pdx.edu (root@rastaban.cs.pdx.edu [131.252.209.214]) by iron.cat.pdx.edu (8.13.1/8.13.1) with ESMTP id j91I0Xxx011633 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 Oct 2005 11:00:34 -0700 (PDT) Received: from rastaban.cs.pdx.edu (suzannew@localhost [127.0.0.1]) by rastaban.cs.pdx.edu (8.12.10/8.12.6) with ESMTP id j91I0XUL012677; Sat, 1 Oct 2005 11:00:33 -0700 (PDT) Received: (from suzannew@localhost) by rastaban.cs.pdx.edu (8.12.10/8.12.6/Submit) id j91I0S3G012676; Sat, 1 Oct 2005 11:00:28 -0700 (PDT) Date: Sat, 1 Oct 2005 11:00:28 -0700 (PDT) From: Suzanne Wood Message-Id: <200510011800.j91I0S3G012676@rastaban.cs.pdx.edu> To: herbert@gondor.apana.org.au Cc: Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections X-archive-position: 3718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: suzannew@cs.pdx.edu Precedence: bulk X-list: netdev Content-Length: 2177 Lines: 53 With the spotlight leaving in_dev_get, we have the parallel question of in_dev_put() and __in_dev_put() both defined with refcnt decrement, but the preceding underscore may lend itself to an inadvertant pairing and refcnt inaccuracy. In the following cscope of linux-2.6.14-rc2 prior to Herbert's patches which remove the occurence in pktgen.c and the others are paired with __in_dev_get_rtnl(), except xfrm4_policy.c(): C symbol: __in_dev_put File Function Line File Function Line 0 inetdevice.h 172 #define __in_dev_put(idev) atomic_dec(&(idev)->refcnt) 1 pktgen.c pktgen_setup_inject 1687 __in_dev_put(in_dev); 2 devinet.c inet_rtm_deladdr 412 __in_dev_put(in_dev); 3 igmp.c igmp_gq_timer_expire 686 __in_dev_put(in_dev); 4 igmp.c igmp_ifc_timer_expire 698 __in_dev_put(in_dev); 5 igmp.c igmp_heard_query 801 __in_dev_put(in_dev); 6 igmp.c ip_mc_down 1228 __in_dev_put(in_dev); 7 igmp.c ip_mc_down 1231 __in_dev_put(in_dev); 8 igmp.c ip_mc_find_dev 1310 __in_dev_put(idev); 9 xfrm4_policy.c xfrm4_dst_ifdown 280 __in_dev_put(loopback_idev); It may not be reasonable to rename __in_dev_put for its parallel definition since its current usage is with __in_dev_get_rtnl() which does not increment refcnt. It is also probably good to retain the old __in_dev_get() and __in_dev_put() and deprecate them. Old business: this is probably stating the obvious, with Herbert's patches in place, none of the test patch I'd submitted 8 Sept should take effect. Thank you. Suzanne ----- Original Message ----- From: "Herbert Xu" Sent: Saturday, October 01, 2005 12:12 AM > On Fri, Sep 30, 2005 at 11:56:41PM -0700, Suzanne Wood wrote: >> >> The other thing I'd hoped to address in pktgen.c was >> removing the __in_dev_put() which decrements refcnt >> while __in_dev_get_rcu() does not increment. > > Well spotted. > > Here is a patch on top of the last one to fix this bogus decrement. > > Signed-off-by: Herbert Xu From paulmck@us.ibm.com Sat Oct 1 11:06:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 11:07:06 -0700 (PDT) Received: from e33.co.us.ibm.com ([32.97.110.151]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91I6wO0030650 for ; Sat, 1 Oct 2005 11:06:58 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id j91I2RFa023337 for ; Sat, 1 Oct 2005 14:02:27 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j91I3tBu547058 for ; Sat, 1 Oct 2005 12:03:55 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j91I3tWT006982 for ; Sat, 1 Oct 2005 12:03:55 -0600 Received: from linux.local (linux-009047022063.beaverton.ibm.com [9.47.22.63]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j91I3rcF006970; Sat, 1 Oct 2005 12:03:54 -0600 Received: by linux.local (Postfix on SuSE Linux 7.3 (i386), from userid 500) id 9C9FC1486D1; Sat, 1 Oct 2005 11:04:41 -0700 (PDT) Date: Sat, 1 Oct 2005 11:04:41 -0700 From: "Paul E. McKenney" To: Herbert Xu Cc: Suzanne Wood , Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections Message-ID: <20051001180441.GA1578@us.ibm.com> Reply-To: paulmck@us.ibm.com References: <200510010656.j916ufhT007410@rastaban.cs.pdx.edu> <20051001071248.GA15990@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051001071248.GA15990@gondor.apana.org.au> User-Agent: Mutt/1.4.1i X-archive-position: 3719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulmck@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2026 Lines: 64 On Sat, Oct 01, 2005 at 05:12:48PM +1000, Herbert Xu wrote: > On Fri, Sep 30, 2005 at 11:56:41PM -0700, Suzanne Wood wrote: > > > > But it is interesting to have discarded what was developed yesterday > > to minimize rcu_dereference impact: > > > > >> ----- Original message ----- > > >> From: Herbert Xu > > >> Date: Fri, 30 Sep 2005 11:19:07 +1000 > > >> > > >> On Thu, Sep 29, 2005 at 06:16:03PM -0700, Paul E. McKenney wrote: > > >>> > > >>> OK, how about this instead? > > >>> > > >>> rcu_read_lock(); > > >>> in_dev = dev->ip_ptr; > > >>> if (in_dev) { > > >>> atomic_inc(&rcu_dereference(in_dev)->refcnt); > > >>> } > > >>> rcu_read_unlock(); > > >>> return in_dev; > > >> > > >> Looks great. > > > > while adding a function call level by wrapping __in_dev_get_rcu > > with in_dev_get as suggested here. > > It might look different, but it should compile to the same result. > GCC should be smart enough to combine the two branches and produce a > memory barrier only when in_dev is not NULL. > > > The other thing I'd hoped to address in pktgen.c was > > removing the __in_dev_put() which decrements refcnt > > while __in_dev_get_rcu() does not increment. > > Well spotted. > > Here is a patch on top of the last one to fix this bogus decrement. Both this and Herbert's prior patch look good to me! Thanx, Paul > Signed-off-by: Herbert Xu > > Thanks, > -- > Visit Openswan at http://www.openswan.org/ > Email: Herbert Xu ~{PmV>HI~} > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > diff --git a/net/core/pktgen.c b/net/core/pktgen.c > --- a/net/core/pktgen.c > +++ b/net/core/pktgen.c > @@ -1673,7 +1673,6 @@ static void pktgen_setup_inject(struct p > pkt_dev->saddr_min = in_dev->ifa_list->ifa_address; > pkt_dev->saddr_max = pkt_dev->saddr_min; > } > - __in_dev_put(in_dev); > } > rcu_read_unlock(); > } From suzannew@cs.pdx.edu Sat Oct 1 11:40:31 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 11:40:35 -0700 (PDT) Received: from iron.cat.pdx.edu (iron.cat.pdx.edu [131.252.208.92]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91IeVO0000983 for ; Sat, 1 Oct 2005 11:40:31 -0700 Received: from rastaban.cs.pdx.edu (root@rastaban.cs.pdx.edu [131.252.209.214]) by iron.cat.pdx.edu (8.13.1/8.13.1) with ESMTP id j91IbF74012501 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 1 Oct 2005 11:37:16 -0700 (PDT) Received: from rastaban.cs.pdx.edu (suzannew@localhost [127.0.0.1]) by rastaban.cs.pdx.edu (8.12.10/8.12.6) with ESMTP id j91IbFUL012916; Sat, 1 Oct 2005 11:37:15 -0700 (PDT) Received: (from suzannew@localhost) by rastaban.cs.pdx.edu (8.12.10/8.12.6/Submit) id j91IbE01012915; Sat, 1 Oct 2005 11:37:14 -0700 (PDT) Date: Sat, 1 Oct 2005 11:37:14 -0700 (PDT) From: Suzanne Wood Message-Id: <200510011837.j91IbE01012915@rastaban.cs.pdx.edu> To: herbert@gondor.apana.org.au Cc: Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections X-archive-position: 3720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: suzannew@cs.pdx.edu Precedence: bulk X-list: netdev Content-Length: 779 Lines: 22 Please excuse this restatement of an earlier concern. > From suzannew Sat Oct 1 11:00:28 2005 > With the spotlight leaving in_dev_get, we have the parallel question > of in_dev_put() and __in_dev_put() both defined with refcnt > decrement, but the preceding underscore may lend itself to an > inadvertant pairing and refcnt inaccuracy. Dave Miller already addressed this question in http://www.ussg.iu.edu/hypermail/linux/kernel/0509.3/0757.html > It may not be reasonable to rename __in_dev_put for its parallel definition > since its current usage is with __in_dev_get_rtnl() which does not increment > refcnt. But the following may be worth considering. > It is also probably good to retain the old __in_dev_get() and deprecate it. Thank you. From herbert@gondor.apana.org.au Sat Oct 1 12:32:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 01 Oct 2005 12:33:09 -0700 (PDT) Received: from arnor.apana.org.au (22.107.233.220.exetel.com.au [220.233.107.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j91JWsO0007870 for ; Sat, 1 Oct 2005 12:32:57 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.36 #1 (Debian)) id 1ELn3E-0005Px-00; Sun, 02 Oct 2005 05:29:40 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1ELn38-0005PJ-00; Sun, 02 Oct 2005 05:29:34 +1000 Date: Sun, 2 Oct 2005 05:29:34 +1000 To: Suzanne Wood Cc: Robert.Olsson@data.slu.se, davem@davemloft.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, walpole@cs.pdx.edu Subject: Re: [RFC][PATCH] identify in_dev_get rcu read-side critical sections Message-ID: <20051001192934.GA20741@gondor.apana.org.au> References: <200510011837.j91IbE01012915@rastaban.cs.pdx.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510011837.j91IbE01012915@rastaban.cs.pdx.edu> User-Agent: Mutt/1.5.9i From: Herbert Xu X-archive-position: 3721 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: 571 Lines: 17 On Sat, Oct 01, 2005 at 11:37:14AM -0700, Suzanne Wood wrote: > > But the following may be worth considering. > > > It is also probably good to retain the old __in_dev_get() > and deprecate it. I think it's better to get rid of it actually so that if there are external modules using this they can make sure that they're using the right function. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt From xschmi00@stud.feec.vutbr.cz Mon Oct 3 04:47:44 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 03 Oct 2005 04:47:49 -0700 (PDT) Received: from fest.stud.feec.vutbr.cz (fest.stud.feec.vutbr.cz [147.229.72.16]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j93BlhO0000787 for ; Mon, 3 Oct 2005 04:47:44 -0700 Received: from [147.229.75.38] (pcschmidt.uamt.feec.vutbr.cz [147.229.75.38]) (authenticated bits=0) by fest.stud.feec.vutbr.cz (8.12.11/8.12.11) with ESMTP id j93BigNq064896; Mon, 3 Oct 2005 13:44:43 +0200 (CEST) Message-ID: <434119B2.2070105@stud.feec.vutbr.cz> Date: Mon, 03 Oct 2005 13:44:50 +0200 From: Michal Schmidt User-Agent: Debian Thunderbird 1.0.2 (X11/20050817) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benjamin Reed CC: Jeff Garzik , netdev@oss.sgi.com Subject: [patch] airo: fix resume Content-Type: multipart/mixed; boundary="------------050502030909040204030807" X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 3722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: xschmi00@stud.feec.vutbr.cz Precedence: bulk X-list: netdev Content-Length: 1414 Lines: 41 This is a multi-part message in MIME format. --------------050502030909040204030807 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cisco Aironet doesn't resume properly from swsusp, because the resume method confuses a PM_EVENT_* for a PCI power state. It thinks that it is resuming from PCI_D1 and doesn't do the necessary initialization of the card. Signed-off-by: Michal Schmidt --------------050502030909040204030807 Content-Type: text/plain; name="airo-fix-resume.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="airo-fix-resume.diff" --- linux-vanilla/drivers/net/wireless/airo.c 2005-09-29 20:44:01.000000000 +0200 +++ linux-mich/drivers/net/wireless/airo.c 2005-10-01 15:07:34.000000000 +0200 @@ -5515,12 +5515,13 @@ static int airo_pci_resume(struct pci_de struct net_device *dev = pci_get_drvdata(pdev); struct airo_info *ai = dev->priv; Resp rsp; + pci_power_t prev_state = pdev->current_state; - pci_set_power_state(pdev, 0); + pci_set_power_state(pdev, PCI_D0); pci_restore_state(pdev); - pci_enable_wake(pdev, pci_choose_state(pdev, ai->power), 0); + pci_enable_wake(pdev, PCI_D0, 0); - if (ai->power.event > 1) { + if (prev_state != PCI_D1) { reset_card(dev, 0); mpi_init_descriptors(ai); setup_card(ai, dev->dev_addr, 0); --------------050502030909040204030807-- From jgarzik@pobox.com Tue Oct 4 02:55:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Oct 2005 02:55:58 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j949tpO0017461 for ; Tue, 4 Oct 2005 02:55:52 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EMjTj-0005tH-VN; Tue, 04 Oct 2005 09:52:57 +0000 Message-ID: <434250F6.2040406@pobox.com> Date: Tue, 04 Oct 2005 05:52:54 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton , Linus Torvalds CC: Netdev list Subject: [git patches] (updated) net driver updates Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3726 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: 1478 Lines: 46 Andrew and Linus, I pushed three more csets to the 'upstream-fixes' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git This fixes some of the fixes :) Changelog of added csets follows: commit 832f8f0378ff1566f2a222352c7ad5df3f8d0d9d Author: Randy Dunlap Date: Tue Oct 4 00:41:22 2005 -0700 [PATCH] sungem: fix gfp flags type Fix nocast sparse warnings in sungen: drivers/net/sungem.h:1040:45: warning: implicit cast to nocast type Signed-off-by: Randy Dunlap Signed-off-by: Jeff Garzik commit 81c58732277654a51bb52832e1bc74234bb977bc Author: Randy Dunlap Date: Mon Oct 3 21:24:36 2005 -0700 [PATCH] ns83820: fix gfp flags type Fix implicit nocast warnings in ns83820 code, including __nocast: drivers/net/ns83820.c:603:46: warning: implicit cast to nocast type Signed-off-by: Randy Dunlap Signed-off-by: Jeff Garzik commit f36a29d5672c7698ffe55c7c05107ae77fa698cc Author: Randy Dunlap Date: Mon Oct 3 21:24:45 2005 -0700 [PATCH] ieee80211: fix gfp flags type Fix implicit nocast warnings in ieee80211 code, including __nocast: net/ieee80211/ieee80211_tx.c:215:9: warning: implicit cast to nocast type Signed-off-by: Randy Dunlap Signed-off-by: Jeff Garzik From jgarzik@pobox.com Tue Oct 4 04:49:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Oct 2005 04:49:53 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94BnkO0004311 for ; Tue, 4 Oct 2005 04:49:46 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EMlFu-0005xh-PO; Tue, 04 Oct 2005 11:46:47 +0000 Message-ID: <43426BA4.5030105@pobox.com> Date: Tue, 04 Oct 2005 07:46:44 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Schmidt CC: Benjamin Reed , netdev@oss.sgi.com Subject: Re: [patch] airo: fix resume References: <434119B2.2070105@stud.feec.vutbr.cz> In-Reply-To: <434119B2.2070105@stud.feec.vutbr.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3727 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: 88 Lines: 3 applied. please CC future patches to netdev@vger.kernel.org, not netdev@oss.sgi.com. From jgarzik@pobox.com Tue Oct 4 06:21:58 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 04 Oct 2005 06:22:02 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j94DLwO0016618 for ; Tue, 4 Oct 2005 06:21:58 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EMmh4-00065X-K4; Tue, 04 Oct 2005 13:18:56 +0000 Message-ID: <4342813B.4070505@pobox.com> Date: Tue, 04 Oct 2005 09:18:51 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Grant Grundler , akpm@osdl.org, T-Bone@parisc-linux.org, varenet@parisc-linux.org, Linux Kernel , Netdev Subject: Re: patch tulip-natsemi-dp83840a-phy-fix.patch added to -mm tree References: <200505101955.j4AJtX9x032464@shell0.pdx.osdl.net> <42881C58.40001@pobox.com> <20050516050843.GA20107@colo.lackof.org> <4288CE51.1050703@pobox.com> <20050521223959.GA4337@electric-eye.fr.zoreil.com> <42968312.90901@pobox.com> <20050527071736.GA17185@electric-eye.fr.zoreil.com> In-Reply-To: <20050527071736.GA17185@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3728 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: 270 Lines: 17 Francois Romieu wrote: > Jeff Garzik : > [...] > >>Looks pretty good to me, at first look. >> >>I'll give it some thought, and probably apply it, in a few days. > > > An updated version is cooking. Ever finish cooking this tulip patch? Jeff From fpotter@cirpack.com Thu Oct 6 00:04:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Oct 2005 00:04:24 -0700 (PDT) Received: from geronimo.parthe.isp.9tel.net (geronimo.parthe.isp.9tel.net [62.62.156.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9674HO0015091 for ; Thu, 6 Oct 2005 00:04:20 -0700 Received: from gtk.cirpack.com (146.39.118-80.rev.gaoland.net [80.118.39.146]) by geronimo.parthe.isp.9tel.net (Postfix) with ESMTP id 84AD41102A2; Thu, 6 Oct 2005 09:01:20 +0200 (CEST) Received: from epicure.SURESNES.local (localhost [127.0.0.1]) by gtk.cirpack.com (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id j9671I3B028985; Thu, 6 Oct 2005 09:01:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CA43.C0188EE3" Subject: 440bx and natsemi Date: Thu, 6 Oct 2005 09:01:18 +0200 Message-ID: <8F5DB51133D6B84383761A7F0E399A7EBEA99D@epicure.suresnes.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 440bx and natsemi Thread-Index: AcXKQ8AvZ9CYCGIGT3q8hQRwAyjmqg== From: =?iso-8859-1?Q?Fr=E9d=E9ric_POTTER?= To: , Cc: "Manfred Spraul" X-archive-position: 3730 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fpotter@cirpack.com Precedence: bulk X-list: netdev Content-Length: 7081 Lines: 172 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CA43.C0188EE3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi,=20 =20 We have designed an embedded board, based on Celeron ULV 400 Mhz and = 440bx chipset. The BIOS has been derivated from Linux Bios of the 440mx (mx and bx = have minimal differences). The ethernet devices are natsemi DP83816 (latest HW revision) =20 The issue :=20 ---------------- =20 If we set the L1 CPU cache in write back mode then, under heavy = ethernet load, we have various memory corruption on the host memory. It looks like, basically, the natsemi = device, when getting bus master, is=20 accessing former skbuf physicall adresses in the tx_ring structure, and = therefore writing at various location in the memory, generating various kernel panic a few moment later. =20 If we set the L1 CPU cache in write through, the issue vanishes = completely (even after a few days of heavy load).. =20 Since we have designed this whole system (hardware, BIOS etc..), it = may clearly be that we have introduced a cache coherency issue in the system, but we have checked it all, and = it seems like not * snooping HW interface is present, correctly wired * Intel CPU and chipset seems to be properly configured, and anyway = no configuration seems to be present that would have allowed us to 'disable' cache coherency. * No Intel CPU or chipset errata have been found that refers to = cache snooping issues. =20 Does anyone have a clue on this one ? Does someone have a 440bx with a = Natsemi device (that may be a rare configuration BTW, since 440bx is used in laptop where the natsemi is = fairly rare)=20 Are we just discovering an N+1 Intel issue or did we miss something ? =20 thanks in advance =20 fred ------_=_NextPart_001_01C5CA43.C0188EE3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
 
   =20 Hi,
 
    We have designed an embedded board, based on Celeron ULV 400 = Mhz and=20 440bx chipset.
    The BIOS has been derivated from Linux Bios of the 440mx (mx = and bx have=20 minimal differences).
    The ethernet devices are natsemi DP83816 (latest HW=20 revision)
 
The = issue :=20
----------------
 
    If we set the L1 CPU cache in write back mode then, under = heavy=20 ethernet load, we have various memory
corruption on the=20 host memory. It looks like, basically, the natsemi device, when getting = bus=20 master, is
accessing former=20 skbuf physicall adresses in the tx_ring structure, and therefore = writing at=20 various location
in the = memory,=20 generating various kernel panic a few moment later.
 
    If we set the L1 CPU cache in write through, the issue vanishes = completely (even after a few days of heavy
load)..
 
    Since we have designed this whole system (hardware, BIOS = etc..), it may=20 clearly be that we have introduced
a = cache coherency=20 issue in the system, but we have checked it all, and it seems like=20 not
    *=20 snooping HW interface is present, correctly wired
    *=20 Intel CPU and chipset seems to be properly configured, and anyway no=20 configuration seems to be present
that = would have=20 allowed us to 'disable' cache coherency.
    *=20 No Intel CPU or chipset errata have been found that refers to cache = snooping=20 issues.
 
Does = anyone have a=20 clue on this one ? Does someone have a 440bx with a Natsemi device (that = may be=20 a rare
configuration BTW,=20 since 440bx is used in laptop where the natsemi is fairly rare)=20
Are we = just=20 discovering an N+1 Intel issue or did we miss something = ?
 
thanks = in=20 advance
 
fred
------_=_NextPart_001_01C5CA43.C0188EE3-- From venza@brownhat.org Thu Oct 6 03:43:05 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Oct 2005 03:43:14 -0700 (PDT) Received: from renditai.milesteg.arr (adsl-ull-66-128.44-151.net24.it [151.44.128.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96AgxO0026820 for ; Thu, 6 Oct 2005 03:43:05 -0700 Received: (qmail 2190 invoked by uid 1000); 6 Oct 2005 12:40:05 +0200 Date: Thu, 6 Oct 2005 12:40:05 +0200 From: Daniele Venzano To: Jeff Garzik Cc: NetDev , Jeff Garzik , Stanislav Protassov , Vasily Averin Subject: [PATCH] sis900: come alive after temporary memory shortage Message-ID: <20051006104004.GA2124@renditai.milesteg.arr> Mail-Followup-To: Jeff Garzik , NetDev , Stanislav Protassov , Vasily Averin References: <4337E76B.1090003@sw.ru> <8204E0D1-F30D-494F-8E97-CDCC26A82807@libero.it> <4337FF9D.70200@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4337FF9D.70200@sw.ru> X-Operating-System: Debian GNU/Linux on kernel Linux 2.6.12.1 X-Copyright: Forwarding or publishing without permission is prohibited. X-Truth: La vita e' una questione di culo, o ce l'hai o te lo fanno. X-GPG-Fingerprint: 642A A345 1CEF B6E3 925C 23CE DAB9 8764 25B3 57ED User-Agent: Mutt/1.5.9i X-archive-position: 3732 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 2417 Lines: 62 This patch is good and fixes some corner cases. Please consider for inclusion. On Mon, Sep 26, 2005 at 06:03:09PM +0400, Konstantin Khorenko wrote: > Patch solves following problems: > 1) Forgotten counter incrementation in sis900_rx() in case > it doesn't get memory for skb, that leads to whole interface failure. > Problem is accompanied with messages: > eth0: Memory squeeze,deferring packet. > eth0: NULL pointer encountered in Rx ring, skipping > 2) If counter cur_rx overflows and there'll be temporary memory problems > buffer can't be recreated later, when memory IS avaliable. > 3) Limit the work in handler to prevent the endless packets processing if > new packets are generated faster then handled. > > Signed-off-by: Konstantin Khorenko > Signed-off-by: Vasily Averin Signed-off-by: Daniele Venzano --- main-2.6.13.1/drivers/net/sis900.c.sis900 2005-08-29 03:41:01.000000000 +0400 +++ main-2.6.13.1/drivers/net/sis900.c 2005-09-19 14:34:42.000000000 +0400 @@ -1696,6 +1696,8 @@ static int sis900_rx(struct net_device * long ioaddr = net_dev->base_addr; unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC; u32 rx_status = sis_priv->rx_ring[entry].cmdsts; + int rx_work_limit = + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC; if (netif_msg_rx_status(sis_priv)) printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d " @@ -1705,6 +1713,8 @@ static int sis900_rx(struct net_device * while (rx_status & OWN) { unsigned int rx_size; + if (--rx_work_limit < 0) + break; rx_size = (rx_status & DSIZE) - CRC_SIZE; if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) { @@ -1770,6 +1780,7 @@ static int sis900_rx(struct net_device * sis_priv->rx_ring[entry].cmdsts = 0; sis_priv->rx_ring[entry].bufptr = 0; sis_priv->stats.rx_dropped++; + sis_priv->cur_rx++; break; } skb->dev = net_dev; @@ -1787,7 +1798,7 @@ static int sis900_rx(struct net_device * /* refill the Rx buffer, what if the rate of refilling is slower * than consuming ?? */ - for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) { + for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) { struct sk_buff *skb; entry = sis_priv->dirty_rx % NUM_RX_DESC; -- ------------------------------ Daniele Venzano Web: http://teg.homeunix.org From venza@brownhat.org Thu Oct 6 04:16:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Oct 2005 04:16:29 -0700 (PDT) Received: from renditai.milesteg.arr (adsl-ull-66-128.44-151.net24.it [151.44.128.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j96BGKO0030849 for ; Thu, 6 Oct 2005 04:16:21 -0700 Received: (qmail 3336 invoked by uid 1000); 6 Oct 2005 13:13:27 +0200 Date: Thu, 6 Oct 2005 13:13:27 +0200 From: Daniele Venzano To: Jeff Garzik , NetDev Cc: akpm@osdl.org Subject: [PATCH] Add Wake on LAN support to sis900 Message-ID: <20051006111326.GA3242@renditai.milesteg.arr> Mail-Followup-To: Jeff Garzik , NetDev , akpm@osdl.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline X-Operating-System: Debian GNU/Linux on kernel Linux 2.6.12.1 X-Copyright: Forwarding or publishing without permission is prohibited. X-Truth: La vita e' una questione di culo, o ce l'hai o te lo fanno. X-GPG-Fingerprint: 642A A345 1CEF B6E3 925C 23CE DAB9 8764 25B3 57ED User-Agent: Mutt/1.5.9i X-archive-position: 3733 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 6211 Lines: 203 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The patch availble below adds support for Wake on LAN to the sis900 driver. Some register addresses were added to sis900.h and two new functions were implemented in sis900.c. WoL status is controlled by ethtool. Patch is against 2.6.13. Comments are welcome, but also consider for inclusion in the -mm series. Signed-off-by: Daniele Venzano -- ------------------------------ Daniele Venzano Web: http://teg.homeunix.org --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sis900_c_127.diff" --- ../../trunk/sis900.h 2005-07-17 10:43:23.000000000 +0200 +++ sis900.h 2005-10-06 12:49:37.000000000 +0200 @@ -33,6 +33,7 @@ rxcfg=0x34, //Receive Configuration Register flctrl=0x38, //Flow Control Register rxlen=0x3c, //Receive Packet Length Register + cfgpmcsr=0x44, //Configuration Power Management Control/Status Register rfcr=0x48, //Receive Filter Control Register rfdr=0x4C, //Receive Filter Data Register pmctrl=0xB0, //Power Management Control Register @@ -140,6 +141,50 @@ EEREQ = 0x00000400, EEDONE = 0x00000200, EEGNT = 0x00000100 }; +/* PCI Registers */ +enum sis900_pci_registers { + CFGPMC = 0x40, + CFGPMCSR = 0x44 +}; + +/* Power management capabilities bits */ +enum sis900_cfgpmc_register_bits { + PMVER = 0x00070000, + DSI = 0x00100000, + PMESP = 0xf8000000 +}; + +enum sis900_pmesp_bits { + PME_D0 = 0x1, + PME_D1 = 0x2, + PME_D2 = 0x4, + PME_D3H = 0x8, + PME_D3C = 0x10 +}; + +/* Power management control/status bits */ +enum sis900_cfgpmcsr_register_bits { + PMESTS = 0x00004000, + PME_EN = 0x00000100, // Power management enable + PWR_STA = 0x00000003 // Current power state +}; + +/* Wake-on-LAN support. */ +enum sis900_power_management_control_register_bits { + LINKLOSS = 0x00000001, + LINKON = 0x00000002, + MAGICPKT = 0x00000400, + ALGORITHM = 0x00000800, + FRM1EN = 0x00100000, + FRM2EN = 0x00200000, + FRM3EN = 0x00400000, + FRM1ACS = 0x01000000, + FRM2ACS = 0x02000000, + FRM3ACS = 0x04000000, + WAKEALL = 0x40000000, + GATECLK = 0x80000000 +}; + /* Management Data I/O (mdio) frame */ #define MIIread 0x6000 #define MIIwrite 0x5002 --- ../../trunk/sis900.c 2005-10-06 12:06:06.000000000 +0200 +++ sis900.c 2005-10-06 12:05:45.000000000 +0200 @@ -1,6 +1,6 @@ /* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux. Copyright 1999 Silicon Integrated System Corporation - Revision: 1.08.08 Jan. 22 2005 + Revision: 1.08.09 Sep. 19 2005 Modified from the driver which is originally written by Donald Becker. @@ -17,6 +17,7 @@ SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution, preliminary Rev. 1.0 Jan. 18, 1998 + Rev 1.08.09 Sep. 19 2005 Daniele Venzano add Wake on LAN support Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages Rev 1.08.07 Nov. 2 2003 Daniele Venzano add suspend/resume support Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support @@ -76,7 +77,7 @@ #include "sis900.h" #define SIS900_MODULE_NAME "sis900" -#define SIS900_DRV_VERSION "v1.08.08 Jan. 22 2005" +#define SIS900_DRV_VERSION "v1.08.09 Sep. 19 2005" static char version[] __devinitdata = KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n"; @@ -538,6 +539,11 @@ printk("%2.2x:", (u8)net_dev->dev_addr[i]); printk("%2.2x.\n", net_dev->dev_addr[i]); + /* Detect Wake on Lan support */ + ret = inl(CFGPMC & PMESP); + if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0) + printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name); + return 0; err_unmap_rx: @@ -2007,6 +2013,67 @@ return mii_nway_restart(&sis_priv->mii_info); } +/** + * sis900_set_wol - Set up Wake on Lan registers + * @net_dev: the net device to probe + * @wol: container for info passed to the driver + * + * Process ethtool command "wol" to setup wake on lan features. + * SiS900 supports sending WoL events if a correct packet is received, + * but there is no simple way to filter them to only a subset (broadcast, + * multicast, unicast or arp). + */ + +static int sis900_set_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol) +{ + struct sis900_private *sis_priv = net_dev->priv; + long pmctrl_addr = net_dev->base_addr + pmctrl; + u32 cfgpmcsr = 0, pmctrl_bits = 0; + + if (wol->wolopts == 0) { + pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr); + cfgpmcsr |= ~PME_EN; + pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr); + outl(pmctrl_bits, pmctrl_addr); + if (netif_msg_wol(sis_priv)) + printk(KERN_DEBUG "%s: Wake on LAN disabled\n", net_dev->name); + return 0; + } + + if (wol->wolopts & (WAKE_MAGICSECURE | WAKE_UCAST | WAKE_MCAST + | WAKE_BCAST | WAKE_ARP)) + return -EINVAL; + + if (wol->wolopts & WAKE_MAGIC) + pmctrl_bits |= MAGICPKT; + if (wol->wolopts & WAKE_PHY) + pmctrl_bits |= LINKON; + + outl(pmctrl_bits, pmctrl_addr); + + pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr); + cfgpmcsr |= PME_EN; + pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr); + if (netif_msg_wol(sis_priv)) + printk(KERN_DEBUG "%s: Wake on LAN enabled\n", net_dev->name); + + return 0; +} + +static void sis900_get_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol) +{ + long pmctrl_addr = net_dev->base_addr + pmctrl; + u32 pmctrl_bits; + + pmctrl_bits = inl(pmctrl_addr); + if (pmctrl_bits & MAGICPKT) + wol->wolopts |= WAKE_MAGIC; + if (pmctrl_bits & LINKON) + wol->wolopts |= WAKE_PHY; + + wol->supported = (WAKE_PHY | WAKE_MAGIC); +} + static struct ethtool_ops sis900_ethtool_ops = { .get_drvinfo = sis900_get_drvinfo, .get_msglevel = sis900_get_msglevel, @@ -2015,6 +2082,8 @@ .get_settings = sis900_get_settings, .set_settings = sis900_set_settings, .nway_reset = sis900_nway_reset, + .get_wol = sis900_get_wol, + .set_wol = sis900_set_wol }; /** --TB36FDmn/VVEgNH/-- From davidsen@tmr.com Thu Oct 6 08:10:10 2005 Received: with ECARTIS (v1.0.0; list netdev); Thu, 06 Oct 2005 08:10:17 -0700 (PDT) Received: from gaimboi.tmr.com (mail.tmr.com [64.65.253.246]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j96FA8O0030152 for ; Thu, 6 Oct 2005 08:10:09 -0700 Received: from [127.0.0.1] (gaimboi.tmr.com [127.0.0.1]) by gaimboi.tmr.com (8.12.8/8.12.8) with ESMTP id j96F9Pqd017600; Thu, 6 Oct 2005 11:09:25 -0400 Message-ID: <43453E25.9020903@tmr.com> Date: Thu, 06 Oct 2005 11:09:25 -0400 From: Bill Davidsen Organization: TMR Associates Inc, Schenectady NY User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Bellion CC: Emmanuel Fleury , linux-kernel@vger.kernel.org, linux-net@vger.kernel.org, netdev@oss.sgi.com, jamal Subject: Re: [ANNOUNCE] Release of nf-HiPAC 0.9.0 References: <200509260445.46740.mbellion@hipac.org> <4337DA7C.2000804@cs.aau.dk> <200509261638.12731.mbellion@hipac.org> In-Reply-To: <200509261638.12731.mbellion@hipac.org> Content-Type: multipart/alternative; boundary="------------040706060300040508090100" X-archive-position: 3734 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davidsen@tmr.com Precedence: bulk X-list: netdev Content-Length: 11911 Lines: 269 This is a multi-part message in MIME format. --------------040706060300040508090100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Michael Bellion wrote: >Hi > > > >>I'm still not convinced by your approach. :-/ >> >> > >You really should have a closer look at nf-HiPAC so that you know what you are >talking about! > >Your Compact Filter takes a completely different approach than nf-HiPAC to >build the data structure used in the kernel for the packet classification >lookup. > >Your Compact Filter uses a static compiler in user space. That compiler >transforms the rule set into boolean expressions and than uses operations >from predicate logic to optimize the rule set. >This has the big drawback that whenever only a single rule changes you have to >recompile the complete lookup data structure. So this approach is clearly not >suitable for scenarios depending on dynamic rule sets. > >nf-HiPAC uses a completely different approach to build the lookup data >structure in the kernel. It is based on geometry. >This approach allows completely dynamic updates. During an update of the rules >only the required changes of the lookup data structure are made. The data >structure is NOT rebuild from scratch. This guarantees that the packet >processing is only affected to the least possible amount during updates. > >Although nf-HiPAC and Compact Filter use completely different approaches and >algorithms to build the lookup data structure it is important that you >understand the following: >nf-HiPAC and Compact filter end up with a very very similar lookup data >structure in the kernel. > > > > >>These experiments have to be updated but can you comment on this: >>http://www.cs.aau.dk/~mixxel/cf/experiments.html >> >> > >The current version of the algorithm used in nf-HiPAC does not optimize >certain aspects of the lookup data structure in order to increase the speed >of dynamic rule set updates. >This means that the lookup data structure is larger than it really needs to be >because it contains some unnecessary redundancy. >This explains your test results. >Compact Filter and nf-HiPAC perform the same when they are both able to keep >their lookup data structure in the CPU caches and when they are both not able >to do so anymore. >Compact Filter is currently able to perform better in the area where it is >able to keep its data structure still in the caches while nf-HiPAC is not >able to do so anymore. > > It would seem, looking at the provided results and author's comments, that the following are true: - for small static rulesets there is little difference, my 200-600 rules run fine in either - for very large rulesets cf will currently perform better (if this is due to cache effects, may be less evident, since the server runs an application rather than being a dedicated network device). - cf can't do large dynamic rulesets, compile time > change interval - the iptables results don't represent server use with persistent sockets, like mail/usenet, in which most (~95%) packets match the first rule in INPUT (ESTABLISHED -> ACCEPT) and the complexity is in processing TCP/SYN packets and forwarding rules. Also: none of the results I've seen show the effect of many tracked sockets, the performance of one stream pushing a lot of packets is not the same as the same bitrate coming from 500-5k source IPs, at least if you use the INPUT rule noted above. >Most aspects of your performance tests are quite nice (e.g. the generating the >traffic by replaying a packet header trace). >But your performance tests have a serious flaw: >You construct your rule set by creating one rule for each entry in your packet >header trace. This results in an completely artificial rule set that creates >a lot of redundancy in the nf-HiPAC lookup data structure making it much >larger than the Compact Filter data structure. > >You have to understand that with real world rule sets the size of the computed >lookup data structure will not be much different for Compact Filter and >nf-HiPAC. This means that when you use real world rule sets there shouldn't >be any noticeable difference in lookup performance betweeen Compact Filter >and nf-HiPAC. > >----------------- > >I am currently working on a new improved version of the algorithm used in >nf-HiPAC. The new algorithmic core will reduce memory usage while at the same >time improving the running time of insert and delete operations. The lookup >performance will be improved too, especially for bigger rulesets. The >concepts and the design are already developed, but the implementation is >still in its early stages. > >The new algorithmic core will make sure that the lookup data structure in the >kernel is always fully optimized while at the same time allowing very fast >dynamic updates. > >At that point Compact Filter will not be able to win in any performance test >against nf-HiPAC anymore, simply because there is no way to optimize the >lookup data structure any further. > The nf-HiPAC advantage seems to be in applications with moderate to large dynamic rulesets, in that it allows a lot of changes quickly. Don't give that up for throughput, the idea of being able to do 5-7 changes/sec on a 500-2k ruleset is exciting, and in some cases vital. Thanks to everyone working on improvements. -- bill davidsen CTO TMR Associates, Inc Doing interesting things with small computers since 1979 --------------040706060300040508090100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Bellion wrote: 
Hi

  
I'm still not convinced by your approach. :-/
    

You really should have a closer look at nf-HiPAC so that you know what you are 
talking about!

Your Compact Filter takes a completely different approach than nf-HiPAC to 
build the data structure used in the kernel for the packet classification 
lookup.

Your Compact Filter uses a static compiler in user space. That compiler 
transforms the rule set into boolean expressions and than uses operations 
from predicate logic to optimize the rule set.
This has the big drawback that whenever only a single rule changes you have to 
recompile the complete lookup data structure. So this approach is clearly not 
suitable for scenarios depending on dynamic rule sets.

nf-HiPAC uses a completely different approach to build the lookup data 
structure in the kernel. It is based on geometry.
This approach allows completely dynamic updates. During an update of the rules 
only the required changes of the lookup data structure are made. The data 
structure is NOT rebuild from scratch. This guarantees that the packet 
processing is only affected to the least possible amount during updates.

Although nf-HiPAC and Compact Filter use completely different approaches and 
algorithms to build the lookup data structure it is important that you 
understand the following:
nf-HiPAC and Compact filter end up with a very very similar lookup data 
structure in the kernel.


  
These experiments have to be updated but can you comment on this:
http://www.cs.aau.dk/~mixxel/cf/experiments.html
    

The current version of the algorithm used in nf-HiPAC does not optimize 
certain aspects of the lookup data structure in order to increase the speed 
of dynamic rule set updates.
This means that the lookup data structure is larger than it really needs to be 
because it contains some unnecessary redundancy.
This explains your test results.
Compact Filter and nf-HiPAC perform the same when they are both able to keep 
their lookup data structure in the CPU caches and when they are both not able 
to do so anymore.
Compact Filter is currently able to perform better in the area where it is 
able to keep its data structure still in the caches while nf-HiPAC is not 
able to do so anymore.

It would seem, looking at the provided results and author's comments, that the following are true:
  - for small static rulesets there is little difference, my 200-600 rules run fine in either
  - for very large rulesets cf will currently perform better (if this is due to cache effects, may be less
    evident, since the server runs an application rather than being a dedicated network device).
  - cf can't do large dynamic rulesets, compile time > change interval
  - the iptables results don't represent server use with persistent sockets, like mail/usenet, in which
    most (~95%) packets match the first rule in INPUT (ESTABLISHED -> ACCEPT) and the complexity is
    in processing TCP/SYN packets and forwarding rules.

Also: none of the results I've seen show the effect of many tracked sockets, the performance of one stream pushing a lot of packets is not the same as the same bitrate coming from 500-5k source IPs, at least if you use the INPUT rule noted above.
Most aspects of your performance tests are quite nice (e.g. the generating the 
traffic by replaying a packet header trace).
But your performance tests have a serious flaw:
You construct your rule set by creating one rule for each entry in your packet 
header trace. This results in an completely artificial rule set that creates 
a lot of redundancy in the nf-HiPAC lookup data structure making it much 
larger than the Compact Filter data structure.

You have to understand that with real world rule sets the size of the computed 
lookup data structure will not be much different for Compact Filter and 
nf-HiPAC. This means that when you use real world rule sets there shouldn't 
be any noticeable difference in lookup performance betweeen Compact Filter 
and nf-HiPAC.

-----------------

I am currently working on a new improved version of the algorithm used in 
nf-HiPAC. The new algorithmic core will reduce memory usage while at the same 
time improving the running time of insert and delete operations. The lookup 
performance will be improved too, especially for bigger rulesets. The 
concepts and the design are already developed, but the implementation is 
still in its early stages.

The new algorithmic core will make sure that the lookup data structure in the 
kernel is always fully optimized while at the same time allowing very fast 
dynamic updates.

At that point Compact Filter will not be able to win in any performance test 
against  nf-HiPAC anymore, simply because there is no way to optimize the 
lookup data structure any further.
The nf-HiPAC advantage seems to be in applications with moderate to large dynamic rulesets, in that it allows a lot of changes quickly. Don't give that up for throughput, the idea of being able to do 5-7 changes/sec on a 500-2k ruleset is exciting, and in some cases vital.

Thanks to everyone working on improvements.

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979
--------------040706060300040508090100-- From vvs@sw.ru Sat Oct 8 06:11:27 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 08 Oct 2005 06:11:39 -0700 (PDT) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j98DBPO0030011 for ; Sat, 8 Oct 2005 06:11:26 -0700 Received: from [192.168.0.157] (dhcp0-157.sw.ru [192.168.0.157]) by relay.sw.ru (8.13.0/8.13.0) with ESMTP id j98D76T5010929; Sat, 8 Oct 2005 17:07:48 +0400 (MSD) Message-ID: <4347C50A.9010501@sw.ru> Date: Sat, 08 Oct 2005 17:09:30 +0400 From: Vasily Averin Organization: SW-soft User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: Daniele Venzano , Andrew Morton CC: Jeff Garzik , NetDev , Stanislav Protassov Subject: Re: [PATCH] sis900: come alive after temporary memory shortage References: <4337E76B.1090003@sw.ru> <8204E0D1-F30D-494F-8E97-CDCC26A82807@libero.it> <4337FF9D.70200@sw.ru> <20051006104004.GA2124@renditai.milesteg.arr> In-Reply-To: <20051006104004.GA2124@renditai.milesteg.arr> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------060507080307030409050507" X-archive-position: 3736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vvs@sw.ru Precedence: bulk X-list: netdev Content-Length: 3781 Lines: 106 This is a multi-part message in MIME format. --------------060507080307030409050507 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Daniele Venzano wrote: > This patch is good and fixes some corner cases. Please consider for > inclusion. Daniele, sorry, but unfortunately our patch was wrong. > + int rx_work_limit = > + (sis_priv->dirty_rx - sis_priv->cur_rx) % NUM_RX_DESC; when dirty_rx = cur_rx it computes limit=0, but should be NUM_RX_DESC Also I've noticed that 'if (sis_priv->rx_skbuff[entry] == NULL)' statement inside the while loop is really impossible now. Therefore I've increased message loglevel up to KERN_WARNING and added some useful debug. Daniele, could you please check our new patch carefully? Andrew, could you please drop our old patch and replace it by the new one? Thank you, Vasily Averin, SWsoft Linux kernel team Patch solves following problems: 1) Forgotten counter incrementation in sis900_rx() in case it doesn't get memory for skb, that leads to whole interface failure. Problem is accompanied with messages: eth0: Memory squeeze,deferring packet. eth0: NULL pointer encountered in Rx ring, skipping 2) If counter cur_rx overflows and there'll be temporary memory problems buffer can't be recreated later, when memory IS available. 3) Limit the work in handler to prevent the endless packets processing if new packets are generated faster then handled. Signed-off-by: Konstantin Khorenko Signed-off-by: Vasily Averin --------------060507080307030409050507 Content-Type: text/plain; name="diff-drv-sis900-20051008" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff-drv-sis900-20051008" --- a/drivers/net/sis900.c 2005-10-08 12:22:53.000000000 +0400 +++ b/drivers/net/sis900.c 2005-10-08 15:12:29.000000000 +0400 @@ -1696,15 +1696,20 @@ static int sis900_rx(struct net_device * long ioaddr = net_dev->base_addr; unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC; u32 rx_status = sis_priv->rx_ring[entry].cmdsts; + int rx_work_limit; if (netif_msg_rx_status(sis_priv)) printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d " "status:0x%8.8x\n", sis_priv->cur_rx, sis_priv->dirty_rx, rx_status); + rx_work_limit = sis_priv->dirty_rx + NUM_RX_DESC - sis_priv->cur_rx; while (rx_status & OWN) { unsigned int rx_size; + if (--rx_work_limit < 0) + break; + rx_size = (rx_status & DSIZE) - CRC_SIZE; if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) { @@ -1732,9 +1737,11 @@ static int sis900_rx(struct net_device * we are working on NULL sk_buff :-( */ if (sis_priv->rx_skbuff[entry] == NULL) { if (netif_msg_rx_err(sis_priv)) - printk(KERN_INFO "%s: NULL pointer " - "encountered in Rx ring, skipping\n", - net_dev->name); + printk(KERN_WARNING "%s: NULL pointer " + "encountered in Rx ring\n" + "cur_rx:%4.4d, dirty_rx:%4.4d\n", + net_dev->name, sis_priv->cur_rx, + sis_priv->dirty_rx); break; } @@ -1770,6 +1777,7 @@ static int sis900_rx(struct net_device * sis_priv->rx_ring[entry].cmdsts = 0; sis_priv->rx_ring[entry].bufptr = 0; sis_priv->stats.rx_dropped++; + sis_priv->cur_rx++; break; } skb->dev = net_dev; @@ -1787,7 +1795,7 @@ static int sis900_rx(struct net_device * /* refill the Rx buffer, what if the rate of refilling is slower * than consuming ?? */ - for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) { + for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) { struct sk_buff *skb; entry = sis_priv->dirty_rx % NUM_RX_DESC; --------------060507080307030409050507-- From venza@brownhat.org Mon Oct 10 01:40:19 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 10 Oct 2005 01:40:31 -0700 (PDT) Received: from renditai.milesteg.arr (adsl-165-99.38-151.net24.it [151.38.99.165]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9A8eHO0001009 for ; Mon, 10 Oct 2005 01:40:18 -0700 Received: (qmail 7240 invoked by uid 1000); 10 Oct 2005 10:37:15 +0200 Date: Mon, 10 Oct 2005 10:37:15 +0200 From: Daniele Venzano To: Vasily Averin Cc: Andrew Morton , Jeff Garzik , NetDev , Stanislav Protassov Subject: Re: [PATCH] sis900: come alive after temporary memory shortage Message-ID: <20051010083715.GA7202@renditai.milesteg.arr> Mail-Followup-To: Vasily Averin , Andrew Morton , Jeff Garzik , NetDev , Stanislav Protassov References: <4337E76B.1090003@sw.ru> <8204E0D1-F30D-494F-8E97-CDCC26A82807@libero.it> <4337FF9D.70200@sw.ru> <20051006104004.GA2124@renditai.milesteg.arr> <4347C50A.9010501@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4347C50A.9010501@sw.ru> X-Operating-System: Debian GNU/Linux on kernel Linux 2.6.12.1 X-Copyright: Forwarding or publishing without permission is prohibited. X-Truth: La vita e' una questione di culo, o ce l'hai o te lo fanno. X-GPG-Fingerprint: 642A A345 1CEF B6E3 925C 23CE DAB9 8764 25B3 57ED User-Agent: Mutt/1.5.9i X-archive-position: 3739 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 3192 Lines: 80 On Sat, Oct 08, 2005 at 05:09:30PM +0400, Vasily Averin wrote: > Daniele, could you please check our new patch carefully? This time I tested it as thoroughly as possible. It kept working during all the time the memory was filling up, until the OOM killer woke up from his dark pit. After OOM frenzy, the driver was still alive and kicking. > Andrew, could you please drop our old patch and replace it by the new one? Yes, this one is better, thanks. > Patch solves following problems: > 1) Forgotten counter incrementation in sis900_rx() in case > it doesn't get memory for skb, that leads to whole interface failure. > Problem is accompanied with messages: > eth0: Memory squeeze,deferring packet. > eth0: NULL pointer encountered in Rx ring, skipping > 2) If counter cur_rx overflows and there'll be temporary memory problems > buffer can't be recreated later, when memory IS available. > 3) Limit the work in handler to prevent the endless packets processing if > new packets are generated faster then handled. > > Signed-off-by: Konstantin Khorenko > Signed-off-by: Vasily Averin Signed-off-by: Daniele Venzano --- a/drivers/net/sis900.c 2005-10-08 12:22:53.000000000 +0400 +++ b/drivers/net/sis900.c 2005-10-08 15:12:29.000000000 +0400 @@ -1696,15 +1696,20 @@ static int sis900_rx(struct net_device * long ioaddr = net_dev->base_addr; unsigned int entry = sis_priv->cur_rx % NUM_RX_DESC; u32 rx_status = sis_priv->rx_ring[entry].cmdsts; + int rx_work_limit; if (netif_msg_rx_status(sis_priv)) printk(KERN_DEBUG "sis900_rx, cur_rx:%4.4d, dirty_rx:%4.4d " "status:0x%8.8x\n", sis_priv->cur_rx, sis_priv->dirty_rx, rx_status); + rx_work_limit = sis_priv->dirty_rx + NUM_RX_DESC - sis_priv->cur_rx; while (rx_status & OWN) { unsigned int rx_size; + if (--rx_work_limit < 0) + break; + rx_size = (rx_status & DSIZE) - CRC_SIZE; if (rx_status & (ABORT|OVERRUN|TOOLONG|RUNT|RXISERR|CRCERR|FAERR)) { @@ -1732,9 +1737,11 @@ static int sis900_rx(struct net_device * we are working on NULL sk_buff :-( */ if (sis_priv->rx_skbuff[entry] == NULL) { if (netif_msg_rx_err(sis_priv)) - printk(KERN_INFO "%s: NULL pointer " - "encountered in Rx ring, skipping\n", - net_dev->name); + printk(KERN_WARNING "%s: NULL pointer " + "encountered in Rx ring\n" + "cur_rx:%4.4d, dirty_rx:%4.4d\n", + net_dev->name, sis_priv->cur_rx, + sis_priv->dirty_rx); break; } @@ -1770,6 +1777,7 @@ static int sis900_rx(struct net_device * sis_priv->rx_ring[entry].cmdsts = 0; sis_priv->rx_ring[entry].bufptr = 0; sis_priv->stats.rx_dropped++; + sis_priv->cur_rx++; break; } skb->dev = net_dev; @@ -1787,7 +1795,7 @@ static int sis900_rx(struct net_device * /* refill the Rx buffer, what if the rate of refilling is slower * than consuming ?? */ - for (;sis_priv->cur_rx - sis_priv->dirty_rx > 0; sis_priv->dirty_rx++) { + for (; sis_priv->cur_rx != sis_priv->dirty_rx; sis_priv->dirty_rx++) { struct sk_buff *skb; entry = sis_priv->dirty_rx % NUM_RX_DESC; From venza@brownhat.org Tue Oct 11 00:47:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Oct 2005 00:47:39 -0700 (PDT) Received: from renditai.milesteg.arr (adsl-100-231.38-151.net24.it [151.38.231.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9B7lVO0015982 for ; Tue, 11 Oct 2005 00:47:32 -0700 Received: (qmail 29843 invoked by uid 1000); 11 Oct 2005 09:44:30 +0200 Date: Tue, 11 Oct 2005 09:44:30 +0200 From: Daniele Venzano To: Jeff Garzik , NetDev Cc: akpm@osdl.org Subject: [PATCH] Add Wake on LAN support to sis900 (2) Message-ID: <20051011074430.GA29824@renditai.milesteg.arr> Mail-Followup-To: Jeff Garzik , NetDev , akpm@osdl.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-archive-position: 3740 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 6346 Lines: 206 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry, but that day I had smoked somthing too heavy for me, the patch didn't apply. Here's a new one. The patch availble below adds support for Wake on LAN to the sis900 driver. Some register addresses were added to sis900.h and two new functions were implemented in sis900.c. WoL status is controlled by ethtool. Patch is against 2.6.13. Comments are welcome, but also consider for inclusion in the -mm series. Signed-off-by: Daniele Venzano -- ------------------------------ Daniele Venzano Web: http://teg.homeunix.org --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sis900_c_127.diff" --- a/drivers/net/sis900.h 2005-07-17 10:43:23.000000000 +0200 +++ b/drivers/net/sis900.h 2005-10-06 12:49:37.000000000 +0200 @@ -33,6 +33,7 @@ rxcfg=0x34, //Receive Configuration Register flctrl=0x38, //Flow Control Register rxlen=0x3c, //Receive Packet Length Register + cfgpmcsr=0x44, //Configuration Power Management Control/Status Register rfcr=0x48, //Receive Filter Control Register rfdr=0x4C, //Receive Filter Data Register pmctrl=0xB0, //Power Management Control Register @@ -140,6 +141,50 @@ EEREQ = 0x00000400, EEDONE = 0x00000200, EEGNT = 0x00000100 }; +/* PCI Registers */ +enum sis900_pci_registers { + CFGPMC = 0x40, + CFGPMCSR = 0x44 +}; + +/* Power management capabilities bits */ +enum sis900_cfgpmc_register_bits { + PMVER = 0x00070000, + DSI = 0x00100000, + PMESP = 0xf8000000 +}; + +enum sis900_pmesp_bits { + PME_D0 = 0x1, + PME_D1 = 0x2, + PME_D2 = 0x4, + PME_D3H = 0x8, + PME_D3C = 0x10 +}; + +/* Power management control/status bits */ +enum sis900_cfgpmcsr_register_bits { + PMESTS = 0x00004000, + PME_EN = 0x00000100, // Power management enable + PWR_STA = 0x00000003 // Current power state +}; + +/* Wake-on-LAN support. */ +enum sis900_power_management_control_register_bits { + LINKLOSS = 0x00000001, + LINKON = 0x00000002, + MAGICPKT = 0x00000400, + ALGORITHM = 0x00000800, + FRM1EN = 0x00100000, + FRM2EN = 0x00200000, + FRM3EN = 0x00400000, + FRM1ACS = 0x01000000, + FRM2ACS = 0x02000000, + FRM3ACS = 0x04000000, + WAKEALL = 0x40000000, + GATECLK = 0x80000000 +}; + /* Management Data I/O (mdio) frame */ #define MIIread 0x6000 #define MIIwrite 0x5002 --- a/drivers/net/sis900.c 2005-10-06 12:06:06.000000000 +0200 +++ b/drivers/net/sis900.c 2005-10-06 12:05:45.000000000 +0200 @@ -1,6 +1,6 @@ /* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux. Copyright 1999 Silicon Integrated System Corporation - Revision: 1.08.08 Jan. 22 2005 + Revision: 1.08.09 Sep. 19 2005 Modified from the driver which is originally written by Donald Becker. @@ -17,6 +17,7 @@ SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution, preliminary Rev. 1.0 Jan. 18, 1998 + Rev 1.08.09 Sep. 19 2005 Daniele Venzano add Wake on LAN support Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages Rev 1.08.07 Nov. 2 2003 Daniele Venzano add suspend/resume support Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support @@ -76,7 +77,7 @@ #include "sis900.h" #define SIS900_MODULE_NAME "sis900" -#define SIS900_DRV_VERSION "v1.08.08 Jan. 22 2005" +#define SIS900_DRV_VERSION "v1.08.09 Sep. 19 2005" static char version[] __devinitdata = KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n"; @@ -538,6 +539,11 @@ printk("%2.2x:", (u8)net_dev->dev_addr[i]); printk("%2.2x.\n", net_dev->dev_addr[i]); + /* Detect Wake on Lan support */ + ret = inl(CFGPMC & PMESP); + if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0) + printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name); + return 0; err_unmap_rx: @@ -2007,6 +2013,67 @@ return mii_nway_restart(&sis_priv->mii_info); } +/** + * sis900_set_wol - Set up Wake on Lan registers + * @net_dev: the net device to probe + * @wol: container for info passed to the driver + * + * Process ethtool command "wol" to setup wake on lan features. + * SiS900 supports sending WoL events if a correct packet is received, + * but there is no simple way to filter them to only a subset (broadcast, + * multicast, unicast or arp). + */ + +static int sis900_set_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol) +{ + struct sis900_private *sis_priv = net_dev->priv; + long pmctrl_addr = net_dev->base_addr + pmctrl; + u32 cfgpmcsr = 0, pmctrl_bits = 0; + + if (wol->wolopts == 0) { + pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr); + cfgpmcsr |= ~PME_EN; + pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr); + outl(pmctrl_bits, pmctrl_addr); + if (netif_msg_wol(sis_priv)) + printk(KERN_DEBUG "%s: Wake on LAN disabled\n", net_dev->name); + return 0; + } + + if (wol->wolopts & (WAKE_MAGICSECURE | WAKE_UCAST | WAKE_MCAST + | WAKE_BCAST | WAKE_ARP)) + return -EINVAL; + + if (wol->wolopts & WAKE_MAGIC) + pmctrl_bits |= MAGICPKT; + if (wol->wolopts & WAKE_PHY) + pmctrl_bits |= LINKON; + + outl(pmctrl_bits, pmctrl_addr); + + pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr); + cfgpmcsr |= PME_EN; + pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr); + if (netif_msg_wol(sis_priv)) + printk(KERN_DEBUG "%s: Wake on LAN enabled\n", net_dev->name); + + return 0; +} + +static void sis900_get_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol) +{ + long pmctrl_addr = net_dev->base_addr + pmctrl; + u32 pmctrl_bits; + + pmctrl_bits = inl(pmctrl_addr); + if (pmctrl_bits & MAGICPKT) + wol->wolopts |= WAKE_MAGIC; + if (pmctrl_bits & LINKON) + wol->wolopts |= WAKE_PHY; + + wol->supported = (WAKE_PHY | WAKE_MAGIC); +} + static struct ethtool_ops sis900_ethtool_ops = { .get_drvinfo = sis900_get_drvinfo, .get_msglevel = sis900_get_msglevel, @@ -2015,6 +2082,8 @@ .get_settings = sis900_get_settings, .set_settings = sis900_set_settings, .nway_reset = sis900_nway_reset, + .get_wol = sis900_get_wol, + .set_wol = sis900_set_wol }; /** --y0ulUmNC+osPPQO6-- From shemminger@osdl.org Tue Oct 11 13:40:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Oct 2005 13:40:33 -0700 (PDT) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9BKeHO0028076 for ; Tue, 11 Oct 2005 13:40:19 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j9BKb04s000738 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Oct 2005 13:37:01 -0700 Received: from localhost.localdomain (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j9BKb0dT026134; Tue, 11 Oct 2005 13:37:00 -0700 Date: Tue, 11 Oct 2005 13:33:28 -0700 From: Stephen Hemminger To: Ryan Harper , "David S. Miller" Cc: netdev@oss.sgi.com, Chris Wright , Greg KH Subject: [PATCH] br: fix race on bridge del if Message-ID: <20051011133328.26db65d7@localhost.localdomain> In-Reply-To: <20050818214036.GH10593@us.ibm.com> References: <20050818214036.GH10593@us.ibm.com> X-Mailer: Sylpheed-Claws 1.9.14 (GTK+ 2.6.10; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.123 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 3741 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: 1015 Lines: 31 This fixes the RCU race on bridge delete interface. Basically, the network device has to be detached from the bridge in the first step (pre-RCU), rather than later. At that point, no more bridge traffic will come in, and the other code will not think that network device is part of a bridge. This should also fix the XEN test problems. If there is another 2.6.13-stable, add it as well. Signed-off-by: Stephen Hemminger Index: nexgate-test/net/bridge/br_if.c =================================================================== --- nexgate-test.orig/net/bridge/br_if.c +++ nexgate-test/net/bridge/br_if.c @@ -79,7 +79,6 @@ static void destroy_nbp(struct net_bridg { struct net_device *dev = p->dev; - dev->br_port = NULL; p->br = NULL; p->dev = NULL; dev_put(dev); @@ -100,6 +99,7 @@ static void del_nbp(struct net_bridge_po struct net_bridge *br = p->br; struct net_device *dev = p->dev; + dev->br_port = NULL; dev_set_promiscuity(dev, -1); spin_lock_bh(&br->lock); From akpm@osdl.org Tue Oct 11 20:56:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 11 Oct 2005 20:56:38 -0700 (PDT) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9C3uZO0003268 for ; Tue, 11 Oct 2005 20:56:35 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j9C3rV4s019802 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Oct 2005 20:53:31 -0700 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id j9C3rUH2012442; Tue, 11 Oct 2005 20:53:30 -0700 Date: Tue, 11 Oct 2005 20:53:04 -0700 From: Andrew Morton To: Daniele Venzano Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] Add Wake on LAN support to sis900 Message-Id: <20051011205304.34bc07ad.akpm@osdl.org> In-Reply-To: <20051006111326.GA3242@renditai.milesteg.arr> References: <20051006111326.GA3242@renditai.milesteg.arr> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.124 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 3742 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: 1184 Lines: 36 Daniele Venzano wrote: > > The patch availble below adds support for Wake on LAN to the sis900 > driver. Some register addresses were added to sis900.h and two new > functions were implemented in sis900.c. WoL status is controlled by > ethtool. > Patch is against 2.6.13. > > Comments are welcome, but also consider for inclusion in the -mm series. > > --- ../../trunk/sis900.h 2005-07-17 10:43:23.000000000 +0200 > +++ sis900.h 2005-10-06 12:49:37.000000000 +0200 Please prepare patches in `patch -p1' form. See http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt. > ... > + /* Detect Wake on Lan support */ > + ret = inl(CFGPMC & PMESP); > + if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0) > + printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name); > + How come? Why doesn't it work after an ordinary `halt -p'? > @@ -2015,6 +2082,8 @@ > .get_settings = sis900_get_settings, > .set_settings = sis900_set_settings, > .nway_reset = sis900_nway_reset, > + .get_wol = sis900_get_wol, > + .set_wol = sis900_set_wol > }; We normally add a comma to the final field so that subsequent patches look cleaner. From venza@brownhat.org Wed Oct 12 10:35:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 12 Oct 2005 10:35:20 -0700 (PDT) Received: from renditai.milesteg.arr (adsl-100-231.38-151.net24.it [151.38.231.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9CHZCO0021193 for ; Wed, 12 Oct 2005 10:35:13 -0700 Received: (qmail 29285 invoked from network); 12 Oct 2005 19:32:11 +0200 Received: from unknown (HELO ?192.168.0.205?) (192.168.0.205) by renditai.milesteg.arr with SMTP; 12 Oct 2005 19:32:11 +0200 In-Reply-To: <20051011205304.34bc07ad.akpm@osdl.org> References: <20051006111326.GA3242@renditai.milesteg.arr> <20051011205304.34bc07ad.akpm@osdl.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A6A690F-B394-4C70-B2B8-74D2271D14AB@brownhat.org> Cc: jgarzik@pobox.com, netdev@oss.sgi.com Content-Transfer-Encoding: 7bit From: Daniele Venzano Subject: Re: [PATCH] Add Wake on LAN support to sis900 Date: Wed, 12 Oct 2005 19:32:07 +0200 To: Andrew Morton X-Mailer: Apple Mail (2.734) X-archive-position: 3743 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: venza@brownhat.org Precedence: bulk X-list: netdev Content-Length: 1492 Lines: 43 Il giorno 12/ott/05, alle ore 05:53, Andrew Morton ha scritto: >> --- ../../trunk/sis900.h 2005-07-17 10:43:23.000000000 +0200 >> +++ sis900.h 2005-10-06 12:49:37.000000000 +0200 >> > > Please prepare patches in `patch -p1' form. See > http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt. Yes, I did send a corrected patch some days later, when I found out. This was the only correction I made there, so you can just trash it. >> + /* Detect Wake on Lan support */ >> + ret = inl(CFGPMC & PMESP); >> + if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0) >> + printk(KERN_INFO "%s: Wake on LAN only available from >> suspend to RAM.", net_dev->name); >> + >> > > How come? Why doesn't it work after an ordinary `halt -p'? That register should report, according to the specs, the status of the additional power supply needed to keep awake the chip when the computer is shut down. Usually there is an additional cable to be installed between the NIC and the motherboard, but on laptops or embedded chips it's difficult to know. >> @@ -2015,6 +2082,8 @@ >> .get_settings = sis900_get_settings, >> .set_settings = sis900_set_settings, >> .nway_reset = sis900_nway_reset, >> + .get_wol = sis900_get_wol, >> + .set_wol = sis900_set_wol >> }; >> > > We normally add a comma to the final field so that subsequent > patches look > cleaner. Will do. Thanks for the comments. -- Daniele Venzano http://www.brownhat.org From davem@davemloft.net Wed Oct 12 15:13:36 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 12 Oct 2005 15:13:45 -0700 (PDT) Received: from sunset.davemloft.net (dsl027-180-168.sfo1.dsl.speakeasy.net [216.27.180.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9CMDWO0017470 for ; Wed, 12 Oct 2005 15:13:34 -0700 Received: from localhost ([127.0.0.1] ident=davem) by sunset.davemloft.net with esmtp (Exim 4.52) id 1EPonf-0001YR-1c; Wed, 12 Oct 2005 15:10:15 -0700 Date: Wed, 12 Oct 2005 15:10:14 -0700 (PDT) Message-Id: <20051012.151014.12946945.davem@davemloft.net> To: shemminger@osdl.org Cc: ryanh@us.ibm.com, netdev@oss.sgi.com, chrisw@osdl.org, greg@kroah.com Subject: Re: [PATCH] br: fix race on bridge del if From: "David S. Miller" In-Reply-To: <20051011133328.26db65d7@localhost.localdomain> References: <20050818214036.GH10593@us.ibm.com> <20051011133328.26db65d7@localhost.localdomain> X-Mailer: Mew version 4.2.53 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 3744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@davemloft.net Precedence: bulk X-list: netdev Content-Length: 576 Lines: 15 From: Stephen Hemminger Date: Tue, 11 Oct 2005 13:33:28 -0700 > This fixes the RCU race on bridge delete interface. Basically, > the network device has to be detached from the bridge in the first > step (pre-RCU), rather than later. At that point, no more bridge traffic > will come in, and the other code will not think that network device > is part of a bridge. > > This should also fix the XEN test problems. If there is another > 2.6.13-stable, add it as well. > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. From cam@mathematica.scientia.net Sun Oct 16 14:22:53 2005 Received: with ECARTIS (v1.0.0; list netdev); Sun, 16 Oct 2005 14:23:02 -0700 (PDT) Received: from mailer2-1.key-systems.net (mailer2-1.key-systems.net [81.3.43.253]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j9GLMpO0020296 for ; Sun, 16 Oct 2005 14:22:51 -0700 Received: (qmail 12689 invoked from network); 16 Oct 2005 21:19:49 -0000 Received: from dslb-084-056-000-166.pools.arcor-ip.net (HELO ?84.56.0.166?) (84.56.0.166) by mailer2-1.key-systems.net with SMTP; 16 Oct 2005 21:19:49 -0000 Message-ID: <4352C3F2.1000102@mathematica.scientia.net> Date: Sun, 16 Oct 2005 23:19:46 +0200 From: Christoph Anton Mitterer User-Agent: Debian Thunderbird 1.0.7 (X11/20051010) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: c-d.hailfinger.kernel.2004@gmx.net Subject: Networ Problems (NETDEV WATCHDOG: eth2: transmit timed out) X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/mixed; boundary="------------010603060407060408040005" X-archive-position: 3750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cam@mathematica.scientia.net Precedence: bulk X-list: netdev Content-Length: 84128 Lines: 1215 This is a multi-part message in MIME format. --------------010603060407060408040005 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi. I'm using a Dual-DualCore-Opteron System on a Tyan S2895 mainboard (Thunder K8WE, see http://www.tyan.com/products/html/thunderk8we_spec.html for specifications). It has two Gigabit Ethernet ports. One is connected to the Chipset connected to CPU1 (Nvidia nForce Professional 2200), the other to the Chipset connected to CPU2 (Nvidia nForce Professional 2050); there's also a 3rd chipset, AMD 8131 but that should be unimportant here. When you look at the kern.log you see that I've some problems with the Networkcard (NETDEV WATCHDOG: eth?: transmit timed out). So I'm writing to you, as I'm using the forcedeth driver :-) . Ok here some description: I'm using a 3 Mbit down / 512 Kbit up ADSL connection via PPPoE (the experimental one) (see my kernel config). The problem always occurs on the eth interface that is connected to my ADSL-modem, and then internet fails, and it takes long time until I can reconnect it (even when doing poff/pon or so) btw: I'm using Debian sid, everything in the neweset versions, the newest kernel (2.6.13.4), too. Ok,.. when doing "normal" internet work, like downloading big files, or www browsing or chatting, et cetera ... everything just works fine... BUT (!!) ;-) .... when I'm starting mldonkey it doesn't take long until I get the errors I noticed in my kern.log. The NETDEV WATCHDOG messages are repeating until I stop mldonkey. Now one could say, that this is a mldonkey problem but I don't think so: 1) There are no bugreports that tell about the same problem. 2) mldonkey is running (of course) as non-root and should not be able to crash networt inferfaces and internet. 3) With my old computer (using Realtek bulk network card) with the same mldonkey version and the sam mldonkey-config, everything just worked fine. Ok,.. I have no idea, but perhaps the reason is the number of connections (TCP/IP) that mldonkey establishes. Any idea? Would be great if you could help. If you need further material, simply ask :-) Best wishes, Christoph Anton Mitterer. btw: Please CC me, as I haven't subscribed to the list (... yet). --------------010603060407060408040005 Content-Type: text/plain; name=".config" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=".config" IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIG1ha2UgY29uZmlnOiBkb24ndCBlZGl0CiMg TGludXgga2VybmVsIHZlcnNpb246IDIuNi4xMy40CiMgU3VuIE9jdCAxNiAyMjozMjoyOCAy MDA1CiMKQ09ORklHX1g4Nj15CkNPTkZJR19NTVU9eQpDT05GSUdfVUlEMTY9eQpDT05GSUdf R0VORVJJQ19JU0FfRE1BPXkKQ09ORklHX0dFTkVSSUNfSU9NQVA9eQoKIwojIENvZGUgbWF0 dXJpdHkgbGV2ZWwgb3B0aW9ucwojCkNPTkZJR19FWFBFUklNRU5UQUw9eQpDT05GSUdfQ0xF QU5fQ09NUElMRT15CkNPTkZJR19MT0NLX0tFUk5FTD15CkNPTkZJR19JTklUX0VOVl9BUkdf TElNSVQ9MzIKCiMKIyBHZW5lcmFsIHNldHVwCiMKQ09ORklHX0xPQ0FMVkVSU0lPTj0iIgpD T05GSUdfU1dBUD15CkNPTkZJR19TWVNWSVBDPXkKQ09ORklHX1BPU0lYX01RVUVVRT15CkNP TkZJR19CU0RfUFJPQ0VTU19BQ0NUPXkKQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1RfVjM9eQpD T05GSUdfU1lTQ1RMPXkKQ09ORklHX0FVRElUPXkKQ09ORklHX0FVRElUU1lTQ0FMTD15CkNP TkZJR19IT1RQTFVHPXkKQ09ORklHX0tPQkpFQ1RfVUVWRU5UPXkKIyBDT05GSUdfSUtDT05G SUcgaXMgbm90IHNldApDT05GSUdfQ1BVU0VUUz15CiMgQ09ORklHX0VNQkVEREVEIGlzIG5v dCBzZXQKQ09ORklHX0tBTExTWU1TPXkKIyBDT05GSUdfS0FMTFNZTVNfRVhUUkFfUEFTUyBp cyBub3Qgc2V0CkNPTkZJR19QUklOVEs9eQpDT05GSUdfQlVHPXkKQ09ORklHX0JBU0VfRlVM TD15CkNPTkZJR19GVVRFWD15CkNPTkZJR19FUE9MTD15CkNPTkZJR19TSE1FTT15CkNPTkZJ R19DQ19BTElHTl9GVU5DVElPTlM9MApDT05GSUdfQ0NfQUxJR05fTEFCRUxTPTAKQ09ORklH X0NDX0FMSUdOX0xPT1BTPTAKQ09ORklHX0NDX0FMSUdOX0pVTVBTPTAKIyBDT05GSUdfVElO WV9TSE1FTSBpcyBub3Qgc2V0CkNPTkZJR19CQVNFX1NNQUxMPTAKCiMKIyBMb2FkYWJsZSBt b2R1bGUgc3VwcG9ydAojCkNPTkZJR19NT0RVTEVTPXkKQ09ORklHX01PRFVMRV9VTkxPQUQ9 eQojIENPTkZJR19NT0RVTEVfRk9SQ0VfVU5MT0FEIGlzIG5vdCBzZXQKQ09ORklHX09CU09M RVRFX01PRFBBUk09eQojIENPTkZJR19NT0RWRVJTSU9OUyBpcyBub3Qgc2V0CkNPTkZJR19N T0RVTEVfU1JDVkVSU0lPTl9BTEw9eQpDT05GSUdfS01PRD15CkNPTkZJR19TVE9QX01BQ0hJ TkU9eQoKIwojIFByb2Nlc3NvciB0eXBlIGFuZCBmZWF0dXJlcwojCkNPTkZJR19YODZfUEM9 eQojIENPTkZJR19YODZfRUxBTiBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9WT1lBR0VSIGlz IG5vdCBzZXQKIyBDT05GSUdfWDg2X05VTUFRIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X1NV TU1JVCBpcyBub3Qgc2V0CiMgQ09ORklHX1g4Nl9CSUdTTVAgaXMgbm90IHNldAojIENPTkZJ R19YODZfVklTV1MgaXMgbm90IHNldAojIENPTkZJR19YODZfR0VORVJJQ0FSQ0ggaXMgbm90 IHNldAojIENPTkZJR19YODZfRVM3MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTTM4NiBpcyBu b3Qgc2V0CiMgQ09ORklHX000ODYgaXMgbm90IHNldAojIENPTkZJR19NNTg2IGlzIG5vdCBz ZXQKIyBDT05GSUdfTTU4NlRTQyBpcyBub3Qgc2V0CiMgQ09ORklHX001ODZNTVggaXMgbm90 IHNldAojIENPTkZJR19NNjg2IGlzIG5vdCBzZXQKIyBDT05GSUdfTVBFTlRJVU1JSSBpcyBu b3Qgc2V0CiMgQ09ORklHX01QRU5USVVNSUlJIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBFTlRJ VU1NIGlzIG5vdCBzZXQKIyBDT05GSUdfTVBFTlRJVU00IGlzIG5vdCBzZXQKIyBDT05GSUdf TUs2IGlzIG5vdCBzZXQKIyBDT05GSUdfTUs3IGlzIG5vdCBzZXQKQ09ORklHX01LOD15CiMg Q09ORklHX01DUlVTT0UgaXMgbm90IHNldAojIENPTkZJR19NRUZGSUNFT04gaXMgbm90IHNl dAojIENPTkZJR19NV0lOQ0hJUEM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTVdJTkNISVAyIGlz IG5vdCBzZXQKIyBDT05GSUdfTVdJTkNISVAzRCBpcyBub3Qgc2V0CiMgQ09ORklHX01HRU9E RUdYMSBpcyBub3Qgc2V0CiMgQ09ORklHX01DWVJJWElJSSBpcyBub3Qgc2V0CiMgQ09ORklH X01WSUFDM18yIGlzIG5vdCBzZXQKIyBDT05GSUdfWDg2X0dFTkVSSUMgaXMgbm90IHNldApD T05GSUdfWDg2X0NNUFhDSEc9eQpDT05GSUdfWDg2X1hBREQ9eQpDT05GSUdfWDg2X0wxX0NB Q0hFX1NISUZUPTYKQ09ORklHX1JXU0VNX1hDSEdBRERfQUxHT1JJVEhNPXkKQ09ORklHX0dF TkVSSUNfQ0FMSUJSQVRFX0RFTEFZPXkKQ09ORklHX1g4Nl9XUF9XT1JLU19PSz15CkNPTkZJ R19YODZfSU5WTFBHPXkKQ09ORklHX1g4Nl9CU1dBUD15CkNPTkZJR19YODZfUE9QQURfT0s9 eQpDT05GSUdfWDg2X0dPT0RfQVBJQz15CkNPTkZJR19YODZfSU5URUxfVVNFUkNPUFk9eQpD T05GSUdfWDg2X1VTRV9QUFJPX0NIRUNLU1VNPXkKQ09ORklHX0hQRVRfVElNRVI9eQpDT05G SUdfSFBFVF9FTVVMQVRFX1JUQz15CkNPTkZJR19TTVA9eQpDT05GSUdfTlJfQ1BVUz00CiMg Q09ORklHX1NDSEVEX1NNVCBpcyBub3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfTk9ORSBpcyBu b3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIGlzIG5vdCBzZXQKQ09ORklHX1BS RUVNUFQ9eQpDT05GSUdfUFJFRU1QVF9CS0w9eQpDT05GSUdfWDg2X0xPQ0FMX0FQSUM9eQpD T05GSUdfWDg2X0lPX0FQSUM9eQpDT05GSUdfWDg2X1RTQz15CkNPTkZJR19YODZfTUNFPXkK Q09ORklHX1g4Nl9NQ0VfTk9ORkFUQUw9eQojIENPTkZJR19YODZfTUNFX1A0VEhFUk1BTCBp cyBub3Qgc2V0CiMgQ09ORklHX1RPU0hJQkEgaXMgbm90IHNldAojIENPTkZJR19JOEsgaXMg bm90IHNldAojIENPTkZJR19YODZfUkVCT09URklYVVBTIGlzIG5vdCBzZXQKIyBDT05GSUdf TUlDUk9DT0RFIGlzIG5vdCBzZXQKQ09ORklHX1g4Nl9NU1I9eQpDT05GSUdfWDg2X0NQVUlE PW0KCiMKIyBGaXJtd2FyZSBEcml2ZXJzCiMKIyBDT05GSUdfRUREIGlzIG5vdCBzZXQKIyBD T05GSUdfTk9ISUdITUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfSElHSE1FTTRHIGlzIG5vdCBz ZXQKQ09ORklHX0hJR0hNRU02NEc9eQpDT05GSUdfSElHSE1FTT15CkNPTkZJR19YODZfUEFF PXkKQ09ORklHX1NFTEVDVF9NRU1PUllfTU9ERUw9eQpDT05GSUdfRkxBVE1FTV9NQU5VQUw9 eQojIENPTkZJR19ESVNDT05USUdNRU1fTUFOVUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BB UlNFTUVNX01BTlVBTCBpcyBub3Qgc2V0CkNPTkZJR19GTEFUTUVNPXkKQ09ORklHX0ZMQVRf Tk9ERV9NRU1fTUFQPXkKQ09ORklHX0hJR0hQVEU9eQojIENPTkZJR19NQVRIX0VNVUxBVElP TiBpcyBub3Qgc2V0CkNPTkZJR19NVFJSPXkKIyBDT05GSUdfRUZJIGlzIG5vdCBzZXQKQ09O RklHX0lSUUJBTEFOQ0U9eQpDT05GSUdfSEFWRV9ERUNfTE9DSz15CiMgQ09ORklHX1JFR1BB Uk0gaXMgbm90IHNldApDT05GSUdfU0VDQ09NUD15CiMgQ09ORklHX0haXzEwMCBpcyBub3Qg c2V0CiMgQ09ORklHX0haXzI1MCBpcyBub3Qgc2V0CkNPTkZJR19IWl8xMDAwPXkKQ09ORklH X0haPTEwMDAKQ09ORklHX1BIWVNJQ0FMX1NUQVJUPTB4MTAwMDAwCiMgQ09ORklHX0tFWEVD IGlzIG5vdCBzZXQKCiMKIyBQb3dlciBtYW5hZ2VtZW50IG9wdGlvbnMgKEFDUEksIEFQTSkK IwpDT05GSUdfUE09eQojIENPTkZJR19QTV9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX1NP RlRXQVJFX1NVU1BFTkQgaXMgbm90IHNldAoKIwojIEFDUEkgKEFkdmFuY2VkIENvbmZpZ3Vy YXRpb24gYW5kIFBvd2VyIEludGVyZmFjZSkgU3VwcG9ydAojCkNPTkZJR19BQ1BJPXkKQ09O RklHX0FDUElfQk9PVD15CkNPTkZJR19BQ1BJX0lOVEVSUFJFVEVSPXkKQ09ORklHX0FDUElf QUM9eQpDT05GSUdfQUNQSV9CQVRURVJZPXkKQ09ORklHX0FDUElfQlVUVE9OPXkKQ09ORklH X0FDUElfVklERU89eQojIENPTkZJR19BQ1BJX0hPVEtFWSBpcyBub3Qgc2V0CkNPTkZJR19B Q1BJX0ZBTj15CkNPTkZJR19BQ1BJX1BST0NFU1NPUj15CkNPTkZJR19BQ1BJX1RIRVJNQUw9 eQojIENPTkZJR19BQ1BJX0FTVVMgaXMgbm90IHNldAojIENPTkZJR19BQ1BJX0lCTSBpcyBu b3Qgc2V0CiMgQ09ORklHX0FDUElfVE9TSElCQSBpcyBub3Qgc2V0CkNPTkZJR19BQ1BJX0JM QUNLTElTVF9ZRUFSPTAKIyBDT05GSUdfQUNQSV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19B Q1BJX0JVUz15CkNPTkZJR19BQ1BJX0VDPXkKQ09ORklHX0FDUElfUE9XRVI9eQpDT05GSUdf QUNQSV9QQ0k9eQpDT05GSUdfQUNQSV9TWVNURU09eQojIENPTkZJR19YODZfUE1fVElNRVIg aXMgbm90IHNldAojIENPTkZJR19BQ1BJX0NPTlRBSU5FUiBpcyBub3Qgc2V0CgojCiMgQVBN IChBZHZhbmNlZCBQb3dlciBNYW5hZ2VtZW50KSBCSU9TIFN1cHBvcnQKIwojIENPTkZJR19B UE0gaXMgbm90IHNldAoKIwojIENQVSBGcmVxdWVuY3kgc2NhbGluZwojCiMgQ09ORklHX0NQ VV9GUkVRIGlzIG5vdCBzZXQKCiMKIyBCdXMgb3B0aW9ucyAoUENJLCBQQ01DSUEsIEVJU0Es IE1DQSwgSVNBKQojCkNPTkZJR19QQ0k9eQojIENPTkZJR19QQ0lfR09CSU9TIGlzIG5vdCBz ZXQKIyBDT05GSUdfUENJX0dPTU1DT05GSUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfR09E SVJFQ1QgaXMgbm90IHNldApDT05GSUdfUENJX0dPQU5ZPXkKQ09ORklHX1BDSV9CSU9TPXkK Q09ORklHX1BDSV9ESVJFQ1Q9eQpDT05GSUdfUENJX01NQ09ORklHPXkKQ09ORklHX1BDSUVQ T1JUQlVTPXkKQ09ORklHX1BDSV9NU0k9eQojIENPTkZJR19QQ0lfTEVHQUNZX1BST0MgaXMg bm90IHNldApDT05GSUdfUENJX05BTUVTPXkKQ09ORklHX0lTQV9ETUFfQVBJPXkKIyBDT05G SUdfSVNBIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0N4 MjAwIGlzIG5vdCBzZXQKIyBDT05GSUdfSE9UUExVR19DUFUgaXMgbm90IHNldAoKIwojIFBD Q0FSRCAoUENNQ0lBL0NhcmRCdXMpIHN1cHBvcnQKIwojIENPTkZJR19QQ0NBUkQgaXMgbm90 IHNldAoKIwojIFBDSSBIb3RwbHVnIFN1cHBvcnQKIwojIENPTkZJR19IT1RQTFVHX1BDSSBp cyBub3Qgc2V0CgojCiMgRXhlY3V0YWJsZSBmaWxlIGZvcm1hdHMKIwpDT05GSUdfQklORk1U X0VMRj15CkNPTkZJR19CSU5GTVRfQU9VVD1tCkNPTkZJR19CSU5GTVRfTUlTQz1tCgojCiMg TmV0d29ya2luZwojCkNPTkZJR19ORVQ9eQoKIwojIE5ldHdvcmtpbmcgb3B0aW9ucwojCkNP TkZJR19QQUNLRVQ9eQpDT05GSUdfUEFDS0VUX01NQVA9eQpDT05GSUdfVU5JWD15CkNPTkZJ R19YRlJNPXkKQ09ORklHX1hGUk1fVVNFUj15CkNPTkZJR19ORVRfS0VZPXkKQ09ORklHX0lO RVQ9eQpDT05GSUdfSVBfTVVMVElDQVNUPXkKIyBDT05GSUdfSVBfQURWQU5DRURfUk9VVEVS IGlzIG5vdCBzZXQKQ09ORklHX0lQX0ZJQl9IQVNIPXkKIyBDT05GSUdfSVBfUE5QIGlzIG5v dCBzZXQKQ09ORklHX05FVF9JUElQPW0KIyBDT05GSUdfTkVUX0lQR1JFIGlzIG5vdCBzZXQK IyBDT05GSUdfSVBfTVJPVVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJQRCBpcyBub3Qgc2V0 CkNPTkZJR19TWU5fQ09PS0lFUz15CkNPTkZJR19JTkVUX0FIPXkKQ09ORklHX0lORVRfRVNQ PXkKQ09ORklHX0lORVRfSVBDT01QPXkKQ09ORklHX0lORVRfVFVOTkVMPXkKQ09ORklHX0lQ X1RDUERJQUc9eQpDT05GSUdfSVBfVENQRElBR19JUFY2PXkKIyBDT05GSUdfVENQX0NPTkdf QURWQU5DRUQgaXMgbm90IHNldApDT05GSUdfVENQX0NPTkdfQklDPXkKQ09ORklHX0lQVjY9 eQpDT05GSUdfSVBWNl9QUklWQUNZPXkKQ09ORklHX0lORVQ2X0FIPXkKQ09ORklHX0lORVQ2 X0VTUD15CkNPTkZJR19JTkVUNl9JUENPTVA9eQpDT05GSUdfSU5FVDZfVFVOTkVMPXkKQ09O RklHX0lQVjZfVFVOTkVMPW0KIyBDT05GSUdfTkVURklMVEVSIGlzIG5vdCBzZXQKCiMKIyBT Q1RQIENvbmZpZ3VyYXRpb24gKEVYUEVSSU1FTlRBTCkKIwojIENPTkZJR19JUF9TQ1RQIGlz IG5vdCBzZXQKIyBDT05GSUdfQVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfQlJJREdFIGlzIG5v dCBzZXQKIyBDT05GSUdfVkxBTl84MDIxUSBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQ05FVCBp cyBub3Qgc2V0CiMgQ09ORklHX0xMQzIgaXMgbm90IHNldAojIENPTkZJR19JUFggaXMgbm90 IHNldAojIENPTkZJR19BVEFMSyBpcyBub3Qgc2V0CiMgQ09ORklHX1gyNSBpcyBub3Qgc2V0 CiMgQ09ORklHX0xBUEIgaXMgbm90IHNldAojIENPTkZJR19ORVRfRElWRVJUIGlzIG5vdCBz ZXQKIyBDT05GSUdfRUNPTkVUIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FOX1JPVVRFUiBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9DTFNf Uk9VVEUgaXMgbm90IHNldAoKIwojIE5ldHdvcmsgdGVzdGluZwojCiMgQ09ORklHX05FVF9Q S1RHRU4gaXMgbm90IHNldAojIENPTkZJR19IQU1SQURJTyBpcyBub3Qgc2V0CiMgQ09ORklH X0lSREEgaXMgbm90IHNldAojIENPTkZJR19CVCBpcyBub3Qgc2V0CgojCiMgRGV2aWNlIERy aXZlcnMKIwoKIwojIEdlbmVyaWMgRHJpdmVyIE9wdGlvbnMKIwpDT05GSUdfU1RBTkRBTE9O RT15CkNPTkZJR19QUkVWRU5UX0ZJUk1XQVJFX0JVSUxEPXkKQ09ORklHX0ZXX0xPQURFUj15 CgojCiMgTWVtb3J5IFRlY2hub2xvZ3kgRGV2aWNlcyAoTVREKQojCiMgQ09ORklHX01URCBp cyBub3Qgc2V0CgojCiMgUGFyYWxsZWwgcG9ydCBzdXBwb3J0CiMKIyBDT05GSUdfUEFSUE9S VCBpcyBub3Qgc2V0CgojCiMgUGx1ZyBhbmQgUGxheSBzdXBwb3J0CiMKQ09ORklHX1BOUD15 CiMgQ09ORklHX1BOUF9ERUJVRyBpcyBub3Qgc2V0CgojCiMgUHJvdG9jb2xzCiMKQ09ORklH X1BOUEFDUEk9eQoKIwojIEJsb2NrIGRldmljZXMKIwpDT05GSUdfQkxLX0RFVl9GRD15CiMg Q09ORklHX0JMS19DUFFfREEgaXMgbm90IHNldAojIENPTkZJR19CTEtfQ1BRX0NJU1NfREEg aXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0RBQzk2MCBpcyBub3Qgc2V0CiMgQ09ORklH X0JMS19ERVZfVU1FTSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfQ09XX0NPTU1PTiBp cyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0xPT1A9eQojIENPTkZJR19CTEtfREVWX0NSWVBU T0xPT1AgaXMgbm90IHNldApDT05GSUdfQkxLX0RFVl9OQkQ9eQojIENPTkZJR19CTEtfREVW X1NYOCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfVUIgaXMgbm90IHNldAojIENPTkZJ R19CTEtfREVWX1JBTSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX1JBTV9DT1VOVD0xNgpD T05GSUdfSU5JVFJBTUZTX1NPVVJDRT0iIgojIENPTkZJR19MQkQgaXMgbm90IHNldApDT05G SUdfQ0RST01fUEtUQ0RWRD1tCkNPTkZJR19DRFJPTV9QS1RDRFZEX0JVRkZFUlM9OAojIENP TkZJR19DRFJPTV9QS1RDRFZEX1dDQUNIRSBpcyBub3Qgc2V0CgojCiMgSU8gU2NoZWR1bGVy cwojCkNPTkZJR19JT1NDSEVEX05PT1A9eQpDT05GSUdfSU9TQ0hFRF9BUz15CkNPTkZJR19J T1NDSEVEX0RFQURMSU5FPXkKQ09ORklHX0lPU0NIRURfQ0ZRPXkKIyBDT05GSUdfQVRBX09W RVJfRVRIIGlzIG5vdCBzZXQKCiMKIyBBVEEvQVRBUEkvTUZNL1JMTCBzdXBwb3J0CiMKQ09O RklHX0lERT15CkNPTkZJR19CTEtfREVWX0lERT15CgojCiMgUGxlYXNlIHNlZSBEb2N1bWVu dGF0aW9uL2lkZS50eHQgZm9yIGhlbHAvaW5mbyBvbiBJREUgZHJpdmVzCiMKIyBDT05GSUdf QkxLX0RFVl9JREVfU0FUQSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSERfSURFIGlz IG5vdCBzZXQKQ09ORklHX0JMS19ERVZfSURFRElTSz15CiMgQ09ORklHX0lERURJU0tfTVVM VElfTU9ERSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lERUNEPXkKIyBDT05GSUdfQkxL X0RFVl9JREVUQVBFIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9JREVGTE9QUFkgaXMg bm90IHNldApDT05GSUdfQkxLX0RFVl9JREVTQ1NJPW0KQ09ORklHX0lERV9UQVNLX0lPQ1RM PXkKCiMKIyBJREUgY2hpcHNldCBzdXBwb3J0L2J1Z2ZpeGVzCiMKQ09ORklHX0lERV9HRU5F UklDPXkKIyBDT05GSUdfQkxLX0RFVl9DTUQ2NDAgaXMgbm90IHNldAojIENPTkZJR19CTEtf REVWX0lERVBOUCBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVWX0lERVBDST15CkNPTkZJR19J REVQQ0lfU0hBUkVfSVJRPXkKIyBDT05GSUdfQkxLX0RFVl9PRkZCT0FSRCBpcyBub3Qgc2V0 CkNPTkZJR19CTEtfREVWX0dFTkVSSUM9eQojIENPTkZJR19CTEtfREVWX09QVEk2MjEgaXMg bm90IHNldAojIENPTkZJR19CTEtfREVWX1JaMTAwMCBpcyBub3Qgc2V0CkNPTkZJR19CTEtf REVWX0lERURNQV9QQ0k9eQojIENPTkZJR19CTEtfREVWX0lERURNQV9GT1JDRUQgaXMgbm90 IHNldApDT05GSUdfSURFRE1BX1BDSV9BVVRPPXkKIyBDT05GSUdfSURFRE1BX09OTFlESVNL IGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5vdCBzZXQKIyBDT05G SUdfQkxLX0RFVl9BTEkxNVgzIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfQU1ENzRYWD15 CiMgQ09ORklHX0JMS19ERVZfQVRJSVhQIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9D TUQ2NFggaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1RSSUZMRVggaXMgbm90IHNldAoj IENPTkZJR19CTEtfREVWX0NZODJDNjkzIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9D UzU1MjAgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NTNTUzMCBpcyBub3Qgc2V0CiMg Q09ORklHX0JMS19ERVZfSFBUMzRYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9IUFQz NjYgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NDMTIwMCBpcyBub3Qgc2V0CiMgQ09O RklHX0JMS19ERVZfUElJWCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSVQ4MjFYIGlz IG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9OUzg3NDE1IGlzIG5vdCBzZXQKIyBDT05GSUdf QkxLX0RFVl9QREMyMDJYWF9PTEQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1BEQzIw MlhYX05FVyBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfU1ZXS1MgaXMgbm90IHNldAoj IENPTkZJR19CTEtfREVWX1NJSU1BR0UgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NJ UzU1MTMgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1NMQzkwRTY2IGlzIG5vdCBzZXQK IyBDT05GSUdfQkxLX0RFVl9UUk0yOTAgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1ZJ QTgyQ1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0lERV9BUk0gaXMgbm90IHNldApDT05GSUdf QkxLX0RFVl9JREVETUE9eQojIENPTkZJR19JREVETUFfSVZCIGlzIG5vdCBzZXQKQ09ORklH X0lERURNQV9BVVRPPXkKIyBDT05GSUdfQkxLX0RFVl9IRCBpcyBub3Qgc2V0CgojCiMgU0NT SSBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19TQ1NJPXkKIyBDT05GSUdfU0NTSV9QUk9DX0ZT IGlzIG5vdCBzZXQKCiMKIyBTQ1NJIHN1cHBvcnQgdHlwZSAoZGlzaywgdGFwZSwgQ0QtUk9N KQojCkNPTkZJR19CTEtfREVWX1NEPXkKIyBDT05GSUdfQ0hSX0RFVl9TVCBpcyBub3Qgc2V0 CiMgQ09ORklHX0NIUl9ERVZfT1NTVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfU1Ig aXMgbm90IHNldApDT05GSUdfQ0hSX0RFVl9TRz15CiMgQ09ORklHX0NIUl9ERVZfU0NIIGlz IG5vdCBzZXQKCiMKIyBTb21lIFNDU0kgZGV2aWNlcyAoZS5nLiBDRCBqdWtlYm94KSBzdXBw b3J0IG11bHRpcGxlIExVTnMKIwpDT05GSUdfU0NTSV9NVUxUSV9MVU49eQojIENPTkZJR19T Q1NJX0NPTlNUQU5UUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfTE9HR0lORyBpcyBub3Qg c2V0CgojCiMgU0NTSSBUcmFuc3BvcnQgQXR0cmlidXRlcwojCkNPTkZJR19TQ1NJX1NQSV9B VFRSUz15CkNPTkZJR19TQ1NJX0ZDX0FUVFJTPXkKQ09ORklHX1NDU0lfSVNDU0lfQVRUUlM9 eQoKIwojIFNDU0kgbG93LWxldmVsIGRyaXZlcnMKIwojIENPTkZJR19CTEtfREVWXzNXX1hY WFhfUkFJRCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfM1dfOVhYWCBpcyBub3Qgc2V0CiMg Q09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FBQ1JBSUQgaXMg bm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJ X0FJQzdYWFhfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9BSUM3OVhYIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9EUFRfSTJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURf TkVXR0VOIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVHQVJBSURfTEVHQUNZIGlzIG5vdCBzZXQK IyBDT05GSUdfU0NTSV9TQVRBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9CVVNMT0dJQyBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENPTkZJR19T Q1NJX0VBVEEgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90 IHNldAojIENPTkZJR19TQ1NJX0dEVEggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qg c2V0CiMgQ09ORklHX1NDU0lfSVBSIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNf RkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1FMT0dJQ18xMjgwIGlzIG5vdCBzZXQKQ09O RklHX1NDU0lfUUxBMlhYWD15CiMgQ09ORklHX1NDU0lfUUxBMjFYWCBpcyBub3Qgc2V0CiMg Q09ORklHX1NDU0lfUUxBMjJYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjMwMCBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjMyMiBpcyBub3Qgc2V0CiMgQ09ORklHX1ND U0lfUUxBNjMxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfUUxBMjRYWCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NDU0lfTFBGQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTV4IGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9EQzM5MFQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJ X05TUDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ERUJVRyBpcyBub3Qgc2V0CgojCiMg TXVsdGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5kIExWTSkKIwpDT05GSUdfTUQ9eQojIENP TkZJR19CTEtfREVWX01EIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfRE09eQpDT05GSUdf RE1fQ1JZUFQ9eQojIENPTkZJR19ETV9TTkFQU0hPVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RN X01JUlJPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0RNX1pFUk8gaXMgbm90IHNldAojIENPTkZJ R19ETV9NVUxUSVBBVEggaXMgbm90IHNldAoKIwojIEZ1c2lvbiBNUFQgZGV2aWNlIHN1cHBv cnQKIwpDT05GSUdfRlVTSU9OPXkKQ09ORklHX0ZVU0lPTl9TUEk9eQojIENPTkZJR19GVVNJ T05fRkMgaXMgbm90IHNldApDT05GSUdfRlVTSU9OX01BWF9TR0U9MTI4CkNPTkZJR19GVVNJ T05fQ1RMPXkKCiMKIyBJRUVFIDEzOTQgKEZpcmVXaXJlKSBzdXBwb3J0CiMKQ09ORklHX0lF RUUxMzk0PXkKCiMKIyBTdWJzeXN0ZW0gT3B0aW9ucwojCiMgQ09ORklHX0lFRUUxMzk0X1ZF UkJPU0VERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUUxMzk0X09VSV9EQiBpcyBub3Qg c2V0CkNPTkZJR19JRUVFMTM5NF9FWFRSQV9DT05GSUdfUk9NUz15CkNPTkZJR19JRUVFMTM5 NF9DT05GSUdfUk9NX0lQMTM5ND15CiMgQ09ORklHX0lFRUUxMzk0X0VYUE9SVF9GVUxMX0FQ SSBpcyBub3Qgc2V0CgojCiMgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19JRUVFMTM5NF9Q Q0lMWU5YIGlzIG5vdCBzZXQKQ09ORklHX0lFRUUxMzk0X09IQ0kxMzk0PXkKCiMKIyBQcm90 b2NvbCBEcml2ZXJzCiMKQ09ORklHX0lFRUUxMzk0X1ZJREVPMTM5ND1tCkNPTkZJR19JRUVF MTM5NF9TQlAyPXkKIyBDT05GSUdfSUVFRTEzOTRfU0JQMl9QSFlTX0RNQSBpcyBub3Qgc2V0 CkNPTkZJR19JRUVFMTM5NF9FVEgxMzk0PW0KQ09ORklHX0lFRUUxMzk0X0RWMTM5ND1tCkNP TkZJR19JRUVFMTM5NF9SQVdJTz15CkNPTkZJR19JRUVFMTM5NF9DTVA9bQpDT05GSUdfSUVF RTEzOTRfQU1EVFA9bQoKIwojIEkyTyBkZXZpY2Ugc3VwcG9ydAojCiMgQ09ORklHX0kyTyBp cyBub3Qgc2V0CgojCiMgTmV0d29yayBkZXZpY2Ugc3VwcG9ydAojCkNPTkZJR19ORVRERVZJ Q0VTPXkKQ09ORklHX0RVTU1ZPW0KIyBDT05GSUdfQk9ORElORyBpcyBub3Qgc2V0CiMgQ09O RklHX0VRVUFMSVpFUiBpcyBub3Qgc2V0CkNPTkZJR19UVU49eQojIENPTkZJR19ORVRfU0Ix MDAwIGlzIG5vdCBzZXQKCiMKIyBBUkNuZXQgZGV2aWNlcwojCiMgQ09ORklHX0FSQ05FVCBp cyBub3Qgc2V0CgojCiMgRXRoZXJuZXQgKDEwIG9yIDEwME1iaXQpCiMKQ09ORklHX05FVF9F VEhFUk5FVD15CiMgQ09ORklHX01JSSBpcyBub3Qgc2V0CiMgQ09ORklHX0hBUFBZTUVBTCBp cyBub3Qgc2V0CiMgQ09ORklHX1NVTkdFTSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9WRU5E T1JfM0NPTSBpcyBub3Qgc2V0CgojCiMgVHVsaXAgZmFtaWx5IG5ldHdvcmsgZGV2aWNlIHN1 cHBvcnQKIwojIENPTkZJR19ORVRfVFVMSVAgaXMgbm90IHNldAojIENPTkZJR19IUDEwMCBp cyBub3Qgc2V0CkNPTkZJR19ORVRfUENJPXkKIyBDT05GSUdfUENORVQzMiBpcyBub3Qgc2V0 CiMgQ09ORklHX0FNRDgxMTFfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfQURBUFRFQ19TVEFS RklSRSBpcyBub3Qgc2V0CiMgQ09ORklHX0I0NCBpcyBub3Qgc2V0CkNPTkZJR19GT1JDRURF VEg9eQojIENPTkZJR19ER1JTIGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk8xMDAgaXMgbm90 IHNldAojIENPTkZJR19FMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkVBTE5YIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05FMktfUENJIGlzIG5v dCBzZXQKIyBDT05GSUdfODEzOUNQIGlzIG5vdCBzZXQKIyBDT05GSUdfODEzOVRPTyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NJUzkwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0VQSUMxMDAgaXMg bm90IHNldAojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RMQU4gaXMg bm90IHNldAojIENPTkZJR19WSUFfUkhJTkUgaXMgbm90IHNldAoKIwojIEV0aGVybmV0ICgx MDAwIE1iaXQpCiMKIyBDT05GSUdfQUNFTklDIGlzIG5vdCBzZXQKIyBDT05GSUdfREwySyBp cyBub3Qgc2V0CiMgQ09ORklHX0UxMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfTlM4MzgyMCBp cyBub3Qgc2V0CiMgQ09ORklHX0hBTUFDSEkgaXMgbm90IHNldAojIENPTkZJR19ZRUxMT1dG SU4gaXMgbm90IHNldAojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0CiMgQ09ORklHX1NLR0Ug aXMgbm90IHNldAojIENPTkZJR19TSzk4TElOIGlzIG5vdCBzZXQKIyBDT05GSUdfVklBX1ZF TE9DSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVElHT04zIGlzIG5vdCBzZXQKIyBDT05GSUdf Qk5YMiBpcyBub3Qgc2V0CgojCiMgRXRoZXJuZXQgKDEwMDAwIE1iaXQpCiMKIyBDT05GSUdf SVhHQiBpcyBub3Qgc2V0CiMgQ09ORklHX1MySU8gaXMgbm90IHNldAoKIwojIFRva2VuIFJp bmcgZGV2aWNlcwojCiMgQ09ORklHX1RSIGlzIG5vdCBzZXQKCiMKIyBXaXJlbGVzcyBMQU4g KG5vbi1oYW1yYWRpbykKIwojIENPTkZJR19ORVRfUkFESU8gaXMgbm90IHNldAoKIwojIFdh biBpbnRlcmZhY2VzCiMKIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfRkRESSBp cyBub3Qgc2V0CiMgQ09ORklHX0hJUFBJIGlzIG5vdCBzZXQKQ09ORklHX1BQUD1tCiMgQ09O RklHX1BQUF9NVUxUSUxJTksgaXMgbm90IHNldAojIENPTkZJR19QUFBfRklMVEVSIGlzIG5v dCBzZXQKIyBDT05GSUdfUFBQX0FTWU5DIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBQX1NZTkNf VFRZIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBQX0RFRkxBVEUgaXMgbm90IHNldAojIENPTkZJ R19QUFBfQlNEQ09NUCBpcyBub3Qgc2V0CkNPTkZJR19QUFBPRT1tCiMgQ09ORklHX1NMSVAg aXMgbm90IHNldAojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldAojIENPTkZJR19TSEFQRVIg aXMgbm90IHNldAojIENPTkZJR19ORVRDT05TT0xFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU UE9MTCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9QT0xMX0NPTlRST0xMRVIgaXMgbm90IHNl dAoKIwojIElTRE4gc3Vic3lzdGVtCiMKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0CgojCiMg VGVsZXBob255IFN1cHBvcnQKIwojIENPTkZJR19QSE9ORSBpcyBub3Qgc2V0CgojCiMgSW5w dXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQoKIwojIFVzZXJsYW5kIGludGVy ZmFjZXMKIwpDT05GSUdfSU5QVVRfTU9VU0VERVY9eQojIENPTkZJR19JTlBVVF9NT1VTRURF Vl9QU0FVWCBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWD0xMjgw CkNPTkZJR19JTlBVVF9NT1VTRURFVl9TQ1JFRU5fWT0xMDI0CkNPTkZJR19JTlBVVF9KT1lE RVY9bQojIENPTkZJR19JTlBVVF9UU0RFViBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9FVkRF Vj15CiMgQ09ORklHX0lOUFVUX0VWQlVHIGlzIG5vdCBzZXQKCiMKIyBJbnB1dCBEZXZpY2Ug RHJpdmVycwojCkNPTkZJR19JTlBVVF9LRVlCT0FSRD15CkNPTkZJR19LRVlCT0FSRF9BVEtC RD15CiMgQ09ORklHX0tFWUJPQVJEX1NVTktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJP QVJEX0xLS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfWFRLQkQgaXMgbm90IHNl dAojIENPTkZJR19LRVlCT0FSRF9ORVdUT04gaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9V U0U9eQpDT05GSUdfTU9VU0VfUFMyPXkKIyBDT05GSUdfTU9VU0VfU0VSSUFMIGlzIG5vdCBz ZXQKIyBDT05GSUdfTU9VU0VfVlNYWFhBQSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9KT1lT VElDSz15CkNPTkZJR19KT1lTVElDS19BTkFMT0c9bQojIENPTkZJR19KT1lTVElDS19BM0Qg aXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19BREkgaXMgbm90IHNldAojIENPTkZJR19K T1lTVElDS19DT0JSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0pPWVNUSUNLX0dGMksgaXMgbm90 IHNldAojIENPTkZJR19KT1lTVElDS19HUklQIGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJ Q0tfR1JJUF9NUCBpcyBub3Qgc2V0CiMgQ09ORklHX0pPWVNUSUNLX0dVSUxMRU1PVCBpcyBu b3Qgc2V0CiMgQ09ORklHX0pPWVNUSUNLX0lOVEVSQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdf Sk9ZU1RJQ0tfU0lERVdJTkRFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0pPWVNUSUNLX1RNREMg aXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19JRk9SQ0UgaXMgbm90IHNldAojIENPTkZJ R19KT1lTVElDS19XQVJSSU9SIGlzIG5vdCBzZXQKIyBDT05GSUdfSk9ZU1RJQ0tfTUFHRUxM QU4gaXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19TUEFDRU9SQiBpcyBub3Qgc2V0CiMg Q09ORklHX0pPWVNUSUNLX1NQQUNFQkFMTCBpcyBub3Qgc2V0CiMgQ09ORklHX0pPWVNUSUNL X1NUSU5HRVIgaXMgbm90IHNldAojIENPTkZJR19KT1lTVElDS19UV0lESk9ZIGlzIG5vdCBz ZXQKIyBDT05GSUdfSk9ZU1RJQ0tfSk9ZRFVNUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVU X1RPVUNIU0NSRUVOIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01JU0M9eQpDT05GSUdfSU5Q VVRfUENTUEtSPXkKQ09ORklHX0lOUFVUX1VJTlBVVD15CgojCiMgSGFyZHdhcmUgSS9PIHBv cnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX0k4MDQyPXkKQ09ORklHX1NFUklP X1NFUlBPUlQ9eQojIENPTkZJR19TRVJJT19DVDgyQzcxMCBpcyBub3Qgc2V0CiMgQ09ORklH X1NFUklPX1BDSVBTMiBpcyBub3Qgc2V0CkNPTkZJR19TRVJJT19MSUJQUzI9eQpDT05GSUdf U0VSSU9fUkFXPXkKQ09ORklHX0dBTUVQT1JUPW0KIyBDT05GSUdfR0FNRVBPUlRfTlM1NTgg aXMgbm90IHNldAojIENPTkZJR19HQU1FUE9SVF9MNCBpcyBub3Qgc2V0CiMgQ09ORklHX0dB TUVQT1JUX0VNVTEwSzEgaXMgbm90IHNldAojIENPTkZJR19HQU1FUE9SVF9GTTgwMSBpcyBu b3Qgc2V0CgojCiMgQ2hhcmFjdGVyIGRldmljZXMKIwpDT05GSUdfVlQ9eQpDT05GSUdfVlRf Q09OU09MRT15CkNPTkZJR19IV19DT05TT0xFPXkKIyBDT05GSUdfU0VSSUFMX05PTlNUQU5E QVJEIGlzIG5vdCBzZXQKCiMKIyBTZXJpYWwgZHJpdmVycwojCkNPTkZJR19TRVJJQUxfODI1 MD15CiMgQ09ORklHX1NFUklBTF84MjUwX0NPTlNPTEUgaXMgbm90IHNldApDT05GSUdfU0VS SUFMXzgyNTBfQUNQST15CkNPTkZJR19TRVJJQUxfODI1MF9OUl9VQVJUUz00CiMgQ09ORklH X1NFUklBTF84MjUwX0VYVEVOREVEIGlzIG5vdCBzZXQKCiMKIyBOb24tODI1MCBzZXJpYWwg cG9ydCBzdXBwb3J0CiMKQ09ORklHX1NFUklBTF9DT1JFPXkKIyBDT05GSUdfU0VSSUFMX0pT TSBpcyBub3Qgc2V0CkNPTkZJR19VTklYOThfUFRZUz15CiMgQ09ORklHX0xFR0FDWV9QVFlT IGlzIG5vdCBzZXQKCiMKIyBJUE1JCiMKIyBDT05GSUdfSVBNSV9IQU5ETEVSIGlzIG5vdCBz ZXQKCiMKIyBXYXRjaGRvZyBDYXJkcwojCkNPTkZJR19XQVRDSERPRz15CiMgQ09ORklHX1dB VENIRE9HX05PV0FZT1VUIGlzIG5vdCBzZXQKCiMKIyBXYXRjaGRvZyBEZXZpY2UgRHJpdmVy cwojCiMgQ09ORklHX1NPRlRfV0FUQ0hET0cgaXMgbm90IHNldAojIENPTkZJR19BQ1FVSVJF X1dEVCBpcyBub3Qgc2V0CkNPTkZJR19BRFZBTlRFQ0hfV0RUPW0KIyBDT05GSUdfQUxJTTE1 MzVfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQKIyBD T05GSUdfU0M1MjBfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfRVVST1RFQ0hfV0RUIGlzIG5v dCBzZXQKIyBDT05GSUdfSUI3MDBfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfV0FGRVJfV0RU IGlzIG5vdCBzZXQKIyBDT05GSUdfSThYWF9UQ08gaXMgbm90IHNldAojIENPTkZJR19TQzEy MDBfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfNjBYWF9XRFQgaXMgbm90IHNldAojIENPTkZJ R19DUFU1X1dEVCBpcyBub3Qgc2V0CiMgQ09ORklHX1c4MzYyN0hGX1dEVCBpcyBub3Qgc2V0 CiMgQ09ORklHX1c4Mzg3N0ZfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUFDSFpfV0RUIGlz IG5vdCBzZXQKCiMKIyBQQ0ktYmFzZWQgV2F0Y2hkb2cgQ2FyZHMKIwpDT05GSUdfUENJUENX QVRDSERPRz1tCkNPTkZJR19XRFRQQ0k9bQojIENPTkZJR19XRFRfNTAxX1BDSSBpcyBub3Qg c2V0CgojCiMgVVNCLWJhc2VkIFdhdGNoZG9nIENhcmRzCiMKIyBDT05GSUdfVVNCUENXQVRD SERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX0hXX1JBTkRPTSBpcyBub3Qgc2V0CkNPTkZJR19O VlJBTT15CkNPTkZJR19SVEM9eQojIENPTkZJR19EVExLIGlzIG5vdCBzZXQKIyBDT05GSUdf UjM5NjQgaXMgbm90IHNldAojIENPTkZJR19BUFBMSUNPTSBpcyBub3Qgc2V0CiMgQ09ORklH X1NPTllQSSBpcyBub3Qgc2V0CgojCiMgRnRhcGUsIHRoZSBmbG9wcHkgdGFwZSBkZXZpY2Ug ZHJpdmVyCiMKQ09ORklHX0FHUD15CiMgQ09ORklHX0FHUF9BTEkgaXMgbm90IHNldAojIENP TkZJR19BR1BfQVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfQUdQX0FNRCBpcyBub3Qgc2V0CiMg Q09ORklHX0FHUF9BTUQ2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9JTlRFTCBpcyBub3Qg c2V0CiMgQ09ORklHX0FHUF9OVklESUEgaXMgbm90IHNldAojIENPTkZJR19BR1BfU0lTIGlz IG5vdCBzZXQKIyBDT05GSUdfQUdQX1NXT1JLUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FHUF9W SUEgaXMgbm90IHNldAojIENPTkZJR19BR1BfRUZGSUNFT04gaXMgbm90IHNldAojIENPTkZJ R19EUk0gaXMgbm90IHNldAojIENPTkZJR19NV0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX1JB V19EUklWRVIgaXMgbm90IHNldApDT05GSUdfSFBFVD15CiMgQ09ORklHX0hQRVRfUlRDX0lS USBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRVRfTU1BUCBpcyBub3Qgc2V0CkNPTkZJR19IQU5H Q0hFQ0tfVElNRVI9bQoKIwojIFRQTSBkZXZpY2VzCiMKIyBDT05GSUdfVENHX1RQTSBpcyBu b3Qgc2V0CgojCiMgSTJDIHN1cHBvcnQKIwpDT05GSUdfSTJDPXkKQ09ORklHX0kyQ19DSEFS REVWPXkKCiMKIyBJMkMgQWxnb3JpdGhtcwojCkNPTkZJR19JMkNfQUxHT0JJVD15CiMgQ09O RklHX0kyQ19BTEdPUENGIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMR09QQ0EgaXMgbm90 IHNldAoKIwojIEkyQyBIYXJkd2FyZSBCdXMgc3VwcG9ydAojCiMgQ09ORklHX0kyQ19BTEkx NTM1IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0FMSTE1NjMgaXMgbm90IHNldAojIENPTkZJ R19JMkNfQUxJMTVYMyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19BTUQ3NTYgaXMgbm90IHNl dAojIENPTkZJR19JMkNfQU1EODExMSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JODAxIGlz IG5vdCBzZXQKIyBDT05GSUdfSTJDX0k4MTAgaXMgbm90IHNldAojIENPTkZJR19JMkNfUElJ WDQgaXMgbm90IHNldAojIENPTkZJR19JMkNfSVNBIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19O Rk9SQ0UyPXkKIyBDT05GSUdfSTJDX1BBUlBPUlRfTElHSFQgaXMgbm90IHNldAojIENPTkZJ R19JMkNfUFJPU0FWQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1NBVkFHRTQgaXMgbm90 IHNldAojIENPTkZJR19TQ3gyMDBfQUNCIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1NJUzU1 OTUgaXMgbm90IHNldAojIENPTkZJR19JMkNfU0lTNjMwIGlzIG5vdCBzZXQKIyBDT05GSUdf STJDX1NJUzk2WCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TVFVCIGlzIG5vdCBzZXQKIyBD T05GSUdfSTJDX1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19WSUFQUk8gaXMgbm90IHNl dAojIENPTkZJR19JMkNfVk9PRE9PMyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QQ0FfSVNB IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1NFTlNPUiBpcyBub3Qgc2V0CgojCiMgTWlzY2Vs bGFuZW91cyBJMkMgQ2hpcCBzdXBwb3J0CiMKIyBDT05GSUdfU0VOU09SU19EUzEzMzcgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0RTMTM3NCBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfRUVQUk9NIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19QQ0Y4NTc0IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19QQ0E5NTM5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19QQ0Y4NTkxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19SVEM4NTY0IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2ODc1IGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X0RFQlVHX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVCVUdfQUxHTyBpcyBub3Qg c2V0CiMgQ09ORklHX0kyQ19ERUJVR19CVVMgaXMgbm90IHNldAojIENPTkZJR19JMkNfREVC VUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgRGFsbGFzJ3MgMS13aXJlIGJ1cwojCiMgQ09ORklH X1cxIGlzIG5vdCBzZXQKCiMKIyBIYXJkd2FyZSBNb25pdG9yaW5nIHN1cHBvcnQKIwpDT05G SUdfSFdNT049eQojIENPTkZJR19TRU5TT1JTX0FETTEwMjEgaXMgbm90IHNldAojIENPTkZJ R19TRU5TT1JTX0FETTEwMjUgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMjYg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FETTEwMzEgaXMgbm90IHNldAojIENPTkZJ R19TRU5TT1JTX0FETTkyNDAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FTQjEwMCBp cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQVRYUDEgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0RTMTYyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRlNDSEVSIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19GU0NQT1MgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0dMNTE4U00gaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0dMNTIwU00gaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0lUODcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JT X0xNNjMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzUgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX0xNNzcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzggaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODAgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0xNODMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNODUgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX0xNODcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNOTAg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNOTIgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX01BWDE2MTkgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1BDODczNjAgaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX1NJUzU1OTUgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TTVNDNDdCMzk3 IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19WSUE2ODZBIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODNMNzg1 VFMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4MzYyN0hGIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMgbm90IHNldAojIENPTkZJR19IV01PTl9ERUJV R19DSElQIGlzIG5vdCBzZXQKCiMKIyBNaXNjIGRldmljZXMKIwojIENPTkZJR19JQk1fQVNN IGlzIG5vdCBzZXQKCiMKIyBNdWx0aW1lZGlhIGRldmljZXMKIwpDT05GSUdfVklERU9fREVW PXkKCiMKIyBWaWRlbyBGb3IgTGludXgKIwoKIwojIFZpZGVvIEFkYXB0ZXJzCiMKIyBDT05G SUdfVklERU9fQlQ4NDggaXMgbm90IHNldAojIENPTkZJR19WSURFT19DUElBIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fU0FBNTI0NkEgaXMgbm90IHNldAojIENPTkZJR19WSURFT19T QUE1MjQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfVFVORVJfMzAzNiBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1NUUkFESVMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19aT1JBTiBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NBQTcxMzQgaXMgbm90IHNldAojIENPTkZJR19WSURF T19NWEIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19EUEMgaXMgbm90IHNldAojIENPTkZJ R19WSURFT19IRVhJVU1fT1JJT04gaXMgbm90IHNldAojIENPTkZJR19WSURFT19IRVhJVU1f R0VNSU5JIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQ1g4OCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX09WQ0FNQ0hJUCBpcyBub3Qgc2V0CgojCiMgUmFkaW8gQWRhcHRlcnMKIwoj IENPTkZJR19SQURJT19HRU1URUtfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fTUFY SVJBRElPIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fTUFFU1RSTyBpcyBub3Qgc2V0Cgoj CiMgRGlnaXRhbCBWaWRlbyBCcm9hZGNhc3RpbmcgRGV2aWNlcwojCkNPTkZJR19EVkI9eQpD T05GSUdfRFZCX0NPUkU9eQoKIwojIFN1cHBvcnRlZCBTQUE3MTQ2IGJhc2VkIFBDSSBBZGFw dGVycwojCiMgQ09ORklHX0RWQl9BVjcxMTAgaXMgbm90IHNldAojIENPTkZJR19EVkJfQlVE R0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JVREdFVF9DSSBpcyBub3Qgc2V0CkNPTkZJ R19EVkJfQlVER0VUX0FWPXkKCiMKIyBTdXBwb3J0ZWQgVVNCIEFkYXB0ZXJzCiMKIyBDT05G SUdfRFZCX1VTQiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9UVFVTQl9CVURHRVQgaXMgbm90 IHNldAojIENPTkZJR19EVkJfVFRVU0JfREVDIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0NJ TkVSR1lUMiBpcyBub3Qgc2V0CgojCiMgU3VwcG9ydGVkIEZsZXhDb3BJSSAoQjJDMikgQWRh cHRlcnMKIwojIENPTkZJR19EVkJfQjJDMl9GTEVYQ09QIGlzIG5vdCBzZXQKCiMKIyBTdXBw b3J0ZWQgQlQ4NzggQWRhcHRlcnMKIwoKIwojIFN1cHBvcnRlZCBQbHV0bzIgQWRhcHRlcnMK IwojIENPTkZJR19EVkJfUExVVE8yIGlzIG5vdCBzZXQKCiMKIyBTdXBwb3J0ZWQgRFZCIEZy b250ZW5kcwojCgojCiMgQ3VzdG9taXNlIERWQiBGcm9udGVuZHMKIwoKIwojIERWQi1TIChz YXRlbGxpdGUpIGZyb250ZW5kcwojCkNPTkZJR19EVkJfU1RWMDI5OT15CiMgQ09ORklHX0RW Ql9DWDI0MTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1REQTgwODMgaXMgbm90IHNldAoj IENPTkZJR19EVkJfVERBODBYWCBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9NVDMxMiBpcyBu b3Qgc2V0CiMgQ09ORklHX0RWQl9WRVMxWDkzIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX1M1 SDE0MjAgaXMgbm90IHNldAoKIwojIERWQi1UICh0ZXJyZXN0cmlhbCkgZnJvbnRlbmRzCiMK IyBDT05GSUdfRFZCX1NQODg3MCBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9TUDg4N1ggaXMg bm90IHNldAojIENPTkZJR19EVkJfQ1gyMjcwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9D WDIyNzAyIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0w2NDc4MSBpcyBub3Qgc2V0CkNPTkZJ R19EVkJfVERBMTAwNFg9eQojIENPTkZJR19EVkJfTlhUNjAwMCBpcyBub3Qgc2V0CiMgQ09O RklHX0RWQl9NVDM1MiBpcyBub3Qgc2V0CiMgQ09ORklHX0RWQl9ESUIzMDAwTUIgaXMgbm90 IHNldAojIENPTkZJR19EVkJfRElCMzAwME1DIGlzIG5vdCBzZXQKCiMKIyBEVkItQyAoY2Fi bGUpIGZyb250ZW5kcwojCiMgQ09ORklHX0RWQl9BVE1FTF9BVDc2QzY1MSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RWQl9WRVMxODIwIGlzIG5vdCBzZXQKQ09ORklHX0RWQl9UREExMDAyMT15 CiMgQ09ORklHX0RWQl9TVFYwMjk3IGlzIG5vdCBzZXQKCiMKIyBBVFNDIChOb3J0aCBBbWVy aWNhbi9Lb3JlYW4gVGVycmVzdGVyaWFsIERUVikgZnJvbnRlbmRzCiMKIyBDT05GSUdfRFZC X05YVDIwMDIgaXMgbm90IHNldAojIENPTkZJR19EVkJfT1I1MTIxMSBpcyBub3Qgc2V0CiMg Q09ORklHX0RWQl9PUjUxMTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfRFZCX0JDTTM1MTAgaXMg bm90IHNldAojIENPTkZJR19EVkJfTEdEVDMzMFggaXMgbm90IHNldApDT05GSUdfVklERU9f U0FBNzE0Nj15CkNPTkZJR19WSURFT19TQUE3MTQ2X1ZWPXkKQ09ORklHX1ZJREVPX1ZJREVP QlVGPXkKQ09ORklHX1ZJREVPX0JVRj15CgojCiMgR3JhcGhpY3Mgc3VwcG9ydAojCkNPTkZJ R19GQj15CkNPTkZJR19GQl9DRkJfRklMTFJFQ1Q9eQpDT05GSUdfRkJfQ0ZCX0NPUFlBUkVB PXkKQ09ORklHX0ZCX0NGQl9JTUFHRUJMSVQ9eQpDT05GSUdfRkJfU09GVF9DVVJTT1I9eQoj IENPTkZJR19GQl9NQUNNT0RFUyBpcyBub3Qgc2V0CkNPTkZJR19GQl9NT0RFX0hFTFBFUlM9 eQojIENPTkZJR19GQl9USUxFQkxJVFRJTkcgaXMgbm90IHNldAojIENPTkZJR19GQl9DSVJS VVMgaXMgbm90IHNldAojIENPTkZJR19GQl9QTTIgaXMgbm90IHNldAojIENPTkZJR19GQl9D WUJFUjIwMDAgaXMgbm90IHNldAojIENPTkZJR19GQl9BUkMgaXMgbm90IHNldAojIENPTkZJ R19GQl9BU0lMSUFOVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0lNU1RUIGlzIG5vdCBzZXQK IyBDT05GSUdfRkJfVkdBMTYgaXMgbm90IHNldApDT05GSUdfRkJfVkVTQT15CkNPTkZJR19W SURFT19TRUxFQ1Q9eQojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldApDT05GSUdfRkJfTlZJ RElBPXkKIyBDT05GSUdfRkJfTlZJRElBX0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1JJ VkEgaXMgbm90IHNldAojIENPTkZJR19GQl9JODEwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf SU5URUwgaXMgbm90IHNldAojIENPTkZJR19GQl9NQVRST1ggaXMgbm90IHNldAojIENPTkZJ R19GQl9SQURFT05fT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUkFERU9OIGlzIG5vdCBz ZXQKIyBDT05GSUdfRkJfQVRZMTI4IGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVRZIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfU0FWQUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lTIGlz IG5vdCBzZXQKIyBDT05GSUdfRkJfTkVPTUFHSUMgaXMgbm90IHNldAojIENPTkZJR19GQl9L WVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfM0RGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZC X1ZPT0RPTzEgaXMgbm90IHNldAojIENPTkZJR19GQl9UUklERU5UIGlzIG5vdCBzZXQKIyBD T05GSUdfRkJfR0VPREUgaXMgbm90IHNldAojIENPTkZJR19GQl9TMUQxM1hYWCBpcyBub3Qg c2V0CiMgQ09ORklHX0ZCX1ZJUlRVQUwgaXMgbm90IHNldAoKIwojIENvbnNvbGUgZGlzcGxh eSBkcml2ZXIgc3VwcG9ydAojCkNPTkZJR19WR0FfQ09OU09MRT15CkNPTkZJR19EVU1NWV9D T05TT0xFPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEU9eQojIENPTkZJR19GT05UUyBp cyBub3Qgc2V0CkNPTkZJR19GT05UXzh4OD15CkNPTkZJR19GT05UXzh4MTY9eQoKIwojIExv Z28gY29uZmlndXJhdGlvbgojCkNPTkZJR19MT0dPPXkKIyBDT05GSUdfTE9HT19MSU5VWF9N T05PIGlzIG5vdCBzZXQKIyBDT05GSUdfTE9HT19MSU5VWF9WR0ExNiBpcyBub3Qgc2V0CkNP TkZJR19MT0dPX0xJTlVYX0NMVVQyMjQ9eQojIENPTkZJR19CQUNLTElHSFRfTENEX1NVUFBP UlQgaXMgbm90IHNldAoKIwojIFNvdW5kCiMKQ09ORklHX1NPVU5EPXkKCiMKIyBBZHZhbmNl ZCBMaW51eCBTb3VuZCBBcmNoaXRlY3R1cmUKIwpDT05GSUdfU05EPXkKQ09ORklHX1NORF9U SU1FUj15CkNPTkZJR19TTkRfUENNPXkKQ09ORklHX1NORF9IV0RFUD15CkNPTkZJR19TTkRf UkFXTUlEST15CkNPTkZJR19TTkRfU0VRVUVOQ0VSPXkKQ09ORklHX1NORF9TRVFfRFVNTVk9 bQojIENPTkZJR19TTkRfTUlYRVJfT1NTIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1BDTV9P U1MgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0VRVUVOQ0VSX09TUyBpcyBub3Qgc2V0CkNP TkZJR19TTkRfUlRDVElNRVI9eQojIENPTkZJR19TTkRfVkVSQk9TRV9QUklOVEsgaXMgbm90 IHNldAojIENPTkZJR19TTkRfREVCVUcgaXMgbm90IHNldAoKIwojIEdlbmVyaWMgZGV2aWNl cwojCiMgQ09ORklHX1NORF9EVU1NWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WSVJNSURJ IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NFUklBTF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBVNDAxIGlzIG5vdCBz ZXQKCiMKIyBQQ0kgZGV2aWNlcwojCkNPTkZJR19TTkRfQUM5N19DT0RFQz15CiMgQ09ORklH X1NORF9BTEk1NDUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NORF9BVElJWFBfTU9ERU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4 ODEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FVODgyMCBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9BVTg4MzAgaXMgbm90IHNldAojIENPTkZJR19TTkRfQVpUMzMyOCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NORF9CVDg3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzQ2WFggaXMg bm90IHNldAojIENPTkZJR19TTkRfQ1M0MjgxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VN VTEwSzEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMVggaXMgbm90IHNldAojIENP TkZJR19TTkRfQ0EwMTA2IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0tPUkcxMjEyIGlzIG5v dCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9OTTI1 NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUUzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9STUU5NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9STUU5NjUyIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0hEU1AgaXMgbm90IHNldAojIENPTkZJR19TTkRfSERTUE0gaXMgbm90IHNl dAojIENPTkZJR19TTkRfVFJJREVOVCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9ZTUZQQ0kg aXMgbm90IHNldAojIENPTkZJR19TTkRfQUxTNDAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9DTUlQQ0kgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9FTlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VTMTkzOCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19TTkRfTUFF U1RSTzMgaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNldAojIENPTkZJ R19TTkRfSUNFMTcxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBz ZXQKQ09ORklHX1NORF9JTlRFTDhYMD15CiMgQ09ORklHX1NORF9JTlRFTDhYME0gaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9W SUE4MlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1ZJQTgyWFhfTU9ERU0gaXMgbm90IHNl dAojIENPTkZJR19TTkRfVlgyMjIgaXMgbm90IHNldAojIENPTkZJR19TTkRfSERBX0lOVEVM IGlzIG5vdCBzZXQKCiMKIyBVU0IgZGV2aWNlcwojCkNPTkZJR19TTkRfVVNCX0FVRElPPXkK IyBDT05GSUdfU05EX1VTQl9VU1gyWSBpcyBub3Qgc2V0CgojCiMgT3BlbiBTb3VuZCBTeXN0 ZW0KIwojIENPTkZJR19TT1VORF9QUklNRSBpcyBub3Qgc2V0CgojCiMgVVNCIHN1cHBvcnQK IwpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0JfQVJDSF9IQVNfT0hDST15 CkNPTkZJR19VU0I9eQojIENPTkZJR19VU0JfREVCVUcgaXMgbm90IHNldAoKIwojIE1pc2Nl bGxhbmVvdXMgVVNCIG9wdGlvbnMKIwpDT05GSUdfVVNCX0RFVklDRUZTPXkKIyBDT05GSUdf VVNCX0JBTkRXSURUSCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EWU5BTUlDX01JTk9SUyBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVVNQRU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X09URyBpcyBub3Qgc2V0CgojCiMgVVNCIEhvc3QgQ29udHJvbGxlciBEcml2ZXJzCiMKQ09O RklHX1VTQl9FSENJX0hDRD15CiMgQ09ORklHX1VTQl9FSENJX1NQTElUX0lTTyBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9FSENJX1JPT1RfSFVCX1RUIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0lTUDExNlhfSENEIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9PSENJX0hDRD15CiMgQ09O RklHX1VTQl9PSENJX0JJR19FTkRJQU4gaXMgbm90IHNldApDT05GSUdfVVNCX09IQ0lfTElU VExFX0VORElBTj15CiMgQ09ORklHX1VTQl9VSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TTDgxMV9IQ0QgaXMgbm90IHNldAoKIwojIFVTQiBEZXZpY2UgQ2xhc3MgZHJpdmVy cwojCiMgQ09ORklHX1VTQl9BVURJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9CTFVFVE9P VEhfVFRZIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01JREkgaXMgbm90IHNldAojIENPTkZJ R19VU0JfQUNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BSSU5URVIgaXMgbm90IHNldAoK IwojIE5PVEU6IFVTQl9TVE9SQUdFIGVuYWJsZXMgU0NTSSwgYW5kICdTQ1NJIGRpc2sgc3Vw cG9ydCcgbWF5IGFsc28gYmUgbmVlZGVkOyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9y ZSBpbmZvcm1hdGlvbgojCkNPTkZJR19VU0JfU1RPUkFHRT15CiMgQ09ORklHX1VTQl9TVE9S QUdFX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfREFUQUZBQiBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNldAojIENPTkZJ R19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9E UENNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfVVNCQVQgaXMgbm90IHNldAoj IENPTkZJR19VU0JfU1RPUkFHRV9TRERSMDkgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RP UkFHRV9TRERSNTUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9KVU1QU0hPVCBp cyBub3Qgc2V0CgojCiMgVVNCIElucHV0IERldmljZXMKIwpDT05GSUdfVVNCX0hJRD15CkNP TkZJR19VU0JfSElESU5QVVQ9eQojIENPTkZJR19ISURfRkYgaXMgbm90IHNldApDT05GSUdf VVNCX0hJRERFVj15CiMgQ09ORklHX1VTQl9BSVBURUsgaXMgbm90IHNldAojIENPTkZJR19V U0JfV0FDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfQUNFQ0FEIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX0tCVEFCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1BPV0VSTUFURSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9NVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19VU0JfSVRN VE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19VU0JfRUdBTEFYIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1hQQUQgaXMgbm90IHNldAojIENPTkZJR19VU0JfQVRJX1JFTU9URSBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9LRVlTUEFOX1JFTU9URSBpcyBub3Qgc2V0CgojCiMgVVNCIElt YWdpbmcgZGV2aWNlcwojCiMgQ09ORklHX1VTQl9NREM4MDAgaXMgbm90IHNldAojIENPTkZJ R19VU0JfTUlDUk9URUsgaXMgbm90IHNldAoKIwojIFVTQiBNdWx0aW1lZGlhIGRldmljZXMK IwojIENPTkZJR19VU0JfREFCVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1ZJQ0FNIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0RTQlIgaXMgbm90IHNldAojIENPTkZJR19VU0JfSUJN Q0FNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0tPTklDQVdDIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX09WNTExIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFNDAxIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NOOUMxMDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RWNjgwIGlz IG5vdCBzZXQKQ09ORklHX1VTQl9QV0M9eQoKIwojIFVTQiBOZXR3b3JrIEFkYXB0ZXJzCiMK IyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldAojIENPTkZJR19VU0JfS0FXRVRIIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX1BFR0FTVVMgaXMgbm90IHNldAojIENPTkZJR19VU0JfUlRM ODE1MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9VU0JORVQgaXMgbm90IHNldAojIENPTkZJ R19VU0JfTU9OIGlzIG5vdCBzZXQKCiMKIyBVU0IgcG9ydCBkcml2ZXJzCiMKCiMKIyBVU0Ig U2VyaWFsIENvbnZlcnRlciBzdXBwb3J0CiMKIyBDT05GSUdfVVNCX1NFUklBTCBpcyBub3Qg c2V0CgojCiMgVVNCIE1pc2NlbGxhbmVvdXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2 MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9BVUVSU1dBTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfUklPNTAwIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0xFR09UT1dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9MQ0QgaXMg bm90IHNldAojIENPTkZJR19VU0JfTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0NZVEhF Uk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfUEhJREdFVEtJVCBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9QSElER0VUU0VSVk8gaXMgbm90IHNldAojIENPTkZJR19VU0JfSURNT1VTRSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENPTkZJR19V U0JfTEQgaXMgbm90IHNldAojIENPTkZJR19VU0JfVEVTVCBpcyBub3Qgc2V0CgojCiMgVVNC IERTTCBtb2RlbSBzdXBwb3J0CiMKCiMKIyBVU0IgR2FkZ2V0IFN1cHBvcnQKIwojIENPTkZJ R19VU0JfR0FER0VUIGlzIG5vdCBzZXQKCiMKIyBNTUMvU0QgQ2FyZCBzdXBwb3J0CiMKIyBD T05GSUdfTU1DIGlzIG5vdCBzZXQKCiMKIyBJbmZpbmlCYW5kIHN1cHBvcnQKIwojIENPTkZJ R19JTkZJTklCQU5EIGlzIG5vdCBzZXQKCiMKIyBTTiBEZXZpY2VzCiMKCiMKIyBGaWxlIHN5 c3RlbXMKIwpDT05GSUdfRVhUMl9GUz1tCkNPTkZJR19FWFQyX0ZTX1hBVFRSPXkKQ09ORklH X0VYVDJfRlNfUE9TSVhfQUNMPXkKQ09ORklHX0VYVDJfRlNfU0VDVVJJVFk9eQpDT05GSUdf RVhUMl9GU19YSVA9eQpDT05GSUdfRlNfWElQPXkKQ09ORklHX0VYVDNfRlM9bQpDT05GSUdf RVhUM19GU19YQVRUUj15CkNPTkZJR19FWFQzX0ZTX1BPU0lYX0FDTD15CkNPTkZJR19FWFQz X0ZTX1NFQ1VSSVRZPXkKQ09ORklHX0pCRD1tCiMgQ09ORklHX0pCRF9ERUJVRyBpcyBub3Qg c2V0CkNPTkZJR19GU19NQkNBQ0hFPW0KQ09ORklHX1JFSVNFUkZTX0ZTPW0KIyBDT05GSUdf UkVJU0VSRlNfQ0hFQ0sgaXMgbm90IHNldAojIENPTkZJR19SRUlTRVJGU19QUk9DX0lORk8g aXMgbm90IHNldApDT05GSUdfUkVJU0VSRlNfRlNfWEFUVFI9eQpDT05GSUdfUkVJU0VSRlNf RlNfUE9TSVhfQUNMPXkKQ09ORklHX1JFSVNFUkZTX0ZTX1NFQ1VSSVRZPXkKQ09ORklHX0pG U19GUz1tCkNPTkZJR19KRlNfUE9TSVhfQUNMPXkKQ09ORklHX0pGU19TRUNVUklUWT15CiMg Q09ORklHX0pGU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0pGU19TVEFUSVNUSUNTIGlz IG5vdCBzZXQKQ09ORklHX0ZTX1BPU0lYX0FDTD15CgojCiMgWEZTIHN1cHBvcnQKIwpDT05G SUdfWEZTX0ZTPXkKQ09ORklHX1hGU19FWFBPUlQ9eQojIENPTkZJR19YRlNfUlQgaXMgbm90 IHNldApDT05GSUdfWEZTX1FVT1RBPXkKQ09ORklHX1hGU19TRUNVUklUWT15CkNPTkZJR19Y RlNfUE9TSVhfQUNMPXkKQ09ORklHX01JTklYX0ZTPW0KQ09ORklHX1JPTUZTX0ZTPW0KQ09O RklHX0lOT1RJRlk9eQpDT05GSUdfUVVPVEE9eQojIENPTkZJR19RRk1UX1YxIGlzIG5vdCBz ZXQKQ09ORklHX1FGTVRfVjI9eQpDT05GSUdfUVVPVEFDVEw9eQpDT05GSUdfRE5PVElGWT15 CiMgQ09ORklHX0FVVE9GU19GUyBpcyBub3Qgc2V0CkNPTkZJR19BVVRPRlM0X0ZTPW0KCiMK IyBDRC1ST00vRFZEIEZpbGVzeXN0ZW1zCiMKQ09ORklHX0lTTzk2NjBfRlM9eQpDT05GSUdf Sk9MSUVUPXkKQ09ORklHX1pJU09GUz15CkNPTkZJR19aSVNPRlNfRlM9eQpDT05GSUdfVURG X0ZTPXkKQ09ORklHX1VERl9OTFM9eQoKIwojIERPUy9GQVQvTlQgRmlsZXN5c3RlbXMKIwpD T05GSUdfRkFUX0ZTPW0KQ09ORklHX01TRE9TX0ZTPW0KQ09ORklHX1ZGQVRfRlM9bQpDT05G SUdfRkFUX0RFRkFVTFRfQ09ERVBBR0U9NDM3CkNPTkZJR19GQVRfREVGQVVMVF9JT0NIQVJT RVQ9Imlzbzg4NTktMSIKQ09ORklHX05URlNfRlM9bQojIENPTkZJR19OVEZTX0RFQlVHIGlz IG5vdCBzZXQKIyBDT05GSUdfTlRGU19SVyBpcyBub3Qgc2V0CgojCiMgUHNldWRvIGZpbGVz eXN0ZW1zCiMKQ09ORklHX1BST0NfRlM9eQpDT05GSUdfUFJPQ19LQ09SRT15CkNPTkZJR19T WVNGUz15CkNPTkZJR19ERVZQVFNfRlNfWEFUVFI9eQpDT05GSUdfREVWUFRTX0ZTX1NFQ1VS SVRZPXkKQ09ORklHX1RNUEZTPXkKQ09ORklHX1RNUEZTX1hBVFRSPXkKQ09ORklHX1RNUEZT X1NFQ1VSSVRZPXkKIyBDT05GSUdfSFVHRVRMQkZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSFVH RVRMQl9QQUdFIGlzIG5vdCBzZXQKQ09ORklHX1JBTUZTPXkKCiMKIyBNaXNjZWxsYW5lb3Vz IGZpbGVzeXN0ZW1zCiMKIyBDT05GSUdfQURGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0FG RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldApDT05GSUdfSEZT UExVU19GUz1tCiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19CRlNfRlMg aXMgbm90IHNldAojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldApDT05GSUdfQ1JBTUZTPW0K Q09ORklHX1ZYRlNfRlM9bQpDT05GSUdfSFBGU19GUz1tCkNPTkZJR19RTlg0RlNfRlM9bQpD T05GSUdfU1lTVl9GUz1tCkNPTkZJR19VRlNfRlM9bQojIENPTkZJR19VRlNfRlNfV1JJVEUg aXMgbm90IHNldAoKIwojIE5ldHdvcmsgRmlsZSBTeXN0ZW1zCiMKQ09ORklHX05GU19GUz1t CkNPTkZJR19ORlNfVjM9eQpDT05GSUdfTkZTX1YzX0FDTD15CiMgQ09ORklHX05GU19WNCBp cyBub3Qgc2V0CiMgQ09ORklHX05GU19ESVJFQ1RJTyBpcyBub3Qgc2V0CkNPTkZJR19ORlNE PW0KQ09ORklHX05GU0RfVjJfQUNMPXkKQ09ORklHX05GU0RfVjM9eQpDT05GSUdfTkZTRF9W M19BQ0w9eQojIENPTkZJR19ORlNEX1Y0IGlzIG5vdCBzZXQKQ09ORklHX05GU0RfVENQPXkK Q09ORklHX0xPQ0tEPW0KQ09ORklHX0xPQ0tEX1Y0PXkKQ09ORklHX0VYUE9SVEZTPXkKQ09O RklHX05GU19BQ0xfU1VQUE9SVD1tCkNPTkZJR19ORlNfQ09NTU9OPXkKQ09ORklHX1NVTlJQ Qz1tCiMgQ09ORklHX1JQQ1NFQ19HU1NfS1JCNSBpcyBub3Qgc2V0CiMgQ09ORklHX1JQQ1NF Q19HU1NfU1BLTTMgaXMgbm90IHNldApDT05GSUdfU01CX0ZTPW0KIyBDT05GSUdfU01CX05M U19ERUZBVUxUIGlzIG5vdCBzZXQKQ09ORklHX0NJRlM9bQojIENPTkZJR19DSUZTX1NUQVRT IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0lGU19YQVRUUiBpcyBub3Qgc2V0CiMgQ09ORklHX0NJ RlNfRVhQRVJJTUVOVEFMIGlzIG5vdCBzZXQKQ09ORklHX05DUF9GUz1tCkNPTkZJR19OQ1BG U19QQUNLRVRfU0lHTklORz15CkNPTkZJR19OQ1BGU19JT0NUTF9MT0NLSU5HPXkKQ09ORklH X05DUEZTX1NUUk9ORz15CkNPTkZJR19OQ1BGU19ORlNfTlM9eQpDT05GSUdfTkNQRlNfT1My X05TPXkKIyBDT05GSUdfTkNQRlNfU01BTExET1MgaXMgbm90IHNldApDT05GSUdfTkNQRlNf TkxTPXkKQ09ORklHX05DUEZTX0VYVFJBUz15CkNPTkZJR19DT0RBX0ZTPW0KIyBDT05GSUdf Q09EQV9GU19PTERfQVBJIGlzIG5vdCBzZXQKIyBDT05GSUdfQUZTX0ZTIGlzIG5vdCBzZXQK CiMKIyBQYXJ0aXRpb24gVHlwZXMKIwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkKQ09O RklHX0FDT1JOX1BBUlRJVElPTj15CkNPTkZJR19BQ09STl9QQVJUSVRJT05fQ1VNQU5BPXkK Q09ORklHX0FDT1JOX1BBUlRJVElPTl9FRVNPWD15CkNPTkZJR19BQ09STl9QQVJUSVRJT05f SUNTPXkKQ09ORklHX0FDT1JOX1BBUlRJVElPTl9BREZTPXkKQ09ORklHX0FDT1JOX1BBUlRJ VElPTl9QT1dFUlRFQz15CkNPTkZJR19BQ09STl9QQVJUSVRJT05fUklTQ0lYPXkKQ09ORklH X09TRl9QQVJUSVRJT049eQpDT05GSUdfQU1JR0FfUEFSVElUSU9OPXkKQ09ORklHX0FUQVJJ X1BBUlRJVElPTj15CkNPTkZJR19NQUNfUEFSVElUSU9OPXkKQ09ORklHX01TRE9TX1BBUlRJ VElPTj15CkNPTkZJR19CU0RfRElTS0xBQkVMPXkKQ09ORklHX01JTklYX1NVQlBBUlRJVElP Tj15CkNPTkZJR19TT0xBUklTX1g4Nl9QQVJUSVRJT049eQpDT05GSUdfVU5JWFdBUkVfRElT S0xBQkVMPXkKQ09ORklHX0xETV9QQVJUSVRJT049eQojIENPTkZJR19MRE1fREVCVUcgaXMg bm90IHNldApDT05GSUdfU0dJX1BBUlRJVElPTj15CkNPTkZJR19VTFRSSVhfUEFSVElUSU9O PXkKQ09ORklHX1NVTl9QQVJUSVRJT049eQpDT05GSUdfRUZJX1BBUlRJVElPTj15CgojCiMg TmF0aXZlIExhbmd1YWdlIFN1cHBvcnQKIwpDT05GSUdfTkxTPXkKQ09ORklHX05MU19ERUZB VUxUPSJ1dGY4IgpDT05GSUdfTkxTX0NPREVQQUdFXzQzNz1tCkNPTkZJR19OTFNfQ09ERVBB R0VfNzM3PW0KQ09ORklHX05MU19DT0RFUEFHRV83NzU9bQpDT05GSUdfTkxTX0NPREVQQUdF Xzg1MD1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODUyPW0KQ09ORklHX05MU19DT0RFUEFHRV84 NTU9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg1Nz1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODYw PW0KQ09ORklHX05MU19DT0RFUEFHRV84NjE9bQpDT05GSUdfTkxTX0NPREVQQUdFXzg2Mj1t CkNPTkZJR19OTFNfQ09ERVBBR0VfODYzPW0KQ09ORklHX05MU19DT0RFUEFHRV84NjQ9bQpD T05GSUdfTkxTX0NPREVQQUdFXzg2NT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODY2PW0KQ09O RklHX05MU19DT0RFUEFHRV84Njk9bQpDT05GSUdfTkxTX0NPREVQQUdFXzkzNj1tCkNPTkZJ R19OTFNfQ09ERVBBR0VfOTUwPW0KQ09ORklHX05MU19DT0RFUEFHRV85MzI9bQpDT05GSUdf TkxTX0NPREVQQUdFXzk0OT1tCkNPTkZJR19OTFNfQ09ERVBBR0VfODc0PW0KQ09ORklHX05M U19JU084ODU5Xzg9bQpDT05GSUdfTkxTX0NPREVQQUdFXzEyNTA9bQpDT05GSUdfTkxTX0NP REVQQUdFXzEyNTE9bQpDT05GSUdfTkxTX0FTQ0lJPW0KQ09ORklHX05MU19JU084ODU5XzE9 bQpDT05GSUdfTkxTX0lTTzg4NTlfMj1tCkNPTkZJR19OTFNfSVNPODg1OV8zPW0KQ09ORklH X05MU19JU084ODU5XzQ9bQpDT05GSUdfTkxTX0lTTzg4NTlfNT1tCkNPTkZJR19OTFNfSVNP ODg1OV82PW0KQ09ORklHX05MU19JU084ODU5Xzc9bQpDT05GSUdfTkxTX0lTTzg4NTlfOT1t CkNPTkZJR19OTFNfSVNPODg1OV8xMz1tCkNPTkZJR19OTFNfSVNPODg1OV8xND1tCkNPTkZJ R19OTFNfSVNPODg1OV8xNT1tCkNPTkZJR19OTFNfS09JOF9SPW0KQ09ORklHX05MU19LT0k4 X1U9bQpDT05GSUdfTkxTX1VURjg9bQoKIwojIFByb2ZpbGluZyBzdXBwb3J0CiMKIyBDT05G SUdfUFJPRklMSU5HIGlzIG5vdCBzZXQKCiMKIyBLZXJuZWwgaGFja2luZwojCiMgQ09ORklH X1BSSU5US19USU1FIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfS0VSTkVMIGlzIG5vdCBz ZXQKQ09ORklHX0xPR19CVUZfU0hJRlQ9MTUKQ09ORklHX0RFQlVHX0JVR1ZFUkJPU0U9eQpD T05GSUdfRUFSTFlfUFJJTlRLPXkKQ09ORklHX1g4Nl9GSU5EX1NNUF9DT05GSUc9eQpDT05G SUdfWDg2X01QUEFSU0U9eQoKIwojIFNlY3VyaXR5IG9wdGlvbnMKIwpDT05GSUdfS0VZUz15 CiMgQ09ORklHX0tFWVNfREVCVUdfUFJPQ19LRVlTIGlzIG5vdCBzZXQKQ09ORklHX1NFQ1VS SVRZPXkKIyBDT05GSUdfU0VDVVJJVFlfTkVUV09SSyBpcyBub3Qgc2V0CkNPTkZJR19TRUNV UklUWV9DQVBBQklMSVRJRVM9eQojIENPTkZJR19TRUNVUklUWV9ST09UUExVRyBpcyBub3Qg c2V0CiMgQ09ORklHX1NFQ1VSSVRZX1NFQ0xWTCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VS SVRZX1NFTElOVVggaXMgbm90IHNldAoKIwojIENyeXB0b2dyYXBoaWMgb3B0aW9ucwojCkNP TkZJR19DUllQVE89eQpDT05GSUdfQ1JZUFRPX0hNQUM9eQpDT05GSUdfQ1JZUFRPX05VTEw9 bQpDT05GSUdfQ1JZUFRPX01END1tCkNPTkZJR19DUllQVE9fTUQ1PXkKQ09ORklHX0NSWVBU T19TSEExPXkKQ09ORklHX0NSWVBUT19TSEEyNTY9bQpDT05GSUdfQ1JZUFRPX1NIQTUxMj15 CkNPTkZJR19DUllQVE9fV1A1MTI9bQpDT05GSUdfQ1JZUFRPX1RHUjE5Mj1tCkNPTkZJR19D UllQVE9fREVTPXkKQ09ORklHX0NSWVBUT19CTE9XRklTSD1tCkNPTkZJR19DUllQVE9fVFdP RklTSD15CkNPTkZJR19DUllQVE9fU0VSUEVOVD15CkNPTkZJR19DUllQVE9fQUVTXzU4Nj15 CkNPTkZJR19DUllQVE9fQ0FTVDU9bQpDT05GSUdfQ1JZUFRPX0NBU1Q2PW0KQ09ORklHX0NS WVBUT19URUE9bQpDT05GSUdfQ1JZUFRPX0FSQzQ9bQpDT05GSUdfQ1JZUFRPX0tIQVpBRD1t CkNPTkZJR19DUllQVE9fQU5VQklTPW0KQ09ORklHX0NSWVBUT19ERUZMQVRFPXkKQ09ORklH X0NSWVBUT19NSUNIQUVMX01JQz1tCkNPTkZJR19DUllQVE9fQ1JDMzJDPW0KQ09ORklHX0NS WVBUT19URVNUPW0KCiMKIyBIYXJkd2FyZSBjcnlwdG8gZGV2aWNlcwojCiMgQ09ORklHX0NS WVBUT19ERVZfUEFETE9DSyBpcyBub3Qgc2V0CgojCiMgTGlicmFyeSByb3V0aW5lcwojCkNP TkZJR19DUkNfQ0NJVFQ9bQpDT05GSUdfQ1JDMzI9eQpDT05GSUdfTElCQ1JDMzJDPW0KQ09O RklHX1pMSUJfSU5GTEFURT15CkNPTkZJR19aTElCX0RFRkxBVEU9eQpDT05GSUdfR0VORVJJ Q19IQVJESVJRUz15CkNPTkZJR19HRU5FUklDX0lSUV9QUk9CRT15CkNPTkZJR19YODZfU01Q PXkKQ09ORklHX1g4Nl9IVD15CkNPTkZJR19YODZfQklPU19SRUJPT1Q9eQpDT05GSUdfWDg2 X1RSQU1QT0xJTkU9eQpDT05GSUdfUEM9eQo= --------------010603060407060408040005 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg" TGludXggdmVyc2lvbiAyLjYuMTMuNCAocm9vdEBmZXJtYXQpIChnY2MgdmVyc2lvbiA0LjAu MiAoRGViaWFuIDQuMC4yLTIpKSAjMSBTTVAgU3VuIE9jdCAxNiAyMjozOTowNiBDRVNUIDIw MDUKQklPUy1wcm92aWRlZCBwaHlzaWNhbCBSQU0gbWFwOgogQklPUy1lODIwOiAwMDAwMDAw MDAwMDAwMDAwIC0gMDAwMDAwMDAwMDA5ZTAwMCAodXNhYmxlKQogQklPUy1lODIwOiAwMDAw MDAwMDAwMDllMDAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4MjA6 IDAwMDAwMDAwMDAwZDIwMDAgLSAwMDAwMDAwMDAwMTAwMDAwIChyZXNlcnZlZCkKIEJJT1Mt ZTgyMDogMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAwN2ZmOTAwMDAgKHVzYWJsZSkKIEJJ T1MtZTgyMDogMDAwMDAwMDA3ZmY5MDAwMCAtIDAwMDAwMDAwN2ZmOTcwMDAgKEFDUEkgZGF0 YSkKIEJJT1MtZTgyMDogMDAwMDAwMDA3ZmY5NzAwMCAtIDAwMDAwMDAwODAwMDAwMDAgKEFD UEkgTlZTKQogQklPUy1lODIwOiAwMDAwMDAwMDgwMDAwMDAwIC0gMDAwMDAwMDBhZmY4MDAw MCAodXNhYmxlKQogQklPUy1lODIwOiAwMDAwMDAwMGFmZjgwMDAwIC0gMDAwMDAwMDBiMDAw MDAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4MjA6IDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAw MGYwMDAwMDAwIChyZXNlcnZlZCkKIEJJT1MtZTgyMDogMDAwMDAwMDBmZWMwMDAwMCAtIDAw MDAwMDAwZmVjMDA0MDAgKHJlc2VydmVkKQogQklPUy1lODIwOiAwMDAwMDAwMGZlZTAwMDAw IC0gMDAwMDAwMDBmZWUwMTAwMCAocmVzZXJ2ZWQpCiBCSU9TLWU4MjA6IDAwMDAwMDAwZmZm ODAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZlZCkKIEJJT1MtZTgyMDogMDAwMDAw MDEwMDAwMDAwMCAtIDAwMDAwMDAxNTAwMDAwMDAgKHVzYWJsZSkKNDQ4ME1CIEhJR0hNRU0g YXZhaWxhYmxlLgo4OTZNQiBMT1dNRU0gYXZhaWxhYmxlLgpmb3VuZCBTTVAgTVAtdGFibGUg YXQgMDAwZjc5NTAKTlggKEV4ZWN1dGUgRGlzYWJsZSkgcHJvdGVjdGlvbjogYWN0aXZlCk9u IG5vZGUgMCB0b3RhbHBhZ2VzOiAxMzc2MjU2CiAgRE1BIHpvbmU6IDQwOTYgcGFnZXMsIExJ Rk8gYmF0Y2g6MQogIE5vcm1hbCB6b25lOiAyMjUyODAgcGFnZXMsIExJRk8gYmF0Y2g6MzEK ICBIaWdoTWVtIHpvbmU6IDExNDY4ODAgcGFnZXMsIExJRk8gYmF0Y2g6MzEKRE1JIHByZXNl bnQuCkFDUEk6IFJTRFAgKHYwMDAgUFRMVEQgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICApIEAgMHgwMDBmNzkyMApBQ1BJOiBSU0RUICh2MDAxIFBUTFREICAgIFJTRFQgICAw eDA2MDQwMDAwICBMVFAgMHgwMDAwMDAwMCkgQCAweDdmZjkyNmU1CkFDUEk6IEZBRFQgKHYw MDEgTlZJRElBIENLOFMgICAgIDB4MDYwNDAwMDAgUFRMXyAweDAwMGY0MjQwKSBAIDB4N2Zm OTZjY2MKQUNQSTogU1JBVCAodjAwMSBBTUQgICAgSEFNTUVSICAgMHgwNjA0MDAwMCBBTUQg IDB4MDAwMDAwMDEpIEAgMHg3ZmY5NmQ0MApBQ1BJOiBTUENSICh2MDAxIFBUTFREICAkVUNS VEJMJCAweDA2MDQwMDAwIFBUTCAgMHgwMDAwMDAwMSkgQCAweDdmZjk2ZTUwCkFDUEk6IE1B RFQgKHYwMDEgUFRMVEQgIAkgQVBJQyAgIDB4MDYwNDAwMDAgIExUUCAweDAwMDAwMDAwKSBA IDB4N2ZmOTZlYTAKQUNQSTogTUFEVCAodjAwMSBQVExURCAgCSBBUElDICAgMHgwNjA0MDAw MCAgTFRQIDB4MDAwMDAwMDApIEAgMHg3ZmY5NmYzYwpBQ1BJOiBCT09UICh2MDAxIFBUTFRE ICAkU0JGVEJMJCAweDA2MDQwMDAwICBMVFAgMHgwMDAwMDAwMSkgQCAweDdmZjk2ZmQ4CkFD UEk6IERTRFQgKHYwMDEgTlZJRElBICAgICAgQ0s4IDB4MDYwNDAwMDAgTVNGVCAweDAxMDAw MDBlKSBAIDB4MDAwMDAwMDAKQUNQSTogTG9jYWwgQVBJQyBhZGRyZXNzIDB4ZmVlMDAwMDAK QUNQSTogMiBkdXBsaWNhdGUgQVBJQyB0YWJsZSBpZ25vcmVkLgpBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQpQcm9jZXNzb3IgIzAgMTU6MSBB UElDIHZlcnNpb24gMTYKQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgw MV0gZW5hYmxlZCkKUHJvY2Vzc29yICMxIDE1OjEgQVBJQyB2ZXJzaW9uIDE2CkFDUEk6IExB UElDIChhY3BpX2lkWzB4MDJdIGxhcGljX2lkWzB4MDJdIGVuYWJsZWQpClByb2Nlc3NvciAj MiAxNToxIEFQSUMgdmVyc2lvbiAxNgpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAzXSBsYXBp Y19pZFsweDAzXSBlbmFibGVkKQpQcm9jZXNzb3IgIzMgMTU6MSBBUElDIHZlcnNpb24gMTYK QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDBdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkFD UEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAxXSBoaWdoIGVkZ2UgbGludFsweDFdKQpBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwMl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkKQUNQSTog TEFQSUNfTk1JIChhY3BpX2lkWzB4MDNdIGhpZ2ggZWRnZSBsaW50WzB4MV0pCkFDUEk6IElP QVBJQyAoaWRbMHgwNF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkKSU9BUElD WzBdOiBhcGljX2lkIDQsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAt MjMKQUNQSTogSU9BUElDIChpZFsweDA1XSBhZGRyZXNzWzB4ZDAwMDAwMDBdIGdzaV9iYXNl WzI0XSkKSU9BUElDWzFdOiBhcGljX2lkIDUsIHZlcnNpb24gMTcsIGFkZHJlc3MgMHhkMDAw MDAwMCwgR1NJIDI0LTI3CkFDUEk6IElPQVBJQyAoaWRbMHgwNl0gYWRkcmVzc1sweGQwMDAx MDAwXSBnc2lfYmFzZVsyOF0pCklPQVBJQ1syXTogYXBpY19pZCA2LCB2ZXJzaW9uIDE3LCBh ZGRyZXNzIDB4ZDAwMDEwMDAsIEdTSSAyOC0zMQpBQ1BJOiBJTlRfU1JDX09WUiAoYnVzIDAg YnVzX2lycSAwIGdsb2JhbF9pcnEgMiBoaWdoIGVkZ2UpCkFDUEk6IEJJT1MgSVJRMCBwaW4y IG92ZXJyaWRlIGlnbm9yZWQuCkFDUEk6IElOVF9TUkNfT1ZSIChidXMgMCBidXNfaXJxIDkg Z2xvYmFsX2lycSA5IGxvdyBsZXZlbCkKQUNQSTogSVJROSB1c2VkIGJ5IG92ZXJyaWRlLgpF bmFibGluZyBBUElDIG1vZGU6ICBGbGF0LiAgVXNpbmcgMyBJL08gQVBJQ3MKVXNpbmcgQUNQ SSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uCkFsbG9jYXRpbmcg UENJIHJlc291cmNlcyBzdGFydGluZyBhdCBiMDAwMDAwMCAoZ2FwOiBiMDAwMDAwMDozMDAw MDAwMCkKQnVpbHQgMSB6b25lbGlzdHMKS2VybmVsIGNvbW1hbmQgbGluZTogQk9PVF9JTUFH RT1HTlUvTGludXggcm8gcm9vdD0zMDEgcm9vdGZsYWdzPXVzcnF1b3RhIHJvb3Rmc3R5cGU9 eGZzCm1hcHBlZCBBUElDIHRvIGZmZmZkMDAwIChmZWUwMDAwMCkKbWFwcGVkIElPQVBJQyB0 byBmZmZmYzAwMCAoZmVjMDAwMDApCm1hcHBlZCBJT0FQSUMgdG8gZmZmZmIwMDAgKGQwMDAw MDAwKQptYXBwZWQgSU9BUElDIHRvIGZmZmZhMDAwIChkMDAwMTAwMCkKSW5pdGlhbGl6aW5n IENQVSMwClBJRCBoYXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAxMiwgNjU1MzYg Ynl0ZXMpCkRldGVjdGVkIDIyMTAuMDg3IE1IeiBwcm9jZXNzb3IuClVzaW5nIHRzYyBmb3Ig aGlnaC1yZXMgdGltZXNvdXJjZQpDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1 CkRlbnRyeSBjYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDEzMTA3MiAob3JkZXI6IDcsIDUy NDI4OCBieXRlcykKSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3Jk ZXI6IDYsIDI2MjE0NCBieXRlcykKTWVtb3J5OiA0MTQyNjA0ay81NTA1MDI0ayBhdmFpbGFi bGUgKDM4MjlrIGtlcm5lbCBjb2RlLCA0OTYwMGsgcmVzZXJ2ZWQsIDExNjdrIGRhdGEsIDIz MmsgaW5pdCwgMzI3NTg0MGsgaGlnaG1lbSkKQ2hlY2tpbmcgaWYgdGhpcyBwcm9jZXNzb3Ig aG9ub3VycyB0aGUgV1AgYml0IGV2ZW4gaW4gc3VwZXJ2aXNvciBtb2RlLi4uIE9rLgpDYWxp YnJhdGluZyBkZWxheSB1c2luZyB0aW1lciBzcGVjaWZpYyByb3V0aW5lLi4gNDQyMy4yOSBC b2dvTUlQUyAobHBqPTIyMTE2NDgpClNlY3VyaXR5IEZyYW1ld29yayB2MS4wLjAgaW5pdGlh bGl6ZWQKQ2FwYWJpbGl0eSBMU00gaW5pdGlhbGl6ZWQKTW91bnQtY2FjaGUgaGFzaCB0YWJs ZSBlbnRyaWVzOiA1MTIKQ1BVOiBBZnRlciBnZW5lcmljIGlkZW50aWZ5LCBjYXBzOiAxNzhi ZmJmZiBlM2QzZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMSAwMDAwMDAwMCAwMDAw MDAwMwpDUFU6IEFmdGVyIHZlbmRvciBpZGVudGlmeSwgY2FwczogMTc4YmZiZmYgZTNkM2Zi ZmYgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMDMKQ1BVOiBM MSBJIENhY2hlOiA2NEsgKDY0IGJ5dGVzL2xpbmUpLCBEIGNhY2hlIDY0SyAoNjQgYnl0ZXMv bGluZSkKQ1BVOiBMMiBDYWNoZTogMTAyNEsgKDY0IGJ5dGVzL2xpbmUpCkNQVSAwKDIpIC0+ IENvcmUgMApDUFU6IEFmdGVyIGFsbCBpbml0cywgY2FwczogMTc4YmZiZmYgZTNkM2ZiZmYg MDAwMDAwMDAgMDAwMDAwMTAgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMDMKSW50ZWwgbWFj aGluZSBjaGVjayBhcmNoaXRlY3R1cmUgc3VwcG9ydGVkLgpJbnRlbCBtYWNoaW5lIGNoZWNr IHJlcG9ydGluZyBlbmFibGVkIG9uIENQVSMwLgptdHJyOiB2Mi4wICgyMDAyMDUxOSkKRW5h YmxpbmcgZmFzdCBGUFUgc2F2ZSBhbmQgcmVzdG9yZS4uLiBkb25lLgpFbmFibGluZyB1bm1h c2tlZCBTSU1EIEZQVSBleGNlcHRpb24gc3VwcG9ydC4uLiBkb25lLgpDaGVja2luZyAnaGx0 JyBpbnN0cnVjdGlvbi4uLiBPSy4KQ1BVMDogQU1EIER1YWwgQ29yZSBBTUQgT3B0ZXJvbih0 bSkgUHJvY2Vzc29yIDI3NSBzdGVwcGluZyAwMgpCb290aW5nIHByb2Nlc3NvciAxLzEgZWlw IDIwMDAKSW5pdGlhbGl6aW5nIENQVSMxCkNhbGlicmF0aW5nIGRlbGF5IHVzaW5nIHRpbWVy IHNwZWNpZmljIHJvdXRpbmUuLiA0NDE5Ljc1IEJvZ29NSVBTIChscGo9MjIwOTg3NSkKQ1BV OiBBZnRlciBnZW5lcmljIGlkZW50aWZ5LCBjYXBzOiAxNzhiZmJmZiBlM2QzZmJmZiAwMDAw MDAwMCAwMDAwMDAwMCAwMDAwMDAwMSAwMDAwMDAwMCAwMDAwMDAwMwpDUFU6IEFmdGVyIHZl bmRvciBpZGVudGlmeSwgY2FwczogMTc4YmZiZmYgZTNkM2ZiZmYgMDAwMDAwMDAgMDAwMDAw MDAgMDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMDMKQ1BVOiBMMSBJIENhY2hlOiA2NEsgKDY0 IGJ5dGVzL2xpbmUpLCBEIGNhY2hlIDY0SyAoNjQgYnl0ZXMvbGluZSkKQ1BVOiBMMiBDYWNo ZTogMTAyNEsgKDY0IGJ5dGVzL2xpbmUpCkNQVSAxKDIpIC0+IENvcmUgMQpDUFU6IEFmdGVy IGFsbCBpbml0cywgY2FwczogMTc4YmZiZmYgZTNkM2ZiZmYgMDAwMDAwMDAgMDAwMDAwMTAg MDAwMDAwMDEgMDAwMDAwMDAgMDAwMDAwMDMKSW50ZWwgbWFjaGluZSBjaGVjayBhcmNoaXRl Y3R1cmUgc3VwcG9ydGVkLgpJbnRlbCBtYWNoaW5lIGNoZWNrIHJlcG9ydGluZyBlbmFibGVk IG9uIENQVSMxLgpDUFUxOiBBTUQgRHVhbCBDb3JlIEFNRCBPcHRlcm9uKHRtKSBQcm9jZXNz b3IgMjc1IHN0ZXBwaW5nIDAyCkJvb3RpbmcgcHJvY2Vzc29yIDIvMiBlaXAgMjAwMApJbml0 aWFsaXppbmcgQ1BVIzIKQ2FsaWJyYXRpbmcgZGVsYXkgdXNpbmcgdGltZXIgc3BlY2lmaWMg cm91dGluZS4uIDQ0MTkuNzQgQm9nb01JUFMgKGxwaj0yMjA5ODcyKQpDUFU6IEFmdGVyIGdl bmVyaWMgaWRlbnRpZnksIGNhcHM6IDE3OGJmYmZmIGUzZDNmYmZmIDAwMDAwMDAwIDAwMDAw MDAwIDAwMDAwMDAxIDAwMDAwMDAwIDAwMDAwMDAzCkNQVTogQWZ0ZXIgdmVuZG9yIGlkZW50 aWZ5LCBjYXBzOiAxNzhiZmJmZiBlM2QzZmJmZiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MSAwMDAwMDAwMCAwMDAwMDAwMwpDUFU6IEwxIEkgQ2FjaGU6IDY0SyAoNjQgYnl0ZXMvbGlu ZSksIEQgY2FjaGUgNjRLICg2NCBieXRlcy9saW5lKQpDUFU6IEwyIENhY2hlOiAxMDI0SyAo NjQgYnl0ZXMvbGluZSkKQ1BVIDIoMikgLT4gQ29yZSAxCkNQVTogQWZ0ZXIgYWxsIGluaXRz LCBjYXBzOiAxNzhiZmJmZiBlM2QzZmJmZiAwMDAwMDAwMCAwMDAwMDAxMCAwMDAwMDAwMSAw MDAwMDAwMCAwMDAwMDAwMwpJbnRlbCBtYWNoaW5lIGNoZWNrIGFyY2hpdGVjdHVyZSBzdXBw b3J0ZWQuCkludGVsIG1hY2hpbmUgY2hlY2sgcmVwb3J0aW5nIGVuYWJsZWQgb24gQ1BVIzIu CkNQVTI6IEFNRCBEdWFsIENvcmUgQU1EIE9wdGVyb24odG0pIFByb2Nlc3NvciAyNzUgc3Rl cHBpbmcgMDIKQm9vdGluZyBwcm9jZXNzb3IgMy8zIGVpcCAyMDAwCkluaXRpYWxpemluZyBD UFUjMwpDYWxpYnJhdGluZyBkZWxheSB1c2luZyB0aW1lciBzcGVjaWZpYyByb3V0aW5lLi4g NDQxOS43NSBCb2dvTUlQUyAobHBqPTIyMDk4NzUpCkNQVTogQWZ0ZXIgZ2VuZXJpYyBpZGVu dGlmeSwgY2FwczogMTc4YmZiZmYgZTNkM2ZiZmYgMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAw MDEgMDAwMDAwMDAgMDAwMDAwMDMKQ1BVOiBBZnRlciB2ZW5kb3IgaWRlbnRpZnksIGNhcHM6 IDE3OGJmYmZmIGUzZDNmYmZmIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAxIDAwMDAwMDAw IDAwMDAwMDAzCkNQVTogTDEgSSBDYWNoZTogNjRLICg2NCBieXRlcy9saW5lKSwgRCBjYWNo ZSA2NEsgKDY0IGJ5dGVzL2xpbmUpCkNQVTogTDIgQ2FjaGU6IDEwMjRLICg2NCBieXRlcy9s aW5lKQpDUFUgMygyKSAtPiBDb3JlIDEKQ1BVOiBBZnRlciBhbGwgaW5pdHMsIGNhcHM6IDE3 OGJmYmZmIGUzZDNmYmZmIDAwMDAwMDAwIDAwMDAwMDEwIDAwMDAwMDAxIDAwMDAwMDAwIDAw MDAwMDAzCkludGVsIG1hY2hpbmUgY2hlY2sgYXJjaGl0ZWN0dXJlIHN1cHBvcnRlZC4KSW50 ZWwgbWFjaGluZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZCBvbiBDUFUjMy4KQ1BVMzogQU1E IER1YWwgQ29yZSBBTUQgT3B0ZXJvbih0bSkgUHJvY2Vzc29yIDI3NSBzdGVwcGluZyAwMgpU b3RhbCBvZiA0IHByb2Nlc3NvcnMgYWN0aXZhdGVkICgxNzY4Mi41NCBCb2dvTUlQUykuCkVO QUJMSU5HIElPLUFQSUMgSVJRcwouLlRJTUVSOiB2ZWN0b3I9MHgzMSBwaW4xPTAgcGluMj0t MQpjaGVja2luZyBUU0Mgc3luY2hyb25pemF0aW9uIGFjcm9zcyA0IENQVXM6IHBhc3NlZC4K QnJvdWdodCB1cCA0IENQVXMKTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgpB Q1BJOiBidXMgdHlwZSBwY2kgcmVnaXN0ZXJlZApQQ0k6IFBDSSBCSU9TIHJldmlzaW9uIDIu MTAgZW50cnkgYXQgMHhmZDZiMCwgbGFzdCBidXM9MTI5ClBDSTogVXNpbmcgY29uZmlndXJh dGlvbiB0eXBlIDEKQUNQSTogU3Vic3lzdGVtIHJldmlzaW9uIDIwMDUwNDA4CkFDUEk6IElu dGVycHJldGVyIGVuYWJsZWQKQUNQSTogVXNpbmcgSU9BUElDIGZvciBpbnRlcnJ1cHQgcm91 dGluZwpBQ1BJOiBQQ0kgUm9vdCBCcmlkZ2UgW1BDSTBdICgwMDAwOjAwKQpQQ0k6IFByb2Jp bmcgUENJIGhhcmR3YXJlIChidXMgMDApCkFDUEk6IEFzc3VtZSByb290IGJyaWRnZSBbXF9T Ql8uUENJMF0gc2VnbWVudCBpcyAwCkFDUEk6IEFzc3VtZSByb290IGJyaWRnZSBbXF9TQl8u UENJMF0gYnVzIGlzIDAKQUNQSTogQXNzdW1lIHJvb3QgYnJpZGdlIFtcX1NCXy5QQ0kyXSBz ZWdtZW50IGlzIDAKQUNQSTogQXNzdW1lIHJvb3QgYnJpZGdlIFtcX1NCXy5QQ0kxXSBzZWdt ZW50IGlzIDAKUENJOiBUcmFuc3BhcmVudCBicmlkZ2UgLSAwMDAwOjAwOjA5LjAKQm9vdCB2 aWRlbyBkZXZpY2UgaXMgMDAwMDowMjowMC4wCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGlu ZyBUYWJsZSBbXF9TQl8uUENJMC5fUFJUXQpBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcg VGFibGUgW1xfU0JfLlBDSTAuUDJQMC5fUFJUXQpBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRp bmcgVGFibGUgW1xfU0JfLlBDSTAuWFZSMC5fUFJUXQpBQ1BJOiBQQ0kgSW50ZXJydXB0IExp bmsgW0xOSzFdIChJUlFzIDE2IDE3IDE4IDE5KSAqMCwgZGlzYWJsZWQuCkFDUEk6IFBDSSBJ bnRlcnJ1cHQgTGluayBbTE5LMl0gKElSUXMgMTYgMTcgMTggMTkpICowLCBkaXNhYmxlZC4K QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTkszXSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAK QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTks0XSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAK QUNQSTogUENJIEludGVycnVwdCBMaW5rIFtMTks1XSAoSVJRcyAxNiAxNyAxOCAxOSkgKjAs IGRpc2FibGVkLgpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xTTUJdIChJUlFzIDIwIDIx IDIyIDIzKSAqMCwgZGlzYWJsZWQuCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFVTMF0g KElSUXMgMjAgMjEgMjIgMjMpICowCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTFVTMl0g KElSUXMgMjAgMjEgMjIgMjMpICowCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE1BQ10g KElSUXMgMjAgMjEgMjIgMjMpICowCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTEFDSV0g KElSUXMgMjAgMjEgMjIgMjMpICowCkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE1DSV0g KElSUXMgMjAgMjEgMjIgMjMpICowLCBkaXNhYmxlZC4KQUNQSTogUENJIEludGVycnVwdCBM aW5rIFtMUElEXSAoSVJRcyAyMCAyMSAyMiAyMykgKjAsIGRpc2FibGVkLgpBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xUSURdIChJUlFzIDIwIDIxIDIyIDIzKSAqMApBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xTSTFdIChJUlFzIDIwIDIxIDIyIDIzKSAqMCwgZGlzYWJsZWQu CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbQVBDUF0gKElSUXMgMjAgMjEgMjIgMjMpICow LCBkaXNhYmxlZC4KQUNQSTogUENJIFJvb3QgQnJpZGdlIFtQQ0kyXSAoMDAwMDowOCkKUENJ OiBQcm9iaW5nIFBDSSBoYXJkd2FyZSAoYnVzIDA4KQpBQ1BJOiBBc3N1bWUgcm9vdCBicmlk Z2UgW1xfU0JfLlBDSTBdIHNlZ21lbnQgaXMgMApBQ1BJOiBBc3N1bWUgcm9vdCBicmlkZ2Ug W1xfU0JfLlBDSTBdIGJ1cyBpcyAwCkFDUEk6IEFzc3VtZSByb290IGJyaWRnZSBbXF9TQl8u UENJMl0gc2VnbWVudCBpcyAwCkFDUEk6IEFzc3VtZSByb290IGJyaWRnZSBbXF9TQl8uUENJ MV0gc2VnbWVudCBpcyAwCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBbXF9T Ql8uUENJMi5HMFBBLl9QUlRdCkFDUEk6IFBDSSBJbnRlcnJ1cHQgUm91dGluZyBUYWJsZSBb XF9TQl8uUENJMi5HMFBCLl9QUlRdCkFDUEk6IFBDSSBSb290IEJyaWRnZSBbUENJMV0gKDAw MDA6ODApClBDSTogUHJvYmluZyBQQ0kgaGFyZHdhcmUgKGJ1cyA4MCkKQUNQSTogQXNzdW1l IHJvb3QgYnJpZGdlIFtcX1NCXy5QQ0kwXSBzZWdtZW50IGlzIDAKQUNQSTogQXNzdW1lIHJv b3QgYnJpZGdlIFtcX1NCXy5QQ0kwXSBidXMgaXMgMApBQ1BJOiBBc3N1bWUgcm9vdCBicmlk Z2UgW1xfU0JfLlBDSTJdIHNlZ21lbnQgaXMgMApBQ1BJOiBBc3N1bWUgcm9vdCBicmlkZ2Ug W1xfU0JfLlBDSTFdIHNlZ21lbnQgaXMgMApBQ1BJOiBQQ0kgSW50ZXJydXB0IFJvdXRpbmcg VGFibGUgW1xfU0JfLlBDSTEuX1BSVF0KQUNQSTogUENJIEludGVycnVwdCBSb3V0aW5nIFRh YmxlIFtcX1NCXy5QQ0kxLlhWUjAuX1BSVF0KTGludXggUGx1ZyBhbmQgUGxheSBTdXBwb3J0 IHYwLjk3IChjKSBBZGFtIEJlbGF5CnBucDogUG5QIEFDUEkgaW5pdApwbnA6IFBuUCBBQ1BJ OiBmb3VuZCAxMyBkZXZpY2VzClNDU0kgc3Vic3lzdGVtIGluaXRpYWxpemVkCnVzYmNvcmU6 IHJlZ2lzdGVyZWQgbmV3IGRyaXZlciB1c2Jmcwp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBk cml2ZXIgaHViClBDSTogVXNpbmcgQUNQSSBmb3IgSVJRIHJvdXRpbmcKUENJOiBJZiBhIGRl dmljZSBkb2Vzbid0IHdvcmssIHRyeSAicGNpPXJvdXRlaXJxIi4gIElmIGl0IGhlbHBzLCBw b3N0IGEgcmVwb3J0CnBucDogMDA6MDE6IGlvcG9ydCByYW5nZSAweDgwMDAtMHg4MDdmIGNv dWxkIG5vdCBiZSByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQgcmFuZ2UgMHg4MDgwLTB4 ODBmZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQgcmFuZ2UgMHg4NDAw LTB4ODQ3ZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQgcmFuZ2UgMHg4 NDgwLTB4ODRmZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQgcmFuZ2Ug MHg4ODAwLTB4ODg3ZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQgcmFu Z2UgMHg4ODgwLTB4ODhmZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3BvcnQg cmFuZ2UgMHhhMDAwLTB4YTAzZiBoYXMgYmVlbiByZXNlcnZlZApwbnA6IDAwOjAxOiBpb3Bv cnQgcmFuZ2UgMHhhMDQwLTB4YTA3ZiBoYXMgYmVlbiByZXNlcnZlZApQQ0k6IEJyaWRnZTog MDAwMDowMDowOS4wCiAgSU8gd2luZG93OiBkaXNhYmxlZC4KICBNRU0gd2luZG93OiBiMDEw MDAwMC1iMDFmZmZmZgogIFBSRUZFVENIIHdpbmRvdzogZGlzYWJsZWQuClBDSTogRmFpbGVk IHRvIGFsbG9jYXRlIG1lbSByZXNvdXJjZSAjNjoyMDAwMEBkMDAwMDAwMCBmb3IgMDAwMDow MjowMC4wClBDSTogQnJpZGdlOiAwMDAwOjAwOjBlLjAKICBJTyB3aW5kb3c6IDIwMDAtMmZm ZgogIE1FTSB3aW5kb3c6IGIxMDAwMDAwLWIyZmZmZmZmCiAgUFJFRkVUQ0ggd2luZG93OiBj MDAwMDAwMC1jZmZmZmZmZgpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2Ug MDAwMDowMDowOS4wIHRvIDY0ClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmlj ZSAwMDAwOjAwOjBlLjAgdG8gNjQKUENJOiBCcmlkZ2U6IDAwMDA6MDg6MGEuMAogIElPIHdp bmRvdzogZGlzYWJsZWQuCiAgTUVNIHdpbmRvdzogZGlzYWJsZWQuCiAgUFJFRkVUQ0ggd2lu ZG93OiBkaXNhYmxlZC4KUENJOiBCcmlkZ2U6IDAwMDA6MDg6MGIuMAogIElPIHdpbmRvdzog MzAwMC0zZmZmCiAgTUVNIHdpbmRvdzogZDAxMDAwMDAtZDA0ZmZmZmYKICBQUkVGRVRDSCB3 aW5kb3c6IGIwMjAwMDAwLWIwM2ZmZmZmClBDSTogQnJpZGdlOiAwMDAwOjgwOjBlLjAKICBJ TyB3aW5kb3c6IGRpc2FibGVkLgogIE1FTSB3aW5kb3c6IGRpc2FibGVkLgogIFBSRUZFVENI IHdpbmRvdzogZGlzYWJsZWQuClBDSTogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmlj ZSAwMDAwOjgwOjBlLjAgdG8gNjQKU2ltcGxlIEJvb3QgRmxhZyBhdCAweDM2IHNldCB0byAw eDEKTWFjaGluZSBjaGVjayBleGNlcHRpb24gcG9sbGluZyB0aW1lciBzdGFydGVkLgphdWRp dDogaW5pdGlhbGl6aW5nIG5ldGxpbmsgc29ja2V0IChkaXNhYmxlZCkKYXVkaXQoMTEyOTQ5 NTk3Ni4zNzM6MSk6IGluaXRpYWxpemVkCmhpZ2htZW0gYm91bmNlIHBvb2wgc2l6ZTogNjQg cGFnZXMKVkZTOiBEaXNrIHF1b3RhcyBkcXVvdF82LjUuMQpEcXVvdC1jYWNoZSBoYXNoIHRh YmxlIGVudHJpZXM6IDEwMjQgKG9yZGVyIDAsIDQwOTYgYnl0ZXMpClNHSSBYRlMgd2l0aCBB Q0xzLCBzZWN1cml0eSBhdHRyaWJ1dGVzLCBubyBkZWJ1ZyBlbmFibGVkClNHSSBYRlMgUXVv dGEgTWFuYWdlbWVudCBzdWJzeXN0ZW0KSW5pdGlhbGl6aW5nIENyeXB0b2dyYXBoaWMgQVBJ ClBDSTogTVNJIHF1aXJrIGRldGVjdGVkLiBwY2lfbXNpX3F1aXJrIHNldC4KUENJOiBNU0kg cXVpcmsgZGV0ZWN0ZWQuIHBjaV9tc2lfcXVpcmsgc2V0LgpQQ0k6IFNldHRpbmcgbGF0ZW5j eSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDowZS4wIHRvIDY0CnBjaWVfcG9ydGRydl9wcm9i ZS0+RGV2WzAwNWQ6MTBkZV0gaGFzIGludmFsaWQgSVJRLiBDaGVjayB2ZW5kb3IgQklPUwph c3NpZ25faW50ZXJydXB0X21vZGUgRm91bmQgTVNJIGNhcGFiaWxpdHkKUENJOiBNU0kgcXVp cmsgZGV0ZWN0ZWQuIE1TSSBkaXNhYmxlZC4KQWxsb2NhdGUgUG9ydCBTZXJ2aWNlW3BjaWUw MF0KUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6ODA6MGUuMCB0 byA2NApwY2llX3BvcnRkcnZfcHJvYmUtPkRldlswMDVkOjEwZGVdIGhhcyBpbnZhbGlkIElS US4gQ2hlY2sgdmVuZG9yIEJJT1MKYXNzaWduX2ludGVycnVwdF9tb2RlIEZvdW5kIE1TSSBj YXBhYmlsaXR5CkFsbG9jYXRlIFBvcnQgU2VydmljZVtwY2llMDBdCnZlc2FmYjogZnJhbWVi dWZmZXIgYXQgMHhjMDAwMDAwMCwgbWFwcGVkIHRvIDB4Zjg4ODAwMDAsIHVzaW5nIDYwMGss IHRvdGFsIDI2MjE0NGsKdmVzYWZiOiBtb2RlIGlzIDY0MHg0ODB4OCwgbGluZWxlbmd0aD02 NDAsIHBhZ2VzPTEwCnZlc2FmYjogcHJvdGVjdGVkIG1vZGUgaW50ZXJmYWNlIGluZm8gYXQg YzAwMDpkNGMwCnZlc2FmYjogc2Nyb2xsaW5nOiByZWRyYXcKdmVzYWZiOiBQc2V1ZG9jb2xv cjogc2l6ZT04Ojg6ODo4LCBzaGlmdD0wOjA6MDowCkNvbnNvbGU6IHN3aXRjaGluZyB0byBj b2xvdXIgZnJhbWUgYnVmZmVyIGRldmljZSA4MHgzMApmYjA6IFZFU0EgVkdBIGZyYW1lIGJ1 ZmZlciBkZXZpY2UKQUNQSTogUG93ZXIgQnV0dG9uIChGRikgW1BXUkZdCkFDUEk6IFBvd2Vy IEJ1dHRvbiAoQ00pIFtQV1JCXQpBQ1BJOiBDUFUwIChwb3dlciBzdGF0ZXM6IEMxW0MxXSkK QUNQSTogQ1BVMSAocG93ZXIgc3RhdGVzOiBDMVtDMV0pCkFDUEk6IENQVTIgKHBvd2VyIHN0 YXRlczogQzFbQzFdKQpBQ1BJOiBDUFUzIChwb3dlciBzdGF0ZXM6IEMxW0MxXSkKUmVhbCBU aW1lIENsb2NrIERyaXZlciB2MS4xMgpOb24tdm9sYXRpbGUgbWVtb3J5IGRyaXZlciB2MS4y CkxpbnV4IGFncGdhcnQgaW50ZXJmYWNlIHYwLjEwMSAoYykgRGF2ZSBKb25lcwpQTlA6IFBT LzIgQ29udHJvbGxlciBbUE5QMDMwMzpQUzJLLFBOUDBmMTM6UFMyTV0gYXQgMHg2MCwweDY0 IGlycSAxLDEyCnNlcmlvOiBpODA0MiBBVVggcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEyCnNl cmlvOiBpODA0MiBLQkQgcG9ydCBhdCAweDYwLDB4NjQgaXJxIDEKU2VyaWFsOiA4MjUwLzE2 NTUwIGRyaXZlciAkUmV2aXNpb246IDEuOTAgJCA0IHBvcnRzLCBJUlEgc2hhcmluZyBkaXNh YmxlZAp0dHlTMCBhdCBJL08gMHgzZjggKGlycSA9IDQpIGlzIGEgMTY1NTBBCnR0eVMwIGF0 IEkvTyAweDNmOCAoaXJxID0gMCkgaXMgYSAxNjU1MEEKdHR5UzAgYXQgSS9PIDB4M2Y4IChp cnEgPSA0KSBpcyBhIDE2NTUwQQppbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCmlvIHNj aGVkdWxlciBhbnRpY2lwYXRvcnkgcmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgZGVhZGxpbmUg cmVnaXN0ZXJlZAppbyBzY2hlZHVsZXIgY2ZxIHJlZ2lzdGVyZWQKRmxvcHB5IGRyaXZlKHMp OiBmZDAgaXMgMS40NE0KRkRDIDAgaXMgYSBwb3N0LTE5OTEgODIwNzcKbG9vcDogbG9hZGVk IChtYXggOCBkZXZpY2VzKQpuYmQ6IHJlZ2lzdGVyZWQgZGV2aWNlIGF0IG1ham9yIDQzCmZv cmNlZGV0aC5jOiBSZXZlcnNlIEVuZ2luZWVyZWQgbkZvcmNlIGV0aGVybmV0IGRyaXZlci4g VmVyc2lvbiAwLjM1LgpBQ1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xNQUNdIGVuYWJsZWQg YXQgSVJRIDIzCkFDUEk6IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDowYS4wW0FdIC0+IExpbmsg W0xNQUNdIC0+IEdTSSAyMyAobGV2ZWwsIGhpZ2gpIC0+IElSUSAxNzcKUENJOiBTZXR0aW5n IGxhdGVuY3kgdGltZXIgb2YgZGV2aWNlIDAwMDA6MDA6MGEuMCB0byA2NApldGgwOiBmb3Jj ZWRldGguYzogc3Vic3lzdGVtOiAwMTBmMToyODk1IGJvdW5kIHRvIDAwMDA6MDA6MGEuMApB Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xOSzNdIGVuYWJsZWQgYXQgSVJRIDE5CkFDUEk6 IFBDSSBJbnRlcnJ1cHQgMDAwMDo4MDowYS4wW0FdIC0+IExpbmsgW0xOSzNdIC0+IEdTSSAx OSAobGV2ZWwsIGhpZ2gpIC0+IElSUSAxODUKUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIg b2YgZGV2aWNlIDAwMDA6ODA6MGEuMCB0byA2NApldGgxOiBmb3JjZWRldGguYzogc3Vic3lz dGVtOiAwMTBmMToyODk1IGJvdW5kIHRvIDAwMDA6ODA6MGEuMAp0dW46IFVuaXZlcnNhbCBU VU4vVEFQIGRldmljZSBkcml2ZXIsIDEuNgp0dW46IChDKSAxOTk5LTIwMDQgTWF4IEtyYXNu eWFuc2t5IDxtYXhrQHF1YWxjb21tLmNvbT4KTGludXggdmlkZW8gY2FwdHVyZSBpbnRlcmZh Y2U6IHYxLjAwCnNhYTcxNDY6IHJlZ2lzdGVyIGV4dGVuc2lvbiAnYnVkZ2V0X2F2Jy4KVW5p Zm9ybSBNdWx0aS1QbGF0Zm9ybSBFLUlERSBkcml2ZXIgUmV2aXNpb246IDcuMDBhbHBoYTIK aWRlOiBBc3N1bWluZyAzM01IeiBzeXN0ZW0gYnVzIHNwZWVkIGZvciBQSU8gbW9kZXM7IG92 ZXJyaWRlIHdpdGggaWRlYnVzPXh4Ck5GT1JDRS1DSzgwNDogSURFIGNvbnRyb2xsZXIgYXQg UENJIHNsb3QgMDAwMDowMDowNi4wCk5GT1JDRS1DSzgwNDogY2hpcHNldCByZXZpc2lvbiAy NDIKTkZPUkNFLUNLODA0OiBub3QgMTAwJSBuYXRpdmUgbW9kZTogd2lsbCBwcm9iZSBpcnFz IGxhdGVyCk5GT1JDRS1DSzgwNDogMDAwMDowMDowNi4wIChyZXYgZjIpIFVETUExMzMgY29u dHJvbGxlcgogICAgaWRlMDogQk0tRE1BIGF0IDB4MWMwMC0weDFjMDcsIEJJT1Mgc2V0dGlu Z3M6IGhkYTpETUEsIGhkYjpETUEKICAgIGlkZTE6IEJNLURNQSBhdCAweDFjMDgtMHgxYzBm LCBCSU9TIHNldHRpbmdzOiBoZGM6cGlvLCBoZGQ6cGlvClByb2JpbmcgSURFIGludGVyZmFj ZSBpZGUwLi4uCmhkYTogSUMzNUwxMjBBVlYyMDctMSwgQVRBIERJU0sgZHJpdmUKaGRiOiBf TkVDIERWRF9SVyBORC0zNTAwQUcsIEFUQVBJIENEL0RWRC1ST00gZHJpdmUKaWRlMCBhdCAw eDFmMC0weDFmNywweDNmNiBvbiBpcnEgMTQKUHJvYmluZyBJREUgaW50ZXJmYWNlIGlkZTEu Li4KUHJvYmluZyBJREUgaW50ZXJmYWNlIGlkZTEuLi4KaGRhOiBtYXggcmVxdWVzdCBzaXpl OiAxMDI0S2lCCmhkYTogMjQxMjU0NzIwIHNlY3RvcnMgKDEyMzUyMiBNQikgdy83OTY1S2lC IENhY2hlLCBDSFM9MTYzODMvMjU1LzYzLCBVRE1BKDEwMCkKaGRhOiBjYWNoZSBmbHVzaGVz IHN1cHBvcnRlZAogaGRhOiBoZGExIGhkYTIgaGRhMyBoZGE0CmhkYjogQVRBUEkgNDhYIERW RC1ST00gRFZELVIgQ0QtUi9SVyBkcml2ZSwgMjA0OGtCIENhY2hlLCBVRE1BKDMzKQpVbmlm b3JtIENELVJPTSBkcml2ZXIgUmV2aXNpb246IDMuMjAKRnVzaW9uIE1QVCBiYXNlIGRyaXZl ciAzLjAzLjAyCkNvcHlyaWdodCAoYykgMTk5OS0yMDA1IExTSSBMb2dpYyBDb3Jwb3JhdGlv bgpGdXNpb24gTVBUIFNQSSBIb3N0IGRyaXZlciAzLjAzLjAyCkFDUEk6IFBDSSBJbnRlcnJ1 cHQgMDAwMDowYTowNi4wW0FdIC0+IEdTSSAzMCAobGV2ZWwsIGxvdykgLT4gSVJRIDE5Mwpt cHRiYXNlOiBJbml0aWF0aW5nIGlvYzAgYnJpbmd1cAppb2MwOiA1M0MxMDMwOiBDYXBhYmls aXRpZXM9e0luaXRpYXRvcixUYXJnZXR9CnNjc2kwIDogaW9jMDogTFNJNTNDMTAzMCwgRndS ZXY9MDEwMzI3MDBoLCBQb3J0cz0xLCBNYXhRPTI1NSwgSVJRPTE5MwpBQ1BJOiBQQ0kgSW50 ZXJydXB0IDAwMDA6MGE6MDYuMVtCXSAtPiBHU0kgMzEgKGxldmVsLCBsb3cpIC0+IElSUSAy MDEKbXB0YmFzZTogSW5pdGlhdGluZyBpb2MxIGJyaW5ndXAKaW9jMTogNTNDMTAzMDogQ2Fw YWJpbGl0aWVzPXtJbml0aWF0b3IsVGFyZ2V0fQpzY3NpMSA6IGlvYzE6IExTSTUzQzEwMzAs IEZ3UmV2PTAxMDMyNzAwaCwgUG9ydHM9MSwgTWF4UT0yNTUsIElSUT0yMDEKRnVzaW9uIE1Q VCBtaXNjIGRldmljZSAoaW9jdGwpIGRyaXZlciAzLjAzLjAyCm1wdGN0bDogUmVnaXN0ZXJl ZCB3aXRoIEZ1c2lvbiBNUFQgYmFzZSBkcml2ZXIKbXB0Y3RsOiAvZGV2L21wdGN0bCBAICht YWpvcixtaW5vcj0xMCwyMjApCmllZWUxMzk0OiBJbml0aWFsaXplZCBjb25maWcgcm9tIGVu dHJ5IGBpcDEzOTQnCm9oY2kxMzk0OiAkUmV2OiAxMjk5ICQgQmVuIENvbGxpbnMgPGJjb2xs aW5zQGRlYmlhbi5vcmc+CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBbTE5LNF0gZW5hYmxl ZCBhdCBJUlEgMTgKQUNQSTogUENJIEludGVycnVwdCAwMDAwOjAxOjA1LjBbQV0gLT4gTGlu ayBbTE5LNF0gLT4gR1NJIDE4IChsZXZlbCwgaGlnaCkgLT4gSVJRIDIwOQpvaGNpMTM5NDog ZnctaG9zdDA6IE9IQ0ktMTM5NCAxLjEgKFBDSSk6IElSUT1bMjA5XSAgTU1JTz1bYjAxMDQw MDAtYjAxMDQ3ZmZdICBNYXggUGFja2V0PVsyMDQ4XQppZWVlMTM5NDogcmF3MTM5NDogL2Rl di9yYXcxMzk0IGRldmljZSBpbml0aWFsaXplZApzYnAyOiAkUmV2OiAxMzA2ICQgQmVuIENv bGxpbnMgPGJjb2xsaW5zQGRlYmlhbi5vcmc+CkFDUEk6IFBDSSBJbnRlcnJ1cHQgTGluayBb TFVTMl0gZW5hYmxlZCBhdCBJUlEgMjIKQUNQSTogUENJIEludGVycnVwdCAwMDAwOjAwOjAy LjFbQl0gLT4gTGluayBbTFVTMl0gLT4gR1NJIDIyIChsZXZlbCwgaGlnaCkgLT4gSVJRIDIx NwpQQ0k6IFNldHRpbmcgbGF0ZW5jeSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMDowMi4xIHRv IDY0CmVoY2lfaGNkIDAwMDA6MDA6MDIuMTogblZpZGlhIENvcnBvcmF0aW9uIENLODA0IFVT QiBDb250cm9sbGVyCmVoY2lfaGNkIDAwMDA6MDA6MDIuMTogZGVidWcgcG9ydCAxCmllZWUx Mzk0OiBIb3N0IGFkZGVkOiBJRDpCVVNbMC0wMDoxMDIzXSAgR1VJRFswMGUwODEwMDAwMjM4 ZDJkXQplaGNpX2hjZCAwMDAwOjAwOjAyLjE6IEJJT1MgaGFuZG9mZiBmYWlsZWQgKDE2MCwg MDEwMTAwMDEpCmVoY2lfaGNkIDAwMDA6MDA6MDIuMTogY29udGludWluZyBhZnRlciBCSU9T IGJ1Zy4uLgplaGNpX2hjZCAwMDAwOjAwOjAyLjE6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQs IGFzc2lnbmVkIGJ1cyBudW1iZXIgMQplaGNpX2hjZCAwMDAwOjAwOjAyLjE6IGlycSAyMTcs IGlvIG1lbSAweGIwMDAxMDAwClBDSTogY2FjaGUgbGluZSBzaXplIG9mIDY0IGlzIG5vdCBz dXBwb3J0ZWQgYnkgZGV2aWNlIDAwMDA6MDA6MDIuMQplaGNpX2hjZCAwMDAwOjAwOjAyLjE6 IHBhcmsgMAplaGNpX2hjZCAwMDAwOjAwOjAyLjE6IFVTQiAyLjAgaW5pdGlhbGl6ZWQsIEVI Q0kgMS4wMCwgZHJpdmVyIDEwIERlYyAyMDA0Cmh1YiAxLTA6MS4wOiBVU0IgaHViIGZvdW5k Cmh1YiAxLTA6MS4wOiAxMCBwb3J0cyBkZXRlY3RlZApvaGNpX2hjZDogMjAwNSBBcHJpbCAy MiBVU0IgMS4xICdPcGVuJyBIb3N0IENvbnRyb2xsZXIgKE9IQ0kpIERyaXZlciAoUENJKQpB Q1BJOiBQQ0kgSW50ZXJydXB0IExpbmsgW0xVUzBdIGVuYWJsZWQgYXQgSVJRIDIxCkFDUEk6 IFBDSSBJbnRlcnJ1cHQgMDAwMDowMDowMi4wW0FdIC0+IExpbmsgW0xVUzBdIC0+IEdTSSAy MSAobGV2ZWwsIGhpZ2gpIC0+IElSUSAyMjUKUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIg b2YgZGV2aWNlIDAwMDA6MDA6MDIuMCB0byA2NApvaGNpX2hjZCAwMDAwOjAwOjAyLjA6IG5W aWRpYSBDb3Jwb3JhdGlvbiBDSzgwNCBVU0IgQ29udHJvbGxlcgpvaGNpX2hjZCAwMDAwOjAw OjAyLjA6IG5ldyBVU0IgYnVzIHJlZ2lzdGVyZWQsIGFzc2lnbmVkIGJ1cyBudW1iZXIgMgpv aGNpX2hjZCAwMDAwOjAwOjAyLjA6IGlycSAyMjUsIGlvIG1lbSAweGIwMDAwMDAwCmh1YiAy LTA6MS4wOiBVU0IgaHViIGZvdW5kCmh1YiAyLTA6MS4wOiAxMCBwb3J0cyBkZXRlY3RlZApJ bml0aWFsaXppbmcgVVNCIE1hc3MgU3RvcmFnZSBkcml2ZXIuLi4KdXNiY29yZTogcmVnaXN0 ZXJlZCBuZXcgZHJpdmVyIHVzYi1zdG9yYWdlClVTQiBNYXNzIFN0b3JhZ2Ugc3VwcG9ydCBy ZWdpc3RlcmVkLgp1c2IgMi0xOiBuZXcgZnVsbCBzcGVlZCBVU0IgZGV2aWNlIHVzaW5nIG9o Y2lfaGNkIGFuZCBhZGRyZXNzIDIKdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZHJpdmVyIGhp ZGRldgp1c2Jjb3JlOiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgdXNiaGlkCmRyaXZlcnMvdXNi L2lucHV0L2hpZC1jb3JlLmM6IHYyLjAxOlVTQiBISUQgY29yZSBkcml2ZXIKcHdjIFBoaWxp cHMgd2ViY2FtIG1vZHVsZSB2ZXJzaW9uIDkuMC4yLXVub2ZmaWNpYWwgbG9hZGVkLgpwd2Mg U3VwcG9ydHMgUGhpbGlwcyBQQ0E2NDUvNjQ2LCBQQ1ZDNjc1LzY4MC82OTAsIFBDVkM3MjBb NDBdLzczMC83NDAvNzUwICYgUENWQzgzMC84NDAuCnB3YyBBbHNvIHN1cHBvcnRzIHRoZSBB c2tleSBWQzAxMCwgdmFyaW91cyBMb2dpdGVjaCBRdWlja2NhbXMsIFNhbXN1bmcgTVBDLUMx MCBhbmQgTVBDLUMzMCwKcHdjIHRoZSBDcmVhdGl2ZSBXZWJDYW0gNSAmIFBybyBFeCwgU09U RUMgQWZpbmEgRXllIGFuZCBWaXNpb25pdGUgVkNTLVVDMzAwIGFuZCBWQ1MtVU0xMDAuCnB3 YyBMb2dpdGVjaCBRdWlja0NhbSA0MDAwIFBybyBVU0Igd2ViY2FtIGRldGVjdGVkLgpwd2Mg UmVnaXN0ZXJlZCBhcyAvZGV2L3ZpZGVvMC4KdXNiY29yZTogcmVnaXN0ZXJlZCBuZXcgZHJp dmVyIFBoaWxpcHMgd2ViY2FtCm1pY2U6IFBTLzIgbW91c2UgZGV2aWNlIGNvbW1vbiBmb3Ig YWxsIG1pY2UKaW5wdXQ6IFBDIFNwZWFrZXIKaTJjIC9kZXYgZW50cmllcyBkcml2ZXIKaTJj X2FkYXB0ZXIgaTJjLTA6IG5Gb3JjZTIgU01CdXMgYWRhcHRlciBhdCAweGEwMDAKaTJjX2Fk YXB0ZXIgaTJjLTE6IG5Gb3JjZTIgU01CdXMgYWRhcHRlciBhdCAweGEwNDAKZGV2aWNlLW1h cHBlcjogNC40LjAtaW9jdGwgKDIwMDUtMDEtMTIpIGluaXRpYWxpc2VkOiBkbS1kZXZlbEBy ZWRoYXQuY29tCkFkdmFuY2VkIExpbnV4IFNvdW5kIEFyY2hpdGVjdHVyZSBEcml2ZXIgVmVy c2lvbiAxLjAuOWIgKFRodSBKdWwgMjggMTI6MjA6MTMgMjAwNSBVVEMpLgpBQ1BJOiBQQ0kg SW50ZXJydXB0IExpbmsgW0xBQ0ldIGVuYWJsZWQgYXQgSVJRIDIwCkFDUEk6IFBDSSBJbnRl cnJ1cHQgMDAwMDowMDowNC4wW0FdIC0+IExpbmsgW0xBQ0ldIC0+IEdTSSAyMCAobGV2ZWws IGhpZ2gpIC0+IElSUSAyMzMKUENJOiBTZXR0aW5nIGxhdGVuY3kgdGltZXIgb2YgZGV2aWNl IDAwMDA6MDA6MDQuMCB0byA2NAppbnB1dDogQVQgVHJhbnNsYXRlZCBTZXQgMiBrZXlib2Fy ZCBvbiBpc2EwMDYwL3NlcmlvMAppbnB1dDogSW1FeFBTLzIgR2VuZXJpYyBFeHBsb3JlciBN b3VzZSBvbiBpc2EwMDYwL3NlcmlvMQppbnRlbDh4MF9tZWFzdXJlX2FjOTdfY2xvY2s6IG1l YXN1cmVkIDUxMTA1IHVzZWNzCmludGVsOHgwOiBjbG9ja2luZyB0byA0Njg3NAp1c2Jjb3Jl OiByZWdpc3RlcmVkIG5ldyBkcml2ZXIgc25kLXVzYi1hdWRpbwpBTFNBIGRldmljZSBsaXN0 OgogICMwOiBOVmlkaWEgQ0s4MDQgd2l0aCBBRDE5ODFCIGF0IDB4YjAwMDIwMDAsIGlycSAy MzMKICAjMTogVVNCIERldmljZSAweDQ2ZDoweDhiMiBhdCB1c2ItMDAwMDowMDowMi4wLTEs IGZ1bGwgc3BlZWQKTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAyCklQIHJvdXRl IGNhY2hlIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRlcjogOCwgMTA0ODU3NiBi eXRlcykKVENQIGVzdGFibGlzaGVkIGhhc2ggdGFibGUgZW50cmllczogMjYyMTQ0IChvcmRl cjogMTAsIDQxOTQzMDQgYnl0ZXMpClRDUCBiaW5kIGhhc2ggdGFibGUgZW50cmllczogNjU1 MzYgKG9yZGVyOiA3LCA3ODY0MzIgYnl0ZXMpClRDUDogSGFzaCB0YWJsZXMgY29uZmlndXJl ZCAoZXN0YWJsaXNoZWQgMjYyMTQ0IGJpbmQgNjU1MzYpClRDUCByZW5vIHJlZ2lzdGVyZWQK VENQIGJpYyByZWdpc3RlcmVkCkluaXRpYWxpemluZyBJUHNlYyBuZXRsaW5rIHNvY2tldApO RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDEKTkVUOiBSZWdpc3RlcmVkIHByb3Rv Y29sIGZhbWlseSAxMApEaXNhYmxlZCBQcml2YWN5IEV4dGVuc2lvbnMgb24gZGV2aWNlIGMw NTg0NWMwKGxvKQpJUHY2IG92ZXIgSVB2NCB0dW5uZWxpbmcgZHJpdmVyCk5FVDogUmVnaXN0 ZXJlZCBwcm90b2NvbCBmYW1pbHkgMTcKTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWls eSAxNQpTdGFydGluZyBiYWxhbmNlZF9pcnEKVXNpbmcgSVBJIFNob3J0Y3V0IG1vZGUKWEZT IG1vdW50aW5nIGZpbGVzeXN0ZW0gaGRhMQpFbmRpbmcgY2xlYW4gWEZTIG1vdW50IGZvciBm aWxlc3lzdGVtOiBoZGExClZGUzogTW91bnRlZCByb290ICh4ZnMgZmlsZXN5c3RlbSkgcmVh ZG9ubHkuCkZyZWVpbmcgdW51c2VkIGtlcm5lbCBtZW1vcnk6IDIzMmsgZnJlZWQKQWRkaW5n IDE5NTE4ODhrIHN3YXAgb24gL2Rldi9oZGE0LiAgUHJpb3JpdHk6LTEgZXh0ZW50czoxClhG UyBtb3VudGluZyBmaWxlc3lzdGVtIGhkYTMKRW5kaW5nIGNsZWFuIFhGUyBtb3VudCBmb3Ig ZmlsZXN5c3RlbTogaGRhMwpYRlMgbW91bnRpbmcgZmlsZXN5c3RlbSBoZGEyCkVuZGluZyBj bGVhbiBYRlMgbW91bnQgZm9yIGZpbGVzeXN0ZW06IGhkYTIKZXRoMDogbm8gbGluayBkdXJp bmcgaW5pdGlhbGl6YXRpb24uCkNTTElQOiBjb2RlIGNvcHlyaWdodCAxOTg5IFJlZ2VudHMg b2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYQpQUFAgZ2VuZXJpYyBkcml2ZXIgdmVy c2lvbiAyLjQuMgpORVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDI0CnR0eVMxOiBM U1Igc2FmZXR5IGNoZWNrIGVuZ2FnZWQhCnR0eVMxOiBMU1Igc2FmZXR5IGNoZWNrIGVuZ2Fn ZWQhCmV0aDA6IG5vIElQdjYgcm91dGVycyBwcmVzZW50CmV0aDE6IG5vIElQdjYgcm91dGVy cyBwcmVzZW50Cm52aWRpYTogbW9kdWxlIGxpY2Vuc2UgJ05WSURJQScgdGFpbnRzIGtlcm5l bC4KQUNQSTogUENJIEludGVycnVwdCAwMDAwOjAyOjAwLjBbQV0gLT4gTGluayBbTE5LM10g LT4gR1NJIDE5IChsZXZlbCwgaGlnaCkgLT4gSVJRIDE4NQpQQ0k6IFNldHRpbmcgbGF0ZW5j eSB0aW1lciBvZiBkZXZpY2UgMDAwMDowMjowMC4wIHRvIDY0Ck5WUk06IGxvYWRpbmcgTlZJ RElBIExpbnV4IHg4NiBOVklESUEgS2VybmVsIE1vZHVsZSAgMS4wLTc2NzYgIEZyaSBKdWwg MjkgMTI6NTg6NTQgUERUIDIwMDUKQUNQSTogUENJIGludGVycnVwdCBmb3IgZGV2aWNlIDAw MDA6MDI6MDAuMCBkaXNhYmxlZApBQ1BJOiBQQ0kgSW50ZXJydXB0IDAwMDA6MDI6MDAuMFtB XSAtPiBMaW5rIFtMTkszXSAtPiBHU0kgMTkgKGxldmVsLCBoaWdoKSAtPiBJUlEgMTg1ClBD STogU2V0dGluZyBsYXRlbmN5IHRpbWVyIG9mIGRldmljZSAwMDAwOjAyOjAwLjAgdG8gNjQK TlZSTTogbG9hZGluZyBOVklESUEgTGludXggeDg2IE5WSURJQSBLZXJuZWwgTW9kdWxlICAx LjAtNzY3NiAgRnJpIEp1bCAyOSAxMjo1ODo1NCBQRFQgMjAwNQpwd2MgRmFpbGVkIHRvIHNl dCBMRUQgb24vb2ZmIHRpbWUuCnB3YyB0eXBlID0gNzQwCnB3YyB0eXBlID0gNzQwCnB3YyBz ZXRfdmlkZW9fbW9kZSgxNzZ4MTQ0IEAgMTAsIHBhbGV0dGUgMTUpLgpwd2MgZGVjb2RlX3Np emUgPSAxLgpwd2MgVXNpbmcgYWx0ZXJuYXRlIHNldHRpbmcgMS4KcHdjIHR5cGUgPSA3NDAK cHdjIHR5cGUgPSA3NDAKcHdjIHNldF92aWRlb19tb2RlKDE2MHgxMjAgQCAxMCwgcGFsZXR0 ZSAxNSkuCnB3YyBkZWNvZGVfc2l6ZSA9IDEuCnB3YyBVc2luZyBhbHRlcm5hdGUgc2V0dGlu ZyAxLgpwd2MgdHlwZSA9IDc0MApwd2MgdHlwZSA9IDc0MApwd2Mgc2V0X3ZpZGVvX21vZGUo MTYweDEyMCBAIDEwLCBwYWxldHRlIDE1KS4KcHdjIGRlY29kZV9zaXplID0gMS4KcHdjIFVz aW5nIGFsdGVybmF0ZSBzZXR0aW5nIDEuCg== --------------010603060407060408040005 Content-Type: text/x-log; name="kern.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kern.log" ... Sep 30 13:08:45 fermat kernel: scsi1 : ioc1: LSI53C1030, FwRev=01032700h, Ports=1, MaxQ=255, IRQ=233 Sep 30 13:08:45 fermat kernel: eth1: no link during initialization. Sep 30 13:08:45 fermat kernel: eth2: no link during initialization. Sep 30 13:08:45 fermat kernel: CSLIP: code copyright 1989 Regents of the University of California Sep 30 13:08:45 fermat kernel: PPP generic driver version 2.4.2 Sep 30 13:08:45 fermat kernel: ttyS1: LSR safety check engaged! Sep 30 13:08:45 fermat kernel: ttyS1: LSR safety check engaged! Sep 30 13:08:52 fermat kernel: eth1: no IPv6 routers present Sep 30 13:08:53 fermat kernel: eth2: no IPv6 routers present Sep 30 13:10:13 fermat kernel: eth1: link up. Sep 30 13:13:09 fermat kernel: eth1: link down. Sep 30 13:13:12 fermat kernel: eth2: link up. Sep 30 13:13:21 fermat kernel: NET: Registered protocol family 24 Sep 30 16:15:58 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 16:16:38 fermat last message repeated 4 times Sep 30 16:17:38 fermat last message repeated 6 times Sep 30 16:18:38 fermat last message repeated 6 times Sep 30 16:19:38 fermat last message repeated 6 times Sep 30 16:20:38 fermat last message repeated 6 times Sep 30 16:21:38 fermat last message repeated 6 times Sep 30 16:22:38 fermat last message repeated 6 times Sep 30 16:23:38 fermat last message repeated 6 times Sep 30 16:24:37 fermat last message repeated 6 times Sep 30 16:25:37 fermat last message repeated 6 times Sep 30 16:26:37 fermat last message repeated 6 times Sep 30 16:27:47 fermat last message repeated 7 times Sep 30 16:27:57 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 17:57:35 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 18:05:05 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 18:51:49 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 19:10:13 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 19:57:32 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 19:58:32 fermat last message repeated 6 times Sep 30 19:59:32 fermat last message repeated 6 times Sep 30 20:00:32 fermat last message repeated 6 times Sep 30 20:01:32 fermat last message repeated 6 times Sep 30 20:02:32 fermat last message repeated 6 times Sep 30 20:03:22 fermat last message repeated 5 times Sep 30 20:19:37 fermat kernel: NETDEV WATCHDOG: eth2: transmit timed out Sep 30 20:19:44 fermat kernel: Kernel logging (proc) stopped. Sep 30 20:19:44 fermat kernel: Kernel log daemon terminating. ... ... ... Oct 16 14:51:15 fermat kernel: NETDEV WATCHDOG: eth1: transmit timed out Oct 16 14:51:55 fermat last message repeated 4 times Oct 16 14:52:55 fermat last message repeated 6 times Oct 16 14:53:55 fermat last message repeated 6 times Oct 16 14:54:55 fermat last message repeated 6 times Oct 16 14:55:45 fermat last message repeated 5 times Oct 16 15:08:15 fermat kernel: NETDEV WATCHDOG: eth1: transmit timed out Oct 16 15:09:25 fermat last message repeated 7 times Oct 16 15:10:25 fermat last message repeated 6 times Oct 16 15:11:25 fermat last message repeated 6 times Oct 16 15:12:25 fermat last message repeated 6 times Oct 16 15:13:25 fermat last message repeated 6 times ... --------------010603060407060408040005 Content-Type: text/x-vcard; charset=utf-8; name="cam.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="cam.vcf" YmVnaW46dmNhcmQNCmZuOk1pdHRlcmVyLCBDaHJpc3RvcGggQW50b24NCm46TWl0dGVyZXI7 Q2hyaXN0b3BoIEFudG9uDQpvcmc6TXVuaWNoIFVuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2ll bmNlcztEZXBhcnRtZW50IG9mIE1hdGhlbWF0aWNzIGFuZCBDb21wdXRlciBTY2llbmNlDQph ZHI7cXVvdGVkLXByaW50YWJsZTtxdW90ZWQtcHJpbnRhYmxlOjs7TG90aHN0cmE9QzM9OUZl IDM0O009QzM9QkNuY2hlbjtGcmVpc3RhYXQgQmF5ZXJuOzgwMzM1O0ZlZGVyYWwgUmVwdWJs aWMgb2YgR2VybWFueQ0KZW1haWw7aW50ZXJuZXQ6Y2FtQG1hdGhlbWF0aWNhLnNjaWVudGlh Lm5ldA0KdGVsO2hvbWU6KzQ5IDg5IDI0NDA5NTY4DQp0ZWw7Y2VsbDorNDkgMTcyIDg2MTcz NDENCngtbW96aWxsYS1odG1sOlRSVUUNCnVybDpodHRwOi8vZmhtLmVkdS8NCnZlcnNpb246 Mi4xDQplbmQ6dmNhcmQNCg0K --------------010603060407060408040005-- From mbizon@freebox.fr Tue Oct 18 10:08:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 18 Oct 2005 10:08:41 -0700 (PDT) Received: from sakura.staff.proxad.net (sakura.staff.proxad.net [213.228.1.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9IH8QO0018901 for ; Tue, 18 Oct 2005 10:08:33 -0700 Received: from localhost ([127.0.0.1]) by sakura.staff.proxad.net with esmtp (Exim 3.36 #1 (Debian)) id 1ERuts-0004MK-00; Tue, 18 Oct 2005 19:05:20 +0200 Subject: [PATCH] ipconfig.c: fix "dhcp server takes precedence over bootp header one" From: Maxime Bizon To: davem@davemloft.net Cc: netdev@oss.sgi.com Content-Type: text/plain Date: Tue, 18 Oct 2005 19:05:19 +0200 Message-Id: <1129655119.4133.71.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 3754 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbizon@freebox.fr Precedence: bulk X-list: netdev Content-Length: 1269 Lines: 50 Hello, I was unable to use nfs root with a dhcp server that does not fill the "saddr" field in the bootp header (kernel then tries RPC on 0.0.0.0). The ipconfig code states that the dhcp server_id takes precedence over bootp header, but I think the check is misplaced as it is done only for DHCPOFFER. The following patch fixes the problem. Signed-off-by: Maxime Bizon --- linux-2.6.13.4/net/ipv4/ipconfig.c.orig 2005-10-18 18:11:54.000000000 +0200 +++ linux-2.6.13.4/net/ipv4/ipconfig.c 2005-10-18 18:22:18.000000000 +0200 @@ -959,13 +959,6 @@ printk(" by server %u.%u.%u.%u\n", NIPQUAD(ic_servaddr)); #endif - /* The DHCP indicated server address takes - * precedence over the bootp header one if - * they are different. - */ - if ((server_id != INADDR_NONE) && - (b->server_ip != server_id)) - b->server_ip = ic_servaddr; break; case DHCPACK: @@ -982,6 +975,14 @@ goto drop_unlock; }; + /* The DHCP indicated server address takes + * precedence over the bootp header one if + * they are different. + */ + if ((server_id != INADDR_NONE) && + (b->server_ip != server_id)) + b->server_ip = ic_servaddr; + ic_dhcp_msgtype = mt; } -- Maxime From mbizon@freebox.fr Wed Oct 19 12:46:45 2005 Received: with ECARTIS (v1.0.0; list netdev); Wed, 19 Oct 2005 12:46:50 -0700 (PDT) Received: from sakura.staff.proxad.net (sakura.staff.proxad.net [213.228.1.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9JJkeO0028324 for ; Wed, 19 Oct 2005 12:46:45 -0700 Received: from localhost ([127.0.0.1]) by sakura.staff.proxad.net with esmtp (Exim 3.36 #1 (Debian)) id 1ESJqX-000590-00; Wed, 19 Oct 2005 21:43:33 +0200 Subject: [PATCH] ipconfig.c: fix dhcp timeout leading to bad requested address. From: Maxime Bizon To: davem@davemloft.net Cc: netdev@oss.sgi.com Content-Type: text/plain Date: Wed, 19 Oct 2005 21:43:32 +0200 Message-Id: <1129751012.1724.13.camel@sakura.staff.proxad.net> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 3757 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mbizon@freebox.fr Precedence: bulk X-list: netdev Content-Length: 870 Lines: 33 Hello, There is still a little bug in dhcp timeout handling. When DHCPOFFER is received, offered and server addresses are kept. If no ack is received, ic_myaddr is reset to INADDR_NONE, but not ic_servaddr. The problem is that ic_dhcp_init_options() checks only ic_servaddr to known if it has to send a DHCPOFFER or a DHCPREQUEST. So packets sent after a timeout will be DHCPREQUEST with requested address INADDR_NONE. If the the dhcp server does not NAK it, this request is done forever. The following patch fixes this. Signed-off-by: Maxime Bizon --- linux-2.6.13.4/net/ipv4/ipconfig.c.orig 2005-10-18 18:11:54.000000000 +0200 +++ linux-2.6.13.4/net/ipv4/ipconfig.c 2005-10-19 20:44:07.000000000 +0200 @@ -1151,6 +1151,7 @@ if (!ic_got_reply) { ic_myaddr = INADDR_NONE; + ic_servaddr = INADDR_NONE; return -1; } -- Maxime From manfred@colorfullife.com Fri Oct 21 11:17:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 11:17:22 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LIHDO0012106 for ; Fri, 21 Oct 2005 11:17:14 -0700 Received: from [127.0.0.2] (dbl [127.0.0.1]) by dbl.q-ag.de (8.13.3/8.13.3/Debian-6) with ESMTP id j9LILXh1021680; Fri, 21 Oct 2005 20:21:34 +0200 Message-ID: <43592FE5.20106@colorfullife.com> Date: Fri, 21 Oct 2005 20:13:57 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.12) Gecko/20050923 Fedora/1.7.12-1.5.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Ayaz Abdulla Subject: [patch] forcedeth: add support for interrupt mitigation Content-Type: multipart/mixed; boundary="------------090502010808050204090705" X-archive-position: 3760 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 Content-Length: 8292 Lines: 276 This is a multi-part message in MIME format. --------------090502010808050204090705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The current forcedeth driver doesn't support interrupt mitigation, this can result in an incredible number of interrupts/sec for gigabit links. The attached patch adds a throughput mode that enables an interrupt mitigation scheme. -- Manfred --------------090502010808050204090705 Content-Type: text/plain; name="patch-forcedeth-046-optimization-mode" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forcedeth-046-optimization-mode" --- 2.6/drivers/net/forcedeth.c 2005-10-20 23:17:24.000000000 +0200 +++ build-2.6/drivers/net/forcedeth.c 2005-10-19 21:01:55.000000000 +0200 @@ -98,6 +98,7 @@ * 0.43: 10 Aug 2005: Add support for tx checksum. * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation. * 0.45: 18 Sep 2005: Remove nv_stop/start_rx from every link check + * 0.46: 20 Aug 2005: Add irq optimization modes. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -109,7 +110,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.45" +#define FORCEDETH_VERSION "0.46" #define DRV_NAME "forcedeth" #include @@ -164,7 +165,8 @@ #define NVREG_IRQ_LINK 0x0040 #define NVREG_IRQ_TX_ERROR 0x0080 #define NVREG_IRQ_TX1 0x0100 -#define NVREG_IRQMASK_WANTED 0x00df +#define NVREG_IRQMASK_THROUGHPUT 0x00df +#define NVREG_IRQMASK_CPU 0x0040 #define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \ NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \ @@ -178,7 +180,8 @@ * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms */ NvRegPollingInterval = 0x00c, -#define NVREG_POLL_DEFAULT 970 +#define NVREG_POLL_DEFAULT_THROUGHPUT 970 +#define NVREG_POLL_DEFAULT_CPU 13 NvRegMisc1 = 0x080, #define NVREG_MISC1_HD 0x02 #define NVREG_MISC1_FORCE 0x3b0f3c @@ -539,6 +542,18 @@ */ static int max_interrupt_work = 5; +/* + * Optimization can be either throuput mode or cpu mode + */ +#define NV_OPTIMIZATION_MODE_THROUGHPUT 0 +#define NV_OPTIMIZATION_MODE_CPU 1 +static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT; + +/* + * Poll interval for timer irq + */ +static int poll_interval = -1; + static inline struct fe_priv *get_nvpriv(struct net_device *dev) { return netdev_priv(dev); @@ -1330,67 +1345,71 @@ if (!(Flags & NV_RX_DESCRIPTORVALID)) goto next_pkt; - if (Flags & NV_RX_MISSEDFRAME) { - np->stats.rx_missed_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3)) { - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX_CRCERR) { - np->stats.rx_crc_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX_OVERFLOW) { - np->stats.rx_over_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX_ERROR4) { - len = nv_getlen(dev, np->rx_skbuff[i]->data, len); - if (len < 0) { + if (Flags & NV_RX_ERROR) { + if (Flags & NV_RX_MISSEDFRAME) { + np->stats.rx_missed_errors++; np->stats.rx_errors++; goto next_pkt; } - } - /* framing errors are soft errors. */ - if (Flags & NV_RX_FRAMINGERR) { - if (Flags & NV_RX_SUBSTRACT1) { - len--; + if (Flags & (NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3)) { + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_CRCERR) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX_ERROR4) { + len = nv_getlen(dev, np->rx_skbuff[i]->data, len); + if (len < 0) { + np->stats.rx_errors++; + goto next_pkt; + } + } + /* framing errors are soft errors. */ + if (Flags & NV_RX_FRAMINGERR) { + if (Flags & NV_RX_SUBSTRACT1) { + len--; + } } } } else { if (!(Flags & NV_RX2_DESCRIPTORVALID)) goto next_pkt; - if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3)) { - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX2_CRCERR) { - np->stats.rx_crc_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX2_OVERFLOW) { - np->stats.rx_over_errors++; - np->stats.rx_errors++; - goto next_pkt; - } - if (Flags & NV_RX2_ERROR4) { - len = nv_getlen(dev, np->rx_skbuff[i]->data, len); - if (len < 0) { + if (Flags & NV_RX2_ERROR) { + if (Flags & (NV_RX2_ERROR1|NV_RX2_ERROR2|NV_RX2_ERROR3)) { np->stats.rx_errors++; goto next_pkt; } - } - /* framing errors are soft errors */ - if (Flags & NV_RX2_FRAMINGERR) { - if (Flags & NV_RX2_SUBSTRACT1) { - len--; + if (Flags & NV_RX2_CRCERR) { + np->stats.rx_crc_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_OVERFLOW) { + np->stats.rx_over_errors++; + np->stats.rx_errors++; + goto next_pkt; + } + if (Flags & NV_RX2_ERROR4) { + len = nv_getlen(dev, np->rx_skbuff[i]->data, len); + if (len < 0) { + np->stats.rx_errors++; + goto next_pkt; + } + } + /* framing errors are soft errors */ + if (Flags & NV_RX2_FRAMINGERR) { + if (Flags & NV_RX2_SUBSTRACT1) { + len--; + } } } Flags &= NV_RX2_CHECKSUMMASK; @@ -1810,22 +1829,18 @@ if (!(events & np->irqmask)) break; - if (events & (NVREG_IRQ_TX1|NVREG_IRQ_TX_OK|NVREG_IRQ_TX_ERROR|NVREG_IRQ_TX_ERR)) { + spin_lock(&np->lock); + nv_tx_done(dev); + spin_unlock(&np->lock); + + nv_rx_process(dev); + if (nv_alloc_rx(dev)) { spin_lock(&np->lock); - nv_tx_done(dev); + if (!np->in_shutdown) + mod_timer(&np->oom_kick, jiffies + OOM_REFILL); spin_unlock(&np->lock); } - - if (events & (NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { - nv_rx_process(dev); - if (nv_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); nv_link_irq(dev); @@ -2226,7 +2241,14 @@ 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); + if (poll_interval == -1) { + if (optimization_mode == NV_OPTIMIZATION_MODE_THROUGHPUT) + writel(NVREG_POLL_DEFAULT_THROUGHPUT, base + NvRegPollingInterval); + else + writel(NVREG_POLL_DEFAULT_CPU, base + NvRegPollingInterval); + } + else + writel(poll_interval, base + NvRegPollingInterval); writel(NVREG_UNKSETUP6_VAL, base + NvRegUnknownSetupReg6); writel((np->phyaddr << NVREG_ADAPTCTL_PHYSHIFT)|NVREG_ADAPTCTL_PHYVALID|NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl); @@ -2510,7 +2532,11 @@ } else { np->tx_flags = NV_TX2_VALID; } - np->irqmask = NVREG_IRQMASK_WANTED; + if (optimization_mode == NV_OPTIMIZATION_MODE_THROUGHPUT) + np->irqmask = NVREG_IRQMASK_THROUGHPUT; + else + np->irqmask = NVREG_IRQMASK_CPU; + if (id->driver_data & DEV_NEED_TIMERIRQ) np->irqmask |= NVREG_IRQ_TIMER; if (id->driver_data & DEV_NEED_LINKTIMER) { @@ -2698,6 +2724,10 @@ module_param(max_interrupt_work, int, 0); MODULE_PARM_DESC(max_interrupt_work, "forcedeth maximum events handled per interrupt"); +module_param(optimization_mode, int, 0); +MODULE_PARM_DESC(optimization_mode, "forcedeth optimization for througput (0) or cpu (1) mode"); +module_param(poll_interval, int, 0); +MODULE_PARM_DESC(poll_interval, "forcedeth polling interval for timer irq"); MODULE_AUTHOR("Manfred Spraul "); MODULE_DESCRIPTION("Reverse Engineered nForce ethernet driver"); --------------090502010808050204090705-- From romieu@fr.zoreil.com Fri Oct 21 13:34:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 13:34:33 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LKYRO0025723 for ; Fri, 21 Oct 2005 13:34:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.4/8.12.1) with ESMTP id j9LKT8XQ021888; Fri, 21 Oct 2005 22:29:08 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.4/8.12.1) id j9LKT8UM021887; Fri, 21 Oct 2005 22:29:08 +0200 Date: Fri, 21 Oct 2005 22:29:08 +0200 From: Francois Romieu To: Manfred Spraul Cc: Netdev , Ayaz Abdulla Subject: Re: [patch] forcedeth: add support for interrupt mitigation Message-ID: <20051021202908.GA18966@electric-eye.fr.zoreil.com> References: <43592FE5.20106@colorfullife.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <43592FE5.20106@colorfullife.com> User-Agent: Mutt/1.4.2.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 3761 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: 340 Lines: 10 Manfred Spraul : > The current forcedeth driver doesn't support interrupt mitigation, this > can result in an incredible number of interrupts/sec for gigabit links. > The attached patch adds a throughput mode that enables an interrupt > mitigation scheme. Naïve question: what about the NAPI way ? -- Ueimor From linville@tuxdriver.com Fri Oct 21 13:46:23 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 13:46:26 -0700 (PDT) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LKkMO0027030 for ; Fri, 21 Oct 2005 13:46:22 -0700 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.13.3/8.13.3) with ESMTP id j9LKgsrE014005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2005 16:42:55 -0400 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j9LKgsOj001240; Fri, 21 Oct 2005 16:42:54 -0400 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j9LKgr4d001234; Fri, 21 Oct 2005 16:42:53 -0400 Date: Fri, 21 Oct 2005 16:42:53 -0400 From: "John W. Linville" To: Francois Romieu Cc: Manfred Spraul , Netdev , Ayaz Abdulla Subject: Re: [patch] forcedeth: add support for interrupt mitigation Message-ID: <20051021204251.GC28212@tuxdriver.com> Mail-Followup-To: Francois Romieu , Manfred Spraul , Netdev , Ayaz Abdulla References: <43592FE5.20106@colorfullife.com> <20051021202908.GA18966@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20051021202908.GA18966@electric-eye.fr.zoreil.com> User-Agent: Mutt/1.4.1i X-archive-position: 3762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 591 Lines: 18 On Fri, Oct 21, 2005 at 10:29:08PM +0200, Francois Romieu wrote: > Manfred Spraul : > > The current forcedeth driver doesn't support interrupt mitigation, this > > can result in an incredible number of interrupts/sec for gigabit links. > > The attached patch adds a throughput mode that enables an interrupt > > mitigation scheme. > > Naïve question: what about the NAPI way ? I was thinking the same thing...although it appears forcedeth already supports NAPI... What does this offer over the NAPI support? John -- John W. Linville linville@tuxdriver.com From jgarzik@pobox.com Fri Oct 21 14:10:29 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:10:35 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLATO0028960 for ; Fri, 21 Oct 2005 14:10:29 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1ET46d-0008LO-38; Fri, 21 Oct 2005 21:07:15 +0000 Message-ID: <43595881.3030809@pobox.com> Date: Fri, 21 Oct 2005 17:07:13 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Manfred Spraul , Netdev , Ayaz Abdulla , "John W. Linville" Subject: Re: [patch] forcedeth: add support for interrupt mitigation References: <43592FE5.20106@colorfullife.com> <20051021202908.GA18966@electric-eye.fr.zoreil.com> In-Reply-To: <20051021202908.GA18966@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3763 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: 89 Lines: 7 FWIW the ideal is to implement both NAPI -and- hardware interrupt mitigation. Jeff From AAbdulla@nvidia.com Fri Oct 21 14:14:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:14:20 -0700 (PDT) Received: from HQEMGATE03.nvidia.com (hqemgate03.nvidia.com [216.228.112.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLEFO0029627 for ; Fri, 21 Oct 2005 14:14:15 -0700 Received: from hqemfe03.nvidia.com (Not Verified[172.16.227.123]) by HQEMGATE03.nvidia.com id ; Fri, 21 Oct 2005 14:10:54 -0700 Received: from hqemmail02.nvidia.com ([172.16.227.143]) by hqemfe03.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 14:10:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [patch] forcedeth: add support for interrupt mitigation Date: Fri, 21 Oct 2005 14:10:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [patch] forcedeth: add support for interrupt mitigation Thread-Index: AcXWg296ceANSK3nQAqClAFFpv92NwAAFCZg From: "Ayaz Abdulla" To: "Jeff Garzik" , "Francois Romieu" Cc: "Manfred Spraul" , "Netdev" , "John W. Linville" X-OriginalArrivalTime: 21 Oct 2005 21:10:51.0928 (UTC) FILETIME=[EADC1980:01C5D683] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j9LLEFO0029627 X-archive-position: 3764 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AAbdulla@nvidia.com Precedence: bulk X-list: netdev Content-Length: 467 Lines: 19 Yes, thats right. I just gave Manfred the hardware interrupt mitigation patch (v46). Next, I will implement NAPI. -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Friday, October 21, 2005 2:07 PM To: Francois Romieu Cc: Manfred Spraul; Netdev; Ayaz Abdulla; John W. Linville Subject: Re: [patch] forcedeth: add support for interrupt mitigation FWIW the ideal is to implement both NAPI -and- hardware interrupt mitigation. Jeff From jgarzik@pobox.com Fri Oct 21 14:26:46 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:26:49 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLQkO0031454 for ; Fri, 21 Oct 2005 14:26:46 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1ET4MV-0008Mh-5a; Fri, 21 Oct 2005 21:23:40 +0000 Message-ID: <43595C59.7070204@pobox.com> Date: Fri, 21 Oct 2005 17:23:37 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Ayaz Abdulla , Netdev Subject: Re: [PATCH 3/2] forcedeth: Compile fix forcedeth 0.44 References: <432D771D.7050107@colorfullife.com> In-Reply-To: <432D771D.7050107@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3766 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: 882 Lines: 25 Manfred Spraul wrote: > Hi, > > forcedeth-0.44 contains a spurious ; in nv_release_txskb. gcc-4 compiles > it with a warning, older compilers might reject it. > The attached onliner fixes that, sorry. > > Signed-off-By: Manfred Spraul > > > ------------------------------------------------------------------------ > > --- 2.6/drivers/net/forcedeth.c 2005-09-18 16:12:10.000000000 +0200 > +++ build-2.6/drivers/net/forcedeth.c 2005-09-18 16:14:19.000000000 +0200 > @@ -923,7 +923,7 @@ static int nv_init_ring(struct net_devic > static void nv_release_txskb(struct net_device *dev, unsigned int skbnr) > { > struct fe_priv *np = get_nvpriv(dev); > - struct sk_buff *skb = np->tx_skbuff[skbnr];; > + struct sk_buff *skb = np->tx_skbuff[skbnr]; > unsigned int j, entry, fragments; obviously OK, but dropped since the previous patch was dropped From jgarzik@pobox.com Fri Oct 21 14:26:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:26:29 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLQPO0031398 for ; Fri, 21 Oct 2005 14:26:25 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1ET4M8-0008Ma-OX; Fri, 21 Oct 2005 21:23:17 +0000 Message-ID: <43595C42.4080201@pobox.com> Date: Fri, 21 Oct 2005 17:23:14 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Netdev , Ayaz Abdulla Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support References: <432D7354.8000503@colorfullife.com> In-Reply-To: <432D7354.8000503@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3765 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: 3483 Lines: 124 Manfred Spraul wrote: > The attached patch adds scatter gather and segmentation offload support > into forcedeth driver. > > This patch has been tested by NVIDIA and reviewed by Manfred. > > Notes: > - Manfred mentioned that mapping of pages could take time and should not > be under spinlock for performance reasons > - During testing with netperf, I have noticed a connection running > segmentation offload gets "unoffloaded" by the kernel due to possible > retransmissions. > > Thanks, > Ayaz > > Signed-off-by: Ayaz Abdulla > Signed-off-By: Manfred Spraul Patch needs to be updated per [minor] comments below, and resent. > ------------------------------------------------------------------------ > > --- orig-2.6/drivers/net/forcedeth.c 2005-09-06 11:54:41.000000000 -0700 > +++ 2.6/drivers/net/forcedeth.c 2005-09-06 13:52:50.000000000 -0700 > @@ -915,21 +920,44 @@ > return nv_alloc_rx(dev); > } > > +static void nv_release_txskb(struct net_device *dev, unsigned int skbnr) > +{ > + struct fe_priv *np = get_nvpriv(dev); Remove get_nvpriv() and call netdev_priv() directly. > + struct sk_buff *skb = np->tx_skbuff[skbnr];; > + unsigned int j, entry, fragments; > + > + dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n", > + dev->name, skbnr, np->tx_skbuff[skbnr]); > + > + entry = skbnr; > + if ((fragments = skb_shinfo(skb)->nr_frags) != 0) { > + for (j = fragments; j >= 1; j--) { > + skb_frag_t *frag = &skb_shinfo(skb)->frags[j-1]; > + pci_unmap_page(np->pci_dev, np->tx_dma[entry], > + frag->size, > + PCI_DMA_TODEVICE); > + entry = (entry - 1) % TX_RING; > + } > + } > + pci_unmap_single(np->pci_dev, np->tx_dma[entry], > + skb->len - skb->data_len, > + PCI_DMA_TODEVICE); > + dev_kfree_skb_irq(skb); > + np->tx_skbuff[skbnr] = NULL; > +} > + > static void nv_drain_tx(struct net_device *dev) > { > struct fe_priv *np = get_nvpriv(dev); ditto, etc. > - int i; > + unsigned int i; > + > for (i = 0; i < TX_RING; i++) { > if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) > np->tx_ring.orig[i].FlagLen = 0; > else > np->tx_ring.ex[i].FlagLen = 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; > + nv_release_txskb(dev, i); > np->stats.tx_dropped++; > } > } > @@ -968,28 +996,69 @@ > 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; > - u32 tx_checksum = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0); > + u32 tx_flags_extra = (np->desc_ver == DESC_VER_1 ? NV_TX_LASTPACKET : NV_TX2_LASTPACKET); > + unsigned int fragments = skb_shinfo(skb)->nr_frags; > + unsigned int nr = (np->next_tx + fragments) % TX_RING; > + unsigned int i; > + > + spin_lock_irq(&np->lock); > + wmb(); wmb() appears spurious AFAICS, with spinlock > + if ((np->next_tx - np->nic_tx + fragments) > TX_LIMIT_STOP) { Why not references MAX_SKB_FRAGS like everyone else? > + spin_unlock_irq(&np->lock); > + netif_stop_queue(dev); > + return 1; new code should properly use NETDEV_TX_xxx return code > @@ -1020,7 +1087,8 @@ > { > struct fe_priv *np = get_nvpriv(dev); use netdev_priv() directly The rest looks OK. Jeff From jgarzik@pobox.com Fri Oct 21 14:27:47 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:27:50 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLRlO0031836 for ; Fri, 21 Oct 2005 14:27:47 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1ET4NU-0008Mp-7h; Fri, 21 Oct 2005 21:24:41 +0000 Message-ID: <43595C96.40300@pobox.com> Date: Fri, 21 Oct 2005 17:24:38 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Netdev , Ayaz Abdulla Subject: Re: [PATCH,CFT] forcedeth: Remove superflous rx engine stop/start cycles. References: <432D7B98.8050307@colorfullife.com> In-Reply-To: <432D7B98.8050307@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3767 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: 355 Lines: 16 Manfred Spraul wrote: > Hi all, > > Ayaz noticed that forcedeth stops and restarts the rx engine every 3 > seconds (link timeout). The attached patch fixes that. > It also contains a larger whitespace cleanup: I've replaced a few spaces > in the comments with tabs. > > Please test it. Patch OK, but dropped since version 0.44 was dropped. Jeff From jgarzik@pobox.com Fri Oct 21 14:36:24 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 21 Oct 2005 14:36:26 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9LLaNO0000680 for ; Fri, 21 Oct 2005 14:36:24 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1ET4Vp-0008NG-8e; Fri, 21 Oct 2005 21:33:17 +0000 Message-ID: <43595E9A.7090505@pobox.com> Date: Fri, 21 Oct 2005 17:33:14 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Manfred Spraul CC: Netdev , Ayaz Abdulla Subject: Re: [patch] forcedeth: add support for interrupt mitigation References: <43592FE5.20106@colorfullife.com> In-Reply-To: <43592FE5.20106@colorfullife.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3768 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: 3151 Lines: 87 Manfred Spraul wrote: > Hi, > > The current forcedeth driver doesn't support interrupt mitigation, this > can result in an incredible number of interrupts/sec for gigabit links. > The attached patch adds a throughput mode that enables an interrupt > mitigation scheme. > > > -- > Manfred > > > ------------------------------------------------------------------------ > > --- 2.6/drivers/net/forcedeth.c 2005-10-20 23:17:24.000000000 +0200 > +++ build-2.6/drivers/net/forcedeth.c 2005-10-19 21:01:55.000000000 +0200 > @@ -98,6 +98,7 @@ > * 0.43: 10 Aug 2005: Add support for tx checksum. > * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation. > * 0.45: 18 Sep 2005: Remove nv_stop/start_rx from every link check > + * 0.46: 20 Aug 2005: Add irq optimization modes. > * > * Known bugs: > * We suspect that on some hardware no TX done interrupts are generated. > @@ -109,7 +110,7 @@ > * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few > * superfluous timer interrupts from the nic. > */ > -#define FORCEDETH_VERSION "0.45" > +#define FORCEDETH_VERSION "0.46" > #define DRV_NAME "forcedeth" > > #include > @@ -164,7 +165,8 @@ > #define NVREG_IRQ_LINK 0x0040 > #define NVREG_IRQ_TX_ERROR 0x0080 > #define NVREG_IRQ_TX1 0x0100 > -#define NVREG_IRQMASK_WANTED 0x00df > +#define NVREG_IRQMASK_THROUGHPUT 0x00df > +#define NVREG_IRQMASK_CPU 0x0040 > > #define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR| \ > NVREG_IRQ_TX_OK|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX_ERROR| \ > @@ -178,7 +180,8 @@ > * NVREG_POLL_DEFAULT=97 would result in an interval length of 1 ms > */ > NvRegPollingInterval = 0x00c, > -#define NVREG_POLL_DEFAULT 970 > +#define NVREG_POLL_DEFAULT_THROUGHPUT 970 > +#define NVREG_POLL_DEFAULT_CPU 13 > NvRegMisc1 = 0x080, > #define NVREG_MISC1_HD 0x02 > #define NVREG_MISC1_FORCE 0x3b0f3c > @@ -539,6 +542,18 @@ > */ > static int max_interrupt_work = 5; > > +/* > + * Optimization can be either throuput mode or cpu mode > + */ > +#define NV_OPTIMIZATION_MODE_THROUGHPUT 0 > +#define NV_OPTIMIZATION_MODE_CPU 1 > +static int optimization_mode = NV_OPTIMIZATION_MODE_THROUGHPUT; > + > +/* > + * Poll interval for timer irq > + */ > +static int poll_interval = -1; The code changes themselves seem correct, but this patch suffers from a few overall problems. * "throughput or cpu" doesn't tell the user very much -- or me, for that matter. Does "cpu mode" mean low latency, high interrupt count? If so, just allow the user to choose between throughput and latency. * making this a static decision at module load time is sub-optimal. 99% of users will simply use the default. the option should be per-interface, ideally. controlled by ethtool? * there is zero information on how to use poll interval. again, 99% of users will simply use the default. since the poll interval is written directly to a hardware register, you should give the user some idea of the unit of measure (ms? ticks? bus cycles? ns?), and some idea of min/max. From AAbdulla@nvidia.com Mon Oct 24 10:51:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 10:51:26 -0700 (PDT) Received: from HQEMGATE03.nvidia.com (hqemgate03.nvidia.com [216.228.112.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OHpLO0018620 for ; Mon, 24 Oct 2005 10:51:21 -0700 Received: from hqemfe03.nvidia.com (Not Verified[172.16.227.123]) by HQEMGATE03.nvidia.com id ; Mon, 24 Oct 2005 10:47:58 -0700 Received: from [172.16.174.152] ([172.16.228.84]) by hqemfe03.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 10:47:57 -0700 Message-ID: <435D1047.2070401@nvidia.com> Date: Mon, 24 Oct 2005 12:48:07 -0400 From: Ayaz Abdulla User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Garzik CC: Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support References: <432D7354.8000503@colorfullife.com> <43595C42.4080201@pobox.com> In-Reply-To: <43595C42.4080201@pobox.com> Content-Type: multipart/mixed; boundary="------------090709050409090706060900" X-OriginalArrivalTime: 24 Oct 2005 17:47:57.0804 (UTC) FILETIME=[11C172C0:01C5D8C3] X-archive-position: 3773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aabdulla@nvidia.com Precedence: bulk X-list: netdev Content-Length: 17154 Lines: 574 This is a multi-part message in MIME format. --------------090709050409090706060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jeff, I made the changes you requested. Here is the new patch. Thanks, Ayaz Signed-off-By: Ayaz Abdulla --------------090709050409090706060900 Content-Type: text/plain; name="patch-forcedeth-044-sg-segmentation" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forcedeth-044-sg-segmentation" --- orig-2.6/drivers/net/forcedeth.c 2005-10-24 12:40:05.000000000 -0400 +++ new-2.6/drivers/net/forcedeth.c 2005-10-24 12:39:12.000000000 -0400 @@ -96,6 +96,7 @@ * 0.42: 06 Aug 2005: Fix lack of link speed initialization * in the second (and later) nv_open call * 0.43: 10 Aug 2005: Add support for tx checksum. + * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -107,7 +108,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.43" +#define FORCEDETH_VERSION "0.44" #define DRV_NAME "forcedeth" #include @@ -340,6 +341,8 @@ /* error and valid are the same for both */ #define NV_TX2_ERROR (1<<30) #define NV_TX2_VALID (1<<31) +#define NV_TX2_TSO (1<<28) +#define NV_TX2_TSO_SHIFT 14 #define NV_TX2_CHECKSUM_L3 (1<<27) #define NV_TX2_CHECKSUM_L4 (1<<26) @@ -542,7 +545,7 @@ static inline u8 __iomem *get_hwbase(struct net_device *dev) { - return get_nvpriv(dev)->base; + return ((struct fe_priv *)netdev_priv(dev))->base; } static inline void pci_push(u8 __iomem *base) @@ -631,7 +634,7 @@ static int phy_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 miicontrol; unsigned int tries = 0; @@ -734,7 +737,7 @@ static void nv_start_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_start_rx\n", dev->name); @@ -790,7 +793,7 @@ static void nv_txrx_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_txrx_reset\n", dev->name); @@ -809,7 +812,7 @@ */ static struct net_device_stats *nv_get_stats(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); /* It seems that the nic always generates interrupts and doesn't * accumulate errors internally. Thus the current values in np->stats @@ -825,7 +828,7 @@ */ static int nv_alloc_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); unsigned int refill_rx = np->refill_rx; int nr; @@ -869,7 +872,7 @@ static void nv_do_rx_refill(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); disable_irq(dev->irq); if (nv_alloc_rx(dev)) { @@ -883,7 +886,7 @@ static void nv_init_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; np->cur_rx = RX_RING; @@ -897,15 +900,17 @@ static void nv_init_tx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; np->next_tx = np->nic_tx = 0; - for (i = 0; i < TX_RING; i++) + for (i = 0; i < TX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) np->tx_ring.orig[i].FlagLen = 0; else np->tx_ring.ex[i].FlagLen = 0; + np->tx_skbuff[i] = NULL; + } } static int nv_init_ring(struct net_device *dev) @@ -915,21 +920,44 @@ return nv_alloc_rx(dev); } +static void nv_release_txskb(struct net_device *dev, unsigned int skbnr) +{ + struct fe_priv *np = netdev_priv(dev); + struct sk_buff *skb = np->tx_skbuff[skbnr]; + unsigned int j, entry, fragments; + + dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n", + dev->name, skbnr, np->tx_skbuff[skbnr]); + + entry = skbnr; + if ((fragments = skb_shinfo(skb)->nr_frags) != 0) { + for (j = fragments; j >= 1; j--) { + skb_frag_t *frag = &skb_shinfo(skb)->frags[j-1]; + pci_unmap_page(np->pci_dev, np->tx_dma[entry], + frag->size, + PCI_DMA_TODEVICE); + entry = (entry - 1) % TX_RING; + } + } + pci_unmap_single(np->pci_dev, np->tx_dma[entry], + skb->len - skb->data_len, + PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + np->tx_skbuff[skbnr] = NULL; +} + static void nv_drain_tx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); - int i; + struct fe_priv *np = netdev_priv(dev); + unsigned int i; + for (i = 0; i < TX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) np->tx_ring.orig[i].FlagLen = 0; else np->tx_ring.ex[i].FlagLen = 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; + nv_release_txskb(dev, i); np->stats.tx_dropped++; } } @@ -937,7 +965,7 @@ static void nv_drain_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; for (i = 0; i < RX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) @@ -967,29 +995,69 @@ */ 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; - u32 tx_checksum = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0); + struct fe_priv *np = netdev_priv(dev); + u32 tx_flags_extra = (np->desc_ver == DESC_VER_1 ? NV_TX_LASTPACKET : NV_TX2_LASTPACKET); + unsigned int fragments = skb_shinfo(skb)->nr_frags; + unsigned int nr = (np->next_tx + fragments) % TX_RING; + unsigned int i; + + spin_lock_irq(&np->lock); + + if ((np->next_tx - np->nic_tx + fragments) > TX_LIMIT_STOP) { + spin_unlock_irq(&np->lock); + netif_stop_queue(dev); + return NETDEV_TX_BUSY; + } np->tx_skbuff[nr] = skb; - np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len, - PCI_DMA_TODEVICE); + + if (fragments) { + dprintk(KERN_DEBUG "%s: nv_start_xmit: buffer contains %d fragments\n", dev->name, fragments); + /* setup descriptors in reverse order */ + for (i = fragments; i >= 1; i--) { + skb_frag_t *frag = &skb_shinfo(skb)->frags[i-1]; + np->tx_dma[nr] = pci_map_page(np->pci_dev, frag->page, frag->page_offset, frag->size, + PCI_DMA_TODEVICE); - if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) + if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) { + np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); + np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra); + } else { + np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32; + np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF; + np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra); + } + + nr = (nr - 1) % TX_RING; + + if (np->desc_ver == DESC_VER_1) + tx_flags_extra &= ~NV_TX_LASTPACKET; + else + tx_flags_extra &= ~NV_TX2_LASTPACKET; + } + } + +#ifdef NETIF_F_TSO + if (skb_shinfo(skb)->tso_size) + tx_flags_extra |= NV_TX2_TSO | (skb_shinfo(skb)->tso_size << NV_TX2_TSO_SHIFT); + else +#endif + tx_flags_extra |= (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0); + + np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len-skb->data_len, + PCI_DMA_TODEVICE); + + if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) { np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); - else { + np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra); + } else { np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32; np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF; - } + np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra); + } - spin_lock_irq(&np->lock); - wmb(); - if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) - np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum); - else - np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum); - dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission\n", - dev->name, np->next_tx); + dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission. tx_flags_extra: %x\n", + dev->name, np->next_tx, tx_flags_extra); { int j; for (j=0; j<64; j++) { @@ -1000,15 +1068,13 @@ dprintk("\n"); } - np->next_tx++; + np->next_tx += 1 + fragments; 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|np->txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl); pci_push(get_hwbase(dev)); - return 0; + return NETDEV_TX_OK; } /* @@ -1018,9 +1084,10 @@ */ static void nv_tx_done(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 Flags; - int i; + unsigned int i; + struct sk_buff *skb; while (np->nic_tx != np->next_tx) { i = np->nic_tx % TX_RING; @@ -1035,35 +1102,38 @@ if (Flags & NV_TX_VALID) break; if (np->desc_ver == DESC_VER_1) { - if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| - NV_TX_UNDERFLOW|NV_TX_ERROR)) { - if (Flags & NV_TX_UNDERFLOW) - np->stats.tx_fifo_errors++; - if (Flags & 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; + if (Flags & NV_TX_LASTPACKET) { + skb = np->tx_skbuff[i]; + if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| + NV_TX_UNDERFLOW|NV_TX_ERROR)) { + if (Flags & NV_TX_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += skb->len; + } + nv_release_txskb(dev, i); } } else { - if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| - NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { - if (Flags & NV_TX2_UNDERFLOW) - np->stats.tx_fifo_errors++; - if (Flags & NV_TX2_CARRIERLOST) - np->stats.tx_carrier_errors++; - np->stats.tx_errors++; - } else { - np->stats.tx_packets++; - np->stats.tx_bytes += np->tx_skbuff[i]->len; + if (Flags & NV_TX2_LASTPACKET) { + skb = np->tx_skbuff[i]; + if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| + NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { + if (Flags & NV_TX2_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX2_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += skb->len; + } + nv_release_txskb(dev, i); } } - 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) @@ -1076,7 +1146,7 @@ */ static void nv_tx_timeout(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); printk(KERN_INFO "%s: Got tx_timeout. irq: %08x\n", dev->name, @@ -1209,7 +1279,7 @@ static void nv_rx_process(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 Flags; for (;;) { @@ -1364,7 +1434,7 @@ */ static int nv_change_mtu(struct net_device *dev, int new_mtu) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int old_mtu; if (new_mtu < 64 || new_mtu > np->pkt_limit) @@ -1449,7 +1519,7 @@ */ static int nv_set_mac_address(struct net_device *dev, void *addr) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); struct sockaddr *macaddr = (struct sockaddr*)addr; if(!is_valid_ether_addr(macaddr->sa_data)) @@ -1484,7 +1554,7 @@ */ static void nv_set_multicast(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 addr[2]; u32 mask[2]; @@ -1544,7 +1614,7 @@ static int nv_update_linkspeed(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); int adv, lpa; int newls = np->linkspeed; @@ -1714,7 +1784,7 @@ static irqreturn_t nv_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); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 events; int i; @@ -1786,7 +1856,7 @@ static void nv_do_nic_poll(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); disable_irq(dev->irq); @@ -1810,7 +1880,7 @@ static void nv_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); strcpy(info->driver, "forcedeth"); strcpy(info->version, FORCEDETH_VERSION); strcpy(info->bus_info, pci_name(np->pci_dev)); @@ -1818,7 +1888,7 @@ static void nv_get_wol(struct net_device *dev, struct ethtool_wolinfo *wolinfo) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); wolinfo->supported = WAKE_MAGIC; spin_lock_irq(&np->lock); @@ -1829,7 +1899,7 @@ static int nv_set_wol(struct net_device *dev, struct ethtool_wolinfo *wolinfo) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); spin_lock_irq(&np->lock); @@ -2030,7 +2100,7 @@ static void nv_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *buf) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 *rbuf = buf; int i; @@ -2044,7 +2114,7 @@ static int nv_nway_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int ret; spin_lock_irq(&np->lock); @@ -2078,7 +2148,7 @@ static int nv_open(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); int ret, oom, i; @@ -2214,7 +2284,7 @@ static int nv_close(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base; spin_lock_irq(&np->lock); @@ -2270,7 +2340,7 @@ if (!dev) goto out; - np = get_nvpriv(dev); + np = netdev_priv(dev); np->pci_dev = pci_dev; spin_lock_init(&np->lock); SET_MODULE_OWNER(dev); @@ -2322,6 +2392,8 @@ if (pci_set_dma_mask(pci_dev, 0x0000007fffffffffULL)) { printk(KERN_INFO "forcedeth: 64-bit DMA failed, using 32-bit addressing for device %s.\n", pci_name(pci_dev)); + } else { + dev->features |= NETIF_F_HIGHDMA; } np->txrxctl_bits = NVREG_TXRXCTL_DESC_3; } else if (id->driver_data & DEV_HAS_LARGEDESC) { @@ -2340,8 +2412,11 @@ if (id->driver_data & DEV_HAS_CHECKSUM) { np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK; - dev->features |= NETIF_F_HW_CSUM; - } + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG; +#ifdef NETIF_F_TSO + dev->features |= NETIF_F_TSO; +#endif + } err = -ENOMEM; np->base = ioremap(addr, NV_PCI_REGSZ); @@ -2420,9 +2495,9 @@ np->wolenabled = 0; if (np->desc_ver == DESC_VER_1) { - np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID; + np->tx_flags = NV_TX_VALID; } else { - np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID; + np->tx_flags = NV_TX2_VALID; } np->irqmask = NVREG_IRQMASK_WANTED; if (id->driver_data & DEV_NEED_TIMERIRQ) @@ -2511,7 +2586,7 @@ 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); + struct fe_priv *np = netdev_priv(dev); unregister_netdev(dev); --------------090709050409090706060900-- From shemminger@osdl.org Mon Oct 24 11:03:25 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 11:03:31 -0700 (PDT) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OI3PO0020088 for ; Mon, 24 Oct 2005 11:03:25 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j9OI04FC005696 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Oct 2005 11:00:05 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j9OI04Hr002144; Mon, 24 Oct 2005 11:00:04 -0700 Date: Mon, 24 Oct 2005 11:00:03 -0700 From: Stephen Hemminger To: Ayaz Abdulla Cc: Jeff Garzik , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Message-ID: <20051024110003.53e37edd@dxpl.pdx.osdl.net> In-Reply-To: <435D1047.2070401@nvidia.com> References: <432D7354.8000503@colorfullife.com> <43595C42.4080201@pobox.com> <435D1047.2070401@nvidia.com> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.125 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 3774 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: 556 Lines: 27 On Mon, 24 Oct 2005 12:48:07 -0400 Ayaz Abdulla wrote: > Jeff, > > I made the changes you requested. Here is the new patch. > > Thanks, > Ayaz > > Signed-off-By: Ayaz Abdulla > > @@ -542,7 +545,7 @@ > > static inline u8 __iomem *get_hwbase(struct net_device *dev) > { > - return get_nvpriv(dev)->base; > + return ((struct fe_priv *)netdev_priv(dev))->base; > } Indentation? Did you mean to leave the tab there. -- Stephen Hemminger OSDL http://developer.osdl.org/~shemminger From AAbdulla@nvidia.com Mon Oct 24 11:09:03 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 11:09:07 -0700 (PDT) Received: from HQEMGATE03.nvidia.com (hqemgate03.nvidia.com [216.228.112.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OI93O0021145 for ; Mon, 24 Oct 2005 11:09:03 -0700 Received: from hqemfe02.nvidia.com (Not Verified[172.16.227.92]) by HQEMGATE03.nvidia.com id ; Mon, 24 Oct 2005 11:05:38 -0700 Received: from [172.16.174.152] ([172.16.228.84]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 11:05:38 -0700 Message-ID: <435D1464.3010203@nvidia.com> Date: Mon, 24 Oct 2005 13:05:40 -0400 From: Ayaz Abdulla User-Agent: Mozilla Thunderbird 1.0.2-6 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jeff Garzik , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support References: <432D7354.8000503@colorfullife.com> <43595C42.4080201@pobox.com> <435D1047.2070401@nvidia.com> <20051024110003.53e37edd@dxpl.pdx.osdl.net> In-Reply-To: <20051024110003.53e37edd@dxpl.pdx.osdl.net> Content-Type: multipart/mixed; boundary="------------000005010801060101040109" X-OriginalArrivalTime: 24 Oct 2005 18:05:38.0126 (UTC) FILETIME=[89C1BEE0:01C5D8C5] X-archive-position: 3775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: aabdulla@nvidia.com Precedence: bulk X-list: netdev Content-Length: 17082 Lines: 569 This is a multi-part message in MIME format. --------------000005010801060101040109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, forgot that indent. Here it is again with that fix. --------------000005010801060101040109 Content-Type: text/plain; name="patch-forcedeth-044-sg-segmentation" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forcedeth-044-sg-segmentation" --- orig-2.6/drivers/net/forcedeth.c 2005-10-24 12:40:05.000000000 -0400 +++ new-2.6/drivers/net/forcedeth.c 2005-10-24 13:03:30.000000000 -0400 @@ -96,6 +96,7 @@ * 0.42: 06 Aug 2005: Fix lack of link speed initialization * in the second (and later) nv_open call * 0.43: 10 Aug 2005: Add support for tx checksum. + * 0.44: 20 Aug 2005: Add support for scatter gather and segmentation. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. @@ -107,7 +108,7 @@ * DEV_NEED_TIMERIRQ will not harm you on sane hardware, only generating a few * superfluous timer interrupts from the nic. */ -#define FORCEDETH_VERSION "0.43" +#define FORCEDETH_VERSION "0.44" #define DRV_NAME "forcedeth" #include @@ -340,6 +341,8 @@ /* error and valid are the same for both */ #define NV_TX2_ERROR (1<<30) #define NV_TX2_VALID (1<<31) +#define NV_TX2_TSO (1<<28) +#define NV_TX2_TSO_SHIFT 14 #define NV_TX2_CHECKSUM_L3 (1<<27) #define NV_TX2_CHECKSUM_L4 (1<<26) @@ -542,7 +545,7 @@ static inline u8 __iomem *get_hwbase(struct net_device *dev) { - return get_nvpriv(dev)->base; + return ((struct fe_priv *)netdev_priv(dev))->base; } static inline void pci_push(u8 __iomem *base) @@ -631,7 +634,7 @@ static int phy_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 miicontrol; unsigned int tries = 0; @@ -734,7 +737,7 @@ static void nv_start_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_start_rx\n", dev->name); @@ -790,7 +793,7 @@ static void nv_txrx_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); dprintk(KERN_DEBUG "%s: nv_txrx_reset\n", dev->name); @@ -809,7 +812,7 @@ */ static struct net_device_stats *nv_get_stats(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); /* It seems that the nic always generates interrupts and doesn't * accumulate errors internally. Thus the current values in np->stats @@ -825,7 +828,7 @@ */ static int nv_alloc_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); unsigned int refill_rx = np->refill_rx; int nr; @@ -869,7 +872,7 @@ static void nv_do_rx_refill(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); disable_irq(dev->irq); if (nv_alloc_rx(dev)) { @@ -883,7 +886,7 @@ static void nv_init_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; np->cur_rx = RX_RING; @@ -897,15 +900,17 @@ static void nv_init_tx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; np->next_tx = np->nic_tx = 0; - for (i = 0; i < TX_RING; i++) + for (i = 0; i < TX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) np->tx_ring.orig[i].FlagLen = 0; else np->tx_ring.ex[i].FlagLen = 0; + np->tx_skbuff[i] = NULL; + } } static int nv_init_ring(struct net_device *dev) @@ -915,21 +920,44 @@ return nv_alloc_rx(dev); } +static void nv_release_txskb(struct net_device *dev, unsigned int skbnr) +{ + struct fe_priv *np = netdev_priv(dev); + struct sk_buff *skb = np->tx_skbuff[skbnr]; + unsigned int j, entry, fragments; + + dprintk(KERN_INFO "%s: nv_release_txskb for skbnr %d, skb %p\n", + dev->name, skbnr, np->tx_skbuff[skbnr]); + + entry = skbnr; + if ((fragments = skb_shinfo(skb)->nr_frags) != 0) { + for (j = fragments; j >= 1; j--) { + skb_frag_t *frag = &skb_shinfo(skb)->frags[j-1]; + pci_unmap_page(np->pci_dev, np->tx_dma[entry], + frag->size, + PCI_DMA_TODEVICE); + entry = (entry - 1) % TX_RING; + } + } + pci_unmap_single(np->pci_dev, np->tx_dma[entry], + skb->len - skb->data_len, + PCI_DMA_TODEVICE); + dev_kfree_skb_irq(skb); + np->tx_skbuff[skbnr] = NULL; +} + static void nv_drain_tx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); - int i; + struct fe_priv *np = netdev_priv(dev); + unsigned int i; + for (i = 0; i < TX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) np->tx_ring.orig[i].FlagLen = 0; else np->tx_ring.ex[i].FlagLen = 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; + nv_release_txskb(dev, i); np->stats.tx_dropped++; } } @@ -937,7 +965,7 @@ static void nv_drain_rx(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int i; for (i = 0; i < RX_RING; i++) { if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) @@ -967,29 +995,69 @@ */ 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; - u32 tx_checksum = (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0); + struct fe_priv *np = netdev_priv(dev); + u32 tx_flags_extra = (np->desc_ver == DESC_VER_1 ? NV_TX_LASTPACKET : NV_TX2_LASTPACKET); + unsigned int fragments = skb_shinfo(skb)->nr_frags; + unsigned int nr = (np->next_tx + fragments) % TX_RING; + unsigned int i; + + spin_lock_irq(&np->lock); + + if ((np->next_tx - np->nic_tx + fragments) > TX_LIMIT_STOP) { + spin_unlock_irq(&np->lock); + netif_stop_queue(dev); + return NETDEV_TX_BUSY; + } np->tx_skbuff[nr] = skb; - np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data,skb->len, - PCI_DMA_TODEVICE); + + if (fragments) { + dprintk(KERN_DEBUG "%s: nv_start_xmit: buffer contains %d fragments\n", dev->name, fragments); + /* setup descriptors in reverse order */ + for (i = fragments; i >= 1; i--) { + skb_frag_t *frag = &skb_shinfo(skb)->frags[i-1]; + np->tx_dma[nr] = pci_map_page(np->pci_dev, frag->page, frag->page_offset, frag->size, + PCI_DMA_TODEVICE); - if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) + if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) { + np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); + np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra); + } else { + np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32; + np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF; + np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (frag->size-1) | np->tx_flags | tx_flags_extra); + } + + nr = (nr - 1) % TX_RING; + + if (np->desc_ver == DESC_VER_1) + tx_flags_extra &= ~NV_TX_LASTPACKET; + else + tx_flags_extra &= ~NV_TX2_LASTPACKET; + } + } + +#ifdef NETIF_F_TSO + if (skb_shinfo(skb)->tso_size) + tx_flags_extra |= NV_TX2_TSO | (skb_shinfo(skb)->tso_size << NV_TX2_TSO_SHIFT); + else +#endif + tx_flags_extra |= (skb->ip_summed == CHECKSUM_HW ? (NV_TX2_CHECKSUM_L3|NV_TX2_CHECKSUM_L4) : 0); + + np->tx_dma[nr] = pci_map_single(np->pci_dev, skb->data, skb->len-skb->data_len, + PCI_DMA_TODEVICE); + + if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) { np->tx_ring.orig[nr].PacketBuffer = cpu_to_le32(np->tx_dma[nr]); - else { + np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra); + } else { np->tx_ring.ex[nr].PacketBufferHigh = cpu_to_le64(np->tx_dma[nr]) >> 32; np->tx_ring.ex[nr].PacketBufferLow = cpu_to_le64(np->tx_dma[nr]) & 0x0FFFFFFFF; - } + np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-skb->data_len-1) | np->tx_flags | tx_flags_extra); + } - spin_lock_irq(&np->lock); - wmb(); - if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) - np->tx_ring.orig[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum); - else - np->tx_ring.ex[nr].FlagLen = cpu_to_le32( (skb->len-1) | np->tx_flags | tx_checksum); - dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission\n", - dev->name, np->next_tx); + dprintk(KERN_DEBUG "%s: nv_start_xmit: packet packet %d queued for transmission. tx_flags_extra: %x\n", + dev->name, np->next_tx, tx_flags_extra); { int j; for (j=0; j<64; j++) { @@ -1000,15 +1068,13 @@ dprintk("\n"); } - np->next_tx++; + np->next_tx += 1 + fragments; 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|np->txrxctl_bits, get_hwbase(dev) + NvRegTxRxControl); pci_push(get_hwbase(dev)); - return 0; + return NETDEV_TX_OK; } /* @@ -1018,9 +1084,10 @@ */ static void nv_tx_done(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 Flags; - int i; + unsigned int i; + struct sk_buff *skb; while (np->nic_tx != np->next_tx) { i = np->nic_tx % TX_RING; @@ -1035,35 +1102,38 @@ if (Flags & NV_TX_VALID) break; if (np->desc_ver == DESC_VER_1) { - if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| - NV_TX_UNDERFLOW|NV_TX_ERROR)) { - if (Flags & NV_TX_UNDERFLOW) - np->stats.tx_fifo_errors++; - if (Flags & 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; + if (Flags & NV_TX_LASTPACKET) { + skb = np->tx_skbuff[i]; + if (Flags & (NV_TX_RETRYERROR|NV_TX_CARRIERLOST|NV_TX_LATECOLLISION| + NV_TX_UNDERFLOW|NV_TX_ERROR)) { + if (Flags & NV_TX_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += skb->len; + } + nv_release_txskb(dev, i); } } else { - if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| - NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { - if (Flags & NV_TX2_UNDERFLOW) - np->stats.tx_fifo_errors++; - if (Flags & NV_TX2_CARRIERLOST) - np->stats.tx_carrier_errors++; - np->stats.tx_errors++; - } else { - np->stats.tx_packets++; - np->stats.tx_bytes += np->tx_skbuff[i]->len; + if (Flags & NV_TX2_LASTPACKET) { + skb = np->tx_skbuff[i]; + if (Flags & (NV_TX2_RETRYERROR|NV_TX2_CARRIERLOST|NV_TX2_LATECOLLISION| + NV_TX2_UNDERFLOW|NV_TX2_ERROR)) { + if (Flags & NV_TX2_UNDERFLOW) + np->stats.tx_fifo_errors++; + if (Flags & NV_TX2_CARRIERLOST) + np->stats.tx_carrier_errors++; + np->stats.tx_errors++; + } else { + np->stats.tx_packets++; + np->stats.tx_bytes += skb->len; + } + nv_release_txskb(dev, i); } } - 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) @@ -1076,7 +1146,7 @@ */ static void nv_tx_timeout(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); printk(KERN_INFO "%s: Got tx_timeout. irq: %08x\n", dev->name, @@ -1209,7 +1279,7 @@ static void nv_rx_process(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u32 Flags; for (;;) { @@ -1364,7 +1434,7 @@ */ static int nv_change_mtu(struct net_device *dev, int new_mtu) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int old_mtu; if (new_mtu < 64 || new_mtu > np->pkt_limit) @@ -1449,7 +1519,7 @@ */ static int nv_set_mac_address(struct net_device *dev, void *addr) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); struct sockaddr *macaddr = (struct sockaddr*)addr; if(!is_valid_ether_addr(macaddr->sa_data)) @@ -1484,7 +1554,7 @@ */ static void nv_set_multicast(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 addr[2]; u32 mask[2]; @@ -1544,7 +1614,7 @@ static int nv_update_linkspeed(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); int adv, lpa; int newls = np->linkspeed; @@ -1714,7 +1784,7 @@ static irqreturn_t nv_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); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 events; int i; @@ -1786,7 +1856,7 @@ static void nv_do_nic_poll(unsigned long data) { struct net_device *dev = (struct net_device *) data; - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); disable_irq(dev->irq); @@ -1810,7 +1880,7 @@ static void nv_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); strcpy(info->driver, "forcedeth"); strcpy(info->version, FORCEDETH_VERSION); strcpy(info->bus_info, pci_name(np->pci_dev)); @@ -1818,7 +1888,7 @@ static void nv_get_wol(struct net_device *dev, struct ethtool_wolinfo *wolinfo) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); wolinfo->supported = WAKE_MAGIC; spin_lock_irq(&np->lock); @@ -1829,7 +1899,7 @@ static int nv_set_wol(struct net_device *dev, struct ethtool_wolinfo *wolinfo) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); spin_lock_irq(&np->lock); @@ -2030,7 +2100,7 @@ static void nv_get_regs(struct net_device *dev, struct ethtool_regs *regs, void *buf) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); u32 *rbuf = buf; int i; @@ -2044,7 +2114,7 @@ static int nv_nway_reset(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); int ret; spin_lock_irq(&np->lock); @@ -2078,7 +2148,7 @@ static int nv_open(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base = get_hwbase(dev); int ret, oom, i; @@ -2214,7 +2284,7 @@ static int nv_close(struct net_device *dev) { - struct fe_priv *np = get_nvpriv(dev); + struct fe_priv *np = netdev_priv(dev); u8 __iomem *base; spin_lock_irq(&np->lock); @@ -2270,7 +2340,7 @@ if (!dev) goto out; - np = get_nvpriv(dev); + np = netdev_priv(dev); np->pci_dev = pci_dev; spin_lock_init(&np->lock); SET_MODULE_OWNER(dev); @@ -2322,6 +2392,8 @@ if (pci_set_dma_mask(pci_dev, 0x0000007fffffffffULL)) { printk(KERN_INFO "forcedeth: 64-bit DMA failed, using 32-bit addressing for device %s.\n", pci_name(pci_dev)); + } else { + dev->features |= NETIF_F_HIGHDMA; } np->txrxctl_bits = NVREG_TXRXCTL_DESC_3; } else if (id->driver_data & DEV_HAS_LARGEDESC) { @@ -2340,8 +2412,11 @@ if (id->driver_data & DEV_HAS_CHECKSUM) { np->txrxctl_bits |= NVREG_TXRXCTL_RXCHECK; - dev->features |= NETIF_F_HW_CSUM; - } + dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG; +#ifdef NETIF_F_TSO + dev->features |= NETIF_F_TSO; +#endif + } err = -ENOMEM; np->base = ioremap(addr, NV_PCI_REGSZ); @@ -2420,9 +2495,9 @@ np->wolenabled = 0; if (np->desc_ver == DESC_VER_1) { - np->tx_flags = NV_TX_LASTPACKET|NV_TX_VALID; + np->tx_flags = NV_TX_VALID; } else { - np->tx_flags = NV_TX2_LASTPACKET|NV_TX2_VALID; + np->tx_flags = NV_TX2_VALID; } np->irqmask = NVREG_IRQMASK_WANTED; if (id->driver_data & DEV_NEED_TIMERIRQ) @@ -2511,7 +2586,7 @@ 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); + struct fe_priv *np = netdev_priv(dev); unregister_netdev(dev); --------------000005010801060101040109-- From shemminger@osdl.org Mon Oct 24 14:25:14 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 14:25:19 -0700 (PDT) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OLP8O0003813 for ; Mon, 24 Oct 2005 14:25:12 -0700 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id j9OLLTFC017146 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 24 Oct 2005 14:21:30 -0700 Received: from dxpl.pdx.osdl.net (dxpl.pdx.osdl.net [10.8.0.74]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with ESMTP id j9OLLSIr012221; Mon, 24 Oct 2005 14:21:29 -0700 Date: Mon, 24 Oct 2005 14:21:28 -0700 From: Stephen Hemminger To: Ayaz Abdulla Cc: Jeff Garzik , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Message-ID: <20051024142128.3193bc22@dxpl.pdx.osdl.net> In-Reply-To: <435D1047.2070401@nvidia.com> References: <432D7354.8000503@colorfullife.com> <43595C42.4080201@pobox.com> <435D1047.2070401@nvidia.com> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.127 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 3776 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: 652 Lines: 27 On Mon, 24 Oct 2005 12:48:07 -0400 Ayaz Abdulla wrote: > Jeff, > > I made the changes you requested. Here is the new patch. > > Thanks, > Ayaz > > Signed-off-By: Ayaz Abdulla > There are really three patches in here. 1. Use netdev_priv (trivial) 2. scatter/gather support 3. TSO support Why do you set the fragments up in reverse order? Going backwards is usually slow on most code. The kernel coding style is to use lower case in local variable names (Flags) and structure elements (PacketBuffer, FlagLen). -- Stephen Hemminger OSDL http://developer.osdl.org/~shemminger From daniele@orlandi.com Mon Oct 24 14:36:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 14:36:18 -0700 (PDT) Received: from relay2.uli.it (relay2.uli.it [62.212.1.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OLaEO0004985 for ; Mon, 24 Oct 2005 14:36:15 -0700 Received: from nabla.orlandi.com (nabla.orlandi.com [62.212.12.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by sid.uli.it (Postfix) with ESMTP id 1D4352B8973; Mon, 24 Oct 2005 23:33:06 +0200 (CEST) From: Daniele Orlandi To: netdev@vger.kernel.org Subject: Re: Request for an ARPHRD_ Date: Mon, 24 Oct 2005 23:33:04 +0200 User-Agent: KMail/1.8 References: <200510240255.28416.daniele@orlandi.com> <200510241807.23290.ak@suse.de> In-Reply-To: <200510241807.23290.ak@suse.de> Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510242333.05366.daniele@orlandi.com> X-archive-position: 3777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniele@orlandi.com Precedence: bulk X-list: netdev Content-Length: 1041 Lines: 31 On Monday 24 October 2005 18:07, Andi Kleen wrote: > > ETH_P_* is managed by the IEEE (part of the ethernet standard) You would > need to ask them. I need a pseudo protocol like it is already done for some internal protocol, e.g.: /* * Non DIX types. Won't clash for 1500 types. */ [.....] #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP 0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type */ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ [....] > Normally Linux doesn't pre-allocate ABIs for out of tree code, mostly > because it is not guaranteed that the interface won't change there. Could you clarify? What interface do you fear that could change? My main concern is that without an ARPHRD_ constant guaranteed to be unique I wouldn't be able to propose a patch for libpcap people to map the (already allocated) DLT_ to the correct ARPHRD_. Bye, -- Daniele Orlandi From buytenh@wantstofly.org Mon Oct 24 14:54:52 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 14:54:55 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [83.160.184.112]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OLspO0006504 for ; Mon, 24 Oct 2005 14:54:52 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id AEFDC945FE; Mon, 24 Oct 2005 23:51:40 +0200 (MEST) Date: Mon, 24 Oct 2005 23:51:40 +0200 From: Lennert Buytenhek To: Daniele Orlandi Cc: netdev@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Request for an ARPHRD_ Message-ID: <20051024215140.GA10872@xi.wantstofly.org> References: <200510240255.28416.daniele@orlandi.com> <200510241807.23290.ak@suse.de> <200510242333.05366.daniele@orlandi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510242333.05366.daniele@orlandi.com> User-Agent: Mutt/1.4.1i X-archive-position: 3778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 341 Lines: 10 On Mon, Oct 24, 2005 at 11:33:04PM +0200, Daniele Orlandi wrote: > My main concern is that without an ARPHRD_ constant guaranteed to be > unique I wouldn't be able to propose a patch for libpcap people to map > the (already allocated) DLT_ to the correct ARPHRD_. First get your code in the kernel, then submit the patch to libpcap. --L From daniele@orlandi.com Mon Oct 24 15:11:20 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 15:11:22 -0700 (PDT) Received: from relay2.uli.it (relay2.uli.it [62.212.1.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OMBJO0008074 for ; Mon, 24 Oct 2005 15:11:19 -0700 Received: from nabla.orlandi.com (nabla.orlandi.com [62.212.12.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by sid.uli.it (Postfix) with ESMTP id E72482B8371; Tue, 25 Oct 2005 00:08:10 +0200 (CEST) From: Daniele Orlandi To: netdev@vger.kernel.org Subject: Re: Request for an ARPHRD_ Date: Tue, 25 Oct 2005 00:08:09 +0200 User-Agent: KMail/1.8 References: <200510240255.28416.daniele@orlandi.com> <200510242333.05366.daniele@orlandi.com> <20051024215140.GA10872@xi.wantstofly.org> In-Reply-To: <20051024215140.GA10872@xi.wantstofly.org> 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: <200510250008.10409.daniele@orlandi.com> X-archive-position: 3779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniele@orlandi.com Precedence: bulk X-list: netdev Content-Length: 499 Lines: 17 On Monday 24 October 2005 23:51, Lennert Buytenhek wrote: > > First get your code in the kernel, then submit the patch to libpcap. Hopefully I will but currently vISDN is not mature enough to be evaluated for kernel inclusion. I would like to keep it out of the tree while it matures, however I would also like to avoid potential constants clashes with outher/future code. You may see the constants allocation as the first step to include that code in the kernel. Bye, -- Daniele Orlandi From buytenh@wantstofly.org Mon Oct 24 15:25:32 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 15:25:35 -0700 (PDT) Received: from xi.wantstofly.org (alephnull.demon.nl [83.160.184.112]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OMPVO0009294 for ; Mon, 24 Oct 2005 15:25:32 -0700 Received: by xi.wantstofly.org (Postfix, from userid 500) id 3100F945FE; Tue, 25 Oct 2005 00:22:23 +0200 (MEST) Date: Tue, 25 Oct 2005 00:22:23 +0200 From: Lennert Buytenhek To: Daniele Orlandi Cc: netdev@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Request for an ARPHRD_ Message-ID: <20051024222222.GA11005@xi.wantstofly.org> References: <200510240255.28416.daniele@orlandi.com> <200510242333.05366.daniele@orlandi.com> <20051024215140.GA10872@xi.wantstofly.org> <200510250008.10409.daniele@orlandi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200510250008.10409.daniele@orlandi.com> User-Agent: Mutt/1.4.1i X-archive-position: 3780 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: buytenh@wantstofly.org Precedence: bulk X-list: netdev Content-Length: 737 Lines: 22 On Tue, Oct 25, 2005 at 12:08:09AM +0200, Daniele Orlandi wrote: > > First get your code in the kernel, then submit the patch to libpcap. > > Hopefully I will but currently vISDN is not mature enough to be > evaluated for kernel inclusion. > > I would like to keep it out of the tree while it matures, however I > would also like to avoid potential constants clashes with outher/future > code. > > You may see the constants allocation as the first step to include that > code in the kernel. Your code might never end up in the kernel at all, for example if you ever lose interest in it. The situation that we'd like to avoid is ending up with reserved constants for code that was never submitted upstream at all. cheers, Lennert From ak@suse.de Mon Oct 24 15:27:22 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 15:27:24 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9OMRLO0009567 for ; Mon, 24 Oct 2005 15:27:21 -0700 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 504DC1CBE8; Tue, 25 Oct 2005 00:24:12 +0200 (CEST) From: Andi Kleen To: Daniele Orlandi Subject: Re: Request for an ARPHRD_ Date: Tue, 25 Oct 2005 00:24:55 +0200 User-Agent: KMail/1.8.2 Cc: netdev@vger.kernel.org, netdev@oss.sgi.com References: <200510240255.28416.daniele@orlandi.com> <200510241807.23290.ak@suse.de> <200510242333.05366.daniele@orlandi.com> In-Reply-To: <200510242333.05366.daniele@orlandi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510250024.56088.ak@suse.de> X-archive-position: 3781 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: 385 Lines: 12 On Monday 24 October 2005 23:33, Daniele Orlandi wrote: > > > Normally Linux doesn't pre-allocate ABIs for out of tree code, mostly > > because it is not guaranteed that the interface won't change there. > > Could you clarify? What interface do you fear that could change? Any interface implemented by your out of tree code for which you're requesting to reserve constants. -Andi From daniele@orlandi.com Mon Oct 24 16:01:33 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 24 Oct 2005 16:01:38 -0700 (PDT) Received: from relay2.uli.it (relay2.uli.it [62.212.1.5]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9ON1XO0012294 for ; Mon, 24 Oct 2005 16:01:33 -0700 Received: from nabla.orlandi.com (nabla.orlandi.com [62.212.12.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by sid.uli.it (Postfix) with ESMTP id EB4BF2B8973; Tue, 25 Oct 2005 00:58:24 +0200 (CEST) From: Daniele Orlandi To: netdev@vger.kernel.org Subject: Re: Request for an ARPHRD_ Date: Tue, 25 Oct 2005 00:58:23 +0200 User-Agent: KMail/1.8 References: <200510240255.28416.daniele@orlandi.com> <200510250008.10409.daniele@orlandi.com> <20051024222222.GA11005@xi.wantstofly.org> In-Reply-To: <20051024222222.GA11005@xi.wantstofly.org> 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: <200510250058.24561.daniele@orlandi.com> X-archive-position: 3782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniele@orlandi.com Precedence: bulk X-list: netdev Content-Length: 551 Lines: 19 On Tuesday 25 October 2005 00:22, Lennert Buytenhek wrote: > > Your code might never end up in the kernel at all, for example if you > ever lose interest in it. The situation that we'd like to avoid is > ending up with reserved constants for code that was never submitted > upstream at all. Okay, I see your point. IMHO I'd have preferred a more open politic like libpcap's. There may be valid reasons to keep code out of the tree and this makes maintenance even harder to perform than it already is. Thanks anyway, Bye, -- Daniele Orlandi From jmorris@namei.org Tue Oct 25 09:51:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 09:51:25 -0700 (PDT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PGpLO0011094 for ; Tue, 25 Oct 2005 09:51:21 -0700 Received: (qmail 11412 invoked from network); 25 Oct 2005 16:48:12 -0000 Received: from megaweapon.nightmoose.net (HELO excalibur.intercode) ([66.92.66.197]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 25 Oct 2005 16:48:12 -0000 Date: Tue, 25 Oct 2005 12:48:14 -0400 (EDT) From: James Morris X-X-Sender: jmorris@excalibur.intercode To: =?iso-2022-jp?Q?YOSHIFUJI_Hideaki_=2F_=B5=C8=C6=A3=B1=D1=CC=C0?= cc: netdev@oss.sgi.com Subject: [PATCH/RFC] Remove spurious sk_filter() call from IPv6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 3783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@namei.org Precedence: bulk X-list: netdev Content-Length: 1094 Lines: 34 It seems that the IPv6 input path has an extra call to sk_filter(). First, the correct call to sk_filter() in tcp_v6_rcv(), matching the IPv4 code. Then, again in tcp_v6_do_rcv(), which often results in a somewhat already processed skb being passed to sk_filter(). As far as I can tell, we should remove this second call, as it is both incorrect and uncecessary. Please review and apply if ok. Signed-off-by: James Morris --- net/ipv6/tcp_ipv6.c | 3 --- 1 files changed, 3 deletions(-) diff -purN -X dontdiff linux-2.6.14-rc5.o/net/ipv6/tcp_ipv6.c linux-2.6.14-rc5.ipv6/net/ipv6/tcp_ipv6.c --- linux-2.6.14-rc5.o/net/ipv6/tcp_ipv6.c 2005-10-21 00:43:33.000000000 -0400 +++ linux-2.6.14-rc5.ipv6/net/ipv6/tcp_ipv6.c 2005-10-25 12:44:23.000000000 -0400 @@ -1451,9 +1451,6 @@ static int tcp_v6_do_rcv(struct sock *sk if (skb->protocol == htons(ETH_P_IP)) return tcp_v4_do_rcv(sk, skb); - if (sk_filter(sk, skb, 0)) - goto discard; - /* * socket locking is here for SMP purposes as backlog rcv * is currently called with bh processing disabled. From AAbdulla@nvidia.com Tue Oct 25 14:19:21 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 14:19:24 -0700 (PDT) Received: from HQEMGATE01.nvidia.com (hqemgate01.nvidia.com [216.228.112.170]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PLJKO0032384 for ; Tue, 25 Oct 2005 14:19:21 -0700 Received: from hqemfe02.nvidia.com (Not Verified[172.16.227.92]) by HQEMGATE01.nvidia.com id ; Tue, 25 Oct 2005 14:15:51 -0700 Received: from hqemmail02.nvidia.com ([172.16.227.143]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 14:15:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Date: Tue, 25 Oct 2005 14:15:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Thread-Index: AcXY4PgDe93ldMxvT9elKfrFyQFxzgAx+gMw From: "Ayaz Abdulla" To: "Stephen Hemminger" Cc: "Jeff Garzik" , "Manfred Spraul" , "Netdev" X-OriginalArrivalTime: 25 Oct 2005 21:15:49.0729 (UTC) FILETIME=[4603ED10:01C5D9A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j9PLJKO0032384 X-archive-position: 3784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AAbdulla@nvidia.com Precedence: bulk X-list: netdev Content-Length: 1143 Lines: 44 We give the fragments in that order to ensure they are all setup before hardware starts looking at them. I can fix up the coding style issue in another patch. That has been there since day 1 and is not related to this patch. -----Original Message----- From: Stephen Hemminger [mailto:shemminger@osdl.org] Sent: Monday, October 24, 2005 2:21 PM To: Ayaz Abdulla Cc: Jeff Garzik; Manfred Spraul; Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support On Mon, 24 Oct 2005 12:48:07 -0400 Ayaz Abdulla wrote: > Jeff, > > I made the changes you requested. Here is the new patch. > > Thanks, > Ayaz > > Signed-off-By: Ayaz Abdulla > There are really three patches in here. 1. Use netdev_priv (trivial) 2. scatter/gather support 3. TSO support Why do you set the fragments up in reverse order? Going backwards is usually slow on most code. The kernel coding style is to use lower case in local variable names (Flags) and structure elements (PacketBuffer, FlagLen). -- Stephen Hemminger OSDL http://developer.osdl.org/~shemminger From romieu@fr.zoreil.com Tue Oct 25 15:06:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 15:06:57 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PM6oO0003606 for ; Tue, 25 Oct 2005 15:06:53 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.4/8.12.1) with ESMTP id j9PLxZTg020587; Tue, 25 Oct 2005 23:59:35 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.4/8.12.1) id j9PLxXsB020586; Tue, 25 Oct 2005 23:59:33 +0200 Date: Tue, 25 Oct 2005 23:59:33 +0200 From: Francois Romieu To: Ayaz Abdulla Cc: Stephen Hemminger , Jeff Garzik , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Message-ID: <20051025215932.GA17794@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 3785 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: 352 Lines: 12 Ayaz Abdulla : > We give the fragments in that order to ensure they are all setup before > hardware starts looking at them. If you are curious of different ways to do it, you can look at: - drivers/net/r8169.c::rtl8169_start_xmit - drivers/net/skge.c::skge_xmit_frame drivers/net/bnx2.c::bnx2_start_xmit seems bogus. -- Ueimor From mchan@broadcom.com Tue Oct 25 15:16:59 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 15:17:02 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PMGxO0004641 for ; Tue, 25 Oct 2005 15:16:59 -0700 Received: from 10.10.64.121 by mms1.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 25 Oct 2005 15:13:37 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 25 Oct 2005 15:13:35 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CBU08706; Tue, 25 Oct 2005 15:13:36 -0700 (PDT) Received: from nt-irva-0740.brcm.ad.broadcom.com (nt-irva-0740 [10.8.194.53]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id PAA10384; Tue, 25 Oct 2005 15:13:35 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com ([10.8.194.65]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 15:13:35 -0700 Received: from 10.7.17.23 ([10.7.17.23]) by NT-IRVA-0751.brcm.ad.broadcom.com ([10.8.194.65]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Oct 2005 22:13:35 +0000 Received: from rh4 by nt-irva-0751; 25 Oct 2005 13:30:03 -0700 Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support From: "Michael Chan" To: "Francois Romieu" cc: "Ayaz Abdulla" , "Stephen Hemminger" , "Jeff Garzik" , "Manfred Spraul" , "Netdev" In-Reply-To: <20051025215932.GA17794@electric-eye.fr.zoreil.com> References: <20051025215932.GA17794@electric-eye.fr.zoreil.com> Date: Tue, 25 Oct 2005 13:30:03 -0700 Message-ID: <1130272203.6236.2.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 25 Oct 2005 22:13:35.0735 (UTC) FILETIME=[57EA7870:01C5D9B1] X-WSS-ID: 6F40719B37W1519627-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 3786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 160 Lines: 7 On Tue, 2005-10-25 at 23:59 +0200, Francois Romieu wrote: > > drivers/net/bnx2.c::bnx2_start_xmit seems bogus. > Please explain what did you mean by bogus? From romieu@fr.zoreil.com Tue Oct 25 16:26:54 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 16:27:00 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PNQqO0014271 for ; Tue, 25 Oct 2005 16:26:53 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.13.4/8.12.1) with ESMTP id j9PNMoHN022125; Wed, 26 Oct 2005 01:22:50 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.13.4/8.12.1) id j9PNMnvw022124; Wed, 26 Oct 2005 01:22:49 +0200 Date: Wed, 26 Oct 2005 01:22:48 +0200 From: Francois Romieu To: Michael Chan Cc: Ayaz Abdulla , Stephen Hemminger , Jeff Garzik , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Message-ID: <20051025232248.GB17794@electric-eye.fr.zoreil.com> References: <20051025215932.GA17794@electric-eye.fr.zoreil.com> <1130272203.6236.2.camel@rh4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1130272203.6236.2.camel@rh4> User-Agent: Mutt/1.4.2.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 3787 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: 490 Lines: 16 Michael Chan : > On Tue, 2005-10-25 at 23:59 +0200, Francois Romieu wrote: > > > > > drivers/net/bnx2.c::bnx2_start_xmit seems bogus. > > > Please explain what did you mean by bogus? When the CPU sets the entries of a multi-descriptor packet, the first descriptor is marked read while the next ones are still unset. If any of BNX2_L2CTX_TX_HOST_{BIDX/BSEQ} prevents the asic to read beyond 'prod' (or b(yte)seq ?), the ordering does not matter. Right ? -- Ueimor From mchan@broadcom.com Tue Oct 25 16:52:15 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 16:52:18 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9PNqEO0017457 for ; Tue, 25 Oct 2005 16:52:15 -0700 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 25 Oct 2005 16:48:53 -0700 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 25 Oct 2005 16:48:51 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CBV00100; Tue, 25 Oct 2005 16:48:51 -0700 (PDT) Received: from nt-irva-0741.brcm.ad.broadcom.com (nt-irva-0741 [10.8.194.54]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA05754; Tue, 25 Oct 2005 16:48:51 -0700 (PDT) Received: from NT-IRVA-0751.brcm.ad.broadcom.com ([10.8.194.65]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 16:48:51 -0700 Received: from 10.7.17.23 ([10.7.17.23]) by NT-IRVA-0751.brcm.ad.broadcom.com ([10.8.194.65]) with Microsoft Exchange Server HTTP-DAV ; Tue, 25 Oct 2005 23:48:50 +0000 Received: from rh4 by nt-irva-0751; 25 Oct 2005 15:05:19 -0700 Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support From: "Michael Chan" To: "Francois Romieu" cc: "Ayaz Abdulla" , "Stephen Hemminger" , "Jeff Garzik" , "Manfred Spraul" , "Netdev" In-Reply-To: <20051025232248.GB17794@electric-eye.fr.zoreil.com> References: <20051025215932.GA17794@electric-eye.fr.zoreil.com> <1130272203.6236.2.camel@rh4> <20051025232248.GB17794@electric-eye.fr.zoreil.com> Date: Tue, 25 Oct 2005 15:05:19 -0700 Message-ID: <1130277919.6236.7.camel@rh4> MIME-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-OriginalArrivalTime: 25 Oct 2005 23:48:51.0346 (UTC) FILETIME=[A6AF7F20:01C5D9BE] X-WSS-ID: 6F401BEF3801387138-01-01 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 3788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mchan@broadcom.com Precedence: bulk X-list: netdev Content-Length: 702 Lines: 19 On Wed, 2005-10-26 at 01:22 +0200, Francois Romieu wrote: > Michael Chan : > > Please explain what did you mean by bogus? > > When the CPU sets the entries of a multi-descriptor packet, the first > descriptor is marked read while the next ones are still unset. > Not sure you you meant by "marked read", but none of the new tx descriptors will be DMA'ed by the chip until we write the producer index and the byte seq. number. > If any of BNX2_L2CTX_TX_HOST_{BIDX/BSEQ} prevents the asic to read > beyond 'prod' (or b(yte)seq ?), the ordering does not matter. Right ? > Right, the chip will only DMA the tx descriptors up to the (prod - 1) index. tg3 works in a similar way. From jgarzik@pobox.com Tue Oct 25 21:56:40 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 21:56:57 -0700 (PDT) Received: from mail.dvmed.net ([216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9Q4uaO0009615 for ; Tue, 25 Oct 2005 21:56:40 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EUdHk-0002hO-5O; Wed, 26 Oct 2005 04:53:13 +0000 Message-ID: <435F0BB5.1070802@pobox.com> Date: Wed, 26 Oct 2005 00:53:09 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ayaz Abdulla CC: Stephen Hemminger , Manfred Spraul , Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support References: <432D7354.8000503@colorfullife.com> <43595C42.4080201@pobox.com> <435D1047.2070401@nvidia.com> <20051024110003.53e37edd@dxpl.pdx.osdl.net> <435D1464.3010203@nvidia.com> In-Reply-To: <435D1464.3010203@nvidia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3789 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: 460 Lines: 19 Ayaz Abdulla wrote: > Yes, forgot that indent. > > Here it is again with that fix. I applied this version of the patch to the 'upstream' patch. In the future, as Stephen noted, it would really be preferred that you split up the patch into logical changes. patch 1/2 netdev_priv(), patch 2/2 SG support, for example. Also, always include the Signed-off-by line, even on patch resends. See http://linux.yyz.us/patch-format.html for more info. Jeff From AAbdulla@nvidia.com Tue Oct 25 23:20:43 2005 Received: with ECARTIS (v1.0.0; list netdev); Tue, 25 Oct 2005 23:20:49 -0700 (PDT) Received: from HQEMGATE01.nvidia.com (hqemgate01.nvidia.com [216.228.112.170]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9Q6KhO0014836 for ; Tue, 25 Oct 2005 23:20:43 -0700 Received: from hqemfe02.nvidia.com (Not Verified[172.16.227.92]) by HQEMGATE01.nvidia.com id ; Tue, 25 Oct 2005 23:17:15 -0700 Received: from hqemmail02.nvidia.com ([172.16.227.143]) by hqemfe02.nvidia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 23:17:14 -0700 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Date: Tue, 25 Oct 2005 23:17:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Thread-Index: AcXZ6SxwlyqecDmdS+am168xL9fcbQAC0YhQ From: "Ayaz Abdulla" To: "Jeff Garzik" Cc: "Stephen Hemminger" , "Manfred Spraul" , "Netdev" X-OriginalArrivalTime: 26 Oct 2005 06:17:14.0147 (UTC) FILETIME=[E83CBF30:01C5D9F4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id j9Q6KhO0014836 X-archive-position: 3790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: AAbdulla@nvidia.com Precedence: bulk X-list: netdev Content-Length: 899 Lines: 37 Thanks. I will resend version 45 (bug fix) and 46 (irq modes) since they will need new modifications based on the changes made in this patch and the comments you suggested. -----Original Message----- From: Jeff Garzik [mailto:jgarzik@pobox.com] Sent: Tuesday, October 25, 2005 9:53 PM To: Ayaz Abdulla Cc: Stephen Hemminger; Manfred Spraul; Netdev Subject: Re: [PATCH 2/2] forcedeth: scatter gather and segmentation offload support Ayaz Abdulla wrote: > Yes, forgot that indent. > > Here it is again with that fix. I applied this version of the patch to the 'upstream' patch. In the future, as Stephen noted, it would really be preferred that you split up the patch into logical changes. patch 1/2 netdev_priv(), patch 2/2 SG support, for example. Also, always include the Signed-off-by line, even on patch resends. See http://linux.yyz.us/patch-format.html for more info. Jeff From jgarzik@pobox.com Fri Oct 28 13:52:35 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 28 Oct 2005 13:52:38 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SKqZO0028317 for ; Fri, 28 Oct 2005 13:52:35 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EVbAC-0005Kf-Nz; Fri, 28 Oct 2005 20:49:25 +0000 Message-ID: <43628ED2.3060606@pobox.com> Date: Fri, 28 Oct 2005 16:49:22 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniele Venzano CC: NetDev , akpm@osdl.org Subject: Re: [PATCH] Add Wake on LAN support to sis900 (2) References: <20051011074430.GA29824@renditai.milesteg.arr> In-Reply-To: <20051011074430.GA29824@renditai.milesteg.arr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3792 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: 164 Lines: 3 applied to sis900-wol branch of netdev-2.6.git. This will auto-propagate to -mm. Let me know when sufficient testing has been had, and I will push it upstream. From jgarzik@pobox.com Fri Oct 28 13:50:18 2005 Received: with ECARTIS (v1.0.0; list netdev); Fri, 28 Oct 2005 13:50:27 -0700 (PDT) Received: from mail.dvmed.net (mail.dvmed.net [216.237.124.58]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9SKoHO0028005 for ; Fri, 28 Oct 2005 13:50:18 -0700 Received: from cpe-069-134-188-146.nc.res.rr.com ([69.134.188.146] helo=[10.10.10.88]) by mail.dvmed.net with esmtpsa (Exim 4.52 #1 (Red Hat Linux)) id 1EVb7k-0005KV-UQ; Fri, 28 Oct 2005 20:46:53 +0000 Message-ID: <43628E3A.70206@pobox.com> Date: Fri, 28 Oct 2005 16:46:50 -0400 From: Jeff Garzik User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vasily Averin CC: Daniele Venzano , Andrew Morton , NetDev , Stanislav Protassov Subject: Re: [PATCH] sis900: come alive after temporary memory shortage References: <4337E76B.1090003@sw.ru> <8204E0D1-F30D-494F-8E97-CDCC26A82807@libero.it> <4337FF9D.70200@sw.ru> <20051006104004.GA2124@renditai.milesteg.arr> <4347C50A.9010501@sw.ru> In-Reply-To: <4347C50A.9010501@sw.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 3791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From fernando@gont.com.ar Sat Oct 29 01:52:16 2005 Received: with ECARTIS (v1.0.0; list netdev); Sat, 29 Oct 2005 01:52:20 -0700 (PDT) Received: from server.frh.utn.edu.ar (server.frh.utn.edu.ar [170.210.17.146]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9T8qDO0024493 for ; Sat, 29 Oct 2005 01:52:15 -0700 Received: (qmail 27567 invoked from network); 29 Oct 2005 08:48:20 -0000 Received: from 200-70-176-138.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.176.138) by server.frh.utn.edu.ar with SMTP; 29 Oct 2005 08:48:20 -0000 Message-Id: <6.2.0.14.0.20051029054837.04018090@pop.frh.utn.edu.ar> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 29 Oct 2005 05:48:47 -0300 To: netdev@oss.sgi.com From: Fernando Gont Subject: ICMP attacks & PMTUD mechanism Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 3793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fernando@gont.com.ar Precedence: bulk X-list: netdev Content-Length: 1608 Lines: 42 Folks, A new revision of my internet-draft on "ICMP attacks against TCP" has been published. The draft is available at http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html , and at the IETF internet-draft public repository: http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-05.txt Linux does not yet implement the PMTUD attack-specific counter-measure, which is a very important one. There are already two implementations of the PMTUD attack-specific counter-measure (which mitigates the possible attack even if large TCP windows are in use). OpenBSD implemented the first one, and NetBSD ported it to their OS. Both OSes now ship with the counter-measure enabled by default. I personally built and tested OpenBSD's implementation, together with other developers. Even if you can guess a valid TCP sequence number (as you can expect if large windows are in use), you're still immune to the PMTUD attack. The current version of the draft (-05) includes a pseudo-code version of the counter-measure, which makes its implementation very straight-forward. You can find audit tools at my web site (http://www.gont.com.ar/tools/icmp-attacks/index.html), so that, if you decide to implement the counter-measure for Linux, you can test it. P.S.: The latest version of my draft also discusses some corner cases of the PMTUD attack you may find it worthwhile reading, to check Linux behavior on this issue (see Section 7.1). (Talk about freezing IPSec-secured connections, for example) Kindest regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org From bmoss@CLEMSON.EDU Mon Oct 31 12:18:08 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 31 Oct 2005 12:18:15 -0800 (PST) Received: from CLEMSON.EDU (mail.clemson.edu [130.127.28.87]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VKI6O0009133 for ; Mon, 31 Oct 2005 12:18:08 -0800 Received: from [130.127.112.146] (mathdhcp17.ces.clemson.edu [130.127.112.146]) (authenticated bits=0) by CLEMSON.EDU (8.13.1/8.13.1) with ESMTP id j9VKEllE010565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Oct 2005 15:14:47 -0500 (EST) Message-ID: <43667B36.3000200@clemson.edu> Date: Mon, 31 Oct 2005 15:14:46 -0500 From: Bill Moss User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com CC: breed@users.sourceforge.net Subject: airo.c patches Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: mail mimedefang 2.52 on 130.127.28.87 X-archive-position: 3797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bmoss@CLEMSON.EDU Precedence: bulk X-list: netdev Content-Length: 4132 Lines: 129 Below are three patches to /usr/src/kernels/2.6.13-1.1532_FC4-i686/drivers/net/wireless/airo.c for your consideration. Patch one. Remove 3 second delay in returning scan results. This delay appears to be unnecessary. Users of NetworkManager have found that this delay makes NetworkManager slow to connect in certain scenarios. Testing has shown no ill effect of removing this delay. This delay does not appear in other drivers such as ipw2200/ieee80211 --- airo.c_orig 2005-10-28 20:06:40.000000000 -0400 +++ airo.c 2005-10-28 20:08:16.000000000 -0400 @@ -6918,7 +6918,7 @@ /* When we are associated again, the scan has surely finished. * Just in case, let's make sure enough time has elapsed since * we started the scan. - Javier */ - if(ai->scan_timestamp && time_before(jiffies,ai->scan_timestamp+3*HZ)) { + if(ai->scan_timestamp && time_before(jiffies,ai->scan_timestamp)) { /* Important note : we don't want to block the caller * until results are ready for various reasons. * First, managing wait queues is complex and racy Patch two. Report the channel correctly in the output from iwlist. --- airo.c_orig 2005-10-28 20:06:40.000000000 -0400 +++ airo.c 2005-10-28 20:16:59.000000000 -0400 @@ -6846,7 +6846,7 @@ /* Add frequency */ iwe.cmd = SIOCGIWFREQ; iwe.u.freq.m = le16_to_cpu(bss->dsChannel); - iwe.u.freq.m = frequency_list[iwe.u.freq.m] * 100000; + iwe.u.freq.m = frequency_list[iwe.u.freq.m-1] * 100000; iwe.u.freq.e = 1; current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_FREQ_LEN); Patch three. Introduce minimal ethtool support. Report driver name and version. Report link (association). This code was cloned from ipw2200/ieee80211. Ethtool support is used by NetworkManager. --- airo.c_orig 2005-10-28 20:06:40.000000000 -0400 +++ airo.c 2005-10-28 20:21:55.000000000 -0400 @@ -39,6 +39,7 @@ #include #include +#include #include #include #include @@ -46,6 +47,10 @@ #include #include +#define DRV_NAME "airo" +#define AIRO_VERSION "0.6 (Ben Reed & Javier Achirica)" +#define DRV_VERSION AIRO_VERSION + #ifdef CONFIG_PCI static struct pci_device_id card_ids[] = { { 0x14b9, 1, PCI_ANY_ID, PCI_ANY_ID, }, @@ -65,7 +70,7 @@ static int airo_pci_resume(struct pci_dev *pdev); static struct pci_driver airo_driver = { - .name = "airo", + .name = DRV_NAME, .id_table = card_ids, .probe = airo_pci_probe, .remove = __devexit_p(airo_pci_remove), @@ -1069,7 +1074,7 @@ static const struct iw_handler_def airo_handler_def; #endif /* WIRELESS_EXT */ -static const char version[] = "airo.c 0.6 (Ben Reed & Javier Achirica)"; +static const char version[] = DRV_VERSION; struct airo_info; @@ -2318,6 +2323,28 @@ return 0; } +static void airo_ethtool_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *info) +{ + strcpy(info->driver, DRV_NAME); + strcpy(info->version, DRV_VERSION); +} + +static u32 airo_ethtool_get_link(struct net_device *dev) +{ + struct airo_info *local = dev->priv; + StatusRid status_rid; + + readStatusRid(local, &status_rid, 1); + + return (status_rid.assocStatus == STAT_ASSOCIATED); +} + +static struct ethtool_ops airo_ethtool_ops = { + .get_link = airo_ethtool_get_link, + .get_drvinfo = airo_ethtool_get_drvinfo, +}; + static int airo_change_mtu(struct net_device *dev, int new_mtu) { if ((new_mtu < 68) || (new_mtu > 2400)) @@ -2757,6 +2784,7 @@ dev->change_mtu = &airo_change_mtu; dev->open = &airo_open; dev->stop = &airo_close; + dev->ethtool_ops = &airo_ethtool_ops; dev->irq = irq; dev->base_addr = port; -- Bill Moss Professor, Mathematical Sciences Clemson University -- Bill Moss Professor, Mathematical Sciences Clemson University From linville@tuxdriver.com Mon Oct 31 13:29:02 2005 Received: with ECARTIS (v1.0.0; list netdev); Mon, 31 Oct 2005 13:29:08 -0800 (PST) Received: from ra.tuxdriver.com (ra.tuxdriver.com [24.172.12.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j9VLT2O0019953 for ; Mon, 31 Oct 2005 13:29:02 -0800 Received: from bilbo.tuxdriver.com (azure.tuxdriver.com [24.172.12.5]) by ra.tuxdriver.com (8.13.3/8.13.3) with ESMTP id j9VLPQBZ016368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2005 16:25:27 -0500 Received: from bilbo.tuxdriver.com (localhost.localdomain [127.0.0.1]) by bilbo.tuxdriver.com (8.13.1/8.13.1) with ESMTP id j9VLPQ3I016241; Mon, 31 Oct 2005 16:25:26 -0500 Received: (from linville@localhost) by bilbo.tuxdriver.com (8.13.1/8.13.1/Submit) id j9VLPPBr016240; Mon, 31 Oct 2005 16:25:25 -0500 Date: Mon, 31 Oct 2005 16:25:24 -0500 From: "John W. Linville" To: Bill Moss Cc: netdev@oss.sgi.com, breed@users.sourceforge.net Subject: Re: airo.c patches Message-ID: <20051031212522.GD29670@tuxdriver.com> Mail-Followup-To: Bill Moss , netdev@oss.sgi.com, breed@users.sourceforge.net References: <43667B36.3000200@clemson.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43667B36.3000200@clemson.edu> User-Agent: Mutt/1.4.1i X-archive-position: 3798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: linville@tuxdriver.com Precedence: bulk X-list: netdev Content-Length: 566 Lines: 18 On Mon, Oct 31, 2005 at 03:14:46PM -0500, Bill Moss wrote: > Below are three patches to > /usr/src/kernels/2.6.13-1.1532_FC4-i686/drivers/net/wireless/airo.c for > your consideration. The intended changes look ok at first glance. However, your mailer has mangled the patches beyond usability. There is tons of whitespace damage, including the removal of the initial space that should preced every unchanged line in the patch. Also, we need a Signed-off-by: line. http://linux.yyz.us/patch-format.html Thanks, John -- John W. Linville linville@tuxdriver.com