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 CiMg