From vda@port.imtp.ilyichevsk.odessa.ua Thu Apr 1 03:10:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 03:10:47 -0800 (PST) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31B9oKO018503 for ; Thu, 1 Apr 2004 03:10:26 -0800 Received: (qmail 20803 invoked by alias); 1 Apr 2004 11:09:38 -0000 Received: from unknown (HELO vda) (172.16.42.177) by 0 (172.16.22.3) with ESMTP; 01 Apr 2004 11:09:38 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Denis Vlasenko To: Francois Romieu , Jeff Garzik Subject: Re: fealnx oopses (with [PATCH]) Date: Thu, 1 Apr 2004 14:09:37 +0300 X-Mailer: KMail [version 1.4] Cc: netdev@oss.sgi.com, Andreas Henriksson , Denis Vlasenko References: <200403261214.58127.vda@port.imtp.ilyichevsk.odessa.ua> <406B2FB5.9080302@pobox.com> <20040401002325.A9022@electric-eye.fr.zoreil.com> In-Reply-To: <20040401002325.A9022@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Message-Id: <200404011409.37628.vda@port.imtp.ilyichevsk.odessa.ua> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i31B9oKO018503 X-archive-position: 4421 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev On Thursday 01 April 2004 01:23, Francois Romieu wrote: > Jeff Garzik : > > FYI to those involved, I sent the TX patch upstream. > > > > When there is a minimal RX patch people are happy with, let me know... > > further changes are fine, but I would like to split up the changes as > > much as is reasonable. > > Attached is the patch tested by Andreas which fixes single allocation > failures but will not protect against excessive work in irq handler nor > complete depletion of the Rx ring. > > It applies on top of the Tx patch (as seen on bk-commit). > > Earth-shattering, anyone ? Yes, this thing improved life for me (from oopses to uninterruptible excessive work in interrupt). My RX coding was on top of it, so I think this should be applied. Jeff? -- vda From mludvig@suse.cz Thu Apr 1 04:23:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 04:23:52 -0800 (PST) Received: from kerberos.suse.cz (ns.suse.cz [82.208.2.84]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31CNKKO023960 for ; Thu, 1 Apr 2004 04:23:22 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (SuSE CR ESMTP Mailer) with ESMTP id 235394FB53 for ; Thu, 1 Apr 2004 14:23:14 +0200 (MEST) Received: by chimera.suse.cz (Postfix, from userid 503) id CADAB4825; Thu, 1 Apr 2004 14:23:13 +0200 (CEST) Received: from suse.cz (ozzy.suse.cz [10.20.1.72]) by chimera.suse.cz (Postfix) with ESMTP id BB0554824; Thu, 1 Apr 2004 14:23:12 +0200 (CEST) Message-ID: <406C09AE.1030407@suse.cz> Date: Thu, 01 Apr 2004 14:23:10 +0200 From: Michal Ludvig Organization: SuSE CR, s.r.o. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: cs, cz, en MIME-Version: 1.0 To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] pfkey_send_new_mapping() Content-Type: multipart/mixed; boundary="------------010900040305060608070900" X-DCC-neonova-Metrics: chimera 1127; Body=1 Fuz1=1 Fuz2=1 X-archive-position: 4422 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mludvig@suse.cz Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------010900040305060608070900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, this is a fix for an obvious typo in $SUBJ. Please apply. Michal Ludvig -- SUSE Labs mludvig@suse.cz | Cray is the only computer (+420) 296.545.373 http://www.suse.cz | that runs an endless loop Personal homepage http://www.logix.cz/michal | in just four hours. --------------010900040305060608070900 Content-Type: text/plain; name="kernel-newmap-dst.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-newmap-dst.diff" diff -rup linux-2.6.4/net/key/af_key.c linux-2.6.4/net/key/af_key.c --- linux-2.6.4/net/key/af_key.c 2004-04-01 10:00:32.000000000 +0200 +++ linux-2.6.4/net/key/af_key.c 2004-04-01 10:08:57.000000000 +0200 @@ -2636,7 +2636,7 @@ static int pfkey_send_new_mapping(struct addr->sadb_address_len = (sizeof(struct sadb_address)+sockaddr_size)/ sizeof(uint64_t); - addr->sadb_address_exttype = SADB_EXT_ADDRESS_SRC; + addr->sadb_address_exttype = SADB_EXT_ADDRESS_DST; addr->sadb_address_proto = 0; addr->sadb_address_reserved = 0; if (x->props.family == AF_INET) { --------------010900040305060608070900-- From romieu@fr.zoreil.com Thu Apr 1 04:30:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 04:30:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31CURKO024563 for ; Thu, 1 Apr 2004 04:30:28 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i31CSxgf021273; Thu, 1 Apr 2004 14:28:59 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i31CSvqc021272; Thu, 1 Apr 2004 14:28:57 +0200 Date: Thu, 1 Apr 2004 14:28:57 +0200 From: Francois Romieu To: Denis Vlasenko Cc: Jeff Garzik , netdev@oss.sgi.com, Andreas Henriksson Subject: Re: fealnx oopses (with [PATCH]) Message-ID: <20040401142857.A21268@electric-eye.fr.zoreil.com> References: <200403261214.58127.vda@port.imtp.ilyichevsk.odessa.ua> <406B2FB5.9080302@pobox.com> <20040401002325.A9022@electric-eye.fr.zoreil.com> <200404011409.37628.vda@port.imtp.ilyichevsk.odessa.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200404011409.37628.vda@port.imtp.ilyichevsk.odessa.ua>; from vda@port.imtp.ilyichevsk.odessa.ua on Thu, Apr 01, 2004 at 02:09:37PM +0300 X-Organisation: Land of Sunshine Inc. X-archive-position: 4423 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Denis Vlasenko : [...] > Yes, this thing improved life for me (from oopses > to uninterruptible excessive work in interrupt). > My RX coding was on top of it, so I think this should > be applied. The patch includes an unneeded 'return' removal which will choke (it is already done in the Tx patch sent by Jeff). Should I rediff and send directly to Jeff ? -- Ueimor From andrea@suse.de Thu Apr 1 05:17:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 05:17:15 -0800 (PST) Received: from dualathlon.random (ppp-217-133-42-200.cust-adsl.tiscali.it [217.133.42.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31DH2KO026205 for ; Thu, 1 Apr 2004 05:17:05 -0800 Received: by dualathlon.random (Postfix, from userid 500) id D47884A6C; Thu, 1 Apr 2004 15:16:57 +0200 (CEST) Date: Thu, 1 Apr 2004 15:16:57 +0200 From: Andrea Arcangeli To: kuznet@ms2.inr.ac.ru Cc: Robert Olsson , Dipankar Sarma , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs Message-ID: <20040401131657.GB18585@dualathlon.random> References: <20040331225259.GT2143@dualathlon.random> <200404010643.KAA08190@yakov.inr.ac.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404010643.KAA08190@yakov.inr.ac.ru> User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 X-archive-position: 4424 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: netdev On Thu, Apr 01, 2004 at 10:43:45AM +0400, kuznet@ms2.inr.ac.ru wrote: > What's about some accounting do_softirq() in some way as a starting point? > F.e. one way is to account all timer ticks happened while do_softirq() > to ksoftirqd instead of current process (I am not sure that this is even > possible without race conditions). Or something like that. This sounds reasonable. However as a start I was thinking at having hardirq run only the softirq they posted actively, and local_bh_enable run only the softirq that have been posted by the critical section (not from hardirqs happening on top of it). And leave everything else for ksoftirqd. this will complicate the bitmask setting and bitmask management but it sounds doable. This will still leave some unfariness under an irq driven flood (partly a feature to provide as usual the lowest possible latency for stuff like not busy routers where NAPI isn't needed) but at least it avoids hardirq to overload excessively the task that happens to run with bh disabled most of the time, and it will^Wshould allow NAPI to offload the softirq to ksoftirqd completely. comments? From Robert.Olsson@data.slu.se Thu Apr 1 06:17:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 06:17:52 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31EHfKO028259 for ; Thu, 1 Apr 2004 06:17:42 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i31DivnC009513; Thu, 1 Apr 2004 15:44:58 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id D58FB903D5; Thu, 1 Apr 2004 15:44:57 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16492.7385.765579.771428@robur.slu.se> Date: Thu, 1 Apr 2004 15:44:57 +0200 To: Andrea Arcangeli Cc: Robert Olsson , Dipankar Sarma , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <20040331225259.GT2143@dualathlon.random> References: <20040329222926.GF3808@dualathlon.random> <200403302005.AAA00466@yakov.inr.ac.ru> <20040330211450.GI3808@dualathlon.random> <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <16491.18384.536778.338660@robur.slu.se> <20040331225259.GT2143@dualathlon.random> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4425 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Andrea Arcangeli writes: > But I feel like we should change the softirq code so that the irqexit > runs only the softirq setup by the current (or nested) irq handler. This > way the timer irq will stop executing the softirqs posted by the network > stack and it may very well fix the problem completely. This definitely > will help fairness too. How would softirq's scheduled be softirq's be run? For a definitive solution a think Alexey analysis make sense: "All of them happening outside of ksoftirqd are equally bad, unaccountable, uncontrollable and will show up in some situation." FYI. I did some more experiments: Simple sycall test: user app = ank-time-loop (does gettimeofday in a loop) ========================================================================= Before total droppped tsquz throttl bh_enbl ksoftird irqexit other 00000099 00000000 00000000 00000000 0000005d 00000005 000163a2 00000000 00000008 00000000 00000000 00000000 00000009 00000000 000162f6 00000000 ank-time-loop After 10 sec. 000000c0 00000000 00000000 00000000 0000005d 00000005 0001c3d2 00000000 00000008 00000000 00000000 00000000 00000009 00000000 0001c2f3 00000000 So syscalls "in this context" seems to do_softirq() via irqexit. Route DoS while BGP tables are loading. ank-time-loop is running. ================================================================ total droppped tsquz throttl bh_enbl ksoftird irqexit other 000000c2 00000000 00000000 00000000 00000042 00000005 0001aef8 00000000 00000008 00000000 00000000 00000000 00000017 00000001 0001adba 00000000 After run: 000b3a10 00000000 00000eda 00000000 000006f6 0000052e 00041c06 00000000 000b0500 00000000 00000ec1 00000000 0000075e 00000197 000419f2 00000000 Most softirq's are run from irqexit but we see local_bh_enable is running softirq's too. And only a minority of softirq's is running under scheduler control. As discussed we before with 100Hz timer we would expect lower rates from irqexit. Cheers. --ro From mashirle@us.ibm.com Thu Apr 1 10:28:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 10:29:02 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31ISpKO006319 for ; Thu, 1 Apr 2004 10:28:57 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i31ISO9x429846; Thu, 1 Apr 2004 13:28:24 -0500 Received: from DYN318388BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i31ISDFY352906; Thu, 1 Apr 2004 11:28:14 -0700 From: Shirley Ma To: Shirley Ma , YOSHIFUJI Hideaki / =?utf-8?q?=E5=90=89=E8=97=A4=E8=8B=B1=E6=98=8E?= Subject: Re: [PATCH]dump interface IPv6 multicast/anycast addresses through netlink Date: Thu, 1 Apr 2004 10:28:12 -0800 User-Agent: KMail/1.5 Cc: davem@redhat.com, netdev@oss.sgi.com, "Hideaki YOSHIFUJI" , yoshfuji@linux-ipv6.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_88FbAl5YLjSg82h" Message-Id: <200404011028.13048.mashirle@us.ibm.com> X-archive-position: 4427 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6025 Lines: 201 --Boundary-00=_88FbAl5YLjSg82h Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Here is the new patch. It has been tested against linux 2.6.4 kernel. Thanks Shirley Ma IBM Linux Technology Center --Boundary-00=_88FbAl5YLjSg82h Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.4-ipv6mib.patch.new1" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.4-ipv6mib.patch.new1" diff -urN linux-2.6.4/include/linux/rtnetlink.h linux-2.6.4-ipv6mib/include/linux/rtnetlink.h --- linux-2.6.4/include/linux/rtnetlink.h 2004-03-10 18:55:42.000000000 -0800 +++ linux-2.6.4-ipv6mib/include/linux/rtnetlink.h 2004-04-01 09:18:16.165353048 -0800 @@ -47,7 +47,11 @@ #define RTM_NEWPREFIX (RTM_BASE+36) #define RTM_GETPREFIX (RTM_BASE+38) -#define RTM_MAX (RTM_BASE+39) +#define RTM_GETMULTICAST (RTM_BASE+42) + +#define RTM_GETANYCAST (RTM_BASE+46) + +#define RTM_MAX (RTM_BASE+47) /* Generic structure for encapsulation of optional route information. @@ -340,7 +344,8 @@ IFA_LABEL, IFA_BROADCAST, IFA_ANYCAST, - IFA_CACHEINFO + IFA_CACHEINFO, + IFA_MULTICAST }; #define IFA_MAX IFA_CACHEINFO diff -urN linux-2.6.4/net/ipv6/addrconf.c linux-2.6.4-ipv6mib/net/ipv6/addrconf.c --- linux-2.6.4/net/ipv6/addrconf.c 2004-03-10 18:55:44.000000000 -0800 +++ linux-2.6.4-ipv6mib/net/ipv6/addrconf.c 2004-04-01 09:56:16.340713704 -0800 @@ -2571,7 +2571,7 @@ if (ipv6_addr_scope(&ifmca->mca_addr)&IFA_SITE) ifm->ifa_scope = RT_SCOPE_SITE; ifm->ifa_index = ifmca->idev->dev->ifindex; - RTA_PUT(skb, IFA_ADDRESS, 16, &ifmca->mca_addr); + RTA_PUT(skb, IFA_MULTICAST, 16, &ifmca->mca_addr); ci.cstamp = (__u32)(TIME_DELTA(ifmca->mca_cstamp, INITIAL_JIFFIES) / HZ * 100 + TIME_DELTA(ifmca->mca_cstamp, INITIAL_JIFFIES) % HZ * 100 / HZ); @@ -2608,7 +2608,7 @@ if (ipv6_addr_scope(&ifaca->aca_addr)&IFA_SITE) ifm->ifa_scope = RT_SCOPE_SITE; ifm->ifa_index = ifaca->aca_idev->dev->ifindex; - RTA_PUT(skb, IFA_ADDRESS, 16, &ifaca->aca_addr); + RTA_PUT(skb, IFA_ANYCAST, 16, &ifaca->aca_addr); ci.cstamp = (__u32)(TIME_DELTA(ifaca->aca_cstamp, INITIAL_JIFFIES) / HZ * 100 + TIME_DELTA(ifaca->aca_cstamp, INITIAL_JIFFIES) % HZ * 100 / HZ); @@ -2627,7 +2627,14 @@ return -1; } -static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +enum addr_type_t +{ + UNICAST_ADDR, + MULTICAST_ADDR, + ANYCAST_ADDR, +}; +static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb, + enum addr_type_t type) { int idx, ip_idx; int s_idx, s_ip_idx; @@ -2651,28 +2658,58 @@ if ((idev = in6_dev_get(dev)) == NULL) continue; read_lock_bh(&idev->lock); - /* unicast address */ - for (ifa = idev->addr_list; ifa; - ifa = ifa->if_next, ip_idx++) { - if (ip_idx < s_ip_idx) - continue; - if ((err = inet6_fill_ifaddr(skb, ifa, - NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) - goto done; - } - /* temp addr */ + switch (type) { + case UNICAST_ADDR: + /* unicast address */ + for (ifa = idev->addr_list; ifa; + ifa = ifa->if_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifaddr(skb, ifa, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + goto done; + } + /* temp addr */ #ifdef CONFIG_IPV6_PRIVACY - for (ifa = idev->tempaddr_list; ifa; - ifa = ifa->tmp_next, ip_idx++) { - if (ip_idx < s_ip_idx) - continue; - if ((err = inet6_fill_ifaddr(skb, ifa, - NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) - goto done; - } + for (ifa = idev->tempaddr_list; ifa; + ifa = ifa->tmp_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifaddr(skb, ifa, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + goto done; + } #endif + break; + case MULTICAST_ADDR: + /* multicast address */ + for (ifmca = idev->mc_list; ifmca; + ifmca = ifmca->next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifmcaddr(skb, ifmca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_GETMULTICAST)) <= 0) + goto done; + } + break; + case ANYCAST_ADDR: + /* anycast address */ + for (ifaca = idev->ac_list; ifaca; + ifaca = ifaca->aca_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifacaddr(skb, ifaca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_GETANYCAST)) <= 0) + goto done; + } + break; + default: + break; + } read_unlock_bh(&idev->lock); in6_dev_put(idev); } @@ -2687,6 +2724,25 @@ return skb->len; } +static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = UNICAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + +static int inet6_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = MULTICAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + + +static int inet6_dump_ifacaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = ANYCAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + static void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa) { struct sk_buff *skb; @@ -2911,6 +2967,8 @@ [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, [RTM_DELADDR - RTM_BASE] = { .doit = inet6_rtm_deladdr, }, [RTM_GETADDR - RTM_BASE] = { .dumpit = inet6_dump_ifaddr, }, + [RTM_GETMULTICAST - RTM_BASE] = { .dumpit = inet6_dump_ifmcaddr, }, + [RTM_GETANYCAST - RTM_BASE] = { .dumpit = inet6_dump_ifacaddr, }, [RTM_NEWROUTE - RTM_BASE] = { .doit = inet6_rtm_newroute, }, [RTM_DELROUTE - RTM_BASE] = { .doit = inet6_rtm_delroute, }, [RTM_GETROUTE - RTM_BASE] = { .doit = inet6_rtm_getroute, --Boundary-00=_88FbAl5YLjSg82h-- From jgarzik@pobox.com Thu Apr 1 10:32:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 10:32:59 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31IWsKO006736 for ; Thu, 1 Apr 2004 10:32:55 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1B96zi-0003m1-Uy; Thu, 01 Apr 2004 19:32:51 +0100 Message-ID: <406C6046.6080106@pobox.com> Date: Thu, 01 Apr 2004 13:32:38 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.4.26-rc1] pcnet32.c References: <200403302217.i2UMHYY12182@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200403302217.i2UMHYY12182@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4428 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From davem@redhat.com Thu Apr 1 10:39:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 10:40:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31IdnKO007183 for ; Thu, 1 Apr 2004 10:39:51 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31Idmjj019403; Thu, 1 Apr 2004 13:39:48 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31Idmj00350; Thu, 1 Apr 2004 13:39:48 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31IdP1n014385; Thu, 1 Apr 2004 13:39:26 -0500 Date: Thu, 1 Apr 2004 10:39:04 -0800 From: "David S. Miller" To: Michal Ludvig Cc: netdev@oss.sgi.com Subject: Re: [PATCH] pfkey_send_new_mapping() Message-Id: <20040401103904.5692a892.davem@redhat.com> In-Reply-To: <406C09AE.1030407@suse.cz> References: <406C09AE.1030407@suse.cz> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4429 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 160 Lines: 6 On Thu, 01 Apr 2004 14:23:10 +0200 Michal Ludvig wrote: > this is a fix for an obvious typo in $SUBJ. Please apply. Applied, thanks Michal. From Robert.Olsson@data.slu.se Thu Apr 1 10:53:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 10:54:08 -0800 (PST) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31IrtKO007879 for ; Thu, 1 Apr 2004 10:53:56 -0800 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i2UMXBnC020477; Wed, 31 Mar 2004 00:33:12 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 6D0C6903D5; Wed, 31 Mar 2004 00:33:11 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <16489.62887.320005.806119@robur.slu.se> Date: Wed, 31 Mar 2004 00:33:11 +0200 To: Andrea Arcangeli Cc: "David S. Miller" , kuznet@ms2.inr.ac.ru, dipankar@in.ibm.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <20040330213742.GL3808@dualathlon.random> References: <20040329222926.GF3808@dualathlon.random> <200403302005.AAA00466@yakov.inr.ac.ru> <20040330211450.GI3808@dualathlon.random> <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> X-Mailer: VM 7.17 under Emacs 21.3.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i31IrtKO007879 X-archive-position: 4430 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1451 Lines: 47 Andrea Arcangeli writes: > He posted these numbers: > > softirq_count, ksoftirqd_count and other_softirq_count shows - > > CPU 0 : 638240 554 637686 > CPU 1 : 102316 1 102315 > CPU 2 : 675696 557 675139 > CPU 3 : 102305 0 102305 > > that means nothing runs in ksoftirqd for Dipankar, so he cannot be using > NAPI. > > Either that or I'm misreading his numbers, or his stats results are wrong. Well we have to ask Dipankar... But I'll buy a beer if it's not on. :) Anyway w. NAPI enabled. 2 * 304 kpps DoS flows into eth0, eth2. Flows are 2 * 10 Millions 64 byte pkts. 32 k buckets routehash. Full Internet routing means ~130 k routes. Linux 2.6.4 2*2.66 MHz XEON. 26: 896 0 IO-APIC-level eth0 27: 25197 0 IO-APIC-level eth1 28: 8 579 IO-APIC-level eth2 29: 10 26112 IO-APIC-level eth3 T-put is seen on output dev. eth1, eth3. So about 16% of incoming load, eth0 1500 0 1577468 9631270 9631270 8422828 237 0 0 0 BRU eth1 1500 0 42 0 0 0 1573355 0 0 0 BRU eth2 1500 0 1636154 9603432 9603432 8363849 41 0 0 0 BRU eth3 1500 0 54 0 0 0 1632274 0 0 0 BRU And lots of . . printk: 1898 messages suppressed. dst cache overflow printk: 829 messages suppressed. dst cache overflow Cheers. --ro From dlstevens@us.ibm.com Thu Apr 1 11:39:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 11:39:26 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31JdMKO009569 for ; Thu, 1 Apr 2004 11:39:22 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i31JdB5U572444 for ; Thu, 1 Apr 2004 14:39:11 -0500 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i31Jd9xt099798 for ; Thu, 1 Apr 2004 12:39:11 -0700 Subject: [PATCH] fix IGMP version number and timer printing for /proc/net/igmp To: davem@redhat.com, netdev@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Thu, 1 Apr 2004 12:39:09 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/01/2004 12:39:11 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D" X-archive-position: 4431 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6366 Lines: 142 --0__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D Content-type: multipart/alternative; Boundary="1__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D" --1__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D Content-type: text/plain; charset=US-ASCII Below are 2.4.x and 2.6.x patches that correctly print the IGMP version number and print "0" for the timer value when a timer is not running. 2.6.x in-line for viewing; both variants attached. +-DLS diff -ruN linux-2.6.5-rc3/net/ipv4/igmp.c linux-2.6.5-rc3F2/net/ipv4/igmp.c --- linux-2.6.5-rc3/net/ipv4/igmp.c 2004-03-30 12:27:30.000000000 -0800 +++ linux-2.6.5-rc3F2/net/ipv4/igmp.c 2004-03-31 23:04:49.000000000 -0800 @@ -2225,7 +2225,9 @@ struct igmp_mc_iter_state *state = igmp_mc_seq_private(seq); char *querier; #ifdef CONFIG_IP_MULTICAST - querier = IGMP_V1_SEEN(state->in_dev) ? "V1" : "V2"; + querier = IGMP_V1_SEEN(state->in_dev) ? "V1" : + IGMP_V2_SEEN(state->in_dev) ? "V2" : + "V3"; #else querier = "NONE"; #endif @@ -2238,7 +2240,9 @@ seq_printf(seq, "\t\t\t\t%08lX %5d %d:%08lX\t\t%d\n", im->multiaddr, im->users, - im->tm_running, jiffies_to_clock_t(im->timer.expires-jiffies), im->reporter); + im->tm_running, im->tm_running ? + jiffies_to_clock_t(im->timer.expires-jiffies) : 0, + im->reporter); } return 0; } (See attached file: 2.4.26rc1-igmpprint.patch) (See attached file: 2.6.5rc3-igmpprint.patch) --1__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Below are 2.4.x and 2.6.x patches that correctly print the IGMP
version number and print "0" for the timer value when a timer
is not running.

2.6.x in-line for viewing; both variants attached.

+-DLS

diff -ruN linux-2.6.5-rc3/net/ipv4/igmp.c linux-2.6.5-rc3F2/net/ipv4/igmp.c
--- linux-2.6.5-rc3/net/ipv4/igmp.c 2004-03-30 12:27:30.000000000 -0800
+++ linux-2.6.5-rc3F2/net/ipv4/igmp.c 2004-03-31 23:04:49.000000000 -0800
@@ -2225,7 +2225,9 @@
struct igmp_mc_iter_state *state = igmp_mc_seq_private(seq);
char *querier;
#ifdef CONFIG_IP_MULTICAST
- querier = IGMP_V1_SEEN(state->in_dev) ? "V1" : "V2";
+ querier = IGMP_V1_SEEN(state->in_dev) ? "V1" :
+ IGMP_V2_SEEN(state->in_dev) ? "V2" :
+ "V3";
#else
querier = "NONE";
#endif
@@ -2238,7 +2240,9 @@
seq_printf(seq,
"\t\t\t\t%08lX %5d %d:%08lX\t\t%d\n",
im->multiaddr, im->users,
- im->tm_running, jiffies_to_clock_t(im->timer.expires-jiffies), im->reporter);
+ im->tm_running, im->tm_running ?
+ jiffies_to_clock_t(im->timer.expires-jiffies) : 0,
+ im->reporter);
}
return 0;
}

(See attached file: 2.4.26rc1-igmpprint.patch)
(See attached file: 2.6.5rc3-igmpprint.patch)
--1__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D-- --0__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D Content-type: application/octet-stream; name="2.4.26rc1-igmpprint.patch" Content-Disposition: attachment; filename="2.4.26rc1-igmpprint.patch" Content-ID: <10__=07BBE4FADFF8272D8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNC4yNi1yYzEvbmV0L2lwdjQvaWdtcC5jIGxpbnV4LTIuNC4yNi1y YzFGMi9uZXQvaXB2NC9pZ21wLmMKLS0tIGxpbnV4LTIuNC4yNi1yYzEvbmV0L2lwdjQvaWdtcC5j CTIwMDQtMDMtMzAgMTY6Mjg6MzkuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjQuMjYtcmMx RjIvbmV0L2lwdjQvaWdtcC5jCTIwMDQtMDMtMzEgMjI6NDI6MzMuMDAwMDAwMDAwIC0wODAwCkBA IC0yMTI4LDcgKzIxMjgsOCBAQAogCQkJY29udGludWU7CiAKICNpZmRlZiBDT05GSUdfSVBfTVVM VElDQVNUCi0JCXF1ZXJpZXIgPSBJR01QX1YxX1NFRU4oaW5fZGV2KSA/ICJWMSIgOiAiVjIiOwor CQlxdWVyaWVyID0gSUdNUF9WMV9TRUVOKGluX2RldikgPyAiVjEiIDogSUdNUF9WMl9TRUVOKGlu X2RldikgPworCQkJIlYyIiA6ICJWMyI7CiAjZW5kaWYKIAogCQlsZW4rPXNwcmludGYoYnVmZmVy K2xlbiwiJWRcdCUtMTBzOiAlNWQgJTdzXG4iLApAQCAtMjEzOSw3ICsyMTQwLDkgQEAKIAkJCWxl bis9c3ByaW50ZihidWZmZXIrbGVuLAogCQkJCSAgICAgIlx0XHRcdFx0JTA4bFggJTVkICVkOiUw OGxYXHRcdCVkXG4iLAogCQkJCSAgICAgaW0tPm11bHRpYWRkciwgaW0tPnVzZXJzLAotCQkJCSAg ICAgaW0tPnRtX3J1bm5pbmcsIGltLT50aW1lci5leHBpcmVzLWppZmZpZXMsIGltLT5yZXBvcnRl cik7CisJCQkJICAgICBpbS0+dG1fcnVubmluZywgaW0tPnRtX3J1bm5pbmcgPworCQkJCSAgICAg aW0tPnRpbWVyLmV4cGlyZXMtamlmZmllcyA6IDAsCisJCQkJICAgICBpbS0+cmVwb3J0ZXIpOwog CiAJCQlwb3M9YmVnaW4rbGVuOwogCQkJaWYocG9zPG9mZnNldCkK --0__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D Content-type: application/octet-stream; name="2.6.5rc3-igmpprint.patch" Content-Disposition: attachment; filename="2.6.5rc3-igmpprint.patch" Content-ID: <20__=07BBE4FADFF8272D8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 ZGlmZiAtcnVOIGxpbnV4LTIuNi41LXJjMy9uZXQvaXB2NC9pZ21wLmMgbGludXgtMi42LjUtcmMz RjIvbmV0L2lwdjQvaWdtcC5jCi0tLSBsaW51eC0yLjYuNS1yYzMvbmV0L2lwdjQvaWdtcC5jCTIw MDQtMDMtMzAgMTI6Mjc6MzAuMDAwMDAwMDAwIC0wODAwCisrKyBsaW51eC0yLjYuNS1yYzNGMi9u ZXQvaXB2NC9pZ21wLmMJMjAwNC0wMy0zMSAyMzowNDo0OS4wMDAwMDAwMDAgLTA4MDAKQEAgLTIy MjUsNyArMjIyNSw5IEBACiAJCXN0cnVjdCBpZ21wX21jX2l0ZXJfc3RhdGUgKnN0YXRlID0gaWdt cF9tY19zZXFfcHJpdmF0ZShzZXEpOwogCQljaGFyICAgKnF1ZXJpZXI7CiAjaWZkZWYgQ09ORklH X0lQX01VTFRJQ0FTVAotCQlxdWVyaWVyID0gSUdNUF9WMV9TRUVOKHN0YXRlLT5pbl9kZXYpID8g IlYxIiA6ICJWMiI7CisJCXF1ZXJpZXIgPSBJR01QX1YxX1NFRU4oc3RhdGUtPmluX2RldikgPyAi VjEiIDoKKwkJCSAgSUdNUF9WMl9TRUVOKHN0YXRlLT5pbl9kZXYpID8gIlYyIiA6CisJCQkgICJW MyI7CiAjZWxzZQogCQlxdWVyaWVyID0gIk5PTkUiOwogI2VuZGlmCkBAIC0yMjM4LDcgKzIyNDAs OSBAQAogCQlzZXFfcHJpbnRmKHNlcSwKIAkJCSAgICJcdFx0XHRcdCUwOGxYICU1ZCAlZDolMDhs WFx0XHQlZFxuIiwKIAkJCSAgIGltLT5tdWx0aWFkZHIsIGltLT51c2VycywKLQkJCSAgIGltLT50 bV9ydW5uaW5nLCBqaWZmaWVzX3RvX2Nsb2NrX3QoaW0tPnRpbWVyLmV4cGlyZXMtamlmZmllcyks IGltLT5yZXBvcnRlcik7CisJCQkgICBpbS0+dG1fcnVubmluZywgaW0tPnRtX3J1bm5pbmcgPwor CQkJICAgamlmZmllc190b19jbG9ja190KGltLT50aW1lci5leHBpcmVzLWppZmZpZXMpIDogMCwK KwkJCSAgIGltLT5yZXBvcnRlcik7CiAJfQogCXJldHVybiAwOwogfQo= --0__=07BBE4FADFF8272D8f9e8a93df938690918c07BBE4FADFF8272D-- From davem@redhat.com Thu Apr 1 11:51:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 11:51:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31Jp3KO010221 for ; Thu, 1 Apr 2004 11:51:03 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31Jp2jj012069; Thu, 1 Apr 2004 14:51:02 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31Jp2j23353; Thu, 1 Apr 2004 14:51:02 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31Joe1n019347; Thu, 1 Apr 2004 14:50:40 -0500 Date: Thu, 1 Apr 2004 11:50:17 -0800 From: "David S. Miller" To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: [PATCH] fix IGMP version number and timer printing for /proc/net/igmp Message-Id: <20040401115017.073ae1cc.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4432 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 24 Lines: 2 Applied, thanks David. From daniel.ritz@gmx.ch Thu Apr 1 13:17:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:17:32 -0800 (PST) Received: from ritz.dnsalias.org (80-218-57-148.dclient.hispeed.ch [80.218.57.148]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31LHRKO021468 for ; Thu, 1 Apr 2004 13:17:28 -0800 Received: from toshba.local (toshba.local [192.168.100.12]) by ritz.dnsalias.org (Postfix) with ESMTP id 8CEE14FBB4; Thu, 1 Apr 2004 23:17:25 +0200 (CEST) From: Daniel Ritz Reply-To: daniel.ritz@gmx.ch To: Jeff Garzik Subject: [PATCH] fix arm/etherh.c Date: Thu, 1 Apr 2004 23:17:23 +0200 User-Agent: KMail/1.5.2 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404012317.23719.daniel.ritz@gmx.ch> X-archive-position: 4433 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.ritz@gmx.ch Precedence: bulk X-list: netdev Content-Length: 1774 Lines: 76 arm/etherh.c was broken when converted to alloc_ei_dev(). fix is the same as in pcnet_cs.c. also kfree()ing ec->irqdata is wrong since it's already freed by free_netdev(). against 2.6.5-rc3-bk. untested. --- 1.21/drivers/net/arm/etherh.c Wed Mar 3 00:15:42 2004 +++ edited/drivers/net/arm/etherh.c Sat Mar 27 21:53:49 2004 @@ -59,7 +59,6 @@ static unsigned int net_debug = NET_DEBUG; struct etherh_priv { - struct ei_device eidev; unsigned int id; unsigned int ctrl_port; unsigned int ctrl; @@ -99,6 +98,12 @@ /* ------------------------------------------------------------------------ */ +static inline struct etherh_priv *PRIV(struct net_device *dev) +{ + char *p = netdev_priv(dev); + return (struct etherh_priv *)(p + sizeof(struct ei_device)); +} + static inline void etherh_set_ctrl(struct etherh_priv *eh, unsigned int mask) { eh->ctrl |= mask; @@ -144,8 +149,7 @@ static void etherh_setif(struct net_device *dev) { - struct etherh_priv *eh = netdev_priv(dev); - struct ei_device *ei_local = &eh->eidev; + struct etherh_priv *eh = PRIV(dev); unsigned long addr, flags; local_irq_save(flags); @@ -188,8 +192,7 @@ static int etherh_getifstat(struct net_device *dev) { - struct etherh_priv *eh = netdev_priv(dev); - struct ei_device *ei_local = &eh->eidev; + struct etherh_priv *eh = PRIV(dev); int stat = 0; switch (eh->id) { @@ -551,13 +554,13 @@ etherh_banner(); - dev = alloc_ei_netdev(); + dev = __alloc_ei_netdev(sizeof(struct etherh_priv)); if (!dev) { ret = -ENOMEM; goto out; } - eh = netdev_priv(dev); + eh = PRIV(dev); spin_lock_init(&eh->eidev.page_lock); @@ -712,7 +715,6 @@ free_netdev(dev); ec->ops = NULL; - kfree(ec->irq_data); } static const struct ecard_id etherh_ids[] = { From shemminger@osdl.org Thu Apr 1 13:36:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:36:32 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31LaSKO026630 for ; Thu, 1 Apr 2004 13:36:29 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i31LaH205838; Thu, 1 Apr 2004 13:36:17 -0800 Date: Thu, 1 Apr 2004 13:36:17 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: [PATCH] bridge (2.6.5) - allow non-root get ioctl's Message-Id: <20040401133617.3f30f39d@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4434 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: 4675 Lines: 185 This patch allows non-root users to inspect the status of a bridge. It moves the permission check for the ioctl from the top level down to where the set type commands are. diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c Thu Apr 1 12:50:06 2004 +++ b/net/bridge/br_device.c Thu Apr 1 12:50:06 2004 @@ -32,7 +32,7 @@ if (copy_from_user(args, data, 4*sizeof(unsigned long))) return -EFAULT; - return br_ioctl(dev->priv, args[0], args[1], args[2], args[3]); + return br_ioctl_device(dev->priv, args[0], args[1], args[2], args[3]); } static struct net_device_stats *br_dev_get_stats(struct net_device *dev) diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Thu Apr 1 12:50:06 2004 +++ b/net/bridge/br_ioctl.c Thu Apr 1 12:50:06 2004 @@ -38,11 +38,8 @@ ? (timer->expires - jiffies) : 0); } -static int br_ioctl_device(struct net_bridge *br, - unsigned int cmd, - unsigned long arg0, - unsigned long arg1, - unsigned long arg2) +int br_ioctl_device(struct net_bridge *br, unsigned int cmd, + unsigned long arg0, unsigned long arg1, unsigned long arg2) { if (br == NULL) return -EINVAL; @@ -55,6 +52,9 @@ struct net_device *dev; int ret; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + dev = dev_get_by_index(arg0); if (dev == NULL) return -EINVAL; @@ -121,6 +121,9 @@ } case BRCTL_SET_BRIDGE_FORWARD_DELAY: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); br->bridge_forward_delay = user_to_ticks(arg0); if (br_is_root_bridge(br)) @@ -129,6 +132,9 @@ return 0; case BRCTL_SET_BRIDGE_HELLO_TIME: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); br->bridge_hello_time = user_to_ticks(arg0); if (br_is_root_bridge(br)) @@ -137,6 +143,9 @@ return 0; case BRCTL_SET_BRIDGE_MAX_AGE: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); br->bridge_max_age = user_to_ticks(arg0); if (br_is_root_bridge(br)) @@ -145,10 +154,10 @@ return 0; case BRCTL_SET_AGEING_TIME: - br->ageing_time = user_to_ticks(arg0); - return 0; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; - case BRCTL_SET_GC_INTERVAL: /* no longer used */ + br->ageing_time = user_to_ticks(arg0); return 0; case BRCTL_GET_PORT_INFO: @@ -185,10 +194,16 @@ } case BRCTL_SET_BRIDGE_STP_STATE: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + br->stp_enabled = arg0?1:0; return 0; case BRCTL_SET_BRIDGE_PRIORITY: + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); br_stp_set_bridge_priority(br, arg0); spin_unlock_bh(&br->lock); @@ -199,6 +214,9 @@ struct net_bridge_port *p; int ret = 0; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); if ((p = br_get_port(br, arg0)) == NULL) ret = -EINVAL; @@ -213,6 +231,9 @@ struct net_bridge_port *p; int ret = 0; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + spin_lock_bh(&br->lock); if ((p = br_get_port(br, arg0)) == NULL) ret = -EINVAL; @@ -265,6 +286,9 @@ { char buf[IFNAMSIZ]; + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + if (copy_from_user(buf, (void *)arg0, IFNAMSIZ)) return -EFAULT; @@ -285,25 +309,8 @@ { unsigned long i[3]; - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - if (copy_from_user(i, (void *)arg, 3*sizeof(unsigned long))) return -EFAULT; return br_ioctl_deviceless(i[0], i[1], i[2]); -} - -int br_ioctl(struct net_bridge *br, unsigned int cmd, unsigned long arg0, unsigned long arg1, unsigned long arg2) -{ - int err; - - if (!capable(CAP_NET_ADMIN)) - return -EPERM; - - err = br_ioctl_deviceless(cmd, arg0, arg1); - if (err == -EOPNOTSUPP) - err = br_ioctl_device(br, cmd, arg0, arg1, arg2); - - return err; } diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Thu Apr 1 12:50:06 2004 +++ b/net/bridge/br_private.h Thu Apr 1 12:50:06 2004 @@ -174,11 +174,11 @@ extern int br_handle_frame(struct sk_buff *skb); /* br_ioctl.c */ -extern int br_ioctl(struct net_bridge *br, - unsigned int cmd, - unsigned long arg0, - unsigned long arg1, - unsigned long arg2); +extern int br_ioctl_device(struct net_bridge *br, + unsigned int cmd, + unsigned long arg0, + unsigned long arg1, + unsigned long arg2); extern int br_ioctl_deviceless_stub(unsigned long arg); /* br_netfilter.c */ -- Stephen Hemminger mailto:shemminger@osdl.org Open Source Development Lab http://developer.osdl.org/shemminger From davem@redhat.com Thu Apr 1 13:39:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:39:19 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31LdHKO027023 for ; Thu, 1 Apr 2004 13:39:17 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31LdEjj017388; Thu, 1 Apr 2004 16:39:14 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31LdEj27454; Thu, 1 Apr 2004 16:39:14 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31Lcp1n015306; Thu, 1 Apr 2004 16:38:52 -0500 Date: Thu, 1 Apr 2004 13:38:22 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [PATCH] bridge (2.6.5) - allow non-root get ioctl's Message-Id: <20040401133822.37e699fa.davem@redhat.com> In-Reply-To: <20040401133617.3f30f39d@dell_ss3.pdx.osdl.net> References: <20040401133617.3f30f39d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4435 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 97 Lines: 5 Ok, do we want a 2.4.x variant as well? If so, please prepare and I'll apply. Thanks Stephen. From shemminger@osdl.org Thu Apr 1 13:42:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:42:05 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31Lg2KO027412 for ; Thu, 1 Apr 2004 13:42:03 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i31Lfp206862; Thu, 1 Apr 2004 13:41:51 -0800 Date: Thu, 1 Apr 2004 13:41:51 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: [PATCH] bridge (2.6.5) - lift ioctl limits on number of bridges/ports. Message-Id: <20040401134151.79ffe512@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4436 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: 2386 Lines: 79 Get rid of some arbitrary API restrictions that limit the kernel to 64 bridges and 256 ports. Retain compatibility in GET_PORT_LIST, the existing bridge API passes 0 for the third argument, and expects 256 entries. Note: there still is limit of 256 ports due to STP, but this shouldn't show up in the API, it needs to be handled by the "add port to bridge ioctl". diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Thu Apr 1 12:50:36 2004 +++ b/net/bridge/br_if.c Thu Apr 1 12:50:36 2004 @@ -262,13 +262,14 @@ return i; } -void br_get_port_ifindices(struct net_bridge *br, int *ifindices) +void br_get_port_ifindices(struct net_bridge *br, int *ifindices, int num) { struct net_bridge_port *p; rcu_read_lock(); list_for_each_entry_rcu(p, &br->port_list, list) { - ifindices[p->port_no] = p->dev->ifindex; + if (p->port_no < num) + ifindices[p->port_no] = p->dev->ifindex; } rcu_read_unlock(); } diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Thu Apr 1 12:50:36 2004 +++ b/net/bridge/br_ioctl.c Thu Apr 1 12:50:36 2004 @@ -104,17 +104,18 @@ case BRCTL_GET_PORT_LIST: { - int *indices; + int num = arg1 ? arg1 : 256; /* compatiablity */ int ret = 0; + int *indices; - indices = kmalloc(256*sizeof(int), GFP_KERNEL); + indices = kmalloc(num*sizeof(int), GFP_KERNEL); if (indices == NULL) return -ENOMEM; - memset(indices, 0, 256*sizeof(int)); + memset(indices, 0, num*sizeof(int)); - br_get_port_ifindices(br, indices); - if (copy_to_user((void *)arg0, indices, 256*sizeof(int))) + br_get_port_ifindices(br, indices, num); + if (copy_to_user((void *)arg0, indices, num*sizeof(int))) ret = -EFAULT; kfree(indices); return ret; @@ -263,9 +264,6 @@ { int *indices; int ret = 0; - - if (arg1 > 64) - arg1 = 64; indices = kmalloc(arg1*sizeof(int), GFP_KERNEL); if (indices == NULL) diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Thu Apr 1 12:50:36 2004 +++ b/net/bridge/br_private.h Thu Apr 1 12:50:36 2004 @@ -167,7 +167,7 @@ extern int br_get_bridge_ifindices(int *indices, int num); extern void br_get_port_ifindices(struct net_bridge *br, - int *ifindices); + int *ifindices, int num); /* br_input.c */ extern int br_handle_frame_finish(struct sk_buff *skb); From davem@redhat.com Thu Apr 1 13:50:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:51:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31LowKO027840 for ; Thu, 1 Apr 2004 13:50:59 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31Lotjj022257; Thu, 1 Apr 2004 16:50:55 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31Lotj32185; Thu, 1 Apr 2004 16:50:55 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31LoW1n022788; Thu, 1 Apr 2004 16:50:32 -0500 Date: Thu, 1 Apr 2004 13:50:09 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, bridge@osdl.org Subject: Re: [PATCH] bridge (2.6.5) - lift ioctl limits on number of bridges/ports. Message-Id: <20040401135009.1256aef4.davem@redhat.com> In-Reply-To: <20040401134151.79ffe512@dell_ss3.pdx.osdl.net> References: <20040401134151.79ffe512@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4437 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 77 Lines: 6 Applied, thanks Stephen. Again, send 2.4.x variant if applicable. Thanks. From shemminger@osdl.org Thu Apr 1 13:58:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 13:58:10 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31Lw7KO028327 for ; Thu, 1 Apr 2004 13:58:07 -0800 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i31Lvk210566; Thu, 1 Apr 2004 13:57:46 -0800 Date: Thu, 1 Apr 2004 13:57:46 -0800 From: Stephen Hemminger To: "David S. Miller" Cc: Miika Keskinen , bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH] bridge (2.6.5) -- correctl handle up to 256 ports per bridge Message-Id: <20040401135746.0f985897@dell_ss3.pdx.osdl.net> In-Reply-To: <406CA0D7.6020500@usr.fi> References: <406B251B.9050907@usr.fi> <20040401093618.49cca9fa@dell_ss3.pdx.osdl.net> <406CA0D7.6020500@usr.fi> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4438 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: 2837 Lines: 120 Bridge code is limited to 256 ports per bridge because the Spanning Tree Protocol has limit of one octet for port number. This code fixes: * bogus unlock in error path when port list is full. * passes different error status for out of memory, vs port list full. * O(n) vs O(n^2) lookup for free port number * since port and priority are both limited to one byte don't store them as int's * makes limit explicit in code diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Thu Apr 1 12:55:31 2004 +++ b/net/bridge/br_if.c Thu Apr 1 12:55:31 2004 @@ -24,6 +24,9 @@ #include #include "br_private.h" +/* Limited to 256 ports because of STP protocol pdu */ +#define BR_MAX_PORTS 256 + static int br_initial_port_cost(struct net_device *dev) { if (!strncmp(dev->name, "lec", 3)) @@ -126,34 +129,46 @@ return br; } +static int free_port(struct net_bridge *br) +{ + int index; + struct net_bridge_port *p; + long inuse[BR_MAX_PORTS/(sizeof(long)*8)]; + + /* find free port number */ + memset(inuse, 0, sizeof(inuse)); + list_for_each_entry(p, &br->port_list, list) { + set_bit(p->port_no, inuse); + } + + index = find_first_zero_bit(inuse, BR_MAX_PORTS); + if (index >= BR_MAX_PORTS) + return -EXFULL; + + return index; +} + /* called under bridge lock */ static struct net_bridge_port *new_nbp(struct net_bridge *br, struct net_device *dev) { - int i; + int index; struct net_bridge_port *p; + + index = free_port(br); + if (index < 0) + return ERR_PTR(index); p = kmalloc(sizeof(*p), GFP_ATOMIC); if (p == NULL) - return p; + return ERR_PTR(-ENOMEM); memset(p, 0, sizeof(*p)); p->br = br; p->dev = dev; p->path_cost = br_initial_port_cost(dev); p->priority = 0x80; - - for (i=1;i<255;i++) - if (br_get_port(br, i) == NULL) - break; - - if (i == 255) { - kfree(p); - return NULL; - } - dev->br_port = p; - - p->port_no = i; + p->port_no = index; br_init_port(p); p->state = BR_STATE_DISABLED; @@ -218,10 +233,10 @@ return -ELOOP; dev_hold(dev); - if ((p = new_nbp(br, dev)) == NULL) { - spin_unlock_bh(&br->lock); + p = new_nbp(br, dev); + if (IS_ERR(p)) { dev_put(dev); - return -EXFULL; + return PTR_ERR(p); } dev_set_promiscuity(dev, 1); diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Thu Apr 1 12:55:31 2004 +++ b/net/bridge/br_private.h Thu Apr 1 12:55:31 2004 @@ -57,7 +57,8 @@ struct net_bridge *br; struct net_device *dev; struct list_head list; - int port_no; + __u8 port_no; + __u8 priority; /* STP */ port_id port_id; @@ -69,7 +70,6 @@ port_id designated_port; unsigned topology_change_ack:1; unsigned config_pending:1; - int priority; struct timer_list forward_delay_timer; struct timer_list hold_timer; From davem@redhat.com Thu Apr 1 14:14:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 14:14:37 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31MEZKO029012 for ; Thu, 1 Apr 2004 14:14:35 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31MEWjj029880; Thu, 1 Apr 2004 17:14:32 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31MEWj07990; Thu, 1 Apr 2004 17:14:32 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31ME91n003744; Thu, 1 Apr 2004 17:14:10 -0500 Date: Thu, 1 Apr 2004 14:13:46 -0800 From: "David S. Miller" To: Stephen Hemminger Cc: weeti@usr.fi, bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] bridge (2.6.5) -- correctl handle up to 256 ports per bridge Message-Id: <20040401141346.69236947.davem@redhat.com> In-Reply-To: <20040401135746.0f985897@dell_ss3.pdx.osdl.net> References: <406B251B.9050907@usr.fi> <20040401093618.49cca9fa@dell_ss3.pdx.osdl.net> <406CA0D7.6020500@usr.fi> <20040401135746.0f985897@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4439 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 559 Lines: 15 On Thu, 1 Apr 2004 13:57:46 -0800 Stephen Hemminger wrote: > Bridge code is limited to 256 ports per bridge because the Spanning > Tree Protocol has limit of one octet for port number. This code > fixes: > * bogus unlock in error path when port list is full. > * passes different error status for out of memory, vs > port list full. > * O(n) vs O(n^2) lookup for free port number > * since port and priority are both limited to one byte > don't store them as int's > * makes limit explicit in code Applied, thanks Stephen. From davem@redhat.com Thu Apr 1 14:26:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 14:26:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31MQ0KO029665 for ; Thu, 1 Apr 2004 14:26:00 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i31MPxjj001605; Thu, 1 Apr 2004 17:25:59 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i31MPxj12300; Thu, 1 Apr 2004 17:25:59 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i31MPa1n008889; Thu, 1 Apr 2004 17:25:37 -0500 Date: Thu, 1 Apr 2004 14:25:13 -0800 From: "David S. Miller" To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com Subject: [TIGON3]: Driver test update Message-Id: <20040401142513.7a4e7390.davem@redhat.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__1_Apr_2004_14_25_13_-0800_9IDNYzGP+w3u_eb6" X-archive-position: 4440 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 31078 Lines: 428 This is a multi-part message in MIME format. --Multipart=_Thu__1_Apr_2004_14_25_13_-0800_9IDNYzGP+w3u_eb6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm trying to kill the remaining link detection problems that seem to linger in just about every ethernet driver ever written. :-) Enclosed are patches against current 2.4.x and 2.6.x vanilla kernel tg3 driver sources, give it a go and let me know how it goes. If you're going to report a failure or a "it didn't work before now it does", please include full 'dmesg' output. Thanks. --Multipart=_Thu__1_Apr_2004_14_25_13_-0800_9IDNYzGP+w3u_eb6 Content-Type: application/octet-stream; name="diff24" Content-Disposition: attachment; filename="diff24" Content-Transfer-Encoding: base64 LS0tIG1hcmNlbG8tMi40L2RyaXZlcnMvbmV0L3RnMy5jCTIwMDQtMDQtMDEgMTQ6MjA6NDAuNTY5 NTY4MDAwIC0wODAwCisrKyB0ZzMtMi40L2RyaXZlcnMvbmV0L3RnMy5jCTIwMDQtMDQtMDEgMTQ6 MjE6NTcuOTY5NTY4MDAwIC0wODAwCkBAIC01NSw4ICs1NSw4IEBACiAKICNkZWZpbmUgRFJWX01P RFVMRV9OQU1FCQkidGczIgogI2RlZmluZSBQRlggRFJWX01PRFVMRV9OQU1FCSI6ICIKLSNkZWZp bmUgRFJWX01PRFVMRV9WRVJTSU9OCSIyLjkiCi0jZGVmaW5lIERSVl9NT0RVTEVfUkVMREFURQki TWFyY2ggOCwgMjAwNCIKKyNkZWZpbmUgRFJWX01PRFVMRV9WRVJTSU9OCSIzLjAiCisjZGVmaW5l IERSVl9NT0RVTEVfUkVMREFURQkiQXByaWwgMSwgMjAwNCIKIAogI2RlZmluZSBURzNfREVGX01B Q19NT0RFCTAKICNkZWZpbmUgVEczX0RFRl9SWF9NT0RFCQkwCkBAIC02NDIsNyArNjQyLDE0IEBA CiAJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0RTUF9BRERSRVNTLCAweDgyMDApOwogCXRnM193 cml0ZXBoeSh0cCwgMHgxNiwgMHgwMDAwKTsKIAotCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19B VVhfQ1RSTCwgMHgwNDAwKTsKKwlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ID09IEFTSUNfUkVWXzU3MDMgfHwKKwkgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZf aWQpID09IEFTSUNfUkVWXzU3MDQpIHsKKwkJLyogU2V0IEV4dGVuZGVkIHBhY2tldCBsZW5ndGgg Yml0IGZvciBqdW1ibyBmcmFtZXMgKi8KKwkJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0FVWF9D VFJMLCAweDQ0MDApOworCX0KKwllbHNlIHsKKwkJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0FV WF9DVFJMLCAweDA0MDApOworCX0KIAogCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19DVFJMLCBw aHk5X29yaWcpOwogCkBAIC02NTYsNyArNjYzLDcgQEAKIC8qIFRoaXMgd2lsbCByZXNldCB0aGUg dGlnb24zIFBIWSBpZiB0aGVyZSBpcyBubyB2YWxpZAogICogbGluayB1bmxlc3MgdGhlIEZPUkNF IGFyZ3VtZW50IGlzIG5vbi16ZXJvLgogICovCi1zdGF0aWMgaW50IHRnM19waHlfcmVzZXQoc3Ry dWN0IHRnMyAqdHAsIGludCBmb3JjZSkKK3N0YXRpYyBpbnQgdGczX3BoeV9yZXNldChzdHJ1Y3Qg dGczICp0cCkKIHsKIAl1MzIgcGh5X3N0YXR1czsKIAlpbnQgZXJyOwpAQCAtNjY2LDEyICs2NzMs NiBAQAogCWlmIChlcnIgIT0gMCkKIAkJcmV0dXJuIC1FQlVTWTsKIAotCS8qIElmIHdlIGhhdmUg bGluaywgYW5kIG5vdCBmb3JjaW5nIGEgcmVzZXQsIHRoZW4gbm90aGluZwotCSAqIHRvIGRvLgot CSAqLwotCWlmICgocGh5X3N0YXR1cyAmIEJNU1JfTFNUQVRVUykgIT0gMCAmJiAoZm9yY2UgPT0g MCkpCi0JCXJldHVybiAwOwotCiAJaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lk KSA9PSBBU0lDX1JFVl81NzAzIHx8CiAJICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2 X2lkKSA9PSBBU0lDX1JFVl81NzA0IHx8CiAJICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBf cmV2X2lkKSA9PSBBU0lDX1JFVl81NzA1KSB7CkBAIC02OTgsNiArNjk5LDE1IEBACiAJCXRnM193 cml0ZXBoeSh0cCwgMHgxYywgMHg4ZDY4KTsKIAkJdGczX3dyaXRlcGh5KHRwLCAweDFjLCAweDhk NjgpOwogCX0KKwkvKiBTZXQgRXh0ZW5kZWQgcGFja2V0IGxlbmd0aCBiaXQgKGJpdCAxNCkgb24g YWxsIGNoaXBzIHRoYXQgKi8KKwkvKiBzdXBwb3J0IGp1bWJvIGZyYW1lcyAqLworCWlmICgodHAt PnBoeV9pZCAmIFBIWV9JRF9NQVNLKSA9PSBQSFlfSURfQkNNNTQwMSB8fAorCSAgICAodHAtPnBo eV9pZCAmIFBIWV9JRF9NQVNLKSA9PSBQSFlfSURfQkNNNTQxMSkgeworCQl0ZzNfd3JpdGVwaHko dHAsIE1JSV9URzNfQVVYX0NUUkwsIDB4NGMyMCk7CisJfQorCWVsc2UgaWYgKEdFVF9BU0lDX1JF Vih0cC0+cGNpX2NoaXBfcmV2X2lkKSAhPSBBU0lDX1JFVl81NzA1KSB7CisJCXRnM193cml0ZXBo eSh0cCwgTUlJX1RHM19BVVhfQ1RSTCwgMHg0NDAwKTsKKwl9CiAJdGczX3BoeV9zZXRfd2lyZXNw ZWVkKHRwKTsKIAlyZXR1cm4gMDsKIH0KQEAgLTEwNDksNiArMTA1OSw4IEBACiAJdTMyIG5ld19h ZHY7CiAJaW50IGk7CiAKKwl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfQVVYX0NUUkwsIDB4MDQw MCk7CisKIAlpZiAodHAtPmxpbmtfY29uZmlnLnBoeV9pc19sb3dfcG93ZXIpIHsKIAkJLyogRW50 ZXJpbmcgbG93IHBvd2VyIG1vZGUuICBEaXNhYmxlIGdpZ2FiaXQgYW5kCiAJCSAqIDEwMGJhc2VU IGFkdmVydGlzZW1lbnRzLgpAQCAtMTE4OSw3ICsxMjAxLDggQEAKIAlpbnQgZXJyOwogCiAJLyog VHVybiBvZmYgdGFwIHBvd2VyIG1hbmFnZW1lbnQuICovCi0JZXJyICA9IHRnM193cml0ZXBoeSh0 cCwgTUlJX1RHM19BVVhfQ1RSTCwgMHgwYzIwKTsKKwkvKiBTZXQgRXh0ZW5kZWQgcGFja2V0IGxl bmd0aCBiaXQgKi8KKwllcnIgID0gdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0FVWF9DVFJMLCAw eDRjMjApOwogCiAJZXJyIHw9IHRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19EU1BfQUREUkVTUywg MHgwMDEyKTsKIAllcnIgfD0gdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0RTUF9SV19QT1JULCAw eDE4MDQpOwpAQCAtMTIxMSw2ICsxMjI0LDI3IEBACiAJcmV0dXJuIGVycjsKIH0KIAorc3RhdGlj IGludCB0ZzNfY29wcGVyX2lzX2FkdmVydGlzaW5nX2FsbChzdHJ1Y3QgdGczICp0cCkKK3sKKwl1 MzIgYWR2X3JlZywgYWxsX21hc2s7CisKKwl0ZzNfcmVhZHBoeSh0cCwgTUlJX0FEVkVSVElTRSwg JmFkdl9yZWcpOworCWFsbF9tYXNrID0gKEFEVkVSVElTRV8xMEhBTEYgfCBBRFZFUlRJU0VfMTBG VUxMIHwKKwkJICAgIEFEVkVSVElTRV8xMDBIQUxGIHwgQURWRVJUSVNFXzEwMEZVTEwpOworCWlm ICgoYWR2X3JlZyAmIGFsbF9tYXNrKSAhPSBhbGxfbWFzaykKKwkJcmV0dXJuIDA7CisJaWYgKCEo dHAtPnRnM19mbGFncyAmIFRHM19GTEFHXzEwXzEwMF9PTkxZKSkgeworCQl1MzIgdGczX2N0cmw7 CisKKwkJdGczX3JlYWRwaHkodHAsIE1JSV9URzNfQ1RSTCwgJnRnM19jdHJsKTsKKwkJYWxsX21h c2sgPSAoTUlJX1RHM19DVFJMX0FEVl8xMDAwX0hBTEYgfAorCQkJICAgIE1JSV9URzNfQ1RSTF9B RFZfMTAwMF9GVUxMKTsKKwkJaWYgKCh0ZzNfY3RybCAmIGFsbF9tYXNrKSAhPSBhbGxfbWFzaykK KwkJCXJldHVybiAwOworCX0KKwlyZXR1cm4gMTsKK30KKwogc3RhdGljIGludCB0ZzNfc2V0dXBf Y29wcGVyX3BoeShzdHJ1Y3QgdGczICp0cCwgaW50IGZvcmNlX3Jlc2V0KQogewogCWludCBjdXJy ZW50X2xpbmtfdXA7CkBAIC0xMjM5LDcgKzEyNzMsNyBAQAogCSAqLwogCWlmICgoR0VUX0FTSUNf UkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDMgfHwKIAkgICAgIEdFVF9B U0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzA0IHx8Ci0JICAgICB0 cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTcwNV9BMCkgJiYKKwkgICAgIEdFVF9B U0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzA1KSAmJgogCSAgICBu ZXRpZl9jYXJyaWVyX29rKHRwLT5kZXYpKSB7CiAJCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1TUiwg JmJtc3IpOwogCQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZibXNyKTsKQEAgLTEyNDcsNyAr MTI4MSw3IEBACiAJCQlmb3JjZV9yZXNldCA9IDE7CiAJfQogCWlmIChmb3JjZV9yZXNldCkKLQkJ dGczX3BoeV9yZXNldCh0cCwgMSk7CisJCXRnM19waHlfcmVzZXQodHApOwogCiAJaWYgKCh0cC0+ cGh5X2lkICYgUEhZX0lEX01BU0spID09IFBIWV9JRF9CQ001NDAxKSB7CiAJCXRnM19yZWFkcGh5 KHRwLCBNSUlfQk1TUiwgJmJtc3IpOwpAQCAtMTI3NCw3ICsxMzA4LDcgQEAKIAkJCWlmICgodHAt PnBoeV9pZCAmIFBIWV9JRF9SRVZfTUFTSykgPT0gUEhZX1JFVl9CQ001NDAxX0IwICYmCiAJCQkg ICAgIShibXNyICYgQk1TUl9MU1RBVFVTKSAmJgogCQkJICAgIHRwLT5saW5rX2NvbmZpZy5hY3Rp dmVfc3BlZWQgPT0gU1BFRURfMTAwMCkgewotCQkJCWVyciA9IHRnM19waHlfcmVzZXQodHAsIDEp OworCQkJCWVyciA9IHRnM19waHlfcmVzZXQodHApOwogCQkJCWlmICghZXJyKQogCQkJCQllcnIg PSB0ZzNfaW5pdF81NDAxcGh5X2RzcCh0cCk7CiAJCQkJaWYgKGVycikKQEAgLTEzMDksOCArMTM0 MywxNCBAQAogCWN1cnJlbnRfc3BlZWQgPSBTUEVFRF9JTlZBTElEOwogCWN1cnJlbnRfZHVwbGV4 ID0gRFVQTEVYX0lOVkFMSUQ7CiAKLQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZibXNyKTsK LQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZibXNyKTsKKwlibXNyID0gMDsKKwlmb3IgKGkg PSAwOyBpIDwgMTAwOyBpKyspIHsKKwkJdGczX3JlYWRwaHkodHAsIE1JSV9CTVNSLCAmYm1zcik7 CisJCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1TUiwgJmJtc3IpOworCQlpZiAoYm1zciAmIEJNU1Jf TFNUQVRVUykKKwkJCWJyZWFrOworCQl1ZGVsYXkoNDApOworCX0KIAogCWlmIChibXNyICYgQk1T Ul9MU1RBVFVTKSB7CiAJCXUzMiBhdXhfc3RhdCwgYm1jcjsKQEAgLTEzMjYsMjIgKzEzNjYsMjUg QEAKIAkJdGczX2F1eF9zdGF0X3RvX3NwZWVkX2R1cGxleCh0cCwgYXV4X3N0YXQsCiAJCQkJCSAg ICAgJmN1cnJlbnRfc3BlZWQsCiAJCQkJCSAgICAgJmN1cnJlbnRfZHVwbGV4KTsKLQkJdGczX3Jl YWRwaHkodHAsIE1JSV9CTUNSLCAmYm1jcik7Ci0JCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1DUiwg JmJtY3IpOworCisJCWJtY3IgPSAwOworCQlmb3IgKGkgPSAwOyBpIDwgMjAwOyBpKyspIHsKKwkJ CXRnM19yZWFkcGh5KHRwLCBNSUlfQk1DUiwgJmJtY3IpOworCQkJdGczX3JlYWRwaHkodHAsIE1J SV9CTUNSLCAmYm1jcik7CisJCQlpZiAoYm1jciAmJiBibWNyICE9IDB4N2ZmZikKKwkJCQlicmVh azsKKwkJCXVkZWxheSgxMCk7CisJCX0KKwogCQlpZiAodHAtPmxpbmtfY29uZmlnLmF1dG9uZWcg PT0gQVVUT05FR19FTkFCTEUpIHsKIAkJCWlmIChibWNyICYgQk1DUl9BTkVOQUJMRSkgewotCQkJ CXUzMiBnaWdfY3RybDsKLQogCQkJCWN1cnJlbnRfbGlua191cCA9IDE7CiAKIAkJCQkvKiBGb3Jj ZSBhdXRvbmVnIHJlc3RhcnQgaWYgd2UgYXJlIGV4aXRpbmcKIAkJCQkgKiBsb3cgcG93ZXIgbW9k ZS4KIAkJCQkgKi8KLQkJCQl0ZzNfcmVhZHBoeSh0cCwgTUlJX1RHM19DVFJMLCAmZ2lnX2N0cmwp OwotCQkJCWlmICghKGdpZ19jdHJsICYgKE1JSV9URzNfQ1RSTF9BRFZfMTAwMF9IQUxGIHwKLQkJ CQkJCSAgTUlJX1RHM19DVFJMX0FEVl8xMDAwX0ZVTEwpKSkgeworCQkJCWlmICghdGczX2NvcHBl cl9pc19hZHZlcnRpc2luZ19hbGwodHApKQogCQkJCQljdXJyZW50X2xpbmtfdXAgPSAwOwotCQkJ CX0KIAkJCX0gZWxzZSB7CiAJCQkJY3VycmVudF9saW5rX3VwID0gMDsKIAkJCX0KQEAgLTIwMDMs NiArMjA0NiwxMyBAQAogCQkgICAgICAoNiA8PCBUWF9MRU5HVEhTX0lQR19TSElGVCkgfAogCQkg ICAgICAoMzIgPDwgVFhfTEVOR1RIU19TTE9UX1RJTUVfU0hJRlQpKSk7CiAKKwlpZiAobmV0aWZf Y2Fycmllcl9vayh0cC0+ZGV2KSkgeworCQl0dzMyKEhPU1RDQ19TVEFUX0NPQUxfVElDS1MsCisJ CSAgICAgREVGQVVMVF9TVEFUX0NPQUxfVElDS1MpOworCX0gZWxzZSB7CisJCXR3MzIoSE9TVEND X1NUQVRfQ09BTF9USUNLUywgMCk7CisJfQorCiAJcmV0dXJuIGVycjsKIH0KIApAQCAtNDU0Myw2 ICs0NTkzLDEzIEBACiAJCXR3MzIoVEczUENJX1BDSVNUQVRFLCB2YWwpOwogCX0KIAorCWlmIChH RVRfQ0hJUF9SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQ0hJUFJFVl81NzA0X0JYKSB7CisJ CS8qIEVuYWJsZSBzb21lIGh3IGZpeGVzLiAgKi8KKwkJdmFsID0gdHIzMihURzNQQ0lfTVNJX0RB VEEpOworCQl2YWwgfD0gKDEgPDwgMjYpIHwgKDEgPDwgMjgpIHwgKDEgPDwgMjkpOworCQl0dzMy KFRHM1BDSV9NU0lfREFUQSwgdmFsKTsKKwl9CisKIAkvKiBEZXNjcmlwdG9yIHJpbmcgaW5pdCBt YXkgbWFrZSBhY2Nlc3NlcyB0byB0aGUKIAkgKiBOSUMgU1JBTSBhcmVhIHRvIHNldHVwIHRoZSBU WCBkZXNjcmlwdG9ycywgc28gd2UKIAkgKiBjYW4gb25seSBkbyB0aGlzIGFmdGVyIHRoZSBoYXJk d2FyZSBoYXMgYmVlbgpAQCAtNDU3Myw4ICs0NjMwLDEwIEBACiAJICAgICAoR1JDX01PREVfSVJR X09OX01BQ19BVFROIHwgR1JDX01PREVfSE9TVF9TVEFDS1VQKSk7CiAKIAkvKiBTZXR1cCB0aGUg dGltZXIgcHJlc2NhbGFyIHJlZ2lzdGVyLiAgQ2xvY2sgaXMgYWx3YXlzIDY2TWh6LiAqLwotCXR3 MzIoR1JDX01JU0NfQ0ZHLAotCSAgICAgKDY1IDw8IEdSQ19NSVNDX0NGR19QUkVTQ0FMQVJfU0hJ RlQpKTsKKwl2YWwgPSB0cjMyKEdSQ19NSVNDX0NGRyk7CisJdmFsICY9IH4weGZmOworCXZhbCB8 PSAoNjUgPDwgR1JDX01JU0NfQ0ZHX1BSRVNDQUxBUl9TSElGVCk7CisJdHczMihHUkNfTUlTQ19D RkcsIHZhbCk7CiAKIAkvKiBJbml0aWFsaXplIE1CVUYvREVTQyBwb29sLiAqLwogCWlmIChHRVRf QVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJQ19SRVZfNTcwNSkgewpAQCAtNDYz NSwxOSArNDY5NCw2IEBACiAJCXJldHVybiAtRU5PREVWOwogCX0KIAotCXR3MzIoRlRRX1JFU0VU LCAweGZmZmZmZmZmKTsKLQl0dzMyKEZUUV9SRVNFVCwgMHgwMDAwMDAwMCk7Ci0JZm9yIChpID0g MDsgaSA8IDIwMDA7IGkrKykgewotCQlpZiAodHIzMihGVFFfUkVTRVQpID09IDB4MDAwMDAwMDAp Ci0JCQlicmVhazsKLQkJdWRlbGF5KDEwKTsKLQl9Ci0JaWYgKGkgPj0gMjAwMCkgewotCQlwcmlu dGsoS0VSTl9FUlIgUEZYICJ0ZzNfcmVzZXRfaHcgY2Fubm90IHJlc2V0IEZUUSBmb3IgJXMuXG4i LAotCQkgICAgICAgdHAtPmRldi0+bmFtZSk7Ci0JCXJldHVybiAtRU5PREVWOwotCX0KLQogCS8q IENsZWFyIHN0YXRpc3RpY3Mvc3RhdHVzIGJsb2NrIGluIGNoaXAsIGFuZCBzdGF0dXMgYmxvY2sg aW4gcmFtLiAqLwogCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJ Q19SRVZfNTcwNSkgewogCQlmb3IgKGkgPSBOSUNfU1JBTV9TVEFUU19CTEs7CkBAIC00OTc5LDgg KzUwMjUsMTcgQEAKIAl0dzMyX2YoTUFDX1JYX01PREUsIHRwLT5yeF9tb2RlKTsKIAl1ZGVsYXko MTApOwogCi0JaWYgKHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9JRF81NzAzX0ExKQot CQl0dzMyKE1BQ19TRVJERVNfQ0ZHLCAweDYxNjAwMCk7CisJaWYgKHRwLT5waHlfaWQgPT0gUEhZ X0lEX1NFUkRFUykgeworCQlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09 IEFTSUNfUkVWXzU3MDQpIHsKKwkJCS8qIFNldCBkcml2ZSB0cmFuc21pc3Npb24gbGV2ZWwgdG8g MS4yViAgKi8KKwkJCXZhbCA9IHRyMzIoTUFDX1NFUkRFU19DRkcpOworCQkJdmFsICY9IDB4ZmZm ZmYwMDA7CisJCQl2YWwgfD0gMHg4ODA7CisJCQl0dzMyKE1BQ19TRVJERVNfQ0ZHLCB2YWwpOwor CQl9CisJCWlmICh0cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTcwM19BMSkKKwkJ CXR3MzIoTUFDX1NFUkRFU19DRkcsIDB4NjE2MDAwKTsKKwl9CiAKIAkvKiBQcmV2ZW50IGNoaXAg ZnJvbSBkcm9wcGluZyBmcmFtZXMgd2hlbiBmbG93IGNvbnRyb2wKIAkgKiBpcyBlbmFibGVkLgpA QCAtNTg3MSw2ICs1OTI2LDE2IEBACiAJICAgIHRwLT5saW5rX2NvbmZpZy5waHlfaXNfbG93X3Bv d2VyKQogCQlyZXR1cm4gLUVBR0FJTjsKIAorCWlmICh0cC0+cGh5X2lkID09IFBIWV9JRF9TRVJE RVMpIHsKKwkJLyogVGhlc2UgYXJlIHRoZSBvbmx5IHZhbGlkIGFkdmVydGlzZW1lbnQgYml0cyBh bGxvd2VkLiAgKi8KKwkJaWYgKGNtZC0+YXV0b25lZyA9PSBBVVRPTkVHX0VOQUJMRSAmJgorCQkg ICAgKGNtZC0+YWR2ZXJ0aXNpbmcgJiB+KEFEVkVSVElTRURfMTAwMGJhc2VUX0hhbGYgfAorCQkJ CQkgIEFEVkVSVElTRURfMTAwMGJhc2VUX0Z1bGwgfAorCQkJCQkgIEFEVkVSVElTRURfQXV0b25l ZyB8CisJCQkJCSAgQURWRVJUSVNFRF9GSUJSRSkpKQorCQkJcmV0dXJuIC1FSU5WQUw7CisJfQor CiAJc3Bpbl9sb2NrX2lycSgmdHAtPmxvY2spOwogCXNwaW5fbG9jaygmdHAtPnR4X2xvY2spOwog CkBAIC01ODgwLDYgKzU5NDUsNyBAQAogCQl0cC0+bGlua19jb25maWcuc3BlZWQgPSBTUEVFRF9J TlZBTElEOwogCQl0cC0+bGlua19jb25maWcuZHVwbGV4ID0gRFVQTEVYX0lOVkFMSUQ7CiAJfSBl bHNlIHsKKwkJdHAtPmxpbmtfY29uZmlnLmFkdmVydGlzaW5nID0gMDsKIAkJdHAtPmxpbmtfY29u ZmlnLnNwZWVkID0gY21kLT5zcGVlZDsKIAkJdHAtPmxpbmtfY29uZmlnLmR1cGxleCA9IGNtZC0+ ZHVwbGV4OwogICAJfQpAQCAtNjQ3NiwzOCArNjU0Miw2MSBAQAogCQl9CiAJfQogCi0JZXJyID0g dGczX3BoeV9yZXNldCh0cCwgMSk7Ci0JaWYgKGVycikKLQkJcmV0dXJuIGVycjsKKwlpZiAodHAt PnBoeV9pZCAhPSBQSFlfSURfU0VSREVTICYmCisJICAgICEodHAtPnRnM19mbGFncyAmIFRHM19G TEFHX0VOQUJMRV9BU0YpKSB7CisJCXUzMiBibXNyLCBhZHZfcmVnLCB0ZzNfY3RybDsKIAotCWlm ICh0cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTcwMV9BMCB8fAotCSAgICB0cC0+ cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTcwMV9CMCkgewotCQl1MzIgbWlpX3RnM19j dHJsOwotCQkKLQkJLyogVGhlc2UgY2hpcHMsIHdoZW4gcmVzZXQsIG9ubHkgYWR2ZXJ0aXNlIDEw TWIKLQkJICogY2FwYWJpbGl0aWVzLiAgRml4IHRoYXQuCi0JCSAqLwotCQllcnIgID0gdGczX3dy aXRlcGh5KHRwLCBNSUlfQURWRVJUSVNFLAotCQkJCSAgICAoQURWRVJUSVNFX0NTTUEgfAotCQkJ CSAgICAgQURWRVJUSVNFX1BBVVNFX0NBUCB8Ci0JCQkJICAgICBBRFZFUlRJU0VfMTBIQUxGIHwK LQkJCQkgICAgIEFEVkVSVElTRV8xMEZVTEwgfAotCQkJCSAgICAgQURWRVJUSVNFXzEwMEhBTEYg fAotCQkJCSAgICAgQURWRVJUSVNFXzEwMEZVTEwpKTsKLQkJbWlpX3RnM19jdHJsID0gKE1JSV9U RzNfQ1RSTF9BRFZfMTAwMF9IQUxGIHwKLQkJCQlNSUlfVEczX0NUUkxfQURWXzEwMDBfRlVMTCB8 Ci0JCQkJTUlJX1RHM19DVFJMX0FTX01BU1RFUiB8Ci0JCQkJTUlJX1RHM19DVFJMX0VOQUJMRV9B U19NQVNURVIpOwotCQlpZiAodHAtPnRnM19mbGFncyAmIFRHM19GTEFHXzEwXzEwMF9PTkxZKQot CQkJbWlpX3RnM19jdHJsID0gMDsKKwkJdGczX3JlYWRwaHkodHAsIE1JSV9CTVNSLCAmYm1zcik7 CisJCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1TUiwgJmJtc3IpOworCisJCWlmICgoYm1zciAmIEJN U1JfTFNUQVRVUykgJiYKKwkJICAgICEoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQp ID09IEFTSUNfUkVWXzU3MDMgfHwKKwkJICAgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9y ZXZfaWQpID09IEFTSUNfUkVWXzU3MDQgfHwKKwkJICAgICAgR0VUX0FTSUNfUkVWKHRwLT5wY2lf Y2hpcF9yZXZfaWQpID09IEFTSUNfUkVWXzU3MDUpKQorCQkJZ290byBza2lwX3BoeV9yZXNldDsK KwkJICAgIAorCQllcnIgPSB0ZzNfcGh5X3Jlc2V0KHRwKTsKKwkJaWYgKGVycikKKwkJCXJldHVy biBlcnI7CisKKwkJYWR2X3JlZyA9IChBRFZFUlRJU0VfMTBIQUxGIHwgQURWRVJUSVNFXzEwRlVM TCB8CisJCQkgICBBRFZFUlRJU0VfMTAwSEFMRiB8IEFEVkVSVElTRV8xMDBGVUxMIHwKKwkJCSAg IEFEVkVSVElTRV9DU01BIHwgQURWRVJUSVNFX1BBVVNFX0NBUCk7CisJCXRnM19jdHJsID0gMDsK KwkJaWYgKCEodHAtPnRnM19mbGFncyAmIFRHM19GTEFHXzEwXzEwMF9PTkxZKSkgeworCQkJdGcz X2N0cmwgPSAoTUlJX1RHM19DVFJMX0FEVl8xMDAwX0hBTEYgfAorCQkJCSAgICBNSUlfVEczX0NU UkxfQURWXzEwMDBfRlVMTCk7CisJCQlpZiAodHAtPnBjaV9jaGlwX3Jldl9pZCA9PSBDSElQUkVW X0lEXzU3MDFfQTAgfHwKKwkJCSAgICB0cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURf NTcwMV9CMCkKKwkJCQl0ZzNfY3RybCB8PSAoTUlJX1RHM19DVFJMX0FTX01BU1RFUiB8CisJCQkJ CSAgICAgTUlJX1RHM19DVFJMX0VOQUJMRV9BU19NQVNURVIpOworCQl9CiAKLQkJZXJyIHw9IHRn M193cml0ZXBoeSh0cCwgTUlJX1RHM19DVFJMLCBtaWlfdGczX2N0cmwpOwotCQllcnIgfD0gdGcz X3dyaXRlcGh5KHRwLCBNSUlfQk1DUiwKLQkJCQkgICAgKEJNQ1JfQU5SRVNUQVJUIHwgQk1DUl9B TkVOQUJMRSkpOworCQlpZiAoIXRnM19jb3BwZXJfaXNfYWR2ZXJ0aXNpbmdfYWxsKHRwKSkgewor CQkJdGczX3dyaXRlcGh5KHRwLCBNSUlfQURWRVJUSVNFLCBhZHZfcmVnKTsKKworCQkJaWYgKCEo dHAtPnRnM19mbGFncyAmIFRHM19GTEFHXzEwXzEwMF9PTkxZKSkKKwkJCQl0ZzNfd3JpdGVwaHko dHAsIE1JSV9URzNfQ1RSTCwgdGczX2N0cmwpOworCisJCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9C TUNSLAorCQkJCSAgICAgQk1DUl9BTkVOQUJMRSB8IEJNQ1JfQU5SRVNUQVJUKTsKKwkJfQorCQl0 ZzNfcGh5X3NldF93aXJlc3BlZWQodHApOworCisJCXRnM193cml0ZXBoeSh0cCwgTUlJX0FEVkVS VElTRSwgYWR2X3JlZyk7CisJCWlmICghKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR18xMF8xMDBf T05MWSkpCisJCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfQ1RSTCwgdGczX2N0cmwpOworCX0K Kworc2tpcF9waHlfcmVzZXQ6CisJaWYgKCh0cC0+cGh5X2lkICYgUEhZX0lEX01BU0spID09IFBI WV9JRF9CQ001NDAxKSB7CisJCWVyciA9IHRnM19pbml0XzU0MDFwaHlfZHNwKHRwKTsKKwkJaWYg KGVycikKKwkJCXJldHVybiBlcnI7CiAJfQogCiAJaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2No aXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzAzKSB7Ci0JCXRnM193cml0ZXBoeSh0cCwgTUlJX1RH M19BVVhfQ1RSTCwgMHgwYzAwKTsKKwkJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0FVWF9DVFJM LCAweDRjMDApOwogCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfRFNQX0FERFJFU1MsIDB4MjAx Zik7CiAJCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19EU1BfUldfUE9SVCwgMHgyYWFhKTsKIAl9 Cg== --Multipart=_Thu__1_Apr_2004_14_25_13_-0800_9IDNYzGP+w3u_eb6 Content-Type: application/octet-stream; name="diff26" Content-Disposition: attachment; filename="diff26" Content-Transfer-Encoding: base64 LS0tIGxpbnVzLTIuNi9kcml2ZXJzL25ldC90ZzMuYwkyMDA0LTAzLTMxIDE1OjE0OjU1LjAwMDAw MDAwMCAtMDgwMAorKysgdGczLTIuNi9kcml2ZXJzL25ldC90ZzMuYwkyMDA0LTA0LTAxIDE0OjIx OjQxLjA4OTU2ODAwMCAtMDgwMApAQCAtNTYsOCArNTYsOCBAQAogCiAjZGVmaW5lIERSVl9NT0RV TEVfTkFNRQkJInRnMyIKICNkZWZpbmUgUEZYIERSVl9NT0RVTEVfTkFNRQkiOiAiCi0jZGVmaW5l IERSVl9NT0RVTEVfVkVSU0lPTgkiMi45IgotI2RlZmluZSBEUlZfTU9EVUxFX1JFTERBVEUJIk1h cmNoIDgsIDIwMDQiCisjZGVmaW5lIERSVl9NT0RVTEVfVkVSU0lPTgkiMy4wIgorI2RlZmluZSBE UlZfTU9EVUxFX1JFTERBVEUJIkFwcmlsIDEsIDIwMDQiCiAKICNkZWZpbmUgVEczX0RFRl9NQUNf TU9ERQkwCiAjZGVmaW5lIFRHM19ERUZfUlhfTU9ERQkJMApAQCAtNjQzLDcgKzY0MywxNCBAQAog CXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19EU1BfQUREUkVTUywgMHg4MjAwKTsKIAl0ZzNfd3Jp dGVwaHkodHAsIDB4MTYsIDB4MDAwMCk7CiAKLQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfQVVY X0NUUkwsIDB4MDQwMCk7CisJaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9 PSBBU0lDX1JFVl81NzAzIHx8CisJICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lk KSA9PSBBU0lDX1JFVl81NzA0KSB7CisJCS8qIFNldCBFeHRlbmRlZCBwYWNrZXQgbGVuZ3RoIGJp dCBmb3IganVtYm8gZnJhbWVzICovCisJCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19BVVhfQ1RS TCwgMHg0NDAwKTsKKwl9CisJZWxzZSB7CisJCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19BVVhf Q1RSTCwgMHgwNDAwKTsKKwl9CiAKIAl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfQ1RSTCwgcGh5 OV9vcmlnKTsKIApAQCAtNjU3LDcgKzY2NCw3IEBACiAvKiBUaGlzIHdpbGwgcmVzZXQgdGhlIHRp Z29uMyBQSFkgaWYgdGhlcmUgaXMgbm8gdmFsaWQKICAqIGxpbmsgdW5sZXNzIHRoZSBGT1JDRSBh cmd1bWVudCBpcyBub24temVyby4KICAqLwotc3RhdGljIGludCB0ZzNfcGh5X3Jlc2V0KHN0cnVj dCB0ZzMgKnRwLCBpbnQgZm9yY2UpCitzdGF0aWMgaW50IHRnM19waHlfcmVzZXQoc3RydWN0IHRn MyAqdHApCiB7CiAJdTMyIHBoeV9zdGF0dXM7CiAJaW50IGVycjsKQEAgLTY2NywxMiArNjc0LDYg QEAKIAlpZiAoZXJyICE9IDApCiAJCXJldHVybiAtRUJVU1k7CiAKLQkvKiBJZiB3ZSBoYXZlIGxp bmssIGFuZCBub3QgZm9yY2luZyBhIHJlc2V0LCB0aGVuIG5vdGhpbmcKLQkgKiB0byBkby4KLQkg Ki8KLQlpZiAoKHBoeV9zdGF0dXMgJiBCTVNSX0xTVEFUVVMpICE9IDAgJiYgKGZvcmNlID09IDAp KQotCQlyZXR1cm4gMDsKLQogCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkg PT0gQVNJQ19SRVZfNTcwMyB8fAogCSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jldl9p ZCkgPT0gQVNJQ19SRVZfNTcwNCB8fAogCSAgICBHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlwX3Jl dl9pZCkgPT0gQVNJQ19SRVZfNTcwNSkgewpAQCAtNjk5LDYgKzcwMCwxNSBAQAogCQl0ZzNfd3Jp dGVwaHkodHAsIDB4MWMsIDB4OGQ2OCk7CiAJCXRnM193cml0ZXBoeSh0cCwgMHgxYywgMHg4ZDY4 KTsKIAl9CisJLyogU2V0IEV4dGVuZGVkIHBhY2tldCBsZW5ndGggYml0IChiaXQgMTQpIG9uIGFs bCBjaGlwcyB0aGF0ICovCisJLyogc3VwcG9ydCBqdW1ibyBmcmFtZXMgKi8KKwlpZiAoKHRwLT5w aHlfaWQgJiBQSFlfSURfTUFTSykgPT0gUEhZX0lEX0JDTTU0MDEgfHwKKwkgICAgKHRwLT5waHlf aWQgJiBQSFlfSURfTUFTSykgPT0gUEhZX0lEX0JDTTU0MTEpIHsKKwkJdGczX3dyaXRlcGh5KHRw LCBNSUlfVEczX0FVWF9DVFJMLCAweDRjMjApOworCX0KKwllbHNlIGlmIChHRVRfQVNJQ19SRVYo dHAtPnBjaV9jaGlwX3Jldl9pZCkgIT0gQVNJQ19SRVZfNTcwNSkgeworCQl0ZzNfd3JpdGVwaHko dHAsIE1JSV9URzNfQVVYX0NUUkwsIDB4NDQwMCk7CisJfQogCXRnM19waHlfc2V0X3dpcmVzcGVl ZCh0cCk7CiAJcmV0dXJuIDA7CiB9CkBAIC0xMDUwLDYgKzEwNjAsOCBAQAogCXUzMiBuZXdfYWR2 OwogCWludCBpOwogCisJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0FVWF9DVFJMLCAweDA0MDAp OworCiAJaWYgKHRwLT5saW5rX2NvbmZpZy5waHlfaXNfbG93X3Bvd2VyKSB7CiAJCS8qIEVudGVy aW5nIGxvdyBwb3dlciBtb2RlLiAgRGlzYWJsZSBnaWdhYml0IGFuZAogCQkgKiAxMDBiYXNlVCBh ZHZlcnRpc2VtZW50cy4KQEAgLTExOTAsNyArMTIwMiw4IEBACiAJaW50IGVycjsKIAogCS8qIFR1 cm4gb2ZmIHRhcCBwb3dlciBtYW5hZ2VtZW50LiAqLwotCWVyciAgPSB0ZzNfd3JpdGVwaHkodHAs IE1JSV9URzNfQVVYX0NUUkwsIDB4MGMyMCk7CisJLyogU2V0IEV4dGVuZGVkIHBhY2tldCBsZW5n dGggYml0ICovCisJZXJyICA9IHRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19BVVhfQ1RSTCwgMHg0 YzIwKTsKIAogCWVyciB8PSB0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfRFNQX0FERFJFU1MsIDB4 MDAxMik7CiAJZXJyIHw9IHRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19EU1BfUldfUE9SVCwgMHgx ODA0KTsKQEAgLTEyMTIsNiArMTIyNSwyNyBAQAogCXJldHVybiBlcnI7CiB9CiAKK3N0YXRpYyBp bnQgdGczX2NvcHBlcl9pc19hZHZlcnRpc2luZ19hbGwoc3RydWN0IHRnMyAqdHApCit7CisJdTMy IGFkdl9yZWcsIGFsbF9tYXNrOworCisJdGczX3JlYWRwaHkodHAsIE1JSV9BRFZFUlRJU0UsICZh ZHZfcmVnKTsKKwlhbGxfbWFzayA9IChBRFZFUlRJU0VfMTBIQUxGIHwgQURWRVJUSVNFXzEwRlVM TCB8CisJCSAgICBBRFZFUlRJU0VfMTAwSEFMRiB8IEFEVkVSVElTRV8xMDBGVUxMKTsKKwlpZiAo KGFkdl9yZWcgJiBhbGxfbWFzaykgIT0gYWxsX21hc2spCisJCXJldHVybiAwOworCWlmICghKHRw LT50ZzNfZmxhZ3MgJiBURzNfRkxBR18xMF8xMDBfT05MWSkpIHsKKwkJdTMyIHRnM19jdHJsOwor CisJCXRnM19yZWFkcGh5KHRwLCBNSUlfVEczX0NUUkwsICZ0ZzNfY3RybCk7CisJCWFsbF9tYXNr ID0gKE1JSV9URzNfQ1RSTF9BRFZfMTAwMF9IQUxGIHwKKwkJCSAgICBNSUlfVEczX0NUUkxfQURW XzEwMDBfRlVMTCk7CisJCWlmICgodGczX2N0cmwgJiBhbGxfbWFzaykgIT0gYWxsX21hc2spCisJ CQlyZXR1cm4gMDsKKwl9CisJcmV0dXJuIDE7Cit9CisKIHN0YXRpYyBpbnQgdGczX3NldHVwX2Nv cHBlcl9waHkoc3RydWN0IHRnMyAqdHAsIGludCBmb3JjZV9yZXNldCkKIHsKIAlpbnQgY3VycmVu dF9saW5rX3VwOwpAQCAtMTI0MCw3ICsxMjc0LDcgQEAKIAkgKi8KIAlpZiAoKEdFVF9BU0lDX1JF Vih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzAzIHx8CiAJICAgICBHRVRfQVNJ Q19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwNCB8fAotCSAgICAgdHAt PnBjaV9jaGlwX3Jldl9pZCA9PSBDSElQUkVWX0lEXzU3MDVfQTApICYmCisJICAgICBHRVRfQVNJ Q19SRVYodHAtPnBjaV9jaGlwX3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwNSkgJiYKIAkgICAgbmV0 aWZfY2Fycmllcl9vayh0cC0+ZGV2KSkgewogCQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZi bXNyKTsKIAkJdGczX3JlYWRwaHkodHAsIE1JSV9CTVNSLCAmYm1zcik7CkBAIC0xMjQ4LDcgKzEy ODIsNyBAQAogCQkJZm9yY2VfcmVzZXQgPSAxOwogCX0KIAlpZiAoZm9yY2VfcmVzZXQpCi0JCXRn M19waHlfcmVzZXQodHAsIDEpOworCQl0ZzNfcGh5X3Jlc2V0KHRwKTsKIAogCWlmICgodHAtPnBo eV9pZCAmIFBIWV9JRF9NQVNLKSA9PSBQSFlfSURfQkNNNTQwMSkgewogCQl0ZzNfcmVhZHBoeSh0 cCwgTUlJX0JNU1IsICZibXNyKTsKQEAgLTEyNzUsNyArMTMwOSw3IEBACiAJCQlpZiAoKHRwLT5w aHlfaWQgJiBQSFlfSURfUkVWX01BU0spID09IFBIWV9SRVZfQkNNNTQwMV9CMCAmJgogCQkJICAg ICEoYm1zciAmIEJNU1JfTFNUQVRVUykgJiYKIAkJCSAgICB0cC0+bGlua19jb25maWcuYWN0aXZl X3NwZWVkID09IFNQRUVEXzEwMDApIHsKLQkJCQllcnIgPSB0ZzNfcGh5X3Jlc2V0KHRwLCAxKTsK KwkJCQllcnIgPSB0ZzNfcGh5X3Jlc2V0KHRwKTsKIAkJCQlpZiAoIWVycikKIAkJCQkJZXJyID0g dGczX2luaXRfNTQwMXBoeV9kc3AodHApOwogCQkJCWlmIChlcnIpCkBAIC0xMzEwLDggKzEzNDQs MTQgQEAKIAljdXJyZW50X3NwZWVkID0gU1BFRURfSU5WQUxJRDsKIAljdXJyZW50X2R1cGxleCA9 IERVUExFWF9JTlZBTElEOwogCi0JdGczX3JlYWRwaHkodHAsIE1JSV9CTVNSLCAmYm1zcik7Ci0J dGczX3JlYWRwaHkodHAsIE1JSV9CTVNSLCAmYm1zcik7CisJYm1zciA9IDA7CisJZm9yIChpID0g MDsgaSA8IDEwMDsgaSsrKSB7CisJCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1TUiwgJmJtc3IpOwor CQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZibXNyKTsKKwkJaWYgKGJtc3IgJiBCTVNSX0xT VEFUVVMpCisJCQlicmVhazsKKwkJdWRlbGF5KDQwKTsKKwl9CiAKIAlpZiAoYm1zciAmIEJNU1Jf TFNUQVRVUykgewogCQl1MzIgYXV4X3N0YXQsIGJtY3I7CkBAIC0xMzI3LDIyICsxMzY3LDI1IEBA CiAJCXRnM19hdXhfc3RhdF90b19zcGVlZF9kdXBsZXgodHAsIGF1eF9zdGF0LAogCQkJCQkgICAg ICZjdXJyZW50X3NwZWVkLAogCQkJCQkgICAgICZjdXJyZW50X2R1cGxleCk7Ci0JCXRnM19yZWFk cGh5KHRwLCBNSUlfQk1DUiwgJmJtY3IpOwotCQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNQ1IsICZi bWNyKTsKKworCQlibWNyID0gMDsKKwkJZm9yIChpID0gMDsgaSA8IDIwMDsgaSsrKSB7CisJCQl0 ZzNfcmVhZHBoeSh0cCwgTUlJX0JNQ1IsICZibWNyKTsKKwkJCXRnM19yZWFkcGh5KHRwLCBNSUlf Qk1DUiwgJmJtY3IpOworCQkJaWYgKGJtY3IgJiYgYm1jciAhPSAweDdmZmYpCisJCQkJYnJlYWs7 CisJCQl1ZGVsYXkoMTApOworCQl9CisKIAkJaWYgKHRwLT5saW5rX2NvbmZpZy5hdXRvbmVnID09 IEFVVE9ORUdfRU5BQkxFKSB7CiAJCQlpZiAoYm1jciAmIEJNQ1JfQU5FTkFCTEUpIHsKLQkJCQl1 MzIgZ2lnX2N0cmw7Ci0KIAkJCQljdXJyZW50X2xpbmtfdXAgPSAxOwogCiAJCQkJLyogRm9yY2Ug YXV0b25lZyByZXN0YXJ0IGlmIHdlIGFyZSBleGl0aW5nCiAJCQkJICogbG93IHBvd2VyIG1vZGUu CiAJCQkJICovCi0JCQkJdGczX3JlYWRwaHkodHAsIE1JSV9URzNfQ1RSTCwgJmdpZ19jdHJsKTsK LQkJCQlpZiAoIShnaWdfY3RybCAmIChNSUlfVEczX0NUUkxfQURWXzEwMDBfSEFMRiB8Ci0JCQkJ CQkgIE1JSV9URzNfQ1RSTF9BRFZfMTAwMF9GVUxMKSkpIHsKKwkJCQlpZiAoIXRnM19jb3BwZXJf aXNfYWR2ZXJ0aXNpbmdfYWxsKHRwKSkKIAkJCQkJY3VycmVudF9saW5rX3VwID0gMDsKLQkJCQl9 CiAJCQl9IGVsc2UgewogCQkJCWN1cnJlbnRfbGlua191cCA9IDA7CiAJCQl9CkBAIC0yMDA0LDYg KzIwNDcsMTMgQEAKIAkJICAgICAgKDYgPDwgVFhfTEVOR1RIU19JUEdfU0hJRlQpIHwKIAkJICAg ICAgKDMyIDw8IFRYX0xFTkdUSFNfU0xPVF9USU1FX1NISUZUKSkpOwogCisJaWYgKG5ldGlmX2Nh cnJpZXJfb2sodHAtPmRldikpIHsKKwkJdHczMihIT1NUQ0NfU1RBVF9DT0FMX1RJQ0tTLAorCQkg ICAgIERFRkFVTFRfU1RBVF9DT0FMX1RJQ0tTKTsKKwl9IGVsc2UgeworCQl0dzMyKEhPU1RDQ19T VEFUX0NPQUxfVElDS1MsIDApOworCX0KKwogCXJldHVybiBlcnI7CiB9CiAKQEAgLTQ1NTIsNiAr NDYwMiwxMyBAQAogCQl0dzMyKFRHM1BDSV9QQ0lTVEFURSwgdmFsKTsKIAl9CiAKKwlpZiAoR0VU X0NISVBfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpID09IENISVBSRVZfNTcwNF9CWCkgeworCQkv KiBFbmFibGUgc29tZSBodyBmaXhlcy4gICovCisJCXZhbCA9IHRyMzIoVEczUENJX01TSV9EQVRB KTsKKwkJdmFsIHw9ICgxIDw8IDI2KSB8ICgxIDw8IDI4KSB8ICgxIDw8IDI5KTsKKwkJdHczMihU RzNQQ0lfTVNJX0RBVEEsIHZhbCk7CisJfQorCiAJLyogRGVzY3JpcHRvciByaW5nIGluaXQgbWF5 IG1ha2UgYWNjZXNzZXMgdG8gdGhlCiAJICogTklDIFNSQU0gYXJlYSB0byBzZXR1cCB0aGUgVFgg ZGVzY3JpcHRvcnMsIHNvIHdlCiAJICogY2FuIG9ubHkgZG8gdGhpcyBhZnRlciB0aGUgaGFyZHdh cmUgaGFzIGJlZW4KQEAgLTQ1ODIsOCArNDYzOSwxMCBAQAogCSAgICAgKEdSQ19NT0RFX0lSUV9P Tl9NQUNfQVRUTiB8IEdSQ19NT0RFX0hPU1RfU1RBQ0tVUCkpOwogCiAJLyogU2V0dXAgdGhlIHRp bWVyIHByZXNjYWxhciByZWdpc3Rlci4gIENsb2NrIGlzIGFsd2F5cyA2Nk1oei4gKi8KLQl0dzMy KEdSQ19NSVNDX0NGRywKLQkgICAgICg2NSA8PCBHUkNfTUlTQ19DRkdfUFJFU0NBTEFSX1NISUZU KSk7CisJdmFsID0gdHIzMihHUkNfTUlTQ19DRkcpOworCXZhbCAmPSB+MHhmZjsKKwl2YWwgfD0g KDY1IDw8IEdSQ19NSVNDX0NGR19QUkVTQ0FMQVJfU0hJRlQpOworCXR3MzIoR1JDX01JU0NfQ0ZH LCB2YWwpOwogCiAJLyogSW5pdGlhbGl6ZSBNQlVGL0RFU0MgcG9vbC4gKi8KIAlpZiAoR0VUX0FT SUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNfUkVWXzU3MDUpIHsKQEAgLTQ2NDQs MTkgKzQ3MDMsNiBAQAogCQlyZXR1cm4gLUVOT0RFVjsKIAl9CiAKLQl0dzMyKEZUUV9SRVNFVCwg MHhmZmZmZmZmZik7Ci0JdHczMihGVFFfUkVTRVQsIDB4MDAwMDAwMDApOwotCWZvciAoaSA9IDA7 IGkgPCAyMDAwOyBpKyspIHsKLQkJaWYgKHRyMzIoRlRRX1JFU0VUKSA9PSAweDAwMDAwMDAwKQot CQkJYnJlYWs7Ci0JCXVkZWxheSgxMCk7Ci0JfQotCWlmIChpID49IDIwMDApIHsKLQkJcHJpbnRr KEtFUk5fRVJSIFBGWCAidGczX3Jlc2V0X2h3IGNhbm5vdCByZXNldCBGVFEgZm9yICVzLlxuIiwK LQkJICAgICAgIHRwLT5kZXYtPm5hbWUpOwotCQlyZXR1cm4gLUVOT0RFVjsKLQl9Ci0KIAkvKiBD bGVhciBzdGF0aXN0aWNzL3N0YXR1cyBibG9jayBpbiBjaGlwLCBhbmQgc3RhdHVzIGJsb2NrIGlu IHJhbS4gKi8KIAlpZiAoR0VUX0FTSUNfUkVWKHRwLT5wY2lfY2hpcF9yZXZfaWQpICE9IEFTSUNf UkVWXzU3MDUpIHsKIAkJZm9yIChpID0gTklDX1NSQU1fU1RBVFNfQkxLOwpAQCAtNDk4OCw4ICs1 MDM0LDE3IEBACiAJdHczMl9mKE1BQ19SWF9NT0RFLCB0cC0+cnhfbW9kZSk7CiAJdWRlbGF5KDEw KTsKIAotCWlmICh0cC0+cGNpX2NoaXBfcmV2X2lkID09IENISVBSRVZfSURfNTcwM19BMSkKLQkJ dHczMihNQUNfU0VSREVTX0NGRywgMHg2MTYwMDApOworCWlmICh0cC0+cGh5X2lkID09IFBIWV9J RF9TRVJERVMpIHsKKwkJaWYgKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9PSBB U0lDX1JFVl81NzA0KSB7CisJCQkvKiBTZXQgZHJpdmUgdHJhbnNtaXNzaW9uIGxldmVsIHRvIDEu MlYgICovCisJCQl2YWwgPSB0cjMyKE1BQ19TRVJERVNfQ0ZHKTsKKwkJCXZhbCAmPSAweGZmZmZm MDAwOworCQkJdmFsIHw9IDB4ODgwOworCQkJdHczMihNQUNfU0VSREVTX0NGRywgdmFsKTsKKwkJ fQorCQlpZiAodHAtPnBjaV9jaGlwX3Jldl9pZCA9PSBDSElQUkVWX0lEXzU3MDNfQTEpCisJCQl0 dzMyKE1BQ19TRVJERVNfQ0ZHLCAweDYxNjAwMCk7CisJfQogCiAJLyogUHJldmVudCBjaGlwIGZy b20gZHJvcHBpbmcgZnJhbWVzIHdoZW4gZmxvdyBjb250cm9sCiAJICogaXMgZW5hYmxlZC4KQEAg LTU4ODIsNiArNTkzNywxNiBAQAogCSAgICB0cC0+bGlua19jb25maWcucGh5X2lzX2xvd19wb3dl cikKIAkJcmV0dXJuIC1FQUdBSU47CiAKKwlpZiAodHAtPnBoeV9pZCA9PSBQSFlfSURfU0VSREVT KSB7CisJCS8qIFRoZXNlIGFyZSB0aGUgb25seSB2YWxpZCBhZHZlcnRpc2VtZW50IGJpdHMgYWxs b3dlZC4gICovCisJCWlmIChjbWQtPmF1dG9uZWcgPT0gQVVUT05FR19FTkFCTEUgJiYKKwkJICAg IChjbWQtPmFkdmVydGlzaW5nICYgfihBRFZFUlRJU0VEXzEwMDBiYXNlVF9IYWxmIHwKKwkJCQkJ ICBBRFZFUlRJU0VEXzEwMDBiYXNlVF9GdWxsIHwKKwkJCQkJICBBRFZFUlRJU0VEX0F1dG9uZWcg fAorCQkJCQkgIEFEVkVSVElTRURfRklCUkUpKSkKKwkJCXJldHVybiAtRUlOVkFMOworCX0KKwog CXNwaW5fbG9ja19pcnEoJnRwLT5sb2NrKTsKIAlzcGluX2xvY2soJnRwLT50eF9sb2NrKTsKIApA QCAtNTg5MSw2ICs1OTU2LDcgQEAKIAkJdHAtPmxpbmtfY29uZmlnLnNwZWVkID0gU1BFRURfSU5W QUxJRDsKIAkJdHAtPmxpbmtfY29uZmlnLmR1cGxleCA9IERVUExFWF9JTlZBTElEOwogCX0gZWxz ZSB7CisJCXRwLT5saW5rX2NvbmZpZy5hZHZlcnRpc2luZyA9IDA7CiAJCXRwLT5saW5rX2NvbmZp Zy5zcGVlZCA9IGNtZC0+c3BlZWQ7CiAJCXRwLT5saW5rX2NvbmZpZy5kdXBsZXggPSBjbWQtPmR1 cGxleDsKICAgCX0KQEAgLTY0ODcsMzggKzY1NTMsNjEgQEAKIAkJfQogCX0KIAotCWVyciA9IHRn M19waHlfcmVzZXQodHAsIDEpOwotCWlmIChlcnIpCi0JCXJldHVybiBlcnI7CisJaWYgKHRwLT5w aHlfaWQgIT0gUEhZX0lEX1NFUkRFUyAmJgorCSAgICAhKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxB R19FTkFCTEVfQVNGKSkgeworCQl1MzIgYm1zciwgYWR2X3JlZywgdGczX2N0cmw7CiAKLQlpZiAo dHAtPnBjaV9jaGlwX3Jldl9pZCA9PSBDSElQUkVWX0lEXzU3MDFfQTAgfHwKLQkgICAgdHAtPnBj aV9jaGlwX3Jldl9pZCA9PSBDSElQUkVWX0lEXzU3MDFfQjApIHsKLQkJdTMyIG1paV90ZzNfY3Ry bDsKLQkJCi0JCS8qIFRoZXNlIGNoaXBzLCB3aGVuIHJlc2V0LCBvbmx5IGFkdmVydGlzZSAxME1i Ci0JCSAqIGNhcGFiaWxpdGllcy4gIEZpeCB0aGF0LgotCQkgKi8KLQkJZXJyICA9IHRnM193cml0 ZXBoeSh0cCwgTUlJX0FEVkVSVElTRSwKLQkJCQkgICAgKEFEVkVSVElTRV9DU01BIHwKLQkJCQkg ICAgIEFEVkVSVElTRV9QQVVTRV9DQVAgfAotCQkJCSAgICAgQURWRVJUSVNFXzEwSEFMRiB8Ci0J CQkJICAgICBBRFZFUlRJU0VfMTBGVUxMIHwKLQkJCQkgICAgIEFEVkVSVElTRV8xMDBIQUxGIHwK LQkJCQkgICAgIEFEVkVSVElTRV8xMDBGVUxMKSk7Ci0JCW1paV90ZzNfY3RybCA9IChNSUlfVEcz X0NUUkxfQURWXzEwMDBfSEFMRiB8Ci0JCQkJTUlJX1RHM19DVFJMX0FEVl8xMDAwX0ZVTEwgfAot CQkJCU1JSV9URzNfQ1RSTF9BU19NQVNURVIgfAotCQkJCU1JSV9URzNfQ1RSTF9FTkFCTEVfQVNf TUFTVEVSKTsKLQkJaWYgKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR18xMF8xMDBfT05MWSkKLQkJ CW1paV90ZzNfY3RybCA9IDA7CisJCXRnM19yZWFkcGh5KHRwLCBNSUlfQk1TUiwgJmJtc3IpOwor CQl0ZzNfcmVhZHBoeSh0cCwgTUlJX0JNU1IsICZibXNyKTsKKworCQlpZiAoKGJtc3IgJiBCTVNS X0xTVEFUVVMpICYmCisJCSAgICAhKEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2X2lkKSA9 PSBBU0lDX1JFVl81NzAzIHx8CisJCSAgICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2NoaXBfcmV2 X2lkKSA9PSBBU0lDX1JFVl81NzA0IHx8CisJCSAgICAgIEdFVF9BU0lDX1JFVih0cC0+cGNpX2No aXBfcmV2X2lkKSA9PSBBU0lDX1JFVl81NzA1KSkKKwkJCWdvdG8gc2tpcF9waHlfcmVzZXQ7CisJ CSAgICAKKwkJZXJyID0gdGczX3BoeV9yZXNldCh0cCk7CisJCWlmIChlcnIpCisJCQlyZXR1cm4g ZXJyOworCisJCWFkdl9yZWcgPSAoQURWRVJUSVNFXzEwSEFMRiB8IEFEVkVSVElTRV8xMEZVTEwg fAorCQkJICAgQURWRVJUSVNFXzEwMEhBTEYgfCBBRFZFUlRJU0VfMTAwRlVMTCB8CisJCQkgICBB RFZFUlRJU0VfQ1NNQSB8IEFEVkVSVElTRV9QQVVTRV9DQVApOworCQl0ZzNfY3RybCA9IDA7CisJ CWlmICghKHRwLT50ZzNfZmxhZ3MgJiBURzNfRkxBR18xMF8xMDBfT05MWSkpIHsKKwkJCXRnM19j dHJsID0gKE1JSV9URzNfQ1RSTF9BRFZfMTAwMF9IQUxGIHwKKwkJCQkgICAgTUlJX1RHM19DVFJM X0FEVl8xMDAwX0ZVTEwpOworCQkJaWYgKHRwLT5wY2lfY2hpcF9yZXZfaWQgPT0gQ0hJUFJFVl9J RF81NzAxX0EwIHx8CisJCQkgICAgdHAtPnBjaV9jaGlwX3Jldl9pZCA9PSBDSElQUkVWX0lEXzU3 MDFfQjApCisJCQkJdGczX2N0cmwgfD0gKE1JSV9URzNfQ1RSTF9BU19NQVNURVIgfAorCQkJCQkg ICAgIE1JSV9URzNfQ1RSTF9FTkFCTEVfQVNfTUFTVEVSKTsKKwkJfQogCi0JCWVyciB8PSB0ZzNf d3JpdGVwaHkodHAsIE1JSV9URzNfQ1RSTCwgbWlpX3RnM19jdHJsKTsKLQkJZXJyIHw9IHRnM193 cml0ZXBoeSh0cCwgTUlJX0JNQ1IsCi0JCQkJICAgIChCTUNSX0FOUkVTVEFSVCB8IEJNQ1JfQU5F TkFCTEUpKTsKKwkJaWYgKCF0ZzNfY29wcGVyX2lzX2FkdmVydGlzaW5nX2FsbCh0cCkpIHsKKwkJ CXRnM193cml0ZXBoeSh0cCwgTUlJX0FEVkVSVElTRSwgYWR2X3JlZyk7CisKKwkJCWlmICghKHRw LT50ZzNfZmxhZ3MgJiBURzNfRkxBR18xMF8xMDBfT05MWSkpCisJCQkJdGczX3dyaXRlcGh5KHRw LCBNSUlfVEczX0NUUkwsIHRnM19jdHJsKTsKKworCQkJdGczX3dyaXRlcGh5KHRwLCBNSUlfQk1D UiwKKwkJCQkgICAgIEJNQ1JfQU5FTkFCTEUgfCBCTUNSX0FOUkVTVEFSVCk7CisJCX0KKwkJdGcz X3BoeV9zZXRfd2lyZXNwZWVkKHRwKTsKKworCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9BRFZFUlRJ U0UsIGFkdl9yZWcpOworCQlpZiAoISh0cC0+dGczX2ZsYWdzICYgVEczX0ZMQUdfMTBfMTAwX09O TFkpKQorCQkJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0NUUkwsIHRnM19jdHJsKTsKKwl9CisK K3NraXBfcGh5X3Jlc2V0OgorCWlmICgodHAtPnBoeV9pZCAmIFBIWV9JRF9NQVNLKSA9PSBQSFlf SURfQkNNNTQwMSkgeworCQllcnIgPSB0ZzNfaW5pdF81NDAxcGh5X2RzcCh0cCk7CisJCWlmIChl cnIpCisJCQlyZXR1cm4gZXJyOwogCX0KIAogCWlmIChHRVRfQVNJQ19SRVYodHAtPnBjaV9jaGlw X3Jldl9pZCkgPT0gQVNJQ19SRVZfNTcwMykgewotCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNf QVVYX0NUUkwsIDB4MGMwMCk7CisJCXRnM193cml0ZXBoeSh0cCwgTUlJX1RHM19BVVhfQ1RSTCwg MHg0YzAwKTsKIAkJdGczX3dyaXRlcGh5KHRwLCBNSUlfVEczX0RTUF9BRERSRVNTLCAweDIwMWYp OwogCQl0ZzNfd3JpdGVwaHkodHAsIE1JSV9URzNfRFNQX1JXX1BPUlQsIDB4MmFhYSk7CiAJfQo= --Multipart=_Thu__1_Apr_2004_14_25_13_-0800_9IDNYzGP+w3u_eb6-- From romieu@fr.zoreil.com Thu Apr 1 15:05:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 15:05:29 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31N5NKO031337 for ; Thu, 1 Apr 2004 15:05:24 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i31N3pgf031195; Fri, 2 Apr 2004 01:03:51 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i31N3pCK031194; Fri, 2 Apr 2004 01:03:51 +0200 Date: Fri, 2 Apr 2004 01:03:51 +0200 From: Francois Romieu To: Maciek Moskal Cc: netdev@oss.sgi.com Subject: Re: Problem witch Your patch to kernel 2.4.26-pre2 ? Message-ID: <20040402010351.A29887@electric-eye.fr.zoreil.com> References: <1080777461.4358.58.camel@b6.kei.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1080777461.4358.58.camel@b6.kei.pl>; from maciek@kei.pl on Thu, Apr 01, 2004 at 01:57:43AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4441 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 200 Lines: 10 Maciek Moskal : [bad experience with r8169 driver in 2.4.26-pre2] You may try: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.26-rc1/r8169-mammoth-attack.patch Please keep netdev Cc:ed. -- Ueimor From christopherc@team.outblaze.com Thu Apr 1 16:55:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 16:56:01 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i320twKO011344 for ; Thu, 1 Apr 2004 16:55:59 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id B880E37AF0 for ; Fri, 2 Apr 2004 00:55:58 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id 6BC4316DD85 for ; Fri, 2 Apr 2004 00:55:58 +0000 (GMT) Received: (qmail 1864 invoked from network); 2 Apr 2004 00:55:52 -0000 Received: from unknown (HELO outblaze.com) (christopherc@team.outblaze.com@210.177.227.130) by smtp1.hk1.outblaze.com with SMTP; 2 Apr 2004 00:55:52 -0000 Message-ID: <406CBA60.50103@outblaze.com> Date: Fri, 02 Apr 2004 08:57:05 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: Yusuf Goolamabbas Subject: High number of concurrent connections causes 2.6.4 to go berserk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.7; VDF: 6.24.0.79; host: corpmail.outblaze.com) X-archive-position: 4442 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 695 Lines: 22 KERNEL: assertion (flags & MSG_PEEK) failed a[t net/ipv4/tcp.c (1571) KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK | MSG_TRUNC))) failed at net/ipv4/tcp.c (1635) These are repeated in the logs during kernel berserk period postfix is running on this box. It is set to spawn max 750 smtpd processes to handle incoming smtp sessions. When tcp_max_syn_backlog is set to 4096 and route.max_size = 131072 route.gc_thresh = 65536 the box goes berserk almost immediately after bootup due to a bounce flood hitting the box. The below values seem to workaround whatever problem the kernel has. tcp_max_syn_backlog = 2048 route.max_size = 1048576 route.gc_thresh = 65536 From niv@us.ibm.com Thu Apr 1 19:31:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 19:31:54 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i323VfKO020027 for ; Thu, 1 Apr 2004 19:31:47 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i323VZG9650132; Thu, 1 Apr 2004 22:31:35 -0500 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i323VTGC109444; Thu, 1 Apr 2004 22:31:33 -0500 Message-ID: <406CDDF5.4070500@us.ibm.com> Date: Thu, 01 Apr 2004 19:28:53 -0800 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christopher Chan CC: netdev@oss.sgi.com, Yusuf Goolamabbas Subject: Re: High number of concurrent connections causes 2.6.4 to go berserk References: <406CBA60.50103@outblaze.com> In-Reply-To: <406CBA60.50103@outblaze.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4443 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 543 Lines: 24 Christopher Chan wrote: > When tcp_max_syn_backlog is set to 4096 and > route.max_size = 131072 > route.gc_thresh = 65536 > > the box goes berserk almost immediately after bootup due to a bounce > flood hitting the box. > The below values seem to workaround whatever problem the kernel has. > > tcp_max_syn_backlog = 2048 > route.max_size = 1048576 > route.gc_thresh = 65536 Did you try just one of the first two and see which one actually made a difference? I'm assuming the first, but that might not be the case.. thanks, Nivedita From cchan@outblaze.com Thu Apr 1 20:00:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 01 Apr 2004 20:01:02 -0800 (PST) Received: from 192-246.netfront.net (246-192.netfront.net [202.81.246.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3240hKO021422 for ; Thu, 1 Apr 2004 20:00:44 -0800 Received: from outblaze.com (localhost [127.0.0.1]) by 192-246.netfront.net (Postfix) with ESMTP id 341DFEAE70; Fri, 2 Apr 2004 12:00:36 +0800 (HKT) Message-ID: <406CE563.5090105@outblaze.com> Date: Fri, 02 Apr 2004 12:00:35 +0800 From: Christopher Chan User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi Cc: netdev@oss.sgi.com, Yusuf Goolamabbas Subject: Re: High number of concurrent connections causes 2.6.4 to go berserk References: <406CBA60.50103@outblaze.com> <406CDDF5.4070500@us.ibm.com> In-Reply-To: <406CDDF5.4070500@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4444 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 879 Lines: 40 Nivedita Singhvi wrote: > Christopher Chan wrote: > >> When tcp_max_syn_backlog is set to 4096 and >> route.max_size = 131072 >> route.gc_thresh = 65536 >> >> the box goes berserk almost immediately after bootup due to a bounce >> flood hitting the box. > > >> The below values seem to workaround whatever problem the kernel has. >> >> tcp_max_syn_backlog = 2048 >> route.max_size = 1048576 >> route.gc_thresh = 65536 > > > Did you try just one of the first two and see which > one actually made a difference? I'm assuming the first, > but that might not be the case.. Another box that has less traffic but sometimes gets ddosed by bounces has default settings tcp_max_syn_backlog = 1024 route.max_size = 131072 route.gc_thresh = 8192 This box's 2.6.4 also went berserk during the ddos. I'll try your suggestion and get back to you. > > thanks, > Nivedita > > > From christopherc@team.outblaze.com Fri Apr 2 08:36:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 08:36:28 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32GaEKO012208 for ; Fri, 2 Apr 2004 08:36:15 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 57AA837B0E for ; Fri, 2 Apr 2004 16:36:15 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id C0F3116DD94 for ; Fri, 2 Apr 2004 16:36:14 +0000 (GMT) Received: (qmail 12048 invoked from network); 2 Apr 2004 16:36:08 -0000 Received: from unknown (HELO outblaze.com) (christopherc@team.outblaze.com@210.177.227.130) by smtp1.hk1.outblaze.com with SMTP; 2 Apr 2004 16:36:08 -0000 Message-ID: <406D96C1.2000901@outblaze.com> Date: Sat, 03 Apr 2004 00:37:21 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nivedita Singhvi Cc: netdev@oss.sgi.com, Yusuf Goolamabbas Subject: Re: High number of concurrent connections causes 2.6.4 to go berserk References: <406CBA60.50103@outblaze.com> <406CDDF5.4070500@us.ibm.com> In-Reply-To: <406CDDF5.4070500@us.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.7; VDF: 6.24.0.83; host: corpmail.outblaze.com) X-archive-position: 4445 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 1180 Lines: 34 >> The below values seem to workaround whatever problem the kernel has. >> >> tcp_max_syn_backlog = 2048 >> route.max_size = 1048576 >> route.gc_thresh = 65536 I take that back. Under peak hours, the kernel starts spewing its stuff onto serial console and network connectivity is lost. What it spews is not human readable anymore. eg: 3->g:asag6A &| rKEt d n SE1PERUELnet p-15 ( t bL:(D3laEED1 f))sspv/ipi 3->g:asag6A &| <3leaititv4d_>r<3_npiti (q G__TRNtd (c p. =msRN||E1(f_P33KNC: t/ne>c7116p-ug ala7gsK 2 a) sev4ipie<6) : ssgsA & M3>ediliocp/tsre3>nxieio(M E_PTRNE na(t (.c==sgNE| 1DflPE3D)C) a/ietco1)63->g:asag6A | ai fer4/pved6> cvcses s MMS>Kd leonp.tceqc>KxtedonMSE1PERUELnet p(1c = g EL (D3laEED1 f)asipt/op) 3->g:asag6A | ai fer4/pved6> cvcoes s MMS>Kd leonp.tceqc>KxtedonMSE1PERUELnet p-1c = g EL (D3laEED1 f))sipt/op) 3->g:asag6A &| r<3_npiti eqSGG_ERatd (ccpq vmER | E (G_D3EKNC:et n->57(1tpbu: fl37gsK12fa) sev4ipie<6) c csesA & M3>ediliocp/tseec>nxieio(M E_PTRNE nattp(.c==sgNE| 1DflPE3D) ))asietco1)63->g:asag6A &| r<3_npiti eqSGG_ERatd (c p. =msRN| E (G_D3EKNC: t/ne>c711tpbu: fl37gsK 2 a) sev4ipi From tmattox@seahawk.ecc.engr.uky.edu Fri Apr 2 12:34:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 12:34:06 -0800 (PST) Received: from seahawk.ecc.engr.uky.edu (seahawk.ecc.engr.uky.edu [128.163.144.83]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32KY0KO022225 for ; Fri, 2 Apr 2004 12:34:01 -0800 Received: from tmattox (helo=localhost) by seahawk.ecc.engr.uky.edu with local-esmtp (Exim 4.30) id 1B9VBO-0001B4-3N; Fri, 02 Apr 2004 15:22:30 -0500 Date: Fri, 2 Apr 2004 15:22:30 -0500 (EST) From: Timothy I Mattox X-X-Sender: tmattox@seahawk To: jgarzik@pobox.com cc: tulip-users@lists.sourceforge.net, Subject: [PATCH] tulip, kernel 2.4.26-rc1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4446 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 2921 Lines: 67 Here is a patch for the tulip driver found in kernel 2.4.26-rc1 This adds MII functionality to the ADMtek Comet flavor of the tulip, specifically, the ability to detect and report the link status with MII. I've tested on several Linksys LNE100TX v4.1 PCI cards, as well as on an HP Pavilion N5475 laptop with a built-in NIC that is detected as this same model of chip. This patch was modeled after Donald Becker's tulip.c:v0.98 1/8/2004, but the specific bits from his driver have been there for about two years. Please apply to 2.4 mainline. If this is accepted, I will convert & test it for the 2.6 kernel series as well. -- Tim Mattox - tmattox at engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ diff -Naur -p linux-2.4.26-rc1/drivers/net/tulip/ChangeLog linux-2.4.26-rc1-comet/drivers/net/tulip/ChangeLog --- linux-2.4.26-rc1/drivers/net/tulip/ChangeLog Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc1-comet/drivers/net/tulip/ChangeLog Fri Apr 2 14:58:31 2004 @@ -1,3 +1,11 @@ +2004-04-02 Tim Mattox + + Add MII support for ADMtek Comet (Linksys LNE100TX v4.1 & others): + * tulip_core.c: add HAS_MII flag to COMET entry in tulip_tbl[] + * timer.c (comet_timer): add missing call to tulip_check_duplex() + and replace inl() calls with tulip_mdio_read() calls + Changes modeled after Donald Becker's tulip.c:v0.98 1/8/2004 + 2002-09-18 Ryan Bradetich tulip hppa support: diff -Naur -p linux-2.4.26-rc1/drivers/net/tulip/timer.c linux-2.4.26-rc1-comet/drivers/net/tulip/timer.c --- linux-2.4.26-rc1/drivers/net/tulip/timer.c Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc1-comet/drivers/net/tulip/timer.c Fri Apr 2 14:36:51 2004 @@ -211,10 +211,16 @@ void comet_timer(unsigned long data) if (tulip_debug > 1) printk(KERN_DEBUG "%s: Comet link status %4.4x partner capability " "%4.4x.\n", - dev->name, inl(ioaddr + 0xB8), inl(ioaddr + 0xC8)); + dev->name, + tulip_mdio_read(dev, tp->phys[0], 1), + tulip_mdio_read(dev, tp->phys[0], 5)); /* mod_timer synchronizes us with potential add_timer calls * from interrupts. */ + if (tulip_check_duplex(dev) < 0) + { /* netif_carrier_off(dev); */ } + else + { /* netif_carrier_on(dev); */ } mod_timer(&tp->timer, RUN_AT(next_tick)); } diff -Naur -p linux-2.4.26-rc1/drivers/net/tulip/tulip_core.c linux-2.4.26-rc1-comet/drivers/net/tulip/tulip_core.c --- linux-2.4.26-rc1/drivers/net/tulip/tulip_core.c Fri Apr 2 14:31:27 2004 +++ linux-2.4.26-rc1-comet/drivers/net/tulip/tulip_core.c Fri Apr 2 14:36:38 2004 @@ -176,7 +176,7 @@ struct tulip_chip_table tulip_tbl[] = { /* COMET */ { "ADMtek Comet", 256, 0x0001abef, - MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, + HAS_MII | MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, /* COMPEX9881 */ { "Compex 9881 PMAC", 128, 0x0001ebef, From romieu@fr.zoreil.com Fri Apr 2 15:01:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 15:01:34 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32N1RKO026157 for ; Fri, 2 Apr 2004 15:01:28 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i32N0ngf014197; Sat, 3 Apr 2004 01:00:49 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i32N0jpU014196; Sat, 3 Apr 2004 01:00:45 +0200 Date: Sat, 3 Apr 2004 01:00:45 +0200 From: Francois Romieu To: Andi Kleen Cc: jgarzik@pobox.com, netdev@oss.sgi.com, Srihari Vijayaraghavan Subject: [patch] 2.6.5-rc2 - r8169 DAC Message-ID: <20040403010045.A12904@electric-eye.fr.zoreil.com> References: <20040329193604.A4744@electric-eye.fr.zoreil.com> <20040329144034.3d943d12.ak@suse.de> <20040329223513.C4744@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040329223513.C4744@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Mar 29, 2004 at 10:35:13PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4447 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 7177 Lines: 246 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline By popular request, patch for DAC on r8169 is available at: http://www.fr.zoreil.com/people/francois/misc/20040403-2.6.5-rc2-r8169.c-test.patch It applies against 2.6.5-rc2 (i.e. anything 2.6.5-rcX I guess). The incremental patches against the latest serie of r8169 patches posted on netdev is attached. A tester on a x86-32 and a tester on something-64 bits would be _really_ welcome. -- Ueimor --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-dac-00.patch" DMA_{32/64}BIT_MASK for all. include/linux/dma-mapping.h | 3 +++ 1 files changed, 3 insertions(+) diff -puN include/linux/dma-mapping.h~r8169-dac-00 include/linux/dma-mapping.h --- linux-2.6.5-rc2/include/linux/dma-mapping.h~r8169-dac-00 2004-04-03 00:29:17.000000000 +0200 +++ linux-2.6.5-rc2-fr/include/linux/dma-mapping.h 2004-04-03 00:29:17.000000000 +0200 @@ -10,6 +10,9 @@ enum dma_data_direction { DMA_NONE = 3, }; +#define DMA_64BIT_MASK 0xffffffffffffffffULL +#define DMA_32BIT_MASK 0x00000000ffffffffULL + #include /* Backwards compat, remove in 2.7.x */ _ --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="r8169-dac-10.patch" DAC experience: - Rx and Tx descriptors rings handled on 64 bit; - enable DAC through use of CPlusCmd register (reserved bits apart, this is similar to the 8139cp driver); - use the higher 32 bits of addresses for the Rx/Tx buffers. linux/dma-mapping.h | 0 drivers/net/r8169.c | 66 ++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 46 insertions(+), 20 deletions(-) diff -puN drivers/net/r8169.c~r8169-dac-10 drivers/net/r8169.c --- linux-2.6.5-rc2/drivers/net/r8169.c~r8169-dac-10 2004-04-03 00:29:35.000000000 +0200 +++ linux-2.6.5-rc2-fr/drivers/net/r8169.c 2004-04-03 00:29:35.000000000 +0200 @@ -152,8 +152,10 @@ static int rx_copybreak = 200; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ MAR0 = 8, /* Multicast filter. */ - TxDescStartAddr = 0x20, - TxHDescStartAddr = 0x28, + TxDescStartAddrLow = 0x20, + TxDescStartAddrHigh = 0x24, + TxHDescStartAddrLow = 0x28, + TxHDescStartAddrHigh = 0x2c, FLASH = 0x30, ERSR = 0x36, ChipCmd = 0x37, @@ -178,7 +180,8 @@ enum RTL8169_registers { PHYstatus = 0x6C, RxMaxSize = 0xDA, CPlusCmd = 0xE0, - RxDescStartAddr = 0xE4, + RxDescAddrLow = 0xE4, + RxDescAddrHigh = 0xE8, EarlyTxThres = 0xEC, FuncEvent = 0xF0, FuncEventMask = 0xF4, @@ -230,7 +233,13 @@ enum RTL8169_register_content { /*TxConfigBits */ TxInterFrameGapShift = 24, - TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ + TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ + + /* CPlusCmd p.31 */ + RxVlan = (1 << 6), + RxChkSum = (1 << 5), + PCIDAC = (1 << 4), + PCIMulRW = (1 << 3), /*rtl8169_PHYstatus */ TBI_Enable = 0x80, @@ -289,15 +298,13 @@ enum _DescStatusBit { struct TxDesc { u32 status; u32 vlan_tag; - u32 buf_addr; - u32 buf_Haddr; + u64 addr; }; struct RxDesc { u32 status; u32 vlan_tag; - u32 buf_addr; - u32 buf_Haddr; + u64 addr; }; struct rtl8169_private { @@ -320,6 +327,7 @@ struct rtl8169_private { struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ struct timer_list timer; unsigned long phy_link_down_cnt; + u16 cp_cmd; }; MODULE_AUTHOR("Realtek"); @@ -716,6 +724,20 @@ rtl8169_init_board(struct pci_dev *pdev, goto err_out_disable; } + tp->cp_cmd = PCIMulRW | RxChkSum; + + if ((sizeof(dma_addr_t) > 32) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) + tp->cp_cmd |= PCIDAC; + else { + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); + if (rc < 0) { + printk(KERN_ERR PFX "DMA configuration failed.\n"); + goto err_out_free_res; + } + } + + // enable PCI bus-mastering pci_set_master(pdev); @@ -1102,17 +1124,21 @@ rtl8169_hw_start(struct net_device *dev) RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << TxInterFrameGapShift)); - RTL_W16(CPlusCmd, RTL_R16(CPlusCmd)); + tp->cp_cmd |= RTL_R16(CPlusCmd); + RTL_W16(CPlusCmd, tp->cp_cmd); if (tp->mac_version == RTL_GIGA_MAC_VER_D) { dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0: bit-3 and bit-14 MUST be 1\n"); - RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | (1 << 14) | (1 << 3)); + tp->cp_cmd |= (1 << 14) | PCIMulRW; + RTL_W16(CPlusCmd, tp->cp_cmd); } tp->cur_rx = 0; - RTL_W32(TxDescStartAddr, tp->TxPhyAddr); - RTL_W32(RxDescStartAddr, tp->RxPhyAddr); + RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); + RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); RTL_W8(Cfg9346, Cfg9346_Lock); udelay(10); @@ -1132,14 +1158,14 @@ rtl8169_hw_start(struct net_device *dev) static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { - desc->buf_addr = 0xdeadbeef; + desc->addr = 0x0badbadbadbadbad; desc->status &= ~cpu_to_le32(OWNbit | RsvdMask); } static void rtl8169_free_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff, struct RxDesc *desc) { - pci_unmap_single(pdev, le32_to_cpu(desc->buf_addr), RX_BUF_SIZE, + pci_unmap_single(pdev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); dev_kfree_skb(*sk_buff); *sk_buff = NULL; @@ -1153,7 +1179,7 @@ static inline void rtl8169_return_to_asi static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping) { - desc->buf_addr = cpu_to_le32(mapping); + desc->addr = cpu_to_le64(mapping); desc->status |= cpu_to_le32(OWNbit + RX_BUF_SIZE); } @@ -1251,9 +1277,9 @@ static void rtl8169_unmap_tx_skb(struct { u32 len = sk_buff[0]->len; - pci_unmap_single(pdev, le32_to_cpu(desc->buf_addr), + pci_unmap_single(pdev, le64_to_cpu(desc->addr), len < ETH_ZLEN ? ETH_ZLEN : len, PCI_DMA_TODEVICE); - desc->buf_addr = 0x00; + desc->addr = 0x00; *sk_buff = NULL; } @@ -1325,7 +1351,7 @@ rtl8169_start_xmit(struct sk_buff *skb, PCI_DMA_TODEVICE); tp->Tx_skbuff[entry] = skb; - tp->TxDescArray[entry].buf_addr = cpu_to_le32(mapping); + tp->TxDescArray[entry].addr = cpu_to_le64(mapping); tp->TxDescArray[entry].status = cpu_to_le32(OWNbit | FSbit | LSbit | len | (EORbit * !((entry + 1) % NUM_TX_DESC))); @@ -1452,7 +1478,7 @@ rtl8169_rx_interrupt(struct net_device * pci_dma_sync_single_for_cpu(tp->pci_dev, - le32_to_cpu(desc->buf_addr), RX_BUF_SIZE, + le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); if (rtl8169_try_rx_copy(&skb, pkt_size, desc, dev)) { @@ -1460,7 +1486,7 @@ rtl8169_rx_interrupt(struct net_device * tp->Rx_skbuff[entry] = NULL; } - pci_action(tp->pci_dev, le32_to_cpu(desc->buf_addr), + pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); skb_put(skb, pkt_size); diff -puN include/linux/dma-mapping.h~r8169-dac-10 include/linux/dma-mapping.h _ --FL5UXtIhxfXey3p5-- From akpm@osdl.org Fri Apr 2 15:34:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 15:34:29 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32NYRKO027773 for ; Fri, 2 Apr 2004 15:34:27 -0800 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i32NYD226046; Fri, 2 Apr 2004 15:34:14 -0800 Date: Fri, 2 Apr 2004 15:36:28 -0800 From: Andrew Morton To: Marco Fais Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-Id: <20040402153628.4a09d979.akpm@osdl.org> In-Reply-To: <406D3E8F.20902@abbeynet.it> References: <406D3E8F.20902@abbeynet.it> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4448 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: 1963 Lines: 56 (linux-2.4.25) Marco Fais wrote: > > kernel BUG at page_alloc.c:98! > uh-oh. > > > >EIP; c01372ae <__free_pages_ok+26e/280> <===== > > > >ebx; c14b3f00 <_end+116e728/204d48a8> > > >ecx; c14b3f00 <_end+116e728/204d48a8> > > >edi; dec11340 <_end+1e8cbb68/204d48a8> > > >ebp; c02f1d04 > > >esp; c02f1cd4 > > Trace; c0135a76 > Trace; c021667b > Trace; c02166b4 > Trace; c0216816 <__kfree_skb+106/160> > Trace; c023be39 > Trace; c023c385 > Trace; c023f51c > Trace; c02465a9 > Trace; c0246a76 > Trace; c022dad0 > Trace; c022dc25 > Trace; c0222780 > Trace; c022dad0 > Trace; c022d88f > Trace; c022dad0 > Trace; c022de3a > Trace; e08d7eab <[8139too]rtl8139_rx_interrupt+6b/3b0> > Trace; c021ad14 > Trace; c021ae3f > Trace; c021af5a > Trace; c0121cd7 > Trace; c010a66d distcc uses sendfile(). The 8139too hardware and driver are zerocopy-capable so the kernel uses zerocopy direct-from-user-pages for sendfile(). The bug is that the networking layer is releasing the final ref to user pages from softirq context. Those pages are still on the page LRU so __free_pages_ok() will take them off. Problem is, removing these pages from the LRU requires that the pagemap_lru_lock be taken, and that lock may not be taken from interrupt context. So we go BUG instead. This was all discussed fairly extensively a couple of years back and I thought it ended up being fixed. From harisri@bigpond.com Fri Apr 2 18:07:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 18:07:52 -0800 (PST) Received: from gizmo10bw.bigpond.com (gizmo10bw.bigpond.com [144.140.70.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3327kKO002756 for ; Fri, 2 Apr 2004 18:07:47 -0800 Received: (qmail 22303 invoked from network); 3 Apr 2004 02:03:30 -0000 Received: from unknown (HELO bwmam02.bigpond.com) (144.135.24.72) by gizmo10bw.bigpond.com with SMTP; 3 Apr 2004 02:03:30 -0000 Received: from bzpp-p-144-138-166-105.prem.tmns.net.au ([144.138.166.105]) by bwmam02.bigpond.com(MAM REL_3_4_2 11/34929230) with SMTP id 34929230; Sat, 03 Apr 2004 12:07:38 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [patch] 2.6.5-rc2 - r8169 DAC Date: Sat, 3 Apr 2004 12:08:16 +1000 User-Agent: KMail/1.5.4 Cc: jgarzik@pobox.com, netdev@oss.sgi.com, Andi Kleen References: <20040329193604.A4744@electric-eye.fr.zoreil.com> <20040329223513.C4744@electric-eye.fr.zoreil.com> <20040403010045.A12904@electric-eye.fr.zoreil.com> In-Reply-To: <20040403010045.A12904@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404031208.17066.harisri@bigpond.com> X-archive-position: 4449 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Content-Length: 1322 Lines: 36 Hello Francois, On Saturday 03 April 2004 09:00, Francois Romieu wrote: > By popular request, patch for DAC on r8169 is available at: > http://www.fr.zoreil.com/people/francois/misc/20040403-2.6.5-rc2-r8169.c-te >st.patch > > It applies against 2.6.5-rc2 (i.e. anything 2.6.5-rcX I guess). Yes it does apply cleanly on both 2.6.5-rc2 and 2.6.5-rc3. > A tester on a x86-32 and a tester on something-64 bits would be _really_ > welcome. I can test your patch on x86-64, but it does not compile. Here is the error message (same error message on both 2.6.5-rc2 and 2.6.5-rc3): CC [M] drivers/net/r8169.o drivers/net/r8169.c: In function `rtl8169_init_board': drivers/net/r8169.c:730: error: `DMA_64BIT_MASK' undeclared (first use in this function) drivers/net/r8169.c:730: error: (Each undeclared identifier is reported only once drivers/net/r8169.c:730: error: for each function it appears in.) drivers/net/r8169.c:733: error: `DMA_32BIT_MASK' undeclared (first use in this function) drivers/net/r8169.c: In function `rtl8169_hw_start': drivers/net/r8169.c:1138: error: `DMA_32BIT_MASK' undeclared (first use in this function) make[2]: *** [drivers/net/r8169.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 CC net/core/dev.o make: *** Waiting for unfinished jobs.... Thanks Hari From jgarzik@pobox.com Fri Apr 2 18:25:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 02 Apr 2004 18:26:15 -0800 (PST) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i332PrKO003491 for ; Fri, 2 Apr 2004 18:25:56 -0800 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1B8LJb-0006xN-ET; Tue, 30 Mar 2004 16:38:11 +0100 Message-ID: <40699457.1020304@pobox.com> Date: Tue, 30 Mar 2004 10:37:59 -0500 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: [patch 0/4] 2.6.5-rc2-mm5 - r8169 queue References: <20040329193604.A4744@electric-eye.fr.zoreil.com> <4068656D.2080103@pobox.com> <20040329211441.B4744@electric-eye.fr.zoreil.com> In-Reply-To: <20040329211441.B4744@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4450 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: 770 Lines: 29 Francois Romieu wrote: > Jeff Garzik : > [...] > >>I am pondering taking your latest version of r8169, and moving the >>phy-related code from there to 8139cp.c. Then just add >> MODULE_ALIAS("r8169"); >>and deleting r8169.c. >> >>The rationale is, 8169 is _exactly_ the same as 8139C+, except the phy >>code and one or two bits in the chip registers. I would rather have >>just one codebase, supporting one MAC (i.e. the RX/TX part) and multiple >>phys. > > > It seems appealing. Do you have a specific schedule in mind ? schedules are an anathema to me ;-) I was thinking about getting your initial patches into 2.6.x upstream so that r8169 users at least have something usable while the phy code gets moved over to 8139cp.c. Jeff From romieu@fr.zoreil.com Sat Apr 3 00:21:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 00:22:21 -0800 (PST) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i338LRKO018234 for ; Sat, 3 Apr 2004 00:21:30 -0800 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i338Jugf018871; Sat, 3 Apr 2004 10:19:57 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i338JsaB018870; Sat, 3 Apr 2004 10:19:54 +0200 Date: Sat, 3 Apr 2004 10:19:54 +0200 From: Francois Romieu To: Srihari Vijayaraghavan Cc: jgarzik@pobox.com, netdev@oss.sgi.com, Andi Kleen Subject: Re: [patch] 2.6.5-rc2 - r8169 DAC Message-ID: <20040403101954.A18810@electric-eye.fr.zoreil.com> References: <20040329193604.A4744@electric-eye.fr.zoreil.com> <20040329223513.C4744@electric-eye.fr.zoreil.com> <20040403010045.A12904@electric-eye.fr.zoreil.com> <200404031208.17066.harisri@bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200404031208.17066.harisri@bigpond.com>; from harisri@bigpond.com on Sat, Apr 03, 2004 at 12:08:16PM +1000 X-Organisation: Land of Sunshine Inc. X-archive-position: 4451 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 678 Lines: 25 Srihari Vijayaraghavan : [compile error message] DMA_{32/64}BIT_MASK for all. include/linux/dma-mapping.h | 3 +++ 1 files changed, 3 insertions(+) diff -puN include/linux/dma-mapping.h~r8169-dac-00 include/linux/dma-mapping.h --- linux-2.6.5-rc2/include/linux/dma-mapping.h~r8169-dac-00 2004-04-03 00:29:17.000000000 +0200 +++ linux-2.6.5-rc2-fr/include/linux/dma-mapping.h 2004-04-03 00:29:17.000000000 +0200 @@ -10,6 +10,9 @@ enum dma_data_direction { DMA_NONE = 3, }; +#define DMA_64BIT_MASK 0xffffffffffffffffULL +#define DMA_32BIT_MASK 0x00000000ffffffffULL + #include /* Backwards compat, remove in 2.7.x */ _ From cranium2003@yahoo.com Sat Apr 3 07:07:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 07:07:17 -0800 (PST) Received: from web41414.mail.yahoo.com (web41414.mail.yahoo.com [66.218.93.80]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33F7GKO004402 for ; Sat, 3 Apr 2004 07:07:16 -0800 Message-ID: <20040403150711.81930.qmail@web41414.mail.yahoo.com> Received: from [61.11.18.134] by web41414.mail.yahoo.com via HTTP; Sat, 03 Apr 2004 07:07:11 PST Date: Sat, 3 Apr 2004 07:07:11 -0800 (PST) From: Parag Nemade Subject: kernel development netwrok protocol modification To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4452 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 819 Lines: 25 hello friends, I want to add my own routine to network protocol stack. What i want to do i will explain you. For each and every packet that outgoes from kernel i want to attach a 8 byte of my own checksum to data part in packet. This ensures that data is to be transmitted correctly across computers. Can anybody help me where i have to insert my code in kernel source tree cause there are 3 programs to be included in which one exchanges keys adjecent computers. second calculates checksum on basis of that key. and third checks packet replay. I wish to be personally CC'ed the answers/comments posted to the list in response to my posting. regards, Parag. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ From manfred@colorfullife.com Sat Apr 3 11:43:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 11:43:05 -0800 (PST) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33JgvKO015703 for ; Sat, 3 Apr 2004 11:42:58 -0800 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i33JgP06017587; Sat, 3 Apr 2004 21:42:27 +0200 Message-ID: <406F13A1.4030201@colorfullife.com> Date: Sat, 03 Apr 2004 21:42:25 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org CC: Michal Wronski , Krzysztof Benedyczak Subject: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) Content-Type: multipart/mixed; boundary="------------020509080401080507010703" X-archive-position: 4453 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 17972 Lines: 637 This is a multi-part message in MIME format. --------------020509080401080507010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit mq_notify(SIGEV_THREAD) must be implemented in user space. If an event is triggered, the kernel must send a notification to user space, and then glibc must create the thread with the requested attributes for the notification callback. The current implementation in Andrew's -mm tree uses single shot file descriptor - it works, but it's resource hungry. Attached is a new proposal: - split netlink_unicast into separate substeps - use an AF_NETLINK socket for the message queue notification What do you think? -- Manfred --------------020509080401080507010703 Content-Type: text/plain; name="patch-mqueue-netlink" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-mqueue-netlink" // $Header$ // Kernel Version: // VERSION = 2 // PATCHLEVEL = 6 // SUBLEVEL = 5 // EXTRAVERSION =-rc3-mm1 --- 2.6/include/linux/netlink.h 2004-04-03 14:29:26.000000000 +0200 +++ build-2.6/include/linux/netlink.h 2004-04-03 21:05:11.525685846 +0200 @@ -120,6 +120,13 @@ extern int netlink_register_notifier(struct notifier_block *nb); extern int netlink_unregister_notifier(struct notifier_block *nb); +/* finegrained unicast helpers: */ +struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid); +struct sock *netlink_getsockbyfilp(struct file *filp); +int netlink_attachskb(struct sock *sk, struct sk_buff *skb, int nonblock, long timeo); +void netlink_detachskb(struct sock *sk, struct sk_buff *skb); +int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol); + /* * skb should fit one page. This choice is good for headerless malloc. * --- 2.6/net/netlink/af_netlink.c 2004-03-31 18:36:32.000000000 +0200 +++ build-2.6/net/netlink/af_netlink.c 2004-04-03 21:30:26.147554044 +0200 @@ -415,38 +415,66 @@ } } -int netlink_unicast(struct sock *ssk, struct sk_buff *skb, u32 pid, int nonblock) +struct sock *netlink_getsockbypid(struct sock *ssk, u32 pid) { - struct sock *sk; - struct netlink_opt *nlk; - int len = skb->len; int protocol = ssk->sk_protocol; - long timeo; - DECLARE_WAITQUEUE(wait, current); - - timeo = sock_sndtimeo(ssk, nonblock); + struct sock *sock; + struct netlink_opt *nlk; -retry: - sk = netlink_lookup(protocol, pid); - if (sk == NULL) - goto no_dst; - nlk = nlk_sk(sk); + sock = netlink_lookup(protocol, pid); + if (!sock) + return ERR_PTR(-ECONNREFUSED); /* Don't bother queuing skb if kernel socket has no input function */ - if (nlk->pid == 0 && !nlk->data_ready) - goto no_dst; + nlk = nlk_sk(sock); + if (nlk->pid == 0 && !nlk->data_ready) { + sock_put(sock); + return ERR_PTR(-ECONNREFUSED); + } + return sock; +} + +struct sock *netlink_getsockbyfilp(struct file *filp) +{ + struct inode *inode = filp->f_dentry->d_inode; + struct socket *socket; + struct sock *sock; + + if (!inode->i_sock || !(socket = SOCKET_I(inode))) + return ERR_PTR(-ENOTSOCK); + + sock = socket->sk; + if (sock->sk_family != AF_NETLINK) + return ERR_PTR(-EINVAL); + + sock_hold(sock); + return sock; +} + +/* + * Attach a skb to a netlink socket. + * The caller must hold a reference to the destination socket. On error, the + * reference is dropped. The skb is not send to the destination, just all + * all error checks are performed and memory in the queue is reserved. + * Return values: + * < 0: error. skb freed, reference to sock dropped. + * 0: continue + * 1: repeat lookup - reference dropped while waiting for socket memory. + */ +int netlink_attachskb(struct sock *sk, struct sk_buff *skb, int nonblock, long timeo) +{ + struct netlink_opt *nlk; + + nlk = nlk_sk(sk); #ifdef NL_EMULATE_DEV - if (nlk->handler) { - skb_orphan(skb); - len = nlk->handler(protocol, skb); - sock_put(sk); - return len; - } + if (nlk->handler) + return 0; #endif if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf || test_bit(0, &nlk->state)) { + DECLARE_WAITQUEUE(wait, current); if (!timeo) { if (!nlk->pid) netlink_overrun(sk); @@ -471,19 +499,62 @@ kfree_skb(skb); return sock_intr_errno(timeo); } - goto retry; + return 1; } - skb_orphan(skb); skb_set_owner_r(skb, sk); + return 0; + +} + +int netlink_sendskb(struct sock *sk, struct sk_buff *skb, int protocol) +{ + struct netlink_opt *nlk; + int len = skb->len; + + nlk = nlk_sk(sk); +#ifdef NL_EMULATE_DEV + if (nlk->handler) { + skb_orphan(skb); + len = nlk->handler(protocol, skb); + sock_put(sk); + return len; + } +#endif + skb_queue_tail(&sk->sk_receive_queue, skb); sk->sk_data_ready(sk, len); sock_put(sk); return len; +} -no_dst: +void netlink_detachskb(struct sock *sk, struct sk_buff *skb) +{ kfree_skb(skb); - return -ECONNREFUSED; + sock_put(sk); +} + +int netlink_unicast(struct sock *ssk, struct sk_buff *skb, u32 pid, int nonblock) +{ + struct sock *sk; + int err; + long timeo; + + timeo = sock_sndtimeo(ssk, nonblock); + +retry: + sk = netlink_getsockbypid(ssk, pid); + if (IS_ERR(sk)) { + kfree_skb(skb); + return PTR_ERR(skb); + } + err = netlink_attachskb(sk, skb, nonblock, timeo); + if (err == 1) + goto retry; + if (err) + return err; + + return netlink_sendskb(sk, skb, ssk->sk_protocol); } static __inline__ int netlink_broadcast_deliver(struct sock *sk, struct sk_buff *skb) --- 2.6/include/linux/mqueue.h 2004-04-03 14:29:26.000000000 +0200 +++ build-2.6/include/linux/mqueue.h 2004-04-03 21:32:34.006794932 +0200 @@ -30,8 +30,24 @@ long __reserved[4]; /* ignored for input, zeroed for output */ }; +/* + * SIGEV_THREAD implementation: + * SIGEV_THREAD must be implemented in user space. If SIGEV_THREAD is passed + * to mq_notify, then + * - sigev_signo must be the file descriptor of an AF_NETLINK socket. It's not + * necessary that the socket is bound. + * - sigev_value.sival_ptr must point to a cookie that is NOTIFY_COOKIE_LEN + * bytes long. + * If the notification is triggered, then the cookie is sent to the netlink + * socket. The first byte of the cookie is replaced with the NOTIFY_?? codes: + * NOTIFY_WOKENUP if the notification got triggered, NOTIFY_REMOVED if it was + * removed, either due to a close() on the message queue fd or due to a + * mq_notify() that removed the notification. + */ #define NOTIFY_NONE 0 #define NOTIFY_WOKENUP 1 #define NOTIFY_REMOVED 2 +#define NOTIFY_COOKIE_LEN 32 + #endif --- 2.6/ipc/mqueue.c 2004-04-03 14:29:27.000000000 +0200 +++ build-2.6/ipc/mqueue.c 2004-04-03 20:30:07.207197313 +0200 @@ -20,6 +20,9 @@ #include #include #include +#include +#include +#include #include "util.h" #define MQUEUE_MAGIC 0x19800202 @@ -33,9 +36,6 @@ #define STATE_PENDING 1 #define STATE_READY 2 -#define NP_NONE ((void*)NOTIFY_NONE) -#define NP_WOKENUP ((void*)NOTIFY_WOKENUP) -#define NP_REMOVED ((void*)NOTIFY_REMOVED) /* used by sysctl */ #define FS_MQUEUE 1 #define CTL_QUEUESMAX 2 @@ -48,6 +48,8 @@ #define HARD_MSGMAX (131072/sizeof(void*)) #define DFLT_MSGSIZEMAX 16384 /* max message size */ +#define NOTIFY_COOKIE_LEN 32 + struct ext_wait_queue { /* queue of sleeping tasks */ struct task_struct *task; struct list_head list; @@ -56,25 +58,26 @@ }; struct mqueue_inode_info { - struct mq_attr attr; + spinlock_t lock; + struct inode vfs_inode; + wait_queue_head_t wait_q; + struct msg_msg **messages; + struct mq_attr attr; - pid_t notify_owner; /* != 0 means notification registered */ - struct sigevent notify; - struct file *notify_filp; + struct sigevent notify; /* notify.sigev_notify == SIGEV_NONE means */ + pid_t notify_owner; /* no notification registered */ + struct sock *notify_sock; + struct sk_buff *notify_cookie; /* for tasks waiting for free space and messages, respectively */ struct ext_wait_queue e_wait_q[2]; - wait_queue_head_t wait_q; unsigned long qsize; /* size of queue in memory (sum of all msgs) */ - spinlock_t lock; - struct inode vfs_inode; }; static struct inode_operations mqueue_dir_inode_operations; static struct file_operations mqueue_file_operations; -static struct file_operations mqueue_notify_fops; static struct super_operations mqueue_super_ops; static void remove_notification(struct mqueue_inode_info *info); @@ -119,7 +122,7 @@ init_waitqueue_head(&info->wait_q); INIT_LIST_HEAD(&info->e_wait_q[0].list); INIT_LIST_HEAD(&info->e_wait_q[1].list); - info->notify_owner = 0; + info->notify.sigev_notify = SIGEV_NONE; info->qsize = 0; memset(&info->attr, 0, sizeof(info->attr)); info->attr.mq_maxmsg = DFLT_MSGMAX; @@ -283,10 +286,11 @@ snprintf(buffer, sizeof(buffer), "QSIZE:%-10lu NOTIFY:%-5d SIGNO:%-5d NOTIFY_PID:%-6d\n", info->qsize, - info->notify_owner ? info->notify.sigev_notify : SIGEV_NONE, - (info->notify_owner && info->notify.sigev_notify == SIGEV_SIGNAL ) ? + info->notify.sigev_notify, + (info->notify.sigev_notify == SIGEV_SIGNAL ) ? info->notify.sigev_signo : 0, - info->notify_owner); + (info->notify.sigev_notify != SIGEV_NONE) ? + info->notify_owner : 0); spin_unlock(&info->lock); buffer[sizeof(buffer)-1] = '\0'; slen = strlen(buffer)+1; @@ -299,7 +303,7 @@ count = slen - o; if (copy_to_user(u_data, buffer + o, count)) - return -EFAULT; + return -EFAULT; *off = o + count; filp->f_dentry->d_inode->i_atime = filp->f_dentry->d_inode->i_ctime = CURRENT_TIME; @@ -311,7 +315,8 @@ struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode); spin_lock(&info->lock); - if (current->tgid == info->notify_owner) + if (info->notify.sigev_notify != SIGEV_NONE && + current->tgid == info->notify_owner) remove_notification(info); spin_unlock(&info->lock); @@ -445,7 +450,8 @@ * waiting synchronously for message AND state of queue changed from * empty to not empty. Here we are sure that no one is waiting * synchronously. */ - if (info->notify_owner && info->attr.mq_curmsgs == 1) { + if (info->notify.sigev_notify != SIGEV_NONE && + info->attr.mq_curmsgs == 1) { /* sends signal */ if (info->notify.sigev_notify == SIGEV_SIGNAL) { struct siginfo sig_i; @@ -460,10 +466,11 @@ kill_proc_info(info->notify.sigev_signo, &sig_i, info->notify_owner); } else if (info->notify.sigev_notify == SIGEV_THREAD) { - info->notify_filp->private_data = (void*)NP_WOKENUP; + *(char*)info->notify_cookie->data = NOTIFY_WOKENUP; + netlink_sendskb(info->notify_sock, info->notify_cookie, 0); } /* after notification unregisters process */ - info->notify_owner = 0; + info->notify.sigev_notify = SIGEV_NONE; } wake_up(&info->wait_q); } @@ -499,90 +506,13 @@ return timeout; } -/* - * File descriptor based notification, intended to be used to implement - * SIGEV_THREAD: - * SIGEV_THREAD means that a notification function should be called in the - * context of a new thread. The kernel can't do that. Therefore mq_notify - * calls with SIGEV_THREAD return a new file descriptor. A user space helper - * must create a new thread and then read from the given file descriptor. - * The read always returns one byte. If it's NOTIFY_WOKENUP, then it must - * call the notification function. If it's NOTIFY_REMOVED, then the - * notification was removed. The file descriptor supports poll, thus one - * supervisor thread can manage multiple message queue notifications. - * - * The implementation must support multiple outstanding notifications: - * It's possible that a new notification is added and signaled before user - * space calls mqueue_notify_read for the previous notification. - * Therefore the notification state is stored in the private_data field of - * the file descriptor. - */ -static unsigned int mqueue_notify_poll(struct file *filp, - struct poll_table_struct *poll_tab) -{ - struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode); - int retval; - - poll_wait(filp, &info->wait_q, poll_tab); - - if (filp->private_data == NP_NONE) - retval = 0; - else - retval = POLLIN | POLLRDNORM; - return retval; -} - -static ssize_t mqueue_notify_read(struct file *filp, char __user *buf, - size_t count, loff_t *ppos) -{ - struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode); - char result; - - if (!count) - return 0; - if (*ppos != 0) - return 0; - spin_lock(&info->lock); - while (filp->private_data == NP_NONE) { - DEFINE_WAIT(wait); - if (filp->f_flags & O_NONBLOCK) { - spin_unlock(&info->lock); - return -EAGAIN; - } - prepare_to_wait(&info->wait_q, &wait, TASK_INTERRUPTIBLE); - spin_unlock(&info->lock); - schedule(); - finish_wait(&info->wait_q, &wait); - spin_lock(&info->lock); - } - spin_unlock(&info->lock); - result = (char)(unsigned long)filp->private_data; - if (put_user(result, buf)) - return -EFAULT; - *ppos = 1; - return 1; -} - -static int mqueue_notify_release(struct inode *inode, struct file *filp) -{ - struct mqueue_inode_info *info = MQUEUE_I(filp->f_dentry->d_inode); - - spin_lock(&info->lock); - if (info->notify_owner && info->notify_filp == filp) - info->notify_owner = 0; - filp->private_data = NP_REMOVED; - spin_unlock(&info->lock); - - return 0; -} - static void remove_notification(struct mqueue_inode_info *info) { if (info->notify.sigev_notify == SIGEV_THREAD) { - info->notify_filp->private_data = NP_REMOVED; - wake_up(&info->wait_q); + *(char*)info->notify_cookie->data = NOTIFY_REMOVED; + netlink_sendskb(info->notify_sock, info->notify_cookie, 0); } - info->notify_owner = 0; + info->notify.sigev_notify = SIGEV_NONE; } /* @@ -780,7 +710,8 @@ */ /* pipelined_send() - send a message directly to the task waiting in - * sys_mq_timedreceive() (without inserting message into a queue). */ + * sys_mq_timedreceive() (without inserting message into a queue). + */ static inline void pipelined_send(struct mqueue_inode_info *info, struct msg_msg *message, struct ext_wait_queue *receiver) @@ -974,12 +905,16 @@ asmlinkage long sys_mq_notify(mqd_t mqdes, const struct sigevent __user *u_notification) { - int ret, fd; - struct file *filp, *nfilp; + int ret; + struct file *filp; + struct sock *sock; struct inode *inode; struct sigevent notification; struct mqueue_inode_info *info; + struct sk_buff *nc; + nc = NULL; + sock = NULL; if (u_notification == NULL) { notification.sigev_notify = SIGEV_NONE; } else { @@ -996,6 +931,44 @@ notification.sigev_signo > _NSIG)) { return -EINVAL; } + if (notification.sigev_notify == SIGEV_THREAD) { + /* create the notify skb */ + nc = alloc_skb(NOTIFY_COOKIE_LEN, GFP_KERNEL); + ret = -ENOMEM; + if (!nc) + goto out; + ret = -EFAULT; + if (copy_from_user(nc->data, + notification.sigev_value.sival_ptr, + NOTIFY_COOKIE_LEN)) { + goto out; + } + + /* TODO: add a header? */ + skb_put(nc, NOTIFY_COOKIE_LEN); + /* and attach it to the socket */ +retry: + filp = fget(notification.sigev_signo); + ret = -EBADF; + if (!filp) + goto out; + sock = netlink_getsockbyfilp(filp); + fput(filp); + if (IS_ERR(sock)) { + ret = PTR_ERR(sock); + sock = NULL; + goto out; + } + + ret = netlink_attachskb(sock, nc, 0, MAX_SCHEDULE_TIMEOUT); + if (ret == 1) + goto retry; + if (ret) { + sock = NULL; + nc = NULL; + goto out; + } + } } ret = -EBADF; @@ -1009,47 +982,33 @@ info = MQUEUE_I(inode); ret = 0; - if (notification.sigev_notify == SIGEV_THREAD) { - ret = get_unused_fd(); - if (ret < 0) - goto out_fput; - fd = ret; - nfilp = get_empty_filp(); - if (!nfilp) { - ret = -ENFILE; - goto out_dropfd; - } - nfilp->private_data = NP_NONE; - nfilp->f_op = &mqueue_notify_fops; - nfilp->f_vfsmnt = mntget(mqueue_mnt); - nfilp->f_dentry = dget(filp->f_dentry); - nfilp->f_mapping = filp->f_dentry->d_inode->i_mapping; - nfilp->f_flags = O_RDONLY; - nfilp->f_mode = FMODE_READ; - } else { - nfilp = NULL; - fd = -1; - } - spin_lock(&info->lock); - - if (notification.sigev_notify == SIGEV_NONE) { - if (info->notify_owner == current->tgid) { + switch (notification.sigev_notify) { + case SIGEV_NONE: + if (info->notify.sigev_notify != SIGEV_NONE && + info->notify_owner == current->tgid) { remove_notification(info); inode->i_atime = inode->i_ctime = CURRENT_TIME; } - } else if (info->notify_owner) { - ret = -EBUSY; - } else if (notification.sigev_notify == SIGEV_THREAD) { - info->notify_filp = nfilp; - fd_install(fd, nfilp); - ret = fd; - fd = -1; - nfilp = NULL; + break; + case SIGEV_THREAD: + if (info->notify.sigev_notify != SIGEV_NONE) { + ret = -EBUSY; + break; + } + info->notify_sock = sock; + info->notify_cookie = nc; + sock = NULL; + nc = NULL; info->notify.sigev_notify = SIGEV_THREAD; info->notify_owner = current->tgid; inode->i_atime = inode->i_ctime = CURRENT_TIME; - } else { + break; + case SIGEV_SIGNAL: + if (info->notify.sigev_notify != SIGEV_NONE) { + ret = -EBUSY; + break; + } info->notify.sigev_signo = notification.sigev_signo; info->notify.sigev_value = notification.sigev_value; info->notify.sigev_notify = SIGEV_SIGNAL; @@ -1057,12 +1016,14 @@ inode->i_atime = inode->i_ctime = CURRENT_TIME; } spin_unlock(&info->lock); -out_dropfd: - if (fd != -1) - put_unused_fd(fd); out_fput: fput(filp); out: + if (sock) { + netlink_detachskb(sock, nc); + } else if (nc) { + dev_kfree_skb(nc); + } return ret; } @@ -1131,13 +1092,6 @@ .read = mqueue_read_file, }; -static struct file_operations mqueue_notify_fops = { - .poll = mqueue_notify_poll, - .read = mqueue_notify_read, - .release = mqueue_notify_release, -}; - - static struct super_operations mqueue_super_ops = { .alloc_inode = mqueue_alloc_inode, .destroy_inode = mqueue_destroy_inode, --------------020509080401080507010703-- From hadi@cyberus.ca Sat Apr 3 12:18:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 12:18:54 -0800 (PST) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33KIqKO016816 for ; Sat, 3 Apr 2004 12:18:52 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1B9rbj-0005aH-KV for netdev@oss.sgi.com; Sat, 03 Apr 2004 15:19:11 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1B9rbI-0007Dn-Sz; Sat, 03 Apr 2004 15:18:45 -0500 Subject: Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) From: jamal Reply-To: hadi@cyberus.ca To: Manfred Spraul Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Michal Wronski , Krzysztof Benedyczak In-Reply-To: <406F13A1.4030201@colorfullife.com> References: <406F13A1.4030201@colorfullife.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081023487.2037.19.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2004 15:18:07 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4454 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1402 Lines: 38 On Sat, 2004-04-03 at 14:42, Manfred Spraul wrote: > mq_notify(SIGEV_THREAD) must be implemented in user space. If an event > is triggered, the kernel must send a notification to user space, and > then glibc must create the thread with the requested attributes for the > notification callback. I am ignorant about SIGEV_THREAD but from what i gathered above: - something (from user space??) attempts to create a thread in the kernel - the kernel sends notification to user space when said thread is created or done doing something it was asked - something (in glibc/userspace??) is signalled by the kernel to do something with the result Is the above correct? > The current implementation in Andrew's -mm tree > uses single shot file descriptor - it works, but it's resource hungry. Essentially you attempt to open only a single fd via netlink as opposed to open/close behavior you are alluding to, is that correct? then all events are unicast to this fd. I am assuming you dont need to have more than one listener to these events? example, could one process create such a event which multiple processes may be interested in? > Attached is a new proposal: > - split netlink_unicast into separate substeps > - use an AF_NETLINK socket for the message queue notification I am trying to frob why you mucked around with AF_NETLINK; maybe your response will shed some light. cheers, jamal From manfred@colorfullife.com Sat Apr 3 12:43:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 12:43:57 -0800 (PST) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33KhpKO020732 for ; Sat, 3 Apr 2004 12:43:54 -0800 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i33Khd06018014; Sat, 3 Apr 2004 22:43:41 +0200 Message-ID: <406F21FB.4010502@colorfullife.com> Date: Sat, 03 Apr 2004 22:43:39 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Michal Wronski , Krzysztof Benedyczak Subject: Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) References: <406F13A1.4030201@colorfullife.com> <1081023487.2037.19.camel@jzny.localdomain> In-Reply-To: <1081023487.2037.19.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4455 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 2710 Lines: 79 jamal wrote: >On Sat, 2004-04-03 at 14:42, Manfred Spraul wrote: > > >>mq_notify(SIGEV_THREAD) must be implemented in user space. If an event >>is triggered, the kernel must send a notification to user space, and >>then glibc must create the thread with the requested attributes for the >>notification callback. >> >> > >I am ignorant about SIGEV_THREAD but from what i gathered above: > >- something (from user space??) attempts to create a thread in the >kernel >- the kernel sends notification to user space when said thread is >created or done doing something it was asked > No - this part is wrong. >- something (in glibc/userspace??) is signalled by the kernel to do >something with the result > > This is correct. mq_notify is a function from the posix message queue interface: It allows user space to request that a notification should be sent if a new message is waiting in the message queue. There are two options for the notification: a signal or a callback that should be called in the context of a new thread. Signals are trivial, but calling a function in the context of a new thread is tricky: the kernel can't create new user space threads. Thus the kernel interface for mq_notify with sigev_notify==SIGEV_THREAD is an asynchroneous interface: the initial syscall just registers something and if a message arrives in the queue, then a notice is sent to user space. glibc must then create a SuS compatible interface on top of that. The problem is how should I sent the information that a message is waiting to user space? >> The current implementation in Andrew's -mm tree >>uses single shot file descriptor - it works, but it's resource hungry. >> >> > >Essentially you attempt to open only a single fd via netlink as opposed >to open/close behavior you are alluding to, is that correct? > Yes. >then all events are unicast to this fd. I am assuming you dont need to >have more than one listener to these events? example, could one process >create such a event which multiple processes may be interested in? > > Correct, always only one process interested in the notification. >>Attached is a new proposal: >>- split netlink_unicast into separate substeps >>- use an AF_NETLINK socket for the message queue notification >> >> > >I am trying to frob why you mucked around with AF_NETLINK; maybe your >response will shed some light. > > I'm looking for the simplest interface to send 32 byte cookies from kernel to user space. The final send must be non-blocking, setup can block. Someone recommended that I should look at netlink. netlink_unicast was nearly perfect, except that I had to split setup and sending into two functions. -- Manfred From hadi@cyberus.ca Sat Apr 3 14:01:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 14:02:00 -0800 (PST) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33M1uKO023117 for ; Sat, 3 Apr 2004 14:01:57 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1B9tDU-0003rR-VS for netdev@oss.sgi.com; Sat, 03 Apr 2004 17:02:16 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1B9tD2-0005d8-Qc; Sat, 03 Apr 2004 17:01:49 -0500 Subject: Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) From: jamal Reply-To: hadi@cyberus.ca To: Manfred Spraul Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Michal Wronski , Krzysztof Benedyczak In-Reply-To: <406F21FB.4010502@colorfullife.com> References: <406F13A1.4030201@colorfullife.com> <1081023487.2037.19.camel@jzny.localdomain> <406F21FB.4010502@colorfullife.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081029667.2037.55.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2004 17:01:07 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4456 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1326 Lines: 33 On Sat, 2004-04-03 at 15:43, Manfred Spraul wrote: > Thus the kernel interface for mq_notify with sigev_notify==SIGEV_THREAD > is an asynchroneous interface: the initial syscall just registers > something and if a message arrives in the queue, then a notice is sent > to user space. glibc must then create a SuS compatible interface on top > of that. The above is a good description of the challenge i think. [..] > I'm looking for the simplest interface to send 32 byte cookies from > kernel to user space. The final send must be non-blocking, setup can > block. Someone recommended that I should look at netlink. > netlink_unicast was nearly perfect, except that I had to split setup and > sending into two functions. Your split of netlink_unicast seems fine ; I guess the bigger question is whether this interface could be a speacilized netlink protocol instead? It doesnt seem too nasty as is right now, just tending towards cleanliness. It seems that user space must first open a netlink socket for this to work but somehow the result skb is passed back to userspace using the mq_notify and not via the socket interface opened? Why should user space even bother doing this? The kernel could on its behalf, no? Are you sure there will always be one and only one message outstanding always? cheers, jamal From davem@redhat.com Sat Apr 3 14:31:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 14:32:07 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33MVuKO024077 for ; Sat, 3 Apr 2004 14:31:57 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i33MVrjj001217; Sat, 3 Apr 2004 17:31:53 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i33MVrj25009; Sat, 3 Apr 2004 17:31:53 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i33MVF1n022358; Sat, 3 Apr 2004 17:31:29 -0500 Date: Sat, 3 Apr 2004 14:30:37 -0800 From: "David S. Miller" To: Shirley Ma Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org, xma@us.ibm.com Subject: Re: [PATCH]Add IPv6 MIBs counters in MLD (mcast.c) Message-Id: <20040403143037.61530b25.davem@redhat.com> In-Reply-To: <200403311326.43647.mashirle@us.ibm.com> References: <200403311326.43647.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4457 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 174 Lines: 6 On Wed, 31 Mar 2004 13:26:43 -0800 Shirley Ma wrote: > Here is the patch against linux 2.6.4 kernel. Please review it. Patch applied, thanks Shirley. From davem@redhat.com Sat Apr 3 14:47:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 14:47:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33Ml8KO024777 for ; Sat, 3 Apr 2004 14:47:08 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i33Mkujj004182; Sat, 3 Apr 2004 17:46:56 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i33Mkuj27664; Sat, 3 Apr 2004 17:46:56 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i33MkI1n026567; Sat, 3 Apr 2004 17:46:32 -0500 Date: Sat, 3 Apr 2004 14:45:40 -0800 From: "David S. Miller" To: Shirley Ma Cc: xma@us.ibm.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@cerberus.hongo.wide.ad.jp Subject: Re: [PATCH]dump interface IPv6 multicast/anycast addresses through netlink Message-Id: <20040403144540.7f201bc1.davem@redhat.com> In-Reply-To: <200404011028.13048.mashirle@us.ibm.com> References: <200404011028.13048.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4458 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 299 Lines: 11 On Thu, 1 Apr 2004 10:28:12 -0800 Shirley Ma wrote: > Here is the new patch. It has been tested against linux 2.6.4 kernel. I'm Ok with this patch and I believe Yoshfuji et al. are too. But this patch will not apply cleanly to current 2.6.x sources, please rediff. Thanks. From hadi@cyberus.ca Sat Apr 3 16:51:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 16:51:32 -0800 (PST) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i340pTKO000957 for ; Sat, 3 Apr 2004 16:51:29 -0800 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1B9uAV-0006fu-WD for netdev@oss.sgi.com; Sat, 03 Apr 2004 18:03:15 -0500 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1B9uA5-0007HW-SI; Sat, 03 Apr 2004 18:02:50 -0500 Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling From: jamal Reply-To: hadi@cyberus.ca To: Yusuf Goolamabbas Cc: netdev@oss.sgi.com In-Reply-To: <20040330142354.GA17671@outblaze.com> References: <20040330142354.GA17671@outblaze.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081033332.2037.61.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 03 Apr 2004 18:02:12 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 4459 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 722 Lines: 22 On Tue, 2004-03-30 at 09:23, Yusuf Goolamabbas wrote: > Maybe this might be of interest to netdev hackers > > Luca Deri's paper > Improving Passive Packet Capture: Beyond Device Polling > > http://www.net-security.org/dl/articles/Ring.pdf > Thanks for posting this. I am a little suprised at some of the results especially with NAPI + packet mmap. I have had no problem at all handling wire rate 100mbps with tulip-NAPI in 2.4.x using packet mmap on a p3 or maybe it was a p2; This is zero drops at 148.8Kpps. Jason Lunz actually seemed to have been doing more work on this and e1000 - he could provide better perfomance numbers. It should also be noted that infact packet mmap already uses rings. cheers, jamal From manfred@colorfullife.com Sat Apr 3 23:11:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 03 Apr 2004 23:11:50 -0800 (PST) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i347BdKO016099 for ; Sat, 3 Apr 2004 23:11:40 -0800 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i347BQ06026046; Sun, 4 Apr 2004 09:11:28 +0200 Message-ID: <406FB51E.3090001@colorfullife.com> Date: Sun, 04 Apr 2004 09:11:26 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, Michal Wronski , Krzysztof Benedyczak Subject: Re: [RFC, PATCH] netlink based mq_notify(SIGEV_THREAD) References: <406F13A1.4030201@colorfullife.com> <1081023487.2037.19.camel@jzny.localdomain> <406F21FB.4010502@colorfullife.com> <1081029667.2037.55.camel@jzny.localdomain> In-Reply-To: <1081029667.2037.55.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4460 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 945 Lines: 26 jamal wrote: >Your split of netlink_unicast seems fine ; >I guess the bigger question is whether this interface could be a >speacilized netlink protocol instead? It doesnt seem too nasty as is >right now, just tending towards cleanliness. >It seems that user space must first open a netlink socket for this to >work but somehow the result skb is passed back to userspace using the >mq_notify and not via the socket interface opened? > No, the result is returned via the socket fd. It's just created due to the mq_notify call. > Why should user space >even bother doing this? The kernel could on its behalf, no? Are you sure >there will always be one and only one message outstanding always? > > There can be multiple messages outstanding. Each sucessful mq_notify call generates exactly one message, but a process could create multiple message queues and then there can be multiple messages in the notification socket. -- Manfred From shawn.starr@rogers.com Sun Apr 4 13:58:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 13:58:48 -0700 (PDT) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34KwfKO028434 for ; Sun, 4 Apr 2004 13:58:41 -0700 Received: from panic ([67.60.40.239]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20040404205720.VLRH39251.fep02-mail.bloor.is.net.cable.rogers.com@panic> for ; Sun, 4 Apr 2004 16:57:20 -0400 From: "Shawn Starr" To: Subject: [BUG][2.6.5 final][e100] NETDEV_WATCHDOG Timeout - Was not a problem with 2.6.5-rc3 Date: Sun, 4 Apr 2004 16:58:35 -0400 Message-ID: <000201c41a87$98897970$0200080a@panic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [67.60.40.239] using ID at Sun, 4 Apr 2004 16:57:20 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i34KwfKO028434 X-archive-position: 4461 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 11339 Lines: 248 I've been told this sould be directed here :-) -----Original Message----- From: Shawn Starr [mailto:shawn.starr@rogers.com] Sent: Sunday, April 04, 2004 04:51 PM To: 'linux-kernel@vger.kernel.org' Subject: [BUG][2.6.5 final][e100] NETDEV_WATCHDOG Timeout - Was not a problem with 2.6.5-rc3 Dmesg: Linux version 2.6.5 (root@coredump) (gcc version 3.3.4 20040313 (prerelease)) #2 Sun Apr 4 04:18:23 EDT 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000023ffd9c0 (usable) BIOS-e820: 0000000023ffd9c0 - 0000000024000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved) 575MB LOWMEM available. On node 0 totalpages: 147453 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 143357 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.1 present. IBM machine detected. Enabling interrupts during APM calls. IBM machine detected. Disabling SMBus accesses. ACPI: RSDP (v000 IBM ) @ 0x000fdfe0 ACPI: RSDT (v001 IBM CDTPWSNV 0x00001010 IBM 0x00000000) @ 0x23ffff80 ACPI: FADT (v001 IBM CDTPWSNV 0x00001010 IBM 0x00000000) @ 0x23ffff00 ACPI: DSDT (v001 IBM CDTPWSNV 0x00001000 MSFT 0x01000007) @ 0x00000000 ACPI: PM-Timer IO Port: 0xfd08 Built 1 zonelists Kernel command line: BOOT_IMAGE=linux ro root=301 console=tty0 psmouse_rate=60 psmouse_resolution=200 nmi_watchdog=2 atkbd.softrepeat=1 Parameter psmouse_rate= is obsolete, ignored Parameter psmouse_resolution= is obsolete, ignored Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Initializing CPU#0 PID hash table entries: 4096 (order 12: 32768 bytes) Detected 547.805 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Memory: 578720k/589812k available (2453k kernel code, 10304k reserved, 688k data, 364k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 1085.44 BogoMIPS Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 CPU: After vendor identify, caps: 0383fbff 00000000 00000000 00000000 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0383fbf7 00000000 00000000 00000040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: Intel Pentium III (Katmai) stepping 03 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 testing NMI watchdog ... OK. Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 547.0532 MHz. ..... host bus clock speed is 99.0551 MHz. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd83c, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20040326 ACPI: IRQ9 SCI: Level Trigger. ACPI-0179: *** Warning: The ACPI AML in your computer contains errors, please nag the manufacturer to correct it. ACPI-0182: *** Warning: Allowing relaxed access to fields; turn on CONFIG_ACPI_DEBUG for details. ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [PIN1] (IRQs 3 4 5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [PIN2] (IRQs 3 4 *5 6 7 9 10 11 12 14 15) ACPI: PCI Interrupt Link [PIN3] (IRQs 3 4 5 6 7 *9 10 11 12 14 15) ACPI: PCI Interrupt Link [PIN4] (IRQs 3 4 5 6 7 9 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: the driver 'system' has been registered PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fde50 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0x587a, dseg 0xf0000 pnp: match found with the PnP device '00:09' and the driver 'system' pnp: match found with the PnP device '00:0a' and the driver 'system' pnp: match found with the PnP device '00:0c' and the driver 'system' pnp: match found with the PnP device '00:0d' and the driver 'system' pnp: match found with the PnP device '00:0e' and the driver 'system' pnp: 00:0e: ioport range 0x370-0x371 has been reserved pnp: 00:0e: ioport range 0x4d0-0x4d1 has been reserved pnp: match found with the PnP device '00:0f' and the driver 'system' pnp: 00:0f: ioport range 0x290-0x297 has been reserved pnp: match found with the PnP device '00:10' and the driver 'system' pnp: 00:10: ioport range 0xfd00-0xfd3f has been reserved pnp: 00:10: ioport range 0xfe00-0xfe0f has been reserved pnp: match found with the PnP device '00:15' and the driver 'system' PnPBIOS: 21 nodes reported by PnP BIOS; 21 recorded by driver SCSI subsystem initialized drivers/usb/core/usb.c: registered new driver usbfs drivers/usb/core/usb.c: registered new driver hub ACPI: PCI Interrupt Link [PIN4] enabled at IRQ 11 ACPI: PCI Interrupt Link [PIN3] enabled at IRQ 9 ACPI: PCI Interrupt Link [PIN2] enabled at IRQ 5 PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' IA-32 Microcode Update Driver: v1.13 Limiting direct PCI/PCI transfers. ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU0] (supports C1) isapnp: Scanning for PnP cards... pnp: Calling quirk for 01:01.00 pnp: SB audio device quirk - increasing port range pnp: Calling quirk for 01:01.02 pnp: AWE32 quirk - adding two ports isapnp: Card 'Creative SB32 PnP' isapnp: Card 'U.S. Robotics Sportster 33600 FAX/Voice Int' isapnp: 2 Plug & Play cards detected total lp: driver loaded but no devices found Real Time Clock Driver v1.12 Hangcheck: starting hangcheck timer 0.5.0 (tick is 180 seconds, margin is 60 seconds). Serial: 8250/16550 driver $Revision: 1.90 $ 7 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A pnp: the driver 'serial' has been registered pnp: match found with the PnP device '00:12' and the driver 'serial' pnp: match found with the PnP device '00:13' and the driver 'serial' pnp: match found with the PnP device '01:02.00' and the driver 'serial' pnp: Unable to assign resources to device 01:02.00. serial: probe of 01:02.00 failed with error -16 pnp: the driver 'parport_pc' has been registered pnp: match found with the PnP device '00:14' and the driver 'parport_pc' parport: PnPBIOS parport detected. parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] lp0: using parport0 (interrupt-driven). Using anticipatory io scheduler Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 e100: Intel(R) PRO/100 Network Driver, 3.0.17 e100: Copyright(c) 1999-2004 Intel Corporation e100: eth0: e100_probe: addr 0xf3cff000, irq 11, MAC addr 00:06:29:CE:07:04 e100: eth1: e100_probe: addr 0xf3dff000, irq 5, MAC addr 00:D0:B7:4E:F0:7D netconsole: not configured, aborting Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller at PCI slot 0000:00:02.1 PIIX4: chipset revision 1 PIIX4: not 100%% native mode: will probe irqs later ide0: BM-DMA at 0xfff0-0xfff7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xfff8-0xffff, BIOS settings: hdc:pio, hdd:pio hda: MAXTOR 6L040L2, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: CRD-8400B, ATAPI CD/DVD-ROM drive hdc: Disabling (U)DMA for CRD-8400B (blacklisted) ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 78177792 sectors (40027 MB) w/1819KiB Cache, CHS=65535/16/63, UDMA(33) hda: hda1 hda2 hdc: ATAPI 40X CD-ROM drive, 128kB Cache Uniform CD-ROM driver Revision: 3.20 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs Vendor: HP Model: T4000s Rev: 1.10 Type: Sequential-Access ANSI SCSI revision: 02 ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ohci_hcd: block sizes: ed 64 td 64 USB Universal Host Controller Interface driver v2.2 PCI: Enabling device 0000:00:02.2 (0000 -> 0001) uhci_hcd 0000:00:02.2: Intel Corp. 82371AB/EB/MB PIIX4 USB uhci_hcd 0000:00:02.2: irq 11, io base 00001000 uhci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1 hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected mice: PS/2 mouse device common for all mice input: PC Speaker serio: i8042 AUX port at 0x60,0x64 irq 12 input: ImExPS/2 Generic Explorer Mouse on isa0060/serio1 serio: i8042 KBD port at 0x60,0x64 irq 1 input: AT Translated Set 2 keyboard on isa0060/serio0 i2c /dev entries driver i2c-core: driver dev_driver registered. sb: Init: Starting Probe... pnp: the driver 'OSS SndBlstr' has been registered pnp: match found with the PnP device '01:01.00' and the driver 'OSS SndBlstr' pnp: Device 01:01.00 activated. sb: PnP: Found Card Named = "Creative SB32 PnP", Card PnP id = CTL0048, Device PnP id =CTL0031 sb: PnP: Detected at: io=0x220, irq=10, dma=1, dma16=5 at 0x220 irq 10 dma 1,5 sb: Turning on MPU at 0x300 irq 10 sb: Init: Done AWE32: Probing for WaveTable... pnp: the driver 'AWE32' has been registered pnp: match found with the PnP device '01:01.02' and the driver 'AWE32' pnp: Device 01:01.02 activated. AWE32: A PnP Wave Table was detected at IO's 0x620,0xa20,0xe20 .<6> NET: Registered protocol family 2 IP: routing cache hash table of 1024 buckets, 32Kbytes TCP: Hash tables configured (established 262144 bind 37449) NET: Registered protocol family 1 NET: Registered protocol family 17 kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 364k freed Adding 72284k swap on /dev/hda2. Priority:1 extents:1 EXT3 FS on hda1, internal journal e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex e100: eth1: e100_watchdog: link up, 100Mbps, full-duplex When I try to access the eth0 device I get: Apr 4 15:39:01 coredump kernel: NETDEV WATCHDOG: eth0: transmit timed out Apr 4 16:22:12 coredump kernel: NETDEV WATCHDOG: eth0: transmit timed out And then the eth0 device stops responding to traffic until I shut down and cut power fo the machine by removing the power cable. Can someone confirm problems with the changes from 2.6.5-rc3 -> 2.6.5 final? Thanks Shawn. From bhartin@straus-frank.com Sun Apr 4 14:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 14:06:02 -0700 (PDT) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34L5xKO028987 for ; Sun, 4 Apr 2004 14:05:59 -0700 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i34L5pkH016045; Sun, 4 Apr 2004 21:05:51 GMT (envelope-from bhartin@straus-frank.com) Date: Sun, 4 Apr 2004 16:05:39 -0500 (CDT) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040126235559.A3832@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4462 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 2669 Lines: 71 Francois: I don't remember if I ever did reply to you last time concerning this. Since I emailed you, I've tried many, many versions of the 2.6.x series kernels and superpatch variants. The only change was with today's release of 2.6.5. I now get the message "eth0: Too much work at interrupt!" prior to the interface locking up. I still have absolutely no problems with the 2.4.x kernels with respect to the networking (I have video/AGP issues with it though, but that's another story). Trying the same kernel with SMP and ACPI disabled: Rather than the interface locking up (the NIC failing to transmit or receive), the entire system locks up hard. All of these tests are done on a 100Mbit network, both on an unmanaged Linksys switch and on a Cisco 2948G, with the same results. The test is done by doing an scp to copy a remote file to the local filesystem. The lockups occur anywhere from 45MBytes to 95MBytes transferred. I haven't tried your latest set of patches because I haven't been able to find the URL for them again (I got carried away cleaning up my bookmarks recently). Let me know if there are any newer ones you'd like for me to try. Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company Thanks, On Mon, 26 Jan 2004, Francois Romieu wrote: > bhartin@straus-frank.com : > [...] > > Attached is a tar.gz containing the outputs you request in your README, > > plus 'lspci -v' output and my .config for the kernel. This data was > > collected from a fresh 2.6.2-rc2 bootup, using your full set of 2.6.2-rc1 > > patches, manually doing a 'modprobe r8169' once booted up. The system is > > running a P4 with HT enabled, with an SMP kernel. > > There has been report of non-regression on non-SMP kernel with the following > patches applied (2.6.2-rc1 serie): > r8169-tx-index-overflow.patch > r8169-dma-api-tx.patch > r8169-dma-api-rx-buffers.patch > r8169-dma-api-tx-buffers.patch > r8169-rx_copybreak.patch > r8169-mac-phy-version.patch > r8169-init_one.patch > r8169-timer.patch > r8169-hw_start.patch > r8169-intr_mask.patch > r8169-suspend.patch > r8169-endianness.patch > r8169-getstats.patch > > Can you confirm that the driver behaves the same as the standard driver > with a non-SMP enabled kernel ? > > Does it make a difference if you give an 'acpi=off' option at boot time ? > > r8169-addr-high.patch is not doing its job on amd64 so it is not suggested > to use it at all. > > There is something broken wrt SMP and the r8169 patches: do not use both at > the same time. I still have to find what happens here. > > -- > Ueimor From romieu@fr.zoreil.com Sun Apr 4 15:21:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 15:21:26 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34MLNKO031398 for ; Sun, 4 Apr 2004 15:21:24 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i34MKSgf008746; Mon, 5 Apr 2004 00:20:28 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i34MKSqw008745; Mon, 5 Apr 2004 00:20:28 +0200 Date: Mon, 5 Apr 2004 00:20:28 +0200 From: Francois Romieu To: bhartin@straus-frank.com Cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop Message-ID: <20040405002028.A8125@electric-eye.fr.zoreil.com> References: <20040126235559.A3832@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bhartin@straus-frank.com on Sun, Apr 04, 2004 at 04:05:39PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4463 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 504 Lines: 14 bhartin@straus-frank.com : [...] > I haven't tried your latest set of patches because I haven't been able to > find the URL for them again (I got carried away cleaning up my bookmarks > recently). Let me know if there are any newer ones you'd like for me to > try. http://www.fr.zoreil.com/people/francois/misc/20040329-2.6.5-rc2-r8169.c-test.patch It removes a possible loop in the Tx irq handler and should save some cpu cycles as well. Apply against 2.6.5. -- Ueimor From harisri@bigpond.com Sun Apr 4 16:43:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 16:43:17 -0700 (PDT) Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.158]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34NhEKO003928 for ; Sun, 4 Apr 2004 16:43:15 -0700 Received: from lerc-daemon.mta04ps.email.bigpond.com by mta04ps.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) id <0HVO00L2W70T0W@mta04ps.email.bigpond.com> for netdev@oss.sgi.com; Mon, 05 Apr 2004 09:38:53 +1000 (EST) Received: from email.bigpond.com ([172.26.103.15]) by mta04ps.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HVO00CLI70MZ0@mta04ps.email.bigpond.com>; Mon, 05 Apr 2004 09:38:46 +1000 (EST) Received: from [192.168.115.141] by mailms6aps.email.bigpond.com (mshttpd) ; Mon, 05 Apr 2004 09:38:46 +1000 Date: Mon, 05 Apr 2004 09:38:46 +1000 From: Srihari Vijayaraghavan Subject: Re: [patch] 2.6.5-rc2 - r8169 DAC To: romieu@fr.zoreil.com Cc: jgarzik@pobox.com, netdev@oss.sgi.com, ak@suse.de Message-id: <253ea2a8f4.2a8f4253ea@email.bigpond.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.14 (built Oct 29 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-archive-position: 4464 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@telstra.com Precedence: bulk X-list: netdev Content-Length: 784 Lines: 22 Hello Francois, > DMA_{32/64}BIT_MASK for all. > > > include/linux/dma-mapping.h | 3 +++ > 1 files changed, 3 insertions(+) > > diff -puN include/linux/dma-mapping.h~r8169-dac-00 > include/linux/dma-mapping.h With that patch 2.6.5-rc2 + r8169 DAC compiles and works fine. There is one problem however: If I unplug and plug the cable it does not come back to online (even the LED on the card does not glow). I did not try reloading the driver, but a reboot does fix it :-( (later today I shall try reloading the driver). OTOH the vanilla 2.6.5-rc2 (or rc3) does not show this behaviour. As for as the stability, I have stress tested it for couple of hours and it seems to work just fine. Thanks Hari From bhartin@straus-frank.com Sun Apr 4 16:57:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 16:57:39 -0700 (PDT) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34NvaKO004888 for ; Sun, 4 Apr 2004 16:57:37 -0700 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i34NvYkH050911; Sun, 4 Apr 2004 23:57:34 GMT (envelope-from bhartin@straus-frank.com) Date: Sun, 4 Apr 2004 18:57:20 -0500 (CDT) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040405002028.A8125@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4465 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 1383 Lines: 43 Here are the results using this new patch: No SMP, no ACPI: Appears to work well--transferred about 8 gigs okay With SMP, with ACPI: Interface locks up after a few MB With SMP, no ACPI: Interface locks up after a few MB No SMP, with ACPI: Appears to work well--transferred about 8 gigs okay My laptop is *finally* reaching full usability! Thanks! I can live without SMP--this is just a single P4/HT, so I'm not losing much. Thanks again. If there is any debugging info you need towards fixing the SMP compatibility issue, just let me know, but I'm not in a hurry for it. Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company Thanks, On Mon, 5 Apr 2004, Francois Romieu wrote: > bhartin@straus-frank.com : > [...] > > I haven't tried your latest set of patches because I haven't been able to > > find the URL for them again (I got carried away cleaning up my bookmarks > > recently). Let me know if there are any newer ones you'd like for me to > > try. > > http://www.fr.zoreil.com/people/francois/misc/20040329-2.6.5-rc2-r8169.c-test.patch > > It removes a possible loop in the Tx irq handler and should save some cpu > cycles as well. Apply against 2.6.5. > > -- > Ueimor > Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company From rddunlap@osdl.org Sun Apr 4 20:10:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 04 Apr 2004 20:10:32 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i353ALKO010466 for ; Sun, 4 Apr 2004 20:10:22 -0700 Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i353AE210825; Sun, 4 Apr 2004 20:10:15 -0700 Date: Sun, 4 Apr 2004 20:03:54 -0700 From: "Randy.Dunlap" To: netdev@oss.sgi.com Cc: davem@redhat.com, benh@kernel.crashing.org Subject: [PATCH] update networking config menu (v3) Message-Id: <20040404200354.50e5dd74.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4466 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 11339 Lines: 359 Hi, This is a modified version of the patch that I posted about 3 weeks ago. It no longer puts "Networking support" in the top-level menu because it makes more sense to me to keep it close to the Network drivers and other protocols, so basically this patch mostly moves some menu items around to have a better logical grouping (IMO of course). Comments/suggestions? Thanks, -- ~Randy // linux-2.6.5 // Networking support/options and Networking drivers have been, uhm, // messy to navigate for some time now. BenH mentioned this // and I was already looking into options to clean it up. // This is a cleanup of Networking support/options and Networking Drivers. // It presents a more consistent interface and lists similar driver // groups and protocol groups closer together. // It also moves the IBMVETH driver so that it no longer breaks the // dependency tree, allowing other drivers (nearby in Kconfig file) // to be presented in a more linear manner. diffstat:= drivers/net/Kconfig | 53 ++++++++++----------- net/Kconfig | 123 +++++++++++++++++++++++++------------------------- net/ax25/Kconfig | 7 -- net/bluetooth/Kconfig | 6 -- net/irda/Kconfig | 8 --- 5 files changed, 93 insertions(+), 104 deletions(-) diff -Naurp ./drivers/net/Kconfig.orig ./drivers/net/Kconfig --- ./drivers/net/Kconfig.orig 2004-04-03 19:38:10.000000000 -0800 +++ ./drivers/net/Kconfig 2004-04-04 17:31:22.000000000 -0700 @@ -21,10 +21,6 @@ config NETDEVICES If unsure, say Y. -if NETDEVICES - source "drivers/net/arcnet/Kconfig" -endif - config DUMMY tristate "Dummy net driver support" depends on NETDEVICES @@ -155,6 +151,10 @@ config NET_SB1000 If you don't have this card, of course say N. +if NETDEVICES + source "drivers/net/arcnet/Kconfig" +endif + # # Ethernet # @@ -1178,6 +1178,17 @@ config IBMLANA boards with this driver should be possible, but has not been tested up to now due to lack of hardware. +config IBMVETH + tristate "IBM LAN Virtual Ethernet support" + depends on NETDEVICES && NET_ETHERNET && PPC_PSERIES + ---help--- + This driver supports virtual ethernet adapters on newer IBM iSeries + and pSeries systems. + + To compile this driver as a module, choose M here and read + . The module will + be called ibmveth. + config NET_PCI bool "EISA, VLB, PCI and on board controllers" depends on NET_ETHERNET && (ISA || EISA || PCI) @@ -2103,6 +2114,17 @@ config IXGB_NAPI endmenu +source "drivers/net/tokenring/Kconfig" + +source "drivers/net/wireless/Kconfig" + +source "drivers/net/pcmcia/Kconfig" + +source "drivers/net/wan/Kconfig" + +source "drivers/atm/Kconfig" + +source "drivers/s390/net/Kconfig" config VETH tristate "iSeries Virtual Ethernet driver support" @@ -2170,17 +2192,6 @@ config HIPPI under Linux, say Y here (you must also remember to enable the driver for your HIPPI card below). Most people will say N here. -config IBMVETH - tristate "IBM LAN Virtual Ethernet support" - depends on NETDEVICES && NET_ETHERNET && PPC_PSERIES - ---help--- - This driver supports virtual ethernet adapters on newer IBM iSeries - and pSeries systems. - - To compile this driver as a module, choose M here and read - . The module will - be called ibmveth. - config ROADRUNNER tristate "Essential RoadRunner HIPPI PCI adapter support (EXPERIMENTAL)" depends on HIPPI && PCI @@ -2438,10 +2449,6 @@ config SLIP_MODE_SLIP6 end of the link as well. It's good enough, for example, to run IP over the async ports of a Camtec JNT Pad. If unsure, say N. -source "drivers/net/wireless/Kconfig" - -source "drivers/net/tokenring/Kconfig" - config NET_FC bool "Fibre Channel driver support" depends on NETDEVICES && SCSI && PCI @@ -2501,11 +2508,3 @@ config NETCONSOLE ---help--- If you want to log kernel messages over the network, enable this. See Documentation/networking/netconsole.txt for details. - -source "drivers/net/wan/Kconfig" - -source "drivers/net/pcmcia/Kconfig" - -source "drivers/atm/Kconfig" - -source "drivers/s390/net/Kconfig" diff -Naurp ./net/bluetooth/Kconfig.orig ./net/bluetooth/Kconfig --- ./net/bluetooth/Kconfig.orig 2004-04-03 19:38:12.000000000 -0800 +++ ./net/bluetooth/Kconfig 2004-04-03 22:30:19.000000000 -0800 @@ -2,10 +2,8 @@ # Bluetooth subsystem configuration # -menu "Bluetooth support" +menuconfig BT depends on NET - -config BT tristate "Bluetooth subsystem support" help Bluetooth is low-cost, low-power, short-range wireless technology. @@ -62,5 +60,3 @@ source "net/bluetooth/cmtp/Kconfig" source "drivers/bluetooth/Kconfig" -endmenu - diff -Naurp ./net/irda/Kconfig.orig ./net/irda/Kconfig --- ./net/irda/Kconfig.orig 2004-04-03 19:37:07.000000000 -0800 +++ ./net/irda/Kconfig 2004-04-03 22:30:19.000000000 -0800 @@ -2,11 +2,9 @@ # IrDA protocol configuration # -menu "IrDA (infrared) support" +menuconfig IRDA depends on NET - -config IRDA - tristate "IrDA subsystem support" + tristate "IrDA (infrared) subsystem support" ---help--- Say Y here if you want to build support for the IrDA (TM) protocols. The Infrared Data Associations (tm) specifies standards for wireless @@ -95,5 +93,3 @@ config IRDA_DEBUG source "drivers/net/irda/Kconfig" -endmenu - diff -Naurp ./net/ax25/Kconfig.orig ./net/ax25/Kconfig --- ./net/ax25/Kconfig.orig 2004-04-03 19:38:13.000000000 -0800 +++ ./net/ax25/Kconfig 2004-04-03 22:30:19.000000000 -0800 @@ -6,9 +6,8 @@ # Joerg Reuter DL1BKE # 19980129 Moved to net/ax25/Config.in, sourcing device drivers. -menu "Amateur Radio support" - -config HAMRADIO +menuconfig HAMRADIO + depends on NET bool "Amateur Radio support" help If you want to connect your Linux box to an amateur radio, answer Y @@ -109,5 +108,3 @@ source "drivers/net/hamradio/Kconfig" endmenu -endmenu - diff -Naurp ./net/Kconfig.orig ./net/Kconfig --- ./net/Kconfig.orig 2004-04-03 19:36:16.000000000 -0800 +++ ./net/Kconfig 2004-04-04 19:44:42.000000000 -0700 @@ -129,59 +129,6 @@ config IPV6 source "net/ipv6/Kconfig" -config DECNET - tristate "DECnet Support" - ---help--- - The DECnet networking protocol was used in many products made by - Digital (now Compaq). It provides reliable stream and sequenced - packet communications over which run a variety of services similar - to those which run over TCP/IP. - - To find some tools to use with the kernel layer support, please - look at Patrick Caulfield's web site: - . - - More detailed documentation is available in - . - - Be sure to say Y to "/proc file system support" and "Sysctl support" - below when using DECnet, since you will need sysctl support to aid - in configuration at run time. - - The DECnet code is also available as a module ( = code which can be - inserted in and removed from the running kernel whenever you want). - The module is called decnet. - -source "net/decnet/Kconfig" - -config BRIDGE - tristate "802.1d Ethernet Bridging" - ---help--- - If you say Y here, then your Linux box will be able to act as an - Ethernet bridge, which means that the different Ethernet segments it - is connected to will appear as one Ethernet to the participants. - Several such bridges can work together to create even larger - networks of Ethernets using the IEEE 802.1 spanning tree algorithm. - As this is a standard, Linux bridges will cooperate properly with - other third party bridge products. - - In order to use the Ethernet bridge, you'll need the bridge - configuration tools; see - for location. Please read the Bridge mini-HOWTO for more - information. - - If you enable iptables support along with the bridge support then you - turn your bridge into a bridging IP firewall. - iptables will then see the IP packets being bridged, so you need to - take this into account when setting up your firewall rules. - Enabling arptables support when bridging will let arptables see - bridged ARP traffic in the arptables FORWARD chain. - - To compile this code as a module, choose M here: the module - will be called bridge. - - If unsure, say N. - menuconfig NETFILTER bool "Network packet filtering (replaces ipchains)" ---help--- @@ -345,9 +292,62 @@ config ATM_BR2684_IPFILTER large number of IP-only vcc's. Do not enable this unless you are sure you know what you are doing. +config BRIDGE + tristate "802.1d Ethernet Bridging" + ---help--- + If you say Y here, then your Linux box will be able to act as an + Ethernet bridge, which means that the different Ethernet segments it + is connected to will appear as one Ethernet to the participants. + Several such bridges can work together to create even larger + networks of Ethernets using the IEEE 802.1 spanning tree algorithm. + As this is a standard, Linux bridges will cooperate properly with + other third party bridge products. + + In order to use the Ethernet bridge, you'll need the bridge + configuration tools; see + for location. Please read the Bridge mini-HOWTO for more + information. + + If you enable iptables support along with the bridge support then you + turn your bridge into a bridging IP firewall. + iptables will then see the IP packets being bridged, so you need to + take this into account when setting up your firewall rules. + Enabling arptables support when bridging will let arptables see + bridged ARP traffic in the arptables FORWARD chain. + + To compile this code as a module, choose M here: the module + will be called bridge. + + If unsure, say N. + config VLAN_8021Q tristate "802.1Q VLAN Support" +config DECNET + tristate "DECnet Support" + ---help--- + The DECnet networking protocol was used in many products made by + Digital (now Compaq). It provides reliable stream and sequenced + packet communications over which run a variety of services similar + to those which run over TCP/IP. + + To find some tools to use with the kernel layer support, please + look at Patrick Caulfield's web site: + . + + More detailed documentation is available in + . + + Be sure to say Y to "/proc file system support" and "Sysctl support" + below when using DECnet, since you will need sysctl support to aid + in configuration at run time. + + The DECnet code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called decnet. + +source "net/decnet/Kconfig" + source "net/llc/Kconfig" config IPX @@ -650,14 +650,6 @@ endmenu endmenu -source "drivers/net/Kconfig" - -source "net/ax25/Kconfig" - -source "net/irda/Kconfig" - -source "net/bluetooth/Kconfig" - config NETPOLL def_bool NETCONSOLE @@ -674,4 +666,13 @@ config NETPOLL_TRAP config NET_POLL_CONTROLLER def_bool NETPOLL +source "net/ax25/Kconfig" + +source "net/irda/Kconfig" + +source "net/bluetooth/Kconfig" + +source "drivers/net/Kconfig" + endmenu + From kazunori@miyazawa.org Mon Apr 5 00:09:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 00:11:32 -0700 (PDT) Received: from miyazawa.org (usen-221x116x13x66.ap-US01.usen.ad.jp [221.116.13.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3579uKO021698 for ; Mon, 5 Apr 2004 00:09:57 -0700 Received: from 2001:200:1b0:2032:20c:29ff:febb:6598 ([2001:200:1b0:2032:20c:29ff:febb:6598]) (AUTH: PLAIN kazunori, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by miyazawa.org with esmtp; Mon, 05 Apr 2004 16:03:34 +0900 From: Kazunori Miyazawa To: netdev@oss.sgi.com Subject: [PATCH 2.6][IPSEC] conforming to rfc2406 Date: Mon, 5 Apr 2004 15:38:35 +0900 User-Agent: KMail/1.5.4 Cc: kazunori@miyazawa.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404051538.35608.kazunori@miyazawa.org> X-archive-position: 4467 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kazunori@miyazawa.org Precedence: bulk X-list: netdev Content-Length: 8253 Lines: 311 Hello, I send patches to make 2.6 IPsec conform to rfc2406. In section 3.4.3, RFC saids All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the authentication service also is enabled for the SA, since otherwise the Sequence Number field has not been integrity protected. Original code checks sequence number unless integrity check. I moved sequence number checking and advancing from xfrm[46]_input.c to each ah[64].c and esp[64].c. Best regards, --Kazunori Miyazawa ===== include/net/xfrm.h 1.54 vs edited ===== --- 1.54/include/net/xfrm.h Sat Mar 20 12:35:32 2004 +++ edited/include/net/xfrm.h Mon Apr 5 12:24:10 2004 @@ -869,7 +869,7 @@ extern void km_policy_expired(struct xfrm_policy *pol, int dir, int hard); extern void xfrm_input_init(void); -extern int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi, u32 *seq); +extern int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi); extern void xfrm_probe_algs(void); extern int xfrm_count_auth_supported(void); ===== net/ipv4/ah4.c 1.29 vs edited ===== --- 1.29/net/ipv4/ah4.c Sun Jan 25 03:08:48 2004 +++ edited/net/ipv4/ah4.c Mon Apr 5 12:11:32 2004 @@ -166,6 +166,8 @@ goto out; ah = (struct ip_auth_hdr*)skb->data; + if (x->props.replay_window && xfrm_replay_check(x, ah->seq_no)) + goto out; ahp = x->data; ah_hlen = (ah->hdrlen + 2) << 2; @@ -209,6 +211,8 @@ goto out; } } + if (x->props.replay_window) + xfrm_replay_advance(x, ah->seq_no); ((struct iphdr*)work_buf)->protocol = ah->nexthdr; skb->nh.raw = skb_pull(skb, ah_hlen); memcpy(skb->nh.raw, work_buf, iph->ihl*4); ===== net/ipv4/esp4.c 1.36 vs edited ===== --- 1.36/net/ipv4/esp4.c Wed Mar 10 08:21:50 2004 +++ edited/net/ipv4/esp4.c Mon Apr 5 12:14:10 2004 @@ -227,6 +227,7 @@ if (!pskb_may_pull(skb, sizeof(struct ip_esp_hdr))) goto out; + esph = (struct ip_esp_hdr*)skb->data; if (elen <= 0 || (elen & (blksize-1))) goto out; @@ -236,6 +237,8 @@ u8 sum[esp->auth.icv_full_len]; u8 sum1[alen]; + if (x->props.replay_window && xfrm_replay_check(x, esp->seq_no)) + goto out; esp->auth.icv(esp, skb, 0, skb->len-alen, sum); if (skb_copy_bits(skb, skb->len-alen, sum1, alen)) @@ -245,6 +248,9 @@ x->stats.integrity_failed++; goto out; } + + if (x->props.replay_winodw) + xfrm_replay_advance(x, esph->seq_no); } if ((nfrags = skb_cow_data(skb, 0, &trailer)) < 0) @@ -252,7 +258,6 @@ skb->ip_summed = CHECKSUM_NONE; - esph = (struct ip_esp_hdr*)skb->data; iph = skb->nh.iph; /* Get ivec. This can be wrong, check against another impls. */ ===== net/ipv4/xfrm4_input.c 1.10 vs edited ===== --- 1.10/net/ipv4/xfrm4_input.c Sat Feb 14 16:06:45 2004 +++ edited/net/ipv4/xfrm4_input.c Mon Apr 5 12:15:31 2004 @@ -29,30 +29,29 @@ IP_ECN_set_ce(inner_iph); } -static int xfrm4_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi, u32 *seq) +static int xfrm4_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi) { switch (nexthdr) { case IPPROTO_IPIP: if (!pskb_may_pull(skb, sizeof(struct iphdr))) return -EINVAL; *spi = skb->nh.iph->saddr; - *seq = 0; return 0; } - return xfrm_parse_spi(skb, nexthdr, spi, seq); + return xfrm_parse_spi(skb, nexthdr, spi); } int xfrm4_rcv_encap(struct sk_buff *skb, __u16 encap_type) { int err; - u32 spi, seq; + u32 spi; struct sec_decap_state xfrm_vec[XFRM_MAX_DEPTH]; struct xfrm_state *x; int xfrm_nr = 0; int decaps = 0; - if ((err = xfrm4_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) != 0) + if ((err = xfrm4_parse_spi(skb, skb->nh.iph->protocol, &spi)) != 0) goto drop; do { @@ -69,9 +68,6 @@ if (unlikely(x->km.state != XFRM_STATE_VALID)) goto drop_unlock; - if (x->props.replay_window && xfrm_replay_check(x, seq)) - goto drop_unlock; - if (xfrm_state_check_expire(x)) goto drop_unlock; @@ -82,9 +78,6 @@ /* only the first xfrm gets the encap type */ encap_type = 0; - if (x->props.replay_window) - xfrm_replay_advance(x, seq); - x->curlft.bytes += skb->len; x->curlft.packets++; @@ -112,7 +105,7 @@ break; } - if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi, &seq)) < 0) + if ((err = xfrm_parse_spi(skb, skb->nh.iph->protocol, &spi)) < 0) goto drop; } while (!err); ===== net/ipv6/ah6.c 1.26 vs edited ===== --- 1.26/net/ipv6/ah6.c Sun Jan 25 03:08:48 2004 +++ edited/net/ipv6/ah6.c Mon Apr 5 12:21:22 2004 @@ -286,6 +286,8 @@ hdr_len = skb->data - skb->nh.raw; cleared_hlen = hdr_len; ah = (struct ipv6_auth_hdr*)skb->data; + if (x->props.replay_window && xfrm_replay_check(x, ah->seq_no)) + goto out; ahp = x->data; nexthdr = ah->nexthdr; ah_hlen = (ah->hdrlen + 2) << 2; @@ -329,6 +331,8 @@ } } + if (x->props.replay_window) + xfrm_replay_advance(x, ah->seq_no); skb->nh.raw = skb_pull(skb, ah_hlen); memcpy(skb->nh.raw, tmp_hdr, hdr_len); if (nexthdr == NEXTHDR_DEST) { ===== net/ipv6/esp6.c 1.24 vs edited ===== --- 1.24/net/ipv6/esp6.c Wed Mar 10 08:21:50 2004 +++ edited/net/ipv6/esp6.c Mon Apr 5 12:22:39 2004 @@ -210,6 +210,7 @@ ret = -EINVAL; goto out_nofree; } + esph = (struct ipv6_esp_hdr*)skb->data; if (elen <= 0 || (elen & (blksize-1))) { ret = -EINVAL; @@ -228,6 +229,10 @@ u8 sum[esp->auth.icv_full_len]; u8 sum1[alen]; + if (x->props.replay_window && xfrm_replay_check(x, esph->seq_no)) { + ret = -EINVAL; + goto out; + } esp->auth.icv(esp, skb, 0, skb->len-alen, sum); if (skb_copy_bits(skb, skb->len-alen, sum1, alen)) @@ -238,6 +243,9 @@ ret = -EINVAL; goto out; } + + if (x->props.replay_window) + xfrm_replay_advance(x, esph->seq_no); } if ((nfrags = skb_cow_data(skb, 0, &trailer)) < 0) { @@ -247,7 +255,6 @@ skb->ip_summed = CHECKSUM_NONE; - esph = (struct ipv6_esp_hdr*)skb->data; iph = skb->nh.ipv6h; /* Get ivec. This can be wrong, check against another impls. */ ===== net/ipv6/xfrm6_input.c 1.15 vs edited ===== --- 1.15/net/ipv6/xfrm6_input.c Sat Feb 14 16:06:45 2004 +++ edited/net/ipv6/xfrm6_input.c Mon Apr 5 12:23:15 2004 @@ -29,7 +29,7 @@ { struct sk_buff *skb = *pskb; int err; - u32 spi, seq; + u32 spi; struct sec_decap_state xfrm_vec[XFRM_MAX_DEPTH]; struct xfrm_state *x; int xfrm_nr = 0; @@ -41,7 +41,7 @@ nexthdr = *prevhdr; *nhoffp = prevhdr - skb->nh.raw; - if ((err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) != 0) + if ((err = xfrm_parse_spi(skb, nexthdr, &spi)) != 0) goto drop; do { @@ -57,9 +57,6 @@ if (unlikely(x->km.state != XFRM_STATE_VALID)) goto drop_unlock; - if (x->props.replay_window && xfrm_replay_check(x, seq)) - goto drop_unlock; - if (xfrm_state_check_expire(x)) goto drop_unlock; @@ -67,9 +64,6 @@ if (nexthdr <= 0) goto drop_unlock; - if (x->props.replay_window) - xfrm_replay_advance(x, seq); - x->curlft.bytes += skb->len; x->curlft.packets++; @@ -94,7 +88,7 @@ break; } - if ((err = xfrm_parse_spi(skb, nexthdr, &spi, &seq)) < 0) + if ((err = xfrm_parse_spi(skb, nexthdr, &spi)) < 0) goto drop; } while (!err); ===== net/xfrm/xfrm_input.c 1.13 vs edited ===== --- 1.13/net/xfrm/xfrm_input.c Mon Jul 28 11:22:27 2003 +++ edited/net/xfrm/xfrm_input.c Mon Apr 5 12:20:23 2004 @@ -43,24 +43,21 @@ /* Fetch spi and seq from ipsec header */ -int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi, u32 *seq) +int xfrm_parse_spi(struct sk_buff *skb, u8 nexthdr, u32 *spi) { - int offset, offset_seq; + int offset; switch (nexthdr) { case IPPROTO_AH: offset = offsetof(struct ip_auth_hdr, spi); - offset_seq = offsetof(struct ip_auth_hdr, seq_no); break; case IPPROTO_ESP: offset = offsetof(struct ip_esp_hdr, spi); - offset_seq = offsetof(struct ip_esp_hdr, seq_no); break; case IPPROTO_COMP: if (!pskb_may_pull(skb, sizeof(struct ip_comp_hdr))) return -EINVAL; *spi = ntohl(ntohs(*(u16*)(skb->h.raw + 2))); - *seq = 0; return 0; default: return 1; @@ -70,7 +67,6 @@ return -EINVAL; *spi = *(u32*)(skb->h.raw + offset); - *seq = *(u32*)(skb->h.raw + offset_seq); return 0; } From marco.fais@abbeynet.it Mon Apr 5 03:47:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 03:47:53 -0700 (PDT) Received: from abbeynet.it ([151.39.82.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35AllKO008753 for ; Mon, 5 Apr 2004 03:47:48 -0700 Received: (qmail 19775 invoked from network); 5 Apr 2004 10:47:41 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 5 Apr 2004 10:47:41 -0000 Received: from abbeynet.it (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 19755-2565FFF6; Mon, 05 Apr 2004 12:47:39 +0200 Received: (qmail 19748 invoked from network); 5 Apr 2004 10:47:38 -0000 Received: from neutrix.localnet (HELO abbeynet.it) (192.168.0.205) by 0 with SMTP; 5 Apr 2004 10:47:38 -0000 Message-ID: <4071394A.1060007@abbeynet.it> Date: Mon, 05 Apr 2004 12:47:38 +0200 From: Marco Fais User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.4.2) Gecko/20040308 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc References: <406D3E8F.20902@abbeynet.it> <20040402153628.4a09d979.akpm@osdl.org> In-Reply-To: <20040402153628.4a09d979.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.24.0.7; VDF: 6.24.0.85; host: abbeynet.it) X-archive-position: 4468 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marco.fais@abbeynet.it Precedence: bulk X-list: netdev Content-Length: 638 Lines: 23 Andrew Morton ha scritto: >>kernel BUG at page_alloc.c:98! > uh-oh. That was the same thing that I've said when I saw all the leds blinking in *all* the keyboards ... :) > distcc uses sendfile(). The 8139too hardware and driver are > zerocopy-capable so the kernel uses zerocopy direct-from-user-pages for > sendfile(). Ok. Other servers with e100 driver doesn't show the problem. This means that they're not "zerocopy-capable"? > This was all discussed fairly extensively a couple of years back and I > thought it ended up being fixed. There are any workarounds for this, until the problem is corrected? Thank you very much. From akpm@osdl.org Mon Apr 5 03:56:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 03:56:25 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35AuOKO009274 for ; Mon, 5 Apr 2004 03:56:24 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i35AuD203059; Mon, 5 Apr 2004 03:56:13 -0700 Date: Mon, 5 Apr 2004 03:56:06 -0700 From: Andrew Morton To: Marco Fais Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-Id: <20040405035606.0b470efb.akpm@osdl.org> In-Reply-To: <4071394A.1060007@abbeynet.it> References: <406D3E8F.20902@abbeynet.it> <20040402153628.4a09d979.akpm@osdl.org> <4071394A.1060007@abbeynet.it> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4469 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: 1205 Lines: 38 Marco Fais wrote: > > Andrew Morton ha scritto: > > >>kernel BUG at page_alloc.c:98! > > uh-oh. > > That was the same thing that I've said when I saw all the leds blinking > in *all* the keyboards ... :) > > > distcc uses sendfile(). The 8139too hardware and driver are > > zerocopy-capable so the kernel uses zerocopy direct-from-user-pages for > > sendfile(). > > Ok. Other servers with e100 driver doesn't show the problem. This means > that they're not "zerocopy-capable"? They are. It could be a timing thing. > > This was all discussed fairly extensively a couple of years back and I > > thought it ended up being fixed. > > There are any workarounds for this, until the problem is corrected? This will probably make it go away. --- linux-2.4.26-rc1/drivers/net/8139too.c 2004-03-27 22:06:18.000000000 -0800 +++ 24/drivers/net/8139too.c 2004-04-05 03:54:50.478692968 -0700 @@ -983,7 +983,7 @@ static int __devinit rtl8139_init_one (s * through the use of skb_copy_and_csum_dev we enable these * features */ - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA; + dev->features |= NETIF_F_SG | NETIF_F_HIGHDMA; dev->irq = pdev->irq; From marco.fais@abbeynet.it Mon Apr 5 06:58:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 06:58:36 -0700 (PDT) Received: from abbeynet.it ([151.39.82.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35DwUKO018903 for ; Mon, 5 Apr 2004 06:58:33 -0700 Received: (qmail 13553 invoked from network); 5 Apr 2004 13:58:24 -0000 Received: from localhost (HELO localhost.localdomain) (127.0.0.1) by 0 with SMTP; 5 Apr 2004 13:58:24 -0000 Received: from abbeynet.it (localhost.localdomain [127.0.0.1]) by localhost.localdomain (VaMailArmor-2.0.1.16) id 13534-7D6B87E5; Mon, 05 Apr 2004 15:58:23 +0200 Received: (qmail 13528 invoked from network); 5 Apr 2004 13:58:23 -0000 Received: from neutrix.localnet (HELO abbeynet.it) (192.168.0.205) by 0 with SMTP; 5 Apr 2004 13:58:23 -0000 Message-ID: <407165FF.903@abbeynet.it> Date: Mon, 05 Apr 2004 15:58:23 +0200 From: Marco Fais User-Agent: Mozilla/5.0 (X11; U; Linux i686; it-IT; rv:1.4.2) Gecko/20040308 X-Accept-Language: it, en, en-us MIME-Version: 1.0 To: Andrew Morton CC: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc References: <406D3E8F.20902@abbeynet.it> <20040402153628.4a09d979.akpm@osdl.org> <4071394A.1060007@abbeynet.it> <20040405035606.0b470efb.akpm@osdl.org> In-Reply-To: <20040405035606.0b470efb.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.24.0.7; VDF: 6.24.0.86; host: abbeynet.it) X-archive-position: 4470 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marco.fais@abbeynet.it Precedence: bulk X-list: netdev Content-Length: 921 Lines: 27 Hola Andrew! Andrew Morton ha scritto: >>There are any workarounds for this, until the problem is corrected? > This will probably make it go away. > > --- linux-2.4.26-rc1/drivers/net/8139too.c 2004-03-27 22:06:18.000000000 -0800 > +++ 24/drivers/net/8139too.c 2004-04-05 03:54:50.478692968 -0700 > @@ -983,7 +983,7 @@ static int __devinit rtl8139_init_one (s > * through the use of skb_copy_and_csum_dev we enable these > * features > */ > - dev->features |= NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA; > + dev->features |= NETIF_F_SG | NETIF_F_HIGHDMA; > > dev->irq = pdev->irq; Unfortunately, this doesn't solve the problem. Seems that the panic it's triggered a little later (1-2 minutes instead of a few seconds), but anyway I have a kernel panic every time, also with this patch. The oops tracing looks very similar to the one I've posted on the linux-kernel list. Thank you Andrew, bye! From okir@suse.de Mon Apr 5 08:40:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 08:40:30 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35FeHKO024415 for ; Mon, 5 Apr 2004 08:40:18 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 686253F0E08 for ; Mon, 5 Apr 2004 17:03:12 +0200 (CEST) Date: Mon, 5 Apr 2004 17:03:12 +0200 From: Olaf Kirch To: netdev@oss.sgi.com Subject: [PATCH] eliminate divert_blk message Message-ID: <20040405150312.GS11477@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="hHWLQfXTYDoKhP50" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 4471 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 871 Lines: 34 --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Every time a non-ethernet device is configured (e.g. when using PPP) the kernel logs a message saying "not allocating divert_blk for non-ethernet device". This patch disables the message. Cheers, Olaf -- Olaf Kirch | The Hardware Gods hate me. okir@suse.de | ---------------+ --hHWLQfXTYDoKhP50 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename=divert_blk-shutup --- linux-2.6.4/net/core/dv.c.quiet 2004-02-04 04:43:45.000000000 +0100 +++ linux-2.6.4/net/core/dv.c 2004-04-05 16:50:06.000000000 +0200 @@ -67,9 +67,6 @@ } dev_hold(dev); } else { - printk(KERN_DEBUG "divert: not allocating divert_blk for non-ethernet device %s\n", - dev->name); - dev->divert = NULL; } return 0; --hHWLQfXTYDoKhP50-- From ak@muc.de Mon Apr 5 08:53:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 08:53:16 -0700 (PDT) Received: from zero.aec.at (Hannibal_Hunsiker@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35FrCKO024987 for ; Mon, 5 Apr 2004 08:53:13 -0700 Received: from averell.firstfloor.org.muc.de (Orrin_Goof@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i35Fr9D28039 for ; Mon, 5 Apr 2004 17:53:10 +0200 To: netdev@oss.sgi.com Subject: [PATCH] Force IPv6 garbage collection on device down From: Andi Kleen Date: Mon, 05 Apr 2004 17:53:09 +0200 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4472 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 638 Lines: 24 We had some problems with devices occasionally hanging with non zero reference count on device destroy until the next time the IPv6 garbage collection timer ran (upto 10s). To avoid that this patch forces an IPv6 FIB garbage collection on device down. -Andi diff -u linux-2.6.5/net/ipv6/ndisc.c-N linux-2.6.5/net/ipv6/ndisc.c --- linux-2.6.5/net/ipv6/ndisc.c-N 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5/net/ipv6/ndisc.c 2004-04-05 17:50:52.000000000 +0200 @@ -1403,6 +1403,9 @@ neigh_changeaddr(&nd_tbl, dev); fib6_run_gc(0); break; + case NETDEV_UNREGISTER: + fib6_run_gc(0); + break; default: break; } From linux-netdev@gmane.org Mon Apr 5 09:03:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 09:03:34 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35G3FKO025518 for ; Mon, 5 Apr 2004 09:03:16 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BAWZ7-00022E-00 for ; Mon, 05 Apr 2004 18:03:13 +0200 Received: from finn.gmane.org ([80.91.224.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Apr 2004 18:03:13 +0200 Received: from lunz by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 05 Apr 2004 18:03:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Jason Lunz Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling Date: Mon, 5 Apr 2004 16:03:11 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: slrn/0.9.8.0 (Linux) X-archive-position: 4473 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 1627 Lines: 36 hadi@cyberus.ca said: > Jason Lunz actually seemed to have been doing more work on this and > e1000 - he could provide better perfomance numbers. Well, not really. What I have is still available at: http://gtf.org/lunz/linux/net/perf/ ...but those are mainly measurements of very outdated versions of the e1000 napi driver backported to 2.4, running on 1.8Ghz Xeon systems. That work hasn't really been kept up to date, I'm afraid. > It should also be noted that infact packet mmap already uses rings. Yes, I read the paper (but not his code). What stood out to me is that the description of his custom socket implementation matches exactly what packet-mmap already is. I noticed he only mentioned testing of libpcap-mmap, but did not use mmap packet sockets directly -- maybe there's something about libpcap that limits performance? I haven't looked. What I can say for sure is that the napi + packet-mmap performance with many small packets is almost surely limited by problems with irq/softirq load. There was an excellent thread last week about this with Andrea Arcangeli, Robert Olsson and others about the balancing of softirq and userspace load; they eventually were beginning to agree that running softirqs on return from hardirq and bh was a bigger load than expected when there was lots of napi work to do. So despite NAPI, too much kernel time is spent handling (soft)irq load with many small packets. It appears this problem became worse in 2.6 with HZ=1000, because now the napi rx softirq work is being done 10X as much on return from the timer interrupt. I'm not sure if a solution was reached. Jason From ak@suse.de Mon Apr 5 09:19:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 09:19:37 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35GJXKO026256 for ; Mon, 5 Apr 2004 09:19:33 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0DABA3F141E for ; Mon, 5 Apr 2004 18:19:27 +0200 (CEST) Date: Mon, 5 Apr 2004 18:19:25 +0200 From: Andi Kleen To: Olaf Kirch Cc: netdev@oss.sgi.com Subject: Re: [PATCH] eliminate divert_blk message Message-Id: <20040405181925.70897aac.ak@suse.de> In-Reply-To: <20040405150312.GS11477@suse.de> References: <20040405150312.GS11477@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4474 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 475 Lines: 12 On Mon, 5 Apr 2004 17:03:12 +0200 Olaf Kirch wrote: > Every time a non-ethernet device is configured (e.g. when using PPP) the > kernel logs a message saying "not allocating divert_blk for non-ethernet > device". This patch disables the message. Are you sure? All our kernels have CONFIG_NET_DIVERT disabled. I don't see how you could get this message unless you enabled it on your own. If you did that just disable it, it's imho an useless option. -Andi From ak@suse.de Mon Apr 5 10:06:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 10:06:03 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35H5nKO028274 for ; Mon, 5 Apr 2004 10:05:49 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id A7C973F181E for ; Mon, 5 Apr 2004 18:20:16 +0200 (CEST) Date: Mon, 5 Apr 2004 18:20:15 +0200 From: Andi Kleen To: Andi Kleen Cc: okir@suse.de, netdev@oss.sgi.com Subject: Re: [PATCH] eliminate divert_blk message Message-Id: <20040405182015.261e2d5d.ak@suse.de> In-Reply-To: <20040405181925.70897aac.ak@suse.de> References: <20040405150312.GS11477@suse.de> <20040405181925.70897aac.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4475 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 631 Lines: 18 On Mon, 5 Apr 2004 18:19:25 +0200 Andi Kleen wrote: > On Mon, 5 Apr 2004 17:03:12 +0200 > Olaf Kirch wrote: > > > Every time a non-ethernet device is configured (e.g. when using PPP) the > > kernel logs a message saying "not allocating divert_blk for non-ethernet > > device". This patch disables the message. > > Are you sure? All our kernels have CONFIG_NET_DIVERT disabled. I don't see > how you could get this message unless you enabled it on your own. > If you did that just disable it, it's imho an useless option. Oops, that should have gone to Olaf privately. Sorry for the noise. -Andi From Robert.Olsson@data.slu.se Mon Apr 5 10:12:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 10:12:12 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35HC8KO028702 for ; Mon, 5 Apr 2004 10:12:09 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i35HBqNv030049; Mon, 5 Apr 2004 19:11:54 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 9C04F903D5; Mon, 5 Apr 2004 19:11:52 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16497.37720.607342.193544@robur.slu.se> Date: Mon, 5 Apr 2004 19:11:52 +0200 To: dipankar@in.ibm.com Cc: Andrea Arcangeli , Robert Olsson , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <20040331214342.GD4543@in.ibm.com> References: <20040329222926.GF3808@dualathlon.random> <200403302005.AAA00466@yakov.inr.ac.ru> <20040330211450.GI3808@dualathlon.random> <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4476 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 2468 Lines: 57 Dipankar Sarma writes: > Robert, btw, this rcu-softirq patch is slightly different > from the earlier one in the sense that now every softirq > handler completion is a quiescent point. Earlier each iteration > of softirqs was a quiescent point. So this has more quiescent > points. Hello! Yes it seems reduce RCU latency in our setup as well. It does not eliminate overflows but reduces with ~50% and increases the throughput a bit. dst cache overflow depends on RCU-delay + gc_min_interval and the number of entries freed per sec so this means RCU has improved. Also the user app doing gettimeofday seems to be better scheduled. The worst starvation improved from ~7.5 to ~4.4 sec. Cheers. --ro Setup as described before. Without patch ============= 2 * 283 kpps (eth0, eth2) 32768 flows and 10 pkts flow Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 5419435 8802471 8802471 4580569 44 0 0 0 BRU eth1 1500 0 45 0 0 0 5417465 0 0 0 BRU eth2 1500 0 5372943 8849348 8849348 4627060 44 0 0 0 BRU eth3 1500 0 46 0 0 0 5371007 0 0 0 BRU /proc/net/rt_cache_stat (3:rd last is ovfr) 000034d0 0046284e 000c8986 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000bf952 000bf173 000007b8 000007b3 0081b228 00000000 000034d0 004559f4 000ca247 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000c369c 000c2edf 00000799 00000792 008057a4 00000000 User app max delay 7.5 Sec WIth RCU patch =============== 2 * 284 kpps 32768 flows and 10 pkts flow Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 5838522 8704663 8704663 4161481 44 0 0 0 BRU eth1 1500 0 45 0 0 0 5837586 0 0 0 BRU eth2 1500 0 5957987 8643714 8643714 4042016 44 0 0 0 BRU eth3 1500 0 46 0 0 0 5957051 0 0 0 BRU /proc/net/rt_cache_stat 0002dcb5 004b6add 000dac08 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000d029a 000cfec3 000003aa 000003a9 008c80b2 00000000 0002dcb5 004d2db5 000dbbda 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000cfa51 000cf67e 000003b1 000003aa 008eb195 00000000 User app max delay 4.4 Sec From romieu@fr.zoreil.com Mon Apr 5 10:41:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 10:41:28 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35HfPKO029669 for ; Mon, 5 Apr 2004 10:41:26 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Hclgf019725; Mon, 5 Apr 2004 19:38:47 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35HcjNL019724; Mon, 5 Apr 2004 19:38:45 +0200 Date: Mon, 5 Apr 2004 19:38:45 +0200 From: Francois Romieu To: Srihari Vijayaraghavan Cc: jgarzik@pobox.com, netdev@oss.sgi.com, ak@suse.de Subject: Re: [patch] 2.6.5-rc2 - r8169 DAC Message-ID: <20040405193845.A19650@electric-eye.fr.zoreil.com> References: <253ea2a8f4.2a8f4253ea@email.bigpond.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <253ea2a8f4.2a8f4253ea@email.bigpond.com>; from harisri@telstra.com on Mon, Apr 05, 2004 at 09:38:46AM +1000 X-Organisation: Land of Sunshine Inc. X-archive-position: 4477 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 642 Lines: 18 Srihari Vijayaraghavan : [...] > With that patch 2.6.5-rc2 + r8169 DAC compiles and works fine. Nice. > There is one problem however: If I unplug and plug the cable it does not > come back to online (even the LED on the card does not glow). I did not try > reloading the driver, but a reboot does fix it :-( (later today I shall try > reloading the driver). OTOH the vanilla 2.6.5-rc2 (or rc3) does not show > this behaviour. Reloading the driver is known to bring the device online again.The issue is known but I had not understood it as a regression against vanilla kernel :o( I'll see what can be done. -- Ueimor From vda@port.imtp.ilyichevsk.odessa.ua Mon Apr 5 13:07:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 13:07:35 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35K6uKO022515 for ; Mon, 5 Apr 2004 13:07:06 -0700 Received: (qmail 16182 invoked by alias); 5 Apr 2004 19:18:11 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 05 Apr 2004 19:18:11 -0000 From: Denis Vlasenko To: Jeff Garzik , Francois Romieu , andreas@fjortis.info Subject: [PATCH] 2.4, 2.6 patchset for fealnx.c Date: Mon, 5 Apr 2004 22:18:06 +0300 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, Denis Vlasenko MIME-Version: 1.0 Message-Id: <200404052217.35883.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: Multipart/Mixed; boundary="Boundary-00=_uDbcA5rEVIjmlkt" X-archive-position: 4478 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 25979 Lines: 401 --Boundary-00=_uDbcA5rEVIjmlkt Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline I almost emptied my TODO. Hurray ;) 2.4 patches are stress-tested. As before, I used UDP flood in extremely memory constrained box (kernel OOM killed several processes while I ran test). Looks ok. 2.6.5 kernel have console-related slab corruption issues on test machine, can't stress-test patches. Compile and boot tested only. Pings work. 24/* patches against 2.4.25 26/* patches against 2.6.5 fealnx.0.diff replace dev->base_addr with ioaddr 2.4 only: sync with 2.6 fealnx.1.diff replace magic constants with enums fealnx.2.diff add 'static' fix wrapped comment fealnx.3.diff fix pointer substraction bug fealnx.4.diff stop doing stop_nic_rx()/writel(np->crvalue, ioaddr+TCRRCR) in rest_rx_descriptors(), this can inadvertently (re)enable tx and/or rx. fealnx.5.diff introduce stop_nic_rxtx(), use it where makes sense fealnx.6.diff Francois' fixes for low memory handling remove free_one_rx_descriptor(), not used anymore fealnx.7.diff Garzik fix (AFAIR): add locking to tx_timeout fealnx.8.diff Move reset code from tx_timeout into two separate routines: reset_and_disable_rxtx() and enable_rxtx() New function reset_tx_descriptors(): clean up tx ring after tx_timeout. tx_timeout now does: reset_and_disable_rxtx() reset_tx_descriptors() enable_rxtx() netif_wake_queue() Absense of netif_wake_queue() call was probably the cause of tx_timeout() stalling all future tx. Add reset timer, fire it 1/2 sec after 'Too much work in interrupt' It cleans up rx ring and resets device a-la tx_timeout() Remove stop_nic_tx(), not used anymore fealnx.9.diff set_rx_mode() can be called by core code, needs locking. __set_rx_mode() is a 'dont lock' variant fealnx.10.diff replace local delay functions with udelay fealnx.11.diff beautify some code a bit make driver coding style uniform fix bug in dead code -- vda --Boundary-00=_uDbcA5rEVIjmlkt Content-Type: application/x-tgz; name="fealnx.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="fealnx.tar.gz" H4sIAICwcUACA+w8aXfjNpL9Vf0rkM4bRzIlmZcuO+7EhzytF19Lq485Mnw0RVlcS6SWpNrypju/ fasK4KXbHvexu1Y6FgUWgEKhUBcK6DvW0JvuvPiSH1nW5UatBt/0mf2mZ0WWNV1T6w0dyhUFfrxg tRdf4TMJIytg7EXg+9EquHXv/5d++nz+VX3ne5n/Gs6/Wq8/z//XnX/+VFXkas/t9590/mFy67q+ bP71Rl0X86/U6liuaHVFfsHk5/n/4p9KpcLEzNuFM99jB2OgRo2p8q5e29Va8CDrLyVJWgpV39U0 DvXrr6zSrJXrTIK/Dfbrry/Zj65nDyc9h/08dL3JdGfkutXB6/lyJxpEvj9c+M4ObE3FN9Lsm54z tO6pTraWFY52xoFvO2HoB/C2sLPNLuPfLLofO6wPD7ZlDxxmDd0bb+R4UZVt78y2cu1G/jjEDnBo DYXG1lDqYnCFwIkmgcecINh7yT4DFtJLBuwUuTb76Ls9Zpo956MzdSNBPDNwRv5Hx/Q9pxhGwcSO 2Nh2EYhtj+Fv6SX7A5oVrzwnwleu7bBtBNkn4BssDT72rMgqUp09jpzWKOsaYKe1AEnCrjAOXC+6 Lf7WNs7NtmGwVxyLXcbRICpMvFvPv/MY7+if3quSGEpl4oVAGqfHoBE2asqIvdUzYXC3RRxd6WUF CNufeHbk+t4uM+BtyCKgadcdOUBoAGS2P4HagXPjhhGU3Q1cewB92YAB0Dxk1/dMZf3AHzEkPzaY fuq1mlZnkc9kBlQM7pmyo9WruqIzv88sFjq27/WqrA3zCI1kGoXXiMZcgzEy48AJCbCpNZkH7fwU VtkGH9Gg640nEfzcZR5M5EY1VzfoTyJq8Wka/ONlpZDMnT0A4RaNxntQiPP40RpOHPgBP+8CN3Ku i0UEKTF5KtfL8FfXSnuFnR125I9GltdjTbWm4xwMrQjI3JV/CjkZqQmAA+ZhyBdEcXpThRfQI7Br MYdGieCui9CHXEJ8CBcEKwJmJcSyxH7+mTX3HtbAJ2wh08QWjKLfJwCxPosEiCWfEe2XFVqcxNIk QYo5Vof/nQBqzPI3EOHOwqUMqwa4b+zYbt+FOhFwe/Ux3BN3xKrVKpHvgW1+ee7JkkMpJ48qPMLs yJyPEgAomhETnJVAYkFVN3JhqDQTUKnnM+wpqawuqkwAfVZMe/g5xaGEb3OdJ6+ooiS5+P0ZZc7Q ESwiYCuZZqDN4iQc+AHwTzL1bGsLuoVXKINqpZh1WCLeJ0Pfu+EYgyjpmfYIsPbN8eC+yN+47hia JJoxf2z7PYc/A4TV448gFa0eiXxSnIoGakVqNJqxdkG9NXBvBuzs+IiUU6EAzQbI8GcHV7+ZZ52O gX9MeL+Hb2lFD4sIVI4x4FTM8LqGa0cqFCaZn0z05jnTKO7JCm/Z69f7TOH6pakjXhLHcg69MkNZ QcvjyRDlS/qR6CqyWis3mdRqyQm+hYI3rrwGy+HWv2UESYVcSPAfn4mpgGepN/qRwQhsVI5MjA0v YFiPAac5w9AhBV5AGVHka4QhGx0jOKrFPQZ8WRJTjl4uR7L51ZBE5b7a/le+tv3fUHV5zv6XlWf7 /1vb/6llv8b+l1P7X28oZaXGJPpWiKnzNnEIJrXpubYZTLmodH2r1wM5QD/sgOvql6QehJwQhaDZ i38eGeZ70/jQPi+VRU0mse6RYRwZJa6PQDAkejqYUn+k2QqxwuHKq8yXDz5OgfmEMivE2uKHImqi YXG2D0ACUID/Plx1Ly5Lqaag1kolrtZi7QPrTaIuZ/uS5sf2Z3H12KQYt0qF9wVdSVxBss2QZfv7 ud8kJa6h6u1eLBoYn8Rms9yCOWzq8IVTiEJt0TDYymFI9NRdOll8QNnxkMJfNZxiBn+JnrtiIrDu CtsGhr60Lis9krgrsEHScoTW9Mzm5gBnoMatgZrcShzpvtdz+uzs4vjtaZucRFpTZFOgn+f0THCS QjBVsSFE/IeZckkiInGvEIxiXsqVhXAV0zL2I5g1bh+agn+2FfRMtzeVJKFdlSb6wBJ8qwI/gIKF 99ZxR36wmy7AmswujzrMvreHTsiKaCX0h2BusbEPDiGYDMg+4AZGd6UqtgH0eg+G8CRwhve8lcj3 uWgoIvnBh5fQ9QU7ygodqPN+4IMnD+W/8EU+x1KLZpahQs3N6SFxJJaProslPhU0Uq1Ro5FqIM9i HY0a2p4EZjQ1bX98Dz98Lwr8Ibkih5dd9GK6h1dXA7cfoQm8za4n/T64v6H73+SWxgYMUggN/6EV 4toK7cAdR1BGIymQeQMtinAAl79su8Rm+q8ioInVzaF/49rWkKZUVJ9DdgE049CV1+EtYgq14CFT HI9vn3U/dI7YJ/g6PYavI+Oo7VnXQN1P7PLgmD8vqId0gRbBrnE8JM7lb90sdca3UUIaIrquqUR0 XW2m7DVrU3U/mEbn/K/mVefvbSgB7uYzC4MFoC0cN4wZ+PrmH+7vwpcowst4lJklPlOKSxJDLRNv ZI3NEFoAlsL2RLCmzKgCn9QyN9AyTdAwy8j35vHZgdm9OG6/6xy1OX8VoL552w8cxwToXM9ibem6 VlZUHL3WwgfOcwSYzoO8xw1gp+f0fhE2MFIy8K9hDu7BFYzE2youKHC3xIIc86U1tgLLQ3UM6yD0 vVA0Qb0kDCK4R1DR7I0sJpF2K7qSUtrGKfP7efaketyUz7cVM9vc1EjK79xchbmV2JpmpY2bxbZ+ FyJ1bqlF07nVlq2c5ayK8nt1BUH2Nq26DFGZRr+sCfBU1/W/ceVVGJDm57pfqSsyLb66nMQ5aZFU Ktf+zSS0QeH8zORknWRijO8PjHPonL36S7jLuiC3RxN7wO784JZZIpAQTMbgFL+iqkIzv0JNNgn3 5elf9Ko+rf7Te4W22UeYZWvEvebA5DCcsXAd/4AjwDBeZGKsJDCtYOT0xJLm2m8pROJlzb3NOFwz 76vOdOzCb4Aw3p6bB93im7/vqGJJF0CJcLDi1ky9eFE39VpZ0YCqTV3BByKrsJ1IQnP7aZGZxKOx WRPacyKUIiIS7Hp9P1ESMzHjMhPlIr6ewG/jX7BSVjf7yFZngtjYKLDJRyuC6h7G9Wh2sQh9+QqC 2uN7jPP0/crrHpSDWGXHxjvz/OCsTZOeBxFmCod51zauOhfnC8CuJ6GJT2UKnCM3ZaV4ieQJr7G8 6xmIJT3PQK3vmC+4jA2XIT4wTwQLM9yU+vaox7bhT4mzWqvFLZZWK7ZYYDrQKRqA8rXYyO9NhsBo 0cANGfwTRiK+BvkYMBCIqDx4hyED0wpk58TDYCCpF0fsk/Qz1mhloVG53KZMt06QJBwjE0OExa1Y 3tNMQJ0Xz5+vu//79Nu/a/d/1fpc/Kem1J/jP986/qPt6rVN4j9qLY3/1FUy3flX6i6NB/chWBog +zV1j8RRs7VT31E1BuquzIrXzo3rlVJDFvcMoA7freXuECp17rWR+rgG/88UuvLyzd86x+3zbuek 0zYozHF2D1YtFZdiI3/G41tdhwkTAH52EYX0Lal8jPQugLlACUowRIpag0hBX6kdhVX6Q+smxD7f HFxRZPzD0TuD9zrqub5JlkGRhH2GemWGoAfHoHe6nat2mSWP5snb09NSihpaScK6yMMIyypLvIPz A+Pg/PTywBBx4yUVE8rlKoj5xX19MLFtxwQzyrViQyoOKLU4KVopKZAShIrbNzH8j8SQiQL5Uho/ qBprMoyoiJsMAkd5wXiMD5fHIl6WACW4xy/Zzg5yYGtHQYXo9u/LVMRYxhijOJcsOzrIKGUPTVVg zIgiiqAUKZThB3dWAPwbTXeCKXO4L0xMnG3nU66hwsatkDpX1Qa3HMWD8IYztuP1vPEowhlPQagC 2rLBFLU0cSSVwRCOhg7ITcRfhAAS+5529YURQz5X8obhNg1PtIj7PDlsYzzh7fkJxhPOuxfv8ME4 fIulHXzsZLDqXHGcMqN3R3Oj75xtMPruqtHHL5HSVDMCdzlEL4R48j9BQ7pOuCfmGc24sAr+FIzS D8IkSqbJGm7v0LfIyVjribJC3o1d7wCurrHK66skW+R5D1BXWmVFxwiE0sCHOAK8NC9lkaVaQpKD UQfE8WwKCm3oEVQKuW2BxOncB+6ZmgkvmehX4vRloOOGknlO3q9pheX3vL3JyISZoS1uHvgeAKMP yUGU13IWZz9wCcauB+S3b7lXiE+CLZdii8GEPD1zpCpl6bSQcWPWZ3yHHcTpRFOzLjS0PqMI+Zqi ia/Vdcxwgm8VGJerLOGlZxzyBfVFn5ssSymmzMRbQJvEMegY/2Ea7e67g9OioD33mp4t9i+d//m1 7X8w9mX12f7/Lvd/1Y3sf6WZ2v+qptP+L36rfPOwYEzbQSCsKfqoZVSEgWM74OUz0pqk+z6TeIRX hy5YEa5HevLciVBIH/le371JUgnJipA2Ai2z96R0UTqB6iszg+8NgxhDC0W0c9L5cNbeZaE/chjK OR76cL2PDoVHwKTBlKwzK7jFYIkbDcCSB7BfSnEDnT679yegKT5ivN0OyTbC5Ep27Ua8yTIbg9UU OqzvTtlPzogG7YC2YcLAMq9xNLgPakzP4PcZprUg4Ry5DIWXxsUZ/WzK5TjeP3JDe+KDYMf63FU6 OCQgXQBZtu2A7XUdgCC20ejgQLwlNQ80mkRDNwNkXPJ5a3KoeMoCTKTEbRsOdSqg9DwUad4E6qot oNQ8FJ9+ASYVaM+4ff6mwGE5wxC/ON4ATYkeH2mW+rzSyXGBV0J5E1fqT4ZD1psA3acZ0MsrRRaw cjOBVWQ2unazeODedQynJ3BRYqTPI4Ety0nbSqZtOdM6E96E2Co/fGtcdTFVKlkjDlRjnREDs2SC bsK1P4l4yC7tyvhwdnHcxmqFdG0ho8SoALdk3jQ5IotYRlQ4OCxk4HUOv4h7YvizLLyag88xUgxv XGbgkaeWsFQMf5qD18vLmEvAA4cV1kiZfAUjM72kiniNdHonHo0BZjg707x6vInPG9AzjMq9u/EY WHWWQYz1XNpzIsdGkZPWWc2uCyoYGcxEnXhoCzDjchf5sYvZ25OhO2bGlORXdxrvXaduSliNnVOt US8DFpKWZNn9CK666zns9EMXh2ee4MDgg4JGjr1uRd0B1UCBH9qSHNzHqa82E1ZqKruHzkcH5tpB sDIrOh6mTPLUXKirVVyvojAbhSpKmbh/pFg2/SMlXQpzcpxPEUnnJN+OLM+0Q0Ak82dQKLPDsyPj ykgT3ilWHtPE9W474duxWkjliaA7tnP55m8xXfWaTD6/XldSlz+fPRU9KnsKlQJ8luUXLUm3WprB I7I+kmyPKE23YgXyPlakW7EN063SxbUw20raPGeruzxni8U5W0meJM1Dne/a6cjni+cheOQ8KA+c A2PTOQi+0ByI9fPvzoHx0Dlo6S0KHdaTRN6se4kpKatiR3EuVGb7DcOJFKLYJ0uqpYi+s6E0HrID kUXRutCJGCjTvzKhviuFBeE9YakkFRJrJbEoZivFls7SKgKpZKxQp93txEkNm0QARSp0HVMxJUXW GnFO5ubbsyn9kjh3GgwH0iHys1J4ZbA+ZYiT2eD8ClihO9PIPNeWZMHsM3Vvga03G6fP1eBx2IE1 7GdqbIo4aoUHos6rsDS/2zFB54mUA67NzxYhnYNUBSQH5Zl4ikr+FnxrSWJBpo313VE6OShme2Dd OLHoEmUZjt3aL/5Jg9gq/gnzsDe7Crb2mQAgoQUg9M0VKN9ZmANPLOZSKujiihlrmm8zxGyYHQyM hp8DmVlaWI9vZixac/ytoDRb3K62tF15Tcs8LzZBN8t1MIMLmz05Xt4kvssl5ypKvcmTLxvpxlLh xonw0ADulyVR+hSJuNEf9pk/7JmxfoqTYbJWRazIMtVE2k0hq/QWgOUsDLGXtFGd1MiIE2o2zIwp cEUR52qqIN8w3q7qdRFvf2z4fmlkvKnzxMRWmg1KRIbawnLdYt0PF+/P+VpPMntF3hID/Zgffao5 SrnspRmwWFckinKu1+LR1SmovFNMz2zjn7fHqA3fnKRVlo2Wv5xtsH0kEkpqGuUiKzU9c5YGFIfb N++sW8f8r4kzSZhO7N/yI4FI9RHoMtEmmid5J973hvcZwbuUNGmq5hKyiCGS9YX5wQKTAuUKz4W8 u2nIu6GpPNuykc22xFRmD4+Xunj2zxoClkP/BrUli6xxKLawcslv5xfdzlGb575dzvrY3J/szeS2 cRYeOSNQ/sWRbfbdIbk8eH6xzEQeZFJe4stQRIpgUBQN+sQODvHPGa239GUSAaA0XXLuk6ezvfS4 EtKUKy/oiB+QfQ3O+zAix1d0bQ5dmMaS2A749Els3fJd7C3WOTkBX/307O1ptxNzGzqTmAFoefd4 cnKEx0fLmFwk4gNA07SbhKCPpsUKIiwZOGEprCA0gaDtoYvhipGN33uJ5RwzCtihpGgbtTo+iHWA phqoMsqdArlqF9vdN0CM9nmZ8YZAA4xcMgpK7PVrptZL7F8wKu2Er7tkSP/AlgCg9julSyuYJw1F 8dGtR4+WFsImAv7B0v3hoj21WtNhY1pDsjDPDgw5u8GbgikzYEopTr3NWBR/plHTODE2+3YmarY3 v00viLn3kOTM/2P7P+pXz//SVFWf3/9pPO//fPv9n3hnZ/X+j5zZ/9Fr5K7zL5SR8zmu9tAPnSXJ rbiksjnJPJU64AcARPhxRVVxtH/DKJm08Fzi2sgae0ygjJ+NJOuRfyFtuGVZeUhESXrcWUr2mMAS v1eEcG7QSWVuUq+/GIR97xeDPPW1INJTX1wiPTWG7KkvLmFPffVEfA9Ck87EN+kioThnaujfpbcg 0N0CqM8XXi6w7G6BJR6dJk4yasmVRdlFSee0YGh5CVRcGjybWZ8Pr85P2go/B5YVeB5YmTPA/j4z Mud7StmziMGUu3aU4WOgBxofJ5MV7rLK8oIBPkS+5sf2oJoPOxHynJXzDe0/7avbf4qu1ebsP1V9 tv++vf0nb2b/6an9p6hqk/aE4wfuJ2eOVWeyJ4vp4WRWyWa2rjoFys+gzqTB5nJ3Tw8P+PUCM70E cS/BQ3oJFvZiiF6krKOYOynL+NVa26XcIDNl8VjLFNuaRT/XcLCy4WCm4WBhwzHGm2ePi2RgoT8U JT2LDXrJt0F6o/zn+QFhEgCsrEB86UyUn2a88fGBfJq7GPdCl37Zvs3/l2TTOfmvf3X5r9YWnP9S tWf5/x3If30j+Z+5/4fsTH59AT4oGYsTfZorTE2A9Xvt9PH4iw2ChJ8S4Zlt7CtZmPloZ14GzEVG UXLw7IYfigvM7S1ubpfIHF9i8YNpnxGomhCoarpL9YVlX+Xhsi/d82ootKum11tJ9kB8LV+Q2X8y Ojz5ItlvmocxOmJbTMwQp73YXqQta0k8iK2wdTHmUnI92gJW4U1Lm+8nIuhnBBcZKHRVHZ/5jDsW CXcsucWt1pT5qYmmsjTmBeg/BeeuO+0ikoE6fda+uMTT3ZhW4vPkaLoPxoH5uIexRz+FzIKiOza2 7FsnqrIrB894R2wyjg9obcLzMQ3qGt+TruuyuDKK9hRXrweCwDtNXG/iiN/x7gzlxPgjByQDDJj2 Kst0ownGVWi6udCwB+5YpNdszi5r+eUBG9B8Bzre6aU8ZbzwFynOKTj042wshP3u9X/t68f/5cYC /f98/9/3oP/l9fq/tltr5OP/9W8X/5eWXDb4JYL6/KY8PtwW2DrZ6NqyMP2aDYk/HnVd4Jp79qRF l6I9/p496d+7Zy/JiZHwcsTPOGM5JqE70/EukNgdx+elN6aL27dElNwLI5aHAuYwYQa2Qe+JbBal QRfDKkozfyy/iIlR8b2reBadMlSzl7FisplIeLxzEl3Es+9J3vOj73RlgXVjuV4s9R+bm1V54tys 3Gb8rHkVrdSYj0vIatA5UklpNNJbgzfIV6g8Wb7CzIg3Gu7/tHe1zW3jSPq+Kr8CM1ubWKGoiBT1 Zo0nlRd74ro4SSnOXm625lSyRNtcS6JCSYm9M7u//dDdAAi+U7LiZHed2h1LIgCCINBodD/99I5B CkT/1O7iQHRDdmcZvIvI6tQIXnlcQmZ1ruZwle2UojIG10wkOHAJOpM+Yo3McWrkDEdDxb1PBTfW 8mY+pjhdyWl1b6P/t7X/tO9c/+t07KT9v9m61/++tf4XanYF+p+Tiv9ofwv8xx3rf5bVcgT+vtWU KqDCFS6v0DrOHhOdKl65OqNz+xBt6EgCKuw4vOhw+fcQWT/lJ3P+6PznODGrKZUWbO2AvQH2H41J GLaO5+4KgBXT9fiKjv4BsLjR2V4L2Em/UVXB0cNrgntEL5xGPCseEqNs6EmxOxA4zUZLdubCeX69 pJBqPMLTO6xrQTLZT86SBUR8ImXHySJsxR6tRt60piIr1IiHVK1Hg7cniqzV3HIAUh4h5pdnEOeU 4uCPMEBbtoD52215lKoghgMTaQBbbnDNPo8CD5DFy5A6Rj0WwFIJ2Ltas5+48trip7mnwL07fP7h aPj+V7bP1HWDNYnNUrMzCsaYQGeMSQ4JzD0JtkyMlagrG04AGohNRX8weKq0UFOr2WvXmhDF1Ox1 arZuVzZvB7nAlCelIRdmPuTClNbLvDUcaQB/TF3zamLr5enHdBmR6EvWNNtyapuIQ47MEL1raTUo 4Q77Xiz/pmQIL7Tlm/m2S6OS9Bmzx0Q9HbbbF8d5r1/oNTUS/NaDNH7rFMJqFNX0Q2wCGJIMO50z WRzBv773QUq0lmAmbXUVs/BdmbPN0uZso1RJMA4kl7HwfCybNiDJ1etItiOUgRyp0xDmirbTITgF WNitMEuMFsvDq03d+cXqUg/pEaUAiMmnMYZbRCUrX2TTEbAG4AqMUnWg5T42HXnVuU/pa0SJggVS 0Ij08GhszcnBFCUigTYvD59/+EVdqWDAzfGjGVtCGoBJIsJGFlRWpwoZ7cWHPGGeKFIs8IyK5hLQ fBvmrX0bsrI0tAmiisLKbFeOEbaBY4Smbo+sP+1eQ6UkjETfoKI4XKxXpMemLKgazEmY3VWNljta RKkgZqVS2Wgfz9JwpezGG5pmhqIm3zJqlovAX/ljZObnb3UIlr4hRr/Bk+F8VPFmjWbNtnFUelo0 nb6Yz24gJYZxIJ9dBsRHouRiYyDOAMJomHr8MOlSmfOHilaE0j9E295euTfjL3BTzT18ZyV094y5 QkNRqeTpRhRu9Q8ah4wRl6OC5QsE4SYChKEHGtmOJoAHj/kQaUNkUpOAx5GsD0KjgGK3sf907h7/ 4zjtpP3n3v/3Pdh/nDL2H6en4X8shzgk4W8nhv45HV3BXB5flToFpKnLuzgECDeQtNt0Wkqv2pTg lAKNS8OOCrRdytCKMgFDZA6A4ekxe/WrJCHV3ENSkAQioWuMwFT3ZbHQhwXSSJXDzmAIb0jzMXHP 1hfVeGgzalwU2XyCLq6lO3UxuAcTlVJET01Gef+5W+9eU4oPmeFjTIR8eCWR3yOFTrSmVU53UYoz k6JYHXrBp+XosxvSidbo2apkkson3iZ1RLjp6DFCpecrOgdpJvZELi2uEPTKAWyVKyaZlkRNn5CC lohWYYR4SWCdTh8kI69ZMRNxRGLZTpRPSBFUgIWGQk7saMhJsRkgKiXA17X8HuwG/0H+n+6d8792 bCsF/3Pv//kO9n+5sxfs/23N/4OoVgP+SDYNOCCg8Jv5c48vSVy+KGbofCrWIPmakYMBP5KE55UH dKjFnQZPw8kKWsYlaXNLJHdKbn5i9xwuPyevSdItukhPcRS4n9bufDW9oTMOFuCb4pXrLog4djT5 22jMS6BOPh6Nudx3ufAer8SjQsfklltJ4FnogwAWOR3CUTWjOCqUczqgpJwfLbq3lasjhCKJ+ujo gOYDm0ZS+OaUjjS+usaiPhz+S/UGYUAwd4rLwygj1w+4/VLOwiqDUrIJcmF2wcFgAPtfZOxjeZf8 xVKOkfZT/25dnmbU/VHS4WnmZdc9LZtdd/XVsuuels2uiy4JOKmnTcXSXuMtExRjkhdkgjLaXXna ITM43D9k0UEZdcAeaqk0+rLkxB96/niFCRpmnkdf1FV9roE/LmW6mYLiSi0oXjD8ApItef2hXkDc 6gtQ9Ez8C7qAuT6Hp8cnh28/nPYpDayLLN4yZn9IndnTjFt8mweh1euFkQJAh4uSm1j8RY6LLBUS Zbe3yk6mZyQS8wmGp6jIwUQJaaUlKwGMQWzTyMoI2CD5L/ISNHRF1+bP60CiDLvh1Jq9LJ9ksazL Px0LvZj2QbTrgmI88ZZIUhxcQ+YY/ElLwQJ1kkuCFxqKegT6ylGOzd2eaz0SAdn5IiVZGAzVBKgF oifK2o+8tjxQ0uMAm3u9XuZAKYTX7ySFUs62DDB1qJn8ebHPfqxFghNR1hS751A0ibZ/pE7zhvb0 g3lVb/ev3m91Pa+lrMqfh0X7dprs2yqvb6dFfYNEm9GGcjpTFZ5fkv4DF1Zonf0S+EvBRq4Qywct SznthNZ2O+xibpxGPnyRd+GlWCHRzERjSFyUk5rILIBmFuRdSTw62AHcAKhRFwFfYsgJ5y3JJLIO RiCNoimRNDryZEzuLtJsm7dIs81Enu34lGs1NB/1LbN4pwDWy2XsRji5UVaYYgIuEqfnAJUi51lc cBJ1X760RNz+jkK4wBCT54WLuuu3jThnKRHntKUBjK0lSDQ7ViJRbU64OMvLI2am5BEzkr+BW5P3 d37BZ1rExyhmsId5hH2hLxIb/79KOjKWl2lMTt0NTlTxabeBzXqD2ZpqLzbC9K7JnVztzVItCa75 SPOFNneDm6R/vrQZtxLNzad9Eyf4GDG4/lUc4+XSSuhBckLC8cYProirlB/oIdGLTL2xr6qvUlYm CS5dWsg2iSqVDqQaVyoLk85Azt1UPlUm5GGlSD/dyNSbMtXKqKi7FHIZ00pqirnzq4SmaNxGU4Sb I/Rkcz3RKKUnGrfQE42t9USjlJ5obKInGnE9EQFllfKOmcL1mL3e0hfbRgtha3poI4P+GDnRAlav i9Ver7OnTynDisY4ZqFlz2q22yGhSvGbCZMUJN6EEAIIG5j4yv8UKwtgpAAhKh8/fuzLjiWazMk1 yRDcXeH9NJiVR57Tz2s3KyMltvqbYi1DM7LltOyaY5d1Iwvd7gXodJCrnE+PG3bpg612RUujjorC XMICt7YabSgNM8CiMYkXhXevYvBuo6KpdSnZPPXrw7G/uMkuFGMykPMHHaQAZdEuRCYi9rLUVFXQ 0+grxh5A6KkOYBU4PzB/r+dZMCCsQJ7QGgHitCb4wnbnIRTo9K0CAkFJeDdX+FwAdtLvTNdp0UZK geCIllQ7sX5fDf5OiMIoDLfRV7+Fi48yhMACdSeyTUrLRdN17q/E1Tocovh6Fme8BR2nFiMurGi6 jpb+XEyNShTim7p2DVy7RsHKTbSVuV4N6zcp8QvT2hoRcaBPGbMov23JqnmJboXGw+7UuSwyqhI3 SJufpuyGFm5smiol7U+sISlTsnUe4FJfjy9RO2WjVXiIqRHUQik8NPsOGte4eSdUHo2QRUx/vhp/ SNUtFQA3S/O0+qnXk+iBV78+sSUUN2b6jZt3M4OSG/KyVKd5IT3zgFFRS5lKgCAnlULq0moJQ7l3 gQupHZkPzO18Va0ul8Q3i1oFnV5qwXUNBmypKkYPHXEUjiqiHTtiB5F+oh2kMt1TnhcZDo28vFKj WHqzxRS9KU8jXdFOOyIrCQH6w8QTIpWSwBHuaRHJpIX02ioMfvtwYCP1avTVopYD4hVEK+V4Dz5J aOx9PPF3g//o3T3+s9Ny7uN/v0/8R7sM/qOp4T8d2vAcla5NOsPhJAYetOGK9iDhD9xD/RckAW6y j/Wk8cpPv+D7rnvBpTD8t9rfjGAr5l7XTY6ZNSLnguGwVJ0YSiAsgNst7/wF/wU/lkMwKGdwRnE1 Oh4Xq5/42HzC3Z2NZ5Nkb4owC5hpr0OZ9roqzU86IlJLmHXlX1U16KTGcJJu740OZWjRzjCRKT+r QxBJ2+nE6DN2bJLewvyc9kybN8O+uRWbtAKbYo67dk+pq8Lx/VDZQoQH3FAZULMQD3ENusQyEufq hUf2G97GFA7TD/eyInir6pxdJfNOjnExaZSaLnT7ctrszLYnReqWdDxtLFY247UssLrm7f/tJ19v j4Fct51WK2v/x8+0/9vtTqvJ93+Lf/gv1rrf/+9M/2tL/c9q7FwBLND/nE5b6X9N27ZB/2tbjXv9 71vqf1Zvv+XsNwv4/0QpO9T/uhj9o9Bwf/Lm4+l64rKfuAxcXz/hSk398ufk70IZSb02DsZNG64Y 8SsID8A6eq3RcvZEQEz8gF+l0774ThEYITx3NOU7BWRfoR002sqZx4/ES7gBpsKxICWJ0bFU9LrY Gvk+rPZEFhXxXAQjHaiwsQXuzP/sZrLZJcR9zKULhUGLnASfwY+7twixd51mp+Y0IVFPTwXb6tak w8GA/Ui9AA8tdANHYT2/mvtf5iJOk7w4+ChmcZof83tP8xNrcAdpdMxdp9Exd51GB6G96t0B9oOt ZguJwhM2KFOinM4IMlKFZJttyLboNKt9yPz7wp/NQA/t2i0H3sEU0KHstPFoScNIcLAnvMdfRLJP gDvBlTq/wO8YwWTSPaDc2R7kEETtW1qu9vbQ48nrVCHpYbe/WQOQLVFv4iHmjBTwMVyfe4o0kOhI KPUNTmmUIBHXKynWvEZ8fvNBUHgrPvsW7tg798CzxGd7fZvZI2/E6vU6Dt+GbX792aMPh1VTH+0a gbxpHqkC/KeYmKCpxCWWYveRyaUnPpOAcWoyrbIMvw7v8FPYB4I06jdXlwT1DWLEleVzT2vG1Jrh be6tl5eQJSp89Qp3DjKoVZVTJ0SKr1HTxh5zUTIZ8kP3cOUPF5c3hBkXiafoRO4vxlzFp8+8xGhC H7lUHE2Uq6BLtPCdkCESE5R7F5dh5itKfcUnfGrmq8zUV7xeONebwpC+1r7KrL3IqSLuxA+V7Oef 0chP+zqeDKmXie7V8MyKy2NnHaUlvWV3rYaNNK+9npazuKIHbEJJwR0vsoLJwH+Ys3g3/KL1yJKJ zGVvLJmb/B+xvLJxH+lLKA7bouI+oU5iVj3eye6ddTKe1iSp/1t3rf93bKeR0P8b9/H/34P+b5fS /1ua/bfTQPwo/rUEvGW78Bpz85yV8Qil4KtFKA3KRihtQ+idR+PNEjzeLI/IW+8sRKnr33U2biEa RKLSbqfW4++w2xQR6b+L2MX4Y7Db8JKbSZi3eQtecvN2vOTbDG4+S7pwyhfcmSXeAbyBlgWh80ar 0VUH6fP5xD1nJ29ffnh9iIdE5SnAc547GfJD0pKrqtJG/0PsdxEGQqdCrhTTrxEYX/gb+xNXa7xz Cvwaj4LJ0JtcA/aNOAtE1kyra4cYttsHJrDbRg6YaVT3yTdbLpqA0Hodsog3VdLeShxnFaJ74Cjy /N0pnGJOn79/f+mdr6oI9xFMR4C7kdb+BGYmCpgBikZQb0IcN8lfwHDH7l/PYCGl6onOppIOYek0 slX8OUQvnX48fgFOhI+vXyJQ4YXwU/zB3j17SZ9T6sG4II/T1J3D4Lz771N9dIB3Tg4Nof+aNL2c pr05RDIDd2Zm4M7idIoSiVMejcZKo9FYARqNHh4Y/zCBltNUMfSFKDJ2exQZK4UiM0uhyMxNUWTl YKXlwWkCTIoitRieZm4PTzN3AE/LbIKfVLeHx8Uq5/VAxye3LYdSOVmNSIKM7wOxZpZBrClGydQS rADTxjbBtLFCTBs5Vlt8UTfBswrxVc2EDzsvqcY/4vHEwg8oLMHe/NxnRRgB6eyX5R/Df2MZnZPN btnq5rn4gvHiBuw8577584T/zsUqezn4y/DNs5NDkcRCLyLUFCrzl8PB++O3b1KKna2XQ/hUQ8M5 zCZdisuUIFAj+9axEhl3jpUqvjEtuCSMBTEi5OVflh398WzCHgPqA6caP4kh+xL/K001vyPy9csl 33yBhGWynvKJhhhX/j+hJMJlREICftJfCX/AknHVisvONQaX4/biCj/JuaaNmqlKZbZOGbpOkPkR e4R5fvYeSnmPb6Lav8cF3rX/t3H3+d+cTsL+07Lv/b93b/95vxaWHYc12vvNDv9fgf3H2beb+46W /7Vt48GV/oTHpcXlzZJrGlz2N+0+iqNu70n7id1kfLursb0z98KbV0NFFnwGvA55a+k4BJs6ndoS ROPvXv3v8cvDN6fHR8eHAzRznNxwrRZ/rkolP3biy68jSXn511PoQngVt3zMVZos8xYkKJbBoWih IKY/oR6VTUOILc4mnj9EzWAPhb02ejUGRZ+95PvO6fH7wxpTH4dHwEUbds0MmZqjZVKSvj5782zw 7M3rd89kCtSMimrkIhXE+wW/Plexx+6QeA6FIiUNSj0ail44FMQ2CSjw8yGY/wXnuaSRV7/i8/Ot ZrServCnSIrxRsrzSHifkYf9Y0+ewAzsPbFgQ/TOb2r4E2PRGGOgYnAdoGLoC85t4jzimyKaMvzg yyiYAP/KEyDjprOwSsUh2/kj0lCldCuEfbSF5ig+JBMG5+AfdzBQKTjOf5WA+9ynP817enlx6whR OsnbVs3CKEb44ChL6qYh+xokegO6WbMSMa+rw9sBfwuQVVG8kyGcz8pEbOP1glZiNLTz9YyCFRuS wpZQ35Mw84vCZIYBusXvjl4wOp+zSYeSUZi5vC3okebiZ9209SMnEl4losT/ffTSpP/vzvk/m82k /69lte/1v2/q/4todjn6X6u773RD/c9uEn8M/LVFJvDB9SEyxyliI7sGO0jgjl1+yqMcFhQl3xcs wc89vot4lOjljbsC4fKCOKQllKwug72Li9bY/6D5D5Y/35JqbEC+Qb6staBxQcWBNJ5wYqejrzeH IEHKZwCQHMh0AIdlb3XJNTle7GlVNnB8zm78NZdwn8HeOl7i3gjgOnbmrajJGlvwXXPJT9TeNXvk zvChXS4lmdhgh2fwNOAHG1yf8O8nAGuAgXMbkP7g3eDtCX7tNmrS3gtcUmsklYKsqqgqP3uOhRxR aDQeu3zvPQu4BANwvihELdnRQrP1aupphQbv6L11qZR8ZQEA6VS6mGevRSknWiqaVOb9oShlR0vR 6xfFjAr6DA/fvKpQWZowNcqIcAlb4ISeVB99qnT0skKVQN7ISufr6ZRN1nzcr7Wi795bDVG20VVl rQabnXl6P8B3Kcs5qtxKKWnJTkDLDdW2pbXd0FqXGVyEq/T5h8H7U4DKqDXiAvHY8Yzx7XQNauKZ JKHRbjX4ePL25SFUq4RrCyaK7AqfLdqVLnUkbcqICs+eV7TyDpVPmz2y/Ile3o6Uj0wkWX7wTisP cypjSsnyryPlnVrW5BLl+QyrFEiZaIWB9nqJcK0i0uqI17ue4zPwN6y/aaounbjUgKNNVMGLuuBT NT5BBsWzlDjjed2wTv50Takw0Hom6shHS+kZyV2Mjgf07nrqLYDmBuTXqcwrkpqUrwm5ExrMaHZl Lps/8aOaN3fZ64+n8HjDI3gw/g8ETUOeuiz7Cd8a8OCPLil+zhfQx7Ek8gll99T97PJ37UKxGttz 5wCZI2gmr9s0vblpsTEIVZAy8v4wYrr7Pxy6sMzRyyhEIHwn0XYajVg7WEhFP2ldqLHnJy8G7wch 4BltpXJMvPnV8fLDwq6E8kSMO7Tz7tX/ynF1nB6e+SCKUh35NkxomoqegU2B/8vCl2xKCCy8/mmE wKyC2nQO3IaVhNuEiysVbWPshFWYScyOwslRMKtD7wHmefp7CLZ8D9aG72BQ9h0EX+kdiPVz23cw 2PQd9ByKSlUBxXHig1zbgR6vKtwvmLwKjtYHqEn1LI1a6SxisuEiC601QAvJN9NfmNi+zUqKeUdo KqqC0laURhGvJDWdzCosRvLA6xyeHkundhkLkIDCtgGKZ1iNZkfxMpd2z4Xjp+ycoTFUZDyJS+Fc Y204IY7ixtmcsmLvDC2ztFuiBnPA7H6Krhe300ZqkB3ucjQ912qU7TjsCht2naqwEN/rDvmeJ1zO tJufpHU6UtIWJakoIbEg0QLmMbJDx7LWRvHtEE7MN+bx5ejClaJL/KbN2IcHe//Eh3i490/+Hvrx VfDwgIkCKLR4EfxLG6iWB00vrjTmaijoZEVNmw7z8MQfBrLuoLE7trSgXl/lsI6vOboqRpqlt9vM bLdR0DLhIlV39VnH32Bqs0cvs5uEaxFwpmWJxNBWJ3QspETgMy0domz0hwM9iZQCQ6QRMEezQ5ol kkhGNIwUMp/MOqGSIQEVJZERMgmjwOo5XRoYp6cNDAzBSiVjfchOMX8r3UbiLlW+wx/2on0L5Xo1 gi2JFZOSXG1jibvuvXj/mm9IrwE8dwj/+fAS9qpXR2GVLFMyq6Q1ePhCJIhtNSnZUstpa/kkU+kJ Fe6QArYkjaZoE5SH6BHbn09vNLGYOTQhkC5jWMQjKupamZ9WcPfHNYaQj6DDHwqxcJ1WK8TCAdB0 DsF/HkRmAZUdV7suYC9jq9FiKRwMEWjSm7enxy8OCZn0Ln4CptPepJ7gpoXAEnfGt+a92Xh47k3x QALRZTUmUGrq9yotEmHH4Q+Ftpo/2LPn8J8TXA3hRXU+l2xPWEwcqvthMAnmHqMk7WNByfczC1kW 6NbDqcdfY1XkTPvjD+FYIx/jQ3Z8dMRP0q9PPrw+PZazDY56gM8azW8grm0GwX01gH6I0zukC1a3 UQO69VjkDELGg1MeZdJRQEHhbROlxGwMf/tKr5UTpS1oqzsd3A/FOgBFim80iGzhUm+8d3j6ig/G 4Zsao4a4fJ55uGVX2c8/M7tdZf/Hn6p5ROtOPdJfoSVeoPUbglktQLHyn2RgzdZPSz6QEuJ3Y9m7 ueANdcrwscHprBbmybNBQ3e/hcWsWDGrKoGROslZaNOMsznD1ZhNq590omqpU0pD5+4RPhv6f+y7 x/802+0k/ufe//Ot/T+aZyfT/9Pab1j7raYW/9VCHYz+6Pxfd5EMi4nQ7pJWMmOLzFm4M21hKKPY OAzxpT9arqBNLErGdrF0bBvDEvFKIBq8g5GqZAArJoZg3zsxxK5pIYxdE1cYu+4h2zVxBds19YCM g+9iTHS325I8JvxGU/9LGAWPseWgMaQGl2fFlis6iGi0A1DLdZFaTt5vW8hP1h2aPZsiyJSTRF/2 GanjM81zMQmweXWK5RRnNUEEHii+74NIvoKqHu0GCesVJmYAp2jF1S7T/TopD7gRbbJxJ9l879lm c/S/5p3rf5bTbCX1P/te//um+l9Es8vT/7r7jU6o/1m23UWfsPxAJ3EtrFbD9u1FElXp6UpyogAp BjEWBxfBblI6q+RdAnmXYJO7BKl3GYi7GLvIxmWkZOOKNBzkNhzEGg5SG5Y9Lo8eJulutUi6W60w Fjc/PX12xzPfRG03zyvh41GYs3juVKNBlt/mP8V4kJD/zt3zf7faKfE/zXv5/63lfyjZc+S/1d5v WZr8By2QwtfhgxVL3fP+Kybc2DDmNDw6R2VAwvYKkoPQDT/spSjDD0kZrqKynKGPc8VbE6hCXbba 4YnjK8s+c3PZp84vAH6BExKYLSR6QNKyBZqHa3BM4Avl0UqWGRwLx1tI2i7ZwoXL2hAfZOqRAit2 VdFj5eSJLe1PxPwZUFwgUJCqjN58StYkxeLVIs5T/reVafMKrncyc4uiNAQY6PicHb59B9G9ACvx CRyNfCAufx83/NlXj5ZsxH/6whaj8ZW7qrP3LsT4rmRmrJJzXo5B26FDLhfzgjIIvZb56wFLAKeF N1+74rv0/yAmxp+5XDLwB8ZTdo3Smq18kakVhQbmb5UpUcpOl8L5soEDmjzQ0peMOGUgfIURpxGc +hKNBWW/+/2/dff2/0Za/O89/9u33v+1nT1z/+9CKduJ2v/b387+b2SQzX0Noz4xpdHjdns1S7d9 ZZnpCxwSv29FF1fAs2akkWJtz7Nm3I5nTaFuDJmwO0qEgZzZwAUhj+PwOZMxW7AvCSv5fLli0VKQ fgXSyvB9T+BlLKHOWN1oWPYeAKMk7ybEIiNCVSfjBLCZADzKFJt8LyL0Pcp7Cn3GkPXRxcibS6m/ LTbL3DE2K+Luz0m1lrJjbgfI6nTIuN7RxroEIsLcGSIi9sSlHnfHMAii/+naOBDdnh1LYEPI6tSI VHlcQmZtruZwle2UojIG10wQ3LsEzkkfsUbmODVyhqNMwrd7C/q/rf2nfefxv/z/SfyH1bnX/76p /hfR7PL5f1t2Kv6j/S3wH3es/1lWyxH4eyB2k5uc6OHyCq3j7DHRaeKVqzM6tw/Rho4kkMKOw4sO l38PkfVTfjLnj85/jhNzmlJpwdYoCbHOJAtbx3N3BcCK6Xp8RUf/AFi86GyvBeyk36iq4OjhNcHF ohdOIx4VD4lRNvSk2B0InGajJTtz4Ty/XlJINR7h6R3WtSCZ7CdnyQIiPpGyo2QRdmKPViNvWlOR FWrEQ6rOo8HbE0XWaW45ACmPEPOaM4hzSnG/RxiALVvA/O22xA3EEoQHsQThLPpYAHwl6PBqzX7i ymur0WBPgXt1+PzD0fD9r2yfqesGaxKboWZnFDyRgcYTaSaHRCbATh0rUVc2nIAbSBaQ8MHgqdJC TS2Ha0lNC+3KVs3W7crm7QARmPKiNCDCzAdEmNJ6mbeGIw3gj6lrXk1svTz9mC4jEn3JmmZbTm0T kc6RGaJ3La0GJVxh34vl35QM0YW2fDPfdmlUkj5j9pioh8N2++I47/ULvaZGgt94kMZvnEJYrCWl j00AQ5Ihp3PmiiP41/c+SInW6vUoVCVMynFX5myztDnbKFUSjAPJZSw8H8umDVh19TqS7QhlIEfq NIS5ot2yCE4BFnYrzBKiodB4tak7v1hd6kFDohQAMfk0xoCOqGTli2w6AtYAXIFRqg603MemI686 9yl9iShRsEAKGpEeHo2tNzmYokQklOfl4fMPv6grFQzpOX40Y0uggZ8kYnhkQWV1qpDRXnzIE+aJ IsUCz6hoLgHNt2He2rchK0tDmyCqKKzMduUYYRs4Rsj603DI+tOwVUo6NNalqlsUiHh1NlysV6TX piywGsxRmO1VjaY5WkSpJGalUtloX8/SeKUsxxuaZobiJt86apqLwF/5Y2Rq5295CJa/IeJJ4clk 0nsaJKtV46csPkqWpcXv6Yv77AZSJBgH8tllgHwkLi82BuJMIIyIqccRky6VOY+o+Ego/UO07e2V fTP+Asto8lL2kM1XU+sjv0f1++i1LGU/YzLRWFUqecoURYD9gwYq45XIYcPyBZJzE4nD0GWN9EgT AJDHnI60gzKpesDjSJoIoYJAsXs72L39T9h3OneP/3KcpP2vee///bb2v4hlr8D+p+X/siyH0DDw txNDf2XmRk89BaYdl3ZxCBRuQGm3A26fTpwUpRwxK4Wy7yo9O2VoRRGPIVIHwPD1mL36VZKnau5B uS8EIqFrjHhV92Wy0IcJm4sqh53BIPGQ5mXinq0vqvHgedS4KXb+BF2cS3fqYnAXJiqliK6a5BH4 c7fevaYUHzLDx5gIGfFKIr9HCr1qTauc7qIWZ2bFHjv0gk/L0Wc3ZJGt0bNVySSZT7xNxzbhpqXH CJXer+gcppnYE7m0+Om4Vw5grVxxybQkavqQkQLGZz2XI8RLAut0+iAZec2KmYgjEst2onyCiqAE LHQUENSOBgQVm4GiUgJ8ncvvwW70H7T/d+/c/9exrRT8V+t+//8O9v9Wqf2/p/n/+DEWAFH8j+Rr gQMhCr+ZP/f4ksTli2KG7BNiDRLWAFk+8CNJeF55QEYN3GnQGpKsoGVckjbXRHKn5OYnds/h8nPy miRdo4v0FEeB+2ntzlfTGzrTYgG+KV657oKIg0eTv43GvAQescajMZf7Lhfe45V4VOiY3HIrCTwT fRDAMqdNODo7iqNDOacDisr5UaN7W7k6QiiSqI+ODmg+sGkkhW9O6Ujjq2ss6oOxp1RvEAYGc6e4 PIwyxu2C2zfF9qEyKCWbIBd2BxxMBrA/RsY+lnfJXyzlGGk/9e/W5W1G3V8lHd5mXnbd07LZdVdf LbvuadnsuuiSAsNL2lQsjRrYMkExJnnpoa7T7qr0oKg2wP1DniaUUQfsoZZKoy9LTvyh549XmJZv 5nn0RV3V5xr4Y1OmmynC1dWC4gXDLyDZktcf6gXErb4ACdTEv6ALmOtzeHp8cvj2w2mf0sC6yOIu ORuG1Jk9zZjJt3kQWj2uycpIEaBDRslNmR+IETdThUTZ7a2yk+kZicR8gkMsKnIwaUZaaclKAWMQ 2zSyMgI2SP6LhGUNXdG1+fM6YLy1G06t2cvySRfLuvzTsdCLaR9Euz4oxhNviSTVwTVkjsGftBQs UCe5JHihoahHoL8c5djc7bnWIxGQnS9S0tHBUE2AWiJ6oqz9yGvLAyU9DrD51+tlDpRCeP1OUijl bMsAU4mayZ8X++zHWiQ4FWVNsXsWRZNo+0fqNG9oTz+YV/V2/+r9VtfzWsqq/HlYtG+nyb6t8vp2 WtQ3SLQZbSinM1Xh+SfpP3BhhdbZL4G/FGz0CrF+0LKU01ZobbfDrubG6eTDV3kXXooVEs1MNIbE RTmpicwCaG5BHpnEo4MdwA2AGncR8CWGrIPekkwi62AE0iiaEkmjo0/GZO8izbZ5izTbTOTZjk+5 VkPDKNwyi3dKwEK5jN0YTmCUFaaYgIvE6TlA5ch5GhecRA6ZLy0xbmNHIXxgiMnzwkbhGtsyDrAU xgHa0lqCSBGIcTpWIlFtDl0Ay8sjZqbkETOSv4Fbm/d3fsFnWsTHLGawh3mEfaEvUjaGf5V0ZCwv 05icuhucqOLTbgOb9QazNdVebITpXZM7udqbpVoSXPOR5gtt7gY3SXxGaTNuJZqbT/smTvAxYnj9 qzjGy6WV0IPkhITjjR9cERsuP9BDoh+ZemVfVV+lrEwSXLq0kG0SGS8dSDU2XhYmHYKcu6mMvUzI w0qRfrqRqTdlqpVRUXcp5DKmldQUc+dXCU3RuI2mCDdH6NHmeqJRSk80bqEnGlvriUYpPdHYRE80 4noiAgor5R0zhesxe72lL7aNFsLWVG9GBsE2cuIFrF4Xq71eZ0+fUoYdjQ/O6qCDtNluh4Q6xW8m TFKReBNCCCAKZOIr/1OsLIDRAoQkffz4sS87lmhSQUyEBI1oGAhO4v00mJVHntTPa1dCVyS+XJWB Vn9TnHJoSbCcFj9h22XdyEK3ewE6HeQq59Pjhl36YKtd0dKoo6Iwl7DQra1GG0rDDLBwTOJF4f2r GLzfqGhqXWzsAJuvXx+O/cVNdqEYk4WcP+ggBWSSdiEyEbGXpaaqgh5HXzH2AEKPdQCzwHmC+Xs9 zwrgwArkCa0RIFJrgi9sdx6GcZy+VbguKAnv5gqfC8Bt+p3pOi3aSCkQHNGSaifW76uFPxCiNArD bvTVb+HiowwxsEDdiWyT0rLRdJ37K3G1Docovp7FGW9Bx6nFiAsrmq6jpT8XU6MShXinrl0D165R sHITbWWuV8P6TUp8kcIKtOsp5Hxb6VDjcPLKqvqUMa1cmdMvWzWrmzjrSeNhd+pcJsh7m9Aw7Vaj Zje0cHPTVKl0f2INSZmTrfMAW/96fInaKRutwkNMjaAWSuGh2XfQuMbNO6HyaIQ8Yvrz1fhDqm6p ANhZmqfVT72eRA+8+vWJLaHYMdNv3LybGZTekJelOs0L6bktjIpaylQCBDmpFFKXVksYyr0LXEjt yXzIDcBX1epySXzDqFXQ6aUWXNdgwJaqYvTQEUfhqCLasSN2EOkn2kEq2z3leZHh8MjLLDWKpTdb TNGb8jTSFe20I7LSUEBHmNpEpNISsNC9MCK908OJ2euo6LLtw8GN1KvRV4taDohXEK2U4z34JKHQ 9/Hk3w3+o3f3+M9Oy0niP+/xH98D/qNXBv/RbOjx3z3CLfRi/D9wEgMP2nBFe5DwB+6h/guSADfZ x3qye+WnX/B9173gUhj+W+1vRrAWc6/rJsfMGpFzwXBYqk4MJRAWwO2Wd/6C/4IfyyEYlDM4o7ga HY+L1U98bD7h7s7Gs0myN0WYBcy02KFMi10VnZeOiNQSpl35V1UNOqkx3KTbe6NDGVq0M0xkOkk7 hkI7nRh9yo5N0luYn9OeafNm2De3YpNW4DRwoLuOpdRV4fh+qGwhwgNuqAy4WYiHuAZdYhmJc/XC I/sNb2MKh+mHe1kR3FV1zq6SeSfHuJg0Sk0Xun05bXZm25MidUs6njYWK5vxmhZYXXP2f3mm8fz5 7veYIv4/vu+L/d/uOHYH9v9m457/907+2XUHDj/8ZMmPvMF6bnL5tALbw7OlmMA1dkxwxw8v3/EJ 7/uTB96c8WM3ZC3hh5KZO/ODG2JfC0YeLLsz/5rtXbnB3J2yt29P2JU3nbqTB0vIhsJP6Mr/L04l xywYzRncuFpn70b8yqT+4IFdb9dbTLRyyVcr3sKfuqaMXF5OR2f8R5SCgOnxlsu1u3zgU1vS51Tj K3D+aKUejh4XwAcv/NkC7g/y9oy/3gf07Jj3EDrgPHn8AM7UogLh9nkDfMzqdgsvPeCKc1Yh3v0H D4TW1ECt+gEFNCymI76+Y+Hy4GkSSxeLwYuBjuwzOFHRZd6matFKtjgbXXDhgi9iBFlisI47X8+W qpYd1uJ3Yo9IID3CH869a75BjTA7/NifQUoaVa8Z1oNiCx+3H7Zcn8FLJ0jV2fpClXfC8mhjmfgg AnVoXfVJdiixIeCAWJ9PNpC5cctLtSbinPnU8eajCZ9aK8Lm7gVulVwDWJ+ckE8w5rGuOtgKOwjq qD9Z8wGMnoD5HdaQg3HFp6kbwPBeuUBBMF+6qpl22MwRn8Rj31s+ghFyyYMIeWvE+kB9lw+CeGMz n0/ojDBQfmOwAuKiG81vePXwhp3whr+Mgr97V3C3fXyZsOmgduBr7jxVsRtWfDaZyEhxOJzzbcwL 8DmtJzZkJxJ4iEdRo5M3D3UOmjAn8AzU0Bgo/dB8ouEMUcdZffF5m2C15FtWwH/mS3K5L0Yh1fdT xQWpO3doIrxxv6isUunG+uo+onvAvC8N/jTV8XnCntX1Xs75O5r40KcsZ1T1Qbofiv8e7WXSLUQ9 f3aGswbCc5MlUEFgX0bL0AaM0KHRGmuIOazcs1VQqUijgHrna66dgbOgjgUHNLF0RFXebOppy1RT Rqq4qs5Id6Hg7TGqMvwikQ0s5Wyj20Z1mSrsJSP2aOLz4wiUe0SeDE2eWCkCESKepgI3LN+zEGJr /DWsrQk/NI155zcEwMd5OILUnHgRliybcOWIv35+iWTQDRf567nH1+dMCTQuu2CCTyAxLrTx4N4g df/v/t/9v3/3f/8PaxEx9gBoAQA= --Boundary-00=_uDbcA5rEVIjmlkt-- From mashirle@us.ibm.com Mon Apr 5 13:51:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 13:51:58 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35KpkKO023443 for ; Mon, 5 Apr 2004 13:51:54 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i35KpD67457010; Mon, 5 Apr 2004 16:51:16 -0400 Received: from DYN318388BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35KpWrU086518; Mon, 5 Apr 2004 16:51:33 -0400 From: Shirley Ma To: "David S. Miller" Subject: Re: [PATCH]dump interface IPv6 multicast/anycast addresses through netlink Date: Mon, 5 Apr 2004 13:51:09 -0700 User-Agent: KMail/1.5 Cc: xma@us.ibm.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@cerberus.hongo.wide.ad.jp References: <200404011028.13048.mashirle@us.ibm.com> <20040403144540.7f201bc1.davem@redhat.com> In-Reply-To: <20040403144540.7f201bc1.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_9accA6m7DJZzaxc" Message-Id: <200404051351.09740.mashirle@us.ibm.com> X-archive-position: 4479 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8004 Lines: 268 --Boundary-00=_9accA6m7DJZzaxc Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Dumping multicast/anycast api was removed in Linux 2.6.5 kernel, so it couldn't be applied cleanly. I recreated the patch. This patch has been tested against linux-2.6.5 kernel. --Boundary-00=_9accA6m7DJZzaxc Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.5-ipv6mib.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.5-ipv6mib.patch" diff -urN linux-2.6.5/include/linux/rtnetlink.h linux-2.6.5-ipv6mib/include/linux/rtnetlink.h --- linux-2.6.5/include/linux/rtnetlink.h 2004-04-03 19:37:42.000000000 -0800 +++ linux-2.6.5-ipv6mib/include/linux/rtnetlink.h 2004-04-05 13:13:27.000000000 -0700 @@ -47,7 +47,11 @@ #define RTM_NEWPREFIX (RTM_BASE+36) #define RTM_GETPREFIX (RTM_BASE+38) -#define RTM_MAX (RTM_BASE+39) +#define RTM_GETMULTICAST (RTM_BASE+42) + +#define RTM_GETANYCAST (RTM_BASE+46) + +#define RTM_MAX (RTM_BASE+47) /* Generic structure for encapsulation of optional route information. @@ -340,7 +344,8 @@ IFA_LABEL, IFA_BROADCAST, IFA_ANYCAST, - IFA_CACHEINFO + IFA_CACHEINFO, + IFA_MULTICAST }; #define IFA_MAX IFA_CACHEINFO diff -urN linux-2.6.5/net/ipv6/addrconf.c linux-2.6.5-ipv6mib/net/ipv6/addrconf.c --- linux-2.6.5/net/ipv6/addrconf.c 2004-04-03 19:38:17.000000000 -0800 +++ linux-2.6.5-ipv6mib/net/ipv6/addrconf.c 2004-04-05 13:20:34.194635432 -0700 @@ -2553,7 +2553,89 @@ return -1; } -static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +static int inet6_fill_ifmcaddr(struct sk_buff *skb, struct ifmcaddr6 *ifmca, + u32 pid, u32 seq, int event) +{ + struct ifaddrmsg *ifm; + struct nlmsghdr *nlh; + struct ifa_cacheinfo ci; + unsigned char *b = skb->tail; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); + if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + ifm = NLMSG_DATA(nlh); + ifm->ifa_family = AF_INET6; + ifm->ifa_prefixlen = 128; + ifm->ifa_flags = IFA_F_PERMANENT; + ifm->ifa_scope = RT_SCOPE_UNIVERSE; + if (ipv6_addr_scope(&ifmca->mca_addr)&IFA_SITE) + ifm->ifa_scope = RT_SCOPE_SITE; + ifm->ifa_index = ifmca->idev->dev->ifindex; + RTA_PUT(skb, IFA_MULTICAST, 16, &ifmca->mca_addr); + ci.cstamp = (__u32)(TIME_DELTA(ifmca->mca_cstamp, INITIAL_JIFFIES) / HZ + * 100 + TIME_DELTA(ifmca->mca_cstamp, INITIAL_JIFFIES) % HZ + * 100 / HZ); + ci.tstamp = (__u32)(TIME_DELTA(ifmca->mca_tstamp, INITIAL_JIFFIES) / HZ + * 100 + TIME_DELTA(ifmca->mca_tstamp, INITIAL_JIFFIES) % HZ + * 100 / HZ); + ci.ifa_prefered = INFINITY_LIFE_TIME; + ci.ifa_valid = INFINITY_LIFE_TIME; + RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +static int inet6_fill_ifacaddr(struct sk_buff *skb, struct ifacaddr6 *ifaca, + u32 pid, u32 seq, int event) +{ + struct ifaddrmsg *ifm; + struct nlmsghdr *nlh; + struct ifa_cacheinfo ci; + unsigned char *b = skb->tail; + + nlh = NLMSG_PUT(skb, pid, seq, event, sizeof(*ifm)); + if (pid) nlh->nlmsg_flags |= NLM_F_MULTI; + ifm = NLMSG_DATA(nlh); + ifm->ifa_family = AF_INET6; + ifm->ifa_prefixlen = 128; + ifm->ifa_flags = IFA_F_PERMANENT; + ifm->ifa_scope = RT_SCOPE_UNIVERSE; + if (ipv6_addr_scope(&ifaca->aca_addr)&IFA_SITE) + ifm->ifa_scope = RT_SCOPE_SITE; + ifm->ifa_index = ifaca->aca_idev->dev->ifindex; + RTA_PUT(skb, IFA_ANYCAST, 16, &ifaca->aca_addr); + ci.cstamp = (__u32)(TIME_DELTA(ifaca->aca_cstamp, INITIAL_JIFFIES) / HZ + * 100 + TIME_DELTA(ifaca->aca_cstamp, INITIAL_JIFFIES) % HZ + * 100 / HZ); + ci.tstamp = (__u32)(TIME_DELTA(ifaca->aca_tstamp, INITIAL_JIFFIES) / HZ + * 100 + TIME_DELTA(ifaca->aca_tstamp, INITIAL_JIFFIES) % HZ + * 100 / HZ); + ci.ifa_prefered = INFINITY_LIFE_TIME; + ci.ifa_valid = INFINITY_LIFE_TIME; + RTA_PUT(skb, IFA_CACHEINFO, sizeof(ci), &ci); + nlh->nlmsg_len = skb->tail - b; + return skb->len; + +nlmsg_failure: +rtattr_failure: + skb_trim(skb, b - skb->data); + return -1; +} + +enum addr_type_t +{ + UNICAST_ADDR, + MULTICAST_ADDR, + ANYCAST_ADDR, +}; + +static int inet6_dump_addr(struct sk_buff *skb, struct netlink_callback *cb, + enum addr_type_t type) { int idx, ip_idx; int s_idx, s_ip_idx; @@ -2561,7 +2643,9 @@ struct net_device *dev; struct inet6_dev *idev = NULL; struct inet6_ifaddr *ifa; - + struct ifmcaddr6 *ifmca; + struct ifacaddr6 *ifaca; + s_idx = cb->args[0]; s_ip_idx = ip_idx = cb->args[1]; read_lock(&dev_base_lock); @@ -2575,28 +2659,58 @@ if ((idev = in6_dev_get(dev)) == NULL) continue; read_lock_bh(&idev->lock); - /* unicast address */ - for (ifa = idev->addr_list; ifa; - ifa = ifa->if_next, ip_idx++) { - if (ip_idx < s_ip_idx) - continue; - if ((err = inet6_fill_ifaddr(skb, ifa, - NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) - goto done; - } - /* temp addr */ + switch (type) { + case UNICAST_ADDR: + /* unicast address */ + for (ifa = idev->addr_list; ifa; + ifa = ifa->if_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifaddr(skb, ifa, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + goto done; + } + /* temp addr */ #ifdef CONFIG_IPV6_PRIVACY - for (ifa = idev->tempaddr_list; ifa; - ifa = ifa->tmp_next, ip_idx++) { - if (ip_idx < s_ip_idx) - continue; - if ((err = inet6_fill_ifaddr(skb, ifa, - NETLINK_CB(cb->skb).pid, - cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) - goto done; - } + for (ifa = idev->tempaddr_list; ifa; + ifa = ifa->tmp_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifaddr(skb, ifa, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_NEWADDR)) <= 0) + goto done; + } #endif + break; + case MULTICAST_ADDR: + /* multicast address */ + for (ifmca = idev->mc_list; ifmca; + ifmca = ifmca->next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifmcaddr(skb, ifmca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_GETMULTICAST)) <= 0) + goto done; + } + break; + case ANYCAST_ADDR: + /* anycast address */ + for (ifaca = idev->ac_list; ifaca; + ifaca = ifaca->aca_next, ip_idx++) { + if (ip_idx < s_ip_idx) + continue; + if ((err = inet6_fill_ifacaddr(skb, ifaca, + NETLINK_CB(cb->skb).pid, + cb->nlh->nlmsg_seq, RTM_GETANYCAST)) <= 0) + goto done; + } + break; + default: + break; + } read_unlock_bh(&idev->lock); in6_dev_put(idev); } @@ -2611,6 +2725,25 @@ return skb->len; } +static int inet6_dump_ifaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = UNICAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + +static int inet6_dump_ifmcaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = MULTICAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + + +static int inet6_dump_ifacaddr(struct sk_buff *skb, struct netlink_callback *cb) +{ + enum addr_type_t type = ANYCAST_ADDR; + return inet6_dump_addr(skb, cb, type); +} + static void inet6_ifa_notify(int event, struct inet6_ifaddr *ifa) { struct sk_buff *skb; @@ -2835,6 +2968,8 @@ [RTM_NEWADDR - RTM_BASE] = { .doit = inet6_rtm_newaddr, }, [RTM_DELADDR - RTM_BASE] = { .doit = inet6_rtm_deladdr, }, [RTM_GETADDR - RTM_BASE] = { .dumpit = inet6_dump_ifaddr, }, + [RTM_GETMULTICAST - RTM_BASE] = { .dumpit = inet6_dump_ifmcaddr, }, + [RTM_GETANYCAST - RTM_BASE] = { .dumpit = inet6_dump_ifacaddr, }, [RTM_NEWROUTE - RTM_BASE] = { .doit = inet6_rtm_newroute, }, [RTM_DELROUTE - RTM_BASE] = { .doit = inet6_rtm_delroute, }, [RTM_GETROUTE - RTM_BASE] = { .doit = inet6_rtm_getroute, --Boundary-00=_9accA6m7DJZzaxc-- From brazilnut@us.ibm.com Mon Apr 5 14:26:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:27:02 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LQlKO024864 for ; Mon, 5 Apr 2004 14:26:47 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i35LQdih563458; Mon, 5 Apr 2004 17:26:39 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35LQbKe330746; Mon, 5 Apr 2004 15:26:38 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i35LQWc10992; Mon, 5 Apr 2004 14:26:32 -0700 From: Don Fry Message-Id: <200404052126.i35LQWc10992@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.5 2/4] pcnet32 all printk under netif_msg To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 5 Apr 2004 14:26:32 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4482 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 14393 Lines: 439 Please apply the following patch to 2.6.5. All printk's are now done under netif_msg debug level tests. --- linux-2.6.5/drivers/net/add.pcnet32.c Mon Apr 5 11:40:57 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Mon Apr 5 13:37:56 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.28" -#define DRV_RELDATE "02.20.2004" +#define DRV_VERSION "1.29" +#define DRV_RELDATE "04.06.2004" #define PFX DRV_NAME ": " static const char *version = @@ -484,11 +484,11 @@ #ifdef CONFIG_NET_POLL_CONTROLLER static void pcnet32_poll_controller(struct net_device *dev) -{ +{ disable_irq(dev->irq); pcnet32_interrupt(0, dev, NULL); enable_irq(dev->irq); -} +} #endif @@ -611,7 +611,7 @@ test->flags |= ETH_TEST_FL_FAILED; } else if (netif_msg_hw(lp)) printk(KERN_DEBUG "%s: Loopback test passed.\n", dev->name); - } else + } else if (netif_msg_hw(lp)) printk(KERN_DEBUG "%s: No tests to run (specify 'Offline' on ethtool).", dev->name); } /* end pcnet32_ethtool_test */ @@ -793,23 +793,27 @@ err = pci_enable_device(pdev); if (err < 0) { - printk(KERN_ERR PFX "failed to enable device -- err=%d\n", err); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "failed to enable device -- err=%d\n", err); return err; } pci_set_master(pdev); ioaddr = pci_resource_start (pdev, 0); if (!ioaddr) { - printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); return -ENODEV; } if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) { - printk(KERN_ERR PFX "architecture does not support 32bit PCI busmaster DMA\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "architecture does not support 32bit PCI busmaster DMA\n"); return -ENODEV; } if (request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_pci") == NULL) { - printk(KERN_ERR PFX "io address range already allocated\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "io address range already allocated\n"); return -EBUSY; } @@ -847,14 +851,15 @@ if (pcnet32_dwio_read_csr(ioaddr, 0) == 4 && pcnet32_dwio_check(ioaddr)) { a = &pcnet32_dwio; } else - goto err_release_region; + goto err_release_region; } chip_version = a->read_csr(ioaddr, 88) | (a->read_csr(ioaddr,89) << 16); - if (pcnet32_debug & NETIF_MSG_PROBE) + if ((pcnet32_debug & NETIF_MSG_PROBE) && (pcnet32_debug & NETIF_MSG_HW)) printk(KERN_INFO " PCnet chip version is %#x.\n", chip_version); if ((chip_version & 0xfff) != 0x003) { - printk(KERN_INFO PFX "Unsupported chip version.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "Unsupported chip version.\n"); goto err_release_region; } @@ -914,8 +919,9 @@ fdx = 1; mii = 1; break; default: - printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", - chip_version); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", + chip_version); goto err_release_region; } @@ -935,13 +941,15 @@ dev = alloc_etherdev(0); if (!dev) { - printk(KERN_ERR PFX "Memory allocation failed.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "Memory allocation failed.\n"); ret = -ENOMEM; goto err_release_region; } SET_NETDEV_DEV(dev, &pdev->dev); - printk(KERN_INFO PFX "%s at %#3lx,", chipname, ioaddr); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "%s at %#3lx,", chipname, ioaddr); /* In most chips, after a chip reset, the ethernet address is read from the * station address PROM at the base address and programmed into the @@ -970,8 +978,10 @@ if (!is_valid_ether_addr(dev->dev_addr) && is_valid_ether_addr(promaddr)) { #endif - printk(" warning: CSR address invalid,\n"); - printk(KERN_INFO " using instead PROM address of"); + if (pcnet32_debug & NETIF_MSG_PROBE) { + printk(" warning: CSR address invalid,\n"); + printk(KERN_INFO " using instead PROM address of"); + } memcpy(dev->dev_addr, promaddr, 6); } } @@ -980,36 +990,40 @@ if (!is_valid_ether_addr(dev->dev_addr)) memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); - for (i = 0; i < 6; i++) - printk(" %2.2x", dev->dev_addr[i] ); - - if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 - 0x2624 */ - i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ - printk("\n" KERN_INFO " tx_start_pt(0x%04x):",i); - switch(i>>10) { - case 0: printk(" 20 bytes,"); break; - case 1: printk(" 64 bytes,"); break; - case 2: printk(" 128 bytes,"); break; - case 3: printk("~220 bytes,"); break; + if (pcnet32_debug & NETIF_MSG_PROBE) { + for (i = 0; i < 6; i++) + printk(" %2.2x", dev->dev_addr[i] ); + + /* Version 0x2623 and 0x2624 */ + if (((chip_version + 1) & 0xfffe) == 0x2624) { + i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ + printk("\n" KERN_INFO " tx_start_pt(0x%04x):",i); + switch(i>>10) { + case 0: printk(" 20 bytes,"); break; + case 1: printk(" 64 bytes,"); break; + case 2: printk(" 128 bytes,"); break; + case 3: printk("~220 bytes,"); break; + } + i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */ + printk(" BCR18(%x):",i&0xffff); + if (i & (1<<5)) printk("BurstWrEn "); + if (i & (1<<6)) printk("BurstRdEn "); + if (i & (1<<7)) printk("DWordIO "); + if (i & (1<<11)) printk("NoUFlow "); + i = a->read_bcr(ioaddr, 25); + printk("\n" KERN_INFO " SRAMSIZE=0x%04x,",i<<8); + i = a->read_bcr(ioaddr, 26); + printk(" SRAM_BND=0x%04x,",i<<8); + i = a->read_bcr(ioaddr, 27); + if (i & (1<<14)) printk("LowLatRx"); } - i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */ - printk(" BCR18(%x):",i&0xffff); - if (i & (1<<5)) printk("BurstWrEn "); - if (i & (1<<6)) printk("BurstRdEn "); - if (i & (1<<7)) printk("DWordIO "); - if (i & (1<<11)) printk("NoUFlow "); - i = a->read_bcr(ioaddr, 25); - printk("\n" KERN_INFO " SRAMSIZE=0x%04x,",i<<8); - i = a->read_bcr(ioaddr, 26); - printk(" SRAM_BND=0x%04x,",i<<8); - i = a->read_bcr(ioaddr, 27); - if (i & (1<<14)) printk("LowLatRx"); } dev->base_addr = ioaddr; /* pci_alloc_consistent returns page-aligned memory, so we do not have to check the alignment */ if ((lp = pci_alloc_consistent(pdev, sizeof(*lp), &lp_dma_addr)) == NULL) { - printk(KERN_ERR PFX "Consistent memory allocation failed.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "Consistent memory allocation failed.\n"); ret = -ENOMEM; goto err_free_netdev; } @@ -1045,7 +1059,8 @@ lp->options |= PCNET32_PORT_FD; if (!a) { - printk(KERN_ERR PFX "No access methods\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "No access methods\n"); ret = -ENODEV; goto err_free_consistent; } @@ -1079,9 +1094,10 @@ dev->irq = irq_line; } - if (dev->irq >= 2) - printk(" assigned IRQ %d.\n", dev->irq); - else { + if (dev->irq >= 2) { + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(" assigned IRQ %d.\n", dev->irq); + } else { unsigned long irq_mask = probe_irq_on(); /* @@ -1095,11 +1111,13 @@ dev->irq = probe_irq_off (irq_mask); if (!dev->irq) { - printk(", failed to detect IRQ line.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(", failed to detect IRQ line.\n"); ret = -ENODEV; goto err_free_consistent; } - printk(", probed IRQ %d.\n", dev->irq); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(", probed IRQ %d.\n", dev->irq); } /* Set the mii phy_id so that we can query the link state */ @@ -1123,7 +1141,7 @@ #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller = pcnet32_poll_controller; -#endif +#endif /* Fill in the generic fields of the device structure. */ if (register_netdev(dev)) @@ -1136,7 +1154,8 @@ pcnet32_dev = dev; } - printk(KERN_INFO "%s: registered as %s\n",dev->name, lp->name); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; return 0; @@ -1265,7 +1284,7 @@ /* If we have mii, print the link status and start the watchdog */ if (lp->mii) { - mii_check_media (&lp->mii_if, 1, 1); + mii_check_media (&lp->mii_if, netif_msg_link(lp), 1); mod_timer (&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT); } @@ -1358,8 +1377,9 @@ if (rx_skbuff == NULL) { if (!(rx_skbuff = lp->rx_skbuff[i] = dev_alloc_skb (PKT_BUF_SZ))) { /* there is not much, we can do at this point */ - printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n", - dev->name); + if (pcnet32_debug & NETIF_MSG_DRV) + printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n", + dev->name); return -1; } skb_reserve (rx_skbuff, 2); @@ -1421,8 +1441,9 @@ spin_lock_irqsave(&lp->lock, flags); /* Transmitter timeout, serious problems. */ - printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", - dev->name, lp->a.read_csr(ioaddr, 0)); + if (pcnet32_debug & NETIF_MSG_DRV) + printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", + dev->name, lp->a.read_csr(ioaddr, 0)); lp->a.write_csr (ioaddr, 0, 0x0004); lp->stats.tx_errors++; if (netif_msg_tx_err(lp)) { @@ -1530,7 +1551,8 @@ int must_restart; if (!dev) { - printk (KERN_DEBUG "%s(): irq %d for unknown device\n", + if (pcnet32_debug & NETIF_MSG_INTR) + printk (KERN_DEBUG "%s(): irq %d for unknown device\n", __FUNCTION__, irq); return IRQ_NONE; } @@ -1582,8 +1604,9 @@ lp->stats.tx_fifo_errors++; /* Ackk! On FIFO errors the Tx unit is turned off! */ /* Remove this verbosity later! */ - printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", - dev->name, csr0); + if (netif_msg_tx_err(lp)) + printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", + dev->name, csr0); must_restart = 1; } #else @@ -1592,8 +1615,9 @@ if (! lp->dxsuflo) { /* If controller doesn't recover ... */ /* Ackk! On FIFO errors the Tx unit is turned off! */ /* Remove this verbosity later! */ - printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", - dev->name, csr0); + if (netif_msg_tx_err(lp)) + printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", + dev->name, csr0); must_restart = 1; } } @@ -1617,8 +1641,9 @@ delta = (lp->cur_tx - dirty_tx) & (TX_RING_MOD_MASK + TX_RING_SIZE); if (delta >= TX_RING_SIZE) { - printk(KERN_ERR "%s: out-of-sync dirty pointer, %d vs. %d, full=%d.\n", - dev->name, dirty_tx, lp->cur_tx, lp->tx_full); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: out-of-sync dirty pointer, %d vs. %d, full=%d.\n", + dev->name, dirty_tx, lp->cur_tx, lp->tx_full); dirty_tx += TX_RING_SIZE; delta -= TX_RING_SIZE; } @@ -1650,8 +1675,9 @@ lp->stats.rx_errors++; /* Missed a Rx frame. */ } if (csr0 & 0x0800) { - printk(KERN_ERR "%s: Bus master arbitration failure, status %4.4x.\n", - dev->name, csr0); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Bus master arbitration failure, status %4.4x.\n", + dev->name, csr0); /* unlike for the lance, there is no restart needed */ } @@ -1668,7 +1694,7 @@ if (netif_msg_intr(lp)) printk(KERN_DEBUG "%s: exiting interrupt, csr0=%#4.4x.\n", - dev->name, lp->a.read_csr (ioaddr, 0)); + dev->name, lp->a.read_csr (ioaddr, 0)); spin_unlock(&lp->lock); @@ -1705,7 +1731,8 @@ struct sk_buff *skb; if (pkt_len < 60) { - printk(KERN_ERR "%s: Runt packet!\n",dev->name); + if (netif_msg_rx_err(lp)) + printk(KERN_ERR "%s: Runt packet!\n", dev->name); lp->stats.rx_errors++; } else { int rx_in_place = 0; @@ -1734,8 +1761,9 @@ if (skb == NULL) { int i; - printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", - dev->name); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", + dev->name); for (i = 0; i < RX_RING_SIZE; i++) if ((short)le16_to_cpu(lp->rx_ring[(entry+i) & RX_RING_MOD_MASK].status) < 0) @@ -1904,7 +1932,8 @@ spin_lock_irqsave(&lp->lock, flags); if (dev->flags&IFF_PROMISC) { /* Log any net taps. */ - printk(KERN_INFO "%s: Promiscuous mode enabled.\n", dev->name); + if (netif_msg_hw(lp)) + printk(KERN_INFO "%s: Promiscuous mode enabled.\n", dev->name); lp->init_block.mode = le16_to_cpu(0x8000 | (lp->options & PCNET32_PORT_PORTSEL) << 7); } else { lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); @@ -1979,7 +2008,7 @@ /* Print the link status if it has changed */ if (lp->mii) { spin_lock_irqsave(&lp->lock, flags); - mii_check_media (&lp->mii_if, 1, 0); + mii_check_media (&lp->mii_if, netif_msg_link(lp), 0); spin_unlock_irqrestore(&lp->lock, flags); } @@ -2027,6 +2056,8 @@ MODULE_DESCRIPTION("Driver for PCnet32 and PCnetPCI based ethercards"); MODULE_LICENSE("GPL"); +#define PCNET32_MSG_DEFAULT (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) + /* An additional parameter that may be passed in... */ static int debug = -1; static int tx_start_pt = -1; @@ -2036,8 +2067,7 @@ { printk(KERN_INFO "%s", version); - if (debug >= 0 && debug < (sizeof(int) - 1)) - pcnet32_debug = 1 << debug; + pcnet32_debug = netif_msg_init(debug, PCNET32_MSG_DEFAULT); if ((tx_start_pt >= 0) && (tx_start_pt <= 3)) tx_start = tx_start_pt; @@ -2050,7 +2080,7 @@ if (pcnet32vlb) pcnet32_probe_vlbus(); - if (cards_found) + if (cards_found && (pcnet32_debug & NETIF_MSG_PROBE)) printk(KERN_INFO PFX "%d cards_found.\n", cards_found); return (pcnet32_have_pci + cards_found) ? 0 : -ENODEV; @@ -2079,7 +2109,6 @@ /* * Local variables: - * compile-command: "gcc -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototypes -O6 -m486 -c pcnet32.c" * c-indent-level: 4 * tab-width: 8 * End: -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Mon Apr 5 14:25:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:25:14 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LPBKO024540 for ; Mon, 5 Apr 2004 14:25:12 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i35LP2Fe471494; Mon, 5 Apr 2004 17:25:02 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35LPMrU109268; Mon, 5 Apr 2004 17:25:22 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i35LOrD10981; Mon, 5 Apr 2004 14:24:53 -0700 From: Don Fry Message-Id: <200404052124.i35LOrD10981@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.5 1/4] pcnet32.c add support for 79C976 To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 5 Apr 2004 14:24:53 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4480 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 531 Lines: 20 Please include this patch to add support for the 79C976 device to the pcnet32 driver. --- linux-2.6.5/drivers/net/orig.pcnet32.c Sat Apr 3 19:36:53 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Mon Apr 5 11:40:57 2004 @@ -909,6 +909,10 @@ chipname = "PCnet/FAST III 79C975"; /* PCI */ fdx = 1; mii = 1; break; + case 0x2628: + chipname = "PCnet/FAST III 79C976"; + fdx = 1; mii = 1; + break; default: printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", chip_version); -- Don Fry brazilnut@us.ibm.com From dipankar@in.ibm.com Mon Apr 5 14:25:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:25:16 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LP3KO024528 for ; Mon, 5 Apr 2004 14:25:04 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i35LO90o238280; Mon, 5 Apr 2004 17:24:09 -0400 Received: from soprano.in.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35LNsKe325000; Mon, 5 Apr 2004 15:24:06 -0600 Received: by soprano.in.ibm.com (Postfix, from userid 500) id B463A7C52A; Tue, 6 Apr 2004 02:52:20 +0530 (IST) Date: Tue, 6 Apr 2004 02:52:20 +0530 From: Dipankar Sarma To: Robert Olsson Cc: Andrea Arcangeli , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs Message-ID: <20040405212220.GH4003@in.ibm.com> Reply-To: dipankar@in.ibm.com References: <200403302005.AAA00466@yakov.inr.ac.ru> <20040330211450.GI3808@dualathlon.random> <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> <16497.37720.607342.193544@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16497.37720.607342.193544@robur.slu.se> User-Agent: Mutt/1.4.1i X-archive-position: 4481 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dipankar@in.ibm.com Precedence: bulk X-list: netdev Content-Length: 8494 Lines: 247 On Mon, Apr 05, 2004 at 07:11:52PM +0200, Robert Olsson wrote: > > Dipankar Sarma writes: > > > Robert, btw, this rcu-softirq patch is slightly different > > from the earlier one in the sense that now every softirq > > handler completion is a quiescent point. Earlier each iteration > > of softirqs was a quiescent point. So this has more quiescent > > points. > > Hello! > > Yes it seems reduce RCU latency in our setup as well. It does not eliminate > overflows but reduces with ~50% and increases the throughput a bit. dst cache > overflow depends on RCU-delay + gc_min_interval and the number of entries > freed per sec so this means RCU has improved. Also the user app doing gettimeofday > seems to be better scheduled. The worst starvation improved from ~7.5 to ~4.4 sec. Looks better atleast. Can you apply the following patch (rs-throttle-rcu) on top of rcu-softirq.patch in your tree and see if helps a little bit more ? Please make sure to set the kernel paramenters rcupdate.maxbatch to 4 and rcupdate.plugticks to 0. You can make sure of those parameters by looking at dmesg (rcu prints them out during boot). I just merged it, but have not tested this patch yet. Thanks Dipankar Throttle rcu by forcing a limit on how many callbacks per softirq and also implement a configurable plug. Applies on top of the rcu-softirq (hence rs-) patch. include/linux/list.h | 21 +++++++++++++++++++++ include/linux/rcupdate.h | 7 ++++++- kernel/rcupdate.c | 33 +++++++++++++++++++++++++-------- kernel/sched.c | 2 ++ 4 files changed, 54 insertions(+), 9 deletions(-) diff -puN include/linux/list.h~rs-throttle-rcu include/linux/list.h --- linux-2.6.4-rcu/include/linux/list.h~rs-throttle-rcu 2004-04-06 02:05:13.000000000 +0530 +++ linux-2.6.4-rcu-dipankar/include/linux/list.h 2004-04-06 02:05:13.000000000 +0530 @@ -251,6 +251,27 @@ static inline void list_splice(struct li __list_splice(list, head); } +static inline void __list_splice_tail(struct list_head *list, + struct list_head *head) +{ + struct list_head *first = list->next; + struct list_head *last = list->prev; + struct list_head *at = head->prev; + + first->prev = at; + at->next = first; + head->prev = last; + last->next = head; +} + + +static inline void list_splice_tail(struct list_head *list, + struct list_head *head) +{ + if (!list_empty(list)) + __list_splice_tail(list, head); +} + /** * list_splice_init - join two lists and reinitialise the emptied list. * @list: the new list to add. diff -puN include/linux/rcupdate.h~rs-throttle-rcu include/linux/rcupdate.h --- linux-2.6.4-rcu/include/linux/rcupdate.h~rs-throttle-rcu 2004-04-06 02:05:13.000000000 +0530 +++ linux-2.6.4-rcu-dipankar/include/linux/rcupdate.h 2004-04-06 02:27:29.000000000 +0530 @@ -96,10 +96,12 @@ struct rcu_data { long batch; /* Batch # for current RCU batch */ struct list_head nxtlist; struct list_head curlist; + struct list_head donelist; }; DECLARE_PER_CPU(struct rcu_data, rcu_data); DECLARE_PER_CPU(struct rcu_data, rcu_bh_data); +DECLARE_PER_CPU(int, rcu_plugticks); extern struct rcu_ctrlblk rcu_ctrlblk; extern struct rcu_ctrlblk rcu_bh_ctrlblk; @@ -107,6 +109,8 @@ extern struct rcu_ctrlblk rcu_bh_ctrlblk #define RCU_nxtlist(cpu) (per_cpu(rcu_data, (cpu)).nxtlist) #define RCU_bh_qsctr(cpu) (per_cpu(rcu_bh_data, (cpu)).qsctr) #define RCU_bh_nxtlist(cpu) (per_cpu(rcu_bh_data, (cpu)).nxtlist) + +#define RCU_plugticks(cpu) (per_cpu(rcu_plugticks, (cpu))) #define RCU_QSCTR_INVALID 0 @@ -117,7 +121,8 @@ static inline int __rcu_pending(int cpu, rcu_batch_before(rdp->batch, rcp->curbatch)) || (list_empty(&rdp->curlist) && !list_empty(&rdp->nxtlist)) || - cpu_isset(cpu, rcp->rcu_cpu_mask)) + cpu_isset(cpu, rcp->rcu_cpu_mask) || + (!list_empty(&rdp->donelist) && RCU_plugticks(cpu) == 0)) return 1; else return 0; diff -puN kernel/rcupdate.c~rs-throttle-rcu kernel/rcupdate.c --- linux-2.6.4-rcu/kernel/rcupdate.c~rs-throttle-rcu 2004-04-06 02:05:13.000000000 +0530 +++ linux-2.6.4-rcu-dipankar/kernel/rcupdate.c 2004-04-06 02:47:10.000000000 +0530 @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -59,6 +60,10 @@ DEFINE_PER_CPU(struct rcu_data, rcu_bh_d /* Fake initialization required by compiler */ static DEFINE_PER_CPU(struct tasklet_struct, rcu_tasklet) = {NULL}; #define RCU_tasklet(cpu) (per_cpu(rcu_tasklet, cpu)) +DEFINE_PER_CPU(int, rcu_plugticks) = 0; + +static int maxbatch = 1000000; +static int plugticks = 4; /** * call_rcu - Queue an RCU update request. @@ -112,16 +117,23 @@ void call_rcu_bh(struct rcu_head *head, * Invoke the completed RCU callbacks. They are expected to be in * a per-cpu list. */ -static void rcu_do_batch(struct list_head *list) +static void rcu_do_batch(int cpu, struct list_head *list) { struct list_head *entry; struct rcu_head *head; + int count = 0; while (!list_empty(list)) { entry = list->next; list_del(entry); head = list_entry(entry, struct rcu_head, list); head->func(head->arg); + if (++count >= maxbatch) { + RCU_plugticks(cpu) = plugticks; + if (!RCU_plugticks(cpu)) + tasklet_hi_schedule(&RCU_tasklet(cpu)); + break; + } } } @@ -178,7 +190,7 @@ out_unlock: spin_unlock(&rcp->mutex); } -static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp, +static void __rcu_process_callbacks(int cpu, struct rcu_ctrlblk *rcp, struct rcu_data *rdp) { LIST_HEAD(list); @@ -186,6 +198,7 @@ static void __rcu_process_callbacks(stru if (!list_empty(&rdp->curlist) && rcu_batch_after(rcp->curbatch, rdp->batch)) { list_splice(&rdp->curlist, &list); + list_splice_tail(&rdp->curlist, &rdp->donelist); INIT_LIST_HEAD(&rdp->curlist); } @@ -206,13 +219,13 @@ static void __rcu_process_callbacks(stru local_irq_enable(); } rcu_check_quiescent_state(rcp, rdp); - if (!list_empty(&list)) - rcu_do_batch(&list); + if (!list_empty(&rdp->donelist) && !RCU_plugticks(cpu)) + rcu_do_batch(cpu, &rdp->donelist); } void rcu_process_callbacks_bh(int cpu) { - __rcu_process_callbacks(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu)); + __rcu_process_callbacks(cpu, &rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu)); } /* @@ -221,8 +234,8 @@ void rcu_process_callbacks_bh(int cpu) static void rcu_process_callbacks(unsigned long unused) { int cpu = smp_processor_id(); - __rcu_process_callbacks(&rcu_ctrlblk, &per_cpu(rcu_data, cpu)); - __rcu_process_callbacks(&rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu)); + __rcu_process_callbacks(cpu, &rcu_ctrlblk, &per_cpu(rcu_data, cpu)); + __rcu_process_callbacks(cpu, &rcu_bh_ctrlblk, &per_cpu(rcu_bh_data, cpu)); } void rcu_check_callbacks(int cpu, int user) @@ -234,7 +247,7 @@ void rcu_check_callbacks(int cpu, int us RCU_bh_qsctr(cpu)++; } else if (!in_softirq()) RCU_bh_qsctr(cpu)++; - tasklet_schedule(&RCU_tasklet(cpu)); + tasklet_hi_schedule(&RCU_tasklet(cpu)); } static void __devinit rcu_online_cpu(struct rcu_data *rdp) @@ -242,6 +255,7 @@ static void __devinit rcu_online_cpu(str memset(rdp, 0, sizeof(*rdp)); INIT_LIST_HEAD(&rdp->nxtlist); INIT_LIST_HEAD(&rdp->curlist); + INIT_LIST_HEAD(&rdp->donelist); } static int __devinit rcu_cpu_notify(struct notifier_block *self, @@ -277,6 +291,7 @@ void __init rcu_init(void) (void *)(long)smp_processor_id()); /* Register notifier for non-boot CPUs */ register_cpu_notifier(&rcu_nb); + printk("RCU: maxbatch = %d, plugticks = %d\n", maxbatch, plugticks); } @@ -302,6 +317,8 @@ void synchronize_kernel(void) wait_for_completion(&completion); } +module_param(maxbatch, int, 0); +module_param(plugticks, int, 0); EXPORT_SYMBOL(call_rcu); EXPORT_SYMBOL(call_rcu_bh); diff -puN kernel/sched.c~rs-throttle-rcu kernel/sched.c --- linux-2.6.4-rcu/kernel/sched.c~rs-throttle-rcu 2004-04-06 02:05:13.000000000 +0530 +++ linux-2.6.4-rcu-dipankar/kernel/sched.c 2004-04-06 02:05:13.000000000 +0530 @@ -1486,6 +1486,8 @@ void scheduler_tick(int user_ticks, int if (rcu_pending(cpu)) rcu_check_callbacks(cpu, user_ticks); + if (RCU_plugticks(cpu)) + RCU_plugticks(cpu)--; /* note: this timer irq context must be accounted for as well */ if (hardirq_count() - HARDIRQ_OFFSET) { _ From brazilnut@us.ibm.com Mon Apr 5 14:28:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:28:17 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LSDKO025531 for ; Mon, 5 Apr 2004 14:28:13 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i35LS6ih700038; Mon, 5 Apr 2004 17:28:06 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35LS4ZA076454; Mon, 5 Apr 2004 15:28:05 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i35LRxW11003; Mon, 5 Apr 2004 14:27:59 -0700 From: Don Fry Message-Id: <200404052127.i35LRxW11003@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.5 3/4] pcnet32 correct name display To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 5 Apr 2004 14:27:59 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4483 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 522 Lines: 18 This displays the device name (eth%d) instead of the device type when registering the interrupt handler. --- linux-2.6.5/drivers/net/print.pcnet32.c Mon Apr 5 11:48:47 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Mon Apr 5 11:48:56 2004 @@ -1180,7 +1180,7 @@ if (dev->irq == 0 || request_irq(dev->irq, &pcnet32_interrupt, - lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) { + lp->shared_irq ? SA_SHIRQ : 0, dev->name, (void *)dev)) { return -EAGAIN; } -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Mon Apr 5 14:29:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:29:27 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LTOKO025877 for ; Mon, 5 Apr 2004 14:29:24 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i35LTHFe416386; Mon, 5 Apr 2004 17:29:17 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i35LTbrU103564; Mon, 5 Apr 2004 17:29:38 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i35LTBY11014; Mon, 5 Apr 2004 14:29:11 -0700 From: Don Fry Message-Id: <200404052129.i35LTBY11014@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.5 4/4] pcnet32 add led blink capability To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Mon, 5 Apr 2004 14:29:11 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4484 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3825 Lines: 125 Please apply this patch to 2.6.5 to include the capability of blinking the LED's for device identification. Ethtool -p support. --- linux-2.6.5/drivers/net/mac.pcnet32.c Mon Apr 5 13:37:22 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Mon Apr 5 13:37:44 2004 @@ -102,6 +102,7 @@ #define PCNET32_DMA_MASK 0xffffffff #define PCNET32_WATCHDOG_TIMEOUT (jiffies + (2 * HZ)) +#define PCNET32_BLINK_TIMEOUT (jiffies + (HZ/4)) /* * table to translate option values from tulip @@ -232,6 +233,8 @@ * length errors, and transmit hangs. Cleans up after errors in open. * Jim Lewis added ethernet loopback test. * Thomas Munck Steenholdt non-mii ioctl corrections. + * v1.29 6 Apr 2004 Jim Lewis added physical + * identification code (blink led's). */ @@ -342,6 +345,7 @@ struct net_device *next; struct mii_if_info mii_if; struct timer_list watchdog_timer; + struct timer_list blink_timer; u32 msg_enable; /* debug message level */ }; @@ -365,6 +369,8 @@ static void pcnet32_ethtool_test(struct net_device *dev, struct ethtool_test *eth_test, u64 *data); static int pcnet32_loopback_test(struct net_device *dev, uint64_t *data1); +static int pcnet32_phys_id(struct net_device *dev, u32 data); +static void pcnet32_led_blink_callback(struct net_device *dev); enum pci_flags_bit { PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4, @@ -746,6 +752,63 @@ return(rc); } /* end pcnet32_loopback_test */ +static void pcnet32_led_blink_callback(struct net_device *dev) +{ + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + unsigned long flags; + int i; + + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + a->write_bcr(ioaddr, i, a->read_bcr(ioaddr, i) ^ 0x4000); + } + spin_unlock_irqrestore(&lp->lock, flags); + + mod_timer(&lp->blink_timer, PCNET32_BLINK_TIMEOUT); +} + +static int pcnet32_phys_id(struct net_device *dev, u32 data) +{ + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + unsigned long flags; + int i, regs[4]; + + if (!lp->blink_timer.function) { + init_timer(&lp->blink_timer); + lp->blink_timer.function = (void *) pcnet32_led_blink_callback; + lp->blink_timer.data = (unsigned long) dev; + } + + /* Save the current value of the bcrs */ + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + regs[i-4] = a->read_bcr(ioaddr, i); + } + spin_unlock_irqrestore(&lp->lock, flags); + + mod_timer(&lp->blink_timer, jiffies); + set_current_state(TASK_INTERRUPTIBLE); + + if ((!data) || (data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))) + data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ); + + schedule_timeout(data * HZ); + del_timer_sync(&lp->blink_timer); + + /* Restore the original value of the bcrs */ + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + a->write_bcr(ioaddr, i, regs[i-4]); + } + spin_unlock_irqrestore(&lp->lock, flags); + + return 0; +} + static struct ethtool_ops pcnet32_ethtool_ops = { .get_settings = pcnet32_get_settings, .set_settings = pcnet32_set_settings, @@ -761,6 +824,7 @@ .get_strings = pcnet32_get_strings, .self_test_count = pcnet32_self_test_count, .self_test = pcnet32_ethtool_test, + .phys_id = pcnet32_phys_id, }; /* only probes for non-PCI devices, the rest are handled by @@ -1152,6 +1216,9 @@ if (pcnet32_debug & NETIF_MSG_PROBE) printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; + + a->write_bcr(ioaddr, 2, 0x1002); /* enable LED writes */ + return 0; err_free_consistent: -- Don Fry brazilnut@us.ibm.com From davem@redhat.com Mon Apr 5 14:43:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:43:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LhoKO026447 for ; Mon, 5 Apr 2004 14:43:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i35Lhi5D002158; Mon, 5 Apr 2004 17:43:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i35Lhij07492; Mon, 5 Apr 2004 17:43:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i35Lh51n007308; Mon, 5 Apr 2004 17:43:20 -0400 Date: Mon, 5 Apr 2004 14:42:13 -0700 From: "David S. Miller" To: Shirley Ma Cc: xma@us.ibm.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@cerberus.hongo.wide.ad.jp Subject: Re: [PATCH]dump interface IPv6 multicast/anycast addresses through netlink Message-Id: <20040405144213.198f76ea.davem@redhat.com> In-Reply-To: <200404051351.09740.mashirle@us.ibm.com> References: <200404011028.13048.mashirle@us.ibm.com> <20040403144540.7f201bc1.davem@redhat.com> <200404051351.09740.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4485 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 280 Lines: 8 On Mon, 5 Apr 2004 13:51:09 -0700 Shirley Ma wrote: > Dumping multicast/anycast api was removed in Linux 2.6.5 kernel, so it > couldn't be applied cleanly. > I recreated the patch. This patch has been tested against linux-2.6.5 kernel. Applied, thank you. From romieu@fr.zoreil.com Mon Apr 5 14:57:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:57:30 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LvPKO027044 for ; Mon, 5 Apr 2004 14:57:26 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Ltjgf023435; Mon, 5 Apr 2004 23:55:45 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35LtjfR023434; Mon, 5 Apr 2004 23:55:45 +0200 Date: Mon, 5 Apr 2004 23:55:45 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 0/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235545.A20805@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 4487 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 935 Lines: 34 No ack for previous patches. Try #2. The following serie of patches applies against 2.6.5 + bk-netdev (as found in 2.6.5-mm1 for instance). It contains: - r8169-dma-api-resync.patch resync with the recent DMA api changes (pci_dma_sync_single_for_{cpu/device}) - r8169-ethtool-introduction.patch lightweight ethtool support - r8169-missing-static.patch missing 'static' qualifiers - r8169-barrier.patch safety rmb() - r8169-kill-potential-busy-loop.patch A similar patch exists in -mm. I like mine better. - r8169-dac-00.patch DMA_{32/64}_BIT_MASK thing against include/linux/dma-mapping.h - r8169-dac-10.patch DAC changes for (as of now even more) happy owners of x86-64. It seems to work. An update of the patch against 2.6.5 is available for testers at: http://www.fr.zoreil.com/people/francois/misc/20040405-2.6.5-r8169.c-stable.patch The link loss issue when cable is unplugged is on the TODO. -- Ueimor From romieu@fr.zoreil.com Mon Apr 5 14:57:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 14:57:29 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35LvPKO027045 for ; Mon, 5 Apr 2004 14:57:26 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Lumgf023441; Mon, 5 Apr 2004 23:56:48 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35LumoV023440; Mon, 5 Apr 2004 23:56:48 +0200 Date: Mon, 5 Apr 2004 23:56:48 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 1/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235648.A23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235545.A20805@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:55:45PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4486 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1370 Lines: 42 DMA api resync. drivers/net/r8169.c | 17 ++++++++++------- 1 files changed, 10 insertions(+), 7 deletions(-) diff -puN drivers/net/r8169.c~r8169-dma-api-resync drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-dma-api-resync 2004-04-05 23:05:27.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:05:27.000000000 +0200 @@ -1429,19 +1429,22 @@ rtl8169_rx_interrupt(struct net_device * struct RxDesc *desc = tp->RxDescArray + entry; struct sk_buff *skb = tp->Rx_skbuff[entry]; int pkt_size = (status & 0x00001FFF) - 4; + void (*pci_action)(struct pci_dev *, dma_addr_t, + size_t, int) = pci_dma_sync_single_for_device; - pci_dma_sync_single(tp->pci_dev, - le32_to_cpu(desc->buf_addr), - RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + + pci_dma_sync_single_for_cpu(tp->pci_dev, + le32_to_cpu(desc->buf_addr), RX_BUF_SIZE, + PCI_DMA_FROMDEVICE); if (rtl8169_try_rx_copy(&skb, pkt_size, desc, dev)) { - pci_unmap_single(tp->pci_dev, - le32_to_cpu(desc->buf_addr), - RX_BUF_SIZE, - PCI_DMA_FROMDEVICE); + pci_action = pci_unmap_single; tp->Rx_skbuff[entry] = NULL; } + pci_action(tp->pci_dev, le32_to_cpu(desc->buf_addr), + RX_BUF_SIZE, PCI_DMA_FROMDEVICE); + skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); netif_rx(skb); _ From romieu@fr.zoreil.com Mon Apr 5 15:01:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:34 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1RKO027763 for ; Mon, 5 Apr 2004 15:01:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Lxxgf023508; Mon, 5 Apr 2004 23:59:59 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35LxxOW023507; Mon, 5 Apr 2004 23:59:59 +0200 Date: Mon, 5 Apr 2004 23:59:59 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 6/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235959.F23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> <20040405235726.B23436@electric-eye.fr.zoreil.com> <20040405235802.C23436@electric-eye.fr.zoreil.com> <20040405235844.D23436@electric-eye.fr.zoreil.com> <20040405235929.E23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235929.E23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:59:29PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4491 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 598 Lines: 22 DMA_{32/64}BIT_MASK for all. include/linux/dma-mapping.h | 3 +++ 1 files changed, 3 insertions(+) diff -puN include/linux/dma-mapping.h~r8169-dac-00 include/linux/dma-mapping.h --- linux-2.6.5/include/linux/dma-mapping.h~r8169-dac-00 2004-04-05 23:06:28.000000000 +0200 +++ linux-2.6.5-fr/include/linux/dma-mapping.h 2004-04-05 23:06:28.000000000 +0200 @@ -10,6 +10,9 @@ enum dma_data_direction { DMA_NONE = 3, }; +#define DMA_64BIT_MASK 0xffffffffffffffffULL +#define DMA_32BIT_MASK 0x00000000ffffffffULL + #include /* Backwards compat, remove in 2.7.x */ _ From romieu@fr.zoreil.com Mon Apr 5 15:01:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:34 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1RKO027764 for ; Mon, 5 Apr 2004 15:01:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35M0qgf023534; Tue, 6 Apr 2004 00:00:52 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35M0q36023533; Tue, 6 Apr 2004 00:00:52 +0200 Date: Tue, 6 Apr 2004 00:00:52 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 7/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040406000052.G23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> <20040405235726.B23436@electric-eye.fr.zoreil.com> <20040405235802.C23436@electric-eye.fr.zoreil.com> <20040405235844.D23436@electric-eye.fr.zoreil.com> <20040405235929.E23436@electric-eye.fr.zoreil.com> <20040405235959.F23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235959.F23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:59:59PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4492 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 5792 Lines: 194 DAC changes: - Rx and Tx descriptors rings handled on 64 bit; - enable DAC through use of CPlusCmd register (reserved bits apart, this is similar to the 8139cp driver); - use the higher 32 bits of addresses for the Rx/Tx buffers. linux/dma-mapping.h | 0 drivers/net/r8169.c | 66 ++++++++++++++++++++++++++++++++++++---------------- 2 files changed, 46 insertions(+), 20 deletions(-) diff -puN drivers/net/r8169.c~r8169-dac-10 drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-dac-10 2004-04-05 23:06:48.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:06:48.000000000 +0200 @@ -149,8 +149,10 @@ static int rx_copybreak = 200; enum RTL8169_registers { MAC0 = 0, /* Ethernet hardware address. */ MAR0 = 8, /* Multicast filter. */ - TxDescStartAddr = 0x20, - TxHDescStartAddr = 0x28, + TxDescStartAddrLow = 0x20, + TxDescStartAddrHigh = 0x24, + TxHDescStartAddrLow = 0x28, + TxHDescStartAddrHigh = 0x2c, FLASH = 0x30, ERSR = 0x36, ChipCmd = 0x37, @@ -175,7 +177,8 @@ enum RTL8169_registers { PHYstatus = 0x6C, RxMaxSize = 0xDA, CPlusCmd = 0xE0, - RxDescStartAddr = 0xE4, + RxDescAddrLow = 0xE4, + RxDescAddrHigh = 0xE8, EarlyTxThres = 0xEC, FuncEvent = 0xF0, FuncEventMask = 0xF4, @@ -227,7 +230,13 @@ enum RTL8169_register_content { /*TxConfigBits */ TxInterFrameGapShift = 24, - TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ + TxDMAShift = 8, /* DMA burst value (0-7) is shift this many bits */ + + /* CPlusCmd p.31 */ + RxVlan = (1 << 6), + RxChkSum = (1 << 5), + PCIDAC = (1 << 4), + PCIMulRW = (1 << 3), /*rtl8169_PHYstatus */ TBI_Enable = 0x80, @@ -286,15 +295,13 @@ enum _DescStatusBit { struct TxDesc { u32 status; u32 vlan_tag; - u32 buf_addr; - u32 buf_Haddr; + u64 addr; }; struct RxDesc { u32 status; u32 vlan_tag; - u32 buf_addr; - u32 buf_Haddr; + u64 addr; }; struct rtl8169_private { @@ -317,6 +324,7 @@ struct rtl8169_private { struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ struct timer_list timer; unsigned long phy_link_down_cnt; + u16 cp_cmd; }; MODULE_AUTHOR("Realtek"); @@ -713,6 +721,20 @@ rtl8169_init_board(struct pci_dev *pdev, goto err_out_disable; } + tp->cp_cmd = PCIMulRW | RxChkSum; + + if ((sizeof(dma_addr_t) > 32) && + !pci_set_dma_mask(pdev, DMA_64BIT_MASK)) + tp->cp_cmd |= PCIDAC; + else { + rc = pci_set_dma_mask(pdev, DMA_32BIT_MASK); + if (rc < 0) { + printk(KERN_ERR PFX "DMA configuration failed.\n"); + goto err_out_free_res; + } + } + + // enable PCI bus-mastering pci_set_master(pdev); @@ -1099,17 +1121,21 @@ rtl8169_hw_start(struct net_device *dev) RTL_W32(TxConfig, (TX_DMA_BURST << TxDMAShift) | (InterFrameGap << TxInterFrameGapShift)); - RTL_W16(CPlusCmd, RTL_R16(CPlusCmd)); + tp->cp_cmd |= RTL_R16(CPlusCmd); + RTL_W16(CPlusCmd, tp->cp_cmd); if (tp->mac_version == RTL_GIGA_MAC_VER_D) { dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0: bit-3 and bit-14 MUST be 1\n"); - RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | (1 << 14) | (1 << 3)); + tp->cp_cmd |= (1 << 14) | PCIMulRW; + RTL_W16(CPlusCmd, tp->cp_cmd); } tp->cur_rx = 0; - RTL_W32(TxDescStartAddr, tp->TxPhyAddr); - RTL_W32(RxDescStartAddr, tp->RxPhyAddr); + RTL_W32(TxDescStartAddrLow, ((u64) tp->TxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(TxDescStartAddrHigh, ((u64) tp->TxPhyAddr >> 32)); + RTL_W32(RxDescAddrLow, ((u64) tp->RxPhyAddr & DMA_32BIT_MASK)); + RTL_W32(RxDescAddrHigh, ((u64) tp->RxPhyAddr >> 32)); RTL_W8(Cfg9346, Cfg9346_Lock); udelay(10); @@ -1129,14 +1155,14 @@ rtl8169_hw_start(struct net_device *dev) static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { - desc->buf_addr = 0xdeadbeef; + desc->addr = 0x0badbadbadbadbad; desc->status &= ~cpu_to_le32(OWNbit | RsvdMask); } static void rtl8169_free_rx_skb(struct pci_dev *pdev, struct sk_buff **sk_buff, struct RxDesc *desc) { - pci_unmap_single(pdev, le32_to_cpu(desc->buf_addr), RX_BUF_SIZE, + pci_unmap_single(pdev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); dev_kfree_skb(*sk_buff); *sk_buff = NULL; @@ -1150,7 +1176,7 @@ static inline void rtl8169_return_to_asi static inline void rtl8169_give_to_asic(struct RxDesc *desc, dma_addr_t mapping) { - desc->buf_addr = cpu_to_le32(mapping); + desc->addr = cpu_to_le64(mapping); desc->status |= cpu_to_le32(OWNbit + RX_BUF_SIZE); } @@ -1248,9 +1274,9 @@ static void rtl8169_unmap_tx_skb(struct { u32 len = sk_buff[0]->len; - pci_unmap_single(pdev, le32_to_cpu(desc->buf_addr), + pci_unmap_single(pdev, le64_to_cpu(desc->addr), len < ETH_ZLEN ? ETH_ZLEN : len, PCI_DMA_TODEVICE); - desc->buf_addr = 0x00; + desc->addr = 0x00; *sk_buff = NULL; } @@ -1322,7 +1348,7 @@ rtl8169_start_xmit(struct sk_buff *skb, PCI_DMA_TODEVICE); tp->Tx_skbuff[entry] = skb; - tp->TxDescArray[entry].buf_addr = cpu_to_le32(mapping); + tp->TxDescArray[entry].addr = cpu_to_le64(mapping); tp->TxDescArray[entry].status = cpu_to_le32(OWNbit | FSbit | LSbit | len | (EORbit * !((entry + 1) % NUM_TX_DESC))); @@ -1454,7 +1480,7 @@ rtl8169_rx_interrupt(struct net_device * pci_dma_sync_single_for_cpu(tp->pci_dev, - le32_to_cpu(desc->buf_addr), RX_BUF_SIZE, + le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); if (rtl8169_try_rx_copy(&skb, pkt_size, desc, dev)) { @@ -1462,7 +1488,7 @@ rtl8169_rx_interrupt(struct net_device * tp->Rx_skbuff[entry] = NULL; } - pci_action(tp->pci_dev, le32_to_cpu(desc->buf_addr), + pci_action(tp->pci_dev, le64_to_cpu(desc->addr), RX_BUF_SIZE, PCI_DMA_FROMDEVICE); skb_put(skb, pkt_size); diff -puN include/linux/dma-mapping.h~r8169-dac-10 include/linux/dma-mapping.h _ From romieu@fr.zoreil.com Mon Apr 5 15:01:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:33 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1QKO027759 for ; Mon, 5 Apr 2004 15:01:27 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Lwigf023499; Mon, 5 Apr 2004 23:58:44 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35Lwiq5023498; Mon, 5 Apr 2004 23:58:44 +0200 Date: Mon, 5 Apr 2004 23:58:44 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 4/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235844.D23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> <20040405235726.B23436@electric-eye.fr.zoreil.com> <20040405235802.C23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235802.C23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:58:02PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4489 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 915 Lines: 32 Barrier against compiler optimization. drivers/net/r8169.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-barrier drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-barrier 2004-04-05 23:06:04.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:06:04.000000000 +0200 @@ -1367,6 +1367,7 @@ rtl8169_tx_interrupt(struct net_device * while (tx_left > 0) { int entry = dirty_tx % NUM_TX_DESC; + rmb(); if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { struct sk_buff *skb = tp->Tx_skbuff[entry]; @@ -1428,7 +1429,10 @@ rtl8169_rx_interrupt(struct net_device * while (rx_left > 0) { int entry = cur_rx % NUM_RX_DESC; - u32 status = le32_to_cpu(tp->RxDescArray[entry].status); + u32 status; + + rmb(); + status = le32_to_cpu(tp->RxDescArray[entry].status); if (status & OWNbit) break; _ From romieu@fr.zoreil.com Mon Apr 5 15:01:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:34 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1QKO027762 for ; Mon, 5 Apr 2004 15:01:27 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35LxTgf023503; Mon, 5 Apr 2004 23:59:29 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35LxT4X023502; Mon, 5 Apr 2004 23:59:29 +0200 Date: Mon, 5 Apr 2004 23:59:29 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 5/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235929.E23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> <20040405235726.B23436@electric-eye.fr.zoreil.com> <20040405235802.C23436@electric-eye.fr.zoreil.com> <20040405235844.D23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235844.D23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:58:44PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4490 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1765 Lines: 53 If a few packets have been scheduled for Tx, it is possible to keep looping in the Tx irq handler as soon as the irq for the first packet has been received until the descriptor of the last packet has been sent (with interrupts disabled btw). drivers/net/r8169.c | 28 +++++++++++++++------------- 1 files changed, 15 insertions(+), 13 deletions(-) diff -puN drivers/net/r8169.c~r8169-kill-potential-busy-loop drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-kill-potential-busy-loop 2004-04-05 23:06:15.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:06:15.000000000 +0200 @@ -1366,22 +1366,24 @@ rtl8169_tx_interrupt(struct net_device * while (tx_left > 0) { int entry = dirty_tx % NUM_TX_DESC; + struct sk_buff *skb = tp->Tx_skbuff[entry]; + u32 status; rmb(); - if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { - struct sk_buff *skb = tp->Tx_skbuff[entry]; + status = le32_to_cpu(tp->TxDescArray[entry].status); + if (status & OWNbit) + break; - /* FIXME: is it really accurate for TxErr ? */ - tp->stats.tx_bytes += skb->len >= ETH_ZLEN ? - skb->len : ETH_ZLEN; - tp->stats.tx_packets++; - rtl8169_unmap_tx_skb(tp->pci_dev, tp->Tx_skbuff + entry, - tp->TxDescArray + entry); - dev_kfree_skb_irq(skb); - tp->Tx_skbuff[entry] = NULL; - dirty_tx++; - tx_left--; - } + /* FIXME: is it really accurate for TxErr ? */ + tp->stats.tx_bytes += skb->len >= ETH_ZLEN ? + skb->len : ETH_ZLEN; + tp->stats.tx_packets++; + rtl8169_unmap_tx_skb(tp->pci_dev, tp->Tx_skbuff + entry, + tp->TxDescArray + entry); + dev_kfree_skb_irq(skb); + tp->Tx_skbuff[entry] = NULL; + dirty_tx++; + tx_left--; } if (tp->dirty_tx != dirty_tx) { _ From romieu@fr.zoreil.com Mon Apr 5 15:01:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:32 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1QKO027761 for ; Mon, 5 Apr 2004 15:01:27 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35Lw2gf023466; Mon, 5 Apr 2004 23:58:02 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35Lw24I023465; Mon, 5 Apr 2004 23:58:02 +0200 Date: Mon, 5 Apr 2004 23:58:02 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 3/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235802.C23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> <20040405235726.B23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235726.B23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:57:26PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4488 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1246 Lines: 42 Missing 'static' qualifier for functions. drivers/net/r8169.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff -puN drivers/net/r8169.c~r8169-missing-static drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-missing-static 2004-04-05 23:05:53.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:05:53.000000000 +0200 @@ -346,8 +346,7 @@ static const unsigned int rtl8169_rx_con #define PHY_Cap_100_Half_Or_Less PHY_Cap_100_Half | PHY_Cap_10_Full_Or_Less #define PHY_Cap_100_Full_Or_Less PHY_Cap_100_Full | PHY_Cap_100_Half_Or_Less -void -mdio_write(void *ioaddr, int RegAddr, int value) +static void mdio_write(void *ioaddr, int RegAddr, int value) { int i; @@ -364,8 +363,7 @@ mdio_write(void *ioaddr, int RegAddr, in } } -int -mdio_read(void *ioaddr, int RegAddr) +static int mdio_read(void *ioaddr, int RegAddr) { int i, value = -1; @@ -1642,8 +1640,7 @@ rtl8169_set_rx_mode(struct net_device *d * * Get TX/RX statistics for rtl8169 */ -struct net_device_stats * -rtl8169_get_stats(struct net_device *dev) +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev) { struct rtl8169_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; _ From romieu@fr.zoreil.com Mon Apr 5 15:01:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:01:36 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35M1QKO027760 for ; Mon, 5 Apr 2004 15:01:27 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i35LvRgf023462; Mon, 5 Apr 2004 23:57:27 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i35LvR0r023461; Mon, 5 Apr 2004 23:57:27 +0200 Date: Mon, 5 Apr 2004 23:57:26 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 2/7] 2.6.5-bk-netdev - r8169 queue Message-ID: <20040405235726.B23436@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040405235648.A23436@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235648.A23436@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:56:48PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4493 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1511 Lines: 50 ethtool driver info (Krishnakumar R. ). drivers/net/r8169.c | 16 ++++++++++++++++ 1 files changed, 16 insertions(+) diff -puN drivers/net/r8169.c~r8169-ethtool-introduction drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-ethtool-introduction 2004-04-05 23:05:42.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-05 23:05:42.000000000 +0200 @@ -40,6 +40,7 @@ VERSION 1.2 <2002/11/30> #include #include #include +#include #include #include @@ -382,6 +383,20 @@ mdio_read(void *ioaddr, int RegAddr) return value; } +static void rtl8169_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *info) +{ + struct rtl8169_private *tp = dev->priv; + + strcpy(info->driver, RTL8169_DRIVER_NAME); + strcpy(info->version, RTL8169_VERSION ); + strcpy(info->bus_info, pci_name(tp->pci_dev)); +} + +static struct ethtool_ops rtl8169_ethtool_ops = { + .get_drvinfo = rtl8169_get_drvinfo, +}; + static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, int bitval) { @@ -793,6 +808,7 @@ rtl8169_init_one(struct pci_dev *pdev, c dev->open = rtl8169_open; dev->hard_start_xmit = rtl8169_start_xmit; dev->get_stats = rtl8169_get_stats; + dev->ethtool_ops = &rtl8169_ethtool_ops; dev->stop = rtl8169_close; dev->tx_timeout = rtl8169_tx_timeout; dev->set_multicast_list = rtl8169_set_rx_mode; _ From davem@redhat.com Mon Apr 5 15:24:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 15:24:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35MOmKO030052 for ; Mon, 5 Apr 2004 15:24:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i35MOg5D017835; Mon, 5 Apr 2004 18:24:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i35MOgj29124; Mon, 5 Apr 2004 18:24:42 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i35MOH1n001914; Mon, 5 Apr 2004 18:24:18 -0400 Date: Mon, 5 Apr 2004 15:23:25 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com, benh@kernel.crashing.org Subject: Re: [PATCH] update networking config menu (v3) Message-Id: <20040405152325.658503fe.davem@redhat.com> In-Reply-To: <20040404200354.50e5dd74.rddunlap@osdl.org> References: <20040404200354.50e5dd74.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4494 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 41 Lines: 2 Looks good to me Randy, applied thanks. From rddunlap@osdl.org Mon Apr 5 16:00:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 16:00:49 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35N0jKO031509 for ; Mon, 5 Apr 2004 16:00:47 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i35N0d203151; Mon, 5 Apr 2004 16:00:39 -0700 Date: Mon, 5 Apr 2004 15:56:54 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik Subject: [PATCH] remove magic '31' for netdev priv. alignment Message-Id: <20040405155654.69a9bb4b.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4495 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1875 Lines: 60 [resend/rediff] // linux-2.6.5 // remove magic number of '31' from net_device and private alignment; diffstat:= drivers/net/net_init.c | 8 +++++--- include/linux/netdevice.h | 7 ++++++- 2 files changed, 11 insertions(+), 4 deletions(-) diff -Naurp ./drivers/net/net_init.c.orig ./drivers/net/net_init.c --- ./drivers/net/net_init.c.orig 2004-04-03 19:36:16.000000000 -0800 +++ ./drivers/net/net_init.c 2004-04-05 15:46:26.000000000 -0700 @@ -79,8 +79,9 @@ struct net_device *alloc_netdev(int size /* ensure 32-byte alignment of both the device and private area */ - alloc_size = (sizeof(struct net_device) + 31) & ~31; - alloc_size += sizeof_priv + 31; + alloc_size = (sizeof(struct net_device) + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST; + alloc_size += sizeof_priv + NETDEV_ALIGN_CONST; p = kmalloc (alloc_size, GFP_KERNEL); if (!p) { @@ -90,7 +91,8 @@ struct net_device *alloc_netdev(int size memset(p, 0, alloc_size); - dev = (struct net_device *)(((long)p + 31) & ~31); + dev = (struct net_device *)(((long)p + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST); dev->padded = (char *)dev - (char *)p; if (sizeof_priv) diff -Naurp ./include/linux/netdevice.h.orig ./include/linux/netdevice.h --- ./include/linux/netdevice.h.orig 2004-04-03 19:38:18.000000000 -0800 +++ ./include/linux/netdevice.h 2004-04-05 15:46:26.000000000 -0700 @@ -484,9 +484,14 @@ struct net_device int padded; }; +#define NETDEV_ALIGN 32 +#define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1) + static inline void *netdev_priv(struct net_device *dev) { - return (char *)dev + ((sizeof(struct net_device) + 31) & ~31); + return (char *)dev + ((sizeof(struct net_device) + + NETDEV_ALIGN_CONST) + & ~NETDEV_ALIGN_CONST); } #define SET_MODULE_OWNER(dev) do { } while (0) -- ~Randy "We have met the enemy and he is us." -- Pogo (by Walt Kelly) From rddunlap@osdl.org Mon Apr 5 16:36:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 16:36:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35NaUKO003011 for ; Mon, 5 Apr 2004 16:36:30 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i35NaP211122; Mon, 5 Apr 2004 16:36:25 -0700 Date: Mon, 5 Apr 2004 16:27:53 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik Subject: [janitor] dgrs: add missing iounmaps Message-Id: <20040405162753.7c0c5257.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4496 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1262 Lines: 53 [resend] Insert missing iounmap's. From: Leana Ogasawara --- linux-265-kj1-rddunlap/drivers/net/dgrs.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletion(-) diff -puN drivers/net/dgrs.c~dgrs_iounmap drivers/net/dgrs.c --- linux-265-kj1/drivers/net/dgrs.c~dgrs_iounmap 2004-04-05 13:08:11.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/dgrs.c 2004-04-05 13:08:11.000000000 -0700 @@ -327,8 +327,10 @@ check_board_dma(struct net_device *dev0) */ priv0->vplxdma[PLX_DMA0_MODE/4] = 0xFFFFFFFF; x = priv0->vplxdma[PLX_DMA0_MODE/4]; - if (x != 0x00001FFF) + if (x != 0x00001FFF) { + iounmap((void *)priv0->vplxdma); return (0); + } return (1); } @@ -1020,6 +1022,8 @@ dgrs_download(struct net_device *dev0) if (!is) { printk("%s: Illegal IRQ %d\n", dev0->name, dev0->irq); + iounmap(priv0->vmem); + priv0->vmem = NULL; return -ENXIO; } OUTB(dev0->base_addr + ES4H_AS_31_24, @@ -1101,6 +1105,8 @@ dgrs_download(struct net_device *dev0) if (priv0->bcomm->bc_status < BC_RUN) { printk("%s: board not operating\n", dev0->name); + iounmap(priv0->vmem); + priv0->vmem = NULL; return -ENXIO; } _ -- ~Randy "We have met the enemy and he is us." -- Pogo (by Walt Kelly) From rddunlap@osdl.org Mon Apr 5 16:36:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 16:36:35 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35NaUKO003012 for ; Mon, 5 Apr 2004 16:36:30 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i35NaP211126; Mon, 5 Apr 2004 16:36:25 -0700 Date: Mon, 5 Apr 2004 16:29:08 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik Subject: [PATCH] lmc header file not needed Message-Id: <20040405162908.68e5aff4.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4497 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1073 Lines: 36 From: Domen Puncer --- linux-265-kj1-rddunlap/drivers/net/wan/lmc/lmc_proto.c | 1 - linux-265-kj1/drivers/net/wan/lmc/lmc_proto_raw.h | 4 ---- 2 files changed, 5 deletions(-) diff -puN drivers/net/wan/lmc/lmc_proto.c~lmc_proto_raw_h_rm drivers/net/wan/lmc/lmc_proto.c --- linux-265-kj1/drivers/net/wan/lmc/lmc_proto.c~lmc_proto_raw_h_rm 2004-04-05 13:06:33.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/wan/lmc/lmc_proto.c 2004-04-05 13:06:33.000000000 -0700 @@ -50,7 +50,6 @@ #include "lmc_debug.h" #include "lmc_ioctl.h" #include "lmc_proto.h" -//#include "lmc_proto_raw.h" /* * The compile-time variable SPPPSTUP causes the module to be diff -puN -L drivers/net/wan/lmc/lmc_proto_raw.h drivers/net/wan/lmc/lmc_proto_raw.h~lmc_proto_raw_h_rm /dev/null --- linux-265-kj1/drivers/net/wan/lmc/lmc_proto_raw.h +++ /dev/null 2003-05-01 16:55:24.000000000 -0700 @@ -1,4 +0,0 @@ -#ifndef _LMC_PROTO_RAW_H_ -#define _LMC_PROTO_RAW_H_ - -#endif _ -- ~Randy "We have met the enemy and he is us." -- Pogo (by Walt Kelly) From mashirle@us.ibm.com Mon Apr 5 17:12:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 05 Apr 2004 17:12:36 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i360CNKO004582 for ; Mon, 5 Apr 2004 17:12:29 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i360BX0o039608; Mon, 5 Apr 2004 20:11:33 -0400 Received: from IBM-KHXOIC5VFKN.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i360BRZA088870; Mon, 5 Apr 2004 18:11:28 -0600 From: Shirley Ma To: "David S. Miller" Subject: Fix IPv6 MIBs counters in 2.6.5 kernel Date: Mon, 5 Apr 2004 17:11:27 -0700 User-Agent: KMail/1.5 Cc: xma@us.ibm.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@cerberus.hongo.wide.ad.jp References: <200404051351.09740.mashirle@us.ibm.com> <20040405144213.198f76ea.davem@redhat.com> In-Reply-To: <20040405144213.198f76ea.davem@redhat.com> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_vWfcAXd3ZEjun88" Message-Id: <200404051711.27188.mashirle@us.ibm.com> X-archive-position: 4498 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mashirle@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10351 Lines: 362 --Boundary-00=_vWfcAXd3ZEjun88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline I have fixed IPv6 MIBs counters which don't increase under some cases in linux-2.6.5 kernel. Please review it. -- Thanks Shirley Ma IBM Linux Technology Center --Boundary-00=_vWfcAXd3ZEjun88 Content-Type: text/x-diff; charset="iso-8859-1"; name="linux-2.6.5-oldmibs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="linux-2.6.5-oldmibs.patch" diff -urN linux-2.6.5/net/ipv6/exthdrs.c linux-2.6.5-oldmibs/net/ipv6/exthdrs.c --- linux-2.6.5/net/ipv6/exthdrs.c 2004-04-03 19:36:15.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/exthdrs.c 2004-04-05 15:34:44.325848720 -0700 @@ -159,6 +159,7 @@ if (!pskb_may_pull(skb, (skb->h.raw-skb->data)+8) || !pskb_may_pull(skb, (skb->h.raw-skb->data)+((skb->h.raw[1]+1)<<3))) { + IP6_INC_STATS_BH(Ip6InHdrErrors); kfree_skb(skb); return -1; } @@ -171,6 +172,7 @@ return 1; } + IP6_INC_STATS_BH(Ip6InHdrErrors); return -1; } @@ -234,6 +236,7 @@ if (ipv6_addr_is_multicast(&skb->nh.ipv6h->daddr) || skb->pkt_type != PACKET_HOST) { + IP6_INC_STATS_BH(Ip6InAddrErrors); kfree_skb(skb); return -1; } @@ -249,11 +252,13 @@ } if (hdr->type != IPV6_SRCRT_TYPE_0) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->type) - skb->nh.raw); return -1; } if (hdr->hdrlen & 0x01) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->hdrlen) - skb->nh.raw); return -1; } @@ -266,6 +271,7 @@ n = hdr->hdrlen >> 1; if (hdr->segments_left > n) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, (&hdr->segments_left) - skb->nh.raw); return -1; } @@ -276,8 +282,11 @@ if (skb_cloned(skb)) { struct sk_buff *skb2 = skb_copy(skb, GFP_ATOMIC); kfree_skb(skb); - if (skb2 == NULL) + /* the copy is a forwarded packet */ + if (skb2 == NULL) { + IP6_INC_STATS_BH(Ip6OutDiscards); return -1; + } *skbp = skb = skb2; opt = (struct inet6_skb_parm *)skb2->cb; hdr = (struct ipv6_rt_hdr *) skb2->h.raw; @@ -293,6 +302,7 @@ addr += i - 1; if (ipv6_addr_is_multicast(addr)) { + IP6_INC_STATS_BH(Ip6InAddrErrors); kfree_skb(skb); return -1; } @@ -309,6 +319,7 @@ } if (skb->dst->dev->flags&IFF_LOOPBACK) { if (skb->nh.ipv6h->hop_limit <= 1) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_send(skb, ICMPV6_TIME_EXCEED, ICMPV6_EXC_HOPLIMIT, 0, skb->dev); kfree_skb(skb); @@ -425,15 +436,18 @@ if (skb->nh.raw[optoff+1] != 4 || (optoff&3) != 2) { if (net_ratelimit()) printk(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n", skb->nh.raw[optoff+1]); + IP6_INC_STATS_BH(Ip6InHdrErrors); goto drop; } pkt_len = ntohl(*(u32*)(skb->nh.raw+optoff+2)); if (pkt_len <= IPV6_MAXPLEN) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff+2); return 0; } if (skb->nh.ipv6h->payload_len) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, optoff); return 0; } diff -urN linux-2.6.5/net/ipv6/ip6_input.c linux-2.6.5-oldmibs/net/ipv6/ip6_input.c --- linux-2.6.5/net/ipv6/ip6_input.c 2004-04-03 19:37:38.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/ip6_input.c 2004-04-05 15:09:55.000000000 -0700 @@ -79,8 +79,10 @@ if (skb->len < sizeof(struct ipv6hdr)) goto err; - if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) + if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) { + IP6_INC_STATS_BH(Ip6InHdrErrors); goto drop; + } hdr = skb->nh.ipv6h; @@ -94,8 +96,10 @@ if (pkt_len + sizeof(struct ipv6hdr) > skb->len) goto truncated; if (pkt_len + sizeof(struct ipv6hdr) < skb->len) { - if (__pskb_trim(skb, pkt_len + sizeof(struct ipv6hdr))) + if (__pskb_trim(skb, pkt_len + sizeof(struct ipv6hdr))){ + IP6_INC_STATS_BH(Ip6InHdrErrors); goto drop; + } hdr = skb->nh.ipv6h; if (skb->ip_summed == CHECKSUM_HW) skb->ip_summed = CHECKSUM_NONE; @@ -206,6 +210,7 @@ return 0; discard: + IP6_INC_STATS_BH(Ip6InDiscards); rcu_read_unlock(); kfree_skb(skb); return 0; diff -urN linux-2.6.5/net/ipv6/ip6_output.c linux-2.6.5-oldmibs/net/ipv6/ip6_output.c --- linux-2.6.5/net/ipv6/ip6_output.c 2004-04-03 19:36:16.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/ip6_output.c 2004-04-05 15:09:55.000000000 -0700 @@ -87,6 +87,7 @@ } else if (dst->neighbour) return dst->neighbour->output(skb); + IP6_INC_STATS_BH(Ip6OutNoRoutes); kfree_skb(skb); return -EINVAL; @@ -131,6 +132,7 @@ ip6_dev_loopback_xmit); if (skb->nh.ipv6h->hop_limit == 0) { + IP6_INC_STATS(Ip6OutDiscards); kfree_skb(skb); return 0; } @@ -167,6 +169,7 @@ dst = ip6_route_output(skb->sk, &fl); if (dst->error) { + IP6_INC_STATS(Ip6OutNoRoutes); if (net_ratelimit()) printk(KERN_DEBUG "ip6_route_me_harder: No more route.\n"); dst_release(dst); @@ -224,8 +227,10 @@ struct sk_buff *skb2 = skb_realloc_headroom(skb, head_room); kfree_skb(skb); skb = skb2; - if (skb == NULL) + if (skb == NULL) { + IP6_INC_STATS(Ip6OutDiscards); return -ENOBUFS; + } if (sk) skb_set_owner_w(skb, sk); } @@ -265,6 +270,7 @@ printk(KERN_DEBUG "IPv6: sending pkt_too_big to self\n"); skb->dev = dst->dev; icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev); + IP6_INC_STATS(Ip6FragFails); kfree_skb(skb); return -EMSGSIZE; } @@ -345,8 +351,10 @@ if (ipv6_devconf.forwarding == 0) goto error; - if (!xfrm6_policy_check(NULL, XFRM_POLICY_FWD, skb)) + if (!xfrm6_policy_check(NULL, XFRM_POLICY_FWD, skb)) { + IP6_INC_STATS(Ip6InDiscards); goto drop; + } skb->ip_summed = CHECKSUM_NONE; @@ -382,8 +390,10 @@ return -ETIMEDOUT; } - if (!xfrm6_route_forward(skb)) + if (!xfrm6_route_forward(skb)) { + IP6_INC_STATS(Ip6InDiscards); goto drop; + } /* IPv6 specs say nothing about it, but it is clear that we cannot send redirects to source routed frames. @@ -420,12 +430,15 @@ skb->dev = dst->dev; icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, dst_pmtu(dst), skb->dev); IP6_INC_STATS_BH(Ip6InTooBigErrors); + IP6_INC_STATS_BH(Ip6FragFails); kfree_skb(skb); return -EMSGSIZE; } - if (skb_cow(skb, dst->dev->hard_header_len)) + if (skb_cow(skb, dst->dev->hard_header_len)) { + IP6_INC_STATS(Ip6OutDiscards); goto drop; + } hdr = skb->nh.ipv6h; @@ -648,6 +661,7 @@ if ((frag = alloc_skb(len+hlen+sizeof(struct frag_hdr)+LL_RESERVED_SPACE(rt->u.dst.dev), GFP_ATOMIC)) == NULL) { NETDEBUG(printk(KERN_INFO "IPv6: frag: no memory for new fragment!\n")); + IP6_INC_STATS(Ip6FragFails); err = -ENOMEM; goto fail; } @@ -1062,6 +1076,7 @@ ipv6_addr_copy(&hdr->daddr, final_dst); skb->dst = dst_clone(&rt->u.dst); + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, skb->dst->dev, dst_output); if (err) { if (err > 0) @@ -1092,8 +1107,10 @@ struct ipv6_pinfo *np = inet6_sk(sk); struct sk_buff *skb; - while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) + while ((skb = __skb_dequeue_tail(&sk->sk_write_queue)) != NULL) { + IP6_INC_STATS(Ip6OutDiscards); kfree_skb(skb); + } inet->cork.flags &= ~IPCORK_OPT; diff -urN linux-2.6.5/net/ipv6/ndisc.c linux-2.6.5-oldmibs/net/ipv6/ndisc.c --- linux-2.6.5/net/ipv6/ndisc.c 2004-04-03 19:37:23.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/ndisc.c 2004-04-05 15:09:55.000000000 -0700 @@ -452,6 +452,7 @@ skb->dst = dst; idev = in6_dev_get(dst->dev); + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, dst_output); if (!err) { ICMP6_INC_STATS(idev, Icmp6OutNeighborAdvertisements); @@ -535,6 +536,7 @@ /* send it! */ skb->dst = dst; idev = in6_dev_get(dst->dev); + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, dst_output); if (!err) { ICMP6_INC_STATS(idev, Icmp6OutNeighborSolicits); @@ -607,6 +609,7 @@ /* send it! */ skb->dst = dst; idev = in6_dev_get(dst->dev); + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, dst->dev, dst_output); if (!err) { ICMP6_INC_STATS(idev, Icmp6OutRouterSolicits); @@ -1332,6 +1335,7 @@ buff->dst = dst; idev = in6_dev_get(dst->dev); + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, buff, NULL, dst->dev, dst_output); if (!err) { ICMP6_INC_STATS(idev, Icmp6OutRedirects); diff -urN linux-2.6.5/net/ipv6/raw.c linux-2.6.5-oldmibs/net/ipv6/raw.c --- linux-2.6.5/net/ipv6/raw.c 2004-04-03 19:36:56.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/raw.c 2004-04-05 15:09:55.000000000 -0700 @@ -526,6 +526,7 @@ if (err) goto error_fault; + IP6_INC_STATS(Ip6OutRequests); err = NF_HOOK(PF_INET6, NF_IP6_LOCAL_OUT, skb, NULL, rt->u.dst.dev, dst_output); if (err > 0) diff -urN linux-2.6.5/net/ipv6/reassembly.c linux-2.6.5-oldmibs/net/ipv6/reassembly.c --- linux-2.6.5/net/ipv6/reassembly.c 2004-04-03 19:36:55.000000000 -0800 +++ linux-2.6.5-oldmibs/net/ipv6/reassembly.c 2004-04-05 15:09:55.000000000 -0700 @@ -426,6 +426,7 @@ ((u8 *) (fhdr + 1) - (u8 *) (skb->nh.ipv6h + 1))); if ((unsigned int)end > IPV6_MAXPLEN) { + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb,ICMPV6_HDR_FIELD, (u8*)&fhdr->frag_off - skb->nh.raw); return; } @@ -452,6 +453,7 @@ /* RFC2460 says always send parameter problem in * this case. -DaveM */ + IP6_INC_STATS_BH(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, offsetof(struct ipv6hdr, payload_len)); return; @@ -570,6 +572,7 @@ return; err: + IP6_INC_STATS(Ip6ReasmFails); kfree_skb(skb); } @@ -694,10 +697,12 @@ /* Jumbo payload inhibits frag. header */ if (hdr->payload_len==0) { + IP6_INC_STATS(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, skb->h.raw-skb->nh.raw); return -1; } if (!pskb_may_pull(skb, (skb->h.raw-skb->data)+sizeof(struct frag_hdr))) { + IP6_INC_STATS(Ip6InHdrErrors); icmpv6_param_prob(skb, ICMPV6_HDR_FIELD, skb->h.raw-skb->nh.raw); return -1; } --Boundary-00=_vWfcAXd3ZEjun88-- From romieu@fr.zoreil.com Tue Apr 6 00:49:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 00:49:38 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i367nXKO004257 for ; Tue, 6 Apr 2004 00:49:34 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i367l9gf030165; Tue, 6 Apr 2004 09:47:09 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i367l7uI030164; Tue, 6 Apr 2004 09:47:07 +0200 Date: Tue, 6 Apr 2004 09:47:07 +0200 From: Francois Romieu To: =?unknown-8bit?Q?Dieter_N=FCtzel?= Cc: Linux-Kernel List , Andrew Morton , Manfred Spraul , netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] Fix kernel lockup in RTL-8169 gigabit ethernet driver Message-ID: <20040406094707.A29666@electric-eye.fr.zoreil.com> References: <200404060108.19488.Dieter.Nuetzel@hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200404060108.19488.Dieter.Nuetzel@hamburg.de>; from Dieter.Nuetzel@hamburg.de on Tue, Apr 06, 2004 at 01:08:19AM +0200 X-Organisation: Land of Sunshine Inc. X-MIME-Autoconverted: from 8bit to quoted-printable by fr.zoreil.com id i367l9gf030165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i367nXKO004257 X-archive-position: 4500 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 618 Lines: 19 Dieter Nützel : [...] > Isn't the "current" RTL8169s (32/64) driver much outdated? > > I got a version # 1.6 with all my cards. This version has been merged in -mm since late 2003. Complete history is available on the netdev mailing list. From memory, there should be a Tx descriptor overflow bug in # 1.6 (see tx_interrupt). You may want to change some bits in your #1.6 version. There is a regression related to link removal in the current -mm/jg-netdev version (-mm stands behind jg-netdev where I hope to push what is posted on the netdev mailing list). Stay tuned. :o) -- Ueimor From cfs@nova.es Tue Apr 6 02:25:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 02:25:46 -0700 (PDT) Received: from fulanito.nisupu.com (qmailr@66.Red-80-38-104.pooles.rima-tde.net [80.38.104.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i369PZKO009191 for ; Tue, 6 Apr 2004 02:25:39 -0700 Received: (qmail 9983 invoked from network); 6 Apr 2004 09:25:32 -0000 Received: from hush.nisupu.com (HELO HUSH) (192.168.20.5) by fulanito.nisupu.com with SMTP; 6 Apr 2004 09:25:32 -0000 Message-ID: <000e01c41bb9$536600b0$1530a8c0@HUSH> From: "Carlos Fernandez Sanz" To: , Subject: vortex problems in 2.6? Date: Tue, 6 Apr 2004 11:27:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C41BCA.16BCC430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4501 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfs@nova.es Precedence: bulk X-list: netdev Content-Length: 24431 Lines: 578 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C41BCA.16BCC430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm trying to track down my problems with my NIC in 2.6.5 (worked fine = in 2.4.22). The network "works" but very very slow, and ifconfig shows = almost the same count in the Tx packet and carrier count: TX packets:23818 errors:0 dropped:0 overruns:0 carrier:23817 dmesg for 2.4.22 and 2.6.5 are almost identical, except for the last = lines in 2.4.22 (vortex_up, etc). There are no (apparently important) = different in vortex-diag. mii-diag, however, fails to run in 2.6.5 while it works in 2.4.22. Dumps follow, in case someone can shed light. (BTW: lsmod in 2.4.22 shows the module as busy (used twice, because I = have two identical NICs, while in 2.6.5 it seems to be unused - I can unload = the module with both interfaces up, but obviously as soon as I do that they dissapear - I assume this is the intended 2.6 behaviour). ***** dmesg ***** 2.4.22: PCI: Found IRQ 9 for device 02:0b.0 PCI: Sharing IRQ 9 with 00:1f.4 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 02:0b.0: 3Com PCI 3c905C Tornado at 0xd800. Vers LK1.1.18-ac 00:01:03:27:81:75, IRQ 9 product code 4a45 rev 00.12 date 10-15-00 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. 02:0b.0: scatter/gather enabled. h/w checksums enabled divert: allocating divert_blk for eth0 eth0: using NWAY device table, not 8 eth0: Initial media type Autonegotiate. eth0: MII #24 status 786d, link partner capability 45e1, info1 0010, = setting full-duplex. eth0: vortex_up() InternalConfig 01800000. eth0: vortex_up() irq 9 media status 8880. 2.6.5: PCI: Found IRQ 9 for device 0000:02:0b.0 PCI: Sharing IRQ 9 with 0000:00:1f.4 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 0000:02:0b.0: 3Com PCI 3c905C Tornado at 0xd800. Vers LK1.1.19 00:01:03:27:81:75, IRQ 9 product code 4a45 rev 00.12 date 10-15-00 Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. 0000:02:0b.0: scatter/gather enabled. h/w checksums enabled ********* vortex-diag ********* 2.4.22: Index #1: Found a 3c920 Series NIC adapter at 0xd800. Station address 00:01:03:27:81:75. Receive mode is 0x07: Normal unicast and all multicast. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 d93f 0000 e3e3 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007e 0000 2000. Window 2: 0100 2703 7581 0000 0000 0000 0042 4000. Window 3: 0000 0180 05ea 0020 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cd8 0001 8880 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 0a00 0000 02e2 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xd800 0xD810: **FIFO** 00000000 0000000a *STATUS* 0xD820: 00000020 00000000 00080000 00000004 0xD830: 00000000 44aebb52 03f58180 00080004 0xD840: 003eb253 00000000 000000b7 00000000 0xD850: 00000000 00000000 00000000 00000000 0xD860: 00000000 00000000 00000000 00000000 0xD870: 00009800 00000000 01600000 00000000 DMA control register is 00000020. Tx list starts at 00000000. Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to = empty. Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to = full. Poll period Tx 00 ns., Rx 0 ns. Maximum burst recorded Tx 0, Rx 352. Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: full-duplex. Station address set to 00:01:03:27:81:75. Configuration options 0042. EEPROM format 64x16, configuration table at offset 0: 00: 0001 0327 8175 9200 014f 0048 454a 6d50 0x08: 2940 0800 0001 0327 8175 0010 0000 00aa 0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7 0x18: 1000 000a 0002 6300 ffb7 b7b7 0000 0000 0x20: 00ba 1234 5600 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: ffff ffff ffff ffff ffff ffff ffff ffff ... The word-wide EEPROM checksum is 0x9dc7. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:01:03:27:81:75 (used as a unique ID only). OEM Station address 00:01:03:27:81:75 (used as the ethernet address). Device ID 9200, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 10/15/2000, division H, product JE. A BIOS ROM of size 0Kx8 is expected. Transceiver selection: Autonegotiate. Options: negotiated duplex, link beat required. PCI bus requested settings -- minimum grant 10, maximum latency 10 = (250ns units). PCI Subsystem IDs: Vendor 10b7 Device 1000. 100baseTx 10baseT. Vortex format checksum is incorrect (2c vs. 10b7). Cyclone format checksum is incorrect (0xbc vs. 0xba). Hurricane format checksum is incorrect (0x95 vs. 0xba). MII PHY found at address 24, status 786d. MII PHY 0 at #24 transceiver registers: 3000 786d 0180 7750 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0238 0087 0000 0000 0000 0000 c4c8 0300 0100 0438 2010 2000 0000 0000 0000 0000. 2.6.5: Index #1: Found a 3c920 Series NIC adapter at 0xd800. Station address 00:01:03:27:81:75. Receive mode is 0x07: Normal unicast and all multicast. The Vortex chip may be active, so FIFO registers will not be read. To see all register values use the '-f' flag. Initial window 7, registers values by window: Window 0: 0000 0000 d93f 0000 e3e3 00bf ffff 0000. Window 1: FIFO FIFO 0700 0000 0000 007e 0000 2000. Window 2: 0100 2703 7581 0000 0000 0000 0042 4000. Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000. Window 4: 0000 0000 0000 0cd8 0001 8c80 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 0600 0000 0569 018c c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xd800 0xD810: **FIFO** 00000000 0000002a *STATUS* 0xD820: 00000020 00000000 00080000 00000004 0xD830: 00000000 d03a2fc6 1ce260c0 00080004 0xD840: 00bb915d 00000000 000000b7 00000000 0xD850: 00000000 00000000 00000000 00000000 0xD860: 00000000 00000000 00000000 00000000 0xD870: 00009800 00000000 01600160 00000000 DMA control register is 00000020. Tx list starts at 00000000. Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty. Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to full. Poll period Tx 00 ns., Rx 0 ns. Maximum burst recorded Tx 352, Rx 352. Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: half-duplex. Station address set to 00:01:03:27:81:75. Configuration options 0042. EEPROM format 64x16, configuration table at offset 0: 00: 0001 0327 8175 9200 014f 0048 454a 6d50 0x08: 2940 0800 0001 0327 8175 0010 0000 00aa 0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7 0x18: 1000 000a 0002 6300 ffb7 b7b7 0000 0000 0x20: 00ba 1234 5600 0000 0000 0000 0000 0000 0x28: 0000 0000 0000 0000 0000 0000 0000 0000 0x30: ffff ffff ffff ffff ffff ffff ffff ffff ... The word-wide EEPROM checksum is 0x9dc7. Saved EEPROM settings of a 3Com Vortex/Boomerang: 3Com Node Address 00:01:03:27:81:75 (used as a unique ID only). OEM Station address 00:01:03:27:81:75 (used as the ethernet address). Device ID 9200, Manufacturer ID 6d50. Manufacture date (MM/DD/YYYY) 10/15/2000, division H, product JE. A BIOS ROM of size 0Kx8 is expected. Transceiver selection: Autonegotiate. Options: negotiated duplex, link beat required. PCI bus requested settings -- minimum grant 10, maximum latency 10 (250ns units). PCI Subsystem IDs: Vendor 10b7 Device 1000. 100baseTx 10baseT. Vortex format checksum is incorrect (2c vs. 10b7). Cyclone format checksum is incorrect (0xbc vs. 0xba). Hurricane format checksum is incorrect (0x95 vs. 0xba). MII PHY found at address 24, status 786d. MII PHY 0 at #24 transceiver registers: 3000 786d 0180 7750 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0238 0087 0000 0000 0000 0000 c4c8 0300 0100 0438 2010 2000 8000 0000 0000 0000. ****** mii-diag ****** 2.4.22: mii-diag.c:v2.09 9/06/2003 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3000). The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD = 10baseT. Able to perform Auto-negotiation, negotiation complete. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver information. libmii.c:v2.10 4/22/2003 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html MII PHY #24 transceiver registers: 3000 786d 0180 7750 05e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0238 0087 0000 0000 0000 0000 c4c8 0300 0100 0438 2010 2000 0000 0000 0000 0000. Basic mode control register 0x3000: Auto-negotiation enabled. Basic mode status register 0x786d ... 786d. Link status: established. Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Able to perform Auto-negotiation, negotiation complete. Vendor ID is 00:60:1d:--:--:--, model 53 rev. 0. No specific information is known about this transceiver type. I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD = 10baseT Advertising no additional info pages. IEEE 802.3 CSMA/CD protocol. Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT. Negotiation completed. 2.6.5: root@fulanito root]# mii-diag --force Using the default interface 'eth0'. Basic registers of MII PHY #24: 0000 0000 0000 0000 0000 0000 0000 = 0000. No MII transceiver present!. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. Thanks. ------=_NextPart_000_000B_01C41BCA.16BCC430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

<Please CC: me in the reply as I = don't subscribe=20 to this list. Thanks>
 
I'm trying to track down my problems with my NIC in 2.6.5 (worked = fine=20 in
2.4.22). The network "works" but very very slow, and ifconfig = shows=20 almost
the same count in the Tx packet and carrier count:

TX=20 packets:23818 errors:0 dropped:0 overruns:0 carrier:23817

dmesg = for=20 2.4.22 and 2.6.5 are almost identical, except for the last lines
in = 2.4.22=20 (vortex_up, etc). There are no (apparently important) different=20 in
vortex-diag. mii-diag, however, fails to run in 2.6.5 while it = works=20 in
2.4.22.

 Dumps follow, in case someone can shed=20 light.

(BTW: lsmod in 2.4.22 shows the module as busy (used = twice,=20 because I have
two identical NICs, while in 2.6.5 it seems to be = unused - I=20 can unload the
module with both interfaces up, but obviously as soon = as I do=20 that they
dissapear - I assume this is the intended 2.6=20 behaviour).

*****
dmesg
*****
2.4.22:
PCI: Found IRQ = 9 for=20 device 02:0b.0
PCI: Sharing IRQ 9 with 00:1f.4
3c59x: Donald = Becker and=20 others. www.scyld.com/network/v= ortex.html
See=20 Documentation/networking/vortex.txt
02:0b.0: 3Com PCI 3c905C Tornado = at=20 0xd800. Vers LK1.1.18-ac
00:01:03:27:81:75, IRQ 9
product code = 4a45 rev=20 00.12 date 10-15-00
Internal config register is 1800000, transceivers = 0xa.
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate=20 interface.
MII transceiver found at address 24, status = 786d.
Enabling=20 bus-master transmits and whole-frame receives.
02:0b.0: = scatter/gather=20 enabled. h/w checksums enabled
divert: allocating divert_blk for=20 eth0
eth0: using NWAY device table, not 8
eth0: Initial media type = Autonegotiate.
eth0: MII #24 status 786d, link partner capability = 45e1, info1=20 0010, setting
full-duplex.
eth0: vortex_up() InternalConfig=20 01800000.
eth0: vortex_up() irq 9 media status = 8880.

2.6.5:
PCI:=20 Found IRQ 9 for device 0000:02:0b.0
PCI: Sharing IRQ 9 with=20 0000:00:1f.4
3c59x: Donald Becker and others. www.scyld.com/network/v= ortex.html
See=20 Documentation/networking/vortex.txt
0000:02:0b.0: 3Com PCI 3c905C = Tornado at=20 0xd800. Vers LK1.1.19
00:01:03:27:81:75, IRQ 9
product code 4a45 = rev 00.12=20 date 10-15-00
Internal config register is 1800000, transceivers = 0xa.
8K=20 byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate = interface.
MII=20 transceiver found at address 24, status 786d.
Enabling bus-master = transmits=20 and whole-frame receives.
0000:02:0b.0: scatter/gather enabled. h/w = checksums=20 enabled
*********
vortex-diag
*********

2.4.22:
Index = #1:=20 Found a 3c920 Series NIC adapter at 0xd800.
Station address=20 00:01:03:27:81:75.
Receive mode is 0x07: Normal unicast and all=20 multicast.
The Vortex chip may be active, so FIFO registers will not = be=20 read.
To see all register values use the '-f' flag.
Initial window = 7,=20 registers values by window:
Window 0: 0000 0000 d93f 0000 e3e3 00bf = ffff=20 0000.
Window 1: FIFO FIFO 0700 0000 0000 007e 0000 2000.
Window 2: = 0100=20 2703 7581 0000 0000 0000 0042 4000.
Window 3: 0000 0180 05ea 0020 = 000a 0800=20 0800 6000.
Window 4: 0000 0000 0000 0cd8 0001 8880 0000 = 8000.
Window 5:=20 1ffc 0000 0000 0600 0807 06ce 06c6 a000.
Window 6: 0000 0000 0000 = 0a00 0000=20 02e2 0000 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 = e000.
Vortex=20 chip registers at 0xd800
0xD810: **FIFO** 00000000 0000000a=20 *STATUS*
0xD820: 00000020 00000000 00080000 00000004
0xD830: = 00000000=20 44aebb52 03f58180 00080004
0xD840: 003eb253 00000000 000000b7=20 00000000
0xD850: 00000000 00000000 00000000 00000000
0xD860: = 00000000=20 00000000 00000000 00000000
0xD870: 00009800 00000000 01600000 = 00000000
DMA=20 control register is 00000020.
Tx list starts at 00000000.
Tx FIFO=20 thresholds: min. burst 256 bytes, priority with 128 bytes to = empty.
Rx FIFO=20 thresholds: min. burst 256 bytes, priority with 128 bytes to = full.
Poll=20 period Tx 00 ns., Rx 0 ns.
Maximum burst recorded Tx 0, Rx = 352.
Indication=20 enable is 06c6, interrupt enable is 06ce.
No interrupt sources are=20 pending.
Transceiver/media interfaces available: 100baseTx=20 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings:=20 full-duplex.
Station address set to = 00:01:03:27:81:75.
Configuration=20 options 0042.
EEPROM format 64x16, configuration table at offset = 0:
00:=20 0001 0327 8175 9200 014f 0048 454a 6d50
0x08: 2940 0800 0001 0327 = 8175 0010=20 0000 00aa
0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7
0x18: 1000 = 000a=20 0002 6300 ffb7 b7b7 0000 0000
0x20: 00ba 1234 5600 0000 0000 0000 = 0000=20 0000
0x28: 0000 0000 0000 0000 0000 0000 0000 0000
0x30: ffff ffff = ffff=20 ffff ffff ffff ffff ffff
...
The word-wide EEPROM checksum is=20 0x9dc7.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com = Node=20 Address 00:01:03:27:81:75 (used as a unique ID only).
OEM Station = address=20 00:01:03:27:81:75 (used as the ethernet address).
Device ID 9200,=20 Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 10/15/2000, = division H,=20 product JE.
A BIOS ROM of size 0Kx8 is expected.
Transceiver = selection:=20 Autonegotiate.
Options: negotiated duplex, link beat required.
PCI = bus=20 requested settings -- minimum grant 10, maximum latency 10=20 (250ns
units).
PCI Subsystem IDs: Vendor 10b7 Device = 1000.
100baseTx=20 10baseT.
Vortex format checksum is incorrect (2c vs. = 10b7).
Cyclone format=20 checksum is incorrect (0xbc vs. 0xba).
Hurricane format checksum is = incorrect=20 (0x95 vs. 0xba).
MII PHY found at address 24, status 786d.
MII PHY = 0 at=20 #24 transceiver registers:
3000 786d 0180 7750 05e1 45e1 0001 = 0000
0000=20 0000 0000 0000 0000 0000 0000 0000
0238 0087 0000 0000 0000 0000 c4c8 = 0300
0100 0438 2010 2000 0000 0000 0000 0000.

2.6.5:
Index = #1:=20 Found a 3c920 Series NIC adapter at 0xd800.
 Station address=20 00:01:03:27:81:75.
  Receive mode is 0x07: Normal unicast and = all=20 multicast.
The Vortex chip may be active, so FIFO registers will not = be=20 read.
To see all register values use the '-f' flag.
Initial window = 7,=20 registers values by window:
  Window 0: 0000 0000 d93f 0000 e3e3 = 00bf=20 ffff 0000.
  Window 1: FIFO FIFO 0700 0000 0000 007e 0000=20 2000.
  Window 2: 0100 2703 7581 0000 0000 0000 0042 = 4000.
 =20 Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
  Window 4: = 0000 0000=20 0000 0cd8 0001 8c80 0000 8000.
  Window 5: 1ffc 0000 0000 0600 = 0807 06ce=20 06c6 a000.
  Window 6: 0000 0000 0000 0600 0000 0569 018c=20 c000.
  Window 7: 0000 0000 0000 0000 0000 0000 0000 = e000.
Vortex=20 chip registers at 0xd800
  0xD810: **FIFO** 00000000 0000002a=20 *STATUS*
  0xD820: 00000020 00000000 00080000 00000004
  = 0xD830:=20 00000000 d03a2fc6 1ce260c0 00080004
  0xD840: 00bb915d 00000000 = 000000b7=20 00000000
  0xD850: 00000000 00000000 00000000 00000000
  = 0xD860:=20 00000000 00000000 00000000 00000000
  0xD870: 00009800 00000000 = 01600160=20 00000000
  DMA control register is 00000020.
   Tx = list=20 starts at 00000000.
   Tx FIFO thresholds: min. burst 256 = bytes,=20 priority with 128 bytes to
empty.
   Rx FIFO thresholds: = min.=20 burst 256 bytes, priority with 128 bytes to
full.
   = Poll period=20 Tx 00 ns.,  Rx 0 ns.
   Maximum burst recorded Tx = 352, =20 Rx 352.
 Indication enable is 06c6, interrupt enable is=20 06ce.
 No interrupt sources are = pending.
 Transceiver/media=20 interfaces available:  100baseTx 10baseT.
Transceiver type in = use: =20 Autonegotiate.
 MAC settings: half-duplex.
 Station = address set=20 to 00:01:03:27:81:75.
 Configuration options 0042.
EEPROM = format=20 64x16, configuration table at offset 0:
    00: 0001 = 0327 8175=20 9200 014f 0048 454a 6d50
  0x08: 2940 0800 0001 0327 8175 0010 = 0000=20 00aa
  0x10: 72a2 0000 0000 0180 0000 0000 0429 10b7
  = 0x18:=20 1000 000a 0002 6300 ffb7 b7b7 0000 0000
  0x20: 00ba 1234 5600 = 0000 0000=20 0000 0000 0000
  0x28: 0000 0000 0000 0000 0000 0000 0000 = 0000
 =20 0x30: ffff ffff ffff ffff ffff ffff ffff = ffff
     =20 ...
 The word-wide EEPROM checksum is 0x9dc7.
Saved EEPROM = settings=20 of a 3Com Vortex/Boomerang:
 3Com Node Address 00:01:03:27:81:75 = (used=20 as a unique ID only).
 OEM Station address 00:01:03:27:81:75 = (used as=20 the ethernet address).
  Device ID 9200,  Manufacturer ID=20 6d50.
  Manufacture date (MM/DD/YYYY) 10/15/2000, division H, = product=20 JE.
  A BIOS ROM of size 0Kx8 is expected.
 Transceiver=20 selection: Autonegotiate.
   Options: negotiated duplex, = link beat=20 required.
   PCI bus requested settings --  minimum = grant 10,=20 maximum latency 10
(250ns units).
 PCI Subsystem IDs: Vendor = 10b7=20 Device 1000.
 100baseTx 10baseT.
  Vortex format = checksum is=20 incorrect (2c vs. 10b7).
  Cyclone format checksum is incorrect = (0xbc=20 vs. 0xba).
  Hurricane format checksum is incorrect (0x95 vs.=20 0xba).
 MII PHY found at address 24, status 786d.
 MII = PHY 0 at=20 #24 transceiver registers:
   3000 786d 0180 7750 05e1 45e1 = 0001=20 0000
   0000 0000 0000 0000 0000 0000 0000 = 0000
  =20 0238 0087 0000 0000 0000 0000 c4c8 0300
   0100 0438 2010 = 2000 8000=20 0000 0000=20 0000.

******
mii-diag
******
2.4.22:
mii-diag.c:v2.09 = 9/06/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/i= ndex.html
Using=20 the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3000).
The autonegotiated = capability is 01e0.
The autonegotiated media type is = 100baseTx-FD.
Basic=20 mode control register 0x3000: Auto-negotiation enabled.
You have link = beat,=20 and everything is working OK.
This transceiver is capable of = 100baseTx-FD=20 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, = negotiation=20 complete.
Your link partner advertised 45e1: Flow-control = 100baseTx-FD=20 100baseTx
10baseT-FD 10baseT, w/ 802.3X flow control.
End of basic = transceiver information.
libmii.c:v2.10 4/22/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/i= ndex.html
MII=20 PHY #24 transceiver registers:
3000 786d 0180 7750 05e1 45e1 0001=20 0000
0000 0000 0000 0000 0000 0000 0000 0000
0238 0087 0000 0000 = 0000 0000=20 c4c8 0300
0100 0438 2010 2000 0000 0000 0000 0000.
Basic mode = control=20 register 0x3000: Auto-negotiation enabled.
Basic mode status register = 0x786d=20 ... 786d.
Link status: established.
Capable of 100baseTx-FD = 100baseTx=20 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation=20 complete.
Vendor ID is 00:60:1d:--:--:--, model 53 rev. 0.
No = specific=20 information is known about this transceiver type.
I'm advertising = 05e1:=20 Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no = additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner=20 capability is 45e1: Flow-control 100baseTx-FD 100baseTx
10baseT-FD=20 10baseT.
Negotiation completed.

2.6.5:
root@fulanito root]# mii-diag = --force
Using=20 the default interface 'eth0'.
Basic registers of MII PHY #24:  = 0000 0000=20 0000 0000 0000 0000 0000 0000.
  No MII transceiver=20 present!.
 Basic mode control register 0x0000: Auto-negotiation=20 disabled, with
 Speed fixed at 10 mbps, = half-duplex.
 Basic mode=20 status register 0x0000 ... 0000.
   Link status: not=20 established.
 Link partner information is not exchanged when in = fixed=20 speed mode.
   End of basic transceiver=20 information.

Thanks.
 
 
------=_NextPart_000_000B_01C41BCA.16BCC430-- From P@draigBrady.com Tue Apr 6 03:31:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 03:31:52 -0700 (PDT) Received: from corvil.com (gate.corvil.net [213.94.219.177]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36AVVKO014718 for ; Tue, 6 Apr 2004 03:31:32 -0700 Received: from draigBrady.com (pixelbeat.local.corvil.com [172.18.1.170]) by corvil.com (8.12.9/8.12.5) with ESMTP id i36AUJhr096614; Tue, 6 Apr 2004 11:30:20 +0100 (IST) (envelope-from P@draigBrady.com) Message-ID: <407286BB.8080107@draigBrady.com> Date: Tue, 06 Apr 2004 11:30:19 +0100 From: P@draigBrady.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: netdev@oss.sgi.com, cpw@lanl.gov, luca.deri@netikos.com Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by corvil.com id i36AUJhr096614 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i36AVVKO014718 X-archive-position: 4502 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: P@draigBrady.com Precedence: bulk X-list: netdev Content-Length: 2262 Lines: 56 Jason Lunz wrote: > hadi@cyberus.ca said: > >>Jason Lunz actually seemed to have been doing more work on this and >>e1000 - he could provide better perfomance numbers. > > > Well, not really. What I have is still available at: > > http://gtf.org/lunz/linux/net/perf/ > > ...but those are mainly measurements of very outdated versions of the > e1000 napi driver backported to 2.4, running on 1.8Ghz Xeon systems. > That work hasn't really been kept up to date, I'm afraid. > > >>It should also be noted that infact packet mmap already uses rings. > > > Yes, I read the paper (but not his code). What stood out to me is that > the description of his custom socket implementation matches exactly what > packet-mmap already is. > > I noticed he only mentioned testing of libpcap-mmap, but did not use > mmap packet sockets directly -- maybe there's something about libpcap > that limits performance? I haven't looked. That's my experience. I'm thinking of redoing libpcap-mmap completely as it has huge amounts of statistics messing in the fast path. Also the ring gets corrupted if packets are being received while the ring buffer is being setup. I've a patch for http://public.lanl.gov/cpw/libpcap-0.8.030808.tar.gz here: http://www.pixelbeat.org/patches/libpcap-0.8.030808-pb.diff (you need to compile with PB defined) Note this only addresses the speed issue. Also there are newer versions of libpcap-mmap available which I haven't looked at yet. > What I can say for sure is that the napi + packet-mmap performance with > many small packets is almost surely limited by problems with irq/softirq > load. There was an excellent thread last week about this with Andrea > Arcangeli, Robert Olsson and others about the balancing of softirq and > userspace load; they eventually were beginning to agree that running > softirqs on return from hardirq and bh was a bigger load than expected > when there was lots of napi work to do. So despite NAPI, too much kernel > time is spent handling (soft)irq load with many small packets. agreed. > It appears this problem became worse in 2.6 with HZ=1000, because now > the napi rx softirq work is being done 10X as much on return from the > timer interrupt. I'm not sure if a solution was reached. Pádraig. From jgarzik@pobox.com Tue Apr 6 04:58:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 04:58:20 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36BwBKO023658 for ; Tue, 6 Apr 2004 04:58:12 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BApDW-0002T4-0S; Tue, 06 Apr 2004 12:58:10 +0100 Message-ID: <40729B41.4040403@pobox.com> Date: Tue, 06 Apr 2004 07:57:53 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5 1/4] pcnet32.c add support for 79C976 References: <200404052124.i35LOrD10981@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404052124.i35LOrD10981@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4503 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: 45 Lines: 3 all four patches applied to 2.6.x, thanks. From jgarzik@pobox.com Tue Apr 6 05:16:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 05:16:35 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36CGLKO026261 for ; Tue, 6 Apr 2004 05:16:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BApV6-0002fs-Nj; Tue, 06 Apr 2004 13:16:20 +0100 Message-ID: <40729F88.4060300@pobox.com> Date: Tue, 06 Apr 2004 08:16:08 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev Subject: Re: [janitor] dgrs: add missing iounmaps References: <20040405162753.7c0c5257.rddunlap@osdl.org> In-Reply-To: <20040405162753.7c0c5257.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4504 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From jgarzik@pobox.com Tue Apr 6 05:18:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 05:18:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36CIRKO026655 for ; Tue, 6 Apr 2004 05:18:28 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BApX9-0002hF-0x; Tue, 06 Apr 2004 13:18:27 +0100 Message-ID: <4072A007.6010409@pobox.com> Date: Tue, 06 Apr 2004 08:18:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev Subject: Re: [PATCH] lmc header file not needed References: <20040405162908.68e5aff4.rddunlap@osdl.org> In-Reply-To: <20040405162908.68e5aff4.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4505 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 9 Lines: 2 applied From deri@ntop.org Tue Apr 6 05:26:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 05:27:13 -0700 (PDT) Received: from localhost.localdomain (host114-228.pool82187.interbusiness.it [82.187.228.114]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36CQlKO027272 for ; Tue, 6 Apr 2004 05:26:49 -0700 Received: from ntop.org (athlon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i36CPnBv026985; Tue, 6 Apr 2004 14:25:59 +0200 Message-ID: <4072A1CD.8070905@ntop.org> Date: Tue, 06 Apr 2004 14:25:49 +0200 From: Luca Deri Organization: ntop.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: P@draigBrady.com CC: Jason Lunz , netdev@oss.sgi.com, cpw@lanl.gov, ntop-misc@fuji.unipi.it Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> In-Reply-To: <407286BB.8080107@draigBrady.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by localhost.localdomain id i36CPnBv026985 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i36CQlKO027272 X-archive-position: 4506 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: deri@ntop.org Precedence: bulk X-list: netdev Content-Length: 4000 Lines: 104 Hi all, the problem with libpcap-mmap is that: - it does not reduce the journey of the packet from NIC to userland beside the last part of it (syscall replaced with mmap). This has a negative impact on the overall performance. - it does not feature things like kernel packet sampling that pushes people to fetch all the packets out of a NIC then discard most of them (i.e. CPU cycles not very well spent). Somehow this is a limitation of pcap that does not feature a pcap_sample call. In addition if you do care about performance, I believe you're willing to turn off packet transmission and only do packet receive. Unfortunately I have no access to a "real" traffic generator (I use a PC as traffic generator). However if you read my paper you can see that with a Pentium IV 1.7 you can capture over 500'000 pkt/sec, so in your setup (Xeon + Spirent) you can have better figures. IRQ: Linux has far too much latency, in particular at high speeds. I'm not the right person who can say "this is the way to go", however I believe that we need some sort of interrupt prioritization like RTIRQ does. FYI, I've just polished the code and added kernel packet filtering to PF_RING. As soon as I have completed my tests I will release a new version. Finally It would be nice to have in the standard Linux core some packet capture improvements. It could either be based on my work or on somebody else's work. It doesn't really matter as long as Linux gets faster. Cheers, Luca P@draigBrady.com wrote: > Jason Lunz wrote: > >> hadi@cyberus.ca said: >> >>> Jason Lunz actually seemed to have been doing more work on this and >>> e1000 - he could provide better perfomance numbers. >> >> >> >> Well, not really. What I have is still available at: >> >> http://gtf.org/lunz/linux/net/perf/ >> >> ...but those are mainly measurements of very outdated versions of the >> e1000 napi driver backported to 2.4, running on 1.8Ghz Xeon systems. >> That work hasn't really been kept up to date, I'm afraid. >> >> >>> It should also be noted that infact packet mmap already uses rings. >> >> >> >> Yes, I read the paper (but not his code). What stood out to me is that >> the description of his custom socket implementation matches exactly what >> packet-mmap already is. >> >> I noticed he only mentioned testing of libpcap-mmap, but did not use >> mmap packet sockets directly -- maybe there's something about libpcap >> that limits performance? I haven't looked. > > > That's my experience. I'm thinking of redoing libpcap-mmap completely > as it has huge amounts of statistics messing in the fast path. > Also the ring gets corrupted if packets are being received while > the ring buffer is being setup. > > I've a patch for http://public.lanl.gov/cpw/libpcap-0.8.030808.tar.gz > here: http://www.pixelbeat.org/patches/libpcap-0.8.030808-pb.diff > (you need to compile with PB defined) > Note this only addresses the speed issue. > Also there are newer versions of libpcap-mmap available which I > haven't looked at yet. > >> What I can say for sure is that the napi + packet-mmap performance with >> many small packets is almost surely limited by problems with irq/softirq >> load. There was an excellent thread last week about this with Andrea >> Arcangeli, Robert Olsson and others about the balancing of softirq and >> userspace load; they eventually were beginning to agree that running >> softirqs on return from hardirq and bh was a bigger load than expected >> when there was lots of napi work to do. So despite NAPI, too much kernel >> time is spent handling (soft)irq load with many small packets. > > > agreed. > >> It appears this problem became worse in 2.6 with HZ=1000, because now >> the napi rx softirq work is being done 10X as much on return from the >> timer interrupt. I'm not sure if a solution was reached. > > > Pádraig > . -- Luca Deri http://luca.ntop.org/ Hacker: someone who loves to program and enjoys being clever about it - Richard Stallman From jgarzik@pobox.com Tue Apr 6 05:29:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 05:29:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36CTXKO027689 for ; Tue, 6 Apr 2004 05:29:34 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BAphs-0002qv-SO; Tue, 06 Apr 2004 13:29:33 +0100 Message-ID: <4072A2A1.7060104@pobox.com> Date: Tue, 06 Apr 2004 08:29:21 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev Subject: Re: [PATCH] remove magic '31' for netdev priv. alignment References: <20040405155654.69a9bb4b.rddunlap@osdl.org> In-Reply-To: <20040405155654.69a9bb4b.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4507 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From Robert.Olsson@data.slu.se Tue Apr 6 05:55:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 05:55:43 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36CtWKO028753 for ; Tue, 6 Apr 2004 05:55:33 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i36CtJNv030320; Tue, 6 Apr 2004 14:55:21 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id BB52E903D5; Tue, 6 Apr 2004 14:55:19 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5cX1WWKSdC" Content-Transfer-Encoding: 7bit Message-ID: <16498.43191.733850.18276@robur.slu.se> Date: Tue, 6 Apr 2004 14:55:19 +0200 To: dipankar@in.ibm.com Cc: Robert Olsson , Andrea Arcangeli , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <20040405212220.GH4003@in.ibm.com> References: <200403302005.AAA00466@yakov.inr.ac.ru> <20040330211450.GI3808@dualathlon.random> <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> <16497.37720.607342.193544@robur.slu.se> <20040405212220.GH4003@in.ibm.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4508 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 3413 Lines: 72 --5cX1WWKSdC Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Dipankar Sarma writes: > Looks better atleast. Can you apply the following patch (rs-throttle-rcu) > on top of rcu-softirq.patch in your tree and see if helps a little bit more ? > Please make sure to set the kernel paramenters rcupdate.maxbatch to 4 > and rcupdate.plugticks to 0. You can make sure of those parameters > by looking at dmesg (rcu prints them out during boot). I just merged > it, but have not tested this patch yet. OK! Well not tested yet but I don't think we will get rid overflow totally in my setup. I've done a little experimental patch so *all* softirq's are run via ksoftirqd. total droppped tsquz throttl bh_enbl ksoftird irqexit other 009bee0c 00000000 00004aa7 00000000 00000000 0336a637 00000078 00000000 0054d381 00000000 00004ca0 00000000 00000000 032f8e48 00000000 00000000 I still see dst overflows. But the priority of the ksoftird's can now control the user apps behavior even during softirq DoS. --5cX1WWKSdC Content-Type: application/octet-stream Content-Disposition: attachment; filename="softirq_limit-040405.pat" Content-Transfer-Encoding: base64 LS0tIGtlcm5lbC9zb2Z0aXJxLmMub3JpZwkyMDA0LTAzLTExIDAzOjU1OjI0LjAwMDAwMDAwMCAr MDEwMAorKysga2VybmVsL3NvZnRpcnEuYwkyMDA0LTA0LTA1IDEyOjUyOjQwLjAwMDAwMDAwMCAr MDIwMApAQCAtNTgsNiArNTgsMTQgQEAKIAkJd2FrZV91cF9wcm9jZXNzKHRzayk7CiB9CiAKK3N0 YXRpYyBpbmxpbmUgaW50IGNhbl9ydW5fa3NvZnRpcnFkKHZvaWQpCit7CisgICAgICAgLyogSW50 ZXJydXB0cyBhcmUgZGlzYWJsZWQ6IG5vIG5lZWQgdG8gc3RvcCBwcmVlbXB0aW9uICovCisgICAg ICAgc3RydWN0IHRhc2tfc3RydWN0ICp0c2sgPSBfX2dldF9jcHVfdmFyKGtzb2Z0aXJxZCk7CisK KyAgICAgICByZXR1cm4gdHNrICYmICEodHNrLT5zdGF0ZSAmICAoVEFTS19ERUFEIHwgVEFTS19a T01CSUUpKTsKK30KKwogLyoKICAqIFdlIHJlc3RhcnQgc29mdGlycSBwcm9jZXNzaW5nIE1BWF9T T0ZUSVJRX1JFU1RBUlQgdGltZXMsCiAgKiBhbmQgd2UgZmFsbCBiYWNrIHRvIHNvZnRpcnFkIGFm dGVyIHRoYXQuCkBAIC02OSw3ICs3Nyw3IEBACiAgKi8KICNkZWZpbmUgTUFYX1NPRlRJUlFfUkVT VEFSVCAxMAogCi1hc21saW5rYWdlIHZvaWQgZG9fc29mdGlycSh2b2lkKQorYXNtbGlua2FnZSB2 b2lkIF9fZG9fc29mdGlycShpbnQgZnJvbV9rc29mdGlycWQpCiB7CiAJaW50IG1heF9yZXN0YXJ0 ID0gTUFYX1NPRlRJUlFfUkVTVEFSVDsKIAlfX3UzMiBwZW5kaW5nOwpAQCAtODYsNiArOTQsOSBA QAogCQlzdHJ1Y3Qgc29mdGlycV9hY3Rpb24gKmg7CiAKIAkJbG9jYWxfYmhfZGlzYWJsZSgpOwor CisJCWlmIChmcm9tX2tzb2Z0aXJxZCAmJiBjYW5fcnVuX2tzb2Z0aXJxZCgpKQorCQkJICAgICBn b3RvIGRvbmU7CiByZXN0YXJ0OgogCQkvKiBSZXNldCB0aGUgcGVuZGluZyBiaXRtYXNrIGJlZm9y ZSBlbmFibGluZyBpcnFzICovCiAJCWxvY2FsX3NvZnRpcnFfcGVuZGluZygpID0gMDsKQEAgLTEw Niw2ICsxMTcsNyBAQAogCQlwZW5kaW5nID0gbG9jYWxfc29mdGlycV9wZW5kaW5nKCk7CiAJCWlm IChwZW5kaW5nICYmIC0tbWF4X3Jlc3RhcnQpCiAJCQlnb3RvIHJlc3RhcnQ7Citkb25lOgogCQlp ZiAocGVuZGluZykKIAkJCXdha2V1cF9zb2Z0aXJxZCgpOwogCQlfX2xvY2FsX2JoX2VuYWJsZSgp OwpAQCAtMTE0LDYgKzEyNiwxMSBAQAogCWxvY2FsX2lycV9yZXN0b3JlKGZsYWdzKTsKIH0KIAor YXNtbGlua2FnZSB2b2lkIGRvX3NvZnRpcnEodm9pZCkgCit7CisJX19kb19zb2Z0aXJxKDApOwkK K30KKwogRVhQT1JUX1NZTUJPTChkb19zb2Z0aXJxKTsKIAogdm9pZCBsb2NhbF9iaF9lbmFibGUo dm9pZCkKQEAgLTMyNCw3ICszNDEsNyBAQAogCQlfX3NldF9jdXJyZW50X3N0YXRlKFRBU0tfUlVO TklORyk7CiAKIAkJd2hpbGUgKGxvY2FsX3NvZnRpcnFfcGVuZGluZygpKSB7Ci0JCQlkb19zb2Z0 aXJxKCk7CisJCQlfX2RvX3NvZnRpcnEoMSk7CQogCQkJY29uZF9yZXNjaGVkKCk7CiAJCX0KIAo= --5cX1WWKSdC Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Cheers. --ro --5cX1WWKSdC-- From hadi@cyberus.ca Tue Apr 6 07:19:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 07:19:24 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36EJ5KO032014 for ; Tue, 6 Apr 2004 07:19:06 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BArQB-0001l6-Qn for netdev@oss.sgi.com; Tue, 06 Apr 2004 10:19:23 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BArPl-0005KJ-OE; Tue, 06 Apr 2004 10:18:57 -0400 Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling From: jamal Reply-To: hadi@cyberus.ca To: Jason Lunz Cc: netdev@oss.sgi.com, Luca Deri , Robert Olsson In-Reply-To: References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081261126.1047.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2004 10:18:46 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4509 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1628 Lines: 39 On Mon, 2004-04-05 at 12:03, Jason Lunz wrote: > Yes, I read the paper (but not his code). What stood out to me is that > the description of his custom socket implementation matches exactly what > packet-mmap already is. The problem is when you first glance at the paper you think its something new. So that piece is a little misleading. > I noticed he only mentioned testing of libpcap-mmap, but did not use > mmap packet sockets directly -- maybe there's something about libpcap > that limits performance? I haven't looked. More than likely turbo packet was used from some of Alexeys old patches- now obsoleted > What I can say for sure is that the napi + packet-mmap performance with > many small packets is almost surely limited by problems with irq/softirq > load. There was an excellent thread last week about this with Andrea > Arcangeli, Robert Olsson and others about the balancing of softirq and > userspace load; they eventually were beginning to agree that running > softirqs on return from hardirq and bh was a bigger load than expected > when there was lots of napi work to do. So despite NAPI, too much kernel > time is spent handling (soft)irq load with many small packets. I didnt follow that discussion; archived for later entertaining reading. My take on it was it is 2.6.x related and in particular the misbehavior observed has to do with use of rcu in the route cache. > It appears this problem became worse in 2.6 with HZ=1000, because now > the napi rx softirq work is being done 10X as much on return from the > timer interrupt. I'm not sure if a solution was reached. Robert? cheers, jamal From klaus@rechert.de Tue Apr 6 07:23:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 07:23:09 -0700 (PDT) Received: from mail.pyramid.de (mail.pyramid.de [213.164.67.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36EN4KO032403 for ; Tue, 6 Apr 2004 07:23:05 -0700 Received: from [192.168.0.14] (helo=exch02.intern.pyramid.de) by mail.pyramid.de with esmtp (Exim 4.22) id 1BArTi-0008Vp-4d for netdev@oss.sgi.com; Tue, 06 Apr 2004 16:23:02 +0200 Received: from rechert.de ([192.168.9.21]) by exch02.intern.pyramid.de with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Apr 2004 16:23:02 +0200 Message-ID: <4072BD45.6050907@rechert.de> Date: Tue, 06 Apr 2004 16:23:01 +0200 From: Klaus Rechert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040119 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: 8139too problems Content-Type: multipart/mixed; boundary="------------080706000502090501090600" X-OriginalArrivalTime: 06 Apr 2004 14:23:02.0201 (UTC) FILETIME=[AB32D290:01C41BE2] X-Scan-Signature: c1aeffcbefa68e69990b35ab4369a76e X-archive-position: 4510 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: klaus@rechert.de Precedence: bulk X-list: netdev Content-Length: 5750 Lines: 123 This is a multi-part message in MIME format. --------------080706000502090501090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, i have problems with my 8139c card on a toshiba tecra 8000 since linux-2.6. lspci -vvv attached. Call Trace: [] kobject_register+0x5b/0x60 [] bus_add_driver+0x4a/0xb0 [] driver_register+0x2f/0x40 [] pci_register_driver+0x5c/0x90 [] rtl8139_init_module+0x1b/0x27 [8139too] [] sys_init_module+0x119/0x230 [] syscall_call+0x7/0xb Cheers Klaus --------------080706000502090501090600 Content-Type: text/plain; name="lspci" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="lspci" 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- 00:05.0 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 05) Subsystem: Toshiba America Info Systems: Unknown device 0001 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 05:00.0 Ethernet controller: Abocom Systems Inc RTL8139 [FE2000VX] CardBus Fast Ethernet Attached Port Adapter (rev 10) Subsystem: Abocom Systems Inc RTL8139 [FE2000VX] CardBus Fast Ethernet Attached Port Adapter Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- --------------080706000502090501090600-- From Robert.Olsson@data.slu.se Tue Apr 6 08:31:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 08:31:34 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36FVUKO006033 for ; Tue, 6 Apr 2004 08:31:31 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i36FVJNv015504; Tue, 6 Apr 2004 17:31:20 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id BA275903D5; Tue, 6 Apr 2004 17:31:19 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16498.52551.712261.214192@robur.slu.se> Date: Tue, 6 Apr 2004 17:31:19 +0200 To: hadi@cyberus.ca Cc: Jason Lunz , netdev@oss.sgi.com, Luca Deri , Robert Olsson Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling In-Reply-To: <1081261126.1047.6.camel@jzny.localdomain> References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <1081261126.1047.6.camel@jzny.localdomain> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4512 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1499 Lines: 36 jamal writes: > I didnt follow that discussion; archived for later entertaining reading. > My take on it was it is 2.6.x related and in particular the misbehavior > observed has to do with use of rcu in the route cache. > > > It appears this problem became worse in 2.6 with HZ=1000, because now > > the napi rx softirq work is being done 10X as much on return from the > > timer interrupt. I'm not sure if a solution was reached. > > Robert? Well it's a general problem controlling softirq/user and the RCU locking put this on our agenda as the dst hash was among the first applications to use the RCU locking. Which in turn had problem doing progress in hard softirq environment which happens during route cache DoS. NAPI is a part of RX_SOFTIRQ which is well-behaved. NAPI addresses only irq/sofirq problem and is totally innocent for do_sofirq() run from other parts of kernel causing userland starvation. Under normal hi-load conditions RX_SOFTIRQ schedules itself when the netdev_max_backlog is done. do_softirq sees this and defers execution to ksoftirqd and things get under (scheduler) control. During route DoS, code that does a lot do_softirq() is run for hash and fib-lookup, GC etc. The effect is that ksoftirqd is more or less bypassed. Again it's a general problem... We are just the unlucky guys getting into this. I don't know if packet capture tests done by Luca ran into this problems. A profile could have helped... Cheers. --ro From jgarzik@pobox.com Tue Apr 6 08:30:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 08:30:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36FUNKO005857 for ; Tue, 6 Apr 2004 08:30:26 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BAsWs-0007n3-8o; Tue, 06 Apr 2004 16:30:22 +0100 Message-ID: <4072CD01.6070408@pobox.com> Date: Tue, 06 Apr 2004 11:30:09 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev CC: Linux Kernel , Andrew Morton Subject: [NET] net driver updates Content-Type: multipart/mixed; boundary="------------080600040902090101010001" X-archive-position: 4511 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: 4579 Lines: 131 This is a multi-part message in MIME format. --------------080600040902090101010001 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit With upstream 2.6.x having been frozen for a while (and will be until end of week or so), a bunch of net driver updates have accumulated. Even though the shortlog output is attached, here's an even shorter summary: * acenic converted to PCI API (yay!). Please test. * new 10gige driver, s2io * Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor fixes and cleanups * 8139cp, pcnet32 updates * other minor stuff BK repository: http://gkernel.bkbits.net/netdev-2.6 Patch: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.5-netdev2.patch.bz2 --------------080600040902090101010001 Content-Type: text/plain; name="changelog.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="changelog.txt" Andrew Morton: o s2io.h: gcc-3.5 build fix Christoph Hellwig: o convert acenic to pci_driver API o kill acient compat cruft from acenic Daniel Ritz: o netdev_priv for xirc2ps_cs, nmclan_cs Domen Puncer: o lmc header file not needed Don Fry: o pcnet32 add led blink capability o pcnet32 correct name display o pcnet32 all printk under netif_msg o pcnet32.c add support for 79C976 François Romieu: o [netdrvr r8169] TX irq handler looping fix o [netdrvr r8169] DAC changes o [netdrvr r8169] Barrier against compiler optimization o [netdrvr r8169] ethtool driver info o [netdrvr r8169] DMA api resync o [netdrvr sis190] more RX path work o [netdrvr sis190] don't use one huge buffer for all RX skb's o [netdrvr sis190] add dirty_rx to private structure o [netdrvr sis190] separate out RX skb alloc, fill o [netdrvr sis190] add helpers o [netdrvr sis190] sis190_open() fixes/updates o [netdrvr sis190] add pci-disable-device o [netdrvr sis190] fix endianness issues o [netdrvr epic100] napi fixes o [netdrvr epic100] napi 3/3 - transmit path o [netdrvr epic100] napi 2/3 - receive path o [netdrvr epic100] napi 1/3 - just shuffle some code around o [netdrvr epic100] minor cleanups o [netdrvr r8169] Rx wrap bug o [netdrvr r8169] fix TX race o [netdrvr r8169] fix phy initialization loop init o [netdrvr r8169] fix rx counter masking bug o [netdrvr r8169] fix oops by removing __devinitdata marker o 2.6.1-rc1-mm1 - typo of death in the r8169 driver o [netdrvr r8169] Stats fix (Fernando Alencar Marótica ) o [netdrvr r8169] Endianness update (original idea from Alexandra N. Kossovsky) o [netdrvr r8169] fix RX o [netdrvr r8169] Suspend/resume code (Fernando Alencar Marótica) o [netdrvr r8169] Modification of the interrupt mask (RealTek) o [netdrvr r8169] Driver forgot to update the transmitted bytes counter o [netdrvr r8169] Merge of changes from Realtek o [netdrvr r8169] Merge of timer related changes from Realtek o [netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one() o [netdrvr r8169] Add {mac/phy}_version o [netdrvr r8169] Rx copybreak for small packets o [netdrvr r8169] Conversion of Tx data buffers to PCI DMA o [netdrvr r8169] rtl8169_start_xmit fixes o [netdrvr r8169] Conversion of Rx data buffers to PCI DMA o [netdrvr r8169] Conversion of Rx/Tx descriptors to consistent DMA Hirofumi Ogawa: o 8139too: more useful debug info for tx_timeout Jeff Garzik: o [netdrvr natsemi] correct DP83816 IntrHoldoff register offset o [netdrvr 8139cp] better dev->close() handling, and misc related stuff o [netdrvr 8139cp] complete 64-bit DMA (PCI DAC) support o [netdrvr 8139cp] use netdev_priv() o [netdrvr 8139cp] minor cleanups o [NET] define HAVE_NETDEV_PRIV back-compat hook o [netdrvr 8139cp] locking cleanups o [netdrvr s2io] NAPI build fixes o [netdrvr 8139cp] rearrange priv struct, add cacheline-align markers o [net/fc iph5526] s/rx_dropped/tx_dropped/ in TX routines o [netdrvr s2io] correct an incorrect cleanup I made o [netdrvr] Add S2IO 10gige network driver o Remove unused compatibility-defines include wan/lmc/lmc_ver.h o Manually merge with upstream Jeff Muizelaar: o tc35815 cleanup Leana Ogasawara: o dgrs: add missing iounmaps Luiz Fernando N. Capitulino: o com20020-isa.c warning fix Pavel Machek: o Support newer revisions of broadcoms in b44.c Randy Dunlap: o remove magic '31' for netdev priv. alignment Scott Feldman: o Update MAINTAINERS with new e100/e1000/ixgb maintainers --------------080600040902090101010001-- From linux-netdev@gmane.org Tue Apr 6 09:01:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 09:01:29 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36G1OKO007650 for ; Tue, 6 Apr 2004 09:01:26 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BAt0u-00020w-00 for ; Tue, 06 Apr 2004 18:01:24 +0200 Received: from finn.gmane.org ([80.91.224.251]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Apr 2004 18:01:23 +0200 Received: from lunz by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Apr 2004 18:01:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Jason Lunz Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling Date: Tue, 6 Apr 2004 16:01:20 +0000 (UTC) Organization: PBR Streetgang Message-ID: References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> <4072A1CD.8070905@ntop.org> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: slrn/0.9.8.0 (Linux) X-archive-position: 4513 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: lunz@falooley.org Precedence: bulk X-list: netdev Content-Length: 2257 Lines: 51 deri@ntop.org said: > In addition if you do care about performance, I believe you're willing > to turn off packet transmission and only do packet receive. I don't understand what you mean by this. packet-mmap works perfectly well on an UP|PROMISC interface with no addresses bound to it. As long as no packets are injected through a packet socket, the tx path never gets involved. > IRQ: Linux has far too much latency, in particular at high speeds. I'm > not the right person who can say "this is the way to go", however I > believe that we need some sort of interrupt prioritization like RTIRQ > does. I don't think this is the problem, since small-packet performance is bad even with a fully-polling e1000 in NAPI mode. As Robert Olsson has demonstrated, a highly-loaded napi e1000 only generates a few hundred interrupts per second. So the vast majority of packets recieved are coming in without a hardware interrupt occurring at all. Could it be that each time an hw irq _is_ generated, it causes many packets to be lost? That's a possibility. Can you explain in more detail how you measured the effect of interrupt latency on recieve efficiency? > Finally It would be nice to have in the standard Linux core some > packet capture improvements. It could either be based on my work or on > somebody else's work. It doesn't really matter as long as Linux gets > faster. I agree. I think a good place to start would be reading and understanding this thread: http://thread.gmane.org/gmane.linux.kernel/193758 There's some disagreement for a while about where all this softirq load is coming from. It looks like an interaction of softirqs and RCU, but the first patch doesn't help. Finally Olsson pointed out: http://article.gmane.org/gmane.linux.kernel/194412 that the majority of softirq's are being run from hardirq exit. Even with NAPI. At this point, I think, it's clear that the problem exists regardless of rcu, and indeed, Linux is bad at doing packet-mmap RX of a small-packet gigabit flood on both 2.4 and 2.6 (my old 2.4 measurements earlier in this thread show this). I'm particularly interested in trying Andrea's suggestion from http://article.gmane.org/gmane.linux.kernel/194486 , but I won't have the time anytime soon. Jason From ak@suse.de Tue Apr 6 09:29:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 09:29:54 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36GTlKO009059 for ; Tue, 6 Apr 2004 09:29:48 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id E28FC3FDE48 for ; Tue, 6 Apr 2004 18:29:41 +0200 (CEST) Date: Tue, 6 Apr 2004 18:29:41 +0200 From: Andi Kleen To: netdev@oss.sgi.com Subject: [PATCH] New version of net timestamp optimization Message-Id: <20040406182941.7e759f4c.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4514 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 17222 Lines: 533 New version of the network packet timestamp optimization. Avoid calling gettimeofday in the network fast path when not needed. This version addresses the proxy ARP problems pointed out by Ville. I ended with just using a magic value (-2) to mark these packets instead of 0. Otherwise no changes. Testing/Feedback/Benchmark results appreciated. -Andi diff -u linux-2.6.5rc3-averell/include/net/sock.h-T linux-2.6.5rc3-averell/include/net/sock.h --- linux-2.6.5rc3-averell/include/net/sock.h-T 2004-03-21 21:11:55.000000000 +0100 +++ linux-2.6.5rc3-averell/include/net/sock.h 2004-03-31 09:44:02.000000000 +0200 @@ -382,6 +382,7 @@ SOCK_LINGER, SOCK_DESTROY, SOCK_BROADCAST, + SOCK_TIMESTAMP, }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) @@ -1023,11 +1024,33 @@ static __inline__ void sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb) { - if (sk->sk_rcvtstamp) - put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(skb->stamp), &skb->stamp); - else - sk->sk_stamp = skb->stamp; -} + struct timeval *stamp = &skb->stamp; + if (sk->sk_rcvtstamp) { + /* Race occurred between timestamp enabling and packet + receiving. Fill in the current time for now. */ + if (stamp->tv_sec == 0) + do_gettimeofday(stamp); + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(struct timeval), + stamp); + } else + sk->sk_stamp = *stamp; +} + +extern atomic_t netstamp_needed; +extern void sock_enable_timestamp(struct sock *sk); +extern void sock_disable_timestamp(struct sock *sk); + +static inline void net_timestamp(struct timeval *stamp) +{ + if (atomic_read(&netstamp_needed)) + do_gettimeofday(stamp); + else { + stamp->tv_sec = 0; + stamp->tv_usec = 0; + } +} + +extern int sock_get_timestamp(struct sock *, struct timeval *); /* * Enable debug/info messages diff -u linux-2.6.5rc3-averell/include/net/neighbour.h-T linux-2.6.5rc3-averell/include/net/neighbour.h --- linux-2.6.5rc3-averell/include/net/neighbour.h-T 2004-03-21 21:11:55.000000000 +0100 +++ linux-2.6.5rc3-averell/include/net/neighbour.h 2004-04-01 23:50:41.000000000 +0200 @@ -281,6 +281,8 @@ return neigh_create(tbl, pkey, dev); } +#define LOCALLY_ENQUEUED -2 + #endif #endif diff -u linux-2.6.5rc3-averell/net/core/sock.c-T linux-2.6.5rc3-averell/net/core/sock.c --- linux-2.6.5rc3-averell/net/core/sock.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/sock.c 2004-03-31 13:45:57.000000000 +0200 @@ -328,6 +328,8 @@ case SO_TIMESTAMP: sk->sk_rcvtstamp = valbool; + if (valbool) + sock_enable_timestamp(sk); break; case SO_RCVLOWAT: @@ -642,6 +644,8 @@ sk->sk_filter = NULL; } + sock_disable_timestamp(sk); + if (atomic_read(&sk->sk_omem_alloc)) printk(KERN_DEBUG "%s: optmem leakage (%d bytes) detected.\n", __FUNCTION__, atomic_read(&sk->sk_omem_alloc)); @@ -1135,6 +1139,9 @@ sk->sk_sndtimeo = MAX_SCHEDULE_TIMEOUT; sk->sk_owner = NULL; + sk->sk_stamp.tv_sec = -1L; + sk->sk_stamp.tv_usec = -1L; + atomic_set(&sk->sk_refcnt, 1); } @@ -1160,9 +1167,42 @@ wake_up(&(sk->sk_lock.wq)); spin_unlock_bh(&(sk->sk_lock.slock)); } - EXPORT_SYMBOL(release_sock); +/* When > 0 there are consumers of rx skb time stamps */ +atomic_t netstamp_needed = ATOMIC_INIT(0); + +int sock_get_timestamp(struct sock *sk, struct timeval *userstamp) +{ + if (!sock_flag(sk, SOCK_TIMESTAMP)) + sock_enable_timestamp(sk); + if (sk->sk_stamp.tv_sec == -1) + return -ENOENT; + if (sk->sk_stamp.tv_sec == 0) + do_gettimeofday(&sk->sk_stamp); + return copy_to_user(userstamp, &sk->sk_stamp, sizeof(struct timeval)) ? + -EFAULT : 0; +} +EXPORT_SYMBOL(sock_get_timestamp); + +void sock_enable_timestamp(struct sock *sk) +{ + if (!sock_flag(sk, SOCK_TIMESTAMP)) { + sock_set_flag(sk, SOCK_TIMESTAMP); + atomic_inc(&netstamp_needed); + } +} +EXPORT_SYMBOL(sock_enable_timestamp); + +void sock_disable_timestamp(struct sock *sk) +{ + if (sock_flag(sk, SOCK_TIMESTAMP)) { + sock_reset_flag(sk, SOCK_TIMESTAMP); + atomic_dec(&netstamp_needed); + } +} +EXPORT_SYMBOL(sock_disable_timestamp); + EXPORT_SYMBOL(__lock_sock); EXPORT_SYMBOL(__release_sock); EXPORT_SYMBOL(sk_alloc); diff -u linux-2.6.5rc3-averell/net/core/dev.c-T linux-2.6.5rc3-averell/net/core/dev.c --- linux-2.6.5rc3-averell/net/core/dev.c-T 2004-03-22 01:28:39.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/dev.c 2004-03-31 09:44:02.000000000 +0200 @@ -1125,7 +1125,7 @@ void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev) { struct packet_type *ptype; - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); rcu_read_lock(); list_for_each_entry_rcu(ptype, &ptype_all, list) { @@ -1546,9 +1546,9 @@ return NET_RX_DROP; } #endif - + if (!skb->stamp.tv_sec) - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); /* * The code is rearranged so that the path is the most @@ -1710,7 +1710,7 @@ #endif if (!skb->stamp.tv_sec) - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); skb_bond(skb); diff -u linux-2.6.5rc3-averell/net/core/neighbour.c-T linux-2.6.5rc3-averell/net/core/neighbour.c --- linux-2.6.5rc3-averell/net/core/neighbour.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/neighbour.c 2004-04-01 23:49:23.000000000 +0200 @@ -1094,7 +1094,7 @@ kfree_skb(skb); return; } - skb->stamp.tv_sec = 0; + skb->stamp.tv_sec = LOCALLY_ENQUEUED; skb->stamp.tv_usec = now + sched_next; spin_lock(&tbl->proxy_queue.lock); diff -u linux-2.6.5rc3-averell/net/ipv4/af_inet.c-T linux-2.6.5rc3-averell/net/ipv4/af_inet.c --- linux-2.6.5rc3-averell/net/ipv4/af_inet.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv4/af_inet.c 2004-03-31 09:44:02.000000000 +0200 @@ -843,11 +843,7 @@ switch (cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - err = -ENOENT; - else if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - err = -EFAULT; + err = sock_get_timestamp(sk, (struct timeval *)arg); break; case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/ipv4/arp.c-T linux-2.6.5rc3-averell/net/ipv4/arp.c --- linux-2.6.5rc3-averell/net/ipv4/arp.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv4/arp.c 2004-04-01 23:49:08.000000000 +0200 @@ -860,7 +860,7 @@ if (n) neigh_release(n); - if (skb->stamp.tv_sec == 0 || + if (skb->stamp.tv_sec == LOCALLY_ENQUEUED || skb->pkt_type == PACKET_HOST || in_dev->arp_parms->proxy_delay == 0) { arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); diff -u linux-2.6.5rc3-averell/net/sunrpc/svcsock.c-T linux-2.6.5rc3-averell/net/sunrpc/svcsock.c --- linux-2.6.5rc3-averell/net/sunrpc/svcsock.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/sunrpc/svcsock.c 2004-03-31 09:44:02.000000000 +0200 @@ -591,6 +591,12 @@ /* possibly an icmp error */ dprintk("svc: recvfrom returned error %d\n", -err); } + if (skb->stamp.tv_sec == 0) { + skb->stamp.tv_sec = xtime.tv_sec; + skb->stamp.tv_usec = xtime.tv_nsec * 1000; + /* Don't enable netstamp, sunrpc doesn't + need that much accuracy */ + } svsk->sk_sk->sk_stamp = skb->stamp; set_bit(SK_DATA, &svsk->sk_flags); /* there may be more data... */ diff -u linux-2.6.5rc3-averell/net/rose/af_rose.c-T linux-2.6.5rc3-averell/net/rose/af_rose.c --- linux-2.6.5rc3-averell/net/rose/af_rose.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/rose/af_rose.c 2004-03-31 09:44:02.000000000 +0200 @@ -1269,12 +1269,8 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - return copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; - } + if (sk != NULL) + return sock_get_timestamp(sk, (struct timeval *)arg); return -EINVAL; case SIOCGIFADDR: diff -u linux-2.6.5rc3-averell/net/irda/af_irda.c-T linux-2.6.5rc3-averell/net/irda/af_irda.c --- linux-2.6.5rc3-averell/net/irda/af_irda.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/irda/af_irda.c 2004-03-31 09:44:02.000000000 +0200 @@ -1796,14 +1796,8 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - return -EFAULT; - return 0; - } + if (sk != NULL) + return sock_get_timestamp(sk, (struct timeval *)arg); return -EINVAL; case SIOCGIFADDR: diff -u linux-2.6.5rc3-averell/net/ipx/af_ipx.c-T linux-2.6.5rc3-averell/net/ipx/af_ipx.c --- linux-2.6.5rc3-averell/net/ipx/af_ipx.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipx/af_ipx.c 2004-03-31 09:44:02.000000000 +0200 @@ -1797,7 +1797,8 @@ copied); if (rc) goto out_free; - sk->sk_stamp = skb->stamp; + if (skb->stamp.tv_sec) + sk->sk_stamp = skb->stamp; msg->msg_namelen = sizeof(*sipx); @@ -1870,15 +1871,8 @@ break; case SIOCGSTAMP: rc = -EINVAL; - if (sk) { - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = -EFAULT; - if (!copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - rc = 0; - } + if (sk) + rc = sock_get_timestamp(sk, (struct timeval *)arg); break; case SIOCGIFDSTADDR: case SIOCSIFDSTADDR: diff -u linux-2.6.5rc3-averell/net/atm/ioctl.c-T linux-2.6.5rc3-averell/net/atm/ioctl.c --- linux-2.6.5rc3-averell/net/atm/ioctl.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/atm/ioctl.c 2004-03-31 09:44:02.000000000 +0200 @@ -76,12 +76,8 @@ goto done; } case SIOCGSTAMP: /* borrowed from IP */ - if (!vcc->sk->sk_stamp.tv_sec) { - error = -ENOENT; - goto done; - } - error = copy_to_user((void *)arg, &vcc->sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + error = sock_get_timestamp(vcc->sk, (struct timeval *) + arg); goto done; case ATM_SETSC: printk(KERN_WARNING "ATM_SETSC is obsolete\n"); diff -u linux-2.6.5rc3-averell/net/ax25/af_ax25.c-T linux-2.6.5rc3-averell/net/ax25/af_ax25.c --- linux-2.6.5rc3-averell/net/ax25/af_ax25.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ax25/af_ax25.c 2004-03-31 09:44:02.000000000 +0200 @@ -1694,12 +1694,7 @@ case SIOCGSTAMP: if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) { - res = -ENOENT; - break; - } - res = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + res = sock_get_timestamp(sk, (struct timeval *)arg); break; } res = -EINVAL; diff -u linux-2.6.5rc3-averell/net/ipv6/af_inet6.c-T linux-2.6.5rc3-averell/net/ipv6/af_inet6.c --- linux-2.6.5rc3-averell/net/ipv6/af_inet6.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv6/af_inet6.c 2004-03-31 09:44:02.000000000 +0200 @@ -474,13 +474,7 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - err = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)); - if (err) - return -EFAULT; - return 0; + return sock_get_timestamp(sk, (struct timeval *)arg); case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/ipv6/ndisc.c-T linux-2.6.5rc3-averell/net/ipv6/ndisc.c --- linux-2.6.5rc3-averell/net/ipv6/ndisc.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv6/ndisc.c 2004-04-01 23:50:23.000000000 +0200 @@ -761,7 +761,7 @@ if (ipv6_chk_acast_addr(dev, &msg->target) || (idev->cnf.forwarding && pneigh_lookup(&nd_tbl, &msg->target, dev, 0))) { - if (skb->stamp.tv_sec != 0 && + if (skb->stamp.tv_sec != LOCALLY_ENQUEUED && skb->pkt_type != PACKET_HOST && inc != 0 && idev->nd_parms->proxy_delay != 0) { diff -u linux-2.6.5rc3-averell/net/rxrpc/transport.c-T linux-2.6.5rc3-averell/net/rxrpc/transport.c --- linux-2.6.5rc3-averell/net/rxrpc/transport.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/rxrpc/transport.c 2004-03-31 09:44:02.000000000 +0200 @@ -341,6 +341,11 @@ msg->trans = trans; msg->state = RXRPC_MSG_RECEIVED; msg->stamp = pkt->stamp; + if (msg->stamp.tv_sec == 0) { + do_gettimeofday(&msg->stamp); + if (skb->sk) + sock_enable_netstamp(skb->sk); + } msg->seq = ntohl(msg->hdr.seq); /* attach the packet */ diff -u linux-2.6.5rc3-averell/net/sctp/input.c-T linux-2.6.5rc3-averell/net/sctp/input.c --- linux-2.6.5rc3-averell/net/sctp/input.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/sctp/input.c 2004-03-31 09:44:02.000000000 +0200 @@ -175,6 +175,12 @@ rcvr = asoc ? &asoc->base : &ep->base; sk = rcvr->sk; + /* SCTP seems to always need a timestamp right now (FIXME) */ + if (skb->stamp.tv_sec == 0) { + do_gettimeofday(&skb->stamp); + sock_enable_timestamp(sk); + } + if (!xfrm_policy_check(sk, XFRM_POLICY_IN, skb, family)) goto discard_release; diff -u linux-2.6.5rc3-averell/net/x25/af_x25.c-T linux-2.6.5rc3-averell/net/x25/af_x25.c --- linux-2.6.5rc3-averell/net/x25/af_x25.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/x25/af_x25.c 2004-03-31 09:44:02.000000000 +0200 @@ -1206,14 +1206,10 @@ } case SIOCGSTAMP: - if (sk) { - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; - } rc = -EINVAL; + if (sk) + rc = sock_get_timestamp(sk, + (struct timeval *)arg); break; case SIOCGIFADDR: case SIOCSIFADDR: diff -u linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c-T linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c --- linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c 2004-03-31 09:44:02.000000000 +0200 @@ -1765,13 +1765,7 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - err = -EFAULT; - if (!copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - err = 0; - return err; + return sock_get_timestamp(sk, (struct timeval *)arg); case SIOC_WANPIPE_CHECK_TX: diff -u linux-2.6.5rc3-averell/net/packet/af_packet.c-T linux-2.6.5rc3-averell/net/packet/af_packet.c --- linux-2.6.5rc3-averell/net/packet/af_packet.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/packet/af_packet.c 2004-03-31 09:44:02.000000000 +0200 @@ -606,6 +606,10 @@ h->tp_snaplen = snaplen; h->tp_mac = macoff; h->tp_net = netoff; + if (skb->stamp.tv_sec == 0) { + do_gettimeofday(&skb->stamp); + sock_enable_timestamp(sk); + } h->tp_sec = skb->stamp.tv_sec; h->tp_usec = skb->stamp.tv_usec; @@ -1442,13 +1446,8 @@ return put_user(amount, (int *)arg); } case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - return -EFAULT; - break; - + return sock_get_timestamp(sk, (struct timeval *)arg); + #ifdef CONFIG_INET case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/netrom/af_netrom.c-T linux-2.6.5rc3-averell/net/netrom/af_netrom.c --- linux-2.6.5rc3-averell/net/netrom/af_netrom.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/netrom/af_netrom.c 2004-03-31 09:44:02.000000000 +0200 @@ -1200,17 +1200,11 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) { - release_sock(sk); - return -ENOENT; - } - ret = copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0; - release_sock(sk); - return ret; - } + ret = -EINVAL; + if (sk != NULL) + ret = sock_get_timestamp(sk, (struct timeval *)arg); release_sock(sk); - return -EINVAL; + return ret; case SIOCGIFADDR: case SIOCSIFADDR: diff -u linux-2.6.5rc3-averell/net/appletalk/ddp.c-T linux-2.6.5rc3-averell/net/appletalk/ddp.c --- linux-2.6.5rc3-averell/net/appletalk/ddp.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/appletalk/ddp.c 2004-03-31 09:44:02.000000000 +0200 @@ -1795,13 +1795,7 @@ break; } case SIOCGSTAMP: - if (!sk) - break; - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + rc = sock_get_timestamp(sk, (struct timeval *)arg); break; /* Routing */ case SIOCADDRT: diff -u linux-2.6.5rc3-averell/net/econet/af_econet.c-T linux-2.6.5rc3-averell/net/econet/af_econet.c --- linux-2.6.5rc3-averell/net/econet/af_econet.c-T 2004-03-21 21:12:01.000000000 +0100 +++ linux-2.6.5rc3-averell/net/econet/af_econet.c 2004-03-31 09:44:02.000000000 +0200 @@ -665,10 +665,8 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - return copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + return sock_get_timestamp(sk,(struct timeval *)arg); + case SIOCSIFADDR: case SIOCGIFADDR: return ec_dev_ioctl(sock, cmd, (void *)arg); From sri@us.ibm.com Tue Apr 6 10:29:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 10:29:19 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36HT3KO011740 for ; Tue, 6 Apr 2004 10:29:13 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i36HSa1v482098; Tue, 6 Apr 2004 13:28:37 -0400 Received: from w-sridhar.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i36HSYpD372214; Tue, 6 Apr 2004 11:28:35 -0600 Date: Tue, 6 Apr 2004 10:28:36 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [BK PATCH] 2.6 SCTP updates. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4515 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 25249 Lines: 809 Hi Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work to get the following updates to SCTP on top of linux 2.6.5 Thanks Sridhar # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/04/06 07:32:30-07:00 sri@us.ibm.com # [SCTP] Use id to ptr translation service in lib/idr.c to assign and # validate ids of associations. # # This patch avoids the use of virt_addr_valid() to validate the address # of associations passed by the user. Currently the address of an # association is used as its id. virt_addr_valid doesn't work as # expected when PAGEALLOC debugging is enabled. # # net/sctp/socket.c # net/sctp/sm_make_chunk.c # net/sctp/protocol.c # net/sctp/associola.c # include/net/sctp/structs.h # include/net/sctp/sctp.h # ChangeSet # 2004/04/06 07:24:04-07:00 sri@us.ibm.com # [SCTP] Update sctp_ulpevent structure to include assoc pointer and # only the receive specific fields of sctp_sndrcvinfo. # # net/sctp/ulpqueue.c # net/sctp/ulpevent.c # net/sctp/socket.c # net/sctp/protocol.c # net/sctp/ipv6.c # include/net/sctp/ulpevent.h # # ChangeSet # 2004/04/06 00:28:31-07:00 sri@us.ibm.com # [SCTP] Fix typo in entry name of the remove_proc_entry() call. # # net/sctp/objcnt.c # diff -Nru a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h --- a/include/net/sctp/sctp.h Tue Apr 6 07:35:28 2004 +++ b/include/net/sctp/sctp.h Tue Apr 6 07:35:28 2004 @@ -1,5 +1,5 @@ /* SCTP kernel reference Implementation - * (C) Copyright IBM Corp. 2001, 2003 + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. * Copyright (c) 2001-2003 Intel Corp. @@ -78,6 +78,7 @@ #include #include #include +#include #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE) #include @@ -223,24 +224,6 @@ #define SCTP_INC_STATS_USER(field) SNMP_INC_STATS_USER(sctp_statistics, field) #define SCTP_DEC_STATS(field) SNMP_DEC_STATS(sctp_statistics, field) -/* Determine if this is a valid kernel address. */ -static inline int sctp_is_valid_kaddr(unsigned long addr) -{ - struct page *page; - - /* Make sure the address is not in the user address space. */ - if (addr < PAGE_OFFSET) - return 0; - - page = virt_to_page(addr); - - /* Is this page valid? */ - if (!virt_addr_valid(addr) || PageReserved(page)) - return 0; - - return 1; -} - #endif /* !TEST_FRAME */ @@ -357,7 +340,7 @@ /* Map an association to an assoc_id. */ static inline sctp_assoc_t sctp_assoc2id(const struct sctp_association *asoc) { - return (sctp_assoc_t) asoc; + return (asoc?asoc->assoc_id:NULL); } /* Look up the association by its id. */ @@ -518,6 +501,9 @@ extern struct proto sctp_prot; extern struct proc_dir_entry *proc_net_sctp; void sctp_put_port(struct sock *sk); + +extern struct idr sctp_assocs_id; +extern spinlock_t sctp_assocs_id_lock; /* Static inline functions. */ diff -Nru a/include/net/sctp/structs.h b/include/net/sctp/structs.h --- a/include/net/sctp/structs.h Tue Apr 6 07:35:28 2004 +++ b/include/net/sctp/structs.h Tue Apr 6 07:35:28 2004 @@ -1,5 +1,5 @@ /* SCTP kernel reference Implementation - * (C) Copyright IBM Corp. 2001, 2003 + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. * Copyright (c) 2001 Intel Corp. @@ -1282,11 +1282,8 @@ /* Associations on the same socket. */ struct list_head asocs; - /* This is a signature that lets us know that this is a - * struct sctp_association data structure. Used for mapping an - * association id to an association. - */ - __u32 eyecatcher; + /* association id. */ + sctp_assoc_t assoc_id; /* This is our parent endpoint. */ struct sctp_endpoint *ep; diff -Nru a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h --- a/include/net/sctp/ulpevent.h Tue Apr 6 07:35:27 2004 +++ b/include/net/sctp/ulpevent.h Tue Apr 6 07:35:27 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -54,7 +54,13 @@ * growing this structure as it is at the maximum limit now. */ struct sctp_ulpevent { - struct sctp_sndrcvinfo sndrcvinfo; + struct sctp_association *asoc; + __u16 stream; + __u16 ssn; + __u16 flags; + __u32 ppid; + __u32 tsn; + __u32 cumtsn; int msg_flags; int iif; }; diff -Nru a/net/sctp/associola.c b/net/sctp/associola.c --- a/net/sctp/associola.c Tue Apr 6 07:35:27 2004 +++ b/net/sctp/associola.c Tue Apr 6 07:35:27 2004 @@ -1,5 +1,5 @@ /* SCTP kernel reference Implementation - * (C) Copyright IBM Corp. 2001, 2003 + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. * Copyright (c) 2001 Intel Corp. @@ -276,7 +276,7 @@ asoc->need_ecne = 0; - asoc->eyecatcher = SCTP_ASSOC_EYECATCHER; + asoc->assoc_id = (sctp_assoc_t)-1; /* Assume that peer would support both address types unless we are * told otherwise. @@ -360,8 +360,6 @@ sctp_transport_free(transport); } - asoc->eyecatcher = 0; - /* Free any cached ASCONF_ACK chunk. */ if (asoc->addip_last_asconf_ack) sctp_chunk_free(asoc->addip_last_asconf_ack); @@ -381,6 +379,12 @@ sctp_endpoint_put(asoc->ep); sock_put(asoc->base.sk); + if ((int)asoc->assoc_id != -1) { + spin_lock_bh(&sctp_assocs_id_lock); + idr_remove(&sctp_assocs_id, (int)asoc->assoc_id); + spin_unlock_bh(&sctp_assocs_id_lock); + } + if (asoc->base.malloced) { kfree(asoc); SCTP_DBG_OBJCNT_DEC(assoc); @@ -856,26 +860,6 @@ return transport; } -/* Is this a live association structure. */ -int sctp_assoc_valid(struct sock *sk, struct sctp_association *asoc) -{ - - /* First, verify that this is a kernel address. */ - if (!sctp_is_valid_kaddr((unsigned long) asoc)) - return 0; - - /* Verify that this _is_ an sctp_association - * data structure and if so, that the socket matches. - */ - if (SCTP_ASSOC_EYECATCHER != asoc->eyecatcher) - return 0; - if (asoc->base.sk != sk) - return 0; - - /* The association is valid. */ - return 1; -} - /* Do delayed input processing. This is scheduled by sctp_rcv(). */ static void sctp_assoc_bh_rcv(struct sctp_association *asoc) { @@ -891,6 +875,7 @@ sk = asoc->base.sk; inqueue = &asoc->base.inqueue; + sctp_association_hold(asoc); while (NULL != (chunk = sctp_inq_pop(inqueue))) { state = asoc->state; subtype = chunk->chunk_hdr->type; @@ -913,14 +898,14 @@ /* Check to see if the association is freed in response to * the incoming chunk. If so, get out of the while loop. */ - if (!sctp_assoc_valid(sk, asoc)) + if (asoc->base.dead) break; /* If there is an error on chunk, discard this packet. */ if (error && chunk) chunk->pdiscard = 1; } - + sctp_association_put(asoc); } /* This routine moves an association from its old sk to a new sk. */ diff -Nru a/net/sctp/ipv6.c b/net/sctp/ipv6.c --- a/net/sctp/ipv6.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/ipv6.c Tue Apr 6 07:35:28 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2002, 2004 * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll - * Copyright (c) 2002-2003 International Business Machines, Corp. * Copyright (c) 2002-2003 Intel Corp. * * This file is part of the SCTP kernel reference Implementation @@ -698,7 +698,7 @@ union sctp_addr *addr; struct sctp_association *asoc; - asoc = event->sndrcvinfo.sinfo_assoc_id; + asoc = event->asoc; sctp_inet6_msgname(msgname, addrlen); sin6 = (struct sockaddr_in6 *)msgname; sin6->sin6_port = htons(asoc->peer.port); diff -Nru a/net/sctp/objcnt.c b/net/sctp/objcnt.c --- a/net/sctp/objcnt.c Tue Apr 6 07:35:27 2004 +++ b/net/sctp/objcnt.c Tue Apr 6 07:35:27 2004 @@ -1,5 +1,5 @@ /* SCTP kernel reference Implementation - * Copyright (c) 2001 International Business Machines Corp. + * (C) Copyright IBM Corp. 2001, 2004 * * This file is part of the SCTP kernel reference Implementation * @@ -134,7 +134,7 @@ /* Cleanup the objcount entry in the proc filesystem. */ void sctp_dbg_objcnt_exit(void) { - remove_proc_entry("sctp_dbg_objcount", proc_net_sctp); + remove_proc_entry("sctp_dbg_objcnt", proc_net_sctp); } diff -Nru a/net/sctp/protocol.c b/net/sctp/protocol.c --- a/net/sctp/protocol.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/protocol.c Tue Apr 6 07:35:28 2004 @@ -64,6 +64,9 @@ struct proc_dir_entry *proc_net_sctp; DEFINE_SNMP_STAT(struct sctp_mib, sctp_statistics); +struct idr sctp_assocs_id; +spinlock_t sctp_assocs_id_lock = SPIN_LOCK_UNLOCKED; + /* This is the global socket data structure used for responding to * the Out-of-the-blue (OOTB) packets. A control sock will be created * for this socket at the initialization time. @@ -721,7 +724,7 @@ if (msgname) { struct sctp_association *asoc; - asoc = event->sndrcvinfo.sinfo_assoc_id; + asoc = event->asoc; sctp_inet_msgname(msgname, addr_len); sin = (struct sockaddr_in *)msgname; sinfrom = &asoc->peer.primary_addr.v4; @@ -1048,6 +1051,9 @@ /* Initialize default stream count setup information. */ sctp_max_instreams = SCTP_DEFAULT_INSTREAMS; sctp_max_outstreams = SCTP_DEFAULT_OUTSTREAMS; + + /* Initialize handle used for association ids. */ + idr_init(&sctp_assocs_id); /* Size and allocate the association hash table. * The methodology is similar to that of the tcp hash tables. diff -Nru a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c --- a/net/sctp/sm_make_chunk.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/sm_make_chunk.c Tue Apr 6 07:35:28 2004 @@ -1,5 +1,5 @@ /* SCTP kernel reference Implementation - * (C) Copyright IBM Corp. 2001, 2003 + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. * Copyright (c) 2001-2002 Intel Corp. @@ -1817,10 +1817,23 @@ /* Allocate storage for the negotiated streams if it is not a temporary * association. */ if (!asoc->temp) { + sctp_assoc_t assoc_id; + asoc->ssnmap = sctp_ssnmap_new(asoc->c.sinit_max_instreams, asoc->c.sinit_num_ostreams, gfp); if (!asoc->ssnmap) - goto nomem_ssnmap; + goto clean_up; + + do { + if (unlikely(!idr_pre_get(&sctp_assocs_id, gfp))) + goto clean_up; + spin_lock_bh(&sctp_assocs_id_lock); + assoc_id = (sctp_assoc_t)idr_get_new(&sctp_assocs_id, + (void *)asoc); + spin_unlock_bh(&sctp_assocs_id_lock); + } while (unlikely((int)assoc_id == -1)); + + asoc->assoc_id = assoc_id; } /* ADDIP Section 4.1 ASCONF Chunk Procedures @@ -1836,7 +1849,6 @@ asoc->peer.addip_serial = asoc->peer.i.initial_tsn - 1; return 1; -nomem_ssnmap: clean_up: /* Release the transport structures. */ list_for_each_safe(pos, temp, &asoc->peer.transport_addr_list) { diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/socket.c Tue Apr 6 07:35:28 2004 @@ -135,8 +135,14 @@ } /* Otherwise this is a UDP-style socket. */ - asoc = (struct sctp_association *)id; - if (!sctp_assoc_valid(sk, asoc)) + if (!id || (id == (sctp_assoc_t)-1)) + return NULL; + + spin_lock_bh(&sctp_assocs_id_lock); + asoc = (struct sctp_association *)idr_find(&sctp_assocs_id, (int)id); + spin_unlock_bh(&sctp_assocs_id_lock); + + if (!asoc || (asoc->base.sk != sk) || asoc->base.dead) return NULL; return asoc; @@ -1498,8 +1504,7 @@ * rwnd by that amount. If all the data in the skb is read, * rwnd is updated when the event is freed. */ - sctp_assoc_rwnd_increase(event->sndrcvinfo.sinfo_assoc_id, - copied); + sctp_assoc_rwnd_increase(event->asoc, copied); goto out; } else if ((event->msg_flags & MSG_NOTIFICATION) || (event->msg_flags & MSG_EOR)) @@ -4477,7 +4482,7 @@ */ sctp_skb_for_each(skb, &oldsk->sk_receive_queue, tmp) { event = sctp_skb2event(skb); - if (event->sndrcvinfo.sinfo_assoc_id == assoc) { + if (event->asoc == assoc) { __skb_unlink(skb, skb->list); __skb_queue_tail(&newsk->sk_receive_queue, skb); } @@ -4506,7 +4511,7 @@ */ sctp_skb_for_each(skb, &oldsp->pd_lobby, tmp) { event = sctp_skb2event(skb); - if (event->sndrcvinfo.sinfo_assoc_id == assoc) { + if (event->asoc == assoc) { __skb_unlink(skb, skb->list); __skb_queue_tail(queue, skb); } diff -Nru a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c --- a/net/sctp/ulpevent.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/ulpevent.c Tue Apr 6 07:35:28 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -590,8 +590,7 @@ struct sctp_chunk *chunk, int gfp) { - struct sctp_ulpevent *event; - struct sctp_sndrcvinfo *info; + struct sctp_ulpevent *event = NULL; struct sk_buff *skb; size_t padding, len; @@ -624,101 +623,21 @@ /* Initialize event with flags 0. */ sctp_ulpevent_init(event, 0); - event->iif = sctp_chunk_iif(chunk); - sctp_ulpevent_receive_data(event, asoc); - info = (struct sctp_sndrcvinfo *) &event->sndrcvinfo; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_stream: 16 bits (unsigned integer) - * - * For recvmsg() the SCTP stack places the message's stream number in - * this value. - */ - info->sinfo_stream = ntohs(chunk->subh.data_hdr->stream); - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_ssn: 16 bits (unsigned integer) - * - * For recvmsg() this value contains the stream sequence number that - * the remote endpoint placed in the DATA chunk. For fragmented - * messages this is the same number for all deliveries of the message - * (if more than one recvmsg() is needed to read the message). - */ - info->sinfo_ssn = ntohs(chunk->subh.data_hdr->ssn); - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_ppid: 32 bits (unsigned integer) - * - * In recvmsg() this value is - * the same information that was passed by the upper layer in the peer - * application. Please note that byte order issues are NOT accounted - * for and this information is passed opaquely by the SCTP stack from - * one end to the other. - */ - info->sinfo_ppid = chunk->subh.data_hdr->ppid; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_flags: 16 bits (unsigned integer) - * - * This field may contain any of the following flags and is composed of - * a bitwise OR of these values. - * - * recvmsg() flags: - * - * MSG_UNORDERED - This flag is present when the message was sent - * non-ordered. - */ + event->stream = ntohs(chunk->subh.data_hdr->stream); + event->ssn = ntohs(chunk->subh.data_hdr->ssn); + event->ppid = chunk->subh.data_hdr->ppid; if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) { - info->sinfo_flags |= MSG_UNORDERED; - - /* sinfo_cumtsn: 32 bit (unsigned integer) - * - * This field will hold the current cumulative TSN as - * known by the underlying SCTP layer. Note this field is - * ignored when sending and only valid for a receive - * operation when sinfo_flags are set to MSG_UNORDERED. - */ - info->sinfo_cumtsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map); + event->flags |= MSG_UNORDERED; + event->cumtsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map); } - - /* Note: For reassembly, we need to have the fragmentation bits. - * For now, merge these into the msg_flags, since those bit - * possitions are not used. - */ + event->tsn = ntohl(chunk->subh.data_hdr->tsn); event->msg_flags |= chunk->chunk_hdr->flags; - - /* With 04 draft, tsn moves into sndrcvinfo. */ - info->sinfo_tsn = ntohl(chunk->subh.data_hdr->tsn); - - /* Context is not used on receive. */ - info->sinfo_context = 0; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_assoc_id: sizeof (sctp_assoc_t) - * - * The association handle field, sinfo_assoc_id, holds the identifier - * for the association announced in the COMMUNICATION_UP notification. - * All notifications for a given association have the same identifier. - * Ignored for TCP-style sockets. - */ - info->sinfo_assoc_id = sctp_assoc2id(asoc); - - return event; + event->iif = sctp_chunk_iif(chunk); fail: - return NULL; + return event; } /* Create a partial delivery related event. @@ -797,11 +716,77 @@ void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, struct msghdr *msghdr) { - if (!sctp_ulpevent_is_notification(event)) { - put_cmsg(msghdr, IPPROTO_SCTP, SCTP_SNDRCV, - sizeof(struct sctp_sndrcvinfo), - (void *) &event->sndrcvinfo); - } + struct sctp_sndrcvinfo sinfo; + + if (sctp_ulpevent_is_notification(event)) + return; + + /* Sockets API Extensions for SCTP + * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) + * + * sinfo_stream: 16 bits (unsigned integer) + * + * For recvmsg() the SCTP stack places the message's stream number in + * this value. + */ + sinfo.sinfo_stream = event->stream; + /* sinfo_ssn: 16 bits (unsigned integer) + * + * For recvmsg() this value contains the stream sequence number that + * the remote endpoint placed in the DATA chunk. For fragmented + * messages this is the same number for all deliveries of the message + * (if more than one recvmsg() is needed to read the message). + */ + sinfo.sinfo_ssn = event->ssn; + /* sinfo_ppid: 32 bits (unsigned integer) + * + * In recvmsg() this value is + * the same information that was passed by the upper layer in the peer + * application. Please note that byte order issues are NOT accounted + * for and this information is passed opaquely by the SCTP stack from + * one end to the other. + */ + sinfo.sinfo_ppid = event->ppid; + /* sinfo_flags: 16 bits (unsigned integer) + * + * This field may contain any of the following flags and is composed of + * a bitwise OR of these values. + * + * recvmsg() flags: + * + * MSG_UNORDERED - This flag is present when the message was sent + * non-ordered. + */ + sinfo.sinfo_flags = event->flags; + /* sinfo_tsn: 32 bit (unsigned integer) + * + * For the receiving side, this field holds a TSN that was + * assigned to one of the SCTP Data Chunks. + */ + sinfo.sinfo_tsn = event->tsn; + /* sinfo_cumtsn: 32 bit (unsigned integer) + * + * This field will hold the current cumulative TSN as + * known by the underlying SCTP layer. Note this field is + * ignored when sending and only valid for a receive + * operation when sinfo_flags are set to MSG_UNORDERED. + */ + sinfo.sinfo_cumtsn = event->cumtsn; + /* sinfo_assoc_id: sizeof (sctp_assoc_t) + * + * The association handle field, sinfo_assoc_id, holds the identifier + * for the association announced in the COMMUNICATION_UP notification. + * All notifications for a given association have the same identifier. + * Ignored for one-to-one style sockets. + */ + sinfo.sinfo_assoc_id = sctp_assoc2id(event->asoc); + + /* These fields are not used while receiving. */ + sinfo.sinfo_context = 0; + sinfo.sinfo_timetolive = 0; + + put_cmsg(msghdr, IPPROTO_SCTP, SCTP_SNDRCV, + sizeof(struct sctp_sndrcvinfo), (void *)&sinfo); } /* Stub skb destructor. */ @@ -831,14 +816,14 @@ sctp_association_hold((struct sctp_association *)asoc); skb = sctp_event2skb(event); skb->sk = asoc->base.sk; - event->sndrcvinfo.sinfo_assoc_id = sctp_assoc2id(asoc); + event->asoc = (struct sctp_association *)asoc; skb->destructor = sctp_stub_rfree; } /* A simple destructor to give up the reference to the association. */ static inline void sctp_ulpevent_release_owner(struct sctp_ulpevent *event) { - sctp_association_put(event->sndrcvinfo.sinfo_assoc_id); + sctp_association_put(event->asoc); } /* Do accounting for bytes received and hold a reference to the association @@ -880,8 +865,7 @@ */ skb = sctp_event2skb(event); - sctp_assoc_rwnd_increase(event->sndrcvinfo.sinfo_assoc_id, - skb_headlen(skb)); + sctp_assoc_rwnd_increase(event->asoc, skb_headlen(skb)); /* Don't forget the fragments. */ for (frag = skb_shinfo(skb)->frag_list; frag; frag = frag->next) { diff -Nru a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c --- a/net/sctp/ulpqueue.c Tue Apr 6 07:35:28 2004 +++ b/net/sctp/ulpqueue.c Tue Apr 6 07:35:28 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001-2003 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -251,7 +251,7 @@ struct sctp_ulpevent *cevent; __u32 tsn, ctsn; - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; /* See if it belongs at the end. */ pos = skb_peek_tail(&ulpq->reasm); @@ -262,7 +262,7 @@ /* Short circuit just dropping it at the end. */ cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; if (TSN_lt(ctsn, tsn)) { __skb_queue_tail(&ulpq->reasm, sctp_event2skb(event)); return; @@ -271,7 +271,7 @@ /* Find the right place in this list. We store them by TSN. */ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; if (TSN_lt(tsn, ctsn)) break; @@ -368,7 +368,7 @@ */ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_FIRST_FRAG: @@ -425,7 +425,7 @@ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_MIDDLE_FRAG: @@ -486,7 +486,7 @@ /* Do not even bother unless this is the next tsn to * be delivered. */ - ctsn = event->sndrcvinfo.sinfo_tsn; + ctsn = event->tsn; ctsnap = sctp_tsnmap_get_ctsn(&ulpq->asoc->peer.tsn_map); if (TSN_lte(ctsn, ctsnap)) retval = sctp_ulpq_retrieve_partial(ulpq); @@ -517,7 +517,7 @@ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_FIRST_FRAG: @@ -563,15 +563,15 @@ __u16 sid, csid; __u16 ssn, cssn; - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; in = &ulpq->asoc->ssnmap->in; /* We are holding the chunks by stream, by SSN. */ sctp_skb_for_each(pos, &ulpq->lobby, tmp) { cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; /* Have we gone too far? */ if (csid > sid) @@ -609,12 +609,12 @@ return; } - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; if (sid > csid) { __skb_queue_tail(&ulpq->lobby, sctp_event2skb(event)); return; @@ -630,8 +630,8 @@ */ skb_queue_walk(&ulpq->lobby, pos) { cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; if (csid > sid) break; @@ -656,8 +656,8 @@ return event; /* Note: The stream ID must be verified before this routine. */ - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; in = &ulpq->asoc->ssnmap->in; /* Is this the expected SSN for this stream ID? */ @@ -694,7 +694,7 @@ while ((skb = __skb_dequeue_tail(&ulpq->lobby))) { freed += skb_headlen(skb); event = sctp_skb2event(skb); - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; sctp_ulpevent_free(event); sctp_tsnmap_renege(tsnmap, tsn); @@ -720,7 +720,7 @@ while ((skb = __skb_dequeue_tail(&ulpq->reasm))) { freed += skb_headlen(skb); event = sctp_skb2event(skb); - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; sctp_ulpevent_free(event); sctp_tsnmap_renege(tsnmap, tsn); From greearb@candelatech.com Tue Apr 6 11:40:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 11:40:54 -0700 (PDT) Received: from ns1.wanfear.com (ns1.wanfear.com [207.212.57.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36IelKO014480 for ; Tue, 6 Apr 2004 11:40:49 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by ns1.wanfear.com (8.12.10/8.12.10) with ESMTP id i36IeiPR029094; Tue, 6 Apr 2004 11:40:45 -0700 Message-ID: <4072F9AC.7010307@candelatech.com> Date: Tue, 06 Apr 2004 11:40:44 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: netdev@oss.sgi.com Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> <4072A1CD.8070905@ntop.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4516 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 1293 Lines: 37 Jason Lunz wrote: > deri@ntop.org said: > >>In addition if you do care about performance, I believe you're willing >>to turn off packet transmission and only do packet receive. > > > I don't understand what you mean by this. packet-mmap works perfectly > well on an UP|PROMISC interface with no addresses bound to it. As long > as no packets are injected through a packet socket, the tx path never > gets involved. > > >>IRQ: Linux has far too much latency, in particular at high speeds. I'm >>not the right person who can say "this is the way to go", however I >>believe that we need some sort of interrupt prioritization like RTIRQ >>does. > > > I don't think this is the problem, since small-packet performance is bad > even with a fully-polling e1000 in NAPI mode. As Robert Olsson has > demonstrated, a highly-loaded napi e1000 only generates a few hundred > interrupts per second. So the vast majority of packets recieved are > coming in without a hardware interrupt occurring at all. If the polling is delayed, then you get plenty of latency. With something like e1000, you can have up to 4096 rx buffers too, which can also increase latency, but you do drop fewer packets. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From sri@us.ibm.com Tue Apr 6 12:09:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 12:09:52 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36J9eKO015788 for ; Tue, 6 Apr 2004 12:09:47 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i36J9QAL436114; Tue, 6 Apr 2004 15:09:26 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i36J9OFe122524; Tue, 6 Apr 2004 15:09:25 -0400 Date: Tue, 6 Apr 2004 12:09:26 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [BK PATCH] 2.4 SCTP updates Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4517 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 17103 Lines: 534 Hi Dave Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.4.work to get the following updates to SCTP on top of linux 2.4.26-rc2 This includes 2 of the 3 patches i submitted for 2.6. lib/idr.c is not present in 2.4 and hence i could not remove the use of address of association as its id and virt_addr_valid(). I guess it should be OK for now as PAGEALLOC debugging is not available with 2.4. may be we should backport idr.c to 2.4 or come up with a similar service. Thanks Sridhar # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/04/06 09:28:32-07:00 sri@us.ibm.com # [SCTP] Update sctp_ulpevent structure to include assoc pointer and # only the receive specific fields of sctp_sndrcvinfo. # # net/sctp/ulpqueue.c # net/sctp/ulpevent.c # net/sctp/socket.c # net/sctp/protocol.c # net/sctp/ipv6.c # include/net/sctp/ulpevent.h # # ChangeSet # 2004/04/06 07:54:05-07:00 sri@us.ibm.com # [SCTP] Fix typo in entry name of the remove_proc_entry() call. # # net/sctp/objcnt.c # diff -Nru a/include/net/sctp/ulpevent.h b/include/net/sctp/ulpevent.h --- a/include/net/sctp/ulpevent.h Tue Apr 6 11:54:30 2004 +++ b/include/net/sctp/ulpevent.h Tue Apr 6 11:54:30 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -54,7 +54,13 @@ * growing this structure as it is at the maximum limit now. */ struct sctp_ulpevent { - struct sctp_sndrcvinfo sndrcvinfo; + struct sctp_association *asoc; + __u16 stream; + __u16 ssn; + __u16 flags; + __u32 ppid; + __u32 tsn; + __u32 cumtsn; int msg_flags; int iif; }; diff -Nru a/net/sctp/ipv6.c b/net/sctp/ipv6.c --- a/net/sctp/ipv6.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/ipv6.c Tue Apr 6 11:54:30 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2002, 2004 * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll - * Copyright (c) 2002-2003 International Business Machines, Corp. * Copyright (c) 2002-2003 Intel Corp. * * This file is part of the SCTP kernel reference Implementation @@ -703,7 +703,7 @@ union sctp_addr *addr; struct sctp_association *asoc; - asoc = event->sndrcvinfo.sinfo_assoc_id; + asoc = event->asoc; sctp_inet6_msgname(msgname, addrlen); sin6 = (struct sockaddr_in6 *)msgname; sin6->sin6_port = htons(asoc->peer.port); diff -Nru a/net/sctp/objcnt.c b/net/sctp/objcnt.c --- a/net/sctp/objcnt.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/objcnt.c Tue Apr 6 11:54:30 2004 @@ -132,7 +132,7 @@ /* Cleanup the objcount entry in the proc filesystem. */ void sctp_dbg_objcnt_exit(void) { - remove_proc_entry("sctp_dbg_objcount", proc_net_sctp); + remove_proc_entry("sctp_dbg_objcnt", proc_net_sctp); } diff -Nru a/net/sctp/protocol.c b/net/sctp/protocol.c --- a/net/sctp/protocol.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/protocol.c Tue Apr 6 11:54:30 2004 @@ -719,7 +719,7 @@ if (msgname) { struct sctp_association *asoc; - asoc = event->sndrcvinfo.sinfo_assoc_id; + asoc = event->asoc; sctp_inet_msgname(msgname, addr_len); sin = (struct sockaddr_in *)msgname; sinfrom = &asoc->peer.primary_addr.v4; diff -Nru a/net/sctp/socket.c b/net/sctp/socket.c --- a/net/sctp/socket.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/socket.c Tue Apr 6 11:54:30 2004 @@ -1495,8 +1495,7 @@ * rwnd by that amount. If all the data in the skb is read, * rwnd is updated when the event is freed. */ - sctp_assoc_rwnd_increase(event->sndrcvinfo.sinfo_assoc_id, - copied); + sctp_assoc_rwnd_increase(event->asoc, copied); goto out; } else if ((event->msg_flags & MSG_NOTIFICATION) || (event->msg_flags & MSG_EOR)) @@ -4486,7 +4485,7 @@ */ sctp_skb_for_each(skb, &oldsk->sk_receive_queue, tmp) { event = sctp_skb2event(skb); - if (event->sndrcvinfo.sinfo_assoc_id == assoc) { + if (event->asoc == assoc) { __skb_unlink(skb, skb->list); __skb_queue_tail(&newsk->sk_receive_queue, skb); } @@ -4515,7 +4514,7 @@ */ sctp_skb_for_each(skb, &oldsp->pd_lobby, tmp) { event = sctp_skb2event(skb); - if (event->sndrcvinfo.sinfo_assoc_id == assoc) { + if (event->asoc == assoc) { __skb_unlink(skb, skb->list); __skb_queue_tail(queue, skb); } diff -Nru a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c --- a/net/sctp/ulpevent.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/ulpevent.c Tue Apr 6 11:54:30 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -590,8 +590,7 @@ struct sctp_chunk *chunk, int gfp) { - struct sctp_ulpevent *event; - struct sctp_sndrcvinfo *info; + struct sctp_ulpevent *event = NULL; struct sk_buff *skb; size_t padding, len; @@ -624,101 +623,21 @@ /* Initialize event with flags 0. */ sctp_ulpevent_init(event, 0); - event->iif = sctp_chunk_iif(chunk); - sctp_ulpevent_receive_data(event, asoc); - info = (struct sctp_sndrcvinfo *) &event->sndrcvinfo; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_stream: 16 bits (unsigned integer) - * - * For recvmsg() the SCTP stack places the message's stream number in - * this value. - */ - info->sinfo_stream = ntohs(chunk->subh.data_hdr->stream); - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_ssn: 16 bits (unsigned integer) - * - * For recvmsg() this value contains the stream sequence number that - * the remote endpoint placed in the DATA chunk. For fragmented - * messages this is the same number for all deliveries of the message - * (if more than one recvmsg() is needed to read the message). - */ - info->sinfo_ssn = ntohs(chunk->subh.data_hdr->ssn); - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_ppid: 32 bits (unsigned integer) - * - * In recvmsg() this value is - * the same information that was passed by the upper layer in the peer - * application. Please note that byte order issues are NOT accounted - * for and this information is passed opaquely by the SCTP stack from - * one end to the other. - */ - info->sinfo_ppid = chunk->subh.data_hdr->ppid; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_flags: 16 bits (unsigned integer) - * - * This field may contain any of the following flags and is composed of - * a bitwise OR of these values. - * - * recvmsg() flags: - * - * MSG_UNORDERED - This flag is present when the message was sent - * non-ordered. - */ + event->stream = ntohs(chunk->subh.data_hdr->stream); + event->ssn = ntohs(chunk->subh.data_hdr->ssn); + event->ppid = chunk->subh.data_hdr->ppid; if (chunk->chunk_hdr->flags & SCTP_DATA_UNORDERED) { - info->sinfo_flags |= MSG_UNORDERED; - - /* sinfo_cumtsn: 32 bit (unsigned integer) - * - * This field will hold the current cumulative TSN as - * known by the underlying SCTP layer. Note this field is - * ignored when sending and only valid for a receive - * operation when sinfo_flags are set to MSG_UNORDERED. - */ - info->sinfo_cumtsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map); + event->flags |= MSG_UNORDERED; + event->cumtsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map); } - - /* Note: For reassembly, we need to have the fragmentation bits. - * For now, merge these into the msg_flags, since those bit - * possitions are not used. - */ + event->tsn = ntohl(chunk->subh.data_hdr->tsn); event->msg_flags |= chunk->chunk_hdr->flags; - - /* With 04 draft, tsn moves into sndrcvinfo. */ - info->sinfo_tsn = ntohl(chunk->subh.data_hdr->tsn); - - /* Context is not used on receive. */ - info->sinfo_context = 0; - - /* Sockets API Extensions for SCTP - * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) - * - * sinfo_assoc_id: sizeof (sctp_assoc_t) - * - * The association handle field, sinfo_assoc_id, holds the identifier - * for the association announced in the COMMUNICATION_UP notification. - * All notifications for a given association have the same identifier. - * Ignored for TCP-style sockets. - */ - info->sinfo_assoc_id = sctp_assoc2id(asoc); - - return event; + event->iif = sctp_chunk_iif(chunk); fail: - return NULL; + return event; } /* Create a partial delivery related event. @@ -797,11 +716,77 @@ void sctp_ulpevent_read_sndrcvinfo(const struct sctp_ulpevent *event, struct msghdr *msghdr) { - if (!sctp_ulpevent_is_notification(event)) { - put_cmsg(msghdr, IPPROTO_SCTP, SCTP_SNDRCV, - sizeof(struct sctp_sndrcvinfo), - (void *) &event->sndrcvinfo); - } + struct sctp_sndrcvinfo sinfo; + + if (sctp_ulpevent_is_notification(event)) + return; + + /* Sockets API Extensions for SCTP + * Section 5.2.2 SCTP Header Information Structure (SCTP_SNDRCV) + * + * sinfo_stream: 16 bits (unsigned integer) + * + * For recvmsg() the SCTP stack places the message's stream number in + * this value. + */ + sinfo.sinfo_stream = event->stream; + /* sinfo_ssn: 16 bits (unsigned integer) + * + * For recvmsg() this value contains the stream sequence number that + * the remote endpoint placed in the DATA chunk. For fragmented + * messages this is the same number for all deliveries of the message + * (if more than one recvmsg() is needed to read the message). + */ + sinfo.sinfo_ssn = event->ssn; + /* sinfo_ppid: 32 bits (unsigned integer) + * + * In recvmsg() this value is + * the same information that was passed by the upper layer in the peer + * application. Please note that byte order issues are NOT accounted + * for and this information is passed opaquely by the SCTP stack from + * one end to the other. + */ + sinfo.sinfo_ppid = event->ppid; + /* sinfo_flags: 16 bits (unsigned integer) + * + * This field may contain any of the following flags and is composed of + * a bitwise OR of these values. + * + * recvmsg() flags: + * + * MSG_UNORDERED - This flag is present when the message was sent + * non-ordered. + */ + sinfo.sinfo_flags = event->flags; + /* sinfo_tsn: 32 bit (unsigned integer) + * + * For the receiving side, this field holds a TSN that was + * assigned to one of the SCTP Data Chunks. + */ + sinfo.sinfo_tsn = event->tsn; + /* sinfo_cumtsn: 32 bit (unsigned integer) + * + * This field will hold the current cumulative TSN as + * known by the underlying SCTP layer. Note this field is + * ignored when sending and only valid for a receive + * operation when sinfo_flags are set to MSG_UNORDERED. + */ + sinfo.sinfo_cumtsn = event->cumtsn; + /* sinfo_assoc_id: sizeof (sctp_assoc_t) + * + * The association handle field, sinfo_assoc_id, holds the identifier + * for the association announced in the COMMUNICATION_UP notification. + * All notifications for a given association have the same identifier. + * Ignored for one-to-one style sockets. + */ + sinfo.sinfo_assoc_id = sctp_assoc2id(event->asoc); + + /* These fields are not used while receiving. */ + sinfo.sinfo_context = 0; + sinfo.sinfo_timetolive = 0; + + put_cmsg(msghdr, IPPROTO_SCTP, SCTP_SNDRCV, + sizeof(struct sctp_sndrcvinfo), (void *)&sinfo); } /* Stub skb destructor. */ @@ -831,14 +816,14 @@ sctp_association_hold((struct sctp_association *)asoc); skb = sctp_event2skb(event); skb->sk = asoc->base.sk; - event->sndrcvinfo.sinfo_assoc_id = sctp_assoc2id(asoc); + event->asoc = (struct sctp_association *)asoc; skb->destructor = sctp_stub_rfree; } /* A simple destructor to give up the reference to the association. */ static inline void sctp_ulpevent_release_owner(struct sctp_ulpevent *event) { - sctp_association_put(event->sndrcvinfo.sinfo_assoc_id); + sctp_association_put(event->asoc); } /* Do accounting for bytes received and hold a reference to the association @@ -880,8 +865,7 @@ */ skb = sctp_event2skb(event); - sctp_assoc_rwnd_increase(event->sndrcvinfo.sinfo_assoc_id, - skb_headlen(skb)); + sctp_assoc_rwnd_increase(event->asoc, skb_headlen(skb)); /* Don't forget the fragments. */ for (frag = skb_shinfo(skb)->frag_list; frag; frag = frag->next) { diff -Nru a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c --- a/net/sctp/ulpqueue.c Tue Apr 6 11:54:30 2004 +++ b/net/sctp/ulpqueue.c Tue Apr 6 11:54:30 2004 @@ -1,7 +1,7 @@ /* SCTP kernel reference Implementation + * (C) Copyright IBM Corp. 2001, 2004 * Copyright (c) 1999-2000 Cisco, Inc. * Copyright (c) 1999-2001 Motorola, Inc. - * Copyright (c) 2001-2003 International Business Machines, Corp. * Copyright (c) 2001 Intel Corp. * Copyright (c) 2001 Nokia, Inc. * Copyright (c) 2001 La Monte H.P. Yarroll @@ -251,7 +251,7 @@ struct sctp_ulpevent *cevent; __u32 tsn, ctsn; - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; /* See if it belongs at the end. */ pos = skb_peek_tail(&ulpq->reasm); @@ -262,7 +262,7 @@ /* Short circuit just dropping it at the end. */ cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; if (TSN_lt(ctsn, tsn)) { __skb_queue_tail(&ulpq->reasm, sctp_event2skb(event)); return; @@ -271,7 +271,7 @@ /* Find the right place in this list. We store them by TSN. */ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; if (TSN_lt(tsn, ctsn)) break; @@ -368,7 +368,7 @@ */ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_FIRST_FRAG: @@ -425,7 +425,7 @@ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_MIDDLE_FRAG: @@ -486,7 +486,7 @@ /* Do not even bother unless this is the next tsn to * be delivered. */ - ctsn = event->sndrcvinfo.sinfo_tsn; + ctsn = event->tsn; ctsnap = sctp_tsnmap_get_ctsn(&ulpq->asoc->peer.tsn_map); if (TSN_lte(ctsn, ctsnap)) retval = sctp_ulpq_retrieve_partial(ulpq); @@ -517,7 +517,7 @@ skb_queue_walk(&ulpq->reasm, pos) { cevent = sctp_skb2event(pos); - ctsn = cevent->sndrcvinfo.sinfo_tsn; + ctsn = cevent->tsn; switch (cevent->msg_flags & SCTP_DATA_FRAG_MASK) { case SCTP_DATA_FIRST_FRAG: @@ -563,15 +563,15 @@ __u16 sid, csid; __u16 ssn, cssn; - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; in = &ulpq->asoc->ssnmap->in; /* We are holding the chunks by stream, by SSN. */ sctp_skb_for_each(pos, &ulpq->lobby, tmp) { cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; /* Have we gone too far? */ if (csid > sid) @@ -609,12 +609,12 @@ return; } - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; if (sid > csid) { __skb_queue_tail(&ulpq->lobby, sctp_event2skb(event)); return; @@ -630,8 +630,8 @@ */ skb_queue_walk(&ulpq->lobby, pos) { cevent = (struct sctp_ulpevent *) pos->cb; - csid = cevent->sndrcvinfo.sinfo_stream; - cssn = cevent->sndrcvinfo.sinfo_ssn; + csid = cevent->stream; + cssn = cevent->ssn; if (csid > sid) break; @@ -656,8 +656,8 @@ return event; /* Note: The stream ID must be verified before this routine. */ - sid = event->sndrcvinfo.sinfo_stream; - ssn = event->sndrcvinfo.sinfo_ssn; + sid = event->stream; + ssn = event->ssn; in = &ulpq->asoc->ssnmap->in; /* Is this the expected SSN for this stream ID? */ @@ -694,7 +694,7 @@ while ((skb = __skb_dequeue_tail(&ulpq->lobby))) { freed += skb_headlen(skb); event = sctp_skb2event(skb); - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; sctp_ulpevent_free(event); sctp_tsnmap_renege(tsnmap, tsn); @@ -720,7 +720,7 @@ while ((skb = __skb_dequeue_tail(&ulpq->reasm))) { freed += skb_headlen(skb); event = sctp_skb2event(skb); - tsn = event->sndrcvinfo.sinfo_tsn; + tsn = event->tsn; sctp_ulpevent_free(event); sctp_tsnmap_renege(tsnmap, tsn); From dipankar@in.ibm.com Tue Apr 6 12:55:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 12:55:51 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36JtmKO021322 for ; Tue, 6 Apr 2004 12:55:49 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i36JsmBs615104; Tue, 6 Apr 2004 15:54:48 -0400 Received: from soprano.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i36JsOFd132542; Tue, 6 Apr 2004 15:54:46 -0400 Received: by soprano.in.ibm.com (Postfix, from userid 500) id 441A17C52A; Wed, 7 Apr 2004 01:22:50 +0530 (IST) Date: Wed, 7 Apr 2004 01:22:49 +0530 From: Dipankar Sarma To: Robert Olsson Cc: Andrea Arcangeli , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs Message-ID: <20040406195249.GA4581@in.ibm.com> Reply-To: dipankar@in.ibm.com References: <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> <16497.37720.607342.193544@robur.slu.se> <20040405212220.GH4003@in.ibm.com> <16498.43191.733850.18276@robur.slu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16498.43191.733850.18276@robur.slu.se> User-Agent: Mutt/1.4.1i X-archive-position: 4518 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dipankar@in.ibm.com Precedence: bulk X-list: netdev Content-Length: 1136 Lines: 25 On Tue, Apr 06, 2004 at 02:55:19PM +0200, Robert Olsson wrote: Content-Description: message body text > Dipankar Sarma writes: > > Looks better atleast. Can you apply the following patch (rs-throttle-rcu) > > on top of rcu-softirq.patch in your tree and see if helps a little bit more ? > > Please make sure to set the kernel paramenters rcupdate.maxbatch to 4 > > and rcupdate.plugticks to 0. You can make sure of those parameters > > by looking at dmesg (rcu prints them out during boot). I just merged > > it, but have not tested this patch yet. > > OK! > > Well not tested yet but I don't think we will get rid overflow totally in my > setup. I've done a little experimental patch so *all* softirq's are run via > ksoftirqd. Robert, you should try out rs-throttle-rcu.patch. The idea is that we don't run too many callbacks in a single rcu. In my setup, at 100kpps, I see as many as 30000 rcu callbacks in a single tasklet handler. That is likely hurting even the softirq-only RCU grace periods. Setting rcupdate.maxbatch=4 will do only 4 per tasklet thus providing more quiescent points to the system. Thanks Dipankar From davem@redhat.com Tue Apr 6 13:54:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 13:54:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36Ks3KO023683 for ; Tue, 6 Apr 2004 13:54:04 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i36Kru5D009755; Tue, 6 Apr 2004 16:53:56 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i36Kruj19198; Tue, 6 Apr 2004 16:53:56 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i36KrV1n032255; Tue, 6 Apr 2004 16:53:31 -0400 Date: Tue, 6 Apr 2004 13:52:31 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [BK PATCH] 2.4 SCTP updates Message-Id: <20040406135231.63608955.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4519 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 110 Lines: 4 Both 2.4.x and 2.6.x trees pulled, thanks Sridhar. Don't worry about the pagealloc debugging issue in 2.4.x From rddunlap@osdl.org Tue Apr 6 14:50:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 14:50:45 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36LoeKO025379 for ; Tue, 6 Apr 2004 14:50:41 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i36LoY223666; Tue, 6 Apr 2004 14:50:34 -0700 Date: Tue, 6 Apr 2004 14:45:56 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik Subject: [janitor] remove concat. with __FUNCTION__ (drivers/net/) Message-Id: <20040406144556.78c971a2.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4520 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 3932 Lines: 82 From: Tony Breeds "concatenation of string literals with __FUNCTION__ is deprecated" --- drivers/net/gt96100eth.c | 2 +- drivers/net/irda/smsc-ircc2.c | 6 +++--- drivers/net/irda/via-ircc.c | 2 +- drivers/net/wireless/orinoco.h | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff -puN drivers/net/gt96100eth.c~remove_concat_FUNCTION_drivers drivers/net/gt96100eth.c --- linux-265-kj1/drivers/net/gt96100eth.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/gt96100eth.c 2004-04-05 13:31:23.000000000 -0700 @@ -1212,7 +1212,7 @@ gt96100_rx(struct net_device *dev, u32 s cmdstat, nextOut); if (cmdstat & (u32)rxOwn) { - //err(__FUNCTION__ ": device owns descriptor!\n"); + //err("%s: device owns descriptor!\n", __FUNCTION__); // DMA is not finished updating descriptor??? // Leave and come back later to pick-up where // we left off. diff -puN drivers/net/irda/smsc-ircc2.c~remove_concat_FUNCTION_drivers drivers/net/irda/smsc-ircc2.c --- linux-265-kj1/drivers/net/irda/smsc-ircc2.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/irda/smsc-ircc2.c 2004-04-05 13:31:23.000000000 -0700 @@ -1429,7 +1429,7 @@ static irqreturn_t smsc_ircc_interrupt(i } if (iir & IRCC_IIR_ACTIVE_FRAME) { - /*printk(KERN_WARNING __FUNCTION__ "(): Active Frame\n");*/ + /*printk(KERN_WARNING "%s(): Active Frame\n", __FUNCTION__);*/ } /* Enable interrupts again */ @@ -1995,7 +1995,7 @@ static int __init smsc_ircc_look_for_chi while(address->cfg_base){ cfg_base = address->cfg_base; - /*printk(KERN_WARNING __FUNCTION__ "(): probing: 0x%02x for: 0x%02x\n", cfg_base, address->type);*/ + /*printk(KERN_WARNING "%s(): probing: 0x%02x for: 0x%02x\n", __FUNCTION__, cfg_base, address->type);*/ if( address->type & SMSCSIO_TYPE_FDC){ type = "FDC"; @@ -2040,7 +2040,7 @@ static int __init smsc_superio_flat(cons outb(SMSCSIOFLAT_UARTMODE0C_REG, cfgbase); mode = inb(cfgbase+1); - /*printk(KERN_WARNING __FUNCTION__ "(): mode: 0x%02x\n", mode);*/ + /*printk(KERN_WARNING "%s(): mode: 0x%02x\n", __FUNCTION__, mode);*/ if(!(mode & SMSCSIOFLAT_UART2MODE_VAL_IRDA)) WARNING("%s(): IrDA not enabled\n", __FUNCTION__); diff -puN drivers/net/irda/via-ircc.c~remove_concat_FUNCTION_drivers drivers/net/irda/via-ircc.c --- linux-265-kj1/drivers/net/irda/via-ircc.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/irda/via-ircc.c 2004-04-05 13:31:23.000000000 -0700 @@ -360,7 +360,7 @@ static __devinit int via_ircc_open(int i /* Reserve the ioports that we need */ if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) { -// WARNING(__FUNCTION__ "(), can't get iobase of 0x%03x\n",self->io.fir_base); +// WARNING("%s(), can't get iobase of 0x%03x\n", __FUNCTION__, self->io.fir_base); err = -ENODEV; goto err_out1; } diff -puN drivers/net/wireless/orinoco.h~remove_concat_FUNCTION_drivers drivers/net/wireless/orinoco.h --- linux-265-kj1/drivers/net/wireless/orinoco.h~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/wireless/orinoco.h 2004-04-05 13:31:23.000000000 -0700 @@ -125,8 +125,8 @@ extern int orinoco_debug; #define DEBUG(n, args...) do { } while (0) #endif /* ORINOCO_DEBUG */ -#define TRACE_ENTER(devname) DEBUG(2, "%s: -> " __FUNCTION__ "()\n", devname); -#define TRACE_EXIT(devname) DEBUG(2, "%s: <- " __FUNCTION__ "()\n", devname); +#define TRACE_ENTER(devname) DEBUG(2, "%s: -> %s()\n", __FUNCTION__, devname); +#define TRACE_EXIT(devname) DEBUG(2, "%s: <- %s()\n", __FUNCTION__, devname); extern struct net_device *alloc_orinocodev(int sizeof_card, int (*hard_reset)(struct orinoco_private *)); From rddunlap@osdl.org Tue Apr 6 14:50:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 14:50:46 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36LoeKO025380 for ; Tue, 6 Apr 2004 14:50:41 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i36LoY223670; Tue, 6 Apr 2004 14:50:34 -0700 Date: Tue, 6 Apr 2004 14:46:10 -0700 From: "Randy.Dunlap" To: netdev Cc: davem Subject: [janitor] remove concat. with __FUNCTION__ (net/) Message-Id: <20040406144610.2471dcf7.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4521 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 4960 Lines: 107 From: Tony Breeds "concatenation of string literals with __FUNCTION__ is deprecated" --- linux-265-kj1-rddunlap/net/8021q/vlan.h | 4 ++-- linux-265-kj1-rddunlap/net/8021q/vlanproc.c | 2 +- linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_conntrack_irc.c | 4 ++-- linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_conntrack_tftp.c | 4 ++-- linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_nat_tftp.c | 4 ++-- linux-265-kj1-rddunlap/net/ipv4/netfilter/ipt_ULOG.c | 6 +++--- 6 files changed, 12 insertions(+), 12 deletions(-) diff -puN net/8021q/vlan.h~remove_concat_FUNCTION_net net/8021q/vlan.h --- linux-265-kj1/net/8021q/vlan.h~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/8021q/vlan.h 2004-04-05 13:31:51.000000000 -0700 @@ -19,8 +19,8 @@ I never found it..and the problem seems I'll bet they might prove useful again... --Ben -#define VLAN_MEM_DBG(x, y, z) printk(VLAN_DBG __FUNCTION__ ": " x, y, z); -#define VLAN_FMEM_DBG(x, y) printk(VLAN_DBG __FUNCTION__ ": " x, y); +#define VLAN_MEM_DBG(x, y, z) printk(VLAN_DBG "%s: " x, __FUNCTION__, y, z); +#define VLAN_FMEM_DBG(x, y) printk(VLAN_DBG "%s: " x, __FUNCTION__, y); */ /* This way they don't do anything! */ diff -puN net/8021q/vlanproc.c~remove_concat_FUNCTION_net net/8021q/vlanproc.c --- linux-265-kj1/net/8021q/vlanproc.c~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/8021q/vlanproc.c 2004-04-05 13:31:51.000000000 -0700 @@ -220,7 +220,7 @@ int vlan_proc_rem_dev(struct net_device } #ifdef VLAN_DEBUG - printk(VLAN_DBG __FUNCTION__ ": dev: %p\n", vlandev); + printk(VLAN_DBG "%s: dev: %p\n", __FUNCTION__, vlandev); #endif /** NOTE: This will consume the memory pointed to by dent, it seems. */ diff -puN net/ipv4/netfilter/ip_conntrack_irc.c~remove_concat_FUNCTION_net net/ipv4/netfilter/ip_conntrack_irc.c --- linux-265-kj1/net/ipv4/netfilter/ip_conntrack_irc.c~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_conntrack_irc.c 2004-04-05 13:31:51.000000000 -0700 @@ -60,8 +60,8 @@ DECLARE_LOCK(ip_irc_lock); struct module *ip_conntrack_irc = THIS_MODULE; #if 0 -#define DEBUGP(format, args...) printk(KERN_DEBUG __FILE__ ":" __FUNCTION__ \ - ":" format, ## args) +#define DEBUGP(format, args...) printk(KERN_DEBUG "%s:%s:" format, \ + __FILE__, __FUNCTION__ , ## args) #else #define DEBUGP(format, args...) #endif diff -puN net/ipv4/netfilter/ip_conntrack_tftp.c~remove_concat_FUNCTION_net net/ipv4/netfilter/ip_conntrack_tftp.c --- linux-265-kj1/net/ipv4/netfilter/ip_conntrack_tftp.c~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_conntrack_tftp.c 2004-04-05 13:31:51.000000000 -0700 @@ -33,8 +33,8 @@ MODULE_PARM_DESC(ports, "port numbers of #endif #if 0 -#define DEBUGP(format, args...) printk(__FILE__ ":" __FUNCTION__ ": " \ - format, ## args) +#define DEBUGP(format, args...) printk("%s:%s:" format, \ + __FILE__, __FUNCTION__ , ## args) #else #define DEBUGP(format, args...) #endif diff -puN net/ipv4/netfilter/ip_nat_tftp.c~remove_concat_FUNCTION_net net/ipv4/netfilter/ip_nat_tftp.c --- linux-265-kj1/net/ipv4/netfilter/ip_nat_tftp.c~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/ipv4/netfilter/ip_nat_tftp.c 2004-04-05 13:31:51.000000000 -0700 @@ -47,8 +47,8 @@ MODULE_PARM_DESC(ports, "port numbers of #endif #if 0 -#define DEBUGP(format, args...) printk(__FILE__ ":" __FUNCTION__ ": " \ - format, ## args) +#define DEBUGP(format, args...) printk("%s:%s:" format, \ + __FILE__, __FUNCTION__ , ## args) #else #define DEBUGP(format, args...) #endif diff -puN net/ipv4/netfilter/ipt_ULOG.c~remove_concat_FUNCTION_net net/ipv4/netfilter/ipt_ULOG.c --- linux-265-kj1/net/ipv4/netfilter/ipt_ULOG.c~remove_concat_FUNCTION_net 2004-04-05 13:31:51.000000000 -0700 +++ linux-265-kj1-rddunlap/net/ipv4/netfilter/ipt_ULOG.c 2004-04-05 13:31:51.000000000 -0700 @@ -64,13 +64,13 @@ MODULE_DESCRIPTION("iptables userspace l #define ULOG_MAXNLGROUPS 32 /* numer of nlgroups */ #if 0 -#define DEBUGP(format, args...) printk(__FILE__ ":" __FUNCTION__ ":" \ - format, ## args) +#define DEBUGP(format, args...) printk("%s:%s:" format, \ + __FILE__, __FUNCTION__ , ## args) #else #define DEBUGP(format, args...) #endif -#define PRINTR(format, args...) do { if (net_ratelimit()) printk(format, ## args); } while (0) +#define PRINTR(format, args...) do { if (net_ratelimit()) printk(format , ## args); } while (0) static unsigned int nlbufsiz = 4096; MODULE_PARM(nlbufsiz, "i"); _ From bhartin@straus-frank.com Tue Apr 6 16:03:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 16:03:23 -0700 (PDT) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36N3JKO027941 for ; Tue, 6 Apr 2004 16:03:21 -0700 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i36N3GkH051794; Tue, 6 Apr 2004 23:03:16 GMT (envelope-from bhartin@straus-frank.com) Date: Tue, 6 Apr 2004 18:03:03 -0500 (CDT) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040407001815.C7833@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> <20040407001815.C7833@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4522 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 1078 Lines: 33 On Wed, 7 Apr 2004, Francois Romieu wrote: > Hmmm... Something like "no PHY Reset ack. Giving up." I guess. Ok, I'll > add it to the queue, the locking between the phy_timer() and the irq handler > looks strange. I got my laptop back up and found the messages logged: kernel: r8169: eth0: Reset RTL8169s PHY I didn't see exactly at what point this started happening during the shutdown, but the message repeated about 500 times before the system logger was stopped. Again, I've had no issues so far during normal use. There are no abnormal timeouts, and transfer rates appear within normal ranges. (I've only used it on 100bT switches so far, no 10bT or gigabit.) > As a general note, do not hesitate to post on/Cc: netdev as it can be of > interest to other people as well. I meant to, but must have hit no when Pine asked about replying to all recipients. > Thanks for the report. Not a problem at all. I'm just glad to finally get this thing working! Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company From romieu@fr.zoreil.com Tue Apr 6 16:41:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 16:41:31 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36NfQKO032143 for ; Tue, 6 Apr 2004 16:41:29 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i36Ncfgf011055; Wed, 7 Apr 2004 01:38:41 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i36Ncfa6011054; Wed, 7 Apr 2004 01:38:41 +0200 Date: Wed, 7 Apr 2004 01:38:41 +0200 From: Francois Romieu To: bhartin@straus-frank.com Cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop Message-ID: <20040407013841.A7978@electric-eye.fr.zoreil.com> References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> <20040407001815.C7833@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bhartin@straus-frank.com on Tue, Apr 06, 2004 at 06:03:03PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4523 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1044 Lines: 38 bhartin@straus-frank.com : [...] > I got my laptop back up and found the messages logged: > > kernel: r8169: eth0: Reset RTL8169s PHY > > I didn't see exactly at what point this started happening during the > shutdown, but the message repeated about 500 times before the system > logger was stopped. It implies a minimum of 6000 invocations of rtl8169_phy_timer(). *doh* Please apply patch below. mod_timer() expects an absolute time, not a relative offset. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-mod_timer drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-mod_timer 2004-04-07 01:30:14.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-07 01:32:53.000000000 +0200 @@ -617,7 +617,7 @@ static void rtl8169_phy_timer(unsigned l } } - mod_timer(timer, RTL8169_PHY_TIMEOUT); + mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); } static inline void rtl8169_delete_timer(struct net_device *dev) _ From bhartin@straus-frank.com Tue Apr 6 22:15:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 06 Apr 2004 22:15:50 -0700 (PDT) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i375FlKO013469 for ; Tue, 6 Apr 2004 22:15:48 -0700 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i375FjkH046764; Wed, 7 Apr 2004 05:15:45 GMT (envelope-from bhartin@straus-frank.com) Date: Wed, 7 Apr 2004 00:15:27 -0500 (CDT) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040407013841.A7978@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> <20040407001815.C7833@electric-eye.fr.zoreil.com> <20040407013841.A7978@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4524 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 1487 Lines: 55 The patch resolved the PHY messages, and I stress-tested the networking again--it's still stable. Thanks! Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company On Wed, 7 Apr 2004, Francois Romieu wrote: > bhartin@straus-frank.com : > [...] > > I got my laptop back up and found the messages logged: > > > > kernel: r8169: eth0: Reset RTL8169s PHY > > > > I didn't see exactly at what point this started happening during the > > shutdown, but the message repeated about 500 times before the system > > logger was stopped. > > It implies a minimum of 6000 invocations of rtl8169_phy_timer(). > > *doh* > > Please apply patch below. > > > > mod_timer() expects an absolute time, not a relative offset. > > > drivers/net/r8169.c | 2 +- > 1 files changed, 1 insertion(+), 1 deletion(-) > > diff -puN drivers/net/r8169.c~r8169-mod_timer drivers/net/r8169.c > --- linux-2.6.5/drivers/net/r8169.c~r8169-mod_timer 2004-04-07 01:30:14.000000000 +0200 > +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-07 01:32:53.000000000 +0200 > @@ -617,7 +617,7 @@ static void rtl8169_phy_timer(unsigned l > } > } > > - mod_timer(timer, RTL8169_PHY_TIMEOUT); > + mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); > } > > static inline void rtl8169_delete_timer(struct net_device *dev) > > _ > Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company From deri@ntop.org Wed Apr 7 00:03:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 00:03:20 -0700 (PDT) Received: from localhost.localdomain (host114-228.pool82187.interbusiness.it [82.187.228.114]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37732KO017394 for ; Wed, 7 Apr 2004 00:03:04 -0700 Received: from ntop.org (athlon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i376x4Bv010846; Wed, 7 Apr 2004 08:59:20 +0200 Message-ID: <4073A6B8.8070803@ntop.org> Date: Wed, 07 Apr 2004 08:59:04 +0200 From: Luca Deri Organization: ntop.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca CC: P@draigBrady.com, Jason Lunz , netdev@oss.sgi.com, cpw@lanl.gov, ntop-misc@fuji.unipi.it, Robert.Olsson@data.slu.se Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> <4072A1CD.8070905@ntop.org> <1081262228.1046.25.camel@jzny.localdomain> In-Reply-To: <1081262228.1046.25.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4525 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: deri@ntop.org Precedence: bulk X-list: netdev Content-Length: 5981 Lines: 172 Hi Jamal, from what I read below it seems that you read my first version of the paper/code. The current paper is available here http://luca.ntop.org/Ring.pdf and the code here http://sourceforge.net/project/showfiles.php?group_id=17233&package_id=110128 (as I have said before I plan to have a new release soon). Briefly: - with the new release I don't have to patch the NIC driver anymore - the principle is simple. At the beginning of netif_rx/netif_receive_sk I have added some code that does this: if there's an incoming packet for a device where a PF_RING socket was bound, the packet is processed by the socket and the functions return NET_RX_SUCCESS with no further processing. This means that: - Linux does not have to do anything else with the packet and it's ready to do something else - the PF_RING is mapped to userland via mmap (like libpcap-mmap) but down the stack (for instance I'm below netfilter) so for each incoming packet there's no extra overhead like queuing into data structures, netfilter processing etc. This work has been done to improve passive packet capture in order to speedup apps based on pcap like ntop, snort, ethereal... jamal wrote: >On Tue, 2004-04-06 at 08:25, Luca Deri wrote: > > >>Hi all, >>the problem with libpcap-mmap is that: >>- it does not reduce the journey of the packet from NIC to userland >>beside the last part of it (syscall replaced with mmap). This has a >>negative impact on the overall performance. >> >> > >By how much does it add to the overall cost? I would say not by much if >your other approach is also to cross user space. >Can you post the userland program you used? >Can you also capture profiles and post them? > > The code is available at the URL I have specified before. > > >>- it does not feature things like kernel packet sampling that pushes >>people to fetch all the packets out of a NIC then discard most of them >>(i.e. CPU cycles not very well spent). Somehow this is a limitation of >>pcap that does not feature a pcap_sample call. >> >> > >Sampling can be done easily with tc extensions if you are willing to >accept patches - 2.4.x only at the moment. >Infact if all you want is to account and drop at the kernel, >this would be the easiest way to do it (the kernel will gather stats for >you which you can collect in user space). > > What I did is not for simply accounting. In fact as you pointed out accounting can be done with the kernel. What i did is for apps that need to access the raw packet and do something with it. Moreover, do not forget that at high speeds (or even at 100 Mbit under attack) the standard Linux kernel is not always able to receive all the traffic. This means that even using kernel apps like tc you will not account traffic properly > > > >>In addition if you do care about performance, I believe you're willing >>to turn off packet transmission and only do packet receive. >> >> > >You are talking very speacilized machine here. If all you want is to >recieve and make sure the transmission never happens - consider looking >at the patches i suggested. > > I probably missed your patches. Chan you please send them again? >I still think you want to manage this device, so some packets should be >transmitted. >I have a small issue with your approach btw: >Any solution which hacks things so that they run at the driver level >would always get a good performance at the expense of flexibility. >You might as well stop using Linux - what is the point? Write a bare >bone OS constituting of said driver. > > I agree, that's why in release 2. I have decide not to hack the driver as this is not too smart. >What we should do instead is improve Linux so it can be at the same >level performance wise as your bare bone driver. I have never seen you >post on this subject and then you show up with a a paper showing an >ancient OS like BSD beating us at performance (or worse Win2k). > > > >> >>Unfortunately I have no access to a "real" traffic generator (I use a PC >>as traffic generator). However if you read my paper you can see that >>with a Pentium IV 1.7 you can capture over 500'000 pkt/sec, so in your >>setup (Xeon + Spirent) you can have better figures. >> >> > >Do you have a new version of the paper? In the version i have you >only talk about 100Mbps rates. > > See above. > > >>IRQ: Linux has far too much latency, in particular at high speeds. I'm >>not the right person who can say "this is the way to go", however I >>believe that we need some sort of interrupt prioritization like RTIRQ does. >> >> > >Is this still relevant with NAPI? > > Not really. I have written a simple kernel module with a dummy poll() implementation what returns immediately. Well under high system load the time it takes to process this poll call is much much greater (and totally unpredictable). You should read this: http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040304/rtirq.html > > >>FYI, I've just polished the code and added kernel packet filtering to >>PF_RING. As soon as I have completed my tests I will release a new version. >> >>Finally It would be nice to have in the standard Linux core some packet >>capture improvements. It could either be based on my work or on somebody >>else's work. It doesn't really matter as long as Linux gets faster. >> >> > >You should be involved since you have the energy. You also have to be >willing to provide data when things dont work well - I am willing to >help as i am sure many netdev people are if you are going to be positive >in your approach. Provide results when needed and be willing to invest >time and experiment. > > So tell me what to do in order to integrate my work into Linux and I'll do my best to serve the community. >cheers, >jamal > > > Cheers, Luca -- Luca Deri http://luca.ntop.org/ Hacker: someone who loves to program and enjoys being clever about it - Richard Stallman From deri@ntop.org Wed Apr 7 00:06:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 00:06:26 -0700 (PDT) Received: from localhost.localdomain (host114-228.pool82187.interbusiness.it [82.187.228.114]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37766KO017789 for ; Wed, 7 Apr 2004 00:06:08 -0700 Received: from ntop.org (athlon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3773BBv010983; Wed, 7 Apr 2004 09:03:32 +0200 Message-ID: <4073A7AF.5060401@ntop.org> Date: Wed, 07 Apr 2004 09:03:11 +0200 From: Luca Deri Organization: ntop.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Olsson CC: hadi@cyberus.ca, Jason Lunz , netdev@oss.sgi.com, ntop-misc@fuji.unipi.it Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <1081261126.1047.6.camel@jzny.localdomain> <16498.52551.712261.214192@robur.slu.se> In-Reply-To: <16498.52551.712261.214192@robur.slu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4526 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: deri@ntop.org Precedence: bulk X-list: netdev Content-Length: 1810 Lines: 53 Robert Olsson wrote: >jamal writes: > > > I didnt follow that discussion; archived for later entertaining reading. > > My take on it was it is 2.6.x related and in particular the misbehavior > > observed has to do with use of rcu in the route cache. > > > > > It appears this problem became worse in 2.6 with HZ=1000, because now > > > the napi rx softirq work is being done 10X as much on return from the > > > timer interrupt. I'm not sure if a solution was reached. > > > > Robert? > > Well it's a general problem controlling softirq/user and the RCU locking > put this on our agenda as the dst hash was among the first applications > to use the RCU locking. Which in turn had problem doing progress in hard > softirq environment which happens during route cache DoS. > > NAPI is a part of RX_SOFTIRQ which is well-behaved. NAPI addresses only > irq/sofirq problem and is totally innocent for do_sofirq() run from other > parts of kernel causing userland starvation. > > Under normal hi-load conditions RX_SOFTIRQ schedules itself when the > netdev_max_backlog is done. do_softirq sees this and defers execution > to ksoftirqd and things get under (scheduler) control. > > During route DoS, code that does a lot do_softirq() is run for hash and > fib-lookup, GC etc. The effect is that ksoftirqd is more or less bypassed. > Again it's a general problem... We are just the unlucky guys getting > into this. > > I don't know if packet capture tests done by Luca ran into this problems. > A profile could have helped... > > Robert, yes I run into this problems and I have solved using the RTIRQ kernel patch. Cheers, Luca > Cheers. > --ro > > -- Luca Deri http://luca.ntop.org/ Hacker: someone who loves to program and enjoys being clever about it - Richard Stallman From deri@ntop.org Wed Apr 7 00:14:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 00:15:15 -0700 (PDT) Received: from localhost.localdomain (host114-228.pool82187.interbusiness.it [82.187.228.114]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i377EjKO018331 for ; Wed, 7 Apr 2004 00:14:47 -0700 Received: from ntop.org (athlon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i377BRBv011128; Wed, 7 Apr 2004 09:11:44 +0200 Message-ID: <4073A99F.1000006@ntop.org> Date: Wed, 07 Apr 2004 09:11:27 +0200 From: Luca Deri Organization: ntop.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Lunz CC: ntop-misc@fuji.unipi.it, netdev@oss.sgi.com, Robert.Olsson@data.slu.se, hadi@cyberus.ca Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> <4072A1CD.8070905@ntop.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4527 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: deri@ntop.org Precedence: bulk X-list: netdev Content-Length: 3329 Lines: 93 Jason, Jason Lunz wrote: >[This message has also been posted to gmane.linux.network.] >deri@ntop.org said: > > >>In addition if you do care about performance, I believe you're willing >>to turn off packet transmission and only do packet receive. >> >> > >I don't understand what you mean by this. packet-mmap works perfectly >well on an UP|PROMISC interface with no addresses bound to it. As long >as no packets are injected through a packet socket, the tx path never >gets involved. > > > my PF_RING does not allow you to send data, but just to receive it. I have not implemented transmission as this work is mainly for receiving data and not for sending (although it should be fairly easy to do add this feature). So 1) everything is optimized for receiving packets and 2) as I have explained before the trip of a packet from the NIC to the userland is much shorter that with pcap-mmap (for instance you don't cross netfilter at all). >>IRQ: Linux has far too much latency, in particular at high speeds. I'm >>not the right person who can say "this is the way to go", however I >>believe that we need some sort of interrupt prioritization like RTIRQ >>does. >> >> > >I don't think this is the problem, since small-packet performance is bad >even with a fully-polling e1000 in NAPI mode. As Robert Olsson has >demonstrated, a highly-loaded napi e1000 only generates a few hundred >interrupts per second. So the vast majority of packets recieved are >coming in without a hardware interrupt occurring at all. > >Could it be that each time an hw irq _is_ generated, it causes many >packets to be lost? That's a possibility. Can you explain in more detail >how you measured the effect of interrupt latency on recieve efficiency? > > I'm not an expert here. All i can tell you is that measuring performance with rtdisc I have realized that even at high load, even if there are few incoming interrupts (as Robert demonstrated) the kernel latency is not acceptable. That's why I used RTIRQ. > > >>Finally It would be nice to have in the standard Linux core some >>packet capture improvements. It could either be based on my work or on >>somebody else's work. It doesn't really matter as long as Linux gets >>faster. >> >> > >I agree. I think a good place to start would be reading and >understanding this thread: > >http://thread.gmane.org/gmane.linux.kernel/193758 > >There's some disagreement for a while about where all this softirq load >is coming from. It looks like an interaction of softirqs and RCU, but >the first patch doesn't help. Finally Olsson pointed out: > >http://article.gmane.org/gmane.linux.kernel/194412 > >that the majority of softirq's are being run from hardirq exit. Even >with NAPI. At this point, I think, it's clear that the problem exists >regardless of rcu, and indeed, Linux is bad at doing packet-mmap RX of a >small-packet gigabit flood on both 2.4 and 2.6 (my old 2.4 measurements >earlier in this thread show this). > >I'm particularly interested in trying Andrea's suggestion from >http://article.gmane.org/gmane.linux.kernel/194486 , but I won't have >the time anytime soon. > >Jason > > I'll read them. Thanks, Luca -- Luca Deri http://luca.ntop.org/ Hacker: someone who loves to program and enjoys being clever about it - Richard Stallman From _Svc_NortonAV@synergon.hu Wed Apr 7 01:36:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 01:36:19 -0700 (PDT) Received: from cache1.synergon.hu (cache.synergon.hu [194.149.60.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i378aCKO027952 for ; Wed, 7 Apr 2004 01:36:13 -0700 Date: Wed, 7 Apr 2004 01:36:12 -0700 Message-Id: <200404070836.i378aCKO027952@oss.sgi.com> Received: (qmail 28745 invoked from network); 7 Apr 2004 08:36:12 -0000 Received: from unknown (HELO sy2ba-smtp.synergon.hu) (194.149.60.55) by cache.synergon.hu with SMTP; 7 Apr 2004 08:36:12 -0000 From: _Svc_NortonAV@synergon.hu To: netdev@oss.sgi.com Subject: (SMTP) Virus found in a message you sent X-archive-position: 4528 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: _Svc_NortonAV@synergon.hu Precedence: bulk X-list: netdev Content-Length: 628 Lines: 21 (SMTP) A virus was found in a message sent by this account. --- Scan information follows --- Result: Virus Detected Virus Name: W32.Netsky.P@mm File Attachment: message.scr Attachment Status: deleted --- Original message information follows --- From: netdev@oss.sgi.com To: tiv@itc.hu Date: Wed, 7 Apr 2004 16:37:46 +0800 Subject: Mail Delivery (failure tiv@itc.hu) Message-Id: <200404070835.i378ZSZZ015823@server.itc.hu> Received: from cache1.synergon.hu ([194.149.60.26]) by sy2ba-smtp.synergon.hu (SAVSMTP 3.1.0.29) with SMTP id M2004040710354004630 for ; Wed, 07 Apr 2004 10:35:40 +0200 From degger@fhm.edu Wed Apr 7 01:59:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 01:59:10 -0700 (PDT) Received: from karin.de.interearth.com (dialin-212-144-167-162.arcor-ip.net [212.144.167.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i378wvKO030893 for ; Wed, 7 Apr 2004 01:58:58 -0700 Received: from [192.168.11.8] (lucy [192.168.11.8]) by karin.de.interearth.com (Postfix) with ESMTP id BF6234C9D; Wed, 7 Apr 2004 10:21:29 +0200 (CEST) In-Reply-To: <4072CD01.6070408@pobox.com> References: <4072CD01.6070408@pobox.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--102663672" Message-Id: Content-Transfer-Encoding: 7bit Cc: Linux Kernel , Andrew Morton , Netdev From: Daniel Egger Subject: Re: [NET] net driver updates Date: Tue, 6 Apr 2004 22:35:51 +0200 To: Jeff Garzik X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-archive-position: 4529 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: degger@fhm.edu Precedence: bulk X-list: netdev Content-Length: 1711 Lines: 52 --Apple-Mail-4--102663672 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 06.04.2004, at 17:30, Jeff Garzik wrote: > * Francois work on r8169, epic100, sis190: PCI DMA, NAPI, other minor > fixes and cleanups r8169 seems to work though it is not even a tad bit faster than plain 2.6.5. Those cards are really driving me nuts. Between two r8169 cards, one on Athlon with kernel 2.4.24, one on Athlon with 2.6.5 or 2.4.24, I get 90Mbit/s in one direction and 39Mbit/s in the other using iperf and TCP. With iperf and UDP they deliver 100Mbit/s resp. 230Mbit/s depending on the direction. Crosschecking with my PowerBook (OS X) shows that I can get 844Mbit/s (UDP) or 572Mbit/s (TCP) to one host and 844Mbit/s (UDP) but only 88Mbit/s (TCP) to the other. The environment is switched and changing cables and/or ports doesn't improve the results. Ideas? (Yeah, I'll get Intel NICs RSN...) Servus, Daniel --Apple-Mail-4--102663672 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQHMUpzBkNMiD99JrAQL45Qf/b96+36QbfCn1DYBW1dc3kdvwwK89svqT Hu2akhQbncciQ8Wuy0yw8tYd4N5oDAOi+4NnJMA77JveHIlKSoMcRB5m8O2of5SJ PvNhKQhU3I6ysoUrOO5AIpoiycymYuxgv76tMKQbiouSY/xR8EfxXPRGkCxzfV3w 7yHhjgMFEz9DbgTEQJj3ed5I4GalpCVh/x5EPqv7c/7+LLkWkDYhwoWtZCxb3lrS W5LjRVfHmks+kqk+9WbhwnJEtcoSGEVOLyRGmL8PxUgTDYZjm98MxSgUbnWO6KP2 C0FVe6VtBfElQbLgWuJOHqDjynxwuosMeeEsdigOCuis2hIUBUXQ9w== =j3y8 -----END PGP SIGNATURE----- --Apple-Mail-4--102663672-- From romieu@fr.zoreil.com Wed Apr 7 02:29:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 02:29:30 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i379TRKO000708 for ; Wed, 7 Apr 2004 02:29:28 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i379Q7gf017527; Wed, 7 Apr 2004 11:26:07 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i379Q7pl017526; Wed, 7 Apr 2004 11:26:07 +0200 Date: Wed, 7 Apr 2004 11:26:07 +0200 From: Francois Romieu To: bhartin@straus-frank.com Cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop Message-ID: <20040407112607.A17476@electric-eye.fr.zoreil.com> References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> <20040407001815.C7833@electric-eye.fr.zoreil.com> <20040407013841.A7978@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bhartin@straus-frank.com on Wed, Apr 07, 2004 at 12:15:27AM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4530 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 247 Lines: 9 bhartin@straus-frank.com : [...] > The patch resolved the PHY messages, and I stress-tested the networking > again--it's still stable. Does it allow the link to be recovered if the cable is removed/plugde ? -- Ueimor From chas@cmf.nrl.navy.mil Wed Apr 7 05:05:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 05:05:17 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37C5EKO014300 for ; Wed, 7 Apr 2004 05:05:14 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i37C58MO020742; Wed, 7 Apr 2004 08:05:08 -0400 (EDT) Message-Id: <200404071205.i37C58MO020742@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: get atm_guess_pdu2truesize() right Reply-To: chas3@users.sourceforge.net Date: Wed, 07 Apr 2004 08:05:09 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4531 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 32 please apply to 2.6 and 2.4 kernels. thanks! # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1331.3.3 -> 1.1331.3.4 # include/linux/atmdev.h 1.13 -> 1.14 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/07 chas@relax.cmf.nrl.navy.mil 1.1331.3.4 # [ATM]: get atm_guess_pdu2truesize() right # -------------------------------------------- # diff -Nru a/include/linux/atmdev.h b/include/linux/atmdev.h --- a/include/linux/atmdev.h Wed Apr 7 08:01:57 2004 +++ b/include/linux/atmdev.h Wed Apr 7 08:01:57 2004 @@ -411,9 +411,9 @@ * */ -static inline int atm_guess_pdu2truesize(int pdu_size) +static inline int atm_guess_pdu2truesize(int size) { - return ((pdu_size+15) & ~15) + sizeof(struct sk_buff); + return (SKB_DATA_ALIGN(size) + sizeof(struct skb_shared_info)); } From hadi@cyberus.ca Wed Apr 7 05:20:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 05:21:14 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37CKwKO014976 for ; Wed, 7 Apr 2004 05:20:58 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BBC3L-0006Ri-Nf for netdev@oss.sgi.com; Wed, 07 Apr 2004 08:21:11 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BBC2v-0007yv-2v; Wed, 07 Apr 2004 08:20:45 -0400 Subject: Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling From: jamal Reply-To: hadi@cyberus.ca To: Luca Deri Cc: P@draigBrady.com, Jason Lunz , netdev@oss.sgi.com, cpw@lanl.gov, ntop-misc@fuji.unipi.it, Robert.Olsson@data.slu.se In-Reply-To: <4073A6B8.8070803@ntop.org> References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <407286BB.8080107@draigBrady.com> <4072A1CD.8070905@ntop.org> <1081262228.1046.25.camel@jzny.localdomain> <4073A6B8.8070803@ntop.org> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081340407.15893.114.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2004 08:20:08 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4532 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5637 Lines: 138 On Wed, 2004-04-07 at 02:59, Luca Deri wrote: > Hi Jamal, > from what I read below it seems that you read my first version of the > paper/code. The current paper is available here > http://luca.ntop.org/Ring.pdf and the code here > http://sourceforge.net/project/showfiles.php?group_id=17233&package_id=110128 > (as I have said before I plan to have a new release soon). Thanks. I will take a look at the above. The paper i looked at was posted on netdev by someone else. > Briefly: > - with the new release I don't have to patch the NIC driver anymore > - the principle is simple. At the beginning of netif_rx/netif_receive_sk > I have added some code that does this: if there's an incoming packet for > a device where a PF_RING socket was bound, the packet is processed by > the socket and the functions return NET_RX_SUCCESS with no further > processing. I think theres a good connection with what i am working on since the patches i have are at the same level. On my TODO list was "fast packet diverting to userspace" - but this meant either stealing or sharing unlike your case where it is always stealing the packet. My intention was to just mmaped PF_PACKET at the level you are refering to. So maybe i could use your work instead if its clean. I will send you the patches privately. > This means that: > - Linux does not have to do anything else with the packet and it's ready > to do something else This should be policy driven. In some cases you may want that packet to be shared/copied (i.e this is a more generic solution). i.e you add a policy which says to divert all packets from 10.0.0.1 arriving on eth0 to user space with a tag x. User space binds to tag x or * to receive all. Filtering out at that low level provides early discard opportunities. Of course what above means is you may need to have several rings even within a device. There is also nothing that should stop packet capture to happen at the egress side (what you refered to as transmit). > - the PF_RING is mapped to userland via mmap (like libpcap-mmap) but > down the stack (for instance I'm below netfilter) so for each incoming > packet there's no extra overhead like queuing into data structures, > netfilter processing etc. Netfilter is definetely not something to be proud of perfomance wise but i think you may be overstating the impact of the other pieces. > This work has been done to improve passive packet capture in order to > speedup apps based on pcap like ntop, snort, ethereal... Again note that we want to get as close as possible to performance you get from speacilized work while still maintaining Linux as a general OS. For example creating a new socket family like you have MUST have a good reason; could you not have reused PF_PACKET?[1] > jamal wrote: > > >On Tue, 2004-04-06 at 08:25, Luca Deri wrote: > > > > > >By how much does it add to the overall cost? I would say not by much if > >your other approach is also to cross user space. > >Can you post the userland program you used? > >Can you also capture profiles and post them? > > > > > The code is available at the URL I have specified before. But i asked for your profiles since you did the work ;-> Dont expect me to get very enthusiastic and collect profiles for you. For example, i didnt know why you couldnot get packet mmap to work. I certainly could do about 200Kpps with it on what i remember to be an average machine. > > What I did is not for simply accounting. In fact as you pointed out > accounting can be done with the kernel. What i did is for apps that need > to access the raw packet and do something with it. Moreover, do not > forget that at high speeds (or even at 100 Mbit under attack) the > standard Linux kernel is not always able to receive all the traffic. > This means that even using kernel apps like tc you will not account > traffic properly I think s/ware not receiving all packets will always be an issue regardless - actually i should say even well designed NICs will have problems. So whatever sampling methodology you use should factor that in to account for properly. > > > > > >>IRQ: Linux has far too much latency, in particular at high speeds. I'm > >>not the right person who can say "this is the way to go", however I > >>believe that we need some sort of interrupt prioritization like RTIRQ does. > >> > >> > > > >Is this still relevant with NAPI? > > > > > Not really. I have written a simple kernel module with a dummy poll() > implementation what returns immediately. Well under high system load the > time it takes to process this poll call is much much greater (and > totally unpredictable). You should read this: > http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040304/rtirq.html > This maybe related to what Robert and co. are chasing; How did 2.4.x treat you? I did a quick glance at the above work and i am curious how they address shared interupts. Lets say you have a PC with a soundcard and videocard sharing an IRQ and the video card is considered high prio - how do you control priorities then? > > So tell me what to do in order to integrate my work into Linux and I'll > do my best to serve the community. For one, provide results when people ask. I asked you for profiles above and you point me to the code ;-> You should do the work ;-> cheers, jamal [1]A good reason not to use PF_PACKET maybe because it would have required too many changes and may break backward compatibility. But these are the kind of things you need to show. I would also suggest you look at other work like relayfs which i have not heard time to look at myself. From hadi@cyberus.ca Wed Apr 7 05:25:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 05:25:09 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37CP7KO015458 for ; Wed, 7 Apr 2004 05:25:07 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BBC7O-00019F-Bo for netdev@oss.sgi.com; Wed, 07 Apr 2004 08:25:22 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BBC6y-0000Qi-1c; Wed, 07 Apr 2004 08:24:56 -0400 Subject: Re: [PATCH] New version of net timestamp optimization From: jamal Reply-To: hadi@cyberus.ca To: Andi Kleen Cc: netdev@oss.sgi.com In-Reply-To: <20040406182941.7e759f4c.ak@suse.de> References: <20040406182941.7e759f4c.ak@suse.de> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081340659.15893.117.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2004 08:24:19 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4533 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 433 Lines: 14 On Tue, 2004-04-06 at 12:29, Andi Kleen wrote: > New version of the network packet timestamp optimization. Avoid calling gettimeofday > in the network fast path when not needed. > Andi, The patch does look clean and attractive. I havent had time toi play with it myself - but given the way gettimeofday has been torturing me i will at some point. Also if you have time a 2.4.x patch would be useful (wink, wink);-> cheers, jamal From ak@suse.de Wed Apr 7 05:37:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 05:37:16 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37CbBKO016093 for ; Wed, 7 Apr 2004 05:37:14 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id B13D64088D1; Wed, 7 Apr 2004 14:37:05 +0200 (CEST) Date: Wed, 7 Apr 2004 14:37:03 +0200 From: Andi Kleen To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: [PATCH] New version of net timestamp optimization Message-Id: <20040407143703.6af5bb71.ak@suse.de> In-Reply-To: <1081340659.15893.117.camel@jzny.localdomain> References: <20040406182941.7e759f4c.ak@suse.de> <1081340659.15893.117.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4534 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 411 Lines: 11 On 07 Apr 2004 08:24:19 -0400 jamal wrote: > The patch does look clean and attractive. I havent had time toi play > with it myself - but given the way gettimeofday has been torturing me > i will at some point. Also if you have time a 2.4.x patch would be Thanks. All feedback I received so far was positive. I hope DaveM will merge it soon. I don't have plans to work on 2.4 anymore. -Andi From bhartin@straus-frank.com Wed Apr 7 06:43:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 06:43:35 -0700 (PDT) Received: from kkuy210.securesites.net (kkuy210.securesites.net [204.2.109.192]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37DhVKO018127 for ; Wed, 7 Apr 2004 06:43:31 -0700 Received: from edp12 (209-99-2-226.sat.texas.net [209.99.2.226] (may be forged)) by kkuy210.securesites.net (8.12.6p3/8.12.6) with ESMTP id i37DhPkH071491; Wed, 7 Apr 2004 13:43:25 GMT (envelope-from bhartin@straus-frank.com) Date: Wed, 7 Apr 2004 08:43:18 -0500 (CDT) From: bhartin@straus-frank.com X-X-Sender: bhartin@edp12.straus-frank.int To: Francois Romieu cc: netdev@oss.sgi.com Subject: Re: r8169, 2.6.2-rc2, Sager 4780 laptop In-Reply-To: <20040407112607.A17476@electric-eye.fr.zoreil.com> Message-ID: References: <20040126235559.A3832@electric-eye.fr.zoreil.com> <20040405002028.A8125@electric-eye.fr.zoreil.com> <20040407001815.C7833@electric-eye.fr.zoreil.com> <20040407013841.A7978@electric-eye.fr.zoreil.com> <20040407112607.A17476@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4535 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bhartin@straus-frank.com Precedence: bulk X-list: netdev Content-Length: 776 Lines: 23 I started a ping, and unplugged the network cable. I got the 'r8169: eth0: Reset RTL8169s PHY' message about once every 11 to 15 seconds. Once plugged back in, the connection recovered immediately. I repeated this several times. So, it's still generating the messages, but they seem to be harmless (at least for the few minutes I was testing this). On Wed, 7 Apr 2004, Francois Romieu wrote: > bhartin@straus-frank.com : > [...] > > The patch resolved the PHY messages, and I stress-tested the networking > > again--it's still stable. > > Does it allow the link to be recovered if the cable is removed/plugde ? > > -- > Ueimor > Bradley Hartin - bhartin@straus-frank.com Communications and Network Administrator Straus-Frank Company From Robert.Olsson@data.slu.se Wed Apr 7 08:11:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 08:11:41 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37FBaKO021740 for ; Wed, 7 Apr 2004 08:11:37 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i37FBNNv009423; Wed, 7 Apr 2004 17:11:25 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 8747E903D5; Wed, 7 Apr 2004 17:11:23 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16500.6683.524806.636701@robur.slu.se> Date: Wed, 7 Apr 2004 17:11:23 +0200 To: ntop-misc@fuji.unipi.it Cc: Robert Olsson , hadi@cyberus.ca, Jason Lunz , netdev@oss.sgi.com Subject: [Ntop-misc] Re: Luca Deri's paper: Improving Passive Packet Capture: Beyond Device Polling In-Reply-To: <4073A7AF.5060401@ntop.org> References: <20040330142354.GA17671@outblaze.com> <1081033332.2037.61.camel@jzny.localdomain> <1081261126.1047.6.camel@jzny.localdomain> <16498.52551.712261.214192@robur.slu.se> <4073A7AF.5060401@ntop.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4536 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 365 Lines: 14 Luca Deri writes: > Robert, > yes I run into this problems and I have solved using the RTIRQ kernel patch. Hello! I found a reference in your mail... After a very quick look I don't see how RTIRQ can solve any of softirq/userland balance problems. It's seems to deal with getting realtime-like interrupt responsiveness during load. Cheers. --ro From Robert.Olsson@data.slu.se Wed Apr 7 09:12:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 09:13:13 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37GCpKO027325 for ; Wed, 7 Apr 2004 09:12:52 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i37FNSNv014708; Wed, 7 Apr 2004 17:23:28 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 4CA44903D5; Wed, 7 Apr 2004 17:23:28 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16500.7408.240318.350476@robur.slu.se> Date: Wed, 7 Apr 2004 17:23:28 +0200 To: dipankar@in.ibm.com Cc: Robert Olsson , Andrea Arcangeli , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <20040406195249.GA4581@in.ibm.com> References: <20040330133000.098761e2.davem@redhat.com> <20040330213742.GL3808@dualathlon.random> <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> <16497.37720.607342.193544@robur.slu.se> <20040405212220.GH4003@in.ibm.com> <16498.43191.733850.18276@robur.slu.se> <20040406195249.GA4581@in.ibm.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4537 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 2215 Lines: 48 Dipankar Sarma writes: > Robert, you should try out rs-throttle-rcu.patch. The idea is that > we don't run too many callbacks in a single rcu. In my setup, > at 100kpps, I see as many as 30000 rcu callbacks in a single > tasklet handler. That is likely hurting even the softirq-only > RCU grace periods. Setting rcupdate.maxbatch=4 will do only 4 per > tasklet thus providing more quiescent points to the system. Hello! No bad things happens, lots of overflows and drop in performance and the userland app can stall for 32 sec. We seems to spin in softirq to much and still don't get things done. Cheers. --ro Without patch ============= Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 5568922 8823920 8823920 4431083 46 0 0 0 BRU eth1 1500 0 45 0 0 0 5567591 0 0 0 BRU eth2 1500 0 5742954 8731915 8731915 4257049 42 0 0 0 BRU eth3 1500 0 46 0 0 0 5741617 0 0 0 BRU /proc/net/rt_cache_stat [overflow 3:rd last] 00009e0f 004809d5 000cefee 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000c8c85 000c8725 0000053a 00000533 0085c6f6 00000000 00009e0f 004aa57e 000cfc18 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000c4920 000c43b8 00000541 0000053d 0088c546 00000000 With patch =========== RCU: maxbatch = 4, plugticks = 0 Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 922395 9792296 9792296 9077609 45 0 0 0 BRU eth1 1500 0 47 0 0 0 909892 0 0 0 BRU eth2 1500 0 922586 9789706 9789706 9077417 45 0 0 0 BRU eth3 1500 0 48 0 0 0 909992 0 0 0 BRU /proc/net/rt_cache_stat [overflow 3:rd last] 00000018 000bc6e3 00024c63 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00021077 0001df2f 000030e2 000030d9 0011ed4d 00000000 00000018 000bc27d 0002518a 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00020d75 0001dbba 0000313c 00003135 00122fc9 00000000 From bcrl@kvack.org Wed Apr 7 09:29:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 09:29:25 -0700 (PDT) Received: from mailvirt.achilles.net (mailvirt.achilles.net [209.151.1.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37GTNKO029941 for ; Wed, 7 Apr 2004 09:29:24 -0700 Received: from localhost (localhost [127.0.0.1]) by mailvirt.achilles.net (Postfix) with ESMTP id 8A0F8158DB0 for ; Wed, 7 Apr 2004 12:29:10 -0400 (EDT) Received: from mailvirt.achilles.net ([127.0.0.1]) by localhost (mailvirt.achilles.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23691-24 for ; Wed, 7 Apr 2004 12:29:10 -0400 (EDT) Received: from 221.1.151.209.achilles.net (H38.C133.B246.tor.eicat.ca [66.246.133.38]) by mailvirt.achilles.net (Postfix) with ESMTP id DF7FB158C9A for ; Wed, 7 Apr 2004 12:29:09 -0400 (EDT) Received: from 221.1.151.209.achilles.net (localhost.localdomain [127.0.0.1]) by 221.1.151.209.achilles.net (8.12.8/8.12.8) with ESMTP id i37GTDlf022770 for ; Wed, 7 Apr 2004 12:29:13 -0400 Received: (from bcrl@localhost) by 221.1.151.209.achilles.net (8.12.8/8.12.8/Submit) id i37GTDXP022768 for netdev@oss.sgi.com; Wed, 7 Apr 2004 12:29:13 -0400 X-Authentication-Warning: 221.1.151.209.achilles.net: bcrl set sender to bcrl@kvack.org using -f Date: Wed, 7 Apr 2004 12:29:12 -0400 From: Benjamin LaHaise To: netdev@oss.sgi.com Subject: [PATCH] eliminate useless divert message Message-ID: <20040407162912.GA21868@achilles.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at achilles.net X-archive-position: 4538 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bcrl@kvack.org Precedence: bulk X-list: netdev Content-Length: 949 Lines: 36 [sorry if this is a dupe, but the original wasn't going through.] Hello folks, Debugging some ppp code has made me truely despise divert's log messages. This patch deletes both the allocate and delete printks. -ben -- "Time is what keeps everything from happening all at once." -- John Wheeler ===== net/core/dv.c 1.9 vs edited ===== --- 1.9/net/core/dv.c Sun Sep 28 19:47:07 2003 +++ edited/net/core/dv.c Tue Apr 6 22:17:12 2004 @@ -53,9 +53,6 @@ int alloc_size = (sizeof(struct divert_blk) + 3) & ~3; if (dev->type == ARPHRD_ETHER) { - printk(KERN_DEBUG "divert: allocating divert_blk for %s\n", - dev->name); - dev->divert = (struct divert_blk *) kmalloc(alloc_size, GFP_KERNEL); if (dev->divert == NULL) { @@ -67,9 +64,6 @@ } dev_hold(dev); } else { - printk(KERN_DEBUG "divert: not allocating divert_blk for non-ethernet device %s\n", - dev->name); - dev->divert = NULL; } return 0; From chas@cmf.nrl.navy.mil Wed Apr 7 09:58:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 09:58:03 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37Gw0KO032283 for ; Wed, 7 Apr 2004 09:58:01 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i37CB3gK020805; Wed, 7 Apr 2004 08:11:03 -0400 (EDT) Message-Id: <200404071211.i37CB3gK020805@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: [nicstar] using dev_alloc_skb() (reported by "Johnston, Jayme" ) Reply-To: chas3@users.sourceforge.net Date: Wed, 07 Apr 2004 08:11:04 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4539 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 7578 Lines: 206 the nicstar driver has typically used alloc_skb() to get its i/o buffers. since these buffers are likely to be passed to the network stack at some point it should probably be using dev_alloc_skb(). this patches fixes a crash during pppoatm operation when an unchecked skb_push() operates on a buffer returned by the nicstar. please apply to 2.6 and 2.4 kernels (and if at all possible could i get this in the soon to be released 2.4.26 kernel?) thanks! # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1331.3.2 -> 1.1331.3.3 # drivers/atm/nicstar.c 1.14 -> 1.15 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/06 chas@relax.cmf.nrl.navy.mil 1.1331.3.3 # [ATM]: [nicstar] using dev_alloc_skb() (reported by "Johnston, Jayme" ) # -------------------------------------------- # diff -Nru a/drivers/atm/nicstar.c b/drivers/atm/nicstar.c --- a/drivers/atm/nicstar.c Wed Apr 7 08:02:14 2004 +++ b/drivers/atm/nicstar.c Wed Apr 7 08:02:14 2004 @@ -760,7 +760,7 @@ for (j = 0; j < NUM_HB; j++) { struct sk_buff *hb; - hb = alloc_skb(NS_HBUFSIZE, GFP_KERNEL); + hb = __dev_alloc_skb(NS_HBUFSIZE, GFP_KERNEL); if (hb == NULL) { printk("nicstar%d: can't allocate %dth of %d huge buffers.\n", @@ -780,7 +780,7 @@ for (j = 0; j < NUM_LB; j++) { struct sk_buff *lb; - lb = alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); + lb = __dev_alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); if (lb == NULL) { printk("nicstar%d: can't allocate %dth of %d large buffers.\n", @@ -816,7 +816,7 @@ for (j = 0; j < NUM_SB; j++) { struct sk_buff *sb; - sb = alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); + sb = __dev_alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); if (sb == NULL) { printk("nicstar%d: can't allocate %dth of %d small buffers.\n", @@ -1318,7 +1318,7 @@ card->index); for (i = 0; i < card->sbnr.min; i++) { - sb = alloc_skb(NS_SMSKBSIZE, GFP_ATOMIC); + sb = dev_alloc_skb(NS_SMSKBSIZE); if (sb == NULL) { writel(readl(card->membase + CFG) & ~NS_CFG_EFBIE, card->membase + CFG); @@ -1344,7 +1344,7 @@ card->index); for (i = 0; i < card->lbnr.min; i++) { - lb = alloc_skb(NS_LGSKBSIZE, GFP_ATOMIC); + lb = dev_alloc_skb(NS_LGSKBSIZE); if (lb == NULL) { writel(readl(card->membase + CFG) & ~NS_CFG_EFBIE, card->membase + CFG); @@ -2167,7 +2167,7 @@ cell = skb->data; for (i = ns_rsqe_cellcount(rsqe); i; i--) { - if ((sb = alloc_skb(NS_SMSKBSIZE, GFP_ATOMIC)) == NULL) + if ((sb = dev_alloc_skb(NS_SMSKBSIZE)) == NULL) { printk("nicstar%d: Can't allocate buffers for aal0.\n", card->index); @@ -2399,7 +2399,7 @@ if (hb == NULL) /* No buffers in the queue */ { - hb = alloc_skb(NS_HBUFSIZE, GFP_ATOMIC); + hb = dev_alloc_skb(NS_HBUFSIZE); if (hb == NULL) { printk("nicstar%d: Out of huge buffers.\n", card->index); @@ -2413,7 +2413,7 @@ else if (card->hbpool.count < card->hbnr.min) { struct sk_buff *new_hb; - if ((new_hb = alloc_skb(NS_HBUFSIZE, GFP_ATOMIC)) != NULL) + if ((new_hb = dev_alloc_skb(NS_HBUFSIZE)) != NULL) { skb_queue_tail(&card->hbpool.queue, new_hb); card->hbpool.count++; @@ -2424,14 +2424,14 @@ if (--card->hbpool.count < card->hbnr.min) { struct sk_buff *new_hb; - if ((new_hb = alloc_skb(NS_HBUFSIZE, GFP_ATOMIC)) != NULL) + if ((new_hb = dev_alloc_skb(NS_HBUFSIZE)) != NULL) { skb_queue_tail(&card->hbpool.queue, new_hb); card->hbpool.count++; } if (card->hbpool.count < card->hbnr.min) { - if ((new_hb = alloc_skb(NS_HBUFSIZE, GFP_ATOMIC)) != NULL) + if ((new_hb = dev_alloc_skb(NS_HBUFSIZE)) != NULL) { skb_queue_tail(&card->hbpool.queue, new_hb); card->hbpool.count++; @@ -2513,7 +2513,7 @@ do { - sb = alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); + sb = __dev_alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); if (sb == NULL) break; skb_queue_tail(&card->sbpool.queue, sb); @@ -2536,7 +2536,7 @@ do { - lb = alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); + lb = __dev_alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); if (lb == NULL) break; skb_queue_tail(&card->lbpool.queue, lb); @@ -2555,7 +2555,7 @@ while (card->hbpool.count < card->hbnr.init) { - hb = alloc_skb(NS_HBUFSIZE, GFP_KERNEL); + hb = __dev_alloc_skb(NS_HBUFSIZE, GFP_KERNEL); if (hb == NULL) break; skb_queue_tail(&card->hbpool.queue, hb); @@ -2627,7 +2627,7 @@ if (card->sbfqc < card->sbnr.init) { struct sk_buff *new_sb; - if ((new_sb = alloc_skb(NS_SMSKBSIZE, GFP_ATOMIC)) != NULL) + if ((new_sb = dev_alloc_skb(NS_SMSKBSIZE)) != NULL) { skb_queue_tail(&card->sbpool.queue, new_sb); skb_reserve(new_sb, NS_AAL0_HEADER); @@ -2639,7 +2639,7 @@ #endif /* NS_USE_DESTRUCTORS */ { struct sk_buff *new_sb; - if ((new_sb = alloc_skb(NS_SMSKBSIZE, GFP_ATOMIC)) != NULL) + if ((new_sb = dev_alloc_skb(NS_SMSKBSIZE)) != NULL) { skb_queue_tail(&card->sbpool.queue, new_sb); skb_reserve(new_sb, NS_AAL0_HEADER); @@ -2660,7 +2660,7 @@ if (card->lbfqc < card->lbnr.init) { struct sk_buff *new_lb; - if ((new_lb = alloc_skb(NS_LGSKBSIZE, GFP_ATOMIC)) != NULL) + if ((new_lb = dev_alloc_skb(NS_LGSKBSIZE)) != NULL) { skb_queue_tail(&card->lbpool.queue, new_lb); skb_reserve(new_lb, NS_SMBUFSIZE); @@ -2672,7 +2672,7 @@ #endif /* NS_USE_DESTRUCTORS */ { struct sk_buff *new_lb; - if ((new_lb = alloc_skb(NS_LGSKBSIZE, GFP_ATOMIC)) != NULL) + if ((new_lb = dev_alloc_skb(NS_LGSKBSIZE)) != NULL) { skb_queue_tail(&card->lbpool.queue, new_lb); skb_reserve(new_lb, NS_SMBUFSIZE); @@ -2866,7 +2866,7 @@ { struct sk_buff *sb; - sb = alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); + sb = __dev_alloc_skb(NS_SMSKBSIZE, GFP_KERNEL); if (sb == NULL) return -ENOMEM; skb_queue_tail(&card->sbpool.queue, sb); @@ -2880,7 +2880,7 @@ { struct sk_buff *lb; - lb = alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); + lb = __dev_alloc_skb(NS_LGSKBSIZE, GFP_KERNEL); if (lb == NULL) return -ENOMEM; skb_queue_tail(&card->lbpool.queue, lb); @@ -2909,7 +2909,7 @@ { struct sk_buff *hb; - hb = alloc_skb(NS_HBUFSIZE, GFP_KERNEL); + hb = __dev_alloc_skb(NS_HBUFSIZE, GFP_KERNEL); if (hb == NULL) return -ENOMEM; ns_grab_int_lock(card, flags); From vda@port.imtp.ilyichevsk.odessa.ua Wed Apr 7 11:19:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 11:19:28 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37IJJKO003734 for ; Wed, 7 Apr 2004 11:19:23 -0700 Received: (qmail 28987 invoked by alias); 7 Apr 2004 18:19:16 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 07 Apr 2004 18:19:16 -0000 From: Denis Vlasenko To: Jeff Garzik , Francois Romieu , andreas@fjortis.info Subject: Re: [PATCH] 2.4, 2.6 patchset for fealnx.c Date: Wed, 7 Apr 2004 21:19:10 +0300 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com References: <200404052217.35883.vda@port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200404052217.35883.vda@port.imtp.ilyichevsk.odessa.ua> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200404072116.54908.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 4540 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 462 Lines: 17 On Monday 05 April 2004 22:18, Denis Vlasenko wrote: > I almost emptied my TODO. Hurray ;) > > 2.4 patches are stress-tested. As before, I used UDP flood > in extremely memory constrained box (kernel OOM killed > several processes while I ran test). Looks ok. > > 2.6.5 kernel have console-related slab corruption issues > on test machine, can't stress-test patches. Compile and boot > tested only. Pings work. No problems reported. Jeff please apply. -- vda From rddunlap@osdl.org Wed Apr 7 11:38:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 11:38:06 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37Ic2KO004888 for ; Wed, 7 Apr 2004 11:38:03 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i37ICJ205445; Wed, 7 Apr 2004 11:12:19 -0700 Date: Wed, 7 Apr 2004 11:08:19 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik Subject: [janitor] remove concat. with __FUNCTION__ (drivers/net/) (V2) Message-Id: <20040407110819.61f55064.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4541 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 4746 Lines: 101 Hi, Previous patch had a small problem. This patch replaces the previous version. I can/will send a relative/differential diff if you want/need it. Problem: On Tue, 2004-04-06 at 14:45, Randy.Dunlap wrote: > From: Tony Breeds > > "concatenation of string literals with __FUNCTION__ is deprecated" > -#define TRACE_ENTER(devname) DEBUG(2, "%s: -> " __FUNCTION__ "()\n", devname); > -#define TRACE_EXIT(devname) DEBUG(2, "%s: <- " __FUNCTION__ "()\n", devname); > +#define TRACE_ENTER(devname) DEBUG(2, "%s: -> %s()\n", __FUNCTION__, devname); > +#define TRACE_EXIT(devname) DEBUG(2, "%s: <- %s()\n", __FUNCTION__, devname); | Hi. This isn't the same. It should be: | | +#define TRACE_ENTER(devname) DEBUG(2, "%s: -> %s()\n", devname, __FUNCTION__); | +#define TRACE_EXIT(devname) DEBUG(2, "%s: <- %s()\n", devname, __FUNCTION__ ); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/gt96100eth.c | 2 +- drivers/net/irda/smsc-ircc2.c | 6 +++--- drivers/net/irda/via-ircc.c | 2 +- drivers/net/wireless/orinoco.h | 4 ++-- 4 files changed, 7 insertions(+), 7 deletions(-) diff -puN drivers/net/gt96100eth.c~remove_concat_FUNCTION_drivers drivers/net/gt96100eth.c --- linux-265-kj1/drivers/net/gt96100eth.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/gt96100eth.c 2004-04-05 13:31:23.000000000 -0700 @@ -1212,7 +1212,7 @@ gt96100_rx(struct net_device *dev, u32 s cmdstat, nextOut); if (cmdstat & (u32)rxOwn) { - //err(__FUNCTION__ ": device owns descriptor!\n"); + //err("%s: device owns descriptor!\n", __FUNCTION__); // DMA is not finished updating descriptor??? // Leave and come back later to pick-up where // we left off. diff -puN drivers/net/irda/smsc-ircc2.c~remove_concat_FUNCTION_drivers drivers/net/irda/smsc-ircc2.c --- linux-265-kj1/drivers/net/irda/smsc-ircc2.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/irda/smsc-ircc2.c 2004-04-05 13:31:23.000000000 -0700 @@ -1429,7 +1429,7 @@ static irqreturn_t smsc_ircc_interrupt(i } if (iir & IRCC_IIR_ACTIVE_FRAME) { - /*printk(KERN_WARNING __FUNCTION__ "(): Active Frame\n");*/ + /*printk(KERN_WARNING "%s(): Active Frame\n", __FUNCTION__);*/ } /* Enable interrupts again */ @@ -1995,7 +1995,7 @@ static int __init smsc_ircc_look_for_chi while(address->cfg_base){ cfg_base = address->cfg_base; - /*printk(KERN_WARNING __FUNCTION__ "(): probing: 0x%02x for: 0x%02x\n", cfg_base, address->type);*/ + /*printk(KERN_WARNING "%s(): probing: 0x%02x for: 0x%02x\n", __FUNCTION__, cfg_base, address->type);*/ if( address->type & SMSCSIO_TYPE_FDC){ type = "FDC"; @@ -2040,7 +2040,7 @@ static int __init smsc_superio_flat(cons outb(SMSCSIOFLAT_UARTMODE0C_REG, cfgbase); mode = inb(cfgbase+1); - /*printk(KERN_WARNING __FUNCTION__ "(): mode: 0x%02x\n", mode);*/ + /*printk(KERN_WARNING "%s(): mode: 0x%02x\n", __FUNCTION__, mode);*/ if(!(mode & SMSCSIOFLAT_UART2MODE_VAL_IRDA)) WARNING("%s(): IrDA not enabled\n", __FUNCTION__); diff -puN drivers/net/irda/via-ircc.c~remove_concat_FUNCTION_drivers drivers/net/irda/via-ircc.c --- linux-265-kj1/drivers/net/irda/via-ircc.c~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/irda/via-ircc.c 2004-04-05 13:31:23.000000000 -0700 @@ -360,7 +360,7 @@ static __devinit int via_ircc_open(int i /* Reserve the ioports that we need */ if (!request_region(self->io.fir_base, self->io.fir_ext, driver_name)) { -// WARNING(__FUNCTION__ "(), can't get iobase of 0x%03x\n",self->io.fir_base); +// WARNING("%s(), can't get iobase of 0x%03x\n", __FUNCTION__, self->io.fir_base); err = -ENODEV; goto err_out1; } diff -puN drivers/net/wireless/orinoco.h~remove_concat_FUNCTION_drivers drivers/net/wireless/orinoco.h --- linux-265-kj1/drivers/net/wireless/orinoco.h~remove_concat_FUNCTION_drivers 2004-04-05 13:31:23.000000000 -0700 +++ linux-265-kj1-rddunlap/drivers/net/wireless/orinoco.h 2004-04-05 13:31:23.000000000 -0700 @@ -125,8 +125,8 @@ extern int orinoco_debug; #define DEBUG(n, args...) do { } while (0) #endif /* ORINOCO_DEBUG */ -#define TRACE_ENTER(devname) DEBUG(2, "%s: -> " __FUNCTION__ "()\n", devname); -#define TRACE_EXIT(devname) DEBUG(2, "%s: <- " __FUNCTION__ "()\n", devname); +#define TRACE_ENTER(devname) DEBUG(2, "%s: -> %s()\n", devname, __FUNCTION__); +#define TRACE_EXIT(devname) DEBUG(2, "%s: <- %s()\n", devname, __FUNCTION__); extern struct net_device *alloc_orinocodev(int sizeof_card, int (*hard_reset)(struct orinoco_private *)); From dipankar@in.ibm.com Wed Apr 7 12:51:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 12:51:48 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37JpZKO009986 for ; Wed, 7 Apr 2004 12:51:35 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i37JoY67783452; Wed, 7 Apr 2004 15:50:34 -0400 Received: from soprano.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i37Jog9D110584; Wed, 7 Apr 2004 15:50:54 -0400 Received: by soprano.in.ibm.com (Postfix, from userid 500) id E38837C52A; Thu, 8 Apr 2004 01:18:43 +0530 (IST) Date: Thu, 8 Apr 2004 01:18:43 +0530 From: Dipankar Sarma To: Robert Olsson Cc: Andrea Arcangeli , "David S. Miller" , kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs Message-ID: <20040407194842.GA4548@in.ibm.com> Reply-To: dipankar@in.ibm.com References: <20040331171023.GA4543@in.ibm.com> <16491.4593.718724.277551@robur.slu.se> <20040331203750.GB4543@in.ibm.com> <20040331212817.GQ2143@dualathlon.random> <20040331214342.GD4543@in.ibm.com> <16497.37720.607342.193544@robur.slu.se> <20040405212220.GH4003@in.ibm.com> <16498.43191.733850.18276@robur.slu.se> <20040406195249.GA4581@in.ibm.com> <16500.7408.240318.350476@robur.slu.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline In-Reply-To: <16500.7408.240318.350476@robur.slu.se> User-Agent: Mutt/1.4.1i X-archive-position: 4542 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dipankar@in.ibm.com Precedence: bulk X-list: netdev Content-Length: 7477 Lines: 231 --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Apr 07, 2004 at 05:23:28PM +0200, Robert Olsson wrote: > Dipankar Sarma writes: > > > Robert, you should try out rs-throttle-rcu.patch. The idea is that > > we don't run too many callbacks in a single rcu. In my setup, > > at 100kpps, I see as many as 30000 rcu callbacks in a single > > tasklet handler. That is likely hurting even the softirq-only > > RCU grace periods. Setting rcupdate.maxbatch=4 will do only 4 per > > tasklet thus providing more quiescent points to the system. > > Hello! > > No bad things happens, lots of overflows and drop in performance > and the userland app can stall for 32 sec. We seems to spin in > softirq to much and still don't get things done. Argh!! Andrea, this means that throttling rcu callbacks with back-to-back rcu tasklets for better scheduling latency is bad for this kind of DoS situation. I think we will have to address the softirq limiting question. That said, Robert, one last experiment - if you are running UP, can you try the following patchset (should apply on top of vanilla 2.6.x) ? This implements direct invocation of callbacks instead of waiting for rcu grace periods in UP kernel. This would be a good data point to understand what happens. Thanks Dipankar --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rcu-rt-latency.patch" A new interface call_rcu_rt() allows the updates to happen immediately in a UP kernel. This assumes that no RCU protection is needed against interrupts. include/linux/rcupdate.h | 14 ++++++++++++++ 1 files changed, 14 insertions(+) diff -puN include/linux/rcupdate.h~rcu-rt-latency include/linux/rcupdate.h --- linux-2.6.0-test8-rcu/include/linux/rcupdate.h~rcu-rt-latency 2003-11-30 19:54:09.000000000 +0530 +++ linux-2.6.0-test8-rcu-dipankar/include/linux/rcupdate.h 2003-11-30 21:39:50.000000000 +0530 @@ -131,6 +131,20 @@ extern void rcu_check_callbacks(int cpu, extern void FASTCALL(call_rcu(struct rcu_head *head, void (*func)(void *arg), void *arg)); extern void synchronize_kernel(void); +#if !defined(CONFIG_SMP) && defined(CONFIG_PREEMPT) +static inline void call_rcu_rt(struct rcu_head *head, + void (*func)(void *arg), void *arg) +{ + func(arg); +} +#else +static inline void call_rcu_rt(struct rcu_head *head, + void (*func)(void *arg), void *arg) +{ + call_rcu(head, func, arg); +} +#endif + #endif /* __KERNEL__ */ #endif /* __LINUX_RCUPDATE_H */ _ --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dcache-rcu-latency.patch" Use the new call_rcu_rt() primitive to immediately free dentries to slab for UP/CONFIG_PREEMPT. This should improve scheduling latencies by reducing rcu callback processing time. fs/dcache.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN fs/dcache.c~dcache-rcu-latency fs/dcache.c --- linux-2.6.0-test8-rcu/fs/dcache.c~dcache-rcu-latency 2003-11-30 21:22:02.000000000 +0530 +++ linux-2.6.0-test8-rcu-dipankar/fs/dcache.c 2003-11-30 21:22:16.000000000 +0530 @@ -78,7 +78,7 @@ static void d_free(struct dentry *dentry { if (dentry->d_op && dentry->d_op->d_release) dentry->d_op->d_release(dentry); - call_rcu(&dentry->d_rcu, d_callback, dentry); + call_rcu_rt(&dentry->d_rcu, d_callback, dentry); } /* _ --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rtcache-rcu-latency.patch" include/linux/rcupdate.h | 2 ++ net/ipv4/route.c | 26 +++++++++++++------------- 2 files changed, 15 insertions(+), 13 deletions(-) diff -puN net/ipv4/route.c~rtcache-rcu-latency net/ipv4/route.c --- linux-2.6.0-test8-rcu/net/ipv4/route.c~rtcache-rcu-latency 2003-12-15 01:42:09.000000000 +0530 +++ linux-2.6.0-test8-rcu-dipankar/net/ipv4/route.c 2003-12-15 02:15:13.000000000 +0530 @@ -223,11 +223,11 @@ static struct rtable *rt_cache_get_first struct rt_cache_iter_state *st = seq->private; for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) { - rcu_read_lock(); + rcu_read_lock_bh(); r = rt_hash_table[st->bucket].chain; if (r) break; - rcu_read_unlock(); + rcu_read_unlock_bh(); } return r; } @@ -239,10 +239,10 @@ static struct rtable *rt_cache_get_next( smp_read_barrier_depends(); r = r->u.rt_next; while (!r) { - rcu_read_unlock(); + rcu_read_unlock_bh(); if (--st->bucket < 0) break; - rcu_read_lock(); + rcu_read_lock_bh(); r = rt_hash_table[st->bucket].chain; } return r; @@ -278,7 +278,7 @@ static void *rt_cache_seq_next(struct se static void rt_cache_seq_stop(struct seq_file *seq, void *v) { if (v && v != SEQ_START_TOKEN) - rcu_read_unlock(); + rcu_read_unlock_bh(); } static int rt_cache_seq_show(struct seq_file *seq, void *v) @@ -436,13 +436,13 @@ static struct file_operations rt_cpu_seq static __inline__ void rt_free(struct rtable *rt) { - call_rcu(&rt->u.dst.rcu_head, (void (*)(void *))dst_free, &rt->u.dst); + call_rcu_rt(&rt->u.dst.rcu_head, (void (*)(void *))dst_free, &rt->u.dst); } static __inline__ void rt_drop(struct rtable *rt) { ip_rt_put(rt); - call_rcu(&rt->u.dst.rcu_head, (void (*)(void *))dst_free, &rt->u.dst); + call_rcu_rt(&rt->u.dst.rcu_head, (void (*)(void *))dst_free, &rt->u.dst); } static __inline__ int rt_fast_clean(struct rtable *rth) @@ -2216,7 +2216,7 @@ int __ip_route_output_key(struct rtable hash = rt_hash_code(flp->fl4_dst, flp->fl4_src ^ (flp->oif << 5), flp->fl4_tos); - rcu_read_lock(); + rcu_read_lock_bh(); for (rth = rt_hash_table[hash].chain; rth; rth = rth->u.rt_next) { smp_read_barrier_depends(); if (rth->fl.fl4_dst == flp->fl4_dst && @@ -2232,13 +2232,13 @@ int __ip_route_output_key(struct rtable dst_hold(&rth->u.dst); rth->u.dst.__use++; RT_CACHE_STAT_INC(out_hit); - rcu_read_unlock(); + rcu_read_unlock_bh(); *rp = rth; return 0; } RT_CACHE_STAT_INC(out_hlist_search); } - rcu_read_unlock(); + rcu_read_unlock_bh(); return ip_route_output_slow(rp, flp); } @@ -2448,7 +2448,7 @@ int ip_rt_dump(struct sk_buff *skb, str if (h < s_h) continue; if (h > s_h) s_idx = 0; - rcu_read_lock(); + rcu_read_lock_bh(); for (rt = rt_hash_table[h].chain, idx = 0; rt; rt = rt->u.rt_next, idx++) { smp_read_barrier_depends(); @@ -2459,12 +2459,12 @@ int ip_rt_dump(struct sk_buff *skb, str cb->nlh->nlmsg_seq, RTM_NEWROUTE, 1) <= 0) { dst_release(xchg(&skb->dst, NULL)); - rcu_read_unlock(); + rcu_read_unlock_bh(); goto done; } dst_release(xchg(&skb->dst, NULL)); } - rcu_read_unlock(); + rcu_read_unlock_bh(); } done: diff -puN include/linux/rcupdate.h~rtcache-rcu-latency include/linux/rcupdate.h --- linux-2.6.0-test8-rcu/include/linux/rcupdate.h~rtcache-rcu-latency 2003-12-15 02:15:22.000000000 +0530 +++ linux-2.6.0-test8-rcu-dipankar/include/linux/rcupdate.h 2003-12-22 23:31:14.588119016 +0530 @@ -123,6 +123,8 @@ static inline int rcu_pending(int cpu) #define rcu_read_lock() preempt_disable() #define rcu_read_unlock() preempt_enable() +#define rcu_read_lock_bh() local_bh_disable() +#define rcu_read_unlock_bh() local_bh_enable() extern void rcu_init(void); extern void rcu_check_callbacks(int cpu, int user); _ --9amGYk9869ThD9tj-- From romieu@fr.zoreil.com Wed Apr 7 14:17:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 14:17:36 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37LHSKO013316 for ; Wed, 7 Apr 2004 14:17:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i37LFTgf025879; Wed, 7 Apr 2004 23:15:29 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i37LFT9f025878; Wed, 7 Apr 2004 23:15:29 +0200 Date: Wed, 7 Apr 2004 23:15:29 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 2/3] 2.6.5-netdev2 - r8169 update Message-ID: <20040407231529.B25867@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040407231332.A25021@electric-eye.fr.zoreil.com> <20040407231444.A25867@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040407231444.A25867@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Apr 07, 2004 at 11:14:44PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 743 Lines: 23 The irq handler must not return 1 when the status register is null during the firt iteration. drivers/net/r8169.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/r8169.c~r8169-irq-handler-status drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-irq-handler-status 2004-04-07 22:56:57.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-07 22:58:21.000000000 +0200 @@ -1540,8 +1540,8 @@ rtl8169_interrupt(int irq, void *dev_ins do { status = RTL_R16(IntrStatus); - /* h/w no longer present (hotplug?) or major error, bail */ - if (status == 0xFFFF) + /* hotplug/major error/no more work/shared irq */ + if ((status == 0xFFFF) || !status) break; handled = 1; _ From romieu@fr.zoreil.com Wed Apr 7 14:17:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 14:17:37 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37LHSKO013314 for ; Wed, 7 Apr 2004 14:17:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i37LDYgf025866; Wed, 7 Apr 2004 23:13:34 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i37LDXF3025865; Wed, 7 Apr 2004 23:13:33 +0200 Date: Wed, 7 Apr 2004 23:13:32 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, Srihari Vijayaraghavan Subject: [patch 0/3] 2.6.5-netdev2 - r8169 update Message-ID: <20040407231332.A25021@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040405235545.A20805@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 05, 2004 at 11:55:45PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4544 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 541 Lines: 19 The following serie of patches applies against 2.6.5 + 2.6.5-netdev2. - r8169-missing-static.patch missing 'static' qualifiers. - r8169-irq-handler-status.patch fix status code bogosity for the irq handler if the r8169 interrupt is shared. - r8169-mod_timer.patch missing "jiffies +" in mod_timer(). The link recovery code seems to work again. An update of the patch against 2.6.5 for the whole driver is available for testers at: http://www.fr.zoreil.com/people/francois/misc/20040407-2.6.5-r8169.c-stable.patch -- Ueimor From romieu@fr.zoreil.com Wed Apr 7 14:17:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 14:17:36 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37LHSKO013315 for ; Wed, 7 Apr 2004 14:17:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i37LEigf025872; Wed, 7 Apr 2004 23:14:44 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i37LEiHX025871; Wed, 7 Apr 2004 23:14:44 +0200 Date: Wed, 7 Apr 2004 23:14:44 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com, Srihari Vijayaraghavan Subject: [patch 1/3] 2.6.5-netdev2 - r8169 update Message-ID: <20040407231444.A25867@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040407231332.A25021@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040407231332.A25021@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Apr 07, 2004 at 11:13:32PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4543 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1246 Lines: 42 Missing 'static' qualifier for functions. drivers/net/r8169.c | 9 +++------ 1 files changed, 3 insertions(+), 6 deletions(-) diff -puN drivers/net/r8169.c~r8169-missing-static drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-missing-static 2004-04-07 22:51:10.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-07 22:51:10.000000000 +0200 @@ -357,8 +357,7 @@ static const unsigned int rtl8169_rx_con #define PHY_Cap_100_Half_Or_Less PHY_Cap_100_Half | PHY_Cap_10_Full_Or_Less #define PHY_Cap_100_Full_Or_Less PHY_Cap_100_Full | PHY_Cap_100_Half_Or_Less -void -mdio_write(void *ioaddr, int RegAddr, int value) +static void mdio_write(void *ioaddr, int RegAddr, int value) { int i; @@ -375,8 +374,7 @@ mdio_write(void *ioaddr, int RegAddr, in } } -int -mdio_read(void *ioaddr, int RegAddr) +static int mdio_read(void *ioaddr, int RegAddr) { int i, value = -1; @@ -1677,8 +1675,7 @@ rtl8169_set_rx_mode(struct net_device *d * * Get TX/RX statistics for rtl8169 */ -struct net_device_stats * -rtl8169_get_stats(struct net_device *dev) +static struct net_device_stats *rtl8169_get_stats(struct net_device *dev) { struct rtl8169_private *tp = dev->priv; void *ioaddr = tp->mmio_addr; _ From romieu@fr.zoreil.com Wed Apr 7 14:17:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 14:17:37 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37LHSKO013317 for ; Wed, 7 Apr 2004 14:17:31 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i37LGBgf025883; Wed, 7 Apr 2004 23:16:11 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i37LGBm6025882; Wed, 7 Apr 2004 23:16:11 +0200 Date: Wed, 7 Apr 2004 23:16:11 +0200 From: Francois Romieu To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch 3/3] 2.6.5-netdev2 - r8169 update Message-ID: <20040407231611.C25867@electric-eye.fr.zoreil.com> References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040407231332.A25021@electric-eye.fr.zoreil.com> <20040407231444.A25867@electric-eye.fr.zoreil.com> <20040407231529.B25867@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040407231529.B25867@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Wed, Apr 07, 2004 at 11:15:29PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4545 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 610 Lines: 21 mod_timer() expects an absolute time, not a relative offset. drivers/net/r8169.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/net/r8169.c~r8169-mod_timer drivers/net/r8169.c --- linux-2.6.5/drivers/net/r8169.c~r8169-mod_timer 2004-04-07 22:59:15.000000000 +0200 +++ linux-2.6.5-fr/drivers/net/r8169.c 2004-04-07 22:59:15.000000000 +0200 @@ -617,7 +617,7 @@ static void rtl8169_phy_timer(unsigned l } } - mod_timer(timer, RTL8169_PHY_TIMEOUT); + mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); } static inline void rtl8169_delete_timer(struct net_device *dev) _ From brazilnut@us.ibm.com Wed Apr 7 15:52:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 15:52:18 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37MqBKO017331 for ; Wed, 7 Apr 2004 15:52:14 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i37Mq40o290016; Wed, 7 Apr 2004 18:52:04 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i37Mq25u113872; Wed, 7 Apr 2004 16:52:02 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i37MpZ219567; Wed, 7 Apr 2004 15:51:35 -0700 From: Don Fry Message-Id: <200404072251.i37MpZ219567@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.4.26-rc2] pcnet32 fix hang/crash with loopback test To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 7 Apr 2004 15:51:34 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4547 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7313 Lines: 241 If the pcnet32 interface is not up, running the loopback test may hang or crash the system. This patch provided by Jim Lewis fixes that problem. Tested on ia32 and ppc systems. --- linux-2.4.26-rc2/drivers/net/orig.pcnet32.c Wed Apr 7 15:21:05 2004 +++ linux-2.4.26-rc2/drivers/net/pcnet32.c Wed Apr 7 15:36:56 2004 @@ -351,6 +351,7 @@ static void pcnet32_interrupt(int, void *, struct pt_regs *); static int pcnet32_close(struct net_device *); static struct net_device_stats *pcnet32_get_stats(struct net_device *); +static void pcnet32_load_multicast(struct net_device *dev); static void pcnet32_set_multicast_list(struct net_device *); static int pcnet32_ioctl(struct net_device *, struct ifreq *, int); static int mdio_read(struct net_device *dev, int phy_id, int reg_num); @@ -607,32 +608,40 @@ struct pcnet32_access *a = &lp->a; /* access to registers */ ulong ioaddr = dev->base_addr; /* card base I/O address */ struct sk_buff *skb; /* sk buff */ - int x, y, i; /* counters */ + int x, i; /* counters */ int numbuffs = 4; /* number of TX/RX buffers and descs */ u16 status = 0x8300; /* TX ring status */ + u16 teststatus; /* test of ring status */ int rc; /* return code */ int size; /* size of packets */ unsigned char *packet; /* source packet data */ static int data_len = 60; /* length of source packets */ unsigned long flags; + unsigned long ticks; *data1 = 1; /* status of test, default to fail */ rc = 1; /* default to fail */ + if (netif_running(dev)) + pcnet32_close(dev); + spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x7904); - netif_stop_queue(dev); + /* Reset the PCNET32 */ + lp->a.reset (ioaddr); + + /* switch pcnet32 to 32bit mode */ + lp->a.write_bcr (ioaddr, 20, 2); + + lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); + lp->init_block.filter[0] = 0; + lp->init_block.filter[1] = 0; /* purge & init rings but don't actually restart */ pcnet32_restart(dev, 0x0000); lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ - x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ - x = x | 0x00000002; - a->write_bcr(ioaddr, 32, x); - /* Initialize Transmit buffers. */ size = data_len + 15; for (x=0; xtx_skbuff[x] = skb; lp->tx_ring[x].length = le16_to_cpu(-skb->len); - lp->tx_ring[x].misc = 0x00000000; + lp->tx_ring[x].misc = 0; - /* put DA and SA into the skb */ - for (i=0; i<12; i++) - *packet++ = 0xff; + /* put DA and SA into the skb */ + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; /* type */ *packet++ = 0x08; *packet++ = 0x06; /* packet number */ *packet++ = x; /* fill packet with data */ - for (y=0; ytx_dma_addr[x] = pci_map_single(lp->pci_dev, skb->data, skb->len, PCI_DMA_TODEVICE); @@ -668,20 +679,41 @@ } } - lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ - spin_unlock_irqrestore(&lp->lock, flags); + x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ + x = x | 0x0002; + a->write_bcr(ioaddr, 32, x); - mdelay(50); /* wait a bit */ + lp->a.write_csr (ioaddr, 15, 0x0044); /* set int loopback in CSR15 */ - spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + teststatus = le16_to_cpu(0x8000); + lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ + /* Check status of descriptors */ + for (x=0; xrx_ring[x].status & teststatus) && (ticks < 200)) { + spin_unlock_irqrestore(&lp->lock, flags); + mdelay(1); + spin_lock_irqsave(&lp->lock, flags); + rmb(); + ticks++; + } + if (ticks == 200) { + if (netif_msg_hw(lp)) + printk("%s: Desc %d failed to reset!\n",dev->name,x); + break; + } + } + + lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + wmb(); if (netif_msg_hw(lp) && netif_msg_pktdata(lp)) { printk(KERN_DEBUG "%s: RX loopback packets:\n", dev->name); for (x=0; xname, x); - skb=lp->rx_skbuff[x]; + skb = lp->rx_skbuff[x]; for (i=0; idata+i)); } @@ -714,17 +746,17 @@ a->write_csr(ioaddr, 15, (x & ~0x0044)); /* reset bits 6 and 2 */ x = a->read_bcr(ioaddr, 32); /* reset internal loopback */ - x = x & ~0x00000002; + x = x & ~0x0002; a->write_bcr(ioaddr, 32, x); - pcnet32_restart(dev, 0x0042); /* resume normal operation */ - - netif_wake_queue(dev); - - /* Clear interrupts, and set interrupt enable. */ - lp->a.write_csr(ioaddr, 0, 0x7940); spin_unlock_irqrestore(&lp->lock, flags); + if (netif_running(dev)) { + pcnet32_open(dev); + } else { + lp->a.write_bcr (ioaddr, 20, 4); /* return to 16bit mode */ + } + return(rc); } /* end pcnet32_loopback_test */ @@ -955,7 +987,7 @@ memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); for (i = 0; i < 6; i++) - printk(" %2.2x", dev->dev_addr[i] ); + printk(" %2.2x", dev->dev_addr[i]); if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */ i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ @@ -1113,6 +1145,7 @@ u16 val; int i; int rc; + unsigned long flags; if (dev->irq == 0 || request_irq(dev->irq, &pcnet32_interrupt, @@ -1120,6 +1153,7 @@ return -EAGAIN; } + spin_lock_irqsave(&lp->lock, flags); /* Check for a valid station address */ if (!is_valid_ether_addr(dev->dev_addr)) { rc = -EINVAL; @@ -1196,8 +1230,8 @@ } lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); - lp->init_block.filter[0] = 0x00000000; - lp->init_block.filter[1] = 0x00000000; + pcnet32_load_multicast(dev); + if (pcnet32_init_ring(dev)) { rc = -ENOMEM; goto err_free_ring; @@ -1227,6 +1261,7 @@ dev->name, i, (u32) (lp->dma_addr + offsetof(struct pcnet32_private, init_block)), lp->a.read_csr(ioaddr, 0)); + spin_unlock_irqrestore(&lp->lock, flags); MOD_INC_USE_COUNT; @@ -1251,6 +1286,7 @@ lp->a.write_bcr (ioaddr, 20, 4); err_free_irq: + spin_unlock_irqrestore(&lp->lock, flags); free_irq(dev->irq, dev); return rc; } @@ -1720,9 +1756,12 @@ unsigned long ioaddr = dev->base_addr; struct pcnet32_private *lp = dev->priv; int i; + unsigned long flags; netif_stop_queue(dev); + spin_lock_irqsave(&lp->lock, flags); + lp->stats.rx_missed_errors = lp->a.read_csr (ioaddr, 112); if (netif_msg_ifdown(lp)) @@ -1738,6 +1777,8 @@ */ lp->a.write_bcr (ioaddr, 20, 4); + spin_unlock_irqrestore(&lp->lock, flags); + free_irq(dev->irq, dev); /* free all allocated skbuffs */ -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Wed Apr 7 15:51:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 15:51:19 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37Mp8KO017216 for ; Wed, 7 Apr 2004 15:51:14 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i37MowSk716680; Wed, 7 Apr 2004 18:50:58 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i37MpF9D101626; Wed, 7 Apr 2004 18:51:15 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i37MoPC19556; Wed, 7 Apr 2004 15:50:25 -0700 From: Don Fry Message-Id: <200404072250.i37MoPC19556@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.5] pcnet32 fix hang/crash with loopback test To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 7 Apr 2004 15:50:25 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4546 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7335 Lines: 246 If the pcnet32 interface is not up, running the loopback test may hang or crash the system. This patch provided by Jim Lewis fixes that problem. Tested on ia32 and ppc systems. --- linux-2.6.5/drivers/net/led.pcnet32.c Tue Apr 6 14:52:41 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Wed Apr 7 14:45:15 2004 @@ -360,6 +360,7 @@ static irqreturn_t pcnet32_interrupt(int, void *, struct pt_regs *); static int pcnet32_close(struct net_device *); static struct net_device_stats *pcnet32_get_stats(struct net_device *); +static void pcnet32_load_multicast(struct net_device *dev); static void pcnet32_set_multicast_list(struct net_device *); static int pcnet32_ioctl(struct net_device *, struct ifreq *, int); static void pcnet32_watchdog(struct net_device *); @@ -627,34 +628,40 @@ struct pcnet32_access *a = &lp->a; /* access to registers */ ulong ioaddr = dev->base_addr; /* card base I/O address */ struct sk_buff *skb; /* sk buff */ - int x, y, i; /* counters */ + int x, i; /* counters */ int numbuffs = 4; /* number of TX/RX buffers and descs */ u16 status = 0x8300; /* TX ring status */ + u16 teststatus; /* test of ring status */ int rc; /* return code */ int size; /* size of packets */ unsigned char *packet; /* source packet data */ static int data_len = 60; /* length of source packets */ unsigned long flags; + unsigned long ticks; *data1 = 1; /* status of test, default to fail */ rc = 1; /* default to fail */ + if (netif_running(dev)) + pcnet32_close(dev); + spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x7904); - del_timer_sync(&lp->watchdog_timer); + /* Reset the PCNET32 */ + lp->a.reset (ioaddr); - netif_stop_queue(dev); + /* switch pcnet32 to 32bit mode */ + lp->a.write_bcr (ioaddr, 20, 2); + + lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); + lp->init_block.filter[0] = 0; + lp->init_block.filter[1] = 0; /* purge & init rings but don't actually restart */ pcnet32_restart(dev, 0x0000); lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ - x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ - x = x | 0x00000002; - a->write_bcr(ioaddr, 32, x); - /* Initialize Transmit buffers. */ size = data_len + 15; for (x=0; xtx_skbuff[x] = skb; lp->tx_ring[x].length = le16_to_cpu(-skb->len); - lp->tx_ring[x].misc = 0x00000000; + lp->tx_ring[x].misc = 0; - /* put DA and SA into the skb */ - for (i=0; i<12; i++) - *packet++ = 0xff; + /* put DA and SA into the skb */ + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; /* type */ *packet++ = 0x08; *packet++ = 0x06; /* packet number */ *packet++ = x; /* fill packet with data */ - for (y=0; ytx_dma_addr[x] = pci_map_single(lp->pci_dev, skb->data, skb->len, PCI_DMA_TODEVICE); @@ -690,20 +699,41 @@ } } - lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ - spin_unlock_irqrestore(&lp->lock, flags); + x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ + x = x | 0x0002; + a->write_bcr(ioaddr, 32, x); - mdelay(50); /* wait a bit */ + lp->a.write_csr (ioaddr, 15, 0x0044); /* set int loopback in CSR15 */ - spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + teststatus = le16_to_cpu(0x8000); + lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ + /* Check status of descriptors */ + for (x=0; xrx_ring[x].status & teststatus) && (ticks < 200)) { + spin_unlock_irqrestore(&lp->lock, flags); + mdelay(1); + spin_lock_irqsave(&lp->lock, flags); + rmb(); + ticks++; + } + if (ticks == 200) { + if (netif_msg_hw(lp)) + printk("%s: Desc %d failed to reset!\n",dev->name,x); + break; + } + } + + lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + wmb(); if (netif_msg_hw(lp) && netif_msg_pktdata(lp)) { printk(KERN_DEBUG "%s: RX loopback packets:\n", dev->name); for (x=0; xname, x); - skb=lp->rx_skbuff[x]; + skb = lp->rx_skbuff[x]; for (i=0; idata+i)); } @@ -736,19 +766,17 @@ a->write_csr(ioaddr, 15, (x & ~0x0044)); /* reset bits 6 and 2 */ x = a->read_bcr(ioaddr, 32); /* reset internal loopback */ - x = x & ~0x00000002; + x = x & ~0x0002; a->write_bcr(ioaddr, 32, x); - pcnet32_restart(dev, 0x0042); /* resume normal operation */ - - netif_wake_queue(dev); - - mod_timer(&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT); - - /* Clear interrupts, and set interrupt enable. */ - lp->a.write_csr(ioaddr, 0, 0x7940); spin_unlock_irqrestore(&lp->lock, flags); + if (netif_running(dev)) { + pcnet32_open(dev); + } else { + lp->a.write_bcr (ioaddr, 20, 4); /* return to 16bit mode */ + } + return(rc); } /* end pcnet32_loopback_test */ @@ -1056,7 +1084,7 @@ if (pcnet32_debug & NETIF_MSG_PROBE) { for (i = 0; i < 6; i++) - printk(" %2.2x", dev->dev_addr[i] ); + printk(" %2.2x", dev->dev_addr[i]); /* Version 0x2623 and 0x2624 */ if (((chip_version + 1) & 0xfffe) == 0x2624) { @@ -1244,6 +1272,7 @@ u16 val; int i; int rc; + unsigned long flags; if (dev->irq == 0 || request_irq(dev->irq, &pcnet32_interrupt, @@ -1251,6 +1280,7 @@ return -EAGAIN; } + spin_lock_irqsave(&lp->lock, flags); /* Check for a valid station address */ if (!is_valid_ether_addr(dev->dev_addr)) { rc = -EINVAL; @@ -1331,8 +1361,8 @@ } lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); - lp->init_block.filter[0] = 0x00000000; - lp->init_block.filter[1] = 0x00000000; + pcnet32_load_multicast(dev); + if (pcnet32_init_ring(dev)) { rc = -ENOMEM; goto err_free_ring; @@ -1371,6 +1401,7 @@ offsetof(struct pcnet32_private, init_block)), lp->a.read_csr(ioaddr, 0)); + spin_unlock_irqrestore(&lp->lock, flags); return 0; /* Always succeed */ @@ -1393,6 +1424,7 @@ lp->a.write_bcr (ioaddr, 20, 4); err_free_irq: + spin_unlock_irqrestore(&lp->lock, flags); free_irq(dev->irq, dev); return rc; } @@ -1885,11 +1917,14 @@ unsigned long ioaddr = dev->base_addr; struct pcnet32_private *lp = dev->priv; int i; + unsigned long flags; del_timer_sync(&lp->watchdog_timer); netif_stop_queue(dev); + spin_lock_irqsave(&lp->lock, flags); + lp->stats.rx_missed_errors = lp->a.read_csr (ioaddr, 112); if (netif_msg_ifdown(lp)) @@ -1905,6 +1940,8 @@ */ lp->a.write_bcr (ioaddr, 20, 4); + spin_unlock_irqrestore(&lp->lock, flags); + free_irq(dev->irq, dev); /* free all allocated skbuffs */ -- Don Fry brazilnut@us.ibm.com From alex@pilosoft.com Wed Apr 7 20:36:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 07 Apr 2004 20:36:08 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i383a6KO001994 for ; Wed, 7 Apr 2004 20:36:07 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i383a2518840 for ; Wed, 7 Apr 2004 23:36:02 -0400 Date: Wed, 7 Apr 2004 23:36:02 -0400 (EDT) From: alex@pilosoft.com To: netdev@oss.sgi.com Subject: tc feature request/bounty Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4548 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 1069 Lines: 30 Currently, linux tc has very useful concept of a 'index' for a given policy. However, I need to have policers on multiple hosts to share the same index (and thus, know and police the aggregate traffic across a set of routers). I'd like to be able to share tc policers across a set of boxes. Unfortunately, I'm not knowledgeable enough myself to implement that, but I can throw some money at the pool and hope someone picks it up. ;) Proposed design: Userland daemon that polls kernel tc structure every X milliseconds and broadcasts current bps rate (assuming we are using ewma) to a set of IP addresses. Configuration would have list of indices and list of IP addresses these indices are broadcast to. Kernel changes: Add netlink interface to look up/modify (by "injecting" traffic) policer's structures (interface to tcf_police_lookup and tcf_police_dump). Adding external traffic to policer structures is somewhat tricky, but I'm sure it is possible. At this point, I only care about EWMA, which isn't all that hard. Budget and bounty: 300$ -alex From kuznet@ms2.inr.ac.ru Thu Apr 8 06:29:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 06:29:39 -0700 (PDT) Received: from yakov.inr.ac.ru ([194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38DTUKO027286 for ; Thu, 8 Apr 2004 06:29:31 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id RAA16178; Thu, 8 Apr 2004 17:29:13 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200404081329.RAA16178@yakov.inr.ac.ru> Subject: Re: route cache DoS testing and softirqs To: Robert.Olsson@data.slu.se (Robert Olsson) Date: Thu, 8 Apr 2004 17:29:13 +0400 (MSD) Cc: dipankar@in.ibm.com, Robert.Olsson@data.slu.se (Robert Olsson), andrea@suse.de (Andrea Arcangeli), davem@redhat.com (David S. Miller), kuznet@ms2.inr.ac.ru, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org In-Reply-To: <16498.43191.733850.18276@robur.slu.se> from "Robert Olsson" at áÐÒ 06, 2004 02:55:19 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4555 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 624 Lines: 16 Hello! > setup. I've done a little experimental patch so *all* softirq's are run via > ksoftirqd. BTW what's about performance in this extremal situation? Also, Robert, let's count the numbers again. With this change you should have latency much less 100msec when priority of ksoftirqd is high. So, rcu problem must be solved at current flow rates. This enforces me to suspect we have another source of overflows. F.e. one silly place could be that you set gc_min_interval via sysctl, which uses second resolution (yup :-(). With one second you get maximal ip_rt_max_size/1 second flow rate, it is _not_ a lot. Alexey From kuznet@ms2.inr.ac.ru Thu Apr 8 06:38:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 06:38:40 -0700 (PDT) Received: from yakov.inr.ac.ru ([194.67.69.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38DcbKO030138 for ; Thu, 8 Apr 2004 06:38:38 -0700 Received: (from kuznet@localhost) by yakov.inr.ac.ru (8.6.13/ANK) id RAA16267; Thu, 8 Apr 2004 17:38:27 +0400 From: kuznet@ms2.inr.ac.ru Message-Id: <200404081338.RAA16267@yakov.inr.ac.ru> Subject: Re: route cache DoS testing and softirqs To: andrea@suse.de (Andrea Arcangeli) Date: Thu, 8 Apr 2004 17:38:27 +0400 (MSD) Cc: kuznet@ms2.inr.ac.ru, Robert.Olsson@data.slu.se (Robert Olsson), dipankar@in.ibm.com (Dipankar Sarma), davem@redhat.com (David S. Miller), linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org In-Reply-To: <20040401131657.GB18585@dualathlon.random> from "Andrea Arcangeli" at áÐÒ 01, 2004 03:16:57 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4556 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kuznet@ms2.inr.ac.ru Precedence: bulk X-list: netdev Content-Length: 528 Lines: 13 Hello! > This sounds reasonable. However as a start I was thinking at having > hardirq run only the softirq they posted actively, and local_bh_enable > run only the softirq that have been posted by the critical section (not > from hardirqs happening on top of it). To all that I remember Ingo insisted that the run from local_bh_enable() is necessary for softirqs triggered by hardirqs while softirqs are disabled. Otherwise he observed random delays and redundant scheduler activity breaking at least tux fast path. Alexey From Robert.Olsson@data.slu.se Thu Apr 8 07:07:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 07:07:44 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38E7eKO032342 for ; Thu, 8 Apr 2004 07:07:41 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i38E7VNv029659; Thu, 8 Apr 2004 16:07:31 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 695BE903D5; Thu, 8 Apr 2004 16:07:31 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16501.23715.401825.10935@robur.slu.se> Date: Thu, 8 Apr 2004 16:07:31 +0200 To: kuznet@ms2.inr.ac.ru Cc: Robert.Olsson@data.slu.se (Robert Olsson), dipankar@in.ibm.com, andrea@suse.de (Andrea Arcangeli), davem@redhat.com (David S. Miller), linux-kernel@vger.kernel.org, netdev@oss.sgi.com, paulmck@us.ibm.com, akpm@osdl.org Subject: Re: route cache DoS testing and softirqs In-Reply-To: <200404081329.RAA16178@yakov.inr.ac.ru> References: <16498.43191.733850.18276@robur.slu.se> <200404081329.RAA16178@yakov.inr.ac.ru> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4557 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1241 Lines: 35 kuznet@ms2.inr.ac.ru writes: > BTW what's about performance in this extremal situation? First I used the patch to defer all softirq's to ksoftirq with call_rcu_bh() patch. Sofar this has been the best combination giving both pure sofirq performance and also good response from the userland apps. I also tried other TCP apps netperf and could note any performance degradation which I was expecting. > Also, Robert, let's count the numbers again. With this change you should > have latency much less 100msec when priority of ksoftirqd is high. > So, rcu problem must be solved at current flow rates. > This enforces me to suspect we have another source of overflows. Certainly. I said to Dipankar we should not expect all overflows to disappear the setup I use now. But the call_rcu_bh() patch improved things so it cured some latency caused by RCU. But I don't think we can do much better now in terms dst overflow. > F.e. one silly place could be that you set gc_min_interval via sysctl, I should not... > which uses second resolution (yup :-(). With one second you get maximal > ip_rt_max_size/1 second flow rate, it is _not_ a lot. From /proc gc_min_interval = 0 max_size = 262144 Cheers. --ro From ak@muc.de Thu Apr 8 10:19:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 10:19:02 -0700 (PDT) Received: from zero.aec.at (Jali_Hane@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38HIvKO009801 for ; Thu, 8 Apr 2004 10:18:58 -0700 Received: from averell.firstfloor.org.muc.de (Habeeb_Suleiman@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i38HIfD00712; Thu, 8 Apr 2004 19:18:45 +0200 To: "Mathieu Giguere" cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. References: <1IJuR-8qH-39@gated-at.bofh.it> From: Andi Kleen Date: Thu, 08 Apr 2004 19:18:41 +0200 In-Reply-To: <1IJuR-8qH-39@gated-at.bofh.it> (Mathieu Giguere's message of "Thu, 08 Apr 2004 17:21:01 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4558 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: netdev Content-Length: 1057 Lines: 26 "Mathieu Giguere" writes: [you should probably discuss that on netdev@oss.sgi.com instead, cc'ed] > We currently looking for a multi-FIB, scalable routing table in the > million of entries, no routing cache for IPv4 and IPv6. We want a IP stack No routing cache? Doesn't sound like a good idea. > that can have a log(n) (or better) insertion/deletion and lookup > performance. Predictable performance, even in the million of entries. And even more vast overkill for most linux users than the existing routing code already is. Linux has at least the beginnings of a pluggable FIB interface (fib_table), which has slightly bit rotted, but probably not too bad. I would suggest you clean that up, make the existing hash table really optional and then you can just plug in anything you want. > I join a patch with the fib_hash in IPv4 replace with a patricia tree > ready for multi-FIB base on a 2.4.22 kernel. This is the beginning of a > long cleanup. What do you consider dirty in the current stack? -Andi From shemminger@osdl.org Thu Apr 8 11:07:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 11:07:22 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38I77KO011477 for ; Thu, 8 Apr 2004 11:07:10 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i38I6r223226; Thu, 8 Apr 2004 11:06:53 -0700 Date: Thu, 8 Apr 2004 11:06:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, Jeff Garzik Subject: [PATCH] etherdevice.h -- make constant args Message-Id: <20040408110653.003174e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4559 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: 912 Lines: 26 Rather than forcing cast in some new validation code in the bridge; please fix a couple of inline functions should have "const" on args. diff -Nru a/include/linux/etherdevice.h b/include/linux/etherdevice.h --- a/include/linux/etherdevice.h Thu Apr 8 11:03:52 2004 +++ b/include/linux/etherdevice.h Thu Apr 8 11:03:52 2004 @@ -40,7 +40,9 @@ unsigned char *haddr); extern struct net_device *alloc_etherdev(int sizeof_priv); -static inline void eth_copy_and_sum (struct sk_buff *dest, unsigned char *src, int len, int base) +static inline void eth_copy_and_sum (struct sk_buff *dest, + const unsigned char *src, + int len, int base) { memcpy (dest->data, src, len); } @@ -55,7 +57,7 @@ * * Return true if the address is valid. */ -static inline int is_valid_ether_addr( u8 *addr ) +static inline int is_valid_ether_addr( const u8 *addr ) { const char zaddr[6] = {0,}; From shemminger@osdl.org Thu Apr 8 11:08:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 11:09:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38I8kKO011828 for ; Thu, 8 Apr 2004 11:08:46 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i38I8Z223427; Thu, 8 Apr 2004 11:08:35 -0700 Date: Thu, 8 Apr 2004 11:08:34 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] dummy -- support hardware address Message-Id: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4560 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: 1102 Lines: 40 Dummy device comes in handy for testing, but it always has address of all zero's which isn't a valid ethernet address. This generates a simple fake address and allows changing the address. diff -Nru a/drivers/net/dummy.c b/drivers/net/dummy.c --- a/drivers/net/dummy.c Thu Apr 8 11:03:02 2004 +++ b/drivers/net/dummy.c Thu Apr 8 11:03:02 2004 @@ -86,6 +86,15 @@ return dev->priv; } + +static int dummy_set_address(struct net_device *dev, void *p) +{ + struct sockaddr *sa = p; + + memcpy(dev->dev_addr, sa->sa_data, dev->addr_len); + return 0; +} + static struct net_device **dummies; /* Number of dummy devices to be set up by this module. */ @@ -101,6 +110,16 @@ if (!dev_dummy) return -ENOMEM; + + /* Generate intial fake hardware address */ + dev_dummy->dev_addr[0] = 0x00; + dev_dummy->dev_addr[1] = 0xdd; + dev_dummy->dev_addr[2] = 0xdd; + dev_dummy->dev_addr[3] = index >> 16; + dev_dummy->dev_addr[4] = index >> 8; + dev_dummy->dev_addr[5] = index; + + dev_dummy->set_mac_address = dummy_set_address; if ((err = register_netdev(dev_dummy))) { free_netdev(dev_dummy); From mathieu.giguere@ericsson.com Thu Apr 8 11:11:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 11:11:54 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38IBgKO012224 for ; Thu, 8 Apr 2004 11:11:42 -0700 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i38IAgLc024448; Thu, 8 Apr 2004 13:10:42 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <23S8ZXX0>; Thu, 8 Apr 2004 13:10:46 -0500 Received: from D4SF2B21 ([142.133.72.3]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2RBY6K62; Thu, 8 Apr 2004 14:10:43 -0400 Message-ID: <012201c41d94$cee1b400$0348858e@D4SF2B21> From: "Mathieu Giguere" To: "Andi Kleen" Cc: , References: <1IJuR-8qH-39@gated-at.bofh.it> Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. Date: Thu, 8 Apr 2004 14:10:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4561 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Mathieu.Giguere@ericsson.ca Precedence: bulk X-list: netdev Content-Length: 2629 Lines: 64 Hi, Why we need a routing cache? A patricia tree or radix tree is not fast enough with the kind of memory speed we have in PC technologies now??? The main goal to remove the routing cache is to avoid to have 4096 routes limitation + all problem of the cache is not flush correclty when default route/next-hop for a particular route are change in the middle of a TCP connection and are not consider at all. Also, when the routing cache is finally flush, all the information about the PMTU of the other entries are lost and must be rebuild. So it's a lot of rebuilding of information for nothing when you have a lot of peer to talk with. It's may look like overkill for a home user, but for commercial server, 4k routes can be really fast exhauted. For us, we talking more about million of routes in the system. Also, the patch I provide exploit already the plug/and/pray of the fib. But doesn't give at all the flexibility to remove the _unclean_ hack: the routing cache. What is dirty form the current implementation, quick example spagetti code with goto going back at the beginning of the function in route.c in IPV6. All the mtu/pmtu put in the cache entries instead in the fib himself. Just to name few examples. /mathieu ----- Original Message ----- From: "Andi Kleen" To: "Mathieu Giguere" Cc: ; Sent: Thursday, April 08, 2004 1:18 PM Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. > "Mathieu Giguere" writes: > > [you should probably discuss that on netdev@oss.sgi.com instead, cc'ed] > > > We currently looking for a multi-FIB, scalable routing table in the > > million of entries, no routing cache for IPv4 and IPv6. We want a IP stack > > No routing cache? Doesn't sound like a good idea. > > > that can have a log(n) (or better) insertion/deletion and lookup > > performance. Predictable performance, even in the million of entries. > > And even more vast overkill for most linux users than the existing > routing code already is. Linux has at least the beginnings of a pluggable > FIB interface (fib_table), which has slightly bit rotted, but probably > not too bad. I would suggest you clean that up, make the existing > hash table really optional and then you can just plug in anything you want. > > > I join a patch with the fib_hash in IPv4 replace with a patricia tree > > ready for multi-FIB base on a 2.4.22 kernel. This is the beginning of a > > long cleanup. > > What do you consider dirty in the current stack? > > -Andi > From alex@pilosoft.com Thu Apr 8 11:34:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 11:35:08 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38IYmKO014124 for ; Thu, 8 Apr 2004 11:34:49 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i38IYdP23696 for ; Thu, 8 Apr 2004 14:34:39 -0400 Date: Thu, 8 Apr 2004 14:34:39 -0400 (EDT) From: alex@pilosoft.com cc: netdev@oss.sgi.com Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. In-Reply-To: <012201c41d94$cee1b400$0348858e@D4SF2B21> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4562 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 2173 Lines: 40 > Why we need a routing cache? A patricia tree or radix tree is not fast > enough with the kind of memory speed we have in PC technologies now??? I absolutely agree. Rephasing Linus, "solution to slow route lookup is fast route lookup, not another kernel abstraction". > The main goal to remove the routing cache is to avoid to have 4096 > routes limitation + all problem of the cache is not flush correclty when > default route/next-hop for a particular route are change in the middle > of a TCP connection and are not consider at all. Also, when the routing > cache is finally flush, all the information about the PMTU of the other > entries are lost and must be rebuild. So it's a lot of rebuilding of > information for nothing when you have a lot of peer to talk with. Well, there is no limitation of 4096 routes in route-cache or RIB. If you change the hash size, you can have 32k routes in route-cache easily. And I have >100k routes in the RIB. > It's may look like overkill for a home user, but for commercial server, > 4k routes can be really fast exhauted. For us, we talking more about > million of routes in the system. Also, the patch I provide exploit > already the plug/and/pray of the fib. But doesn't give at all the > flexibility to remove the _unclean_ hack: the routing cache. > > What is dirty form the current implementation, quick example spagetti code > with goto going back at the beginning of the function in route.c in IPV6. > All the mtu/pmtu put in the cache entries instead in the fib himself. Just > to name few examples. Unfortunately, bunch of things in linux depend on existence of per-flow route-cache to store transient flow information. Just do 'ip -s -o route list cache'. You get arp-unreachable info, mtu, , etc. It isn't as easy as just disable out route-cache and recomputing route from RIB (even if RIB lookup was O(1)). Removal (or making route-cache optional) is extremely important to those who are running internet-connected routers. It simply does not matter that you can handle 300kpps in a single flow, when 50kpps flood of 1 packet-per-flow will kill you. Unfortunately, there's no easy solution... From davem@redhat.com Thu Apr 8 11:41:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 11:41:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38IfHKO014730 for ; Thu, 8 Apr 2004 11:41:17 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i38IZUMC000324; Thu, 8 Apr 2004 14:35:30 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i38IZUj21856; Thu, 8 Apr 2004 14:35:30 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i38IZ31n019202; Thu, 8 Apr 2004 14:35:03 -0400 Date: Thu, 8 Apr 2004 11:33:50 -0700 From: "David S. Miller" To: "Mathieu Giguere" Cc: ak@muc.de, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. Message-Id: <20040408113350.03ef5b5c.davem@redhat.com> In-Reply-To: <012201c41d94$cee1b400$0348858e@D4SF2B21> References: <1IJuR-8qH-39@gated-at.bofh.it> <012201c41d94$cee1b400$0348858e@D4SF2B21> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4563 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 592 Lines: 16 On Thu, 8 Apr 2004 14:10:43 -0400 "Mathieu Giguere" wrote: > The main goal to remove the routing cache is to avoid to have 4096 routes > limitation This 4K routes limitation is news to everyone who works on this code. When nexthop changes we _MUST_ flush PMTU etc. information because that could have changed. If however, such information is locked into the route itself, it will propagate immediately into the routing cache entry once recreated. You seem to be talking about a lot of non-problems, but this may because you're not providing enough details. From mathieu.giguere@ericsson.com Thu Apr 8 12:55:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 12:55:16 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38JtDKO021450 for ; Thu, 8 Apr 2004 12:55:13 -0700 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id i38Js9Lc015195; Thu, 8 Apr 2004 14:54:10 -0500 (CDT) Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id <23S8Z8A7>; Thu, 8 Apr 2004 14:54:13 -0500 Received: from D4SF2B21 ([142.133.72.3]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2RBY6MK8; Thu, 8 Apr 2004 15:53:50 -0400 Message-ID: <019e01c41da3$36aae260$0348858e@D4SF2B21> From: "Mathieu Giguere" To: , "David S. Miller" Cc: , Subject: RE: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. Date: Thu, 8 Apr 2004 15:53:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4564 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Mathieu.Giguere@ericsson.ca Precedence: bulk X-list: netdev Content-Length: 1868 Lines: 66 Hi, Just run the join script on your favorite 2.4 kernel. RTNETLINK answers: Cannot allocate memory RTNETLINK answers: Cannot allocate memory RTNETLINK answers: Cannot allocate memory [root@tom tmp]# ip -6 route | wc -l 4094 [root@tom tmp]# And after 4094 IPv6 routes you will the get the same. For the PMTU, the info can't be retain in the route himself. The PTMU is base on DIP not on the current network routing. So it must be kept in a separate hash struct with expire time. _BUT_ you must not flush all the entries each time a route is added or deleted like in the current implementation. /mathieu ------------------------------- #!/bin/csh echo #!/bin/sh set addr1=0 set addr2=1 while ($addr1 < 256) while ($addr2 < 256) echo ip -f inet6 route add 2000:${addr1}::${addr2}/128 dev eth0 @ addr2++ end set addr2=0 @ addr1++ end ----- Original Message ----- From: "David S. Miller" To: "Mathieu Giguere" Cc: ; ; Sent: Thursday, April 08, 2004 2:33 PM Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. > On Thu, 8 Apr 2004 14:10:43 -0400 > "Mathieu Giguere" wrote: > > > The main goal to remove the routing cache is to avoid to have 4096 routes > > limitation > > This 4K routes limitation is news to everyone who works on this > code. > > When nexthop changes we _MUST_ flush PMTU etc. information because that > could have changed. If however, such information is locked into the > route itself, it will propagate immediately into the routing cache > entry once recreated. > > You seem to be talking about a lot of non-problems, but this may because > you're not providing enough details. > From kumarkr@us.ibm.com Thu Apr 8 14:26:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 14:26:26 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38LQOKO025241 for ; Thu, 8 Apr 2004 14:26:24 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i38LJVnr104760; Thu, 8 Apr 2004 17:19:31 -0400 Received: from d03nm132.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i38LJRV3126034; Thu, 8 Apr 2004 15:19:30 -0600 Subject: RE: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. To: "Mathieu Giguere" Cc: ak@muc.de, "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 8 Apr 2004 14:16:46 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/08/2004 15:19:29 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E" X-archive-position: 4565 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10619 Lines: 278 --0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: multipart/alternative; Boundary="1__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E" --1__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: text/plain; charset=US-ASCII Hi Mathieu, It is a sysctl changable parameter, look at ip_rt_max_size or in sysctl -a for max_size. Linux supports infinite routes :-) - KK |---------+-----------------------------> | | "Mathieu Giguere" | | | | | | Sent by: | | | netdev-bounce@oss.| | | sgi.com | | | | | | | | | 04/08/2004 12:53 | | | PM | | | | |---------+-----------------------------> >--------------------------------------------------------------------------------------------------------------| | | | To: , "David S. Miller" | | cc: , | | Subject: RE: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. | | | >--------------------------------------------------------------------------------------------------------------| Hi, Just run the join script on your favorite 2.4 kernel. RTNETLINK answers: Cannot allocate memory RTNETLINK answers: Cannot allocate memory RTNETLINK answers: Cannot allocate memory [root@tom tmp]# ip -6 route | wc -l 4094 [root@tom tmp]# And after 4094 IPv6 routes you will the get the same. For the PMTU, the info can't be retain in the route himself. The PTMU is base on DIP not on the current network routing. So it must be kept in a separate hash struct with expire time. _BUT_ you must not flush all the entries each time a route is added or deleted like in the current implementation. /mathieu ------------------------------- #!/bin/csh echo #!/bin/sh set addr1=0 set addr2=1 while ($addr1 < 256) while ($addr2 < 256) echo ip -f inet6 route add 2000:${addr1}::${addr2}/128 dev eth0 @ addr2++ end set addr2=0 @ addr1++ end ----- Original Message ----- From: "David S. Miller" To: "Mathieu Giguere" Cc: ; ; Sent: Thursday, April 08, 2004 2:33 PM Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. > On Thu, 8 Apr 2004 14:10:43 -0400 > "Mathieu Giguere" wrote: > > > The main goal to remove the routing cache is to avoid to have 4096 routes > > limitation > > This 4K routes limitation is news to everyone who works on this > code. > > When nexthop changes we _MUST_ flush PMTU etc. information because that > could have changed. If however, such information is locked into the > route itself, it will propagate immediately into the routing cache > entry once recreated. > > You seem to be talking about a lot of non-problems, but this may because > you're not providing enough details. > --1__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Hi Mathieu,

It is a sysctl changable parameter, look at ip_rt_max_size or in sysctl -a for max_size.
Linux supports infinite routes :-)

- KK

Inactive hide details for "Mathieu Giguere" <Mathieu.Giguere@ericsson.ca>"Mathieu Giguere" <Mathieu.Giguere@ericsson.ca>




          "Mathieu Giguere" <Mathieu.Giguere@ericsson.ca>
          Sent by: netdev-bounce@oss.sgi.com

          04/08/2004 12:53 PM



To: <linux-kernel@vger.kernel.org>, "David S. Miller" <davem@redhat.com>
cc: <ak@muc.de>, <netdev@oss.sgi.com>
Subject: RE: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries.


Hi,

Just run the join script on your favorite 2.4 kernel.

RTNETLINK answers: Cannot allocate memory
RTNETLINK answers: Cannot allocate memory
RTNETLINK answers: Cannot allocate memory
[root@tom tmp]# ip -6 route | wc -l
4094
[root@tom tmp]#


And after 4094 IPv6 routes you will the get the same.

For the PMTU, the info can't be retain in the route himself. The PTMU
is base on DIP not on the current network routing. So it must be kept in a
separate hash struct with expire time. _BUT_ you must not flush all the
entries each time a route is added or deleted like in the current
implementation.

/mathieu


-------------------------------
#!/bin/csh
echo #!/bin/sh
set addr1=0
set addr2=1
while ($addr1 < 256)
while ($addr2 < 256)
echo ip -f inet6 route add 2000:${addr1}::${addr2}/128 dev eth0
@ addr2++
end
set addr2=0
@ addr1++
end


----- Original Message -----
From: "David S. Miller" <davem@redhat.com>
To: "Mathieu Giguere" <Mathieu.Giguere@ericsson.ca>
Cc: <ak@muc.de>; <netdev@oss.sgi.com>; <linux-kernel@vger.kernel.org>
Sent: Thursday, April 08, 2004 2:33 PM
Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of
entries.


> On Thu, 8 Apr 2004 14:10:43 -0400
> "Mathieu Giguere" <Mathieu.Giguere@ericsson.ca> wrote:
>
> > The main goal to remove the routing cache is to avoid to have 4096
routes
> > limitation
>
> This 4K routes limitation is news to everyone who works on this
> code.
>
> When nexthop changes we _MUST_ flush PMTU etc. information because that
> could have changed. If however, such information is locked into the
> route itself, it will propagate immediately into the routing cache
> entry once recreated.
>
> You seem to be talking about a lot of non-problems, but this may because
> you're not providing enough details.
>


 --1__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E-- --0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=07BBE4E3DFE73D1E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=07BBE4E3DFE73D1E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E Content-type: image/gif; name="pic00583.gif" Content-Disposition: inline; filename="pic00583.gif" Content-ID: <30__=07BBE4E3DFE73D1E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4E3DFE73D1E8f9e8a93df938690918c07BBE4E3DFE73D1E-- From davem@redhat.com Thu Apr 8 14:53:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 14:53:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38LrWKO026613 for ; Thu, 8 Apr 2004 14:53:33 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i38LrUMC004396; Thu, 8 Apr 2004 17:53:30 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i38LrTj23102; Thu, 8 Apr 2004 17:53:29 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i38Lr31n031522; Thu, 8 Apr 2004 17:53:04 -0400 Date: Thu, 8 Apr 2004 14:51:49 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] etherdevice.h -- make constant args Message-Id: <20040408145149.65831d1e.davem@redhat.com> In-Reply-To: <20040408110653.003174e3@dell_ss3.pdx.osdl.net> References: <20040408110653.003174e3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4566 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 249 Lines: 7 On Thu, 8 Apr 2004 11:06:53 -0700 Stephen Hemminger wrote: > Rather than forcing cast in some new validation code in the bridge; > please fix a couple of inline functions should have "const" on args. Applied, thanks Stephen. From davem@redhat.com Thu Apr 8 14:55:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 14:55:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38LtkKO026996 for ; Thu, 8 Apr 2004 14:55:46 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i38LtiMC004871; Thu, 8 Apr 2004 17:55:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i38Ltij23659; Thu, 8 Apr 2004 17:55:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i38LtH1n031993; Thu, 8 Apr 2004 17:55:18 -0400 Date: Thu, 8 Apr 2004 14:54:03 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] dummy -- support hardware address Message-Id: <20040408145403.34382c96.davem@redhat.com> In-Reply-To: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4567 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 353 Lines: 10 Stephen, why don't you do what usbnet does? Look at usbnet_init() where it goes: get_random_bytes (node_id, sizeof node_id); node_id [0] &= 0xfe; // clear multicast bit node_id [0] |= 0x02; // set local assignment bit (IEEE802) I distinctly remember Alan Cox saying this was the right way do this and avoid conflicts with Vendor assigned IDs. From shemminger@osdl.org Thu Apr 8 15:09:14 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 15:09:33 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38M9EKO027674 for ; Thu, 8 Apr 2004 15:09:14 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i38M91205496; Thu, 8 Apr 2004 15:09:01 -0700 Date: Thu, 8 Apr 2004 15:09:01 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] dummy -- support hardware address Message-Id: <20040408150901.0bf65235@dell_ss3.pdx.osdl.net> In-Reply-To: <20040408145403.34382c96.davem@redhat.com> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4568 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: 567 Lines: 16 On Thu, 8 Apr 2004 14:54:03 -0700 "David S. Miller" wrote: > > Stephen, why don't you do what usbnet does? Look at usbnet_init() > where it goes: > > get_random_bytes (node_id, sizeof node_id); > node_id [0] &= 0xfe; // clear multicast bit > node_id [0] |= 0x02; // set local assignment bit (IEEE802) > > I distinctly remember Alan Cox saying this was the right way > do this and avoid conflicts with Vendor assigned IDs. That would work better, just worried about draining the entropy pool when I create 1000 dummies in a test script. From christopherc@team.outblaze.com Thu Apr 8 17:44:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 17:44:11 -0700 (PDT) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i390i6KO003622 for ; Thu, 8 Apr 2004 17:44:07 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 162CD37AE0 for ; Fri, 9 Apr 2004 00:44:07 +0000 (GMT) Received: from smtp1.hk1.outblaze.com (smtp1.hk1.outblaze.com [203.86.166.80]) by corpmail.outblaze.com (Postfix) with SMTP id B8DA116DD8D for ; Fri, 9 Apr 2004 00:44:06 +0000 (GMT) Received: (qmail 9119 invoked from network); 9 Apr 2004 00:46:15 -0000 Received: from unknown (HELO outblaze.com) (christopherc@team.outblaze.com@210.177.227.130) by smtp1.hk1.outblaze.com with SMTP; 9 Apr 2004 00:46:15 -0000 Message-ID: <4075F218.90804@outblaze.com> Date: Fri, 09 Apr 2004 08:45:12 +0800 From: Christopher Chan User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: 2.6.4 e100 NAPI - dst cache overflow and network unavailability Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.25.0.2; VDF: 6.25.0.10; host: corpmail.outblaze.com) X-archive-position: 4569 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cchan@outblaze.com Precedence: bulk X-list: netdev Content-Length: 673 Lines: 16 I previously sent email to the list about seeing dst cache overflows and the kernel spewing gibberish (at which point the box usually needs to be rebooted as you'd wait a long time for the kernel to recover) to serial console. For all those cases with different values in route/max-size, route/gc_thresh and tcp_max_syn_backlog, I'd get the problems even under sufficient network load. However, I had NAPI enabled in the e100 driver then. Turning NAPI off for the e100 driver has meant that the box has now been up several days without any problems under heavy network load. I have not tried out 2.6.5 with NAPI enabled but 2.6.5 without NAPI enabled is stable. From hadi@cyberus.ca Thu Apr 8 18:06:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 08 Apr 2004 18:06:05 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39161KO006315 for ; Thu, 8 Apr 2004 18:06:01 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BBkTN-00022I-60 for netdev@oss.sgi.com; Thu, 08 Apr 2004 21:06:21 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BBkSu-0003kg-SY; Thu, 08 Apr 2004 21:05:53 -0400 Subject: RE: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. From: jamal Reply-To: hadi@cyberus.ca To: Mathieu Giguere Cc: linux-kernel@vger.kernel.org, "David S. Miller" , ak@muc.de, netdev@oss.sgi.com In-Reply-To: <019e01c41da3$36aae260$0348858e@D4SF2B21> References: <019e01c41da3$36aae260$0348858e@D4SF2B21> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081472721.1041.99.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Apr 2004 21:05:21 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4570 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2329 Lines: 80 Mathieu, What i would recommend to you is the following: Make your algorithm changes; test them, come with some perfomance numbers in comparison with what Linux already does for the same kernel version. Then you have ammunition to use for an arguement. cheers, jamal On Thu, 2004-04-08 at 15:53, Mathieu Giguere wrote: > Hi, > > Just run the join script on your favorite 2.4 kernel. > > RTNETLINK answers: Cannot allocate memory > RTNETLINK answers: Cannot allocate memory > RTNETLINK answers: Cannot allocate memory > [root@tom tmp]# ip -6 route | wc -l > 4094 > [root@tom tmp]# > > > And after 4094 IPv6 routes you will the get the same. > > For the PMTU, the info can't be retain in the route himself. The PTMU > is base on DIP not on the current network routing. So it must be kept in a > separate hash struct with expire time. _BUT_ you must not flush all the > entries each time a route is added or deleted like in the current > implementation. > > /mathieu > > > ------------------------------- > #!/bin/csh > echo #!/bin/sh > set addr1=0 > set addr2=1 > while ($addr1 < 256) > while ($addr2 < 256) > echo ip -f inet6 route add 2000:${addr1}::${addr2}/128 dev eth0 > @ addr2++ > end > set addr2=0 > @ addr1++ > end > > > ----- Original Message ----- > From: "David S. Miller" > To: "Mathieu Giguere" > Cc: ; ; > Sent: Thursday, April 08, 2004 2:33 PM > Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of > entries. > > > > On Thu, 8 Apr 2004 14:10:43 -0400 > > "Mathieu Giguere" wrote: > > > > > The main goal to remove the routing cache is to avoid to have 4096 > routes > > > limitation > > > > This 4K routes limitation is news to everyone who works on this > > code. > > > > When nexthop changes we _MUST_ flush PMTU etc. information because that > > could have changed. If however, such information is locked into the > > route itself, it will propagate immediately into the routing cache > > entry once recreated. > > > > You seem to be talking about a lot of non-problems, but this may because > > you're not providing enough details. > > > > > From cfriesen@nortelnetworks.com Fri Apr 9 00:24:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 00:24:22 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i397O5KO016545 for ; Fri, 9 Apr 2004 00:24:05 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i397Nvw06887 for ; Fri, 9 Apr 2004 03:23:58 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GXT6QP8D; Fri, 9 Apr 2004 03:23:59 -0400 Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DNVQ2BK0; Fri, 9 Apr 2004 03:23:57 -0400 Message-ID: <40764F89.8090306@nortelnetworks.com> Date: Fri, 09 Apr 2004 03:23:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: strange e1000 performance issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4571 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 928 Lines: 23 I've got a pair of dual G5s running 2.6.4. For a second gigE link we added in some Intel 82540EM cards, using the mainline e1000 driver with NAPI enabled. lspci reports the bus as 66MHz. The cards were connected together with a crossover cable. A basic UDP packet-blasting program in userspace using 64KB datagrams could only manage 47MB/s of data throughput, using 20% of a cpu. For comparison, the same program managed 108.9 MB/s with 30% cpu when using the onboard gigE ports. Also, I tried setting a larger mtu using "ip set link dev ethx mtu xxxxx". No matter what value I chose (even setting it to its default value, which should have had zero effect) it resulted in the link not being able to transfer data. Downing/upping the link didn't clear the issue, neither did unloading/reloading the driver module. It took a reboot to actually get it working again. Any ideas what's going on? Thanks, Chris From yoshfuji@linux-ipv6.org Fri Apr 9 05:04:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 05:04:58 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39C4nKO018104 for ; Fri, 9 Apr 2004 05:04:49 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id D4D8633CA5; Fri, 9 Apr 2004 21:05:10 +0900 (JST) Date: Fri, 09 Apr 2004 21:05:10 +0900 (JST) Message-Id: <20040409.210510.64268862.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] IPV6: Mark MLDv2 Report as known From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4572 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 540 Lines: 24 Hello. Mark MLDv2 Report as known ICMPv6 type. (We just ignore MLDv2 Reports on hosts as the spec says.) Same patch applies linux-2.4.x. Thanks in advance. ===== net/ipv6/icmp.c 1.47 vs edited ===== --- 1.47/net/ipv6/icmp.c Tue Feb 24 07:09:00 2004 +++ edited/net/ipv6/icmp.c Fri Apr 9 20:56:08 2004 @@ -646,6 +646,7 @@ break; case ICMPV6_MGM_REDUCTION: + case ICMPV6_MLD2_REPORT: break; default: -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ronnie_sahlberg@ozemail.com.au Fri Apr 9 06:15:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 06:15:47 -0700 (PDT) Received: from smta05.mail.ozemail.net (smta05.mail.ozemail.net [203.103.165.90]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39DFdKO025208 for ; Fri, 9 Apr 2004 06:15:42 -0700 Received: from C5043436 ([203.102.163.176]) by smta05.mail.ozemail.net with SMTP id <20040409131509.VWMN6056.smta05.mail.ozemail.net@C5043436> for ; Fri, 9 Apr 2004 13:15:09 +0000 Message-ID: <014801c41e34$d3759e50$6501010a@C5043436> From: "Ronnie Sahlberg" To: Subject: Re: IPv4 and IPv6 stack multi-FIB, scalable in the million of entries. Date: Fri, 9 Apr 2004 23:16:10 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 4573 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ronnie_sahlberg@ozemail.com.au Precedence: bulk X-list: netdev Content-Length: 828 Lines: 24 For fast routing lookups for IPv4, has anyone considered : Treat all addresses as class c networks, dont route on anything else than class c networks. Limit the number of next-hop routers to 256. With next-hop-router index 0 meaning no route to that network. Use a 16Mbyte large lookup table of bytes, where each byte represents the next hop router. Let the route to A.B.C.x re represented by the next-hop router described in table[A*65536+B*256+C] Then a route lookup would be O(1), a simple table lookup. Route insertions/deletions would take longer but anyway, the lookup would be fast, essentially a shift by 8 bits and one memory read from the table. At the cost of 16Mbyte wasted of kernel memory. Wasteful, yes, only really useful if you have enormous routing tables, can not do policy routing but fast. From ak@suse.de Fri Apr 9 08:36:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 08:36:09 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39FZwKO009015 for ; Fri, 9 Apr 2004 08:35:59 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 65F6D424297; Fri, 9 Apr 2004 17:35:50 +0200 (CEST) Date: Fri, 9 Apr 2004 17:35:54 +0200 From: Andi Kleen To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] Do lazy gettimeofday for network packets Message-Id: <20040409173554.49ecc736.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4574 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 17372 Lines: 535 This adds lazy network timestamping to 2.6.5. skb->stamp is only filled in when there is a consumer of network timestamps active in the system. On normal x86 machines (with TSC based gettimeofday) it doesn't seem to make benchmarks significantly faster, but they use a bit less CPU. It also cleans up some duplicated code in the various socket protocols, overall it deletes nearly as much code as it adds. The problems reported for earlier versions have been fixed. Please consider applying, -Andi diff -u linux-2.6.5rc3-averell/include/net/sock.h-T linux-2.6.5rc3-averell/include/net/sock.h --- linux-2.6.5rc3-averell/include/net/sock.h-T 2004-03-21 21:11:55.000000000 +0100 +++ linux-2.6.5rc3-averell/include/net/sock.h 2004-03-31 09:44:02.000000000 +0200 @@ -382,6 +382,7 @@ SOCK_LINGER, SOCK_DESTROY, SOCK_BROADCAST, + SOCK_TIMESTAMP, }; static inline void sock_set_flag(struct sock *sk, enum sock_flags flag) @@ -1023,11 +1024,33 @@ static __inline__ void sock_recv_timestamp(struct msghdr *msg, struct sock *sk, struct sk_buff *skb) { - if (sk->sk_rcvtstamp) - put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(skb->stamp), &skb->stamp); - else - sk->sk_stamp = skb->stamp; -} + struct timeval *stamp = &skb->stamp; + if (sk->sk_rcvtstamp) { + /* Race occurred between timestamp enabling and packet + receiving. Fill in the current time for now. */ + if (stamp->tv_sec == 0) + do_gettimeofday(stamp); + put_cmsg(msg, SOL_SOCKET, SO_TIMESTAMP, sizeof(struct timeval), + stamp); + } else + sk->sk_stamp = *stamp; +} + +extern atomic_t netstamp_needed; +extern void sock_enable_timestamp(struct sock *sk); +extern void sock_disable_timestamp(struct sock *sk); + +static inline void net_timestamp(struct timeval *stamp) +{ + if (atomic_read(&netstamp_needed)) + do_gettimeofday(stamp); + else { + stamp->tv_sec = 0; + stamp->tv_usec = 0; + } +} + +extern int sock_get_timestamp(struct sock *, struct timeval *); /* * Enable debug/info messages diff -u linux-2.6.5rc3-averell/include/net/neighbour.h-T linux-2.6.5rc3-averell/include/net/neighbour.h --- linux-2.6.5rc3-averell/include/net/neighbour.h-T 2004-03-21 21:11:55.000000000 +0100 +++ linux-2.6.5rc3-averell/include/net/neighbour.h 2004-04-01 23:50:41.000000000 +0200 @@ -281,6 +281,8 @@ return neigh_create(tbl, pkey, dev); } +#define LOCALLY_ENQUEUED -2 + #endif #endif diff -u linux-2.6.5rc3-averell/net/core/sock.c-T linux-2.6.5rc3-averell/net/core/sock.c --- linux-2.6.5rc3-averell/net/core/sock.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/sock.c 2004-03-31 13:45:57.000000000 +0200 @@ -328,6 +328,8 @@ case SO_TIMESTAMP: sk->sk_rcvtstamp = valbool; + if (valbool) + sock_enable_timestamp(sk); break; case SO_RCVLOWAT: @@ -642,6 +644,8 @@ sk->sk_filter = NULL; } + sock_disable_timestamp(sk); + if (atomic_read(&sk->sk_omem_alloc)) printk(KERN_DEBUG "%s: optmem leakage (%d bytes) detected.\n", __FUNCTION__, atomic_read(&sk->sk_omem_alloc)); @@ -1135,6 +1139,9 @@ sk->sk_sndtimeo = MAX_SCHEDULE_TIMEOUT; sk->sk_owner = NULL; + sk->sk_stamp.tv_sec = -1L; + sk->sk_stamp.tv_usec = -1L; + atomic_set(&sk->sk_refcnt, 1); } @@ -1160,9 +1167,42 @@ wake_up(&(sk->sk_lock.wq)); spin_unlock_bh(&(sk->sk_lock.slock)); } - EXPORT_SYMBOL(release_sock); +/* When > 0 there are consumers of rx skb time stamps */ +atomic_t netstamp_needed = ATOMIC_INIT(0); + +int sock_get_timestamp(struct sock *sk, struct timeval *userstamp) +{ + if (!sock_flag(sk, SOCK_TIMESTAMP)) + sock_enable_timestamp(sk); + if (sk->sk_stamp.tv_sec == -1) + return -ENOENT; + if (sk->sk_stamp.tv_sec == 0) + do_gettimeofday(&sk->sk_stamp); + return copy_to_user(userstamp, &sk->sk_stamp, sizeof(struct timeval)) ? + -EFAULT : 0; +} +EXPORT_SYMBOL(sock_get_timestamp); + +void sock_enable_timestamp(struct sock *sk) +{ + if (!sock_flag(sk, SOCK_TIMESTAMP)) { + sock_set_flag(sk, SOCK_TIMESTAMP); + atomic_inc(&netstamp_needed); + } +} +EXPORT_SYMBOL(sock_enable_timestamp); + +void sock_disable_timestamp(struct sock *sk) +{ + if (sock_flag(sk, SOCK_TIMESTAMP)) { + sock_reset_flag(sk, SOCK_TIMESTAMP); + atomic_dec(&netstamp_needed); + } +} +EXPORT_SYMBOL(sock_disable_timestamp); + EXPORT_SYMBOL(__lock_sock); EXPORT_SYMBOL(__release_sock); EXPORT_SYMBOL(sk_alloc); diff -u linux-2.6.5rc3-averell/net/core/dev.c-T linux-2.6.5rc3-averell/net/core/dev.c --- linux-2.6.5rc3-averell/net/core/dev.c-T 2004-03-22 01:28:39.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/dev.c 2004-03-31 09:44:02.000000000 +0200 @@ -1125,7 +1125,7 @@ void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev) { struct packet_type *ptype; - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); rcu_read_lock(); list_for_each_entry_rcu(ptype, &ptype_all, list) { @@ -1546,9 +1546,9 @@ return NET_RX_DROP; } #endif - + if (!skb->stamp.tv_sec) - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); /* * The code is rearranged so that the path is the most @@ -1710,7 +1710,7 @@ #endif if (!skb->stamp.tv_sec) - do_gettimeofday(&skb->stamp); + net_timestamp(&skb->stamp); skb_bond(skb); diff -u linux-2.6.5rc3-averell/net/core/neighbour.c-T linux-2.6.5rc3-averell/net/core/neighbour.c --- linux-2.6.5rc3-averell/net/core/neighbour.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/core/neighbour.c 2004-04-01 23:49:23.000000000 +0200 @@ -1094,7 +1094,7 @@ kfree_skb(skb); return; } - skb->stamp.tv_sec = 0; + skb->stamp.tv_sec = LOCALLY_ENQUEUED; skb->stamp.tv_usec = now + sched_next; spin_lock(&tbl->proxy_queue.lock); diff -u linux-2.6.5rc3-averell/net/ipv4/af_inet.c-T linux-2.6.5rc3-averell/net/ipv4/af_inet.c --- linux-2.6.5rc3-averell/net/ipv4/af_inet.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv4/af_inet.c 2004-03-31 09:44:02.000000000 +0200 @@ -843,11 +843,7 @@ switch (cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - err = -ENOENT; - else if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - err = -EFAULT; + err = sock_get_timestamp(sk, (struct timeval *)arg); break; case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/ipv4/arp.c-T linux-2.6.5rc3-averell/net/ipv4/arp.c --- linux-2.6.5rc3-averell/net/ipv4/arp.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv4/arp.c 2004-04-01 23:49:08.000000000 +0200 @@ -860,7 +860,7 @@ if (n) neigh_release(n); - if (skb->stamp.tv_sec == 0 || + if (skb->stamp.tv_sec == LOCALLY_ENQUEUED || skb->pkt_type == PACKET_HOST || in_dev->arp_parms->proxy_delay == 0) { arp_send(ARPOP_REPLY,ETH_P_ARP,sip,dev,tip,sha,dev->dev_addr,sha); diff -u linux-2.6.5rc3-averell/net/sunrpc/svcsock.c-T linux-2.6.5rc3-averell/net/sunrpc/svcsock.c --- linux-2.6.5rc3-averell/net/sunrpc/svcsock.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/sunrpc/svcsock.c 2004-03-31 09:44:02.000000000 +0200 @@ -591,6 +591,12 @@ /* possibly an icmp error */ dprintk("svc: recvfrom returned error %d\n", -err); } + if (skb->stamp.tv_sec == 0) { + skb->stamp.tv_sec = xtime.tv_sec; + skb->stamp.tv_usec = xtime.tv_nsec * 1000; + /* Don't enable netstamp, sunrpc doesn't + need that much accuracy */ + } svsk->sk_sk->sk_stamp = skb->stamp; set_bit(SK_DATA, &svsk->sk_flags); /* there may be more data... */ diff -u linux-2.6.5rc3-averell/net/rose/af_rose.c-T linux-2.6.5rc3-averell/net/rose/af_rose.c --- linux-2.6.5rc3-averell/net/rose/af_rose.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/rose/af_rose.c 2004-03-31 09:44:02.000000000 +0200 @@ -1269,12 +1269,8 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - return copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; - } + if (sk != NULL) + return sock_get_timestamp(sk, (struct timeval *)arg); return -EINVAL; case SIOCGIFADDR: diff -u linux-2.6.5rc3-averell/net/irda/af_irda.c-T linux-2.6.5rc3-averell/net/irda/af_irda.c --- linux-2.6.5rc3-averell/net/irda/af_irda.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/irda/af_irda.c 2004-03-31 09:44:02.000000000 +0200 @@ -1796,14 +1796,8 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - return -EFAULT; - return 0; - } + if (sk != NULL) + return sock_get_timestamp(sk, (struct timeval *)arg); return -EINVAL; case SIOCGIFADDR: diff -u linux-2.6.5rc3-averell/net/ipx/af_ipx.c-T linux-2.6.5rc3-averell/net/ipx/af_ipx.c --- linux-2.6.5rc3-averell/net/ipx/af_ipx.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipx/af_ipx.c 2004-03-31 09:44:02.000000000 +0200 @@ -1797,7 +1797,8 @@ copied); if (rc) goto out_free; - sk->sk_stamp = skb->stamp; + if (skb->stamp.tv_sec) + sk->sk_stamp = skb->stamp; msg->msg_namelen = sizeof(*sipx); @@ -1870,15 +1871,8 @@ break; case SIOCGSTAMP: rc = -EINVAL; - if (sk) { - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = -EFAULT; - if (!copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - rc = 0; - } + if (sk) + rc = sock_get_timestamp(sk, (struct timeval *)arg); break; case SIOCGIFDSTADDR: case SIOCSIFDSTADDR: diff -u linux-2.6.5rc3-averell/net/atm/ioctl.c-T linux-2.6.5rc3-averell/net/atm/ioctl.c --- linux-2.6.5rc3-averell/net/atm/ioctl.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/atm/ioctl.c 2004-03-31 09:44:02.000000000 +0200 @@ -76,12 +76,8 @@ goto done; } case SIOCGSTAMP: /* borrowed from IP */ - if (!vcc->sk->sk_stamp.tv_sec) { - error = -ENOENT; - goto done; - } - error = copy_to_user((void *)arg, &vcc->sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + error = sock_get_timestamp(vcc->sk, (struct timeval *) + arg); goto done; case ATM_SETSC: printk(KERN_WARNING "ATM_SETSC is obsolete\n"); diff -u linux-2.6.5rc3-averell/net/ax25/af_ax25.c-T linux-2.6.5rc3-averell/net/ax25/af_ax25.c --- linux-2.6.5rc3-averell/net/ax25/af_ax25.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ax25/af_ax25.c 2004-03-31 09:44:02.000000000 +0200 @@ -1694,12 +1694,7 @@ case SIOCGSTAMP: if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) { - res = -ENOENT; - break; - } - res = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + res = sock_get_timestamp(sk, (struct timeval *)arg); break; } res = -EINVAL; diff -u linux-2.6.5rc3-averell/net/ipv6/af_inet6.c-T linux-2.6.5rc3-averell/net/ipv6/af_inet6.c --- linux-2.6.5rc3-averell/net/ipv6/af_inet6.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv6/af_inet6.c 2004-03-31 09:44:02.000000000 +0200 @@ -474,13 +474,7 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - err = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)); - if (err) - return -EFAULT; - return 0; + return sock_get_timestamp(sk, (struct timeval *)arg); case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/ipv6/ndisc.c-T linux-2.6.5rc3-averell/net/ipv6/ndisc.c --- linux-2.6.5rc3-averell/net/ipv6/ndisc.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/ipv6/ndisc.c 2004-04-01 23:50:23.000000000 +0200 @@ -761,7 +761,7 @@ if (ipv6_chk_acast_addr(dev, &msg->target) || (idev->cnf.forwarding && pneigh_lookup(&nd_tbl, &msg->target, dev, 0))) { - if (skb->stamp.tv_sec != 0 && + if (skb->stamp.tv_sec != LOCALLY_ENQUEUED && skb->pkt_type != PACKET_HOST && inc != 0 && idev->nd_parms->proxy_delay != 0) { diff -u linux-2.6.5rc3-averell/net/rxrpc/transport.c-T linux-2.6.5rc3-averell/net/rxrpc/transport.c --- linux-2.6.5rc3-averell/net/rxrpc/transport.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/rxrpc/transport.c 2004-03-31 09:44:02.000000000 +0200 @@ -341,6 +341,11 @@ msg->trans = trans; msg->state = RXRPC_MSG_RECEIVED; msg->stamp = pkt->stamp; + if (msg->stamp.tv_sec == 0) { + do_gettimeofday(&msg->stamp); + if (pkt->sk) + sock_enable_timestamp(pkt->sk); + } msg->seq = ntohl(msg->hdr.seq); /* attach the packet */ diff -u linux-2.6.5rc3-averell/net/sctp/input.c-T linux-2.6.5rc3-averell/net/sctp/input.c --- linux-2.6.5rc3-averell/net/sctp/input.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/sctp/input.c 2004-03-31 09:44:02.000000000 +0200 @@ -175,6 +175,12 @@ rcvr = asoc ? &asoc->base : &ep->base; sk = rcvr->sk; + /* SCTP seems to always need a timestamp right now (FIXME) */ + if (skb->stamp.tv_sec == 0) { + do_gettimeofday(&skb->stamp); + sock_enable_timestamp(sk); + } + if (!xfrm_policy_check(sk, XFRM_POLICY_IN, skb, family)) goto discard_release; diff -u linux-2.6.5rc3-averell/net/x25/af_x25.c-T linux-2.6.5rc3-averell/net/x25/af_x25.c --- linux-2.6.5rc3-averell/net/x25/af_x25.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/x25/af_x25.c 2004-03-31 09:44:02.000000000 +0200 @@ -1206,14 +1206,10 @@ } case SIOCGSTAMP: - if (sk) { - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; - } rc = -EINVAL; + if (sk) + rc = sock_get_timestamp(sk, + (struct timeval *)arg); break; case SIOCGIFADDR: case SIOCSIFADDR: diff -u linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c-T linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c --- linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/wanrouter/af_wanpipe.c 2004-03-31 09:44:02.000000000 +0200 @@ -1765,13 +1765,7 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - err = -EFAULT; - if (!copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - err = 0; - return err; + return sock_get_timestamp(sk, (struct timeval *)arg); case SIOC_WANPIPE_CHECK_TX: diff -u linux-2.6.5rc3-averell/net/packet/af_packet.c-T linux-2.6.5rc3-averell/net/packet/af_packet.c --- linux-2.6.5rc3-averell/net/packet/af_packet.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/packet/af_packet.c 2004-03-31 09:44:02.000000000 +0200 @@ -606,6 +606,10 @@ h->tp_snaplen = snaplen; h->tp_mac = macoff; h->tp_net = netoff; + if (skb->stamp.tv_sec == 0) { + do_gettimeofday(&skb->stamp); + sock_enable_timestamp(sk); + } h->tp_sec = skb->stamp.tv_sec; h->tp_usec = skb->stamp.tv_usec; @@ -1442,13 +1446,8 @@ return put_user(amount, (int *)arg); } case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - if (copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval))) - return -EFAULT; - break; - + return sock_get_timestamp(sk, (struct timeval *)arg); + #ifdef CONFIG_INET case SIOCADDRT: case SIOCDELRT: diff -u linux-2.6.5rc3-averell/net/netrom/af_netrom.c-T linux-2.6.5rc3-averell/net/netrom/af_netrom.c --- linux-2.6.5rc3-averell/net/netrom/af_netrom.c-T 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5rc3-averell/net/netrom/af_netrom.c 2004-03-31 09:44:02.000000000 +0200 @@ -1200,17 +1200,11 @@ } case SIOCGSTAMP: - if (sk != NULL) { - if (!sk->sk_stamp.tv_sec) { - release_sock(sk); - return -ENOENT; - } - ret = copy_to_user((void *)arg, &sk->sk_stamp, sizeof(struct timeval)) ? -EFAULT : 0; - release_sock(sk); - return ret; - } + ret = -EINVAL; + if (sk != NULL) + ret = sock_get_timestamp(sk, (struct timeval *)arg); release_sock(sk); - return -EINVAL; + return ret; case SIOCGIFADDR: case SIOCSIFADDR: diff -u linux-2.6.5rc3-averell/net/appletalk/ddp.c-T linux-2.6.5rc3-averell/net/appletalk/ddp.c --- linux-2.6.5rc3-averell/net/appletalk/ddp.c-T 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5rc3-averell/net/appletalk/ddp.c 2004-03-31 09:44:02.000000000 +0200 @@ -1795,13 +1795,7 @@ break; } case SIOCGSTAMP: - if (!sk) - break; - rc = -ENOENT; - if (!sk->sk_stamp.tv_sec) - break; - rc = copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + rc = sock_get_timestamp(sk, (struct timeval *)arg); break; /* Routing */ case SIOCADDRT: diff -u linux-2.6.5rc3-averell/net/econet/af_econet.c-T linux-2.6.5rc3-averell/net/econet/af_econet.c --- linux-2.6.5rc3-averell/net/econet/af_econet.c-T 2004-03-21 21:12:01.000000000 +0100 +++ linux-2.6.5rc3-averell/net/econet/af_econet.c 2004-03-31 09:44:02.000000000 +0200 @@ -665,10 +665,8 @@ switch(cmd) { case SIOCGSTAMP: - if (!sk->sk_stamp.tv_sec) - return -ENOENT; - return copy_to_user((void *)arg, &sk->sk_stamp, - sizeof(struct timeval)) ? -EFAULT : 0; + return sock_get_timestamp(sk,(struct timeval *)arg); + case SIOCSIFADDR: case SIOCGIFADDR: return ec_dev_ioctl(sock, cmd, (void *)arg); From ak@suse.de Fri Apr 9 08:39:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 08:39:10 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39Fd1KO009732 for ; Fri, 9 Apr 2004 08:39:01 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id D389B4244AC; Fri, 9 Apr 2004 17:38:55 +0200 (CEST) Date: Fri, 9 Apr 2004 17:39:01 +0200 From: Andi Kleen To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] Force IPv6 FIB gc on device shutdown Message-Id: <20040409173901.62ebf75b.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4575 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 669 Lines: 23 A few people reported problems with shutdown complaining about lost reference counts in network devices. The problem was that the IPv6 FIB kept some device references around and only dropped it on the next GC timer run, which happens only every 10s. This patch forces a garbage collection on device shutdown. -Andi diff -u linux/net/ipv6/ndisc.c-o linux/net/ipv6/ndisc.c --- linux/net/ipv6/ndisc.c-o 2004-04-04 23:35:36.000000000 +0200 +++ linux/net/ipv6/ndisc.c 2004-04-05 15:11:07.000000000 +0200 @@ -1564,6 +1564,9 @@ neigh_changeaddr(&nd_tbl, dev); fib6_run_gc(0); break; + case NETDEV_UNREGISTER: + fib6_run_gc(0); + break; default: break; } From ak@suse.de Fri Apr 9 08:50:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 08:51:00 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39FonKO011371 for ; Fri, 9 Apr 2004 08:50:50 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 91CF142409C; Fri, 9 Apr 2004 17:48:42 +0200 (CEST) Date: Fri, 9 Apr 2004 17:48:47 +0200 From: Andi Kleen To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040409174847.2f0b7e77.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4576 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 10237 Lines: 292 This wraps all potentially network triggerable printks in IPv6 with NETDEBUG. Default behaviour doesn't change because the main kernel still has NETDEBUG enabled (although it may be a good idea now to disable it by default in the stable series) Please apply. -Andi diff -u linux-2.6.5-netmsg/net/ipv4/esp4.c-o linux-2.6.5-netmsg/net/ipv4/esp4.c --- linux-2.6.5-netmsg/net/ipv4/esp4.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/esp4.c 2004-04-09 17:40:23.000000000 +0200 @@ -428,8 +428,8 @@ x = xfrm_state_lookup((xfrm_address_t *)&iph->daddr, esph->spi, IPPROTO_ESP, AF_INET); if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA ESP/%08x/%08x\n", - ntohl(esph->spi), ntohl(iph->daddr)); + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA ESP/%08x/%08x\n", + ntohl(esph->spi), ntohl(iph->daddr))); xfrm_state_put(x); } @@ -492,10 +492,10 @@ if (aalg_desc->uinfo.auth.icv_fullbits/8 != crypto_tfm_alg_digestsize(esp->auth.tfm)) { - printk(KERN_INFO "ESP: %s digestsize %u != %hu\n", + NETDEBUG(printk(KERN_INFO "ESP: %s digestsize %u != %hu\n", x->aalg->alg_name, crypto_tfm_alg_digestsize(esp->auth.tfm), - aalg_desc->uinfo.auth.icv_fullbits/8); + aalg_desc->uinfo.auth.icv_fullbits/8)); goto error; } diff -u linux-2.6.5-netmsg/net/ipv4/icmp.c-o linux-2.6.5-netmsg/net/ipv4/icmp.c --- linux-2.6.5-netmsg/net/ipv4/icmp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/icmp.c 2004-04-09 17:40:23.000000000 +0200 @@ -620,11 +620,11 @@ break; case ICMP_FRAG_NEEDED: if (ipv4_config.no_pmtu_disc) { - if (net_ratelimit()) + NETDEBUG(if (net_ratelimit()) printk(KERN_INFO "ICMP: %u.%u.%u.%u: " "fragmentation needed " "and DF set.\n", - NIPQUAD(iph->daddr)); + NIPQUAD(iph->daddr))); } else { info = ip_rt_frag_needed(iph, ntohs(icmph->un.frag.mtu)); @@ -633,10 +633,10 @@ } break; case ICMP_SR_FAILED: - if (net_ratelimit()) + NETDEBUG(if (net_ratelimit()) printk(KERN_INFO "ICMP: %u.%u.%u.%u: Source " "Route Failed.\n", - NIPQUAD(iph->daddr)); + NIPQUAD(iph->daddr))); break; default: break; diff -u linux-2.6.5-netmsg/net/ipv4/ipcomp.c-o linux-2.6.5-netmsg/net/ipv4/ipcomp.c --- linux-2.6.5-netmsg/net/ipv4/ipcomp.c-o 2004-03-21 21:11:59.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/ipcomp.c 2004-04-09 17:40:23.000000000 +0200 @@ -258,8 +258,8 @@ spi, IPPROTO_COMP, AF_INET); if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA IPCOMP/%08x/%u.%u.%u.%u\n", - spi, NIPQUAD(iph->daddr)); + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA IPCOMP/%08x/%u.%u.%u.%u\n", + spi, NIPQUAD(iph->daddr))); xfrm_state_put(x); } diff -u linux-2.6.5-netmsg/net/ipv6/ah6.c-o linux-2.6.5-netmsg/net/ipv6/ah6.c --- linux-2.6.5-netmsg/net/ipv6/ah6.c-o 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/ah6.c 2004-04-09 17:40:23.000000000 +0200 @@ -92,8 +92,8 @@ *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun hopopts\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_WARNING "overrun hopopts\n")); return 0; } nexthdr = exthdr->nexthdr; @@ -112,8 +112,8 @@ *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun destopt\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_WARNING "overrun destopt\n")); return 0; } nexthdr = exthdr->nexthdr; @@ -130,8 +130,8 @@ exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); nextnexthdr = exthdr->nexthdr; if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun destopt\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_WARNING "overrun destopt\n")); return 0; } } @@ -322,8 +322,8 @@ skb_push(skb, skb->data - skb->nh.raw); ahp->icv(ahp, skb, ah->auth_data); if (memcmp(ah->auth_data, auth_data, ahp->icv_trunc_len)) { - if (net_ratelimit()) - printk(KERN_WARNING "ipsec ah authentication error\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_WARNING "ipsec ah authentication error\n")); x->stats.integrity_failed++; goto free_out; } @@ -368,9 +368,9 @@ if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA AH/%08x/" + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA AH/%08x/" "%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x\n", - ntohl(ah->spi), NIP6(iph->daddr)); + ntohl(ah->spi), NIP6(iph->daddr))); xfrm_state_put(x); } diff -u linux-2.6.5-netmsg/net/ipv6/esp6.c-o linux-2.6.5-netmsg/net/ipv6/esp6.c --- linux-2.6.5-netmsg/net/ipv6/esp6.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/esp6.c 2004-04-09 17:40:23.000000000 +0200 @@ -278,9 +278,9 @@ padlen = nexthdr[0]; if (padlen+2 >= elen) { - if (net_ratelimit()) { + NETDEBUG(if (net_ratelimit()) { printk(KERN_WARNING "ipsec esp packet is garbage padlen=%d, elen=%d\n", padlen+2, elen); - } + }); ret = -EINVAL; goto out; } diff -u linux-2.6.5-netmsg/net/ipv6/datagram.c-o linux-2.6.5-netmsg/net/ipv6/datagram.c --- linux-2.6.5-netmsg/net/ipv6/datagram.c-o 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/datagram.c 2004-04-09 17:40:23.000000000 +0200 @@ -427,8 +427,8 @@ break; default: - if (net_ratelimit()) - printk(KERN_DEBUG "invalid cmsg type: %d\n", cmsg->cmsg_type); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "invalid cmsg type: %d\n", cmsg->cmsg_type)); err = -EINVAL; break; }; diff -u linux-2.6.5-netmsg/net/ipv6/icmp.c-o linux-2.6.5-netmsg/net/ipv6/icmp.c --- linux-2.6.5-netmsg/net/ipv6/icmp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/icmp.c 2004-04-09 17:40:23.000000000 +0200 @@ -329,8 +329,8 @@ * for now we don't know that. */ if ((addr_type == IPV6_ADDR_ANY) || (addr_type & IPV6_ADDR_MULTICAST)) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6_send: addr_any/mcast source\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "icmpv6_send: addr_any/mcast source\n")); return; } @@ -338,8 +338,8 @@ * Never answer to a ICMP packet. */ if (is_ineligible(skb)) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6_send: no reply to icmp error\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "icmpv6_send: no reply to icmp error\n")); return; } @@ -385,8 +385,8 @@ len = skb->len - msg.offset; len = min_t(unsigned int, len, IPV6_MIN_MTU - sizeof(struct ipv6hdr) -sizeof(struct icmp6hdr)); if (len < 0) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmp: len problem\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "icmp: len problem\n")); goto out_dst_release; } @@ -570,17 +570,17 @@ skb->ip_summed = CHECKSUM_UNNECESSARY; if (csum_ipv6_magic(saddr, daddr, skb->len, IPPROTO_ICMPV6, skb->csum)) { - if (net_ratelimit()) - printk(KERN_DEBUG "ICMPv6 hw checksum failed\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "ICMPv6 hw checksum failed\n")); skb->ip_summed = CHECKSUM_NONE; } } if (skb->ip_summed == CHECKSUM_NONE) { if (csum_ipv6_magic(saddr, daddr, skb->len, IPPROTO_ICMPV6, skb_checksum(skb, 0, skb->len, 0))) { - if (net_ratelimit()) + NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - NIP6(*saddr), NIP6(*daddr)); + NIP6(*saddr), NIP6(*daddr))); goto discard_it; } } @@ -649,8 +649,8 @@ break; default: - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6: msg of unknown type\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "icmpv6: msg of unknown type\n")); /* informational */ if (type & ICMPV6_INFOMSG_MASK) diff -u linux-2.6.5-netmsg/net/ipv6/exthdrs.c-o linux-2.6.5-netmsg/net/ipv6/exthdrs.c --- linux-2.6.5-netmsg/net/ipv6/exthdrs.c-o 2004-04-06 13:12:25.000000000 +0200 +++ linux-2.6.5-netmsg/net/ipv6/exthdrs.c 2004-04-09 17:40:23.000000000 +0200 @@ -410,8 +410,8 @@ ((struct inet6_skb_parm*)skb->cb)->ra = optoff; return 1; } - if (net_ratelimit()) - printk(KERN_DEBUG "ipv6_hop_ra: wrong RA length %d\n", skb->nh.raw[optoff+1]); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "ipv6_hop_ra: wrong RA length %d\n", skb->nh.raw[optoff+1])); kfree_skb(skb); return 0; } @@ -423,8 +423,8 @@ u32 pkt_len; if (skb->nh.raw[optoff+1] != 4 || (optoff&3) != 2) { - if (net_ratelimit()) - printk(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n", skb->nh.raw[optoff+1]); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n", skb->nh.raw[optoff+1])); goto drop; } diff -u linux-2.6.5-netmsg/net/ipv6/udp.c-o linux-2.6.5-netmsg/net/ipv6/udp.c --- linux-2.6.5-netmsg/net/ipv6/udp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/udp.c 2004-04-09 17:40:23.000000000 +0200 @@ -634,8 +634,8 @@ /* RFC 2460 section 8.1 says that we SHOULD log this error. Well, it is reasonable. */ - if (net_ratelimit()) - printk(KERN_INFO "IPv6: udp checksum is 0\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_INFO "IPv6: udp checksum is 0\n")); goto discard; } diff -u linux-2.6.5-netmsg/net/ipv6/ip6_output.c-o linux-2.6.5-netmsg/net/ipv6/ip6_output.c --- linux-2.6.5-netmsg/net/ipv6/ip6_output.c-o 2004-04-06 13:12:25.000000000 +0200 +++ linux-2.6.5-netmsg/net/ipv6/ip6_output.c 2004-04-09 17:40:24.000000000 +0200 @@ -167,8 +167,8 @@ dst = ip6_route_output(skb->sk, &fl); if (dst->error) { - if (net_ratelimit()) - printk(KERN_DEBUG "ip6_route_me_harder: No more route.\n"); + NETDEBUG(if (net_ratelimit()) + printk(KERN_DEBUG "ip6_route_me_harder: No more route.\n")); dst_release(dst); return -EINVAL; } From yoshfuji@linux-ipv6.org Fri Apr 9 09:00:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 09:00:38 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39G0TKO013152 for ; Fri, 9 Apr 2004 09:00:30 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 0EE0D33CA5; Sat, 10 Apr 2004 01:00:52 +0900 (JST) Date: Sat, 10 Apr 2004 01:00:51 +0900 (JST) Message-Id: <20040410.010051.129465789.yoshfuji@linux-ipv6.org> To: ak@suse.de Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040409174847.2f0b7e77.ak@suse.de> References: <20040409174847.2f0b7e77.ak@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4577 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 624 Lines: 17 In article <20040409174847.2f0b7e77.ak@suse.de> (at Fri, 9 Apr 2004 17:48:47 +0200), Andi Kleen says: > This wraps all potentially network triggerable printks in IPv6 with NETDEBUG. I really do NOT like this. Please, please do not do this. > case ICMP_SR_FAILED: > - if (net_ratelimit()) > + NETDEBUG(if (net_ratelimit()) > printk(KERN_INFO "ICMP: %u.%u.%u.%u: Source " > "Route Failed.\n", > - NIPQUAD(iph->daddr)); > + NIPQUAD(iph->daddr))); -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From ak@suse.de Fri Apr 9 10:08:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 10:08:25 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39H87KO020136 for ; Fri, 9 Apr 2004 10:08:08 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 0BB39424141; Fri, 9 Apr 2004 18:21:21 +0200 (CEST) Date: Fri, 9 Apr 2004 18:21:25 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040409182125.348fd6cd.ak@suse.de> In-Reply-To: <20040410.010051.129465789.yoshfuji@linux-ipv6.org> References: <20040409174847.2f0b7e77.ak@suse.de> <20040410.010051.129465789.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4578 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 647 Lines: 15 On Sat, 10 Apr 2004 01:00:51 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <20040409174847.2f0b7e77.ak@suse.de> (at Fri, 9 Apr 2004 17:48:47 +0200), Andi Kleen says: > > > This wraps all potentially network triggerable printks in IPv6 with NETDEBUG. > > I really do NOT like this. Please, please do not do this. If you don't like it just keep NETDEBUG on. But for production systems being able to fill up logs from the network is not acceptable IMHO. Anyways default behaviour does not change right now, it just allows to easily disable all this cruft for people who want that. -Andi From yoshfuji@linux-ipv6.org Fri Apr 9 10:18:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 10:18:25 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39HIIKO021344 for ; Fri, 9 Apr 2004 10:18:21 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id E293533CA5; Sat, 10 Apr 2004 02:18:40 +0900 (JST) Date: Sat, 10 Apr 2004 02:18:40 +0900 (JST) Message-Id: <20040410.021840.113165465.yoshfuji@linux-ipv6.org> To: ak@suse.de Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040409182125.348fd6cd.ak@suse.de> References: <20040409174847.2f0b7e77.ak@suse.de> <20040410.010051.129465789.yoshfuji@linux-ipv6.org> <20040409182125.348fd6cd.ak@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4579 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 658 Lines: 15 In article <20040409182125.348fd6cd.ak@suse.de> (at Fri, 9 Apr 2004 18:21:25 +0200), Andi Kleen says: > > > This wraps all potentially network triggerable printks in IPv6 with NETDEBUG. > > > > I really do NOT like this. Please, please do not do this. > > If you don't like it just keep NETDEBUG on. But for production systems being able > to fill up logs from the network is not acceptable IMHO. Anyways default behaviour > does not change right now, it just allows to easily disable all this cruft for > people who want that. I don't like the style; it is too ugly. E.g. please do not put "if () ..." into the macro argument. --yoshfuji From ak@suse.de Fri Apr 9 10:31:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 10:31:31 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39HVOKO022767 for ; Fri, 9 Apr 2004 10:31:25 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 17E114254EC; Fri, 9 Apr 2004 19:31:19 +0200 (CEST) Date: Fri, 9 Apr 2004 19:31:23 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040409193123.63e4cdc7.ak@suse.de> In-Reply-To: <20040410.021840.113165465.yoshfuji@linux-ipv6.org> References: <20040409174847.2f0b7e77.ak@suse.de> <20040410.010051.129465789.yoshfuji@linux-ipv6.org> <20040409182125.348fd6cd.ak@suse.de> <20040410.021840.113165465.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4580 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 12960 Lines: 361 On Sat, 10 Apr 2004 02:18:40 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <20040409182125.348fd6cd.ak@suse.de> (at Fri, 9 Apr 2004 18:21:25 +0200), Andi Kleen says: > > > > > This wraps all potentially network triggerable printks in IPv6 with NETDEBUG. > > > > > > I really do NOT like this. Please, please do not do this. > > > > If you don't like it just keep NETDEBUG on. But for production systems being able > > to fill up logs from the network is not acceptable IMHO. Anyways default behaviour > > does not change right now, it just allows to easily disable all this cruft for > > people who want that. > > I don't like the style; it is too ugly. > E.g. please do not put "if () ..." into the macro argument. Ok, here is a new version that defines a new macro LIMIT_NETDEBUG that does the rate limit implicitely. DaveM, please apply. -Andi diff -u linux-2.6.5-netmsg/include/net/sock.h-o linux-2.6.5-netmsg/include/net/sock.h --- linux-2.6.5-netmsg/include/net/sock.h-o 2004-03-21 21:11:55.000000000 +0100 +++ linux-2.6.5-netmsg/include/net/sock.h 2004-04-09 19:27:13.000000000 +0200 @@ -1035,8 +1035,10 @@ #if 0 #define NETDEBUG(x) do { } while (0) +#define LIMIT_NETDEBUG(x) do {} while(0) #else #define NETDEBUG(x) do { x; } while (0) +#define LIMIT_NETDEBUG(x) do { if (net_ratelimit()) { x; } } while(0) #endif /* diff -u linux-2.6.5-netmsg/net/ipv4/esp4.c-o linux-2.6.5-netmsg/net/ipv4/esp4.c --- linux-2.6.5-netmsg/net/ipv4/esp4.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/esp4.c 2004-04-09 17:40:23.000000000 +0200 @@ -428,8 +428,8 @@ x = xfrm_state_lookup((xfrm_address_t *)&iph->daddr, esph->spi, IPPROTO_ESP, AF_INET); if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA ESP/%08x/%08x\n", - ntohl(esph->spi), ntohl(iph->daddr)); + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA ESP/%08x/%08x\n", + ntohl(esph->spi), ntohl(iph->daddr))); xfrm_state_put(x); } @@ -492,10 +492,10 @@ if (aalg_desc->uinfo.auth.icv_fullbits/8 != crypto_tfm_alg_digestsize(esp->auth.tfm)) { - printk(KERN_INFO "ESP: %s digestsize %u != %hu\n", + NETDEBUG(printk(KERN_INFO "ESP: %s digestsize %u != %hu\n", x->aalg->alg_name, crypto_tfm_alg_digestsize(esp->auth.tfm), - aalg_desc->uinfo.auth.icv_fullbits/8); + aalg_desc->uinfo.auth.icv_fullbits/8)); goto error; } diff -u linux-2.6.5-netmsg/net/ipv4/icmp.c-o linux-2.6.5-netmsg/net/ipv4/icmp.c --- linux-2.6.5-netmsg/net/ipv4/icmp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/icmp.c 2004-04-09 19:29:46.000000000 +0200 @@ -620,11 +620,11 @@ break; case ICMP_FRAG_NEEDED: if (ipv4_config.no_pmtu_disc) { - if (net_ratelimit()) + LIMIT_NETDEBUG( printk(KERN_INFO "ICMP: %u.%u.%u.%u: " "fragmentation needed " "and DF set.\n", - NIPQUAD(iph->daddr)); + NIPQUAD(iph->daddr))); } else { info = ip_rt_frag_needed(iph, ntohs(icmph->un.frag.mtu)); @@ -633,10 +633,10 @@ } break; case ICMP_SR_FAILED: - if (net_ratelimit()) + LIMIT_NETDEBUG( printk(KERN_INFO "ICMP: %u.%u.%u.%u: Source " "Route Failed.\n", - NIPQUAD(iph->daddr)); + NIPQUAD(iph->daddr))); break; default: break; diff -u linux-2.6.5-netmsg/net/ipv4/ipcomp.c-o linux-2.6.5-netmsg/net/ipv4/ipcomp.c --- linux-2.6.5-netmsg/net/ipv4/ipcomp.c-o 2004-03-21 21:11:59.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv4/ipcomp.c 2004-04-09 17:40:23.000000000 +0200 @@ -258,8 +258,8 @@ spi, IPPROTO_COMP, AF_INET); if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA IPCOMP/%08x/%u.%u.%u.%u\n", - spi, NIPQUAD(iph->daddr)); + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA IPCOMP/%08x/%u.%u.%u.%u\n", + spi, NIPQUAD(iph->daddr))); xfrm_state_put(x); } diff -u linux-2.6.5-netmsg/net/ipv6/ah6.c-o linux-2.6.5-netmsg/net/ipv6/ah6.c --- linux-2.6.5-netmsg/net/ipv6/ah6.c-o 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/ah6.c 2004-04-09 19:24:59.000000000 +0200 @@ -92,8 +92,8 @@ *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun hopopts\n"); + LIMIT_NETDEBUG( + printk(KERN_WARNING "overrun hopopts\n")); return 0; } nexthdr = exthdr->nexthdr; @@ -112,8 +112,8 @@ *nh_offset = offset; offset += ipv6_optlen(exthdr); if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun destopt\n"); + LIMIT_NETDEBUG( + printk(KERN_WARNING "overrun destopt\n")); return 0; } nexthdr = exthdr->nexthdr; @@ -130,8 +130,8 @@ exthdr = (struct ipv6_opt_hdr*)(skb->nh.raw + offset); nextnexthdr = exthdr->nexthdr; if (!zero_out_mutable_opts(exthdr)) { - if (net_ratelimit()) - printk(KERN_WARNING "overrun destopt\n"); + LIMIT_NETDEBUG( + printk(KERN_WARNING "overrun destopt\n")); return 0; } } @@ -322,8 +322,8 @@ skb_push(skb, skb->data - skb->nh.raw); ahp->icv(ahp, skb, ah->auth_data); if (memcmp(ah->auth_data, auth_data, ahp->icv_trunc_len)) { - if (net_ratelimit()) - printk(KERN_WARNING "ipsec ah authentication error\n"); + LIMIT_NETDEBUG( + printk(KERN_WARNING "ipsec ah authentication error\n")); x->stats.integrity_failed++; goto free_out; } @@ -368,9 +368,9 @@ if (!x) return; - printk(KERN_DEBUG "pmtu discovery on SA AH/%08x/" + NETDEBUG(printk(KERN_DEBUG "pmtu discovery on SA AH/%08x/" "%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x\n", - ntohl(ah->spi), NIP6(iph->daddr)); + ntohl(ah->spi), NIP6(iph->daddr))); xfrm_state_put(x); } diff -u linux-2.6.5-netmsg/net/ipv6/esp6.c-o linux-2.6.5-netmsg/net/ipv6/esp6.c --- linux-2.6.5-netmsg/net/ipv6/esp6.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/esp6.c 2004-04-09 19:24:56.000000000 +0200 @@ -278,9 +278,9 @@ padlen = nexthdr[0]; if (padlen+2 >= elen) { - if (net_ratelimit()) { + LIMIT_NETDEBUG( printk(KERN_WARNING "ipsec esp packet is garbage padlen=%d, elen=%d\n", padlen+2, elen); - } + }); ret = -EINVAL; goto out; } diff -u linux-2.6.5-netmsg/net/ipv6/datagram.c-o linux-2.6.5-netmsg/net/ipv6/datagram.c --- linux-2.6.5-netmsg/net/ipv6/datagram.c-o 2004-03-21 21:12:00.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/datagram.c 2004-04-09 19:24:57.000000000 +0200 @@ -427,8 +427,8 @@ break; default: - if (net_ratelimit()) - printk(KERN_DEBUG "invalid cmsg type: %d\n", cmsg->cmsg_type); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "invalid cmsg type: %d\n", cmsg->cmsg_type)); err = -EINVAL; break; }; diff -u linux-2.6.5-netmsg/net/ipv6/icmp.c-o linux-2.6.5-netmsg/net/ipv6/icmp.c --- linux-2.6.5-netmsg/net/ipv6/icmp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/icmp.c 2004-04-09 19:24:52.000000000 +0200 @@ -329,8 +329,8 @@ * for now we don't know that. */ if ((addr_type == IPV6_ADDR_ANY) || (addr_type & IPV6_ADDR_MULTICAST)) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6_send: addr_any/mcast source\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "icmpv6_send: addr_any/mcast source\n")); return; } @@ -338,8 +338,8 @@ * Never answer to a ICMP packet. */ if (is_ineligible(skb)) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6_send: no reply to icmp error\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "icmpv6_send: no reply to icmp error\n")); return; } @@ -385,8 +385,8 @@ len = skb->len - msg.offset; len = min_t(unsigned int, len, IPV6_MIN_MTU - sizeof(struct ipv6hdr) -sizeof(struct icmp6hdr)); if (len < 0) { - if (net_ratelimit()) - printk(KERN_DEBUG "icmp: len problem\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "icmp: len problem\n")); goto out_dst_release; } @@ -570,17 +570,17 @@ skb->ip_summed = CHECKSUM_UNNECESSARY; if (csum_ipv6_magic(saddr, daddr, skb->len, IPPROTO_ICMPV6, skb->csum)) { - if (net_ratelimit()) - printk(KERN_DEBUG "ICMPv6 hw checksum failed\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "ICMPv6 hw checksum failed\n")); skb->ip_summed = CHECKSUM_NONE; } } if (skb->ip_summed == CHECKSUM_NONE) { if (csum_ipv6_magic(saddr, daddr, skb->len, IPPROTO_ICMPV6, skb_checksum(skb, 0, skb->len, 0))) { - if (net_ratelimit()) + LIMIT_NETDEBUG( printk(KERN_DEBUG "ICMPv6 checksum failed [%04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x > %04x:%04x:%04x:%04x:%04x:%04x:%04x:%04x]\n", - NIP6(*saddr), NIP6(*daddr)); + NIP6(*saddr), NIP6(*daddr))); goto discard_it; } } @@ -649,8 +649,8 @@ break; default: - if (net_ratelimit()) - printk(KERN_DEBUG "icmpv6: msg of unknown type\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "icmpv6: msg of unknown type\n")); /* informational */ if (type & ICMPV6_INFOMSG_MASK) diff -u linux-2.6.5-netmsg/net/ipv6/exthdrs.c-o linux-2.6.5-netmsg/net/ipv6/exthdrs.c --- linux-2.6.5-netmsg/net/ipv6/exthdrs.c-o 2004-04-06 13:12:25.000000000 +0200 +++ linux-2.6.5-netmsg/net/ipv6/exthdrs.c 2004-04-09 19:24:54.000000000 +0200 @@ -410,8 +410,8 @@ ((struct inet6_skb_parm*)skb->cb)->ra = optoff; return 1; } - if (net_ratelimit()) - printk(KERN_DEBUG "ipv6_hop_ra: wrong RA length %d\n", skb->nh.raw[optoff+1]); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "ipv6_hop_ra: wrong RA length %d\n", skb->nh.raw[optoff+1])); kfree_skb(skb); return 0; } @@ -423,8 +423,8 @@ u32 pkt_len; if (skb->nh.raw[optoff+1] != 4 || (optoff&3) != 2) { - if (net_ratelimit()) - printk(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n", skb->nh.raw[optoff+1]); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "ipv6_hop_jumbo: wrong jumbo opt length/alignment %d\n", skb->nh.raw[optoff+1])); goto drop; } diff -u linux-2.6.5-netmsg/net/ipv6/udp.c-o linux-2.6.5-netmsg/net/ipv6/udp.c --- linux-2.6.5-netmsg/net/ipv6/udp.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/udp.c 2004-04-09 19:24:46.000000000 +0200 @@ -634,8 +634,8 @@ /* RFC 2460 section 8.1 says that we SHOULD log this error. Well, it is reasonable. */ - if (net_ratelimit()) - printk(KERN_INFO "IPv6: udp checksum is 0\n"); + LIMIT_NETDEBUG( + printk(KERN_INFO "IPv6: udp checksum is 0\n")); goto discard; } @@ -650,7 +650,7 @@ if (skb->ip_summed==CHECKSUM_HW) { skb->ip_summed = CHECKSUM_UNNECESSARY; if (csum_ipv6_magic(saddr, daddr, ulen, IPPROTO_UDP, skb->csum)) { - NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG "udp v6 hw csum failure.\n")); + LIMIT_NETDEBUG(printk(KERN_DEBUG "udp v6 hw csum failure.\n")); skb->ip_summed = CHECKSUM_NONE; } } @@ -970,7 +970,7 @@ /* ... which is an evident application bug. --ANK */ release_sock(sk); - NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG "udp cork app bug 2\n")); + LIMIT_NETDEBUG(printk(KERN_DEBUG "udp cork app bug 2\n")); err = -EINVAL; goto out; } diff -u linux-2.6.5-netmsg/net/ipv6/ip6_output.c-o linux-2.6.5-netmsg/net/ipv6/ip6_output.c --- linux-2.6.5-netmsg/net/ipv6/ip6_output.c-o 2004-04-06 13:12:25.000000000 +0200 +++ linux-2.6.5-netmsg/net/ipv6/ip6_output.c 2004-04-09 19:24:51.000000000 +0200 @@ -167,8 +167,8 @@ dst = ip6_route_output(skb->sk, &fl); if (dst->error) { - if (net_ratelimit()) - printk(KERN_DEBUG "ip6_route_me_harder: No more route.\n"); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "ip6_route_me_harder: No more route.\n")); dst_release(dst); return -EINVAL; } diff -u linux-2.6.5-netmsg/net/ipv6/raw.c-o linux-2.6.5-netmsg/net/ipv6/raw.c --- linux-2.6.5-netmsg/net/ipv6/raw.c-o 1970-01-01 01:12:51.000000000 +0100 +++ linux-2.6.5-netmsg/net/ipv6/raw.c 2004-04-09 19:24:50.000000000 +0200 @@ -328,7 +328,8 @@ if (csum_ipv6_magic(&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr, skb->len, inet->num, skb->csum)) { - NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG "raw v6 hw csum failure.\n")); + LIMIT_NETDEBUG( + printk(KERN_DEBUG "raw v6 hw csum failure.\n")); skb->ip_summed = CHECKSUM_NONE; } } diff -u linux-2.6.5-netmsg/net/ipv6/tcp_ipv6.c-o linux-2.6.5-netmsg/net/ipv6/tcp_ipv6.c --- linux-2.6.5-netmsg/net/ipv6/tcp_ipv6.c-o 2004-04-06 13:12:25.000000000 +0200 +++ linux-2.6.5-netmsg/net/ipv6/tcp_ipv6.c 2004-04-09 19:24:48.000000000 +0200 @@ -1425,7 +1425,7 @@ if (!tcp_v6_check(skb->h.th,skb->len,&skb->nh.ipv6h->saddr, &skb->nh.ipv6h->daddr,skb->csum)) return 0; - NETDEBUG(if (net_ratelimit()) printk(KERN_DEBUG "hw tcp v6 csum failed\n")); + LIMIT_NETDEBUG(printk(KERN_DEBUG "hw tcp v6 csum failed\n")); } if (skb->len <= 76) { if (tcp_v6_check(skb->h.th,skb->len,&skb->nh.ipv6h->saddr, From yoshfuji@linux-ipv6.org Fri Apr 9 10:46:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 10:46:50 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39HkhKO023951 for ; Fri, 9 Apr 2004 10:46:44 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 2276A33CA5; Sat, 10 Apr 2004 02:47:06 +0900 (JST) Date: Sat, 10 Apr 2004 02:47:05 +0900 (JST) Message-Id: <20040410.024705.97089877.yoshfuji@linux-ipv6.org> To: ak@suse.de Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040409193123.63e4cdc7.ak@suse.de> References: <20040409182125.348fd6cd.ak@suse.de> <20040410.021840.113165465.yoshfuji@linux-ipv6.org> <20040409193123.63e4cdc7.ak@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4581 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 677 Lines: 25 In article <20040409193123.63e4cdc7.ak@suse.de> (at Fri, 9 Apr 2004 19:31:23 +0200), Andi Kleen says: > > I don't like the style; it is too ugly. > > E.g. please do not put "if () ..." into the macro argument. > > Ok, here is a new version that defines a new macro LIMIT_NETDEBUG that does the > rate limit implicitely. > - if (net_ratelimit()) > - printk(KERN_WARNING "overrun destopt\n"); > + LIMIT_NETDEBUG( > + printk(KERN_WARNING "overrun destopt\n")); Grr... I'd prefer: if (net_ratelimit()) NETDEBUG_PRINTK("overrun destopt\n"..) or NETDEBUG_PRINTK_LIMIT("overrun destopt\n"..) (or something like this) much more. --yoshfuji From niv@us.ibm.com Fri Apr 9 11:06:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:06:58 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39I6mKO025851 for ; Fri, 9 Apr 2004 11:06:54 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i39I6gBs586918; Fri, 9 Apr 2004 14:06:42 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i39I6Zhg131188; Fri, 9 Apr 2004 14:06:36 -0400 Message-ID: <4076E636.5050803@us.ibm.com> Date: Fri, 09 Apr 2004 11:06:46 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: "YOSHIFUJI Hideaki / _$B5HF#1QL@" , davem@redhat.com, netdev@oss.sgi.com Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 References: <20040409174847.2f0b7e77.ak@suse.de> <20040410.010051.129465789.yoshfuji@linux-ipv6.org> <20040409182125.348fd6cd.ak@suse.de> In-Reply-To: <20040409182125.348fd6cd.ak@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4582 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 546 Lines: 20 Andi Kleen wrote: > If you don't like it just keep NETDEBUG on. But for production systems being able > to fill up logs from the network is not acceptable IMHO. Anyways default behaviour > does not change right now, it just allows to easily disable all this cruft for > people who want that. I'd like to support Andi's patch - or any flavor thereof, that results in being able to prevent nw triggered logging filling up logs. It is very much needed by us, too. I would like to see it be the default in mainline, really. thanks, Nivedita From yoshfuji@linux-ipv6.org Fri Apr 9 11:08:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:08:48 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39I8gKO026394 for ; Fri, 9 Apr 2004 11:08:42 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id B1BC033CA5; Sat, 10 Apr 2004 03:09:04 +0900 (JST) Date: Sat, 10 Apr 2004 03:09:04 +0900 (JST) Message-Id: <20040410.030904.82108741.yoshfuji@linux-ipv6.org> To: ak@suse.de Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040409195052.10ba931c.ak@suse.de> References: <20040409193123.63e4cdc7.ak@suse.de> <20040410.024705.97089877.yoshfuji@linux-ipv6.org> <20040409195052.10ba931c.ak@suse.de> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4583 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 358 Lines: 12 In article <20040409195052.10ba931c.ak@suse.de> (at Fri, 9 Apr 2004 19:50:52 +0200), Andi Kleen says: > > NETDEBUG_PRINTK_LIMIT("overrun destopt\n"..) > > > > (or something like this) much more. > > ... and this will make the lines even longer. If you mind that, you can use shorter name like IP6DEBUG / IP6DEBUG_LIMIT() etc. --yoshfuji From ak@suse.de Fri Apr 9 11:35:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:35:53 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39IZcKO028305 for ; Fri, 9 Apr 2004 11:35:39 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id AAA7242593D; Fri, 9 Apr 2004 19:50:46 +0200 (CEST) Date: Fri, 9 Apr 2004 19:50:52 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040409195052.10ba931c.ak@suse.de> In-Reply-To: <20040410.024705.97089877.yoshfuji@linux-ipv6.org> References: <20040409182125.348fd6cd.ak@suse.de> <20040410.021840.113165465.yoshfuji@linux-ipv6.org> <20040409193123.63e4cdc7.ak@suse.de> <20040410.024705.97089877.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4584 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 396 Lines: 21 On Sat, 10 Apr 2004 02:47:05 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > > I'd prefer: > > if (net_ratelimit()) > NETDEBUG_PRINTK("overrun destopt\n"..) This won't optimize away the function call. > or > > NETDEBUG_PRINTK_LIMIT("overrun destopt\n"..) > > (or something like this) much more. ... and this will make the lines even longer. -Andi From shemminger@osdl.org Fri Apr 9 11:47:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:47:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39IlrKO029641 for ; Fri, 9 Apr 2004 11:47:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i39Ild219125; Fri, 9 Apr 2004 11:47:39 -0700 Date: Fri, 9 Apr 2004 11:45:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-usb-devel@lists.sourceforge.net Subject: [PATCH] (2/4) set random address in dummy Message-Id: <20040409114553.7f5b5d25@dell_ss3.pdx.osdl.net> In-Reply-To: <20040408145403.34382c96.davem@redhat.com> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4587 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: 1708 Lines: 58 Fix several things in dummy device to make it more useable. * add MODULE_PARAM_DESC for num_dummies * set initial random ether address * allow changing address diff -Nru a/drivers/net/dummy.c b/drivers/net/dummy.c --- a/drivers/net/dummy.c Fri Apr 9 11:33:59 2004 +++ b/drivers/net/dummy.c Fri Apr 9 11:33:59 2004 @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -40,6 +41,17 @@ static int dummy_xmit(struct sk_buff *skb, struct net_device *dev); static struct net_device_stats *dummy_get_stats(struct net_device *dev); +static int dummy_set_address(struct net_device *dev, void *p) +{ + struct sockaddr *sa = p; + + if (!is_valid_ether_addr(sa->sa_data)) + return -EADDRNOTAVAIL; + + memcpy(dev->dev_addr, sa->sa_data, ETH_ALEN); + return 0; +} + /* fake multicast ability */ static void set_multicast_list(struct net_device *dev) { @@ -58,6 +70,7 @@ dev->get_stats = dummy_get_stats; dev->hard_start_xmit = dummy_xmit; dev->set_multicast_list = set_multicast_list; + dev->set_mac_address = dummy_set_address; #ifdef CONFIG_NET_FASTROUTE dev->accept_fastpath = dummy_accept_fastpath; #endif @@ -68,6 +81,7 @@ dev->flags |= IFF_NOARP; dev->flags &= ~IFF_MULTICAST; SET_MODULE_OWNER(dev); + random_ether_addr(dev->dev_addr); } static int dummy_xmit(struct sk_buff *skb, struct net_device *dev) @@ -90,6 +104,7 @@ /* Number of dummy devices to be set up by this module. */ module_param(numdummies, int, 0); +MODULE_PARM_DESC(numdimmies, "Number of dummy psuedo devices"); static int __init dummy_init_one(int index) { From shemminger@osdl.org Fri Apr 9 11:47:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:47:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39IlrKO029643 for ; Fri, 9 Apr 2004 11:47:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i39Ile219133; Fri, 9 Apr 2004 11:47:40 -0700 Date: Fri, 9 Apr 2004 11:47:27 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-usb-devel@lists.sourceforge.net Subject: [PATCH] (4/4) usbnet -- use random_ether_addr Message-Id: <20040409114727.0619405d@dell_ss3.pdx.osdl.net> In-Reply-To: <20040408145403.34382c96.davem@redhat.com> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4586 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: 570 Lines: 17 Same code to generate random_ether_address is in ether_device.h (patch1) so use it for usbnet. diff -Nru a/drivers/usb/net/usbnet.c b/drivers/usb/net/usbnet.c --- a/drivers/usb/net/usbnet.c Fri Apr 9 11:41:19 2004 +++ b/drivers/usb/net/usbnet.c Fri Apr 9 11:41:19 2004 @@ -3414,9 +3414,7 @@ < sizeof (struct cdc_state))); #endif - get_random_bytes (node_id, sizeof node_id); - node_id [0] &= 0xfe; // clear multicast bit - node_id [0] |= 0x02; // set local assignment bit (IEEE802) + random_ether_addr(node_id); return usb_register(&usbnet_driver); } From shemminger@osdl.org Fri Apr 9 11:47:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:47:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39IlrKO029640 for ; Fri, 9 Apr 2004 11:47:53 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i39Ild219089; Fri, 9 Apr 2004 11:47:39 -0700 Date: Fri, 9 Apr 2004 11:45:47 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-usb-devel@lists.sourceforge.net Subject: [PATCH] (1/4) add random_ether_addr to ether_device.h Message-Id: <20040409114547.7ef37fc0@dell_ss3.pdx.osdl.net> In-Reply-To: <20040408145403.34382c96.davem@redhat.com> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4585 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: 1099 Lines: 34 Since generating a random ethernet address needs to be done in several drivers, add a random_ether_addr function to etherdevice.h diff -Nru a/include/linux/etherdevice.h b/include/linux/etherdevice.h --- a/include/linux/etherdevice.h Fri Apr 9 11:33:59 2004 +++ b/include/linux/etherdevice.h Fri Apr 9 11:33:59 2004 @@ -25,6 +25,7 @@ #define _LINUX_ETHERDEVICE_H #include +#include #ifdef __KERNEL__ extern int eth_header(struct sk_buff *skb, struct net_device *dev, @@ -64,6 +65,19 @@ return !(addr[0]&1) && memcmp( addr, zaddr, 6); } +/** + * random_ether_addr - Generate software assigned random Ethernet address + * @addr: Pointer to a six-byte array containing the Ethernet address + * + * Generate a random Ethernet address (MAC) that is not multicast + * and has the local assigned bit set. + */ +static inline void random_ether_addr(u8 *addr) +{ + get_random_bytes (addr, ETH_ALEN); + addr [0] &= 0xfe; /* clear multicast bit */ + addr [0] |= 0x02; /* set local assignment bit (IEEE802) */ +} #endif #endif /* _LINUX_ETHERDEVICE_H */ From shemminger@osdl.org Fri Apr 9 11:47:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 11:47:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39IlrKO029639 for ; Fri, 9 Apr 2004 11:47:53 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i39Ild219121; Fri, 9 Apr 2004 11:47:39 -0700 Date: Fri, 9 Apr 2004 11:45:50 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-usb-devel@lists.sourceforge.net Subject: [PATCH] (3/4) usb gadget -- use random_ether_addr Message-Id: <20040409114550.444abe30@dell_ss3.pdx.osdl.net> In-Reply-To: <20040408145403.34382c96.davem@redhat.com> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4588 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: 1140 Lines: 26 Use new common code in ether_device.h for random_ether_addr. Same exact code just in one common place. diff -Nru a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c --- a/drivers/usb/gadget/ether.c Fri Apr 9 11:39:51 2004 +++ b/drivers/usb/gadget/ether.c Fri Apr 9 11:39:51 2004 @@ -1804,17 +1804,13 @@ /* one random address for the gadget device ... both of these could * reasonably come from an id prom or a module parameter. */ - get_random_bytes (net->dev_addr, ETH_ALEN); - net->dev_addr [0] &= 0xfe; // clear multicast bit - net->dev_addr [0] |= 0x02; // set local assignment bit (IEEE802) + random_ether_addr(net->dev_addr); #ifdef DEV_CONFIG_CDC /* ... another address for the host, on the other end of the * link, gets exported through CDC (see CDC spec table 41) */ - get_random_bytes (node_id, sizeof node_id); - node_id [0] &= 0xfe; // clear multicast bit - node_id [0] |= 0x02; // set local assignment bit (IEEE802) + random_ether_addr(node_id); snprintf (ethaddr, sizeof ethaddr, "%02X%02X%02X%02X%02X%02X", node_id [0], node_id [1], node_id [2], node_id [3], node_id [4], node_id [5]); From ak@suse.de Fri Apr 9 12:08:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 12:08:21 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39J86KO032666 for ; Fri, 9 Apr 2004 12:08:07 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 8D6B8425E01; Fri, 9 Apr 2004 20:24:33 +0200 (CEST) Date: Fri, 9 Apr 2004 20:24:38 +0200 From: Andi Kleen To: "YOSHIFUJI Hideaki / _$B5HF#1QL@" Cc: davem@redhat.com, netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040409202438.5ff80565.ak@suse.de> In-Reply-To: <20040410.030904.82108741.yoshfuji@linux-ipv6.org> References: <20040409193123.63e4cdc7.ak@suse.de> <20040410.024705.97089877.yoshfuji@linux-ipv6.org> <20040409195052.10ba931c.ak@suse.de> <20040410.030904.82108741.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4589 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 514 Lines: 17 On Sat, 10 Apr 2004 03:09:04 +0900 (JST) YOSHIFUJI Hideaki / _$B5HF#1QL@ wrote: > In article <20040409195052.10ba931c.ak@suse.de> (at Fri, 9 Apr 2004 19:50:52 +0200), Andi Kleen says: > > > > NETDEBUG_PRINTK_LIMIT("overrun destopt\n"..) > > > > > > (or something like this) much more. > > > > ... and this will make the lines even longer. > > If you mind that, you can use shorter name > like IP6DEBUG / IP6DEBUG_LIMIT() etc. Yes, I opted for NETDEBUG_LIMIT. -Andi From tmattox@engr.uky.edu Fri Apr 9 12:31:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 12:31:12 -0700 (PDT) Received: from skyhawk.ecc.engr.uky.edu (skyhawk.ecc.engr.uky.edu [128.163.144.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39JV6KO005520 for ; Fri, 9 Apr 2004 12:31:06 -0700 Received: from tmattox (helo=localhost) by skyhawk.ecc.engr.uky.edu with local-esmtp (Exim 3.33 #1) id 1BC1hy-0004zG-00; Fri, 09 Apr 2004 15:30:34 -0400 Date: Fri, 9 Apr 2004 15:30:34 -0400 (EDT) From: Timothy I Mattox X-X-Sender: tmattox@skyhawk.ecc.engr.uky.edu To: tulip-devel@lists.sourceforge.net cc: jgarzik@pobox.com, Subject: [PATCH] tulip, kernel 2.4.26-rc2, 2nd try In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4590 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 3168 Lines: 71 Resubmitting ADMtek Comet MII support patch... Here is a patch for the tulip driver found in kernel 2.4.26-rc2 This adds MII functionality to the ADMtek Comet flavor of the tulip, specifically, the ability to detect and report the link status with MII. This is critical for use with newer channel bonding drivers. I've tested on several Linksys LNE100TX v4.1 PCI cards, as well as on an HP Pavilion N5475 laptop with a built-in NIC that is detected as this same model of chip. I have over 750 of this model tulip card in use in various beowulf clusters. This patch was modeled after Donald Becker's tulip.c:v0.98 1/8/2004, but the specific bits from his driver have been there for about two years. (See: http://sourceforge.net/mailarchive/message.php?msg_id=1841280) Please apply to 2.4 mainline. If this is accepted, I will convert & test it for the 2.6 kernel series as well. -- Tim Mattox - tmattox@engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/ChangeLog linux-2.4.26-rc2-comet/drivers/net/tulip/ChangeLog --- linux-2.4.26-rc2/drivers/net/tulip/ChangeLog Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/ChangeLog Fri Apr 9 15:08:44 2004 @@ -1,3 +1,11 @@ +2004-04-02 Tim Mattox + + Add MII support for ADMtek Comet (Linksys LNE100TX v4.1 & others): + * tulip_core.c: add HAS_MII flag to COMET entry in tulip_tbl[] + * timer.c (comet_timer): add missing call to tulip_check_duplex() + and replace inl() calls with tulip_mdio_read() calls + Changes modeled after Donald Becker's tulip.c:v0.98 1/8/2004 + 2002-09-18 Ryan Bradetich tulip hppa support: diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/timer.c linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c --- linux-2.4.26-rc2/drivers/net/tulip/timer.c Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c Fri Apr 9 15:08:44 2004 @@ -211,10 +211,16 @@ void comet_timer(unsigned long data) if (tulip_debug > 1) printk(KERN_DEBUG "%s: Comet link status %4.4x partner capability " "%4.4x.\n", - dev->name, inl(ioaddr + 0xB8), inl(ioaddr + 0xC8)); + dev->name, + tulip_mdio_read(dev, tp->phys[0], 1), + tulip_mdio_read(dev, tp->phys[0], 5)); /* mod_timer synchronizes us with potential add_timer calls * from interrupts. */ + if (tulip_check_duplex(dev) < 0) + { /* netif_carrier_off(dev); */ } + else + { /* netif_carrier_on(dev); */ } mod_timer(&tp->timer, RUN_AT(next_tick)); } diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/tulip_core.c linux-2.4.26-rc2-comet/drivers/net/tulip/tulip_core.c --- linux-2.4.26-rc2/drivers/net/tulip/tulip_core.c Fri Apr 9 15:02:34 2004 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/tulip_core.c Fri Apr 9 15:08:44 2004 @@ -176,7 +176,7 @@ struct tulip_chip_table tulip_tbl[] = { /* COMET */ { "ADMtek Comet", 256, 0x0001abef, - MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, + HAS_MII | MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, /* COMPEX9881 */ { "Compex 9881 PMAC", 128, 0x0001ebef, From tmattox@engr.uky.edu Fri Apr 9 12:44:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 12:44:31 -0700 (PDT) Received: from skyhawk.ecc.engr.uky.edu (skyhawk.ecc.engr.uky.edu [128.163.144.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39JiSKO006956 for ; Fri, 9 Apr 2004 12:44:29 -0700 Received: from tmattox (helo=localhost) by skyhawk.ecc.engr.uky.edu with local-esmtp (Exim 3.33 #1) id 1BC1uG-00050H-00; Fri, 09 Apr 2004 15:43:16 -0400 Date: Fri, 9 Apr 2004 15:43:16 -0400 (EDT) From: Timothy I Mattox X-X-Sender: tmattox@skyhawk.ecc.engr.uky.edu To: Jeff Garzik cc: tulip-devel@lists.sourceforge.net, Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 2nd try In-Reply-To: <4076FA7F.7020801@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4591 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 485 Lines: 16 OK, testing now... I had the netif_carrier_xxx code commented out from seeing them commented out in the tulip_timer routine just a few lines above in the comet_timer() routine. On Fri, 9 Apr 2004, Jeff Garzik wrote: > Looks OK, but can you test without netif_carrier_xxx commented out? > > I would prefer to leave those active. > > Jeff -- Tim Mattox - tmattox@engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ From romieu@fr.zoreil.com Fri Apr 9 13:01:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 13:01:45 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39K1dKO008016 for ; Fri, 9 Apr 2004 13:01:40 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i39JwHgf022260; Fri, 9 Apr 2004 21:58:17 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i39JwHd8022259; Fri, 9 Apr 2004 21:58:17 +0200 Date: Fri, 9 Apr 2004 21:58:17 +0200 From: Francois Romieu To: Timothy I Mattox Cc: tulip-devel@lists.sourceforge.net, jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 2nd try Message-ID: <20040409215817.A22121@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from tmattox@engr.uky.edu on Fri, Apr 09, 2004 at 03:30:34PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 4592 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 499 Lines: 16 Timothy I Mattox : [...] > diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/timer.c linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c > --- linux-2.4.26-rc2/drivers/net/tulip/timer.c Fri Jun 13 10:51:35 2003 > +++ linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c Fri Apr 9 15:08:44 2004 [...] > + if (tulip_check_duplex(dev) < 0) > + { /* netif_carrier_off(dev); */ } > + else > + { /* netif_carrier_on(dev); */ } > mod_timer(&tp->timer, RUN_AT(next_tick)); ? -- Ueimor From tmattox@engr.uky.edu Fri Apr 9 13:40:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 13:41:15 -0700 (PDT) Received: from skyhawk.ecc.engr.uky.edu (skyhawk.ecc.engr.uky.edu [128.163.144.19]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39KesKO010223 for ; Fri, 9 Apr 2004 13:40:55 -0700 Received: from tmattox (helo=localhost) by skyhawk.ecc.engr.uky.edu with local-esmtp (Exim 3.33 #1) id 1BC2mD-00052L-00; Fri, 09 Apr 2004 16:39:01 -0400 Date: Fri, 9 Apr 2004 16:39:01 -0400 (EDT) From: Timothy I Mattox X-X-Sender: tmattox@skyhawk.ecc.engr.uky.edu To: Jeff Garzik cc: tulip-devel@lists.sourceforge.net, Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 3rd try In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4593 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tmattox@engr.uky.edu Precedence: bulk X-list: netdev Content-Length: 3185 Lines: 75 Attached is the patch with the netif_carrier_xxx() calls active for the ADMtek Comet version of the tulip. I tested pulling the cable & reconnecting it on both a laptop as well as a desktop machine with a LNE100TX v4.1 and tulip_debug=2. All appears to work as expected. If you like, I can submit a seperate patch enabling netif_carrier_xxx() in the rest of the tulip driver, but I don't have other flavors of tulip cards to test on. It looks like the calls are all there, just that they are commented out. -- Tim Mattox - tmattox@engr.uky.edu - http://homepage.mac.com/tmattox/ http://aggregate.org/KAOS/ - http://advogato.org/person/tmattox/ On Fri, 9 Apr 2004, Timothy I Mattox wrote: > OK, testing now... I had the netif_carrier_xxx code commented out > from seeing them commented out in the tulip_timer routine just a few > lines above in the comet_timer() routine. > > On Fri, 9 Apr 2004, Jeff Garzik wrote: > > Looks OK, but can you test without netif_carrier_xxx commented out? > > > > I would prefer to leave those active. > > > > Jeff diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/ChangeLog linux-2.4.26-rc2-comet/drivers/net/tulip/ChangeLog --- linux-2.4.26-rc2/drivers/net/tulip/ChangeLog Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/ChangeLog Fri Apr 9 15:08:44 2004 @@ -1,3 +1,11 @@ +2004-04-02 Tim Mattox + + Add MII support for ADMtek Comet (Linksys LNE100TX v4.1 & others): + * tulip_core.c: add HAS_MII flag to COMET entry in tulip_tbl[] + * timer.c (comet_timer): add missing call to tulip_check_duplex() + and replace inl() calls with tulip_mdio_read() calls + Changes modeled after Donald Becker's tulip.c:v0.98 1/8/2004 + 2002-09-18 Ryan Bradetich tulip hppa support: diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/timer.c linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c --- linux-2.4.26-rc2/drivers/net/tulip/timer.c Fri Jun 13 10:51:35 2003 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/timer.c Fri Apr 9 15:37:32 2004 @@ -211,10 +211,16 @@ void comet_timer(unsigned long data) if (tulip_debug > 1) printk(KERN_DEBUG "%s: Comet link status %4.4x partner capability " "%4.4x.\n", - dev->name, inl(ioaddr + 0xB8), inl(ioaddr + 0xC8)); + dev->name, + tulip_mdio_read(dev, tp->phys[0], 1), + tulip_mdio_read(dev, tp->phys[0], 5)); /* mod_timer synchronizes us with potential add_timer calls * from interrupts. */ + if (tulip_check_duplex(dev) < 0) + { netif_carrier_off(dev); } + else + { netif_carrier_on(dev); } mod_timer(&tp->timer, RUN_AT(next_tick)); } diff -Naur -p linux-2.4.26-rc2/drivers/net/tulip/tulip_core.c linux-2.4.26-rc2-comet/drivers/net/tulip/tulip_core.c --- linux-2.4.26-rc2/drivers/net/tulip/tulip_core.c Fri Apr 9 15:02:34 2004 +++ linux-2.4.26-rc2-comet/drivers/net/tulip/tulip_core.c Fri Apr 9 15:08:44 2004 @@ -176,7 +176,7 @@ struct tulip_chip_table tulip_tbl[] = { /* COMET */ { "ADMtek Comet", 256, 0x0001abef, - MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, + HAS_MII | MC_HASH_ONLY | COMET_MAC_ADDR, comet_timer }, /* COMPEX9881 */ { "Compex 9881 PMAC", 128, 0x0001ebef, From jgarzik@pobox.com Fri Apr 9 13:59:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 13:59:38 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39KxVKO011367 for ; Fri, 9 Apr 2004 13:59:32 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BC360-0002Iz-T7; Fri, 09 Apr 2004 21:59:29 +0100 Message-ID: <40770EA3.6040102@pobox.com> Date: Fri, 09 Apr 2004 16:59:15 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy I Mattox CC: tulip-devel@lists.sourceforge.net, netdev@oss.sgi.com, Jay Estabrook , jamal Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 3rd try References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------020704050303040808080803" X-archive-position: 4594 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: 20814 Lines: 646 This is a multi-part message in MIME format. --------------020704050303040808080803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Timothy I Mattox wrote: > Attached is the patch with the netif_carrier_xxx() calls active > for the ADMtek Comet version of the tulip. > I tested pulling the cable & reconnecting it on both a laptop as well > as a desktop machine with a LNE100TX v4.1 and tulip_debug=2. > All appears to work as expected. Thanks, patch applied to 2.4 and 2.6. > If you like, I can submit a seperate patch enabling netif_carrier_xxx() > in the rest of the tulip driver, but I don't have other flavors of > tulip cards to test on. It looks like the calls are all there, just > that they are commented out. It's not ready to turn them all on yet, unfortunately. Tulip driver desperately wants ethtool support, too. Dr. Jamal Salim ported the phy code from a recent version of Donald Becker's tulip.c to upstream... that's what we really want to merge. Jay Estabrook updated this while pursuing tulip problems on alpha. This patch needs testing and merging... Jeff --------------020704050303040808080803 Content-Type: text/plain; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" diff -Naurp old/drivers/net/tulip/21142.c new/drivers/net/tulip/21142.c --- old/drivers/net/tulip/21142.c Wed Dec 17 21:58:28 2003 +++ new/drivers/net/tulip/21142.c Wed Jan 21 12:45:05 2004 @@ -23,6 +23,114 @@ static u16 t21142_csr13[] = { 0x0001, 0x u16 t21142_csr14[] = { 0xFFFF, 0x0705, 0x0705, 0x0000, 0x7F3D, }; static u16 t21142_csr15[] = { 0x0008, 0x0006, 0x000E, 0x0008, 0x0008, }; +void +print_csr12(unsigned int new,unsigned int old) { + printk("BIT FIELD NEW OLD\n"); + printk("LPC %04x %04x\n", ((new & 0xffff0000) >> 16), + ((old & 0xffff0000) >> 16)); + printk("LPN %01x %01x\n", ((new & 0x8000) >> 15), + ((old & 0x8000) >> 15)); + printk("ANS %01x %01x\n", ((new & 0x7000) >> 12), + ((old & 0x7000) >> 12)); + printk("TRF %01x %01x\n", ((new & 0x800) >> 11), + ((old & 0x800) >> 11)); + printk("NSN %01x %01x\n", ((new & 0x400) >> 10), + ((old & 0x400) >> 10)); + printk("TRA %01x %01x\n", ((new & 0x200) >> 9), + ((old & 0x200) >> 9)); + printk("ARA %01x %01x\n", ((new & 0x100) >> 8), + ((old & 0x100) >> 8)); + printk("APS %01x %01x\n", ((new & 0x8) >> 3), + ((old & 0x8) >> 3)); + printk("LS10 %01x %01x\n", ((new & 0x4) >> 2), + ((old & 0x4) >> 2)); + printk("LS100 %01x %01x\n", ((new & 0x2) >> 1), + ((old & 0x2) >> 1)); + printk("MRA %01x %01x\n", (new & 0x1), + (old & 0x1)); + + +} + +void +chk_lnk_st( struct net_device *dev) +{ + struct tulip_private *tp = (struct tulip_private *)dev->priv; + unsigned long flags; + long ioaddr = dev->base_addr; + int csr12 = inl(ioaddr + CSR12); + + + spin_lock_irqsave (&tp->lock, flags); + + if (tp->lnc) { +lnk_changed: + if (tp->scsr12 != csr12) { + +// print_csr12(csr12,tp->scsr12); + + if ((csr12 & 0x6) == (tp->scsr12 & 0x6)) + goto done; /* no interest in other bits */ + + if (tp->medialock) { + if(!tulip_chk_fixed_media(dev)) + goto link_down; + } + + if (!(tp->lnc & MEDIA_CONNECTED)) { + if ((tp->lnc & MEDIA_INITIALIZED)) { + if ((!(csr12 & 4) || !(csr12 & 2)) && + ((tp->scsr12 & 4) && (tp->scsr12 & 2))){ + printk("\n %s %s Link up!\n",dev->name,medianame[dev->if_port]); + tp->lnc |= MEDIA_CONNECTED; + netif_carrier_on(dev); + } + } else { /* first time */ + if (!(csr12 & 4) || !(csr12 & 2)) { + printk("\n %s %s Link up!\n",dev->name,medianame[dev->if_port]); + tp->lnc |= MEDIA_INITIALIZED; + tp->lnc |= MEDIA_CONNECTED; + netif_carrier_on(dev); + } + } + } else { + if (!(tp->lnc & MEDIA_INITIALIZED)) { + printk(" \nBUG on INIT !\n"); + } + + if ((!(tp->scsr12 & 4) || !(tp->scsr12 & 2)) && + ((csr12 & 4) && (csr12 & 2))) { +link_down: + printk(" \n %s Link down!\n",dev->name); + tp->lnc &= ~MEDIA_CONNECTED; + netif_carrier_off(dev); + } else { + if (tp->medialock) { + if(tulip_chk_fixed_media(dev)) { + tp->scsr12 = csr12; + goto done; + } + } + printk(" BUG3: %s lnc %x csr12 %x old csr12 %x\n",dev->name,tp->lnc,csr12,tp->scsr12); + } + } + + tp->scsr12 = csr12; + } + +done: + tp->lnc &= ~(MEDIA_CHANGED); + } else { + /* FIXME: weird behavior: we missed other sides interupt + * needs investigation */ + if (tulip_debug > 1) + printk("\n %s csr12 %x not lnc!!\n",dev->name,csr12); + tp->lnc &= MEDIA_CHANGED; + goto lnk_changed; + } + spin_unlock_irqrestore (&tp->lock, flags); + +} /* Handle the 21143 uniquely: do autoselect with NWay, not the EEPROM list of available transceivers. */ @@ -35,9 +143,7 @@ void t21142_timer(unsigned long data) int next_tick = 60*HZ; int new_csr6 = 0; - if (tulip_debug > 2) - printk(KERN_INFO"%s: 21143 negotiation status %8.8x, %s.\n", - dev->name, csr12, medianame[dev->if_port]); + if (tulip_media_cap[dev->if_port] & MediaIsMII) { if (tulip_check_duplex(dev) < 0) { netif_carrier_off(dev); @@ -52,7 +158,12 @@ void t21142_timer(unsigned long data) printk(KERN_INFO"%s: Using NWay-set %s media, csr12 %8.8x.\n", dev->name, medianame[dev->if_port], csr12); } else if (tp->medialock) { - ; + + if (tp->lnc&MEDIA_CONNECTED && !tulip_chk_fixed_media(dev)) { + printk("timer: %s recovering fixed media new csr12 %x old %x\n",dev->name,csr12,tp->scsr12); + tulip_select_fixed_media(dev); + } + } else if (dev->if_port == 3) { if (csr12 & 2) { /* No 100mbps link beat, revert to 10mbps. */ if (tulip_debug > 1) @@ -85,15 +196,18 @@ void t21142_timer(unsigned long data) if (tulip_debug > 1) printk(KERN_INFO"%s: Testing new 21143 media %s.\n", dev->name, medianame[dev->if_port]); - if (new_csr6 != (tp->csr6 & ~0x00D5)) { - tp->csr6 &= 0x00D5; + if (new_csr6 != (tp->csr6 & ~0x20D7)) { + tp->csr6 &= 0x20D7; tp->csr6 |= new_csr6; outl(0x0301, ioaddr + CSR12); - tulip_restart_rxtx(tp); + outl(tp->csr6 | RxOn, ioaddr + CSR6); + outl(tp->csr6 | TxOn | RxOn, ioaddr + CSR6); } next_tick = 3*HZ; } + chk_lnk_st(dev); + /* mod_timer synchronizes us with potential add_timer calls * from interrupts. */ @@ -108,6 +222,9 @@ void t21142_start_nway(struct net_device int csr14 = ((tp->sym_advertise & 0x0780) << 9) | ((tp->sym_advertise & 0x0020) << 1) | 0xffbf; + if(tp->medialock) + return; + dev->if_port = 0; tp->nway = tp->mediasense = 1; tp->nwayset = tp->lpar = 0; @@ -115,9 +232,9 @@ void t21142_start_nway(struct net_device printk(KERN_DEBUG "%s: Restarting 21143 autonegotiation, csr14=%8.8x.\n", dev->name, csr14); outl(0x0001, ioaddr + CSR13); - udelay(100); outl(csr14, ioaddr + CSR14); - tp->csr6 = 0x82420000 | (tp->sym_advertise & 0x0040 ? FullDuplex : 0); + tp->csr6 = 0x82420000 | (tp->sym_advertise & 0x0040 ? FullDuplex : 0) + | (tp->csr6 & 0x20ff); outl(tp->csr6, ioaddr + CSR6); if (tp->mtable && tp->mtable->csr15dir) { outl(tp->mtable->csr15dir, ioaddr + CSR15); @@ -128,7 +245,6 @@ void t21142_start_nway(struct net_device } - void t21142_lnk_change(struct net_device *dev, int csr5) { struct tulip_private *tp = (struct tulip_private *)dev->priv; @@ -136,8 +252,10 @@ void t21142_lnk_change(struct net_device int csr12 = inl(ioaddr + CSR12); if (tulip_debug > 1) - printk(KERN_INFO"%s: 21143 link status interrupt %8.8x, CSR5 %x, " - "%8.8x.\n", dev->name, csr12, csr5, inl(ioaddr + CSR14)); + printk(KERN_INFO"%s: IN 21143 link status interrupt %8.8x, media %d, CSR5 %x, " + "%8.8x.\n", dev->name, csr12, dev->if_port, csr5, inl(ioaddr + CSR14)); + + tp->lnc |= MEDIA_CHANGED; /* If NWay finished and we have a negotiated partner capability. */ if (tp->nway && !tp->nwayset && (csr12 & 0x7000) == 0x5000) { @@ -172,9 +290,9 @@ void t21142_lnk_change(struct net_device int i; for (i = 0; i < tp->mtable->leafcount; i++) if (tp->mtable->mleaf[i].media == dev->if_port) { - int startup = ! ((tp->chip_id == DC21143 && tp->revision == 65)); + //int startup = ! ((tp->chip_id == DC21143 && tp->revision == 65)); tp->cur_index = i; - tulip_select_media(dev, startup); + tulip_select_media(dev, 0); setup_done = 1; break; } @@ -215,7 +333,7 @@ void t21142_lnk_change(struct net_device t21142_start_nway(dev); tp->timer.expires = RUN_AT(3*HZ); add_timer(&tp->timer); - } else if (dev->if_port == 5) + } else if (!tp->medialock && dev->if_port == 5) outl(inl(ioaddr + CSR14) & ~0x080, ioaddr + CSR14); } else if (dev->if_port == 0 || dev->if_port == 4) { if ((csr12 & 4) == 0) @@ -225,7 +343,8 @@ void t21142_lnk_change(struct net_device if (tulip_debug) printk(KERN_INFO"%s: 21143 10mbps sensed media.\n", dev->name); - dev->if_port = 0; + if (!tp->medialock) + dev->if_port = 0; } else if (tp->nwayset) { if (tulip_debug) printk(KERN_INFO"%s: 21143 using NWay-set %s, csr6 %8.8x.\n", @@ -234,12 +353,18 @@ void t21142_lnk_change(struct net_device if (tulip_debug) printk(KERN_INFO"%s: 21143 100baseTx sensed media.\n", dev->name); - dev->if_port = 3; - tp->csr6 = 0x838E0000 | (tp->csr6 & 0x20ff); - outl(0x0003FF7F, ioaddr + CSR14); - outl(0x0301, ioaddr + CSR12); - tulip_restart_rxtx(tp); + if (!tp->medialock) { + dev->if_port = 3; + tp->csr6 = 0x838E0000 | (tp->csr6 & 0x20ff); + outl(0x0003FF7F, ioaddr + CSR14); + outl(0x0301, ioaddr + CSR12); + outl(tp->csr6 | RxOn, ioaddr + CSR6); + outl(tp->csr6 | RxOn | TxOn, ioaddr + CSR6); + //tulip_restart_rxtx(tp); + } } -} + chk_lnk_st( dev); + +} diff -Naurp old/drivers/net/tulip/media.c new/drivers/net/tulip/media.c --- old/drivers/net/tulip/media.c Wed Dec 17 21:58:29 2003 +++ new/drivers/net/tulip/media.c Wed Jan 21 12:45:05 2004 @@ -71,6 +71,8 @@ int tulip_mdio_read(struct net_device *d outl(0x60020000 + (phy_id<<23) + (location<<18), ioaddr + 0xA0); inl(ioaddr + 0xA0); inl(ioaddr + 0xA0); + inl(ioaddr + 0xA0); + inl(ioaddr + 0xA0); while (--i > 0) { barrier(); if ( ! ((retval = inl(ioaddr + 0xA0)) & 0x80000000)) @@ -166,6 +168,116 @@ void tulip_mdio_write(struct net_device spin_unlock_irqrestore(&tp->mii_lock, flags); } +int tulip_chk_fixed_media(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + struct tulip_private *tp = (struct tulip_private *)dev->priv; + u32 csr12 = inl(ioaddr + CSR12); + int ret = 0; + + if (!tp->medialock) { + printk(KERN_DEBUG "%s: Bad call to check force media %s\n", + dev->name, medianame[dev->if_port]); + return 0; + } + + switch(dev->if_port) { + + case 4: + case 12: + if (! (csr12&4)) + ret = 1; + break; + case 5: + /* Fall Through */ + case 3: + if (! (csr12&2)) + ret = 1; + break; + default: + printk(KERN_DEBUG " %s: Bad type force media chk %s\n", + dev->name, medianame[dev->if_port]); + } + + + return ret; +} + +void tulip_select_fixed_media(struct net_device *dev) +{ + long ioaddr = dev->base_addr; + struct tulip_private *tp = (struct tulip_private *)dev->priv; + u32 csr6=0, csr13=0, csr14=0, csr15=0,csr12=0; + int goodm = 0; + + csr6 = tp->csr6 & ~(FullDuplex | csr6_om_int_loop | csr6_ps) ; + + if (!tp->medialock) { + printk(KERN_DEBUG "%s: Bad call to force media to %s\n", + dev->name, medianame[dev->if_port]); + return; + } + + switch(dev->if_port) { + + case 12: + goodm = 1; + tp->csr6 = csr6; + csr14 = 0x7F3F; + csr13 = 1; + break; + case 4: + goodm = 1; + csr13 = 0x0001; + csr14 = 0x7F3D; + tp->csr6 = csr6 | FullDuplex; + break; + + case 5: + goodm = 1; + tp->csr6 = csr6 | FullDuplex; + /* Fall Through */ + + case 3: + goodm = 1; + csr13 = 0x0000; + csr14 = 0x0000; + tp->csr6 |= csr6_ps | csr6_hbd; + break; + + default: + printk(KERN_DEBUG " %s: Bad type force media to %s\n", + dev->name, medianame[dev->if_port]); + } + + if (goodm) { + printk(KERN_DEBUG " %s: Fixed force media to %s\n", + dev->name, medianame[dev->if_port]); + if (tp->sym_advertise) { + csr15 = 0x40000|8; + tp->csr6 |= (csr6_pcs | csr6_scr); + } else { + csr15 = 8; + } + outl(tp->csr6,ioaddr + CSR6); + outl(0,ioaddr + CSR13); + udelay(1); + outl(csr14,ioaddr + CSR14); + outl(csr13,ioaddr + CSR13); + outl(csr15,ioaddr + CSR15); + udelay(5); + csr12 = inl(ioaddr+CSR12); + if (tulip_debug > 1) + printk(" -->fixed media: csr6 %x csr7 %x valid %x csr12 %x\n",inl(ioaddr+CSR6),inl(ioaddr+CSR7),tulip_tbl[tp->chip_id].valid_intrs,csr12); + if (tulip_chk_fixed_media(dev)) { + tp->lnc |= MEDIA_INITIALIZED; + tp->scsr12 = csr12; + printk("%s %s Link up!\n",dev->name,medianame[dev->if_port]); + netif_carrier_on(dev); + } + } + +} /* Set up the transceiver control registers for the selected media type. */ void tulip_select_media(struct net_device *dev, int startup) @@ -176,11 +288,18 @@ void tulip_select_media(struct net_devic u32 new_csr6; int i; + if (tp->medialock) { + printk(KERN_DEBUG "===> %s: forced media to %s\n", + dev->name, medianame[dev->if_port]); + tulip_select_fixed_media(dev); + return; + } + if (mtable) { struct medialeaf *mleaf = &mtable->mleaf[tp->cur_index]; unsigned char *p = mleaf->leafdata; switch (mleaf->type) { - case 0: /* 21140 non-MII xcvr. */ + case 0: /* 21140 non-MII xcvr. */ if (tulip_debug > 1) printk(KERN_DEBUG "%s: Using a 21140 non-MII transceiver" " with control setting %2.2x.\n", @@ -226,7 +345,7 @@ void tulip_select_media(struct net_devic outl(csr13val, ioaddr + CSR13); } else { csr13val = 1; - csr14val = 0; + csr14val = 0x0003FFFF; csr15dir = (setup[0]<<16) | 0x0008; csr15val = (setup[1]<<16) | 0x0008; if (dev->if_port <= 4) @@ -243,7 +362,7 @@ void tulip_select_media(struct net_devic printk(KERN_DEBUG "%s: Setting CSR15 to %8.8x/%8.8x.\n", dev->name, csr15dir, csr15val); if (mleaf->type == 4) - new_csr6 = 0x82020000 | ((setup[2] & 0x71) << 18); + new_csr6 = 0x820A0000 | ((setup[2] & 0x71) << 18); else new_csr6 = 0x82420000; break; diff -Naurp old/drivers/net/tulip/tulip.h new/drivers/net/tulip/tulip.h --- old/drivers/net/tulip/tulip.h Wed Dec 17 21:59:39 2003 +++ new/drivers/net/tulip/tulip.h Wed Jan 21 13:32:07 2004 @@ -29,7 +29,7 @@ /* undefine, or define to various debugging levels (>4 == obscene levels) */ -#define TULIP_DEBUG 1 +#define TULIP_DEBUG 4 /* undefine USE_IO_OPS for MMIO, define for PIO */ #ifdef CONFIG_TULIP_MMIO @@ -156,6 +156,7 @@ enum tulip_mode_bits { AcceptAllPhys = 0x0040, AcceptRunt = 0x0008, RxOn = 0x0002, + CSR6_OM_INTLB = 0x00000400, /* Internal loopback mode*/ RxTx = (TxOn | RxOn), }; @@ -380,9 +381,15 @@ struct tulip_private { unsigned long nir; unsigned long base_addr; int csr12_shadow; + unsigned int scsr12; + unsigned int lnc; int pad0; /* Used for 8-byte alignment */ }; +#define MEDIA_CONNECTED 0x1 +#define MEDIA_CHANGED 0x2 +#define MEDIA_INITIALIZED 0x4 + struct eeprom_fixup { char *name; @@ -399,6 +406,7 @@ void t21142_timer(unsigned long data); void t21142_start_nway(struct net_device *dev); void t21142_lnk_change(struct net_device *dev, int csr5); +int tulip_chk_fixed_media(struct net_device *dev); /* PNIC2.c */ void pnic2_lnk_change(struct net_device *dev, int csr5); @@ -419,6 +427,7 @@ int tulip_refill_rx(struct net_device *d /* media.c */ int tulip_mdio_read(struct net_device *dev, int phy_id, int location); void tulip_mdio_write(struct net_device *dev, int phy_id, int location, int value); +void tulip_select_fixed_media(struct net_device *dev); void tulip_select_media(struct net_device *dev, int startup); int tulip_check_duplex(struct net_device *dev); void tulip_find_mii (struct net_device *dev, int board_idx); diff -Naurp old/drivers/net/tulip/tulip_core.c new/drivers/net/tulip/tulip_core.c --- old/drivers/net/tulip/tulip_core.c Wed Dec 17 21:58:57 2003 +++ new/drivers/net/tulip/tulip_core.c Wed Jan 21 12:56:06 2004 @@ -515,86 +515,50 @@ static void tulip_tx_timeout(struct net_ unsigned long flags; spin_lock_irqsave (&tp->lock, flags); + tulip_stop_rxtx(tp); - if (tulip_media_cap[dev->if_port] & MediaIsMII) { - /* Do nothing -- the media monitor should handle this. */ - if (tulip_debug > 1) - printk(KERN_WARNING "%s: Transmit timeout using MII device.\n", - dev->name); - } else if (tp->chip_id == DC21140 || tp->chip_id == DC21142 - || tp->chip_id == MX98713 || tp->chip_id == COMPEX9881 - || tp->chip_id == DM910X) { - printk(KERN_WARNING "%s: 21140 transmit timed out, status %8.8x, " - "SIA %8.8x %8.8x %8.8x %8.8x, resetting...\n", - dev->name, inl(ioaddr + CSR5), inl(ioaddr + CSR12), - inl(ioaddr + CSR13), inl(ioaddr + CSR14), inl(ioaddr + CSR15)); - if ( ! tp->medialock && tp->mtable) { - do - --tp->cur_index; - while (tp->cur_index >= 0 - && (tulip_media_cap[tp->mtable->mleaf[tp->cur_index].media] - & MediaIsFD)); - if (--tp->cur_index < 0) { - /* We start again, but should instead look for default. */ - tp->cur_index = tp->mtable->leafcount - 1; - } - tulip_select_media(dev, 0); - printk(KERN_WARNING "%s: transmit timed out, switching to %s " - "media.\n", dev->name, medianame[dev->if_port]); - } - } else if (tp->chip_id == PNIC2) { - printk(KERN_WARNING "%s: PNIC2 transmit timed out, status %8.8x, " - "CSR6/7 %8.8x / %8.8x CSR12 %8.8x, resetting...\n", - dev->name, (int)inl(ioaddr + CSR5), (int)inl(ioaddr + CSR6), - (int)inl(ioaddr + CSR7), (int)inl(ioaddr + CSR12)); - } else { - printk(KERN_WARNING "%s: Transmit timed out, status %8.8x, CSR12 " - "%8.8x, resetting...\n", - dev->name, inl(ioaddr + CSR5), inl(ioaddr + CSR12)); - dev->if_port = 0; - } + printk("\n%s: Possibly a bug in the driver, contact author\n", + dev->name); + printk(KERN_WARNING "%s:transmit timed out, \nstatus %8.8x, " + "SIA %8.8x %8.8x %8.8x %8.8x\n", + dev->name, inl(ioaddr + CSR5), inl(ioaddr + CSR12), + inl(ioaddr + CSR13), inl(ioaddr + CSR14),inl(ioaddr + CSR15)); + printk("%s: CSR6 %8.8x CSR7 %8.8x\n", + dev->name, inl(ioaddr + CSR6), inl(ioaddr + CSR7)); + if (tp->lnc) { + printk("%s: Link status",dev->name); + + if (tp->lnc & MEDIA_CONNECTED) + printk(": other side detected"); + else + printk(": No Cable connected"); + + if (tp->lnc & MEDIA_INITIALIZED) + printk(": INITIALIZED"); + else + printk(": Havent initialized detection"); -#if defined(way_too_many_messages) - if (tulip_debug > 3) { - int i; - for (i = 0; i < RX_RING_SIZE; i++) { - u8 *buf = (u8 *)(tp->rx_ring[i].buffer1); - int j; - printk(KERN_DEBUG "%2d: %8.8x %8.8x %8.8x %8.8x " - "%2.2x %2.2x %2.2x.\n", - i, (unsigned int)tp->rx_ring[i].status, - (unsigned int)tp->rx_ring[i].length, - (unsigned int)tp->rx_ring[i].buffer1, - (unsigned int)tp->rx_ring[i].buffer2, - buf[0], buf[1], buf[2]); - for (j = 0; buf[j] != 0xee && j < 1600; j++) - if (j < 100) printk(" %2.2x", buf[j]); - printk(" j=%d.\n", j); - } - printk(KERN_DEBUG " Rx ring %8.8x: ", (int)tp->rx_ring); - for (i = 0; i < RX_RING_SIZE; i++) - printk(" %8.8x", (unsigned int)tp->rx_ring[i].status); - printk("\n" KERN_DEBUG " Tx ring %8.8x: ", (int)tp->tx_ring); - for (i = 0; i < TX_RING_SIZE; i++) - printk(" %8.8x", (unsigned int)tp->tx_ring[i].status); + if (tp->lnc & MEDIA_CHANGED) + printk(": CHANGED"); printk("\n"); } -#endif + + /* we should really free the ring .. */ - /* Stop and restart the chip's Tx processes . */ #ifdef CONFIG_NET_HW_FLOWCONTROL - if (tp->fc_bit && test_bit(tp->fc_bit,&netdev_fc_xoff)) - printk("BUG tx_timeout restarting rx when fc on\n"); + if (tp->fc_bit && test_bit(tp->fc_bit,&netdev_fc_xoff)) + printk("BUG tx_timeout restarting rx when fc on\n"); #endif - tulip_restart_rxtx(tp); + + /* (Re)start the chip's Tx processes. */ + tulip_start_rxtx(tp); + /* Trigger an immediate transmit demand. */ outl(0, ioaddr + CSR1); - tp->stats.tx_errors++; spin_unlock_irqrestore (&tp->lock, flags); dev->trans_start = jiffies; - netif_wake_queue (dev); } --------------020704050303040808080803-- From jonmason@us.ibm.com Fri Apr 9 14:39:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 14:39:04 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39LcrKO013762; Fri, 9 Apr 2004 14:38:59 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i39LclcC535722; Fri, 9 Apr 2004 17:38:47 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i39LckG3351638; Fri, 9 Apr 2004 15:38:47 -0600 In-Reply-To: <20040328011052.GQ27747@krispykreme> To: scott.feldman@intel.com, Ganesh.Venkatesan@intel.com, john.ronciak@intel.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com Cc: Brian M Rzycki MIME-Version: 1.0 Subject: e1000 module unloadable during boot X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Fri, 9 Apr 2004 16:38:42 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/09/2004 15:38:47, Serialize complete at 04/09/2004 15:38:47 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4595 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1624 Lines: 38 Hey guys, We are experiencing a problem where the e1000 driver will fail module loading during boot. We did some debugging and found that the cause of this is the driver attempting to pci_alloc_consistent a transmit and receive descriptor ring size of zero. This occurs because there is a timing issue in the driver. The driver does not set the user definable attributes (defined in e1000_param.c), until after it registers the device with the kernel. This allows the possibility of the driver being opened before it can read these parameters (which is what is happening in this error). The fix is to move the reading of the user tunable parameters to before the registering of the device. --- e1000_main.c.orig 2004-04-08 13:51:34.967879752 -0500 +++ e1000_main.c 2004-04-08 14:34:48.113661672 -0500 @@ -536,6 +536,9 @@ e1000_probe(struct pci_dev *pdev, INIT_WORK(&adapter->tx_timeout_task, (void (*)(void *))e1000_tx_timeout_task, netdev); + e1000_check_options(adapter); + if((err = register_netdev(netdev))) goto err_register; @@ -544,9 +547,6 @@ e1000_probe(struct pci_dev *pdev, netif_carrier_off(netdev); netif_stop_queue(netdev); DPRINTK(PROBE, INFO, "Intel(R) PRO/1000 Network Connection\n"); - e1000_check_options(adapter); - /* Initial Wake on LAN setting * If APM wake is enabled in the EEPROM, * enable the ACPI Magic Packet filter Jon Mason jonmason@us.ibm.com Software Engineer Phone:(512)838.4162 Linux eServer I/O Fax: (512)838.3509 From davem@redhat.com Fri Apr 9 15:34:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 15:34:25 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39MYGKO017974 for ; Fri, 9 Apr 2004 15:34:16 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i39M6aTM012784; Fri, 9 Apr 2004 18:06:37 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i39MX6j17294; Fri, 9 Apr 2004 18:33:06 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i39MWe1n018803; Fri, 9 Apr 2004 18:32:40 -0400 Date: Fri, 9 Apr 2004 15:31:17 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com, tspat@de.ibm.com, shemminger@osdl.org Subject: Re: [PATCH] Force IPv6 FIB gc on device shutdown Message-Id: <20040409153117.490c9ba3.davem@redhat.com> In-Reply-To: <20040409173901.62ebf75b.ak@suse.de> References: <20040409173901.62ebf75b.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4596 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1225 Lines: 44 Thanks Andi. A week ago Thomas Spatzier posted a similar patch, and I had asked Stephen Hemminger (in private email) for his take on this. So here is the final patch I applied, based upon your and Thomas's patches, plus Stephen's commentary. (hint: NETDEV_DOWN is sufficient, because unregister causes a NETDEV_DOWN event if necessary). Thanks everyone. # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/04/09 15:29:23-07:00 davem@nuts.davemloft.net # [IPV6]: In ndisc_netdev_event, handle NETDEV_DOWN. # # Based upon patches and commentary from Thomas Spatzier, # Stephen Hemminger, and Andi Kleen. # # net/ipv6/ndisc.c # 2004/04/09 15:29:00-07:00 davem@nuts.davemloft.net +4 -0 # [IPV6]: In ndisc_netdev_event, handle NETDEV_DOWN. # # Based upon patches and commentary from Thomas Spatzier, # Stephen Hemminger, and Andi Kleen. # diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c Fri Apr 9 15:30:59 2004 +++ b/net/ipv6/ndisc.c Fri Apr 9 15:30:59 2004 @@ -1403,6 +1403,10 @@ neigh_changeaddr(&nd_tbl, dev); fib6_run_gc(0); break; + case NETDEV_DOWN: + neigh_ifdown(&nd_tbl, dev); + fib6_run_gc(0); + break; default: break; } From davem@redhat.com Fri Apr 9 16:29:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 16:29:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39NT8KO024774 for ; Fri, 9 Apr 2004 16:29:11 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i39NT2MC003080; Fri, 9 Apr 2004 19:29:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i39NT2j31503; Fri, 9 Apr 2004 19:29:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i39NSZ1n003841; Fri, 9 Apr 2004 19:28:35 -0400 Date: Fri, 9 Apr 2004 16:27:12 -0700 From: "David S. Miller" To: Shirley Ma Cc: xma@us.ibm.com, yoshfuji@linux-ipv6.org, netdev@oss.sgi.com, yoshfuji@cerberus.hongo.wide.ad.jp Subject: Re: Fix IPv6 MIBs counters in 2.6.5 kernel Message-Id: <20040409162712.243edcda.davem@redhat.com> In-Reply-To: <200404051711.27188.mashirle@us.ibm.com> References: <200404051351.09740.mashirle@us.ibm.com> <20040405144213.198f76ea.davem@redhat.com> <200404051711.27188.mashirle@us.ibm.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4597 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 46 Lines: 4 Looks great Shirley, patch applied. Thanks. From davem@redhat.com Fri Apr 9 16:33:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 16:33:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39NXhKO025271 for ; Fri, 9 Apr 2004 16:33:44 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i39NXbMC004086; Fri, 9 Apr 2004 19:33:37 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i39NXbj32551; Fri, 9 Apr 2004 19:33:37 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i39NXB1n005327; Fri, 9 Apr 2004 19:33:11 -0400 Date: Fri, 9 Apr 2004 16:31:48 -0700 From: "David S. Miller" To: "Randy.Dunlap" Cc: netdev@oss.sgi.com Subject: Re: [janitor] remove concat. with __FUNCTION__ (net/) Message-Id: <20040409163148.5f95356e.davem@redhat.com> In-Reply-To: <20040406144610.2471dcf7.rddunlap@osdl.org> References: <20040406144610.2471dcf7.rddunlap@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4598 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 213 Lines: 8 On Tue, 6 Apr 2004 14:46:10 -0700 "Randy.Dunlap" wrote: > From: Tony Breeds > > "concatenation of string literals with __FUNCTION__ is deprecated" Applied, thanks. From davem@redhat.com Fri Apr 9 16:38:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 16:38:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39NcgKO025638 for ; Fri, 9 Apr 2004 16:38:45 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i39NcbMC005294; Fri, 9 Apr 2004 19:38:37 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i39Ncbj01401; Fri, 9 Apr 2004 19:38:37 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i39NcB1n006966; Fri, 9 Apr 2004 19:38:11 -0400 Date: Fri, 9 Apr 2004 16:36:48 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: get atm_guess_pdu2truesize() right Message-Id: <20040409163648.79ab815a.davem@redhat.com> In-Reply-To: <200404071205.i37C58MO020742@ginger.cmf.nrl.navy.mil> References: <200404071205.i37C58MO020742@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4599 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 210 Lines: 8 On Wed, 07 Apr 2004 08:05:09 -0400 "chas williams (contractor)" wrote: > please apply to 2.6 and 2.4 kernels. ... > # [ATM]: get atm_guess_pdu2truesize() right Applied, thanks Chas. From davem@redhat.com Fri Apr 9 16:40:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 16:40:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39NeCKO025783 for ; Fri, 9 Apr 2004 16:40:13 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i39Ne7MC005647; Fri, 9 Apr 2004 19:40:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i39Ne7j01628; Fri, 9 Apr 2004 19:40:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i39Ndf1n007261; Fri, 9 Apr 2004 19:39:41 -0400 Date: Fri, 9 Apr 2004 16:38:18 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: [nicstar] using dev_alloc_skb() (reported by "Johnston, Jayme" ) Message-Id: <20040409163818.7e2b6f71.davem@redhat.com> In-Reply-To: <200404071211.i37CB3gK020805@ginger.cmf.nrl.navy.mil> References: <200404071211.i37CB3gK020805@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4600 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 653 Lines: 16 On Wed, 07 Apr 2004 08:11:04 -0400 "chas williams (contractor)" wrote: > the nicstar driver has typically used alloc_skb() to get its i/o buffers. > since these buffers are likely to be passed to the network stack at some > point it should probably be using dev_alloc_skb(). this patches fixes > a crash during pppoatm operation when an unchecked skb_push() operates on > a buffer returned by the nicstar. > > please apply to 2.6 and 2.4 kernels (and if at all possible could > i get this in the soon to be released 2.4.26 kernel?) Good catch, applied. I'll do my best to get Marcelo to eats this soon, but no promises. :-) From jgarzik@pobox.com Fri Apr 9 21:11:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 21:11:25 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3A4BCKO001143 for ; Fri, 9 Apr 2004 21:11:13 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BC1ko-0001Ax-S9; Fri, 09 Apr 2004 20:33:30 +0100 Message-ID: <4076FA7F.7020801@pobox.com> Date: Fri, 09 Apr 2004 15:33:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy I Mattox CC: tulip-devel@lists.sourceforge.net, netdev@oss.sgi.com Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 2nd try References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4601 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: 944 Lines: 26 Timothy I Mattox wrote: > Resubmitting ADMtek Comet MII support patch... > > Here is a patch for the tulip driver found in kernel 2.4.26-rc2 > This adds MII functionality to the ADMtek Comet flavor of the tulip, > specifically, the ability to detect and report the link status with MII. > This is critical for use with newer channel bonding drivers. > > I've tested on several Linksys LNE100TX v4.1 PCI cards, as well as on > an HP Pavilion N5475 laptop with a built-in NIC that is detected as > this same model of chip. I have over 750 of this model tulip card in > use in various beowulf clusters. > > This patch was modeled after Donald Becker's tulip.c:v0.98 1/8/2004, but > the specific bits from his driver have been there for about two years. > (See: http://sourceforge.net/mailarchive/message.php?msg_id=1841280) Looks OK, but can you test without netif_carrier_xxx commented out? I would prefer to leave those active. Jeff From davem@redhat.com Fri Apr 9 21:15:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 21:15:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3A4FlKO001516 for ; Fri, 9 Apr 2004 21:15:48 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3A4FiMC002229; Sat, 10 Apr 2004 00:15:44 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3A4Fij21285; Sat, 10 Apr 2004 00:15:44 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3A4FH1n005972; Sat, 10 Apr 2004 00:15:18 -0400 Date: Fri, 9 Apr 2004 21:13:53 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] IPV6: Mark MLDv2 Report as known Message-Id: <20040409211353.0f76e33c.davem@redhat.com> In-Reply-To: <20040409.210510.64268862.yoshfuji@linux-ipv6.org> References: <20040409.210510.64268862.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3A4FlKO001516 X-archive-position: 4602 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 295 Lines: 12 On Fri, 09 Apr 2004 21:05:10 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > Mark MLDv2 Report as known ICMPv6 type. > (We just ignore MLDv2 Reports on hosts as the spec says.) > > Same patch applies linux-2.4.x. Applied to both 2.4.x and 2.6.x Thank you. From davem@redhat.com Fri Apr 9 21:18:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 21:18:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3A4IBKO001848 for ; Fri, 9 Apr 2004 21:18:11 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3A4I6MC002755; Sat, 10 Apr 2004 00:18:06 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3A4I6j21754; Sat, 10 Apr 2004 00:18:06 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3A4He1n006645; Sat, 10 Apr 2004 00:17:40 -0400 Date: Fri, 9 Apr 2004 21:16:16 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com, linux-usb-devel@lists.sourceforge.net Subject: Re: [PATCH] (4/4) usbnet -- use random_ether_addr Message-Id: <20040409211616.7b8f1aea.davem@redhat.com> In-Reply-To: <20040409114727.0619405d@dell_ss3.pdx.osdl.net> References: <20040408110834.2fd1bd25@dell_ss3.pdx.osdl.net> <20040408145403.34382c96.davem@redhat.com> <20040409114727.0619405d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4603 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 40 Lines: 2 All 4 patches applied, thanks Stephen. From shawn.starr@rogers.com Fri Apr 9 23:23:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 09 Apr 2004 23:23:18 -0700 (PDT) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3A6N6KO004298 for ; Fri, 9 Apr 2004 23:23:07 -0700 Received: from panic ([69.196.108.95]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20040410062140.WCSW39251.fep02-mail.bloor.is.net.cable.rogers.com@panic>; Sat, 10 Apr 2004 02:21:40 -0400 From: "Shawn Starr" To: "'Feldman, Scott'" , "'Brown, Len'" Cc: , Subject: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout - Related to i2c interface? Date: Sat, 10 Apr 2004 02:23:06 -0400 Message-ID: <000001c41ec4$5b937430$0200080a@panic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [69.196.108.95] using ID at Sat, 10 Apr 2004 02:21:39 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3A6N6KO004298 X-archive-position: 4604 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 2411 Lines: 53 Ok, did disable ACPI but still get these errors. I have noticed that if I start loading/unloading any i2c drivers I start getting eth0 timeouts....the question is why? coredump kernel: i2c_adapter i2c-2: Transaction (post): CNT=08, CMD=3a, ADD=50, DAT0=3e, DAT1=00 Apr 10 01:56:44 coredump kernel: i2c-core: unregister_driver - looking for clients. Apr 10 01:56:44 coredump kernel: i2c_adapter i2c-2: examining adapter Apr 10 01:56:44 coredump kernel: i2c-core.o: detaching client lm80: Apr 10 01:56:44 coredump kernel: i2c-core.o: detaching client lm80: Apr 10 01:56:44 coredump kernel: i2c-core: driver unregistered: lm80 Apr 10 01:56:48 coredump kernel: i2c_adapter i2c-2: Adapter unregistered Apr 10 01:56:48 coredump kernel: i2c_adapter i2c-2: adapter unregistered Apr 10 01:56:55 coredump kernel: eth0: wait_for_cmd_done timeout! Apr 10 01:56:55 coredump kernel: Command 00ff never accepted (201 polls)! Apr 10 01:56:55 coredump kernel: Command 0006 was not accepted after 20001 polls! Current status ffffffff. Apr 10 01:56:55 coredump kernel: Command 00ff never accepted (201 polls)! Apr 10 01:56:55 coredump kernel: Command 0060 was not accepted after 20001 polls! Current status ffffffff. Apr 10 01:56:55 coredump kernel: eth0: wait_for_cmd_done timeout! Apr 10 01:56:55 coredump kernel: Command 00ff never accepted (201 polls)! Apr 10 01:56:55 coredump kernel: Command 0001 was not accepted after 20001 polls! Current status ffffffff. Apr 10 01:56:55 coredump kernel: Command 00ff never accepted (201 polls)! Apr 10 01:56:56 coredump kernel: Command 0070 was not accepted after 20001 polls! Current status ffffffff. Apr 10 01:56:56 coredump kernel: eth0: wait_for_cmd_done timeout! Apr 10 01:57:27 coredump last message repeated 26 times Apr 10 01:57:29 coredump last message repeated 3 times -----Original Message----- From: Feldman, Scott [mailto:scott.feldman@intel.com] Sent: Wednesday, April 07, 2004 02:31 PM To: Brown, Len; Shawn Starr Subject: RE: [BUG][2.6.5 final][e100] NETDEV_WATCHDOG Timeout - Was not a problem with 2.6.5-rc3 > >Shawn, try turning off ACPI for interrupt routing. Load the kernel > >with the kernel parameter "noapci" set. > > You mean "acpi=off", or "pci=noacpi". If either of these fix > the problem, please let me know. (and send me the dmesg and > /proc/interrupts for both cases) Yes, sorry. Can't believe I posted that to lkml. Oh well. -scott From hugo@innerghost.net Sun Apr 11 05:44:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 05:44:04 -0700 (PDT) Received: from haven.innerghost.net (a213-22-117-228.netcabo.pt [213.22.117.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BCi1KO004710 for ; Sun, 11 Apr 2004 05:44:02 -0700 Received: from innerghost.net (adslsapo-b4-56-46.telepac.pt [81.193.56.46]) by haven.innerghost.net (Postfix) with ESMTP id 56160BC6BE; Sun, 11 Apr 2004 13:43:55 +0100 (WEST) Message-ID: <40793D5A.9060706@innerghost.net> Date: Sun, 11 Apr 2004 13:43:06 +0100 From: Hugo Santos User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040401 Debian/1.6-4 X-Accept-Language: en MIME-Version: 1.0 To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: sch_dsmark bug Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4605 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hugo@innerghost.net Precedence: bulk X-list: netdev Content-Length: 767 Lines: 23 Hi there, I tried to contact the person whose name is in the source file but with no success. While developing some code that handles with kernel's TC objects direcly (by netlink) i found a small problem with dsmark (maybe other scheds have it too, but i haven't checked). This is in linux 2.6.4 (there is no change in this context in 2.6.5); in dsmark_init, if opt is NULL, the module will crash and TC will get stuck. the module will have a ref count of 1 so i can't unload it, and i can't change any other TC stuff since the netlink socket gets stuck when dsmark crashes. So, a simple if (!opt) return -EINVAL; would prevent such problems. If you prefer i may send a patch, but since it's only a one line patch i didn't send one. Best regards, Hugo Santos From hadi@cyberus.ca Sun Apr 11 12:38:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 12:38:07 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BJc3KO019273 for ; Sun, 11 Apr 2004 12:38:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BCkmZ-0006jS-Nc for netdev@oss.sgi.com; Sun, 11 Apr 2004 15:38:19 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BCkm9-0000AL-5J; Sun, 11 Apr 2004 15:37:53 -0400 Subject: Re: [PATCH] tulip, kernel 2.4.26-rc2, 3rd try From: jamal Reply-To: hadi@cyberus.ca To: Jeff Garzik Cc: Timothy I Mattox , tulip-devel@lists.sourceforge.net, netdev@oss.sgi.com, Jay Estabrook In-Reply-To: <40770EA3.6040102@pobox.com> References: <40770EA3.6040102@pobox.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081712235.1040.371.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2004 15:37:15 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4606 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 835 Lines: 21 On Fri, 2004-04-09 at 16:59, Jeff Garzik wrote: > It's not ready to turn them all on yet, unfortunately. Tulip driver > desperately wants ethtool support, too. > > Dr. Jamal Salim ported the phy code from a recent version of Donald > Becker's tulip.c to upstream... that's what we really want to merge. > Jay Estabrook updated this while pursuing tulip problems on alpha. This > patch needs testing and merging... > The code Jeff mentions is about a year old - so needs updates. I will send anyone who will ensure that this goes in cleanly one or two of my NICs + the code since i dont have much time to allocate to this lately. There were bits in there as well to fix SYM phys in addition to the netif_carrier_xxxx stuff. You want the NICs you have to promise to make sure both work. Send me private email. cheers, jamal From hadi@cyberus.ca Sun Apr 11 12:43:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 12:43:53 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BJhpKO019722 for ; Sun, 11 Apr 2004 12:43:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BCksE-0001XA-62 for netdev@oss.sgi.com; Sun, 11 Apr 2004 15:44:10 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BCkro-0000s1-4P; Sun, 11 Apr 2004 15:43:44 -0400 Subject: Re: sch_dsmark bug From: jamal Reply-To: hadi@cyberus.ca To: Hugo Santos Cc: netdev@oss.sgi.com, "David S. Miller" , Werner Almesberger In-Reply-To: <40793D5A.9060706@innerghost.net> References: <40793D5A.9060706@innerghost.net> Content-Type: multipart/mixed; boundary="=-W0I2djxKtMlUoVZlYoDp" Organization: jamalopolis Message-Id: <1081712583.1044.375.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2004 15:43:03 -0400 X-archive-position: 4607 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1654 Lines: 58 --=-W0I2djxKtMlUoVZlYoDp Content-Type: text/plain Content-Transfer-Encoding: 7bit Looks legit nit. Why are you sending empty opts anyways? ;-> patchlet attached - you should have sent one ;-> Maybe you can inspect other qdiscs. cheers, jamal On Sun, 2004-04-11 at 08:43, Hugo Santos wrote: > Hi there, > > I tried to contact the person whose name is in the source file but with > no success. While developing some code that handles with kernel's TC > objects direcly (by netlink) i found a small problem with dsmark (maybe > other scheds have it too, but i haven't checked). This is in linux 2.6.4 > (there is no change in this context in 2.6.5); in dsmark_init, if opt is > NULL, the module will crash and TC will get stuck. the module will have a > ref count of 1 so i can't unload it, and i can't change any other TC > stuff since the netlink socket gets stuck when dsmark crashes. So, a simple > > if (!opt) return -EINVAL; > > would prevent such problems. > > If you prefer i may send a patch, but since it's only a one line patch i didn't > send one. > > Best regards, > Hugo Santos > > > > > --=-W0I2djxKtMlUoVZlYoDp Content-Disposition: attachment; filename=p1 Content-Type: text/plain; name=p1; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- sch_dsmark.c 2004/04/11 19:39:16 1.1 +++ sch_dsmark.c 2004/04/11 19:39:41 @@ -321,6 +321,7 @@ struct rtattr *tb[TCA_DSMARK_MAX]; __u16 tmp; + if (!opt) return -EINVAL; DPRINTK("dsmark_init(sch %p,[qdisc %p],opt %p)\n",sch,p,opt); if (rtattr_parse(tb,TCA_DSMARK_MAX,RTA_DATA(opt),RTA_PAYLOAD(opt)) < 0 || !tb[TCA_DSMARK_INDICES-1] || --=-W0I2djxKtMlUoVZlYoDp-- From hadi@znyx.com Sun Apr 11 12:54:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 12:54:56 -0700 (PDT) Received: from lotus.znyx.com (znx208-2-156-007.znyx.com [208.2.156.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BJsoKO020200 for ; Sun, 11 Apr 2004 12:54:50 -0700 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004041112580414:3209 ; Sun, 11 Apr 2004 12:58:04 -0700 Subject: [Fwd: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to 2.6] From: Jamal Hadi Salim Reply-To: hadi@znyx.com To: netdev@oss.sgi.com Cc: Ralf Baechle Organization: ZNYX Networks Message-Id: <1081713274.1041.385.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2004 15:54:35 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/11/2004 12:58:04 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 04/11/2004 12:58:06 PM, Serialize complete at 04/11/2004 12:58:06 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-archive-position: 4608 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@znyx.com Precedence: bulk X-list: netdev Content-Length: 6053 Lines: 157 netdev swallowed this email? never saw it reflected was Message-Id: <1081711933.1042.365.camel@jzny.localdomain> -----Forwarded Message----- From: jamal To: Vladimir B. Savkin Cc: netdev@oss.sgi.com Subject: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to 2.6 Date: 11 Apr 2004 15:32:13 -0400 Hello, Following up on a 3 month old email ;-> I finally hacked dummy device as a good replacement (IMO) for IMQ. I am only subscribed to netdev so if there are other lists which are of interest to this subject please forward on, but make sure responses make it to netdev. Well, why dummy you ask? Because it is such dumb a device ;-> Ok, that may not be funny enough, how about: because nobody has touched the dummy device in 10 years - that cant be right in Linux. On a serious note though, because i didnt think it was worth writting another device for this. Dummy continues to work the same way when not used with tc extensions. Like i said in my email at the bottom that IMQ was just at the wrong abstraction layer. The dummy extension can now pick ANY packets (not just IP and requiring to attach to a few hooks to get IPV6, arp etc) Of course all this needs the tc extensions (which has a lot of other features that i wont discuss here). Why dont i show an example: ---- export TC="/sbin/tc" # #attach prio qdisc to the dummy0 device # $TC qdisc add dev dummy0 root handle 1: prio $TC qdisc add dev dummy0 parent 1:1 handle 10: sfq $TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 $TC qdisc add dev dummy0 parent 1:3 handle 30: sfq # redirect packets coming in with fwmark 1 to class 1:1 (sfq) $TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1 #redirect packets tagged with fwmark 2 to 1:2 (tbf) $TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2 #bring up dummy0 ifconfig dummy0 up #watch the ingress of eth0; $TC qdisc add dev eth0 ingress # redirect all IP packets arriving in eth0 to dummy0 # use mark 1 --> puts them onto class 1:1 $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action ipt -j MARK --set-mark 1 \ action mirred egress redirect dev dummy0 # note, the above just shows eth0 and only at ingress; # you could repeat this on egress/ingress of any device # and redirect to dummy0 if you wanted; A Little test: from another machine ping so that you have packets going into the box: ----- [root@jzny action-tests]# ping 10.22 PING 10.22 (10.0.0.22): 56 data bytes 64 bytes from 10.0.0.22: icmp_seq=0 ttl=64 time=2.8 ms 64 bytes from 10.0.0.22: icmp_seq=1 ttl=64 time=0.6 ms 64 bytes from 10.0.0.22: icmp_seq=2 ttl=64 time=0.6 ms --- 10.22 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.6/1.3/2.8 ms [root@jzny action-tests]# Now look at some stats: ----- [root@jmandrake]:~# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 match 00000000/00000000 at 0 action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target MARK set 0x1 index 1 ref 1 bind 1 installed 4195sec used 27sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) action order 2: mirred (Egress Redirect to device dummy0) stolen index 1 ref 1 bind 1 installed 165 sec used 27 sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) [root@jmandrake]:~# ifconfig dummy0 dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:6 errors:0 dropped:3 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:504 (504.0 b) TX bytes:252 (252.0 b) ----- Note the three extra received packets on dummy0 were ndisc packets sent by the stack when it booted up (which would normally be dropped - they were). Also, the mirred action can do a _lot_ more, but thats not the point of this email. Send me private email if you want to know more. Additionaly note: the ipt report of NF_IP_PRE_ROUTING is a lie since this happens waaay before IP. This has been tested on both uni and smp machines. Unfortunately, the code is only available for 2.4.x (2.4.25 patches available - more vigorous testing happened on 2.4.21 - my two machines above) What am i looking for? 1) users and authors of IMQ to tell me if this achieves what IMQ started as. I have to say I DONT like the level of obstrutiveness from IMQ as is today. The code added by this is small (100 or less lines on top of dummy) and doesnt touch any of the main core bits. 2) testing of the above by people who use IMQ 3) If someone has better ideas - i am not religious about keeping this; but it certainly cant be the blasphemy that IMQ introduces. I have also introduced hooks to easily add a -i to tc classifiers - still on the TODO list. So on the egress you could now classify based on which incoming device the packet arrived on. cheers, jamal On Sat, 2004-01-31 at 17:26, jamal wrote: > On Sat, 2004-01-31 at 16:58, Vladimir B. Savkin wrote: > > > Well, not, the primary reason being that there would be no single class > > with appropriate bandwith limit (ceil). There would be multiple classes, > > Ok - i think you made your point. > So i should add that a third condition is there are multiple devices > towards the clients. > You have convinced me there is value in such a scheme as IMQ provides > for such conditions. As it is right now though IMQ needs to have the > right abstraction (and not be dependent on netfilter).And may be we > could abuse it to do other things. > Let me hear from Tomas and then we should take it from there. > > cheers, > jamal > > From shawn.starr@rogers.com Sun Apr 11 13:08:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 13:08:45 -0700 (PDT) Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BK8eKO020787 for ; Sun, 11 Apr 2004 13:08:40 -0700 Received: from panic ([69.196.108.95]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20040411200706.FJWP39251.fep02-mail.bloor.is.net.cable.rogers.com@panic>; Sun, 11 Apr 2004 16:07:06 -0400 From: "Shawn Starr" To: "'Len Brown'" Cc: , Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? Date: Sun, 11 Apr 2004 16:09:14 -0400 Message-ID: <000001c42000$dd6e78f0$0200080a@panic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1081671742.2844.0.camel@dhcppc4> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [69.196.108.95] using ID at Sun, 11 Apr 2004 16:07:06 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3BK8eKO020787 X-archive-position: 4609 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 4065 Lines: 111 Ok, this is strange, I put in an external 10/100 PRO S Adaptor, and im not getting anymore eth0 timeouts, I would only get eth0 timeouts on the ONBOARD nic if I enabled the lm80 sensor driver.. I don't know what to say, the onboard nic would work fine without lm80 being loaded? Is there some sort of race condition that the onboard 10/100 PRO is doing ? I'm confused -----Original Message----- From: Len Brown [mailto:len.brown@intel.com] Sent: Sunday, April 11, 2004 04:22 AM To: Shawn Starr Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? it could be that i2c is hooked up to the NIC for some management purpose -- maybe Scott knows. On Sun, 2004-04-11 at 03:32, Shawn Starr wrote: > No, something else is causing problem, don't know why i2c is? > > -----Original Message----- > From: Brown, Len [mailto:len.brown@intel.com] > Sent: Sunday, April 11, 2004 01:22 AM > To: Shawn Starr > Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout - > Related to i2c interface? > > > So ACPI enabled/disabled doesn't make any difference? > > >-----Original Message----- > >From: Shawn Starr [mailto:shawn.starr@rogers.com] > >Sent: Saturday, April 10, 2004 2:23 AM > >To: Feldman, Scott; Brown, Len > >Cc: linux-kernel@vger.kernel.org; netdev@oss.sgi.com > >Subject: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG > >Timeout - Related to i2c interface? > > > > > >Ok, did disable ACPI but still get these errors. I have noticed that > >if I start loading/unloading any i2c drivers I start getting eth0 > >timeouts....the > >question is why? > > > >coredump kernel: i2c_adapter i2c-2: Transaction (post): CNT=08, > >CMD=3a, > >ADD=50, DAT0=3e, DAT1=00 Apr 10 01:56:44 coredump kernel: i2c-core: > >unregister_driver - looking for > >clients. > >Apr 10 01:56:44 coredump kernel: i2c_adapter i2c-2: examining adapter > >Apr 10 01:56:44 coredump kernel: i2c-core.o: detaching client lm80: > >Apr 10 01:56:44 coredump kernel: i2c-core.o: detaching client lm80: > >Apr 10 01:56:44 coredump kernel: i2c-core: driver unregistered: lm80 > >Apr 10 01:56:48 coredump kernel: i2c_adapter i2c-2: Adapter > >unregistered > >Apr 10 01:56:48 coredump kernel: i2c_adapter i2c-2: adapter > >unregistered > >Apr 10 01:56:55 coredump kernel: eth0: wait_for_cmd_done timeout! > >Apr 10 01:56:55 coredump kernel: Command 00ff never accepted > >(201 polls)! > >Apr 10 01:56:55 coredump kernel: Command 0006 was not accepted > >after 20001 > >polls! Current status ffffffff. > >Apr 10 01:56:55 coredump kernel: Command 00ff never accepted > >(201 polls)! > >Apr 10 01:56:55 coredump kernel: Command 0060 was not accepted > >after 20001 > >polls! Current status ffffffff. > >Apr 10 01:56:55 coredump kernel: eth0: wait_for_cmd_done timeout! > >Apr 10 01:56:55 coredump kernel: Command 00ff never accepted > >(201 polls)! > >Apr 10 01:56:55 coredump kernel: Command 0001 was not accepted > >after 20001 > >polls! Current status ffffffff. > >Apr 10 01:56:55 coredump kernel: Command 00ff never accepted > >(201 polls)! > >Apr 10 01:56:56 coredump kernel: Command 0070 was not accepted > >after 20001 > >polls! Current status ffffffff. > >Apr 10 01:56:56 coredump kernel: eth0: wait_for_cmd_done timeout! > >Apr 10 01:57:27 coredump last message repeated 26 times > >Apr 10 01:57:29 coredump last message repeated 3 times > > > >-----Original Message----- > >From: Feldman, Scott [mailto:scott.feldman@intel.com] > >Sent: Wednesday, April 07, 2004 02:31 PM > >To: Brown, Len; Shawn Starr > >Subject: RE: [BUG][2.6.5 final][e100] NETDEV_WATCHDOG Timeout > >- Was not a > >problem with 2.6.5-rc3 > > > > > >> >Shawn, try turning off ACPI for interrupt routing. Load the > >> >kernel > >> >with the kernel parameter "noapci" set. > >> > >> You mean "acpi=off", or "pci=noacpi". If either of these fix the > >> problem, please let me know. (and send me the dmesg and > >> /proc/interrupts for both cases) > > > >Yes, sorry. Can't believe I posted that to lkml. Oh well. > > > >-scott > > > > > From sven@zion.homelinux.com Sun Apr 11 15:52:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 15:52:55 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BMqqKO024550 for ; Sun, 11 Apr 2004 15:52:53 -0700 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BCnop-0003pQ-00 for netdev@oss.sgi.com; Mon, 12 Apr 2004 00:52:51 +0200 Received: from [80.136.65.119] (helo=zion.homelinux.com) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BCnop-00033p-00 for netdev@oss.sgi.com; Mon, 12 Apr 2004 00:52:51 +0200 Received: from localhost (zion.homelinux.com [127.0.0.1]) by stage2.zion.homelinux.com (Postfix) with ESMTP id 6737E2C6FD for ; Mon, 12 Apr 2004 00:52:49 +0200 (CEST) Received: from zion.homelinux.com ([127.0.0.1]) by localhost (zion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07443-05 for ; Mon, 12 Apr 2004 00:52:46 +0200 (CEST) Received: by zion.homelinux.com (Postfix, from userid 1022) id 79D492C6FE; Mon, 12 Apr 2004 00:52:46 +0200 (CEST) Date: Mon, 12 Apr 2004 00:52:46 +0200 From: Sven Schuster To: netdev@oss.sgi.com Subject: Re: sch_dsmark bug Message-ID: <20040411225246.GA8644@zion.homelinux.com> References: <40793D5A.9060706@innerghost.net> <1081712583.1044.375.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ADZbWkCsHQ7r3kzd" Content-Disposition: inline In-Reply-To: <1081712583.1044.375.camel@jzny.localdomain> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new-20030616-p7 at zion.homelinux.com X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:38b5f051b8cd178556c5593940405c4a X-archive-position: 4610 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schuster.sven@gmx.de Precedence: bulk X-list: netdev Content-Length: 2195 Lines: 74 --ADZbWkCsHQ7r3kzd Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 11, 2004 at 03:43:03PM -0400, jamal told us: >=20 > Looks legit nit. Why are you sending empty opts anyways? ;-> > patchlet attached - you should have sent one ;-> > Maybe you can inspect other qdiscs. >=20 > cheers, > jamal >=20 I took a look at the others and found this ones... Sven --=20 Linux zion 2.6.5 #1 Sun Apr 4 19:56:55 CEST 2004 i686 athlon i386 GNU/Linux 00:43:25 up 7 days, 1:27, 2 users, load average: 0.02, 0.05, 0.01 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="sched.patch" Content-Transfer-Encoding: quoted-printable --- net/sched/sch_cbq.c.orig 2004-04-12 00:24:08.123743284 +0200 +++ net/sched/sch_cbq.c 2004-04-12 00:40:30.186534165 +0200 @@ -1399,7 +1399,8 @@ static int cbq_init(struct Qdisc *sch, s struct rtattr *tb[TCA_CBQ_MAX]; struct tc_ratespec *r; =20 - if (rtattr_parse(tb, TCA_CBQ_MAX, RTA_DATA(opt), RTA_PAYLOAD(opt)) < 0 || + if (!opt ||=20 + rtattr_parse(tb, TCA_CBQ_MAX, RTA_DATA(opt), RTA_PAYLOAD(opt)) < 0 || tb[TCA_CBQ_RTAB-1] =3D=3D NULL || tb[TCA_CBQ_RATE-1] =3D=3D NULL || RTA_PAYLOAD(tb[TCA_CBQ_RATE-1]) < sizeof(struct tc_ratespec)) return -EINVAL; --- net/sched/sch_csz.c.orig 2004-04-12 00:24:08.126743018 +0200 +++ net/sched/sch_csz.c 2004-04-12 00:36:16.195184499 +0200 @@ -763,6 +763,8 @@ static int csz_init(struct Qdisc *sch, s struct tc_csz_qopt *qopt; int i; =20 + if (!opt) + return -EINVAL; rtattr_parse(tb, TCA_CSZ_PTAB, RTA_DATA(opt), RTA_PAYLOAD(opt)); if (tb[TCA_CSZ_PARMS-1] =3D=3D NULL || RTA_PAYLOAD(tb[TCA_CSZ_PARMS-1]) < sizeof(*qopt)) --Kj7319i9nmIyA2yE-- --ADZbWkCsHQ7r3kzd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAecw+o4FAdB2PneQRAmHIAJ9YyIEveq5zX/P+R4dcbYowsxhOvgCfVBLY fpVeWUPpePlbroynOrZvxA0= =dZoe -----END PGP SIGNATURE----- --ADZbWkCsHQ7r3kzd-- From hadi@cyberus.ca Sun Apr 11 18:25:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 11 Apr 2004 18:25:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C1P1KO031602 for ; Sun, 11 Apr 2004 18:25:02 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BCkhi-0006OM-5W for netdev@oss.sgi.com; Sun, 11 Apr 2004 15:33:18 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BCkhH-0007sb-JV; Sun, 11 Apr 2004 15:32:51 -0400 Subject: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to 2.6 From: jamal Reply-To: hadi@cyberus.ca To: "Vladimir B. Savkin" Cc: netdev@oss.sgi.com In-Reply-To: <1075587994.1036.231.camel@jzny.localdomain> References: <20040126093230.GA17811@usr.lcm.msu.ru> <1075124312.1732.292.camel@jzny.localdomain> <20040126135545.GA19497@usr.lcm.msu.ru> <1075127396.1746.370.camel@jzny.localdomain> <20040131185231.GA2608@usr.lcm.msu.ru> <1075580812.1035.83.camel@jzny.localdomain> <20040131205326.GA3089@usr.lcm.msu.ru> <1075584318.1033.159.camel@jzny.localdomain> <20040131213236.GA3451@usr.lcm.msu.ru> <1075585764.1035.192.camel@jzny.localdomain> <20040131215821.GA3615@usr.lcm.msu.ru> <1075587994.1036.231.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1081711933.1042.365.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Apr 2004 15:32:13 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4611 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 5698 Lines: 146 Hello, Following up on a 3 month old email ;-> I finally hacked dummy device as a good replacement (IMO) for IMQ. I am only subscribed to netdev so if there are other lists which are of interest to this subject please forward on, but make sure responses make it to netdev. Well, why dummy you ask? Because it is such dumb a device ;-> Ok, that may not be funny enough, how about: because nobody has touched the dummy device in 10 years - that cant be right in Linux. On a serious note though, because i didnt think it was worth writting another device for this. Dummy continues to work the same way when not used with tc extensions. Like i said in my email at the bottom that IMQ was just at the wrong abstraction layer. The dummy extension can now pick ANY packets (not just IP and requiring to attach to a few hooks to get IPV6, arp etc) Of course all this needs the tc extensions (which has a lot of other features that i wont discuss here). Why dont i show an example: ---- export TC="/sbin/tc" # #attach prio qdisc to the dummy0 device # $TC qdisc add dev dummy0 root handle 1: prio $TC qdisc add dev dummy0 parent 1:1 handle 10: sfq $TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 $TC qdisc add dev dummy0 parent 1:3 handle 30: sfq # redirect packets coming in with fwmark 1 to class 1:1 (sfq) $TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1 #redirect packets tagged with fwmark 2 to 1:2 (tbf) $TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2 #bring up dummy0 ifconfig dummy0 up #watch the ingress of eth0; $TC qdisc add dev eth0 ingress # redirect all IP packets arriving in eth0 to dummy0 # use mark 1 --> puts them onto class 1:1 $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action ipt -j MARK --set-mark 1 \ action mirred egress redirect dev dummy0 # note, the above just shows eth0 and only at ingress; # you could repeat this on egress/ingress of any device # and redirect to dummy0 if you wanted; A Little test: from another machine ping so that you have packets going into the box: ----- [root@jzny action-tests]# ping 10.22 PING 10.22 (10.0.0.22): 56 data bytes 64 bytes from 10.0.0.22: icmp_seq=0 ttl=64 time=2.8 ms 64 bytes from 10.0.0.22: icmp_seq=1 ttl=64 time=0.6 ms 64 bytes from 10.0.0.22: icmp_seq=2 ttl=64 time=0.6 ms --- 10.22 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.6/1.3/2.8 ms [root@jzny action-tests]# Now look at some stats: ----- [root@jmandrake]:~# tc -s filter show parent ffff: dev eth0 filter protocol ip pref 10 u32 filter protocol ip pref 10 u32 fh 800: ht divisor 1 filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 match 00000000/00000000 at 0 action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING target MARK set 0x1 index 1 ref 1 bind 1 installed 4195sec used 27sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) action order 2: mirred (Egress Redirect to device dummy0) stolen index 1 ref 1 bind 1 installed 165 sec used 27 sec Sent 252 bytes 3 pkts (dropped 0, overlimits 0) [root@jmandrake]:~# ifconfig dummy0 dummy0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link UP BROADCAST RUNNING NOARP MTU:1500 Metric:1 RX packets:6 errors:0 dropped:3 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:504 (504.0 b) TX bytes:252 (252.0 b) ----- Note the three extra received packets on dummy0 were ndisc packets sent by the stack when it booted up (which would normally be dropped - they were). Also, the mirred action can do a _lot_ more, but thats not the point of this email. Send me private email if you want to know more. Additionaly note: the ipt report of NF_IP_PRE_ROUTING is a lie since this happens waaay before IP. This has been tested on both uni and smp machines. Unfortunately, the code is only available for 2.4.x (2.4.25 patches available - more vigorous testing happened on 2.4.21 - my two machines above) What am i looking for? 1) users and authors of IMQ to tell me if this achieves what IMQ started as. I have to say I DONT like the level of obstrutiveness from IMQ as is today. The code added by this is small (100 or less lines on top of dummy) and doesnt touch any of the main core bits. 2) testing of the above by people who use IMQ 3) If someone has better ideas - i am not religious about keeping this; but it certainly cant be the blasphemy that IMQ introduces. I have also introduced hooks to easily add a -i to tc classifiers - still on the TODO list. So on the egress you could now classify based on which incoming device the packet arrived on. cheers, jamal On Sat, 2004-01-31 at 17:26, jamal wrote: > On Sat, 2004-01-31 at 16:58, Vladimir B. Savkin wrote: > > > Well, not, the primary reason being that there would be no single class > > with appropriate bandwith limit (ceil). There would be multiple classes, > > Ok - i think you made your point. > So i should add that a third condition is there are multiple devices > towards the clients. > You have convinced me there is value in such a scheme as IMQ provides > for such conditions. As it is right now though IMQ needs to have the > right abstraction (and not be dependent on netfilter).And may be we > could abuse it to do other things. > Let me hear from Tomas and then we should take it from there. > > cheers, > jamal > > From martinjd@net-ronin.org Mon Apr 12 00:01:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 00:01:31 -0700 (PDT) Received: from antichrist (postfix@d64-180-152-77.bchsia.telus.net [64.180.152.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C71SKO009803 for ; Mon, 12 Apr 2004 00:01:29 -0700 Received: by antichrist (Postfix, from userid 1000) id 69E374036; Sun, 11 Apr 2004 23:59:47 -0700 (PDT) Date: Sun, 11 Apr 2004 23:59:47 -0700 From: Jeremy Martin To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] fix tuntap oversight Message-ID: <20040412065947.GC18810@net-ronin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 4612 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: martinjd@csc.uvic.ca Precedence: bulk X-list: netdev Content-Length: 955 Lines: 41 Hi everyone, This 2.6.5 patch for the universal tuntap driver allows setting the MAC address via ifconfig(8). I'm not subscribed to netdev so if you could CC me that'd be awesome. -Jeremy Patch contents: -- CUT HERE -- ===== drivers/net/tun.c 1.33 vs edited ===== --- 1.33/drivers/net/tun.c Mon Mar 15 12:45:05 2004 +++ edited/drivers/net/tun.c Sun Apr 11 22:39:06 2004 @@ -117,6 +117,15 @@ return &tun->stats; } +static int tun_mac_addr(struct net_device *dev, void *p) +{ + struct sockaddr *addr=p; + if (netif_running(dev)) + return -EBUSY; + memcpy(dev->dev_addr, addr->sa_data,dev->addr_len); + return 0; +} + /* Initialize net device. */ static void tun_net_init(struct net_device *dev) { @@ -138,6 +147,7 @@ case TUN_TAP_DEV: /* Ethernet TAP Device */ dev->set_multicast_list = tun_net_mclist; + dev->set_mac_address = tun_mac_addr; /* Generate random Ethernet address. */ *(u16 *)dev->dev_addr = htons(0x00FF); From davem@redhat.com Mon Apr 12 00:18:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 00:18:12 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C7I9KO010481 for ; Mon, 12 Apr 2004 00:18:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3C7HxMC030903; Mon, 12 Apr 2004 03:17:59 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3C7Hxj26297; Mon, 12 Apr 2004 03:17:59 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3C7HV1n002462; Mon, 12 Apr 2004 03:17:31 -0400 Date: Mon, 12 Apr 2004 00:15:51 -0700 From: "David S. Miller" To: Jeremy Martin Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tuntap oversight Message-Id: <20040412001551.05476658.davem@redhat.com> In-Reply-To: <20040412065947.GC18810@net-ronin.org> References: <20040412065947.GC18810@net-ronin.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4613 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 551 Lines: 20 On Sun, 11 Apr 2004 23:59:47 -0700 Jeremy Martin wrote: > +static int tun_mac_addr(struct net_device *dev, void *p) > +{ > + struct sockaddr *addr=p; > + if (netif_running(dev)) > + return -EBUSY; > + memcpy(dev->dev_addr, addr->sa_data,dev->addr_len); > + return 0; > +} This netif_running() check is not necessary, and in fact wrong. In fact, if ethernet drivers erroneously do this, this causes them to fail to support the ALB bonding driver modes which require on-the-fly MAC address changes while the interface is up. From vda@port.imtp.ilyichevsk.odessa.ua Mon Apr 12 06:24:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 06:24:14 -0700 (PDT) Received: from port.imtp.ilyichevsk.odessa.ua (168.imtp.Ilyichevsk.Odessa.UA [195.66.192.168] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CDNwKO026978 for ; Mon, 12 Apr 2004 06:24:01 -0700 Received: (qmail 28291 invoked by alias); 12 Apr 2004 13:23:49 -0000 Received: from unknown (1.0.3.9) by 0 (195.66.192.168) with ESMTP; 12 Apr 2004 13:23:49 -0000 From: Denis Vlasenko To: "David S. Miller" , netdev@oss.sgi.com, jmorris@redhat.com, yoshfuji@linux-ipv6.org Date: Mon, 12 Apr 2004 16:23:42 +0300 User-Agent: KMail/1.5.4 Cc: linux-kernel@vger.kernel.org MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ehpeAQktxORaQ/f" Message-Id: <200404121623.42558.vda@port.imtp.ilyichevsk.odessa.ua> X-archive-position: 4615 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vda@port.imtp.ilyichevsk.odessa.ua Precedence: bulk X-list: netdev Content-Length: 7354 Lines: 260 --Boundary-00=_ehpeAQktxORaQ/f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline According to my measurements, ip_vs_control_add() (from include/net/ip_vs.h) is called twice and sock_queue_rcv_skb() (from=A0include/net/sock.h) is called 19 times from various kernel .c files. Both these includes generate more than 500 bytes of code on x86. These patches uninline them. Please apply. =2D- vda --Boundary-00=_ehpeAQktxORaQ/f Content-Type: text/x-diff; charset="us-ascii"; name="net_inline1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="net_inline1.patch" diff -urN linux-2.6.5.orig/include/net/ip_vs.h linux-2.6.5.net_inline/include/net/ip_vs.h --- linux-2.6.5.orig/include/net/ip_vs.h Mon Apr 12 15:42:10 2004 +++ linux-2.6.5.net_inline/include/net/ip_vs.h Mon Apr 12 15:46:43 2004 @@ -766,53 +766,8 @@ extern void ip_vs_random_dropentry(void); extern int ip_vs_conn_init(void); extern void ip_vs_conn_cleanup(void); - -static inline void ip_vs_control_del(struct ip_vs_conn *cp) -{ - struct ip_vs_conn *ctl_cp = cp->control; - if (!ctl_cp) { - IP_VS_ERR("request control DEL for uncontrolled: " - "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", - NIPQUAD(cp->caddr),ntohs(cp->cport), - NIPQUAD(cp->vaddr),ntohs(cp->vport)); - return; - } - - IP_VS_DBG(7, "DELeting control for: " - "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n", - NIPQUAD(cp->caddr),ntohs(cp->cport), - NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport)); - - cp->control = NULL; - if (atomic_read(&ctl_cp->n_control) == 0) { - IP_VS_ERR("BUG control DEL with n=0 : " - "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", - NIPQUAD(cp->caddr),ntohs(cp->cport), - NIPQUAD(cp->vaddr),ntohs(cp->vport)); - return; - } - atomic_dec(&ctl_cp->n_control); -} - -static inline void -ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp) -{ - if (cp->control) { - IP_VS_ERR("request control ADD for already controlled: " - "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", - NIPQUAD(cp->caddr),ntohs(cp->cport), - NIPQUAD(cp->vaddr),ntohs(cp->vport)); - ip_vs_control_del(cp); - } - - IP_VS_DBG(7, "ADDing control for: " - "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n", - NIPQUAD(cp->caddr),ntohs(cp->cport), - NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport)); - - cp->control = ctl_cp; - atomic_inc(&ctl_cp->n_control); -} +extern void ip_vs_control_del(struct ip_vs_conn *cp); +extern void ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp); /* diff -urN linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c --- linux-2.6.5.orig/net/ipv4/ipvs/ip_vs_core.c Sun Apr 4 06:36:13 2004 +++ linux-2.6.5.net_inline/net/ipv4/ipvs/ip_vs_core.c Mon Apr 12 15:59:10 2004 @@ -199,6 +199,57 @@ return 1; } + +void +ip_vs_control_del(struct ip_vs_conn *cp) +{ + struct ip_vs_conn *ctl_cp = cp->control; + if (!ctl_cp) { + IP_VS_ERR("request control DEL for uncontrolled: " + "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", + NIPQUAD(cp->caddr),ntohs(cp->cport), + NIPQUAD(cp->vaddr),ntohs(cp->vport)); + return; + } + + IP_VS_DBG(7, "DELeting control for: " + "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n", + NIPQUAD(cp->caddr),ntohs(cp->cport), + NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport)); + + cp->control = NULL; + if (atomic_read(&ctl_cp->n_control) == 0) { + IP_VS_ERR("BUG control DEL with n=0 : " + "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", + NIPQUAD(cp->caddr),ntohs(cp->cport), + NIPQUAD(cp->vaddr),ntohs(cp->vport)); + return; + } + atomic_dec(&ctl_cp->n_control); +} + + +void +ip_vs_control_add(struct ip_vs_conn *cp, struct ip_vs_conn *ctl_cp) +{ + if (cp->control) { + IP_VS_ERR("request control ADD for already controlled: " + "%d.%d.%d.%d:%d to %d.%d.%d.%d:%d\n", + NIPQUAD(cp->caddr),ntohs(cp->cport), + NIPQUAD(cp->vaddr),ntohs(cp->vport)); + ip_vs_control_del(cp); + } + + IP_VS_DBG(7, "ADDing control for: " + "cp.dst=%d.%d.%d.%d:%d ctl_cp.dst=%d.%d.%d.%d:%d\n", + NIPQUAD(cp->caddr),ntohs(cp->cport), + NIPQUAD(ctl_cp->caddr),ntohs(ctl_cp->cport)); + + cp->control = ctl_cp; + atomic_inc(&ctl_cp->n_control); +} + + /* * IPVS persistent scheduling function * It creates a connection entry according to its template if exists, --Boundary-00=_ehpeAQktxORaQ/f Content-Type: text/x-diff; charset="us-ascii"; name="net_inline2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="net_inline2.patch" diff -urN linux-2.6.5.orig/include/net/sock.h linux-2.6.5.net_inline2/include/net/sock.h --- linux-2.6.5.orig/include/net/sock.h Sun Apr 4 06:37:37 2004 +++ linux-2.6.5.net_inline2/include/net/sock.h Mon Apr 12 16:05:03 2004 @@ -898,45 +898,7 @@ atomic_add(skb->truesize, &sk->sk_rmem_alloc); } -static inline int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) -{ - int err = 0; - int skb_len; - - /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces - number of warnings when compiling with -W --ANK - */ - if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >= - (unsigned)sk->sk_rcvbuf) { - err = -ENOMEM; - goto out; - } - - /* It would be deadlock, if sock_queue_rcv_skb is used - with socket lock! We assume that users of this - function are lock free. - */ - err = sk_filter(sk, skb, 1); - if (err) - goto out; - - skb->dev = NULL; - skb_set_owner_r(skb, sk); - - /* Cache the SKB length before we tack it onto the receive - * queue. Once it is added it no longer belongs to us and - * may be freed by other threads of control pulling packets - * from the queue. - */ - skb_len = skb->len; - - skb_queue_tail(&sk->sk_receive_queue, skb); - - if (!sock_flag(sk, SOCK_DEAD)) - sk->sk_data_ready(sk, skb_len); -out: - return err; -} +int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb); static inline int sock_queue_err_skb(struct sock *sk, struct sk_buff *skb) { diff -urN linux-2.6.5.orig/net/core/sock.c linux-2.6.5.net_inline2/net/core/sock.c --- linux-2.6.5.orig/net/core/sock.c Sun Apr 4 06:37:37 2004 +++ linux-2.6.5.net_inline2/net/core/sock.c Mon Apr 12 16:05:39 2004 @@ -1138,6 +1138,46 @@ atomic_set(&sk->sk_refcnt, 1); } +int sock_queue_rcv_skb(struct sock *sk, struct sk_buff *skb) +{ + int err = 0; + int skb_len; + + /* Cast skb->rcvbuf to unsigned... It's pointless, but reduces + number of warnings when compiling with -W --ANK + */ + if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >= + (unsigned)sk->sk_rcvbuf) { + err = -ENOMEM; + goto out; + } + + /* It would be deadlock, if sock_queue_rcv_skb is used + with socket lock! We assume that users of this + function are lock free. + */ + err = sk_filter(sk, skb, 1); + if (err) + goto out; + + skb->dev = NULL; + skb_set_owner_r(skb, sk); + + /* Cache the SKB length before we tack it onto the receive + * queue. Once it is added it no longer belongs to us and + * may be freed by other threads of control pulling packets + * from the queue. + */ + skb_len = skb->len; + + skb_queue_tail(&sk->sk_receive_queue, skb); + + if (!sock_flag(sk, SOCK_DEAD)) + sk->sk_data_ready(sk, skb_len); +out: + return err; +} + void lock_sock(struct sock *sk) { might_sleep(); --Boundary-00=_ehpeAQktxORaQ/f-- From martinjd@net-ronin.org Mon Apr 12 09:31:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 09:31:03 -0700 (PDT) Received: from antichrist (postfix@d64-180-152-77.bchsia.telus.net [64.180.152.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CGV1KO005723 for ; Mon, 12 Apr 2004 09:31:02 -0700 Received: by antichrist (Postfix, from userid 1000) id 6C1044314; Mon, 12 Apr 2004 09:29:17 -0700 (PDT) Date: Mon, 12 Apr 2004 09:29:16 -0700 From: Jeremy Martin To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tuntap oversight Message-ID: <20040412162916.GA5046@net-ronin.org> References: <20040412065947.GC18810@net-ronin.org> <20040412001551.05476658.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040412001551.05476658.davem@redhat.com> User-Agent: Mutt/1.3.28i X-archive-position: 4616 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: martinjd@csc.uvic.ca Precedence: bulk X-list: netdev Content-Length: 649 Lines: 25 On Mon, Apr 12, 2004 at 12:15:51AM -0700, David S. Miller wrote: > > This netif_running() check is not necessary, and in fact > wrong. > > In fact, if ethernet drivers erroneously do this, this causes > them to fail to support the ALB bonding driver modes which > require on-the-fly MAC address changes while the interface is > up. > I just took a look in drivers/net/ and acenic.c atarilance.c b44.c cs89x0.c net_init.c typhoon.c all use that netif_running() check when setting the MAC. I actually just pulled the function from net_init.c for the tun change. Are these broken? (I'm asking in total ignorance so be gentle :). -Jeremy From davem@redhat.com Mon Apr 12 11:01:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 11:01:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CI1GKO007691 for ; Mon, 12 Apr 2004 11:01:17 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3CI16u6008841; Mon, 12 Apr 2004 14:01:06 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3CI16j06355; Mon, 12 Apr 2004 14:01:06 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3CI0c1n002793; Mon, 12 Apr 2004 14:00:38 -0400 Date: Mon, 12 Apr 2004 10:58:55 -0700 From: "David S. Miller" To: Jeremy Martin Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tuntap oversight Message-Id: <20040412105855.37ec2162.davem@redhat.com> In-Reply-To: <20040412162916.GA5046@net-ronin.org> References: <20040412065947.GC18810@net-ronin.org> <20040412001551.05476658.davem@redhat.com> <20040412162916.GA5046@net-ronin.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4617 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 240 Lines: 8 On Mon, 12 Apr 2004 09:29:16 -0700 Jeremy Martin wrote: > all use that netif_running() check when setting the MAC. I actually just pulled > the function from net_init.c for the tun change. Are these broken? Yes. From jgarzik@pobox.com Mon Apr 12 11:31:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 11:31:33 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CIVTKO008690 for ; Mon, 12 Apr 2004 11:31:30 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BD4X8-0005OA-IV; Mon, 12 Apr 2004 17:43:42 +0100 Message-ID: <407AC732.1090000@pobox.com> Date: Mon, 12 Apr 2004 12:43:30 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeremy Martin CC: "David S. Miller" , netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] fix tuntap oversight References: <20040412065947.GC18810@net-ronin.org> <20040412001551.05476658.davem@redhat.com> <20040412162916.GA5046@net-ronin.org> In-Reply-To: <20040412162916.GA5046@net-ronin.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4618 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: 1263 Lines: 45 Jeremy Martin wrote: > On Mon, Apr 12, 2004 at 12:15:51AM -0700, David S. Miller wrote: > >>This netif_running() check is not necessary, and in fact >>wrong. >> >>In fact, if ethernet drivers erroneously do this, this causes >>them to fail to support the ALB bonding driver modes which >>require on-the-fly MAC address changes while the interface is >>up. >> > > > I just took a look in drivers/net/ > and > acenic.c > atarilance.c > b44.c > cs89x0.c > net_init.c > typhoon.c > > all use that netif_running() check when setting the MAC. I actually just pulled > the function from net_init.c for the tun change. Are these broken? > (I'm asking in total ignorance so be gentle :). It's different for a driver that drives real hardware. struct net_device::set_mac_address() is called inside rtnl_lock(). The safe thing to do is 1) read MAC address from eeprom on probe 2) write MAC address to hardware upon each dev->open() 3) use default eth_mac_addr() from net_init.c And the netif_running() check in eth_mac_addr() is correct, because it does not update the hardware MAC address (which in this API would be impossible). Normally the netif_running() check is for hardware that cannot update its MAC address safely during operation. Jeff From modica@sgi.com Mon Apr 12 15:16:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 15:16:47 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CMGjKO016765 for ; Mon, 12 Apr 2004 15:16:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3CMGdhv017490 for ; Mon, 12 Apr 2004 15:16:40 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3CMGdKe36892067 for ; Mon, 12 Apr 2004 17:16:39 -0500 (CDT) Received: from sgi.com (cf-vpn-sw-corp-64-54.corp.sgi.com [134.15.64.54]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3CMGdXa3871497 for ; Mon, 12 Apr 2004 17:16:39 -0500 (CDT) Message-ID: <407B1547.5020402@sgi.com> Date: Mon, 12 Apr 2004 17:16:39 -0500 From: Steve Modica User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: rudimentary ISR question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4619 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: modica@sgi.com Precedence: bulk X-list: netdev Content-Length: 302 Lines: 10 Hi All, I'm looking at the tg3.c driver in the 2.4.21 kernel and in the _interrupt routing, the driver is calling spin_lock_irqsave. Since it's guaranteed that the tg3 interrupt handler will be disabled for the duration of the interrupt handler, why can't the driver simply call spin_lock? Steve From kumarkr@us.ibm.com Mon Apr 12 16:26:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 16:26:19 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CNQBKO021913 for ; Mon, 12 Apr 2004 16:26:17 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3CNQ50o662588; Mon, 12 Apr 2004 19:26:05 -0400 Received: from d03nm132.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3CNQ4QK112234; Mon, 12 Apr 2004 17:26:04 -0600 Subject: Re: rudimentary ISR question To: Steve Modica Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Mon, 12 Apr 2004 16:23:28 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/12/2004 17:26:04 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22" X-archive-position: 4620 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6805 Lines: 160 --0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: multipart/alternative; Boundary="1__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22" --1__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: text/plain; charset=US-ASCII I think it is because the interrupt routine can be called as dev->poll_controller() and race with real interrupts. - KK |---------+----------------------------> | | Steve Modica | | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 04/12/2004 03:16 | | | PM | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------| | | | To: netdev@oss.sgi.com | | cc: | | Subject: rudimentary ISR question | | | >-------------------------------------------------------------------------------------------------------------------------| Hi All, I'm looking at the tg3.c driver in the 2.4.21 kernel and in the _interrupt routing, the driver is calling spin_lock_irqsave. Since it's guaranteed that the tg3 interrupt handler will be disabled for the duration of the interrupt handler, why can't the driver simply call spin_lock? Steve --1__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I think it is because the interrupt routine can be called as dev->poll_controller()
and race with real interrupts.

- KK

Inactive hide details for Steve Modica <modica@sgi.com>Steve Modica <modica@sgi.com>




          Steve Modica <modica@sgi.com>
          Sent by: netdev-bounce@oss.sgi.com

          04/12/2004 03:16 PM



To: netdev@oss.sgi.com
cc:
Subject: rudimentary ISR question


Hi All,

I'm looking at the tg3.c driver in the 2.4.21 kernel and in the
_interrupt routing, the driver is calling spin_lock_irqsave.

Since it's guaranteed that the tg3 interrupt handler will be disabled
for the duration of the interrupt handler, why can't the driver simply
call spin_lock?

Steve

 --1__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22-- --0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=07BBE4E7DFEC3F228f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=07BBE4E7DFEC3F228f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22 Content-type: image/gif; name="pic29317.gif" Content-Disposition: inline; filename="pic29317.gif" Content-ID: <30__=07BBE4E7DFEC3F228f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4E7DFEC3F228f9e8a93df938690918c07BBE4E7DFEC3F22-- From yoshfuji@linux-ipv6.org Mon Apr 12 20:12:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 20:12:31 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D3CPKO027508 for ; Mon, 12 Apr 2004 20:12:25 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 57C7D33CA5 for ; Tue, 13 Apr 2004 12:12:51 +0900 (JST) Resent-Date: Tue, 13 Apr 2004 12:12:46 +0900 (JST) Resent-Message-Id: <20040413.121246.39559361.yoshfuji@linux-ipv6.org> Resent-To: netdev@oss.sgi.com Resent-From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Date: Tue, 13 Apr 2004 04:45:17 +0200 From: Vincent Lefevre To: linux-kernel@vger.kernel.org Subject: PROBLEM: kernel BUG at tcp_input.c:2927 Message-ID: <20040413024517.GE3858@ay.vinc17.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer-Info: http://www.vinc17.org/mutt/ User-Agent: Mutt/1.5.6i Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-archive-position: 4622 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 14206 Lines: 320 [1.] One line summary of the problem: Crash; "kernel BUG at tcp_input.c:2927" written in the console. [2.] Full description of the problem/report: The machine didn't answer to ping. When I went to see what was wrong, I saw the following in the console: kernel BUG at tcp_input.c:2927! invalid operand: 0000 [...] (I didn't have the time to copy the following data, and unfortunately I couldn't see these data in any log file after rebooting the machine.) This was the first time such a problem occurred. [3.] Keywords (i.e., modules, networking, kernel): networking [4.] Kernel version (from /proc/version): Linux version 2.4.25 (root@greux.loria.fr) (gcc version 3.3.3 (Debian)) #1 SMP Fri Feb 20 14:51:57 CET 2004 [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) [6.] A small shell script or example program which triggers the problem (if possible) [7.] Environment [7.1.] Software (add the output of the ver_linux script here) Linux greux.loria.fr 2.4.25 #1 SMP Fri Feb 20 14:51:57 CET 2004 i686 GNU/Linux Gnu C 3.3.3 Gnu make 3.80 util-linux 2.12 mount 2.12 modutils 2.4.26 e2fsprogs 1.35 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.0 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.0.91 Modules Loaded [7.2.] Processor information (from /proc/cpuinfo): processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 731.026 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1458.17 [7.3.] Module information (from /proc/modules): nothing [7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem) 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 02f8-02ff : serial(set) 0376-0376 : ide1 03c0-03df : vga+ 03f8-03ff : serial(set) 0cf8-0cff : PCI conf1 5000-50ff : Adaptec AIC-7892P U160/m 5400-543f : Intel Corp. 82557/8/9 [Ethernet Pro 100] 5400-543f : eepro100 6000-60ff : Intel Corp. 82801AA AC'97 Audio 6400-643f : Intel Corp. 82801AA AC'97 Audio 6440-645f : Intel Corp. 82801AA USB 6440-645f : usb-uhci 6460-646f : Intel Corp. 82801AA IDE 6460-6467 : ide0 6468-646f : ide1 fc00-fc0f : Intel Corp. 82801AA SMBus 00000000-0009fbff : System RAM 0009fc00-0009ffff : reserved 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000c8000-000c97ff : Extension ROM 000c9800-000cf5ff : Extension ROM 000e0000-000effff : Extension ROM 000f0000-000fffff : System ROM 00100000-07feffff : System RAM 00100000-00336f80 : Kernel code 00336f81-003f3483 : Kernel data 07ff0000-07ffffff : reserved d4000000-d7ffffff : Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A) f9d00000-f9d00fff : Intel Corp. 82557/8/9 [Ethernet Pro 100] f9d00000-f9d00fff : eepro100 f9e00000-f9efffff : Intel Corp. 82557/8/9 [Ethernet Pro 100] f9f00000-f9f00fff : Adaptec AIC-7892P U160/m f9f00000-f9f00fff : aic7xxx fa000000-fbffffff : PCI Bus #01 fa000000-fbffffff : Matrox Graphics, Inc. MGA G400 AGP fd700000-fdffffff : PCI Bus #01 fd700000-fd703fff : Matrox Graphics, Inc. MGA G400 AGP fd800000-fdffffff : Matrox Graphics, Inc. MGA G400 AGP [7.5.] PCI information ('lspci -vvv' as root) pcilib: Cannot open /sys/bus/pci/devices 0000:00:00.0 Host bridge: Intel Corp. 82840 840 (Carmel) Chipset Host Bridge (Hub A) (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR+ 0000:00:01.0 PCI bridge: Intel Corp. 82840 840 (Carmel) Chipset AGP Bridge (rev 01) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 0000:00:1e.0 PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 02) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- 0000:00:1f.0 ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR+ TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [f0] AGP version 2.0 Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1 0000:02:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) Subsystem: Compaq Computer Corporation 82559 Fast Ethernet LOM with Alert on LAN* Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=1M] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 0000:02:07.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02) Subsystem: Compaq Computer Corporation: Unknown device b1bc Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- [7.6.] SCSI information (from /proc/scsi/scsi) Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: COMPAQPC Model: MAJ3091MP Rev: 1812 Type: Direct-Access ANSI SCSI revision: 02 [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): /var/log/messages contains: Apr 11 06:47:29 greux syslogd 1.4.1#14: restart. Apr 11 07:17:19 greux -- MARK -- Apr 11 07:37:19 greux -- MARK -- Apr 11 07:57:19 greux -- MARK -- Apr 11 08:17:19 greux -- MARK -- Apr 11 08:37:19 greux -- MARK -- Apr 11 08:39:22 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 08:39:22 greux last message repeated 90 times Apr 11 08:39:22 greux kernel: CCF6EDC Apr 11 08:39:22 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 08:39:22 greux last message repeated 1336 times Apr 11 08:39:22 greux kernel: CCF6EDC Apr 11 08:39:22 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 08:39:22 greux last message repeated 1455 times Apr 11 08:39:22 greux kernel: CCF6EDC [...] Apr 11 08:45:15 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 08:45:15 greux last message repeated 3787 times Apr 11 08:45:15 greux kernel: CCF6EDC Apr 11 08:45:15 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 08:45:16 greux last message repeated 3399 times Apr 11 08:45:16 greux kernel: CCF6EDC Apr 11 08:45:16 greux kernel: recvmsg bug: copied 7CCF6E4D seq 7CCF6EDC Apr 11 17:06:29 greux syslogd 1.4.1#14: restart. Apr 11 17:06:29 greux kernel: klogd 1.4.1#14, log source = /proc/kmsg started. Apr 11 17:06:29 greux kernel: Inspecting /boot/System.map-2.4.25 [...] (I rebooted the machine at 17:06.) I've just done some pings: loria1:~> ping greux PING greux.loria.fr (152.81.2.43) 56(84) bytes of data. 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=1 ttl=63 time=0.277 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=3 ttl=63 time=0.287 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=4 ttl=63 time=0.285 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=5 ttl=63 time=0.296 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=2 ttl=63 time=3876 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=9 ttl=63 time=0.282 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=10 ttl=63 time=0.287 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=11 ttl=63 time=0.280 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=12 ttl=63 time=0.351 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=6 ttl=63 time=6440 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=7 ttl=63 time=5441 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=8 ttl=63 time=4441 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=16 ttl=63 time=0.278 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=17 ttl=63 time=0.302 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=18 ttl=63 time=0.329 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=13 ttl=63 time=5019 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=14 ttl=63 time=4019 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=15 ttl=63 time=3020 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=23 ttl=63 time=0.284 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=19 ttl=63 time=4776 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=20 ttl=63 time=3776 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=21 ttl=63 time=2777 ms 64 bytes from greux.loria.fr (152.81.2.43): icmp_seq=22 ttl=63 time=1777 ms --- greux.loria.fr ping statistics --- 25 packets transmitted, 23 received, 8% packet loss, time 24110ms rtt min/avg/max/mdev = 0.277/1972.673/6440.864/2233.875 ms, pipe 7 It seems that there is still a network problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From jm@jm.kir.nu Mon Apr 12 21:21:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 21:21:26 -0700 (PDT) Received: from jm.kir.nu (64-60-242-179.cust.telepacific.net [64.60.242.179]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D4LOKO031847 for ; Mon, 12 Apr 2004 21:21:24 -0700 Received: from jm by jm.kir.nu with local (Exim 4.21) id 1BDFPz-00011U-Vv; Mon, 12 Apr 2004 21:21:03 -0700 Date: Mon, 12 Apr 2004 21:21:03 -0700 From: Jouni Malinen To: Jeff Garzik Cc: Greg KH , Ga?l Le Mignot , linux-kernel@vger.kernel.org, Netdev Subject: Re: Any plan for inclusion of linux-wlan-ng ? Message-ID: <20040413042103.GB3670@jm.kir.nu> References: <20040411164011.GA21257@kroah.com> <4079B313.7010907@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4079B313.7010907@pobox.com> User-Agent: Mutt/1.5.6i X-archive-position: 4623 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev Content-Length: 642 Lines: 14 On Sun, Apr 11, 2004 at 05:05:23PM -0400, Jeff Garzik wrote: > I had hoped that HostAP would be submitted, and that could form the > basis of a common 802.11 stack, but I haven't heard anything about that > in many weeks. It will be.. WPA2 distracted me from this preparation, but I will try to get back to cleaning up the Host AP driver for 2.6. Actually, I might consider submitting it first without CCMP (AES-counter with CBC-MAC), because that is the part that is likely to take most time to convert for crypto API and this can be easily added separately. -- Jouni Malinen PGP id EFC895FA From shawn.starr@rogers.com Mon Apr 12 22:16:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 22:16:37 -0700 (PDT) Received: from web02-imail.rogers.com (web02-imail.bloor.is.net.cable.rogers.com [66.185.86.76]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D5GXKO000565 for ; Mon, 12 Apr 2004 22:16:34 -0700 Received: from panic ([69.196.108.95]) by web02-imail.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20040413051538.WGEC40503.web02-imail.rogers.com@panic>; Tue, 13 Apr 2004 01:15:38 -0400 From: "Shawn Starr" To: "'Jeff Garzik'" Cc: "'Len Brown'" , , Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? Date: Tue, 13 Apr 2004 01:16:33 -0400 Message-ID: <000001c42116$7d00fb70$0200080a@panic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4079B246.4070107@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at web02-imail.rogers.com from [69.196.108.95] using ID at Tue, 13 Apr 2004 01:15:38 -0400 X-archive-position: 4624 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 908 Lines: 32 Might be, I have since not had any issues with timeouts. Though, I don't know where it is doing this. It is an IBM machine so some things are proprietary. -----Original Message----- From: Jeff Garzik Sent: Sunday, April 11, 2004 05:02 PM To: Shawn Starr Cc: 'Len Brown'; linux-kernel@; netdev@ Subject: Re: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? Shawn Starr wrote: > Ok, this is strange, I put in an external 10/100 PRO S Adaptor, and im > not getting anymore eth0 timeouts, I would only get eth0 timeouts on > the ONBOARD nic if I enabled the lm80 sensor driver.. I don't know > what to say, the onboard nic would work fine without lm80 being > loaded? > > Is there some sort of race condition that the onboard 10/100 PRO is > doing ? If i2c is killing the network, sounds like it's diddling something on the motherboard it shouldn't... Jeff From shawn.starr@rogers.com Mon Apr 12 22:16:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 22:16:48 -0700 (PDT) Received: from web02-imail.rogers.com (web02-imail.bloor.is.net.cable.rogers.com [66.185.86.76]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D5GiKO000581 for ; Mon, 12 Apr 2004 22:16:46 -0700 Received: from panic ([69.196.108.95]) by web02-imail.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20040413051548.WGFY40503.web02-imail.rogers.com@panic>; Tue, 13 Apr 2004 01:15:48 -0400 From: "Shawn Starr" To: "'Jeff Garzik'" Cc: "'Len Brown'" , , Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? Date: Tue, 13 Apr 2004 01:16:43 -0400 Message-ID: <000101c42116$82b8e910$0200080a@panic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <4079B246.4070107@pobox.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Authentication-Info: Submitted using SMTP AUTH LOGIN at web02-imail.rogers.com from [69.196.108.95] using ID at Tue, 13 Apr 2004 01:15:38 -0400 X-archive-position: 4625 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shawn.starr@rogers.com Precedence: bulk X-list: netdev Content-Length: 908 Lines: 32 Might be, I have since not had any issues with timeouts. Though, I don't know where it is doing this. It is an IBM machine so some things are proprietary. -----Original Message----- From: Jeff Garzik Sent: Sunday, April 11, 2004 05:02 PM To: Shawn Starr Cc: 'Len Brown'; linux-kernel@; netdev@ Subject: Re: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? Shawn Starr wrote: > Ok, this is strange, I put in an external 10/100 PRO S Adaptor, and im > not getting anymore eth0 timeouts, I would only get eth0 timeouts on > the ONBOARD nic if I enabled the lm80 sensor driver.. I don't know > what to say, the onboard nic would work fine without lm80 being > loaded? > > Is there some sort of race condition that the onboard 10/100 PRO is > doing ? If i2c is killing the network, sounds like it's diddling something on the motherboard it shouldn't... Jeff From akpm@osdl.org Mon Apr 12 22:25:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 22:25:53 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D5PpKO001359 for ; Mon, 12 Apr 2004 22:25:51 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i3D5Pj219559 for ; Mon, 12 Apr 2004 22:25:45 -0700 Date: Mon, 12 Apr 2004 22:25:32 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: add-a-slab-for-ethernet.patch Message-Id: <20040412222532.25c7e1b9.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4626 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: 1078 Lines: 42 I've been sitting on this for a while: From: Manfred Spraul Improve the packing density for 1536-byte ethernet frames on 8k or larger page size machines. The slab has 1620 bytes - 5 should fit into one page (1620*5+40 bytes slab+5*4 bufctl - 32 bytes should remain unused on 64-bit archs). --- 25-akpm/include/linux/kmalloc_sizes.h | 3 +++ 1 files changed, 3 insertions(+) diff -puN include/linux/kmalloc_sizes.h~add-a-slab-for-ethernet include/linux/kmalloc_sizes.h --- 25/include/linux/kmalloc_sizes.h~add-a-slab-for-ethernet Tue Feb 24 14:40:06 2004 +++ 25-akpm/include/linux/kmalloc_sizes.h Tue Feb 24 14:40:06 2004 @@ -12,6 +12,9 @@ CACHE(256) CACHE(512) CACHE(1024) +#if (PAGE_SIZE != 4096) /* special cache for eth skbs - 5 fit into one 8 kB page */ + CACHE(1620) +#endif CACHE(2048) CACHE(4096) CACHE(8192) _ Problem is, I'm not sure it's worth the effort - it seems that the system just never has that many full-sized ethernet frames floating about, so we don't save significant amounts of memory. Am I wrong? From krupa@globaledgesoft.com Mon Apr 12 22:32:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 12 Apr 2004 22:32:19 -0700 (PDT) Received: from globaledgesoft.com ([203.145.183.39]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D5W0KO001794 for ; Mon, 12 Apr 2004 22:32:10 -0700 Received: from krupaxp ([172.16.6.17]) by globaledgesoft.com (globaledgesoft.com [172.16.6.2]) (MDaemon.PRO.v6.8.5.R) with ESMTP id 5-md50000000001.tmp for ; Tue, 13 Apr 2004 11:01:44 +0530 Message-ID: <007501c3b895$efd46d60$110610ac@krupaxp> From: "krupa" To: , References: <000001c42116$7d00fb70$0200080a@panic> Subject: Fragmentation issue Date: Tue, 2 Dec 2003 11:04:20 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-MDRemoteIP: 172.16.6.17 X-Return-Path: krupa@globaledgesoft.com X-MDaemon-Deliver-To: netdev@oss.sgi.com X-archive-position: 4627 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: krupa@globaledgesoft.com Precedence: bulk X-list: netdev Content-Length: 1729 Lines: 55 Hi, Anybody.........could you help me. Steps followed. 1. insmod module.o // inserting module 2. iwconfig eth1 essid // associating with AP 3. iwconfig eth1 frag 512 // setting fragmentation 4. ping -s 700 The problem here is ..............when I ping to that AP with packect size more that Frag value,69 packets it will send then it will hang. How to overcome this ----- Original Message ----- From: "Shawn Starr" To: "'Jeff Garzik'" Cc: "'Len Brown'" ; ; Sent: Tuesday, April 13, 2004 10:46 AM Subject: RE: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? > Might be, I have since not had any issues with timeouts. Though, I don't > know where it is doing this. It is an IBM machine so some things are > proprietary. > > -----Original Message----- > From: Jeff Garzik > Sent: Sunday, April 11, 2004 05:02 PM > To: Shawn Starr > Cc: 'Len Brown'; linux-kernel@; netdev@ > Subject: Re: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout > -Related to i2c interface? > > > Shawn Starr wrote: > > Ok, this is strange, I put in an external 10/100 PRO S Adaptor, and im > > not getting anymore eth0 timeouts, I would only get eth0 timeouts on > > the ONBOARD nic if I enabled the lm80 sensor driver.. I don't know > > what to say, the onboard nic would work fine without lm80 being > > loaded? > > > > Is there some sort of race condition that the onboard 10/100 PRO is > > doing ? > > If i2c is killing the network, sounds like it's diddling something on > the motherboard it shouldn't... > > Jeff > From nam4ku@emailaccount.com Tue Apr 13 02:01:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 02:01:38 -0700 (PDT) Received: from omta06.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D91aKO010750 for ; Tue, 13 Apr 2004 02:01:36 -0700 Received: from sitemail.everyone.net (bigip1-snat [216.200.145.29]) by omta06.mta.everyone.net (Postfix) with ESMTP id 963724CBEA for ; Tue, 13 Apr 2004 02:01:33 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 8775C282C17; Tue, 13 Apr 2004 02:01:33 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Tue, 13 Apr 2004 02:01:33 -0700 (PDT) From: nam aku To: netdev@oss.sgi.com Subject: mailing list ??? Reply-To: nam4ku@emailaccount.com X-Originating-Ip: [202.6.234.6] X-Eon-Sig: AQHs4iVAe6xtAATgigEAAAAB,7aed005dfe3fd0feea8ada42086e055e Message-Id: <20040413090133.8775C282C17@sitemail.everyone.net> X-archive-position: 4628 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nam4ku@emailaccount.com Precedence: bulk X-list: netdev Content-Length: 221 Lines: 5 mailing list is for network development (not user questions). _____________________________________________________________ Free, simple, fast, memorable email Become you@EmailAccount.com at http://www.emailaccount.com/ From praveen@india.hp.com Tue Apr 13 03:39:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 03:39:20 -0700 (PDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DAd7KO015064 for ; Tue, 13 Apr 2004 03:39:07 -0700 Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.42.231.12]) by atlrel7.hp.com (Postfix) with ESMTP id 365861C012F1 for ; Tue, 13 Apr 2004 06:11:21 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.9.3 (PHNE_25184)/8.9.3 SMKit7.02) id PAA18883; Tue, 13 Apr 2004 15:43:29 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200404131013.PAA18883@shilpa.india.hp.com> Subject: zero window probes on linux (fwd) To: netdev@oss.sgi.com Date: Tue, 13 Apr 2004 15:43:29 +0530 (IST) Cc: praveen@shilpa.india.hp.com (Praveen Kumar Amritaluru) X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4629 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: praveen@india.hp.com Precedence: bulk X-list: netdev Content-Length: 1254 Lines: 35 Hi, I am running a client-server program with client running on a linux machine with 2.4.18-14 kernel installed. When the server announces zero-window to the client, client starts sending zero-window probes which are nothing but unacceptable segments. A short trace obtained using tcpdump and interpreted using ethereal is shown below: 16:27:17.979349 e.f.g.h.33464 > a.b.c.d.40000: P Seq=76441951 Ack=802335667 Win 5840 len=1080 16:27:18.040407 a.b.c.d.40000 > e.f.g.h.33464: . Seq=802335667 Ack=764413031 Win 0 len=0 16:27:18.256213 e.f.g.h.33464 > a.b.c.d.40000: . Seq=764413030 Ack=802335667 Win 5840 len=0 This sequence continues as per retransmission algorithm with same seq no. and ack no on both ends of TCP connection. It can be seen above that unacceptable zero-length packets with a sequence no. already unacknowledged is being used as zero-window probes. Zero window probes are defined in RFC 793 and RFC1122 to be a data segment containing atleast one byte of data beyond the window of the receiver who has closed the window. This seems to be a bug. Has it been already fixed in later kernel versions or is this how it is intended to remain? Regards, Praveen From ltarkkal@safenet-inc.com Tue Apr 13 05:19:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 05:19:54 -0700 (PDT) Received: from gonzo.vught.safenet-inc.com ([213.53.67.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DCJnKO021706 for ; Tue, 13 Apr 2004 05:19:50 -0700 Received: from tehdas ([172.30.4.70]) by gonzo.vught.safenet-inc.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Apr 2004 14:19:43 +0200 Received: from ltarkkal by tehdas with local (Exim 3.36 #1 (Debian)) id 1BDbq7-0005DC-00 for ; Wed, 14 Apr 2004 07:17:31 +0300 Date: Wed, 14 Apr 2004 07:17:31 +0300 From: Lauri Tarkkala To: netdev@oss.sgi.com Subject: [PATCH] ip multicast, kernel 2.4.2*, 2.6.* Message-ID: <20040414041731.GA2010@safenet-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-OriginalArrivalTime: 13 Apr 2004 12:19:43.0950 (UTC) FILETIME=[9A638EE0:01C42151] X-archive-position: 4630 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltarkkala@safenet-inc.com Precedence: bulk X-list: netdev Content-Length: 3017 Lines: 78 There is an obnoxious problem in the sending of both ipv4 and ipv6 multicast/broadcast packets in both the 2.4 and 2.6 series and netfilter modules. The processing is roughly as follows: 1. If packet is multicast/broadcast, duplicate it. 2. Pass the duplicate packet through netfilter hooks using NF_HOOK_SLOW(IP_POST_ROUTING). 3. Set skb.type to PACKET_LOOPBACK in the netfilter hook callback and pass the packet to netif_rx(). 4. Send the original packet out via NF_HOOK(IP_POST_ROUTING). The reason for this processing (my guess), is that the inbound (duplicate) packet will not be sent, unless the original passes the netfilter hooks. This has the side-effect that netfilter hooks have no way of detecting whether packets are intended to or are going to be looped back. The looped-back packet will of course still go through the inbound hooks. This is quite error-prone, both in terms of configuring policy for netfilter modules, not to mention optimization and implementation. There are also some cases that just can not be handled correctly. My first choice would be to simply change the behaviour so that the duplicate packet is not bassed through the IP_POST_ROUTING hook. Below is a patch that does exactly this.. The patch works against recent 2.4.x and 2.6.x series kernels. I can not think of a (good) reason for the current behaviour. If someone with more history knowledge could enlighten me, I'd be grateful. Lauri -- Lauri Tarkkala Safenet Inc. http://www.safenet-inc.com/ diff -aur -p linux-2.4.25/net/ipv4/ip_output.c linux-2.4.25-fixed/net/ipv4/ip_output.c --- linux-2.4.25/net/ipv4/ip_output.c 2004-04-14 06:00:52.000000000 +0300 +++ linux-2.4.25-fixed/net/ipv4/ip_output.c 2004-04-14 06:01:04.000000000 +0300 @@ -233,9 +233,7 @@ int ip_mc_output(struct sk_buff *skb) ) { struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC); if (newskb) - NF_HOOK(PF_INET, NF_IP_POST_ROUTING, newskb, NULL, - newskb->dev, - ip_dev_loopback_xmit); + ip_dev_loopback_xmit(newskb); } /* Multicasts with ttl 0 must not go beyond the host */ @@ -249,8 +247,7 @@ int ip_mc_output(struct sk_buff *skb) if (rt->rt_flags&RTCF_BROADCAST) { struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC); if (newskb) - NF_HOOK(PF_INET, NF_IP_POST_ROUTING, newskb, NULL, - newskb->dev, ip_dev_loopback_xmit); + ip_dev_loopback_xmit(newskb); } return ip_finish_output(skb); diff -aur -p linux-2.4.25/net/ipv6/ip6_output.c linux-2.4.25-fixed/net/ipv6/ip6_output.c --- linux-2.4.25/net/ipv6/ip6_output.c 2004-04-14 06:00:52.000000000 +0300 +++ linux-2.4.25-fixed/net/ipv6/ip6_output.c 2004-04-14 05:44:40.000000000 +0300 @@ -118,9 +118,7 @@ int ip6_output(struct sk_buff *skb) is not supported in any case. */ if (newskb) - NF_HOOK(PF_INET6, NF_IP6_POST_ROUTING, newskb, NULL, - newskb->dev, - ip6_dev_loopback_xmit); + ip6_dev_loopback_xmit(newskb); if (skb->nh.ipv6h->hop_limit == 0) { kfree_skb(skb); From Robert.Olsson@data.slu.se Tue Apr 13 06:06:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 06:06:34 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DD6TKO023090 for ; Tue, 13 Apr 2004 06:06:30 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i3DD6SNv016294; Tue, 13 Apr 2004 15:06:28 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 59DEE903D5; Tue, 13 Apr 2004 15:06:28 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16507.58836.330646.613359@robur.slu.se> Date: Tue, 13 Apr 2004 15:06:28 +0200 To: Christopher Chan Cc: netdev@oss.sgi.com, Robert.Olsson@data.slu.se Subject: 2.6.4 e100 NAPI - dst cache overflow and network unavailability In-Reply-To: <4075F218.90804@outblaze.com> References: <4075F218.90804@outblaze.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-archive-position: 4631 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1177 Lines: 34 Christopher Chan writes: > However, I had NAPI enabled in the e100 driver then. > > Turning NAPI off for the e100 driver has meant that the box has now been > up several days without any problems under heavy network load. > > I have not tried out 2.6.5 with NAPI enabled but 2.6.5 without NAPI > enabled is stable. dst cache overflows when garbage collection cannot keep up dst entries freed so we exceed max_size. GC is run after gc_min_interval and eventually a RCU delay which we have discussed here and are looking into now. So if you increase your network performance/load for any reason so more dst entries are freed you can reach the overflow threshold. This is probably what happens for you with NAPI driver. You can try to decrease gc_min_interval a bit but if you are unlucky you have run into RCU problem as well. There is one experimental patch that seems help. Tuning just to avoid dst cache overflows can mean you sacrifice a lot of network performance. Anyway monitor your route cache to start with. There is interesting stats in /proc/net/rt_cache_stat. The rtstat utility can be handy parsing it. Cheers. --ro From jmorris@redhat.com Tue Apr 13 06:46:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 06:46:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DDkMKO024333 for ; Tue, 13 Apr 2004 06:46:23 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3DDkIu6005959; Tue, 13 Apr 2004 09:46:18 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3DDkGj08552; Tue, 13 Apr 2004 09:46:16 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i3DDkBF5000452; Tue, 13 Apr 2004 09:46:15 -0400 Date: Tue, 13 Apr 2004 09:46:11 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Denis Vlasenko cc: "David S. Miller" , , =?iso-2022-jp?Q?YOSHIFUJI_Hideaki_=2F_=1B$B5HF#1QL=40=1B=28B?= , Subject: Re: your mail In-Reply-To: <200404121623.42558.vda@port.imtp.ilyichevsk.odessa.ua> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id i3DDkIu6005959 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3DDkMKO024333 X-archive-position: 4632 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 483 Lines: 23 On Mon, 12 Apr 2004, Denis Vlasenko wrote: > According to my measurements, > > ip_vs_control_add() (from include/net/ip_vs.h) is called twice > and > sock_queue_rcv_skb() (from include/net/sock.h) is called 19 times > from various kernel .c files. > > Both these includes generate more than 500 bytes of code on x86. > > These patches uninline them. Please apply. What kind of performance impact (if any) does this patch have? - James -- James Morris From jgarzik@pobox.com Tue Apr 13 11:07:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:07:08 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DI74KO006560 for ; Tue, 13 Apr 2004 11:07:05 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BDSJL-0007zh-6I; Tue, 13 Apr 2004 19:07:03 +0100 Message-ID: <407C2C3B.9000409@pobox.com> Date: Tue, 13 Apr 2004 14:06:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] pcnet32 fix hang/crash with loopback test References: <200404072250.i37MoPC19556@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404072250.i37MoPC19556@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4633 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 17 Lines: 3 applied to 2.6 From jgarzik@pobox.com Tue Apr 13 11:24:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:24:46 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIObKO007316 for ; Tue, 13 Apr 2004 11:24:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BDSaK-0008EJ-L7; Tue, 13 Apr 2004 19:24:36 +0100 Message-ID: <407C3058.50808@pobox.com> Date: Tue, 13 Apr 2004 14:24:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.4.26-rc2] pcnet32 fix hang/crash with loopback test References: <200404072251.i37MpZ219567@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404072251.i37MpZ219567@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4634 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: 70 Lines: 3 patch is acceptable, but does not apply to my net-drivers-2.4 tree. From jgarzik@pobox.com Tue Apr 13 11:27:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:27:45 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIRgKO007756 for ; Tue, 13 Apr 2004 11:27:42 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BDSdJ-0008GB-4e; Tue, 13 Apr 2004 19:27:41 +0100 Message-ID: <407C3111.4040606@pobox.com> Date: Tue, 13 Apr 2004 14:27:29 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com, Srihari Vijayaraghavan Subject: Re: [patch 1/3] 2.6.5-netdev2 - r8169 update References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040407231332.A25021@electric-eye.fr.zoreil.com> <20040407231444.A25867@electric-eye.fr.zoreil.com> In-Reply-To: <20040407231444.A25867@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4635 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: 411 Lines: 14 My apologies, these three patches applied successfully to 2.6.x: 1) Missing 'static' qualifier for functions. 2) The irq handler must not return 1 when the status register is null during the firt iteration. 3) mod_timer() expects an absolute time, not a relative offset. Also, future requests: a) please include a useful Subject line (mentioned in previous email) b) please -exclude- your diffstat output From jgarzik@pobox.com Tue Apr 13 11:29:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:29:25 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DITFKO008096 for ; Tue, 13 Apr 2004 11:29:16 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BDSeo-0008HO-Rz; Tue, 13 Apr 2004 19:29:14 +0100 Message-ID: <407C316F.9070308@pobox.com> Date: Tue, 13 Apr 2004 14:29:03 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev Subject: Re: [janitor] remove concat. with __FUNCTION__ (drivers/net/) (V2) References: <20040407110819.61f55064.rddunlap@osdl.org> In-Reply-To: <20040407110819.61f55064.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4636 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From jgarzik@pobox.com Tue Apr 13 11:32:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:32:43 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIWdKO008455 for ; Tue, 13 Apr 2004 11:32:40 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BDSi4-0008J8-Bl; Tue, 13 Apr 2004 19:32:36 +0100 Message-ID: <407C3238.9030103@pobox.com> Date: Tue, 13 Apr 2004 14:32:24 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Vlasenko CC: Francois Romieu , andreas@fjortis.info, netdev@oss.sgi.com Subject: Re: [PATCH] 2.4, 2.6 patchset for fealnx.c References: <200404052217.35883.vda@port.imtp.ilyichevsk.odessa.ua> In-Reply-To: <200404052217.35883.vda@port.imtp.ilyichevsk.odessa.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4637 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: 159 Lines: 10 Can you please patchbomb me instead? One patch per email, and separate patchbombs for 2.4 and 2.6 if a single set does not apply to both kernels. Jeff From ak@suse.de Tue Apr 13 11:50:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 11:50:49 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIojKO009810 for ; Tue, 13 Apr 2004 11:50:47 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 7475344E936; Tue, 13 Apr 2004 20:50:39 +0200 (CEST) Date: Tue, 13 Apr 2004 20:50:35 +0200 From: Andi Kleen To: Praveen Kumar Amritaluru Cc: netdev@oss.sgi.com, praveen@shilpa.india.hp.com Subject: Re: zero window probes on linux (fwd) Message-Id: <20040413205035.447c925c.ak@suse.de> In-Reply-To: <200404131013.PAA18883@shilpa.india.hp.com> References: <200404131013.PAA18883@shilpa.india.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4638 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 332 Lines: 12 On Tue, 13 Apr 2004 15:43:29 +0530 (IST) Praveen Kumar Amritaluru wrote: > > This seems to be a bug. Has it been already fixed in later > kernel versions or is this how it is intended to remain? iirc this was intentional. The RFC suggested method doesn't work when talking to some stacks. -Andi From mv@inv.cz Tue Apr 13 12:42:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 12:42:21 -0700 (PDT) Received: from web.dragon.cz (root@web.dragon.cz [213.168.176.4]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DJg5KO014005 for ; Tue, 13 Apr 2004 12:42:07 -0700 Received: from mv.dragon.cz (mv.dragon.cz [213.168.178.188]) by web.dragon.cz with SMTP id i3DJfxSR005490; Tue, 13 Apr 2004 21:41:59 +0200 Date: Tue, 13 Apr 2004 21:41:57 +0200 From: Martin Volf To: jamal Subject: Re: [LARTC] FWD IMQ mail on netdev Message-ID: <20040413194157.GA20599@martinpc.doma> References: <407B9ABF.60101@dsl.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <407B9ABF.60101@dsl.pipex.com> User-Agent: Mutt/1.5.6i X-archive-position: 4639 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mv@inv.cz Precedence: bulk X-list: netdev Content-Length: 997 Lines: 34 > ----- Forwarded message from jamal ----- > > Subject: (Long) ANNOUNCE: IMQ replacement WAS(Re: [RFC/PATCH] IMQ port to > 2.6 > From: jamal > Reply-To: hadi@cyberus.ca > To: "Vladimir B. Savkin" > Cc: netdev@oss.sgi.com .. > I finally hacked dummy device as a good replacement (IMO) for IMQ. > I am only subscribed to netdev so if there are other lists which > are of interest to this subject please forward on, but make sure > responses make it to netdev. .. > What am i looking for? .. > 2) testing of the above by people who use IMQ Hello, I would like to test your patch. Can you please point me to the place, from which it can be downloaded? I have a terrible experience with Patrick McHardy's IMQ on NATing firewalls (kernel panics randomly etc) and a very good experience with the very same IMQ on an ethernet bridge (rock solid for one year). I can share the results of the test with netdev ml. Thanks! -- Martin Volf From mitch@sfgoth.com Tue Apr 13 13:00:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 13:00:15 -0700 (PDT) Received: from gaz.sfgoth.com (gaz.sfgoth.com [69.36.241.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DK02KO014721 for ; Tue, 13 Apr 2004 13:00:03 -0700 Received: from gaz.sfgoth.com (localhost.sfgoth.com [127.0.0.1]) by gaz.sfgoth.com (8.12.10/8.12.9) with ESMTP id i3DK1Hqu038755; Tue, 13 Apr 2004 13:01:17 -0700 (PDT) (envelope-from mitch@gaz.sfgoth.com) Received: (from mitch@localhost) by gaz.sfgoth.com (8.12.10/8.12.6/Submit) id i3DK1H3l038754; Tue, 13 Apr 2004 13:01:17 -0700 (PDT) (envelope-from mitch) Date: Tue, 13 Apr 2004 13:01:17 -0700 From: Mitchell Blank Jr To: Andrew Morton Cc: netdev@oss.sgi.com Subject: Re: add-a-slab-for-ethernet.patch Message-ID: <20040413200117.GB36793@gaz.sfgoth.com> References: <20040412222532.25c7e1b9.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040412222532.25c7e1b9.akpm@osdl.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 4640 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mitch@sfgoth.com Precedence: bulk X-list: netdev Content-Length: 851 Lines: 22 Andrew Morton wrote: > +#if (PAGE_SIZE != 4096) /* special cache for eth skbs - 5 fit into one 8 kB page */ > + CACHE(1620) > +#endif Nitpicks: 1. Shouldn't this be (PAGE_SIZE > 4096)? Yeah, it's not very likely that we'll ever have to support an arch w/ a page size <4K (I believe the linux-vax port uses 4K superpages, not the 1K native page size) but it doesn't hurt to be careful. 2. Maybe also add "&& defined(CONFIG_NET)" to that? You could also argue for CONFIG_ETHERNET but there's lots of cases where people might want to use ethernet-sized frames (bridged over ATM, whatever) even if they don't have any ethernet cards installed. Doubt there's too many people with 8K page sizes and no networking support compiled in... but today's high-end is tomorrow's embedded processor :-) -Mitch From romieu@fr.zoreil.com Tue Apr 13 13:56:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 13:56:55 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DKuYKO016714 for ; Tue, 13 Apr 2004 13:56:35 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3DJs9uX009366; Tue, 13 Apr 2004 21:54:09 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3DJs8jd009365; Tue, 13 Apr 2004 21:54:08 +0200 Date: Tue, 13 Apr 2004 21:54:08 +0200 From: Francois Romieu To: Jeff Garzik Cc: Daniel Egger , Linux Kernel , Andrew Morton , Netdev Subject: Re: [NET] net driver updates Message-ID: <20040413215408.A8741@electric-eye.fr.zoreil.com> References: <4072CD01.6070408@pobox.com> <407C31F4.9070800@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <407C31F4.9070800@pobox.com>; from jgarzik@pobox.com on Tue, Apr 13, 2004 at 02:31:16PM -0400 X-Organisation: Land of Sunshine Inc. X-archive-position: 4641 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 485 Lines: 16 Jeff Garzik : [...] > Francois is still trying to fix all the vendor-created bugs, so > performance is a secondary consideration. With due respect to Realtek and others, some pesky bugs in the driver were really (c) by me. The issues related to 64 bit host and/or link recovery seem to be gone. If people experience issues with the r8169 driver in -mm/-netdev whereas the vanilla driver works fine, I am interested to hear from them. Preferably now. -- Ueimor From brazilnut@us.ibm.com Tue Apr 13 15:09:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:09:44 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DM9NKO018398 for ; Tue, 13 Apr 2004 15:09:30 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3DM9Enr227830; Tue, 13 Apr 2004 18:09:14 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3DM9CbT132970; Tue, 13 Apr 2004 16:09:12 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3DM8BB01509; Tue, 13 Apr 2004 15:08:11 -0700 From: Don Fry Message-Id: <200404132208.i3DM8BB01509@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.4.26-rc3]pcnet32 fix hang/crash with loopback test To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 13 Apr 2004 15:08:10 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4642 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 7503 Lines: 246 If the pcnet32 interface is not up, running the loopback test may hang or crash the system. This patch provided by Jim Lewis fixes that problem. Tested on ia32 and ppc systems. This applies cleanly against net-drivers-2.4 --- linux-2.4.26-rc3/drivers/net/kent.pcnet32.c Tue Apr 13 14:11:02 2004 +++ linux-2.4.26-rc3/drivers/net/pcnet32.c Tue Apr 13 14:14:19 2004 @@ -353,6 +353,7 @@ static void pcnet32_interrupt(int, void *, struct pt_regs *); static int pcnet32_close(struct net_device *); static struct net_device_stats *pcnet32_get_stats(struct net_device *); +static void pcnet32_load_multicast(struct net_device *dev); static void pcnet32_set_multicast_list(struct net_device *); static int pcnet32_ioctl(struct net_device *, struct ifreq *, int); static void pcnet32_watchdog(struct net_device *); @@ -618,34 +619,40 @@ struct pcnet32_access *a = &lp->a; /* access to registers */ ulong ioaddr = dev->base_addr; /* card base I/O address */ struct sk_buff *skb; /* sk buff */ - int x, y, i; /* counters */ + int x, i; /* counters */ int numbuffs = 4; /* number of TX/RX buffers and descs */ u16 status = 0x8300; /* TX ring status */ + u16 teststatus; /* test of ring status */ int rc; /* return code */ int size; /* size of packets */ unsigned char *packet; /* source packet data */ static int data_len = 60; /* length of source packets */ unsigned long flags; + unsigned long ticks; *data1 = 1; /* status of test, default to fail */ rc = 1; /* default to fail */ + if (netif_running(dev)) + pcnet32_close(dev); + spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x7904); - del_timer_sync(&lp->watchdog_timer); + /* Reset the PCNET32 */ + lp->a.reset (ioaddr); - netif_stop_queue(dev); + /* switch pcnet32 to 32bit mode */ + lp->a.write_bcr (ioaddr, 20, 2); + + lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); + lp->init_block.filter[0] = 0; + lp->init_block.filter[1] = 0; /* purge & init rings but don't actually restart */ pcnet32_restart(dev, 0x0000); lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ - x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ - x = x | 0x00000002; - a->write_bcr(ioaddr, 32, x); - /* Initialize Transmit buffers. */ size = data_len + 15; for (x=0; xtx_skbuff[x] = skb; lp->tx_ring[x].length = le16_to_cpu(-skb->len); - lp->tx_ring[x].misc = 0x00000000; + lp->tx_ring[x].misc = 0; - /* put DA and SA into the skb */ - for (i=0; i<12; i++) - *packet++ = 0xff; + /* put DA and SA into the skb */ + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; + for (i=0; i<6; i++) + *packet++ = dev->dev_addr[i]; /* type */ *packet++ = 0x08; *packet++ = 0x06; /* packet number */ *packet++ = x; /* fill packet with data */ - for (y=0; ytx_dma_addr[x] = pci_map_single(lp->pci_dev, skb->data, skb->len, PCI_DMA_TODEVICE); @@ -681,20 +690,41 @@ } } - lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ - spin_unlock_irqrestore(&lp->lock, flags); + x = a->read_bcr(ioaddr, 32); /* set internal loopback in BSR32 */ + x = x | 0x0002; + a->write_bcr(ioaddr, 32, x); - mdelay(50); /* wait a bit */ + lp->a.write_csr (ioaddr, 15, 0x0044); /* set int loopback in CSR15 */ - spin_lock_irqsave(&lp->lock, flags); - lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + teststatus = le16_to_cpu(0x8000); + lp->a.write_csr(ioaddr, 0, 0x0002); /* Set STRT bit */ + + /* Check status of descriptors */ + for (x=0; xrx_ring[x].status & teststatus) && (ticks < 200)) { + spin_unlock_irqrestore(&lp->lock, flags); + mdelay(1); + spin_lock_irqsave(&lp->lock, flags); + rmb(); + ticks++; + } + if (ticks == 200) { + if (netif_msg_hw(lp)) + printk("%s: Desc %d failed to reset!\n",dev->name,x); + break; + } + } + lp->a.write_csr(ioaddr, 0, 0x0004); /* Set STOP bit */ + wmb(); if (netif_msg_hw(lp) && netif_msg_pktdata(lp)) { printk(KERN_DEBUG "%s: RX loopback packets:\n", dev->name); for (x=0; xname, x); - skb=lp->rx_skbuff[x]; + skb = lp->rx_skbuff[x]; for (i=0; idata+i)); } @@ -727,19 +757,17 @@ a->write_csr(ioaddr, 15, (x & ~0x0044)); /* reset bits 6 and 2 */ x = a->read_bcr(ioaddr, 32); /* reset internal loopback */ - x = x & ~0x00000002; + x = x & ~0x0002; a->write_bcr(ioaddr, 32, x); - pcnet32_restart(dev, 0x0042); /* resume normal operation */ - - netif_wake_queue(dev); - - mod_timer (&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT); - - /* Clear interrupts, and set interrupt enable. */ - lp->a.write_csr(ioaddr, 0, 0x7940); spin_unlock_irqrestore(&lp->lock, flags); + if (netif_running(dev)) { + pcnet32_open(dev); + } else { + lp->a.write_bcr (ioaddr, 20, 4); /* return to 16bit mode */ + } + return(rc); } /* end pcnet32_loopback_test */ @@ -980,7 +1008,7 @@ memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); for (i = 0; i < 6; i++) - printk(" %2.2x", dev->dev_addr[i] ); + printk(" %2.2x", dev->dev_addr[i]); if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */ i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ @@ -1153,6 +1181,7 @@ u16 val; int i; int rc; + unsigned long flags; if (dev->irq == 0 || request_irq(dev->irq, &pcnet32_interrupt, @@ -1160,6 +1189,7 @@ return -EAGAIN; } + spin_lock_irqsave(&lp->lock, flags); /* Check for a valid station address */ if (!is_valid_ether_addr(dev->dev_addr)) { rc = -EINVAL; @@ -1236,8 +1266,8 @@ } lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); - lp->init_block.filter[0] = 0x00000000; - lp->init_block.filter[1] = 0x00000000; + pcnet32_load_multicast(dev); + if (pcnet32_init_ring(dev)) { rc = -ENOMEM; goto err_free_ring; @@ -1273,6 +1303,7 @@ dev->name, i, (u32) (lp->dma_addr + offsetof(struct pcnet32_private, init_block)), lp->a.read_csr(ioaddr, 0)); + spin_unlock_irqrestore(&lp->lock, flags); return 0; /* Always succeed */ @@ -1295,6 +1326,7 @@ lp->a.write_bcr (ioaddr, 20, 4); err_free_irq: + spin_unlock_irqrestore(&lp->lock, flags); free_irq(dev->irq, dev); return rc; } @@ -1764,11 +1796,14 @@ unsigned long ioaddr = dev->base_addr; struct pcnet32_private *lp = dev->priv; int i; + unsigned long flags; del_timer_sync(&lp->watchdog_timer); netif_stop_queue(dev); + spin_lock_irqsave(&lp->lock, flags); + lp->stats.rx_missed_errors = lp->a.read_csr (ioaddr, 112); if (netif_msg_ifdown(lp)) @@ -1784,6 +1819,8 @@ */ lp->a.write_bcr (ioaddr, 20, 4); + spin_unlock_irqrestore(&lp->lock, flags); + free_irq(dev->irq, dev); /* free all allocated skbuffs */ -- Don Fry brazilnut@us.ibm.com From shemminger@osdl.org Tue Apr 13 15:16:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:16:55 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMGhKO018847 for ; Tue, 13 Apr 2004 15:16:43 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMGV205559; Tue, 13 Apr 2004 15:16:31 -0700 Date: Tue, 13 Apr 2004 15:16:30 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (1/9) bridge - include file cleanup Message-Id: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4643 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: 4951 Lines: 165 Cleanup some of the include file's in the bridge code. * if_bridge.h defines net_bridge, but not needed as part of the API. * get rid of places that include if_bridge.h and uaccess.h but don't actually do API work. diff -Nru a/include/linux/if_bridge.h b/include/linux/if_bridge.h --- a/include/linux/if_bridge.h Tue Apr 13 14:44:58 2004 +++ b/include/linux/if_bridge.h Tue Apr 13 14:44:58 2004 @@ -99,9 +99,6 @@ #include -struct net_bridge; -struct net_bridge_port; - extern void brioctl_set(int (*ioctl_hook)(unsigned long)); extern int (*br_handle_frame_hook)(struct sk_buff *skb); extern int (*br_should_route_hook)(struct sk_buff **pskb); diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br.c Tue Apr 13 14:44:58 2004 @@ -20,8 +20,7 @@ #include #include #include -#include -#include + #include "br_private.h" #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) diff -Nru a/net/bridge/br_device.c b/net/bridge/br_device.c --- a/net/bridge/br_device.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_device.c Tue Apr 13 14:44:58 2004 @@ -15,7 +15,6 @@ #include #include -#include #include #include #include "br_private.h" diff -Nru a/net/bridge/br_forward.c b/net/bridge/br_forward.c --- a/net/bridge/br_forward.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_forward.c Tue Apr 13 14:44:58 2004 @@ -15,9 +15,7 @@ #include #include -#include #include -#include #include #include "br_private.h" diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_if.c Tue Apr 13 14:44:58 2004 @@ -15,13 +15,11 @@ #include #include -#include -#include #include #include #include #include -#include + #include "br_private.h" /* Limited to 256 ports because of STP protocol pdu */ diff -Nru a/net/bridge/br_input.c b/net/bridge/br_input.c --- a/net/bridge/br_input.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_input.c Tue Apr 13 14:44:58 2004 @@ -16,7 +16,6 @@ #include #include #include -#include #include #include "br_private.h" diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_ioctl.c Tue Apr 13 14:44:58 2004 @@ -15,7 +15,7 @@ #include #include -#include +#include #include #include "br_private.h" diff -Nru a/net/bridge/br_notify.c b/net/bridge/br_notify.c --- a/net/bridge/br_notify.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_notify.c Tue Apr 13 14:44:58 2004 @@ -14,7 +14,7 @@ */ #include -#include + #include "br_private.h" static int br_device_event(struct notifier_block *unused, unsigned long event, void *ptr); diff -Nru a/net/bridge/br_stp.c b/net/bridge/br_stp.c --- a/net/bridge/br_stp.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_stp.c Tue Apr 13 14:44:58 2004 @@ -13,9 +13,8 @@ * 2 of the License, or (at your option) any later version. */ #include -#include #include -#include + #include "br_private.h" #include "br_private_stp.h" diff -Nru a/net/bridge/br_stp_bpdu.c b/net/bridge/br_stp_bpdu.c --- a/net/bridge/br_stp_bpdu.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_stp_bpdu.c Tue Apr 13 14:44:58 2004 @@ -14,9 +14,8 @@ */ #include -#include -#include #include + #include "br_private.h" #include "br_private_stp.h" diff -Nru a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c --- a/net/bridge/br_stp_if.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_stp_if.c Tue Apr 13 14:44:58 2004 @@ -14,9 +14,8 @@ */ #include -#include #include -#include + #include "br_private.h" #include "br_private_stp.h" diff -Nru a/net/bridge/br_stp_timer.c b/net/bridge/br_stp_timer.c --- a/net/bridge/br_stp_timer.c Tue Apr 13 14:44:58 2004 +++ b/net/bridge/br_stp_timer.c Tue Apr 13 14:44:58 2004 @@ -14,9 +14,8 @@ */ #include -#include #include -#include + #include "br_private.h" #include "br_private_stp.h" From shemminger@osdl.org Tue Apr 13 15:18:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:19:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMIxKO019201 for ; Tue, 13 Apr 2004 15:18:59 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMIl206614; Tue, 13 Apr 2004 15:18:47 -0700 Date: Tue, 13 Apr 2004 15:18:47 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (2/9) bridge - rmmod race Message-Id: <20040413151847.50c62126@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4644 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: 733 Lines: 29 Fix observed race between removing bridge module and ip packets in flight. Need to remove the hook last, after all bridges are gone not the other way around. diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c Mon Apr 12 16:09:56 2004 +++ b/net/bridge/br.c Mon Apr 12 16:09:56 2004 @@ -54,16 +54,17 @@ #endif unregister_netdevice_notifier(&br_device_notifier); brioctl_set(NULL); - br_handle_frame_hook = NULL; + + br_cleanup_bridges(); + + synchronize_net(); #if defined(CONFIG_ATM_LANE) || defined(CONFIG_ATM_LANE_MODULE) br_fdb_get_hook = NULL; br_fdb_put_hook = NULL; #endif - br_cleanup_bridges(); - - synchronize_net(); + br_handle_frame_hook = NULL; } EXPORT_SYMBOL(br_should_route_hook); From shemminger@osdl.org Tue Apr 13 15:20:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:21:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMKmKO019573 for ; Tue, 13 Apr 2004 15:20:49 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMKb206992; Tue, 13 Apr 2004 15:20:37 -0700 Date: Tue, 13 Apr 2004 15:20:37 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (3/9) bridge - jiffies_to_clock Message-Id: <20040413152037.5e28054d@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4645 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: 3873 Lines: 114 Rather than doing the math directly, use jiffies_to_clock functions to convert from user hz to jiffies. diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c Mon Apr 12 16:10:09 2004 +++ b/net/bridge/br_fdb.c Mon Apr 12 16:10:09 2004 @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include "br_private.h" @@ -48,7 +49,7 @@ ent->compat_port_no = ent->port_no; ent->is_local = f->is_local; ent->ageing_timer_value = f->is_static ? 0 - : ((jiffies - f->ageing_timer) * USER_HZ) / HZ; + : jiffies_to_clock_t(jiffies - f->ageing_timer); } static __inline__ int br_mac_hash(const unsigned char *mac) diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Mon Apr 12 16:10:09 2004 +++ b/net/bridge/br_ioctl.c Mon Apr 12 16:10:09 2004 @@ -16,26 +16,15 @@ #include #include #include +#include #include #include "br_private.h" -/* import values in USER_HZ */ -static inline unsigned long user_to_ticks(unsigned long utick) -{ - return (utick * HZ) / USER_HZ; -} - -/* export values in USER_HZ */ -static inline unsigned long ticks_to_user(unsigned long tick) -{ - return (tick * USER_HZ) / HZ; -} - /* Report time remaining in user HZ */ static unsigned long timer_residue(const struct timer_list *timer) { - return ticks_to_user(timer_pending(timer) - ? (timer->expires - jiffies) : 0); + return timer_pending(timer) + ? jiffies_to_clock_t(timer->expires - jiffies) : 0; } int br_ioctl_device(struct net_bridge *br, unsigned int cmd, @@ -79,17 +68,17 @@ memcpy(&b.designated_root, &br->designated_root, 8); memcpy(&b.bridge_id, &br->bridge_id, 8); b.root_path_cost = br->root_path_cost; - b.max_age = ticks_to_user(br->max_age); - b.hello_time = ticks_to_user(br->hello_time); + b.max_age = jiffies_to_clock_t(br->max_age); + b.hello_time = jiffies_to_clock_t(br->hello_time); b.forward_delay = br->forward_delay; b.bridge_max_age = br->bridge_max_age; b.bridge_hello_time = br->bridge_hello_time; - b.bridge_forward_delay = ticks_to_user(br->bridge_forward_delay); + b.bridge_forward_delay = jiffies_to_clock_t(br->bridge_forward_delay); b.topology_change = br->topology_change; b.topology_change_detected = br->topology_change_detected; b.root_port = br->root_port; b.stp_enabled = br->stp_enabled; - b.ageing_time = ticks_to_user(br->ageing_time); + b.ageing_time = jiffies_to_clock_t(br->ageing_time); b.hello_timer_value = timer_residue(&br->hello_timer); b.tcn_timer_value = timer_residue(&br->tcn_timer); b.topology_change_timer_value = timer_residue(&br->topology_change_timer); @@ -126,7 +115,7 @@ return -EPERM; spin_lock_bh(&br->lock); - br->bridge_forward_delay = user_to_ticks(arg0); + br->bridge_forward_delay = clock_t_to_jiffies(arg0); if (br_is_root_bridge(br)) br->forward_delay = br->bridge_forward_delay; spin_unlock_bh(&br->lock); @@ -137,7 +126,7 @@ return -EPERM; spin_lock_bh(&br->lock); - br->bridge_hello_time = user_to_ticks(arg0); + br->bridge_hello_time = clock_t_to_jiffies(arg0); if (br_is_root_bridge(br)) br->hello_time = br->bridge_hello_time; spin_unlock_bh(&br->lock); @@ -148,7 +137,7 @@ return -EPERM; spin_lock_bh(&br->lock); - br->bridge_max_age = user_to_ticks(arg0); + br->bridge_max_age = clock_t_to_jiffies(arg0); if (br_is_root_bridge(br)) br->max_age = br->bridge_max_age; spin_unlock_bh(&br->lock); @@ -158,7 +147,7 @@ if (!capable(CAP_NET_ADMIN)) return -EPERM; - br->ageing_time = user_to_ticks(arg0); + br->ageing_time = clock_t_to_jiffies(arg0); return 0; case BRCTL_GET_PORT_INFO: From shemminger@osdl.org Tue Apr 13 15:24:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:24:59 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMOrKO019920 for ; Tue, 13 Apr 2004 15:24:53 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMOe207329; Tue, 13 Apr 2004 15:24:40 -0700 Date: Tue, 13 Apr 2004 15:24:40 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (4/9) bridge - use ethtool to get port speed Message-Id: <20040413152440.7e410cd8@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4646 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: 5312 Lines: 222 The bridge code needs to keep track of a cost estimate for each port in the bridge. Instead of a hack based on device name, try and use ethtool to get port speed from device. This has been tested on e100 (uses ethtool_ops) and e1000 (does ethtool the hard way) and dummy (no ethtool). Need to export dev_ethtool() to allow bridge module to get to it easily. Code takes care to maintain same locking and semantics as if ioctl was being done from application. diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Mon Apr 12 16:10:23 2004 +++ b/net/bridge/br_if.c Mon Apr 12 16:10:23 2004 @@ -14,6 +14,8 @@ */ #include +#include +#include #include #include #include @@ -25,18 +27,55 @@ /* Limited to 256 ports because of STP protocol pdu */ #define BR_MAX_PORTS 256 +/* + * Determine initial path cost based on speed. + * using recommendations from 802.1d standard + * + * Need to simulate user ioctl because not all device's that support + * ethtool, use ethtool_ops. Also, since driver might sleep need to + * not be holding any locks. + */ static int br_initial_port_cost(struct net_device *dev) { + + struct ethtool_cmd ecmd = { ETHTOOL_GSET }; + struct ifreq ifr; + mm_segment_t old_fs; + int err; + + strncpy(ifr.ifr_name, dev->name, IFNAMSIZ); + ifr.ifr_data = (void *) &ecmd; + + old_fs = get_fs(); + set_fs(KERNEL_DS); + err = dev_ethtool(&ifr); + set_fs(old_fs); + + if (!err) { + switch(ecmd.speed) { + case SPEED_100: + return 19; + case SPEED_1000: + return 4; + case SPEED_10000: + return 2; + case SPEED_10: + return 100; + default: + pr_info("bridge: can't decode speed from %s: %d\n", + dev->name, ecmd.speed); + return 100; + } + } + + /* Old silly heuristics based on name */ if (!strncmp(dev->name, "lec", 3)) return 7; - if (!strncmp(dev->name, "eth", 3)) - return 100; /* FIXME handle 100Mbps */ - if (!strncmp(dev->name, "plip", 4)) return 2500; - return 100; + return 100; /* assume old 10Mbps */ } static void destroy_nbp(void *arg) @@ -147,7 +186,9 @@ } /* called under bridge lock */ -static struct net_bridge_port *new_nbp(struct net_bridge *br, struct net_device *dev) +static struct net_bridge_port *new_nbp(struct net_bridge *br, + struct net_device *dev, + unsigned long cost) { int index; struct net_bridge_port *p; @@ -162,16 +203,15 @@ memset(p, 0, sizeof(*p)); p->br = br; + dev_hold(dev); p->dev = dev; - p->path_cost = br_initial_port_cost(dev); + p->path_cost = cost; p->priority = 0x80; dev->br_port = p; p->port_no = index; br_init_port(p); p->state = BR_STATE_DISABLED; - list_add_rcu(&p->list, &br->port_list); - return p; } @@ -216,13 +256,11 @@ return ret; } -/* called under bridge lock */ int br_add_if(struct net_bridge *br, struct net_device *dev) { struct net_bridge_port *p; - - if (dev->br_port != NULL) - return -EBUSY; + unsigned long cost; + int err = 0; if (dev->flags & IFF_LOOPBACK || dev->type != ARPHRD_ETHER) return -EINVAL; @@ -230,34 +268,46 @@ if (dev->hard_start_xmit == br_dev_xmit) return -ELOOP; - dev_hold(dev); - p = new_nbp(br, dev); - if (IS_ERR(p)) { - dev_put(dev); - return PTR_ERR(p); - } + cost = br_initial_port_cost(dev); - dev_set_promiscuity(dev, 1); + spin_lock_bh(&br->lock); + if (dev->br_port != NULL) + err = -EBUSY; + + else if (IS_ERR(p = new_nbp(br, dev, cost))) + err = PTR_ERR(p); - br_stp_recalculate_bridge_id(br); - br_fdb_insert(br, p, dev->dev_addr, 1); - if ((br->dev->flags & IFF_UP) && (dev->flags & IFF_UP)) - br_stp_enable_port(p); + else { + dev_set_promiscuity(dev, 1); - return 0; + list_add_rcu(&p->list, &br->port_list); + + br_stp_recalculate_bridge_id(br); + br_fdb_insert(br, p, dev->dev_addr, 1); + if ((br->dev->flags & IFF_UP) && (dev->flags & IFF_UP)) + br_stp_enable_port(p); + + } + spin_unlock_bh(&br->lock); + return err; } -/* called under bridge lock */ int br_del_if(struct net_bridge *br, struct net_device *dev) { struct net_bridge_port *p; + int err = 0; - if ((p = dev->br_port) == NULL || p->br != br) - return -EINVAL; + spin_lock_bh(&br->lock); + p = dev->br_port; + if (!p || p->br != br) + err = -EINVAL; + else { + del_nbp(p); + br_stp_recalculate_bridge_id(br); + } + spin_unlock_bh(&br->lock); - del_nbp(p); - br_stp_recalculate_bridge_id(br); - return 0; + return err; } int br_get_bridge_ifindices(int *indices, int num) diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Mon Apr 12 16:10:23 2004 +++ b/net/bridge/br_ioctl.c Mon Apr 12 16:10:23 2004 @@ -48,12 +48,10 @@ if (dev == NULL) return -EINVAL; - spin_lock_bh(&br->lock); if (cmd == BRCTL_ADD_IF) ret = br_add_if(br, dev); else ret = br_del_if(br, dev); - spin_unlock_bh(&br->lock); dev_put(dev); return ret; diff -Nru a/net/core/ethtool.c b/net/core/ethtool.c --- a/net/core/ethtool.c Mon Apr 12 16:10:23 2004 +++ b/net/core/ethtool.c Mon Apr 12 16:10:23 2004 @@ -740,6 +740,7 @@ return -EOPNOTSUPP; } +EXPORT_SYMBOL(dev_ethtool); EXPORT_SYMBOL(ethtool_op_get_link); EXPORT_SYMBOL(ethtool_op_get_sg); EXPORT_SYMBOL(ethtool_op_get_tso); From shemminger@osdl.org Tue Apr 13 15:26:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:26:43 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMQVKO020241 for ; Tue, 13 Apr 2004 15:26:32 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMQK207710; Tue, 13 Apr 2004 15:26:20 -0700 Date: Tue, 13 Apr 2004 15:26:20 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (5/9) bridge - multicast address as const Message-Id: <20040413152620.2a0f0bd1@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4647 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: 1879 Lines: 58 Trivial change. For places where bridge multicast address is defined, or compared use constant. diff -Nru a/net/bridge/br_input.c b/net/bridge/br_input.c --- a/net/bridge/br_input.c Mon Apr 12 16:10:36 2004 +++ b/net/bridge/br_input.c Mon Apr 12 16:10:36 2004 @@ -19,7 +19,7 @@ #include #include "br_private.h" -unsigned char bridge_ula[6] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 }; +const unsigned char bridge_ula[6] = { 0x01, 0x80, 0xc2, 0x00, 0x00, 0x00 }; static int br_pass_frame_up_finish(struct sk_buff *skb) { diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Mon Apr 12 16:10:36 2004 +++ b/net/bridge/br_private.h Mon Apr 12 16:10:36 2004 @@ -111,7 +111,7 @@ }; extern struct notifier_block br_device_notifier; -extern unsigned char bridge_ula[6]; +extern const unsigned char bridge_ula[6]; /* called under bridge lock */ static inline int br_is_root_bridge(const struct net_bridge *br) diff -Nru a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c --- a/net/bridge/br_stp_if.c Mon Apr 12 16:10:36 2004 +++ b/net/bridge/br_stp_if.c Mon Apr 12 16:10:36 2004 @@ -110,7 +110,8 @@ } /* called under bridge lock */ -static void br_stp_change_bridge_id(struct net_bridge *br, unsigned char *addr) +static void br_stp_change_bridge_id(struct net_bridge *br, + const unsigned char *addr) { unsigned char oldaddr[6]; struct net_bridge_port *p; @@ -137,15 +138,13 @@ br_become_root_bridge(br); } -static unsigned char br_mac_zero[6]; +static const unsigned char br_mac_zero[6]; /* called under bridge lock */ void br_stp_recalculate_bridge_id(struct net_bridge *br) { - unsigned char *addr; + const unsigned char *addr = br_mac_zero; struct net_bridge_port *p; - - addr = br_mac_zero; list_for_each_entry(p, &br->port_list, list) { if (addr == br_mac_zero || From shemminger@osdl.org Tue Apr 13 15:28:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:29:02 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMSoKO020583 for ; Tue, 13 Apr 2004 15:28:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMSc207955; Tue, 13 Apr 2004 15:28:38 -0700 Date: Tue, 13 Apr 2004 15:28:38 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (6/9) bridge - forwarding database changes Message-Id: <20040413152838.181eb743@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4648 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: 3374 Lines: 120 Make forwarding database more robust. + Don't insert invalid ether address, + Report errors back so adding an interface to bridge can fail + get rid of unneeded explicit pads in data structure + replace bitfields with byte's for simple booleans. diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c Mon Apr 12 16:10:50 2004 +++ b/net/bridge/br_fdb.c Mon Apr 12 16:10:50 2004 @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include "br_private.h" @@ -243,12 +244,16 @@ return num; } -void br_fdb_insert(struct net_bridge *br, struct net_bridge_port *source, - const unsigned char *addr, int is_local) +int br_fdb_insert(struct net_bridge *br, struct net_bridge_port *source, + const unsigned char *addr, int is_local) { struct hlist_node *h; struct net_bridge_fdb_entry *fdb; int hash = br_mac_hash(addr); + int ret = 0; + + if (!is_valid_ether_addr(addr)) + return -EADDRNOTAVAIL; write_lock_bh(&br->hash_lock); hlist_for_each(h, &br->hash[hash]) { @@ -264,6 +269,7 @@ printk(KERN_WARNING "%s: received packet with " " own address as source address\n", source->dev->name); + ret = -EEXIST; goto out; } @@ -278,8 +284,10 @@ } fdb = kmalloc(sizeof(*fdb), GFP_ATOMIC); - if (fdb == NULL) + if (unlikely(fdb == NULL)) { + ret = -ENOMEM; goto out; + } memcpy(fdb->addr.addr, addr, ETH_ALEN); atomic_set(&fdb->use_count, 1); @@ -298,4 +306,6 @@ list_add_tail(&fdb->age_list, &br->age_list); out: write_unlock_bh(&br->hash_lock); + + return ret; } diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Mon Apr 12 16:10:50 2004 +++ b/net/bridge/br_if.c Mon Apr 12 16:10:50 2004 @@ -277,13 +277,15 @@ else if (IS_ERR(p = new_nbp(br, dev, cost))) err = PTR_ERR(p); + else if ((err = br_fdb_insert(br, p, dev->dev_addr, 1))) + destroy_nbp(p); + else { dev_set_promiscuity(dev, 1); list_add_rcu(&p->list, &br->port_list); br_stp_recalculate_bridge_id(br); - br_fdb_insert(br, p, dev->dev_addr, 1); if ((br->dev->flags & IFF_UP) && (dev->flags & IFF_UP)) br_stp_enable_port(p); diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Mon Apr 12 16:10:50 2004 +++ b/net/bridge/br_private.h Mon Apr 12 16:10:50 2004 @@ -37,7 +37,6 @@ struct mac_addr { unsigned char addr[6]; - unsigned char pad[2]; }; struct net_bridge_fdb_entry @@ -48,8 +47,8 @@ atomic_t use_count; unsigned long ageing_timer; mac_addr addr; - unsigned is_local:1; - unsigned is_static:1; + unsigned char is_local; + unsigned char is_static; }; struct net_bridge_port @@ -135,10 +134,10 @@ extern void br_fdb_put(struct net_bridge_fdb_entry *ent); extern int br_fdb_get_entries(struct net_bridge *br, void __user *buf, int maxnum, int offset); -extern void br_fdb_insert(struct net_bridge *br, - struct net_bridge_port *source, - const unsigned char *addr, - int is_local); +extern int br_fdb_insert(struct net_bridge *br, + struct net_bridge_port *source, + const unsigned char *addr, + int is_local); /* br_forward.c */ extern void br_deliver(const struct net_bridge_port *to, From shemminger@osdl.org Tue Apr 13 15:31:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:31:12 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMV0KO020913 for ; Tue, 13 Apr 2004 15:31:00 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMUk208232; Tue, 13 Apr 2004 15:30:46 -0700 Date: Tue, 13 Apr 2004 15:30:46 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (7/9) bridge - STP unsigned fields Message-Id: <20040413153046.4f47fe0f@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4649 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: 4711 Lines: 162 Use correct types for fields related to spanning tree protocols. * costs are 32 bit unsigned * ports are 16 bit unsigned * booleans are bytes rather than bitfield * arrange for better packing diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Mon Apr 12 16:11:03 2004 +++ b/net/bridge/br_private.h Mon Apr 12 16:11:03 2004 @@ -56,19 +56,19 @@ struct net_bridge *br; struct net_device *dev; struct list_head list; - __u8 port_no; - __u8 priority; /* STP */ + u8 priority; + u8 state; + u16 port_no; + unsigned char topology_change_ack; + unsigned char config_pending; port_id port_id; - int state; - int path_cost; + port_id designated_port; bridge_id designated_root; - int designated_cost; bridge_id designated_bridge; - port_id designated_port; - unsigned topology_change_ack:1; - unsigned config_pending:1; + u32 path_cost; + u32 designated_cost; struct timer_list forward_delay_timer; struct timer_list hold_timer; @@ -88,25 +88,25 @@ /* STP */ bridge_id designated_root; - int root_path_cost; - int root_port; - int max_age; - int hello_time; - int forward_delay; bridge_id bridge_id; - int bridge_max_age; - int bridge_hello_time; - int bridge_forward_delay; - unsigned stp_enabled:1; - unsigned topology_change:1; - unsigned topology_change_detected:1; + u32 root_path_cost; + unsigned long max_age; + unsigned long hello_time; + unsigned long forward_delay; + unsigned long bridge_max_age; + unsigned long ageing_time; + unsigned long bridge_hello_time; + unsigned long bridge_forward_delay; + + u16 root_port; + unsigned char stp_enabled; + unsigned char topology_change; + unsigned char topology_change_detected; struct timer_list hello_timer; struct timer_list tcn_timer; struct timer_list topology_change_timer; struct timer_list gc_timer; - - int ageing_time; }; extern struct notifier_block br_device_notifier; @@ -185,7 +185,7 @@ /* br_stp.c */ extern void br_log_state(const struct net_bridge_port *p); extern struct net_bridge_port *br_get_port(struct net_bridge *br, - int port_no); + u16 port_no); extern void br_init_port(struct net_bridge_port *p); extern void br_become_designated_port(struct net_bridge_port *p); @@ -196,11 +196,11 @@ extern void br_stp_disable_port(struct net_bridge_port *p); extern void br_stp_recalculate_bridge_id(struct net_bridge *br); extern void br_stp_set_bridge_priority(struct net_bridge *br, - int newprio); + u16 newprio); extern void br_stp_set_port_priority(struct net_bridge_port *p, - int newprio); + u8 newprio); extern void br_stp_set_path_cost(struct net_bridge_port *p, - int path_cost); + u32 path_cost); /* br_stp_bpdu.c */ extern int br_stp_handle_bpdu(struct sk_buff *skb); diff -Nru a/net/bridge/br_stp.c b/net/bridge/br_stp.c --- a/net/bridge/br_stp.c Mon Apr 12 16:11:03 2004 +++ b/net/bridge/br_stp.c Mon Apr 12 16:11:03 2004 @@ -35,7 +35,7 @@ } /* called under bridge lock */ -struct net_bridge_port *br_get_port(struct net_bridge *br, int port_no) +struct net_bridge_port *br_get_port(struct net_bridge *br, u16 port_no) { struct net_bridge_port *p; @@ -49,7 +49,7 @@ /* called under bridge lock */ static int br_should_become_root_port(const struct net_bridge_port *p, - int root_port) + u16 root_port) { struct net_bridge *br; struct net_bridge_port *rp; @@ -102,9 +102,7 @@ static void br_root_selection(struct net_bridge *br) { struct net_bridge_port *p; - int root_port; - - root_port = 0; + u16 root_port = 0; list_for_each_entry(p, &br->port_list, list) { if (br_should_become_root_port(p, root_port)) diff -Nru a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c --- a/net/bridge/br_stp_if.c Mon Apr 12 16:11:03 2004 +++ b/net/bridge/br_stp_if.c Mon Apr 12 16:11:03 2004 @@ -158,7 +158,7 @@ } /* called under bridge lock */ -void br_stp_set_bridge_priority(struct net_bridge *br, int newprio) +void br_stp_set_bridge_priority(struct net_bridge *br, u16 newprio) { struct net_bridge_port *p; int wasroot; @@ -183,7 +183,7 @@ } /* called under bridge lock */ -void br_stp_set_port_priority(struct net_bridge_port *p, int newprio) +void br_stp_set_port_priority(struct net_bridge_port *p, u8 newprio) { __u16 new_port_id; @@ -202,7 +202,7 @@ } /* called under bridge lock */ -void br_stp_set_path_cost(struct net_bridge_port *p, int path_cost) +void br_stp_set_path_cost(struct net_bridge_port *p, u32 path_cost) { p->path_cost = path_cost; br_configuration_update(p->br); From shemminger@osdl.org Tue Apr 13 15:33:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:33:32 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMXKKO021251 for ; Tue, 13 Apr 2004 15:33:20 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMX8209393; Tue, 13 Apr 2004 15:33:08 -0700 Date: Tue, 13 Apr 2004 15:33:08 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (8/9) bridge - support lots of 1k ports Message-Id: <20040413153308.6e0dd462@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4650 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: 4669 Lines: 176 Support >256 ports on a bridge. Use the suggestion of reducing the number of bits of priority and increasing the number of bits for port number. Easy to increase to even larger if necessary. diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Tue Apr 13 13:16:56 2004 +++ b/net/bridge/br_if.c Tue Apr 13 13:16:56 2004 @@ -24,9 +24,6 @@ #include "br_private.h" -/* Limited to 256 ports because of STP protocol pdu */ -#define BR_MAX_PORTS 256 - /* * Determine initial path cost based on speed. * using recommendations from 802.1d standard @@ -166,23 +163,27 @@ return br; } -static int free_port(struct net_bridge *br) +/* find an available port number */ +static int find_portno(struct net_bridge *br) { int index; struct net_bridge_port *p; - long inuse[BR_MAX_PORTS/(sizeof(long)*8)]; + unsigned long *inuse; + + inuse = kmalloc(BITS_TO_LONGS(BR_MAX_PORTS)*sizeof(unsigned long), + GFP_ATOMIC); + if (!inuse) + return -ENOMEM; - /* find free port number */ - memset(inuse, 0, sizeof(inuse)); + CLEAR_BITMAP(inuse, BR_MAX_PORTS); + set_bit(0, inuse); /* zero is reserved */ list_for_each_entry(p, &br->port_list, list) { set_bit(p->port_no, inuse); } - index = find_first_zero_bit(inuse, BR_MAX_PORTS); - if (index >= BR_MAX_PORTS) - return -EXFULL; + kfree(inuse); - return index; + return (index >= BR_MAX_PORTS) ? -EXFULL : index; } /* called under bridge lock */ @@ -193,7 +194,7 @@ int index; struct net_bridge_port *p; - index = free_port(br); + index = find_portno(br); if (index < 0) return ERR_PTR(index); @@ -206,7 +207,7 @@ dev_hold(dev); p->dev = dev; p->path_cost = cost; - p->priority = 0x80; + p->priority = 0x8000 >> BR_PORT_BITS; dev->br_port = p; p->port_no = index; br_init_port(p); diff -Nru a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c --- a/net/bridge/br_ioctl.c Tue Apr 13 13:16:56 2004 +++ b/net/bridge/br_ioctl.c Tue Apr 13 13:16:56 2004 @@ -91,9 +91,15 @@ case BRCTL_GET_PORT_LIST: { - int num = arg1 ? arg1 : 256; /* compatiablity */ - int ret = 0; - int *indices; + int num, *indices; + + num = arg1; + if (num < 0) + return -EINVAL; + if (num == 0) + num = 256; + if (num > BR_MAX_PORTS) + num = BR_MAX_PORTS; indices = kmalloc(num*sizeof(int), GFP_KERNEL); if (indices == NULL) @@ -103,9 +109,9 @@ br_get_port_ifindices(br, indices, num); if (copy_to_user((void *)arg0, indices, num*sizeof(int))) - ret = -EFAULT; + num = -EFAULT; kfree(indices); - return ret; + return num; } case BRCTL_SET_BRIDGE_FORWARD_DELAY: @@ -204,6 +210,9 @@ if (!capable(CAP_NET_ADMIN)) return -EPERM; + + if (arg1 >= (1<<(16-BR_PORT_BITS))) + return -ERANGE; spin_lock_bh(&br->lock); if ((p = br_get_port(br, arg0)) == NULL) diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Tue Apr 13 13:16:56 2004 +++ b/net/bridge/br_private.h Tue Apr 13 13:16:56 2004 @@ -24,6 +24,9 @@ #define BR_HOLD_TIME (1*HZ) +#define BR_PORT_BITS 10 +#define BR_MAX_PORTS (1<priority << 8) | p->port_no; + return ((u16)priority << BR_PORT_BITS) + | (port_no & ((1<port_id = br_make_port_id(p); + p->port_id = br_make_port_id(p->priority, p->port_no); br_become_designated_port(p); p->state = BR_STATE_BLOCKING; p->topology_change_ack = 0; @@ -185,15 +191,13 @@ /* called under bridge lock */ void br_stp_set_port_priority(struct net_bridge_port *p, u8 newprio) { - __u16 new_port_id; - - p->priority = newprio & 0xFF; - new_port_id = br_make_port_id(p); + port_id new_port_id = br_make_port_id(newprio, p->port_no); if (br_is_designated_port(p)) p->designated_port = new_port_id; p->port_id = new_port_id; + p->priority = newprio; if (!memcmp(&p->br->bridge_id, &p->designated_bridge, 8) && p->port_id < p->designated_port) { br_become_designated_port(p); From shemminger@osdl.org Tue Apr 13 15:35:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 15:35:17 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DMZ5KO021587 for ; Tue, 13 Apr 2004 15:35:05 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3DMYr209581; Tue, 13 Apr 2004 15:34:53 -0700 Date: Tue, 13 Apr 2004 15:34:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] (9/9) bridge - fdb cache alloc Message-Id: <20040413153453.4765b26a@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4651 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: 2616 Lines: 97 Since forwarding database gets a lot of memory alloc/free on a busy bridge, use kmem_cache_alloc to provide cache and better stats. diff -Nru a/net/bridge/br.c b/net/bridge/br.c --- a/net/bridge/br.c Tue Apr 13 13:17:16 2004 +++ b/net/bridge/br.c Tue Apr 13 13:17:16 2004 @@ -31,6 +31,8 @@ static int __init br_init(void) { + br_fdb_init(); + #ifdef CONFIG_BRIDGE_NETFILTER if (br_netfilter_init()) return 1; @@ -65,6 +67,7 @@ #endif br_handle_frame_hook = NULL; + br_fdb_fini(); } EXPORT_SYMBOL(br_should_route_hook); diff -Nru a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c --- a/net/bridge/br_fdb.c Tue Apr 13 13:17:16 2004 +++ b/net/bridge/br_fdb.c Tue Apr 13 13:17:16 2004 @@ -22,6 +22,22 @@ #include #include "br_private.h" +static kmem_cache_t *br_fdb_cache; + +void __init br_fdb_init(void) +{ + br_fdb_cache = kmem_cache_create("bridge_fdb_cache", + sizeof(struct net_bridge_fdb_entry), + 0, + SLAB_HWCACHE_ALIGN, NULL, NULL); +} + +void __exit br_fdb_fini(void) +{ + kmem_cache_destroy(br_fdb_cache); +} + + /* if topology_changing then use forward_delay (default 15 sec) * otherwise keep longer (default 5 minutes) */ @@ -37,7 +53,7 @@ && time_before_eq(fdb->ageing_timer + hold_time(br), jiffies); } -static __inline__ void copy_fdb(struct __fdb_entry *ent, +static inline void copy_fdb(struct __fdb_entry *ent, const struct net_bridge_fdb_entry *f) { memset(ent, 0, sizeof(struct __fdb_entry)); @@ -180,7 +196,7 @@ void br_fdb_put(struct net_bridge_fdb_entry *ent) { if (atomic_dec_and_test(&ent->use_count)) - kfree(ent); + kmem_cache_free(br_fdb_cache, ent); } int br_fdb_get_entries(struct net_bridge *br, void __user *buf, @@ -224,7 +240,7 @@ /* entry was deleted during copy_to_user */ if (atomic_dec_and_test(&f->use_count)) { - kfree(f); + kmem_cache_free(br_fdb_cache, f); num = -EAGAIN; goto out; } @@ -283,7 +299,7 @@ } } - fdb = kmalloc(sizeof(*fdb), GFP_ATOMIC); + fdb = kmem_cache_alloc(br_fdb_cache, GFP_ATOMIC); if (unlikely(fdb == NULL)) { ret = -ENOMEM; goto out; diff -Nru a/net/bridge/br_private.h b/net/bridge/br_private.h --- a/net/bridge/br_private.h Tue Apr 13 13:17:16 2004 +++ b/net/bridge/br_private.h Tue Apr 13 13:17:16 2004 @@ -127,6 +127,8 @@ extern int br_dev_xmit(struct sk_buff *skb, struct net_device *dev); /* br_fdb.c */ +extern void br_fdb_init(void); +extern void br_fdb_fini(void); extern void br_fdb_changeaddr(struct net_bridge_port *p, const unsigned char *newaddr); extern void br_fdb_cleanup(unsigned long arg); From harisri@bigpond.com Tue Apr 13 16:41:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 13 Apr 2004 16:41:58 -0700 (PDT) Received: from gizmo01bw.bigpond.com (gizmo01bw.bigpond.com [144.140.70.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DNfeKO026255 for ; Tue, 13 Apr 2004 16:41:43 -0700 Received: (qmail 25590 invoked from network); 13 Apr 2004 23:36:11 -0000 Received: from unknown (HELO bwmam13.bigpond.com) (144.135.24.106) by gizmo01bw.bigpond.com with SMTP; 13 Apr 2004 23:36:11 -0000 Received: from 144.138.164.166 ([144.138.164.166]) by bwmam13.bigpond.com(MAM REL_3_4_2 192/40449251) with SMTP id 40449251; Wed, 14 Apr 2004 09:41:33 +1000 From: Srihari Vijayaraghavan To: Francois Romieu Subject: Re: [patch 0/3] 2.6.5-netdev2 - r8169 update Date: Wed, 14 Apr 2004 09:42:12 +1000 User-Agent: KMail/1.5.4 Cc: netdev@oss.sgi.com, Srihari Vijayaraghavan , Jeff Garzik References: <20040405235545.A20805@electric-eye.fr.zoreil.com> <20040407231332.A25021@electric-eye.fr.zoreil.com> In-Reply-To: <20040407231332.A25021@electric-eye.fr.zoreil.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404140942.12659.harisri@bigpond.com> X-archive-position: 4652 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: harisri@bigpond.com Precedence: bulk X-list: netdev Content-Length: 752 Lines: 27 Hello Francois, On Thursday 08 April 2004 07:13, Francois Romieu wrote: > The following serie of patches applies against 2.6.5 + 2.6.5-netdev2. > > - r8169-missing-static.patch > missing 'static' qualifiers. > > - r8169-irq-handler-status.patch > fix status code bogosity for the irq handler if the r8169 interrupt is > shared. > > - r8169-mod_timer.patch > missing "jiffies +" in mod_timer(). The link recovery code seems to work > again. > > An update of the patch against 2.6.5 for the whole driver is available for > testers at: > http://www.fr.zoreil.com/people/francois/misc/20040407-2.6.5-r8169.c-stable >.patch I have tested this under moderate network load on my Athlon 64 (2.6.5 64 bit kernel). It is working fine. Thanks Hari From degger@fhm.edu Wed Apr 14 00:18:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 00:18:53 -0700 (PDT) Received: from karin.de.interearth.com (dialin-145-254-075-204.arcor-ip.net [145.254.75.204]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E7IKKO007434 for ; Wed, 14 Apr 2004 00:18:22 -0700 Received: from [192.168.11.8] (lucy [192.168.11.8]) by karin.de.interearth.com (Postfix) with ESMTP id CB2B63EE4; Tue, 13 Apr 2004 23:09:54 +0200 (CEST) In-Reply-To: <407C31F4.9070800@pobox.com> References: <4072CD01.6070408@pobox.com> <407C31F4.9070800@pobox.com> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-9-504179173" Message-Id: Content-Transfer-Encoding: 7bit Cc: Linux Kernel , Andrew Morton , Netdev From: Daniel Egger Subject: Re: [NET] net driver updates Date: Tue, 13 Apr 2004 23:09:54 +0200 To: Jeff Garzik X-Pgp-Agent: GPGMail 1.0.1 (v33, 10.3) X-Mailer: Apple Mail (2.613) X-archive-position: 4654 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: degger@fhm.edu Precedence: bulk X-list: netdev Content-Length: 1327 Lines: 42 --Apple-Mail-9-504179173 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On 13.04.2004, at 20:31, Jeff Garzik wrote: > RTL8169 is a nice chipset, though. Robert Ollsson had some nice > pktgen numbers for it, IIRC. You gotta be kidding. I've not seen a single OS where this cheapass chipset was fast. It's always the last in line but maybe that's just because Realtek wrote the drivers themselves. :) 3Com/Marvell and Broadcom are much better though and I intend to try Intel, they are said to be the best. Servus, Daniel --Apple-Mail-9-504179173 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQHxXIjBkNMiD99JrAQLtFwgAhE3raUOTf8SEYY2NQO0n/upDX57RrcCU oewk2m0Tm2GSs2pmnygYj5juGdxm2TmvIS/BalGXGL+SjHXKrnv0MKQaeShMkO5+ WlQzLCASF0f2VfD2ajQvtODsgh38yIYaCYYHI7x3pvif3pgilASOvdGjNDaXtS4K u6KIBrCwzW9XOaNKBJq9VksbLRjRhNk7TZ07y5vi8N3ix6sA4Ftcm22MKH9r+Hkb c75HNJDLYZFVrrIBfZNE7rNMAHvFiE2b6qRRbEpgaF81SjuKLJUnedEsKnQ/69a7 k3HriPbkEMM2Ke/UO5xV4UZTBp9cxSstAkCmlS/l8pgettyrF9+ezQ== =n0IY -----END PGP SIGNATURE----- --Apple-Mail-9-504179173-- From praveen@india.hp.com Wed Apr 14 01:55:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 01:55:10 -0700 (PDT) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E8t4KO016913 for ; Wed, 14 Apr 2004 01:55:07 -0700 Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.42.231.12]) by atlrel8.hp.com (Postfix) with ESMTP id 1D08C1C00A69; Wed, 14 Apr 2004 04:55:02 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.9.3 (PHNE_25184)/8.9.3 SMKit7.02) id OAA03903; Wed, 14 Apr 2004 14:27:09 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200404140857.OAA03903@shilpa.india.hp.com> Subject: Re: zero window probes on linux (fwd) To: ak@suse.de Date: Wed, 14 Apr 2004 14:27:09 +0530 (IST) Cc: netdev@oss.sgi.com In-Reply-To: <20040413205035.447c925c.ak@suse.de> from Andi Kleen at Apr "13," 2004 "08:50:35" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4655 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: praveen@india.hp.com Precedence: bulk X-list: netdev Content-Length: 448 Lines: 15 > > This seems to be a bug. Has it been already fixed in later > > kernel versions or is this how it is intended to remain? > > iirc this was intentional. The RFC suggested method doesn't work when talking to > some stacks. > But that cannot be valid enough justification for doing something against RFC right? Is there anyone who is aware/confirm the reason/history? Is it the above reason mentioned by Andy? > -Andi From dlstevens@us.ibm.com Wed Apr 14 02:06:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 02:06:36 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E96SKO017558 for ; Wed, 14 Apr 2004 02:06:34 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3E96M0o712014; Wed, 14 Apr 2004 05:06:22 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3E96KbT050312; Wed, 14 Apr 2004 03:06:20 -0600 In-Reply-To: <20040414041731.GA2010@safenet-inc.com> To: Lauri Tarkkala Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] ip multicast, kernel 2.4.2*, 2.6.* X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 14 Apr 2004 02:06:17 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/14/2004 03:06:20, Serialize complete at 04/14/2004 03:06:20 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4656 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1759 Lines: 39 Lauri Tarkkala wrote on 04/13/2004 09:17:31 PM: > The reason for this processing (my guess), is that the inbound > (duplicate) packet will not be sent, unless the original > passes the netfilter hooks. This has the side-effect that netfilter > hooks have no way of detecting whether packets are intended to or are > going to be looped back. The looped-back packet will of course still go > through the inbound hooks. If a packet doesn't pass the outbound hooks, won't your patch still deliver it locally? Isn't that wrong? I think the reason it creates a duplicate is because there are two cases-- one to be sent to the interface and one to be delivered locally. The one going out the interface should pass the outbound checks (only) and the one delivered locally should pass (I think) first the outbound filter and then the inbound filter. Right? Whether a particular multicast packet should be looped back or not is not static-- it's determined by the sender (and different senders may have different IP_MULTICAST_LOOP settings for the same group on the same machine). So, there is no answer for netfilter that applies to all multicast packets or even for all for a particular . Under what circumstances does netfilter need to "detect whether packets are intended to or are going to be looped back?" > This is quite error-prone, both in terms of configuring policy for > netfilter modules, not to mention optimization and implementation. There > are also some cases that just can not be handled correctly. What does it break? Can you give an example? I'm not saying I disagree (or agree) with your patch yet-- haven't looked at it enough. Just trying to understand what it fixes. +-DLS From romieu@fr.zoreil.com Wed Apr 14 04:16:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 04:16:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EBGTKO001364 for ; Wed, 14 Apr 2004 04:16:30 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3EAD5uX020830; Wed, 14 Apr 2004 12:13:05 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3EAD4cU020829; Wed, 14 Apr 2004 12:13:04 +0200 Date: Wed, 14 Apr 2004 12:13:04 +0200 From: Francois Romieu To: Daniel Egger Cc: Jeff Garzik , Linux Kernel , Andrew Morton , Netdev Subject: Re: [NET] net driver updates Message-ID: <20040414121304.A20405@electric-eye.fr.zoreil.com> References: <4072CD01.6070408@pobox.com> <407C31F4.9070800@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from degger@fhm.edu on Tue, Apr 13, 2004 at 11:09:54PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4657 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 475 Lines: 17 Daniel Egger : > On 13.04.2004, at 20:31, Jeff Garzik wrote: > > > RTL8169 is a nice chipset, though. Robert Ollsson had some nice > > pktgen numbers for it, IIRC. > > You gotta be kidding. I've not seen a single OS where > this cheapass chipset was fast. It's always the last in > line but maybe that's just because Realtek wrote the > drivers themselves. :) http://oss.sgi.com/projects/netdev/archive/2003-11/msg00399.html Coming soon :o) -- Ueimor From ltarkkal@safenet-inc.com Wed Apr 14 04:16:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 04:16:52 -0700 (PDT) Received: from gonzo.vught.safenet-inc.com ([213.53.67.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EBGRKO001348 for ; Wed, 14 Apr 2004 04:16:28 -0700 Received: from tehdas ([172.30.4.70]) by gonzo.vught.safenet-inc.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 12:47:50 +0200 Received: from ltarkkal by tehdas with local (Exim 3.36 #1 (Debian)) id 1BDwsh-0007Ri-00; Thu, 15 Apr 2004 05:45:35 +0300 Date: Thu, 15 Apr 2004 05:45:35 +0300 From: Lauri Tarkkala To: David Stevens Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ip multicast, kernel 2.4.2*, 2.6.* Message-ID: <20040415024535.GA28612@safenet-inc.com> References: <20040414041731.GA2010@safenet-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-OriginalArrivalTime: 14 Apr 2004 10:47:50.0354 (UTC) FILETIME=[EE715320:01C4220D] X-archive-position: 4658 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ltarkkala@safenet-inc.com Precedence: bulk X-list: netdev Content-Length: 3065 Lines: 77 On Wed, Apr 14, 2004 at 02:06:17AM -0700, David Stevens wrote: > > The reason for this processing (my guess), is that the inbound > > (duplicate) packet will not be sent, unless the original > > passes the netfilter hooks. This has the side-effect that netfilter > > hooks have no way of detecting whether packets are intended to or are > > going to be looped back. The looped-back packet will of course still go > > through the inbound hooks. > > If a packet doesn't pass the outbound hooks, won't your patch still > deliver it locally? Isn't that wrong? This boils down to how one feels about the following questions. A) Should it be possible to send multicast packets through a netfilter module in such a manner that a local listener receives them, but the packet does not enter the network? B) Should A netfilter module know if the packet it is processing is destined for the network, or for the local stack? Personally I feel that the answer to question "B" should be YES. I do not feel so strongly about "A", but I think that should also be a YES. I do not see much breaking, if a multicast packet is sent to the local stack even if it the network-bound packet was dropped by a packet filter. Note that even after my proposed patch is applied, having this style of behaviour is possible by putting proper processing in the inbound hooks (drop similar multicast packets that have skb.type == PACKET_LOOPBACK set and that are not on the loopback interface). > I think the reason it creates a duplicate is because there are two > cases-- one to be sent to the interface and one to be delivered > locally. The one going out the interface should pass the outbound > checks (only) and the one delivered locally should pass (I think) > first the outbound filter and then the inbound filter. Right? This is my interpretation also. > Under what circumstances does netfilter need to "detect whether packets > are intended to or are going to be looped back?" Well, for one thing a module can use (in the outbound case) in a netfilter hook the "skb->dev->flags & IFF_LOOPBACK" case to detect whether we are on the loopback stack. > > This is quite error-prone, both in terms of configuring policy for > > netfilter modules, not to mention optimization and implementation. There > > are also some cases that just can not be handled correctly. > > What does it break? Can you give an example? Trivial case: + Statistics counter in netfilter module counting amount of packets sent out via an interface through the module. More complicated case: + Netfilter module has a policy of not allowing multicast packets to the network, but would like them to be received by a listener bound to the same interface. If the module is actively manipulating the packet instead of just passively filtering, this can be a serious problem. Hypotethically: + Any case where the processing tries to factor into account the intended destination of the packet into the policy decision. Lauri -- Lauri Tarkkala Safenet Inc. http://www.safenet-inc.com/ From praveen@india.hp.com Wed Apr 14 05:03:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 05:03:31 -0700 (PDT) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EC3RKO011188 for ; Wed, 14 Apr 2004 05:03:27 -0700 Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.42.231.12]) by atlrel9.hp.com (Postfix) with ESMTP id D17221C01F7C; Wed, 14 Apr 2004 08:03:24 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.9.3 (PHNE_25184)/8.9.3 SMKit7.02) id RAA06111; Wed, 14 Apr 2004 17:35:33 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200404141205.RAA06111@shilpa.india.hp.com> Subject: Re: zero window probes on linux (fwd) To: ak@suse.de Date: Wed, 14 Apr 2004 17:35:33 +0530 (IST) Cc: netdev@oss.sgi.com In-Reply-To: <20040414134106.3f36c629.ak@suse.de> from Andi Kleen at Apr "14," 2004 "01:41:06" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4659 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: praveen@india.hp.com Precedence: bulk X-list: netdev Content-Length: 906 Lines: 28 Andi, > > > > This seems to be a bug. Has it been already fixed in later > > > > kernel versions or is this how it is intended to remain? > > > > > > iirc this was intentional. The RFC suggested method doesn't work when talking to > > > some stacks. > > > > > > > But that cannot be valid enough justification for doing > > something against RFC right? > > Of course it is. Welcome to the real world. RFC1122 has a lot of bugs and sometimes > does not describe really implemented practice (e.g. BSD set the defacto standard > in many behaviours and it does not always follow 1122) So do u consider mandating definition of zero-window probes as defined in RFC793 as a bug in RFC1122? Or else r u saying this bug is introduced in linux to take care of faulty stacks existing in the world. zero-window probes as defined in RFC1122 is not buggy right? -Praveen > > -Andi > From ak@suse.de Wed Apr 14 05:14:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 05:14:23 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ECEIKO011732 for ; Wed, 14 Apr 2004 05:14:18 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id BFB04455686; Wed, 14 Apr 2004 14:10:11 +0200 (CEST) Date: Wed, 14 Apr 2004 14:10:10 +0200 From: Andi Kleen To: Praveen Kumar Amritaluru Cc: netdev@oss.sgi.com Subject: Re: zero window probes on linux (fwd) Message-Id: <20040414141010.267a6204.ak@suse.de> In-Reply-To: <200404141205.RAA06111@shilpa.india.hp.com> References: <20040414134106.3f36c629.ak@suse.de> <200404141205.RAA06111@shilpa.india.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4660 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 1280 Lines: 32 On Wed, 14 Apr 2004 17:35:33 +0530 (IST) Praveen Kumar Amritaluru wrote: > > > > > This seems to be a bug. Has it been already fixed in later > > > > > kernel versions or is this how it is intended to remain? > > > > > > > > iirc this was intentional. The RFC suggested method doesn't work when talking to > > > > some stacks. > > > > > > > > > > But that cannot be valid enough justification for doing > > > something against RFC right? > > > > Of course it is. Welcome to the real world. RFC1122 has a lot of bugs and sometimes > > does not describe really implemented practice (e.g. BSD set the defacto standard > > in many behaviours and it does not always follow 1122) > > So do u consider mandating definition of zero-window probes as defined > in RFC793 as a bug in RFC1122? They are not directly a bug, but are just not what the world standardized on. > Or else r u saying this bug is introduced in linux to take care of > faulty stacks existing in the world. zero-window probes as defined > in RFC1122 is not buggy right? Implementing a production network stack is not about following some standard to the letter, but about interoperating with real implementations in a useful matter. Linux does that. -Andi From praveen@india.hp.com Wed Apr 14 05:24:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 05:24:19 -0700 (PDT) Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ECO8KO012286 for ; Wed, 14 Apr 2004 05:24:08 -0700 Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.42.231.12]) by atlrel9.hp.com (Postfix) with ESMTP id 3D4FB1C0152E; Wed, 14 Apr 2004 08:24:06 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.9.3 (PHNE_25184)/8.9.3 SMKit7.02) id RAA06400; Wed, 14 Apr 2004 17:56:14 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200404141226.RAA06400@shilpa.india.hp.com> Subject: Re: zero window probes on linux (fwd) To: ak@suse.de Date: Wed, 14 Apr 2004 17:56:14 +0530 (IST) Cc: netdev@oss.sgi.com In-Reply-To: <20040414141010.267a6204.ak@suse.de> from Andi Kleen at Apr "14," 2004 "02:10:10" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4661 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: praveen@india.hp.com Precedence: bulk X-list: netdev Content-Length: 1399 Lines: 35 > > > > > > This seems to be a bug. Has it been already fixed in later > > > > > > kernel versions or is this how it is intended to remain? > > > > > > > > > > iirc this was intentional. The RFC suggested method doesn't work when talking to > > > > > some stacks. > > > > > > > > > > > > > But that cannot be valid enough justification for doing > > > > something against RFC right? > > > > > > Of course it is. Welcome to the real world. RFC1122 has a lot of bugs and sometimes > > > does not describe really implemented practice (e.g. BSD set the defacto standard > > > in many behaviours and it does not always follow 1122) > > > > So do u consider mandating definition of zero-window probes as defined > > in RFC793 as a bug in RFC1122? > > They are not directly a bug, but are just not what the world standardized on. Are u aware of other production network stacks sending unacceptable segment as a zero-window probe? Can you list them. This is just for my information. > > > > Or else r u saying this bug is introduced in linux to take care of > > faulty stacks existing in the world. zero-window probes as defined > > in RFC1122 is not buggy right? > > Implementing a production network stack is not about following some standard to the > letter, but about interoperating with real implementations in a useful matter. > Linux does that. > > -Andi From ak@suse.de Wed Apr 14 05:27:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 05:27:28 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ECRFKO012616 for ; Wed, 14 Apr 2004 05:27:15 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 7B112455AFA; Wed, 14 Apr 2004 13:41:07 +0200 (CEST) Date: Wed, 14 Apr 2004 13:41:06 +0200 From: Andi Kleen To: Praveen Kumar Amritaluru Cc: netdev@oss.sgi.com Subject: Re: zero window probes on linux (fwd) Message-Id: <20040414134106.3f36c629.ak@suse.de> In-Reply-To: <200404140857.OAA03903@shilpa.india.hp.com> References: <20040413205035.447c925c.ak@suse.de> <200404140857.OAA03903@shilpa.india.hp.com> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4662 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: netdev Content-Length: 678 Lines: 18 On Wed, 14 Apr 2004 14:27:09 +0530 (IST) Praveen Kumar Amritaluru wrote: > > > This seems to be a bug. Has it been already fixed in later > > > kernel versions or is this how it is intended to remain? > > > > iirc this was intentional. The RFC suggested method doesn't work when talking to > > some stacks. > > > > But that cannot be valid enough justification for doing > something against RFC right? Of course it is. Welcome to the real world. RFC1122 has a lot of bugs and sometimes does not describe really implemented practice (e.g. BSD set the defacto standard in many behaviours and it does not always follow 1122) -Andi From okir@suse.de Wed Apr 14 07:22:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 07:22:31 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EEMGKO029439 for ; Wed, 14 Apr 2004 07:22:17 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 1D6334574FD; Wed, 14 Apr 2004 15:41:49 +0200 (CEST) Date: Wed, 14 Apr 2004 15:41:48 +0200 From: Olaf Kirch To: netdev@oss.sgi.com Cc: lksctp-developers@lists.sourceforge.net Subject: [PATCH] Propagate error from sctp_proc_init Message-ID: <20040414134148.GC16591@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 4664 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 1014 Lines: 41 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline The following patch makes sure that an error in sctp_proc_init() causes module initialization to fail. Olaf -- Olaf Kirch | The Hardware Gods hate me. okir@suse.de | ---------------+ --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename=sctp-initfail --- linux-2.6.4/net/sctp/protocol.c.initfail 2004-02-19 11:36:37.000000000 +0100 +++ linux-2.6.4/net/sctp/protocol.c 2004-04-14 15:36:19.000000000 +0200 @@ -1001,7 +1001,9 @@ goto err_init_mibs; /* Initialize proc fs directory. */ - sctp_proc_init(); + status = sctp_proc_init(); + if (status) + goto err_init_proc; /* Initialize object count debugging. */ sctp_dbg_objcnt_init(); @@ -1165,6 +1167,7 @@ sizeof(struct sctp_hashbucket))); err_ahash_alloc: sctp_dbg_objcnt_exit(); +err_init_proc: sctp_proc_exit(); cleanup_sctp_mibs(); err_init_mibs: --OXfL5xGRrasGEqWY-- From oxymoron@waste.org Wed Apr 14 11:46:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 11:47:01 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EIksKO006926 for ; Wed, 14 Apr 2004 11:46:57 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3EIkiDM019527; Wed, 14 Apr 2004 13:46:44 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i3EIkhka019523; Wed, 14 Apr 2004 13:46:43 -0500 Date: Wed, 14 Apr 2004 13:46:42 -0500 From: Matt Mackall To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [patch] tg3 ring buffer allocation error handling Message-ID: <20040414184642.GZ1175@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 4665 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1786 Lines: 67 tg3 - handle ring buffer allocation failure Try to allocate rx ring buffer and properly clean up and exit on failure. tiny-mpm/drivers/net/tg3.c | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff -puN drivers/net/tg3.c~tg3-oops drivers/net/tg3.c --- tiny/drivers/net/tg3.c~tg3-oops 2004-03-20 20:08:42.000000000 -0600 +++ tiny-mpm/drivers/net/tg3.c 2004-03-20 20:08:42.000000000 -0600 @@ -3092,7 +3092,7 @@ static void tg3_free_rings(struct tg3 *t * end up in the driver. tp->{tx,}lock are held and thus * we may not sleep. */ -static void tg3_init_rings(struct tg3 *tp) +static int tg3_init_rings(struct tg3 *tp) { unsigned long start, end; u32 i; @@ -3151,18 +3151,23 @@ static void tg3_init_rings(struct tg3 *t /* Now allocate fresh SKBs for each rx ring. */ for (i = 0; i < tp->rx_pending; i++) { - if (tg3_alloc_rx_skb(tp, RXD_OPAQUE_RING_STD, - -1, i) < 0) - break; + if (tg3_alloc_rx_skb(tp, RXD_OPAQUE_RING_STD, -1, i) < 0) { + printk("tg3_alloc_rx_skb %d failed\n", i); + return -ENOMEM; + } } if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { for (i = 0; i < tp->rx_jumbo_pending; i++) { if (tg3_alloc_rx_skb(tp, RXD_OPAQUE_RING_JUMBO, - -1, i) < 0) - break; + -1, i) < 0) { + printk("tg3_alloc_rx_skb %d failed\n", i); + return -ENOMEM; + } } } + + return 0; } /* @@ -4557,7 +4562,9 @@ static int tg3_reset_hw(struct tg3 *tp) * can only do this after the hardware has been * successfully reset. */ - tg3_init_rings(tp); + err = tg3_init_rings(tp); + if (err) + return err; /* This value is determined during the probe time DMA * engine test, tg3_test_dma. _ -- Matt Mackall : http://www.selenic.com : Linux development and consulting From shemminger@osdl.org Wed Apr 14 12:04:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 12:04:52 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EJ4oKO007717 for ; Wed, 14 Apr 2004 12:04:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3EJ4Z219822; Wed, 14 Apr 2004 12:04:35 -0700 Date: Wed, 14 Apr 2004 12:04:34 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: [PATCH 2.6.5] bridge - replace CLEAR_BITMAP with memset Message-Id: <20040414120434.2029b567@dell_ss3.pdx.osdl.net> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4666 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: 503 Lines: 14 It looks like a recent patch to 2.6.5 got rid of CLEAR_BITMAP. diff -Nru a/net/bridge/br_if.c b/net/bridge/br_if.c --- a/net/bridge/br_if.c Wed Apr 14 12:01:21 2004 +++ b/net/bridge/br_if.c Wed Apr 14 12:01:21 2004 @@ -175,7 +175,7 @@ if (!inuse) return -ENOMEM; - CLEAR_BITMAP(inuse, BR_MAX_PORTS); + memset(inuse, 0, BITS_TO_LONGS(BR_MAX_PORTS)*sizeof(unsigned long)); set_bit(0, inuse); /* zero is reserved */ list_for_each_entry(p, &br->port_list, list) { set_bit(p->port_no, inuse); From sven@zion.homelinux.com Wed Apr 14 14:00:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 14:00:27 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EL06KO013713 for ; Wed, 14 Apr 2004 14:00:07 -0700 Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BDrUK-0004rp-00; Wed, 14 Apr 2004 23:00:04 +0200 Received: from [80.136.73.120] (helo=zion.homelinux.com) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BDrUK-0003JK-00; Wed, 14 Apr 2004 23:00:04 +0200 Received: from localhost (zion.homelinux.com [127.0.0.1]) by stage2.zion.homelinux.com (Postfix) with ESMTP id 254AA2C704; Wed, 14 Apr 2004 23:00:02 +0200 (CEST) Received: from zion.homelinux.com ([127.0.0.1]) by localhost (zion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20365-08; Wed, 14 Apr 2004 22:59:59 +0200 (CEST) Received: by zion.homelinux.com (Postfix, from userid 1022) id 43F542C705; Wed, 14 Apr 2004 22:59:59 +0200 (CEST) Date: Wed, 14 Apr 2004 22:59:59 +0200 From: Sven Schuster To: Matt Mackall Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [patch] tg3 ring buffer allocation error handling Message-ID: <20040414205959.GA22051@zion.homelinux.com> References: <20040414184642.GZ1175@waste.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: <20040414184642.GZ1175@waste.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new-20030616-p7 at zion.homelinux.com X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:38b5f051b8cd178556c5593940405c4a X-archive-position: 4667 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schuster.sven@gmx.de Precedence: bulk X-list: netdev Content-Length: 1186 Lines: 48 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2004 at 01:46:42PM -0500, Matt Mackall told us: > if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { > for (i =3D 0; i < tp->rx_jumbo_pending; i++) { > if (tg3_alloc_rx_skb(tp, RXD_OPAQUE_RING_JUMBO, > - -1, i) < 0) > - break; > + -1, i) < 0) { > + printk("tg3_alloc_rx_skb %d failed\n", i); > + return -ENOMEM; Please correct me if I'm wrong, but shouldn't the buffers from the=20 irst allocation (RXD_OPAQUE_RING_STD) be freed (maybe via=20 tg3_free_rings??) when we get an error here?? Sven > + } > } > } > + > + return 0; > } > =20 --=20 Linux zion 2.6.5 #1 Sun Apr 4 19:56:55 CEST 2004 i686 athlon i386 GNU/Linux 22:53:42 up 9 days, 23:37, 2 users, load average: 0.00, 0.00, 0.00 --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD4DBQFAfaZPo4FAdB2PneQRAg/vAJY271NoGQ+BQIq4LQaoLttZkXoHAJ4o+CkG N2Ni5uzqICLb1U9OZPmMEg== =i0cp -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From adq@lidskialf.net Wed Apr 14 14:37:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 14:37:27 -0700 (PDT) Received: from beyond.lidskialf.net (lidskialf.net [62.3.233.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ELbOKO021731 for ; Wed, 14 Apr 2004 14:37:25 -0700 Received: from monstrousfish (monstrousfish [172.16.1.2]) by beyond.lidskialf.net (Postfix) with ESMTP id 63BF926918; Wed, 14 Apr 2004 22:40:35 +0100 (BST) From: Andrew de Quincey To: Carl-Daniel Hailfinger Subject: Re: [Fwd: extra spinlocking in forcedeth 0.25] Date: Wed, 14 Apr 2004 22:37:20 +0100 User-Agent: KMail/1.6.1 References: <407D6ABE.7010503@gmx.net> In-Reply-To: <407D6ABE.7010503@gmx.net> Cc: Jeff Garzik , Manfred Spraul , netdev@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200404142237.20688.adq@lidskialf.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3ELbOKO021731 X-archive-position: 4668 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adq@lidskialf.net Precedence: bulk X-list: netdev Content-Length: 891 Lines: 29 On Wednesday 14 April 2004 17:45, you wrote: > Andrew, > > could you have a look at the attached mail regarding spinlocking in your > WOL patch for forcedeth? > In 0.23 -> 0.25 forcedeth diff I noticed this: > > +       case ETHTOOL_GWOL: > +       { > +               struct ethtool_wolinfo wolinfo; > +               memset(&wolinfo, 0, sizeof(wolinfo)); > +               wolinfo.supported = WAKE_MAGIC; > + > +               spin_lock_irq(&np->lock); > +               if (np->wolenabled) > +                       wolinfo.wolopts = WAKE_MAGIC; > +               spin_unlock_irq(&np->lock); > + > +               if (copy_to_user(useraddr, &wolinfo, sizeof(wolinfo))) > +                       return -EFAULT; > +               return 0; > +       } > > IMHO this pair of lock()/unlock() is not needed > and can be safely removed. Yeah, he's right. Absolutely no need for it there. From oxymoron@waste.org Wed Apr 14 14:45:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 14:45:40 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ELjWKO022178 for ; Wed, 14 Apr 2004 14:45:35 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3ELjCDM020054; Wed, 14 Apr 2004 16:45:12 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i3ELjAGV020050; Wed, 14 Apr 2004 16:45:10 -0500 Date: Wed, 14 Apr 2004 16:45:10 -0500 From: Matt Mackall To: Sven Schuster Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [patch] tg3 ring buffer allocation error handling Message-ID: <20040414214510.GH1175@waste.org> References: <20040414184642.GZ1175@waste.org> <20040414205959.GA22051@zion.homelinux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040414205959.GA22051@zion.homelinux.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 4669 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1001 Lines: 24 On Wed, Apr 14, 2004 at 10:59:59PM +0200, Sven Schuster wrote: > On Wed, Apr 14, 2004 at 01:46:42PM -0500, Matt Mackall told us: > > if (tp->tg3_flags & TG3_FLAG_JUMBO_ENABLE) { > > for (i = 0; i < tp->rx_jumbo_pending; i++) { > > if (tg3_alloc_rx_skb(tp, RXD_OPAQUE_RING_JUMBO, > > - -1, i) < 0) > > - break; > > + -1, i) < 0) { > > + printk("tg3_alloc_rx_skb %d failed\n", i); > > + return -ENOMEM; > > Please correct me if I'm wrong, but shouldn't the buffers from the > irst allocation (RXD_OPAQUE_RING_STD) be freed (maybe via > tg3_free_rings??) when we get an error here?? The buffers are freed in the module release path, which is invoked when we return failure here. Without this, we don't notice the allocation failure and instead blow up when we get traffic. FYI, I last tested this on a mem=4M box, where it was very obvious that the 1M of ring buffers weren't leaking. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From sven@zion.homelinux.com Wed Apr 14 15:03:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 15:03:05 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.189]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EM2xKO022742 for ; Wed, 14 Apr 2004 15:03:00 -0700 Received: from [212.227.126.162] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BDsTC-0006EG-00; Thu, 15 Apr 2004 00:02:58 +0200 Received: from [80.136.73.64] (helo=zion.homelinux.com) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BDsTC-0003AV-00; Thu, 15 Apr 2004 00:02:58 +0200 Received: from localhost (zion.homelinux.com [127.0.0.1]) by stage2.zion.homelinux.com (Postfix) with ESMTP id EE3422C708; Thu, 15 Apr 2004 00:02:56 +0200 (CEST) Received: from zion.homelinux.com ([127.0.0.1]) by localhost (zion [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24716-02; Thu, 15 Apr 2004 00:02:54 +0200 (CEST) Received: by zion.homelinux.com (Postfix, from userid 1022) id 9E5072C709; Thu, 15 Apr 2004 00:02:54 +0200 (CEST) Date: Thu, 15 Apr 2004 00:02:54 +0200 From: Sven Schuster To: Matt Mackall Cc: Jeff Garzik , netdev@oss.sgi.com Subject: Re: [patch] tg3 ring buffer allocation error handling Message-ID: <20040414220254.GA24974@zion.homelinux.com> References: <20040414184642.GZ1175@waste.org> <20040414205959.GA22051@zion.homelinux.com> <20040414214510.GH1175@waste.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <20040414214510.GH1175@waste.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new-20030616-p7 at zion.homelinux.com X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:38b5f051b8cd178556c5593940405c4a X-archive-position: 4670 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: schuster.sven@gmx.de Precedence: bulk X-list: netdev Content-Length: 1351 Lines: 45 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 14, 2004 at 04:45:10PM -0500, Matt Mackall told us: > > Please correct me if I'm wrong, but shouldn't the buffers from the=20 > > irst allocation (RXD_OPAQUE_RING_STD) be freed (maybe via=20 > > tg3_free_rings??) when we get an error here?? >=20 > The buffers are freed in the module release path, which is invoked > when we return failure here. Without this, we don't notice the > allocation failure and instead blow up when we get traffic. So thanks for correcting me :-) should have taken a closer look at the tg3 source. Sven >=20 > FYI, I last tested this on a mem=3D4M box, where it was very obvious > that the 1M of ring buffers weren't leaking. >=20 > --=20 > Matt Mackall : http://www.selenic.com : Linux development and consulting --=20 Linux zion 2.6.5 #1 Sun Apr 4 19:56:55 CEST 2004 i686 athlon i386 GNU/Linux 00:01:49 up 10 days, 45 min, 2 users, load average: 0.06, 0.05, 0.02 --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAfbUOo4FAdB2PneQRAtKvAJwNfiUfBoT9Q6OD9kCuAFv3GBnUNQCeJMfE xzfCMYMdQdvokJAojtkiYqQ= =gWm3 -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From sri@us.ibm.com Wed Apr 14 15:10:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 15:10:54 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EMAmKO023179 for ; Wed, 14 Apr 2004 15:10:48 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3EM9nAL512660; Wed, 14 Apr 2004 18:09:49 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3EM9lCQ095524; Wed, 14 Apr 2004 18:09:48 -0400 Date: Wed, 14 Apr 2004 15:09:47 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: Olaf Kirch cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [PATCH] Propagate error from sctp_proc_init In-Reply-To: <20040414134148.GC16591@suse.de> Message-ID: References: <20040414134148.GC16591@suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4671 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 968 Lines: 39 The patch looks fine. Dave, could you apply it both 2.6 and 2.4 trees. It should apply to both of them with a little fuzz. Thanks Sridhar On Wed, 14 Apr 2004, Olaf Kirch wrote: > The following patch makes sure that an error in sctp_proc_init() > causes module initialization to fail. > > Olaf > -- > Olaf Kirch | The Hardware Gods hate me. > okir@suse.de | > ---------------+ > --- linux-2.6.4/net/sctp/protocol.c.initfail 2004-02-19 11:36:37.000000000 +0100 +++ linux-2.6.4/net/sctp/protocol.c 2004-04-14 15:36:19.000000000 +0200 @@ -1001,7 +1001,9 @@ goto err_init_mibs; /* Initialize proc fs directory. */ - sctp_proc_init(); + status = sctp_proc_init(); + if (status) + goto err_init_proc; /* Initialize object count debugging. */ sctp_dbg_objcnt_init(); @@ -1165,6 +1167,7 @@ sizeof(struct sctp_hashbucket))); err_ahash_alloc: sctp_dbg_objcnt_exit(); +err_init_proc: sctp_proc_exit(); cleanup_sctp_mibs(); err_init_mibs: From yoshfuji@linux-ipv6.org Wed Apr 14 15:32:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 15:32:59 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EMWuKO023987 for ; Wed, 14 Apr 2004 15:32:57 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id C7CF633CA5; Thu, 15 Apr 2004 07:33:24 +0900 (JST) Date: Thu, 15 Apr 2004 07:33:24 +0900 (JST) Message-Id: <20040415.073324.44957072.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, yoshfuji@linux-ipv6.org Subject: [PATCH] MLDV2: Use IANA icmpv6 type for MLDv2 Report From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4672 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 759 Lines: 28 Hello. IANA has finally assigned an ICMPv6 type for MLDv2 Report. (See: ) Patch also applies to 2.4. Thanks. ===== include/linux/icmpv6.h 1.3 vs edited ===== --- 1.3/include/linux/icmpv6.h Wed Apr 16 17:45:42 2003 +++ edited/include/linux/icmpv6.h Thu Apr 15 07:30:09 2004 @@ -95,8 +95,7 @@ #define MLD2_ALLOW_NEW_SOURCES 5 #define MLD2_BLOCK_OLD_SOURCES 6 -/* this must be an IANA-assigned value; 206 for testing only */ -#define ICMPV6_MLD2_REPORT 206 +#define ICMPV6_MLD2_REPORT 143 #define MLD2_ALL_MCR_INIT { { { 0xff,0x02,0,0,0,0,0,0,0,0,0,0,0,0,0,0x16 } } } /* -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From scott.feldman@intel.com Wed Apr 14 22:01:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 14 Apr 2004 22:01:21 -0700 (PDT) Received: from hermes.py.intel.com (hermes.py.intel.com [146.152.216.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3F51IKO011072 for ; Wed, 14 Apr 2004 22:01:18 -0700 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i3F51CZT017201 for ; Thu, 15 Apr 2004 05:01:12 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i3F50wWH006788 for ; Thu, 15 Apr 2004 05:01:01 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004041421443915672 for ; Wed, 14 Apr 2004 21:44:39 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 14 Apr 2004 21:44:40 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: non-NAPI mode question netif_rx_schedule() Date: Wed, 14 Apr 2004 21:44:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: non-NAPI mode question netif_rx_schedule() Thread-Index: AcQipFmNmhX+/2X0SEGXqrv7V0LsEQ== From: "Feldman, Scott" To: X-OriginalArrivalTime: 15 Apr 2004 04:44:40.0008 (UTC) FILETIME=[5CCC2480:01C422A4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3F51IKO011072 X-archive-position: 4673 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 1249 Lines: 34 Hi, [oh-oh, look out, driver dude venturing outside his comfort zone] I'm looking at the kernel Rx path for non-NAPI, and it looks like we could leave work to do on a CPU's backlog queue and not schedule RX_SOFTIRQ on that CPU. Let's say we call netif_rx(skb) on CPU0. This will put the skb on the backlog queue and then call netif_rx_schedule(netdev) which checks if __LINK_STATE_RX_SCHED is not already set for that netdev. If it's not set, it'll set it and start RX_SOFTIRQ on CPU0. No problem so far. Now, let's say while RX_SOFTIRQ is running on CPU0, we get another hard interrupt (same netdev) but this time handled on CPU1. We call netif_rx to queue the skb on CPU1 backlog queue, then call netif_rx_schedule, but this time the check for __LINK_STATE_RX_SCHED fails because RX_SOFTIRQ is already running on CPU0. This means we've put work on the CPU1's backlog queue, but we don't start the RX_SOFTIRQ on CPU1. :-( So the work on CPU1's backlog queue is stuck. It'll get started if 1) we get another hard interrupt on CPU1, and 2) no other CPUs are running their RX_SOFTIRQ. This could cause unnecessary Rx packet ordering issues as well as potentially leaving work pending on a CPU for some time. What am I missing? -scott From jens.laas@data.slu.se Thu Apr 15 01:16:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 01:16:56 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3F8GnKO019652 for ; Thu, 15 Apr 2004 01:16:50 -0700 Received: from jlaas2.data.slu.se (jlaas2.data.slu.se [130.238.98.68]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i3F8GkNw031556; Thu, 15 Apr 2004 10:16:46 +0200 Date: Thu, 15 Apr 2004 10:16:46 +0200 (CEST) From: Jens Laas X-X-Sender: jensl@jlaas2.data.slu.se To: "Feldman, Scott" cc: netdev@oss.sgi.com Subject: Re: non-NAPI mode question netif_rx_schedule() In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mail1.slu.se id i3F8GkNw031556 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3F8GnKO019652 X-archive-position: 4677 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jens.laas@data.slu.se Precedence: bulk X-list: netdev Content-Length: 1257 Lines: 42 (04.04.14 kl.21:44) Feldman, Scott skrev följande till netdev@oss.sgi.com: > Hi, > this time the check for __LINK_STATE_RX_SCHED fails because RX_SOFTIRQ > is already running on CPU0. This means we've put work on the CPU1's > backlog queue, but we don't start the RX_SOFTIRQ on CPU1. :-( > > So the work on CPU1's backlog queue is stuck. It'll get started if 1) > we get another hard interrupt on CPU1, and 2) no other CPUs are running > their RX_SOFTIRQ. > > This could cause unnecessary Rx packet ordering issues as well as > potentially leaving work pending on a CPU for some time. > > What am I missing? __LINK_STATE_RX_SCHED is set on queue->backlog_dev not on the "real" netdev. The backlog_dev is per queue and thus per CPU. Cheers, Jens > > -scott > > > ----------------------------------------------------------------------- 'This mail automatically becomes portable when carried.' ----------------------------------------------------------------------- Jens Låås Email: jens.laas@data.slu.se Department of Computer Services, SLU Phone: +46 18 67 35 15 Vindbrovägen 1 P.O. Box 7079 S-750 07 Uppsala SWEDEN ----------------------------------------------------------------------- From andy.furniss@dsl.pipex.com Thu Apr 15 03:20:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 03:20:49 -0700 (PDT) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FAKWKO026982 for ; Thu, 15 Apr 2004 03:20:33 -0700 Received: from dsl.pipex.com (81-178-251-213.dsl.pipex.com [81.178.251.213]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 57ACA1C000BD for ; Thu, 15 Apr 2004 10:42:29 +0100 (BST) Message-ID: <407E5905.9070108@dsl.pipex.com> Date: Thu, 15 Apr 2004 10:42:29 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: IMQ / new Dummy device post. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4678 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1183 Lines: 28 >What am i looking for? >1) users and authors of IMQ to tell me if this achieves what IMQ >started >as. I have to say I DONT like the level of obstrutiveness from IMQ as >is >today. The code added by this is small (100 or less lines on top of >dummy) and doesnt touch any of the main core bits. >2) testing of the above by people who use IMQ >3) If someone has better ideas - i am not religious about keeping this; >but it certainly cant be the blasphemy that IMQ introduces I am just a user and would drop IMQ without hesitation for something you consider more elegant, but I am not sure whether or not dummy will do what I want. The only reason I use IMQ (+ NAT patch) is that I need to shape ingress (I know I can't shape it "properly" from the wrong end of the bottleneck without an intelligent app, but the ingress policer does not let me share local and forwarded bandwidth and is not fair per user if I just throttle the whole link). I am not sure if dummy will sort this for me, there may be some other way? Basically all I need is something I can use HTB on where the qos ingress box is on this diagram. http://www.docum.org/stef.coene/qos/kptd/ Andy. From nakam@linux-ipv6.org Thu Apr 15 05:02:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 05:02:34 -0700 (PDT) Received: from localhost (kame199.kame.net [203.178.141.199]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FC2TKO006639 for ; Thu, 15 Apr 2004 05:02:30 -0700 Received: from localhost ([127.0.0.1]) by localhost with smtp (Exim 3.36 #1 (Debian)) id 1BE5Za-0000mO-00; Thu, 15 Apr 2004 21:02:26 +0900 Date: Thu, 15 Apr 2004 21:02:23 +0900 From: Masahide NAKAMURA To: davem@redhat.com Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: [PATCH] IPv6 IPsec AH typo Message-Id: <20040415210223.24aabc4a@localhost> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4679 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: nakam@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 371 Lines: 22 Hello, this patch fixes a typo. Please apply it. Thanks, --- linux-2.6.5.orig/net/ipv6/ah6.c Sun Apr 4 12:37:36 2004 +++ linux-2.6.5/net/ipv6/ah6.c Thu Apr 15 20:38:48 2004 @@ -162,7 +162,7 @@ } spin_lock_bh(&x->lock); - err = xfrm_check_output(x, skb, AF_INET); + err = xfrm_check_output(x, skb, AF_INET6); if (err) goto error; -- Masahide NAKAMURA From hadi@cyberus.ca Thu Apr 15 05:16:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 05:16:24 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FCG3KO010929 for ; Thu, 15 Apr 2004 05:16:04 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BE5n3-0000aR-CZ for netdev@oss.sgi.com; Thu, 15 Apr 2004 08:16:21 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BE5md-00032n-Dg; Thu, 15 Apr 2004 08:15:55 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <407E5905.9070108@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082031313.1039.13.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Apr 2004 08:15:13 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4680 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1033 Lines: 32 On Thu, 2004-04-15 at 05:42, Andy Furniss wrote: > > The only reason I use IMQ (+ NAT patch) is that I need to shape ingress > (I know I can't shape it "properly" from the wrong end of the bottleneck > without an intelligent app, but the ingress policer does not let me > share local and forwarded bandwidth and is not fair per user if I just > throttle the whole link). > > I am not sure if dummy will sort this for me, there may be some other way? The summary is dummy can do what IMQ used to; it is however not related to iptables/netfilter. > Basically all I need is something I can use HTB on where the qos ingress > box is on this diagram. Yes you can attach a HTB. Look at the posted example in the previous email and replace prio with HTB. Not sure i answered your questions. Again to emphasize: I will send patches only to people interested. People have to ask directly; this is my way of monitoring what is being tested. At some point i will make the latest patches available to everyone. cheers, jamal From praveen@india.hp.com Thu Apr 15 06:18:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 06:18:53 -0700 (PDT) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FDImKO025464 for ; Thu, 15 Apr 2004 06:18:49 -0700 Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.42.231.12]) by atlrel7.hp.com (Postfix) with ESMTP id B735A1C0260E for ; Thu, 15 Apr 2004 09:18:46 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.9.3 (PHNE_25184)/8.9.3 SMKit7.02) id SAA22825 for netdev@oss.sgi.com; Thu, 15 Apr 2004 18:50:55 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200404151320.SAA22825@shilpa.india.hp.com> Subject: Re: zero window probes on linux (fwd) To: netdev@oss.sgi.com Date: Thu, 15 Apr 2004 18:50:55 +0530 (IST) In-Reply-To: <20040414141010.267a6204.ak@suse.de> from Andi Kleen at Apr "14," 2004 "02:10:10" pm X-Mailer: ELM [] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4681 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: praveen@india.hp.com Precedence: bulk X-list: netdev Content-Length: 1763 Lines: 50 > > > > > > This seems to be a bug. Has it been already fixed in later > > > > > > kernel versions or is this how it is intended to remain? > > > > > > > > > > iirc this was intentional. The RFC suggested method doesn't work when talking to > > > > > some stacks. > > > > > > > > > > > > > But that cannot be valid enough justification for doing > > > > something against RFC right? > > > > > > Of course it is. Welcome to the real world. RFC1122 has a lot of bugs and sometimes > > > does not describe really implemented practice (e.g. BSD set the defacto standard > > > in many behaviours and it does not always follow 1122) > > > > So do u consider mandating definition of zero-window probes as defined > > in RFC793 as a bug in RFC1122? > > They are not directly a bug, but are just not what the world standardized on. > > > > Or else r u saying this bug is introduced in linux to take care of > > faulty stacks existing in the world. zero-window probes as defined > > in RFC1122 is not buggy right? > > Implementing a production network stack is not about following some standard to the > letter, but about interoperating with real implementations in a useful matter. > Linux does that. I checked the following vendor Operating Systems: HPUX, SunOS 5.8, FreeBSD 4.9. All of them send zero-window probes as per RFC1122. If BSD is considered the defacto standard then why is linux deviating from BSD in this aspect? Do u mean to say the above will not interoperate with the production network stacks which u r talking. BTW which r those production network stacks u r referring to? Is there any other linux mailing-lists where I can get most appropriate response? -Praveen > > -Andi > From scott.feldman@intel.com Thu Apr 15 11:07:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 11:08:00 -0700 (PDT) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FI7vKO004821 for ; Thu, 15 Apr 2004 11:07:57 -0700 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3FI7hcU023518; Thu, 15 Apr 2004 18:07:44 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3FI5v4D030285; Thu, 15 Apr 2004 18:07:43 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004041511074221744 ; Thu, 15 Apr 2004 11:07:42 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 11:07:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: non-NAPI mode question netif_rx_schedule() Date: Thu, 15 Apr 2004 11:07:42 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: non-NAPI mode question netif_rx_schedule() Thread-Index: AcQjEs52p8npWf6qS1q52rnXKVZRjAAAatpg From: "Feldman, Scott" To: "Jens Laas" Cc: X-OriginalArrivalTime: 15 Apr 2004 18:07:42.0804 (UTC) FILETIME=[8BFB5940:01C42314] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3FI7vKO004821 X-archive-position: 4682 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 147 Lines: 7 > __LINK_STATE_RX_SCHED is set on queue->backlog_dev not on the "real" > netdev. > > The backlog_dev is per queue and thus per CPU. Ah, thanks! From andy.furniss@dsl.pipex.com Thu Apr 15 12:35:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 12:35:12 -0700 (PDT) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FJZ9KO010029 for ; Thu, 15 Apr 2004 12:35:10 -0700 Received: from dsl.pipex.com (81-178-251-213.dsl.pipex.com [81.178.251.213]) by shockwave.systems.pipex.net (Postfix) with ESMTP id 1FC0E1C001F1; Thu, 15 Apr 2004 20:35:01 +0100 (BST) Message-ID: <407EE3E5.8060200@dsl.pipex.com> Date: Thu, 15 Apr 2004 20:35:01 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> In-Reply-To: <1082031313.1039.13.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4683 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1492 Lines: 46 jamal wrote: > On Thu, 2004-04-15 at 05:42, Andy Furniss wrote: > > >>The only reason I use IMQ (+ NAT patch) is that I need to shape ingress >>(I know I can't shape it "properly" from the wrong end of the bottleneck >>without an intelligent app, but the ingress policer does not let me >>share local and forwarded bandwidth and is not fair per user if I just >>throttle the whole link). >> >>I am not sure if dummy will sort this for me, there may be some other way? > > > The summary is dummy can do what IMQ used to; it is however not related > to iptables/netfilter. > > >>Basically all I need is something I can use HTB on where the qos ingress >>box is on this diagram. > > > Yes you can attach a HTB. Look at the posted example in the previous > email and replace prio with HTB. > Not sure i answered your questions. What I want to know is what state IP packets will be in if I filter/shape with dummy - In my case I would need them to have been demasqued so I can tell the difference between local and to be forwarded ingress traffic. Ie. where on the KPTD would dummy be - IMQ appears twice and by using the IMQ nat patch I can use the prerouting one to filter/shape the packets after they are denatted. Andy. > > Again to emphasize: I will send patches only to people interested. > People have to ask directly; > this is my way of monitoring what is being tested. At some point i will > make the latest patches available to everyone. > > cheers, > jamal From brazilnut@us.ibm.com Thu Apr 15 13:57:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 13:57:22 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FKv9KO015374 for ; Thu, 15 Apr 2004 13:57:18 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3FKuvcC319044; Thu, 15 Apr 2004 16:56:57 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3FKutIY142110; Thu, 15 Apr 2004 14:56:56 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3FKtXT04354; Thu, 15 Apr 2004 13:55:33 -0700 From: Don Fry Message-Id: <200404152055.i3FKtXT04354@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.6-rc1] pcnet32 transmit performance fix To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Thu, 15 Apr 2004 13:55:33 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4684 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1020 Lines: 25 When the pcnet32 adapter is installed in a system with long PCI latency and the read burst bit is not set, performance on transmission is very low (under 20Mbit on a 100Mbit link). This patch against 2.6.6-rc1 will make sure that read and write bursts are enabled. Tested on ppc64 and ia32. --- linux-2.6.6-rc1/drivers/net/orig.pcnet32.c Thu Apr 15 11:18:09 2004 +++ linux-2.6.6-rc1/drivers/net/pcnet32.c Thu Apr 15 11:47:00 2004 @@ -1022,10 +1022,11 @@ * starting until the packet is loaded. Strike one for reliability, lose * one for latency - although on PCI this isnt a big loss. Older chips * have FIFO's smaller than a packet, so you can't do this. + * Turn on BCR18:BurstRdEn and BCR18:BurstWrEn. */ if (fset) { - a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0800)); + a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0860)); a->write_csr(ioaddr, 80, (a->read_csr(ioaddr, 80) & 0x0C00) | 0x0c00); dxsuflo = 1; ltint = 1; -- Don Fry brazilnut@us.ibm.com From jgarzik@pobox.com Thu Apr 15 18:28:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 18:28:57 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3G1SsKO024472 for ; Thu, 15 Apr 2004 18:28:54 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BCm5j-0003xQ-VQ; Sun, 11 Apr 2004 22:02:12 +0100 Message-ID: <4079B246.4070107@pobox.com> Date: Sun, 11 Apr 2004 17:01:58 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shawn Starr CC: "'Len Brown'" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [BUG][2.6.5 final][e100/ee100pro] NETDEV_WATCHDOG Timeout -Related to i2c interface? References: <000001c42000$dd6e78f0$0200080a@panic> In-Reply-To: <000001c42000$dd6e78f0$0200080a@panic> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4685 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: 502 Lines: 16 Shawn Starr wrote: > Ok, this is strange, I put in an external 10/100 PRO S Adaptor, and im not > getting anymore eth0 timeouts, I would only get eth0 timeouts on the ONBOARD > nic if I enabled the lm80 sensor driver.. I don't know what to say, the > onboard nic would work fine without lm80 being loaded? > > Is there some sort of race condition that the onboard 10/100 PRO is doing ? If i2c is killing the network, sounds like it's diddling something on the motherboard it shouldn't... Jeff From hadi@cyberus.ca Thu Apr 15 20:53:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 15 Apr 2004 20:53:21 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3G3rIKO030128 for ; Thu, 15 Apr 2004 20:53:19 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BEKQ7-0007Sk-LW for netdev@oss.sgi.com; Thu, 15 Apr 2004 23:53:39 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BEKPe-0002R4-Vl; Thu, 15 Apr 2004 23:53:11 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <407EE3E5.8060200@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082087553.1035.287.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Apr 2004 23:52:33 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4686 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2171 Lines: 71 On Thu, 2004-04-15 at 15:35, Andy Furniss wrote: > jamal wrote: > What I want to know is what state IP packets will be in if I Just to be sure, this is not specific just to IP; it could be ARP, IPX, v6 etc. > > filter/shape with dummy - In my case I would need them to have been > demasqued so I can tell the difference between local and to be forwarded > ingress traffic. The packets are grabbed before NAT on the way in and after NAT on the way out. Coming from non-local machines before NAT you can redirect to a dummy device; and also be able to redirect on their way back to the non-local; to use the example i posted earlier: ---- $TC qdisc add dev dummy0 root handle 1: prio $TC qdisc add dev dummy0 parent 1:1 handle 10: sfq $TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 $TC qdisc add dev dummy0 parent 1:3 handle 30: sfq $TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw classid 1:1 $TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw classid 1:2 ifconfig dummy0 up #deal with ingress of eth0 first $TC qdisc add dev eth0 ingress # redirect all IP packets arriving from 10.0.0.21/24 in eth0 to dummy0 # use mark 1 --> puts them onto class 1:1 of dummy # $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match ip src 10.0.0.21/24 flowid 1:1 \ action ipt -j MARK --set-mark 1 \ action mirred egress redirect dev dummy0 #deal with egress of eth0 $TC qdisc add dev eth0 root handle 1: prio # redirect all IP packets going to 10.0.0.21/24 in eth0 to dummy0 # use mark 2 --> puts them onto class 1:2 of dummy # $TC filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ match ip dst 10.0.0.21/24 flowid 1:1 \ action ipt -j MARK --set-mark 2 \ action mirred egress redirect dev dummy0 ----- I havent tested the above but it should work (sans syntax bugs). If it doesnt then we have a bug that needs fixing. > Ie. where on the KPTD would dummy be - IMQ appears twice and by using > the IMQ nat patch I can use the prerouting one to filter/shape the > packets after they are denatted. > does the above help? cheers, jamal From luto@stanford.edu Fri Apr 16 00:39:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 00:39:47 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3G7dfKO011806 for ; Fri, 16 Apr 2004 00:39:42 -0700 Received: from stanford.edu (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3G5JBlT004336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Apr 2004 22:19:12 -0700 Message-ID: <407F6CC8.1060903@stanford.edu> Date: Thu, 15 Apr 2004 22:19:04 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kernel Mailing List , netdev@oss.sgi.com, shuchen@realtek.com.tw Subject: r8169 excessive PHY reset Content-Type: multipart/mixed; boundary="------------020206070400060601020304" X-archive-position: 4687 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@stanford.edu Precedence: bulk X-list: netdev Content-Length: 4062 Lines: 154 This is a multi-part message in MIME format. --------------020206070400060601020304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit On my r8169 (Really 8110S, I think -- it's a MSI K8T Neo-FIS2R, running x86_64), if I unplug the network cable and reconnect it, the link stays down and the driver starts resetting the PHY at an absurd rate (many times per second). Strangely enough, simply removing all the PHY reset code fixes it. Is there any reason for this code? (The other end of my link is e1000, and I'm using 1000Mbps.) Patch against 2.6.5-mm5 (attached because my mailer will mangle it otherwise). --Andy Please CC me b/c i'm not subscribed. --------------020206070400060601020304 Content-Type: text/plain; name="r8169fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="r8169fix.patch" --- ./drivers/net/r8169.c.orig 2004-04-15 22:08:07.962654280 -0700 +++ ./drivers/net/r8169.c 2004-04-15 22:09:22.101383480 -0700 @@ -98,7 +98,6 @@ #define RTL_MIN_IO_SIZE 0x80 #define RTL8169_TX_TIMEOUT (6*HZ) -#define RTL8169_PHY_TIMEOUT (HZ) /* write/read MMIO register */ #define RTL_W8(reg, val8) writeb ((val8), ioaddr + (reg)) @@ -323,7 +322,6 @@ dma_addr_t RxPhyAddr; struct sk_buff *Rx_skbuff[NUM_RX_DESC]; /* Rx data buffers */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ - struct timer_list timer; unsigned long phy_link_down_cnt; u16 cp_cmd; }; @@ -568,90 +566,6 @@ mdio_write(ioaddr, 31, 0x0000); //w 31 2 0 0 } -static void rtl8169_hw_phy_reset(struct net_device *dev) -{ - struct rtl8169_private *tp = dev->priv; - void *ioaddr = tp->mmio_addr; - int i, val; - - printk(KERN_WARNING PFX "%s: Reset RTL8169s PHY\n", dev->name); - - val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; - mdio_write(ioaddr, 0, val); - - for (i = 50; i >= 0; i--) { - if (!(mdio_read(ioaddr, 0) & 0x8000)) - break; - udelay(100); /* Gross */ - } - - if (i < 0) { - printk(KERN_WARNING PFX "%s: no PHY Reset ack. Giving up.\n", - dev->name); - } -} - -static void rtl8169_phy_timer(unsigned long __opaque) -{ - struct net_device *dev = (struct net_device *)__opaque; - struct rtl8169_private *tp = dev->priv; - struct timer_list *timer = &tp->timer; - void *ioaddr = tp->mmio_addr; - - assert(tp->mac_version > RTL_GIGA_MAC_VER_B); - assert(tp->phy_version < RTL_GIGA_PHY_VER_G); - - if (RTL_R8(PHYstatus) & LinkStatus) - tp->phy_link_down_cnt = 0; - else { - tp->phy_link_down_cnt++; - if (tp->phy_link_down_cnt >= 12) { - int reg; - - // If link on 1000, perform phy reset. - reg = mdio_read(ioaddr, PHY_1000_CTRL_REG); - if (reg & PHY_Cap_1000_Full) - rtl8169_hw_phy_reset(dev); - - tp->phy_link_down_cnt = 0; - } - } - - mod_timer(timer, RTL8169_PHY_TIMEOUT); -} - -static inline void rtl8169_delete_timer(struct net_device *dev) -{ - struct rtl8169_private *tp = dev->priv; - struct timer_list *timer = &tp->timer; - - if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) - return; - - del_timer_sync(timer); - - tp->phy_link_down_cnt = 0; -} - -static inline void rtl8169_request_timer(struct net_device *dev) -{ - struct rtl8169_private *tp = dev->priv; - struct timer_list *timer = &tp->timer; - - if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || - (tp->phy_version >= RTL_GIGA_PHY_VER_G)) - return; - - tp->phy_link_down_cnt = 0; - - init_timer(timer); - timer->expires = jiffies + RTL8169_PHY_TIMEOUT; - timer->data = (unsigned long)(dev); - timer->function = rtl8169_phy_timer; - add_timer(timer); -} - static int __devinit rtl8169_init_board(struct pci_dev *pdev, struct net_device **dev_out, void **ioaddr_out) @@ -1074,8 +988,6 @@ goto err_free_rx; rtl8169_hw_start(dev); - - rtl8169_request_timer(dev); out: return retval; @@ -1587,8 +1499,6 @@ netif_stop_queue(dev); - rtl8169_delete_timer(dev); - spin_lock_irq(&tp->lock); /* Stop the chip's Tx and Rx DMA processes. */ --------------020206070400060601020304-- From romieu@fr.zoreil.com Fri Apr 16 00:40:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 00:40:26 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3G7eNKO011871 for ; Fri, 16 Apr 2004 00:40:24 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3G6cguX024732; Fri, 16 Apr 2004 08:38:42 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3G6carG024731; Fri, 16 Apr 2004 08:38:36 +0200 Date: Fri, 16 Apr 2004 08:38:36 +0200 From: Francois Romieu To: Andy Lutomirski Cc: Kernel Mailing List , netdev@oss.sgi.com, shuchen@realtek.com.tw Subject: Re: r8169 excessive PHY reset Message-ID: <20040416083836.A24723@electric-eye.fr.zoreil.com> References: <407F6CC8.1060903@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <407F6CC8.1060903@stanford.edu>; from luto@stanford.edu on Thu, Apr 15, 2004 at 10:19:04PM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 4688 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 193 Lines: 8 Andy Lutomirski : [r8169 phy issue with 2.6.5-mm5] > - mod_timer(timer, RTL8169_PHY_TIMEOUT); I forgot a 'jiffies +' there. It is fixed in current Linus's tree. -- Ueimor From yoshfuji@linux-ipv6.org Fri Apr 16 03:35:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 03:35:52 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.135.30]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GAZjKO021059 for ; Fri, 16 Apr 2004 03:35:48 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 8A20C33CA5; Fri, 16 Apr 2004 19:36:15 +0900 (JST) Date: Fri, 16 Apr 2004 19:36:15 +0900 (JST) Message-Id: <20040416.193615.62247078.yoshfuji@linux-ipv6.org> To: davem@redhat.com Cc: netdev@oss.sgi.com, takamiya@po.ntts.co.jp, usagi-core@linux-ipv6.org, yoshfuji@linux-ipv6.org Subject: [PATCH] IPv6 Extension Headers with UDP From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4689 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 649 Lines: 23 Hello. D: Fix SEGV when sending UDPv6 with extension headers using ancillary data. (fix is based on patch from ) Thanks. --yoshfuji ===== net/ipv6/udp.c 1.60 vs edited ===== --- 1.60/net/ipv6/udp.c Wed Feb 25 17:17:45 2004 +++ edited/net/ipv6/udp.c Fri Apr 16 19:23:38 2004 @@ -913,6 +913,7 @@ if (msg->msg_controllen) { opt = &opt_space; memset(opt, 0, sizeof(struct ipv6_txoptions)); + opt->tot_len = sizeof(*opt); err = datagram_send_ctl(msg, fl, opt, &hlimit); if (err < 0) { -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From shemminger@osdl.org Fri Apr 16 09:47:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 09:47:24 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GGlJKO001873 for ; Fri, 16 Apr 2004 09:47:20 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3GGkE209106; Fri, 16 Apr 2004 09:46:14 -0700 Date: Fri, 16 Apr 2004 09:46:14 -0700 From: Stephen Hemminger To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] Mixed PCI/ISA device name conflicts Message-Id: <20040416094614.5d5775dd@dell_ss3.pdx.osdl.net> In-Reply-To: <407C33A4.3010804@pobox.com> References: <20031222091115.42dd5f1f.shemminger@osdl.org> <405F994B.6080501@pobox.com> <20040329153236.0cf427c9@dell_ss3.pdx.osdl.net> <407C33A4.3010804@pobox.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4690 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: 968 Lines: 29 In systems with mixed network cards, and all drivers compiled into the kernel; the PCI device (eth0) will get probed first, before the ISA. The problem is that the ISA device can mistakenly try to probe for eth0. The problem is that the ISA driver will not detect the failure until it goes to call register_netdevice, and not all drivers have perfect error unwind code. This patch short circuits the device probe, so it won't bother looking for devices that already are registered. diff -Nru a/net/core/dev.c b/net/core/dev.c --- a/net/core/dev.c Fri Apr 16 09:37:20 2004 +++ b/net/core/dev.c Fri Apr 16 09:37:20 2004 @@ -432,6 +432,14 @@ int i; sprintf(name, "%s%d", prefix, unit); + + /* + * If device already registered then return base of 1 + * to indicate not to probe for this interface + */ + if (__dev_get_by_name(name)) + return 1; + for (i = 0; i < NETDEV_BOOT_SETUP_MAX; i++) if (!strcmp(name, s[i].name)) return s[i].map.base_addr; From jgarzik@pobox.com Fri Apr 16 10:02:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 10:02:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GH2MKO002471 for ; Fri, 16 Apr 2004 10:02:23 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BEWjM-0001ma-V6; Fri, 16 Apr 2004 18:02:21 +0100 Message-ID: <40801191.1050900@pobox.com> Date: Fri, 16 Apr 2004 13:02:09 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.6-rc1] pcnet32 transmit performance fix References: <200404152055.i3FKtXT04354@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404152055.i3FKtXT04354@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4691 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From willy@www.linux.org.uk Fri Apr 16 11:00:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 11:00:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GI0YKO004322 for ; Fri, 16 Apr 2004 11:00:35 -0700 Received: from willy by www.linux.org.uk with local (Exim 4.22) id 1BEXdf-0003Kk-6B; Fri, 16 Apr 2004 19:00:31 +0100 Date: Fri, 16 Apr 2004 19:00:31 +0100 From: Matthew Wilcox To: "Luiz Fernando N. Capitulino" Cc: kernel-janitors@lists.osdl.org, cramerj@intel.com, scott.feldman@intel.com, netdev@oss.sgi.com Subject: Re: [Kernel-janitors] Fw: [CHECKER] Probable security holes in 2.6.5 Message-ID: <20040416180031.GK18329@parcelfarce.linux.theplanet.co.uk> References: <20040416141827.6e38cd14.lcapitulino@prefeitura.sp.gov.br> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040416141827.6e38cd14.lcapitulino@prefeitura.sp.gov.br> User-Agent: Mutt/1.4.1i X-archive-position: 4692 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@debian.org Precedence: bulk X-list: netdev Content-Length: 2426 Lines: 52 On Fri, Apr 16, 2004 at 02:18:27PM -0300, Luiz Fernando N. Capitulino wrote: > Início da mensagem encaminhada: > > Date: Fri, 16 Apr 2004 10:01:57 -0700 > From: Ken Ashcraft > To: linux-kernel@vger.kernel.org > Cc: mc@cs.stanford.edu > Subject: [CHECKER] Probable security holes in 2.6.5 > > The error reports below are sorted roughly by their severity. The last > 12 of the errors are fairly minor because they are either protected by a > capable() check or the scalar is only 8 bits. I also consider it to be > a minor error to pass an unchecked value to kmalloc(). I realize that > kmalloc() will fail when asked for more than 128k, but it may not be > appropriate to allow the user to allocate that much memory. All of > these minor errors will be marked by [MINOR] and/or [CAPABLE] tags in > the error report. > > --------------------------------------------------------- > [BUG] > /home/kash/linux/linux-2.6.5/drivers/net/e1000/e1000_ethtool.c:1494:e1000_ethtool_ioctl: ERROR:TAINT: 1487:1494:Passing unbounded user value "(regs).len" as arg 2 to function "copy_to_user", which uses it unsafely in model [SOURCE_MODEL=(lib,copy_from_user,user,taintscalar)] [SINK_MODEL=(lib,copy_to_user,user,trustingsink)] [PATH=] > } > case ETHTOOL_GREGS: { > struct ethtool_regs regs = {ETHTOOL_GREGS}; > uint32_t regs_buff[E1000_REGS_LEN]; > > Start ---> > if(copy_from_user(®s, addr, sizeof(regs))) > return -EFAULT; > e1000_ethtool_gregs(adapter, ®s, regs_buff); > if(copy_to_user(addr, ®s, sizeof(regs))) > return -EFAULT; > > addr += offsetof(struct ethtool_regs, data); > Error ---> > if(copy_to_user(addr, regs_buff, regs.len)) > return -EFAULT; > > return 0; This one is probably best fixed by converting the e1000 driver to use ethtool_ops which does all the user-access stuff in generic code and gets looked at by dozens more people than a driver does. cc'ing the e1000 people on this in case they want to do it themselves. -- "Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception." -- Mark Twain From khc@pm.waw.pl Fri Apr 16 11:07:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 11:07:34 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GI7SKO005122 for ; Fri, 16 Apr 2004 11:07:30 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 23951366; Fri, 16 Apr 2004 20:07:12 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 14593302DD; Fri, 16 Apr 2004 18:10:24 +0200 (CEST) To: linux-kernel@vger.kernel.org, dev@able.be, netdev@oss.sgi.com Subject: Re: Kernel panic using frame relay protocol and IPSec References: <407E93F9.3010105@able.be> From: Krzysztof Halasa Date: Fri, 16 Apr 2004 18:10:23 +0200 In-Reply-To: <407E93F9.3010105@able.be> (Wim Ceulemans's message of "Thu, 15 Apr 2004 15:54:01 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4693 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 852 Lines: 23 Wim Ceulemans writes: > We are using kernel 2.4.24 and super-freeswan 1.99.8. > When using the frame relay protocol when a psk tunnel is established, > we are seeing a kernel panic when we ping through the tunnel. Short version of my email to Wim: It looks like a known bug - IPSEC code seems to ignore dev->hard_header_len = 10 requirement for PVC devices and passes skbs which have less than 10 bytes of header space. Not sure how does it work with Ethernet which requires 14 bytes, though. It might be a good idea to investigate. I wonder if the FR behavior is correct - i.e. is it OK to set dev->hard_header_len = 10 and expect that all skbs passed to dev->hard_start_xmit() will have at least 10 bytes of space before the data? Does the situation depend on dev->hard_header being non-NULL? -- Krzysztof Halasa, B*FH From jbondjr@gambit.implode.net Fri Apr 16 11:38:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 11:38:57 -0700 (PDT) Received: from cyclops.implode.net (Debian-exim@d216-232-206-119.bchsia.telus.net [216.232.206.119]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GIctKO009366 for ; Fri, 16 Apr 2004 11:38:56 -0700 Received: from gambit.implode.net ([192.168.1.2]) by cyclops.implode.net with esmtp (Exim 4.30) id 1BEYEn-0003NS-EB; Fri, 16 Apr 2004 11:38:53 -0700 Received: from jbondjr by gambit.implode.net with local (Exim 4.31) id 1BEYEe-0000pv-F6; Fri, 16 Apr 2004 11:38:44 -0700 Date: Fri, 16 Apr 2004 11:38:44 -0700 From: John Wong To: netdev@oss.sgi.com Cc: c-d.hailfinger.kernel.2004@gmx.net, manfred@colorfullife.com Subject: forcedeth and kernel 2.6.5 has "no link" Message-ID: <20040416183844.GA2923@gambit.implode.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 4694 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@implode.net Precedence: bulk X-list: netdev Content-Length: 973 Lines: 27 Under kernel 2.6.4, ethtool reports: Settings for eth0: Link detected: yes This is with forcedeth 0.23 Under kernel 2.6.5, ethtool reports: Settings for eth0: Supports Wake-on: g Wake-on: d Link detected: no This is with forcedeth 0.25 With 2.6.5, it doesn't see an link but there is one. The connection is quite slow, so I'm thinking it may be using 10baseT-HD instead of 100baseTx-FD. The forcedeth driver does not appear to support autonegotiation. http://bugzilla.kernel.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=OPEN&bug_status=ASSIGNED&bug_status=REOPENED&field0-0-0=product&type0-0-0=substring&value0-0-0=forcedeth&field0-0-1=component&type0-0-1=substring&value0-0-1=forcedeth&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=forcedeth&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=forcedeth I had submitted the bugzilla id 2283. 2496 is something that I am experiencing too. John From manfred@colorfullife.com Fri Apr 16 12:07:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 12:07:02 -0700 (PDT) Received: from dbl.q-ag.de (dbl.q-ag.de [213.172.117.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GJ6wKO010841 for ; Fri, 16 Apr 2004 12:06:59 -0700 Received: from colorfullife.com (dbl [127.0.0.1]) by dbl.q-ag.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3GJ6eNj008508; Fri, 16 Apr 2004 21:06:41 +0200 Message-ID: <40802EC0.2070108@colorfullife.com> Date: Fri, 16 Apr 2004 21:06:40 +0200 From: Manfred Spraul User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.4.1) Gecko/20031114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Wong CC: c-d.hailfinger.kernel.2004@gmx.net, netdev@oss.sgi.com Subject: Re: forcedeth and kernel 2.6.5 has "no link" References: <20040416183844.GA2923@gambit.implode.net> In-Reply-To: <20040416183844.GA2923@gambit.implode.net> Content-Type: multipart/mixed; boundary="------------050806000708040207010204" X-archive-position: 4695 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: manfred@colorfullife.com Precedence: bulk X-list: netdev Content-Length: 1558 Lines: 64 This is a multi-part message in MIME format. --------------050806000708040207010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Wong wrote: >Under kernel 2.6.4, ethtool reports: > >Settings for eth0: > Link detected: yes > >This is with forcedeth 0.23 > >Under kernel 2.6.5, ethtool reports: > >Settings for eth0: > Supports Wake-on: g > Wake-on: d > Link detected: no > >This is with forcedeth 0.25 > > Odd. I'm not aware of any changes that might cause that difference. I'll check the diff. >I had submitted the bugzilla id 2283. 2496 is something that I am >experiencing too. > > Could you try the attached patch? -- Manfred --------------050806000708040207010204 Content-Type: text/plain; name="patch-forced-test" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-forced-test" --- 2.6/drivers/net/forcedeth.c 2004-04-10 09:52:45.000000000 +0200 +++ build-2.6/drivers/net/forcedeth.c 2004-04-13 18:58:59.000000000 +0200 @@ -1263,6 +1263,14 @@ dev->name, id1, id2, i); np->phyaddr = i; + if (id1 == 0x0015 && (id2 &0xfff0) == 0xf440) { + printk(KERN_DEBUG "%s: open: Found ICS, applying workaround.\n", dev->name); + /* workaround for ICS1893 PHY */ + mii_rw(dev, i, 0x0018, 0xD200); + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(HZ); + } + spin_lock_irq(&np->lock); nv_update_linkspeed(dev); spin_unlock_irq(&np->lock); --------------050806000708040207010204-- From andy.furniss@dsl.pipex.com Fri Apr 16 12:35:20 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 12:35:23 -0700 (PDT) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GJZJKO014867 for ; Fri, 16 Apr 2004 12:35:20 -0700 Received: from dsl.pipex.com (81-178-236-204.dsl.pipex.com [81.178.236.204]) by shockwave.systems.pipex.net (Postfix) with ESMTP id E18D71C00183; Fri, 16 Apr 2004 20:35:11 +0100 (BST) Message-ID: <4080356F.4020609@dsl.pipex.com> Date: Fri, 16 Apr 2004 20:35:11 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> In-Reply-To: <1082087553.1035.287.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4696 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2553 Lines: 96 jamal wrote: > On Thu, 2004-04-15 at 15:35, Andy Furniss wrote: > >>jamal wrote: > > >>What I want to know is what state IP packets will be in if I > > > Just to be sure, this is not specific just to IP; it could be ARP, IPX, > v6 etc. > > >> >>filter/shape with dummy - In my case I would need them to have been >>demasqued so I can tell the difference between local and to be forwarded >>ingress traffic. > > > The packets are grabbed before NAT on the way in and after NAT on the > way out. This is what I wanted to know. Is it possible to make an option to get them after NAT in and pre NAT out? > Coming from non-local machines before NAT you can redirect to a dummy > device; and also be able to redirect on their way back to the non-local; > to use the example i posted earlier: > > ---- > $TC qdisc add dev dummy0 root handle 1: prio > $TC qdisc add dev dummy0 parent 1:1 handle 10: sfq > $TC qdisc add dev dummy0 parent 1:2 handle 20: tbf rate 20kbit buffer > 1600 limit > 3000 > $TC qdisc add dev dummy0 parent 1:3 handle 30: > sfq > > $TC filter add dev dummy0 protocol ip pref 1 parent 1: handle 1 fw > classid 1:1 > $TC filter add dev dummy0 protocol ip pref 2 parent 1: handle 2 fw > classid 1:2 > > ifconfig dummy0 up > > #deal with ingress of eth0 first > $TC qdisc add dev eth0 ingress > > # redirect all IP packets arriving from 10.0.0.21/24 in eth0 to dummy0 > # use mark 1 --> puts them onto class 1:1 of dummy > # > $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ > match ip src 10.0.0.21/24 flowid 1:1 \ > action ipt -j MARK --set-mark 1 \ > action mirred egress redirect dev dummy0 > > #deal with egress of eth0 > $TC qdisc add dev eth0 root handle 1: prio > > # redirect all IP packets going to 10.0.0.21/24 in eth0 to dummy0 > # use mark 2 --> puts them onto class 1:2 of dummy > # > $TC filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ > match ip dst 10.0.0.21/24 flowid 1:1 \ > action ipt -j MARK --set-mark 2 \ > action mirred egress redirect dev dummy0 > ----- > > I havent tested the above but it should work (sans syntax bugs). If it > doesnt then we have a bug that needs fixing. I don't think this applies to my setup Masqerading many local onto one real address. > > >>Ie. where on the KPTD would dummy be - IMQ appears twice and by using >>the IMQ nat patch I can use the prerouting one to filter/shape the >>packets after they are denatted. >> > > > does the above help? Yes - Thanks. Andy. > > cheers, > jamal > > From brazilnut@us.ibm.com Fri Apr 16 13:03:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 13:03:26 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GK3HKO015529 for ; Fri, 16 Apr 2004 13:03:23 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3GK37kV793774; Fri, 16 Apr 2004 16:03:07 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3GK36CH138952; Fri, 16 Apr 2004 14:03:06 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3GK1Y806283; Fri, 16 Apr 2004 13:01:34 -0700 From: Don Fry Message-Id: <200404162001.i3GK1Y806283@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.4.26-bk1] netdevice.h add netif_msg_init helper To: jgarzik@pobox.com, netdev@oss.sgi.com Date: Fri, 16 Apr 2004 13:01:34 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4697 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 967 Lines: 30 Please apply the following patch to 2.4.26-bk1 This patch adds a helper function to initialize the debug bit mask for use with netif_msg_*. When the debug_value is out of range it returns the default_msg_enable_bits. Tested IA32. --- linux-2.4.26-bk1/include/linux/orig.netdevice.h Fri Apr 16 11:09:23 2004 +++ linux-2.4.26-bk1/include/linux/netdevice.h Fri Apr 16 12:55:00 2004 @@ -737,6 +737,17 @@ #define netif_msg_hw(p) ((p)->msg_enable & NETIF_MSG_HW) #define netif_msg_wol(p) ((p)->msg_enable & NETIF_MSG_WOL) +static inline u32 netif_msg_init(int debug_value, int default_msg_enable_bits) +{ + /* use default */ + if (debug_value < 0 || debug_value >= (sizeof(u32) * 8)) + return default_msg_enable_bits; + if (debug_value == 0) /* no output */ + return 0; + /* set low N bits */ + return (1 << debug_value) - 1; +} + /* Schedule rx intr now? */ static inline int netif_rx_schedule_prep(struct net_device *dev) -- Don Fry brazilnut@us.ibm.com From shemminger@osdl.org Fri Apr 16 13:16:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 13:17:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GKGoKO015990 for ; Fri, 16 Apr 2004 13:16:52 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3GKGX225287; Fri, 16 Apr 2004 13:16:34 -0700 Date: Fri, 16 Apr 2004 13:16:33 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: "Paul Rolland" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6.5] Bad scheduling while atomic Message-Id: <20040416131633.1bfbfa4c@dell_ss3.pdx.osdl.net> In-Reply-To: <200404161551.i3GFpD124970@tag.witbe.net> References: <200404161551.i3GFpD124970@tag.witbe.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4698 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: 1006 Lines: 37 Bring up/down network devices with lapbether causes scheduling while atomic (if preempt enabled). The calls to rcu_read_lock are unnecessary since lapb_device_event is called from notifier with the rtnetlink semaphore held, it is already protected from the labp_devices list changing. Patch against 2.6.6-rc1 diff -Nru a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c --- a/drivers/net/wan/lapbether.c Fri Apr 16 11:00:35 2004 +++ b/drivers/net/wan/lapbether.c Fri Apr 16 11:00:35 2004 @@ -392,6 +392,8 @@ /* * Handle device status changes. + * + * Called from notifier with RTNL held. */ static int lapbeth_device_event(struct notifier_block *this, unsigned long event, void *ptr) @@ -402,7 +404,6 @@ if (!dev_is_ethdev(dev)) return NOTIFY_DONE; - rcu_read_lock(); switch (event) { case NETDEV_UP: /* New ethernet device -> new LAPB interface */ @@ -422,7 +423,6 @@ lapbeth_free_device(lapbeth); break; } - rcu_read_unlock(); return NOTIFY_DONE; } From davem@redhat.com Fri Apr 16 13:50:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 13:50:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GKokKO016878 for ; Fri, 16 Apr 2004 13:50:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GKojJW007601; Fri, 16 Apr 2004 16:50:45 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GKojj20258; Fri, 16 Apr 2004 16:50:45 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GKoL1n012496; Fri, 16 Apr 2004 16:50:22 -0400 Date: Fri, 16 Apr 2004 13:50:12 -0700 From: "David S. Miller" To: Andi Kleen Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Do lazy gettimeofday for network packets Message-Id: <20040416135012.02c5f000.davem@redhat.com> In-Reply-To: <20040409173554.49ecc736.ak@suse.de> References: <20040409173554.49ecc736.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4699 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 275 Lines: 9 On Fri, 9 Apr 2004 17:35:54 +0200 Andi Kleen wrote: > This adds lazy network timestamping to 2.6.5. skb->stamp is only filled in > when there is a consumer of network timestamps active in the system. Ok, let's give this a try, I'll apply this. Thanks Andi. From davem@redhat.com Fri Apr 16 13:52:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 13:53:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GKqwKO017226 for ; Fri, 16 Apr 2004 13:52:58 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GKqtJW008133; Fri, 16 Apr 2004 16:52:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GKqtj20944; Fri, 16 Apr 2004 16:52:55 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GKqV1n013953; Fri, 16 Apr 2004 16:52:31 -0400 Date: Fri, 16 Apr 2004 13:52:22 -0700 From: "David S. Miller" To: Andi Kleen Cc: yoshfuji@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: [PATCH] NETDEBUG network triggerable messages in IPv6 Message-Id: <20040416135222.43028332.davem@redhat.com> In-Reply-To: <20040409193123.63e4cdc7.ak@suse.de> References: <20040409174847.2f0b7e77.ak@suse.de> <20040410.010051.129465789.yoshfuji@linux-ipv6.org> <20040409182125.348fd6cd.ak@suse.de> <20040410.021840.113165465.yoshfuji@linux-ipv6.org> <20040409193123.63e4cdc7.ak@suse.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4700 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 223 Lines: 9 On Fri, 9 Apr 2004 19:31:23 +0200 Andi Kleen wrote: > Ok, here is a new version that defines a new macro LIMIT_NETDEBUG that does the > rate limit implicitely. > > DaveM, please apply. Will do, thanks Andi. From davem@redhat.com Fri Apr 16 14:13:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:13:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLDYKO017872 for ; Fri, 16 Apr 2004 14:13:34 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLDVJW012837; Fri, 16 Apr 2004 17:13:31 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLDVj27277; Fri, 16 Apr 2004 17:13:31 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLD71n024163; Fri, 16 Apr 2004 17:13:07 -0400 Date: Fri, 16 Apr 2004 14:12:57 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (1/9) bridge - include file cleanup Message-Id: <20040416141257.345e916b.davem@redhat.com> In-Reply-To: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4701 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 318 Lines: 9 On Tue, 13 Apr 2004 15:16:30 -0700 Stephen Hemminger wrote: > Cleanup some of the include file's in the bridge code. > * if_bridge.h defines net_bridge, but not needed as part of the API. > * get rid of places that include if_bridge.h and uaccess.h but don't > actually do API work. Applied. From davem@redhat.com Fri Apr 16 14:14:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:14:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLEPKO018039 for ; Fri, 16 Apr 2004 14:14:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLENJW012969; Fri, 16 Apr 2004 17:14:23 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLENj27390; Fri, 16 Apr 2004 17:14:23 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLDx1n024427; Fri, 16 Apr 2004 17:13:59 -0400 Date: Fri, 16 Apr 2004 14:13:49 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (2/9) bridge - rmmod race Message-Id: <20040416141349.6465c878.davem@redhat.com> In-Reply-To: <20040413151847.50c62126@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413151847.50c62126@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4702 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 258 Lines: 8 On Tue, 13 Apr 2004 15:18:47 -0700 Stephen Hemminger wrote: > Fix observed race between removing bridge module and ip packets > in flight. Need to remove the hook last, after all bridges are gone > not the other way around. Applied. From davem@redhat.com Fri Apr 16 14:15:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:15:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLF3KO018470 for ; Fri, 16 Apr 2004 14:15:03 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLEwJW013104; Fri, 16 Apr 2004 17:14:58 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLEwj27569; Fri, 16 Apr 2004 17:14:58 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLEY1n024638; Fri, 16 Apr 2004 17:14:35 -0400 Date: Fri, 16 Apr 2004 14:14:25 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (3/9) bridge - jiffies_to_clock Message-Id: <20040416141425.37bb59d8.davem@redhat.com> In-Reply-To: <20040413152037.5e28054d@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413152037.5e28054d@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4703 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 201 Lines: 7 On Tue, 13 Apr 2004 15:20:37 -0700 Stephen Hemminger wrote: > Rather than doing the math directly, use jiffies_to_clock functions > to convert from user hz to jiffies. Applied. From davem@redhat.com Fri Apr 16 14:16:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:16:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLGFKO018811 for ; Fri, 16 Apr 2004 14:16:16 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLGAJW013391; Fri, 16 Apr 2004 17:16:10 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLGAj27890; Fri, 16 Apr 2004 17:16:10 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLFk1n025327; Fri, 16 Apr 2004 17:15:47 -0400 Date: Fri, 16 Apr 2004 14:15:37 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (4/9) bridge - use ethtool to get port speed Message-Id: <20040416141537.74dd31ec.davem@redhat.com> In-Reply-To: <20040413152440.7e410cd8@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413152440.7e410cd8@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4704 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 402 Lines: 10 On Tue, 13 Apr 2004 15:24:40 -0700 Stephen Hemminger wrote: > The bridge code needs to keep track of a cost estimate for each > port in the bridge. Instead of a hack based on device name, try > and use ethtool to get port speed from device. This has been tested > on e100 (uses ethtool_ops) and e1000 (does ethtool the hard way) > and dummy (no ethtool). Looks fine, applied. From davem@redhat.com Fri Apr 16 14:16:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:16:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLGnKO019060 for ; Fri, 16 Apr 2004 14:16:49 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLGlJW013550; Fri, 16 Apr 2004 17:16:47 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLGlj28121; Fri, 16 Apr 2004 17:16:47 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLGN1n025889; Fri, 16 Apr 2004 17:16:23 -0400 Date: Fri, 16 Apr 2004 14:16:13 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (5/9) bridge - multicast address as const Message-Id: <20040416141613.2ff1db7f.davem@redhat.com> In-Reply-To: <20040413152620.2a0f0bd1@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413152620.2a0f0bd1@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4705 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 194 Lines: 7 On Tue, 13 Apr 2004 15:26:20 -0700 Stephen Hemminger wrote: > Trivial change. For places where bridge multicast address is defined, > or compared use constant. Applied. From davem@redhat.com Fri Apr 16 14:21:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:21:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLLbKO019475 for ; Fri, 16 Apr 2004 14:21:38 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLLZJW014607; Fri, 16 Apr 2004 17:21:35 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLLZj29664; Fri, 16 Apr 2004 17:21:35 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLLA1n030178; Fri, 16 Apr 2004 17:21:11 -0400 Date: Fri, 16 Apr 2004 14:21:01 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (6/9) bridge - forwarding database changes Message-Id: <20040416142101.52dfe6e9.davem@redhat.com> In-Reply-To: <20040413152838.181eb743@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413152838.181eb743@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4706 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 359 Lines: 10 On Tue, 13 Apr 2004 15:28:38 -0700 Stephen Hemminger wrote: > Make forwarding database more robust. > + Don't insert invalid ether address, > + Report errors back so adding an interface to bridge can fail > + get rid of unneeded explicit pads in data structure > + replace bitfields with byte's for simple booleans. Applied. From davem@redhat.com Fri Apr 16 14:22:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:22:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLMiKO019743 for ; Fri, 16 Apr 2004 14:22:45 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLMgJW014798; Fri, 16 Apr 2004 17:22:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLMgj29836; Fri, 16 Apr 2004 17:22:42 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLMI1n030811; Fri, 16 Apr 2004 17:22:19 -0400 Date: Fri, 16 Apr 2004 14:22:09 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (7/9) bridge - STP unsigned fields Message-Id: <20040416142209.04913f56.davem@redhat.com> In-Reply-To: <20040413153046.4f47fe0f@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413153046.4f47fe0f@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4707 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 303 Lines: 10 On Tue, 13 Apr 2004 15:30:46 -0700 Stephen Hemminger wrote: > Use correct types for fields related to spanning tree protocols. > * costs are 32 bit unsigned > * ports are 16 bit unsigned > * booleans are bytes rather than bitfield > * arrange for better packing Applied. From davem@redhat.com Fri Apr 16 14:23:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:23:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLNUKO020085 for ; Fri, 16 Apr 2004 14:23:30 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLNQJW015030; Fri, 16 Apr 2004 17:23:26 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLNPj30093; Fri, 16 Apr 2004 17:23:25 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLN21n031726; Fri, 16 Apr 2004 17:23:02 -0400 Date: Fri, 16 Apr 2004 14:22:52 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (8/9) bridge - support lots of 1k ports Message-Id: <20040416142252.05481624.davem@redhat.com> In-Reply-To: <20040413153308.6e0dd462@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413153308.6e0dd462@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4708 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 257 Lines: 8 On Tue, 13 Apr 2004 15:33:08 -0700 Stephen Hemminger wrote: > Support >256 ports on a bridge. Use the suggestion of reducing > the number of bits of priority and increasing the number of bits > for port number. Seems sane, applied. From davem@redhat.com Fri Apr 16 14:24:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:24:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLOMKO020407 for ; Fri, 16 Apr 2004 14:24:22 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLOIJW015254; Fri, 16 Apr 2004 17:24:18 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLOIj30262; Fri, 16 Apr 2004 17:24:18 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLNs1n032328; Fri, 16 Apr 2004 17:23:54 -0400 Date: Fri, 16 Apr 2004 14:23:44 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] (9/9) bridge - fdb cache alloc Message-Id: <20040416142344.37eb3d6f.davem@redhat.com> In-Reply-To: <20040413153453.4765b26a@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040413153453.4765b26a@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4709 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 229 Lines: 7 On Tue, 13 Apr 2004 15:34:53 -0700 Stephen Hemminger wrote: > Since forwarding database gets a lot of memory alloc/free on a busy > bridge, use kmem_cache_alloc to provide cache and better stats. Applied. From davem@redhat.com Fri Apr 16 14:24:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:24:54 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLOpKO020606 for ; Fri, 16 Apr 2004 14:24:52 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLOnJW015320; Fri, 16 Apr 2004 17:24:49 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLOnj30360; Fri, 16 Apr 2004 17:24:49 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLOP1n000380; Fri, 16 Apr 2004 17:24:25 -0400 Date: Fri, 16 Apr 2004 14:24:15 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: bridge@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH 2.6.5] bridge - replace CLEAR_BITMAP with memset Message-Id: <20040416142415.07572f56.davem@redhat.com> In-Reply-To: <20040414120434.2029b567@dell_ss3.pdx.osdl.net> References: <20040413151630.710042e3@dell_ss3.pdx.osdl.net> <20040414120434.2029b567@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4710 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 158 Lines: 6 On Wed, 14 Apr 2004 12:04:34 -0700 Stephen Hemminger wrote: > It looks like a recent patch to 2.6.5 got rid of CLEAR_BITMAP. Applied. From davem@redhat.com Fri Apr 16 14:53:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:53:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLr9KO021367 for ; Fri, 16 Apr 2004 14:53:09 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLr3JW021129; Fri, 16 Apr 2004 17:53:03 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLr3j06031; Fri, 16 Apr 2004 17:53:03 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLqd1n015641; Fri, 16 Apr 2004 17:52:39 -0400 Date: Fri, 16 Apr 2004 14:52:29 -0700 From: "David S. Miller" To: yoshfuji@linux-ipv6.org Cc: netdev@oss.sgi.com Subject: Re: [PATCH] MLDV2: Use IANA icmpv6 type for MLDv2 Report Message-Id: <20040416145229.265a741c.davem@redhat.com> In-Reply-To: <20040415.073324.44957072.yoshfuji@linux-ipv6.org> References: <20040415.073324.44957072.yoshfuji@linux-ipv6.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3GLr9KO021367 X-archive-position: 4711 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 283 Lines: 10 On Thu, 15 Apr 2004 07:33:24 +0900 (JST) YOSHIFUJI Hideaki / $B5HF#1QL@(B wrote: > IANA has finally assigned an ICMPv6 type for MLDv2 Report. > (See: ) > > Patch also applies to 2.4. Applied, thanks. From davem@redhat.com Fri Apr 16 14:53:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:53:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLrrKO022428 for ; Fri, 16 Apr 2004 14:53:53 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLrpJW021339; Fri, 16 Apr 2004 17:53:51 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLrpj06204; Fri, 16 Apr 2004 17:53:51 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLrR1n015863; Fri, 16 Apr 2004 17:53:27 -0400 Date: Fri, 16 Apr 2004 14:53:17 -0700 From: "David S. Miller" To: Masahide NAKAMURA Cc: netdev@oss.sgi.com, usagi-core@linux-ipv6.org Subject: Re: [PATCH] IPv6 IPsec AH typo Message-Id: <20040416145317.67832409.davem@redhat.com> In-Reply-To: <20040415210223.24aabc4a@localhost> References: <20040415210223.24aabc4a@localhost> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4712 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 11 On Thu, 15 Apr 2004 21:02:23 +0900 Masahide NAKAMURA wrote: > this patch fixes a typo. Please apply it. ... > - err = xfrm_check_output(x, skb, AF_INET); > + err = xfrm_check_output(x, skb, AF_INET6); It is fine, patch applied. Thanks. From davem@redhat.com Fri Apr 16 14:57:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 14:57:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GLv9KO022962 for ; Fri, 16 Apr 2004 14:57:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3GLv6JW022161; Fri, 16 Apr 2004 17:57:06 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3GLv6j07131; Fri, 16 Apr 2004 17:57:06 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3GLug1n017326; Fri, 16 Apr 2004 17:56:42 -0400 Date: Fri, 16 Apr 2004 14:56:32 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: rol@witbe.net, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [2.6.5] Bad scheduling while atomic Message-Id: <20040416145632.0b96a3c9.davem@redhat.com> In-Reply-To: <20040416131633.1bfbfa4c@dell_ss3.pdx.osdl.net> References: <200404161551.i3GFpD124970@tag.witbe.net> <20040416131633.1bfbfa4c@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4713 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 408 Lines: 11 On Fri, 16 Apr 2004 13:16:33 -0700 Stephen Hemminger wrote: > Bring up/down network devices with lapbether causes scheduling while > atomic (if preempt enabled). > > The calls to rcu_read_lock are unnecessary since lapb_device_event > is called from notifier with the rtnetlink semaphore held, it is > already protected from the labp_devices list changing. Applied, thanks Stephen. From chrisw@osdl.org Fri Apr 16 15:38:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 15:38:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GMc0KO024229 for ; Fri, 16 Apr 2004 15:38:00 -0700 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i3GMbt225519; Fri, 16 Apr 2004 15:37:55 -0700 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id i3GMbsK16663; Fri, 16 Apr 2004 15:37:54 -0700 Date: Fri, 16 Apr 2004 15:37:54 -0700 From: Chris Wright To: Jeff Garzik Cc: netdev@oss.sgi.com Subject: [PATCH] remove redundant check in de2104x ->get_regs() Message-ID: <20040416153754.U21045@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 4714 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 797 Lines: 29 Hi Jeff, Trivial patchlet...ethtool core already caps regs.len at a max of ->get_regs_len(): reglen = ops->get_regs_len(dev); if (regs.len > reglen) regs.len = reglen; So doing the same in the in de2104x driver ->get_regs() is redundant. Patch below simply removes it to clarify the guarantee of the API. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net ===== drivers/net/tulip/de2104x.c 1.29 vs edited ===== --- 1.29/drivers/net/tulip/de2104x.c Wed Mar 17 11:32:53 2004 +++ edited/drivers/net/tulip/de2104x.c Fri Apr 16 15:31:55 2004 @@ -1676,8 +1676,6 @@ { struct de_private *de = dev->priv; - if (regs->len > DE_REGS_SIZE) - regs->len = DE_REGS_SIZE; regs->version = (DE_REGS_VER << 2) | de->de21040; spin_lock_irq(&de->lock); From shemminger@osdl.org Fri Apr 16 15:55:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 15:55:57 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GMtnKO024793 for ; Fri, 16 Apr 2004 15:55:50 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3GMsn229369; Fri, 16 Apr 2004 15:54:49 -0700 Date: Fri, 16 Apr 2004 15:54:49 -0700 From: Stephen Hemminger To: Jeff Cramer , "Feldman, Scott" , Jeff Garzik , Chris Wright Cc: netdev@oss.sgi.com Subject: [PATCH] e1000 ethtool_ops support Message-Id: <20040416155449.0796053f@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4715 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: 24375 Lines: 907 Okay, here is a first cut at ethtool ops integration for e1000. It has been touch tested for the basic operations on a card on a lab machine. Please review before including in the 2.6.6 kernel. diff -Nru a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c --- a/drivers/net/e1000/e1000_ethtool.c Fri Apr 16 15:50:02 2004 +++ b/drivers/net/e1000/e1000_ethtool.c Fri Apr 16 15:50:02 2004 @@ -53,7 +53,7 @@ #define E1000_STAT(m) sizeof(((struct e1000_adapter *)0)->m), \ offsetof(struct e1000_adapter, m) -static struct e1000_stats e1000_gstrings_stats[] = { +static const struct e1000_stats e1000_gstrings_stats[] = { { "rx_packets", E1000_STAT(net_stats.rx_packets) }, { "tx_packets", E1000_STAT(net_stats.tx_packets) }, { "rx_bytes", E1000_STAT(net_stats.rx_bytes) }, @@ -100,9 +100,10 @@ }; #define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN -static void -e1000_ethtool_gset(struct e1000_adapter *adapter, struct ethtool_cmd *ecmd) +static int +e1000_get_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; if(hw->media_type == e1000_media_type_copper) { @@ -169,11 +170,13 @@ } ecmd->autoneg = (hw->autoneg ? AUTONEG_ENABLE : AUTONEG_DISABLE); + return 0; } static int -e1000_ethtool_sset(struct e1000_adapter *adapter, struct ethtool_cmd *ecmd) +e1000_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; if(ecmd->autoneg == AUTONEG_ENABLE) { @@ -195,10 +198,11 @@ return 0; } -static int -e1000_ethtool_gpause(struct e1000_adapter *adapter, +static void +e1000_get_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *epause) { + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; epause->autoneg = @@ -212,14 +216,13 @@ epause->rx_pause = 1; epause->tx_pause = 1; } - - return 0; } static int -e1000_ethtool_spause(struct e1000_adapter *adapter, +e1000_set_pauseparam(struct net_device *netdev, struct ethtool_pauseparam *epause) { + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; adapter->fc_autoneg = epause->autoneg; @@ -248,28 +251,117 @@ return 0; } +static u32 +e1000_get_rx_csum(struct net_device *netdev) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + return adapter->rx_csum; +} + +static int +e1000_set_rx_csum(struct net_device *netdev, u32 data) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + + adapter->rx_csum = data; + if(netif_running(netdev)) { + e1000_down(adapter); + e1000_up(adapter); + } else + e1000_reset(adapter); + return 0; +} + +static u32 +e1000_get_tx_csum(struct net_device *netdev) +{ + return (netdev->features & NETIF_F_HW_CSUM) != 0; +} + +static int +e1000_set_tx_csum(struct net_device *netdev, u32 data) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + + if(adapter->hw.mac_type < e1000_82543) + return data ? -EINVAL : 0; + + if (data) + netdev->features |= NETIF_F_HW_CSUM; + else + netdev->features &= ~NETIF_F_HW_CSUM; + return 0; +} + +static u32 +e1000_get_sg(struct net_device *netdev) +{ + return (netdev->features & NETIF_F_SG) != 0; +} + +static int +e1000_set_sg(struct net_device *netdev, u32 data) +{ + if (data) + netdev->features |= NETIF_F_SG; + else + netdev->features &= ~NETIF_F_SG; + return 0; +} + +static u32 +e1000_get_tso(struct net_device *netdev) +{ + return (netdev->features & NETIF_F_TSO); +} + +static int +e1000_set_tso(struct net_device *netdev, u32 data) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + + if (adapter->hw.mac_type < e1000_82544 || + adapter->hw.mac_type == e1000_82547) + return data ? -EINVAL : 0; + + if (data) + netdev->features |= NETIF_F_TSO; + else + netdev->features &= ~NETIF_F_TSO; + return 0; +} + + static void -e1000_ethtool_gdrvinfo(struct e1000_adapter *adapter, - struct ethtool_drvinfo *drvinfo) +e1000_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *drvinfo) { + struct e1000_adapter *adapter = netdev_priv(dev); + strncpy(drvinfo->driver, e1000_driver_name, 32); strncpy(drvinfo->version, e1000_driver_version, 32); strncpy(drvinfo->fw_version, "N/A", 32); strncpy(drvinfo->bus_info, pci_name(adapter->pdev), 32); - drvinfo->n_stats = E1000_STATS_LEN; - drvinfo->testinfo_len = E1000_TEST_LEN; +} + +static int +e1000_get_regs_len(struct net_device *dev) +{ #define E1000_REGS_LEN 32 - drvinfo->regdump_len = E1000_REGS_LEN * sizeof(uint32_t); - drvinfo->eedump_len = adapter->hw.eeprom.word_size * 2; + return E1000_REGS_LEN * sizeof(uint32_t); } static void -e1000_ethtool_gregs(struct e1000_adapter *adapter, - struct ethtool_regs *regs, uint32_t *regs_buff) +e1000_get_regs(struct net_device *dev, + struct ethtool_regs *regs, void *p) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; + u32 *regs_buff = p; uint16_t phy_data; + memset(p, 0, E1000_REGS_LEN * sizeof(uint32_t)); + regs->version = (1 << 24) | (hw->revision_id << 16) | hw->device_id; regs_buff[0] = E1000_READ_REG(hw, CTRL); @@ -342,30 +434,36 @@ e1000_read_phy_reg(hw, PHY_1000T_STATUS, &phy_data); regs_buff[24] = (uint32_t)phy_data; /* phy local receiver status */ regs_buff[25] = regs_buff[24]; /* phy remote receiver status */ +} + +static int +e1000_get_eeprom_len(struct net_device *dev) +{ + struct e1000_adapter *adapter = netdev_priv(dev); - return; + return adapter->hw.eeprom.word_size * 2; } static int -e1000_ethtool_geeprom(struct e1000_adapter *adapter, - struct ethtool_eeprom *eeprom, uint16_t *eeprom_buff) +e1000_get_eeprom(struct net_device *dev, + struct ethtool_eeprom *eeprom, u8 *bytes) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; + uint16_t *eeprom_buff = (uint16_t *) bytes; int first_word, last_word; int ret_val = 0; uint16_t i; - if(eeprom->len == 0) { - ret_val = -EINVAL; - goto geeprom_error; - } + if(eeprom->len == 0) + return -EINVAL; eeprom->magic = hw->vendor_id | (hw->device_id << 16); - if(eeprom->offset > eeprom->offset + eeprom->len) { - ret_val = -EINVAL; - goto geeprom_error; - } + if(eeprom->offset > eeprom->offset + eeprom->len) + return -EINVAL; + + memset(bytes, 0, adapter->hw.eeprom.word_size*2); if((eeprom->offset + eeprom->len) > (hw->eeprom.word_size * 2)) eeprom->len = ((hw->eeprom.word_size * 2) - eeprom->offset); @@ -388,14 +486,14 @@ for (i = 0; i < last_word - first_word + 1; i++) le16_to_cpus(&eeprom_buff[i]); -geeprom_error: return ret_val; } static int -e1000_ethtool_seeprom(struct e1000_adapter *adapter, - struct ethtool_eeprom *eeprom, void *user_data) +e1000_set_eeprom(struct net_device *netdev, + struct ethtool_eeprom *eeprom, u8 *bytes) { + struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; uint16_t *eeprom_buff; void *ptr; @@ -439,11 +537,7 @@ for (i = 0; i < last_word - first_word + 1; i++) le16_to_cpus(&eeprom_buff[i]); - if((ret_val != 0) || copy_from_user(ptr, user_data, eeprom->len)) { - ret_val = -EFAULT; - goto seeprom_error; - } - + memcpy(ptr, bytes, eeprom->len); for (i = 0; i < last_word - first_word + 1; i++) eeprom_buff[i] = cpu_to_le16(eeprom_buff[i]); @@ -454,15 +548,15 @@ if((ret_val == 0) && first_word <= EEPROM_CHECKSUM_REG) e1000_update_eeprom_checksum(hw); -seeprom_error: kfree(eeprom_buff); return ret_val; } -static int -e1000_ethtool_gring(struct e1000_adapter *adapter, +static void +e1000_get_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { + struct e1000_adapter *adapter = netdev_priv(netdev); e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; struct e1000_desc_ring *rxdr = &adapter->rx_ring; @@ -477,13 +571,12 @@ ring->tx_pending = txdr->count; ring->rx_mini_pending = 0; ring->rx_jumbo_pending = 0; - - return 0; } + static int -e1000_ethtool_sring(struct e1000_adapter *adapter, - struct ethtool_ringparam *ring) +e1000_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring) { + struct e1000_adapter *adapter = netdev_priv(netdev); int err; e1000_mac_type mac_type = adapter->hw.mac_type; struct e1000_desc_ring *txdr = &adapter->tx_ring; @@ -806,8 +899,6 @@ kfree(txdr->buffer_info); if(rxdr->buffer_info) kfree(rxdr->buffer_info); - - return; } static int @@ -939,8 +1030,6 @@ e1000_write_phy_reg(&adapter->hw, 30, 0x8FFC); e1000_write_phy_reg(&adapter->hw, 29, 0x001A); e1000_write_phy_reg(&adapter->hw, 30, 0x8FF0); - - return; } static void @@ -1257,11 +1346,19 @@ return *data; } + static int -e1000_ethtool_test(struct e1000_adapter *adapter, - struct ethtool_test *eth_test, uint64_t *data) +e1000_diag_test_count(struct net_device *dev) { - boolean_t if_running = netif_running(adapter->netdev); + return E1000_TEST_LEN; +} + +static void +e1000_diag_test(struct net_device *netdev, + struct ethtool_test *eth_test, u64 *data) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + boolean_t if_running = netif_running(netdev); if(eth_test->flags == ETH_TEST_FL_OFFLINE) { /* Offline tests */ @@ -1305,12 +1402,12 @@ data[2] = 0; data[3] = 0; } - return 0; } static void -e1000_ethtool_gwol(struct e1000_adapter *adapter, struct ethtool_wolinfo *wol) +e1000_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; switch(adapter->hw.device_id) { @@ -1348,10 +1445,10 @@ return; } } - static int -e1000_ethtool_swol(struct e1000_adapter *adapter, struct ethtool_wolinfo *wol) +e1000_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol) { + struct e1000_adapter *adapter = netdev_priv(dev); struct e1000_hw *hw = &adapter->hw; switch(adapter->hw.device_id) { @@ -1408,8 +1505,13 @@ } static int -e1000_ethtool_led_blink(struct e1000_adapter *adapter, struct ethtool_value *id) +e1000_phys_id(struct net_device *netdev, u32 data) { + struct e1000_adapter *adapter = netdev_priv(netdev); + + if(!data || data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ)) + data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ); + if(!adapter->blink_timer.function) { init_timer(&adapter->blink_timer); adapter->blink_timer.function = e1000_led_blink_callback; @@ -1420,11 +1522,7 @@ mod_timer(&adapter->blink_timer, jiffies); set_current_state(TASK_INTERRUPTIBLE); - if(id->data) - schedule_timeout(id->data * HZ); - else - schedule_timeout(MAX_SCHEDULE_TIMEOUT); - + schedule_timeout(data * HZ); del_timer_sync(&adapter->blink_timer); e1000_led_off(&adapter->hw); clear_bit(E1000_LED_ON, &adapter->led_status); @@ -1433,342 +1531,96 @@ return 0; } -int -e1000_ethtool_ioctl(struct net_device *netdev, struct ifreq *ifr) +static int +e1000_nway_reset(struct net_device *netdev) { - struct e1000_adapter *adapter = netdev->priv; - void *addr = ifr->ifr_data; - uint32_t cmd; - - if(get_user(cmd, (uint32_t *) addr)) - return -EFAULT; - - switch(cmd) { - case ETHTOOL_GSET: { - struct ethtool_cmd ecmd = {ETHTOOL_GSET}; - e1000_ethtool_gset(adapter, &ecmd); - if(copy_to_user(addr, &ecmd, sizeof(ecmd))) - return -EFAULT; - return 0; - } - case ETHTOOL_SSET: { - struct ethtool_cmd ecmd; - if(copy_from_user(&ecmd, addr, sizeof(ecmd))) - return -EFAULT; - return e1000_ethtool_sset(adapter, &ecmd); - } - case ETHTOOL_GDRVINFO: { - struct ethtool_drvinfo drvinfo = {ETHTOOL_GDRVINFO}; - e1000_ethtool_gdrvinfo(adapter, &drvinfo); - if(copy_to_user(addr, &drvinfo, sizeof(drvinfo))) - return -EFAULT; - return 0; - } - case ETHTOOL_GSTRINGS: { - struct ethtool_gstrings gstrings = { ETHTOOL_GSTRINGS }; - char *strings = NULL; - int err = 0; - - if(copy_from_user(&gstrings, addr, sizeof(gstrings))) - return -EFAULT; - switch(gstrings.string_set) { - case ETH_SS_TEST: - gstrings.len = E1000_TEST_LEN; - strings = kmalloc(E1000_TEST_LEN * ETH_GSTRING_LEN, - GFP_KERNEL); - if(!strings) - return -ENOMEM; - memcpy(strings, e1000_gstrings_test, E1000_TEST_LEN * - ETH_GSTRING_LEN); - break; - case ETH_SS_STATS: { - int i; - gstrings.len = E1000_STATS_LEN; - strings = kmalloc(E1000_STATS_LEN * ETH_GSTRING_LEN, - GFP_KERNEL); - if(!strings) - return -ENOMEM; - for(i=0; i < E1000_STATS_LEN; i++) { - memcpy(&strings[i * ETH_GSTRING_LEN], - e1000_gstrings_stats[i].stat_string, - ETH_GSTRING_LEN); - } - break; - } - default: - return -EOPNOTSUPP; - } - if(copy_to_user(addr, &gstrings, sizeof(gstrings))) - err = -EFAULT; - addr += offsetof(struct ethtool_gstrings, data); - if(!err && copy_to_user(addr, strings, - gstrings.len * ETH_GSTRING_LEN)) - err = -EFAULT; - - kfree(strings); - return err; - } - case ETHTOOL_GREGS: { - struct ethtool_regs regs = {ETHTOOL_GREGS}; - uint32_t regs_buff[E1000_REGS_LEN]; - - if(copy_from_user(®s, addr, sizeof(regs))) - return -EFAULT; - e1000_ethtool_gregs(adapter, ®s, regs_buff); - if(copy_to_user(addr, ®s, sizeof(regs))) - return -EFAULT; - - addr += offsetof(struct ethtool_regs, data); - if(copy_to_user(addr, regs_buff, regs.len)) - return -EFAULT; - - return 0; - } - case ETHTOOL_NWAY_RST: { - if(netif_running(netdev)) { - e1000_down(adapter); - e1000_up(adapter); - } - return 0; - } - case ETHTOOL_PHYS_ID: { - struct ethtool_value id; - if(copy_from_user(&id, addr, sizeof(id))) - return -EFAULT; - return e1000_ethtool_led_blink(adapter, &id); - } - case ETHTOOL_GLINK: { - struct ethtool_value link = {ETHTOOL_GLINK}; - link.data = netif_carrier_ok(netdev); - if(copy_to_user(addr, &link, sizeof(link))) - return -EFAULT; - return 0; - } - case ETHTOOL_GWOL: { - struct ethtool_wolinfo wol = {ETHTOOL_GWOL}; - e1000_ethtool_gwol(adapter, &wol); - if(copy_to_user(addr, &wol, sizeof(wol)) != 0) - return -EFAULT; - return 0; - } - case ETHTOOL_SWOL: { - struct ethtool_wolinfo wol; - if(copy_from_user(&wol, addr, sizeof(wol)) != 0) - return -EFAULT; - return e1000_ethtool_swol(adapter, &wol); - } - case ETHTOOL_GEEPROM: { - struct ethtool_eeprom eeprom = {ETHTOOL_GEEPROM}; - struct e1000_hw *hw = &adapter->hw; - uint16_t *eeprom_buff; - void *ptr; - int err = 0; - - if(copy_from_user(&eeprom, addr, sizeof(eeprom))) - return -EFAULT; - - eeprom_buff = kmalloc(hw->eeprom.word_size * 2, GFP_KERNEL); - - if(!eeprom_buff) - return -ENOMEM; - - if((err = e1000_ethtool_geeprom(adapter, &eeprom, - eeprom_buff))) - goto err_geeprom_ioctl; - - if(copy_to_user(addr, &eeprom, sizeof(eeprom))) { - err = -EFAULT; - goto err_geeprom_ioctl; - } - - addr += offsetof(struct ethtool_eeprom, data); - ptr = ((void *)eeprom_buff) + (eeprom.offset & 1); - - if(copy_to_user(addr, ptr, eeprom.len)) - err = -EFAULT; - -err_geeprom_ioctl: - kfree(eeprom_buff); - return err; - } - case ETHTOOL_SEEPROM: { - struct ethtool_eeprom eeprom; - - if(copy_from_user(&eeprom, addr, sizeof(eeprom))) - return -EFAULT; - - addr += offsetof(struct ethtool_eeprom, data); - return e1000_ethtool_seeprom(adapter, &eeprom, addr); - } - case ETHTOOL_GRINGPARAM: { - struct ethtool_ringparam ering = {ETHTOOL_GRINGPARAM}; - e1000_ethtool_gring(adapter, &ering); - if(copy_to_user(addr, &ering, sizeof(ering))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRINGPARAM: { - struct ethtool_ringparam ering; - if(copy_from_user(&ering, addr, sizeof(ering))) - return -EFAULT; - return e1000_ethtool_sring(adapter, &ering); - } - case ETHTOOL_GPAUSEPARAM: { - struct ethtool_pauseparam epause = {ETHTOOL_GPAUSEPARAM}; - e1000_ethtool_gpause(adapter, &epause); - if(copy_to_user(addr, &epause, sizeof(epause))) - return -EFAULT; - return 0; - } - case ETHTOOL_SPAUSEPARAM: { - struct ethtool_pauseparam epause; - if(copy_from_user(&epause, addr, sizeof(epause))) - return -EFAULT; - return e1000_ethtool_spause(adapter, &epause); - } - case ETHTOOL_GSTATS: { - struct { - struct ethtool_stats eth_stats; - uint64_t data[E1000_STATS_LEN]; - } stats = { {ETHTOOL_GSTATS, E1000_STATS_LEN} }; - int i; - - e1000_update_stats(adapter); - for(i = 0; i < E1000_STATS_LEN; i++) - stats.data[i] = (e1000_gstrings_stats[i].sizeof_stat == - sizeof(uint64_t)) ? - *(uint64_t *)((char *)adapter + - e1000_gstrings_stats[i].stat_offset) : - *(uint32_t *)((char *)adapter + - e1000_gstrings_stats[i].stat_offset); - if(copy_to_user(addr, &stats, sizeof(stats))) - return -EFAULT; - return 0; - } - case ETHTOOL_TEST: { - struct { - struct ethtool_test eth_test; - uint64_t data[E1000_TEST_LEN]; - } test = { {ETHTOOL_TEST} }; - int err; - - if(copy_from_user(&test.eth_test, addr, sizeof(test.eth_test))) - return -EFAULT; - - test.eth_test.len = E1000_TEST_LEN; - - if((err = e1000_ethtool_test(adapter, &test.eth_test, - test.data))) - return err; - - if(copy_to_user(addr, &test, sizeof(test)) != 0) - return -EFAULT; - return 0; - } - case ETHTOOL_GRXCSUM: { - struct ethtool_value edata = { ETHTOOL_GRXCSUM }; - - edata.data = adapter->rx_csum; - if (copy_to_user(addr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_SRXCSUM: { - struct ethtool_value edata; - - if (copy_from_user(&edata, addr, sizeof(edata))) - return -EFAULT; - adapter->rx_csum = edata.data; - if(netif_running(netdev)) { - e1000_down(adapter); - e1000_up(adapter); - } else - e1000_reset(adapter); - return 0; - } - case ETHTOOL_GTXCSUM: { - struct ethtool_value edata = { ETHTOOL_GTXCSUM }; + struct e1000_adapter *adapter = netdev_priv(netdev); - edata.data = - (netdev->features & NETIF_F_HW_CSUM) != 0; - if (copy_to_user(addr, &edata, sizeof(edata))) - return -EFAULT; - return 0; + if(netif_running(netdev)) { + e1000_down(adapter); + e1000_up(adapter); } - case ETHTOOL_STXCSUM: { - struct ethtool_value edata; + return 0; +} - if (copy_from_user(&edata, addr, sizeof(edata))) - return -EFAULT; +static u32 +e1000_get_link(struct net_device *netdev) +{ + return netif_carrier_ok(netdev); +} - if(adapter->hw.mac_type < e1000_82543) { - if (edata.data != 0) - return -EINVAL; - return 0; - } - if (edata.data) - netdev->features |= NETIF_F_HW_CSUM; - else - netdev->features &= ~NETIF_F_HW_CSUM; +static int +e1000_get_stats_count(struct net_device *dev) +{ + return E1000_STATS_LEN; +} - return 0; - } - case ETHTOOL_GSG: { - struct ethtool_value edata = { ETHTOOL_GSG }; +static void +e1000_get_ethtool_stats(struct net_device *netdev, + struct ethtool_stats *stats, u64 *data) +{ + struct e1000_adapter *adapter = netdev_priv(netdev); + int i; - edata.data = - (netdev->features & NETIF_F_SG) != 0; - if (copy_to_user(addr, &edata, sizeof(edata))) - return -EFAULT; - return 0; + e1000_update_stats(adapter); + for(i = 0; i < E1000_STATS_LEN; i++) { + char *p = (char *) adapter + e1000_gstrings_stats[i].stat_offset; + data[i] = (e1000_gstrings_stats[i].sizeof_stat == sizeof(uint64_t)) + ? *(uint64_t *)p : *(uint32_t *)p; } - case ETHTOOL_SSG: { - struct ethtool_value edata; - - if (copy_from_user(&edata, addr, sizeof(edata))) - return -EFAULT; - - if (edata.data) - netdev->features |= NETIF_F_SG; - else - netdev->features &= ~NETIF_F_SG; +} - return 0; - } -#ifdef NETIF_F_TSO - case ETHTOOL_GTSO: { - struct ethtool_value edata = { ETHTOOL_GTSO }; - - edata.data = (netdev->features & NETIF_F_TSO) != 0; - if (copy_to_user(addr, &edata, sizeof(edata))) - return -EFAULT; - return 0; - } - case ETHTOOL_STSO: { - struct ethtool_value edata; +static void +e1000_get_strings(struct net_device *netdev, u32 string_set, u8 *data) +{ + int i; - if (copy_from_user(&edata, addr, sizeof(edata))) - return -EFAULT; + switch(string_set) { + case ETH_SS_TEST: + memcpy(data, e1000_gstrings_test, E1000_TEST_LEN * ETH_GSTRING_LEN); + break; - if ((adapter->hw.mac_type < e1000_82544) || - (adapter->hw.mac_type == e1000_82547)) { - if (edata.data != 0) - return -EINVAL; - return 0; + case ETH_SS_STATS: + for(i=0; i < E1000_STATS_LEN; i++) { + memcpy(data + i * ETH_GSTRING_LEN, + e1000_gstrings_stats[i].stat_string, + ETH_GSTRING_LEN); } - - if (edata.data) - netdev->features |= NETIF_F_TSO; - else - netdev->features &= ~NETIF_F_TSO; - - return 0; - } -#endif - default: - return -EOPNOTSUPP; + break; } } +struct ethtool_ops e1000_ethtool_ops = { + .get_settings = e1000_get_settings, + .set_settings = e1000_set_settings, + .get_drvinfo = e1000_get_drvinfo, + .get_regs_len = e1000_get_regs_len, + .get_regs = e1000_get_regs, + .get_wol = e1000_get_wol, + .set_wol = e1000_set_wol, + .nway_reset = e1000_nway_reset, + .get_link = e1000_get_link, + .get_eeprom_len = e1000_get_eeprom_len, + .get_eeprom = e1000_get_eeprom, + .set_eeprom = e1000_set_eeprom, + .get_ringparam = e1000_get_ringparam, + .set_ringparam = e1000_set_ringparam, + .get_pauseparam = e1000_get_pauseparam, + .set_pauseparam = e1000_set_pauseparam, + .get_rx_csum = e1000_get_rx_csum, + .set_rx_csum = e1000_set_rx_csum, + .get_tx_csum = e1000_get_tx_csum, + .set_tx_csum = e1000_set_tx_csum, + .get_sg = e1000_get_sg, + .set_sg = e1000_set_sg, + .get_tso = e1000_get_tso, + .set_tso = e1000_set_tso, + .self_test_count = e1000_diag_test_count, + .self_test = e1000_diag_test, + .get_strings = e1000_get_strings, + .phys_id = e1000_phys_id, + .get_stats_count = e1000_get_stats_count, + .get_ethtool_stats = e1000_get_ethtool_stats, +}; diff -Nru a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c --- a/drivers/net/e1000/e1000_main.c Fri Apr 16 15:50:02 2004 +++ b/drivers/net/e1000/e1000_main.c Fri Apr 16 15:50:02 2004 @@ -167,9 +167,9 @@ static boolean_t e1000_clean_rx_irq(struct e1000_adapter *adapter); #endif static void e1000_alloc_rx_buffers(struct e1000_adapter *adapter); -static int e1000_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd); -static int e1000_mii_ioctl(struct net_device *netdev, struct ifreq *ifr, - int cmd); + +static int e1000_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd); +extern struct ethtool_ops e1000_ethtool_ops; static void e1000_enter_82542_rst(struct e1000_adapter *adapter); static void e1000_leave_82542_rst(struct e1000_adapter *adapter); static inline void e1000_rx_checksum(struct e1000_adapter *adapter, @@ -206,7 +206,6 @@ /* Exported from other modules */ extern void e1000_check_options(struct e1000_adapter *adapter); -extern int e1000_ethtool_ioctl(struct net_device *netdev, struct ifreq *ifr); static struct pci_driver e1000_driver = { .name = e1000_driver_name, @@ -445,7 +444,8 @@ netdev->set_multicast_list = &e1000_set_multi; netdev->set_mac_address = &e1000_set_mac; netdev->change_mtu = &e1000_change_mtu; - netdev->do_ioctl = &e1000_ioctl; + netdev->do_ioctl = &e1000_do_ioctl; + SET_ETHTOOL_OPS(netdev, &e1000_ethtool_ops); netdev->tx_timeout = &e1000_tx_timeout; netdev->watchdog_timeo = 5 * HZ; #ifdef CONFIG_E1000_NAPI @@ -2498,37 +2498,16 @@ adapter->smartspeed = 0; } -/** - * e1000_ioctl - - * @netdev: - * @ifreq: - * @cmd: - **/ - -static int -e1000_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd) -{ - switch (cmd) { - case SIOCGMIIPHY: - case SIOCGMIIREG: - case SIOCSMIIREG: - return e1000_mii_ioctl(netdev, ifr, cmd); - case SIOCETHTOOL: - return e1000_ethtool_ioctl(netdev, ifr); - default: - return -EOPNOTSUPP; - } -} /** - * e1000_mii_ioctl - + * e1000_do_ioctl - * @netdev: * @ifreq: * @cmd: **/ static int -e1000_mii_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd) +e1000_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd) { struct e1000_adapter *adapter = netdev->priv; struct mii_ioctl_data *data = (struct mii_ioctl_data *)&ifr->ifr_data; From scott.feldman@intel.com Fri Apr 16 16:15:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 16 Apr 2004 16:15:17 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GNFAKO025643 for ; Fri, 16 Apr 2004 16:15:14 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3GNEtEA026019; Fri, 16 Apr 2004 23:14:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3GNE6qa009479; Fri, 16 Apr 2004 23:14:09 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004041616145113608 ; Fri, 16 Apr 2004 16:14:51 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 16 Apr 2004 16:14:50 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [PATCH] e1000 ethtool_ops support Date: Fri, 16 Apr 2004 16:14:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] e1000 ethtool_ops support Thread-Index: AcQkBdSy04efEMVVT3+aSX4thCr98AAAl05w From: "Feldman, Scott" To: "Stephen Hemminger" , "Jeff Garzik" , "Chris Wright" , "Cramer, Jeb J" , "Venkatesan, Ganesh" , "Ronciak, John" Cc: X-OriginalArrivalTime: 16 Apr 2004 23:14:50.0912 (UTC) FILETIME=[9E673A00:01C42408] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3GNFAKO025643 X-archive-position: 4716 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 175 Lines: 7 > Okay, here is a first cut at ethtool ops integration for e1000. Thanks Stephen! This will be nice to get off the TODO list. Forwarding to John/Ganesh to review. -scott From andy.furniss@dsl.pipex.com Sat Apr 17 03:39:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Apr 2004 03:39:34 -0700 (PDT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HAdRKO016053 for ; Sat, 17 Apr 2004 03:39:27 -0700 Received: from dsl.pipex.com (81-178-208-246.dsl.pipex.com [81.178.208.246]) by pengo.systems.pipex.net (Postfix) with ESMTP id 897184C00068; Sat, 17 Apr 2004 11:39:19 +0100 (BST) Message-ID: <40810957.6030209@dsl.pipex.com> Date: Sat, 17 Apr 2004 11:39:19 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> In-Reply-To: <1082145341.1026.125.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4717 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1488 Lines: 42 jamal wrote: > On Fri, 2004-04-16 at 15:35, Andy Furniss wrote: > > >>This is what I wanted to know. Is it possible to make an option to get >>them after NAT in and pre NAT out? > > > No i dont plan to. Why do you want to go that path? I think it's the only way I can shape/share my ingress traffic between a process (eg. bittorrent/squid) running on my shaping machine and traffic that is forwarded to my LAN. I masquerade onto one real dynamic IP. In the case of pre nat outbound - I know people can mark pre NAT and shape on that, but it would allow people with big LANs doing NAT to use WRR/ESFQ on src for egress traffic. > > >>I don't think this applies to my setup Masqerading many local onto one >>real address. > > > If you have local on eth0(or substitute with whatever device you have > local on), the example i gave should work fine. You just have to change > the way you approach the setup. In case i didnt understand you, please > post the details of your setup. My setup is very simple - the only reason I use IMQ+NAT patch is because I want to use my gateway/shaping PC to run bittorrent and I want the LAN machines to have priority/fair share of incoming traffic. I guess my setup is not that common - more common are people who run squid on the same PC they shape/do NAT on. ppp0 one dynamic real IP -> gateway PC -> eth0 -> LAN 192.168.0.0/24 | -> local process. Andy. From hadi@cyberus.ca Sat Apr 17 05:10:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Apr 2004 05:10:49 -0700 (PDT) Received: from mx03.cybersurf.com (mx03.cybersurf.com [209.197.145.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HCAhKO021314 for ; Sat, 17 Apr 2004 05:10:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx03.cybersurf.com with esmtp (Exim 4.20) id 1BEoez-0003j4-7h for netdev@oss.sgi.com; Sat, 17 Apr 2004 08:11:01 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BEoea-00019P-Vk; Sat, 17 Apr 2004 08:10:37 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <40810957.6030209@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082203795.1043.18.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Apr 2004 08:09:55 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4718 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 2300 Lines: 53 On Sat, 2004-04-17 at 06:39, Andy Furniss wrote: > > No i dont plan to. Why do you want to go that path? > > I think it's the only way I can shape/share my ingress traffic between a > process (eg. bittorrent/squid) running on my shaping machine and > traffic that is forwarded to my LAN. I masquerade onto one real dynamic IP. I think i am almost understanding you now. Your main concern is people using bittorrent to upload to you, correct? Is there a way to recognize packets going to/from bittorent? > In the case of pre nat outbound - I know people can mark pre NAT and > shape on that, but it would allow people with big LANs doing NAT to use > WRR/ESFQ on src for egress traffic. Dont jump into the HOW; lets get to your setup and dissect it. Like i said, dont think in terms of IMQ but still think in terms of meeting your requirements. Your setup is certainly new to me (at least from what i have been told or read on how people use IMQ) - so thanks for posting. This is the kind of thing i needed to hear about. > My setup is very simple - the only reason I use IMQ+NAT patch is because > I want to use my gateway/shaping PC to run bittorrent and I want the LAN > machines to have priority/fair share of incoming traffic. I guess my > setup is not that common - more common are people who run squid on the > same PC they shape/do NAT on. > > ppp0 one dynamic real IP -> gateway PC -> eth0 -> LAN 192.168.0.0/24 > | > -> local process. Ok good. Assuming you have attached your HTB etc on one or more dummy devices. - packets from local Lan can be marked at ingress and redirect to a dummy if needed. Infact you can do this on the egress at ppp0 as well using the new tc -i that i introduced. So this is easy. - packets from the bittorent process can be marked by iptables before they get NATed (is this right?). Such packets can then be redirected to dummy from egress of ppp0 using fw classifier. So again this is easy. - The third path is packets that come in from ppp0, get demasquareded, then have to either go a) to the LAN/eth0 or b)localhost bittorent process. You want to restrict b) - is that correct? I have some suggestion, but need you to verify this part. cheers, jamal From ja@ssi.bg Sat Apr 17 06:25:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Apr 2004 06:25:13 -0700 (PDT) Received: from u.domain.uli (ja.ssi.bg [217.79.71.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HDP3KO022870 for ; Sat, 17 Apr 2004 06:25:06 -0700 Received: from localhost (localhost [127.0.0.1]) by u.domain.uli (8.12.10/8.12.10) with ESMTP id i3HDQ9eV005264; Sat, 17 Apr 2004 16:26:10 +0300 Date: Sat, 17 Apr 2004 16:26:09 +0300 (EEST) From: Julian Anastasov X-X-Sender: ja@u.domain.uli To: coreteam@netfilter.org cc: netfilter-devel@lists.netfilter.org, netdev@oss.sgi.com Subject: [2.4/2.6] ip_nat_ftp - manip at the right place Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1607745702-453966119-1082208369=:3263" X-archive-position: 4719 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ja@ssi.bg Precedence: bulk X-list: netdev Content-Length: 2629 Lines: 61 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1607745702-453966119-1082208369=:3263 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, The attached patch changes the way the ip_nat_ftp helper manipulates the packets: - no manips => no fixup - check the direction, do manip once and at the same time when the headers are changed This is needed mostly for IPVS setups and I hope we do not create troubles for other setups or FTP software. I'm not sure whether proper locking for 'info' is needed, may be not. Tested for SNAT, DNAT, passive, active. Regards -- Julian Anastasov --1607745702-453966119-1082208369=:3263 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="nat_ftp-1.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: ip_nat_ftp - change manip Content-Disposition: attachment; filename="nat_ftp-1.diff" LS0tIHYyLjYuNS9saW51eC9uZXQvaXB2NC9uZXRmaWx0ZXIvaXBfbmF0X2Z0 cC5jCTIwMDQtMDItMTkgMDA6MTM6MzguMDAwMDAwMDAwICswMjAwDQorKysg bGludXgvbmV0L2lwdjQvbmV0ZmlsdGVyL2lwX25hdF9mdHAuYwkyMDA0LTA0 LTE3IDExOjQ0OjE0LjQ3MTA3NDY4OCArMDMwMA0KQEAgLTI1MCwxNyArMjUw LDIzIEBADQogCXVuc2lnbmVkIGludCBkYXRhbGVuOw0KIAlpbnQgZGlyOw0K IAlzdHJ1Y3QgaXBfY3RfZnRwX2V4cGVjdCAqY3RfZnRwX2luZm87DQorCWlu dCBpLCBkb19tYW5pcCA9IDA7DQogDQogCWlmICghZXhwKQ0KIAkJREVCVUdQ KCJpcF9uYXRfZnRwOiBubyBleHAhISIpOw0KIA0KIAljdF9mdHBfaW5mbyA9 ICZleHAtPmhlbHAuZXhwX2Z0cF9pbmZvOw0KIA0KLQkvKiBPbmx5IG1hbmds ZSB0aGluZ3Mgb25jZTogb3JpZ2luYWwgZGlyZWN0aW9uIGluIFBPU1RfUk9V VElORw0KLQkgICBhbmQgcmVwbHkgZGlyZWN0aW9uIG9uIFBSRV9ST1VUSU5H LiAqLw0KKwkvKiBPbmx5IG1hbmdsZSB0aGluZ3Mgb25jZTogZm9yIHRoZSBm aXJzdCBtYW5pcCBpbiB0aGlzIGRpcmVjdGlvbi4gKi8NCiAJZGlyID0gQ1RJ TkZPMkRJUihjdGluZm8pOw0KLQlpZiAoISgoaG9va251bSA9PSBORl9JUF9Q T1NUX1JPVVRJTkcgJiYgZGlyID09IElQX0NUX0RJUl9PUklHSU5BTCkNCi0J ICAgICAgfHwgKGhvb2tudW0gPT0gTkZfSVBfUFJFX1JPVVRJTkcgJiYgZGly ID09IElQX0NUX0RJUl9SRVBMWSkpKSB7DQorCWZvciAoaSA9IDA7IGkgPCBp bmZvLT5udW1fbWFuaXBzOyBpKyspIHsNCisJCWlmIChpbmZvLT5tYW5pcHNb aV0uZGlyZWN0aW9uID09IGRpcikgew0KKwkJCWlmIChpbmZvLT5tYW5pcHNb aV0uaG9va251bSA9PSBob29rbnVtKQ0KKwkJCQlkb19tYW5pcCA9IDE7DQor CQkJYnJlYWs7DQorCQl9DQorCX0NCisJaWYgKCFkb19tYW5pcCkgew0KIAkJ REVCVUdQKCJuYXRfZnRwOiBOb3QgdG91Y2hpbmcgZGlyICVzIGF0IGhvb2sg JXNcbiIsDQogCQkgICAgICAgZGlyID09IElQX0NUX0RJUl9PUklHSU5BTCA/ ICJPUklHIiA6ICJSRVBMWSIsDQogCQkgICAgICAgaG9va251bSA9PSBORl9J UF9QT1NUX1JPVVRJTkcgPyAiUE9TVFJPVVRJTkciDQo= --1607745702-453966119-1082208369=:3263-- From jbondjr@gambit.implode.net Sat Apr 17 13:20:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Apr 2004 13:20:54 -0700 (PDT) Received: from cyclops.implode.net (Debian-exim@d216-232-206-119.bchsia.telus.net [216.232.206.119]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HKKrKO003585 for ; Sat, 17 Apr 2004 13:20:53 -0700 Received: from gambit.implode.net ([192.168.1.2]) by cyclops.implode.net with esmtp (Exim 4.30) id 1BEwIw-0005XS-SB; Sat, 17 Apr 2004 13:20:46 -0700 Received: from jbondjr by gambit.implode.net with local (Exim 4.31) id 1BEwIt-0001Sn-K6; Sat, 17 Apr 2004 13:20:43 -0700 Date: Sat, 17 Apr 2004 13:20:43 -0700 From: John Wong To: Manfred Spraul Cc: c-d.hailfinger.kernel.2004@gmx.net, netdev@oss.sgi.com Subject: Re: forcedeth and kernel 2.6.5 has "no link" Message-ID: <20040417202043.GA5282@gambit.implode.net> References: <20040416183844.GA2923@gambit.implode.net> <40802EC0.2070108@colorfullife.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40802EC0.2070108@colorfullife.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 4720 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kernel@implode.net Precedence: bulk X-list: netdev Content-Length: 1531 Lines: 62 Hi, After applying the patch to 2.6.5, I still get the timeouts: NETDEV WATCHDOG: eth1: transmit timed out eth1: tx_timeout: dead entries! NETDEV WATCHDOG: eth1: transmit timed out eth1: tx_timeout: dead entries! John On Fri, Apr 16, 2004 at 09:06:40PM +0200, Manfred Spraul wrote: > John Wong wrote: > > >Under kernel 2.6.4, ethtool reports: > > > >Settings for eth0: > > Link detected: yes > > > >This is with forcedeth 0.23 > > > >Under kernel 2.6.5, ethtool reports: > > > >Settings for eth0: > > Supports Wake-on: g > > Wake-on: d > > Link detected: no > > > >This is with forcedeth 0.25 > > > > > Odd. I'm not aware of any changes that might cause that difference. I'll > check the diff. > > >I had submitted the bugzilla id 2283. 2496 is something that I am > >experiencing too. > > > > > Could you try the attached patch? > > > -- > Manfred > --- 2.6/drivers/net/forcedeth.c 2004-04-10 09:52:45.000000000 +0200 > +++ build-2.6/drivers/net/forcedeth.c 2004-04-13 18:58:59.000000000 +0200 > @@ -1263,6 +1263,14 @@ > dev->name, id1, id2, i); > np->phyaddr = i; > > + if (id1 == 0x0015 && (id2 &0xfff0) == 0xf440) { > + printk(KERN_DEBUG "%s: open: Found ICS, applying workaround.\n", dev->name); > + /* workaround for ICS1893 PHY */ > + mii_rw(dev, i, 0x0018, 0xD200); > + set_current_state(TASK_UNINTERRUPTIBLE); > + schedule_timeout(HZ); > + } > + > spin_lock_irq(&np->lock); > nv_update_linkspeed(dev); > spin_unlock_irq(&np->lock); From andy.furniss@dsl.pipex.com Sat Apr 17 14:57:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 17 Apr 2004 14:57:13 -0700 (PDT) Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HLuxKO006077 for ; Sat, 17 Apr 2004 14:57:00 -0700 Received: from dsl.pipex.com (81-178-208-246.dsl.pipex.com [81.178.208.246]) by colossus.systems.pipex.net (Postfix) with ESMTP id 760D01C0009D; Sat, 17 Apr 2004 22:56:52 +0100 (BST) Message-ID: <4081A824.5020107@dsl.pipex.com> Date: Sat, 17 Apr 2004 22:56:52 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> In-Reply-To: <1082203795.1043.18.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4721 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2805 Lines: 81 jamal wrote: > On Sat, 2004-04-17 at 06:39, Andy Furniss wrote: > > >>>No i dont plan to. Why do you want to go that path? >> >>I think it's the only way I can shape/share my ingress traffic between a >> process (eg. bittorrent/squid) running on my shaping machine and >>traffic that is forwarded to my LAN. I masquerade onto one real dynamic IP. > > > I think i am almost understanding you now. Your main concern is people > using bittorrent to upload to you, correct? > Is there a way to recognize packets going to/from bittorent? Quite possibly (though I think it uses connmark which I can't use as I use connbytes to get new tcps out of slowstart). I also sometimes use wget and I've seen posts on LARTC from people who use squid and need to solve the same problem. > > >>In the case of pre nat outbound - I know people can mark pre NAT and >>shape on that, but it would allow people with big LANs doing NAT to use >>WRR/ESFQ on src for egress traffic. > > > Dont jump into the HOW; lets get to your setup and dissect it. Like i > said, dont think in terms of IMQ but still think in terms of meeting > your requirements. > Your setup is certainly new to me (at least from what i have been told > or read on how people use IMQ) - so thanks for posting. This is the kind > of thing i needed to hear about. > > >>My setup is very simple - the only reason I use IMQ+NAT patch is because >>I want to use my gateway/shaping PC to run bittorrent and I want the LAN >>machines to have priority/fair share of incoming traffic. I guess my >>setup is not that common - more common are people who run squid on the >>same PC they shape/do NAT on. >> >>ppp0 one dynamic real IP -> gateway PC -> eth0 -> LAN 192.168.0.0/24 >> | >> -> local process. > > > > Ok good. Assuming you have attached your HTB etc on one or more dummy > devices. > > - packets from local Lan can be marked at ingress and redirect to a > dummy if needed. Infact you can do this on the egress at ppp0 as well > using the new tc -i that i introduced. So this is easy. > > - packets from the bittorent process can be marked by iptables before > they get NATed (is this right?). Such packets can then be redirected to > dummy from egress of ppp0 using fw classifier. So again this is easy. Yes - egress is sortable without IMQ. > > - The third path is packets that come in from ppp0, get demasquareded, > then have to either go a) to the LAN/eth0 or b)localhost bittorent > process. You want to restrict b) Well not just restrict - dynamically share per IP total incoming bandwidth with LAN traffic using HTB. Andy. - is that correct? I have some > suggestion, but need you to verify this part. > > cheers, > jamal > > From hadi@cyberus.ca Sun Apr 18 07:28:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 07:28:42 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IEScKO013725 for ; Sun, 18 Apr 2004 07:28:39 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BFDI0-0008Dq-Om for netdev@oss.sgi.com; Sun, 18 Apr 2004 10:28:56 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BFDHb-0004yu-Bq; Sun, 18 Apr 2004 10:28:31 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <4081A824.5020107@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082298480.1041.94.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Apr 2004 10:28:00 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4722 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1713 Lines: 51 On Sat, 2004-04-17 at 17:56, Andy Furniss wrote: > jamal wrote: > > I think i am almost understanding you now. Your main concern is people > > using bittorrent to upload to you, correct? > > Is there a way to recognize packets going to/from bittorent? > > Quite possibly (though I think it uses connmark which I can't use as I > use connbytes to get new tcps out of slowstart). You are speaking Inuit to me. What is connmark? and what is the relation to tcp slowstart. > I also sometimes use wget and I've seen posts on LARTC from people who > use squid and need to solve the same problem. I am gonna assume that you have some way to recognize the flows destined to localhost which you want to punish. > > > > > >>ppp0 one dynamic real IP -> gateway PC -> eth0 -> LAN 192.168.0.0/24 > >> | > >> -> local process. > > > > > > > > Ok good. Assuming you have attached your HTB etc on one or more dummy > > devices. > > - The third path is packets that come in from ppp0, get demasquareded, > > then have to either go a) to the LAN/eth0 or b)localhost bittorent > > process. You want to restrict b) > > Well not just restrict - dynamically share per IP total incoming > bandwidth with LAN traffic using HTB. Sure - thats assumed since you attach HTB to the dummy device. To accomodate your need for b), the idea would be as follows: packet gets demasquared, mark it with a fwmark based on some recognition you have for bittorent or squid and lastly policy route it to the dummy device based on fwmark (since routing happens last). I will need to modify the dummy to not drop such packets which are fwmarked. cheers, jamal From linux-netdev@gmane.org Sun Apr 18 07:30:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 07:30:42 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IEUaKO014024 for ; Sun, 18 Apr 2004 07:30:37 -0700 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BFDJb-0002qY-00 for ; Sun, 18 Apr 2004 16:30:35 +0200 Received: from 203-217-29-45.perm.iinet.net.au ([203.217.29.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Apr 2004 16:30:35 +0200 Received: from daniel by 203-217-29-45.perm.iinet.net.au with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Apr 2004 16:30:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: netdev@oss.sgi.com From: Daniel Pittman Subject: Linux IPSec crash. Date: Mon, 19 Apr 2004 00:20:12 +1000 Message-ID: <87k70djrkz.fsf@enki.rimspace.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 203-217-29-45.perm.iinet.net.au User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) Cancel-Lock: sha1:s2RHrQYA+VMcdKsXdPx0FtbYjyU= X-archive-position: 4723 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel@rimspace.net Precedence: bulk X-list: netdev Content-Length: 5509 Lines: 155 --=-=-= [this is a resent version of a message I posted, but can't find, from the other day. Sorry if it is a duplicate message.] I have been trying to get IPSec, specifically tunnel mode ESP with authentication, working between a couple of systems on my network. This works fine in one direction, but caused a kernel panic in the other, from the following assertion and oops. I have attached the IPSec (setkey) configuration files for both ends, since they are not for anything but testing anyway. 'enki' is the machine that originated the traffic, and 'achor' the machine that crashed. The kernel is a current BKCVS pull, built yesterday morning to enable netconsole. This was captured by netconsole, which is a very nice tool for debugging this sort of thing. Thanks to those who put it in place. If I can do anything more, please let me know. Daniel KERNEL: assertion (x->km.state == XFRM_STATE_DEAD) failed at net/xfrm/xfrm_state.c (193) Unable to handle kernel paging request at virtual address 90002033 printing eip: c029442f *pde = 00000000 Oops: 0000 [#1] CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010282 (2.6.5-achor) EIP is at __xfrm4_state_lookup+0x6f/0xa0 eax: 9000202b ebx: c2119808 ecx: c0378898 edx: 90002033 esi: 9000202b edi: 211dd9cb ebp: 00010000 esp: c0319ca8 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, threadinfo=c0318000 task=c02dca20) Stack: 32000000 00000032 c02f41e0 c3f685e0 c3f685e0 c0298f6c c2119830 00010000 00000032 00000000 c2721800 c0294760 c2119830 00010000 00000032 00000002 00000000 00000001 00000000 00000282 c2721800 00000000 00000000 00010000 Call Trace: [] xfrm_state_lookup+0x4c/0x70 [] xfrm4_rcv_encap+0x90/0x430 [] sock_def_readable+0x5f/0x70 [] raw_rcv_skb+0xd2/0x140 [] raw_rcv+0x9c/0x100 [] raw_v4_input+0xc2/0x100 [] xfrm4_rcv+0x15/0x20 [] ip_local_deliver_finish+0xc5/0x1b0 [] nf_hook_slow+0xdb/0x130 [] ip_local_deliver_finish+0x0/0x1b0 [] ip_local_deliver+0x209/0x230 [] ip_local_deliver_finish+0x0/0x1b0 [] ip_rcv_finish+0x1e9/0x260 [] ip_rcv_finish+0x0/0x260 [] nf_hook_slow+0xdb/0x130 [] ip_rcv_finish+0x0/0x260 [] ip_rcv+0x3bf/0x480 [] ip_rcv_finish+0x0/0x260 [] do_gettimeofday+0x1a/0xd0 [] netif_receive_skb+0x141/0x180 [] rtl8139_rx+0x1a8/0x320 [] scheduler_tick+0x1f/0x520 [] i8042_timer_func+0x0/0x20 [] rtl8139_poll+0x43/0xc0 [] net_rx_action+0x74/0x100 [] do_softirq+0x95/0xa0 [] do_IRQ+0xc5/0xf0 [] common_interrupt+0x18/0x20 [] default_idle+0x23/0x40 [] cpu_idle+0x34/0x40 [] start_kernel+0x153/0x170 [] unknown_bootoption+0x0/0x120 Code: 8b 40 08 0f 18 00 90 39 ca 75 e6 31 c0 5a 5b 5e 5f 5d c3 3b <0>Kernel panic: Fatal exception in interrupt In interrupt handler - not syncing <0>Rebooting in 10 seconds.. --=-=-= Content-Disposition: attachment; filename=enki.conf #!/usr/sbin/setkey -f # Configuration for enki (203.217.29.45) to achor (203.217.29.33) # This is the enki side # Flush the SAD and SPD flush; spdflush; # Create the ESP session with encryption and authentication. add 203.217.29.45 203.217.29.33 esp 0x100 -m tunnel -E blowfish-cbc 0xf4aaa016e85dcec8318f10b97aa237cf07a95734f53849d0bf461961ff3d828c -A hmac-sha2-256 0x8338aca85649969d95765c96a17a622629752b095acfd80595b7e72da45264d2 ; add 203.217.29.33 203.217.29.45 esp 0x101 -m tunnel -E blowfish-cbc 0xa55be4391df590938e00ce616eef526d7404fb9a4a8ee2077152e16ef41117bc -A hmac-sha2-256 0xb4ead5d3fdee487c81846155fed01ade8783900b5b8a2c9c50884db0459c6990 ; # Create the security policy that encrypts packets heading to the firewall. # This is just a point-to-point link, for the moment, for ICMP only. spdadd 203.217.29.45 203.217.29.33 icmp -P out ipsec esp/tunnel/203.217.29.45-203.217.29.33/require; spdadd 203.217.29.33 203.217.29.45 icmp -P in ipsec esp/tunnel/203.217.29.33-203.217.29.45/require; --=-=-= Content-Disposition: attachment; filename=achor.conf #!/usr/sbin/setkey -f # Configuration for enki (203.217.29.45) to achor (203.217.29.33) # This is the achor side. # Flush the SAD and SPD flush; spdflush; # Create the ESP session with encryption and authentication. add 203.217.29.45 203.217.29.33 esp 0x100 -m tunnel -E blowfish-cbc 0xf4aaa016e85dcec8318f10b97aa237cf07a95734f53849d0bf461961ff3d828c -A hmac-sha2-256 0x8338aca85649969d95765c96a17a622629752b095acfd80595b7e72da45264d2 ; add 203.217.29.33 203.217.29.45 esp 0x101 -m tunnel -E blowfish-cbc 0xa55be4391df590938e00ce616eef526d7404fb9a4a8ee2077152e16ef41117bc -A hmac-sha2-256 0xb4ead5d3fdee487c81846155fed01ade8783900b5b8a2c9c50884db0459c6990 ; # Create the security policy that encrypts packets heading to the firewall. # This is just a point-to-point link, for the moment, for ICMP only. spdadd 203.217.29.45 203.217.29.33 icmp -P in ipsec esp/tunnel/203.217.29.45-203.217.29.33/require; spdadd 203.217.29.33 203.217.29.45 icmp -P out ipsec esp/tunnel/203.217.29.45-203.217.29.33/require; --=-=-= -- Psychology is a rubber stamp pressed upon a slippery, dodging ghost. -- Maxwell Bodenheim --=-=-=-- From wharveszig@attbi.com Sun Apr 18 08:10:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 08:10:54 -0700 (PDT) Received: from ma-northadams1a-b-104.bur.adelphia.net (ma-northadams1a-b-104.bur.adelphia.net [24.52.175.104] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IFAgKO017144 for ; Sun, 18 Apr 2004 08:10:50 -0700 Message-Id: <200404181510.i3IFAgKO017144@oss.sgi.com> Received: from [24.52.175.104] by 0.108.96.208 with HTTP; Sun, 18 Apr 2004 09:07:13 -0100 From: "Blaine Quick" To: netdev@oss.sgi.com Subject: Mime-Version: 1.0 Date: Sun, 18 Apr 2004 07:11:13 -0300 Reply-To: "Blaine Quick" Content-Type: multipart/alternative; boundary="=_NextPart_000_000B_20S73QF0_1584K7681" X-archive-position: 4725 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: twaddletrust@attbi.com Precedence: bulk X-list: netdev Content-Length: 1838 Lines: 52 --=_NextPart_000_000B_20S73QF0_1584K7681 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit helen montage diebold convict scotty confrere delectate compendia emphatic handshake azure syncopate abner seclude clench angelo corrigenda bring valkyrie drowse burt grandiloquent dentistry fishy telescope schafer octile clarinet frayed edmonds aye colombia clark vivo spore dishevel salvage burial abase duffy enterprise dragonhead pickerel helvetica avon jutish crusade reynolds dwight synonym cheesecloth normalcy chaff attainder collocation pinhole sri goa canal lev scripps papyrus archimedes york porch ftc student --=_NextPart_000_000B_20S73QF0_1584K7681 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 8bit

I think you want human_growth_hormone DIETARY THERAPY

It has been labeled the health discovery of the decade.

Achieve many benefits, including:

Body Fat Loss - 82% Improvement
Energy Level  - 84% Increase
Body Fat Loss - 82% Improvement

Do this all with:

NO Dieting
NO Strenuous Exercise

http://www.C5k.timesere.com/at/



I want to say adios



bankrupt nozzle consumptive inflater curran fennel augite juke tale stenographer watchband moulton betel front kneecap nakayama leachate masseur conscript hoof saturnine ordnance charley butane sorption diachronic tribune affect conspirator adposition ely tulle college phosphate decease meyers root americanism accent declassify parallelogram deceptive horsewoman conformance arabesque canterbury kensington pemmican kingbird tragicomic

--=_NextPart_000_000B_20S73QF0_1584K7681-- From andy.furniss@dsl.pipex.com Sun Apr 18 10:14:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 10:14:06 -0700 (PDT) Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IHDqKO028835 for ; Sun, 18 Apr 2004 10:13:53 -0700 Received: from dsl.pipex.com (81-178-248-207.dsl.pipex.com [81.178.248.207]) by shockwave.systems.pipex.net (Postfix) with ESMTP id B50371C001C5; Sun, 18 Apr 2004 17:35:17 +0100 (BST) Message-ID: <4082AE45.7030101@dsl.pipex.com> Date: Sun, 18 Apr 2004 17:35:17 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> In-Reply-To: <1082298480.1041.94.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4736 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 2958 Lines: 93 jamal wrote: > On Sat, 2004-04-17 at 17:56, Andy Furniss wrote: > >>jamal wrote: > > > >>>I think i am almost understanding you now. Your main concern is people >>>using bittorrent to upload to you, correct? >>>Is there a way to recognize packets going to/from bittorent? >> >>Quite possibly (though I think it uses connmark which I can't use as I >>use connbytes to get new tcps out of slowstart). > > > You are speaking Inuit to me. What is connmark? and what is the relation > to tcp slowstart. > > Connmark is a netfilter patch which is required by the type of P2P limiting/marking projects on sf.net that could mark bittorrent traffic. It is incompatable with the connbytes patch which I use to mark the first x KB of new connections. Doing this lets me send new TCps to a short queue which is capped at 50% of my bandwidth. This means that some packets get dropped and the slowstart phase is ended before it's exponential nature floods my ISP buffer. Put another way - I can game without latency spikes while a couple of people are browsing "heavy .jpg" type websites. It only works well if my link is otherwise clear - but this is a common situation for my home setup. >>I also sometimes use wget and I've seen posts on LARTC from people who >>use squid and need to solve the same problem. > > > I am gonna assume that you have some way to recognize the flows destined > to localhost which you want to punish. > > >>> > > >>>>ppp0 one dynamic real IP -> gateway PC -> eth0 -> LAN 192.168.0.0/24 >>>> | >>>> -> local process. >>> >>> >>> >>>Ok good. Assuming you have attached your HTB etc on one or more dummy >>>devices. > > >>>- The third path is packets that come in from ppp0, get demasquareded, >>>then have to either go a) to the LAN/eth0 or b)localhost bittorent >>>process. You want to restrict b) >> >>Well not just restrict - dynamically share per IP total incoming >>bandwidth with LAN traffic using HTB. > > > Sure - thats assumed since you attach HTB to the dummy device. > > To accomodate your need for b), the idea would be as follows: > packet gets demasquared, mark it with a fwmark I guess you really mean mark then demasquerade. > based on some recognition > you have for bittorent or squid and lastly policy route it to the dummy > device based on fwmark (since routing happens last). > I will need to modify the dummy to not drop such packets which are > fwmarked. OK I can see this as a possibility - assuming I can mark. Maybe conmark will be OK with connbytes sometime. I don't really know how to use it, but if it is possible to mark egress connections in output and have connmark match their incoming packets that would be a solution. I haven't got a clue if connmark can do this, though, just speculating. Does anyone else know, and why it's not compatable with connbytes? Andy. > cheers, > jamal > > > From rol@as2917.net Sun Apr 18 11:51:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 11:51:12 -0700 (PDT) Received: from tag.witbe.net (IDENT:root@tag.witbe.net [81.88.96.48]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IIp7KO001156 for ; Sun, 18 Apr 2004 11:51:09 -0700 Received: from GeoTrouvetou (APuteaux-102-1-5-241.w80-14.abo.wanadoo.fr [80.14.191.241]) by tag.witbe.net (8.11.0/8.11.0) with ESMTP id i3IIp1107295; Sun, 18 Apr 2004 18:51:01 GMT Message-Id: <200404181851.i3IIp1107295@tag.witbe.net> Reply-To: From: "Paul Rolland" To: "'Stephen Hemminger'" , "'David S. Miller'" Cc: "'Paul Rolland'" , , Subject: RE: [2.6.5] Bad scheduling while atomic Date: Sun, 18 Apr 2004 20:50:55 +0200 Organization: AS2917 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQj8N4vTSnSCAKNT3W50Gg+qBW/wgAAdfUg In-Reply-To: <20040416131633.1bfbfa4c@dell_ss3.pdx.osdl.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3IIp7KO001156 X-archive-position: 4744 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rol@as2917.net Precedence: bulk X-list: netdev Content-Length: 1988 Lines: 73 Thanks Stephen for being so fast ! Regards, Paul Paul Rolland, rol(at)as2917.net ex-AS2917 Network administrator and Peering Coordinator -- Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur "Some people dream of success... while others wake up and work hard at it" > -----Message d'origine----- > De : linux-kernel-owner@vger.kernel.org > [mailto:linux-kernel-owner@vger.kernel.org] De la part de > Stephen Hemminger > Envoyé : vendredi 16 avril 2004 22:17 > À : David S. Miller > Cc : Paul Rolland; linux-kernel@vger.kernel.org; netdev@oss.sgi.com > Objet : Re: [2.6.5] Bad scheduling while atomic > > Bring up/down network devices with lapbether causes scheduling while > atomic (if preempt enabled). > > The calls to rcu_read_lock are unnecessary since lapb_device_event > is called from notifier with the rtnetlink semaphore held, it is > already protected from the labp_devices list changing. > > Patch against 2.6.6-rc1 > > diff -Nru a/drivers/net/wan/lapbether.c b/drivers/net/wan/lapbether.c > --- a/drivers/net/wan/lapbether.c Fri Apr 16 11:00:35 2004 > +++ b/drivers/net/wan/lapbether.c Fri Apr 16 11:00:35 2004 > @@ -392,6 +392,8 @@ > > /* > * Handle device status changes. > + * > + * Called from notifier with RTNL held. > */ > static int lapbeth_device_event(struct notifier_block *this, > unsigned long event, void *ptr) > @@ -402,7 +404,6 @@ > if (!dev_is_ethdev(dev)) > return NOTIFY_DONE; > > - rcu_read_lock(); > switch (event) { > case NETDEV_UP: > /* New ethernet device -> new LAPB interface */ > @@ -422,7 +423,6 @@ > lapbeth_free_device(lapbeth); > break; > } > - rcu_read_unlock(); > > return NOTIFY_DONE; > } > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > From andy.furniss@dsl.pipex.com Sun Apr 18 13:35:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 13:35:08 -0700 (PDT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IKZ0KO008455 for ; Sun, 18 Apr 2004 13:35:01 -0700 Received: from dsl.pipex.com (81-178-248-207.dsl.pipex.com [81.178.248.207]) by pengo.systems.pipex.net (Postfix) with ESMTP id A407E4C000F4; Sun, 18 Apr 2004 21:34:53 +0100 (BST) Message-ID: <4082E66D.2020707@dsl.pipex.com> Date: Sun, 18 Apr 2004 21:34:53 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Furniss Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> In-Reply-To: <4082AE45.7030101@dsl.pipex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4747 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1122 Lines: 42 Andy Furniss wrote: >> To accomodate your need for b), the idea would be as follows: >> packet gets demasquared, mark it with a fwmark > > > I guess you really mean mark then demasquerade. > >> based on some recognition >> you have for bittorent or squid and lastly policy route it to the dummy >> device based on fwmark (since routing happens last). >> I will need to modify the dummy to not drop such packets which are >> fwmarked. > > > OK I can see this as a possibility - assuming I can mark. Maybe conmark > will be OK with connbytes sometime. I don't really know how to use it, > but if it is possible to mark egress connections in output and have > connmark match their incoming packets that would be a solution. I > haven't got a clue if connmark can do this, though, just speculating. Hmm second thoughts - if I can route packets to dummy after demasquerade then I don't need to mark - I can use u32 as I do now to seperate per IP. Am I missing something here? > > Does anyone else know, and why it's not compatable with connbytes? > > Andy. > >> cheers, >> jamal >> >> >> > > > > From hadi@cyberus.ca Sun Apr 18 13:53:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 13:53:59 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IKroKO008920 for ; Sun, 18 Apr 2004 13:53:51 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BFJIn-0005a8-Nd for netdev@oss.sgi.com; Sun, 18 Apr 2004 16:54:09 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BFJIN-0000Jo-HR; Sun, 18 Apr 2004 16:53:43 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <4082AE45.7030101@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082321582.1039.319.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Apr 2004 16:53:04 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4748 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1470 Lines: 42 On Sun, 2004-04-18 at 12:35, Andy Furniss wrote: > Connmark is a netfilter patch which is required by the type of P2P > limiting/marking projects on sf.net that could mark bittorrent traffic. just from the sounds of it, appears it may be able to mark a group of related flows with the same fwmark. > It is incompatable with the connbytes patch which I use to mark the > first x KB of new connections. Doing this lets me send new TCps to a > short queue which is capped at 50% of my bandwidth. This means that some > packets get dropped and the slowstart phase is ended before it's > exponential nature floods my ISP buffer. seems very similar in concept to what Alex (alex@pilotsoft.com) was trying to achieve. > > To accomodate your need for b), the idea would be as follows: > > packet gets demasquared, mark it with a fwmark > > I guess you really mean mark then demasquerade. Either should work fine. > OK I can see this as a possibility - assuming I can mark. Maybe conmark sounds like connmark maybe what you want. > will be OK with connbytes sometime. I don't really know how to use it, > but if it is possible to mark egress connections in output and have > connmark match their incoming packets that would be a solution. I > haven't got a clue if connmark can do this, though, just speculating. > > Does anyone else know, and why it's not compatable with connbytes? > some of the netfilter people should be able to help. cheers, jamal From hadi@cyberus.ca Sun Apr 18 14:08:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 14:08:10 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IL85KO009451 for ; Sun, 18 Apr 2004 14:08:06 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BFJWa-0008Um-TT for netdev@oss.sgi.com; Sun, 18 Apr 2004 17:08:24 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BFJWB-0002Wq-CO; Sun, 18 Apr 2004 17:07:59 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Andy Furniss Cc: netdev@oss.sgi.com In-Reply-To: <4082E66D.2020707@dsl.pipex.com> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <4082E66D.2020707@dsl.pipex.com> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082322448.1041.329.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Apr 2004 17:07:28 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4749 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1100 Lines: 30 On Sun, 2004-04-18 at 16:34, Andy Furniss wrote: > Hmm second thoughts - if I can route packets to dummy after demasquerade > then I don't need to mark - I can use u32 as I do now to seperate per > IP. Am I missing something here? The problem is dummy had some speacial reason for existence in the old days of slip/ppp dummy acts as blackhole; some apps insist(ed) on getting a static IP address on primary interface when you are offline. So people would typically setup routes to the dummy device where packets just get swalloed. I have a feeling there are people who still use this functionality somewhere in the globe (sorry i am from .ca dont know what that means anymore;->). And i dont want to break this functionality. So what i was thinking is i will have dummy spare any fwmarked packets and reinject them back. Another alternative is to just fsck this backward compatibility mode because people could use blackhole routes today. Yet another alternative is to create a brand new device and call it something like imq2. For such little code, this may be overkill. cheers, jamal From gandalf@wlug.westbo.se Sun Apr 18 14:24:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 14:24:16 -0700 (PDT) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ILO6KO010001 for ; Sun, 18 Apr 2004 14:24:09 -0700 Received: by null.rsn.bth.se (Postfix, from userid 65534) id 074A72C008A; Sun, 18 Apr 2004 23:24:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 948B52C008E; Sun, 18 Apr 2004 23:24:00 +0200 (CEST) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id 479042C008A; Sun, 18 Apr 2004 23:23:52 +0200 (CEST) Received: by tux.rsn.bth.se (Postfix, from userid 501) id 1972C3EDC; Sun, 18 Apr 2004 23:23:53 +0200 (CEST) Subject: Re: IMQ / new Dummy device post. From: Martin Josefsson To: jamal Cc: Andy Furniss , netdev@oss.sgi.com In-Reply-To: <1082321582.1039.319.camel@jzny.localdomain> References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <1082321582.1039.319.camel@jzny.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ii7GnMs9b8DQn+4nkyhN" Message-Id: <1082323432.13261.397.camel@tux.rsn.bth.se> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 18 Apr 2004 23:23:52 +0200 X-Virus-Scanned: by amavisd-new-20030616-p7 on null.rsn.bth.se X-archive-position: 4750 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 1827 Lines: 52 --=-ii7GnMs9b8DQn+4nkyhN Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-04-18 at 22:53, jamal wrote: > On Sun, 2004-04-18 at 12:35, Andy Furniss wrote: >=20 > > Connmark is a netfilter patch which is required by the type of P2P=20 > > limiting/marking projects on sf.net that could mark bittorrent traffic.= =20 >=20 > just from the sounds of it, appears it may be able to mark a group of > related flows with the same fwmark. connmark is like nfmark but it marks the connection-entry in ip_conntrack instead. And then you can "restore" that mark to the nfmark of the packet at any time you want with filter rules. > > will be OK with connbytes sometime. I don't really know how to use it,=20 > > but if it is possible to mark egress connections in output and have=20 > > connmark match their incoming packets that would be a solution. I=20 > > haven't got a clue if connmark can do this, though, just speculating. > > > > Does anyone else know, and why it's not compatable with connbytes? > >=20 >=20 > some of the netfilter people should be able to help. with connmark you mark the connection, and then you can "restore" that mark to packets in either direction in the mangle table of iptables. connmark isn't incompatible with connbytes. It's just that both patches modify the same part of the code, a struct, and the patch program can't handle that. You'll have to fix some rejects by hand, that's it. --=20 /Martin --=-ii7GnMs9b8DQn+4nkyhN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAgvHoWm2vlfa207ERAqw1AJ4t4XgDuenaJwtUHc1exZFdUbRWpwCgsBYW R6K7gyIJe+8ntTACFfTvnjY= =mTms -----END PGP SIGNATURE----- --=-ii7GnMs9b8DQn+4nkyhN-- From andy.furniss@dsl.pipex.com Sun Apr 18 14:31:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 14:31:48 -0700 (PDT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ILVgKO010425 for ; Sun, 18 Apr 2004 14:31:43 -0700 Received: from dsl.pipex.com (81-178-248-207.dsl.pipex.com [81.178.248.207]) by pengo.systems.pipex.net (Postfix) with ESMTP id D737B4C000ED; Sun, 18 Apr 2004 22:31:35 +0100 (BST) Message-ID: <4082F3B7.8000408@dsl.pipex.com> Date: Sun, 18 Apr 2004 22:31:35 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <4082E66D.2020707@dsl.pipex.com> <1082322448.1041.329.camel@jzny.localdomain> In-Reply-To: <1082322448.1041.329.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4751 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1566 Lines: 39 jamal wrote: > On Sun, 2004-04-18 at 16:34, Andy Furniss wrote: > > > >>Hmm second thoughts - if I can route packets to dummy after demasquerade >>then I don't need to mark - I can use u32 as I do now to seperate per >>IP. Am I missing something here? > > > The problem is dummy had some speacial reason for existence in the old > days of slip/ppp dummy acts as blackhole; > some apps insist(ed) on getting a static IP address > on primary interface when you are offline. So people would typically > setup routes to the dummy device where packets just get swalloed. > > I have a feeling there are people who still use this functionality > somewhere in the globe (sorry i am from .ca dont know what that means > anymore;->). And i dont want to break this functionality. > So what i was thinking is i will have dummy spare any fwmarked packets > and reinject them back. I think this would still be a solution for me - I allready mark everything coming in on ppp0 in prerouting filter (pre demasquerade) into three classes - interactive, new and bulk. I then use u32 to further share bulk per dst IP post demasquerade on the HTB/IMQ. So as long as I can route to dummy post demasquerade I don't need IMQ. This would be alot better than messing around with connmark. Andy. > Another alternative is to just fsck this backward compatibility mode > because people could use blackhole routes today. > Yet another alternative is to create a brand new device and call it > something like imq2. For such little code, this may be overkill. > > cheers, > jamal From andy.furniss@dsl.pipex.com Sun Apr 18 14:58:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 14:58:46 -0700 (PDT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3ILwfKO011195 for ; Sun, 18 Apr 2004 14:58:42 -0700 Received: from dsl.pipex.com (81-178-248-207.dsl.pipex.com [81.178.248.207]) by pengo.systems.pipex.net (Postfix) with ESMTP id 4AAE74C00134; Sun, 18 Apr 2004 22:58:33 +0100 (BST) Message-ID: <4082FA09.2040404@dsl.pipex.com> Date: Sun, 18 Apr 2004 22:58:33 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Josefsson Cc: jamal , netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <1082321582.1039.319.camel@jzny.localdomain> <1082323432.13261.397.camel@tux.rsn.bth.se> In-Reply-To: <1082323432.13261.397.camel@tux.rsn.bth.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4752 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 1643 Lines: 45 Martin Josefsson wrote: > On Sun, 2004-04-18 at 22:53, jamal wrote: > >>On Sun, 2004-04-18 at 12:35, Andy Furniss wrote: >> >> >>>Connmark is a netfilter patch which is required by the type of P2P >>>limiting/marking projects on sf.net that could mark bittorrent traffic. >> >>just from the sounds of it, appears it may be able to mark a group of >>related flows with the same fwmark. > > > connmark is like nfmark but it marks the connection-entry in > ip_conntrack instead. And then you can "restore" that mark to the nfmark > of the packet at any time you want with filter rules. > > >>>will be OK with connbytes sometime. I don't really know how to use it, >>>but if it is possible to mark egress connections in output and have >>>connmark match their incoming packets that would be a solution. I >>>haven't got a clue if connmark can do this, though, just speculating. >>> >>>Does anyone else know, and why it's not compatable with connbytes? >>> >> >>some of the netfilter people should be able to help. > > > with connmark you mark the connection, and then you can "restore" that > mark to packets in either direction in the mangle table of iptables. > > connmark isn't incompatible with connbytes. It's just that both patches > modify the same part of the code, a struct, and the patch program can't > handle that. You'll have to fix some rejects by hand, that's it. > Thanks for that - though I hope not to have to use it now, just to confirm - does it work in all of the 5 mangle tables or more specifically could I mark every connection from local processes in output and restore the marks in prerouting? Andy. From andy.furniss@dsl.pipex.com Sun Apr 18 15:18:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 18 Apr 2004 15:18:58 -0700 (PDT) Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3IMIhKO011862 for ; Sun, 18 Apr 2004 15:18:44 -0700 Received: from dsl.pipex.com (81-178-248-207.dsl.pipex.com [81.178.248.207]) by pengo.systems.pipex.net (Postfix) with ESMTP id B752E4C000ED; Sun, 18 Apr 2004 22:45:39 +0100 (BST) Message-ID: <4082F703.2030209@dsl.pipex.com> Date: Sun, 18 Apr 2004 22:45:39 +0100 From: Andy Furniss User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andy Furniss Cc: hadi@cyberus.ca, netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <4082E66D.2020707@dsl.pipex.com> <1082322448.1041.329.camel@jzny.localdomain> <4082F3B7.8000408@dsl.pipex.com> In-Reply-To: <4082F3B7.8000408@dsl.pipex.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4753 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andy.furniss@dsl.pipex.com Precedence: bulk X-list: netdev Content-Length: 190 Lines: 9 Andy Furniss wrote: > I think this would still be a solution for me - I allready mark > everything coming in on ppp0 in prerouting filter I meant mangle not filter of course :-) Andy. From gandalf@wlug.westbo.se Mon Apr 19 01:15:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 01:15:33 -0700 (PDT) Received: from null.rsn.bth.se (postfix@null.rsn.bth.se [194.47.142.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3J8F2KO003037 for ; Mon, 19 Apr 2004 01:15:23 -0700 Received: by null.rsn.bth.se (Postfix, from userid 65534) id A902C2C0095; Mon, 19 Apr 2004 10:14:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by null.rsn.bth.se (Postfix) with ESMTP id 3F11F2C009C; Mon, 19 Apr 2004 10:14:56 +0200 (CEST) Received: from tux.rsn.bth.se (tux.rsn.bth.se [194.47.143.135]) by null.rsn.bth.se (Postfix) with ESMTP id 8B2BC2C0095; Mon, 19 Apr 2004 10:14:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tux.rsn.bth.se (Postfix) with ESMTP id AFABC3EDC; Mon, 19 Apr 2004 10:14:48 +0200 (CEST) Date: Mon, 19 Apr 2004 10:14:48 +0200 (CEST) From: Martin Josefsson X-X-Sender: gandalf@tux.rsn.bth.se To: Andy Furniss Cc: jamal , netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. In-Reply-To: <4082FA09.2040404@dsl.pipex.com> Message-ID: References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> <4081A824.5020107@dsl.pipex.com> <1082298480.1041.94.camel@jzny.localdomain> <4082AE45.7030101@dsl.pipex.com> <1082321582.1039.319.camel@jzny.localdomain> <1082323432.13261.397.camel@tux.rsn.bth.se> <4082FA09.2040404@dsl.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p7 on null.rsn.bth.se X-archive-position: 4755 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gandalf@wlug.westbo.se Precedence: bulk X-list: netdev Content-Length: 723 Lines: 18 On Sun, 18 Apr 2004, Andy Furniss wrote: > > with connmark you mark the connection, and then you can "restore" that > > mark to packets in either direction in the mangle table of iptables. > > > > connmark isn't incompatible with connbytes. It's just that both patches > > modify the same part of the code, a struct, and the patch program can't > > handle that. You'll have to fix some rejects by hand, that's it. > > > > Thanks for that - though I hope not to have to use it now, just to > confirm - does it work in all of the 5 mangle tables or more > specifically could I mark every connection from local processes in > output and restore the marks in prerouting? It works in all of the 5 mangle chains iirc. /Martin From akpm@osdl.org Mon Apr 19 01:14:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 01:14:50 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3J8EeKO002999 for ; Mon, 19 Apr 2004 01:14:43 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i3J8EY230586 for ; Mon, 19 Apr 2004 01:14:34 -0700 Date: Mon, 19 Apr 2004 01:14:18 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [BUG] linux >= 2.6.5 won't compile with CONFIG_IPV6=m and CONFIG_IP6_NF_QUEUE=y Message-Id: <20040419011418.42b6f4e9.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__19_Apr_2004_01_14_18_-0700_vHvhsWdixkG577N2" X-archive-position: 4754 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: 28879 Lines: 1332 This is a multi-part message in MIME format. --Multipart=_Mon__19_Apr_2004_01_14_18_-0700_vHvhsWdixkG577N2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Begin forwarded message: Date: Mon, 19 Apr 2004 00:44:36 -0700 From: Corey Hickey To: linux-kernel@vger.kernel.org Subject: [BUG] linux >= 2.6.5 won't compile with CONFIG_IPV6=m and CONFIG_IP6_NF_QUEUE=y [If I ought to send this to a different list/person, please tell me and I'll do so] I've tested 2.6.5-rc3, 2.6.5, and 2.6.6-rc1-bk3. 2.6.5-rc3 isn't affected by this problem, but the other two (and I presume any version in between) fail with this message: ------------------- AS arch/i386/lib/getuser.o CC arch/i386/lib/memcpy.o CC arch/i386/lib/strstr.o CC arch/i386/lib/usercopy.o AR arch/i386/lib/lib.a GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 net/built-in.o(.text+0x67b20): In function `ipq_mangle_ipv6': : undefined reference to `ip6_route_me_harder' make: *** [.tmp_vmlinux1] Error 1 ------------------- Attached is my .config from 2.6.5. Steps to reproduce: 1. Start with a kernel tree from 2.6.5 or later. 2. make defconfig 3. make menuconfig a. Enable ipv6 as a module b. Enable ipv6 "Userspace queueing via NETLINK" (not as a module). 4. make I can make the error go away by either (a)setting CONFIG_IPV6=y, or (b)setting CONFIG_IP6_NF_QUEUE=m. System details: 2.6.5-mm1 Debian Sarge libc6 version 2.3.2.ds1-11 gcc version 2.95.4 20011002 (Debian prerelease) Note: I have the same problem compiling with GCC 3.3: gcc version 3.3.3 (Debian 20040401) GNU assembler 2.14.90.0.7 20031029 Debian GNU/Linux GNU ld version 2.14.90.0.7 20031029 Debian GNU/Linux Thanks, Corey --Multipart=_Mon__19_Apr_2004_01_14_18_-0700_vHvhsWdixkG577N2 Content-Type: text/plain; name="config-2.6.5" Content-Disposition: attachment; filename="config-2.6.5" Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=15 CONFIG_HOTPLUG=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y CONFIG_HAVE_DEC_LOCK=y # CONFIG_REGPARM is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y # CONFIG_PM_DISK is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_X86_PM_TIMER is not set # # APM (Advanced Power Management) BIOS Support # # CONFIG_APM is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCI_USE_VECTOR is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_PCMCIA_PROBE=y # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y # # Device Drivers # # # Generic Driver Options # # CONFIG_FW_LOADER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_CML1=y # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # # CONFIG_ISAPNP is not set # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_CARMEL is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_LBD=y # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_TASKFILE_IO=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_REPORT_LUNS=y # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # # SCSI Transport Attributes # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y # CONFIG_SCSI_SATA_PROMISE is not set # CONFIG_SCSI_SATA_SIL is not set # CONFIG_SCSI_SATA_VIA is not set # CONFIG_SCSI_SATA_VITESSE is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_OUI_DB is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # # Device Drivers # # # Texas Instruments PCILynx requires I2C # CONFIG_IEEE1394_OHCI1394=y # # Protocol Drivers # # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=y # CONFIG_IEEE1394_CMP is not set # # I2O device support # # CONFIG_I2O is not set # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # # IP: Virtual Server Configuration # # CONFIG_IP_VS is not set CONFIG_IPV6=m # CONFIG_IPV6_PRIVACY is not set # CONFIG_INET6_AH is not set # CONFIG_INET6_ESP is not set # CONFIG_INET6_IPCOMP is not set # CONFIG_IPV6_TUNNEL is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y # CONFIG_IP_NF_FTP is not set # CONFIG_IP_NF_IRC is not set # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_PKTTYPE=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_DSCP=y CONFIG_IP_NF_MATCH_AH_ESP=y CONFIG_IP_NF_MATCH_LENGTH=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_TCPMSS=y CONFIG_IP_NF_MATCH_HELPER=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_TARGET_NETMAP=y CONFIG_IP_NF_TARGET_SAME=y # CONFIG_IP_NF_NAT_LOCAL is not set # CONFIG_IP_NF_NAT_SNMP_BASIC is not set CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_CLASSIFY=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_ULOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_ARPTABLES=y CONFIG_IP_NF_ARPFILTER=y CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=y # CONFIG_IP6_NF_IPTABLES is not set # # SCTP Configuration (EXPERIMENTAL) # # CONFIG_IP_SCTP is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_OLD_RX_RESET is not set CONFIG_8139_RXBUF_IDX=2 # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y # CONFIG_SERIAL_8250_CONSOLE is not set # CONFIG_SERIAL_8250_ACPI is not set CONFIG_SERIAL_8250_NR_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 CONFIG_PRINTER=y # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR is not set # CONFIG_QIC02_TAPE is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_INTEL_MCH is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set # CONFIG_DRM_GAMMA is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_I810 is not set CONFIG_DRM_I830=y # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # # CONFIG_I2C is not set # # Misc devices # # CONFIG_IBM_ASM is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set # CONFIG_VIDEO_SELECT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=y # # Advanced Linux Sound Architecture # CONFIG_SND=y CONFIG_SND_TIMER=y CONFIG_SND_PCM=y CONFIG_SND_RAWMIDI=y CONFIG_SND_SEQUENCER=y # CONFIG_SND_SEQ_DUMMY is not set CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=y # CONFIG_SND_DUMMY is not set # CONFIG_SND_VIRMIDI is not set # CONFIG_SND_MTPAV is not set # CONFIG_SND_SERIAL_U16550 is not set # CONFIG_SND_MPU401 is not set # # ISA devices # # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set # CONFIG_SND_SB16 is not set # CONFIG_SND_SBAWE is not set # CONFIG_SND_WAVEFRONT is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # # PCI devices # CONFIG_SND_AC97_CODEC=y # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set CONFIG_SND_INTEL8X0=y # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VX222 is not set # # ALSA USB devices # # CONFIG_SND_USB_AUDIO is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH_TTY is not set # CONFIG_USB_MIDI is not set # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # # USB Human Interface Devices (HID) # CONFIG_USB_HID=y CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # CONFIG_USB_MTOUCH is not set # CONFIG_USB_XPAD is not set # CONFIG_USB_ATI_REMOTE is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # CONFIG_USB_DABUSB is not set # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_LED is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_XFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set CONFIG_AUTOFS4_FS=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_EXPORTFS=y CONFIG_SUNRPC=y # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=y # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y # CONFIG_FRAME_POINTER is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # CONFIG_CRC32=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --Multipart=_Mon__19_Apr_2004_01_14_18_-0700_vHvhsWdixkG577N2-- From herbert@gondor.apana.org.au Mon Apr 19 04:13:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 04:13:11 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JBD1KO010404 for ; Mon, 19 Apr 2004 04:13:02 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BFWhd-0000ue-00; Mon, 19 Apr 2004 21:12:41 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BFWha-0006AS-00; Mon, 19 Apr 2004 21:12:38 +1000 Date: Mon, 19 Apr 2004 21:12:38 +1000 To: Andrew Morton , "David S. Miller" , netdev@oss.sgi.com Subject: Re: Fw: [BUG] linux >= 2.6.5 won't compile with CONFIG_IPV6=m and CONFIG_IP6_NF_QUEUE=y Message-ID: <20040419111238.GA23696@gondor.apana.org.au> References: <20040419011418.42b6f4e9.akpm@osdl.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <20040419011418.42b6f4e9.akpm@osdl.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 4756 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: 1297 Lines: 38 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 19, 2004 at 08:14:18AM +0000, Andrew Morton wrote: > Subject: [BUG] linux >= 2.6.5 won't compile with CONFIG_IPV6=m and CONFIG_IP6_NF_QUEUE=y This patch should stop this from happening. -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: net/ipv6/netfilter/Kconfig =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv6/netfilter/Kconfig,v retrieving revision 1.1.1.5 diff -u -r1.1.1.5 Kconfig --- a/net/ipv6/netfilter/Kconfig 19 Feb 2004 08:56:07 -0000 1.1.1.5 +++ b/net/ipv6/netfilter/Kconfig 19 Apr 2004 11:08:21 -0000 @@ -3,7 +3,7 @@ # menu "IPv6: Netfilter Configuration" - depends on INET && IPV6!=n && NETFILTER + depends on INET && IPV6 && NETFILTER #tristate 'Connection tracking (required for masq/NAT)' CONFIG_IP6_NF_CONNTRACK #if [ "$CONFIG_IP6_NF_CONNTRACK" != "n" ]; then --6c2NcOVqGQ03X4Wi-- From herbert@gondor.apana.org.au Mon Apr 19 05:56:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 05:57:05 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JCuZKO003385 for ; Mon, 19 Apr 2004 05:56:56 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BFYK9-0001j3-00 for ; Mon, 19 Apr 2004 22:56:33 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BFYK6-0006LX-00 for ; Mon, 19 Apr 2004 22:56:30 +1000 Date: Mon, 19 Apr 2004 22:56:29 +1000 To: netdev@oss.sgi.com Subject: [RFC] Store inner MTU in dst_pmtu for IPsec Message-ID: <20040419125629.GA24314@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 4757 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: 8653 Lines: 245 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi: WARNING: This patch is completely untested. Various people have reported that there are issues with TCP MTU handling with the native IPsec stack. I found that if your interface/route's MTU is in a certain range then the xfrm4_tunnel_check_size() function is guaranteed to fail when given a full-sized packet. The reason is that it uses trailer_len unconditionally even though trailer_len is calculated for a packet of a particular size (zero). For example, in the typical ESP/3DES/IPIP scenario, if the MTU is congruent to 3/4 modulo 8 then this all works. But all other values are doomed to fail. Luckily, the most common MTUs of 1500/1492 happen to satisfy this condition. But the MTU of 1480 (IPIP over Ethernet) fails. The obvious fix is to use get_mss to calculate the correct size. However, since get_mss is rather slow I realised that its value should be cached rather than recomputed for every outgoing packet. It soon dawned on me that the entire MTU handling for IPsec is broken. In particular, we simply ignore ICMP need-to-frag packets for peers that are across an IPsec tunnel. This is because the dst_pmtu value for IPsec dst's comes from the route for the IPsec gateway, not the route for the peer across the IPsec tunnel. This patch solves the problem in the obvious way by setting the path to the peer's route instead of that of the IPsec gateway. I haven't even compiled this patch so there are bound to be problems with it. I have also ignored IPv6 for now. But I'd like to know whether I'm completely off my head before proceeding any further :) Thanks, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: include/linux/tcp.h =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/include/linux/tcp.h,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 tcp.h --- a/include/linux/tcp.h 5 Apr 2004 09:49:43 -0000 1.1.1.8 +++ b/include/linux/tcp.h 19 Apr 2004 12:39:44 -0000 @@ -250,7 +250,6 @@ __u16 mss_cache_std; /* Like mss_cache, but without TSO */ __u16 mss_clamp; /* Maximal mss, negotiated at connection setup */ __u16 ext_header_len; /* Network protocol overhead (IP/IPv6 options) */ - __u16 ext2_header_len;/* Options depending on route */ __u8 ca_state; /* State of fast-retransmit machine */ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ Index: include/net/tcp.h =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/include/net/tcp.h,v retrieving revision 1.1.1.13 diff -u -r1.1.1.13 tcp.h --- a/include/net/tcp.h 11 Mar 2004 02:55:22 -0000 1.1.1.13 +++ b/include/net/tcp.h 19 Apr 2004 12:39:56 -0000 @@ -1030,8 +1030,7 @@ if (dst) { u32 mtu = dst_pmtu(dst); - if (mtu != tp->pmtu_cookie || - tp->ext2_header_len != dst->header_len) + if (mtu != tp->pmtu_cookie) mss_now = tcp_sync_mss(sk, mtu); } if (tp->eff_sacks) Index: net/core/dst.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/core/dst.c,v retrieving revision 1.1.1.8 diff -u -r1.1.1.8 dst.c --- a/net/core/dst.c 5 Feb 2004 08:19:57 -0000 1.1.1.8 +++ b/net/core/dst.c 19 Apr 2004 12:11:02 -0000 @@ -170,6 +170,9 @@ struct hh_cache *hh; again: + if (dst->path != dst) + atomic_dec(&dst->path->__refcnt); + neigh = dst->neighbour; hh = dst->hh; child = dst->child; Index: net/ipv4/ip_sockglue.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/ip_sockglue.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 ip_sockglue.c --- a/net/ipv4/ip_sockglue.c 11 Mar 2004 02:55:24 -0000 1.1.1.7 +++ b/net/ipv4/ip_sockglue.c 19 Apr 2004 12:33:05 -0000 @@ -957,7 +957,7 @@ val = 0; dst = sk_dst_get(sk); if (dst) { - val = dst_pmtu(dst) - dst->header_len; + val = dst_pmtu(dst); dst_release(dst); } if (!val) { Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/tcp_ipv4.c,v retrieving revision 1.4 diff -u -r1.4 tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c 5 Apr 2004 10:54:54 -0000 1.4 +++ b/net/ipv4/tcp_ipv4.c 19 Apr 2004 12:39:00 -0000 @@ -841,7 +841,6 @@ /* OK, now commit destination to socket. */ __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tp->ext2_header_len = rt->u.dst.header_len; if (!tp->write_seq) tp->write_seq = secure_tcp_sequence_number(inet->saddr, @@ -1592,7 +1591,6 @@ newtp->ext_header_len = 0; if (newinet->opt) newtp->ext_header_len = newinet->opt->optlen; - newtp->ext2_header_len = dst->header_len; newinet->id = newtp->write_seq ^ jiffies; tcp_sync_mss(newsk, dst_pmtu(dst)); @@ -1891,7 +1889,6 @@ __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tcp_sk(sk)->ext2_header_len = rt->u.dst.header_len; new_saddr = rt->rt_src; @@ -1951,7 +1948,6 @@ if (!err) { __sk_dst_set(sk, &rt->u.dst); tcp_v4_setup_caps(sk, &rt->u.dst); - tcp_sk(sk)->ext2_header_len = rt->u.dst.header_len; return 0; } Index: net/ipv4/tcp_output.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/tcp_output.c,v retrieving revision 1.1.1.7 diff -u -r1.1.1.7 tcp_output.c --- a/net/ipv4/tcp_output.c 8 Oct 2003 19:24:17 -0000 1.1.1.7 +++ b/net/ipv4/tcp_output.c 19 Apr 2004 12:38:37 -0000 @@ -558,9 +558,6 @@ struct dst_entry *dst = __sk_dst_get(sk); int mss_now; - if (dst && dst->ops->get_mss) - pmtu = dst->ops->get_mss(dst, pmtu); - /* Calculate base mss without TCP options: It is MMS_S - sizeof(tcphdr) of rfc1122 */ @@ -571,7 +568,7 @@ mss_now = tp->mss_clamp; /* Now subtract optional transport overhead */ - mss_now -= tp->ext_header_len + tp->ext2_header_len; + mss_now -= tp->ext_header_len; /* Then reserve room for full set of TCP options and 8 bytes of data */ if (mss_now < 48) @@ -592,7 +589,7 @@ int large_mss; large_mss = 65535 - tp->af_specific->net_header_len - - tp->ext_header_len - tp->ext2_header_len - tp->tcp_header_len; + tp->ext_header_len - tp->tcp_header_len; if (tp->max_window && large_mss > (tp->max_window>>1)) large_mss = max((tp->max_window>>1), 68U - tp->tcp_header_len); Index: net/ipv4/xfrm4_policy.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/xfrm4_policy.c,v retrieving revision 1.4 diff -u -r1.4 xfrm4_policy.c --- a/net/ipv4/xfrm4_policy.c 5 Apr 2004 10:54:54 -0000 1.4 +++ b/net/ipv4/xfrm4_policy.c 19 Apr 2004 12:25:13 -0000 @@ -133,7 +133,8 @@ dst_prev->header_len = header_len; dst_prev->trailer_len = trailer_len; memcpy(&dst_prev->metrics, &rt->u.dst.metrics, sizeof(dst_prev->metrics)); - dst_prev->path = &rt->u.dst; + dst_hold(&rt0->u.dst); + dst_prev->path = &rt0->u.dst; /* Copy neighbout for reachability confirmation */ dst_prev->neighbour = neigh_clone(rt->u.dst.neighbour); @@ -153,6 +154,10 @@ header_len -= x->u.dst.xfrm->props.header_len; trailer_len -= x->u.dst.xfrm->props.trailer_len; } + + rt0->u.dst.metrics[RTAX_MTU-1] = + dst->get_mss(dst, dst_metric(dst, RTAX_MTU)) - dst->header_len; + *dst_p = dst; return 0; @@ -227,9 +232,6 @@ { struct dst_entry *path = dst->path; - if (mtu < 68 + dst->header_len) - return; - path->ops->update_pmtu(path, mtu); } Index: net/ipv4/xfrm4_tunnel.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/xfrm4_tunnel.c,v retrieving revision 1.3 diff -u -r1.3 xfrm4_tunnel.c --- a/net/ipv4/xfrm4_tunnel.c 28 Sep 2003 01:39:20 -0000 1.3 +++ b/net/ipv4/xfrm4_tunnel.c 19 Apr 2004 12:17:05 -0000 @@ -24,7 +24,7 @@ goto out; dst = skb->dst; - mtu = dst_pmtu(dst) - dst->header_len - dst->trailer_len; + mtu = dst_pmtu(dst); if (skb->len > mtu) { icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); ret = -EMSGSIZE; --uAKRQypu60I7Lcqm-- From syrius.ml@no-log.org Mon Apr 19 07:00:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 07:00:35 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JE01KO006038 for ; Mon, 19 Apr 2004 07:00:21 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id 84643361B3; Mon, 19 Apr 2004 14:40:20 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id 74ECF3622E; Mon, 19 Apr 2004 14:40:19 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 4E6C8F3; Mon, 19 Apr 2004 14:33:16 +0200 (CEST) To: hadi@cyberus.ca Cc: Andy Furniss , netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <407E5905.9070108@dsl.pipex.com> <1082031313.1039.13.camel@jzny.localdomain> <407EE3E5.8060200@dsl.pipex.com> <1082087553.1035.287.camel@jzny.localdomain> <4080356F.4020609@dsl.pipex.com> <1082145341.1026.125.camel@jzny.localdomain> <40810957.6030209@dsl.pipex.com> <1082203795.1043.18.camel@jzny.localdomain> From: syrius.ml@no-log.org Date: Mon, 19 Apr 2004 14:33:16 +0200 In-Reply-To: <1082203795.1043.18.camel@jzny.localdomain> (hadi@cyberus.ca's message of "17 Apr 2004 08:09:55 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4758 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 554 Lines: 14 [...] > - packets from local Lan can be marked at ingress and redirect to a > dummy if needed. Infact you can do this on the egress at ppp0 as well > using the new tc -i that i introduced. So this is easy. Hmm I don't see -i option in the patches. what's the point of having a -i option ? does it mean I can work on egress at ppp0 and use -i eth0 to match packets that were originaly from eth0 ? I personnaly use netfilter to mark packets and 'handle $mark fw' to filter them. (that may explain why i don't see the point :-) -- From syrius.ml@no-log.org Mon Apr 19 07:30:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 07:30:12 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JEU6KO009239 for ; Mon, 19 Apr 2004 07:30:07 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id 2FDBE2EC65; Mon, 19 Apr 2004 16:30:01 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id 1858E36054; Mon, 19 Apr 2004 16:30:00 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 72CD9F3; Mon, 19 Apr 2004 16:22:30 +0200 (CEST) To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. From: syrius.ml@no-log.org Importance: high Date: Mon, 19 Apr 2004 16:22:30 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4759 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 2941 Lines: 79 Ok it's seems to be working as expected for ipv4 traffic: Here is how i'm actually using it: (i use netfilter (for both ipv4 & ipv6) to mark packets) OUT=dummy0 $TC qdisc add dev $OUT root handle 1: htb default 20 # CLASSES $TC class add dev $OUT parent 1: classid 1:1 htb rate $UL ceil $ULC \ prio 0 $TC class add dev $OUT parent 1:1 classid 1:10 htb rate \ $UL1 ceil $ULC1 quantum $QU1 prio 1 $TC class add dev $OUT parent 1:1 classid 1:2 htb rate $UL01 ceil \ $ULC01 quantum $QU01 prio 2 $TC class add dev $OUT parent 1:2 classid 1:20 htb rate $UL2 ceil \ $ULC2 quantum $QU2 prio 3 $TC class add dev $OUT parent 1:2 classid 1:3 htb rate $UL02 ceil \ $ULC02 quantum $QU02 prio 4 $TC class add dev $OUT parent 1:3 classid 1:30 htb rate $UL3 ceil \ $ULC3 quantum $QU3 prio 5 $TC class add dev $OUT parent 1:3 classid 1:40 htb rate $UL4 ceil \ $ULC4 quantum $QU4 prio 5 $TC class add dev $OUT parent 1:3 classid 1:50 htb rate $UL5 ceil \ $ULC5 quantum $QU5 prio 7 $TC qdisc add dev $OUT parent 1:10 handle 110: pfifo limit 50 $TC qdisc add dev $OUT parent 1:20 handle 120: sfq perturb 10 $TC qdisc add dev $OUT parent 1:30 handle 130: sfq perturb 10 $TC qdisc add dev $OUT parent 1:40 handle 140: sfq perturb 10 $TC qdisc add dev $OUT parent 1:50 handle 150: sfq perturb 10 # FILTERS $TC filter add dev $OUT parent 1: protocol ip prio 10 handle 1 fw \ flowid 1:10 $TC filter add dev $OUT parent 1: protocol ipv6 prio 11 handle 1 fw \ flowid 1:10 $TC filter add dev $OUT parent 1: protocol ip prio 12 handle 2 fw \ flowid 1:20 $TC filter add dev $OUT parent 1: protocol ipv6 prio 13 handle 2 fw \ flowid 1:20 $TC filter add dev $OUT parent 1: protocol ip prio 14 handle 3 fw \ flowid 1:30 $TC filter add dev $OUT parent 1: protocol ipv6 prio 15 handle 3 fw \ flowid 1:30 $TC filter add dev $OUT parent 1: protocol ip prio 16 handle 4 fw \ flowid 1:40 $TC filter add dev $OUT parent 1: protocol ipv6 prio 17 handle 4 fw \ flowid 1:40 $TC filter add dev $OUT parent 1: protocol ip prio 18 handle 5 fw \ flowid 1:50 $TC filter add dev $OUT parent 1: protocol ipv6 prio 19 handle 5 fw \ flowid 1:50 $IP link set $OUT up $TC qdisc add dev ppp0 root handle 1: prio $TC filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 $TC qdisc add dev tun0 root handle 1: prio $TC filter add dev tun0 parent 1:0 protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 $TC qdisc add dev sit1 root handle 1: prio $TC filter add dev sit1 parent 1:0 protocol ipv6 prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 but it doesn't work with ipv6 traffic. If I try to ping6 somehost, i sometimes get "ping: sendmsg: No buffer space available" messages anyway, there's nothing going out on sit1. Is it the correct way to do it ? -- From jgarzik@pobox.com Mon Apr 19 09:37:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 09:37:51 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JGbjKO018316 for ; Mon, 19 Apr 2004 09:37:46 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFbmB-0001Wx-T5; Mon, 19 Apr 2004 17:37:44 +0100 Message-ID: <4084004B.50500@pobox.com> Date: Mon, 19 Apr 2004 12:37:31 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: Jeff Cramer , "Feldman, Scott" , Chris Wright , netdev@oss.sgi.com, john.ronciak@intel.com, ganesh.venkatesan@intel.com Subject: Re: [PATCH] e1000 ethtool_ops support References: <20040416155449.0796053f@dell_ss3.pdx.osdl.net> In-Reply-To: <20040416155449.0796053f@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4760 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: 105 Lines: 6 applied to netdev-2.6 queue. In the future please CC the e1000 maintainer, as listed in MAINTAINERS. From jgarzik@pobox.com Mon Apr 19 09:38:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 09:38:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JGcbKO018411 for ; Mon, 19 Apr 2004 09:38:38 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFbn3-0001am-1K; Mon, 19 Apr 2004 17:38:37 +0100 Message-ID: <40840081.8050601@pobox.com> Date: Mon, 19 Apr 2004 12:38:25 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wright CC: netdev@oss.sgi.com Subject: Re: [PATCH] remove redundant check in de2104x ->get_regs() References: <20040416153754.U21045@build.pdx.osdl.net> In-Reply-To: <20040416153754.U21045@build.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4761 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 10 Lines: 3 applied From jgarzik@pobox.com Mon Apr 19 09:45:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 09:45:15 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JGjAKO019086 for ; Mon, 19 Apr 2004 09:45:11 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFbtL-0001sq-QC; Mon, 19 Apr 2004 17:45:07 +0100 Message-ID: <40840208.6060906@pobox.com> Date: Mon, 19 Apr 2004 12:44:56 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.4.26-bk1] netdevice.h add netif_msg_init helper References: <200404162001.i3GK1Y806283@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404162001.i3GK1Y806283@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4762 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 17 Lines: 3 applied to 2.4 From jgarzik@pobox.com Mon Apr 19 09:49:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 09:49:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JGnWKO019438 for ; Mon, 19 Apr 2004 09:49:33 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFbxb-0001zs-Ll; Mon, 19 Apr 2004 17:49:31 +0100 Message-ID: <40840310.4090101@pobox.com> Date: Mon, 19 Apr 2004 12:49:20 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Hemminger CC: netdev@oss.sgi.com Subject: Re: [PATCH] Mixed PCI/ISA device name conflicts References: <20031222091115.42dd5f1f.shemminger@osdl.org> <405F994B.6080501@pobox.com> <20040329153236.0cf427c9@dell_ss3.pdx.osdl.net> <407C33A4.3010804@pobox.com> <20040416094614.5d5775dd@dell_ss3.pdx.osdl.net> In-Reply-To: <20040416094614.5d5775dd@dell_ss3.pdx.osdl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4763 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: 33 Lines: 3 applied, thanks for the resend From jgarzik@pobox.com Mon Apr 19 09:51:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 09:51:37 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JGpWKO019754 for ; Mon, 19 Apr 2004 09:51:33 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFbzX-00021M-Ma; Mon, 19 Apr 2004 17:51:31 +0100 Message-ID: <40840387.40605@pobox.com> Date: Mon, 19 Apr 2004 12:51:19 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 2.4.26-rc3]pcnet32 fix hang/crash with loopback test References: <200404132208.i3DM8BB01509@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404132208.i3DM8BB01509@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4764 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: 263 Lines: 8 Don Fry wrote: > If the pcnet32 interface is not up, running the loopback test may hang or > crash the system. This patch provided by Jim Lewis fixes that problem. > Tested on ia32 and ppc systems. This applies cleanly against net-drivers-2.4 applied to 2.4 From jgarzik@pobox.com Mon Apr 19 10:01:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 10:01:36 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JH1RKO020241 for ; Mon, 19 Apr 2004 10:01:27 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFc95-00029s-P1; Mon, 19 Apr 2004 18:01:23 +0100 Message-ID: <408405D7.7010209@pobox.com> Date: Mon, 19 Apr 2004 13:01:11 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH] pcnet32.c add support for 79C976 References: <200403292112.i2TLCGD10901@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200403292112.i2TLCGD10901@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4765 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 17 Lines: 3 applied to 2.6 From jgarzik@pobox.com Mon Apr 19 10:03:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 10:03:27 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JH3LKO020562 for ; Mon, 19 Apr 2004 10:03:22 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFcAy-0002Bm-RZ; Mon, 19 Apr 2004 18:03:21 +0100 Message-ID: <4084064D.7000901@pobox.com> Date: Mon, 19 Apr 2004 13:03:09 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: daniel.ritz@gmx.ch CC: netdev@oss.sgi.com Subject: Re: [PATCH 2.6] missing s/dev->priv/netdev_priv(dev) in drivers/net/pcmcia/ References: <200403242315.53770.daniel.ritz@gmx.ch> <40620ADD.90307@pobox.com> <200403242327.28378.daniel.ritz@gmx.ch> In-Reply-To: <200403242327.28378.daniel.ritz@gmx.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4766 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: 2716 Lines: 80 Daniel Ritz wrote: > On Wednesday 24 March 2004 23:25, Jeff Garzik wrote: > >>Daniel Ritz wrote: >> >>>clean up the last two instances of dev->priv in drivers/net/pcmcia. >>>against 2.6.5-rc2-bk. >>> >>>--- 1.27/drivers/net/pcmcia/3c589_cs.c Wed Mar 3 01:03:51 2004 >>>+++ edited/drivers/net/pcmcia/3c589_cs.c Wed Mar 24 22:29:35 2004 >>>@@ -716,7 +716,7 @@ >>> "status %4.4x.\n", dev->name, (long)skb->len, >>> inw(ioaddr + EL3_STATUS)); >>> >>>- ((struct el3_private *)dev->priv)->stats.tx_bytes += skb->len; >>>+ ((struct el3_private *)netdev_priv(dev))->stats.tx_bytes += skb->len; >>> >>> /* Put out the doubleword header... */ >>> outw(skb->len, ioaddr + TX_FIFO); >>>--- 1.24/drivers/net/pcmcia/ibmtr_cs.c Wed Mar 3 01:06:03 2004 >>>+++ edited/drivers/net/pcmcia/ibmtr_cs.c Wed Mar 24 22:29:51 2004 >>>@@ -444,7 +444,7 @@ >>> link->state &= ~DEV_PRESENT; >>> if (link->state & DEV_CONFIG) { >>> /* set flag to bypass normal interrupt code */ >>>- ((struct tok_info *)dev->priv)->sram_virt |= 1; >>>+ ((struct tok_info *)netdev_priv(dev))->sram_virt |= 1; >>> netif_device_detach(dev); >>> ibmtr_release(link); >> >> >>although the patch is OK, the code itself is a bit yucky. >> >>Can you please create a temporary variable, of struct el3_private or >>tok_info type, and eliminate that cast? >> >>struct el3_private *priv = netdev_priv(dev); >>priv->stats.tx_bytes += skb->len; >> >>Much nicer :) >> > > > agreed. here we go... > > --- 1.27/drivers/net/pcmcia/3c589_cs.c Wed Mar 3 01:03:51 2004 > +++ edited/drivers/net/pcmcia/3c589_cs.c Wed Mar 24 23:22:59 2004 > @@ -711,12 +711,13 @@ > static int el3_start_xmit(struct sk_buff *skb, struct net_device *dev) > { > ioaddr_t ioaddr = dev->base_addr; > + struct el3_private *priv = netdev_priv(dev); > > DEBUG(3, "%s: el3_start_xmit(length = %ld) called, " > "status %4.4x.\n", dev->name, (long)skb->len, > inw(ioaddr + EL3_STATUS)); > > - ((struct el3_private *)dev->priv)->stats.tx_bytes += skb->len; > + priv->stats.tx_bytes += skb->len; > > /* Put out the doubleword header... */ > outw(skb->len, ioaddr + TX_FIFO); > --- 1.24/drivers/net/pcmcia/ibmtr_cs.c Wed Mar 3 01:06:03 2004 > +++ edited/drivers/net/pcmcia/ibmtr_cs.c Wed Mar 24 23:24:39 2004 > @@ -444,7 +444,8 @@ > link->state &= ~DEV_PRESENT; > if (link->state & DEV_CONFIG) { > /* set flag to bypass normal interrupt code */ > - ((struct tok_info *)dev->priv)->sram_virt |= 1; > + struct tok_info *priv = netdev_priv(dev); > + priv->sram_virt |= 1; > netif_device_detach(dev); > ibmtr_release(link); > } applied to 2.6 From jgarzik@pobox.com Mon Apr 19 10:05:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 10:05:31 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JH5QKO020945 for ; Mon, 19 Apr 2004 10:05:27 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BFcCz-0002Ep-Kd; Mon, 19 Apr 2004 18:05:25 +0100 Message-ID: <408406C9.4050104@pobox.com> Date: Mon, 19 Apr 2004 13:05:13 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pavel Roskin CC: netdev@oss.sgi.com Subject: Re: [PATCH] Tulip endianess fix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4767 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: 25 Lines: 3 applied to 2.4 and 2.6 From oxymoron@waste.org Mon Apr 19 10:43:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 10:43:47 -0700 (PDT) Received: from waste.org (waste.org [209.173.204.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JHhKKO021758 for ; Mon, 19 Apr 2004 10:43:41 -0700 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3JHgxDM021894; Mon, 19 Apr 2004 12:42:59 -0500 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-6.6) id i3JHgskT021866; Mon, 19 Apr 2004 12:42:54 -0500 Date: Mon, 19 Apr 2004 12:42:54 -0500 From: Matt Mackall To: Hariprasad Nellitheertha Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, mingo@elte.hu, suparna@in.ibm.com Subject: Re: Problem with Netpoll based netdumping and NAPI Message-ID: <20040419174254.GQ1175@waste.org> References: <20040419125148.GA4495@in.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040419125148.GA4495@in.ibm.com> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavisd-new X-archive-position: 4768 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev Content-Length: 1578 Lines: 37 [changed cc: from linux-net to netdev] On Mon, Apr 19, 2004 at 06:21:48PM +0530, Hariprasad Nellitheertha wrote: > Hi All, > > I am facing a problem while trying to network dump using LKCD. My > debugging so far indicates that this is due to both NAPI and NETPOLL > being enabled. > > I am using LKCD on the 2.6.5 kernel and both the client and server are > i386 boxes. The dumping machine has an e100 card. I have built the kernel > with both CONFIG_E100_NAPI and CONFIG_NET_POLL_CONTROLLER (and the other > netpoll related options) selected. > > LKCD uses netpoll for its network dump implementation. The problem we see > is that the network dump driver does not receive any packet from the > card driver and hence dumping fails. In e100_intr(), we call > netif_rx_schedule() if we are using the NAPI feature. netif_rx_schedule, > in turn, ends up adding the processing of this packet to the NET_RX_SOFTIRQ > softirq. Netpoll should be manually calling the NAPI poll function like this after calling the interrupt handler (in netpoll_poll()): /* If scheduling is stopped, tickle NAPI bits */ if(trapped && np->dev->poll && test_bit(__LINK_STATE_RX_SCHED, &np->dev->state)) np->dev->poll(np->dev, &budget); Please ensure that LKCD is calling netpoll_set_trap(1) which tells it that packet scheduling is stopped. I've tested this path primarily with tg3 and kgdb-over-ethernet, but it should be functionally quite similar to e100 and lkcd. -- Matt Mackall : http://www.selenic.com : Linux development and consulting From jonmason@us.ibm.com Mon Apr 19 11:10:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 11:10:56 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JIAjKO022404 for ; Mon, 19 Apr 2004 11:10:51 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3JIAOnr137162; Mon, 19 Apr 2004 14:10:24 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3JIACZc135384; Mon, 19 Apr 2004 12:10:23 -0600 To: romieu@fr.zoreil.com Cc: netdev@oss.sgi.com MIME-Version: 1.0 Subject: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Mon, 19 Apr 2004 13:10:09 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/19/2004 12:10:23, Serialize complete at 04/19/2004 12:10:23 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4769 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 6412 Lines: 197 Bonjour Francois, Below is my implementation of NAPI for the r8169 driver. I wrote and tested it on an x86_64 box running the 2.6.6-rc1 kernel, and it appears to work well. Let me know if you see anything you do not like in it, and I'll be happy to change it. Thanks, Jon #diff -Narup Kconfig.orig Kconfig --- Kconfig.orig 2004-04-19 13:01:05.594735288 -0500 +++ Kconfig 2004-04-18 09:23:40.000000000 -0500 @@ -1976,6 +1962,10 @@ config R8169 To compile this driver as a module, choose M here: the module will be called r8169. This is recommended. +config R8169_NAPI + bool "Use Rx Polling (NAPI) (EXPERIMENTAL)" + depends on R8169 && EXPERIMENTAL + config SK98LIN tristate "Marvell Yukon Chipset / SysKonnect SK-98xx Support" depends on PCI # diff -Narup r8169.c.orig r8169.c --- r8169.c.orig 2004-04-18 22:51:33.000000000 -0500 +++ r8169.c 2004-04-19 07:47:13.679621544 -0500 @@ -111,6 +111,9 @@ static int multicast_filter_limit = 32; #define RTL_R16(reg) readw (ioaddr + (reg)) #define RTL_R32(reg) ((unsigned long) readl (ioaddr + (reg))) +/* The number of Rx iterations processed (if NAPI enabled) */ +#define R8169_NAPI_WEIGHT 16 + enum mac_version { RTL_GIGA_MAC_VER_B = 0x00, /* RTL_GIGA_MAC_VER_C = 0x03, */ @@ -347,6 +350,9 @@ static int rtl8169_close(struct net_devi static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget); +#endif static const u16 rtl8169_intr_mask = RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; @@ -840,6 +846,11 @@ rtl8169_init_one(struct pci_dev *pdev, c dev->irq = pdev->irq; dev->base_addr = (unsigned long) ioaddr; // dev->do_ioctl = mii_ioctl; +#ifdef CONFIG_R8169_NAPI + dev->poll = rtl8169_poll; + dev->weight = R8169_NAPI_WEIGHT; + printk(KERN_INFO "r8169 NAPI enabled\n"); +#endif tp = dev->priv; // private data // tp->pci_dev = pdev; @@ -990,7 +1001,10 @@ rtl8169_remove_one(struct pci_dev *pdev) assert(dev != NULL); assert(tp != NULL); + printk(KERN_INFO "Before unregister_netdev %d\n", atomic_read(&dev->refcnt)); unregister_netdev(dev); + printk(KERN_INFO "After unregister_netdev\n"); + iounmap(tp->mmio_addr); pci_release_regions(pdev); @@ -1309,6 +1323,7 @@ rtl8169_tx_timeout(struct net_device *de void *ioaddr = tp->mmio_addr; u8 tmp8; + printk(KERN_INFO "%s: TX Timeout\n", dev->name); /* disable Tx, if not already */ tmp8 = RTL_R8(ChipCmd); if (tmp8 & CmdTxEnb) @@ -1445,12 +1460,13 @@ static inline int rtl8169_try_rx_copy(st return ret; } -static void +static int rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void *ioaddr) { unsigned long cur_rx, rx_left; int delta; + uint32_t count = 0; assert(dev != NULL); assert(tp != NULL); @@ -1497,7 +1513,11 @@ rtl8169_rx_interrupt(struct net_device * skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); +#ifdef CONFIG_R8169_NAPI + netif_receive_skb(skb); +#else netif_rx(skb); +#endif dev->last_rx = jiffies; tp->stats.rx_bytes += pkt_size; @@ -1506,15 +1526,17 @@ rtl8169_rx_interrupt(struct net_device * cur_rx++; rx_left--; + count++; } tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta > 0) - tp->dirty_rx += delta; - else if (delta < 0) + if (delta < 0) { printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); + delta = 0; + } + tp->dirty_rx += delta; /* * FIXME: until there is periodic timer to try and refill the ring, @@ -1525,6 +1547,8 @@ rtl8169_rx_interrupt(struct net_device * */ if (tp->dirty_rx + NUM_RX_DESC == tp->cur_rx) printk(KERN_EMERG "%s: Rx buffers exhausted\n", dev->name); + + return count; } /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ @@ -1558,7 +1582,19 @@ rtl8169_interrupt(int irq, void *dev_ins // Rx interrupt if (status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) { +#ifdef CONFIG_R8169_NAPI + if(netif_rx_schedule_prep(dev)) { + RTL_W16(IntrMask, rtl8169_intr_mask | + ~(RxOK | RxUnderrun | RxOverflow | RxFIFOOver)); + __netif_rx_schedule(dev); + } else { + printk(KERN_INFO "driver bug! interrupt while in poll\n"); + RTL_W16(IntrMask, rtl8169_intr_mask | + ~(RxOK | RxUnderrun | RxOverflow | RxFIFOOver)); + } +#else rtl8169_rx_interrupt(dev, tp, ioaddr); +#endif } // Tx interrupt if (status & (TxOK | TxErr)) { @@ -1692,6 +1728,28 @@ static struct net_device_stats *rtl8169_ return &tp->stats; } +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget) +{ + uint32_t work_done = 0, + work_to_do = min(*budget, dev->quota); + struct rtl8169_private *tp = (struct rtl8169_private *)dev->priv; + void *ioaddr = tp->mmio_addr; + + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); + + *budget -= work_done; + dev->quota -= work_done; + + if (!work_done || !netif_running(dev)) { + netif_rx_complete(dev); + RTL_W16(IntrMask, rtl8169_intr_mask); + } + + return (work_done >= work_to_do); +} +#endif + static struct pci_driver rtl8169_pci_driver = { .name = MODULENAME, .id_table = rtl8169_pci_tbl From romieu@fr.zoreil.com Mon Apr 19 12:28:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 12:29:06 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JJSXKO026801 for ; Mon, 19 Apr 2004 12:28:54 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3JIPWuX017263; Mon, 19 Apr 2004 20:25:32 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3JIPUOm017262; Mon, 19 Apr 2004 20:25:30 +0200 Date: Mon, 19 Apr 2004 20:25:30 +0200 From: Francois Romieu To: Jon D Mason Cc: netdev@oss.sgi.com, jgarzik@pobox.com Subject: Re: [PATCH] r8169 NAPI addition Message-ID: <20040419202530.A16586@electric-eye.fr.zoreil.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jonmason@us.ibm.com on Mon, Apr 19, 2004 at 01:10:09PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4770 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 3885 Lines: 126 Jon D Mason : [...] > +/* The number of Rx iterations processed (if NAPI enabled) */ > +#define R8169_NAPI_WEIGHT 16 > + May be a bit low. 64 ? [...] > @@ -990,7 +1001,10 @@ rtl8169_remove_one(struct pci_dev *pdev) > assert(dev != NULL); > assert(tp != NULL); > > + printk(KERN_INFO "Before unregister_netdev %d\n", > atomic_read(&dev->refcnt)); > unregister_netdev(dev); > + printk(KERN_INFO "After unregister_netdev\n"); > + > iounmap(tp->mmio_addr); > pci_release_regions(pdev); What is the previous change intended for ? [...] > rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, > void *ioaddr) > { > unsigned long cur_rx, rx_left; > int delta; > + uint32_t count = 0; ^^^^^^^^ The r8169 driver mostly uses u32 and such. A plain old int would be enough. [...] > @@ -1497,7 +1513,11 @@ rtl8169_rx_interrupt(struct net_device * > > skb_put(skb, pkt_size); > skb->protocol = eth_type_trans(skb, dev); > +#ifdef CONFIG_R8169_NAPI > + netif_receive_skb(skb); > +#else > netif_rx(skb); > +#endif I'd probably favor something like r8169_rx_skb() to avoid the flashy #ifdef. [...] > @@ -1558,7 +1582,19 @@ rtl8169_interrupt(int irq, void *dev_ins > > // Rx interrupt > if (status & (RxOK | RxUnderrun | RxOverflow | > RxFIFOOver)) { > +#ifdef CONFIG_R8169_NAPI > + if(netif_rx_schedule_prep(dev)) { ^^^ -> "if (" please. > + RTL_W16(IntrMask, rtl8169_intr_mask | > + ~(RxOK | RxUnderrun | RxOverflow | > RxFIFOOver)); > + __netif_rx_schedule(dev); > + } else { > + printk(KERN_INFO "driver bug! interrupt > while in poll\n"); > + RTL_W16(IntrMask, rtl8169_intr_mask | > + ~(RxOK | RxUnderrun | RxOverflow | > RxFIFOOver)); > + } > +#else > rtl8169_rx_interrupt(dev, tp, ioaddr); > +#endif > } > // Tx interrupt > if (status & (TxOK | TxErr)) { > @@ -1692,6 +1728,28 @@ static struct net_device_stats *rtl8169_ > return &tp->stats; > } > > +#ifdef CONFIG_R8169_NAPI > +static int rtl8169_poll(struct net_device *dev, int *budget) > +{ > + uint32_t work_done = 0, ^^^^^^^^ See above. > + work_to_do = min(*budget, dev->quota); Please put this on a separate line after the declarations of the variables. > + struct rtl8169_private *tp = (struct rtl8169_private *)dev->priv; The cast is not needed (nor used anywhere in the current driver). > + void *ioaddr = tp->mmio_addr; > + > + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); Nothing will prevent rtl8169_rx_interrupt() to process packets in excess of *budget. A simple min(rx_left, *budget) for rx_left in rtl8169_rx_interrupt() should fix it. > + > + *budget -= work_done; > + dev->quota -= work_done; > + > + if (!work_done || !netif_running(dev)) { > + netif_rx_complete(dev); > + RTL_W16(IntrMask, rtl8169_intr_mask); - it may as well complete as soon as work_done > 0. Not all drivers are equally fair in this regard. - if irq are not disabled, the previous code will race with the irq handler. Btw, be it here or in rtl8169_interrupt(), RTL_W16() is a posted pci write. Global remarks: - you probably want a larger Rx ring; - please tell Notes to not turn the tabs into whitespaces. Have you considered Tx napi ? :o) Please Cc: Jeff. -- Ueimor From A.Verweij2@ewi.tudelft.nl Mon Apr 19 13:11:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 13:11:22 -0700 (PDT) Received: from mailhst2.its.tudelft.nl (mailhst2.its.tudelft.nl [130.161.34.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JKBEKO027860 for ; Mon, 19 Apr 2004 13:11:17 -0700 Received: from elektron.its.tudelft.nl (elektron.its.tudelft.nl [130.161.33.15]) by mailhst2.its.tudelft.nl (8.11.6p2/8.11.6) with ESMTP id i3JKBA117052; Mon, 19 Apr 2004 22:11:11 +0200 (METDST) Received: from localhost (verwei90@localhost) by elektron.its.tudelft.nl (8.9.3 (PHNE_26305)/8.9.3) with ESMTP id WAA12562; Mon, 19 Apr 2004 22:11:10 +0200 (METDST) Date: Mon, 19 Apr 2004 22:11:10 +0200 (METDST) From: Arjen Verweij Reply-To: a.verweij@student.tudelft.nl To: netdev@oss.sgi.com cc: adq@lidskialf.net Subject: wol support in forcedeth v25 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4771 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: A.Verweij2@ewi.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 802 Lines: 21 Hi, Is the wol support in forcedeth v25 complete yet? I was trying it with the 2.6.5 kernel it came with, tried the new forcedeth driver with a 2.6.3 kernel (because firewire seems broken in 2.6.5) however, my box will not wake up as of yet. According to the source there is a FIXME with a comment about powering down the NIC. Does this mean that support for wol is incomplete for now? Mind you, I am just curious, this is in no way meant as criticism. On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be removed from future releases. Is this still the case? Feedback would be much appreciated, so I can keep my humble audience up to date on what's going on at the wol front. Thank you guys for your excellent work, Arjen http://atlas.et.tudelft.nl/verwei90/nforce2/index.html From jonmason@us.ibm.com Mon Apr 19 13:58:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 13:58:26 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JKw5KQ028824 for ; Mon, 19 Apr 2004 13:58:21 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3JKvx5N506770; Mon, 19 Apr 2004 16:58:00 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3JKvxKL358212; Mon, 19 Apr 2004 14:57:59 -0600 In-Reply-To: <20040419202530.A16586@electric-eye.fr.zoreil.com> To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Mon, 19 Apr 2004 15:57:55 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/19/2004 14:57:58, Serialize complete at 04/19/2004 14:57:58 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4772 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4833 Lines: 148 [...] >> +/* The number of Rx iterations processed (if NAPI enabled) */ >> +#define R8169_NAPI_WEIGHT 16 >> + >May be a bit low. 64 ? I used 16 because it was in the NAPI documentation. The e1000 and tg3 use 64, so that is good enough for me. Done. [...] >> @@ -990,7 +1001,10 @@ rtl8169_remove_one(struct pci_dev *pdev) >> assert(dev != NULL); >> assert(tp != NULL); >> >> + printk(KERN_INFO "Before unregister_netdev %d\n", >> atomic_read(&dev->>refcnt)); >> unregister_netdev(dev); >> + printk(KERN_INFO "After unregister_netdev\n"); >> + >> iounmap(tp->>mmio_addr); >> pci_release_regions(pdev); >What is the previous change intended for ? Sorry, it was debug code for an unrelated error. Removed. [...] >> rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, >> void *ioaddr) >> { >> unsigned long cur_rx, rx_left; >> int delta; >> + uint32_t count = 0; > ^^^^^^^^ >The r8169 driver mostly uses u32 and such. A plain old int would be enough. Unsigned variables are a little bit faster on ppc hardware. I figgured that it doesn't matter on x86/x86_64, but would help other archatectures. [...] >> @@ -1497,7 +1513,11 @@ rtl8169_rx_interrupt(struct net_device * >> >> skb_put(skb, pkt_size); >> skb->>protocol = eth_type_trans(skb, dev); >> +#ifdef CONFIG_R8169_NAPI >> + netif_receive_skb(skb); >> +#else >> netif_rx(skb); >> +#endif >I'd probably favor something like r8169_rx_skb() to avoid the flashy #ifdef. I can try and hide as many #ifdefs as possible if you like, just didn't know your preferance. Will do. [...] >> @@ -1558,7 +1582,19 @@ rtl8169_interrupt(int irq, void *dev_ins >> >> // Rx interrupt >> if (status & (RxOK | RxUnderrun | RxOverflow | >> RxFIFOOver)) { >> +#ifdef CONFIG_R8169_NAPI >> + if(netif_rx_schedule_prep(dev)) { ^^^ >> "if (" please. Done. >> @@ -1692,6 +1728,28 @@ static struct net_device_stats *rtl8169_ >> return &tp->stats; >> } >> >> +#ifdef CONFIG_R8169_NAPI >> +static int rtl8169_poll(struct net_device *dev, int *budget) >> +{ >> + uint32_t work_done = 0, >> + work_to_do = min(*budget, dev->>quota); > >Please put this on a separate line after the declarations of the variables. This is declaration and assignment. Would you prefer decleration and assignment seperate? >> + struct rtl8169_private *tp = (struct rtl8169_private *)dev->priv; >The cast is not needed (nor used anywhere in the current driver). Removed. >> + void *ioaddr = tp->mmio_addr; >> + >> + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); > >Nothing will prevent rtl8169_rx_interrupt() to process packets in >excess of *budget. A simple min(rx_left, *budget) for rx_left in >rtl8169_rx_interrupt() should fix it. That's true, I just didn't want to be too invasive in the Rx code. Will do. >> + >> + *budget -= work_done; >> + dev->>quota -= work_done; >> + >> + if (!work_done || !netif_running(dev)) { >> + netif_rx_complete(dev); >> + RTL_W16(IntrMask, rtl8169_intr_mask); > >- it may as well complete as soon as work_done > 0. Not all drivers > are equally fair in this regard. This is true. Adding the requested rx_interrupt changes will fix this. >- if irq are not disabled, the previous code will race with the irq > handler. Btw, be it here or in rtl8169_interrupt(), RTL_W16() is a > posted pci write. I could be wrong, but I don't think its possible to be in the poll function with interrupts turned on. The work scheduling is done in the interrupt handler, which turns off the Rx interrupts. I could turn off interrupts prior to schduling the work in the interrupt handler, but I'm not sure that is necessary. Not sure the significance of RTL_W16 being a posted pci write. Can you clarify its significance for me? >Global remarks: >- you probably want a larger Rx ring; It might be better to be a user turnable parameter, but I can increase the size for NAPI useage. Any perefance as to the ring size? >- please tell Notes to not turn the tabs into whitespaces. I hate Notes! Be assured that they are tabs and not whitespaces. If you perfer, I can have the diffs as an attachment. >Have you considered Tx napi ? :o) Actually, I have a copy of the driver that does Tx. After reading the NAPI howto, which states that there is a slight performance degridadtion if Tx is NAPI too, I figgured that you would want only Rx. I can add Tx if you like. >Please Cc: Jeff. Sorry, I will copy him on directly (instead of the indirect netdev). From romieu@fr.zoreil.com Mon Apr 19 14:52:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 14:52:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JLqWKO000973 for ; Mon, 19 Apr 2004 14:52:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3JKnDuX019816; Mon, 19 Apr 2004 22:49:13 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3JKnB5d019815; Mon, 19 Apr 2004 22:49:11 +0200 Date: Mon, 19 Apr 2004 22:49:11 +0200 From: Francois Romieu To: Jon D Mason Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] r8169 NAPI addition Message-ID: <20040419224911.A17362@electric-eye.fr.zoreil.com> References: <20040419202530.A16586@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jonmason@us.ibm.com on Mon, Apr 19, 2004 at 03:57:55PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4773 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2791 Lines: 88 Jon D Mason : [...] > Unsigned variables are a little bit faster on ppc hardware. I figgured > that it doesn't matter on x86/x86_64, but would help other archatectures. Ok. No objection against an unsigned int or an u32 instead ? [...] > >> +#ifdef CONFIG_R8169_NAPI > >> + netif_receive_skb(skb); > >> +#else > >> netif_rx(skb); > >> +#endif > >I'd probably favor something like r8169_rx_skb() to avoid the flashy > #ifdef. > > I can try and hide as many #ifdefs as possible if you like, just didn't > know your preferance. Will do. (sometimes hch is bored and dissects network patches too :o) ) I have no suggestion for the others #ifdef but at least this one can be isolated. [...] > >> +static int rtl8169_poll(struct net_device *dev, int *budget) > >> +{ > >> + uint32_t work_done = 0, > >> + work_to_do = min(*budget, dev->>quota); > > > >Please put this on a separate line after the declarations of the > variables. > > This is declaration and assignment. Would you prefer decleration and > assignment seperate? Anything as long as it avoids the indentation of a line in the declaration block. [...] > I could be wrong, but I don't think its possible to be in the poll > function with interrupts turned on. The work scheduling is done in the > interrupt handler, which turns off the Rx interrupts. I could turn off I fail to see where the Tx interrupts are disabled. [...] > Not sure the significance of RTL_W16 being a posted pci write. Can you > clarify its significance for me? The locking scheme which will be used between ->poll() and ->interrupt() should guarantee some ordering of the registers operations (provided they appear in the locked section). However, if no read is issued, no one knows when the write will actually hit the chipset. (I should probably check this in the epic100 changes as well) > >Global remarks: > >- you probably want a larger Rx ring; > > It might be better to be a user turnable parameter, but I can increase the > size for NAPI useage. Any perefance as to the ring size? (wet finger in the wind) 256 [...] > I hate Notes! Be assured that they are tabs and not whitespaces. If you > perfer, I can have the diffs as an attachment. If it helps, please do. > >Have you considered Tx napi ? :o) > Actually, I have a copy of the driver that does Tx. After reading the > NAPI howto, which states that there is a slight performance degridadtion > if Tx is NAPI too, I figgured that you would want only Rx. I can add Tx > if you like. Separate patches are usually easier to review, yes. [...] > Sorry, I will copy him on directly (instead of the indirect netdev). Please keep netdev@oss.sgi.com Cced as well. -- Ueimor From sri@us.ibm.com Mon Apr 19 15:11:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 15:12:01 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JMBnKO001706 for ; Mon, 19 Apr 2004 15:11:56 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3JMBSAL827496; Mon, 19 Apr 2004 18:11:28 -0400 Received: from w-sridhar.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3JMBVJW052386; Mon, 19 Apr 2004 18:11:32 -0400 Date: Mon, 19 Apr 2004 15:11:26 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: davem@redhat.com cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: [BK PATCH] PR-SCTP support, misc SCTP cleanups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4774 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1840 Lines: 75 Dave, Please do a bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work & bk pull http://linux-lksctp.bkbits.net/lksctp-2.4.work to get the following updates to 2.6 and 2.4 SCTP. The updates include PR-SCTP(partial reliability extension) support and some misc. bug fixes and cleanups. Thanks Sridhar # ChangeSet # 2004/04/19 11:26:22-07:00 sri@us.ibm.com # [SCTP] Propagate error from sctp_proc_init. (Olaf Kirch) # # net/sctp/protocol.c # # ChangeSet # 2004/04/19 10:58:26-07:00 sri@us.ibm.com # [SCTP] Partial Reliability Extension support. # # net/sctp/ulpqueue.c # net/sctp/tsnmap.c # net/sctp/sysctl.c # net/sctp/sm_statetable.c # net/sctp/sm_statefuns.c # net/sctp/sm_sideeffect.c # net/sctp/sm_make_chunk.c # net/sctp/protocol.c # net/sctp/outqueue.c # net/sctp/output.c # net/sctp/debug.c # net/sctp/chunk.c # net/sctp/associola.c # include/net/sctp/ulpqueue.h # include/net/sctp/tsnmap.h # include/net/sctp/structs.h # include/net/sctp/sm.h # include/net/sctp/sctp.h # include/net/sctp/constants.h # include/net/sctp/command.h # include/linux/sysctl.h # include/linux/sctp.h # # ChangeSet # 2004/04/19 10:46:21-07:00 sri@us.ibm.com # [SCTP] Cleanup sctp_packet and sctp_outq infrastructure. # # net/sctp/transport.c # net/sctp/sm_statefuns.c # net/sctp/outqueue.c # net/sctp/output.c # net/sctp/associola.c # include/net/sctp/structs.h # include/net/sctp/constants.h # # ChangeSet # 2004/04/19 10:36:56-07:00 sri@us.ibm.com # [SCTP] Avoid the use of constant SCTP_IP_OVERHEAD to determine the # max data size in a SCTP packet. # # Calculate the overhead based on the socket's protocol family header # length. # # net/sctp/ulpevent.c # net/sctp/socket.c # net/sctp/outqueue.c # net/sctp/output.c # net/sctp/chunk.c # include/net/sctp/structs.h # include/net/sctp/sctp.h # include/net/sctp/constants.h # From romieu@fr.zoreil.com Mon Apr 19 15:52:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 15:52:38 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JMqWKO002804 for ; Mon, 19 Apr 2004 15:52:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3JLoFuX020530; Mon, 19 Apr 2004 23:50:15 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3JLoFRh020528; Mon, 19 Apr 2004 23:50:15 +0200 Date: Mon, 19 Apr 2004 23:50:14 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [patch 1/2] 2.6.6-rc1-mm1 - spin_unlock_irqrestore avoidance in epic100 Message-ID: <20040419235014.A20504@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 4775 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1758 Lines: 63 This patch avoids to duplicate a spin_unlock: - it is mostly an artifact due to wild goto; - it makes the generated code smaller. diff -puN drivers/net/epic100.c~epic100-napi-40 drivers/net/epic100.c --- linux-2.6.6-rc1/drivers/net/epic100.c~epic100-napi-40 2004-04-20 00:37:05.000000000 +0200 +++ linux-2.6.6-rc1-fr/drivers/net/epic100.c 2004-04-20 00:37:05.000000000 +0200 @@ -632,7 +632,8 @@ static inline void __epic_pci_commit(lon #endif } -static void epic_napi_irq_off(struct net_device *dev, struct epic_private *ep) +static inline void epic_napi_irq_off(struct net_device *dev, + struct epic_private *ep) { long ioaddr = dev->base_addr; @@ -640,7 +641,8 @@ static void epic_napi_irq_off(struct net __epic_pci_commit(ioaddr); } -static void epic_napi_irq_on(struct net_device *dev, struct epic_private *ep) +static inline void epic_napi_irq_on(struct net_device *dev, + struct epic_private *ep) { long ioaddr = dev->base_addr; @@ -1370,20 +1372,24 @@ rx_action: if (netif_running(dev) && (work_done < orig_budget)) { unsigned long flags; + int more; + + /* A bit baroque but it avoids a (space hungry) spin_unlock */ spin_lock_irqsave(&ep->napi_lock, flags); - if (ep->reschedule_in_poll) { + more = ep->reschedule_in_poll; + if (!more) { + __netif_rx_complete(dev); + outl(EpicNapiEvent, ioaddr + INTSTAT); + epic_napi_irq_on(dev, ep); + } else ep->reschedule_in_poll--; - spin_unlock_irqrestore(&ep->napi_lock, flags); - goto rx_action; - } - - outl(EpicNapiEvent, ioaddr + INTSTAT); - epic_napi_irq_on(dev, ep); - __netif_rx_complete(dev); spin_unlock_irqrestore(&ep->napi_lock, flags); + + if (more) + goto rx_action; } return (work_done >= orig_budget); _ From romieu@fr.zoreil.com Mon Apr 19 15:52:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 15:52:39 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JMqWKO002805 for ; Mon, 19 Apr 2004 15:52:33 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3JLqQuX020539; Mon, 19 Apr 2004 23:52:26 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3JLqPqv020538; Mon, 19 Apr 2004 23:52:25 +0200 Date: Mon, 19 Apr 2004 23:52:25 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: netdev@oss.sgi.com Subject: [patch 2/2] 2.6.6-rc1-mm1 - code removal in the epic100 irq handler Message-ID: <20040419235225.A20535@electric-eye.fr.zoreil.com> References: <20040419235014.A20504@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040419235014.A20504@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Mon, Apr 19, 2004 at 11:50:14PM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4776 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 5390 Lines: 157 The loop in the irq handler is not needed any more as the high frequency events have been deferred due to napi usage. diff -puN drivers/net/epic100.c~epic100-napi-50 drivers/net/epic100.c --- linux-2.6.6-rc1/drivers/net/epic100.c~epic100-napi-50 2004-04-20 00:37:16.000000000 +0200 +++ linux-2.6.6-rc1-fr/drivers/net/epic100.c 2004-04-20 00:37:16.000000000 +0200 @@ -77,8 +77,6 @@ These may be modified when a driver module is loaded.*/ static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */ -/* Maximum events (Rx packets, etc.) to handle at each interrupt. */ -static int max_interrupt_work = 32; /* Used to pass the full-duplex flag, etc. */ #define MAX_UNITS 8 /* More are supported, limit only on options */ @@ -155,12 +153,10 @@ MODULE_DESCRIPTION("SMC 83c170 EPIC seri MODULE_LICENSE("GPL"); MODULE_PARM(debug, "i"); -MODULE_PARM(max_interrupt_work, "i"); MODULE_PARM(rx_copybreak, "i"); MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM_DESC(debug, "EPIC/100 debug level (0-5)"); -MODULE_PARM_DESC(max_interrupt_work, "EPIC/100 maximum events handled per interrupt"); MODULE_PARM_DESC(options, "EPIC/100: Bits 0-3: media type, bit 4: full duplex"); MODULE_PARM_DESC(rx_copybreak, "EPIC/100 copy breakpoint for copy-only-tiny-frames"); MODULE_PARM_DESC(full_duplex, "EPIC/100 full duplex setting(s) (1)"); @@ -1162,74 +1158,66 @@ static irqreturn_t epic_interrupt(int ir struct net_device *dev = dev_instance; struct epic_private *ep = dev->priv; long ioaddr = dev->base_addr; - int status, boguscnt = max_interrupt_work; unsigned int handled = 0; + int status; - do { - status = inl(ioaddr + INTSTAT); - /* Acknowledge all of the current interrupt sources ASAP. */ - outl(status & EpicNormalEvent, ioaddr + INTSTAT); + status = inl(ioaddr + INTSTAT); + /* Acknowledge all of the current interrupt sources ASAP. */ + outl(status & EpicNormalEvent, ioaddr + INTSTAT); - if (debug > 4) - printk(KERN_DEBUG "%s: Interrupt, status=%#8.8x new " - "intstat=%#8.8x.\n", - dev->name, status, (int)inl(ioaddr + INTSTAT)); + if (debug > 4) { + printk(KERN_DEBUG "%s: Interrupt, status=%#8.8x new " + "intstat=%#8.8x.\n", dev->name, status, + (int)inl(ioaddr + INTSTAT)); + } - if ((status & IntrSummary) == 0) - break; - handled = 1; + if ((status & IntrSummary) == 0) + goto out; - if ((status & EpicNapiEvent) && !ep->reschedule_in_poll) { - spin_lock(&ep->napi_lock); - if (netif_rx_schedule_prep(dev)) { - epic_napi_irq_off(dev, ep); - __netif_rx_schedule(dev); - } else - ep->reschedule_in_poll++; - spin_unlock(&ep->napi_lock); - } - status &= ~EpicNapiEvent; + handled = 1; - /* Check uncommon events all at once. */ - if (status & - (CntFull | TxUnderrun | PCIBusErr170 | PCIBusErr175)) { - if (status == EpicRemoved) - break; - /* Always update the error counts to avoid overhead later. */ - ep->stats.rx_missed_errors += inb(ioaddr + MPCNT); - ep->stats.rx_frame_errors += inb(ioaddr + ALICNT); - ep->stats.rx_crc_errors += inb(ioaddr + CRCCNT); - - if (status & TxUnderrun) { /* Tx FIFO underflow. */ - ep->stats.tx_fifo_errors++; - outl(ep->tx_threshold += 128, ioaddr + TxThresh); - /* Restart the transmit process. */ - outl(RestartTx, ioaddr + COMMAND); - } - if (status & PCIBusErr170) { - printk(KERN_ERR "%s: PCI Bus Error! EPIC status %4.4x.\n", - dev->name, status); - epic_pause(dev); - epic_restart(dev); - } - /* Clear all error sources. */ - outl(status & 0x7f18, ioaddr + INTSTAT); + if ((status & EpicNapiEvent) && !ep->reschedule_in_poll) { + spin_lock(&ep->napi_lock); + if (netif_rx_schedule_prep(dev)) { + epic_napi_irq_off(dev, ep); + __netif_rx_schedule(dev); + } else + ep->reschedule_in_poll++; + spin_unlock(&ep->napi_lock); + } + status &= ~EpicNapiEvent; + + /* Check uncommon events all at once. */ + if (status & (CntFull | TxUnderrun | PCIBusErr170 | PCIBusErr175)) { + if (status == EpicRemoved) + goto out; + + /* Always update the error counts to avoid overhead later. */ + ep->stats.rx_missed_errors += inb(ioaddr + MPCNT); + ep->stats.rx_frame_errors += inb(ioaddr + ALICNT); + ep->stats.rx_crc_errors += inb(ioaddr + CRCCNT); + + if (status & TxUnderrun) { /* Tx FIFO underflow. */ + ep->stats.tx_fifo_errors++; + outl(ep->tx_threshold += 128, ioaddr + TxThresh); + /* Restart the transmit process. */ + outl(RestartTx, ioaddr + COMMAND); } - if (!(status & EpicNormalEvent)) - break; - if (--boguscnt < 0) { - printk(KERN_ERR "%s: Too much work at interrupt, " - "IntrStatus=0x%8.8x.\n", - dev->name, status); - /* Clear all interrupt sources. */ - outl(0x0001ffff, ioaddr + INTSTAT); - break; + if (status & PCIBusErr170) { + printk(KERN_ERR "%s: PCI Bus Error! status %4.4x.\n", + dev->name, status); + epic_pause(dev); + epic_restart(dev); } - } while (1); + /* Clear all error sources. */ + outl(status & 0x7f18, ioaddr + INTSTAT); + } - if (debug > 3) - printk(KERN_DEBUG "%s: exiting interrupt, intr_status=%#4.4x.\n", - dev->name, status); +out: + if (debug > 3) { + printk(KERN_DEBUG "%s: exit interrupt, intr_status=%#4.4x.\n", + dev->name, status); + } return IRQ_RETVAL(handled); } _ From adq@lidskialf.net Mon Apr 19 16:07:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 16:07:14 -0700 (PDT) Received: from beyond.lidskialf.net (lidskialf.net [62.3.233.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JN78KO003686 for ; Mon, 19 Apr 2004 16:07:09 -0700 Received: from monstrousfish (monstrousfish [172.16.1.2]) by beyond.lidskialf.net (Postfix) with ESMTP id E2C3D9373; Tue, 20 Apr 2004 00:10:45 +0100 (BST) From: Andrew de Quincey To: a.verweij@student.tudelft.nl Subject: Re: wol support in forcedeth v25 Date: Tue, 20 Apr 2004 00:07:59 +0100 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline X-UID: 49 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404200007.59345.adq@lidskialf.net> X-archive-position: 4777 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adq@lidskialf.net Precedence: bulk X-list: netdev Content-Length: 1152 Lines: 27 On Monday 19 April 2004 21:11, Arjen Verweij wrote: > Hi, > > Is the wol support in forcedeth v25 complete yet? I was trying it with the > 2.6.5 kernel it came with, tried the new forcedeth driver with a 2.6.3 > kernel (because firewire seems broken in 2.6.5) however, my box will not > wake up as of yet. You're right! It _was_ working with patch-forced-0.25, but it ain't in 2.6.5. I'll see if I can spot the problem. > According to the source there is a FIXME with a comment about powering > down the NIC. Does this mean that support for wol is incomplete for now? > Mind you, I am just curious, this is in no way meant as criticism. That would only be for when WOL is NOT used; I think it has to leave the NIC powered up for WOL to work... and as you say it ain't implemented yet. > On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be > removed from future releases. Is this still the case? Feedback would be > much appreciated, so I can keep my humble audience up to date on what's > going on at the wol front. > > Thank you guys for your excellent work, > > Arjen > http://atlas.et.tudelft.nl/verwei90/nforce2/index.html From hadi@cyberus.ca Mon Apr 19 19:16:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 19:16:34 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K2GSKO010851 for ; Mon, 19 Apr 2004 19:16:29 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BFkob-0005xx-9B for netdev@oss.sgi.com; Mon, 19 Apr 2004 22:16:49 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BFko9-0001K3-V4; Mon, 19 Apr 2004 22:16:22 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: syrius.ml@no-log.org Cc: netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1082427350.1034.70.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Apr 2004 22:15:50 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4778 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1480 Lines: 42 On Mon, 2004-04-19 at 10:22, syrius.ml@no-log.org wrote: [..] If you already marked the packets before they hit egress then you dont need use the ipt mark action. So what you are doing is correct > $TC qdisc add dev ppp0 root handle 1: prio > $TC filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 Note: this will do for ipv4; if you want ipv6 add a new rule, in addition to above if you want ipv4, with "protocol ip" replaced by "protocol ipv6" > $TC qdisc add dev tun0 root handle 1: prio > $TC filter add dev tun0 parent 1:0 protocol ip prio 10 u32 \ > match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 > > $TC qdisc add dev sit1 root handle 1: prio > $TC filter add dev sit1 parent 1:0 protocol ipv6 prio 10 u32 \ > match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 not sure if you need the above but i dont know your setup sufficiently to be 100% > but it doesn't work with ipv6 traffic. > If I try to ping6 somehost, i sometimes get "ping: sendmsg: No buffer > space available" messages > anyway, there's nothing going out on sit1. > > Is it the correct way to do it ? Seems right. Try adding the new ipv6 rule on ppp0 and if you are still having problems try dumping some stats for the filters and see if they are incrementing. eg tc -s filter show parent 1:0 dev ppp0 also a ifconfig on the dummy0 should show starts going up cheers, jamal From davem@redhat.com Mon Apr 19 22:19:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 19 Apr 2004 22:19:47 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K5JaKO019166 for ; Mon, 19 Apr 2004 22:19:36 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3K5JSJW008687; Tue, 20 Apr 2004 01:19:28 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3K5JSj29367; Tue, 20 Apr 2004 01:19:28 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3K5J21n016548; Tue, 20 Apr 2004 01:19:03 -0400 Date: Mon, 19 Apr 2004 22:19:27 -0700 From: "David S. Miller" To: Sridhar Samudrala Cc: netdev@oss.sgi.com, lksctp-developers@lists.sourceforge.net Subject: Re: [BK PATCH] PR-SCTP support, misc SCTP cleanups Message-Id: <20040419221927.2acd8106.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4779 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 293 Lines: 9 On Mon, 19 Apr 2004 15:11:26 -0700 (PDT) Sridhar Samudrala wrote: > Please do a > bk pull http://linux-lksctp.bkbits.net/lksctp-2.5.work & > bk pull http://linux-lksctp.bkbits.net/lksctp-2.4.work > to get the following updates to 2.6 and 2.4 SCTP. Pulled, thanks Sridhar. From A.Verweij2@ewi.tudelft.nl Tue Apr 20 04:13:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 04:13:22 -0700 (PDT) Received: from mailhst2.its.tudelft.nl (mailhst2.its.tudelft.nl [130.161.34.250]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KBDEKO004507 for ; Tue, 20 Apr 2004 04:13:14 -0700 Received: from elektron.its.tudelft.nl (elektron.its.tudelft.nl [130.161.33.15]) by mailhst2.its.tudelft.nl (8.11.6p2/8.11.6) with ESMTP id i3KBDA126518; Tue, 20 Apr 2004 13:13:11 +0200 (METDST) Received: from localhost (verwei90@localhost) by elektron.its.tudelft.nl (8.9.3 (PHNE_26305)/8.9.3) with ESMTP id NAA26576; Tue, 20 Apr 2004 13:13:09 +0200 (METDST) Date: Tue, 20 Apr 2004 13:13:09 +0200 (METDST) From: Arjen Verweij Reply-To: a.verweij@student.tudelft.nl To: Andrew de Quincey cc: netdev@oss.sgi.com Subject: Re: wol support in forcedeth v25 In-Reply-To: <200404200007.59345.adq@lidskialf.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4781 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: A.Verweij2@ewi.tudelft.nl Precedence: bulk X-list: netdev Content-Length: 1347 Lines: 39 OK, let me know if you need a guinea pig to test any patches you might have. Regards, Arjen On Tue, 20 Apr 2004, Andrew de Quincey wrote: > On Monday 19 April 2004 21:11, Arjen Verweij wrote: > > Hi, > > > > Is the wol support in forcedeth v25 complete yet? I was trying it with the > > 2.6.5 kernel it came with, tried the new forcedeth driver with a 2.6.3 > > kernel (because firewire seems broken in 2.6.5) however, my box will not > > wake up as of yet. > > You're right! It _was_ working with patch-forced-0.25, but it ain't in 2.6.5. > I'll see if I can spot the problem. > > > According to the source there is a FIXME with a comment about powering > > down the NIC. Does this mean that support for wol is incomplete for now? > > Mind you, I am just curious, this is in no way meant as criticism. > > That would only be for when WOL is NOT used; I think it has to leave the NIC > powered up for WOL to work... and as you say it ain't implemented yet. > > > On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be > > removed from future releases. Is this still the case? Feedback would be > > much appreciated, so I can keep my humble audience up to date on what's > > going on at the wol front. > > > > Thank you guys for your excellent work, > > > > Arjen > > http://atlas.et.tudelft.nl/verwei90/nforce2/index.html > > From adq@lidskialf.net Tue Apr 20 04:35:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 04:35:59 -0700 (PDT) Received: from beyond.lidskialf.net (lidskialf.net [62.3.233.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KBZkKO008178 for ; Tue, 20 Apr 2004 04:35:46 -0700 Received: from monstrousfish (monstrousfish [172.16.1.2]) by beyond.lidskialf.net (Postfix) with ESMTP id 8E2269395; Tue, 20 Apr 2004 12:39:26 +0100 (BST) From: Andrew de Quincey To: a.verweij@student.tudelft.nl Subject: Re: wol support in forcedeth v25 Date: Tue, 20 Apr 2004 12:36:41 +0100 User-Agent: KMail/1.6.2 Cc: netdev@oss.sgi.com References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404201236.41188.adq@lidskialf.net> X-archive-position: 4782 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: adq@lidskialf.net Precedence: bulk X-list: netdev Content-Length: 1989 Lines: 48 On Tuesday 20 April 2004 12:13, Arjen Verweij wrote: I found how I could get it going again, but its not the right way of doing it.. In nv_close(), if you comment out the lines "nv_stop_rx(dev);" and "if (np->wolenabled) nv_start_rx(dev);", WOL works. However this isn't the right way to do it, which is why I haven't supplied a patch. What its supposed to do it stop receiving, clear any buffers, then restart receiving again. But this seems to break WOL for some reason. There must be some extra operation required for it all to work properly... I'll keep looking. > OK, let me know if you need a guinea pig to test any patches you might > have. > > Regards, > > Arjen > > On Tue, 20 Apr 2004, Andrew de Quincey wrote: > > On Monday 19 April 2004 21:11, Arjen Verweij wrote: > > > Hi, > > > > > > Is the wol support in forcedeth v25 complete yet? I was trying it with > > > the 2.6.5 kernel it came with, tried the new forcedeth driver with a > > > 2.6.3 kernel (because firewire seems broken in 2.6.5) however, my box > > > will not wake up as of yet. > > > > You're right! It _was_ working with patch-forced-0.25, but it ain't in > > 2.6.5. I'll see if I can spot the problem. > > > > > According to the source there is a FIXME with a comment about powering > > > down the NIC. Does this mean that support for wol is incomplete for > > > now? Mind you, I am just curious, this is in no way meant as criticism. > > > > That would only be for when WOL is NOT used; I think it has to leave the > > NIC powered up for WOL to work... and as you say it ain't implemented > > yet. > > > > > On another note, Carl-Daniel mentioned that DEV_NEED_TIMERIRQ might be > > > removed from future releases. Is this still the case? Feedback would be > > > much appreciated, so I can keep my humble audience up to date on what's > > > going on at the wol front. > > > > > > Thank you guys for your excellent work, > > > > > > Arjen > > > http://atlas.et.tudelft.nl/verwei90/nforce2/index.html From jonmason@us.ibm.com Tue Apr 20 08:45:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 08:45:42 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KFjLKQ016617 for ; Tue, 20 Apr 2004 08:45:37 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KFjFkV331452; Tue, 20 Apr 2004 11:45:15 -0400 Received: from d03nm130.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KFj9VR372194; Tue, 20 Apr 2004 09:45:10 -0600 In-Reply-To: <20040419224911.A17362@electric-eye.fr.zoreil.com> To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Tue, 20 Apr 2004 09:45:07 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/20/2004 09:45:13 Content-Type: multipart/mixed; boundary="=_mixed 0056289386256E7C_=" X-archive-position: 4783 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10392 Lines: 188 --=_mixed 0056289386256E7C_= Content-Type: text/plain; charset="US-ASCII" >[...] >> Unsigned variables are a little bit faster on ppc hardware. I figgured >> that it doesn't matter on x86/x86_64, but would help other architectures. > >Ok. No objection against an unsigned int or an u32 instead ? I made them u32's, but in retrospect I should make them "unsigned int" for code uniformity (i.e., the heavy usage of "unsigned long"). Actually, all the driver u32's should be replaced with "unsigned int", and most of the int's should probably be changed as well. I can make those changes if you like, but that is outside the scope of this patch. :-) [...] >> I can try and hide as many #ifdefs as possible if you like, just didn't >> know your preference. Will do. > >(sometimes hch is bored and dissects network patches too :o) ) > >I have no suggestion for the others #ifdef but at least this one can be >isolated. I made this change. I will attempt to clean-up the #ifdefs more when I have some free time. [...] >Anything as long as it avoids the indentation of a line in the declaration >block. Removed the indentation. [...] >I fail to see where the Tx interrupts are disabled. The code will now check for interrupts before it resets the interrupt mask (and not reset it if an interrupt comes in). However, this won't really be a problem if/when I add Tx to NAPI (which is why the error was there in the first place). [...] >The locking scheme which will be used between ->poll() and ->interrupt() >should guarantee some ordering of the registers operations (provided they >appear in the locked section). However, if no read is issued, no one knows >when the write will actually hit the chipset. I assume you are referring to the driver being used in weakly ordered memory model machines. To address this I added a rmb() after the update to the interrupt mask. >> It might be better to be a user tunable parameter, but I can increase the >> size for NAPI usage. Any preference as to the ring size? > >256 Done. >> Actually, I have a copy of the driver that does Tx. After reading the >> NAPI howto, which states that there is a slight performance degradation >> if Tx is NAPI too, I figgured that you would want only Rx. I can add Tx >> if you like. > >Separate patches are usually easier to review, yes. I will add the Tx NAPI to the next version I send you. --=_mixed 0056289386256E7C_= Content-Type: application/octet-stream; name="Kconfig.diff" Content-Disposition: attachment; filename="Kconfig.diff" Content-Transfer-Encoding: base64 LS0tIEtjb25maWcub3JpZwkyMDA0LTA0LTIwIDEwOjMxOjE4LjY1MzQzMTkyMCAtMDUwMAorKysg S2NvbmZpZwkyMDA0LTA0LTIwIDEwOjMwOjA0Ljg4MTY0NjkzNiAtMDUwMApAQCAtMTk2Miw2ICsx OTYyLDEwIEBAIGNvbmZpZyBSODE2OQogCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1v ZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlIG1vZHVsZQogCSAgd2lsbCBiZSBjYWxsZWQgcjgxNjku ICBUaGlzIGlzIHJlY29tbWVuZGVkLgogCitjb25maWcgUjgxNjlfTkFQSQorCWJvb2wgIlVzZSBS eCBQb2xsaW5nIChOQVBJKSAoRVhQRVJJTUVOVEFMKSIKKwlkZXBlbmRzIG9uIFI4MTY5ICYmIEVY UEVSSU1FTlRBTCAKKwkKIGNvbmZpZyBTSzk4TElOCiAJdHJpc3RhdGUgIk1hcnZlbGwgWXVrb24g Q2hpcHNldCAvIFN5c0tvbm5lY3QgU0stOTh4eCBTdXBwb3J0IgogCWRlcGVuZHMgb24gUENJCg== --=_mixed 0056289386256E7C_= Content-Type: application/octet-stream; name="r8169.diff" Content-Disposition: attachment; filename="r8169.diff" Content-Transfer-Encoding: base64 LS0tIHI4MTY5LmMub3JpZwkyMDA0LTA0LTE4IDIyOjUxOjMzLjAwMDAwMDAwMCAtMDUwMAorKysg cjgxNjkuYwkyMDA0LTA0LTIwIDEwOjQxOjQzLjA1NDY0NDgyNCAtMDUwMApAQCAtOTMsOCArOTMs MTUgQEAgc3RhdGljIGludCBtdWx0aWNhc3RfZmlsdGVyX2xpbWl0ID0gMzI7CiAjZGVmaW5lIFJ4 UGFja2V0TWF4U2l6ZQkweDA4MDAJLyogTWF4aW11bSBzaXplIHN1cHBvcnRlZCBpcyAxNkstMSAq LwogI2RlZmluZSBJbnRlckZyYW1lR2FwCTB4MDMJLyogMyBtZWFucyBJbnRlckZyYW1lR2FwID0g dGhlIHNob3J0ZXN0IG9uZSAqLwogCi0jZGVmaW5lIE5VTV9UWF9ERVNDCTY0CS8qIE51bWJlciBv ZiBUeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisv KiBUaGUgbnVtYmVyIG9mIFJ4IGl0ZXJhdGlvbnMgcHJvY2Vzc2VkIChpZiBOQVBJIGVuYWJsZWQp ICovCisjZGVmaW5lIFI4MTY5X05BUElfV0VJR0hUCTY0CisKKyNkZWZpbmUgTlVNX1JYX0RFU0MJ MjU2CS8qIE51bWJlciBvZiBSeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2Vsc2UKICNkZWZp bmUgTlVNX1JYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFJ4IGRlc2NyaXB0b3IgcmVnaXN0ZXJzICov CisjZW5kaWYKKyNkZWZpbmUgTlVNX1RYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFR4IGRlc2NyaXB0 b3IgcmVnaXN0ZXJzICovCiAjZGVmaW5lIFJYX0JVRl9TSVpFCTE1MzYJLyogUnggQnVmZmVyIHNp emUgKi8KICNkZWZpbmUgUjgxNjlfVFhfUklOR19CWVRFUwkoTlVNX1RYX0RFU0MgKiBzaXplb2Yo c3RydWN0IFR4RGVzYykpCiAjZGVmaW5lIFI4MTY5X1JYX1JJTkdfQllURVMJKE5VTV9SWF9ERVND ICogc2l6ZW9mKHN0cnVjdCBSeERlc2MpKQpAQCAtMzQ3LDYgKzM1NCw5IEBAIHN0YXRpYyBpbnQg cnRsODE2OV9jbG9zZShzdHJ1Y3QgbmV0X2RldmkKIHN0YXRpYyB2b2lkIHJ0bDgxNjlfc2V0X3J4 X21vZGUoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CiBzdGF0aWMgdm9pZCBydGw4MTY5X3R4X3Rp bWVvdXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vf c3RhdHMgKnJ0bDgxNjlfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYpOworI2lm ZGVmIENPTkZJR19SODE2OV9OQVBJCitzdGF0aWMgaW50IHJ0bDgxNjlfcG9sbChzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBpbnQgKmJ1ZGdldCk7CisjZW5kaWYKIAogc3RhdGljIGNvbnN0IHUxNiBy dGw4MTY5X2ludHJfbWFzayA9CiAgICAgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBSeEZJRk9P dmVyIHwgVHhFcnIgfCBUeE9LIHwgUnhFcnIgfCBSeE9LOwpAQCAtODQwLDYgKzg1MCwxMSBAQCBy dGw4MTY5X2luaXRfb25lKHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBjCiAJZGV2LT5pcnEgPSBwZGV2 LT5pcnE7CiAJZGV2LT5iYXNlX2FkZHIgPSAodW5zaWduZWQgbG9uZykgaW9hZGRyOwogLy8gICAg ICBkZXYtPmRvX2lvY3RsICAgICAgICAgICA9IG1paV9pb2N0bDsKKyNpZmRlZiBDT05GSUdfUjgx NjlfTkFQSQorCWRldi0+cG9sbCA9IHJ0bDgxNjlfcG9sbDsKKwlkZXYtPndlaWdodCA9IFI4MTY5 X05BUElfV0VJR0hUOworCXByaW50ayhLRVJOX0lORk8gInI4MTY5IE5BUEkgZW5hYmxlZFxuIik7 CisjZW5kaWYKIAogCXRwID0gZGV2LT5wcml2OwkJLy8gcHJpdmF0ZSBkYXRhIC8vCiAJdHAtPnBj aV9kZXYgPSBwZGV2OwpAQCAtMTMwOSw2ICsxMzI0LDcgQEAgcnRsODE2OV90eF90aW1lb3V0KHN0 cnVjdCBuZXRfZGV2aWNlICpkZQogCXZvaWQgKmlvYWRkciA9IHRwLT5tbWlvX2FkZHI7CiAJdTgg dG1wODsKIAorCXByaW50ayhLRVJOX0lORk8gIiVzOiBUWCBUaW1lb3V0XG4iLCBkZXYtPm5hbWUp OwogCS8qIGRpc2FibGUgVHgsIGlmIG5vdCBhbHJlYWR5ICovCiAJdG1wOCA9IFJUTF9SOChDaGlw Q21kKTsKIAlpZiAodG1wOCAmIENtZFR4RW5iKQpAQCAtMTQ0NSwxMiArMTQ2MSwyMiBAQCBzdGF0 aWMgaW5saW5lIGludCBydGw4MTY5X3RyeV9yeF9jb3B5KHN0CiAJcmV0dXJuIHJldDsKIH0KIAot c3RhdGljIHZvaWQKK3N0YXRpYyBpbmxpbmUgdm9pZCBydGw4MTY5X3J4X3NrYihzdHJ1Y3Qgc2tf YnVmZiAqc2tiKQoreworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisJbmV0aWZfcmVjZWl2ZV9z a2Ioc2tiKTsJCQkKKyNlbHNlCisJbmV0aWZfcngoc2tiKTsKKyNlbmRpZgorfQorCitzdGF0aWMg aW50IAogcnRsODE2OV9yeF9pbnRlcnJ1cHQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0 IHJ0bDgxNjlfcHJpdmF0ZSAqdHAsCiAJCSAgICAgdm9pZCAqaW9hZGRyKQogewogCXVuc2lnbmVk IGxvbmcgY3VyX3J4LCByeF9sZWZ0OwogCWludCBkZWx0YTsKKwl1MzIgY291bnQgPSAwOwogCiAJ YXNzZXJ0KGRldiAhPSBOVUxMKTsKIAlhc3NlcnQodHAgIT0gTlVMTCk7CkBAIC0xNDU4LDYgKzE0 ODQsOSBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqCiAKIAljdXJf cnggPSB0cC0+Y3VyX3J4OwogCXJ4X2xlZnQgPSBOVU1fUlhfREVTQyArIHRwLT5kaXJ0eV9yeCAt IGN1cl9yeDsKKyNpZmRlZiBDT05GSUdfUjgxNjlfTkFQSQorCXJ4X2xlZnQgPSBtaW4ocnhfbGVm dCwgKHVuc2lnbmVkIGxvbmcpIGRldi0+cXVvdGEpOworI2VuZGlmCiAKIAl3aGlsZSAocnhfbGVm dCA+IDApIHsKIAkJaW50IGVudHJ5ID0gY3VyX3J4ICUgTlVNX1JYX0RFU0M7CkBAIC0xNDk3LDcg KzE1MjYsNyBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqCiAKIAkJ CXNrYl9wdXQoc2tiLCBwa3Rfc2l6ZSk7CiAJCQlza2ItPnByb3RvY29sID0gZXRoX3R5cGVfdHJh bnMoc2tiLCBkZXYpOwotCQkJbmV0aWZfcngoc2tiKTsKKwkJCXJ0bDgxNjlfcnhfc2tiKHNrYik7 CiAKIAkJCWRldi0+bGFzdF9yeCA9IGppZmZpZXM7CiAJCQl0cC0+c3RhdHMucnhfYnl0ZXMgKz0g cGt0X3NpemU7CkBAIC0xNTA2LDE1ICsxNTM1LDE3IEBAIHJ0bDgxNjlfcnhfaW50ZXJydXB0KHN0 cnVjdCBuZXRfZGV2aWNlICoKIAkJCiAJCWN1cl9yeCsrOyAKIAkJcnhfbGVmdC0tOworCQljb3Vu dCsrOwogCX0KIAogCXRwLT5jdXJfcnggPSBjdXJfcng7CiAKIAlkZWx0YSA9IHJ0bDgxNjlfcnhf ZmlsbCh0cCwgZGV2LCB0cC0+ZGlydHlfcngsIHRwLT5jdXJfcngpOwotCWlmIChkZWx0YSA+IDAp Ci0JCXRwLT5kaXJ0eV9yeCArPSBkZWx0YTsKLQllbHNlIGlmIChkZWx0YSA8IDApCisJaWYgKGRl bHRhIDwgMCkgewogCQlwcmludGsoS0VSTl9JTkZPICIlczogbm8gUnggYnVmZmVyIGFsbG9jYXRl ZFxuIiwgZGV2LT5uYW1lKTsKKwkJZGVsdGEgPSAwOworCX0KKwl0cC0+ZGlydHlfcnggKz0gZGVs dGE7CiAKIAkvKgogCSAqIEZJWE1FOiB1bnRpbCB0aGVyZSBpcyBwZXJpb2RpYyB0aW1lciB0byB0 cnkgYW5kIHJlZmlsbCB0aGUgcmluZywKQEAgLTE1MjUsNiArMTU1Niw4IEBAIHJ0bDgxNjlfcnhf aW50ZXJydXB0KHN0cnVjdCBuZXRfZGV2aWNlICoKIAkgKi8KIAlpZiAodHAtPmRpcnR5X3J4ICsg TlVNX1JYX0RFU0MgPT0gdHAtPmN1cl9yeCkKIAkJcHJpbnRrKEtFUk5fRU1FUkcgIiVzOiBSeCBi dWZmZXJzIGV4aGF1c3RlZFxuIiwgZGV2LT5uYW1lKTsKKworCXJldHVybiBjb3VudDsKIH0KIAog LyogVGhlIGludGVycnVwdCBoYW5kbGVyIGRvZXMgYWxsIG9mIHRoZSBSeCB0aHJlYWQgd29yayBh bmQgY2xlYW5zIHVwIGFmdGVyIHRoZSBUeCB0aHJlYWQuICovCkBAIC0xNTU4LDcgKzE1OTEsMTkg QEAgcnRsODE2OV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lucwogCiAJCS8vIFJ4IGlu dGVycnVwdCAKIAkJaWYgKHN0YXR1cyAmIChSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cg fCBSeEZJRk9PdmVyKSkgeworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisJCQlpZiAobmV0aWZf cnhfc2NoZWR1bGVfcHJlcChkZXYpKSB7CisJCQkJUlRMX1cxNihJbnRyTWFzaywgcnRsODE2OV9p bnRyX21hc2sgfCAKKwkJCQkJfihSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBSeEZJ Rk9PdmVyKSk7CisJCQkJX19uZXRpZl9yeF9zY2hlZHVsZShkZXYpOworCQkJfSBlbHNlIHsKKwkJ CQlwcmludGsoS0VSTl9JTkZPICJkcml2ZXIgYnVnISBpbnRlcnJ1cHQgd2hpbGUgaW4gcG9sbFxu Iik7CQorCQkJCVJUTF9XMTYoSW50ck1hc2ssIHJ0bDgxNjlfaW50cl9tYXNrIHwgCisJCQkJCX4o UnhPSyB8IFJ4VW5kZXJydW4gfCBSeE92ZXJmbG93IHwgUnhGSUZPT3ZlcikpOworCQkJfQorI2Vs c2UKIAkJCXJ0bDgxNjlfcnhfaW50ZXJydXB0KGRldiwgdHAsIGlvYWRkcik7CisjZW5kaWYKIAkJ fQogCQkvLyBUeCBpbnRlcnJ1cHQKIAkJaWYgKHN0YXR1cyAmIChUeE9LIHwgVHhFcnIpKSB7CkBA IC0xNjkyLDYgKzE3MzcsMzEgQEAgc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpydGw4 MTY5XwogCXJldHVybiAmdHAtPnN0YXRzOwogfQogCisjaWZkZWYgQ09ORklHX1I4MTY5X05BUEkK K3N0YXRpYyBpbnQgcnRsODE2OV9wb2xsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCAqYnVk Z2V0KQoreworCXUzMiBzdGF0dXMsIHdvcmtfZG9uZSA9IDAsIHdvcmtfdG9fZG8gPSBtaW4oKmJ1 ZGdldCwgZGV2LT5xdW90YSk7CisJc3RydWN0IHJ0bDgxNjlfcHJpdmF0ZSAqdHAgPSBkZXYtPnBy aXY7CisJdm9pZCAqaW9hZGRyID0gdHAtPm1taW9fYWRkcjsKKwkKKwl3b3JrX2RvbmUgPSBydGw4 MTY5X3J4X2ludGVycnVwdChkZXYsIHRwLCBpb2FkZHIpOworCQorCSpidWRnZXQgLT0gd29ya19k b25lOworCWRldi0+cXVvdGEgLT0gd29ya19kb25lOworCQorCWlmICghd29ya19kb25lIHx8ICFu ZXRpZl9ydW5uaW5nKGRldikpIHsKKwkJbmV0aWZfcnhfY29tcGxldGUoZGV2KTsKKwkJc3RhdHVz ID0gUlRMX1IxNihJbnRyU3RhdHVzKTsKKwkJaWYgKCFzdGF0dXMpIHsKKwkJCVJUTF9XMTYoSW50 ck1hc2ssIHJ0bDgxNjlfaW50cl9tYXNrKTsKKwkJCXJtYigpOworCQl9CQorCX0KKworCXJldHVy biAod29ya19kb25lID49IHdvcmtfdG9fZG8pOworfQorI2VuZGlmCisKIHN0YXRpYyBzdHJ1Y3Qg cGNpX2RyaXZlciBydGw4MTY5X3BjaV9kcml2ZXIgPSB7CiAJLm5hbWUJCT0gTU9EVUxFTkFNRSwK IAkuaWRfdGFibGUJPSBydGw4MTY5X3BjaV90YmwsCg== --=_mixed 0056289386256E7C_=-- From mike_keehan@yahoo.com Tue Apr 20 09:08:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 09:08:13 -0700 (PDT) Received: from web12305.mail.yahoo.com (web12305.mail.yahoo.com [216.136.173.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KG87KO017311 for ; Tue, 20 Apr 2004 09:08:07 -0700 Message-ID: <20040420160806.33161.qmail@web12305.mail.yahoo.com> Received: from [82.44.103.172] by web12305.mail.yahoo.com via HTTP; Tue, 20 Apr 2004 09:08:06 PDT Date: Tue, 20 Apr 2004 09:08:06 -0700 (PDT) From: Mike Keehan Subject: Re: e100 NETDEV WATCHDOG transmit timeout since 2.6.4 To: linux-kernel@vger.kernel.org Cc: netdev@oss.sgi.com In-Reply-To: <20040420155903.GA16152@zarquon.at.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4784 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mike_keehan@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1473 Lines: 53 I am getting these too in recent kernels, but only on a 10Mhz half-duplex network. I have to manually down and up the interface to recover. On a 100Mhz switched network, the e100 is OK (at least 12hours+). Mike. NETDEV WATCHDOG: eth0: transmit timed out --- Mike@Keehan.net wrote: > ----- Forwarded message from Eamonn Hamilton > ----- > > Subject: e100 NETDEV WATCHDOG transmit timeout since 2.6.4 > From: Eamonn Hamilton > To: linux-kernel@vger.kernel.org > Date: Tue, 20 Apr 2004 10:13:33 +0100 > > Hi, > > Since 2.6.4 my ethernet interface is timing out after successfully > operating for 30 minutes or so, and is reset by the watchdog and runs > for another 30 minutes or so. This behaviour is only since 2.6.4 when > I > believe a rewrite of the code was done. I've tried it with acpi > disabled, and got the same results if this helps. > > Anybody got any ideas? > > Cheers, > Eamonn > -- > Eamonn Hamilton > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > > > ----- End forwarded message ----- __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From brazilnut@us.ibm.com Tue Apr 20 09:19:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 09:19:49 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KGJbKO018850 for ; Tue, 20 Apr 2004 09:19:44 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KGJOUk015984; Tue, 20 Apr 2004 12:19:25 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KGJNVR370322; Tue, 20 Apr 2004 10:19:23 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KGHcB13213; Tue, 20 Apr 2004 09:17:38 -0700 From: Don Fry Message-Id: <200404201617.i3KGHcB13213@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2.6.6-rc1-bk5] remove duplicate pcnet32 patch To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 09:17:38 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4785 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 611 Lines: 20 Please apply this patch to 2.6.6-rc1-bk5 to remove a duplicate patch that added 79C976 support (twice). As is, it will not compile. --- linux-2.6.6-rc1-bk5/drivers/net/bad.pcnet32.c Tue Apr 20 09:11:01 2004 +++ linux-2.6.6-rc1-bk5/drivers/net/pcnet32.c Tue Apr 20 09:11:06 2004 @@ -1010,10 +1010,6 @@ chipname = "PCnet/FAST III 79C976"; fdx = 1; mii = 1; break; - case 0x2628: - chipname = "PCnet/FAST III 79C976"; - fdx = 1; mii = 1; - break; default: if (pcnet32_debug & NETIF_MSG_PROBE) printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", -- Don Fry brazilnut@us.ibm.com From romieu@fr.zoreil.com Tue Apr 20 10:28:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 10:28:45 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KHSYKO020690 for ; Tue, 20 Apr 2004 10:28:35 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3KGP3uX032007; Tue, 20 Apr 2004 18:25:03 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3KGP1IO032006; Tue, 20 Apr 2004 18:25:01 +0200 Date: Tue, 20 Apr 2004 18:25:01 +0200 From: Francois Romieu To: Jon D Mason Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] r8169 NAPI addition Message-ID: <20040420182501.A31888@electric-eye.fr.zoreil.com> References: <20040419224911.A17362@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jonmason@us.ibm.com on Tue, Apr 20, 2004 at 09:45:07AM -0600 X-Organisation: Land of Sunshine Inc. X-archive-position: 4786 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 446 Lines: 12 Jon D Mason : [...] > I assume you are referring to the driver being used in weakly ordered > memory model machines. To address this I added a rmb() after the update > to the interrupt mask. Nonono, it is a PCI thing. Writes to (pci-)MMIO registers are posted and typically require a read in the MMIO range (or "some" time) to be committed to the final device. (pci-)IO accesses do not exhibit this property. -- Ueimor From daniel.ritz@gmx.ch Tue Apr 20 11:50:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 11:50:42 -0700 (PDT) Received: from ritz.dnsalias.org (80-218-57-148.dclient.hispeed.ch [80.218.57.148]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KIoaKO022504 for ; Tue, 20 Apr 2004 11:50:37 -0700 Received: from toshba.local (toshba.local [192.168.100.12]) by ritz.dnsalias.org (Postfix) with ESMTP id 6709C4FBB4; Tue, 20 Apr 2004 20:50:34 +0200 (CEST) From: Daniel Ritz Reply-To: daniel.ritz@gmx.ch To: Jeff Garzik , Russell King Subject: [PATCH] fix arm/etherh.c allocation Date: Tue, 20 Apr 2004 20:49:08 +0200 User-Agent: KMail/1.5.2 Cc: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404202049.09130.daniel.ritz@gmx.ch> X-archive-position: 4787 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: daniel.ritz@gmx.ch Precedence: bulk X-list: netdev Content-Length: 428 Lines: 21 russell, there's a part of my original patch you missed: allocation of the netdevice. doesn't need a comment. against 2.6-bknow rgds -daniel --- 1.23/drivers/net/arm/etherh.c Wed Apr 14 12:23:55 2004 +++ edited/etherh.c Tue Apr 20 20:39:04 2004 @@ -574,7 +574,7 @@ if (ret) goto out; - dev = alloc_ei_netdev(); + dev = __alloc_ei_netdev(sizeof(struct etherh_priv)); if (!dev) { ret = -ENOMEM; goto release; From brazilnut@us.ibm.com Tue Apr 20 13:18:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:18:58 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKIYKO030613 for ; Tue, 20 Apr 2004 13:18:40 -0700 Received: from westrelay05.boulder.ibm.com (westrelay05.boulder.ibm.com [9.17.193.33]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKHucC468346; Tue, 20 Apr 2004 16:18:01 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKHi93243308; Tue, 20 Apr 2004 14:17:45 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKDf913589; Tue, 20 Apr 2004 13:13:41 -0700 From: Don Fry Message-Id: <200404202013.i3KKDf913589@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2/8 2.4.26-bk1] pcnet32 add 79C976 support To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:13:41 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4791 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 556 Lines: 20 Please include this patch to add support for the 79C976 device to the pcnet32 driver. Tested ia32. --- linux-2.4.26-bk1/drivers/net/white.pcnet32.c Tue Apr 20 12:39:41 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:39:46 2004 @@ -936,6 +936,10 @@ chipname = "PCnet/FAST III 79C975"; /* PCI */ fdx = 1; mii = 1; break; + case 0x2628: + chipname = "PCnet/FAST III 79C976"; + fdx = 1; mii = 1; + break; default: printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", chip_version); -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:18:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:18:50 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKIdKO030616 for ; Tue, 20 Apr 2004 13:18:40 -0700 Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKIO67709384; Tue, 20 Apr 2004 16:18:25 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by northrelay03.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKIPbX099040; Tue, 20 Apr 2004 16:18:31 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKD7213578; Tue, 20 Apr 2004 13:13:07 -0700 From: Don Fry Message-Id: <200404202013.i3KKD7213578@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 1/8 2.4.26-bk1] pcnet32 whitespace only changes To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:13:02 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4788 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 38227 Lines: 1168 This modifies the whitespace only. consistent indentation, deletes trailing tabs, trailing spaces, etc. --- linux-2.4.26-bk1/drivers/net/new.pcnet32.c Tue Apr 20 12:38:46 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:39:02 2004 @@ -1,12 +1,12 @@ /* pcnet32.c: An AMD PCnet32 ethernet driver for linux. */ /* * Copyright 1996-1999 Thomas Bogendoerfer - * + * * Derived from the lance driver written 1993,1994,1995 by Donald Becker. - * + * * Copyright 1993 United States Government as represented by the * Director, National Security Agency. - * + * * This software may be used and distributed according to the terms * of the GNU General Public License, incorporated herein by reference. * @@ -48,9 +48,10 @@ #include #include -#include #include +#include #include +#include /* * PCI device identifiers for "new style" Linux PCI Device Drivers @@ -71,10 +72,10 @@ static int cards_found __devinitdata; -/* - * VLB I/O addresses +/* + * VLB I/O addresses */ -static unsigned int pcnet32_portlist[] __initdata = +static unsigned int pcnet32_portlist[] __initdata = { 0x300, 0x320, 0x340, 0x360, 0 }; @@ -109,7 +110,7 @@ static unsigned char options_mapping[] = { PCNET32_PORT_ASEL, /* 0 Auto-select */ PCNET32_PORT_AUI, /* 1 BNC/AUI */ - PCNET32_PORT_AUI, /* 2 AUI/BNC */ + PCNET32_PORT_AUI, /* 2 AUI/BNC */ PCNET32_PORT_ASEL, /* 3 not supported */ PCNET32_PORT_10BT | PCNET32_PORT_FD, /* 4 10baseT-FD */ PCNET32_PORT_ASEL, /* 5 not supported */ @@ -136,14 +137,14 @@ /* * Theory of Operation - * + * * This driver uses the same software structure as the normal lance * driver. So look for a verbose description in lance.c. The differences * to the normal lance driver is the use of the 32bit mode of PCnet32 * and PCnetPCI chips. Because these chips are 32bit chips, there is no * 16MB limitation and we don't need bounce buffers. */ - + /* * History: * v0.01: Initial version @@ -197,7 +198,7 @@ * v1.22: changed pci scanning code to make PPC people happy * fixed switching to 32bit mode in pcnet32_open() (thanks * to Michael Richard for noticing this one) - * added sub vendor/device id matching (thanks again to + * added sub vendor/device id matching (thanks again to * Michael Richard ) * added chip id for 79c973/975 (thanks to Zach Brown ) * v1.23 fixed small bug, when manual selecting MII speed/duplex @@ -215,7 +216,7 @@ * v1.26p Fix oops on rmmod+insmod; plug i/o resource leak - Paul Gortmaker * v1.27 improved CSR/PROM address detection, lots of cleanups, * new pcnet32vlb module option, HP-PARISC support, - * added module parameter descriptions, + * added module parameter descriptions, * initial ethtool support - Helge Deller * v1.27a Sun Feb 10 2002 Go Taniguchi * use alloc_etherdev and register_netdev @@ -223,7 +224,7 @@ * FD auto negotiate error workaround for xSeries250 * clean up and using new mii module * v1.27b Sep 30 2002 Kent Yoder - * Added timer for cable connection state changes. + * Added timer for cable connection state changes. * v1.28 20 Feb 2004 Don Fry * Jon Mason , Chinmay Albal * Now uses ethtool_ops, netif_msg_* and generic_mii_ioctl. @@ -271,11 +272,11 @@ struct pcnet32_rx_head { u32 base; s16 buf_length; - s16 status; + s16 status; u32 msg_length; u32 reserved; }; - + struct pcnet32_tx_head { u32 base; s16 length; @@ -291,7 +292,7 @@ u8 phys_addr[6]; u16 reserved; u32 filter[2]; - /* Receive and transmit ring base, along with extra bits. */ + /* Receive and transmit ring base, along with extra bits. */ u32 rx_ring; u32 tx_ring; }; @@ -308,7 +309,7 @@ }; /* - * The first three fields of pcnet32_private are read by the ethernet device + * The first three fields of pcnet32_private are read by the ethernet device * so we allocate the structure should be allocated by pci_alloc_consistent(). */ struct pcnet32_private { @@ -316,16 +317,18 @@ struct pcnet32_rx_head rx_ring[RX_RING_SIZE]; struct pcnet32_tx_head tx_ring[TX_RING_SIZE]; struct pcnet32_init_block init_block; - dma_addr_t dma_addr; /* DMA address of beginning of this object, - returned by pci_alloc_consistent */ - struct pci_dev *pci_dev; /* Pointer to the associated pci device structure */ + dma_addr_t dma_addr; /* DMA address of beginning of this + object, returned by + pci_alloc_consistent */ + struct pci_dev *pci_dev; /* Pointer to the associated pci device + structure */ const char *name; /* The saved address of a sent-in-place packet/buffer, for skfree(). */ struct sk_buff *tx_skbuff[TX_RING_SIZE]; struct sk_buff *rx_skbuff[RX_RING_SIZE]; dma_addr_t tx_dma_addr[TX_RING_SIZE]; dma_addr_t rx_dma_addr[RX_RING_SIZE]; - struct pcnet32_access a; + struct pcnet32_access a; spinlock_t lock; /* Guard lock */ unsigned int cur_rx, cur_tx; /* The next free ring entry */ unsigned int dirty_rx, dirty_tx; /* The ring entries to be free()ed. */ @@ -337,7 +340,7 @@ dxsuflo:1, /* disable transmit stop on uflo */ mii:1; /* mii port available */ struct net_device *next; - struct mii_if_info mii_if; + struct mii_if_info mii_if; struct timer_list watchdog_timer; u32 msg_enable; /* debug message level */ }; @@ -482,11 +485,11 @@ #ifdef CONFIG_NET_POLL_CONTROLLER static void pcnet32_poll_controller(struct net_device *dev) -{ - disable_irq(dev->irq); - pcnet32_interrupt(0, dev, NULL); - enable_irq(dev->irq); -} +{ + disable_irq(dev->irq); + pcnet32_interrupt(0, dev, NULL); + enable_irq(dev->irq); +} #endif @@ -521,14 +524,14 @@ static void pcnet32_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct pcnet32_private *lp = dev->priv; - - strcpy (info->driver, DRV_NAME); - strcpy (info->version, DRV_VERSION); - if (lp->pci_dev) - strcpy (info->bus_info, pci_name(lp->pci_dev)); - else - sprintf(info->bus_info, "VLB 0x%lx", dev->base_addr); + struct pcnet32_private *lp = dev->priv; + + strcpy (info->driver, DRV_NAME); + strcpy (info->version, DRV_VERSION); + if (lp->pci_dev) + strcpy (info->bus_info, pci_name(lp->pci_dev)); + else + sprintf(info->bus_info, "VLB 0x%lx", dev->base_addr); } static u32 pcnet32_get_link(struct net_device *dev) @@ -551,16 +554,16 @@ static u32 pcnet32_get_msglevel(struct net_device *dev) { - struct pcnet32_private *lp = dev->priv; - return lp->msg_enable; + struct pcnet32_private *lp = dev->priv; + return lp->msg_enable; } - + static void pcnet32_set_msglevel(struct net_device *dev, u32 value) { - struct pcnet32_private *lp = dev->priv; - lp->msg_enable = value; + struct pcnet32_private *lp = dev->priv; + lp->msg_enable = value; } - + static int pcnet32_nway_reset(struct net_device *dev) { struct pcnet32_private *lp = dev->priv; @@ -577,12 +580,12 @@ static void pcnet32_get_ringparam(struct net_device *dev, struct ethtool_ringparam *ering) { - struct pcnet32_private *lp = dev->priv; + struct pcnet32_private *lp = dev->priv; - ering->tx_max_pending = TX_RING_SIZE - 1; - ering->tx_pending = lp->cur_tx - lp->dirty_tx; - ering->rx_max_pending = RX_RING_SIZE - 1; - ering->rx_pending = lp->cur_rx & RX_RING_MOD_MASK; + ering->tx_max_pending = TX_RING_SIZE - 1; + ering->tx_pending = lp->cur_tx - lp->dirty_tx; + ering->rx_max_pending = RX_RING_SIZE - 1; + ering->rx_pending = lp->cur_rx & RX_RING_MOD_MASK; } static void pcnet32_get_strings(struct net_device *dev, u32 stringset, u8 *data) @@ -672,7 +675,7 @@ for (i=0; i<6; i++) *packet++ = dev->dev_addr[i]; for (i=0; i<6; i++) - *packet++ = dev->dev_addr[i]; + *packet++ = dev->dev_addr[i]; /* type */ *packet++ = 0x08; *packet++ = 0x06; @@ -787,14 +790,14 @@ .self_test = pcnet32_ethtool_test, }; -/* only probes for non-PCI devices, the rest are handled by +/* only probes for non-PCI devices, the rest are handled by * pci_register_driver via pcnet32_probe_pci */ static void __devinit pcnet32_probe_vlbus(void) { unsigned int *port, ioaddr; - + /* search for PCnet32 VLB cards at known addresses */ for (port = pcnet32_portlist; (ioaddr = *port); port++) { if (request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_vlbus")) { @@ -824,10 +827,10 @@ ioaddr = pci_resource_start (pdev, 0); if (!ioaddr) { - printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); - return -ENODEV; + printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); + return -ENODEV; } - + if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) { printk(KERN_ERR PFX "architecture does not support 32bit PCI busmaster DMA\n"); return -ENODEV; @@ -841,8 +844,8 @@ } -/* pcnet32_probe1 - * Called from both pcnet32_probe_vlbus and pcnet_probe_pci. +/* pcnet32_probe1 + * Called from both pcnet32_probe_vlbus and pcnet_probe_pci. * pdev will be NULL when called from pcnet32_probe_vlbus. */ static int __devinit @@ -881,7 +884,7 @@ printk(KERN_INFO PFX "Unsupported chip version.\n"); goto err_release_region; } - + /* initialize variables */ fdx = mii = fset = dxsuflo = ltint = 0; chip_version = (chip_version >> 12) & 0xffff; @@ -916,7 +919,7 @@ case 0x2626: chipname = "PCnet/Home 79C978"; /* PCI */ fdx = 1; - /* + /* * This is based on specs published at www.amd.com. This section * assumes that a card with a 79C978 wants to go into 1Mb HomePNA * mode. The 79C978 can also go into standard ethernet, and there @@ -925,12 +928,6 @@ */ /* switch to home wiring mode */ media = a->read_bcr(ioaddr, 49); -#if 0 - if (pcnet32_debug > 2) - printk(KERN_DEBUG PFX "media value %#x.\n", media); - media &= ~3; - media |= 1; -#endif if (pcnet32_debug & NETIF_MSG_PROBE) printk(KERN_DEBUG PFX "media reset to %#x.\n", media); a->write_bcr(ioaddr, 49, media); @@ -941,25 +938,24 @@ break; default: printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", - chip_version); + chip_version); goto err_release_region; } /* * On selected chips turn on the BCR18:NOUFLO bit. This stops transmit * starting until the packet is loaded. Strike one for reliability, lose - * one for latency - although on PCI this isnt a big loss. Older chips + * one for latency - although on PCI this isnt a big loss. Older chips * have FIFO's smaller than a packet, so you can't do this. */ - - if(fset) - { + + if (fset) { a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0800)); a->write_csr(ioaddr, 80, (a->read_csr(ioaddr, 80) & 0x0C00) | 0x0c00); dxsuflo = 1; ltint = 1; } - + dev = alloc_etherdev(0); if (!dev) { printk(KERN_ERR PFX "Memory allocation failed.\n"); @@ -988,13 +984,13 @@ /* read PROM address and compare with CSR address */ for (i = 0; i < 6; i++) promaddr[i] = inb(ioaddr + i); - - if( memcmp( promaddr, dev->dev_addr, 6) - || !is_valid_ether_addr(dev->dev_addr) ) { + + if (memcmp(promaddr, dev->dev_addr, 6) + || !is_valid_ether_addr(dev->dev_addr)) { #ifndef __powerpc__ - if( is_valid_ether_addr(promaddr) ){ + if (is_valid_ether_addr(promaddr)) { #else - if( !is_valid_ether_addr(dev->dev_addr) + if (!is_valid_ether_addr(dev->dev_addr) && is_valid_ether_addr(promaddr)) { #endif printk(" warning: CSR address invalid,\n"); @@ -1004,13 +1000,13 @@ } /* if the ethernet address is not valid, force to 00:00:00:00:00:00 */ - if( !is_valid_ether_addr(dev->dev_addr) ) + if (!is_valid_ether_addr(dev->dev_addr)) memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); for (i = 0; i < 6; i++) printk(" %2.2x", dev->dev_addr[i]); - if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 or 0x2624 */ + if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 - 0x2624 */ i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ printk("\n" KERN_INFO " tx_start_pt(0x%04x):",i); switch(i>>10) { @@ -1034,7 +1030,6 @@ } dev->base_addr = ioaddr; - /* pci_alloc_consistent returns page-aligned memory, so we do not have to check the alignment */ if ((lp = pci_alloc_consistent(pdev, sizeof(*lp), &lp_dma_addr)) == NULL) { printk(KERN_ERR PFX "Consistent memory allocation failed.\n"); @@ -1047,7 +1042,7 @@ lp->pci_dev = pdev; spin_lock_init(&lp->lock); - + SET_MODULE_OWNER(dev); SET_NETDEV_DEV(dev, &pdev->dev); dev->priv = lp; @@ -1067,46 +1062,51 @@ lp->mii_if.dev = dev; lp->mii_if.mdio_read = mdio_read; lp->mii_if.mdio_write = mdio_write; - - if (fdx && !(lp->options & PCNET32_PORT_ASEL) && + + if (fdx && !(lp->options & PCNET32_PORT_ASEL) && ((cards_found>=MAX_UNITS) || full_duplex[cards_found])) lp->options |= PCNET32_PORT_FD; - + if (!a) { printk(KERN_ERR PFX "No access methods\n"); ret = -ENODEV; goto err_free_consistent; } lp->a = *a; - + /* detect special T1/E1 WAN card by checking for MAC address */ - if (dev->dev_addr[0] == 0x00 && dev->dev_addr[1] == 0xe0 && dev->dev_addr[2] == 0x75) + if (dev->dev_addr[0] == 0x00 && dev->dev_addr[1] == 0xe0 + && dev->dev_addr[2] == 0x75) lp->options = PCNET32_PORT_FD | PCNET32_PORT_GPSI; lp->init_block.mode = le16_to_cpu(0x0003); /* Disable Rx and Tx. */ - lp->init_block.tlen_rlen = le16_to_cpu(TX_RING_LEN_BITS | RX_RING_LEN_BITS); + lp->init_block.tlen_rlen = le16_to_cpu(TX_RING_LEN_BITS | RX_RING_LEN_BITS); for (i = 0; i < 6; i++) lp->init_block.phys_addr[i] = dev->dev_addr[i]; lp->init_block.filter[0] = 0x00000000; lp->init_block.filter[1] = 0x00000000; - lp->init_block.rx_ring = (u32)le32_to_cpu(lp->dma_addr + offsetof(struct pcnet32_private, rx_ring)); - lp->init_block.tx_ring = (u32)le32_to_cpu(lp->dma_addr + offsetof(struct pcnet32_private, tx_ring)); - + lp->init_block.rx_ring = (u32)le32_to_cpu(lp->dma_addr + + offsetof(struct pcnet32_private, rx_ring)); + lp->init_block.tx_ring = (u32)le32_to_cpu(lp->dma_addr + + offsetof(struct pcnet32_private, tx_ring)); + /* switch pcnet32 to 32bit mode */ - a->write_bcr (ioaddr, 20, 2); + a->write_bcr(ioaddr, 20, 2); + + a->write_csr(ioaddr, 1, (lp->dma_addr + offsetof(struct pcnet32_private, + init_block)) & 0xffff); + a->write_csr(ioaddr, 2, (lp->dma_addr + offsetof(struct pcnet32_private, + init_block)) >> 16); - a->write_csr (ioaddr, 1, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) & 0xffff); - a->write_csr (ioaddr, 2, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) >> 16); - if (irq_line) { dev->irq = irq_line; } - + if (dev->irq >= 2) printk(" assigned IRQ %d.\n", dev->irq); else { unsigned long irq_mask = probe_irq_on(); - + /* * To auto-IRQ we enable the initialization-done and DMA error * interrupts. For ISA boards we get a DMA error, but VLB and PCI @@ -1115,7 +1115,7 @@ /* Trigger an initialization just for the interrupt. */ a->write_csr (ioaddr, 0, 0x41); mdelay (1); - + dev->irq = probe_irq_off (irq_mask); if (!dev->irq) { printk(", failed to detect IRQ line.\n"); @@ -1128,7 +1128,7 @@ /* Set the mii phy_id so that we can query the link state */ if (lp->mii) lp->mii_if.phy_id = ((lp->a.read_bcr (ioaddr, 33)) >> 5) & 0x1f; - + init_timer (&lp->watchdog_timer); lp->watchdog_timer.data = (unsigned long) dev; lp->watchdog_timer.function = (void *) &pcnet32_watchdog; @@ -1146,7 +1146,7 @@ #ifdef CONFIG_NET_POLL_CONTROLLER dev->poll_controller = pcnet32_poll_controller; -#endif +#endif /* Fill in the generic fields of the device structure. */ if (register_netdev(dev)) @@ -1208,13 +1208,13 @@ (u32) (lp->dma_addr + offsetof(struct pcnet32_private, tx_ring)), (u32) (lp->dma_addr + offsetof(struct pcnet32_private, rx_ring)), (u32) (lp->dma_addr + offsetof(struct pcnet32_private, init_block))); - + /* set/reset autoselect bit */ val = lp->a.read_bcr (ioaddr, 2) & ~2; if (lp->options & PCNET32_PORT_ASEL) val |= 2; lp->a.write_bcr (ioaddr, 2, val); - + /* handle full duplex setting */ if (lp->mii_if.full_duplex) { val = lp->a.read_bcr (ioaddr, 9) & ~3; @@ -1224,34 +1224,38 @@ val |= 2; } else if (lp->options & PCNET32_PORT_ASEL) { /* workaround of xSeries250, turn on for 79C975 only */ - i = ((lp->a.read_csr(ioaddr, 88) | (lp->a.read_csr(ioaddr,89) << 16)) >> 12) & 0xffff; - if (i == 0x2627) val |= 3; + i = ((lp->a.read_csr(ioaddr, 88) | + (lp->a.read_csr(ioaddr,89) << 16)) >> 12) & 0xffff; + if (i == 0x2627) + val |= 3; } lp->a.write_bcr (ioaddr, 9, val); } - + /* set/reset GPSI bit in test register */ val = lp->a.read_csr (ioaddr, 124) & ~0x10; if ((lp->options & PCNET32_PORT_PORTSEL) == PCNET32_PORT_GPSI) val |= 0x10; lp->a.write_csr (ioaddr, 124, val); - + if (lp->mii && !(lp->options & PCNET32_PORT_ASEL)) { - val = lp->a.read_bcr (ioaddr, 32) & ~0x38; /* disable Auto Negotiation, set 10Mpbs, HD */ + /* disable Auto Negotiation, set 10Mpbs, HD */ + val = lp->a.read_bcr (ioaddr, 32) & ~0x38; if (lp->options & PCNET32_PORT_FD) val |= 0x10; if (lp->options & PCNET32_PORT_100) val |= 0x08; lp->a.write_bcr (ioaddr, 32, val); } else { - if (lp->options & PCNET32_PORT_ASEL) { /* enable auto negotiate, setup, disable fd */ - val = lp->a.read_bcr(ioaddr, 32) & ~0x98; - val |= 0x20; - lp->a.write_bcr(ioaddr, 32, val); + if (lp->options & PCNET32_PORT_ASEL) { + /* enable auto negotiate, setup, disable fd */ + val = lp->a.read_bcr(ioaddr, 32) & ~0x98; + val |= 0x20; + lp->a.write_bcr(ioaddr, 32, val); } } -#ifdef DO_DXSUFLO +#ifdef DO_DXSUFLO if (lp->dxsuflo) { /* Disable transmit stop on underflow */ val = lp->a.read_csr (ioaddr, 3); val |= 0x40; @@ -1264,7 +1268,7 @@ val |= (1<<14); lp->a.write_csr (ioaddr, 5, val); } - + lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); pcnet32_load_multicast(dev); @@ -1272,10 +1276,12 @@ rc = -ENOMEM; goto err_free_ring; } - + /* Re-initialize the PCNET32, and start it when done. */ - lp->a.write_csr (ioaddr, 1, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) &0xffff); - lp->a.write_csr (ioaddr, 2, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) >> 16); + lp->a.write_csr (ioaddr, 1, (lp->dma_addr + + offsetof(struct pcnet32_private, init_block)) &0xffff); + lp->a.write_csr (ioaddr, 2, (lp->dma_addr + + offsetof(struct pcnet32_private, init_block)) >> 16); lp->a.write_csr (ioaddr, 4, 0x0915); lp->a.write_csr (ioaddr, 0, 0x0001); @@ -1292,7 +1298,7 @@ while (i++ < 100) if (lp->a.read_csr (ioaddr, 0) & 0x0100) break; - /* + /* * We used to clear the InitDone bit, 0x0100, here but Mark Stockton * reports that doing so triggers a bug in the '974. */ @@ -1300,8 +1306,9 @@ if (netif_msg_ifup(lp)) printk(KERN_DEBUG "%s: pcnet32 open after %d ticks, init block %#x csr0 %4.4x.\n", - dev->name, i, (u32) (lp->dma_addr + offsetof(struct pcnet32_private, init_block)), - lp->a.read_csr(ioaddr, 0)); + dev->name, i, (u32) (lp->dma_addr + + offsetof(struct pcnet32_private, init_block)), + lp->a.read_csr(ioaddr, 0)); spin_unlock_irqrestore(&lp->lock, flags); @@ -1310,17 +1317,17 @@ err_free_ring: /* free any allocated skbuffs */ for (i = 0; i < RX_RING_SIZE; i++) { - lp->rx_ring[i].status = 0; + lp->rx_ring[i].status = 0; if (lp->rx_skbuff[i]) { - pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, + pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); dev_kfree_skb(lp->rx_skbuff[i]); - } + } lp->rx_skbuff[i] = NULL; - lp->rx_dma_addr[i] = 0; + lp->rx_dma_addr[i] = 0; } /* - * Switch back to 16bit mode to avoid problems with dumb + * Switch back to 16bit mode to avoid problems with dumb * DOS packet driver after a warm reboot */ lp->a.write_bcr (ioaddr, 20, 4); @@ -1344,7 +1351,7 @@ * restarting the chip, but I'm too lazy to do so right now. dplatt@3do.com */ -static void +static void pcnet32_purge_tx_ring(struct net_device *dev) { struct pcnet32_private *lp = dev->priv; @@ -1352,10 +1359,11 @@ for (i = 0; i < TX_RING_SIZE; i++) { if (lp->tx_skbuff[i]) { - pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); - dev_kfree_skb_any(lp->tx_skbuff[i]); + pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], + lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); + dev_kfree_skb_any(lp->tx_skbuff[i]); lp->tx_skbuff[i] = NULL; - lp->tx_dma_addr[i] = 0; + lp->tx_dma_addr[i] = 0; } } } @@ -1373,37 +1381,40 @@ lp->dirty_rx = lp->dirty_tx = 0; for (i = 0; i < RX_RING_SIZE; i++) { - struct sk_buff *rx_skbuff = lp->rx_skbuff[i]; + struct sk_buff *rx_skbuff = lp->rx_skbuff[i]; if (rx_skbuff == NULL) { if (!(rx_skbuff = lp->rx_skbuff[i] = dev_alloc_skb (PKT_BUF_SZ))) { /* there is not much, we can do at this point */ - printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n",dev->name); + printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n", + dev->name); return -1; } skb_reserve (rx_skbuff, 2); } - if (lp->rx_dma_addr[i] == 0) - lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, - rx_skbuff->tail, PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); + if (lp->rx_dma_addr[i] == 0) + lp->rx_dma_addr[i] = pci_map_single(lp->pci_dev, rx_skbuff->tail, + PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); lp->rx_ring[i].base = (u32)le32_to_cpu(lp->rx_dma_addr[i]); lp->rx_ring[i].buf_length = le16_to_cpu(2-PKT_BUF_SZ); lp->rx_ring[i].status = le16_to_cpu(0x8000); } /* The Tx buffer address is filled in as needed, but we do need to clear - the upper ownership bit. */ + * the upper ownership bit. */ for (i = 0; i < TX_RING_SIZE; i++) { lp->tx_ring[i].base = 0; lp->tx_ring[i].status = 0; - lp->tx_dma_addr[i] = 0; + lp->tx_dma_addr[i] = 0; } wmb(); /* Make sure all changes are visible */ lp->init_block.tlen_rlen = le16_to_cpu(TX_RING_LEN_BITS | RX_RING_LEN_BITS); for (i = 0; i < 6; i++) lp->init_block.phys_addr[i] = dev->dev_addr[i]; - lp->init_block.rx_ring = (u32)le32_to_cpu(lp->dma_addr + offsetof(struct pcnet32_private, rx_ring)); - lp->init_block.tx_ring = (u32)le32_to_cpu(lp->dma_addr + offsetof(struct pcnet32_private, tx_ring)); + lp->init_block.rx_ring = (u32)le32_to_cpu(lp->dma_addr + + offsetof(struct pcnet32_private, rx_ring)); + lp->init_block.tx_ring = (u32)le32_to_cpu(lp->dma_addr + + offsetof(struct pcnet32_private, tx_ring)); return 0; } @@ -1413,11 +1424,11 @@ struct pcnet32_private *lp = dev->priv; unsigned long ioaddr = dev->base_addr; int i; - + pcnet32_purge_tx_ring(dev); if (pcnet32_init_ring(dev)) return; - + /* ReInit Ring */ lp->a.write_csr (ioaddr, 0, 1); i = 0; @@ -1437,31 +1448,31 @@ spin_lock_irqsave(&lp->lock, flags); /* Transmitter timeout, serious problems. */ - printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", - dev->name, lp->a.read_csr(ioaddr, 0)); - lp->a.write_csr (ioaddr, 0, 0x0004); - lp->stats.tx_errors++; - if (netif_msg_tx_err(lp)) { - int i; - printk(KERN_DEBUG " Ring data dump: dirty_tx %d cur_tx %d%s cur_rx %d.", - lp->dirty_tx, lp->cur_tx, lp->tx_full ? " (full)" : "", - lp->cur_rx); - for (i = 0 ; i < RX_RING_SIZE; i++) - printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ", - lp->rx_ring[i].base, -lp->rx_ring[i].buf_length, - lp->rx_ring[i].msg_length, (unsigned)lp->rx_ring[i].status); - for (i = 0 ; i < TX_RING_SIZE; i++) - printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ", - lp->tx_ring[i].base, -lp->tx_ring[i].length, - lp->tx_ring[i].misc, (unsigned)lp->tx_ring[i].status); - printk("\n"); - } - pcnet32_restart(dev, 0x0042); + printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", + dev->name, lp->a.read_csr(ioaddr, 0)); + lp->a.write_csr (ioaddr, 0, 0x0004); + lp->stats.tx_errors++; + if (netif_msg_tx_err(lp)) { + int i; + printk(KERN_DEBUG " Ring data dump: dirty_tx %d cur_tx %d%s cur_rx %d.", + lp->dirty_tx, lp->cur_tx, lp->tx_full ? " (full)" : "", + lp->cur_rx); + for (i = 0 ; i < RX_RING_SIZE; i++) + printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ", + lp->rx_ring[i].base, -lp->rx_ring[i].buf_length, + lp->rx_ring[i].msg_length, (unsigned)lp->rx_ring[i].status); + for (i = 0 ; i < TX_RING_SIZE; i++) + printk("%s %08x %04x %08x %04x", i & 1 ? "" : "\n ", + lp->tx_ring[i].base, -lp->tx_ring[i].length, + lp->tx_ring[i].misc, (unsigned)lp->tx_ring[i].status); + printk("\n"); + } + pcnet32_restart(dev, 0x0042); - dev->trans_start = jiffies; - netif_wake_queue(dev); + dev->trans_start = jiffies; + netif_wake_queue(dev); - spin_unlock_irqrestore(&lp->lock, flags); + spin_unlock_irqrestore(&lp->lock, flags); } @@ -1498,21 +1509,22 @@ */ status = 0x9300; } - + /* Fill in a Tx ring entry */ - + /* Mask to ring buffer boundary. */ entry = lp->cur_tx & TX_RING_MOD_MASK; - + /* Caution: the write order is important here, set the status - with the "ownership" bits last. */ + * with the "ownership" bits last. */ lp->tx_ring[entry].length = le16_to_cpu(-skb->len); lp->tx_ring[entry].misc = 0x00000000; lp->tx_skbuff[entry] = skb; - lp->tx_dma_addr[entry] = pci_map_single(lp->pci_dev, skb->data, skb->len, PCI_DMA_TODEVICE); + lp->tx_dma_addr[entry] = pci_map_single(lp->pci_dev, skb->data, skb->len, + PCI_DMA_TODEVICE); lp->tx_ring[entry].base = (u32)le32_to_cpu(lp->tx_dma_addr[entry]); wmb(); /* Make sure owner changes after all others are visible */ lp->tx_ring[entry].status = le16_to_cpu(status); @@ -1552,9 +1564,9 @@ ioaddr = dev->base_addr; lp = dev->priv; - + spin_lock(&lp->lock); - + rap = lp->a.read_rap(ioaddr); while ((csr0 = lp->a.read_csr (ioaddr, 0)) & 0x8600 && --boguscnt >= 0) { if (csr0 == 0xffff) { @@ -1579,7 +1591,7 @@ while (dirty_tx != lp->cur_tx) { int entry = dirty_tx & TX_RING_MOD_MASK; int status = (short)le16_to_cpu(lp->tx_ring[entry].status); - + if (status < 0) break; /* It still hasn't been Txed */ @@ -1621,11 +1633,11 @@ /* We must free the original skb */ if (lp->tx_skbuff[entry]) { - pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[entry], + pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[entry], lp->tx_skbuff[entry]->len, PCI_DMA_TODEVICE); dev_kfree_skb_irq(lp->tx_skbuff[entry]); lp->tx_skbuff[entry] = 0; - lp->tx_dma_addr[entry] = 0; + lp->tx_dma_addr[entry] = 0; } dirty_tx++; } @@ -1654,11 +1666,12 @@ /* * this happens when our receive ring is full. This shouldn't * be a problem as we will see normal rx interrupts for the frames - * in the receive ring. But there are some PCI chipsets (I can reproduce - * this on SP3G with Intel saturn chipset) which have sometimes problems - * and will fill up the receive ring with error descriptors. In this - * situation we don't get a rx interrupt, but a missed frame interrupt sooner - * or later. So we try to clean up our receive ring here. + * in the receive ring. But there are some PCI chipsets (I can + * reproduce this on SP3G with Intel saturn chipset) which have + * sometimes problems and will fill up the receive ring with + * error descriptors. In this situation we don't get a rx + * interrupt, but a missed frame interrupt sooner or later. + * So we try to clean up our receive ring here. */ pcnet32_rx(dev); lp->stats.rx_errors++; /* Missed a Rx frame. */ @@ -1679,7 +1692,7 @@ /* Clear any other interrupt, and set interrupt enable. */ lp->a.write_csr (ioaddr, 0, 0x7940); lp->a.write_rap (ioaddr,rap); - + if (netif_msg_intr(lp)) printk(KERN_DEBUG "%s: exiting interrupt, csr0=%#4.4x.\n", dev->name, lp->a.read_csr (ioaddr, 0)); @@ -1698,7 +1711,7 @@ int status = (short)le16_to_cpu(lp->rx_ring[entry].status) >> 8; if (status != 0x03) { /* There was an error. */ - /* + /* * There is a tricky error noted by John Murphy, * to Russ Nelson: Even with full-sized * buffers it's possible for a jabber packet to use two @@ -1715,8 +1728,8 @@ /* Malloc up new buffer, compatible with net-2e. */ short pkt_len = (le32_to_cpu(lp->rx_ring[entry].msg_length) & 0xfff)-4; struct sk_buff *skb; - - if(pkt_len < 60) { + + if (pkt_len < 60) { printk(KERN_ERR "%s: Runt packet!\n",dev->name); lp->stats.rx_errors++; } else { @@ -1724,8 +1737,8 @@ if (pkt_len > rx_copybreak) { struct sk_buff *newskb; - - if ((newskb = dev_alloc_skb (PKT_BUF_SZ))) { + + if ((newskb = dev_alloc_skb(PKT_BUF_SZ))) { skb_reserve (newskb, 2); skb = lp->rx_skbuff[entry]; pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[entry], @@ -1733,22 +1746,24 @@ skb_put (skb, pkt_len); lp->rx_skbuff[entry] = newskb; newskb->dev = dev; - lp->rx_dma_addr[entry] = - pci_map_single(lp->pci_dev, newskb->tail, - PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); + lp->rx_dma_addr[entry] = + pci_map_single(lp->pci_dev, newskb->tail, + PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); lp->rx_ring[entry].base = le32_to_cpu(lp->rx_dma_addr[entry]); rx_in_place = 1; } else skb = NULL; } else { skb = dev_alloc_skb(pkt_len+2); - } - + } + if (skb == NULL) { - int i; - printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", dev->name); + int i; + printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", + dev->name); for (i = 0; i < RX_RING_SIZE; i++) - if ((short)le16_to_cpu(lp->rx_ring[(entry+i) & RX_RING_MOD_MASK].status) < 0) + if ((short)le16_to_cpu(lp->rx_ring[(entry+i) + & RX_RING_MOD_MASK].status) < 0) break; if (i > RX_RING_SIZE -2) { @@ -1767,8 +1782,8 @@ PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); eth_copy_and_sum(skb, - (unsigned char *)(lp->rx_skbuff[entry]->tail), - pkt_len,0); + (unsigned char *)(lp->rx_skbuff[entry]->tail), + pkt_len,0); } lp->stats.rx_bytes += skb->len; skb->protocol=eth_type_trans(skb,dev); @@ -1814,7 +1829,7 @@ lp->a.write_csr (ioaddr, 0, 0x0004); /* - * Switch back to 16bit mode to avoid problems with dumb + * Switch back to 16bit mode to avoid problems with dumb * DOS packet driver after a warm reboot */ lp->a.write_bcr (ioaddr, 20, 4); @@ -1822,28 +1837,29 @@ spin_unlock_irqrestore(&lp->lock, flags); free_irq(dev->irq, dev); - + /* free all allocated skbuffs */ for (i = 0; i < RX_RING_SIZE; i++) { - lp->rx_ring[i].status = 0; + lp->rx_ring[i].status = 0; if (lp->rx_skbuff[i]) { - pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, + pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); dev_kfree_skb(lp->rx_skbuff[i]); } lp->rx_skbuff[i] = NULL; - lp->rx_dma_addr[i] = 0; + lp->rx_dma_addr[i] = 0; } - + for (i = 0; i < TX_RING_SIZE; i++) { if (lp->tx_skbuff[i]) { - pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); + pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], + lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); dev_kfree_skb(lp->tx_skbuff[i]); - } + } lp->tx_skbuff[i] = NULL; - lp->tx_dma_addr[i] = 0; + lp->tx_dma_addr[i] = 0; } - + return 0; } @@ -1874,9 +1890,9 @@ char *addrs; int i; u32 crc; - + /* set all multicast bits */ - if (dev->flags & IFF_ALLMULTI){ + if (dev->flags & IFF_ALLMULTI) { ib->filter[0] = 0xffffffff; ib->filter[1] = 0xffffffff; return; @@ -1886,19 +1902,18 @@ ib->filter[1] = 0; /* Add addresses */ - for (i = 0; i < dev->mc_count; i++){ + for (i = 0; i < dev->mc_count; i++) { addrs = dmi->dmi_addr; dmi = dmi->next; - + /* multicast address? */ if (!(*addrs & 1)) continue; - + crc = ether_crc_le(6, addrs); crc = crc >> 26; mcast_table [crc >> 4] = le16_to_cpu( - le16_to_cpu(mcast_table [crc >> 4]) | (1 << (crc & 0xf)) - ); + le16_to_cpu(mcast_table [crc >> 4]) | (1 << (crc & 0xf))); } return; } @@ -1910,7 +1925,7 @@ static void pcnet32_set_multicast_list(struct net_device *dev) { unsigned long ioaddr = dev->base_addr, flags; - struct pcnet32_private *lp = dev->priv; + struct pcnet32_private *lp = dev->priv; spin_lock_irqsave(&lp->lock, flags); if (dev->flags&IFF_PROMISC) { @@ -1921,7 +1936,7 @@ lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); pcnet32_load_multicast (dev); } - + lp->a.write_csr (ioaddr, 0, 0x0004); /* Temporarily stop the lance. */ pcnet32_restart(dev, 0x0042); /* Resume normal operation */ @@ -1930,42 +1945,42 @@ static int mdio_read(struct net_device *dev, int phy_id, int reg_num) { - struct pcnet32_private *lp = dev->priv; - unsigned long ioaddr = dev->base_addr; - u16 val_out; - int phyaddr; - - if (!lp->mii) - return 0; - - phyaddr = lp->a.read_bcr(ioaddr, 33); - - lp->a.write_bcr(ioaddr, 33, ((phy_id & 0x1f) << 5) | (reg_num & 0x1f)); - val_out = lp->a.read_bcr(ioaddr, 34); - lp->a.write_bcr(ioaddr, 33, phyaddr); - - return val_out; + struct pcnet32_private *lp = dev->priv; + unsigned long ioaddr = dev->base_addr; + u16 val_out; + int phyaddr; + + if (!lp->mii) + return 0; + + phyaddr = lp->a.read_bcr(ioaddr, 33); + + lp->a.write_bcr(ioaddr, 33, ((phy_id & 0x1f) << 5) | (reg_num & 0x1f)); + val_out = lp->a.read_bcr(ioaddr, 34); + lp->a.write_bcr(ioaddr, 33, phyaddr); + + return val_out; } static void mdio_write(struct net_device *dev, int phy_id, int reg_num, int val) { - struct pcnet32_private *lp = dev->priv; - unsigned long ioaddr = dev->base_addr; - int phyaddr; + struct pcnet32_private *lp = dev->priv; + unsigned long ioaddr = dev->base_addr; + int phyaddr; - if (!lp->mii) - return; - - phyaddr = lp->a.read_bcr(ioaddr, 33); - - lp->a.write_bcr(ioaddr, 33, ((phy_id & 0x1f) << 5) | (reg_num & 0x1f)); - lp->a.write_bcr(ioaddr, 34, val); - lp->a.write_bcr(ioaddr, 33, phyaddr); + if (!lp->mii) + return; + + phyaddr = lp->a.read_bcr(ioaddr, 33); + + lp->a.write_bcr(ioaddr, 33, ((phy_id & 0x1f) << 5) | (reg_num & 0x1f)); + lp->a.write_bcr(ioaddr, 34, val); + lp->a.write_bcr(ioaddr, 33, phyaddr); } static int pcnet32_ioctl(struct net_device *dev, struct ifreq *rq, int cmd) { - struct pcnet32_private *lp = dev->priv; + struct pcnet32_private *lp = dev->priv; struct mii_ioctl_data *data = (struct mii_ioctl_data *)&rq->ifr_data; int rc; unsigned long flags; @@ -2022,15 +2037,15 @@ MODULE_PARM(debug, "i"); MODULE_PARM_DESC(debug, DRV_NAME " debug level"); MODULE_PARM(max_interrupt_work, "i"); -MODULE_PARM_DESC(max_interrupt_work, DRV_NAME " maximum events handled per interrupt"); +MODULE_PARM_DESC(max_interrupt_work, DRV_NAME " maximum events handled per interrupt"); MODULE_PARM(rx_copybreak, "i"); -MODULE_PARM_DESC(rx_copybreak, DRV_NAME " copy breakpoint for copy-only-tiny-frames"); +MODULE_PARM_DESC(rx_copybreak, DRV_NAME " copy breakpoint for copy-only-tiny-frames"); MODULE_PARM(tx_start_pt, "i"); -MODULE_PARM_DESC(tx_start_pt, DRV_NAME " transmit start point (0-3)"); +MODULE_PARM_DESC(tx_start_pt, DRV_NAME " transmit start point (0-3)"); MODULE_PARM(pcnet32vlb, "i"); -MODULE_PARM_DESC(pcnet32vlb, DRV_NAME " Vesa local bus (VLB) support (0/1)"); +MODULE_PARM_DESC(pcnet32vlb, DRV_NAME " Vesa local bus (VLB) support (0/1)"); MODULE_PARM(options, "1-" __MODULE_STRING(MAX_UNITS) "i"); -MODULE_PARM_DESC(options, DRV_NAME " initial option setting(s) (0-15)"); +MODULE_PARM_DESC(options, DRV_NAME " initial option setting(s) (0-15)"); MODULE_PARM(full_duplex, "1-" __MODULE_STRING(MAX_UNITS) "i"); MODULE_PARM_DESC(full_duplex, DRV_NAME " full duplex setting(s) (1)"); @@ -2063,7 +2078,7 @@ if (cards_found) printk(KERN_INFO PFX "%d cards_found.\n", cards_found); - + return (pcnet32_have_pci + cards_found) ? 0 : -ENODEV; } @@ -2071,7 +2086,6 @@ { struct net_device *next_dev; - /* No need to check MOD_IN_USE, as sys_delete_module() checks. */ while (pcnet32_dev) { struct pcnet32_private *lp = pcnet32_dev->priv; next_dev = lp->next; @@ -2081,6 +2095,7 @@ free_netdev(pcnet32_dev); pcnet32_dev = next_dev; } + if (pcnet32_have_pci) pci_unregister_driver(&pcnet32_driver); } -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:18:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:18:56 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKIaKO030614 for ; Tue, 20 Apr 2004 13:18:40 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKHnvt225428; Tue, 20 Apr 2004 16:17:54 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av03.boulder.ibm.com [9.17.193.83]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKHgux333644; Tue, 20 Apr 2004 14:17:42 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKEF513624; Tue, 20 Apr 2004 13:14:15 -0700 From: Don Fry Message-Id: <200404202014.i3KKEF513624@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 3/8 2.4.26-bk1] pcnet32 all printk under netif_msg To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:14:14 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4789 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 13726 Lines: 410 All printk's are now done under netif_msg debug level tests. --- linux-2.4.26-bk1/drivers/net/add.pcnet32.c Tue Apr 20 12:40:29 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:40:59 2004 @@ -22,8 +22,8 @@ *************************************************************************/ #define DRV_NAME "pcnet32" -#define DRV_VERSION "1.28" -#define DRV_RELDATE "02.20.2004" +#define DRV_VERSION "1.29" +#define DRV_RELDATE "04.06.2004" #define PFX DRV_NAME ": " static const char *version = @@ -612,7 +612,7 @@ test->flags |= ETH_TEST_FL_FAILED; } else if (netif_msg_hw(lp)) printk(KERN_DEBUG "%s: Loopback test passed.\n", dev->name); - } else + } else if (netif_msg_hw(lp)) printk(KERN_DEBUG "%s: No tests to run (specify 'Offline' on ethtool).", dev->name); } /* end pcnet32_ethtool_test */ @@ -820,23 +820,27 @@ err = pci_enable_device(pdev); if (err < 0) { - printk(KERN_ERR PFX "failed to enable device -- err=%d\n", err); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "failed to enable device -- err=%d\n", err); return err; } pci_set_master(pdev); ioaddr = pci_resource_start (pdev, 0); if (!ioaddr) { - printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk (KERN_ERR PFX "card has no PCI IO resources, aborting\n"); return -ENODEV; } if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) { - printk(KERN_ERR PFX "architecture does not support 32bit PCI busmaster DMA\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "architecture does not support 32bit PCI busmaster DMA\n"); return -ENODEV; } if (request_region(ioaddr, PCNET32_TOTAL_SIZE, "pcnet32_probe_pci") == NULL) { - printk(KERN_ERR PFX "io address range already allocated\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "io address range already allocated\n"); return -EBUSY; } @@ -878,10 +882,11 @@ } chip_version = a->read_csr(ioaddr, 88) | (a->read_csr(ioaddr,89) << 16); - if (pcnet32_debug & NETIF_MSG_PROBE) + if ((pcnet32_debug & NETIF_MSG_PROBE) && (pcnet32_debug & NETIF_MSG_HW)) printk(KERN_INFO " PCnet chip version is %#x.\n", chip_version); if ((chip_version & 0xfff) != 0x003) { - printk(KERN_INFO PFX "Unsupported chip version.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "Unsupported chip version.\n"); goto err_release_region; } @@ -941,8 +946,9 @@ fdx = 1; mii = 1; break; default: - printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", - chip_version); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", + chip_version); goto err_release_region; } @@ -962,13 +968,15 @@ dev = alloc_etherdev(0); if (!dev) { - printk(KERN_ERR PFX "Memory allocation failed.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "Memory allocation failed.\n"); ret = -ENOMEM; goto err_release_region; } SET_NETDEV_DEV(dev, &pdev->dev); - printk(KERN_INFO PFX "%s at %#3lx,", chipname, ioaddr); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO PFX "%s at %#3lx,", chipname, ioaddr); /* In most chips, after a chip reset, the ethernet address is read from the * station address PROM at the base address and programmed into the @@ -997,8 +1005,10 @@ if (!is_valid_ether_addr(dev->dev_addr) && is_valid_ether_addr(promaddr)) { #endif - printk(" warning: CSR address invalid,\n"); - printk(KERN_INFO " using instead PROM address of"); + if (pcnet32_debug & NETIF_MSG_PROBE) { + printk(" warning: CSR address invalid,\n"); + printk(KERN_INFO " using instead PROM address of"); + } memcpy(dev->dev_addr, promaddr, 6); } } @@ -1007,36 +1017,40 @@ if (!is_valid_ether_addr(dev->dev_addr)) memset(dev->dev_addr, 0, sizeof(dev->dev_addr)); - for (i = 0; i < 6; i++) - printk(" %2.2x", dev->dev_addr[i]); - - if (((chip_version + 1) & 0xfffe) == 0x2624) { /* Version 0x2623 - 0x2624 */ - i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ - printk("\n" KERN_INFO " tx_start_pt(0x%04x):",i); - switch(i>>10) { - case 0: printk(" 20 bytes,"); break; - case 1: printk(" 64 bytes,"); break; - case 2: printk(" 128 bytes,"); break; - case 3: printk("~220 bytes,"); break; - } - i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */ - printk(" BCR18(%x):",i&0xffff); - if (i & (1<<5)) printk("BurstWrEn "); - if (i & (1<<6)) printk("BurstRdEn "); - if (i & (1<<7)) printk("DWordIO "); - if (i & (1<<11)) printk("NoUFlow "); - i = a->read_bcr(ioaddr, 25); - printk("\n" KERN_INFO " SRAMSIZE=0x%04x,",i<<8); - i = a->read_bcr(ioaddr, 26); - printk(" SRAM_BND=0x%04x,",i<<8); - i = a->read_bcr(ioaddr, 27); - if (i & (1<<14)) printk("LowLatRx"); + if (pcnet32_debug & NETIF_MSG_PROBE) { + for (i = 0; i < 6; i++) + printk(" %2.2x", dev->dev_addr[i]); + + /* Version 0x2623 - 0x2624 */ + if (((chip_version + 1) & 0xfffe) == 0x2624) { + i = a->read_csr(ioaddr, 80) & 0x0C00; /* Check tx_start_pt */ + printk("\n" KERN_INFO " tx_start_pt(0x%04x):",i); + switch(i>>10) { + case 0: printk(" 20 bytes,"); break; + case 1: printk(" 64 bytes,"); break; + case 2: printk(" 128 bytes,"); break; + case 3: printk("~220 bytes,"); break; + } + i = a->read_bcr(ioaddr, 18); /* Check Burst/Bus control */ + printk(" BCR18(%x):",i&0xffff); + if (i & (1<<5)) printk("BurstWrEn "); + if (i & (1<<6)) printk("BurstRdEn "); + if (i & (1<<7)) printk("DWordIO "); + if (i & (1<<11)) printk("NoUFlow "); + i = a->read_bcr(ioaddr, 25); + printk("\n" KERN_INFO " SRAMSIZE=0x%04x,",i<<8); + i = a->read_bcr(ioaddr, 26); + printk(" SRAM_BND=0x%04x,",i<<8); + i = a->read_bcr(ioaddr, 27); + if (i & (1<<14)) printk("LowLatRx"); + } } dev->base_addr = ioaddr; /* pci_alloc_consistent returns page-aligned memory, so we do not have to check the alignment */ if ((lp = pci_alloc_consistent(pdev, sizeof(*lp), &lp_dma_addr)) == NULL) { - printk(KERN_ERR PFX "Consistent memory allocation failed.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "Consistent memory allocation failed.\n"); ret = -ENOMEM; goto err_free_netdev; } @@ -1072,7 +1086,8 @@ lp->options |= PCNET32_PORT_FD; if (!a) { - printk(KERN_ERR PFX "No access methods\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_ERR PFX "No access methods\n"); ret = -ENODEV; goto err_free_consistent; } @@ -1106,9 +1121,10 @@ dev->irq = irq_line; } - if (dev->irq >= 2) - printk(" assigned IRQ %d.\n", dev->irq); - else { + if (dev->irq >= 2) { + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(" assigned IRQ %d.\n", dev->irq); + } else { unsigned long irq_mask = probe_irq_on(); /* @@ -1122,11 +1138,13 @@ dev->irq = probe_irq_off (irq_mask); if (!dev->irq) { - printk(", failed to detect IRQ line.\n"); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(", failed to detect IRQ line.\n"); ret = -ENODEV; goto err_free_consistent; } - printk(", probed IRQ %d.\n", dev->irq); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(", probed IRQ %d.\n", dev->irq); } /* Set the mii phy_id so that we can query the link state */ @@ -1163,7 +1181,8 @@ pcnet32_dev = dev; } - printk(KERN_INFO "%s: registered as %s\n",dev->name, lp->name); + if (pcnet32_debug & NETIF_MSG_PROBE) + printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; return 0; @@ -1294,7 +1313,7 @@ /* If we have mii, print the link status and start the watchdog */ if (lp->mii) { - mii_check_media (&lp->mii_if, 1, 1); + mii_check_media (&lp->mii_if, netif_msg_link(lp), 1); mod_timer (&(lp->watchdog_timer), PCNET32_WATCHDOG_TIMEOUT); } @@ -1389,8 +1408,9 @@ if (rx_skbuff == NULL) { if (!(rx_skbuff = lp->rx_skbuff[i] = dev_alloc_skb (PKT_BUF_SZ))) { /* there is not much, we can do at this point */ - printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n", - dev->name); + if (pcnet32_debug & NETIF_MSG_DRV) + printk(KERN_ERR "%s: pcnet32_init_ring dev_alloc_skb failed.\n", + dev->name); return -1; } skb_reserve (rx_skbuff, 2); @@ -1452,8 +1472,9 @@ spin_lock_irqsave(&lp->lock, flags); /* Transmitter timeout, serious problems. */ - printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", - dev->name, lp->a.read_csr(ioaddr, 0)); + if (pcnet32_debug & NETIF_MSG_DRV) + printk(KERN_ERR "%s: transmit timed out, status %4.4x, resetting.\n", + dev->name, lp->a.read_csr(ioaddr, 0)); lp->a.write_csr (ioaddr, 0, 0x0004); lp->stats.tx_errors++; if (netif_msg_tx_err(lp)) { @@ -1561,7 +1582,8 @@ int must_restart; if (!dev) { - printk (KERN_DEBUG "%s(): irq %d for unknown device\n", + if (pcnet32_debug & NETIF_MSG_INTR) + printk (KERN_DEBUG "%s(): irq %d for unknown device\n", __FUNCTION__, irq); return; } @@ -1613,8 +1635,9 @@ lp->stats.tx_fifo_errors++; /* Ackk! On FIFO errors the Tx unit is turned off! */ /* Remove this verbosity later! */ - printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", - dev->name, csr0); + if (netif_msg_tx_err(lp)) + printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", + dev->name, csr0); must_restart = 1; } #else @@ -1623,8 +1646,9 @@ if (! lp->dxsuflo) { /* If controller doesn't recover ... */ /* Ackk! On FIFO errors the Tx unit is turned off! */ /* Remove this verbosity later! */ - printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", - dev->name, csr0); + if (netif_msg_tx_err(lp)) + printk(KERN_ERR "%s: Tx FIFO error! CSR0=%4.4x\n", + dev->name, csr0); must_restart = 1; } } @@ -1648,8 +1672,9 @@ delta = (lp->cur_tx - dirty_tx) & (TX_RING_MOD_MASK + TX_RING_SIZE); if (delta >= TX_RING_SIZE) { - printk(KERN_ERR "%s: out-of-sync dirty pointer, %d vs. %d, full=%d.\n", - dev->name, dirty_tx, lp->cur_tx, lp->tx_full); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: out-of-sync dirty pointer, %d vs. %d, full=%d.\n", + dev->name, dirty_tx, lp->cur_tx, lp->tx_full); dirty_tx += TX_RING_SIZE; delta -= TX_RING_SIZE; } @@ -1681,8 +1706,9 @@ lp->stats.rx_errors++; /* Missed a Rx frame. */ } if (csr0 & 0x0800) { - printk(KERN_ERR "%s: Bus master arbitration failure, status %4.4x.\n", - dev->name, csr0); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Bus master arbitration failure, status %4.4x.\n", + dev->name, csr0); /* unlike for the lance, there is no restart needed */ } @@ -1699,7 +1725,7 @@ if (netif_msg_intr(lp)) printk(KERN_DEBUG "%s: exiting interrupt, csr0=%#4.4x.\n", - dev->name, lp->a.read_csr (ioaddr, 0)); + dev->name, lp->a.read_csr (ioaddr, 0)); spin_unlock(&lp->lock); } @@ -1734,7 +1760,8 @@ struct sk_buff *skb; if (pkt_len < 60) { - printk(KERN_ERR "%s: Runt packet!\n",dev->name); + if (netif_msg_rx_err(lp)) + printk(KERN_ERR "%s: Runt packet!\n", dev->name); lp->stats.rx_errors++; } else { int rx_in_place = 0; @@ -1763,8 +1790,9 @@ if (skb == NULL) { int i; - printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", - dev->name); + if (netif_msg_drv(lp)) + printk(KERN_ERR "%s: Memory squeeze, deferring packet.\n", + dev->name); for (i = 0; i < RX_RING_SIZE; i++) if ((short)le16_to_cpu(lp->rx_ring[(entry+i) & RX_RING_MOD_MASK].status) < 0) @@ -1934,7 +1962,8 @@ spin_lock_irqsave(&lp->lock, flags); if (dev->flags&IFF_PROMISC) { /* Log any net taps. */ - printk(KERN_INFO "%s: Promiscuous mode enabled.\n", dev->name); + if (netif_msg_hw(lp)) + printk(KERN_INFO "%s: Promiscuous mode enabled.\n", dev->name); lp->init_block.mode = le16_to_cpu(0x8000 | (lp->options & PCNET32_PORT_PORTSEL) << 7); } else { lp->init_block.mode = le16_to_cpu((lp->options & PCNET32_PORT_PORTSEL) << 7); @@ -2009,7 +2038,7 @@ /* Print the link status if it has changed */ if (lp->mii) { spin_lock_irqsave(&lp->lock, flags); - mii_check_media (&lp->mii_if, 1, 0); + mii_check_media (&lp->mii_if, netif_msg_link(lp), 0); spin_unlock_irqrestore(&lp->lock, flags); } @@ -2057,6 +2086,8 @@ MODULE_DESCRIPTION("Driver for PCnet32 and PCnetPCI based ethercards"); MODULE_LICENSE("GPL"); +#define PCNET32_MSG_DEFAULT (NETIF_MSG_DRV | NETIF_MSG_PROBE | NETIF_MSG_LINK) + /* An additional parameter that may be passed in... */ static int debug = -1; static int tx_start_pt = -1; @@ -2066,8 +2097,7 @@ { printk(KERN_INFO "%s", version); - if (debug >= 0 && debug < (sizeof(int) - 1)) - pcnet32_debug = 1 << debug; + pcnet32_debug = netif_msg_init(debug, PCNET32_MSG_DEFAULT); if ((tx_start_pt >= 0) && (tx_start_pt <= 3)) tx_start = tx_start_pt; @@ -2080,7 +2110,7 @@ if (pcnet32vlb) pcnet32_probe_vlbus(); - if (cards_found) + if (cards_found && (pcnet32_debug & NETIF_MSG_PROBE)) printk(KERN_INFO PFX "%d cards_found.\n", cards_found); return (pcnet32_have_pci + cards_found) ? 0 : -ENODEV; @@ -2109,7 +2139,6 @@ /* * Local variables: - * compile-command: "gcc -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototypes -O6 -m486 -c pcnet32.c" * c-indent-level: 4 * tab-width: 8 * End: -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:18:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:18:57 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKInKO030622 for ; Tue, 20 Apr 2004 13:18:50 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKIQ67610526; Tue, 20 Apr 2004 16:18:26 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKIV6k052612; Tue, 20 Apr 2004 16:18:31 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKGTh13660; Tue, 20 Apr 2004 13:16:29 -0700 From: Don Fry Message-Id: <200404202016.i3KKGTh13660@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 6/8 2.4.26-bk1] pcnet32 transmit performance fix To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:16:29 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4790 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 987 Lines: 24 When the pcnet32 adapter is installed in a system with long PCI latency and the read burst bit is not set, performance on transmission is very low (under 20Mbit on a 100Mbit link). This will make sure that read and write bursts are enabled. Tested on ia32. --- linux-2.4.26-bk1/drivers/net/led.pcnet32.c Tue Apr 20 12:48:10 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:48:13 2004 @@ -1021,10 +1021,11 @@ * starting until the packet is loaded. Strike one for reliability, lose * one for latency - although on PCI this isnt a big loss. Older chips * have FIFO's smaller than a packet, so you can't do this. + * Turn on BCR18:BurstRdEn and BCR18:BurstWrEn. */ if (fset) { - a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0800)); + a->write_bcr(ioaddr, 18, (a->read_bcr(ioaddr, 18) | 0x0860)); a->write_csr(ioaddr, 80, (a->read_csr(ioaddr, 80) & 0x0C00) | 0x0c00); dxsuflo = 1; ltint = 1; -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:19:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:19:51 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKJkKO031200 for ; Tue, 20 Apr 2004 13:19:46 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKJdBs021228; Tue, 20 Apr 2004 16:19:39 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKJd6k062638; Tue, 20 Apr 2004 16:19:44 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKC9C13567; Tue, 20 Apr 2004 13:12:09 -0700 From: Don Fry Message-Id: <200404202012.i3KKC9C13567@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 0/8] 2.4.26-bk1 pcnet32.c To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:12:04 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4792 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 615 Lines: 15 Please apply the following patches to 2.4.26-bk1 to bring the 2.4 driver to the same level as 2.6.6 (and a little beyond). [PATCH 1/8 2.4.26-bk1] pcnet32 whitespace only changes [PATCH 2/8 2.4.26-bk1] pcnet32 add 79C976 support [PATCH 3/8 2.4.26-bk1] pcnet32 all printk under netif_msg [PATCH 4/8 2.4.26-bk1] pcnet32 correct name display [PATCH 5/8 2.4.26-bk1] pcnet32 add led blink capability [PATCH 6/8 2.4.26-bk1] pcnet32 transmit performance fix [PATCH 7/8 2.4.26-bk1] pcnet32 add register dump capability [PATCH 8/8 2.4.26-bk1] pcnet32 timer to free tx skbs for 79C971/972 -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:20:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:20:52 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKKhKO032096 for ; Tue, 20 Apr 2004 13:20:45 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKIxvt614882; Tue, 20 Apr 2004 16:19:05 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKIeVR141440; Tue, 20 Apr 2004 14:18:40 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKEpf13638; Tue, 20 Apr 2004 13:14:51 -0700 From: Don Fry Message-Id: <200404202014.i3KKEpf13638@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 4/8 2.4.26-bk1] pcnet32 correct name display To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:14:50 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4793 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 532 Lines: 18 This displays the device name (eth%d) instead of the device type when registering the interrupt handler. --- linux-2.4.26-bk1/drivers/net/print.pcnet32.c Tue Apr 20 12:45:37 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:46:18 2004 @@ -1208,7 +1208,7 @@ if (dev->irq == 0 || request_irq(dev->irq, &pcnet32_interrupt, - lp->shared_irq ? SA_SHIRQ : 0, lp->name, (void *)dev)) { + lp->shared_irq ? SA_SHIRQ : 0, dev->name, (void *)dev)) { return -EAGAIN; } -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:20:50 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:20:55 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKKnKO032140 for ; Tue, 20 Apr 2004 13:20:49 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKJpru777420; Tue, 20 Apr 2004 16:19:56 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKKFYS106828; Tue, 20 Apr 2004 16:20:16 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKI2H13698; Tue, 20 Apr 2004 13:18:02 -0700 From: Don Fry Message-Id: <200404202018.i3KKI2H13698@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 7/8 2.4.26-bk1] pcnet32 add register dump capability To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:18:01 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4794 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3397 Lines: 119 Please apply this patch to include the capability to dump chip registers. Ethtool -d support. --- linux-2.4.26-bk1/drivers/net/read.pcnet32.c Tue Apr 20 12:48:18 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:54:21 2004 @@ -132,6 +132,8 @@ }; #define PCNET32_TEST_LEN (sizeof(pcnet32_gstrings_test) / ETH_GSTRING_LEN) +#define PCNET32_NUM_REGS 146 + #define MAX_UNITS 8 /* More are supported, limit only on options */ static int options[MAX_UNITS]; static int full_duplex[MAX_UNITS]; @@ -234,7 +236,7 @@ * Jim Lewis added ethernet loopback test. * Thomas Munck Steenholdt non-mii ioctl corrections. * v1.29 6 Apr 2004 Jim Lewis added physical - * identification code (blink led's). + * identification code (blink led's) and register dump. */ @@ -372,6 +374,9 @@ static int pcnet32_loopback_test(struct net_device *dev, uint64_t *data1); static int pcnet32_phys_id(struct net_device *dev, u32 data); static void pcnet32_led_blink_callback(struct net_device *dev); +static int pcnet32_get_regs_len(struct net_device *dev); +static void pcnet32_get_regs(struct net_device *dev, struct ethtool_regs *regs, + void *ptr); enum pci_flags_bit { PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4, @@ -837,6 +842,72 @@ return 0; } +int pcnet32_get_regs_len(struct net_device *dev) +{ + return(PCNET32_NUM_REGS * sizeof(u16)); +} + +void pcnet32_get_regs(struct net_device *dev, struct ethtool_regs *regs, + void *ptr) +{ + int i, csr0; + u16 *buff = ptr; + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + int ticks; + unsigned long flags; + + spin_lock_irqsave(&lp->lock, flags); + + csr0 = a->read_csr(ioaddr, 0); + if (!(csr0 & 0x0004)) { /* If not stopped */ + /* set SUSPEND (SPND) - CSR5 bit 0 */ + a->write_csr(ioaddr, 5, 0x0001); + + /* poll waiting for bit to be set */ + ticks = 0; + while (!(a->read_csr(ioaddr, 5) & 0x0001)) { + spin_unlock_irqrestore(&lp->lock, flags); + mdelay(1); + spin_lock_irqsave(&lp->lock, flags); + ticks++; + if (ticks > 200) { + if (netif_msg_hw(lp)) + printk(KERN_DEBUG "%s: Error getting into suspend!\n", + dev->name); + break; + } + } + } + + /* read address PROM */ + for (i=0; i<16; i += 2) + *buff++ = inw(ioaddr + i); + + for (i = 0; i <= 89; i++) { + *buff++ = a->read_csr(ioaddr, i); + } + + *buff++ = a->read_csr(ioaddr, 112); + *buff++ = a->read_csr(ioaddr, 114); + + for (i = 0; i <= 35; i++) { + *buff++ = a->read_bcr(ioaddr, i); + } + + if (!(csr0 & 0x0004)) { /* If not stopped */ + /* clear SUSPEND (SPND) - CSR5 bit 0 */ + a->write_csr(ioaddr, 5, 0x0000); + } + + i = buff - (u16 *)ptr; + for (; i < PCNET32_NUM_REGS; i++) + *buff++ = 0; + + spin_unlock_irqrestore(&lp->lock, flags); +} + static struct ethtool_ops pcnet32_ethtool_ops = { .get_settings = pcnet32_get_settings, .set_settings = pcnet32_set_settings, @@ -852,6 +923,8 @@ .self_test_count = pcnet32_self_test_count, .self_test = pcnet32_ethtool_test, .phys_id = pcnet32_phys_id, + .get_regs_len = pcnet32_get_regs_len, + .get_regs = pcnet32_get_regs, }; /* only probes for non-PCI devices, the rest are handled by -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:21:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:21:15 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKL9KO032324 for ; Tue, 20 Apr 2004 13:21:09 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i3KKL1Kg467484; Tue, 20 Apr 2004 16:21:01 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKL56k083126; Tue, 20 Apr 2004 16:21:06 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKFg513649; Tue, 20 Apr 2004 13:15:42 -0700 From: Don Fry Message-Id: <200404202015.i3KKFg513649@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 5/8 2.4.26-bk1] pcnet32 add led blink capability To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:15:32 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4795 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 3826 Lines: 125 Please apply this patch to include the capability of blinking the LED's for device identification. Ethtool -p support. --- linux-2.4.26-bk1/drivers/net/irq.pcnet32.c Tue Apr 20 12:46:27 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:47:08 2004 @@ -102,6 +102,7 @@ #define PCNET32_DMA_MASK 0xffffffff #define PCNET32_WATCHDOG_TIMEOUT (jiffies + (2 * HZ)) +#define PCNET32_BLINK_TIMEOUT (jiffies + (HZ/4)) /* * table to translate option values from tulip @@ -232,6 +233,8 @@ * length errors, and transmit hangs. Cleans up after errors in open. * Jim Lewis added ethernet loopback test. * Thomas Munck Steenholdt non-mii ioctl corrections. + * v1.29 6 Apr 2004 Jim Lewis added physical + * identification code (blink led's). */ @@ -342,6 +345,7 @@ struct net_device *next; struct mii_if_info mii_if; struct timer_list watchdog_timer; + struct timer_list blink_timer; u32 msg_enable; /* debug message level */ }; @@ -366,6 +370,8 @@ static void pcnet32_ethtool_test(struct net_device *dev, struct ethtool_test *eth_test, u64 *data); static int pcnet32_loopback_test(struct net_device *dev, uint64_t *data1); +static int pcnet32_phys_id(struct net_device *dev, u32 data); +static void pcnet32_led_blink_callback(struct net_device *dev); enum pci_flags_bit { PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4, @@ -774,6 +780,63 @@ return(rc); } /* end pcnet32_loopback_test */ +static void pcnet32_led_blink_callback(struct net_device *dev) +{ + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + unsigned long flags; + int i; + + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + a->write_bcr(ioaddr, i, a->read_bcr(ioaddr, i) ^ 0x4000); + } + spin_unlock_irqrestore(&lp->lock, flags); + + mod_timer(&lp->blink_timer, PCNET32_BLINK_TIMEOUT); +} + +static int pcnet32_phys_id(struct net_device *dev, u32 data) +{ + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + unsigned long flags; + int i, regs[4]; + + if (!lp->blink_timer.function) { + init_timer(&lp->blink_timer); + lp->blink_timer.function = (void *) pcnet32_led_blink_callback; + lp->blink_timer.data = (unsigned long) dev; + } + + /* Save the current value of the bcrs */ + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + regs[i-4] = a->read_bcr(ioaddr, i); + } + spin_unlock_irqrestore(&lp->lock, flags); + + mod_timer(&lp->blink_timer, jiffies); + set_current_state(TASK_INTERRUPTIBLE); + + if ((!data) || (data > (u32)(MAX_SCHEDULE_TIMEOUT / HZ))) + data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ); + + schedule_timeout(data * HZ); + del_timer_sync(&lp->blink_timer); + + /* Restore the original value of the bcrs */ + spin_lock_irqsave(&lp->lock, flags); + for (i=4; i<8; i++) { + a->write_bcr(ioaddr, i, regs[i-4]); + } + spin_unlock_irqrestore(&lp->lock, flags); + + return 0; +} + static struct ethtool_ops pcnet32_ethtool_ops = { .get_settings = pcnet32_get_settings, .set_settings = pcnet32_set_settings, @@ -788,6 +851,7 @@ .get_strings = pcnet32_get_strings, .self_test_count = pcnet32_self_test_count, .self_test = pcnet32_ethtool_test, + .phys_id = pcnet32_phys_id, }; /* only probes for non-PCI devices, the rest are handled by @@ -1184,6 +1248,9 @@ if (pcnet32_debug & NETIF_MSG_PROBE) printk(KERN_INFO "%s: registered as %s\n", dev->name, lp->name); cards_found++; + + a->write_bcr(ioaddr, 2, 0x1002); /* enable LED writes */ + return 0; err_free_consistent: -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 13:22:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 13:23:00 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KKMpKO000644 for ; Tue, 20 Apr 2004 13:22:54 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KKMEru343000; Tue, 20 Apr 2004 16:22:19 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KKMZYS067170; Tue, 20 Apr 2004 16:22:36 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KKJwU13709; Tue, 20 Apr 2004 13:19:58 -0700 From: Don Fry Message-Id: <200404202019.i3KKJwU13709@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 8/8 2.4.26-bk1] pcnet32 timer to free tx skbs for 79C971/972 To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 13:19:58 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4796 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4632 Lines: 160 This patch uses an on-chip timer to free completed transmit skb's for the 79C971 and 972 versions which currently will leave completed transmit skb's on the transmit ring until new transmit traffic occurs. --- linux-2.4.26-bk1/drivers/net/dump.pcnet32.c Tue Apr 20 12:54:49 2004 +++ linux-2.4.26-bk1/drivers/net/pcnet32.c Tue Apr 20 12:54:57 2004 @@ -237,6 +237,8 @@ * Thomas Munck Steenholdt non-mii ioctl corrections. * v1.29 6 Apr 2004 Jim Lewis added physical * identification code (blink led's) and register dump. + * Don Fry added timer for 971/972 so skbufs don't remain on tx ring + * forever. */ @@ -1104,6 +1106,13 @@ ltint = 1; } + if (ltint) { + /* Enable timer to prevent skbuffs from remaining on the tx ring + * forever if no other tx being done. Set timer period to about + * 122 ms */ + a->write_bcr(ioaddr, 31, 0x253b); + } + dev = alloc_etherdev(0); if (!dev) { if (pcnet32_debug & NETIF_MSG_PROBE) @@ -1450,6 +1459,11 @@ lp->a.write_csr (ioaddr, 4, 0x0915); lp->a.write_csr (ioaddr, 0, 0x0001); + if (lp->ltint) { + /* start the software timer */ + lp->a.write_csr(ioaddr, 7, 0x0400); /* set STINTE */ + } + netif_start_queue(dev); /* If we have mii, print the link status and start the watchdog */ @@ -1651,13 +1665,13 @@ int entry; unsigned long flags; + spin_lock_irqsave(&lp->lock, flags); + if (netif_msg_tx_queued(lp)) { printk(KERN_DEBUG "%s: pcnet32_start_xmit() called, csr0 %4.4x.\n", dev->name, lp->a.read_csr(ioaddr, 0)); } - spin_lock_irqsave(&lp->lock, flags); - /* Default status -- will not enable Successful-TxDone * interrupt when that option is available to us. */ @@ -1718,7 +1732,7 @@ struct net_device *dev = dev_id; struct pcnet32_private *lp; unsigned long ioaddr; - u16 csr0,rap; + u16 csr0, csr7, rap; int boguscnt = max_interrupt_work; int must_restart; @@ -1735,13 +1749,19 @@ spin_lock(&lp->lock); rap = lp->a.read_rap(ioaddr); - while ((csr0 = lp->a.read_csr (ioaddr, 0)) & 0x8600 && --boguscnt >= 0) { + csr0 = lp->a.read_csr (ioaddr, 0); + csr7 = lp->ltint ? lp->a.read_csr(ioaddr, 7) : 0; + + while ((csr0 & 0x8600 || csr7 & 0x0800) && --boguscnt >= 0) { if (csr0 == 0xffff) { break; /* PCMCIA remove happened */ } /* Acknowledge all of the current interrupt sources ASAP. */ lp->a.write_csr (ioaddr, 0, csr0 & ~0x004f); + if (csr7 & 0x0800) + lp->a.write_csr(ioaddr, 7, csr7); + must_restart = 0; if (netif_msg_intr(lp)) @@ -1751,7 +1771,7 @@ if (csr0 & 0x0400) /* Rx interrupt */ pcnet32_rx(dev); - if (csr0 & 0x0200) { /* Tx-done interrupt */ + if (csr0 & 0x0200 || csr7 & 0x0800) { /* Tx-done or Timer interrupt */ unsigned int dirty_tx = lp->dirty_tx; int delta; @@ -1858,6 +1878,9 @@ lp->a.write_csr (ioaddr, 0, 0x0004); pcnet32_restart(dev, 0x0002); } + + csr0 = lp->a.read_csr (ioaddr, 0); + csr7 = lp->ltint ? lp->a.read_csr(ioaddr, 7) : 0; } /* Clear any other interrupt, and set interrupt enable. */ @@ -1942,6 +1965,7 @@ if (i > RX_RING_SIZE -2) { lp->stats.rx_dropped++; lp->rx_ring[entry].status |= le16_to_cpu(0x8000); + wmb(); /* Make sure adapter sees owner change */ lp->cur_rx++; } break; @@ -2001,6 +2025,10 @@ /* We stop the PCNET32 here -- it occasionally polls memory if we don't. */ lp->a.write_csr (ioaddr, 0, 0x0004); + if (lp->ltint) { /* Disable timer interrupts */ + lp->a.write_csr(ioaddr, 7, 0x0000); + } + /* * Switch back to 16bit mode to avoid problems with dumb * DOS packet driver after a warm reboot @@ -2011,9 +2039,12 @@ free_irq(dev->irq, dev); + spin_lock_irqsave(&lp->lock, flags); + /* free all allocated skbuffs */ for (i = 0; i < RX_RING_SIZE; i++) { lp->rx_ring[i].status = 0; + wmb(); /* Make sure adapter sees owner change */ if (lp->rx_skbuff[i]) { pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); @@ -2024,6 +2055,8 @@ } for (i = 0; i < TX_RING_SIZE; i++) { + lp->tx_ring[i].status = 0; /* CPU owns buffer */ + wmb(); /* Make sure adapter sees owner change */ if (lp->tx_skbuff[i]) { pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); @@ -2033,6 +2066,8 @@ lp->tx_dma_addr[i] = 0; } + spin_unlock_irqrestore(&lp->lock, flags); + return 0; } -- Don Fry brazilnut@us.ibm.com From romieu@fr.zoreil.com Tue Apr 20 15:28:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 15:28:43 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KMSZKO002712 for ; Tue, 20 Apr 2004 15:28:36 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3KLR2uX003060; Tue, 20 Apr 2004 23:27:02 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3KLR24C003059; Tue, 20 Apr 2004 23:27:02 +0200 Date: Tue, 20 Apr 2004 23:27:02 +0200 From: Francois Romieu To: netdev@oss.sgi.com Cc: jgarzik@pobox.com, Chen-Bin Su Subject: [patch] 2.4.26 - r8169 backport Message-ID: <20040420232702.A2543@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 4797 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 575 Lines: 19 A backport of the 2.6.6-rc1 r8169 driver against 2.4.26 is available. All in one patch against 2.4.26: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.26/r8169-mammoth-attack.patch Individual files: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.26 Tarball: http://www.fr.zoreil.com/linux/kernel/2.4.x/2.4.26/r8169-blob.tar.bz2 I will surely extract the part related to the Tx loop in the irq handler and submit it for 2.4.x as a bugfix. I have no strong feeling about the remaining parts though. Please Cc: netdev@oss.sgi.com if something goes wrong. -- Ueimor From brazilnut@us.ibm.com Tue Apr 20 15:57:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 15:57:41 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KMvSKO003858 for ; Tue, 20 Apr 2004 15:57:34 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KMv1ru712682; Tue, 20 Apr 2004 18:57:01 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KMv56k077524; Tue, 20 Apr 2004 18:57:06 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KMsva13912; Tue, 20 Apr 2004 15:54:57 -0700 From: Don Fry Message-Id: <200404202254.i3KMsva13912@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 1/2 2.6.6-rc1-bk5] pcnet32 add register dump capability To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 15:54:56 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4798 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 4067 Lines: 137 At the next opportunity to add new code to 2.6.6, please apply the following patch to include the capability to dump chip registers. Ethtool -d support. --- linux-2.6.6-rc1-bk5/drivers/net/good.pcnet32.c Tue Apr 20 15:46:32 2004 +++ linux-2.6.6-rc1-bk5/drivers/net/pcnet32.c Tue Apr 20 15:43:34 2004 @@ -132,6 +132,8 @@ }; #define PCNET32_TEST_LEN (sizeof(pcnet32_gstrings_test) / ETH_GSTRING_LEN) +#define PCNET32_NUM_REGS 146 + #define MAX_UNITS 8 /* More are supported, limit only on options */ static int options[MAX_UNITS]; static int full_duplex[MAX_UNITS]; @@ -234,7 +236,7 @@ * Jim Lewis added ethernet loopback test. * Thomas Munck Steenholdt non-mii ioctl corrections. * v1.29 6 Apr 2004 Jim Lewis added physical - * identification code (blink led's). + * identification code (blink led's) and register dump. */ @@ -372,6 +374,9 @@ static int pcnet32_loopback_test(struct net_device *dev, uint64_t *data1); static int pcnet32_phys_id(struct net_device *dev, u32 data); static void pcnet32_led_blink_callback(struct net_device *dev); +static int pcnet32_get_regs_len(struct net_device *dev); +static void pcnet32_get_regs(struct net_device *dev, struct ethtool_regs *regs, + void *ptr); enum pci_flags_bit { PCI_USES_IO=1, PCI_USES_MEM=2, PCI_USES_MASTER=4, @@ -681,7 +686,7 @@ for (i=0; i<6; i++) *packet++ = dev->dev_addr[i]; for (i=0; i<6; i++) - *packet++ = dev->dev_addr[i]; + *packet++ = dev->dev_addr[i]; /* type */ *packet++ = 0x08; *packet++ = 0x06; @@ -837,6 +842,72 @@ return 0; } +int pcnet32_get_regs_len(struct net_device *dev) +{ + return(PCNET32_NUM_REGS * sizeof(u16)); +} + +void pcnet32_get_regs(struct net_device *dev, struct ethtool_regs *regs, + void *ptr) +{ + int i, csr0; + u16 *buff = ptr; + struct pcnet32_private *lp = dev->priv; + struct pcnet32_access *a = &lp->a; + ulong ioaddr = dev->base_addr; + int ticks; + unsigned long flags; + + spin_lock_irqsave(&lp->lock, flags); + + csr0 = a->read_csr(ioaddr, 0); + if (!(csr0 & 0x0004)) { /* If not stopped */ + /* set SUSPEND (SPND) - CSR5 bit 0 */ + a->write_csr(ioaddr, 5, 0x0001); + + /* poll waiting for bit to be set */ + ticks = 0; + while (!(a->read_csr(ioaddr, 5) & 0x0001)) { + spin_unlock_irqrestore(&lp->lock, flags); + mdelay(1); + spin_lock_irqsave(&lp->lock, flags); + ticks++; + if (ticks > 200) { + if (netif_msg_hw(lp)) + printk(KERN_DEBUG "%s: Error getting into suspend!\n", + dev->name); + break; + } + } + } + + /* read address PROM */ + for (i=0; i<16; i += 2) + *buff++ = inw(ioaddr + i); + + for (i = 0; i <= 89; i++) { + *buff++ = a->read_csr(ioaddr, i); + } + + *buff++ = a->read_csr(ioaddr, 112); + *buff++ = a->read_csr(ioaddr, 114); + + for (i = 0; i <= 35; i++) { + *buff++ = a->read_bcr(ioaddr, i); + } + + if (!(csr0 & 0x0004)) { /* If not stopped */ + /* clear SUSPEND (SPND) - CSR5 bit 0 */ + a->write_csr(ioaddr, 5, 0x0000); + } + + i = buff - (u16 *)ptr; + for (; i < PCNET32_NUM_REGS; i++) + *buff++ = 0; + + spin_unlock_irqrestore(&lp->lock, flags); +} + static struct ethtool_ops pcnet32_ethtool_ops = { .get_settings = pcnet32_get_settings, .set_settings = pcnet32_set_settings, @@ -853,6 +924,8 @@ .self_test_count = pcnet32_self_test_count, .self_test = pcnet32_ethtool_test, .phys_id = pcnet32_phys_id, + .get_regs_len = pcnet32_get_regs_len, + .get_regs = pcnet32_get_regs, }; /* only probes for non-PCI devices, the rest are handled by @@ -1371,7 +1444,7 @@ /* Re-initialize the PCNET32, and start it when done. */ lp->a.write_csr (ioaddr, 1, (lp->dma_addr + - offsetof(struct pcnet32_private, init_block)) & 0xffff); + offsetof(struct pcnet32_private, init_block)) & 0xffff); lp->a.write_csr (ioaddr, 2, (lp->dma_addr + offsetof(struct pcnet32_private, init_block)) >> 16); -- Don Fry brazilnut@us.ibm.com From brazilnut@us.ibm.com Tue Apr 20 15:59:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 15:59:47 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KMxYKO004182 for ; Tue, 20 Apr 2004 15:59:35 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3KMxRAL651468; Tue, 20 Apr 2004 18:59:27 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3KMxlYS104034; Tue, 20 Apr 2004 18:59:47 -0400 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3KMvSr13923; Tue, 20 Apr 2004 15:57:28 -0700 From: Don Fry Message-Id: <200404202257.i3KMvSr13923@DYN318364BLD.beaverton.ibm.com> Subject: [PATCH 2/2 2.6.6-rc1-bk5] pcnet32 timer to free tx skbs for 79C971/972 To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Tue, 20 Apr 2004 15:57:28 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4799 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 5026 Lines: 175 At the next opportunity to add new code to 2.6.6, please apply the following: This patch uses an on-chip timer to free completed transmit skb's for the 79C971 and 972 versions which currently will leave completed transmit skb's on the transmit ring until new transmit traffic occurs. --- linux-2.6.6-rc1-bk5/drivers/net/dump.pcnet32.c Tue Apr 20 15:47:47 2004 +++ linux-2.6.6-rc1-bk5/drivers/net/pcnet32.c Tue Apr 20 15:48:49 2004 @@ -237,6 +237,8 @@ * Thomas Munck Steenholdt non-mii ioctl corrections. * v1.29 6 Apr 2004 Jim Lewis added physical * identification code (blink led's) and register dump. + * Don Fry added timer for 971/972 so skbufs don't remain on tx ring + * forever. */ @@ -497,9 +499,9 @@ #ifdef CONFIG_NET_POLL_CONTROLLER static void pcnet32_poll_controller(struct net_device *dev) { - disable_irq(dev->irq); - pcnet32_interrupt(0, dev, NULL); - enable_irq(dev->irq); + disable_irq(dev->irq); + pcnet32_interrupt(0, dev, NULL); + enable_irq(dev->irq); } #endif @@ -1105,6 +1107,13 @@ ltint = 1; } + if (ltint) { + /* Enable timer to prevent skbuffs from remaining on the tx ring + * forever if no other tx being done. Set timer period to about + * 122 ms */ + a->write_bcr(ioaddr, 31, 0x253b); + } + dev = alloc_etherdev(0); if (!dev) { if (pcnet32_debug & NETIF_MSG_PROBE) @@ -1451,6 +1460,11 @@ lp->a.write_csr (ioaddr, 4, 0x0915); lp->a.write_csr (ioaddr, 0, 0x0001); + if (lp->ltint) { + /* start the software timer */ + lp->a.write_csr(ioaddr, 7, 0x0400); /* set STINTE */ + } + netif_start_queue(dev); /* If we have mii, print the link status and start the watchdog */ @@ -1652,13 +1666,13 @@ int entry; unsigned long flags; + spin_lock_irqsave(&lp->lock, flags); + if (netif_msg_tx_queued(lp)) { printk(KERN_DEBUG "%s: pcnet32_start_xmit() called, csr0 %4.4x.\n", dev->name, lp->a.read_csr(ioaddr, 0)); } - spin_lock_irqsave(&lp->lock, flags); - /* Default status -- will not enable Successful-TxDone * interrupt when that option is available to us. */ @@ -1719,7 +1733,7 @@ struct net_device *dev = dev_id; struct pcnet32_private *lp; unsigned long ioaddr; - u16 csr0,rap; + u16 csr0, csr7, rap; int boguscnt = max_interrupt_work; int must_restart; @@ -1736,13 +1750,19 @@ spin_lock(&lp->lock); rap = lp->a.read_rap(ioaddr); - while ((csr0 = lp->a.read_csr (ioaddr, 0)) & 0x8600 && --boguscnt >= 0) { + csr0 = lp->a.read_csr (ioaddr, 0); + csr7 = lp->ltint ? lp->a.read_csr(ioaddr, 7) : 0; + + while ((csr0 & 0x8600 || csr7 & 0x0800) && --boguscnt >= 0) { if (csr0 == 0xffff) { break; /* PCMCIA remove happened */ } /* Acknowledge all of the current interrupt sources ASAP. */ lp->a.write_csr (ioaddr, 0, csr0 & ~0x004f); + if (csr7 & 0x0800) + lp->a.write_csr(ioaddr, 7, csr7); + must_restart = 0; if (netif_msg_intr(lp)) @@ -1752,7 +1772,7 @@ if (csr0 & 0x0400) /* Rx interrupt */ pcnet32_rx(dev); - if (csr0 & 0x0200) { /* Tx-done interrupt */ + if (csr0 & 0x0200 || csr7 & 0x0800) { /* Tx-done or Timer interrupt */ unsigned int dirty_tx = lp->dirty_tx; int delta; @@ -1859,6 +1879,9 @@ lp->a.write_csr (ioaddr, 0, 0x0004); pcnet32_restart(dev, 0x0002); } + + csr0 = lp->a.read_csr (ioaddr, 0); + csr7 = lp->ltint ? lp->a.read_csr(ioaddr, 7) : 0; } /* Clear any other interrupt, and set interrupt enable. */ @@ -1945,6 +1968,7 @@ if (i > RX_RING_SIZE -2) { lp->stats.rx_dropped++; lp->rx_ring[entry].status |= le16_to_cpu(0x8000); + wmb(); /* Make sure adapter sees owner change */ lp->cur_rx++; } break; @@ -2008,6 +2032,10 @@ /* We stop the PCNET32 here -- it occasionally polls memory if we don't. */ lp->a.write_csr (ioaddr, 0, 0x0004); + if (lp->ltint) { /* Disable timer interrupts */ + lp->a.write_csr(ioaddr, 7, 0x0000); + } + /* * Switch back to 16bit mode to avoid problems with dumb * DOS packet driver after a warm reboot @@ -2018,9 +2046,12 @@ free_irq(dev->irq, dev); + spin_lock_irqsave(&lp->lock, flags); + /* free all allocated skbuffs */ for (i = 0; i < RX_RING_SIZE; i++) { lp->rx_ring[i].status = 0; + wmb(); /* Make sure adapter sees owner change */ if (lp->rx_skbuff[i]) { pci_unmap_single(lp->pci_dev, lp->rx_dma_addr[i], PKT_BUF_SZ-2, PCI_DMA_FROMDEVICE); @@ -2031,6 +2062,8 @@ } for (i = 0; i < TX_RING_SIZE; i++) { + lp->tx_ring[i].status = 0; /* CPU owns buffer */ + wmb(); /* Make sure adapter sees owner change */ if (lp->tx_skbuff[i]) { pci_unmap_single(lp->pci_dev, lp->tx_dma_addr[i], lp->tx_skbuff[i]->len, PCI_DMA_TODEVICE); @@ -2040,6 +2073,8 @@ lp->tx_dma_addr[i] = 0; } + spin_unlock_irqrestore(&lp->lock, flags); + return 0; } -- Don Fry brazilnut@us.ibm.com From scott.feldman@intel.com Tue Apr 20 16:08:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 16:08:50 -0700 (PDT) Received: from fmsfmr004.fm.intel.com (fmr11.intel.com [192.55.52.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3KN8jKO004618 for ; Tue, 20 Apr 2004 16:08:45 -0700 Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by fmsfmr004.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3KN8hhl031272; Tue, 20 Apr 2004 23:08:43 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3KN8PUL028217; Tue, 20 Apr 2004 23:08:37 GMT Received: from snichols-desk.amr.corp.intel.com ([134.134.3.158]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042016083015110 ; Tue, 20 Apr 2004 16:08:31 -0700 Date: Tue, 20 Apr 2004 16:04:26 -0700 (PDT) From: Scott Feldman To: Mike Keehan , eamonn.hamilton@saic.com cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: e100 NETDEV WATCHDOG transmit timeout since 2.6.4 In-Reply-To: Message-ID: References: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4800 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 2189 Lines: 75 On Tue, 20 Apr 2004, Mike Keehan wrote: > I am getting these too in recent kernels, but only on a > 10Mhz half-duplex network. I have to manually down > and up the interface to recover. > > On a 100Mhz switched network, the e100 is OK (at least 12hours+). Mike/Eamonn, Give this patch a try. This adds a required workaround for ICH when working at 10/Half. (Guessing you have an ICH system). --- linux-2.5/drivers/net/e100.c 2004-04-20 15:52:24.000000000 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-04-20 15:55:32.000000000 -0700 @@ -287,6 +287,7 @@ enum scb_cmd_hi { }; enum scb_cmd_lo { + cuc_nop = 0x00, ruc_start = 0x01, ruc_load_base = 0x06, cuc_start = 0x10, @@ -514,10 +515,11 @@ struct nic { /* End: frequently used values: keep adjacent for cache effect */ enum { - ich = (1 << 0), - promiscuous = (1 << 1), - multicast_all = (1 << 2), - wol_magic = (1 << 3), + ich = (1 << 0), + promiscuous = (1 << 1), + multicast_all = (1 << 2), + wol_magic = (1 << 3), + ich_10h_workaround = (1 << 4), } flags ____cacheline_aligned; enum mac mac; @@ -1225,6 +1227,12 @@ static void e100_watchdog(unsigned long /* Issue a multicast command to workaround a 557 lock up */ e100_set_multicast_list(nic->netdev); + if(nic->flags & ich && cmd.speed==SPEED_10 && cmd.duplex==DUPLEX_HALF) + /* Need SW workaround for ICH[x] 10Mbps/half duplex Tx hang. */ + nic->flags |= ich_10h_workaround; + else + nic->flags &= ~ich_10h_workaround; + mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD); } @@ -1244,7 +1252,17 @@ static inline void e100_xmit_prepare(str static int e100_xmit_frame(struct sk_buff *skb, struct net_device *netdev) { struct nic *nic = netdev->priv; - int err = e100_exec_cb(nic, skb, e100_xmit_prepare); + int err; + + if(nic->flags & ich_10h_workaround) { + /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang. + Issue a NOP command followed by a 1us delay before + issuing the Tx command. */ + e100_exec_cmd(nic, cuc_nop, 0); + udelay(1); + } + + err = e100_exec_cb(nic, skb, e100_xmit_prepare); switch(err) { case -ENOSPC: From chrisw@osdl.org Tue Apr 20 18:05:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 18:06:00 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L15uKO010121 for ; Tue, 20 Apr 2004 18:05:57 -0700 Received: from build.pdx.osdl.net (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i3L15p225539; Tue, 20 Apr 2004 18:05:51 -0700 Received: (from chrisw@localhost) by build.pdx.osdl.net (8.11.6/8.11.6) id i3L15pH28028; Tue, 20 Apr 2004 18:05:51 -0700 Date: Tue, 20 Apr 2004 18:05:51 -0700 From: Chris Wright To: davem@redhat.com Cc: netdev@oss.sgi.com Subject: [PATCH] fix return value on MCAST_MSFILTER error case Message-ID: <20040420180551.I21045@build.pdx.osdl.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 4801 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chrisw@osdl.org Precedence: bulk X-list: netdev Content-Length: 445 Lines: 14 Return -EINVAL if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen) ===== net/ipv4/ip_sockglue.c 1.22 vs edited ===== --- 1.22/net/ipv4/ip_sockglue.c Mon Mar 8 12:15:03 2004 +++ edited/net/ipv4/ip_sockglue.c Tue Apr 20 18:00:50 2004 @@ -800,7 +800,7 @@ goto mc_msf_out; } if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen) { - err = EINVAL; + err = -EINVAL; goto mc_msf_out; } msize = IP_MSFILTER_SIZE(gsf->gf_numsrc); From syrius.ml@no-log.org Tue Apr 20 18:50:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 18:50:22 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L1oHKO011431 for ; Tue, 20 Apr 2004 18:50:17 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id 2D477341CB; Wed, 21 Apr 2004 03:50:11 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id 182B334403; Wed, 21 Apr 2004 03:50:10 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 067C5F9; Wed, 21 Apr 2004 03:43:13 +0200 (CEST) To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <1082427350.1034.70.camel@jzny.localdomain> From: syrius.ml@no-log.org Date: Wed, 21 Apr 2004 03:43:13 +0200 In-Reply-To: <1082427350.1034.70.camel@jzny.localdomain> (hadi@cyberus.ca's message of "19 Apr 2004 22:15:50 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4802 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 1185 Lines: 29 jamal writes: [...] >> $TC qdisc add dev ppp0 root handle 1: prio >> $TC filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \ >> match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 > Note: this will do for ipv4; if you want ipv6 add a new rule, > in addition to above if you want ipv4, with "protocol ip" replaced by > "protocol ipv6" >> $TC qdisc add dev tun0 root handle 1: prio >> $TC filter add dev tun0 parent 1:0 protocol ip prio 10 u32 \ >> match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 >> $TC qdisc add dev sit1 root handle 1: prio >> $TC filter add dev sit1 parent 1:0 protocol ipv6 prio 10 u32 \ >> match u32 0 0 flowid 1:1 action mirred egress redirect dev dummy0 > not sure if you need the above but i dont know your setup sufficiently > to be 100% using 'protocol ipv6' on ppp0 rather than sit1 did the trick. It's even simplier ! I don't have to create filters for each ipv6 tunnel. Considering the ipv4 over udp tun0 tunnel, i guess i should prevent those udp packets to be matched by the filter on ppp0. I'll optimize it later. Cheers -- From hari@in.ibm.com Tue Apr 20 23:02:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 23:02:23 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L62HKO020104 for ; Tue, 20 Apr 2004 23:02:17 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3L62667733458; Wed, 21 Apr 2004 02:02:07 -0400 Received: from hari.in.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3L61i6k069896; Wed, 21 Apr 2004 02:01:58 -0400 Received: by hari.in.ibm.com (Postfix, from userid 500) id 8362C37EF5; Wed, 21 Apr 2004 11:30:21 +0530 (IST) Date: Wed, 21 Apr 2004 11:30:21 +0530 From: Hariprasad Nellitheertha To: Matt Mackall Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org, mingo@elte.hu, suparna@in.ibm.com Subject: Re: Problem with Netpoll based netdumping and NAPI Message-ID: <20040421060021.GB3716@in.ibm.com> Reply-To: hari@in.ibm.com References: <20040419125148.GA4495@in.ibm.com> <20040419174254.GQ1175@waste.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040419174254.GQ1175@waste.org> User-Agent: Mutt/1.4.1i X-archive-position: 4803 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hari@in.ibm.com Precedence: bulk X-list: netdev Content-Length: 1982 Lines: 52 Hi Matt, On Mon, Apr 19, 2004 at 12:42:54PM -0500, Matt Mackall wrote: > [changed cc: from linux-net to netdev] > > On Mon, Apr 19, 2004 at 06:21:48PM +0530, Hariprasad Nellitheertha wrote: > > Hi All, > > > > I am facing a problem while trying to network dump using LKCD. My > > debugging so far indicates that this is due to both NAPI and NETPOLL > > being enabled. > > > > I am using LKCD on the 2.6.5 kernel and both the client and server are > > i386 boxes. The dumping machine has an e100 card. I have built the kernel > > with both CONFIG_E100_NAPI and CONFIG_NET_POLL_CONTROLLER (and the other > > netpoll related options) selected. > > > > LKCD uses netpoll for its network dump implementation. The problem we see > > is that the network dump driver does not receive any packet from the > > card driver and hence dumping fails. In e100_intr(), we call > > netif_rx_schedule() if we are using the NAPI feature. netif_rx_schedule, > > in turn, ends up adding the processing of this packet to the NET_RX_SOFTIRQ > > softirq. > > Netpoll should be manually calling the NAPI poll function like this > after calling the interrupt handler (in netpoll_poll()): > > /* If scheduling is stopped, tickle NAPI bits */ > if(trapped && np->dev->poll && > test_bit(__LINK_STATE_RX_SCHED, &np->dev->state)) > np->dev->poll(np->dev, &budget); > > Please ensure that LKCD is calling netpoll_set_trap(1) which tells it > that packet scheduling is stopped. This was indeed the problem. We were not calling netpoll_set_trap in LKCD. Adding this fixed the problem. Thanks so much for your help with this. Regards, Hari > > I've tested this path primarily with tg3 and kgdb-over-ethernet, but > it should be functionally quite similar to e100 and lkcd. > > -- > Matt Mackall : http://www.selenic.com : Linux development and consulting -- Hariprasad Nellitheertha Linux Technology Center India Software Labs IBM India, Bangalore From hibi665@oki.com Tue Apr 20 23:08:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 20 Apr 2004 23:08:36 -0700 (PDT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L68WKO020527 for ; Tue, 20 Apr 2004 23:08:33 -0700 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id PAA24587 for ; Wed, 21 Apr 2004 15:08:31 +0900 Received: (qmail 2493 invoked from network); 21 Apr 2004 15:08:30 +0900 Received: from vacant23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 21 Apr 2004 15:08:30 +0900 Message-Id: <20040421150832.1f1dcde9%hibi665@oki.com> MIME-Version: 1.0 Date: Wed, 21 Apr 2004 15:08:32 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: netdev@oss.sgi.com Subject: ping6 error X-archive-position: 4804 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Content-Length: 390 Lines: 16 Hi all, There are IPv6 addresses for which ping6 doesn't work. The host has a global IPv6 address. $ ping6 ff05::1 (site-local multicast address) connect: Cannot assign requested address $ ping6 fec0::1 (site-local address) connect: Cannot assign requested address Usagi kernel doesn't have this problem. Is this an expected behavior? And why this happens? Regards, Takashi Hibi From cranium2003@yahoo.com Wed Apr 21 01:01:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 01:01:29 -0700 (PDT) Received: from web41412.mail.yahoo.com (web41412.mail.yahoo.com [66.218.93.78]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L81OKO026820 for ; Wed, 21 Apr 2004 01:01:25 -0700 Message-ID: <20040421080119.10446.qmail@web41412.mail.yahoo.com> Received: from [203.199.141.99] by web41412.mail.yahoo.com via HTTP; Wed, 21 Apr 2004 01:01:19 PDT Date: Wed, 21 Apr 2004 01:01:19 -0700 (PDT) From: Parag Nemade Subject: adding own 8 byte header to ip packet To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4805 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 604 Lines: 21 hello, Actually i added my own 8 byte header using skb_push function in front of transport header in ip_build_and_send_pkt function in ip_output.c file before skb_push for IP header. same thing i did in ip_rcv function in ip_input.c to strip off headers. but when i boot that image and ping the effects in ping packet will not reflect and after some time i got kernel BUG at slab 1130! Is am i missimg some other modifications. regards, Parag __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From EAMONN.HAMILTON@saic.com Wed Apr 21 02:42:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 02:43:00 -0700 (PDT) Received: from cpmx.saic.com (cpmx.mail.saic.com [139.121.17.160]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L9gqKO031120 for ; Wed, 21 Apr 2004 02:42:52 -0700 Received: from cp-its-ieg01.mail.saic.com by cpmx.saic.com; Wed, 21 Apr 2004 02:42:43 -0700 Received: from cpmx.saic.com ([139.121.17.160]) by cp-its-ieg01.mail.saic.com (SAVSMTP 3.1.5.43) with SMTP id M2004042102424228888 ; Wed, 21 Apr 2004 02:42:42 -0700 Received: from ukabzc383.uk.saic.com by cpmx.saic.com with ESMTP; Wed, 21 Apr 2004 02:42:43 -0700 Received: from localhost (localhost [127.0.0.1]) by ukabzc383.uk.saic.com (Postfix) with ESMTP id A1DDB2B069; Wed, 21 Apr 2004 10:42:41 +0100 (BST) Subject: Re: e100 NETDEV WATCHDOG transmit timeout since 2.6.4 From: Eamonn Hamilton To: Scott Feldman Cc: Mike Keehan , linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1082540561.3159.1.camel@ukabzc383.uk.saic.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Apr 2004 10:42:41 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 4806 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: EAMONN.HAMILTON@saic.com Precedence: bulk X-list: netdev Content-Length: 2786 Lines: 94 Hi Scott, Thanks for the patch - a bit of manual fumbling to get it applied, but it seems to work ok so far ( ~46 minutes, so it's not exactly definitive :) Certainly it doesn't make things worse in my case at least. Cheers, Eamonn On Wed, 2004-04-21 at 00:04, Scott Feldman wrote: > On Tue, 20 Apr 2004, Mike Keehan wrote: > > > I am getting these too in recent kernels, but only on a > > 10Mhz half-duplex network. I have to manually down > > and up the interface to recover. > > > > On a 100Mhz switched network, the e100 is OK (at least 12hours+). > > > Mike/Eamonn, > > Give this patch a try. This adds a required workaround for ICH when > working at 10/Half. (Guessing you have an ICH system). > > --- linux-2.5/drivers/net/e100.c 2004-04-20 15:52:24.000000000 -0700 > +++ linux-2.5/drivers/net/e100.c.mod 2004-04-20 15:55:32.000000000 -0700 > @@ -287,6 +287,7 @@ enum scb_cmd_hi { > }; > > enum scb_cmd_lo { > + cuc_nop = 0x00, > ruc_start = 0x01, > ruc_load_base = 0x06, > cuc_start = 0x10, > @@ -514,10 +515,11 @@ struct nic { > /* End: frequently used values: keep adjacent for cache effect */ > > enum { > - ich = (1 << 0), > - promiscuous = (1 << 1), > - multicast_all = (1 << 2), > - wol_magic = (1 << 3), > + ich = (1 << 0), > + promiscuous = (1 << 1), > + multicast_all = (1 << 2), > + wol_magic = (1 << 3), > + ich_10h_workaround = (1 << 4), > } flags ____cacheline_aligned; > > enum mac mac; > @@ -1225,6 +1227,12 @@ static void e100_watchdog(unsigned long > /* Issue a multicast command to workaround a 557 lock up */ > e100_set_multicast_list(nic->netdev); > > + if(nic->flags & ich && cmd.speed==SPEED_10 && cmd.duplex==DUPLEX_HALF) > + /* Need SW workaround for ICH[x] 10Mbps/half duplex Tx hang. */ > + nic->flags |= ich_10h_workaround; > + else > + nic->flags &= ~ich_10h_workaround; > + > mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD); > } > > @@ -1244,7 +1252,17 @@ static inline void e100_xmit_prepare(str > static int e100_xmit_frame(struct sk_buff *skb, struct net_device *netdev) > { > struct nic *nic = netdev->priv; > - int err = e100_exec_cb(nic, skb, e100_xmit_prepare); > + int err; > + > + if(nic->flags & ich_10h_workaround) { > + /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang. > + Issue a NOP command followed by a 1us delay before > + issuing the Tx command. */ > + e100_exec_cmd(nic, cuc_nop, 0); > + udelay(1); > + } > + > + err = e100_exec_cb(nic, skb, e100_xmit_prepare); > > switch(err) { > case -ENOSPC: -- Eamonn Hamilton Senior Technical Designer Technical Projects and Design (North) Tel : +44 (0) 1224 333833 Fax : +44 (0) 1224 840032 Email eamonn.hamilton@saic.com From syrius.ml@no-log.org Wed Apr 21 05:50:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 05:50:20 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LCoFKO005559 for ; Wed, 21 Apr 2004 05:50:16 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id D563C36A20; Wed, 21 Apr 2004 14:50:09 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id A427636A2C; Wed, 21 Apr 2004 14:50:08 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 5F519F9; Wed, 21 Apr 2004 14:49:26 +0200 (CEST) To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <1082427350.1034.70.camel@jzny.localdomain> From: syrius.ml@no-log.org Date: Wed, 21 Apr 2004 14:49:26 +0200 In-Reply-To: (syrius ml's message of "Wed, 21 Apr 2004 03:43:13 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4807 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 1502 Lines: 35 skput:under: c88c93aa:98 put:14 dev:tun0kernel BUG at skbuff.c:113! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010286 eax: 00000028 ebx: c46afe60 ecx: 00000000 edx: c6a5e000 esi: c88c6780 edi: 00000001 ebp: c5573d78 esp: c5573d64 ds: 0018 es: 0018 ss: 0018 Process openvpn (pid: 940, stackpage=c5573000) Stack: c022a180 c88c93aa 00000062 0000000e c5db4824 c5573da8 c88c93b2 c582e3a0 0000000e c88c93aa 42924e9d c58eccc0 c582ebe0 c582e3a0 c57dae00 c582ebe0 c5f17f20 c5573dbc c01cd277 c5573dc4 c57dae00 c5573e60 c5573e28 c890f104 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 71 00 0a 92 22 c0 89 ec 5d c3 8d 74 26 00 8d bc 27 00 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing I'm going to recompile the kernel with frame pointers, and i'll feed the oops thru ksymoops. First I have to narrow the problem so I can tell how to reproduce it, and I'll give more informations. -- From mike_keehan@yahoo.com Wed Apr 21 06:20:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 06:20:23 -0700 (PDT) Received: from web12305.mail.yahoo.com (web12305.mail.yahoo.com [216.136.173.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LDKHKO006495 for ; Wed, 21 Apr 2004 06:20:18 -0700 Message-ID: <20040421132017.68243.qmail@web12305.mail.yahoo.com> Received: from [194.247.49.10] by web12305.mail.yahoo.com via HTTP; Wed, 21 Apr 2004 06:20:17 PDT Date: Wed, 21 Apr 2004 06:20:17 -0700 (PDT) From: Mike Keehan Subject: Re: e100 NETDEV WATCHDOG transmit timeout since 2.6.4 To: Scott Feldman Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4808 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mike_keehan@yahoo.com Precedence: bulk X-list: netdev Content-Length: 2972 Lines: 105 HI Scott, That's a lot better. I've been running OK for about four hours on the half duplex network. The only time that the wathcdog timed out was when I was using KDE's Konqueror to look at files on a SMB mounted directory (from an NT 4 system). Previously the network connection would fail within minutes when using ssh or ftp to another Linux box. Now, they have worked consistently for hours. Cheers, Mike. --- Scott Feldman wrote: > > > On Tue, 20 Apr 2004, Mike Keehan wrote: > > > I am getting these too in recent kernels, but only on a > > 10Mhz half-duplex network. I have to manually down > > and up the interface to recover. > > > > On a 100Mhz switched network, the e100 is OK (at least 12hours+). > > > Mike/Eamonn, > > Give this patch a try. This adds a required workaround for ICH when > working at 10/Half. (Guessing you have an ICH system). > > --- linux-2.5/drivers/net/e100.c 2004-04-20 15:52:24.000000000 -0700 > +++ linux-2.5/drivers/net/e100.c.mod 2004-04-20 15:55:32.000000000 > -0700 > @@ -287,6 +287,7 @@ enum scb_cmd_hi { > }; > > enum scb_cmd_lo { > + cuc_nop = 0x00, > ruc_start = 0x01, > ruc_load_base = 0x06, > cuc_start = 0x10, > @@ -514,10 +515,11 @@ struct nic { > /* End: frequently used values: keep adjacent for cache effect */ > > enum { > - ich = (1 << 0), > - promiscuous = (1 << 1), > - multicast_all = (1 << 2), > - wol_magic = (1 << 3), > + ich = (1 << 0), > + promiscuous = (1 << 1), > + multicast_all = (1 << 2), > + wol_magic = (1 << 3), > + ich_10h_workaround = (1 << 4), > } flags ____cacheline_aligned; > > enum mac mac; > @@ -1225,6 +1227,12 @@ static void e100_watchdog(unsigned long > /* Issue a multicast command to workaround a 557 lock up */ > e100_set_multicast_list(nic->netdev); > > + if(nic->flags & ich && cmd.speed==SPEED_10 && > cmd.duplex==DUPLEX_HALF) > + /* Need SW workaround for ICH[x] 10Mbps/half duplex Tx hang. */ > + nic->flags |= ich_10h_workaround; > + else > + nic->flags &= ~ich_10h_workaround; > + > mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD); > } > > @@ -1244,7 +1252,17 @@ static inline void e100_xmit_prepare(str > static int e100_xmit_frame(struct sk_buff *skb, struct net_device > *netdev) > { > struct nic *nic = netdev->priv; > - int err = e100_exec_cb(nic, skb, e100_xmit_prepare); > + int err; > + > + if(nic->flags & ich_10h_workaround) { > + /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang. > + Issue a NOP command followed by a 1us delay before > + issuing the Tx command. */ > + e100_exec_cmd(nic, cuc_nop, 0); > + udelay(1); > + } > + > + err = e100_exec_cb(nic, skb, e100_xmit_prepare); > > switch(err) { > case -ENOSPC: > __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From cfriesen@nortelnetworks.com Wed Apr 21 08:25:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 08:25:42 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LFPaKO014057 for ; Wed, 21 Apr 2004 08:25:36 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3LFPSV06812; Wed, 21 Apr 2004 11:25:28 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT827K9; Wed, 21 Apr 2004 11:25:29 -0400 Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC47F08B; Wed, 21 Apr 2004 11:25:29 -0400 Message-ID: <40869267.30408@nortelnetworks.com> Date: Wed, 21 Apr 2004 11:25:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: tcp vulnerability? haven't seen anything on it here... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4809 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 308 Lines: 12 There has been some discussion about this on the Debian and OpenBSD lists, but I haven't seen anything on it here. I know my boss is going to hear about this and want more information, so where does Linux stand with regards to this? http://www.uniras.gov.uk/vuls/2004/236929/index.htm Thanks, Chris From root@chaos.analogic.com Wed Apr 21 09:10:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 09:10:19 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LGACKO015587 for ; Wed, 21 Apr 2004 09:10:12 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i3LG2MR01192; Wed, 21 Apr 2004 12:02:22 -0400 Date: Wed, 21 Apr 2004 12:02:22 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Chris Friesen cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <40869267.30408@nortelnetworks.com> Message-ID: References: <40869267.30408@nortelnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4810 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 1101 Lines: 32 On Wed, 21 Apr 2004, Chris Friesen wrote: > > There has been some discussion about this on the Debian and OpenBSD > lists, but I haven't seen anything on it here. I know my boss is going > to hear about this and want more information, so where does Linux stand > with regards to this? > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > Thanks, > > Chris The vulnerabilities were discussed on US news reports as being like somebody discovered they could disconnect your electricity if they had some wire-cutters. Those guys in the UK just don't have anything else to do! It seems that they discovered that if you tap-into some network physical media you could disrupt it! Since it has been taking so long for IP/V6 to take hold, those proponents claim that it will be a solution. Me-thinks it's a solution waiting for a problem. The IP/V6 folks want to force (using government and industry FUD) to discontinue IP/V4 as a "security risk!!!" Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). Note 96.31% of all statistics are fiction. From cfriesen@nortelnetworks.com Wed Apr 21 09:26:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 09:26:16 -0700 (PDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LGQAKO016238 for ; Wed, 21 Apr 2004 09:26:10 -0700 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3LGPSV19512; Wed, 21 Apr 2004 12:25:28 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCWP9DZ3; Wed, 21 Apr 2004 12:25:28 -0400 Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC47GACG; Wed, 21 Apr 2004 12:25:28 -0400 Message-ID: <4086A077.2000705@nortelnetworks.com> Date: Wed, 21 Apr 2004 12:25:27 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: root@chaos.analogic.com CC: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: tcp vulnerability? haven't seen anything on it here... References: <40869267.30408@nortelnetworks.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4811 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 574 Lines: 15 Richard B. Johnson wrote: > The vulnerabilities were discussed on US news reports as being > like somebody discovered they could disconnect your electricity > if they had some wire-cutters. > > Those guys in the UK just don't have anything else to do! It > seems that they discovered that if you tap-into some network > physical media you could disrupt it! The impression I got was that some equipment was much more vulnerable due to having a) massive windows, and b) using sequential source ports, making it much easier to guess even if you can't tap the line. Chris From joern@wohnheim.fh-wedel.de Wed Apr 21 10:04:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 10:04:55 -0700 (PDT) Received: from mail.fh-wedel.de (mail.fh-wedel.de [213.39.232.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LH4oKO017878 for ; Wed, 21 Apr 2004 10:04:51 -0700 Received: from wohnheim.fh-wedel.de (wohnheim.fh-wedel.de [213.39.233.138]) by mail.fh-wedel.de (8.12.9/8.12.9/Debian-1) with ESMTP id i3LH3bmh000646; Wed, 21 Apr 2004 19:03:37 +0200 Received: from joern by wohnheim.fh-wedel.de with local (Exim 3.35 #1 (Debian)) id 1BGL8O-0002Vf-00; Wed, 21 Apr 2004 19:03:40 +0200 Date: Wed, 21 Apr 2004 19:03:40 +0200 From: =?iso-8859-1?Q?J=F6rn?= Engel To: Chris Friesen Cc: netdev@oss.sgi.com, Linux Kernel Mailing List Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-ID: <20040421170340.GB24201@wohnheim.fh-wedel.de> References: <40869267.30408@nortelnetworks.com> <4086A077.2000705@nortelnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4086A077.2000705@nortelnetworks.com> User-Agent: Mutt/1.3.28i X-MIME-Autoconverted: from 8bit to quoted-printable by mail.fh-wedel.de id i3LH3bmh000646 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3LH4oKO017878 X-archive-position: 4812 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joern@wohnheim.fh-wedel.de Precedence: bulk X-list: netdev Content-Length: 851 Lines: 23 On Wed, 21 April 2004 12:25:27 -0400, Chris Friesen wrote: > > The impression I got was that some equipment was much more vulnerable > due to having a) massive windows, and b) using sequential source ports, > making it much easier to guess even if you can't tap the line. Heise.de made it appear, as if the only news was that with tcp windows, the propability of guessing the right sequence number is not 1:2^32 but something smaller. They said that 64k packets would be enough, so guess what the window will be. Obvious solution would be to use a small window, which would cost performance. Different solution would be to use a different window size for reset, like, say, 1. Not sure if that would still be standard, though. Jörn -- The cost of changing business rules is much more expensive for software than for a secretaty. -- unknown From bfields@fieldses.org Wed Apr 21 10:45:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 10:45:34 -0700 (PDT) Received: from pumpkin.fieldses.org (Debian-exim@dsl093-002-214.det1.dsl.speakeasy.net [66.93.2.214]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LHjUKO019013 for ; Wed, 21 Apr 2004 10:45:30 -0700 Received: from bfields by pumpkin.fieldses.org with local (Exim 4.32) id 1BGLmo-00024z-08; Wed, 21 Apr 2004 13:45:26 -0400 Date: Wed, 21 Apr 2004 13:45:25 -0400 To: Dave Jones , Linux Kernel , netdev@oss.sgi.com Cc: Trond Myklebust , Neil Brown Subject: Re: 2.6.4 sunrpc oops. Message-ID: <20040421174525.GA7859@fieldses.org> References: <20040315194642.GB19555@redhat.com> <20040315203853.GF3114@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040315203853.GF3114@fieldses.org> User-Agent: Mutt/1.5.5.1+cvs20040105i From: "J. Bruce Fields" X-archive-position: 4813 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: bfields@fieldses.org Precedence: bulk X-list: netdev Content-Length: 2232 Lines: 63 On Mon, Mar 15, 2004 at 03:38:53PM -0500, J. Bruce Fields wrote: > On Mon, Mar 15, 2004 at 07:46:42PM +0000, Dave Jones wrote: > > modprobe auth_rpcgss > > rmmod auth_rpcgss > > rmmod sunrpc > > *bang* > > > > Seems to survive rmmod sunrpc usually, so it's the auth_rpcgcc > > module leaving something around long after its dead perhaps? > > Yes, this is my fault, apologies. I'll follow up with a patch as soon > as I've made one....--Bruce Fields Ugh, sorry for the delay. --b. Unregister svcauth_gss caches on exit from gss module; fixes an oops on rmmod. include/linux/sunrpc/svcauth_gss.h | 1 + net/sunrpc/auth_gss/auth_gss.c | 1 + net/sunrpc/auth_gss/svcauth_gss.c | 7 +++++++ 3 files changed, 9 insertions(+) diff -puN include/linux/sunrpc/svcauth_gss.h~nfsd_gss_rmmod_fix include/linux/sunrpc/svcauth_gss.h --- linux-2.6.6-rc1/include/linux/sunrpc/svcauth_gss.h~nfsd_gss_rmmod_fix 2004-04-21 13:42:56.000000000 -0400 +++ linux-2.6.6-rc1-bfields/include/linux/sunrpc/svcauth_gss.h 2004-04-21 13:42:56.000000000 -0400 @@ -20,6 +20,7 @@ #include int gss_svc_init(void); +void gss_svc_shutdown(void); int svcauth_gss_register_pseudoflavor(u32 pseudoflavor, char * name); #endif /* __KERNEL__ */ diff -puN net/sunrpc/auth_gss/auth_gss.c~nfsd_gss_rmmod_fix net/sunrpc/auth_gss/auth_gss.c --- linux-2.6.6-rc1/net/sunrpc/auth_gss/auth_gss.c~nfsd_gss_rmmod_fix 2004-04-21 13:42:56.000000000 -0400 +++ linux-2.6.6-rc1-bfields/net/sunrpc/auth_gss/auth_gss.c 2004-04-21 13:42:56.000000000 -0400 @@ -998,6 +998,7 @@ out: static void __exit exit_rpcsec_gss(void) { + gss_svc_shutdown(); gss_mech_unregister_all(); rpcauth_unregister(&authgss_ops); } diff -puN net/sunrpc/auth_gss/svcauth_gss.c~nfsd_gss_rmmod_fix net/sunrpc/auth_gss/svcauth_gss.c --- linux-2.6.6-rc1/net/sunrpc/auth_gss/svcauth_gss.c~nfsd_gss_rmmod_fix 2004-04-21 13:42:56.000000000 -0400 +++ linux-2.6.6-rc1-bfields/net/sunrpc/auth_gss/svcauth_gss.c 2004-04-21 13:42:56.000000000 -0400 @@ -1086,3 +1086,10 @@ gss_svc_init(void) svc_auth_register(RPC_AUTH_GSS, &svcauthops_gss); return 0; } + +void +gss_svc_shutdown(void) +{ + cache_unregister(&rsc_cache); + cache_unregister(&rsi_cache); +} _ From shemminger@osdl.org Wed Apr 21 11:11:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 11:11:04 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LIAxKO020082 for ; Wed, 21 Apr 2004 11:10:59 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3LIAl230780; Wed, 21 Apr 2004 11:10:47 -0700 Date: Wed, 21 Apr 2004 11:10:46 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] add sysctl to turn off caching metrics Message-Id: <20040421111046.34bf3e73@dell_ss3.pdx.osdl.net> In-Reply-To: <20040420155738.4146b5bb.davem@redhat.com> References: <20040420155738.4146b5bb.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4815 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: 2225 Lines: 76 When running benchmarks and other experiments, it is often useful not to save the route metrics (cwnd, rtt) from each connection. Here is a simple way to do it with sysctl. Not a new idea, it is part of the web100 stuff as well. Patch against 2.6.6-rc2 diff -Nru a/include/linux/sysctl.h b/include/linux/sysctl.h --- a/include/linux/sysctl.h Wed Apr 21 10:39:28 2004 +++ b/include/linux/sysctl.h Wed Apr 21 10:39:28 2004 @@ -326,6 +326,7 @@ NET_IPV4_IPFRAG_SECRET_INTERVAL=94, NET_TCP_WESTWOOD=95, NET_IPV4_IGMP_MAX_MSF=96, + NET_TCP_NO_METRICS_SAVE=97, }; enum { diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h Wed Apr 21 10:39:28 2004 +++ b/include/net/tcp.h Wed Apr 21 10:39:28 2004 @@ -583,6 +583,7 @@ extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; extern int sysctl_tcp_westwood; +extern int sysctl_tcp_nometrics_save; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; diff -Nru a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c --- a/net/ipv4/sysctl_net_ipv4.c Wed Apr 21 10:39:28 2004 +++ b/net/ipv4/sysctl_net_ipv4.c Wed Apr 21 10:39:28 2004 @@ -594,6 +594,14 @@ .strategy = &sysctl_jiffies }, { + .ctl_name = NET_TCP_NO_METRICS_SAVE, + .procname = "tcp_no_metrics_save", + .data = &sysctl_tcp_nometrics_save, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, + { .ctl_name = NET_TCP_WESTWOOD, .procname = "tcp_westwood", .data = &sysctl_tcp_westwood, @@ -601,6 +609,7 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { .ctl_name = 0 } }; diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c Wed Apr 21 10:39:28 2004 +++ b/net/ipv4/tcp_input.c Wed Apr 21 10:39:28 2004 @@ -87,6 +87,7 @@ int sysctl_tcp_max_orphans = NR_FILE; int sysctl_tcp_frto; int sysctl_tcp_westwood; +int sysctl_tcp_nometrics_save; #define FLAG_DATA 0x01 /* Incoming frame contained data. */ #define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */ @@ -517,6 +518,9 @@ { struct tcp_opt *tp = tcp_sk(sk); struct dst_entry *dst = __sk_dst_get(sk); + + if (sysctl_tcp_nometrics_save) + return; dst_confirm(dst); From shemminger@osdl.org Wed Apr 21 11:10:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 11:10:49 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LIAiKO020058 for ; Wed, 21 Apr 2004 11:10:45 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3LIAW230702; Wed, 21 Apr 2004 11:10:32 -0700 Date: Wed, 21 Apr 2004 11:10:32 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] rearrange frto field to save space. Message-Id: <20040421111032.0705b605@dell_ss3.pdx.osdl.net> In-Reply-To: <20040420155738.4146b5bb.davem@redhat.com> References: <20040420155738.4146b5bb.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4814 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: 1054 Lines: 27 Since the frto_counter field only goes from 0 to 4, it can be moved into a unused byte size hole to save space. diff -Nru a/include/linux/tcp.h b/include/linux/tcp.h --- a/include/linux/tcp.h Wed Apr 21 10:39:07 2004 +++ b/include/linux/tcp.h Wed Apr 21 10:39:07 2004 @@ -255,6 +255,10 @@ __u8 retransmits; /* Number of unrecovered RTO timeouts. */ __u8 reordering; /* Packet reordering metric. */ + __u8 frto_counter; /* Number of new acks after RTO */ + __u32 frto_highmark; /* snd_nxt when RTO occurred */ + + __u8 unused_pad; __u8 queue_shrunk; /* Write queue has been shrunk recently.*/ __u8 defer_accept; /* User waits for some data after accept() */ @@ -369,9 +373,6 @@ unsigned int keepalive_time; /* time before keep alive takes place */ unsigned int keepalive_intvl; /* time interval between keep alive probes */ int linger2; - - int frto_counter; /* Number of new acks after RTO */ - __u32 frto_highmark; /* snd_nxt when RTO occurred */ unsigned long last_synq_overflow; From jgarzik@pobox.com Wed Apr 21 11:15:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 11:15:15 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LIF9KO020756 for ; Wed, 21 Apr 2004 11:15:10 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BGMFV-0003xu-4N; Wed, 21 Apr 2004 19:15:05 +0100 Message-ID: <4086BA1A.5010900@pobox.com> Date: Wed, 21 Apr 2004 14:14:50 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 0/8] 2.4.26-bk1 pcnet32.c References: <200404202012.i3KKC9C13567@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404202012.i3KKC9C13567@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4816 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: 34 Lines: 2 i seem to be missing patch #2/8. From brazilnut@us.ibm.com Wed Apr 21 11:24:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 11:24:47 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LIOgKO021338 for ; Wed, 21 Apr 2004 11:24:42 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3LIO387041658; Wed, 21 Apr 2004 14:24:03 -0400 Received: from DYN318364BLD.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3LINu0p131998; Wed, 21 Apr 2004 12:23:56 -0600 Received: (from donf@localhost) by DYN318364BLD.beaverton.ibm.com (8.11.6/8.11.6) id i3LILoQ02135; Wed, 21 Apr 2004 11:21:50 -0700 From: Don Fry Message-Id: <200404211821.i3LILoQ02135@DYN318364BLD.beaverton.ibm.com> Subject: re-send [PATCH 2/8 2.4.26-bk1] pcnet32 add 79C976 support To: tsbogend@alpha.franken.de, jgarzik@pobox.com, netdev@oss.sgi.com Date: Wed, 21 Apr 2004 11:21:50 -0700 (PDT) X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4817 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: brazilnut@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 545 Lines: 20 Please include this patch to add support for the 79C976 device to the pcnet32 driver. Tested ia32. --- linux-2.6.5/drivers/net/orig.pcnet32.c Sat Apr 3 19:36:53 2004 +++ linux-2.6.5/drivers/net/pcnet32.c Mon Apr 5 11:40:57 2004 @@ -909,6 +909,10 @@ chipname = "PCnet/FAST III 79C975"; /* PCI */ fdx = 1; mii = 1; break; + case 0x2628: + chipname = "PCnet/FAST III 79C976"; + fdx = 1; mii = 1; + break; default: printk(KERN_INFO PFX "PCnet version %#x, no PCnet32 chip.\n", chip_version); -- Don Fry brazilnut@us.ibm.com From syrius.ml@no-log.org Wed Apr 21 13:20:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 13:20:33 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LKKRKO027840 for ; Wed, 21 Apr 2004 13:20:28 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id 1B4033486B; Wed, 21 Apr 2004 22:20:22 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id C26AA35457; Wed, 21 Apr 2004 22:20:19 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 6D2F110F; Wed, 21 Apr 2004 22:19:45 +0200 (CEST) To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <1082427350.1034.70.camel@jzny.localdomain> From: syrius.ml@no-log.org Date: Wed, 21 Apr 2004 22:19:45 +0200 In-Reply-To: (syrius ml's message of "Wed, 21 Apr 2004 14:49:26 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 4818 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 6126 Lines: 185 --=-=-= ok, i'm able to reproduce it with a simpler setup. Let's consider I'm using the new dummy device on machine connected to a ethernet lan. this host is using openvpn to establish a vpn tunnel. debian:~# ip a l dev eth0 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:25:4a:b6 brd ff:ff:ff:ff:ff:ff inet 192.168.5.4/24 brd 192.168.5.255 scope global eth0 debian:~# ip a l dev tun0 4: tun0: mtu 1447 qdisc pfifo_fast qlen 10 link/ppp inet 172.16.0.2 peer 172.16.0.1/32 scope global tun0 I attach the script i'm using to setup a simple new dummy+htb setup. it's very simple, I do not use iptables to mark packets, i do not use filter with htb, everything goes to the default classes (1:20 & 2:20) I can verify it's working as expected with a simple ping -f 192.168.5.1 (or a ping -f 192.168.5.4 from 192.168.5.1) after the ping -f 192.168.5.1 (let's say i let it run 30sec), if a do ping 172.16.0.1 the oops appears ! I attach the result of ksymoops. Please tell me if you're able to reproduce it. I'm ok to try with another vpn software, but I don't think it has anything to do with openvpn. --=-=-= Content-Type: text/x-sh Content-Disposition: inline; filename=tc.sh Content-Description: qos script #!/bin/sh TC=/usr/local/iproute2/sbin/tc IP=/usr/local/iproute2/sbin/ip OUT=dummy0 IN=dummy1 tc qdisc ls | sed -e 's/^.*dev \([a-zA-Z0-9]\+\) .*$/\1/' | sort -u | \ while read a; do tc qdisc del dev $a root &>/dev/null tc qdisc del dev $a ingress &>/dev/null done ifconfig $IN down &> /dev/null ifconfig $OUT down &> /dev/null if [ "$1" = "stop" ] then exit fi ###### uplink # ROOT $TC qdisc add dev $OUT root handle 1: htb default 20 # CLASSES $TC class add dev $OUT parent 1: classid 1:1 htb rate 200kbit ceil 200kbit prio 0 $TC class add dev $OUT parent 1:1 classid 1:10 htb rate 100kbit ceil 200kbit prio 1 $TC class add dev $OUT parent 1:1 classid 1:20 htb rate 100kbit ceil 100kbit prio 2 $IP link set $OUT up $TC qdisc add dev eth0 root handle 1: prio $TC filter add dev eth0 parent 1:0 protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev $OUT $TC qdisc add dev tun0 root handle 1: prio $TC filter add dev tun0 parent 1:0 protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev $OUT modprobe dummy ###### downlink $TC qdisc add dev $IN root handle 2: htb default 20 # CLASSES $TC class add dev $IN parent 2: classid 2:1 htb rate 100kbit ceil 200kbit prio 0 $TC class add dev $IN parent 2:1 classid 2:10 htb rate 100kbit ceil 200kbit prio 1 $TC class add dev $IN parent 2:1 classid 2:20 htb rate 100kbit ceil 100kbit prio 3 $IP link set $IN up $TC qdisc add dev eth0 ingress $TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev $IN $TC qdisc add dev tun0 ingress $TC filter add dev tun0 parent ffff: protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev $IN --=-=-= Content-Disposition: inline; filename=ksymsoops.txt Content-Description: ksymoops result ksymoops 2.4.9 on i686 2.4.25. Options used -v /mnt/vmlinux (specified) -k /mnt/ksyms (specified) -l /mnt/modules (specified) -o /lib/modules/2.4.25 (specified) -m /mnt/System.map (specified) skput:under: c88863d8:126 put:14 dev:tun0kernel BUG at skbuff.c:113! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00000282 eax: 00000029 ebx: c639ff40 ecx: c6434000 edx: c6777f7c esi: c8888780 edi: 00000001 ebp: c6435db4 esp: c6435da0 ds: 0018 es: 0018 ss: 0018 Process openvpn (pid: 415, stackpage=c6435000) Stack: c025e0a0 c88863d8 0000007e 0000000e c6706224 c6435de4 c88863e4 c67c0480 0000000e c88863d8 c1167420 c61eae00 c67c0540 c67c0480 c5ce8dc0 00000000 c6424880 c6435df8 c01f294d c6435e00 c5ce8dc0 c67c0540 c6435e64 c888311a Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 71 00 27 d1 25 c0 c9 c3 8d 74 26 00 8d bc 27 00 00 00 >>EIP; c01e088b <===== >>ebx; c639ff40 <_end+609c4e0/84fc620> >>ecx; c6434000 <_end+61305a0/84fc620> >>edx; c6777f7c <_end+647451c/84fc620> >>esi; c8888780 <[dummy]__module_license+a8/19a8> >>ebp; c6435db4 <_end+6132354/84fc620> >>esp; c6435da0 <_end+6132340/84fc620> Trace; c88863d8 <[mirred]tcf_mirred+168/1d0> Trace; c88863e4 <[mirred]tcf_mirred+174/1d0> Trace; c88863d8 <[mirred]tcf_mirred+168/1d0> Trace; c01f294d Trace; c888311a <[cls_u32]u32_classify+9a/1d0> Trace; c021f17d Trace; c888a462 <[sch_ingress]tc_classify+52/cf> Trace; c888a12b <[sch_ingress]ingress_enqueue+2b/80> Trace; c01e5108 Trace; c01e520f Trace; c01e54a9 Trace; c01e55aa Trace; c011a854 Trace; c8843c9f <[tun]tun_get_user+df/165> Trace; c8843353 <[tun]tun_chr_write+33/40> Trace; c013642b Trace; c01071bb Code; c01e088b 00000000 <_EIP>: Code; c01e088b <===== 0: 0f 0b ud2a <===== Code; c01e088d 2: 71 00 jno 4 <_EIP+0x4> Code; c01e088f 4: 27 daa Code; c01e0890 5: d1 25 c0 c9 c3 8d shll 0x8dc3c9c0 Code; c01e0896 b: 74 26 je 33 <_EIP+0x33> Code; c01e0898 d: 00 8d bc 27 00 00 add %cl,0x27bc(%ebp) <0>Kernel panic: Aiee, killing interrupt handler! --=-=-= -- --=-=-=-- From davem@redhat.com Wed Apr 21 13:27:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 13:27:07 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LKR0KO028450 for ; Wed, 21 Apr 2004 13:27:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3LKL1Fe031521; Wed, 21 Apr 2004 16:21:01 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3LKL0p24070; Wed, 21 Apr 2004 16:21:00 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3LKKY1n020478; Wed, 21 Apr 2004 16:20:34 -0400 Date: Wed, 21 Apr 2004 13:20:47 -0700 From: "David S. Miller" To: =?ISO-8859-1?Q?J=F6rn?= Engel Cc: cfriesen@nortelnetworks.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-Id: <20040421132047.026ab7f2.davem@redhat.com> In-Reply-To: <20040421170340.GB24201@wohnheim.fh-wedel.de> References: <40869267.30408@nortelnetworks.com> <4086A077.2000705@nortelnetworks.com> <20040421170340.GB24201@wohnheim.fh-wedel.de> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3LKR0KO028450 X-archive-position: 4819 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 876 Lines: 21 On Wed, 21 Apr 2004 19:03:40 +0200 Jörn Engel wrote: > Heise.de made it appear, as if the only news was that with tcp > windows, the propability of guessing the right sequence number is not > 1:2^32 but something smaller. They said that 64k packets would be > enough, so guess what the window will be. Yes, that is their major discovery. You need to guess the ports and source/destination addresses as well, which is why I don't consider this such a serious issue personally. It is mitigated if timestamps are enabled, because that becomes another number you have to guess. It is mitigated also by randomized ephemeral port selection, which OpenBSD implements and we could easily implement as well. I'm very happy that OpenBSD checked in a fix for this a week or so ago and took some of the thunder out of this bogusly hyped announcement. From dlstevens@us.ibm.com Wed Apr 21 15:06:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 15:06:59 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LM6kKO032241; Wed, 21 Apr 2004 15:06:53 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3LM61pB608412; Wed, 21 Apr 2004 18:06:11 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3LM5m0r149704; Wed, 21 Apr 2004 16:05:59 -0600 In-Reply-To: <20040421150832.1f1dcde9%hibi665@oki.com> To: Takashi Hibi Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: ping6 error X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Wed, 21 Apr 2004 15:05:47 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/21/2004 16:05:59, Serialize complete at 04/21/2004 16:05:59 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4820 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 949 Lines: 25 Takashi Hibi wrote on 04/20/2004 11:08:32 PM: > There are IPv6 addresses for which ping6 doesn't work. > The host has a global IPv6 address. > $ ping6 ff05::1 (site-local multicast address) > connect: Cannot assign requested address This makes less sense (but doesn't fail for me on 2.6.x kernels). Multicast memberships are per-interface, so a multi-homed host or router may not have a route for that address to the interface you actually wanted. It's almost always best to specify "-I" in ping6 to get what you want. > $ ping6 fec0::1 (site-local address) > connect: Cannot assign requested address This works fine on my 2.6.1 system talking to my 2.6.5 system, when I have an address with an fec0 prefix on both. If you don't, it's probably a routing table issue-- try "netstat -A inet6 -rn" and see if you have routing table entries on each so that they can talk to each other. +-DLS From davem@redhat.com Wed Apr 21 16:46:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 16:46:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LNkaKO004986 for ; Wed, 21 Apr 2004 16:46:37 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3LNkXFe016524; Wed, 21 Apr 2004 19:46:33 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3LNkXp23452; Wed, 21 Apr 2004 19:46:33 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3LNk61n018746; Wed, 21 Apr 2004 19:46:07 -0400 Date: Wed, 21 Apr 2004 16:46:18 -0700 From: "David S. Miller" To: Chris Wright Cc: netdev@oss.sgi.com Subject: Re: [PATCH] fix return value on MCAST_MSFILTER error case Message-Id: <20040421164618.5ba064ea.davem@redhat.com> In-Reply-To: <20040420180551.I21045@build.pdx.osdl.net> References: <20040420180551.I21045@build.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4821 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 176 Lines: 8 On Tue, 20 Apr 2004 18:05:51 -0700 Chris Wright wrote: > Return -EINVAL if (GROUP_FILTER_SIZE(gsf->gf_numsrc) > optlen) Good catch, applied. Thanks Chris. From davem@redhat.com Wed Apr 21 16:59:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 16:59:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LNxKKO005492 for ; Wed, 21 Apr 2004 16:59:20 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3LNxHFe019697; Wed, 21 Apr 2004 19:59:17 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3LNxHp26689; Wed, 21 Apr 2004 19:59:17 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3LNwo1n023686; Wed, 21 Apr 2004 19:58:51 -0400 Date: Wed, 21 Apr 2004 16:59:02 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] rearrange frto field to save space. Message-Id: <20040421165902.549126f0.davem@redhat.com> In-Reply-To: <20040421111032.0705b605@dell_ss3.pdx.osdl.net> References: <20040420155738.4146b5bb.davem@redhat.com> <20040421111032.0705b605@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4822 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 213 Lines: 7 On Wed, 21 Apr 2004 11:10:32 -0700 Stephen Hemminger wrote: > Since the frto_counter field only goes from 0 to 4, it can be moved > into a unused byte size hole to save space. Ok. Applied. From davem@redhat.com Wed Apr 21 17:01:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 17:01:36 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M01WKO005821 for ; Wed, 21 Apr 2004 17:01:32 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3M01UFe020221; Wed, 21 Apr 2004 20:01:30 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3M01Up27178; Wed, 21 Apr 2004 20:01:30 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3M0131n024180; Wed, 21 Apr 2004 20:01:04 -0400 Date: Wed, 21 Apr 2004 17:01:15 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] add sysctl to turn off caching metrics Message-Id: <20040421170115.5c9017dd.davem@redhat.com> In-Reply-To: <20040421111046.34bf3e73@dell_ss3.pdx.osdl.net> References: <20040420155738.4146b5bb.davem@redhat.com> <20040421111046.34bf3e73@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4823 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 336 Lines: 9 On Wed, 21 Apr 2004 11:10:46 -0700 Stephen Hemminger wrote: > When running benchmarks and other experiments, it is often useful > not to save the route metrics (cwnd, rtt) from each connection. > Here is a simple way to do it with sysctl. Not a new idea, it is part > of the web100 stuff as well. This is fine. From joe@perches.com Wed Apr 21 17:14:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 17:15:02 -0700 (PDT) Received: from Perches.com (DSL022.LABridge.com [206.117.136.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M0EpKO006325 for ; Wed, 21 Apr 2004 17:14:51 -0700 Received: from [192.168.1.128] (local128.perches.com [192.168.1.128]) by Perches.com (8.9.3/8.9.3) with ESMTP id QAA27116; Wed, 21 Apr 2004 16:17:58 -0700 Subject: Re: [PATCH] rearrange frto field to save space. From: Joe Perches To: Stephen Hemminger Cc: David S Miller , netdev@oss.sgi.com In-Reply-To: <20040421111032.0705b605@dell_ss3.pdx.osdl.net> References: <20040420155738.4146b5bb.davem@redhat.com> <20040421111032.0705b605@dell_ss3.pdx.osdl.net> Content-Type: text/plain Message-Id: <1082592912.11328.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 21 Apr 2004 17:15:12 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 4824 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: joe@perches.com Precedence: bulk X-list: netdev Content-Length: 137 Lines: 5 On Wed, 2004-04-21 at 11:10, Stephen Hemminger wrote: > + __u8 unused_pad; There's no real reason that I can see to have padding here. From davem@redhat.com Wed Apr 21 17:38:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 17:38:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M0ceKO007051 for ; Wed, 21 Apr 2004 17:38:40 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3M0caFe029740; Wed, 21 Apr 2004 20:38:36 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3M0cap02369; Wed, 21 Apr 2004 20:38:36 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3M0c91n003364; Wed, 21 Apr 2004 20:38:10 -0400 Date: Wed, 21 Apr 2004 17:38:21 -0700 From: "David S. Miller" To: Joe Perches Cc: shemminger@osdl.org, netdev@oss.sgi.com Subject: Re: [PATCH] rearrange frto field to save space. Message-Id: <20040421173821.4ec5c5c6.davem@redhat.com> In-Reply-To: <1082592912.11328.0.camel@localhost.localdomain> References: <20040420155738.4146b5bb.davem@redhat.com> <20040421111032.0705b605@dell_ss3.pdx.osdl.net> <1082592912.11328.0.camel@localhost.localdomain> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4825 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 287 Lines: 10 On Wed, 21 Apr 2004 17:15:12 -0700 Joe Perches wrote: > On Wed, 2004-04-21 at 11:10, Stephen Hemminger wrote: > > + __u8 unused_pad; > > There's no real reason that I can see to have padding here. SO that the next person adding member to this struct know it exists. From jmorris@redhat.com Wed Apr 21 17:51:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 17:51:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M0pUKO007899 for ; Wed, 21 Apr 2004 17:51:31 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3M0jhFe031627; Wed, 21 Apr 2004 20:45:43 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3M0jgp04071; Wed, 21 Apr 2004 20:45:42 -0400 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i3M0jgex016032; Wed, 21 Apr 2004 20:45:42 -0400 Date: Wed, 21 Apr 2004 20:45:42 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: "David S. Miller" cc: =?ISO-8859-1?Q?J=F6rn?= Engel , , , Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <20040421132047.026ab7f2.davem@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mx1.redhat.com id i3M0jhFe031627 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3M0pUKO007899 X-archive-position: 4826 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmorris@redhat.com Precedence: bulk X-list: netdev Content-Length: 1043 Lines: 33 On Wed, 21 Apr 2004, David S. Miller wrote: > On Wed, 21 Apr 2004 19:03:40 +0200 > Jörn Engel wrote: > > > Heise.de made it appear, as if the only news was that with tcp > > windows, the propability of guessing the right sequence number is not > > 1:2^32 but something smaller. They said that 64k packets would be > > enough, so guess what the window will be. > > Yes, that is their major discovery. You need to guess the ports > and source/destination addresses as well, which is why I don't > consider this such a serious issue personally. > > It is mitigated if timestamps are enabled, because that becomes > another number you have to guess. > > It is mitigated also by randomized ephemeral port selection, which > OpenBSD implements and we could easily implement as well. What about the techniques mentioned in http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ? Curiously there is no mention of port guessing or timestamps there. - James -- James Morris From jgarzik@pobox.com Wed Apr 21 18:00:01 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 18:00:04 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M100KO008339 for ; Wed, 21 Apr 2004 18:00:00 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BGSZL-0002DN-5j; Thu, 22 Apr 2004 01:59:59 +0100 Message-ID: <40871903.8020309@pobox.com> Date: Wed, 21 Apr 2004 20:59:47 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 1/8 2.4.26-bk1] pcnet32 whitespace only changes References: <200404202013.i3KKD7213578@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404202013.i3KKD7213578@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4828 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: 33 Lines: 3 applied all 8 patches to 2.4.x From jgarzik@pobox.com Wed Apr 21 17:59:51 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 17:59:56 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M0xoKO008321 for ; Wed, 21 Apr 2004 17:59:51 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BGSZ9-0002DK-22; Thu, 22 Apr 2004 01:59:47 +0100 Message-ID: <408718F6.701@pobox.com> Date: Wed, 21 Apr 2004 20:59:34 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Fry CC: tsbogend@alpha.franken.de, netdev@oss.sgi.com Subject: Re: [PATCH 1/2 2.6.6-rc1-bk5] pcnet32 add register dump capability References: <200404202254.i3KMsva13912@DYN318364BLD.beaverton.ibm.com> In-Reply-To: <200404202254.i3KMsva13912@DYN318364BLD.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4827 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: 32 Lines: 3 applied both patches to 2.6.x From hibi665@oki.com Wed Apr 21 18:31:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 18:31:50 -0700 (PDT) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M1VeKO010109 for ; Wed, 21 Apr 2004 18:31:41 -0700 Received: from aoi.okilab.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id KAA25394 for ; Thu, 22 Apr 2004 10:31:38 +0900 Received: (qmail 7780 invoked from network); 22 Apr 2004 10:31:37 +0900 Received: from vacant23233.okilab.oki.co.jp (HELO kiso) (172.24.23.233) by aoi.okilab.oki.co.jp with SMTP; 22 Apr 2004 10:31:37 +0900 Message-Id: <20040422103139.2346adc2%hibi665@oki.com> MIME-Version: 1.0 Date: Thu, 22 Apr 2004 10:31:39 +0900 X-Mailer: Denshin 8 Go V32.1.4.3 X-My-Real-Login-Name: thibi; aoi From: Takashi Hibi To: David Stevens Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com In-Reply-To: (Your message of "Wed, 21 Apr 2004 15:05:47 -0700") References: Subject: Re: ping6 error X-archive-position: 4830 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hibi665@oki.com Precedence: bulk X-list: netdev Content-Length: 1322 Lines: 38 Thank you for the response. > Takashi Hibi wrote on 04/20/2004 11:08:32 PM: > >> There are IPv6 addresses for which ping6 doesn't work. >> The host has a global IPv6 address. > >> $ ping6 ff05::1 (site-local multicast address) >> connect: Cannot assign requested address > > This makes less sense (but doesn't fail for me on 2.6.x kernels). > Multicast memberships are per-interface, so a multi-homed host or > router may not have a route for that address to the interface you > actually wanted. It's almost always best to specify "-I" in ping6 > to get what you want. The problem occurs with 2.4.x kernel. And -I option doesn't help. (same result) I didn't check with newest 2.6.x kernel yet. > >> $ ping6 fec0::1 (site-local address) >> connect: Cannot assign requested address > > This works fine on my 2.6.1 system talking to my 2.6.5 system, > when I have an address with an fec0 prefix on both. If you don't, > it's probably a routing table issue-- try "netstat -A inet6 -rn" > and see if you have routing table entries on each so that they > can talk to each other. > If it is a problem of routing talbe, the error would be "network unreachable". Since the default route is set, I think routing table is OK. And when the host has an address with fec0 prefix, ping6 succeeds. Regards, Takashi Hibi From jgarzik@pobox.com Wed Apr 21 20:28:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 20:28:59 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M3SsKO015272 for ; Wed, 21 Apr 2004 20:28:55 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BGUtR-0007na-RO; Thu, 22 Apr 2004 04:28:53 +0100 Message-ID: <40873BEA.1040208@pobox.com> Date: Wed, 21 Apr 2004 23:28:42 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: daniel.ritz@gmx.ch CC: Russell King , netdev@oss.sgi.com Subject: Re: [PATCH] fix arm/etherh.c allocation References: <200404202049.09130.daniel.ritz@gmx.ch> In-Reply-To: <200404202049.09130.daniel.ritz@gmx.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4831 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: 367 Lines: 20 Daniel Ritz wrote: > russell, there's a part of my original patch you missed: allocation of the > netdevice. doesn't need a comment. > > against 2.6-bknow > > rgds > -daniel > > > --- 1.23/drivers/net/arm/etherh.c Wed Apr 14 12:23:55 2004 > +++ edited/etherh.c Tue Apr 20 20:39:04 2004 can one of you resend something that applies with 'patch -sp1'? Jeff From jgarzik@pobox.com Wed Apr 21 20:32:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 20:32:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M3W7KO015619 for ; Wed, 21 Apr 2004 20:32:08 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BGUwY-0007pD-Qc; Thu, 22 Apr 2004 04:32:06 +0100 Message-ID: <40873CAB.6020306@pobox.com> Date: Wed, 21 Apr 2004 23:31:55 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: netdev@oss.sgi.com Subject: Re: [patch 1/2] 2.6.6-rc1-mm1 - spin_unlock_irqrestore avoidance in epic100 References: <20040419235014.A20504@electric-eye.fr.zoreil.com> In-Reply-To: <20040419235014.A20504@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4832 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: 60 Lines: 3 applied both epic100 patches in this series to netdev-2.6 From w@w.ods.org Wed Apr 21 22:05:33 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 22:05:39 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M55VKO017919 for ; Wed, 21 Apr 2004 22:05:33 -0700 Date: Thu, 22 Apr 2004 07:04:12 +0200 From: Willy Tarreau To: James Morris Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-ID: <20040422050411.GM596@alpha.home.local> References: <20040421132047.026ab7f2.davem@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MIME-Autoconverted: from 8bit to quoted-printable by willy.net1.nerim.net id i3M65PUo001410 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3M55VKO017919 X-archive-position: 4833 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: w@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2775 Lines: 57 On Wed, Apr 21, 2004 at 08:45:42PM -0400, James Morris wrote: > On Wed, 21 Apr 2004, David S. Miller wrote: > > > On Wed, 21 Apr 2004 19:03:40 +0200 > > Jörn Engel wrote: > > > > > Heise.de made it appear, as if the only news was that with tcp > > > windows, the propability of guessing the right sequence number is not > > > 1:2^32 but something smaller. They said that 64k packets would be > > > enough, so guess what the window will be. > > > > Yes, that is their major discovery. You need to guess the ports > > and source/destination addresses as well, which is why I don't > > consider this such a serious issue personally. > > > > It is mitigated if timestamps are enabled, because that becomes > > another number you have to guess. > > > > It is mitigated also by randomized ephemeral port selection, which > > OpenBSD implements and we could easily implement as well. > > What about the techniques mentioned in > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt ? They might break the net rather than fix it, they don't seem to consider every aspect. Imagine installed stateful firewalls, NAT boxes, load balancers, etc... All those boxes which won't speak RFCXXXX will block the return ACK once they see the forward RST, and the server behind the firewall will keep ESTABLISHED sessions for hours, days, ... or up to the session time-out dictated by the application. RSTs are very common on the internet from dialup networks because there are lots of people without any clue about networking, who hang up their modem while they fill a form on a site or read a long page, ignoring that their MSIE does HTTP keep-alive and has not yet closed the session. Some also experiment hard lockups or BSODs during FTP transfers, ... And when they release the line, someone else on the same ISP connects and gets the same address. And what does he do with all the ACKs the server sends him ? RST ! It seems that this RST is covered by their draft, but instead of enumerating every possibility to get an RST and check how they can cover it, they focus on changing the RFC, regardless of already deployed implementations. Well, I'm already waiting for the fight between RFCxxxx compliant OSes vs RFCyyyy with yyyy > xxxx. It will be a bit like rfc1337: an entry in /proc for us, a sysctl for BSD users, ndd for solaris and a registry key for many others. At least their draft needs to be validated in every condition, and consequences must be evaluated, with perhaps work-arounds (eg: fall back to old behaviour after a certain number of particular RSTs, ...). > Curiously there is no mention of port guessing or timestamps there. They don't even explain why RSTs are generated and why we need them. Regards, Willy From ap@swapped.cc Wed Apr 21 23:03:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 21 Apr 2004 23:03:26 -0700 (PDT) Received: from mx.coredump.cc (S010600105aa5438e.vc.shawcable.net [24.87.213.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M63LKO019218 for ; Wed, 21 Apr 2004 23:03:21 -0700 Received: (qmail 14392 invoked from network); 22 Apr 2004 06:02:22 -0000 Received: from unknown (HELO swapped.cc) (10.0.0.104) by 10.0.0.1 with SMTP; 22 Apr 2004 06:02:22 -0000 Message-ID: <40875F2F.7010204@swapped.cc> Date: Wed, 21 Apr 2004 22:59:11 -0700 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David S. Miller" CC: netdev@oss.sgi.com, Michael Rozhavsky Subject: RST business Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4834 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ap@swapped.cc Precedence: bulk X-list: netdev Content-Length: 2099 Lines: 60 Looking at the hype around 'TCP vulnerability' the following occured to me, and I wonder if it makes any sense - A host may recieve legitimate RST packet only in response to something that it has previously sent (let's call it a 'trigger'). SEQ/ACK values in RST packet are correlated to SEQ/ACK of the trigger. If the correlation is not there, then RST packet is most certainly spoofed and should be dropped even if its SEQ falls into host's rcpt window. In other words, it seems to be possible to stregthen ingress RST checking (and thus better protect against blind RST attacks) while maintaining _full RFC compliance_. Here's a how-to sketch. RFC 793 (page 35) states that for the connection in non-established state - If the incoming segment has an ACK field, the reset takes its sequence number from the ACK field of the segment, otherwise the reset has sequence number zero and the ACK field is set to the sum of the sequence number and segment length of the incoming segment. Hence the second RST check (after standard window check) is if (! pkt->seq) check if we've recently sent a segment without an ACK with (pkt->ack - pkt->seq) bytes in it else check if we've recently sent a segment with ACK of (pkt->seq) and with (pkt->ack - pkt->seq) bytes in it If RST passes the check, it's accepted. Otherwise checks continue. RFC 793 (page 36) states that for the connection in established state - .. elicit only an empty acknowledgment segment containing the current send-sequence number and an acknowledgment indicating the next sequence number expected to be received .. At this point seeing a RST means that (a) remote host is an ESTABLISHED state (b) we sent a segment that it considers not to be a part of the current connection And (b) is something that we can always check since we're now sure about (a). The above obviously requires keeping some sort of 'outbound history', plus (b) involves some non-trivial logic, which however seems to be doable from the first glance. Comments ? Alex From glen.turner@aarnet.edu.au Thu Apr 22 00:12:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 00:12:17 -0700 (PDT) Received: from clix.aarnet.edu.au (clix.aarnet.edu.au [192.94.63.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M7CBKO020868 for ; Thu, 22 Apr 2004 00:12:12 -0700 Received: from [192.43.230.12] ([192.43.230.12]) (authenticated bits=0) by clix.aarnet.edu.au (8.12.8/8.12.8) with ESMTP id i3M7C7Wo014915 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 22 Apr 2004 17:12:07 +1000 Subject: Re: RST business From: Glen Turner To: Alex Pankratov Cc: netdev@oss.sgi.com In-Reply-To: <40875F2F.7010204@swapped.cc> References: <40875F2F.7010204@swapped.cc> Content-Type: text/plain Organization: Australian Academic and Research Network Message-Id: <1082617714.9967.45.camel@andromache> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 22 Apr 2004 16:38:34 +0930 Content-Transfer-Encoding: 7bit X-MDSA: Yes X-Scanned-By: MIMEDefang 2.39 X-archive-position: 4835 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: glen.turner@aarnet.edu.au Precedence: bulk X-list: netdev Content-Length: 1644 Lines: 51 On Thu, 2004-04-22 at 15:29, Alex Pankratov wrote: > Looking at the hype around 'TCP vulnerability' We're seeing the results of that hype. Lots of peers ringing the NOC to urgently arrange TCP MD5 authentication of their BGP sessions. It looks like lots of managers have read the press and issued directives. Which is ironic, as we're pretty insistent about configuring MD5 authentication, and so the peer has in the past explicitly requested that we not run BGP authentication. In the past we've assumed that those were Linux peers, but apparently they were just slack. BGP is particularly vulnerable as they are long-lived (some sessions here are longer than 400 days, so there can be lots of attempts) and the interpretation of RST is dramatic (remove routes learned from that neighbour). Now if only they would release a Security Advisory about the risks of unauthenticated OSPF and get the same level of response :-) > Comments ? The essential problem is that RST is the generic way of recovering from a failure condition in the TCP state machine. So trusting that the values in the remainder of the TCP header are correct is a large leap of faith (perhaps they got trod on by an errant pointer, and perhaps the resulting out-of-range value is why the other end sent us the RST). If you choose to ignore a RST, and the RST is valid, then you need to ensure that the TCP connection will always time out (thus issuing its own RST). You can expect, but not be assured of, a RST for each subsequent packet sent on that connection (and maybe that's a cheap way of checking if the original RST is valid, hmmm). Best wishes, Glen From cranium2003@yahoo.com Thu Apr 22 00:27:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 00:27:18 -0700 (PDT) Received: from web41411.mail.yahoo.com (web41411.mail.yahoo.com [66.218.93.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M7RCKO024554 for ; Thu, 22 Apr 2004 00:27:15 -0700 Message-ID: <20040422072707.15370.qmail@web41411.mail.yahoo.com> Received: from [203.199.141.99] by web41411.mail.yahoo.com via HTTP; Thu, 22 Apr 2004 00:27:07 PDT Date: Thu, 22 Apr 2004 00:27:07 -0700 (PDT) From: Parag Nemade Subject: how data travels across tcp stack? To: net dev MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4836 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 675 Lines: 24 hello, 1)which function in kernel source tree actually takes data from application to be send it as a packet? 2)when one layer gives control to next layer i.e. from transport to IP layer is it neccessary for transport layer to occur interrupt to give control to next layer? 3)i am not getting line in ip_fragment function if ((skb2 = alloc_skb(len+hlen+dev->hard_header_len+15,GFP_ATOMIC)) == NULL) in ip_output.c. i want to know what is the mean ing for 15 value when skbuff is allocated for new fragment? regards, parag. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From rmk+netdev=oss.sgi.com@arm.linux.org.uk Thu Apr 22 00:33:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 00:34:00 -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.9) with SMTP id i3M7XrKO026230 for ; Thu, 22 Apr 2004 00:33:54 -0700 Received: from flint.arm.linux.org.uk ([2002:d412:e8ba:1:201:2ff:fe14:8fad]) by caramon.arm.linux.org.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.32) id 1BGYiN-00043P-Fv; Thu, 22 Apr 2004 08:33:43 +0100 Received: from rmk by flint.arm.linux.org.uk with local (Exim 4.32) id 1BGYiM-0004p8-Kn; Thu, 22 Apr 2004 08:33:42 +0100 Date: Thu, 22 Apr 2004 08:33:42 +0100 From: Russell King To: Jeff Garzik Cc: daniel.ritz@gmx.ch, netdev@oss.sgi.com Subject: Re: [PATCH] fix arm/etherh.c allocation Message-ID: <20040422083342.A31406@flint.arm.linux.org.uk> References: <200404202049.09130.daniel.ritz@gmx.ch> <40873BEA.1040208@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <40873BEA.1040208@pobox.com>; from jgarzik@pobox.com on Wed, Apr 21, 2004 at 11:28:42PM -0400 X-archive-position: 4837 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: 666 Lines: 18 On Wed, Apr 21, 2004 at 11:28:42PM -0400, Jeff Garzik wrote: > Daniel Ritz wrote: > > --- 1.23/drivers/net/arm/etherh.c Wed Apr 14 12:23:55 2004 > > +++ edited/etherh.c Tue Apr 20 20:39:04 2004 > > > can one of you resend something that applies with 'patch -sp1'? I've noticed this as well - I just end up fixing the patch headers manually. It's a BK bug unfortunately - if you provide a directory for bk diffs, it messes up like above, but if you give explicit files it doesn't. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From pochini@shiny.it Thu Apr 22 01:24:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 01:24:24 -0700 (PDT) Received: from denise.shiny.it (denise.shiny.it [194.20.232.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M8OFKO027535 for ; Thu, 22 Apr 2004 01:24:16 -0700 Received: from agnus (agnus.shiny.it [194.20.232.6]) by denise.shiny.it (8.11.7/8.11.6) with ESMTP id i3M8NwE21076; Thu, 22 Apr 2004 10:23:58 +0200 Message-ID: X-Mailer: XFMail 1.4.7 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 In-Reply-To: <20040421132047.026ab7f2.davem@redhat.com> Date: Thu, 22 Apr 2004 10:23:59 +0200 (CEST) From: Giuliano Pochini To: "David S. Miller" Subject: Re: tcp vulnerability? haven't seen anything on it here... Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?ISO-8859-1?Q?J=F6rn?= Engel X-MIME-Autoconverted: from 8bit to quoted-printable by denise.shiny.it id i3M8NwE21076 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3M8OFKO027535 X-archive-position: 4838 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pochini@shiny.it Precedence: bulk X-list: netdev Content-Length: 1030 Lines: 27 On 21-Apr-2004 David S. Miller wrote: > On Wed, 21 Apr 2004 19:03:40 +0200 > Jörn Engel wrote: > >> Heise.de made it appear, as if the only news was that with tcp >> windows, the propability of guessing the right sequence number is not >> 1:2^32 but something smaller. They said that 64k packets would be >> enough, so guess what the window will be. > > Yes, that is their major discovery. You need to guess the ports > and source/destination addresses as well, which is why I don't > consider this such a serious issue personally. Yes, but it is possible, expecially for long sessions. Also, data injections is also possible with the same method, because the receiver accepts everything inside the window, which is usually 64k. Out of curiosity: in case Linux receives two packets relative to the same portion of the stream, does it check if the overlapping data is the same ? It would add extra security about data injection in case the data has not been sent to userspace yet. -- Giuliano. From hnawab@in.ibm.com Thu Apr 22 02:09:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 02:09:26 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M99IKO028835 for ; Thu, 22 Apr 2004 02:09:20 -0700 Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id i3M998lJ069056 for ; Thu, 22 Apr 2004 19:09:08 +1000 Received: from d23m0063.in.ibm.com (d23av02.au.ibm.com [9.190.250.243]) by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3M99e4O081482 for ; Thu, 22 Apr 2004 19:09:42 +1000 Subject: Jumbogram!-checksum! To: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Nawab Hasan Date: Thu, 22 Apr 2004 19:13:18 +1000 X-MIMETrack: Serialize by Router on d23m0063/23/M/IBM(Release 6.0.2CF2|July 23, 2003) at 22/04/2004 14:43:23 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-archive-position: 4839 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hnawab@in.ibm.com Precedence: bulk X-list: netdev Content-Length: 328 Lines: 14 Hi, in Ipv6 the jumbogram packet could be as large as 4294967296 octet.It will be overhead for calculating the checksum for TCP and UDP(pseudo header).It will in turn degrade the performance if not what are other methods for getting the integrate ipv6 packet over ipv6 node.Could someone help me out on this issue? Nawab From root@chaos.analogic.com Thu Apr 22 04:35:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 04:35:28 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MBZKKO005743 for ; Thu, 22 Apr 2004 04:35:21 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i3MBZsA08096; Thu, 22 Apr 2004 07:35:54 -0400 Date: Thu, 22 Apr 2004 07:35:54 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Giuliano Pochini cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?ISO-8859-1?Q?J=F6rn?= Engel Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i3MBZKKO005743 X-archive-position: 4840 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 1400 Lines: 39 On Thu, 22 Apr 2004, Giuliano Pochini wrote: > > On 21-Apr-2004 David S. Miller wrote: > > On Wed, 21 Apr 2004 19:03:40 +0200 > > Jörn Engel wrote: > > > >> Heise.de made it appear, as if the only news was that with tcp > >> windows, the propability of guessing the right sequence number is not > >> 1:2^32 but something smaller. They said that 64k packets would be > >> enough, so guess what the window will be. > > > > Yes, that is their major discovery. You need to guess the ports > > and source/destination addresses as well, which is why I don't > > consider this such a serious issue personally. > > Yes, but it is possible, expecially for long sessions. Also, > data injections is also possible with the same method, because > the receiver accepts everything inside the window, which is > usually 64k. Out of curiosity: in case Linux receives two > packets relative to the same portion of the stream, does it > check if the overlapping data is the same ? It would add extra > security about data injection in case the data has not been > sent to userspace yet. > > Has anybody checked to see what Linux does if it receives a RST to the broadcast address? It would be a shame if all connections were dropped! Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). Note 96.31% of all statistics are fiction. From mtk-lists@gmx.net Thu Apr 22 06:05:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:05:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MD5IKO008432 for ; Thu, 22 Apr 2004 06:05:19 -0700 Received: (qmail 6721 invoked by uid 0); 22 Apr 2004 13:05:12 -0000 Received: from 62.245.207.82 by www15.gmx.net with HTTP; Thu, 22 Apr 2004 15:05:13 +0200 (MEST) Date: Thu, 22 Apr 2004 15:05:13 +0200 (MEST) From: "Michael T Kerrisk" To: netdev@oss.sgi.com MIME-Version: 1.0 Subject: Assassination of TIME_WAIT state X-Priority: 3 (Normal) X-Authenticated: #18454895 Message-ID: <18236.1082639113@www15.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 4841 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mtk-lists@gmx.net Precedence: bulk X-list: netdev Content-Length: 2546 Lines: 74 Gidday, In the scenario below, one achieves assassination of the TIME_WAIT state on Linux 2.6.5 and 2.4.x. From a conversation I had a while ago with Andi Kleen (see below), it appears that this is expected behavior. I have two (closely linked) questions: -- what is the rationale for this behavior (i.e., why assassinate in this scenario)? -- why does Linux behave differently from FreeBSD and Solaris in this scenario? Assume in the following scenario that SO_RESUSEADDR is set on the server socket(s): Server Client 1. Create listening socket bound to INADDR_ANY/port=9999 2. Accept a connection on the listening socket 3. Create a socket bound to INADDR_ANY/port=50000 4. Connect to server socket (on port 9999) 5. Close listening and connected sockets 6. Close the socket At this point, there is TCP on the server side in the TIME_WAIT state: { local=localhost:9999, peer=XXX:50000 } (re-run server) 7. Create listening socket bound to INADDR_ANY/port=9999 8. Accept a connection on the listening socket (re-run client while TIME_WAIT TCP still exists) 9. Create a socket bound to INADDR_ANY/port=50000 10.Connect to server socket (on port 9999) On Linux the connect() in step 10 succeeds; the reason that it does is that the TIME_WAIT TCP is immediately assassinated. A while back I asked Andi Kleen about this scenario, and he commented that this behavious was: > a (dubious) BSD extension, also implemented > in linux (after all sockets is about being bug to bug coompatible). > the kernel sees the TIME-WAIT and choses a sequence number with > a large offset to avoid conflicts. When you don't have PAWS > but still had a big window it is rather risky though. However, when I try the above on FreeBSD 5.1 and Solaris 8, we see different behavior: the TIME_WAIT TCP is NOT assassinated and the connect() at step 10 fails with EADDRINUSE (which makes sense because we can't create a duplicate 4-tuple...). Cheers, Michael -- Michael Kerrisk mtk-lists@gmx.net "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info From hadi@cyberus.ca Thu Apr 22 06:16:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:17:31 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MDGfKO009512 for ; Thu, 22 Apr 2004 06:16:41 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BGe4Z-0007xE-Dm for netdev@oss.sgi.com; Thu, 22 Apr 2004 09:16:59 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BGe4B-0005iK-FG; Thu, 22 Apr 2004 09:16:35 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: syrius.ml@no-log.org Cc: netdev@oss.sgi.com In-Reply-To: References: <1082427350.1034.70.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082639764.1059.81.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Apr 2004 09:16:04 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4842 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1469 Lines: 43 Hi there, On Wed, 2004-04-21 at 16:19, syrius.ml@no-log.org wrote: > ok, i'm able to reproduce it with a simpler setup. > > Let's consider I'm using the new dummy device on machine connected to > a ethernet lan. this host is using openvpn to establish a vpn tunnel. [..] > after the ping -f 192.168.5.1 (let's say i let it run 30sec), if a do > ping 172.16.0.1 the oops appears ! > > I attach the result of ksymoops. > > Please tell me if you're able to reproduce it. > I'm ok to try with another vpn software, but I don't think it has > anything to do with openvpn. > It may be more related to the tun device that software uses. Tun is an interesting netdevice. I dont have a setup to reproduce this. BTW, doesnt the packet eventually make it to eth0 coming from the vpn? Also the other direction is true (always starts at the eth0 level); if yes, why do you have to redirect packets from the tap device? Try the following to debug: remove the egress qdisc from the tap device and run the test. (this part: $TC qdisc add dev tun0 root handle 1: prio) If thats till ooopses, remove the ingress attachment to the tun. And if that still fails, compile both tun and dummy into the kernel (as opposed to modules) and reproduce the oops. Additionaly some useful tools are stats on the dummy devices as well as the actions (example: tc -s filter ls dev eth0 parent ffff:) cheers, jamal ________________________________________________________________________ From w@w.ods.org Thu Apr 22 06:18:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:18:56 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MDIpKO010173 for ; Thu, 22 Apr 2004 06:18:52 -0700 Date: Thu, 22 Apr 2004 15:17:04 +0200 From: Willy Tarreau To: "Richard B. Johnson" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-ID: <20040422131704.GA6839@alpha.home.local> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 4843 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: w@w.ods.org Precedence: bulk X-list: netdev Content-Length: 515 Lines: 14 On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote: > Has anybody checked to see what Linux does if it receives a > RST to the broadcast address? It would be a shame if all > connections were dropped! I don't see how this would be possible : a TCP packet is matched *only* if it refers to a valid session. If you have no session established from/to the broadcast address, there's no possibility that an RST targetted at this address terminates anything, even if the ports are OK. Cheers, Willy From root@chaos.analogic.com Thu Apr 22 06:41:27 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:41:31 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MDfRKO013045 for ; Thu, 22 Apr 2004 06:41:27 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i3MDgwP08774; Thu, 22 Apr 2004 09:42:58 -0400 Date: Thu, 22 Apr 2004 09:42:58 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Willy Tarreau cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <20040422131704.GA6839@alpha.home.local> Message-ID: References: <20040422131704.GA6839@alpha.home.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4844 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 1663 Lines: 41 On Thu, 22 Apr 2004, Willy Tarreau wrote: > On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote: > > > Has anybody checked to see what Linux does if it receives a > > RST to the broadcast address? It would be a shame if all > > connections were dropped! > > I don't see how this would be possible : a TCP packet is matched *only* if > it refers to a valid session. If you have no session established from/to the > broadcast address, there's no possibility that an RST targetted at this > address > terminates anything, even if the ports are OK. > > Cheers, > Willy > If course it's possible. Remember the trick to blue-screen W$, just send a fragmented packet with a large length, then never send the rest. There are lots of things that can happen when control data goes to the broadcast address. Ping the broadcast address and observe. If you have any W$/2000/prof machines on your network that don't have service-pack 2 or later installed, just syn-flood the broadcast address. So I wonder how well the corner cases have been checked. Of course you can't "connect" to a host using the broadcast address, unless some code runs off the end of a switch statement unchecked. Hopefully invalid packets just get dropped on the floor. However, history shows otherwise. Linux has a habit of loudly complaining about invalid packets or protocol violations. The result being a log full of messages leading to a full file-system. Fortunately one can turn off many using the /proc/sys/net/ipv4 interface. Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). Note 96.31% of all statistics are fiction. From pochini@denise.shiny.it Thu Apr 22 06:46:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:47:07 -0700 (PDT) Received: from denise.shiny.it (denise.shiny.it [194.20.232.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MDkvKO013431 for ; Thu, 22 Apr 2004 06:46:58 -0700 Received: from localhost (pochini@localhost) by denise.shiny.it (8.11.7/8.11.6) with ESMTP id i3MDk5R03114; Thu, 22 Apr 2004 15:46:05 +0200 Date: Thu, 22 Apr 2004 15:46:05 +0200 (CEST) From: Giuliano Pochini To: jamal cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?ISO-8859-1?Q?J=F6rn?= Engel Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <1082640135.1059.93.camel@jzny.localdomain> Message-ID: References: <1082640135.1059.93.camel@jzny.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4845 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: pochini@denise.shiny.it Precedence: bulk X-list: netdev Content-Length: 670 Lines: 22 On Thu, 22 Apr 2004, jamal wrote: > On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote: > > > Yes, but it is possible, expecially for long sessions. > > In other words, 80% or more of internet traffic would not be affected > still using http1.0 would not be affected. > And for something like a huge download to just regular joe, this is more > of a nuisance assuming some kiddie has access between you and the > server. No, TCP/IP is 100% vulnerable to the man-in-the-middle attach. There is no cure for that. Some devices or softwares called "firewall" are designed to cut or to modify connections. :) This vulnerability is about external attacks. -- Giuliano. From fw@deneb.enyo.de Thu Apr 22 06:58:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 06:59:00 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MDwsKO013862 for ; Thu, 22 Apr 2004 06:58:55 -0700 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGeiv-0000dP-6y; Thu, 22 Apr 2004 15:58:41 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGeiu-0001K2-8k; Thu, 22 Apr 2004 15:58:40 +0200 To: hadi@cyberus.ca Cc: Giuliano Pochini , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?iso-8859-1?q?J=F6rn_Engel?= Subject: Re: tcp vulnerability? haven't seen anything on it here... References: <1082640135.1059.93.camel@jzny.localdomain> From: Florian Weimer Date: Thu, 22 Apr 2004 15:58:40 +0200 In-Reply-To: <1082640135.1059.93.camel@jzny.localdomain> (hadi@cyberus.ca's message of "22 Apr 2004 09:22:16 -0400") Message-ID: <87zn94w1v3.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4846 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: netdev Content-Length: 552 Lines: 15 jamal writes: > OTOH, long lived BGP sessions are affected assuming you are going across > hostile path to your peer. Hostile path is not required. Not at all. 8-( And it's not BGP specific. You might be able to use this attack to split IRC networks, too. However, it's a bit harder in this case because IRC servers usually use more random source ports. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. From w@w.ods.org Thu Apr 22 07:23:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 07:23:35 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MENSKO015201 for ; Thu, 22 Apr 2004 07:23:29 -0700 Date: Thu, 22 Apr 2004 16:18:48 +0200 From: Willy Tarreau To: "Richard B. Johnson" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-ID: <20040422141848.GA6986@alpha.home.local> References: <20040422131704.GA6839@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 4847 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: w@w.ods.org Precedence: bulk X-list: netdev Content-Length: 3080 Lines: 71 Richard, you are confusing several thinks, stateful vs stateless protocols. A ping doesn't need a session on the remote host to be interpreted. A TCP segment whose flags don't show a SYN need a session to be interpreted. Please note that I'm not arguing that you won't crash a linux box with an RST addressed to a broadcast address, I'm saying that there's absolutely no reason why this should reset all connections, as you proposed it. Someone would have had to code this explicitly, it cannot be a simple side effect. Imagine that each packet which enters the system is presented to a hash table containing the sessions, and that its session is looked for into this hash table. You agree that in such code, there's no reason to find anything that runs through all sessions and kill everyone, since this code has no use there, and has no reason to be implemented on purpose ! Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for example. When it reaches tcp_v4_lookup_established(), you find this : for(sk = head->chain; sk; sk = sk->next) { if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) goto hit; /* You sunk my battleship! */ } You cannot match more than once. Cheers, Willy On Thu, Apr 22, 2004 at 09:42:58AM -0400, Richard B. Johnson wrote: > On Thu, 22 Apr 2004, Willy Tarreau wrote: > > > On Thu, Apr 22, 2004 at 07:35:54AM -0400, Richard B. Johnson wrote: > > > > > Has anybody checked to see what Linux does if it receives a > > > RST to the broadcast address? It would be a shame if all > > > connections were dropped! > > > > I don't see how this would be possible : a TCP packet is matched *only* if > > it refers to a valid session. If you have no session established from/to the > > broadcast address, there's no possibility that an RST targetted at this > > address > > terminates anything, even if the ports are OK. > > > > Cheers, > > Willy > > > > If course it's possible. Remember the trick to blue-screen W$, just > send a fragmented packet with a large length, then never send the > rest. There are lots of things that can happen when control > data goes to the broadcast address. Ping the broadcast address and > observe. If you have any W$/2000/prof machines on your network that > don't have service-pack 2 or later installed, just syn-flood the > broadcast address. So I wonder how well the corner cases have been > checked. Of course you can't "connect" to a host using the broadcast > address, unless some code runs off the end of a switch statement > unchecked. > > Hopefully invalid packets just get dropped on the floor. However, > history shows otherwise. Linux has a habit of loudly complaining > about invalid packets or protocol violations. The result being > a log full of messages leading to a full file-system. Fortunately > one can turn off many using the /proc/sys/net/ipv4 interface. > > Cheers, > Dick Johnson > Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). > Note 96.31% of all statistics are fiction. > From hadi@cyberus.ca Thu Apr 22 07:27:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 07:27:16 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MERBKO015570 for ; Thu, 22 Apr 2004 07:27:11 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BGfAn-0007SR-8x for netdev@oss.sgi.com; Thu, 22 Apr 2004 10:27:29 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BGfAN-0002zx-Vc; Thu, 22 Apr 2004 10:27:04 -0400 Subject: Re: tcp vulnerability? haven't seen anything on it here... From: jamal Reply-To: hadi@cyberus.ca To: Giuliano Pochini Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?ISO-8859-1?Q?J=F6rn?= Engel In-Reply-To: References: <1082640135.1059.93.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082644022.1099.40.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Apr 2004 10:27:02 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4848 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1994 Lines: 52 On Thu, 2004-04-22 at 09:46, Giuliano Pochini wrote: > On Thu, 22 Apr 2004, jamal wrote: > > > On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote: > > > > > Yes, but it is possible, expecially for long sessions. > > > > In other words, 80% or more of internet traffic would not be affected > > still using http1.0 would not be affected. > > And for something like a huge download to just regular joe, this is more > > of a nuisance assuming some kiddie has access between you and the > > server. > > No, TCP/IP is 100% vulnerable to the man-in-the-middle attach. > There is no cure for that. Unless its a private network with locked vaults for the pipes, any network is vulnerable. I am not trying to downplay the relevance of this; all i am saying is it may a little overhyped with the media being involved. Its infact harder to create this attack compared to a simple SYN attack. On Thu, 2004-04-22 at 09:58, Florian Weimer wrote: jamal writes: > > > OTOH, long lived BGP sessions are affected assuming you are going across > > hostile path to your peer. > > Hostile path is not required. Not at all. 8-( > > Unless i misunderstood: You need someone/thing to see about 64K packets within a single flow to make the predicition so the attack is succesful. Sure to have access to such capability is to be in a hostile path, no? ;-> > And it's not BGP specific. You might be able to use this attack to > split IRC networks, too. However, it's a bit harder in this case > because IRC servers usually use more random source ports. Any long lived flow with close to fixed ports. FTP from kernel.org could be vulnerable - get a better client and its just becomes a nuisance. 80% of the internet traffic is still TCP/HTTP1.0 which is very short lived (there could be changes lately - these are numbers from a while back) i.e you wont see more than 8 packets i.e it is highly unlikely your traffic there is affected even if you used fixed ports. cheers, jamal From alex@pilosoft.com Thu Apr 22 07:40:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 07:40:20 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MEe6KO016345 for ; Thu, 22 Apr 2004 07:40:09 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i3MEbgO02962; Thu, 22 Apr 2004 10:37:42 -0400 Date: Thu, 22 Apr 2004 10:37:42 -0400 (EDT) From: alex@pilosoft.com To: jamal cc: linux-kernel@vger.kernel.org, Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <1082644022.1099.40.camel@jzny.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4849 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 1738 Lines: 36 On 22 Apr 2004, jamal wrote: > Unless its a private network with locked vaults for the pipes, any > network is vulnerable. I am not trying to downplay the relevance of > this; all i am saying is it may a little overhyped with the media being > involved. Its infact harder to create this attack compared to a simple > SYN attack. Not quite. With a SYN you have to respond with exactly the same sequence number as attacking host in order to establish connection. With RST, your sequence number needs to be +- rwin in order to kill the connection. That significantly reduces search space. > Unless i misunderstood: You need someone/thing to see about 64K packets > within a single flow to make the predicition so the attack is succesful. > Sure to have access to such capability is to be in a hostile path, no? > ;-> No, you do not need to see any packet. > > And it's not BGP specific. You might be able to use this attack to > > split IRC networks, too. However, it's a bit harder in this case > > because IRC servers usually use more random source ports. > > Any long lived flow with close to fixed ports. FTP from kernel.org could > be vulnerable - get a better client and its just becomes a nuisance. 80% > of the internet traffic is still TCP/HTTP1.0 which is very short lived > (there could be changes lately - these are numbers from a while back) > i.e you wont see more than 8 packets i.e it is highly unlikely your > traffic there is affected even if you used fixed ports. Inter-provider BGP is long-lived with close to fixed ports, which is why it has caused quite a stir. Nevertheless, number of packets to kill the session is still *large* (under "best-case" for attacker, you need to send 2^30 packets)... -alex From hadi@cyberus.ca Thu Apr 22 08:18:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 08:18:20 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFIEKO017742 for ; Thu, 22 Apr 2004 08:18:15 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BGfyC-0004rt-RX for netdev@oss.sgi.com; Thu, 22 Apr 2004 11:18:32 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BGfx9-00051u-Qh; Thu, 22 Apr 2004 11:17:27 -0400 Subject: Re: tcp vulnerability? haven't seen anything on it here... From: jamal Reply-To: hadi@cyberus.ca To: alex@pilosoft.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1082647046.1099.47.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Apr 2004 11:17:26 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4850 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1039 Lines: 33 On Thu, 2004-04-22 at 10:37, alex@pilosoft.com wrote: > On 22 Apr 2004, jamal wrote: > > Its infact harder to create this attack compared to a simple > > SYN attack. > Not quite. I meant a SYN Flood attack is a much trivial attack than this but the media may have gotten used to it by now. > > Unless i misunderstood: You need someone/thing to see about 64K packets > > within a single flow to make the predicition so the attack is succesful. > > Sure to have access to such capability is to be in a hostile path, no? > > ;-> > No, you do not need to see any packet. > Ok, so i misunderstood then. How do you predict the sequences without seeing any packet? Is there any URL to mentioned paper? > Inter-provider BGP is long-lived with close to fixed ports, which is why > it has caused quite a stir. Makes sense. What would be the overall effect though? Route flaps? > Nevertheless, number of packets to kill the session is still *large* > (under "best-case" for attacker, you need to send 2^30 packets)... ;-> cheers, jamal From apankrat@telus.net Thu Apr 22 08:21:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 08:22:03 -0700 (PDT) Received: from mx.coredump.cc (S010600105aa5438e.vc.shawcable.net [24.87.213.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFLvKO021054 for ; Thu, 22 Apr 2004 08:21:57 -0700 Received: (qmail 15494 invoked from network); 22 Apr 2004 15:21:08 -0000 Received: from unknown (HELO telus.net) (10.0.0.104) by 10.0.0.1 with SMTP; 22 Apr 2004 15:21:08 -0000 Message-ID: <4087E219.7000308@telus.net> Date: Thu, 22 Apr 2004 08:17:45 -0700 From: Alex Pankratov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Modica CC: Alex Pankratov , "David S. Miller" , netdev@oss.sgi.com, Michael Rozhavsky Subject: Re: RST business References: <40875F2F.7010204@swapped.cc> <4087D29E.6010907@sgi.com> In-Reply-To: <4087D29E.6010907@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4851 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: apankrat@telus.net Precedence: bulk X-list: netdev Content-Length: 2697 Lines: 75 Yeah, sure, I understand that. But how realistis is this synchronization loss ? Ie I cannot immediately think of a sequence of events, which would result in two sides both in Established state with de-synchronized recp/send windows. Steve Modica wrote: > If one of the potential causes for RST is that SEQ/ACK synchronization > has been lost, then you can't do this. > > Alex Pankratov wrote: > >> >> Looking at the hype around 'TCP vulnerability' the following >> occured to me, and I wonder if it makes any sense - >> >> A host may recieve legitimate RST packet only in response to >> something that it has previously sent (let's call it a 'trigger'). >> >> SEQ/ACK values in RST packet are correlated to SEQ/ACK of the >> trigger. If the correlation is not there, then RST packet is >> most certainly spoofed and should be dropped even if its SEQ >> falls into host's rcpt window. >> >> In other words, it seems to be possible to stregthen ingress >> RST checking (and thus better protect against blind RST attacks) >> while maintaining _full RFC compliance_. Here's a how-to sketch. >> >> RFC 793 (page 35) states that for the connection in >> non-established state - >> >> If the incoming segment has an ACK field, the reset takes its >> sequence number from the ACK field of the segment, otherwise >> the reset has sequence number zero and the ACK field is set to >> the sum of the sequence number and segment length of the incoming >> segment. >> >> Hence the second RST check (after standard window check) is >> >> if (! pkt->seq) >> check if we've recently sent a segment without >> an ACK with (pkt->ack - pkt->seq) bytes in it >> else >> check if we've recently sent a segment with ACK >> of (pkt->seq) and with (pkt->ack - pkt->seq) >> bytes in it >> >> If RST passes the check, it's accepted. Otherwise checks continue. >> >> RFC 793 (page 36) states that for the connection in >> established state - >> >> .. elicit only an empty >> acknowledgment segment containing the current send-sequence number >> and an acknowledgment indicating the next sequence number expected >> to be received .. >> >> At this point seeing a RST means that >> (a) remote host is an ESTABLISHED state >> (b) we sent a segment that it considers not to be a part of the >> current connection >> >> And (b) is something that we can always check since we're now sure >> about (a). >> >> The above obviously requires keeping some sort of 'outbound history', >> plus (b) involves some non-trivial logic, which however seems to be >> doable from the first glance. >> >> Comments ? >> >> Alex > > > From alex@pilosoft.com Thu Apr 22 08:29:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 08:29:59 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFTtKO021459 for ; Thu, 22 Apr 2004 08:29:56 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i3MFR5J03362; Thu, 22 Apr 2004 11:27:05 -0400 Date: Thu, 22 Apr 2004 11:27:05 -0400 (EDT) From: alex@pilosoft.com To: jamal cc: linux-kernel@vger.kernel.org, Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <1082647046.1099.47.camel@jzny.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4852 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 1133 Lines: 27 > > > Unless i misunderstood: You need someone/thing to see about 64K > > > packets within a single flow to make the predicition so the attack > > > is succesful. Sure to have access to such capability is to be in a > > > hostile path, no? ;-> > > No, you do not need to see any packet. > > > > Ok, so i misunderstood then. How do you predict the sequences without > seeing any packet? Is there any URL to mentioned paper? You don't - just brute-force the tcp 4-tuple and sequence number. The attack relies on the fact that you don't have to match sequence number exactly, which cuts down on the search-space. (If total search space is 2^32, rwin is 16k, effective attack search space is 2^32/16k). Multiplied by number of ephemeral ports, it becomes *feasible* but still not very likely. > > Inter-provider BGP is long-lived with close to fixed ports, which is > > why it has caused quite a stir. > > Makes sense. What would be the overall effect though? Route flaps? Yep. > > Nevertheless, number of packets to kill the session is still *large* > > (under "best-case" for attacker, you need to send 2^30 packets)... -alex From cfriesen@nortelnetworks.com Thu Apr 22 08:43:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 08:43:48 -0700 (PDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFhhKO022066 for ; Thu, 22 Apr 2004 08:43:43 -0700 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3MFgpq10996; Thu, 22 Apr 2004 11:42:51 -0400 (EDT) Received: from zcard0k6.ca.nortel.com ([47.129.242.158]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8J36F; Thu, 22 Apr 2004 11:42:52 -0400 Received: from nortelnetworks.com (pcard0ks.ca.nortel.com [47.129.117.131]) by zcard0k6.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC47GCBA; Thu, 22 Apr 2004 11:42:52 -0400 Message-ID: <4087E7FB.7000400@nortelnetworks.com> Date: Thu, 22 Apr 2004 11:42:51 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Chris Friesen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex@pilosoft.com CC: jamal , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4853 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cfriesen@nortelnetworks.com Precedence: bulk X-list: netdev Content-Length: 280 Lines: 8 alex@pilosoft.com wrote: > Nevertheless, number of packets to kill the session is still *large* > (under "best-case" for attacker, you need to send 2^30 packets)... I though the whole point of this vulnerability was that you "only" needed to send 64K packets, not 2^30. Chris From alex@pilosoft.com Thu Apr 22 08:53:07 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 08:53:11 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFr6KO022588 for ; Thu, 22 Apr 2004 08:53:06 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i3MFlFA03545; Thu, 22 Apr 2004 11:47:15 -0400 Date: Thu, 22 Apr 2004 11:47:15 -0400 (EDT) From: alex@pilosoft.com To: Chris Friesen cc: linux-kernel@vger.kernel.org, Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <4087E7FB.7000400@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4854 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 631 Lines: 20 On Thu, 22 Apr 2004, Chris Friesen wrote: > alex@pilosoft.com wrote: > > > Nevertheless, number of packets to kill the session is still *large* > > (under "best-case" for attacker, you need to send 2^30 packets)... > > I though the whole point of this vulnerability was that you "only" > needed to send 64K packets, not 2^30. 64k packets if rwin is 64k and if you know ports on both sides. If rwin is 16k (default on many routers) and you need to scan all ephemeral ports, its 256k packets * number of ephemeral ports. One router vendor has 4000 ephemeral ports maximum, resulting in 256k*4000 = ~1 billion packets. -alex From jonmason@us.ibm.com Thu Apr 22 09:21:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 09:21:35 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MGLNKO023834 for ; Thu, 22 Apr 2004 09:21:30 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MGL1pj454024; Thu, 22 Apr 2004 12:21:02 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MGL0nZ155384; Thu, 22 Apr 2004 10:21:00 -0600 In-Reply-To: <20040420234524.A1374@electric-eye.fr.zoreil.com> To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Thu, 22 Apr 2004 10:20:58 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/22/2004 10:21:00 Content-Type: multipart/mixed; boundary="=_mixed 005967D286256E7E_=" X-archive-position: 4855 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 8622 Lines: 128 --=_mixed 005967D286256E7E_= Content-Type: text/plain; charset="US-ASCII" Hey Francois, Attached is the NAPI diff with all of the requested changes. I think I have it ready for you t accept, let me know any questions/comments. Also, I attempted to add Tx to NAPI, but the performance was severely degraded. A simple ping flood avg rtt went from <0.5ms to >12ms. It is probably poor implementation on my part. I will attempt to add that functionality at a later date (if that's cool with you). There are a few other things in this driver I would like to look into first. Thanks, Jon --=_mixed 005967D286256E7E_= Content-Type: application/octet-stream; name="r8169.diff" Content-Disposition: attachment; filename="r8169.diff" Content-Transfer-Encoding: base64 LS0tIHI4MTY5LmMub3JpZwkyMDA0LTA0LTE4IDIyOjUxOjMzLjAwMDAwMDAwMCAtMDUwMAorKysg cjgxNjkuYwkyMDA0LTA0LTIyIDA4OjA4OjU3LjUyNjU3NzA0OCAtMDUwMApAQCAtOTMsOCArOTMs MTUgQEAgc3RhdGljIGludCBtdWx0aWNhc3RfZmlsdGVyX2xpbWl0ID0gMzI7CiAjZGVmaW5lIFJ4 UGFja2V0TWF4U2l6ZQkweDA4MDAJLyogTWF4aW11bSBzaXplIHN1cHBvcnRlZCBpcyAxNkstMSAq LwogI2RlZmluZSBJbnRlckZyYW1lR2FwCTB4MDMJLyogMyBtZWFucyBJbnRlckZyYW1lR2FwID0g dGhlIHNob3J0ZXN0IG9uZSAqLwogCi0jZGVmaW5lIE5VTV9UWF9ERVNDCTY0CS8qIE51bWJlciBv ZiBUeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisv KiBUaGUgbnVtYmVyIG9mIFJ4IGl0ZXJhdGlvbnMgcHJvY2Vzc2VkIChpZiBOQVBJIGVuYWJsZWQp ICovCisjZGVmaW5lIFI4MTY5X05BUElfV0VJR0hUCTY0CisKKyNkZWZpbmUgTlVNX1JYX0RFU0MJ MjU2CS8qIE51bWJlciBvZiBSeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2Vsc2UKICNkZWZp bmUgTlVNX1JYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFJ4IGRlc2NyaXB0b3IgcmVnaXN0ZXJzICov CisjZW5kaWYKKyNkZWZpbmUgTlVNX1RYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFR4IGRlc2NyaXB0 b3IgcmVnaXN0ZXJzICovCiAjZGVmaW5lIFJYX0JVRl9TSVpFCTE1MzYJLyogUnggQnVmZmVyIHNp emUgKi8KICNkZWZpbmUgUjgxNjlfVFhfUklOR19CWVRFUwkoTlVNX1RYX0RFU0MgKiBzaXplb2Yo c3RydWN0IFR4RGVzYykpCiAjZGVmaW5lIFI4MTY5X1JYX1JJTkdfQllURVMJKE5VTV9SWF9ERVND ICogc2l6ZW9mKHN0cnVjdCBSeERlc2MpKQpAQCAtMzQ3LDYgKzM1NCw5IEBAIHN0YXRpYyBpbnQg cnRsODE2OV9jbG9zZShzdHJ1Y3QgbmV0X2RldmkKIHN0YXRpYyB2b2lkIHJ0bDgxNjlfc2V0X3J4 X21vZGUoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CiBzdGF0aWMgdm9pZCBydGw4MTY5X3R4X3Rp bWVvdXQoc3RydWN0IG5ldF9kZXZpY2UgKmRldik7CiBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vf c3RhdHMgKnJ0bDgxNjlfZ2V0X3N0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpuZXRkZXYpOworI2lm ZGVmIENPTkZJR19SODE2OV9OQVBJCitzdGF0aWMgaW50IHJ0bDgxNjlfcG9sbChzdHJ1Y3QgbmV0 X2RldmljZSAqZGV2LCBpbnQgKmJ1ZGdldCk7CisjZW5kaWYKIAogc3RhdGljIGNvbnN0IHUxNiBy dGw4MTY5X2ludHJfbWFzayA9CiAgICAgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBSeEZJRk9P dmVyIHwgVHhFcnIgfCBUeE9LIHwgUnhFcnIgfCBSeE9LOwpAQCAtODQwLDYgKzg1MCwxMSBAQCBy dGw4MTY5X2luaXRfb25lKHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBjCiAJZGV2LT5pcnEgPSBwZGV2 LT5pcnE7CiAJZGV2LT5iYXNlX2FkZHIgPSAodW5zaWduZWQgbG9uZykgaW9hZGRyOwogLy8gICAg ICBkZXYtPmRvX2lvY3RsICAgICAgICAgICA9IG1paV9pb2N0bDsKKyNpZmRlZiBDT05GSUdfUjgx NjlfTkFQSQorCWRldi0+cG9sbCA9IHJ0bDgxNjlfcG9sbDsKKwlkZXYtPndlaWdodCA9IFI4MTY5 X05BUElfV0VJR0hUOworCXByaW50ayhLRVJOX0lORk8gInI4MTY5IE5BUEkgZW5hYmxlZFxuIik7 CisjZW5kaWYKIAogCXRwID0gZGV2LT5wcml2OwkJLy8gcHJpdmF0ZSBkYXRhIC8vCiAJdHAtPnBj aV9kZXYgPSBwZGV2OwpAQCAtMTMwOSw2ICsxMzI0LDcgQEAgcnRsODE2OV90eF90aW1lb3V0KHN0 cnVjdCBuZXRfZGV2aWNlICpkZQogCXZvaWQgKmlvYWRkciA9IHRwLT5tbWlvX2FkZHI7CiAJdTgg dG1wODsKIAorCXByaW50ayhLRVJOX0lORk8gIiVzOiBUWCBUaW1lb3V0XG4iLCBkZXYtPm5hbWUp OwogCS8qIGRpc2FibGUgVHgsIGlmIG5vdCBhbHJlYWR5ICovCiAJdG1wOCA9IFJUTF9SOChDaGlw Q21kKTsKIAlpZiAodG1wOCAmIENtZFR4RW5iKQpAQCAtMTQ0NSwxMiArMTQ2MSwyMiBAQCBzdGF0 aWMgaW5saW5lIGludCBydGw4MTY5X3RyeV9yeF9jb3B5KHN0CiAJcmV0dXJuIHJldDsKIH0KIAot c3RhdGljIHZvaWQKK3N0YXRpYyBpbmxpbmUgdm9pZCBydGw4MTY5X3J4X3NrYihzdHJ1Y3Qgc2tf YnVmZiAqc2tiKQoreworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisJbmV0aWZfcmVjZWl2ZV9z a2Ioc2tiKTsJCQkKKyNlbHNlCisJbmV0aWZfcngoc2tiKTsKKyNlbmRpZgorfQorCitzdGF0aWMg aW50IAogcnRsODE2OV9yeF9pbnRlcnJ1cHQoc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0 IHJ0bDgxNjlfcHJpdmF0ZSAqdHAsCiAJCSAgICAgdm9pZCAqaW9hZGRyKQogewogCXVuc2lnbmVk IGxvbmcgY3VyX3J4LCByeF9sZWZ0OwogCWludCBkZWx0YTsKKwl1MzIgY291bnQgPSAwOwogCiAJ YXNzZXJ0KGRldiAhPSBOVUxMKTsKIAlhc3NlcnQodHAgIT0gTlVMTCk7CkBAIC0xNDU4LDYgKzE0 ODQsOSBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqCiAKIAljdXJf cnggPSB0cC0+Y3VyX3J4OwogCXJ4X2xlZnQgPSBOVU1fUlhfREVTQyArIHRwLT5kaXJ0eV9yeCAt IGN1cl9yeDsKKyNpZmRlZiBDT05GSUdfUjgxNjlfTkFQSQorCXJ4X2xlZnQgPSBtaW4ocnhfbGVm dCwgKHVuc2lnbmVkIGxvbmcpIGRldi0+cXVvdGEpOworI2VuZGlmCiAKIAl3aGlsZSAocnhfbGVm dCA+IDApIHsKIAkJaW50IGVudHJ5ID0gY3VyX3J4ICUgTlVNX1JYX0RFU0M7CkBAIC0xNDk3LDcg KzE1MjYsNyBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqCiAKIAkJ CXNrYl9wdXQoc2tiLCBwa3Rfc2l6ZSk7CiAJCQlza2ItPnByb3RvY29sID0gZXRoX3R5cGVfdHJh bnMoc2tiLCBkZXYpOwotCQkJbmV0aWZfcngoc2tiKTsKKwkJCXJ0bDgxNjlfcnhfc2tiKHNrYik7 CiAKIAkJCWRldi0+bGFzdF9yeCA9IGppZmZpZXM7CiAJCQl0cC0+c3RhdHMucnhfYnl0ZXMgKz0g cGt0X3NpemU7CkBAIC0xNTA2LDE1ICsxNTM1LDE3IEBAIHJ0bDgxNjlfcnhfaW50ZXJydXB0KHN0 cnVjdCBuZXRfZGV2aWNlICoKIAkJCiAJCWN1cl9yeCsrOyAKIAkJcnhfbGVmdC0tOworCQljb3Vu dCsrOwogCX0KIAogCXRwLT5jdXJfcnggPSBjdXJfcng7CiAKIAlkZWx0YSA9IHJ0bDgxNjlfcnhf ZmlsbCh0cCwgZGV2LCB0cC0+ZGlydHlfcngsIHRwLT5jdXJfcngpOwotCWlmIChkZWx0YSA+IDAp Ci0JCXRwLT5kaXJ0eV9yeCArPSBkZWx0YTsKLQllbHNlIGlmIChkZWx0YSA8IDApCisJaWYgKGRl bHRhIDwgMCkgewogCQlwcmludGsoS0VSTl9JTkZPICIlczogbm8gUnggYnVmZmVyIGFsbG9jYXRl ZFxuIiwgZGV2LT5uYW1lKTsKKwkJZGVsdGEgPSAwOworCX0KKwl0cC0+ZGlydHlfcnggKz0gZGVs dGE7CiAKIAkvKgogCSAqIEZJWE1FOiB1bnRpbCB0aGVyZSBpcyBwZXJpb2RpYyB0aW1lciB0byB0 cnkgYW5kIHJlZmlsbCB0aGUgcmluZywKQEAgLTE1MjUsNiArMTU1Niw4IEBAIHJ0bDgxNjlfcnhf aW50ZXJydXB0KHN0cnVjdCBuZXRfZGV2aWNlICoKIAkgKi8KIAlpZiAodHAtPmRpcnR5X3J4ICsg TlVNX1JYX0RFU0MgPT0gdHAtPmN1cl9yeCkKIAkJcHJpbnRrKEtFUk5fRU1FUkcgIiVzOiBSeCBi dWZmZXJzIGV4aGF1c3RlZFxuIiwgZGV2LT5uYW1lKTsKKworCXJldHVybiBjb3VudDsKIH0KIAog LyogVGhlIGludGVycnVwdCBoYW5kbGVyIGRvZXMgYWxsIG9mIHRoZSBSeCB0aHJlYWQgd29yayBh bmQgY2xlYW5zIHVwIGFmdGVyIHRoZSBUeCB0aHJlYWQuICovCkBAIC0xNTU4LDcgKzE1OTEsMTkg QEAgcnRsODE2OV9pbnRlcnJ1cHQoaW50IGlycSwgdm9pZCAqZGV2X2lucwogCiAJCS8vIFJ4IGlu dGVycnVwdCAKIAkJaWYgKHN0YXR1cyAmIChSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cg fCBSeEZJRk9PdmVyKSkgeworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisJCQlpZiAobmV0aWZf cnhfc2NoZWR1bGVfcHJlcChkZXYpKSB7CisJCQkJUlRMX1cxNihJbnRyTWFzaywgcnRsODE2OV9p bnRyX21hc2sgfCAKKwkJCQkJfihSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBSeEZJ Rk9PdmVyKSk7CisJCQkJX19uZXRpZl9yeF9zY2hlZHVsZShkZXYpOworCQkJfSBlbHNlIHsKKwkJ CQlwcmludGsoS0VSTl9JTkZPICJkcml2ZXIgYnVnISBpbnRlcnJ1cHQgd2hpbGUgaW4gcG9sbFxu Iik7CQorCQkJCVJUTF9XMTYoSW50ck1hc2ssIHJ0bDgxNjlfaW50cl9tYXNrIHwgCisJCQkJCX4o UnhPSyB8IFJ4VW5kZXJydW4gfCBSeE92ZXJmbG93IHwgUnhGSUZPT3ZlcikpOworCQkJfQorI2Vs c2UKIAkJCXJ0bDgxNjlfcnhfaW50ZXJydXB0KGRldiwgdHAsIGlvYWRkcik7CisjZW5kaWYKIAkJ fQogCQkvLyBUeCBpbnRlcnJ1cHQKIAkJaWYgKHN0YXR1cyAmIChUeE9LIHwgVHhFcnIpKSB7CkBA IC0xNjkyLDYgKzE3MzcsMzEgQEAgc3RhdGljIHN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpydGw4 MTY5XwogCXJldHVybiAmdHAtPnN0YXRzOwogfQogCisjaWZkZWYgQ09ORklHX1I4MTY5X05BUEkK K3N0YXRpYyBpbnQgcnRsODE2OV9wb2xsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCAqYnVk Z2V0KQoreworCXUzMiBzdGF0dXMsIHdvcmtfZG9uZSA9IDAsIHdvcmtfdG9fZG8gPSBtaW4oKmJ1 ZGdldCwgZGV2LT5xdW90YSk7CisJc3RydWN0IHJ0bDgxNjlfcHJpdmF0ZSAqdHAgPSBkZXYtPnBy aXY7CisJdm9pZCAqaW9hZGRyID0gdHAtPm1taW9fYWRkcjsKKwkKKwl3b3JrX2RvbmUgPSBydGw4 MTY5X3J4X2ludGVycnVwdChkZXYsIHRwLCBpb2FkZHIpOworCQorCSpidWRnZXQgLT0gd29ya19k b25lOworCWRldi0+cXVvdGEgLT0gd29ya19kb25lOworCQorCWlmICgod29ya19kb25lIDwgd29y a190b19kbykgfHwgIW5ldGlmX3J1bm5pbmcoZGV2KSkgeworCQluZXRpZl9yeF9jb21wbGV0ZShk ZXYpOworCQlzdGF0dXMgPSBSVExfUjE2KEludHJTdGF0dXMpOworCQlpZiAoIXN0YXR1cykgewor CQkJUlRMX1cxNihJbnRyTWFzaywgcnRsODE2OV9pbnRyX21hc2spOworCQkJc3RhdHVzID0gUlRM X1IxNihJbnRyTWFzayk7CisJCX0JCisJfQorCisJcmV0dXJuICh3b3JrX2RvbmUgPj0gd29ya190 b19kbyk7Cit9CisjZW5kaWYKKwogc3RhdGljIHN0cnVjdCBwY2lfZHJpdmVyIHJ0bDgxNjlfcGNp X2RyaXZlciA9IHsKIAkubmFtZQkJPSBNT0RVTEVOQU1FLAogCS5pZF90YWJsZQk9IHJ0bDgxNjlf cGNpX3RibCwK --=_mixed 005967D286256E7E_= Content-Type: application/octet-stream; name="Kconfig.diff" Content-Disposition: attachment; filename="Kconfig.diff" Content-Transfer-Encoding: base64 LS0tIEtjb25maWcub3JpZwkyMDA0LTA0LTIwIDEwOjMxOjE4LjY1MzQzMTkyMCAtMDUwMAorKysg S2NvbmZpZwkyMDA0LTA0LTIwIDEwOjMwOjA0Ljg4MTY0NjkzNiAtMDUwMApAQCAtMTk2Miw2ICsx OTYyLDEwIEBAIGNvbmZpZyBSODE2OQogCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1v ZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlIG1vZHVsZQogCSAgd2lsbCBiZSBjYWxsZWQgcjgxNjku ICBUaGlzIGlzIHJlY29tbWVuZGVkLgogCitjb25maWcgUjgxNjlfTkFQSQorCWJvb2wgIlVzZSBS eCBQb2xsaW5nIChOQVBJKSAoRVhQRVJJTUVOVEFMKSIKKwlkZXBlbmRzIG9uIFI4MTY5ICYmIEVY UEVSSU1FTlRBTCAKKwkKIGNvbmZpZyBTSzk4TElOCiAJdHJpc3RhdGUgIk1hcnZlbGwgWXVrb24g Q2hpcHNldCAvIFN5c0tvbm5lY3QgU0stOTh4eCBTdXBwb3J0IgogCWRlcGVuZHMgb24gUENJCg== --=_mixed 005967D286256E7E_=-- From vonbrand@inf.utfsm.cl Thu Apr 22 10:39:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 10:39:36 -0700 (PDT) Received: from inti.inf.utfsm.cl (inti.inf.utfsm.cl [200.1.21.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MHdPKO025988 for ; Thu, 22 Apr 2004 10:39:27 -0700 Received: from eeyore.valparaiso.cl (laptop16.inf.utfsm.cl [200.1.19.250]) by inti.inf.utfsm.cl (8.12.10/8.12.10) with ESMTP id i3MHcihk011356; Thu, 22 Apr 2004 13:38:44 -0400 Received: from eeyore.valparaiso.cl (localhost.localdomain [127.0.0.1]) by eeyore.valparaiso.cl (8.12.10/8.12.10) with ESMTP id i3MHciO9005239; Thu, 22 Apr 2004 13:38:44 -0400 Received: from eeyore.valparaiso.cl (vonbrand@localhost) by eeyore.valparaiso.cl (8.12.10/8.12.10/Submit) with ESMTP id i3MHcg7J005234; Thu, 22 Apr 2004 13:38:43 -0400 Message-Id: <200404221738.i3MHcg7J005234@eeyore.valparaiso.cl> To: alex@pilosoft.com Cc: jamal , Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: Your message of "Thu, 22 Apr 2004 11:27:05 -0400." X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Thu, 22 Apr 2004 13:38:42 -0400 From: Horst von Brand X-archive-position: 4856 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vonbrand@inf.utfsm.cl Precedence: bulk X-list: netdev Content-Length: 1536 Lines: 29 alex@pilosoft.com said: > > > > Unless i misunderstood: You need someone/thing to see about 64K > > > > packets within a single flow to make the predicition so the attack > > > > is succesful. Sure to have access to such capability is to be in a > > > > hostile path, no? ;-> > > > No, you do not need to see any packet. > > Ok, so i misunderstood then. How do you predict the sequences without > > seeing any packet? Is there any URL to mentioned paper? > You don't - just brute-force the tcp 4-tuple and sequence number. The > attack relies on the fact that you don't have to match sequence number > exactly, which cuts down on the search-space. (If total search space is > 2^32, rwin is 16k, effective attack search space is 2^32/16k). Multiplied > by number of ephemeral ports, it becomes *feasible* but still not very > likely. If everybody (or at least the bigger knots) filters spoofed traffic, this ceases to be a problem. And that solves a shipload of other problems, so... If the cracker has access to the connection between routers (quite unlikely for BGP), there is other, lower-hanging, fun to be had... and in that case they can just read the exact data from the stream, no guessing needed at all. And no protection possible either AFAICS. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From davem@redhat.com Thu Apr 22 11:39:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 11:39:27 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MIdMKO027254 for ; Thu, 22 Apr 2004 11:39:23 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3MISLKG029252; Thu, 22 Apr 2004 14:28:21 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3MISLp02619; Thu, 22 Apr 2004 14:28:21 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3MIRs1n029848; Thu, 22 Apr 2004 14:27:54 -0400 Date: Thu, 22 Apr 2004 11:28:01 -0700 From: "David S. Miller" To: root@chaos.analogic.com Cc: pochini@shiny.it, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, joern@wohnheim.fh-wedel.de Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-Id: <20040422112801.2a1a4a57.davem@redhat.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4857 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 421 Lines: 15 On Thu, 22 Apr 2004 07:35:54 -0400 (EDT) "Richard B. Johnson" wrote: > Has anybody checked to see what Linux does if it receives a > RST to the broadcast address? It would be a shame if all > connections were dropped! int tcp_v4_rcv(struct sk_buff *skb) { ... if (skb->pkt_type != PACKET_HOST) goto discard_it; Packets which are multicast or broadcast do not get marked as "PACKET_HOST". From syrius.ml@no-log.org Thu Apr 22 12:13:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 12:13:33 -0700 (PDT) Received: from main.uucpssh.org (main.uucpssh.org [212.27.33.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MJDJKO028681 for ; Thu, 22 Apr 2004 12:13:20 -0700 Received: from localhost (localhost [127.0.0.1]) by main.uucpssh.org (Postfix) with ESMTP id 6966335C90; Thu, 22 Apr 2004 19:50:10 +0200 (CEST) Received: by main.uucpssh.org (Postfix, from userid 10) id 3F9E836D05; Thu, 22 Apr 2004 19:50:09 +0200 (CEST) Received: by f.smtp.localhost (Postfix, from userid 1000) id 489DF111; Thu, 22 Apr 2004 19:43:50 +0200 (CEST) To: hadi@cyberus.ca Cc: netdev@oss.sgi.com Subject: Re: IMQ / new Dummy device post. References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> From: syrius.ml@no-log.org Message-ID: <87oepjx65r.87n053x65r@87llknx65r.message.id> Date: Thu, 22 Apr 2004 19:43:50 +0200 In-Reply-To: <1082639764.1059.81.camel@jzny.localdomain> (hadi@cyberus.ca's message of "22 Apr 2004 09:16:04 -0400") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4858 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: syrius.ml@no-log.org Precedence: bulk X-list: netdev Content-Length: 215 Lines: 9 Hi, It oops when using the ingress qdisc + action mirred egress redirect filter on tun0. (no egress at all, no ingress on eth0) It doesn't oops using an ingress qdisc + a simple police+drop filter on tun0... -- From ranjeet.shetye2@zultys.com Thu Apr 22 12:52:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 12:52:46 -0700 (PDT) Received: from mail12.intermedia.net (mail12.intermedia.net [206.40.48.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MJqbKO032383 for ; Thu, 22 Apr 2004 12:52:39 -0700 Received: (qmail 28657 invoked from network); 22 Apr 2004 19:52:31 -0000 Received: from unknown (HELO ranjeet-pc2.zultys.com) (ranjeet.shetye2@zultys.com@67.115.97.3) by 0 with SMTP; 22 Apr 2004 19:52:31 -0000 Subject: Re: tcp vulnerability? haven't seen anything on it here... From: Ranjeet Shetye To: "David S. Miller" Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20040421132047.026ab7f2.davem@redhat.com> References: <40869267.30408@nortelnetworks.com> <4086A077.2000705@nortelnetworks.com> <20040421170340.GB24201@wohnheim.fh-wedel.de> <20040421132047.026ab7f2.davem@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <1082664092.9062.14.camel@ranjeet-pc2.zultys.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 22 Apr 2004 13:01:33 -0700 Content-Transfer-Encoding: 8bit X-archive-position: 4859 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: ranjeet.shetye2@zultys.com Precedence: bulk X-list: netdev Content-Length: 2219 Lines: 58 On Wed, 2004-04-21 at 13:20, David S. Miller wrote: > On Wed, 21 Apr 2004 19:03:40 +0200 > Jörn Engel wrote: > > > Heise.de made it appear, as if the only news was that with tcp > > windows, the propability of guessing the right sequence number is not > > 1:2^32 but something smaller. They said that 64k packets would be > > enough, so guess what the window will be. > > Yes, that is their major discovery. You need to guess the ports > and source/destination addresses as well, which is why I don't > consider this such a serious issue personally. > > It is mitigated if timestamps are enabled, because that becomes > another number you have to guess. > > It is mitigated also by randomized ephemeral port selection, which > OpenBSD implements and we could easily implement as well. > > I'm very happy that OpenBSD checked in a fix for this a week or so > ago and took some of the thunder out of this bogusly hyped announcement. (Not the same issue, but interesting still, and its related) Isn't this (http://www.lowth.com/cutter/) an application on the same lines ? (but from the perspective of a person ON one of the two endpoint machines, rather than a remote third party). QUOTE There is a feature of the TCP/IP protocol that we could use to good effect here :- If a packet (other than an RST) is received on a connection that has the wrong sequence number, then the host responds by sending a corrective "ACK" packet back. This "ACK" reply is designed to put the sequence numbers at both ends back into step - and allows the protocol to retransmit packets that got lost. This is very nice for our needs - if the firewall sends a packet that is "correct" in all respects except for the sequence number, then the host very helpfully tells us what should have been used. We can then use this information to build the RST packet that will abort the connection. END OF QUOTE thanks, -- Ranjeet Shetye Senior Software Engineer Zultys Technologies Ranjeet dot Shetye2 at Zultys dot com http://www.zultys.com/ The views, opinions, and judgements expressed in this message are solely those of the author. The message contents have not been reviewed or approved by Zultys. From root@chaos.analogic.com Thu Apr 22 13:25:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 13:25:28 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MKPNKO000792 for ; Thu, 22 Apr 2004 13:25:24 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i3MKPJs00937; Thu, 22 Apr 2004 16:25:19 -0400 Date: Thu, 22 Apr 2004 16:25:19 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Willy Tarreau cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <20040422141848.GA6986@alpha.home.local> Message-ID: References: <20040422131704.GA6839@alpha.home.local> <20040422141848.GA6986@alpha.home.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4860 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 1560 Lines: 38 On Thu, 22 Apr 2004, Willy Tarreau wrote: > Richard, > > you are confusing several thinks, stateful vs stateless protocols. A ping > doesn't need a session on the remote host to be interpreted. A TCP segment > whose flags don't show a SYN need a session to be interpreted. Please note > that I'm not arguing that you won't crash a linux box with an RST addressed > to a broadcast address, I'm saying that there's absolutely no reason why > this should reset all connections, as you proposed it. Someone would have > had to code this explicitly, it cannot be a simple side effect. > > Imagine that each packet which enters the system is presented to a hash > table containing the sessions, and that its session is looked for into > this hash table. You agree that in such code, there's no reason to find > anything that runs through all sessions and kill everyone, since this > code has no use there, and has no reason to be implemented on purpose ! > > Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for > example. When it reaches tcp_v4_lookup_established(), you find this : > > for(sk = head->chain; sk; sk = sk->next) { > if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) > goto hit; /* You sunk my battleship! */ > } > > You cannot match more than once. [SNIPPED...] So you are sure an attacker will fire only one bullet? Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). Note 96.31% of all statistics are fiction. From andre.correa@pobox.com Thu Apr 22 13:52:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 13:52:48 -0700 (PDT) Received: from puzzle.pobox.com (puzzle.pobox.com [207.8.214.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MKqhKO001853 for ; Thu, 22 Apr 2004 13:52:44 -0700 Received: from colander (localhost [127.0.0.1]) by puzzle.pobox.com (Postfix) with ESMTP id 5DB3E1322B2 for ; Thu, 22 Apr 2004 16:52:41 -0400 (EDT) Received: from jester.pobox.com (jester.pobox.com [64.71.166.114]) by puzzle.pobox.com (Postfix) with ESMTP for ; Thu, 22 Apr 2004 16:52:02 -0400 (EDT) Received: from pobox.com (unknown [200.150.240.34]) by jester.pobox.com (Postfix) with ESMTP id AA2D39E for ; Thu, 22 Apr 2004 16:51:24 -0400 (EDT) Message-ID: <4088303A.2080208@pobox.com> Date: Thu, 22 Apr 2004 17:51:06 -0300 From: Andre Correa User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: netdev@oss.sgi.com Subject: nf_unregister_hook crashing kernel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4861 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andre.correa@pobox.com Precedence: bulk X-list: netdev Content-Length: 1642 Lines: 73 Hi list, I'm playing with a module that uses netfilter hooks. It register using nf_register_hook without problems, but when I try nf_unregister_hook in my "cleanup" function the kernel crashs. I've found that it crashs calling nf_unregister_hook, but have no idea how to debug it further... Here goes some snips from my code. Nothing new. I've searched other modules and found that everybody makes the same. ...... static nf_hookfn my_nf_hook; static struct nf_hook_ops my_ingress_ipv4 = { .hook = my_nf_hook, .owner = THIS_MODULE, .pf = PF_INET, .hooknum = NF_IP_PRE_ROUTING, .priority = NF_IP_PRI_MANGLE + 1 }; ...... static unsigned int my_nf_hook(unsigned int hook, struct sk_buff **pskb, const struct net_device *indev, const struct net_device *outdev, int (*okfn)(struct sk_buff *)) { if ((*pskb)->my_flags & MY_F_ENQUEUE) return NF_QUEUE; return NF_ACCEPT; } ...... static int __init my_init_hooks(void) { int err; if ((err = nf_register_queue_handler(PF_INET, my_nf_queue, NULL))) return err; } ....... static void __exit my_unhook(void) { nf_unregister_hook(&my_ingress_ipv4); } ...... module_init(my_init_module); module_exit(my_cleanup_module); MODULE_LICENSE("GPL"); Like I said, nothing new. Is there anybody who can give me some info on how/when can nf_unregister_hook crash the kernel? How can I debug some more?! Tks in advance for any help. Andre From kumarkr@us.ibm.com Thu Apr 22 14:10:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 14:10:53 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MLAgKO002459 for ; Thu, 22 Apr 2004 14:10:49 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MLAUnU667734; Thu, 22 Apr 2004 17:10:30 -0400 Received: from d03nm132.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MLATnZ162304; Thu, 22 Apr 2004 15:10:29 -0600 Subject: Re: nf_unregister_hook crashing kernel To: Andre Correa Cc: netdev@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Krishna Kumar Date: Thu, 22 Apr 2004 14:08:04 -0700 X-MIMETrack: Serialize by Router on D03NM132/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/22/2004 15:10:29 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493" X-archive-position: 4863 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kumarkr@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 10159 Lines: 290 --0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: multipart/alternative; Boundary="1__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493" --1__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: text/plain; charset=US-ASCII If you do a nf_register_queue_handler, you need nf_unregister_queue_handler. Can't mix and match :-) Basically what is happening is that your list is not initialized (actually set to NULL being global), and when you do a de-register, it panics. - KK |---------+----------------------------> | | Andre Correa | | | | | | Sent by: | | | netdev-bounce@oss| | | .sgi.com | | | | | | | | | 04/22/2004 04:51 | | | PM | | | | |---------+----------------------------> >-------------------------------------------------------------------------------------------------------------------------| | | | To: netdev@oss.sgi.com | | cc: | | Subject: nf_unregister_hook crashing kernel | | | >-------------------------------------------------------------------------------------------------------------------------| Hi list, I'm playing with a module that uses netfilter hooks. It register using nf_register_hook without problems, but when I try nf_unregister_hook in my "cleanup" function the kernel crashs. I've found that it crashs calling nf_unregister_hook, but have no idea how to debug it further... Here goes some snips from my code. Nothing new. I've searched other modules and found that everybody makes the same. ...... static nf_hookfn my_nf_hook; static struct nf_hook_ops my_ingress_ipv4 = { .hook = my_nf_hook, .owner = THIS_MODULE, .pf = PF_INET, .hooknum = NF_IP_PRE_ROUTING, .priority = NF_IP_PRI_MANGLE + 1 }; ...... static unsigned int my_nf_hook(unsigned int hook, struct sk_buff **pskb, const struct net_device *indev, const struct net_device *outdev, int (*okfn)(struct sk_buff *)) { if ((*pskb)->my_flags & MY_F_ENQUEUE) return NF_QUEUE; return NF_ACCEPT; } ...... static int __init my_init_hooks(void) { int err; if ((err = nf_register_queue_handler(PF_INET, my_nf_queue, NULL))) return err; } ....... static void __exit my_unhook(void) { nf_unregister_hook(&my_ingress_ipv4); } ...... module_init(my_init_module); module_exit(my_cleanup_module); MODULE_LICENSE("GPL"); Like I said, nothing new. Is there anybody who can give me some info on how/when can nf_unregister_hook crash the kernel? How can I debug some more?! Tks in advance for any help. Andre --1__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

If you do a nf_register_queue_handler, you need nf_unregister_queue_handler. Can't mix
and match :-) Basically what is happening is that your list is not initialized (actually set to
NULL being global), and when you do a de-register, it panics.

- KK

Inactive hide details for Andre Correa <andre.correa@pobox.com>Andre Correa <andre.correa@pobox.com>




          Andre Correa <andre.correa@pobox.com>
          Sent by: netdev-bounce@oss.sgi.com

          04/22/2004 04:51 PM



To: netdev@oss.sgi.com
cc:
Subject: nf_unregister_hook crashing kernel



Hi list, I'm playing with a module that uses netfilter hooks. It
register using nf_register_hook without problems, but when I try
nf_unregister_hook in my "cleanup" function the kernel crashs. I've
found that it crashs calling nf_unregister_hook, but have no idea how to
debug it further...

Here goes some snips from my code. Nothing new. I've searched other
modules and found that everybody makes the same.


...<snip>...

static nf_hookfn my_nf_hook;


static struct nf_hook_ops my_ingress_ipv4 = {
.hook = my_nf_hook,
.owner = THIS_MODULE,
.pf = PF_INET,
.hooknum = NF_IP_PRE_ROUTING,
.priority = NF_IP_PRI_MANGLE + 1
};

...<snip>...

static unsigned int my_nf_hook(unsigned int hook, struct sk_buff **pskb,
const struct net_device *indev,
const struct net_device *outdev,
int (*okfn)(struct sk_buff *))
{
if ((*pskb)->my_flags & MY_F_ENQUEUE)
return NF_QUEUE;


return NF_ACCEPT;
}

...<snip>...

static int __init my_init_hooks(void)
{
int err;


if ((err = nf_register_queue_handler(PF_INET, my_nf_queue, NULL)))
return err;
}

...<snip>....

static void __exit my_unhook(void)
{

nf_unregister_hook(&my_ingress_ipv4);
}

...<snip>...

module_init(my_init_module);
module_exit(my_cleanup_module);
MODULE_LICENSE("GPL");


Like I said, nothing new. Is there anybody who can give me some info on
how/when can nf_unregister_hook crash the kernel? How can I debug some
more?!

Tks in advance for any help.

Andre



 --1__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493-- --0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=07BBE4EDDFE064938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=07BBE4EDDFE064938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493 Content-type: image/gif; name="pic14315.gif" Content-Disposition: inline; filename="pic14315.gif" Content-ID: <30__=07BBE4EDDFE064938f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBE4EDDFE064938f9e8a93df938690918c07BBE4EDDFE06493-- From w@w.ods.org Thu Apr 22 14:10:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 14:10:42 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MLAaKO002458 for ; Thu, 22 Apr 2004 14:10:37 -0700 Date: Thu, 22 Apr 2004 23:08:39 +0200 From: Willy Tarreau To: "Richard B. Johnson" Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... Message-ID: <20040422210839.GA8142@alpha.home.local> References: <20040422131704.GA6839@alpha.home.local> <20040422141848.GA6986@alpha.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 4862 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: w@w.ods.org Precedence: bulk X-list: netdev Content-Length: 2260 Lines: 48 On Thu, Apr 22, 2004 at 04:25:19PM -0400, Richard B. Johnson wrote: > On Thu, 22 Apr 2004, Willy Tarreau wrote: > > > Richard, > > > > you are confusing several thinks, stateful vs stateless protocols. A ping > > doesn't need a session on the remote host to be interpreted. A TCP segment > > whose flags don't show a SYN need a session to be interpreted. Please note > > that I'm not arguing that you won't crash a linux box with an RST addressed > > to a broadcast address, I'm saying that there's absolutely no reason why > > this should reset all connections, as you proposed it. Someone would have > > had to code this explicitly, it cannot be a simple side effect. > > > > Imagine that each packet which enters the system is presented to a hash > > table containing the sessions, and that its session is looked for into > > this hash table. You agree that in such code, there's no reason to find > > anything that runs through all sessions and kill everyone, since this > > code has no use there, and has no reason to be implemented on purpose ! > > > > Look at functions such as tcp_v4_lookup() in net/ipv4/tcp_ipv4.c for > > example. When it reaches tcp_v4_lookup_established(), you find this : > > > > for(sk = head->chain; sk; sk = sk->next) { > > if(TCP_IPV4_MATCH(sk, acookie, saddr, daddr, ports, dif)) > > goto hit; /* You sunk my battleship! */ > > } > > > > You cannot match more than once. > > [SNIPPED...] > > So you are sure an attacker will fire only one bullet? I don't see where you want to go. An attacker will have to fire at least one "bullet" per port, per sequence number block and per timestamp if any. That's the basis of the protocol. You were asking if *one* packet sent to a broadcast address could reset *every* TCP connections, David showed you that broadcasts were dropped, and I showed you that you need as many packets as possible combinations to shoot all connections. That's all. And BTW, do you think that such a "serious" vulnerability wouldn't have been demonstrated on live sites if it was so obvious ? Don't worry, we still have a few years in front of us before home networks are fast enough to scan such large ranges in a matter of days. Cheers, Willy From fw@deneb.enyo.de Thu Apr 22 14:15:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 14:15:33 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MLFSKO003188 for ; Thu, 22 Apr 2004 14:15:29 -0700 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGlXV-00078q-Jh; Thu, 22 Apr 2004 23:15:21 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGlXV-0000NB-EJ; Thu, 22 Apr 2004 23:15:21 +0200 To: Horst von Brand Cc: Linux Kernel Mailing List , netdev@oss.sgi.com Subject: Re: tcp vulnerability? haven't seen anything on it here... References: <200404221738.i3MHcg7J005234@eeyore.valparaiso.cl> From: Florian Weimer Date: Thu, 22 Apr 2004 23:15:21 +0200 In-Reply-To: <200404221738.i3MHcg7J005234@eeyore.valparaiso.cl> (Horst von Brand's message of "Thu, 22 Apr 2004 13:38:42 -0400") Message-ID: <87r7ufu32u.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4864 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: netdev Content-Length: 641 Lines: 15 Horst von Brand writes: > If everybody (or at least the bigger knots) filters spoofed traffic, > this ceases to be a problem. And that solves a shipload of other > problems, so... There isn't much incentive to deploy filters so that other people don't suffer. So it takes a long time until it's almost universally implemented. (We catch less backscatter from DDoS attacks than a few years ago, so the situation may actually be improving.) -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. From sri@us.ibm.com Thu Apr 22 14:26:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 14:27:01 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MLQoKO003636 for ; Thu, 22 Apr 2004 14:26:57 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3MLQjpj351222; Thu, 22 Apr 2004 17:26:45 -0400 Received: from w-sridhar.beaverton.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3MLQicN376400; Thu, 22 Apr 2004 15:26:44 -0600 Date: Thu, 22 Apr 2004 14:26:43 -0700 (PDT) From: Sridhar Samudrala X-X-Sender: sridhar@localhost.localdomain To: "David S. Miller" cc: =?ISO-8859-1?Q?J=F6rn?= Engel , cfriesen@nortelnetworks.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <20040421132047.026ab7f2.davem@redhat.com> Message-ID: References: <40869267.30408@nortelnetworks.com> <4086A077.2000705@nortelnetworks.com> <20040421170340.GB24201@wohnheim.fh-wedel.de> <20040421132047.026ab7f2.davem@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id i3MLQoKO003636 X-archive-position: 4865 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sri@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1492 Lines: 39 On Wed, 21 Apr 2004, David S. Miller wrote: > On Wed, 21 Apr 2004 19:03:40 +0200 > Jörn Engel wrote: > > > Heise.de made it appear, as if the only news was that with tcp > > windows, the propability of guessing the right sequence number is not > > 1:2^32 but something smaller. They said that 64k packets would be > > enough, so guess what the window will be. > > Yes, that is their major discovery. You need to guess the ports > and source/destination addresses as well, which is why I don't > consider this such a serious issue personally. > > It is mitigated if timestamps are enabled, because that becomes > another number you have to guess. I am not sure if enabling timestamps will help. From RFC1323, It is recommended that RST segments NOT carry timestamps, and that RST segments be acceptable regardless of their timestamp. Old duplicate RST segments should be exceedingly unlikely, and their cleanup function should take precedence over timestamps. It looks like linux follows this recommendataion. tcp_input.c: tcp_rcv_established() if (tcp_fast_parse_options(skb, th, tp) && tp->saw_tstamp && tcp_paws_discard(tp, skb)) { if (!th->rst) { NET_INC_STATS_BH(PAWSEstabRejected); tcp_send_dupack(sk, skb); goto discard; } /* Reset is accepted even if it did not pass PAWS. */ } Thanks Sridhar From romieu@fr.zoreil.com Thu Apr 22 17:20:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 17:20:50 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N0KaKO010031 for ; Thu, 22 Apr 2004 17:20:37 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3MNIauX005477; Fri, 23 Apr 2004 01:18:36 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3MNIYjP005476; Fri, 23 Apr 2004 01:18:34 +0200 Date: Fri, 23 Apr 2004 01:18:34 +0200 From: Francois Romieu To: Jon D Mason Cc: jgarzik@pobox.com, netdev@oss.sgi.com Subject: Re: [PATCH] r8169 NAPI addition Message-ID: <20040423011834.A3232@electric-eye.fr.zoreil.com> References: <20040420234524.A1374@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jonmason@us.ibm.com on Thu, Apr 22, 2004 at 10:20:58AM -0600 X-Organisation: Land of Sunshine Inc. X-archive-position: 4866 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1755 Lines: 54 Jon D Mason : [...] --- r8169.c 2004-04-18 22:51:33.000000000 -0500 +++ r8169.c 2004-04-22 08:08:57.526577048 -0500 [...] @@ -1692,6 +1737,31 @@ static struct net_device_stats *rtl8169_ return &tp->stats; } +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget) +{ + u32 status, work_done = 0, work_to_do = min(*budget, dev->quota); + struct rtl8169_private *tp = dev->priv; + void *ioaddr = tp->mmio_addr; + + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); + + *budget -= work_done; + dev->quota -= work_done; + + if ((work_done < work_to_do) || !netif_running(dev)) { Packets are received here. Tx interrupt is issued. --> Interrupts status register is completely cleared by the irq handler <-- There are pending Rx packets. r8169_poll() is not activated by the irq handler. -> Pending Rx packets may wait long. + netif_rx_complete(dev); + status = RTL_R16(IntrStatus); + if (!status) { + RTL_W16(IntrMask, rtl8169_intr_mask); + status = RTL_R16(IntrMask); + } The previous lines imply that if, according to IntrStatus, there is pending Rx work but no pending Tx work, the Rx interrupts are kept disabled. If I am not mistaken (1:55 AM here), either 1) you do not clear the RX related bits of IntrStatus in r8169_interrupt() but you clear it in rtl8169_poll() and you add local_irq_{en/dis}able() to rtl8169_poll() (ala 8139cp.c) or 2) you modify r8169_interrupt() so that it can signal to rtl8169_poll() that it cleared itself the Rx bits of IntrStatus whereas rtl8169_poll() was running (ala epic100-netdev). If you hesitate, go for 1). 2) works but I have not benchmarketed it yet :o) If you have doubts regarding your Tx part, feel free to send any code. -- Ueimor From modica@sgi.com Thu Apr 22 20:12:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 22 Apr 2004 20:12:54 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N3CnKO013352 for ; Thu, 22 Apr 2004 20:12:49 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3N3BUhv031655 for ; Thu, 22 Apr 2004 20:11:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by spindle.corp.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i3N3BTO114392963 for ; Thu, 22 Apr 2004 20:11:30 -0700 (PDT) Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3MEC8Ke37416055; Thu, 22 Apr 2004 09:12:08 -0500 (CDT) Received: from sgi.com (cf-vpn-sw-corp-64-70.corp.sgi.com [134.15.64.70]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3MEBmXa4886135; Thu, 22 Apr 2004 09:11:54 -0500 (CDT) Message-ID: <4087D29E.6010907@sgi.com> Date: Thu, 22 Apr 2004 09:11:42 -0500 From: Steve Modica User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Pankratov CC: "David S. Miller" , netdev@oss.sgi.com, Michael Rozhavsky Subject: Re: RST business References: <40875F2F.7010204@swapped.cc> In-Reply-To: <40875F2F.7010204@swapped.cc> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4867 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: modica@sgi.com Precedence: bulk X-list: netdev Content-Length: 2375 Lines: 64 If one of the potential causes for RST is that SEQ/ACK synchronization has been lost, then you can't do this. Alex Pankratov wrote: > > Looking at the hype around 'TCP vulnerability' the following > occured to me, and I wonder if it makes any sense - > > A host may recieve legitimate RST packet only in response to > something that it has previously sent (let's call it a 'trigger'). > > SEQ/ACK values in RST packet are correlated to SEQ/ACK of the > trigger. If the correlation is not there, then RST packet is > most certainly spoofed and should be dropped even if its SEQ > falls into host's rcpt window. > > In other words, it seems to be possible to stregthen ingress > RST checking (and thus better protect against blind RST attacks) > while maintaining _full RFC compliance_. Here's a how-to sketch. > > RFC 793 (page 35) states that for the connection in > non-established state - > > If the incoming segment has an ACK field, the reset takes its > sequence number from the ACK field of the segment, otherwise > the reset has sequence number zero and the ACK field is set to > the sum of the sequence number and segment length of the incoming > segment. > > Hence the second RST check (after standard window check) is > > if (! pkt->seq) > check if we've recently sent a segment without > an ACK with (pkt->ack - pkt->seq) bytes in it > else > check if we've recently sent a segment with ACK > of (pkt->seq) and with (pkt->ack - pkt->seq) > bytes in it > > If RST passes the check, it's accepted. Otherwise checks continue. > > RFC 793 (page 36) states that for the connection in > established state - > > .. elicit only an empty > acknowledgment segment containing the current send-sequence number > and an acknowledgment indicating the next sequence number expected > to be received .. > > At this point seeing a RST means that > (a) remote host is an ESTABLISHED state > (b) we sent a segment that it considers not to be a part of the > current connection > > And (b) is something that we can always check since we're now sure > about (a). > > The above obviously requires keeping some sort of 'outbound history', > plus (b) involves some non-trivial logic, which however seems to be > doable from the first glance. > > Comments ? > > Alex From fw@deneb.enyo.de Fri Apr 23 03:31:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 03:31:12 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NAV6KO031591 for ; Fri, 23 Apr 2004 03:31:07 -0700 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BGxxX-0002iW-9W; Fri, 23 Apr 2004 12:31:03 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BGxxW-0005fC-F5; Fri, 23 Apr 2004 12:31:02 +0200 To: alex@pilosoft.com Cc: linux-kernel@vger.kernel.org, Subject: Re: tcp vulnerability? haven't seen anything on it here... References: From: Florian Weimer Date: Fri, 23 Apr 2004 12:31:02 +0200 In-Reply-To: (alex@pilosoft.com's message of "Thu, 22 Apr 2004 10:37:42 -0400 (EDT)") Message-ID: <87smevrno9.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4869 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: netdev Content-Length: 567 Lines: 14 alex@pilosoft.com writes: > Not quite. With a SYN you have to respond with exactly the same sequence > number as attacking host in order to establish connection. With RST, your > sequence number needs to be +- rwin in order to kill the connection. That > significantly reduces search space. Don't forget that you can tear down a connection by sending a SYN in the correct window as well. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. From hadi@cyberus.ca Fri Apr 23 04:29:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 04:29:47 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NBThKO004484 for ; Fri, 23 Apr 2004 04:29:43 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BGysb-0006dD-Fo for netdev@oss.sgi.com; Fri, 23 Apr 2004 07:30:01 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BGysD-0008Ay-3b; Fri, 23 Apr 2004 07:29:37 -0400 Subject: Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: syrius.ml@no-log.org Cc: netdev@oss.sgi.com In-Reply-To: <87oepjx65r.87n053x65r@87llknx65r.message.id> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082719745.1057.27.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Apr 2004 07:29:06 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4870 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1095 Lines: 31 Hi there, On Thu, 2004-04-22 at 13:43, syrius.ml@no-log.org wrote: > Hi, > > It oops when using the ingress qdisc + action mirred egress redirect > filter on tun0. (no egress at all, no ingress on eth0) > It doesn't oops using an ingress qdisc + a simple police+drop filter > on tun0... Ok, so you have narrowed it down to mirred, tun and ingress qdisc - is that correct? Were you using openvpn to recreate this? BTW, would this happen if you dont issue the ping -f initially in above setup? If yes, before you send create the problem can you send a few pings through tap device and send me output of dmesg? I just did a simple test with a basic program and couldnt reproduce it. I dont have the proper setup, can you do a basic test with some other tunneling s/ware? The doc for tun mentions: http://vtun.sourceforge.net and http://perso.enst.fr/~beyssac/pipsec/ Please compile in tun and dummy into the kernel. BTW, i think we should take this offline; send your response directly to me. Anyone else interested in this conversation email both of us and we will cc you. cheers, jamal From hadi@cyberus.ca Fri Apr 23 04:58:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 04:59:00 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NBwtKO000565 for ; Fri, 23 Apr 2004 04:58:56 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BGeAa-00034Z-Ej for netdev@oss.sgi.com; Thu, 22 Apr 2004 09:23:12 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BGeAA-0006xr-Vj; Thu, 22 Apr 2004 09:22:47 -0400 Subject: Re: tcp vulnerability? haven't seen anything on it here... From: jamal Reply-To: hadi@cyberus.ca To: Giuliano Pochini Cc: "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?ISO-8859-1?Q?J=F6rn?= Engel In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1082640135.1059.93.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Apr 2004 09:22:16 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4871 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 611 Lines: 20 On Thu, 2004-04-22 at 04:23, Giuliano Pochini wrote: > Yes, but it is possible, expecially for long sessions. In other words, 80% or more of internet traffic would not be affected still using http1.0 would not be affected. And for something like a huge download to just regular joe, this is more of a nuisance assuming some kiddie has access between you and the server. OTOH, long lived BGP sessions are affected assuming you are going across hostile path to your peer. So whats all this ado about nothing? Local media made it appear we are all about to die. Is anyone working on some fix? cheers, jamal From fw@deneb.enyo.de Fri Apr 23 06:55:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 06:55:50 -0700 (PDT) Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NDtiKO005743 for ; Fri, 23 Apr 2004 06:55:45 -0700 Received: (debugging) helo=deneb ip=212.9.189.171 name=deneb.enyo.de Received: from deneb.enyo.de ([212.9.189.171] helo=deneb) by mail.enyo.de with esmtp id 1BH19S-0003xZ-Qj; Fri, 23 Apr 2004 15:55:34 +0200 Received: from fw by deneb with local (Exim 4.32) id 1BH19R-0006AY-TJ; Fri, 23 Apr 2004 15:55:33 +0200 To: hadi@cyberus.ca Cc: Giuliano Pochini , "David S. Miller" , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, cfriesen@nortelnetworks.com, =?iso-8859-1?q?J=F6rn_Engel?= Subject: Re: tcp vulnerability? haven't seen anything on it here... References: <1082640135.1059.93.camel@jzny.localdomain> From: Florian Weimer Date: Fri, 23 Apr 2004 15:55:33 +0200 In-Reply-To: <1082640135.1059.93.camel@jzny.localdomain> (hadi@cyberus.ca's message of "22 Apr 2004 09:22:16 -0400") Message-ID: <87u0zare7e.fsf@deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4872 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fw@deneb.enyo.de Precedence: bulk X-list: netdev Content-Length: 629 Lines: 17 jamal writes: > OTOH, long lived BGP sessions are affected assuming you are going across > hostile path to your peer. Jamal, please forget that "hostile path to your peer" part. It's just wrong. You are entitled to your opinion that this isssue is being overhyped (I tend to share it, at least until some evidence shows up that there's also a 4.4BSD-like RST bug), but please try to understand the issue before making any judgement. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr. From hadi@cyberus.ca Fri Apr 23 07:25:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 07:25:54 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NEPkKO006680 for ; Fri, 23 Apr 2004 07:25:46 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BH1cy-0005gw-V9 for netdev@oss.sgi.com; Fri, 23 Apr 2004 10:26:04 -0400 Received: from [216.209.86.2] (helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BH1cU-00043R-3p; Fri, 23 Apr 2004 10:25:34 -0400 Subject: Re: tcp vulnerability? haven't seen anything on it here... From: jamal Reply-To: hadi@cyberus.ca To: alex@pilosoft.com Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, Florian Weimer In-Reply-To: References: Content-Type: text/plain Organization: jamalopolis Message-Id: <1082730332.1027.57.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Apr 2004 10:25:32 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4873 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1618 Lines: 40 Clarification: I think the latency of my earlier email introduced by probably netdev is creating a lot of "hostile" responses to me ;-> I feel like i am in hostile path here ;-> I sent that email a long time ago, seems like netdev or my ISP decided to deliver it now and reordered the delivery. This has happened to me a few times before with netdev thats why i prefer to cc people whenever i can (worst case they receive more than one message) Consider that message obsolete. I know you can create this problem via brute force as you explained in your later email (that showed up yesterday). cheers, jamal On Fri, 2004-04-23 at 10:15, alex@pilosoft.com wrote: > > And for something like a huge download to just regular joe, this is more > > of a nuisance assuming some kiddie has access between you and the > > server. OTOH, long lived BGP sessions are affected assuming you are > > going across hostile path to your peer. > Again - no hostile path necessary. Attack is brute-force and does not rely > on MITM. > > > So whats all this ado about nothing? Local media made it appear we are > > all about to die. > Pretty much. > > > > Is anyone working on some fix? > In networking world, there was a craze of enabling TCP-MD5 for BGP > sessions reacting to this attack. There is alternative solution, "TTL > hack", relying that most BGP sessions are between directly-connected > routers, so if connection originator sets TTL to 255 and receiver verifies > that TTL on incoming packet is 255, you can be reasonably certain that the > packet was sent by someone directly connected to you. ;) > > -alex > > From weddy@drpepper.grc.nasa.gov Fri Apr 23 07:39:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 07:39:17 -0700 (PDT) Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NEd2KO007181 for ; Fri, 23 Apr 2004 07:39:02 -0700 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 963CE689A7 for ; Fri, 23 Apr 2004 10:28:03 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NES23c022340; Fri, 23 Apr 2004 10:28:02 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id 46A1D289DF; Fri, 23 Apr 2004 10:24:45 -0400 (EDT) Date: Fri, 23 Apr 2004 10:24:45 -0400 From: Wesley Eddy To: netdev@oss.sgi.com Cc: linux-kernel@vger.kernel.org Subject: TCP rto estimation patch Message-ID: <20040423142445.GC501@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WfZ7S8PLGjBY9Voh" Content-Disposition: inline X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-archive-position: 4874 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weddy@grc.nasa.gov Precedence: bulk X-list: netdev Content-Length: 8634 Lines: 222 --WfZ7S8PLGjBY9Voh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The TCP RTO estimation algorithm defined in RFC 2988 is followed properly in the kernel, however the constants alpha and beta in the specification are hardcoded as 3 and 2 everywhere they occur in the kernel. Since these constants crop up multiple times, this is poor programming practice. This patch binds the numeric values to symbols RTT_ALPHA and RTTVAR_BETA, and uses those symbolic values throughout the code. Since using 2 and 3 for these values is not mandatory, this makes tweaking them much easier. -Wes diff -ur linux-2.6.5/include/linux/tcp.h linux-2.6.5-weddy/include/linux/tc= p.h --- linux-2.6.5/include/linux/tcp.h 2004-04-03 22:37:06.000000000 -0500 +++ linux-2.6.5-weddy/include/linux/tcp.h 2004-04-21 16:05:38.0000000= 00 -0 400 @@ -406,4 +406,8 @@ =20 #endif =20 +/* weights for RTO estimator from RFC 2988 */ +#define RTT_ALPHA 3 +#define RTTVAR_BETA 2 + #endif /* _LINUX_TCP_H */ diff -ur linux-2.6.5/net/ipv4/tcp.c linux-2.6.5-weddy/net/ipv4/tcp.c --- linux-2.6.5/net/ipv4/tcp.c 2004-04-03 22:36:53.000000000 -0500 +++ linux-2.6.5-weddy/net/ipv4/tcp.c 2004-04-21 16:00:29.000000000 -0400 @@ -2538,8 +2538,8 @@ =20 info.tcpi_pmtu =3D tp->pmtu_cookie; info.tcpi_rcv_ssthresh =3D tp->rcv_ssthresh; - info.tcpi_rtt =3D ((1000000 * tp->srtt) / HZ) >> 3; - info.tcpi_rttvar =3D ((1000000 * tp->mdev) / HZ) >> 2; + info.tcpi_rtt =3D ((1000000 * tp->srtt) / HZ) >> RTT_ALPHA; + info.tcpi_rttvar =3D ((1000000 * tp->mdev) / HZ) >> RTTVAR_= BETA; info.tcpi_snd_ssthresh =3D tp->snd_ssthresh; info.tcpi_snd_cwnd =3D tp->snd_cwnd; info.tcpi_advmss =3D tp->advmss; diff -ur linux-2.6.5/net/ipv4/tcp_diag.c linux-2.6.5-weddy/net/ipv4/tcp_dia= g.c --- linux-2.6.5/net/ipv4/tcp_diag.c 2004-04-03 22:36:14.000000000 -0500 +++ linux-2.6.5-weddy/net/ipv4/tcp_diag.c 2004-04-21 16:01:08.0000000= 00 -0 400 @@ -188,8 +188,8 @@ =20 info->tcpi_pmtu =3D tp->pmtu_cookie; info->tcpi_rcv_ssthresh =3D tp->rcv_ssthresh; - info->tcpi_rtt =3D ((1000000*tp->srtt)/HZ)>>3; - info->tcpi_rttvar =3D ((1000000*tp->mdev)/HZ)>>2; + info->tcpi_rtt =3D ((1000000*tp->srtt)/HZ)>>RTT_ALPHA; + info->tcpi_rttvar =3D ((1000000*tp->mdev)/HZ)>>RTTVAR_BETA; info->tcpi_snd_ssthresh =3D tp->snd_ssthresh; info->tcpi_snd_cwnd =3D tp->snd_cwnd; info->tcpi_advmss =3D tp->advmss; diff -ur linux-2.6.5/net/ipv4/tcp_input.c linux-2.6.5-weddy/net/ipv4/tcp_in= put.c --- linux-2.6.5/net/ipv4/tcp_input.c 2004-04-03 22:37:39.000000000 -0500 +++ linux-2.6.5-weddy/net/ipv4/tcp_input.c 2004-04-21 15:59:25.0000000= 00 -0 400 @@ -435,11 +435,12 @@ if(m =3D=3D 0) m =3D 1; if (tp->srtt !=3D 0) { - m -=3D (tp->srtt >> 3); /* m is now error in rtt est */ + m -=3D (tp->srtt >> RTT_ALPHA); /* m is now error in rtt = est */ tp->srtt +=3D m; /* rtt =3D 7/8 rtt + 1/8 new */ if (m < 0) { m =3D -m; /* m is now abs(error) */ - m -=3D (tp->mdev >> 2); /* similar update on mdev= */ + /* similar update on mdev */ + m -=3D (tp->mdev >> RTTVAR_BETA); /* This is similar to one of Eifel findings. * Eifel blocks mdev updates when rtt decreases. * This solution is a bit different: we use finer g= ain @@ -449,9 +450,10 @@ * happening in pure Eifel. */ if (m > 0) - m >>=3D 3; + m >>=3D RTT_ALPHA; } else { - m -=3D (tp->mdev >> 2); /* similar update on mdev= */ + /* similar update on mdev */ + m -=3D (tp->mdev >> RTTVAR_BETA); } tp->mdev +=3D m; /* mdev =3D 3/4 mdev + 1/4 new */ if (tp->mdev > tp->mdev_max) { @@ -461,19 +463,21 @@ } if (after(tp->snd_una, tp->rtt_seq)) { if (tp->mdev_max < tp->rttvar) - tp->rttvar -=3D (tp->rttvar-tp->mdev_max)>>= 2; + tp->rttvar -=3D (tp->rttvar-tp->mdev_max) >> + RTTVAR_BETA; tp->rtt_seq =3D tp->snd_nxt; tp->mdev_max =3D TCP_RTO_MIN; } } else { /* no previous measure. */ - tp->srtt =3D m<<3; /* take the measured time to be r= tt */ - tp->mdev =3D m<<1; /* make sure rto =3D 3*rtt */ + /* take the measured time to be rtt */ + tp->srtt =3D m<mdev =3D m<< (RTTVAR_BETA-1); /* make sure rto =3D 3*rt= t */ tp->mdev_max =3D tp->rttvar =3D max(tp->mdev, TCP_RTO_MIN); tp->rtt_seq =3D tp->snd_nxt; } =20 - tcp_westwood_update_rtt(tp, tp->srtt >> 3); + tcp_westwood_update_rtt(tp, tp->srtt >> RTT_ALPHA); } =20 /* Calculate rto without backoff. This is the second half of Van Jacobson= 's @@ -491,7 +495,7 @@ * is invisible. Actually, Linux-2.4 also generates erratic * ACKs in some curcumstances. */ - tp->rto =3D (tp->srtt >> 3) + tp->rttvar; + tp->rto =3D (tp->srtt >> RTT_ALPHA) + tp->rttvar; =20 /* 2. Fixups made earlier cannot be right. * If we do not estimate RTO correctly without them, @@ -543,7 +547,7 @@ if (m <=3D 0) dst->metrics[RTAX_RTT-1] =3D tp->srtt; else - dst->metrics[RTAX_RTT-1] -=3D (m>>3); + dst->metrics[RTAX_RTT-1] -=3D (m>>RTT_ALPHA= ); } =20 if (!(dst_metric_locked(dst, RTAX_RTTVAR))) { @@ -551,7 +555,7 @@ m =3D -m; =20 /* Scale deviation to rttvar fixed point */ - m >>=3D 1; + m >>=3D (RTT_ALPHA-RTTVAR_BETA); if (m < tp->mdev) m =3D tp->mdev; =20 @@ -559,7 +563,8 @@ dst->metrics[RTAX_RTTVAR-1] =3D m; else dst->metrics[RTAX_RTTVAR-1] -=3D - (dst->metrics[RTAX_RTTVAR-1] - m)>>= 2; + (dst->metrics[RTAX_RTTVAR-1] - m ) >> + RTTVAR_BETA; } =20 if (tp->snd_ssthresh >=3D 0xFFFF) { @@ -641,7 +646,8 @@ if (dst_metric(dst, RTAX_RTT) =3D=3D 0) goto reset; =20 - if (!tp->srtt && dst_metric(dst, RTAX_RTT) < (TCP_TIMEOUT_INIT << 3= )) + if (!tp->srtt && dst_metric(dst, RTAX_RTT) < + (TCP_TIMEOUT_INIT << RTT_ALPHA)) goto reset; =20 /* Initial rtt is determined from SYN,SYN-ACK. @@ -2083,7 +2089,7 @@ =20 static inline __u32 westwood_do_filter(__u32 a, __u32 b) { - return (((7 * a) + b) >> 3); + return ((7 * a) + b) >> 3; } =20 static void westwood_filter(struct sock *sk, __u32 delta) diff -ur linux-2.6.5/net/ipv4/tcp_output.c linux-2.6.5-weddy/net/ipv4/tcp_o= utput =2Ec --- linux-2.6.5/net/ipv4/tcp_output.c 2004-04-03 22:37:36.000000000 -0500 +++ linux-2.6.5-weddy/net/ipv4/tcp_output.c 2004-04-21 16:00:39.0000000= 00 -0 400 @@ -1356,7 +1356,7 @@ * directly. */ if (tp->srtt) { - int rtt =3D max(tp->srtt>>3, TCP_DELACK_MIN); + int rtt =3D max(tp->srtt>>RTT_ALPHA, TCP_DELACK_MIN= ); =20 if (rtt < max_ato) max_ato =3D rtt; --WfZ7S8PLGjBY9Voh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiSctzBuYqbnj3IwRAshIAJ9eBL6B6MVMwMziOvOyt7xyFKXOmgCcDO3w lHZ2p2mCEVYLBUPrEJ/BJNU= =/6Bl -----END PGP SIGNATURE----- --WfZ7S8PLGjBY9Voh-- From alex@pilosoft.com Fri Apr 23 07:58:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 07:58:40 -0700 (PDT) Received: from paix.pilosoft.com (dsl-gw-90.pilosoft.com [69.31.90.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NEwYKO007882 for ; Fri, 23 Apr 2004 07:58:35 -0700 Received: from localhost (alex@localhost) by paix.pilosoft.com (8.11.6/8.11.6) with ESMTP id i3NEFs711028; Fri, 23 Apr 2004 10:15:54 -0400 Date: Fri, 23 Apr 2004 10:15:54 -0400 (EDT) From: alex@pilosoft.com To: jamal cc: linux-kernel@vger.kernel.org, Subject: Re: tcp vulnerability? haven't seen anything on it here... In-Reply-To: <1082640135.1059.93.camel@jzny.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4875 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: alex@pilosoft.com Precedence: bulk X-list: netdev Content-Length: 907 Lines: 21 > And for something like a huge download to just regular joe, this is more > of a nuisance assuming some kiddie has access between you and the > server. OTOH, long lived BGP sessions are affected assuming you are > going across hostile path to your peer. Again - no hostile path necessary. Attack is brute-force and does not rely on MITM. > So whats all this ado about nothing? Local media made it appear we are > all about to die. Pretty much. > > Is anyone working on some fix? In networking world, there was a craze of enabling TCP-MD5 for BGP sessions reacting to this attack. There is alternative solution, "TTL hack", relying that most BGP sessions are between directly-connected routers, so if connection originator sets TTL to 255 and receiver verifies that TTL on incoming packet is 255, you can be reasonably certain that the packet was sent by someone directly connected to you. ;) -alex From geert@linux-m68k.org Fri Apr 23 07:59:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 07:59:23 -0700 (PDT) Received: from witte.sonytel.be (witte.sonytel.be [80.88.33.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NEx9KO007948 for ; Fri, 23 Apr 2004 07:59:10 -0700 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i3NEx0xt029653; Fri, 23 Apr 2004 16:59:00 +0200 (MEST) Date: Fri, 23 Apr 2004 16:58:58 +0200 (MEST) From: Geert Uytterhoeven To: Marcelo Tosatti , netdev@oss.sgi.com cc: Linux Kernel Development , linux-net@vger.kernel.org Subject: [PATCH] pktgen dependency (was: Re: Linux 2.4.27-pre1) In-Reply-To: <20040422130651.GB18358@logos.cnet> Message-ID: References: <20040422130651.GB18358@logos.cnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4876 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: netdev Content-Length: 823 Lines: 26 The packet generator doesn't compile if procfs is disabled. IIRC, there was an agreement that this dependency is needed: --- linux-2.4.27-pre1/net/Config.in.orig 2003-10-01 20:49:26.000000000 +0200 +++ linux-2.4.27-pre1/net/Config.in 2004-04-23 14:43:58.000000000 +0200 @@ -99,7 +99,7 @@ mainmenu_option next_comment comment 'Network testing' -tristate 'Packet Generator (USE WITH CAUTION)' CONFIG_NET_PKTGEN +dep_tristate 'Packet Generator (USE WITH CAUTION)' CONFIG_NET_PKTGEN $CONFIG_PROC_FS endmenu endmenu Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From vonbrand@inf.utfsm.cl Fri Apr 23 10:35:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 10:35:49 -0700 (PDT) Received: from inti.inf.utfsm.cl (inti.inf.utfsm.cl [200.1.21.155]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NHZfKO020929 for ; Fri, 23 Apr 2004 10:35:43 -0700 Received: from eeyore.valparaiso.cl (laptop16.inf.utfsm.cl [200.1.19.250]) by inti.inf.utfsm.cl (8.12.10/8.12.10) with ESMTP id i3NHZShk004033; Fri, 23 Apr 2004 13:35:28 -0400 Received: from eeyore.valparaiso.cl (localhost.localdomain [127.0.0.1]) by eeyore.valparaiso.cl (8.12.10/8.12.10) with ESMTP id i3NHZSfc012114; Fri, 23 Apr 2004 13:35:28 -0400 Received: from eeyore.valparaiso.cl (vonbrand@localhost) by eeyore.valparaiso.cl (8.12.10/8.12.10/Submit) with ESMTP id i3NHZRp3012111; Fri, 23 Apr 2004 13:35:27 -0400 Message-Id: <200404231735.i3NHZRp3012111@eeyore.valparaiso.cl> To: weddy@grc.nasa.gov cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TCP rto estimation patch In-Reply-To: Message from Wesley Eddy of "Fri, 23 Apr 2004 10:24:45 -0400." <20040423142445.GC501@grc.nasa.gov> X-Mailer: MH-E 7.4.2; nmh 1.0.4; XEmacs 21.4 (patch 14) Date: Fri, 23 Apr 2004 13:35:27 -0400 From: Horst von Brand X-archive-position: 4878 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: vonbrand@inf.utfsm.cl Precedence: bulk X-list: netdev Content-Length: 1284 Lines: 24 Wesley Eddy said: > The TCP RTO estimation algorithm defined in RFC 2988 is followed properly > in the kernel, however the constants alpha and beta in the specification > are hardcoded as 3 and 2 everywhere they occur in the kernel. Since these > constants crop up multiple times, this is poor programming practice. This > patch binds the numeric values to symbols RTT_ALPHA and RTTVAR_BETA, and > uses those symbolic values throughout the code. Since using 2 and 3 for > these values is not mandatory, this makes tweaking them much easier. Why RTT_ALPHA and RTTVAR_BETA, and not just RTT_BETA? Or even RTO_xxx? Is there any reason to change them, ever? What happens if you change them? Restrictions on values? All this should go with such a patch IMHO (at least pointers to relevant discussion). Must go over it with a fine comb to make sure no unrelated 2 or 3 got replaced... out of my league, sorry. Your patch is MIME-mangled, =3D, =20, =\n shows up all over the place here. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From weddy@drpepper.grc.nasa.gov Fri Apr 23 13:48:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 13:48:11 -0700 (PDT) Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NKm5KO032156 for ; Fri, 23 Apr 2004 13:48:05 -0700 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A1B17689B2 for ; Fri, 23 Apr 2004 16:47:59 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NKlq3c008619; Fri, 23 Apr 2004 16:47:55 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id D3C45289DF; Fri, 23 Apr 2004 16:44:34 -0400 (EDT) Date: Fri, 23 Apr 2004 16:44:34 -0400 From: Wesley Eddy To: Horst von Brand Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: TCP rto estimation patch Message-ID: <20040423204434.GA7492@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040423142445.GC501@grc.nasa.gov> <200404231735.i3NHZRp3012111@eeyore.valparaiso.cl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <200404231735.i3NHZRp3012111@eeyore.valparaiso.cl> X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-archive-position: 4879 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weddy@grc.nasa.gov Precedence: bulk X-list: netdev Content-Length: 1363 Lines: 44 --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 01:35:27PM -0400, Horst von Brand wrote: >=20 > Why RTT_ALPHA and RTTVAR_BETA, and not just RTT_BETA? Or even RTO_xxx? > Per the spec, alpha is used to compute rtt and beta likewise for rttvar. =20 > Is there any reason to change them, ever? What happens if you change them? > Restrictions on values? All this should go with such a patch IMHO (at lea= st > pointers to relevant discussion). The information isn't relevant since the patch didn't change them, and if you were interested in changing the values then simple google search would return a plethora of research on RTT estimation. > Must go over it with a fine comb to make sure no unrelated 2 or 3 got > replaced... out of my league, sorry. There are stray constants all over the place, which is something that even freshman computer science students are taught to avoid. This patch represents a minor improvement to that situation. -Wes --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiYAyzBuYqbnj3IwRAjhPAKCBRdDgGsALp9DTh5qFK+41cTEb6QCfUENV XM5O6g2f/gEt/3X2IoG5xAw= =Dfxq -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv-- From chas@cmf.nrl.navy.mil Fri Apr 23 14:04:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 14:04:17 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NL4AKO032690 for ; Fri, 23 Apr 2004 14:04:10 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i3NL44Zx002473; Fri, 23 Apr 2004 17:04:04 -0400 (EDT) Message-Id: <200404232104.i3NL44Zx002473@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: [fore200e] make tasklet use configurable (2 of 2) [ATM]: [fore200e] make tasklet use configurable Reply-To: chas3@users.sourceforge.net Date: Fri, 23 Apr 2004 17:04:05 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4880 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 1993 Lines: 63 here is the second part of the fore200e patch. # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1331.3.1 -> 1.1331.3.2 # drivers/atm/Config.in 1.8 -> 1.9 # drivers/atm/fore200e.c 1.11 -> 1.12 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/02 chas@relax.cmf.nrl.navy.mil 1.1331.3.2 # [ATM]: [fore200e] make tasklet use configurable # -------------------------------------------- # diff -Nru a/drivers/atm/Config.in b/drivers/atm/Config.in --- a/drivers/atm/Config.in Fri Apr 16 10:44:52 2004 +++ b/drivers/atm/Config.in Fri Apr 16 10:44:52 2004 @@ -83,6 +83,7 @@ fi if [ "$CONFIG_ATM_FORE200E_PCA" = "y" -o "$CONFIG_ATM_FORE200E_SBA" = "y" ]; \ then + bool ' Defer interrupt work to a tasklet' CONFIG_ATM_FORE200E_USE_TASKLET int ' Maximum number of tx retries' CONFIG_ATM_FORE200E_TX_RETRY 16 int ' Debugging level (0-3)' CONFIG_ATM_FORE200E_DEBUG 0 if [ "$CONFIG_ATM_FORE200E_MAYBE" = "y" ]; then diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c Fri Apr 16 10:44:52 2004 +++ b/drivers/atm/fore200e.c Fri Apr 16 10:44:52 2004 @@ -57,7 +57,7 @@ #include #endif -#if 0 /* defer interrupt work to a tasklet */ +#if defined(CONFIG_ATM_FORE200E_USE_TASKLET) /* defer interrupt work to a tasklet */ #define FORE200E_USE_TASKLET #endif @@ -1343,6 +1343,7 @@ } +#ifndef FORE200E_USE_TASKLET static void fore200e_irq(struct fore200e* fore200e) { @@ -1356,6 +1357,7 @@ fore200e_tx_irq(fore200e); spin_unlock_irqrestore(&fore200e->q_lock, flags); } +#endif static void @@ -1396,6 +1398,7 @@ } +static void fore200e_rx_tasklet(unsigned long data) { struct fore200e* fore200e = (struct fore200e*) data; From dlstevens@us.ibm.com Fri Apr 23 14:06:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 14:07:01 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NL6vKO000564 for ; Fri, 23 Apr 2004 14:06:57 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3NL6gnU117048; Fri, 23 Apr 2004 17:06:42 -0400 Received: from d03nm121.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3NL6fP3177068; Fri, 23 Apr 2004 15:06:41 -0600 In-Reply-To: <20040423142445.GC501@grc.nasa.gov> To: weddy@grc.nasa.gov Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: TCP rto estimation patch X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: David Stevens Date: Fri, 23 Apr 2004 14:06:39 -0700 X-MIMETrack: Serialize by Router on D03NM121/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/23/2004 15:06:40, Serialize complete at 04/23/2004 15:06:40 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4881 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dlstevens@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 198 Lines: 7 I believe "2" and "3" are the scale factors for the fixed-point representation of the data, not the "alpha" and "beta" I remember from the estimator paper. +-DLS From davem@redhat.com Fri Apr 23 14:09:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 14:09:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NL9kKO000910 for ; Fri, 23 Apr 2004 14:09:46 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3NL9gKG029999; Fri, 23 Apr 2004 17:09:42 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3NL9fp20818; Fri, 23 Apr 2004 17:09:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3NL9E1n001573; Fri, 23 Apr 2004 17:09:14 -0400 Date: Fri, 23 Apr 2004 14:09:13 -0700 From: "David S. Miller" To: David Stevens Cc: weddy@grc.nasa.gov, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP rto estimation patch Message-Id: <20040423140913.5a7491b9.davem@redhat.com> In-Reply-To: References: <20040423142445.GC501@grc.nasa.gov> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4882 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 263 Lines: 9 On Fri, 23 Apr 2004 14:06:39 -0700 David Stevens wrote: > I believe "2" and "3" are the scale factors for the fixed-point > representation > of the data, not the "alpha" and "beta" I remember from the estimator > paper. That's correct. From chas@cmf.nrl.navy.mil Fri Apr 23 14:11:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 14:12:01 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NLBiKO001250 for ; Fri, 23 Apr 2004 14:11:45 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i3NL1hGG002420; Fri, 23 Apr 2004 17:01:44 -0400 (EDT) Message-Id: <200404232101.i3NL1hGG002420@ginger.cmf.nrl.navy.mil> To: davem@redhat.com cc: netdev@oss.sgi.com Subject: [PATCH][ATM]: [fore200e] 0.3e version (1 of 2) Reply-To: chas3@users.sourceforge.net Date: Fri, 23 Apr 2004 17:01:44 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4883 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 61698 Lines: 1940 dave, this is an update for the fore200e driver in the 2.4 kernels. part 2 of 2 of this patches makes tasklet use configurable. please apply to the 2.4 kernel. thanks! # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1331 -> 1.1331.3.1 # drivers/atm/fore200e.h 1.1 -> 1.2 # drivers/atm/fore200e.c 1.10 -> 1.11 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/03/30 chas@relax.cmf.nrl.navy.mil 1.1331.3.1 # [ATM]: [fore200e] 0.3e version by Christophe Lizzi (lizzi@cnam.fr) # -------------------------------------------- # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c Fri Apr 16 10:44:36 2004 +++ b/drivers/atm/fore200e.c Fri Apr 16 10:44:36 2004 @@ -2,7 +2,7 @@ $Id: fore200e.c,v 1.5 2000/04/14 10:10:34 davem Exp $ A FORE Systems 200E-series driver for ATM on Linux. - Christophe Lizzi (lizzi@cnam.fr), October 1999-March 2000. + Christophe Lizzi (lizzi@cnam.fr), October 1999-March 2003. Based on the PCA-200E driver from Uwe Dannowski (Uwe.Dannowski@inf.tu-dresden.de). @@ -34,6 +34,8 @@ #include #include #include +#include +#include #include #include #include @@ -46,7 +48,6 @@ #include #include #include -#include #ifdef CONFIG_ATM_FORE200E_SBA #include @@ -56,25 +57,33 @@ #include #endif -#include +#if 0 /* defer interrupt work to a tasklet */ +#define FORE200E_USE_TASKLET +#endif -#include "fore200e.h" -#include "suni.h" +#if 0 /* enable the debugging code of the buffer supply queues */ +#define FORE200E_BSQ_DEBUG +#endif -#if 1 /* ensure correct handling of 52-byte AAL0 SDUs used by atmdump-like apps */ +#if 1 /* ensure correct handling of 52-byte AAL0 SDUs expected by atmdump-like apps */ #define FORE200E_52BYTE_AAL0_SDU #endif -#define FORE200E_VERSION "0.2d" +#include "fore200e.h" +#include "suni.h" +#define FORE200E_VERSION "0.3e" #define FORE200E "fore200e: " +#if 0 /* override .config */ +#define CONFIG_ATM_FORE200E_DEBUG 1 +#endif #if defined(CONFIG_ATM_FORE200E_DEBUG) && (CONFIG_ATM_FORE200E_DEBUG > 0) #define DPRINTK(level, format, args...) do { if (CONFIG_ATM_FORE200E_DEBUG >= (level)) \ - printk(FORE200E format, ##args); } while(0) + printk(FORE200E format, ##args); } while (0) #else -#define DPRINTK(level, format, args...) while(0) +#define DPRINTK(level, format, args...) do {} while (0) #endif @@ -85,18 +94,28 @@ #define FORE200E_INDEX(virt_addr, type, index) (&((type *)(virt_addr))[ index ]) -#define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo)) +#define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo)) #define MSECS(ms) (((ms)*HZ/1000)+1) +#if 1 +#define ASSERT(expr) if (!(expr)) { \ + printk(FORE200E "assertion failed! %s[%d]: %s\n", \ + __FUNCTION__, __LINE__, #expr); \ + panic(FORE200E "%s", __FUNCTION__); \ + } +#else +#define ASSERT(expr) do {} while (0) +#endif + + extern const struct atmdev_ops fore200e_ops; extern const struct fore200e_bus fore200e_bus[]; static struct fore200e* fore200e_boards = NULL; - #ifdef MODULE MODULE_AUTHOR("Christophe Lizzi - credits to Uwe Dannowski and Heikki Vatiainen"); MODULE_DESCRIPTION("FORE Systems 200E-series ATM driver - version " FORE200E_VERSION); @@ -225,29 +244,6 @@ } - -#if 0 /* currently unused */ -static int -fore200e_checkup(struct fore200e* fore200e) -{ - u32 hb1, hb2; - - hb1 = fore200e->bus->read(&fore200e->cp_queues->heartbeat); - fore200e_spin(10); - hb2 = fore200e->bus->read(&fore200e->cp_queues->heartbeat); - - if (hb2 <= hb1) { - printk(FORE200E "device %s heartbeat is not counting upwards, hb1 = %x; hb2 = %x\n", - fore200e->name, hb1, hb2); - return -EIO; - } - printk(FORE200E "device %s heartbeat is ok\n", fore200e->name); - - return 0; -} -#endif - - static void fore200e_spin(int msecs) { @@ -444,7 +440,6 @@ } - #ifdef CONFIG_ATM_FORE200E_PCA static u32 fore200e_pca_read(volatile u32* addr) @@ -501,20 +496,16 @@ fore200e_pca_dma_chunk_alloc(struct fore200e* fore200e, struct chunk* chunk, int size, int nbr, int alignment) { -#if defined(__sparc_v9__) /* returned chunks are page-aligned */ + chunk->alloc_size = size * nbr; chunk->alloc_addr = pci_alloc_consistent((struct pci_dev*)fore200e->bus_dev, chunk->alloc_size, &chunk->dma_addr); - if (chunk->alloc_addr == NULL || chunk->dma_addr == 0) + if ((chunk->alloc_addr == NULL) || (chunk->dma_addr == 0)) return -ENOMEM; chunk->align_addr = chunk->alloc_addr; -#else - if (fore200e_chunk_alloc(fore200e, chunk, size * nbr, alignment, FORE200E_DMA_BIDIRECTIONAL) < 0) - return -ENOMEM; -#endif return 0; } @@ -525,14 +516,10 @@ static void fore200e_pca_dma_chunk_free(struct fore200e* fore200e, struct chunk* chunk) { -#if defined(__sparc_v9__) pci_free_consistent((struct pci_dev*)fore200e->bus_dev, chunk->alloc_size, chunk->alloc_addr, chunk->dma_addr); -#else - fore200e_chunk_free(fore200e, chunk); -#endif } @@ -540,7 +527,15 @@ fore200e_pca_irq_check(struct fore200e* fore200e) { /* this is a 1 bit register */ - return readl(fore200e->regs.pca.psr); + int irq_posted = readl(fore200e->regs.pca.psr); + +#if defined(CONFIG_ATM_FORE200E_DEBUG) && (CONFIG_ATM_FORE200E_DEBUG == 2) + if (irq_posted && (readl(fore200e->regs.pca.hcr) & PCA200E_HCR_OUTFULL)) { + DPRINTK(2,"FIFO OUT full, device %d\n", fore200e->atm_dev->number); + } +#endif + + return irq_posted; } @@ -574,7 +569,7 @@ DPRINTK(1, "device %s mapped to 0x%p\n", fore200e->name, fore200e->virt_base); - /* gain access to the PCA-200E specific registers */ + /* gain access to the PCA specific registers */ fore200e->regs.pca.hcr = (u32*)(fore200e->virt_base + PCA200E_HCR_OFFSET); fore200e->regs.pca.imr = (u32*)(fore200e->virt_base + PCA200E_IMR_OFFSET); fore200e->regs.pca.psr = (u32*)(fore200e->virt_base + PCA200E_PSR_OFFSET); @@ -589,8 +584,6 @@ { DPRINTK(2, "device %s being unmapped from memory\n", fore200e->name); - /* XXX iounmap() does nothing on PowerPC (at least in 2.2.12 and 2.3.41), - this leads to a kernel panic if the module is loaded and unloaded several times */ if (fore200e->virt_base != NULL) iounmap(fore200e->virt_base); } @@ -600,7 +593,7 @@ fore200e_pca_configure(struct fore200e* fore200e) { struct pci_dev* pci_dev = (struct pci_dev*)fore200e->bus_dev; - u8 master_ctrl; + u8 master_ctrl, latency; DPRINTK(2, "device %s being configured\n", fore200e->name); @@ -609,21 +602,29 @@ return -EIO; } - pci_read_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, &master_ctrl); + pci_read_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, &master_ctrl); master_ctrl = master_ctrl -#if 0 - | PCA200E_CTRL_DIS_CACHE_RD - | PCA200E_CTRL_DIS_WRT_INVAL -#endif #if defined(__BIG_ENDIAN) /* request the PCA board to convert the endianess of slave RAM accesses */ | PCA200E_CTRL_CONVERT_ENDIAN #endif +#if 0 + | PCA200E_CTRL_DIS_CACHE_RD + | PCA200E_CTRL_DIS_WRT_INVAL + | PCA200E_CTRL_ENA_CONT_REQ_MODE + | PCA200E_CTRL_2_CACHE_WRT_INVAL +#endif | PCA200E_CTRL_LARGE_PCI_BURSTS; pci_write_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, master_ctrl); + /* raise latency from 32 (default) to 192, as this seems to prevent NIC + lockups (under heavy rx loads) due to continuous 'FIFO OUT full' condition. + this may impact the performances of other PCI devices on the same bus, though */ + latency = 192; + pci_write_config_byte(pci_dev, PCI_LATENCY_TIMER, latency); + fore200e->state = FORE200E_STATE_CONFIGURE; return 0; } @@ -657,11 +658,7 @@ fore200e->bus = bus; fore200e->bus_dev = pci_dev; fore200e->irq = pci_dev->irq; - fore200e->phys_base = pci_resource_start (pci_dev, 0); - -#if defined(__powerpc__) - fore200e->phys_base += KERNELBASE; -#endif + fore200e->phys_base = pci_resource_start(pci_dev, 0); sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); @@ -729,8 +726,6 @@ #endif /* CONFIG_ATM_FORE200E_PCA */ - - #ifdef CONFIG_ATM_FORE200E_SBA static u32 @@ -792,7 +787,7 @@ chunk->alloc_size, &chunk->dma_addr); - if (chunk->alloc_addr == NULL || chunk->dma_addr == 0) + if ((chunk->alloc_addr == NULL) || (chunk->dma_addr == 0)) return -ENOMEM; chunk->align_addr = chunk->alloc_addr; @@ -851,8 +846,7 @@ struct sbus_dev* sbus_dev = (struct sbus_dev*)fore200e->bus_dev; unsigned int bursts; - /* gain access to the SBA-200E specific registers */ - + /* gain access to the SBA specific registers */ fore200e->regs.sba.hcr = (u32*)sbus_ioremap(&sbus_dev->resource[0], 0, SBA200E_HCR_LENGTH, "SBA HCR"); fore200e->regs.sba.bsr = (u32*)sbus_ioremap(&sbus_dev->resource[1], 0, SBA200E_BSR_LENGTH, "SBA BSR"); fore200e->regs.sba.isr = (u32*)sbus_ioremap(&sbus_dev->resource[2], 0, SBA200E_ISR_LENGTH, "SBA ISR"); @@ -873,17 +867,6 @@ if (sbus_can_dma_64bit(sbus_dev)) sbus_set_sbus64(sbus_dev, bursts); -#if 0 - if (bursts & DMA_BURST16) - fore200e->bus->write(SBA200E_BSR_BURST16, fore200e->regs.sba.bsr); - else - if (bursts & DMA_BURST8) - fore200e->bus->write(SBA200E_BSR_BURST8, fore200e->regs.sba.bsr); - else - if (bursts & DMA_BURST4) - fore200e->bus->write(SBA200E_BSR_BURST4, fore200e->regs.sba.bsr); -#endif - fore200e->state = FORE200E_STATE_MAP; return 0; } @@ -928,13 +911,11 @@ return NULL; found: -#if 1 if (sbus_dev->num_registers != 4) { printk(FORE200E "this %s device has %d instead of 4 registers\n", bus->model_name, sbus_dev->num_registers); return NULL; } -#endif fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); if (fore200e == NULL) @@ -987,46 +968,143 @@ static void -fore200e_irq_tx(struct fore200e* fore200e) +fore200e_tx_irq(struct fore200e* fore200e) { - struct host_txq_entry* entry; - int i; - - entry = fore200e->host_txq.host_entry; + struct host_txq* txq = &fore200e->host_txq; + struct host_txq_entry* entry; + struct atm_vcc* vcc; + struct fore200e_vc_map* vc_map; - for (i = 0; i < QUEUE_SIZE_TX; i++) { + if (fore200e->host_txq.txing == 0) + return; + + for (;;) { + + entry = &txq->host_entry[ txq->tail ]; - if (*entry->status & STATUS_COMPLETE) { + if ((*entry->status & STATUS_COMPLETE) == 0) { + break; + } - DPRINTK(3, "TX COMPLETED: entry = %p, vcc = %p, skb = %p\n", entry, entry->vcc, entry->skb); + DPRINTK(3, "TX COMPLETED: entry = %p [tail = %d], vc_map = %p, skb = %p\n", + entry, txq->tail, entry->vc_map, entry->skb); - /* free copy of misaligned data */ - if (entry->data) - kfree(entry->data); + /* free copy of misaligned data */ + if (entry->data) + kfree(entry->data); + + /* remove DMA mapping */ + fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, + FORE200E_DMA_TODEVICE); - /* remove DMA mapping */ - fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, - FORE200E_DMA_TODEVICE); + vc_map = entry->vc_map; - /* notify tx completion */ - if (entry->vcc->pop) - entry->vcc->pop(entry->vcc, entry->skb); - else - dev_kfree_skb_irq(entry->skb); + /* vcc closed since the time the entry was submitted for tx? */ + if ((vc_map->vcc == NULL) || + (test_bit(ATM_VF_READY, &vc_map->vcc->flags) == 0)) { - /* check error condition */ - if (*entry->status & STATUS_ERROR) - atomic_inc(&entry->vcc->stats->tx_err); - else - atomic_inc(&entry->vcc->stats->tx); + DPRINTK(1, "no ready vcc found for PDU sent on device %d\n", + fore200e->atm_dev->number); - *entry->status = STATUS_FREE; - - fore200e->host_txq.txing--; + dev_kfree_skb_any(entry->skb); + } + else { + ASSERT(vc_map->vcc); + + /* vcc closed then immediately re-opened? */ + if (vc_map->incarn != entry->incarn) { + + /* when a vcc is closed, some PDUs may be still pending in the tx queue. + if the same vcc is immediately re-opened, those pending PDUs must + not be popped after the completion of their emission, as they refer + to the prior incarnation of that vcc. otherwise, vcc->sk->wmem_alloc + would be decremented by the size of the (unrelated) skb, possibly + leading to a negative sk->wmem_alloc count, ultimately freezing the vcc. + we thus bind the tx entry to the current incarnation of the vcc + when the entry is submitted for tx. When the tx later completes, + if the incarnation number of the tx entry does not match the one + of the vcc, then this implies that the vcc has been closed then re-opened. + we thus just drop the skb here. */ + + DPRINTK(1, "vcc closed-then-re-opened; dropping PDU sent on device %d\n", + fore200e->atm_dev->number); + + dev_kfree_skb_any(entry->skb); + } + else { + vcc = vc_map->vcc; + ASSERT(vcc); + + /* notify tx completion */ + if (vcc->pop) { + vcc->pop(vcc, entry->skb); + } + else { + dev_kfree_skb_any(entry->skb); + } +#if 1 + /* race fixed by the above incarnation mechanism, but... */ + if (atomic_read(&vcc->sk->wmem_alloc) < 0) { + atomic_set(&vcc->sk->wmem_alloc, 0); + } +#endif + /* check error condition */ + if (*entry->status & STATUS_ERROR) + atomic_inc(&vcc->stats->tx_err); + else + atomic_inc(&vcc->stats->tx); + } + } + + *entry->status = STATUS_FREE; + + fore200e->host_txq.txing--; + + FORE200E_NEXT_ENTRY(txq->tail, QUEUE_SIZE_TX); + } +} + + +#ifdef FORE200E_BSQ_DEBUG +int bsq_audit(int where, struct host_bsq* bsq, int scheme, int magn) +{ + struct buffer* buffer; + int count = 0; + + buffer = bsq->freebuf; + while (buffer) { + + if (buffer->supplied) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld supplied but in free list!\n", + where, scheme, magn, buffer->index); + } + + if (buffer->magn != magn) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld, unexpected magn = %d\n", + where, scheme, magn, buffer->index, buffer->magn); + } + + if (buffer->scheme != scheme) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld, unexpected scheme = %d\n", + where, scheme, magn, buffer->index, buffer->scheme); + } + + if ((buffer->index < 0) || (buffer->index >= fore200e_rx_buf_nbr[ scheme ][ magn ])) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, out of range buffer index = %ld !\n", + where, scheme, magn, buffer->index); } - entry++; + + count++; + buffer = buffer->next; + } + + if (count != bsq->freebuf_count) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, %d bufs in free list, but freebuf_count = %d\n", + where, scheme, magn, count, bsq->freebuf_count); } + return 0; } +#endif static void @@ -1043,28 +1121,42 @@ bsq = &fore200e->host_bsq[ scheme ][ magn ]; - if (fore200e_rx_buf_nbr[ scheme ][ magn ] - bsq->count > RBD_BLK_SIZE) { +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(1, bsq, scheme, magn); +#endif + while (bsq->freebuf_count >= RBD_BLK_SIZE) { - DPRINTK(2, "supplying rx buffers to queue %d / %d, count = %d\n", - scheme, magn, bsq->count); + DPRINTK(2, "supplying %d rx buffers to queue %d / %d, freebuf_count = %d\n", + RBD_BLK_SIZE, scheme, magn, bsq->freebuf_count); entry = &bsq->host_entry[ bsq->head ]; - - FORE200E_NEXT_ENTRY(bsq->head, QUEUE_SIZE_BS); for (i = 0; i < RBD_BLK_SIZE; i++) { - buffer = &bsq->buffer[ bsq->free ]; - - FORE200E_NEXT_ENTRY(bsq->free, fore200e_rx_buf_nbr[ scheme ][ magn ]); + /* take the first buffer in the free buffer list */ + buffer = bsq->freebuf; + if (!buffer) { + printk(FORE200E "no more free bufs in queue %d.%d, but freebuf_count = %d\n", + scheme, magn, bsq->freebuf_count); + return; + } + bsq->freebuf = buffer->next; +#ifdef FORE200E_BSQ_DEBUG + if (buffer->supplied) + printk(FORE200E "queue %d.%d, buffer %lu already supplied\n", + scheme, magn, buffer->index); + buffer->supplied = 1; +#endif entry->rbd_block->rbd[ i ].buffer_haddr = buffer->data.dma_addr; entry->rbd_block->rbd[ i ].handle = FORE200E_BUF2HDL(buffer); } - /* increase the number of supplied rx buffers */ - bsq->count += RBD_BLK_SIZE; - + FORE200E_NEXT_ENTRY(bsq->head, QUEUE_SIZE_BS); + + /* decrease accordingly the number of free rx buffers */ + bsq->freebuf_count -= RBD_BLK_SIZE; + *entry->status = STATUS_PENDING; fore200e->bus->write(entry->rbd_block_dma, &entry->cp_entry->rbd_block_haddr); } @@ -1073,33 +1165,9 @@ } - -static struct atm_vcc* -fore200e_find_vcc(struct fore200e* fore200e, struct rpd* rpd) -{ - struct sock *s; - struct atm_vcc* vcc; - - read_lock(&vcc_sklist_lock); - for(s = vcc_sklist; s; s = s->next) { - vcc = s->protinfo.af_atm; - if (vcc->dev != fore200e->atm_dev) - continue; - if (vcc->vpi == rpd->atm_header.vpi && vcc->vci == rpd->atm_header.vci) { - read_unlock(&vcc_sklist_lock); - return vcc; - } - } - read_unlock(&vcc_sklist_lock); - - return NULL; -} - - -static void -fore200e_push_rpd(struct fore200e* fore200e, struct rpd* rpd) +static int +fore200e_push_rpd(struct fore200e* fore200e, struct atm_vcc* vcc, struct rpd* rpd) { - struct atm_vcc* vcc; struct sk_buff* skb; struct buffer* buffer; struct fore200e_vcc* fore200e_vcc; @@ -1108,15 +1176,10 @@ u32 cell_header = 0; #endif - vcc = fore200e_find_vcc(fore200e, rpd); - if (vcc == NULL) { - - printk(FORE200E "no vcc found for PDU received on %d.%d.%d\n", - fore200e->atm_dev->number, rpd->atm_header.vpi, rpd->atm_header.vci); - return; - } - + ASSERT(vcc); + fore200e_vcc = FORE200E_VCC(vcc); + ASSERT(fore200e_vcc); #ifdef FORE200E_52BYTE_AAL0_SDU if ((vcc->qos.aal == ATM_AAL0) && (vcc->qos.rxtp.max_sdu == ATM_AAL0_SDU)) { @@ -1136,10 +1199,10 @@ skb = alloc_skb(pdu_len, GFP_ATOMIC); if (skb == NULL) { - - printk(FORE200E "unable to alloc new skb, rx PDU length = %d\n", pdu_len); + DPRINTK(2, "unable to alloc new skb, rx PDU length = %d\n", pdu_len); + atomic_inc(&vcc->stats->rx_drop); - return; + return -ENOMEM; } skb->stamp = xtime; @@ -1161,13 +1224,14 @@ memcpy(skb_put(skb, rpd->rsd[ i ].length), buffer->data.align_addr, rpd->rsd[ i ].length); } - + DPRINTK(3, "rx skb: len = %d, truesize = %d\n", skb->len, skb->truesize); if (pdu_len < fore200e_vcc->rx_min_pdu) fore200e_vcc->rx_min_pdu = pdu_len; if (pdu_len > fore200e_vcc->rx_max_pdu) fore200e_vcc->rx_max_pdu = pdu_len; + fore200e_vcc->rx_pdu++; /* push PDU */ if (atm_charge(vcc, skb->truesize) == 0) { @@ -1175,37 +1239,63 @@ DPRINTK(2, "receive buffers saturated for %d.%d.%d - PDU dropped\n", vcc->itf, vcc->vpi, vcc->vci); - dev_kfree_skb_irq(skb); - return; + dev_kfree_skb_any(skb); + + atomic_inc(&vcc->stats->rx_drop); + return -ENOMEM; } + ASSERT(atomic_read(&vcc->sk->wmem_alloc) >= 0); + vcc->push(vcc, skb); atomic_inc(&vcc->stats->rx); + + ASSERT(atomic_read(&vcc->sk->wmem_alloc) >= 0); + + return 0; } static void fore200e_collect_rpd(struct fore200e* fore200e, struct rpd* rpd) { - struct buffer* buffer; - int i; + struct host_bsq* bsq; + struct buffer* buffer; + int i; for (i = 0; i < rpd->nseg; i++) { /* rebuild rx buffer address from rsd handle */ buffer = FORE200E_HDL2BUF(rpd->rsd[ i ].handle); - /* decrease the number of supplied rx buffers */ - fore200e->host_bsq[ buffer->scheme ][ buffer->magn ].count--; + bsq = &fore200e->host_bsq[ buffer->scheme ][ buffer->magn ]; + +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(2, bsq, buffer->scheme, buffer->magn); + + if (buffer->supplied == 0) + printk(FORE200E "queue %d.%d, buffer %ld was not supplied\n", + buffer->scheme, buffer->magn, buffer->index); + buffer->supplied = 0; +#endif + + /* re-insert the buffer into the free buffer list */ + buffer->next = bsq->freebuf; + bsq->freebuf = buffer; + + /* then increment the number of free rx buffers */ + bsq->freebuf_count++; } } static void -fore200e_irq_rx(struct fore200e* fore200e) +fore200e_rx_irq(struct fore200e* fore200e) { - struct host_rxq* rxq = &fore200e->host_rxq; - struct host_rxq_entry* entry; + struct host_rxq* rxq = &fore200e->host_rxq; + struct host_rxq_entry* entry; + struct atm_vcc* vcc; + struct fore200e_vc_map* vc_map; for (;;) { @@ -1215,28 +1305,59 @@ if ((*entry->status & STATUS_COMPLETE) == 0) break; - FORE200E_NEXT_ENTRY(rxq->head, QUEUE_SIZE_RX); + vc_map = FORE200E_VC_MAP(fore200e, entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); - if ((*entry->status & STATUS_ERROR) == 0) { + if ((vc_map->vcc == NULL) || + (test_bit(ATM_VF_READY, &vc_map->vcc->flags) == 0)) { - fore200e_push_rpd(fore200e, entry->rpd); + DPRINTK(1, "no ready VC found for PDU received on %d.%d.%d\n", + fore200e->atm_dev->number, + entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); } else { - printk(FORE200E "damaged PDU on %d.%d.%d\n", - fore200e->atm_dev->number, entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); + vcc = vc_map->vcc; + ASSERT(vcc); + + if ((*entry->status & STATUS_ERROR) == 0) { + + fore200e_push_rpd(fore200e, vcc, entry->rpd); + } + else { + DPRINTK(2, "damaged PDU on %d.%d.%d\n", + fore200e->atm_dev->number, + entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); + atomic_inc(&vcc->stats->rx_err); + } } - fore200e_collect_rpd(fore200e, entry->rpd); + FORE200E_NEXT_ENTRY(rxq->head, QUEUE_SIZE_RX); - fore200e_supply(fore200e); + fore200e_collect_rpd(fore200e, entry->rpd); /* rewrite the rpd address to ack the received PDU */ fore200e->bus->write(entry->rpd_dma, &entry->cp_entry->rpd_haddr); *entry->status = STATUS_FREE; + + fore200e_supply(fore200e); } } +static void +fore200e_irq(struct fore200e* fore200e) +{ + unsigned long flags; + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_rx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_tx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); +} + + static void fore200e_interrupt(int irq, void* dev, struct pt_regs* regs) { @@ -1244,57 +1365,64 @@ if (fore200e->bus->irq_check(fore200e) == 0) { - DPRINTK(3, "unexpected interrupt on device %c\n", fore200e->name[9]); + DPRINTK(3, "interrupt NOT triggered by device %d\n", fore200e->atm_dev->number); return; } - DPRINTK(3, "valid interrupt on device %c\n", fore200e->name[9]); + DPRINTK(3, "interrupt triggered by device %d\n", fore200e->atm_dev->number); - tasklet_schedule(&fore200e->tasklet); +#ifdef FORE200E_USE_TASKLET + tasklet_schedule(&fore200e->tx_tasklet); + tasklet_schedule(&fore200e->rx_tasklet); +#else + fore200e_irq(fore200e); +#endif fore200e->bus->irq_ack(fore200e); } +#ifdef FORE200E_USE_TASKLET static void -fore200e_tasklet(unsigned long data) +fore200e_tx_tasklet(unsigned long data) { struct fore200e* fore200e = (struct fore200e*) data; + unsigned long flags; - fore200e_irq_rx(fore200e); - - if (fore200e->host_txq.txing) - fore200e_irq_tx(fore200e); + DPRINTK(3, "tx tasklet scheduled for device %d\n", fore200e->atm_dev->number); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_tx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); } +fore200e_rx_tasklet(unsigned long data) +{ + struct fore200e* fore200e = (struct fore200e*) data; + unsigned long flags; + + DPRINTK(3, "rx tasklet scheduled for device %d\n", fore200e->atm_dev->number); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_rx_irq((struct fore200e*) data); + spin_unlock_irqrestore(&fore200e->q_lock, flags); +} +#endif + static int fore200e_select_scheme(struct atm_vcc* vcc) { - int scheme; - -#if 1 - /* fairly balance VCs over (identical) buffer schemes */ - scheme = vcc->vci % 2 ? BUFFER_SCHEME_ONE : BUFFER_SCHEME_TWO; -#else - /* bit 7 of VPI magically selects the second buffer scheme */ - if (vcc->vpi & (1<<7)) { - vcc->vpi &= ((1<<7) - 1); /* reset the magic bit */ - scheme = BUFFER_SCHEME_TWO; - } - else { - scheme = BUFFER_SCHEME_ONE; - } -#endif + /* fairly balance the VCs over (identical) buffer schemes */ + int scheme = vcc->vci % 2 ? BUFFER_SCHEME_ONE : BUFFER_SCHEME_TWO; - DPRINTK(1, "vpvc %d.%d.%d uses the %s buffer scheme\n", - vcc->itf, vcc->vpi, vcc->vci, scheme == BUFFER_SCHEME_ONE ? "first" : "second"); + DPRINTK(1, "VC %d.%d.%d uses buffer scheme %d\n", + vcc->itf, vcc->vpi, vcc->vci, scheme); return scheme; } - static int fore200e_activate_vcin(struct fore200e* fore200e, int activate, struct atm_vcc* vcc, int mtu) { @@ -1331,7 +1459,7 @@ #ifdef FORE200E_52BYTE_AAL0_SDU mtu = 48; #endif - /* the MTU is unused by the cp, except in the case of AAL0 */ + /* the MTU is not used by the cp, except in the case of AAL0 */ fore200e->bus->write(mtu, &entry->cp_entry->cmd.activate_block.mtu); fore200e->bus->write(*(u32*)&vpvc, (u32*)&entry->cp_entry->cmd.activate_block.vpvc); fore200e->bus->write(*(u32*)&activ_opcode, (u32*)&entry->cp_entry->cmd.activate_block.opcode); @@ -1346,13 +1474,13 @@ *entry->status = STATUS_FREE; if (ok == 0) { - printk(FORE200E "unable to %s vpvc %d.%d on device %s\n", - activate ? "open" : "close", vcc->vpi, vcc->vci, fore200e->name); + printk(FORE200E "unable to %s VC %d.%d.%d\n", + activate ? "open" : "close", vcc->itf, vcc->vpi, vcc->vci); return -EIO; } - DPRINTK(1, "vpvc %d.%d %sed on device %s\n", vcc->vpi, vcc->vci, - activate ? "open" : "clos", fore200e->name); + DPRINTK(1, "VC %d.%d.%d %sed\n", vcc->itf, vcc->vpi, vcc->vci, + activate ? "open" : "clos"); return 0; } @@ -1410,7 +1538,7 @@ { if (qos->txtp.max_pcr < ATM_OC3_PCR) { - /* compute the data cells to idle cells ratio from the PCR */ + /* compute the data cells to idle cells ratio from the tx PCR */ rate->data_cells = qos->txtp.max_pcr * FORE200E_MAX_BACK2BACK_CELLS / ATM_OC3_PCR; rate->idle_cells = FORE200E_MAX_BACK2BACK_CELLS - rate->data_cells; } @@ -1424,21 +1552,38 @@ static int fore200e_open(struct atm_vcc *vcc, short vpi, int vci) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - struct fore200e_vcc* fore200e_vcc; - - /* find a free VPI/VCI */ + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc; + struct fore200e_vc_map* vc_map; + unsigned long flags; + fore200e_walk_vccs(vcc, &vpi, &vci); + + ASSERT((vpi >= 0) && (vpi < 1<= 0) && (vci < 1<vpi = vpi; - vcc->vci = vci; + spin_lock_irqsave(&fore200e->q_lock, flags); - /* ressource checking only? */ - if (vci == ATM_VCI_UNSPEC || vpi == ATM_VPI_UNSPEC) - return 0; + vc_map = FORE200E_VC_MAP(fore200e, vpi, vci); + if (vc_map->vcc) { - set_bit(ATM_VF_ADDR, &vcc->flags); - vcc->itf = vcc->dev->number; + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + printk(FORE200E "VC %d.%d.%d already in use\n", + fore200e->atm_dev->number, vpi, vci); + + return -EINVAL; + } + + vc_map->vcc = vcc; + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + fore200e_vcc = fore200e_kmalloc(sizeof(struct fore200e_vcc), GFP_ATOMIC); + if (fore200e_vcc == NULL) { + vc_map->vcc = NULL; + return -ENOMEM; + } DPRINTK(2, "opening %d.%d.%d:%d QoS = (tx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d; " "rx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d)\n", @@ -1448,44 +1593,52 @@ fore200e_traffic_class[ vcc->qos.rxtp.traffic_class ], vcc->qos.rxtp.min_pcr, vcc->qos.rxtp.max_pcr, vcc->qos.rxtp.max_cdv, vcc->qos.rxtp.max_sdu); + /* pseudo-CBR bandwidth requested? */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { down(&fore200e->rate_sf); if (fore200e->available_cell_rate < vcc->qos.txtp.max_pcr) { up(&fore200e->rate_sf); + + fore200e_kfree(fore200e_vcc); + vc_map->vcc = NULL; return -EAGAIN; } - /* reserving the pseudo-CBR bandwidth at this point grants us - to reduce the length of the critical section protected - by 'rate_sf'. in counterpart, we have to reset the available - bandwidth if we later encounter an error */ + /* reserve bandwidth */ fore200e->available_cell_rate -= vcc->qos.txtp.max_pcr; up(&fore200e->rate_sf); } - - fore200e_vcc = fore200e_kmalloc(sizeof(struct fore200e_vcc), GFP_KERNEL); - if (fore200e_vcc == NULL) { - down(&fore200e->rate_sf); - fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; - up(&fore200e->rate_sf); - return -ENOMEM; - } + + vcc->itf = vcc->dev->number; + vcc->vpi = vpi; + vcc->vci = vci; + + set_bit(ATM_VF_PARTIAL,&vcc->flags); + set_bit(ATM_VF_ADDR, &vcc->flags); FORE200E_VCC(vcc) = fore200e_vcc; - + if (fore200e_activate_vcin(fore200e, 1, vcc, vcc->qos.rxtp.max_sdu) < 0) { - kfree(fore200e_vcc); - down(&fore200e->rate_sf); + + vc_map->vcc = NULL; + + clear_bit(ATM_VF_ADDR, &vcc->flags); + clear_bit(ATM_VF_PARTIAL,&vcc->flags); + + FORE200E_VCC(vcc) = NULL; + fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; - up(&fore200e->rate_sf); - return -EBUSY; + + fore200e_kfree(fore200e_vcc); + return -EINVAL; } /* compute rate control parameters */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { fore200e_rate_ctrl(&vcc->qos, &fore200e_vcc->rate); + set_bit(ATM_VF_HASQOS, &vcc->flags); DPRINTK(3, "tx on %d.%d.%d:%d, tx PCR = %d, rx PCR = %d, data_cells = %u, idle_cells = %u\n", vcc->itf, vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal), @@ -1493,57 +1646,99 @@ fore200e_vcc->rate.data_cells, fore200e_vcc->rate.idle_cells); } - fore200e_vcc->tx_min_pdu = fore200e_vcc->rx_min_pdu = 65536; + fore200e_vcc->tx_min_pdu = fore200e_vcc->rx_min_pdu = MAX_PDU_SIZE + 1; fore200e_vcc->tx_max_pdu = fore200e_vcc->rx_max_pdu = 0; - + fore200e_vcc->tx_pdu = fore200e_vcc->rx_pdu = 0; + + /* new incarnation of the vcc */ + vc_map->incarn = ++fore200e->incarn_count; + + /* VC unusable before this flag is set */ set_bit(ATM_VF_READY, &vcc->flags); + return 0; } - static void fore200e_close(struct atm_vcc* vcc) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc; + struct fore200e_vc_map* vc_map; + unsigned long flags; + + ASSERT(vcc); + ASSERT((vcc->vpi >= 0) && (vcc->vpi < 1<vci >= 0) && (vcc->vci < 1<itf, vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal)); - + + clear_bit(ATM_VF_READY, &vcc->flags); + fore200e_activate_vcin(fore200e, 0, vcc, 0); - - kfree(FORE200E_VCC(vcc)); - + + spin_lock_irqsave(&fore200e->q_lock, flags); + + vc_map = FORE200E_VC_MAP(fore200e, vcc->vpi, vcc->vci); + + /* the vc is no longer considered as "in use" by fore200e_open() */ + vc_map->vcc = NULL; + + vcc->itf = vcc->vci = vcc->vpi = 0; + + fore200e_vcc = FORE200E_VCC(vcc); + FORE200E_VCC(vcc) = NULL; + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + /* release reserved bandwidth, if any */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { + down(&fore200e->rate_sf); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; up(&fore200e->rate_sf); - } - clear_bit(ATM_VF_READY, &vcc->flags); -} + clear_bit(ATM_VF_HASQOS, &vcc->flags); + } + clear_bit(ATM_VF_ADDR, &vcc->flags); + clear_bit(ATM_VF_PARTIAL,&vcc->flags); -#if 0 -#define FORE200E_SYNC_SEND /* wait tx completion before returning */ -#endif + ASSERT(fore200e_vcc); + fore200e_kfree(fore200e_vcc); +} static int fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); - struct host_txq* txq = &fore200e->host_txq; - struct host_txq_entry* entry; - struct tpd* tpd; - struct tpd_haddr tpd_haddr; - //unsigned long flags; - int retry = CONFIG_ATM_FORE200E_TX_RETRY; - int tx_copy = 0; - int tx_len = skb->len; - u32* cell_header = NULL; - unsigned char* skb_data; - int skb_len; + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); + struct fore200e_vc_map* vc_map; + struct host_txq* txq = &fore200e->host_txq; + struct host_txq_entry* entry; + struct tpd* tpd; + struct tpd_haddr tpd_haddr; + int retry = CONFIG_ATM_FORE200E_TX_RETRY; + int tx_copy = 0; + int tx_len = skb->len; + u32* cell_header = NULL; + unsigned char* skb_data; + int skb_len; + unsigned char* data; + unsigned long flags; + + ASSERT(vcc); + ASSERT(atomic_read(&vcc->sk->wmem_alloc) >= 0); + ASSERT(fore200e); + ASSERT(fore200e_vcc); + + if (!test_bit(ATM_VF_READY, &vcc->flags)) { + DPRINTK(1, "VC %d.%d.%d not ready for tx\n", vcc->itf, vcc->vpi, vcc->vpi); + dev_kfree_skb_any(skb); + return -EINVAL; + } #ifdef FORE200E_52BYTE_AAL0_SDU if ((vcc->qos.aal == ATM_AAL0) && (vcc->qos.txtp.max_sdu == ATM_AAL0_SDU)) { @@ -1551,7 +1746,7 @@ skb_data = skb->data + 4; /* skip 4-byte cell header */ skb_len = tx_len = skb->len - 4; - DPRINTK(3, "skipping user-supplied cell header 0x%08x", *cell_header); + DPRINTK(3, "user-supplied cell header = 0x%08x\n", *cell_header); } else #endif @@ -1560,39 +1755,6 @@ skb_len = skb->len; } - retry_here: - - tasklet_disable(&fore200e->tasklet); - - entry = &txq->host_entry[ txq->head ]; - - if (*entry->status != STATUS_FREE) { - - /* try to free completed tx queue entries */ - fore200e_irq_tx(fore200e); - - if (*entry->status != STATUS_FREE) { - - tasklet_enable(&fore200e->tasklet); - - /* retry once again? */ - if(--retry > 0) - goto retry_here; - - atomic_inc(&vcc->stats->tx_err); - - printk(FORE200E "tx queue of device %s is saturated, PDU dropped - heartbeat is %08x\n", - fore200e->name, fore200e->cp_queues->heartbeat); - if (vcc->pop) - vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); - return -EIO; - } - } - - tpd = entry->tpd; - if (((unsigned long)skb_data) & 0x3) { DPRINTK(2, "misaligned tx PDU on device %s\n", fore200e->name); @@ -1602,43 +1764,87 @@ if ((vcc->qos.aal == ATM_AAL0) && (skb_len % ATM_CELL_PAYLOAD)) { - /* this simply NUKES the PCA-200E board */ + /* this simply NUKES the PCA board */ DPRINTK(2, "incomplete tx AAL0 PDU on device %s\n", fore200e->name); tx_copy = 1; tx_len = ((skb_len / ATM_CELL_PAYLOAD) + 1) * ATM_CELL_PAYLOAD; } if (tx_copy) { - - entry->data = kmalloc(tx_len, GFP_ATOMIC | GFP_DMA); - if (entry->data == NULL) { - - tasklet_enable(&fore200e->tasklet); - if (vcc->pop) + data = kmalloc(tx_len, GFP_ATOMIC | GFP_DMA); + if (data == NULL) { + if (vcc->pop) { vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); + } + else { + dev_kfree_skb_any(skb); + } return -ENOMEM; } - memcpy(entry->data, skb_data, skb_len); + memcpy(data, skb_data, skb_len); if (skb_len < tx_len) - memset(entry->data + skb_len, 0x00, tx_len - skb_len); - - tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, entry->data, tx_len, FORE200E_DMA_TODEVICE); + memset(data + skb_len, 0x00, tx_len - skb_len); } else { - entry->data = NULL; - tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, skb_data, tx_len, FORE200E_DMA_TODEVICE); + data = skb_data; } + vc_map = FORE200E_VC_MAP(fore200e, vcc->vpi, vcc->vci); + ASSERT(vc_map->vcc == vcc); + + retry_here: + + spin_lock_irqsave(&fore200e->q_lock, flags); + + entry = &txq->host_entry[ txq->head ]; + + if ((*entry->status != STATUS_FREE) || (txq->txing >= QUEUE_SIZE_TX - 2)) { + + /* try to free completed tx queue entries */ + fore200e_tx_irq(fore200e); + + if (*entry->status != STATUS_FREE) { + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + /* retry once again? */ + if(--retry > 0) { + schedule(); + goto retry_here; + } + + atomic_inc(&vcc->stats->tx_err); + + fore200e->tx_sat++; + DPRINTK(2, "tx queue of device %s is saturated, PDU dropped - heartbeat is %08x\n", + fore200e->name, fore200e->cp_queues->heartbeat); + if (vcc->pop) { + vcc->pop(vcc, skb); + } + else { + dev_kfree_skb_any(skb); + } + + if (tx_copy) + kfree(data); + + return -ENOBUFS; + } + } + + entry->incarn = vc_map->incarn; + entry->vc_map = vc_map; + entry->skb = skb; + entry->data = tx_copy ? data : NULL; + + tpd = entry->tpd; + tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, data, tx_len, FORE200E_DMA_TODEVICE); tpd->tsd[ 0 ].length = tx_len; FORE200E_NEXT_ENTRY(txq->head, QUEUE_SIZE_TX); txq->txing++; - tasklet_enable(&fore200e->tasklet); - /* ensure DMA synchronisation */ fore200e->bus->dma_sync(fore200e, tpd->tsd[ 0 ].buffer, tpd->tsd[ 0 ].length, FORE200E_DMA_TODEVICE); @@ -1650,9 +1856,7 @@ fore200e_vcc->tx_min_pdu = skb_len; if (skb_len > fore200e_vcc->tx_max_pdu) fore200e_vcc->tx_max_pdu = skb_len; - - entry->vcc = vcc; - entry->skb = skb; + fore200e_vcc->tx_pdu++; /* set tx rate control information */ tpd->rate.data_cells = fore200e_vcc->rate.data_cells; @@ -1677,49 +1881,16 @@ tpd->spec.length = tx_len; tpd->spec.nseg = 1; tpd->spec.aal = fore200e_atm2fore_aal(vcc->qos.aal); -#ifdef FORE200E_SYNC_SEND - tpd->spec.intr = 0; -#else tpd->spec.intr = 1; -#endif - tpd_haddr.size = sizeof(struct tpd) / 32; /* size is expressed in 32 byte blocks */ + tpd_haddr.size = sizeof(struct tpd) / (1<tpd_dma >> 5; /* shift the address, as we are in a bitfield */ + tpd_haddr.haddr = entry->tpd_dma >> TPD_HADDR_SHIFT; /* shift the address, as we are in a bitfield */ *entry->status = STATUS_PENDING; fore200e->bus->write(*(u32*)&tpd_haddr, (u32*)&entry->cp_entry->tpd_haddr); - -#ifdef FORE200E_SYNC_SEND - { - int ok = fore200e_poll(fore200e, entry->status, STATUS_COMPLETE, 10); - - fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, - FORE200E_DMA_TODEVICE); - - /* free tmp copy of misaligned data */ - if (entry->data) - kfree(entry->data); - - /* notify tx completion */ - if (vcc->pop) - vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); - - if (ok == 0) { - printk(FORE200E "synchronous tx on %d:%d:%d failed\n", vcc->itf, vcc->vpi, vcc->vci); - - atomic_inc(&entry->vcc->stats->tx_err); - return -EIO; - } - atomic_inc(&entry->vcc->stats->tx); - - DPRINTK(3, "synchronous tx on %d:%d:%d succeeded\n", vcc->itf, vcc->vpi, vcc->vci); - - } -#endif + spin_unlock_irqrestore(&fore200e->q_lock, flags); return 0; } @@ -1740,7 +1911,8 @@ return -ENOMEM; } - stats_dma_addr = fore200e->bus->dma_map(fore200e, fore200e->stats, sizeof(struct stats), FORE200E_DMA_FROMDEVICE); + stats_dma_addr = fore200e->bus->dma_map(fore200e, fore200e->stats, + sizeof(struct stats), FORE200E_DMA_FROMDEVICE); FORE200E_NEXT_ENTRY(cmdq->head, QUEUE_SIZE_CMD); @@ -1769,9 +1941,9 @@ static int -fore200e_getsockopt (struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) +fore200e_getsockopt(struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) { - // struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + /* struct fore200e* fore200e = FORE200E_DEV(vcc->dev); */ DPRINTK(2, "getsockopt %d.%d.%d, level = %d, optname = 0x%x, optval = 0x%p, optlen = %d\n", vcc->itf, vcc->vpi, vcc->vci, level, optname, optval, optlen); @@ -1783,7 +1955,7 @@ static int fore200e_setsockopt(struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) { - // struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + /* struct fore200e* fore200e = FORE200E_DEV(vcc->dev); */ DPRINTK(2, "setsockopt %d.%d.%d, level = %d, optname = 0x%x, optval = 0x%p, optlen = %d\n", vcc->itf, vcc->vpi, vcc->vci, level, optname, optval, optlen); @@ -1841,6 +2013,8 @@ struct oc3_opcode opcode; int ok; + DPRINTK(2, "set OC-3 reg = 0x%02x, value = 0x%02x, mask = 0x%02x\n", reg, value, mask); + FORE200E_NEXT_ENTRY(cmdq->head, QUEUE_SIZE_CMD); opcode.opcode = OPCODE_SET_OC3; @@ -1896,7 +2070,7 @@ } error = fore200e_set_oc3(fore200e, SUNI_MCT, mct_value, mct_mask); - if ( error == 0) + if (error == 0) fore200e->loop_mode = loop_mode; return error; @@ -1978,6 +2152,11 @@ struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + if (!test_bit(ATM_VF_READY, &vcc->flags)) { + DPRINTK(1, "VC %d.%d.%d not ready for QoS change\n", vcc->itf, vcc->vpi, vcc->vpi); + return -EINVAL; + } + DPRINTK(2, "change_qos %d.%d.%d, " "(tx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d; " "rx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d), flags = 0x%x\n" @@ -1999,6 +2178,7 @@ fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; fore200e->available_cell_rate -= qos->txtp.max_pcr; + up(&fore200e->rate_sf); memcpy(&vcc->qos, qos, sizeof(struct atm_qos)); @@ -2007,6 +2187,7 @@ fore200e_rate_ctrl(qos, &fore200e_vcc->rate); set_bit(ATM_VF_HASQOS, &vcc->flags); + return 0; } @@ -2027,7 +2208,10 @@ printk(FORE200E "IRQ %s reserved for device %s\n", fore200e_irq_itoa(fore200e->irq), fore200e->name); - tasklet_init(&fore200e->tasklet, fore200e_tasklet, (unsigned long)fore200e); +#ifdef FORE200E_USE_TASKLET + tasklet_init(&fore200e->tx_tasklet, fore200e_tx_tasklet, (unsigned long)fore200e); + tasklet_init(&fore200e->rx_tasklet, fore200e_rx_tasklet, (unsigned long)fore200e); +#endif fore200e->state = FORE200E_STATE_IRQ; return 0; @@ -2042,6 +2226,7 @@ if (!prom) return -ENOMEM; + ok = fore200e->bus->prom_read(fore200e, prom); if (ok < 0) { fore200e_kfree(prom); @@ -2089,10 +2274,16 @@ if (buffer == NULL) return -ENOMEM; + bsq->freebuf = NULL; + for (i = 0; i < nbr; i++) { buffer[ i ].scheme = scheme; buffer[ i ].magn = magn; +#ifdef FORE200E_BSQ_DEBUG + buffer[ i ].index = i; + buffer[ i ].supplied = 0; +#endif /* allocate the receive buffer body */ if (fore200e_chunk_alloc(fore200e, @@ -2105,9 +2296,17 @@ return -ENOMEM; } + + /* insert the buffer into the free buffer list */ + buffer[ i ].next = bsq->freebuf; + bsq->freebuf = &buffer[ i ]; } - /* set next free buffer index */ - bsq->free = 0; + /* all the buffers are free, initially */ + bsq->freebuf_count = nbr; + +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(3, bsq, scheme, magn); +#endif } } @@ -2164,9 +2363,9 @@ FORE200E_INDEX(bsq->rbd_block.align_addr, struct rbd_block, i); bsq->host_entry[ i ].rbd_block_dma = FORE200E_DMA_INDEX(bsq->rbd_block.dma_addr, struct rbd_block, i); - bsq->host_entry[ i ].cp_entry = &cp_entry[ i ]; + bsq->host_entry[ i ].cp_entry = &cp_entry[ i ]; - *bsq->host_entry[ i ].status = STATUS_FREE; + *bsq->host_entry[ i ].status = STATUS_FREE; fore200e->bus->write(FORE200E_DMA_INDEX(bsq->status.dma_addr, enum status, i), &cp_entry[ i ].status_haddr); @@ -2293,10 +2492,11 @@ we do not write here the DMA (physical) base address of each tpd into the related cp resident entry, because the cp relies on this write operation to detect that a new pdu has been submitted for tx */ -} + } - /* set the head entry of the queue */ + /* set the head and tail entries of the queue */ txq->head = 0; + txq->tail = 0; fore200e->state = FORE200E_STATE_INIT_TXQ; return 0; @@ -2315,9 +2515,9 @@ /* allocate and align the array of status words */ if (fore200e->bus->dma_chunk_alloc(fore200e, &cmdq->status, - sizeof(enum status), - QUEUE_SIZE_CMD, - fore200e->bus->status_alignment) < 0) { + sizeof(enum status), + QUEUE_SIZE_CMD, + fore200e->bus->status_alignment) < 0) { return -ENOMEM; } @@ -2353,12 +2553,6 @@ { struct bs_spec* bs_spec = &fore200e->cp_queues->init.bs_spec[ scheme ][ magn ]; - /* dumb value; the firmware doesn't allow us to activate a VC while - selecting a buffer scheme with zero-sized rbd pools */ - - if (pool_size == 0) - pool_size = 64; - fore200e->bus->write(queue_length, &bs_spec->queue_length); fore200e->bus->write(fore200e_rx_buf_size[ scheme ][ magn ], &bs_spec->buffer_size); fore200e->bus->write(pool_size, &bs_spec->pool_size); @@ -2375,7 +2569,8 @@ DPRINTK(2, "device %s being initialized\n", fore200e->name); init_MUTEX(&fore200e->rate_sf); - + spin_lock_init(&fore200e->q_lock); + cpq = fore200e->cp_queues = (struct cp_queues*) (fore200e->virt_base + FORE200E_CP_QUEUES_OFFSET); /* enable cp to host interrupts */ @@ -2457,7 +2652,7 @@ static void __init fore200e_monitor_puts(struct fore200e* fore200e, char* str) { - while(*str) { + while (*str) { /* the i960 monitor doesn't accept any new character if it has something to say */ while (fore200e_monitor_getc(fore200e) >= 0); @@ -2478,6 +2673,11 @@ DPRINTK(2, "device %s firmware being started\n", fore200e->name); +#if defined(__sparc_v9__) + /* reported to be required by SBA cards on some sparc64 hosts */ + fore200e_spin(100); +#endif + sprintf(cmd, "\rgo %x\r", le32_to_cpu(fw_header->start_offset)); fore200e_monitor_puts(fore200e, cmd); @@ -2508,12 +2708,10 @@ DPRINTK(2, "device %s firmware being loaded at 0x%p (%d words)\n", fore200e->name, load_addr, fw_size); -#if 1 if (le32_to_cpu(fw_header->magic) != FW_HEADER_MAGIC) { printk(FORE200E "corrupted %s firmware image\n", fore200e->bus->model_name); return -ENODEV; } -#endif for (; fw_size--; fw_data++, load_addr++) fore200e->bus->write(le32_to_cpu(*fw_data), load_addr); @@ -2540,8 +2738,8 @@ FORE200E_DEV(atm_dev) = fore200e; fore200e->atm_dev = atm_dev; - atm_dev->ci_range.vpi_bits = 8; - atm_dev->ci_range.vci_bits = 10; + atm_dev->ci_range.vpi_bits = FORE200E_VPI_BITS; + atm_dev->ci_range.vci_bits = FORE200E_VCI_BITS; fore200e->available_cell_rate = ATM_OC3_PCR; @@ -2610,7 +2808,7 @@ struct fore200e* fore200e; int index, link; - printk(FORE200E "FORE Systems 200E-series driver - version " FORE200E_VERSION "\n"); + printk(FORE200E "FORE Systems 200E-series ATM driver - version " FORE200E_VERSION "\n"); /* for each configured bus interface */ for (link = 0, bus = fore200e_bus; bus->model_name; bus++) { @@ -2657,11 +2855,13 @@ static int -fore200e_proc_read(struct atm_dev *dev,loff_t* pos,char* page) +fore200e_proc_read(struct atm_dev *dev, loff_t* pos, char* page) { - struct sock *s; - struct fore200e* fore200e = FORE200E_DEV(dev); - int len, left = *pos; + struct fore200e* fore200e = FORE200E_DEV(dev); + struct fore200e_vcc* fore200e_vcc; + struct atm_vcc* vcc; + int i, len, left = *pos; + unsigned long flags; if (!left--) { @@ -2694,14 +2894,15 @@ if (!left--) return sprintf(page, - " supplied small bufs (1):\t%d\n" - " supplied large bufs (1):\t%d\n" - " supplied small bufs (2):\t%d\n" - " supplied large bufs (2):\t%d\n", - fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_SMALL ].count, - fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_LARGE ].count, - fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_SMALL ].count, - fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_LARGE ].count); + " free small bufs, scheme 1:\t%d\n" + " free large bufs, scheme 1:\t%d\n" + " free small bufs, scheme 2:\t%d\n" + " free large bufs, scheme 2:\t%d\n", + fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_SMALL ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_LARGE ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_SMALL ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_LARGE ].freebuf_count); + if (!left--) { u32 hb = fore200e->bus->read(&fore200e->cp_queues->heartbeat); @@ -2740,7 +2941,7 @@ u32 media_index = FORE200E_MEDIA_INDEX(fore200e->bus->read(&fore200e->cp_queues->media_type)); u32 oc3_index; - if (media_index < 0 || media_index > 4) + if ((media_index < 0) || (media_index > 4)) media_index = 5; switch (fore200e->loop_mode) { @@ -2887,49 +3088,60 @@ " large b1:\t\t\t%10u\n" " small b2:\t\t\t%10u\n" " large b2:\t\t\t%10u\n" - " RX PDUs:\t\t\t%10u\n", + " RX PDUs:\t\t\t%10u\n" + " TX PDUs:\t\t\t%10lu\n", fore200e_swap(fore200e->stats->aux.small_b1_failed), fore200e_swap(fore200e->stats->aux.large_b1_failed), fore200e_swap(fore200e->stats->aux.small_b2_failed), fore200e_swap(fore200e->stats->aux.large_b2_failed), - fore200e_swap(fore200e->stats->aux.rpd_alloc_failed)); - + fore200e_swap(fore200e->stats->aux.rpd_alloc_failed), + fore200e->tx_sat); + if (!left--) return sprintf(page,"\n" " receive carrier:\t\t\t%s\n", fore200e->stats->aux.receive_carrier ? "ON" : "OFF!"); if (!left--) { - struct atm_vcc *vcc; - struct fore200e_vcc* fore200e_vcc; - - len = sprintf(page,"\n" - " VCCs:\n address\tVPI.VCI:AAL\t(min/max tx PDU size) (min/max rx PDU size)\n"); - - read_lock(&vcc_sklist_lock); - for (s = vcc_sklist; s; s = s->next) { - vcc = s->protinfo.af_atm; + return sprintf(page,"\n" + " VCCs:\n address VPI VCI AAL " + "TX PDUs TX min/max size RX PDUs RX min/max size\n"); + } - if (vcc->dev != fore200e->atm_dev) - continue; + + for (i = 0; i < NBR_CONNECT; i++) { + + vcc = fore200e->vc_map[i].vcc; + + if (vcc == NULL) + continue; + + spin_lock_irqsave(&fore200e->q_lock, flags); + + if (vcc && test_bit(ATM_VF_READY, &vcc->flags) && !left--) { fore200e_vcc = FORE200E_VCC(vcc); - - len += sprintf(page + len, - " %x\t%d.%d:%d\t\t(%d/%d)\t(%d/%d)\n", + ASSERT(fore200e_vcc); + + len = sprintf(page, + " %08x %03d %05d %1d %09lu %05d/%05d %09lu %05d/%05d\n", (u32)(unsigned long)vcc, vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal), + fore200e_vcc->tx_pdu, fore200e_vcc->tx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->tx_min_pdu, fore200e_vcc->tx_max_pdu, + fore200e_vcc->rx_pdu, fore200e_vcc->rx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->rx_min_pdu, fore200e_vcc->rx_max_pdu ); + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + return len; } - read_unlock(&vcc_sklist_lock); - return len; + spin_unlock_irqrestore(&fore200e->q_lock, flags); } - + return 0; } @@ -2966,7 +3178,7 @@ send: fore200e_send, change_qos: fore200e_change_qos, proc_read: fore200e_proc_read, - owner: THIS_MODULE, + owner: THIS_MODULE }; @@ -3027,4 +3239,6 @@ {} }; +#ifdef MODULE_LICENSE MODULE_LICENSE("GPL"); +#endif diff -Nru a/drivers/atm/fore200e.h b/drivers/atm/fore200e.h --- a/drivers/atm/fore200e.h Fri Apr 16 10:44:36 2004 +++ b/drivers/atm/fore200e.h Fri Apr 16 10:44:36 2004 @@ -23,19 +23,21 @@ #define BUFFER_S2_SIZE SMALL_BUFFER_SIZE /* size of small buffers, scheme 2 */ #define BUFFER_L2_SIZE LARGE_BUFFER_SIZE /* size of large buffers, scheme 2 */ -#define BUFFER_S1_NBR (RBD_BLK_SIZE * 2) -#define BUFFER_L1_NBR (RBD_BLK_SIZE * 2) +#define BUFFER_S1_NBR (RBD_BLK_SIZE * 6) +#define BUFFER_L1_NBR (RBD_BLK_SIZE * 4) -#define BUFFER_S2_NBR (RBD_BLK_SIZE * 2) -#define BUFFER_L2_NBR (RBD_BLK_SIZE * 2) +#define BUFFER_S2_NBR (RBD_BLK_SIZE * 6) +#define BUFFER_L2_NBR (RBD_BLK_SIZE * 4) #define QUEUE_SIZE_CMD 16 /* command queue capacity */ #define QUEUE_SIZE_RX 64 /* receive queue capacity */ #define QUEUE_SIZE_TX 256 /* transmit queue capacity */ -#define QUEUE_SIZE_BS 16 /* buffer supply queue capacity */ +#define QUEUE_SIZE_BS 32 /* buffer supply queue capacity */ -#define NBR_CONNECT 1024 /* number of ATM connections */ +#define FORE200E_VPI_BITS 0 +#define FORE200E_VCI_BITS 10 +#define NBR_CONNECT (1 << (FORE200E_VPI_BITS + FORE200E_VCI_BITS)) /* number of connections */ #define TSD_FIXED 2 @@ -207,6 +209,7 @@ ) } tpd_haddr_t; +#define TPD_HADDR_SHIFT 5 /* addr aligned on 32 byte boundary */ /* cp resident transmit queue entry */ @@ -517,13 +520,15 @@ /* host resident transmit queue entry */ typedef struct host_txq_entry { - struct cp_txq_entry* cp_entry; /* addr of cp resident tx queue entry */ - enum status* status; /* addr of host resident status */ - struct tpd* tpd; /* addr of transmit PDU descriptor */ - u32 tpd_dma; /* DMA address of tpd */ - struct sk_buff* skb; /* related skb */ - struct atm_vcc* vcc; /* related vcc */ - void* data; /* copy of misaligned data */ + struct cp_txq_entry* cp_entry; /* addr of cp resident tx queue entry */ + enum status* status; /* addr of host resident status */ + struct tpd* tpd; /* addr of transmit PDU descriptor */ + u32 tpd_dma; /* DMA address of tpd */ + struct sk_buff* skb; /* related skb */ + void* data; /* copy of misaligned data */ + unsigned long incarn; /* vc_map incarnation when submitted for tx */ + struct fore200e_vc_map* vc_map; + } host_txq_entry_t; @@ -576,6 +581,10 @@ enum buffer_scheme scheme; /* buffer scheme */ enum buffer_magn magn; /* buffer magnitude */ struct chunk data; /* data buffer */ +#ifdef FORE200E_BSQ_DEBUG + unsigned long index; /* buffer # in queue */ + int supplied; /* 'buffer supplied' flag */ +#endif } buffer_t; @@ -602,6 +611,7 @@ typedef struct host_txq { struct host_txq_entry host_entry[ QUEUE_SIZE_TX ]; /* host resident tx queue entries */ int head; /* head of tx queue */ + int tail; /* tail of tx queue */ struct chunk tpd; /* array of tpds */ struct chunk status; /* arry of completion status */ int txing; /* number of pending PDUs in tx queue */ @@ -626,8 +636,8 @@ struct chunk rbd_block; /* array of rbds */ struct chunk status; /* array of completion status */ struct buffer* buffer; /* array of rx buffers */ - int free; /* index of first free rx buffer */ - volatile int count; /* count of supplied rx buffers */ + struct buffer* freebuf; /* list of free rx buffers */ + volatile int freebuf_count; /* count of free rx buffers */ } host_bsq_t; @@ -846,6 +856,17 @@ #endif +/* vc mapping */ + +typedef struct fore200e_vc_map { + struct atm_vcc* vcc; /* vcc entry */ + unsigned long incarn; /* vcc incarnation number */ +} fore200e_vc_map_t; + +#define FORE200E_VC_MAP(fore200e, vpi, vci) \ + (& (fore200e)->vc_map[ ((vpi) << FORE200E_VCI_BITS) | (vci) ]) + + /* per-device data */ typedef struct fore200e { @@ -879,20 +900,29 @@ struct stats* stats; /* last snapshot of the stats */ struct semaphore rate_sf; /* protects rate reservation ops */ - struct tasklet_struct tasklet; /* performs interrupt work */ + spinlock_t q_lock; /* protects queue ops */ +#ifdef FORE200E_USE_TASKLET + struct tasklet_struct tx_tasklet; /* performs tx interrupt work */ + struct tasklet_struct rx_tasklet; /* performs rx interrupt work */ +#endif + unsigned long tx_sat; /* tx queue saturation count */ + unsigned long incarn_count; + struct fore200e_vc_map vc_map[ NBR_CONNECT ]; /* vc mapping */ } fore200e_t; /* per-vcc data */ typedef struct fore200e_vcc { - enum buffer_scheme scheme; /* rx buffer scheme */ - struct tpd_rate rate; /* tx rate control data */ - int rx_min_pdu; /* size of smallest PDU received */ - int rx_max_pdu; /* size of largest PDU received */ - int tx_min_pdu; /* size of smallest PDU transmitted */ - int tx_max_pdu; /* size of largest PDU transmitted */ + enum buffer_scheme scheme; /* rx buffer scheme */ + struct tpd_rate rate; /* tx rate control data */ + int rx_min_pdu; /* size of smallest PDU received */ + int rx_max_pdu; /* size of largest PDU received */ + int tx_min_pdu; /* size of smallest PDU transmitted */ + int tx_max_pdu; /* size of largest PDU transmitted */ + unsigned long tx_pdu; /* nbr of tx pdus */ + unsigned long rx_pdu; /* nbr of rx pdus */ } fore200e_vcc_t; From shemminger@osdl.org Fri Apr 23 15:20:30 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 15:20:34 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NMKUKO003218 for ; Fri, 23 Apr 2004 15:20:30 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3NMKI201529; Fri, 23 Apr 2004 15:20:18 -0700 Date: Fri, 23 Apr 2004 15:20:17 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] Report vegas connection info Message-Id: <20040423152017.556fbbb3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4884 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: 2109 Lines: 74 Simple extension of tcp_diag to send out vegas information. Have simple addition to 'ss' command to print: $ ss -i State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB 0 0 172.20.1.73:32775 172.20.1.60:iperf rto:201 rtt:1.875/0.75 cwnd:8 ssthresh:3 vegas bw:9.2672e+10 diff -Nru a/include/linux/tcp_diag.h b/include/linux/tcp_diag.h --- a/include/linux/tcp_diag.h Fri Apr 23 14:56:53 2004 +++ b/include/linux/tcp_diag.h Fri Apr 23 14:56:53 2004 @@ -98,9 +98,10 @@ TCPDIAG_NONE, TCPDIAG_MEMINFO, TCPDIAG_INFO, + TCPDIAG_VEGASINFO, }; -#define TCPDIAG_MAX TCPDIAG_INFO +#define TCPDIAG_MAX TCPDIAG_VEGASINFO /* TCPDIAG_MEM */ @@ -112,5 +113,15 @@ __u32 tcpdiag_fmem; __u32 tcpdiag_tmem; }; + +/* TCPDIAG_VEGASINFO */ + +struct tcpvegas_info { + __u32 tcpv_enabled; + __u32 tcpv_rttcnt; + __u32 tcpv_rtt; + __u32 tcpv_minrtt; +}; + #endif /* _TCP_DIAG_H_ */ diff -Nru a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c --- a/net/ipv4/tcp_diag.c Fri Apr 23 14:56:53 2004 +++ b/net/ipv4/tcp_diag.c Fri Apr 23 14:56:53 2004 @@ -50,6 +50,7 @@ struct nlmsghdr *nlh; struct tcp_info *info = NULL; struct tcpdiag_meminfo *minfo = NULL; + struct tcpvegas_info *vinfo = NULL; unsigned char *b = skb->tail; nlh = NLMSG_PUT(skb, pid, seq, TCPDIAG_GETSOCK, sizeof(*r)); @@ -59,6 +60,9 @@ minfo = TCPDIAG_PUT(skb, TCPDIAG_MEMINFO, sizeof(*minfo)); if (ext & (1<<(TCPDIAG_INFO-1))) info = TCPDIAG_PUT(skb, TCPDIAG_INFO, sizeof(*info)); + + if (tcp_is_vegas(tp) && (ext & (1<<(TCPDIAG_VEGASINFO-1)))) + vinfo = TCPDIAG_PUT(skb, TCPDIAG_VEGASINFO, sizeof(*vinfo)); } r->tcpdiag_family = sk->sk_family; r->tcpdiag_state = sk->sk_state; @@ -194,6 +198,13 @@ info->tcpi_snd_cwnd = tp->snd_cwnd; info->tcpi_advmss = tp->advmss; info->tcpi_reordering = tp->reordering; + } + + if (vinfo) { + vinfo->tcpv_enabled = tp->vegas.doing_vegas_now; + vinfo->tcpv_rttcnt = tp->vegas.cntRTT; + vinfo->tcpv_rtt = tp->vegas.baseRTT; + vinfo->tcpv_minrtt = tp->vegas.minRTT; } nlh->nlmsg_len = skb->tail - b; From jonmason@us.ibm.com Fri Apr 23 15:27:37 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 15:27:41 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NMRbKO003759 for ; Fri, 23 Apr 2004 15:27:37 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3NMRN87194134; Fri, 23 Apr 2004 18:27:23 -0400 Received: from d03nm130.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3NMRMb2347880; Fri, 23 Apr 2004 16:27:22 -0600 In-Reply-To: <20040423011834.A3232@electric-eye.fr.zoreil.com> To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Fri, 23 Apr 2004 17:27:17 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/23/2004 16:27:22, Serialize complete at 04/23/2004 16:27:22 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4885 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 2654 Lines: 73 Jon D Mason : [...] --- r8169.c 2004-04-18 22:51:33.000000000 -0500 +++ r8169.c 2004-04-22 08:08:57.526577048 -0500 [...] @@ -1692,6 +1737,31 @@ static struct net_device_stats *rtl8169_ return &tp->stats; } +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget) +{ + u32 status, work_done = 0, work_to_do = min(*budget, dev->quota); + struct rtl8169_private *tp = dev->priv; + void *ioaddr = tp->mmio_addr; + + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); + + *budget -= work_done; + dev->quota -= work_done; + + if ((work_done < work_to_do) || !netif_running(dev)) { > Packets are received here. > Tx interrupt is issued. > --> Interrupts status register is completely cleared by the irq handler <-- > There are pending Rx packets. > r8169_poll() is not activated by the irq handler. > > --> Pending Rx packets may wait long. + netif_rx_complete(dev); + status = RTL_R16(IntrStatus); + if (!status) { + RTL_W16(IntrMask, rtl8169_intr_mask); + status = RTL_R16(IntrMask); + } > The previous lines imply that if, according to IntrStatus, there is pending > Rx work but no pending Tx work, the Rx interrupts are kept disabled. The above was a poor attempt to solve what I thought was the problem you were describing before. The Interrupt Mask should be fully restored regardless of pending interrupts. Will do. > If I am not mistaken (1:55 AM here), either 1) you do not clear the RX > related bits of IntrStatus in r8169_interrupt() but you clear it in > rtl8169_poll() and you add local_irq_{en/dis}able() to rtl8169_poll() > (ala 8139cp.c) or 2) you modify r8169_interrupt() so that it can signal > to rtl8169_poll() that it cleared itself the Rx bits of IntrStatus whereas > rtl8169_poll() was running (ala epic100-netdev). > >If you hesitate, go for 1). 2) works but I have not benchmarketed it yet :o) I have a few different ideas that I think will solve the problem, but I need to think them out first. I will let you know. Also, thanks for all of your help, hopefully I can get this working properly soon. > >If you have doubts regarding your Tx part, feel free to send any code. I can send you my code, but it might be better to do off the list (as not to spam everyone). :-) Thanks, Jon From carson@taltos.org Fri Apr 23 15:33:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 15:33:19 -0700 (PDT) Received: from gandalf.taltos.org (dsl092-109-241.nyc2.dsl.speakeasy.net [66.92.109.241]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NMXEKO004112 for ; Fri, 23 Apr 2004 15:33:15 -0700 Received: from localhost.localdomain (localhost [127.0.0.1]) by gandalf.taltos.org (Postfix) with ESMTP id B6B4A3A5BB3; Fri, 23 Apr 2004 18:33:13 -0400 (EDT) Date: Fri, 23 Apr 2004 18:33:13 -0400 From: Carson Gaspar To: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-ID: <382320000.1082759593@taltos.ny.ficc.gs.com> X-Mailer: Mulberry/3.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 4886 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: carson@taltos.org Precedence: bulk X-list: netdev Content-Length: 4134 Lines: 102 FYI, we see the exact same panic with the tg3 driver using 2.4.25 and distcc with sendfile(). The bcm5700 driver also panics, but I haven't captured a panic message to be certain it's the same bug. kernel BUG at page_alloc.c:98! invalid operand: 0000 CPU: 1 EIP: 0010:[] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000001 ebx: c294dcb0 ecx: 00000001 edx: 00000020 esi: edb6e2e0 edi: 00000000 ebp: 00000004 esp: c55af9b4 ds: 0018 es: 0018 ss: 0018 Process cc1plus (pid: 21186, stackpage=c55af000) Stack: c022e9ee f6fb1000 c022aa9c 00000287 00000206 00000286 db5a9600 00000001 edb6e2e0 edb6e2e0 00000004 c022aa4e edb6e2e0 f3716100 c022aa9c edb6e2e0 f371623c f3716100 c022ac25 edb6e2e0 00000000 c025423a edb6e2e0 c55ae000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] []o[] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 62 00 bd 35 2a c0 89 d8 e8 5f ed ff ff 8b 6b 28 85 ed >>EIP; c0139492 <__free_pages_ok+32/2b0> <===== Trace; c022e9ee Trace; c022aa9c Trace; c022aa4e Trace; c022aa9c Trace; c022ac25 <__kfree_skb+125/130> Trace; c025423a Trace; c0247d28 Trace; c024be53 Trace; c025675b Trace; c02547c8 Trace; c0256bdf Trace; c0138175 Trace; c022aa9c Trace; c0254307 Trace; c0258a67 Trace; c022aa9c Trace; c0254307 Trace; c025ef5b Trace; c025f4ad Trace; c022ac25 <__kfree_skb+125/130> Trace; c0256bec Trace; c01550dc Trace; c014ba00 Trace; c02449a3 Trace; c02449a3 Trace; c0244da6 Trace; c025ef5b Trace; c0139c05 <__alloc_pages+75/2f0> Trace; c025f4ad Trace; c022a8af Trace; c022f189 Trace; c022a8af Trace; f8990d48 <[usbcore]__kstrtab_usb_hcd_giveback_urb+52f8/6a50> Trace; c02449a3 Trace; f8990ef9 <[usbcore]__kstrtab_usb_hcd_giveback_urb+54a9/6a50> Trace; c022f3a3 Trace; c0119e06 Trace; c0131b08 Trace; c0131990 Trace; c01410d6 Trace; c012e72a Trace; c0108b5f Code; c0139492 <__free_pages_ok+32/2b0> 00000000 <_EIP>: Code; c0139492 <__free_pages_ok+32/2b0> <===== 0: 0f 0b ud2a <===== Code; c0139494 <__free_pages_ok+34/2b0> 2: 62 00 bound %eax,(%eax) Code; c0139496 <__free_pages_ok+36/2b0> 4: bd 35 2a c0 89 mov $0x89c02a35,%ebp Code; c013949b <__free_pages_ok+3b/2b0> 9: d8 e8 fsubr %st(0),%st Code; c013949d <__free_pages_ok+3d/2b0> b: 5f pop %edi Code; c013949e <__free_pages_ok+3e/2b0> c: ed in (%dx),%eax Code; c013949f <__free_pages_ok+3f/2b0> d: ff (bad) Code; c01394a0 <__free_pages_ok+40/2b0> e: ff 8b 6b 28 85 ed decl 0xed85286b(%ebx) <0>Kernel panic: Aiee, killing interrupt handler! From weddy@drpepper.grc.nasa.gov Fri Apr 23 16:22:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 16:22:48 -0700 (PDT) Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NNMcKO007995 for ; Fri, 23 Apr 2004 16:22:39 -0700 Received: from lombok-fi.grc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 3B73D6BA18 for ; Fri, 23 Apr 2004 19:22:33 -0400 (EDT) Received: from drpepper.grc.nasa.gov (drpepper.grc.nasa.gov [139.88.122.76]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id i3NNMW3c001364; Fri, 23 Apr 2004 19:22:32 -0400 (EDT) Received: by drpepper.grc.nasa.gov (Postfix, from userid 501) id DF4D2289DF; Fri, 23 Apr 2004 19:19:14 -0400 (EDT) Date: Fri, 23 Apr 2004 19:19:14 -0400 From: Wesley Eddy To: David Stevens Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: TCP rto estimation patch Message-ID: <20040423231914.GB9057@grc.nasa.gov> Reply-To: weddy@grc.nasa.gov References: <20040423142445.GC501@grc.nasa.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: X-People-Whose-Mailers-Cant-See-This-Header-Are-Lame: true User-Agent: Mutt/1.5.5.1i X-archive-position: 4887 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: weddy@grc.nasa.gov Precedence: bulk X-list: netdev Content-Length: 840 Lines: 32 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 02:06:39PM -0700, David Stevens wrote: > I believe "2" and "3" are the scale factors for the fixed-point=20 > representation > of the data, not the "alpha" and "beta" I remember from the estimator=20 > paper. > The math is done with bit shifts instead of floating point multiplications. It's the same thing though. The 2 means beta of 1/4 and the 3 means alpha of 1/8. -Wes=20 --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAiaRyzBuYqbnj3IwRAkQ4AJ9dXt7Odh3p18MhTydzRxoXrIiGsACdEZfs 7aHa74eaeQkk2fp2VeDNwfA= =CQbL -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- From davem@redhat.com Fri Apr 23 16:30:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 16:30:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NNU9KO008339 for ; Fri, 23 Apr 2004 16:30:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3NNU2KG028352; Fri, 23 Apr 2004 19:30:02 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3NNU2p24613; Fri, 23 Apr 2004 19:30:02 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3NNTY1n021858; Fri, 23 Apr 2004 19:29:34 -0400 Date: Fri, 23 Apr 2004 16:29:33 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] Report vegas connection info Message-Id: <20040423162933.20638d13.davem@redhat.com> In-Reply-To: <20040423152017.556fbbb3@dell_ss3.pdx.osdl.net> References: <20040423152017.556fbbb3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4888 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 191 Lines: 8 On Fri, 23 Apr 2004 15:20:17 -0700 Stephen Hemminger wrote: > Simple extension of tcp_diag to send out vegas information. Looks great, patch applied. Thanks Stephen. From davem@redhat.com Fri Apr 23 16:35:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 16:35:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NNZjKO008697 for ; Fri, 23 Apr 2004 16:35:47 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3NNZeKG029431; Fri, 23 Apr 2004 19:35:40 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3NNZep25864; Fri, 23 Apr 2004 19:35:40 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3NNZC1n023451; Fri, 23 Apr 2004 19:35:12 -0400 Date: Fri, 23 Apr 2004 16:35:11 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: [fore200e] 0.3e version (1 of 2) Message-Id: <20040423163511.2b4ebf61.davem@redhat.com> In-Reply-To: <200404232101.i3NL1hGG002420@ginger.cmf.nrl.navy.mil> References: <200404232101.i3NL1hGG002420@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4889 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 294 Lines: 8 On Fri, 23 Apr 2004 17:01:44 -0400 "chas williams (contractor)" wrote: > this is an update for the fore200e driver in the 2.4 > kernels. part 2 of 2 of this patches makes tasklet > use configurable. please apply to the 2.4 kernel. Both patches applied, thanks Chas. From davem@redhat.com Fri Apr 23 16:40:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 16:40:16 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NNeBKO009065 for ; Fri, 23 Apr 2004 16:40:11 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3NNe7KG030087; Fri, 23 Apr 2004 19:40:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3NNe7p26603; Fri, 23 Apr 2004 19:40:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3NNdd1n024023; Fri, 23 Apr 2004 19:39:39 -0400 Date: Fri, 23 Apr 2004 16:39:38 -0700 From: "David S. Miller" To: Geert Uytterhoeven Cc: marcelo.tosatti@cyclades.com, netdev@oss.sgi.com, linux-kernel@vger.kernel.org, linux-net@vger.kernel.org Subject: Re: [PATCH] pktgen dependency (was: Re: Linux 2.4.27-pre1) Message-Id: <20040423163938.013f362f.davem@redhat.com> In-Reply-To: References: <20040422130651.GB18358@logos.cnet> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4890 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 320 Lines: 10 On Fri, 23 Apr 2004 16:58:58 +0200 (MEST) Geert Uytterhoeven wrote: > The packet generator doesn't compile if procfs is disabled. > IIRC, there was an agreement that this dependency is needed: Applied, thanks Geert. Can you cook up a 2.6.x variant as well if that is needed too? Thanks again. From chas@cmf.nrl.navy.mil Fri Apr 23 17:29:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 17:29:55 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O0TkKO010093 for ; Fri, 23 Apr 2004 17:29:46 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i3O0TPE3005478; Fri, 23 Apr 2004 20:29:25 -0400 (EDT) Message-Id: <200404240029.i3O0TPE3005478@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [fore200e] 0.3e version by Christophe Lizzi (lizzi@cnam.fr) (1 of 2) Reply-To: chas3@users.sourceforge.net Date: Fri, 23 Apr 2004 20:29:26 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4891 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 61778 Lines: 1938 dave, fore200e 0.3e for 2.6 kernels. please apply when available. --thanks! # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1809 -> 1.1810 # drivers/atm/fore200e.h 1.2 -> 1.3 # drivers/atm/fore200e.c 1.24 -> 1.25 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/16 chas@relax.cmf.nrl.navy.mil 1.1810 # [ATM]: [fore200e] 0.3e version by Christophe Lizzi (lizzi@cnam.fr) # -------------------------------------------- # diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c Fri Apr 16 14:52:15 2004 +++ b/drivers/atm/fore200e.c Fri Apr 16 14:52:15 2004 @@ -2,7 +2,7 @@ $Id: fore200e.c,v 1.5 2000/04/14 10:10:34 davem Exp $ A FORE Systems 200E-series driver for ATM on Linux. - Christophe Lizzi (lizzi@cnam.fr), October 1999-March 2000. + Christophe Lizzi (lizzi@cnam.fr), October 1999-March 2003. Based on the PCA-200E driver from Uwe Dannowski (Uwe.Dannowski@inf.tu-dresden.de). @@ -33,6 +33,8 @@ #include #include #include +#include +#include #include #include #include @@ -44,7 +46,6 @@ #include #include #include -#include #ifdef CONFIG_ATM_FORE200E_SBA #include @@ -54,25 +55,33 @@ #include #endif -#include +#if 0 /* defer interrupt work to a tasklet */ +#define FORE200E_USE_TASKLET +#endif -#include "fore200e.h" -#include "suni.h" +#if 0 /* enable the debugging code of the buffer supply queues */ +#define FORE200E_BSQ_DEBUG +#endif -#if 1 /* ensure correct handling of 52-byte AAL0 SDUs used by atmdump-like apps */ +#if 1 /* ensure correct handling of 52-byte AAL0 SDUs expected by atmdump-like apps */ #define FORE200E_52BYTE_AAL0_SDU #endif -#define FORE200E_VERSION "0.2d" +#include "fore200e.h" +#include "suni.h" +#define FORE200E_VERSION "0.3e" #define FORE200E "fore200e: " +#if 0 /* override .config */ +#define CONFIG_ATM_FORE200E_DEBUG 1 +#endif #if defined(CONFIG_ATM_FORE200E_DEBUG) && (CONFIG_ATM_FORE200E_DEBUG > 0) #define DPRINTK(level, format, args...) do { if (CONFIG_ATM_FORE200E_DEBUG >= (level)) \ - printk(FORE200E format, ##args); } while(0) + printk(FORE200E format, ##args); } while (0) #else -#define DPRINTK(level, format, args...) while(0) +#define DPRINTK(level, format, args...) do {} while (0) #endif @@ -83,12 +92,23 @@ #define FORE200E_INDEX(virt_addr, type, index) (&((type *)(virt_addr))[ index ]) -#define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo)) +#define FORE200E_NEXT_ENTRY(index, modulo) (index = ++(index) % (modulo)) #define MSECS(ms) (((ms)*HZ/1000)+1) +#if 1 +#define ASSERT(expr) if (!(expr)) { \ + printk(FORE200E "assertion failed! %s[%d]: %s\n", \ + __FUNCTION__, __LINE__, #expr); \ + panic(FORE200E "%s", __FUNCTION__); \ + } +#else +#define ASSERT(expr) do {} while (0) +#endif + + extern const struct atmdev_ops fore200e_ops; extern const struct fore200e_bus fore200e_bus[]; @@ -221,29 +241,6 @@ } - -#if 0 /* currently unused */ -static int -fore200e_checkup(struct fore200e* fore200e) -{ - u32 hb1, hb2; - - hb1 = fore200e->bus->read(&fore200e->cp_queues->heartbeat); - fore200e_spin(10); - hb2 = fore200e->bus->read(&fore200e->cp_queues->heartbeat); - - if (hb2 <= hb1) { - printk(FORE200E "device %s heartbeat is not counting upwards, hb1 = %x; hb2 = %x\n", - fore200e->name, hb1, hb2); - return -EIO; - } - printk(FORE200E "device %s heartbeat is ok\n", fore200e->name); - - return 0; -} -#endif - - static void fore200e_spin(int msecs) { @@ -440,7 +437,6 @@ } - #ifdef CONFIG_ATM_FORE200E_PCA static u32 fore200e_pca_read(volatile u32* addr) @@ -505,20 +501,16 @@ fore200e_pca_dma_chunk_alloc(struct fore200e* fore200e, struct chunk* chunk, int size, int nbr, int alignment) { -#if defined(__sparc_v9__) /* returned chunks are page-aligned */ + chunk->alloc_size = size * nbr; chunk->alloc_addr = pci_alloc_consistent((struct pci_dev*)fore200e->bus_dev, chunk->alloc_size, &chunk->dma_addr); - if (chunk->alloc_addr == NULL || chunk->dma_addr == 0) + if ((chunk->alloc_addr == NULL) || (chunk->dma_addr == 0)) return -ENOMEM; chunk->align_addr = chunk->alloc_addr; -#else - if (fore200e_chunk_alloc(fore200e, chunk, size * nbr, alignment, FORE200E_DMA_BIDIRECTIONAL) < 0) - return -ENOMEM; -#endif return 0; } @@ -529,14 +521,10 @@ static void fore200e_pca_dma_chunk_free(struct fore200e* fore200e, struct chunk* chunk) { -#if defined(__sparc_v9__) pci_free_consistent((struct pci_dev*)fore200e->bus_dev, chunk->alloc_size, chunk->alloc_addr, chunk->dma_addr); -#else - fore200e_chunk_free(fore200e, chunk); -#endif } @@ -544,7 +532,15 @@ fore200e_pca_irq_check(struct fore200e* fore200e) { /* this is a 1 bit register */ - return readl(fore200e->regs.pca.psr); + int irq_posted = readl(fore200e->regs.pca.psr); + +#if defined(CONFIG_ATM_FORE200E_DEBUG) && (CONFIG_ATM_FORE200E_DEBUG == 2) + if (irq_posted && (readl(fore200e->regs.pca.hcr) & PCA200E_HCR_OUTFULL)) { + DPRINTK(2,"FIFO OUT full, device %d\n", fore200e->atm_dev->number); + } +#endif + + return irq_posted; } @@ -578,7 +574,7 @@ DPRINTK(1, "device %s mapped to 0x%p\n", fore200e->name, fore200e->virt_base); - /* gain access to the PCA-200E specific registers */ + /* gain access to the PCA specific registers */ fore200e->regs.pca.hcr = (u32*)(fore200e->virt_base + PCA200E_HCR_OFFSET); fore200e->regs.pca.imr = (u32*)(fore200e->virt_base + PCA200E_IMR_OFFSET); fore200e->regs.pca.psr = (u32*)(fore200e->virt_base + PCA200E_PSR_OFFSET); @@ -593,8 +589,6 @@ { DPRINTK(2, "device %s being unmapped from memory\n", fore200e->name); - /* XXX iounmap() does nothing on PowerPC (at least in 2.2.12 and 2.3.41), - this leads to a kernel panic if the module is loaded and unloaded several times */ if (fore200e->virt_base != NULL) iounmap(fore200e->virt_base); } @@ -604,7 +598,7 @@ fore200e_pca_configure(struct fore200e* fore200e) { struct pci_dev* pci_dev = (struct pci_dev*)fore200e->bus_dev; - u8 master_ctrl; + u8 master_ctrl, latency; DPRINTK(2, "device %s being configured\n", fore200e->name); @@ -613,21 +607,29 @@ return -EIO; } - pci_read_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, &master_ctrl); + pci_read_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, &master_ctrl); master_ctrl = master_ctrl -#if 0 - | PCA200E_CTRL_DIS_CACHE_RD - | PCA200E_CTRL_DIS_WRT_INVAL -#endif #if defined(__BIG_ENDIAN) /* request the PCA board to convert the endianess of slave RAM accesses */ | PCA200E_CTRL_CONVERT_ENDIAN #endif +#if 0 + | PCA200E_CTRL_DIS_CACHE_RD + | PCA200E_CTRL_DIS_WRT_INVAL + | PCA200E_CTRL_ENA_CONT_REQ_MODE + | PCA200E_CTRL_2_CACHE_WRT_INVAL +#endif | PCA200E_CTRL_LARGE_PCI_BURSTS; pci_write_config_byte(pci_dev, PCA200E_PCI_MASTER_CTRL, master_ctrl); + /* raise latency from 32 (default) to 192, as this seems to prevent NIC + lockups (under heavy rx loads) due to continuous 'FIFO OUT full' condition. + this may impact the performances of other PCI devices on the same bus, though */ + latency = 192; + pci_write_config_byte(pci_dev, PCI_LATENCY_TIMER, latency); + fore200e->state = FORE200E_STATE_CONFIGURE; return 0; } @@ -656,11 +658,7 @@ fore200e->bus = bus; fore200e->bus_dev = pci_dev; fore200e->irq = pci_dev->irq; - fore200e->phys_base = pci_resource_start (pci_dev, 0); - -#if defined(__powerpc__) - fore200e->phys_base += KERNELBASE; -#endif + fore200e->phys_base = pci_resource_start(pci_dev, 0); sprintf(fore200e->name, "%s-%d", bus->model_name, index - 1); @@ -728,8 +726,6 @@ #endif /* CONFIG_ATM_FORE200E_PCA */ - - #ifdef CONFIG_ATM_FORE200E_SBA static u32 @@ -799,7 +795,7 @@ chunk->alloc_size, &chunk->dma_addr); - if (chunk->alloc_addr == NULL || chunk->dma_addr == 0) + if ((chunk->alloc_addr == NULL) || (chunk->dma_addr == 0)) return -ENOMEM; chunk->align_addr = chunk->alloc_addr; @@ -858,8 +854,7 @@ struct sbus_dev* sbus_dev = (struct sbus_dev*)fore200e->bus_dev; unsigned int bursts; - /* gain access to the SBA-200E specific registers */ - + /* gain access to the SBA specific registers */ fore200e->regs.sba.hcr = (u32*)sbus_ioremap(&sbus_dev->resource[0], 0, SBA200E_HCR_LENGTH, "SBA HCR"); fore200e->regs.sba.bsr = (u32*)sbus_ioremap(&sbus_dev->resource[1], 0, SBA200E_BSR_LENGTH, "SBA BSR"); fore200e->regs.sba.isr = (u32*)sbus_ioremap(&sbus_dev->resource[2], 0, SBA200E_ISR_LENGTH, "SBA ISR"); @@ -880,17 +875,6 @@ if (sbus_can_dma_64bit(sbus_dev)) sbus_set_sbus64(sbus_dev, bursts); -#if 0 - if (bursts & DMA_BURST16) - fore200e->bus->write(SBA200E_BSR_BURST16, fore200e->regs.sba.bsr); - else - if (bursts & DMA_BURST8) - fore200e->bus->write(SBA200E_BSR_BURST8, fore200e->regs.sba.bsr); - else - if (bursts & DMA_BURST4) - fore200e->bus->write(SBA200E_BSR_BURST4, fore200e->regs.sba.bsr); -#endif - fore200e->state = FORE200E_STATE_MAP; return 0; } @@ -935,13 +919,11 @@ return NULL; found: -#if 1 if (sbus_dev->num_registers != 4) { printk(FORE200E "this %s device has %d instead of 4 registers\n", bus->model_name, sbus_dev->num_registers); return NULL; } -#endif fore200e = fore200e_kmalloc(sizeof(struct fore200e), GFP_KERNEL); if (fore200e == NULL) @@ -994,46 +976,143 @@ static void -fore200e_irq_tx(struct fore200e* fore200e) +fore200e_tx_irq(struct fore200e* fore200e) { - struct host_txq_entry* entry; - int i; - - entry = fore200e->host_txq.host_entry; + struct host_txq* txq = &fore200e->host_txq; + struct host_txq_entry* entry; + struct atm_vcc* vcc; + struct fore200e_vc_map* vc_map; + + if (fore200e->host_txq.txing == 0) + return; + + for (;;) { + + entry = &txq->host_entry[ txq->tail ]; + + if ((*entry->status & STATUS_COMPLETE) == 0) { + break; + } + + DPRINTK(3, "TX COMPLETED: entry = %p [tail = %d], vc_map = %p, skb = %p\n", + entry, txq->tail, entry->vc_map, entry->skb); + + /* free copy of misaligned data */ + if (entry->data) + kfree(entry->data); + + /* remove DMA mapping */ + fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, + FORE200E_DMA_TODEVICE); - for (i = 0; i < QUEUE_SIZE_TX; i++) { + vc_map = entry->vc_map; - if (*entry->status & STATUS_COMPLETE) { + /* vcc closed since the time the entry was submitted for tx? */ + if ((vc_map->vcc == NULL) || + (test_bit(ATM_VF_READY, &vc_map->vcc->flags) == 0)) { - DPRINTK(3, "TX COMPLETED: entry = %p, vcc = %p, skb = %p\n", entry, entry->vcc, entry->skb); + DPRINTK(1, "no ready vcc found for PDU sent on device %d\n", + fore200e->atm_dev->number); - /* free copy of misaligned data */ - if (entry->data) - kfree(entry->data); + dev_kfree_skb_any(entry->skb); + } + else { + ASSERT(vc_map->vcc); - /* remove DMA mapping */ - fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, - FORE200E_DMA_TODEVICE); + /* vcc closed then immediately re-opened? */ + if (vc_map->incarn != entry->incarn) { - /* notify tx completion */ - if (entry->vcc->pop) - entry->vcc->pop(entry->vcc, entry->skb); - else - dev_kfree_skb_irq(entry->skb); + /* when a vcc is closed, some PDUs may be still pending in the tx queue. + if the same vcc is immediately re-opened, those pending PDUs must + not be popped after the completion of their emission, as they refer + to the prior incarnation of that vcc. otherwise, vcc->sk->sk_wmem_alloc + would be decremented by the size of the (unrelated) skb, possibly + leading to a negative sk->sk_wmem_alloc count, ultimately freezing the vcc. + we thus bind the tx entry to the current incarnation of the vcc + when the entry is submitted for tx. When the tx later completes, + if the incarnation number of the tx entry does not match the one + of the vcc, then this implies that the vcc has been closed then re-opened. + we thus just drop the skb here. */ - /* check error condition */ - if (*entry->status & STATUS_ERROR) - atomic_inc(&entry->vcc->stats->tx_err); - else - atomic_inc(&entry->vcc->stats->tx); + DPRINTK(1, "vcc closed-then-re-opened; dropping PDU sent on device %d\n", + fore200e->atm_dev->number); - *entry->status = STATUS_FREE; - - fore200e->host_txq.txing--; + dev_kfree_skb_any(entry->skb); + } + else { + vcc = vc_map->vcc; + ASSERT(vcc); + + /* notify tx completion */ + if (vcc->pop) { + vcc->pop(vcc, entry->skb); + } + else { + dev_kfree_skb_any(entry->skb); + } +#if 1 + /* race fixed by the above incarnation mechanism, but... */ + if (atomic_read(&vcc->sk->sk_wmem_alloc) < 0) { + atomic_set(&vcc->sk->sk_wmem_alloc, 0); + } +#endif + /* check error condition */ + if (*entry->status & STATUS_ERROR) + atomic_inc(&vcc->stats->tx_err); + else + atomic_inc(&vcc->stats->tx); + } + } + + *entry->status = STATUS_FREE; + + fore200e->host_txq.txing--; + + FORE200E_NEXT_ENTRY(txq->tail, QUEUE_SIZE_TX); + } +} + + +#ifdef FORE200E_BSQ_DEBUG +int bsq_audit(int where, struct host_bsq* bsq, int scheme, int magn) +{ + struct buffer* buffer; + int count = 0; + + buffer = bsq->freebuf; + while (buffer) { + + if (buffer->supplied) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld supplied but in free list!\n", + where, scheme, magn, buffer->index); } - entry++; + + if (buffer->magn != magn) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld, unexpected magn = %d\n", + where, scheme, magn, buffer->index, buffer->magn); + } + + if (buffer->scheme != scheme) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, buffer %ld, unexpected scheme = %d\n", + where, scheme, magn, buffer->index, buffer->scheme); + } + + if ((buffer->index < 0) || (buffer->index >= fore200e_rx_buf_nbr[ scheme ][ magn ])) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, out of range buffer index = %ld !\n", + where, scheme, magn, buffer->index); + } + + count++; + buffer = buffer->next; + } + + if (count != bsq->freebuf_count) { + printk(FORE200E "bsq_audit(%d): queue %d.%d, %d bufs in free list, but freebuf_count = %d\n", + where, scheme, magn, count, bsq->freebuf_count); } + return 0; } +#endif static void @@ -1050,28 +1129,42 @@ bsq = &fore200e->host_bsq[ scheme ][ magn ]; - if (fore200e_rx_buf_nbr[ scheme ][ magn ] - bsq->count > RBD_BLK_SIZE) { +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(1, bsq, scheme, magn); +#endif + while (bsq->freebuf_count >= RBD_BLK_SIZE) { - DPRINTK(2, "supplying rx buffers to queue %d / %d, count = %d\n", - scheme, magn, bsq->count); + DPRINTK(2, "supplying %d rx buffers to queue %d / %d, freebuf_count = %d\n", + RBD_BLK_SIZE, scheme, magn, bsq->freebuf_count); entry = &bsq->host_entry[ bsq->head ]; - - FORE200E_NEXT_ENTRY(bsq->head, QUEUE_SIZE_BS); for (i = 0; i < RBD_BLK_SIZE; i++) { - buffer = &bsq->buffer[ bsq->free ]; - - FORE200E_NEXT_ENTRY(bsq->free, fore200e_rx_buf_nbr[ scheme ][ magn ]); + /* take the first buffer in the free buffer list */ + buffer = bsq->freebuf; + if (!buffer) { + printk(FORE200E "no more free bufs in queue %d.%d, but freebuf_count = %d\n", + scheme, magn, bsq->freebuf_count); + return; + } + bsq->freebuf = buffer->next; +#ifdef FORE200E_BSQ_DEBUG + if (buffer->supplied) + printk(FORE200E "queue %d.%d, buffer %lu already supplied\n", + scheme, magn, buffer->index); + buffer->supplied = 1; +#endif entry->rbd_block->rbd[ i ].buffer_haddr = buffer->data.dma_addr; entry->rbd_block->rbd[ i ].handle = FORE200E_BUF2HDL(buffer); } - /* increase the number of supplied rx buffers */ - bsq->count += RBD_BLK_SIZE; - + FORE200E_NEXT_ENTRY(bsq->head, QUEUE_SIZE_BS); + + /* decrease accordingly the number of free rx buffers */ + bsq->freebuf_count -= RBD_BLK_SIZE; + *entry->status = STATUS_PENDING; fore200e->bus->write(entry->rbd_block_dma, &entry->cp_entry->rbd_block_haddr); } @@ -1080,35 +1173,9 @@ } - -static struct atm_vcc* -fore200e_find_vcc(struct fore200e* fore200e, struct rpd* rpd) -{ - struct sock *s; - struct atm_vcc* vcc; - struct hlist_node *node; - - read_lock(&vcc_sklist_lock); - - sk_for_each(s, node, &vcc_hash[rpd->atm_header.vci & (VCC_HTABLE_SIZE-1)]) { - vcc = atm_sk(s); - if (vcc->dev != fore200e->atm_dev) - continue; - if (vcc->vpi == rpd->atm_header.vpi && vcc->vci == rpd->atm_header.vci) { - read_unlock(&vcc_sklist_lock); - return vcc; - } - } - read_unlock(&vcc_sklist_lock); - - return NULL; -} - - -static void -fore200e_push_rpd(struct fore200e* fore200e, struct rpd* rpd) +static int +fore200e_push_rpd(struct fore200e* fore200e, struct atm_vcc* vcc, struct rpd* rpd) { - struct atm_vcc* vcc; struct sk_buff* skb; struct buffer* buffer; struct fore200e_vcc* fore200e_vcc; @@ -1117,15 +1184,10 @@ u32 cell_header = 0; #endif - vcc = fore200e_find_vcc(fore200e, rpd); - if (vcc == NULL) { - - printk(FORE200E "no vcc found for PDU received on %d.%d.%d\n", - fore200e->atm_dev->number, rpd->atm_header.vpi, rpd->atm_header.vci); - return; - } - + ASSERT(vcc); + fore200e_vcc = FORE200E_VCC(vcc); + ASSERT(fore200e_vcc); #ifdef FORE200E_52BYTE_AAL0_SDU if ((vcc->qos.aal == ATM_AAL0) && (vcc->qos.rxtp.max_sdu == ATM_AAL0_SDU)) { @@ -1145,10 +1207,10 @@ skb = alloc_skb(pdu_len, GFP_ATOMIC); if (skb == NULL) { - - printk(FORE200E "unable to alloc new skb, rx PDU length = %d\n", pdu_len); + DPRINTK(2, "unable to alloc new skb, rx PDU length = %d\n", pdu_len); + atomic_inc(&vcc->stats->rx_drop); - return; + return -ENOMEM; } do_gettimeofday(&skb->stamp); @@ -1173,13 +1235,14 @@ /* Now let the device get at it again. */ fore200e->bus->dma_sync_for_device(fore200e, buffer->data.dma_addr, rpd->rsd[ i ].length, FORE200E_DMA_FROMDEVICE); } - + DPRINTK(3, "rx skb: len = %d, truesize = %d\n", skb->len, skb->truesize); if (pdu_len < fore200e_vcc->rx_min_pdu) fore200e_vcc->rx_min_pdu = pdu_len; if (pdu_len > fore200e_vcc->rx_max_pdu) fore200e_vcc->rx_max_pdu = pdu_len; + fore200e_vcc->rx_pdu++; /* push PDU */ if (atm_charge(vcc, skb->truesize) == 0) { @@ -1187,37 +1250,63 @@ DPRINTK(2, "receive buffers saturated for %d.%d.%d - PDU dropped\n", vcc->itf, vcc->vpi, vcc->vci); - dev_kfree_skb_irq(skb); - return; + dev_kfree_skb_any(skb); + + atomic_inc(&vcc->stats->rx_drop); + return -ENOMEM; } + ASSERT(atomic_read(&vcc->sk->sk_wmem_alloc) >= 0); + vcc->push(vcc, skb); atomic_inc(&vcc->stats->rx); + + ASSERT(atomic_read(&vcc->sk->sk_wmem_alloc) >= 0); + + return 0; } static void fore200e_collect_rpd(struct fore200e* fore200e, struct rpd* rpd) { - struct buffer* buffer; - int i; + struct host_bsq* bsq; + struct buffer* buffer; + int i; for (i = 0; i < rpd->nseg; i++) { /* rebuild rx buffer address from rsd handle */ buffer = FORE200E_HDL2BUF(rpd->rsd[ i ].handle); - /* decrease the number of supplied rx buffers */ - fore200e->host_bsq[ buffer->scheme ][ buffer->magn ].count--; + bsq = &fore200e->host_bsq[ buffer->scheme ][ buffer->magn ]; + +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(2, bsq, buffer->scheme, buffer->magn); + + if (buffer->supplied == 0) + printk(FORE200E "queue %d.%d, buffer %ld was not supplied\n", + buffer->scheme, buffer->magn, buffer->index); + buffer->supplied = 0; +#endif + + /* re-insert the buffer into the free buffer list */ + buffer->next = bsq->freebuf; + bsq->freebuf = buffer; + + /* then increment the number of free rx buffers */ + bsq->freebuf_count++; } } static void -fore200e_irq_rx(struct fore200e* fore200e) +fore200e_rx_irq(struct fore200e* fore200e) { - struct host_rxq* rxq = &fore200e->host_rxq; - struct host_rxq_entry* entry; + struct host_rxq* rxq = &fore200e->host_rxq; + struct host_rxq_entry* entry; + struct atm_vcc* vcc; + struct fore200e_vc_map* vc_map; for (;;) { @@ -1227,28 +1316,59 @@ if ((*entry->status & STATUS_COMPLETE) == 0) break; - FORE200E_NEXT_ENTRY(rxq->head, QUEUE_SIZE_RX); + vc_map = FORE200E_VC_MAP(fore200e, entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); - if ((*entry->status & STATUS_ERROR) == 0) { + if ((vc_map->vcc == NULL) || + (test_bit(ATM_VF_READY, &vc_map->vcc->flags) == 0)) { - fore200e_push_rpd(fore200e, entry->rpd); + DPRINTK(1, "no ready VC found for PDU received on %d.%d.%d\n", + fore200e->atm_dev->number, + entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); } else { - printk(FORE200E "damaged PDU on %d.%d.%d\n", - fore200e->atm_dev->number, entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); + vcc = vc_map->vcc; + ASSERT(vcc); + + if ((*entry->status & STATUS_ERROR) == 0) { + + fore200e_push_rpd(fore200e, vcc, entry->rpd); + } + else { + DPRINTK(2, "damaged PDU on %d.%d.%d\n", + fore200e->atm_dev->number, + entry->rpd->atm_header.vpi, entry->rpd->atm_header.vci); + atomic_inc(&vcc->stats->rx_err); + } } - fore200e_collect_rpd(fore200e, entry->rpd); + FORE200E_NEXT_ENTRY(rxq->head, QUEUE_SIZE_RX); - fore200e_supply(fore200e); + fore200e_collect_rpd(fore200e, entry->rpd); /* rewrite the rpd address to ack the received PDU */ fore200e->bus->write(entry->rpd_dma, &entry->cp_entry->rpd_haddr); *entry->status = STATUS_FREE; + + fore200e_supply(fore200e); } } +static void +fore200e_irq(struct fore200e* fore200e) +{ + unsigned long flags; + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_rx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_tx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); +} + + static irqreturn_t fore200e_interrupt(int irq, void* dev, struct pt_regs* regs) { @@ -1256,58 +1376,66 @@ if (fore200e->bus->irq_check(fore200e) == 0) { - DPRINTK(3, "unexpected interrupt on device %c\n", fore200e->name[9]); + DPRINTK(3, "interrupt NOT triggered by device %d\n", fore200e->atm_dev->number); return IRQ_NONE; } - DPRINTK(3, "valid interrupt on device %c\n", fore200e->name[9]); + DPRINTK(3, "interrupt triggered by device %d\n", fore200e->atm_dev->number); - tasklet_schedule(&fore200e->tasklet); +#ifdef FORE200E_USE_TASKLET + tasklet_schedule(&fore200e->tx_tasklet); + tasklet_schedule(&fore200e->rx_tasklet); +#else + fore200e_irq(fore200e); +#endif fore200e->bus->irq_ack(fore200e); return IRQ_HANDLED; } +#ifdef FORE200E_USE_TASKLET static void -fore200e_tasklet(unsigned long data) +fore200e_tx_tasklet(unsigned long data) { struct fore200e* fore200e = (struct fore200e*) data; + unsigned long flags; - fore200e_irq_rx(fore200e); - - if (fore200e->host_txq.txing) - fore200e_irq_tx(fore200e); + DPRINTK(3, "tx tasklet scheduled for device %d\n", fore200e->atm_dev->number); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_tx_irq(fore200e); + spin_unlock_irqrestore(&fore200e->q_lock, flags); } +static void +fore200e_rx_tasklet(unsigned long data) +{ + struct fore200e* fore200e = (struct fore200e*) data; + unsigned long flags; + + DPRINTK(3, "rx tasklet scheduled for device %d\n", fore200e->atm_dev->number); + + spin_lock_irqsave(&fore200e->q_lock, flags); + fore200e_rx_irq((struct fore200e*) data); + spin_unlock_irqrestore(&fore200e->q_lock, flags); +} +#endif + static int fore200e_select_scheme(struct atm_vcc* vcc) { - int scheme; + /* fairly balance the VCs over (identical) buffer schemes */ + int scheme = vcc->vci % 2 ? BUFFER_SCHEME_ONE : BUFFER_SCHEME_TWO; -#if 1 - /* fairly balance VCs over (identical) buffer schemes */ - scheme = vcc->vci % 2 ? BUFFER_SCHEME_ONE : BUFFER_SCHEME_TWO; -#else - /* bit 7 of VPI magically selects the second buffer scheme */ - if (vcc->vpi & (1<<7)) { - vcc->vpi &= ((1<<7) - 1); /* reset the magic bit */ - scheme = BUFFER_SCHEME_TWO; - } - else { - scheme = BUFFER_SCHEME_ONE; - } -#endif - - DPRINTK(1, "vpvc %d.%d.%d uses the %s buffer scheme\n", - vcc->itf, vcc->vpi, vcc->vci, scheme == BUFFER_SCHEME_ONE ? "first" : "second"); + DPRINTK(1, "VC %d.%d.%d uses buffer scheme %d\n", + vcc->itf, vcc->vpi, vcc->vci, scheme); return scheme; } - static int fore200e_activate_vcin(struct fore200e* fore200e, int activate, struct atm_vcc* vcc, int mtu) { @@ -1344,7 +1472,7 @@ #ifdef FORE200E_52BYTE_AAL0_SDU mtu = 48; #endif - /* the MTU is unused by the cp, except in the case of AAL0 */ + /* the MTU is not used by the cp, except in the case of AAL0 */ fore200e->bus->write(mtu, &entry->cp_entry->cmd.activate_block.mtu); fore200e->bus->write(*(u32*)&vpvc, (u32*)&entry->cp_entry->cmd.activate_block.vpvc); fore200e->bus->write(*(u32*)&activ_opcode, (u32*)&entry->cp_entry->cmd.activate_block.opcode); @@ -1359,13 +1487,13 @@ *entry->status = STATUS_FREE; if (ok == 0) { - printk(FORE200E "unable to %s vpvc %d.%d on device %s\n", - activate ? "open" : "close", vcc->vpi, vcc->vci, fore200e->name); + printk(FORE200E "unable to %s VC %d.%d.%d\n", + activate ? "open" : "close", vcc->itf, vcc->vpi, vcc->vci); return -EIO; } - DPRINTK(1, "vpvc %d.%d %sed on device %s\n", vcc->vpi, vcc->vci, - activate ? "open" : "clos", fore200e->name); + DPRINTK(1, "VC %d.%d.%d %sed\n", vcc->itf, vcc->vpi, vcc->vci, + activate ? "open" : "clos"); return 0; } @@ -1378,7 +1506,7 @@ { if (qos->txtp.max_pcr < ATM_OC3_PCR) { - /* compute the data cells to idle cells ratio from the PCR */ + /* compute the data cells to idle cells ratio from the tx PCR */ rate->data_cells = qos->txtp.max_pcr * FORE200E_MAX_BACK2BACK_CELLS / ATM_OC3_PCR; rate->idle_cells = FORE200E_MAX_BACK2BACK_CELLS - rate->data_cells; } @@ -1392,17 +1520,38 @@ static int fore200e_open(struct atm_vcc *vcc) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - struct fore200e_vcc* fore200e_vcc; - short vpi = vcc->vpi; - int vci = vcc->vci; - - /* ressource checking only? */ - if (vci == ATM_VCI_UNSPEC || vpi == ATM_VPI_UNSPEC) - return 0; + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc; + struct fore200e_vc_map* vc_map; + unsigned long flags; + int vci = vcc->vci; + short vpi = vcc->vpi; - set_bit(ATM_VF_ADDR, &vcc->flags); - vcc->itf = vcc->dev->number; + ASSERT((vpi >= 0) && (vpi < 1<= 0) && (vci < 1<q_lock, flags); + + vc_map = FORE200E_VC_MAP(fore200e, vpi, vci); + if (vc_map->vcc) { + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + printk(FORE200E "VC %d.%d.%d already in use\n", + fore200e->atm_dev->number, vpi, vci); + + return -EINVAL; + } + + vc_map->vcc = vcc; + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + fore200e_vcc = fore200e_kmalloc(sizeof(struct fore200e_vcc), GFP_ATOMIC); + if (fore200e_vcc == NULL) { + vc_map->vcc = NULL; + return -ENOMEM; + } DPRINTK(2, "opening %d.%d.%d:%d QoS = (tx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d; " "rx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d)\n", @@ -1412,44 +1561,50 @@ fore200e_traffic_class[ vcc->qos.rxtp.traffic_class ], vcc->qos.rxtp.min_pcr, vcc->qos.rxtp.max_pcr, vcc->qos.rxtp.max_cdv, vcc->qos.rxtp.max_sdu); + /* pseudo-CBR bandwidth requested? */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { down(&fore200e->rate_sf); if (fore200e->available_cell_rate < vcc->qos.txtp.max_pcr) { up(&fore200e->rate_sf); + + fore200e_kfree(fore200e_vcc); + vc_map->vcc = NULL; return -EAGAIN; } - /* reserving the pseudo-CBR bandwidth at this point grants us - to reduce the length of the critical section protected - by 'rate_sf'. in counterpart, we have to reset the available - bandwidth if we later encounter an error */ + /* reserve bandwidth */ fore200e->available_cell_rate -= vcc->qos.txtp.max_pcr; up(&fore200e->rate_sf); } - fore200e_vcc = fore200e_kmalloc(sizeof(struct fore200e_vcc), GFP_KERNEL); - if (fore200e_vcc == NULL) { - down(&fore200e->rate_sf); - fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; - up(&fore200e->rate_sf); - return -ENOMEM; - } + vcc->itf = vcc->dev->number; + + set_bit(ATM_VF_PARTIAL,&vcc->flags); + set_bit(ATM_VF_ADDR, &vcc->flags); vcc->dev_data = fore200e_vcc; if (fore200e_activate_vcin(fore200e, 1, vcc, vcc->qos.rxtp.max_sdu) < 0) { - kfree(fore200e_vcc); - down(&fore200e->rate_sf); + + vc_map->vcc = NULL; + + clear_bit(ATM_VF_ADDR, &vcc->flags); + clear_bit(ATM_VF_PARTIAL,&vcc->flags); + + vcc->dev_data = NULL; + fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; - up(&fore200e->rate_sf); - return -EBUSY; + + fore200e_kfree(fore200e_vcc); + return -EINVAL; } /* compute rate control parameters */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { fore200e_rate_ctrl(&vcc->qos, &fore200e_vcc->rate); + set_bit(ATM_VF_HASQOS, &vcc->flags); DPRINTK(3, "tx on %d.%d.%d:%d, tx PCR = %d, rx PCR = %d, data_cells = %u, idle_cells = %u\n", vcc->itf, vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal), @@ -1457,57 +1612,99 @@ fore200e_vcc->rate.data_cells, fore200e_vcc->rate.idle_cells); } - fore200e_vcc->tx_min_pdu = fore200e_vcc->rx_min_pdu = 65536; + fore200e_vcc->tx_min_pdu = fore200e_vcc->rx_min_pdu = MAX_PDU_SIZE + 1; fore200e_vcc->tx_max_pdu = fore200e_vcc->rx_max_pdu = 0; - + fore200e_vcc->tx_pdu = fore200e_vcc->rx_pdu = 0; + + /* new incarnation of the vcc */ + vc_map->incarn = ++fore200e->incarn_count; + + /* VC unusable before this flag is set */ set_bit(ATM_VF_READY, &vcc->flags); + return 0; } - static void fore200e_close(struct atm_vcc* vcc) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc; + struct fore200e_vc_map* vc_map; + unsigned long flags; + + ASSERT(vcc); + ASSERT((vcc->vpi >= 0) && (vcc->vpi < 1<vci >= 0) && (vcc->vci < 1<itf, vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal)); - + + clear_bit(ATM_VF_READY, &vcc->flags); + fore200e_activate_vcin(fore200e, 0, vcc, 0); - - kfree(FORE200E_VCC(vcc)); - + + spin_lock_irqsave(&fore200e->q_lock, flags); + + vc_map = FORE200E_VC_MAP(fore200e, vcc->vpi, vcc->vci); + + /* the vc is no longer considered as "in use" by fore200e_open() */ + vc_map->vcc = NULL; + + vcc->itf = vcc->vci = vcc->vpi = 0; + + fore200e_vcc = FORE200E_VCC(vcc); + FORE200E_VCC(vcc) = NULL; + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + /* release reserved bandwidth, if any */ if ((vcc->qos.txtp.traffic_class == ATM_CBR) && (vcc->qos.txtp.max_pcr > 0)) { + down(&fore200e->rate_sf); fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; up(&fore200e->rate_sf); - } - clear_bit(ATM_VF_READY, &vcc->flags); -} + clear_bit(ATM_VF_HASQOS, &vcc->flags); + } + clear_bit(ATM_VF_ADDR, &vcc->flags); + clear_bit(ATM_VF_PARTIAL,&vcc->flags); -#if 0 -#define FORE200E_SYNC_SEND /* wait tx completion before returning */ -#endif + ASSERT(fore200e_vcc); + fore200e_kfree(fore200e_vcc); +} static int fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb) { - struct fore200e* fore200e = FORE200E_DEV(vcc->dev); - struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); - struct host_txq* txq = &fore200e->host_txq; - struct host_txq_entry* entry; - struct tpd* tpd; - struct tpd_haddr tpd_haddr; - //unsigned long flags; - int retry = CONFIG_ATM_FORE200E_TX_RETRY; - int tx_copy = 0; - int tx_len = skb->len; - u32* cell_header = NULL; - unsigned char* skb_data; - int skb_len; + struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); + struct fore200e_vc_map* vc_map; + struct host_txq* txq = &fore200e->host_txq; + struct host_txq_entry* entry; + struct tpd* tpd; + struct tpd_haddr tpd_haddr; + int retry = CONFIG_ATM_FORE200E_TX_RETRY; + int tx_copy = 0; + int tx_len = skb->len; + u32* cell_header = NULL; + unsigned char* skb_data; + int skb_len; + unsigned char* data; + unsigned long flags; + + ASSERT(vcc); + ASSERT(atomic_read(&vcc->sk->sk_wmem_alloc) >= 0); + ASSERT(fore200e); + ASSERT(fore200e_vcc); + + if (!test_bit(ATM_VF_READY, &vcc->flags)) { + DPRINTK(1, "VC %d.%d.%d not ready for tx\n", vcc->itf, vcc->vpi, vcc->vpi); + dev_kfree_skb_any(skb); + return -EINVAL; + } #ifdef FORE200E_52BYTE_AAL0_SDU if ((vcc->qos.aal == ATM_AAL0) && (vcc->qos.txtp.max_sdu == ATM_AAL0_SDU)) { @@ -1515,7 +1712,7 @@ skb_data = skb->data + 4; /* skip 4-byte cell header */ skb_len = tx_len = skb->len - 4; - DPRINTK(3, "skipping user-supplied cell header 0x%08x", *cell_header); + DPRINTK(3, "user-supplied cell header = 0x%08x\n", *cell_header); } else #endif @@ -1524,39 +1721,6 @@ skb_len = skb->len; } - retry_here: - - tasklet_disable(&fore200e->tasklet); - - entry = &txq->host_entry[ txq->head ]; - - if (*entry->status != STATUS_FREE) { - - /* try to free completed tx queue entries */ - fore200e_irq_tx(fore200e); - - if (*entry->status != STATUS_FREE) { - - tasklet_enable(&fore200e->tasklet); - - /* retry once again? */ - if(--retry > 0) - goto retry_here; - - atomic_inc(&vcc->stats->tx_err); - - printk(FORE200E "tx queue of device %s is saturated, PDU dropped - heartbeat is %08x\n", - fore200e->name, fore200e->cp_queues->heartbeat); - if (vcc->pop) - vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); - return -EIO; - } - } - - tpd = entry->tpd; - if (((unsigned long)skb_data) & 0x3) { DPRINTK(2, "misaligned tx PDU on device %s\n", fore200e->name); @@ -1566,43 +1730,87 @@ if ((vcc->qos.aal == ATM_AAL0) && (skb_len % ATM_CELL_PAYLOAD)) { - /* this simply NUKES the PCA-200E board */ + /* this simply NUKES the PCA board */ DPRINTK(2, "incomplete tx AAL0 PDU on device %s\n", fore200e->name); tx_copy = 1; tx_len = ((skb_len / ATM_CELL_PAYLOAD) + 1) * ATM_CELL_PAYLOAD; } if (tx_copy) { - - entry->data = kmalloc(tx_len, GFP_ATOMIC | GFP_DMA); - if (entry->data == NULL) { - - tasklet_enable(&fore200e->tasklet); - if (vcc->pop) + data = kmalloc(tx_len, GFP_ATOMIC | GFP_DMA); + if (data == NULL) { + if (vcc->pop) { vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); + } + else { + dev_kfree_skb_any(skb); + } return -ENOMEM; } - memcpy(entry->data, skb_data, skb_len); + memcpy(data, skb_data, skb_len); if (skb_len < tx_len) - memset(entry->data + skb_len, 0x00, tx_len - skb_len); - - tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, entry->data, tx_len, FORE200E_DMA_TODEVICE); + memset(data + skb_len, 0x00, tx_len - skb_len); } else { - entry->data = NULL; - tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, skb_data, tx_len, FORE200E_DMA_TODEVICE); + data = skb_data; } + vc_map = FORE200E_VC_MAP(fore200e, vcc->vpi, vcc->vci); + ASSERT(vc_map->vcc == vcc); + + retry_here: + + spin_lock_irqsave(&fore200e->q_lock, flags); + + entry = &txq->host_entry[ txq->head ]; + + if ((*entry->status != STATUS_FREE) || (txq->txing >= QUEUE_SIZE_TX - 2)) { + + /* try to free completed tx queue entries */ + fore200e_tx_irq(fore200e); + + if (*entry->status != STATUS_FREE) { + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + + /* retry once again? */ + if (--retry > 0) { + schedule(); + goto retry_here; + } + + atomic_inc(&vcc->stats->tx_err); + + fore200e->tx_sat++; + DPRINTK(2, "tx queue of device %s is saturated, PDU dropped - heartbeat is %08x\n", + fore200e->name, fore200e->cp_queues->heartbeat); + if (vcc->pop) { + vcc->pop(vcc, skb); + } + else { + dev_kfree_skb_any(skb); + } + + if (tx_copy) + kfree(data); + + return -ENOBUFS; + } + } + + entry->incarn = vc_map->incarn; + entry->vc_map = vc_map; + entry->skb = skb; + entry->data = tx_copy ? data : NULL; + + tpd = entry->tpd; + tpd->tsd[ 0 ].buffer = fore200e->bus->dma_map(fore200e, data, tx_len, FORE200E_DMA_TODEVICE); tpd->tsd[ 0 ].length = tx_len; FORE200E_NEXT_ENTRY(txq->head, QUEUE_SIZE_TX); txq->txing++; - tasklet_enable(&fore200e->tasklet); - /* The dma_map call above implies a dma_sync so the device can use it, * thus no explicit dma_sync call is necessary here. */ @@ -1615,9 +1823,7 @@ fore200e_vcc->tx_min_pdu = skb_len; if (skb_len > fore200e_vcc->tx_max_pdu) fore200e_vcc->tx_max_pdu = skb_len; - - entry->vcc = vcc; - entry->skb = skb; + fore200e_vcc->tx_pdu++; /* set tx rate control information */ tpd->rate.data_cells = fore200e_vcc->rate.data_cells; @@ -1642,49 +1848,16 @@ tpd->spec.length = tx_len; tpd->spec.nseg = 1; tpd->spec.aal = fore200e_atm2fore_aal(vcc->qos.aal); -#ifdef FORE200E_SYNC_SEND - tpd->spec.intr = 0; -#else tpd->spec.intr = 1; -#endif - tpd_haddr.size = sizeof(struct tpd) / 32; /* size is expressed in 32 byte blocks */ + tpd_haddr.size = sizeof(struct tpd) / (1<tpd_dma >> 5; /* shift the address, as we are in a bitfield */ + tpd_haddr.haddr = entry->tpd_dma >> TPD_HADDR_SHIFT; /* shift the address, as we are in a bitfield */ *entry->status = STATUS_PENDING; fore200e->bus->write(*(u32*)&tpd_haddr, (u32*)&entry->cp_entry->tpd_haddr); - -#ifdef FORE200E_SYNC_SEND - { - int ok = fore200e_poll(fore200e, entry->status, STATUS_COMPLETE, 10); - - fore200e->bus->dma_unmap(fore200e, entry->tpd->tsd[ 0 ].buffer, entry->tpd->tsd[ 0 ].length, - FORE200E_DMA_TODEVICE); - - /* free tmp copy of misaligned data */ - if (entry->data) - kfree(entry->data); - - /* notify tx completion */ - if (vcc->pop) - vcc->pop(vcc, skb); - else - dev_kfree_skb(skb); - - if (ok == 0) { - printk(FORE200E "synchronous tx on %d:%d:%d failed\n", vcc->itf, vcc->vpi, vcc->vci); - - atomic_inc(&entry->vcc->stats->tx_err); - return -EIO; - } - atomic_inc(&entry->vcc->stats->tx); - - DPRINTK(3, "synchronous tx on %d:%d:%d succeeded\n", vcc->itf, vcc->vpi, vcc->vci); - - } -#endif + spin_unlock_irqrestore(&fore200e->q_lock, flags); return 0; } @@ -1705,7 +1878,8 @@ return -ENOMEM; } - stats_dma_addr = fore200e->bus->dma_map(fore200e, fore200e->stats, sizeof(struct stats), FORE200E_DMA_FROMDEVICE); + stats_dma_addr = fore200e->bus->dma_map(fore200e, fore200e->stats, + sizeof(struct stats), FORE200E_DMA_FROMDEVICE); FORE200E_NEXT_ENTRY(cmdq->head, QUEUE_SIZE_CMD); @@ -1734,9 +1908,9 @@ static int -fore200e_getsockopt (struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) +fore200e_getsockopt(struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) { - // struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + /* struct fore200e* fore200e = FORE200E_DEV(vcc->dev); */ DPRINTK(2, "getsockopt %d.%d.%d, level = %d, optname = 0x%x, optval = 0x%p, optlen = %d\n", vcc->itf, vcc->vpi, vcc->vci, level, optname, optval, optlen); @@ -1748,7 +1922,7 @@ static int fore200e_setsockopt(struct atm_vcc* vcc, int level, int optname, void* optval, int optlen) { - // struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + /* struct fore200e* fore200e = FORE200E_DEV(vcc->dev); */ DPRINTK(2, "setsockopt %d.%d.%d, level = %d, optname = 0x%x, optval = 0x%p, optlen = %d\n", vcc->itf, vcc->vpi, vcc->vci, level, optname, optval, optlen); @@ -1806,6 +1980,8 @@ struct oc3_opcode opcode; int ok; + DPRINTK(2, "set OC-3 reg = 0x%02x, value = 0x%02x, mask = 0x%02x\n", reg, value, mask); + FORE200E_NEXT_ENTRY(cmdq->head, QUEUE_SIZE_CMD); opcode.opcode = OPCODE_SET_OC3; @@ -1861,7 +2037,7 @@ } error = fore200e_set_oc3(fore200e, SUNI_MCT, mct_value, mct_mask); - if ( error == 0) + if (error == 0) fore200e->loop_mode = loop_mode; return error; @@ -1943,6 +2119,11 @@ struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc); struct fore200e* fore200e = FORE200E_DEV(vcc->dev); + if (!test_bit(ATM_VF_READY, &vcc->flags)) { + DPRINTK(1, "VC %d.%d.%d not ready for QoS change\n", vcc->itf, vcc->vpi, vcc->vpi); + return -EINVAL; + } + DPRINTK(2, "change_qos %d.%d.%d, " "(tx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d; " "rx: cl=%s, pcr=%d-%d, cdv=%d, max_sdu=%d), flags = 0x%x\n" @@ -1964,6 +2145,7 @@ fore200e->available_cell_rate += vcc->qos.txtp.max_pcr; fore200e->available_cell_rate -= qos->txtp.max_pcr; + up(&fore200e->rate_sf); memcpy(&vcc->qos, qos, sizeof(struct atm_qos)); @@ -1972,6 +2154,7 @@ fore200e_rate_ctrl(qos, &fore200e_vcc->rate); set_bit(ATM_VF_HASQOS, &vcc->flags); + return 0; } @@ -1992,7 +2175,10 @@ printk(FORE200E "IRQ %s reserved for device %s\n", fore200e_irq_itoa(fore200e->irq), fore200e->name); - tasklet_init(&fore200e->tasklet, fore200e_tasklet, (unsigned long)fore200e); +#ifdef FORE200E_USE_TASKLET + tasklet_init(&fore200e->tx_tasklet, fore200e_tx_tasklet, (unsigned long)fore200e); + tasklet_init(&fore200e->rx_tasklet, fore200e_rx_tasklet, (unsigned long)fore200e); +#endif fore200e->state = FORE200E_STATE_IRQ; return 0; @@ -2007,6 +2193,7 @@ if (!prom) return -ENOMEM; + ok = fore200e->bus->prom_read(fore200e, prom); if (ok < 0) { fore200e_kfree(prom); @@ -2054,10 +2241,16 @@ if (buffer == NULL) return -ENOMEM; + bsq->freebuf = NULL; + for (i = 0; i < nbr; i++) { buffer[ i ].scheme = scheme; buffer[ i ].magn = magn; +#ifdef FORE200E_BSQ_DEBUG + buffer[ i ].index = i; + buffer[ i ].supplied = 0; +#endif /* allocate the receive buffer body */ if (fore200e_chunk_alloc(fore200e, @@ -2070,9 +2263,17 @@ return -ENOMEM; } + + /* insert the buffer into the free buffer list */ + buffer[ i ].next = bsq->freebuf; + bsq->freebuf = &buffer[ i ]; } - /* set next free buffer index */ - bsq->free = 0; + /* all the buffers are free, initially */ + bsq->freebuf_count = nbr; + +#ifdef FORE200E_BSQ_DEBUG + bsq_audit(3, bsq, scheme, magn); +#endif } } @@ -2129,9 +2330,9 @@ FORE200E_INDEX(bsq->rbd_block.align_addr, struct rbd_block, i); bsq->host_entry[ i ].rbd_block_dma = FORE200E_DMA_INDEX(bsq->rbd_block.dma_addr, struct rbd_block, i); - bsq->host_entry[ i ].cp_entry = &cp_entry[ i ]; + bsq->host_entry[ i ].cp_entry = &cp_entry[ i ]; - *bsq->host_entry[ i ].status = STATUS_FREE; + *bsq->host_entry[ i ].status = STATUS_FREE; fore200e->bus->write(FORE200E_DMA_INDEX(bsq->status.dma_addr, enum status, i), &cp_entry[ i ].status_haddr); @@ -2258,10 +2459,11 @@ we do not write here the DMA (physical) base address of each tpd into the related cp resident entry, because the cp relies on this write operation to detect that a new pdu has been submitted for tx */ -} + } - /* set the head entry of the queue */ + /* set the head and tail entries of the queue */ txq->head = 0; + txq->tail = 0; fore200e->state = FORE200E_STATE_INIT_TXQ; return 0; @@ -2280,9 +2482,9 @@ /* allocate and align the array of status words */ if (fore200e->bus->dma_chunk_alloc(fore200e, &cmdq->status, - sizeof(enum status), - QUEUE_SIZE_CMD, - fore200e->bus->status_alignment) < 0) { + sizeof(enum status), + QUEUE_SIZE_CMD, + fore200e->bus->status_alignment) < 0) { return -ENOMEM; } @@ -2318,12 +2520,6 @@ { struct bs_spec* bs_spec = &fore200e->cp_queues->init.bs_spec[ scheme ][ magn ]; - /* dumb value; the firmware doesn't allow us to activate a VC while - selecting a buffer scheme with zero-sized rbd pools */ - - if (pool_size == 0) - pool_size = 64; - fore200e->bus->write(queue_length, &bs_spec->queue_length); fore200e->bus->write(fore200e_rx_buf_size[ scheme ][ magn ], &bs_spec->buffer_size); fore200e->bus->write(pool_size, &bs_spec->pool_size); @@ -2340,7 +2536,8 @@ DPRINTK(2, "device %s being initialized\n", fore200e->name); init_MUTEX(&fore200e->rate_sf); - + spin_lock_init(&fore200e->q_lock); + cpq = fore200e->cp_queues = (struct cp_queues*) (fore200e->virt_base + FORE200E_CP_QUEUES_OFFSET); /* enable cp to host interrupts */ @@ -2422,7 +2619,7 @@ static void __init fore200e_monitor_puts(struct fore200e* fore200e, char* str) { - while(*str) { + while (*str) { /* the i960 monitor doesn't accept any new character if it has something to say */ while (fore200e_monitor_getc(fore200e) >= 0); @@ -2443,6 +2640,11 @@ DPRINTK(2, "device %s firmware being started\n", fore200e->name); +#if defined(__sparc_v9__) + /* reported to be required by SBA cards on some sparc64 hosts */ + fore200e_spin(100); +#endif + sprintf(cmd, "\rgo %x\r", le32_to_cpu(fw_header->start_offset)); fore200e_monitor_puts(fore200e, cmd); @@ -2473,12 +2675,10 @@ DPRINTK(2, "device %s firmware being loaded at 0x%p (%d words)\n", fore200e->name, load_addr, fw_size); -#if 1 if (le32_to_cpu(fw_header->magic) != FW_HEADER_MAGIC) { printk(FORE200E "corrupted %s firmware image\n", fore200e->bus->model_name); return -ENODEV; } -#endif for (; fw_size--; fw_data++, load_addr++) fore200e->bus->write(le32_to_cpu(*fw_data), load_addr); @@ -2505,8 +2705,8 @@ atm_dev->dev_data = fore200e; fore200e->atm_dev = atm_dev; - atm_dev->ci_range.vpi_bits = 8; - atm_dev->ci_range.vci_bits = 10; + atm_dev->ci_range.vpi_bits = FORE200E_VPI_BITS; + atm_dev->ci_range.vci_bits = FORE200E_VCI_BITS; fore200e->available_cell_rate = ATM_OC3_PCR; @@ -2574,7 +2774,7 @@ struct fore200e* fore200e; int index, link; - printk(FORE200E "FORE Systems 200E-series driver - version " FORE200E_VERSION "\n"); + printk(FORE200E "FORE Systems 200E-series ATM driver - version " FORE200E_VERSION "\n"); /* for each configured bus interface */ for (link = 0, bus = fore200e_bus; bus->model_name; bus++) { @@ -2622,12 +2822,13 @@ static int -fore200e_proc_read(struct atm_dev *dev,loff_t* pos,char* page) +fore200e_proc_read(struct atm_dev *dev, loff_t* pos, char* page) { - struct sock *s; - struct hlist_node *node; - struct fore200e* fore200e = FORE200E_DEV(dev); - int i, len, left = *pos; + struct fore200e* fore200e = FORE200E_DEV(dev); + struct fore200e_vcc* fore200e_vcc; + struct atm_vcc* vcc; + int i, len, left = *pos; + unsigned long flags; if (!left--) { @@ -2660,14 +2861,15 @@ if (!left--) return sprintf(page, - " supplied small bufs (1):\t%d\n" - " supplied large bufs (1):\t%d\n" - " supplied small bufs (2):\t%d\n" - " supplied large bufs (2):\t%d\n", - fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_SMALL ].count, - fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_LARGE ].count, - fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_SMALL ].count, - fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_LARGE ].count); + " free small bufs, scheme 1:\t%d\n" + " free large bufs, scheme 1:\t%d\n" + " free small bufs, scheme 2:\t%d\n" + " free large bufs, scheme 2:\t%d\n", + fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_SMALL ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_ONE ][ BUFFER_MAGN_LARGE ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_SMALL ].freebuf_count, + fore200e->host_bsq[ BUFFER_SCHEME_TWO ][ BUFFER_MAGN_LARGE ].freebuf_count); + if (!left--) { u32 hb = fore200e->bus->read(&fore200e->cp_queues->heartbeat); @@ -2706,7 +2908,7 @@ u32 media_index = FORE200E_MEDIA_INDEX(fore200e->bus->read(&fore200e->cp_queues->media_type)); u32 oc3_index; - if (media_index < 0 || media_index > 4) + if ((media_index < 0) || (media_index > 4)) media_index = 5; switch (fore200e->loop_mode) { @@ -2853,12 +3055,14 @@ " large b1:\t\t\t%10u\n" " small b2:\t\t\t%10u\n" " large b2:\t\t\t%10u\n" - " RX PDUs:\t\t\t%10u\n", + " RX PDUs:\t\t\t%10u\n" + " TX PDUs:\t\t\t%10lu\n", fore200e_swap(fore200e->stats->aux.small_b1_failed), fore200e_swap(fore200e->stats->aux.large_b1_failed), fore200e_swap(fore200e->stats->aux.small_b2_failed), fore200e_swap(fore200e->stats->aux.large_b2_failed), - fore200e_swap(fore200e->stats->aux.rpd_alloc_failed)); + fore200e_swap(fore200e->stats->aux.rpd_alloc_failed), + fore200e->tx_sat); if (!left--) return sprintf(page,"\n" @@ -2866,38 +3070,41 @@ fore200e->stats->aux.receive_carrier ? "ON" : "OFF!"); if (!left--) { - struct atm_vcc *vcc; - struct fore200e_vcc* fore200e_vcc; - - len = sprintf(page,"\n" - " VCCs:\n address\tVPI.VCI:AAL\t(min/max tx PDU size) (min/max rx PDU size)\n"); - - read_lock(&vcc_sklist_lock); - for(i = 0; i < VCC_HTABLE_SIZE; ++i) { - struct hlist_head *head = &vcc_hash[i]; + return sprintf(page,"\n" + " VCCs:\n address VPI VCI AAL " + "TX PDUs TX min/max size RX PDUs RX min/max size\n"); + } - sk_for_each(s, node, head) { - vcc = atm_sk(s); + for (i = 0; i < NBR_CONNECT; i++) { - if (vcc->dev != fore200e->atm_dev) - continue; + vcc = fore200e->vc_map[i].vcc; - fore200e_vcc = FORE200E_VCC(vcc); - - len += sprintf(page + len, - " %x\t%d.%d:%d\t\t(%d/%d)\t(%d/%d)\n", - (u32)(unsigned long)vcc, - vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal), - fore200e_vcc->tx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->tx_min_pdu, - fore200e_vcc->tx_max_pdu, - fore200e_vcc->rx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->rx_min_pdu, - fore200e_vcc->rx_max_pdu - ); - } + if (vcc == NULL) + continue; + + spin_lock_irqsave(&fore200e->q_lock, flags); + + if (vcc && test_bit(ATM_VF_READY, &vcc->flags) && !left--) { + + fore200e_vcc = FORE200E_VCC(vcc); + ASSERT(fore200e_vcc); + + len = sprintf(page, + " %08x %03d %05d %1d %09lu %05d/%05d %09lu %05d/%05d\n", + (u32)(unsigned long)vcc, + vcc->vpi, vcc->vci, fore200e_atm2fore_aal(vcc->qos.aal), + fore200e_vcc->tx_pdu, + fore200e_vcc->tx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->tx_min_pdu, + fore200e_vcc->tx_max_pdu, + fore200e_vcc->rx_pdu, + fore200e_vcc->rx_min_pdu > 0xFFFF ? 0 : fore200e_vcc->rx_min_pdu, + fore200e_vcc->rx_max_pdu); + + spin_unlock_irqrestore(&fore200e->q_lock, flags); + return len; } - read_unlock(&vcc_sklist_lock); - return len; + spin_unlock_irqrestore(&fore200e->q_lock, flags); } return 0; @@ -2917,7 +3124,7 @@ .send = fore200e_send, .change_qos = fore200e_change_qos, .proc_read = fore200e_proc_read, - .owner = THIS_MODULE, + .owner = THIS_MODULE }; @@ -2980,4 +3187,6 @@ {} }; +#ifdef MODULE_LICENSE MODULE_LICENSE("GPL"); +#endif diff -Nru a/drivers/atm/fore200e.h b/drivers/atm/fore200e.h --- a/drivers/atm/fore200e.h Fri Apr 16 14:52:15 2004 +++ b/drivers/atm/fore200e.h Fri Apr 16 14:52:15 2004 @@ -23,19 +23,21 @@ #define BUFFER_S2_SIZE SMALL_BUFFER_SIZE /* size of small buffers, scheme 2 */ #define BUFFER_L2_SIZE LARGE_BUFFER_SIZE /* size of large buffers, scheme 2 */ -#define BUFFER_S1_NBR (RBD_BLK_SIZE * 2) -#define BUFFER_L1_NBR (RBD_BLK_SIZE * 2) +#define BUFFER_S1_NBR (RBD_BLK_SIZE * 6) +#define BUFFER_L1_NBR (RBD_BLK_SIZE * 4) -#define BUFFER_S2_NBR (RBD_BLK_SIZE * 2) -#define BUFFER_L2_NBR (RBD_BLK_SIZE * 2) +#define BUFFER_S2_NBR (RBD_BLK_SIZE * 6) +#define BUFFER_L2_NBR (RBD_BLK_SIZE * 4) #define QUEUE_SIZE_CMD 16 /* command queue capacity */ #define QUEUE_SIZE_RX 64 /* receive queue capacity */ #define QUEUE_SIZE_TX 256 /* transmit queue capacity */ -#define QUEUE_SIZE_BS 16 /* buffer supply queue capacity */ +#define QUEUE_SIZE_BS 32 /* buffer supply queue capacity */ -#define NBR_CONNECT 1024 /* number of ATM connections */ +#define FORE200E_VPI_BITS 0 +#define FORE200E_VCI_BITS 10 +#define NBR_CONNECT (1 << (FORE200E_VPI_BITS + FORE200E_VCI_BITS)) /* number of connections */ #define TSD_FIXED 2 @@ -207,6 +209,7 @@ ) } tpd_haddr_t; +#define TPD_HADDR_SHIFT 5 /* addr aligned on 32 byte boundary */ /* cp resident transmit queue entry */ @@ -517,13 +520,15 @@ /* host resident transmit queue entry */ typedef struct host_txq_entry { - struct cp_txq_entry* cp_entry; /* addr of cp resident tx queue entry */ - enum status* status; /* addr of host resident status */ - struct tpd* tpd; /* addr of transmit PDU descriptor */ - u32 tpd_dma; /* DMA address of tpd */ - struct sk_buff* skb; /* related skb */ - struct atm_vcc* vcc; /* related vcc */ - void* data; /* copy of misaligned data */ + struct cp_txq_entry* cp_entry; /* addr of cp resident tx queue entry */ + enum status* status; /* addr of host resident status */ + struct tpd* tpd; /* addr of transmit PDU descriptor */ + u32 tpd_dma; /* DMA address of tpd */ + struct sk_buff* skb; /* related skb */ + void* data; /* copy of misaligned data */ + unsigned long incarn; /* vc_map incarnation when submitted for tx */ + struct fore200e_vc_map* vc_map; + } host_txq_entry_t; @@ -576,6 +581,10 @@ enum buffer_scheme scheme; /* buffer scheme */ enum buffer_magn magn; /* buffer magnitude */ struct chunk data; /* data buffer */ +#ifdef FORE200E_BSQ_DEBUG + unsigned long index; /* buffer # in queue */ + int supplied; /* 'buffer supplied' flag */ +#endif } buffer_t; @@ -602,6 +611,7 @@ typedef struct host_txq { struct host_txq_entry host_entry[ QUEUE_SIZE_TX ]; /* host resident tx queue entries */ int head; /* head of tx queue */ + int tail; /* tail of tx queue */ struct chunk tpd; /* array of tpds */ struct chunk status; /* arry of completion status */ int txing; /* number of pending PDUs in tx queue */ @@ -626,8 +636,8 @@ struct chunk rbd_block; /* array of rbds */ struct chunk status; /* array of completion status */ struct buffer* buffer; /* array of rx buffers */ - int free; /* index of first free rx buffer */ - volatile int count; /* count of supplied rx buffers */ + struct buffer* freebuf; /* list of free rx buffers */ + volatile int freebuf_count; /* count of free rx buffers */ } host_bsq_t; @@ -847,6 +857,17 @@ #endif +/* vc mapping */ + +typedef struct fore200e_vc_map { + struct atm_vcc* vcc; /* vcc entry */ + unsigned long incarn; /* vcc incarnation number */ +} fore200e_vc_map_t; + +#define FORE200E_VC_MAP(fore200e, vpi, vci) \ + (& (fore200e)->vc_map[ ((vpi) << FORE200E_VCI_BITS) | (vci) ]) + + /* per-device data */ typedef struct fore200e { @@ -880,20 +901,29 @@ struct stats* stats; /* last snapshot of the stats */ struct semaphore rate_sf; /* protects rate reservation ops */ - struct tasklet_struct tasklet; /* performs interrupt work */ + spinlock_t q_lock; /* protects queue ops */ +#ifdef FORE200E_USE_TASKLET + struct tasklet_struct tx_tasklet; /* performs tx interrupt work */ + struct tasklet_struct rx_tasklet; /* performs rx interrupt work */ +#endif + unsigned long tx_sat; /* tx queue saturation count */ + unsigned long incarn_count; + struct fore200e_vc_map vc_map[ NBR_CONNECT ]; /* vc mapping */ } fore200e_t; /* per-vcc data */ typedef struct fore200e_vcc { - enum buffer_scheme scheme; /* rx buffer scheme */ - struct tpd_rate rate; /* tx rate control data */ - int rx_min_pdu; /* size of smallest PDU received */ - int rx_max_pdu; /* size of largest PDU received */ - int tx_min_pdu; /* size of smallest PDU transmitted */ - int tx_max_pdu; /* size of largest PDU transmitted */ + enum buffer_scheme scheme; /* rx buffer scheme */ + struct tpd_rate rate; /* tx rate control data */ + int rx_min_pdu; /* size of smallest PDU received */ + int rx_max_pdu; /* size of largest PDU received */ + int tx_min_pdu; /* size of smallest PDU transmitted */ + int tx_max_pdu; /* size of largest PDU transmitted */ + unsigned long tx_pdu; /* nbr of tx pdus */ + unsigned long rx_pdu; /* nbr of rx pdus */ } fore200e_vcc_t; From chas@cmf.nrl.navy.mil Fri Apr 23 17:30:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 17:30:47 -0700 (PDT) Received: from ginger.cmf.nrl.navy.mil (ginger.cmf.nrl.navy.mil [134.207.10.161]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O0UgKO010186 for ; Fri, 23 Apr 2004 17:30:42 -0700 Received: from cmf.nrl.navy.mil (thirdoffive.cmf.nrl.navy.mil [134.207.10.180]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id i3O0UbEI005507; Fri, 23 Apr 2004 20:30:37 -0400 (EDT) Message-Id: <200404240030.i3O0UbEI005507@ginger.cmf.nrl.navy.mil> To: netdev@oss.sgi.com Cc: davem@redhat.com Subject: [PATCH][ATM]: [fore200e] make use tasklet configurable (2 of 2) Reply-To: chas3@users.sourceforge.net Date: Fri, 23 Apr 2004 20:30:38 -0400 From: "chas williams (contractor)" X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-archive-position: 4892 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: chas@cmf.nrl.navy.mil Precedence: bulk X-list: netdev Content-Length: 2048 Lines: 63 fore200e 0.3e part 2 of 2 for 2.6 kernels # This is a BitKeeper generated patch for the following project: # Project Name: Linux kernel tree # This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas: # ChangeSet 1.1810 -> 1.1811 # drivers/atm/Kconfig 1.10 -> 1.11 # drivers/atm/fore200e.c 1.25 -> 1.26 # # The following is the BitKeeper ChangeSet Log # -------------------------------------------- # 04/04/16 chas@relax.cmf.nrl.navy.mil 1.1811 # [ATM]: [fore200e] make use tasklet configurable # -------------------------------------------- # diff -Nru a/drivers/atm/Kconfig b/drivers/atm/Kconfig --- a/drivers/atm/Kconfig Fri Apr 16 14:52:03 2004 +++ b/drivers/atm/Kconfig Fri Apr 16 14:52:03 2004 @@ -385,6 +385,15 @@ not have to supply an alternative one. They just say Y to "Use default SBA-200E firmware", above. +config ATM_FORE200E_USE_TASKLET + bool "Defer interrupt work to a tasklet" + depends on (PCI || SBUS) && (ATM_FORE200E_PCA || ATM_FORE200E_SBA) + default n + help + This defers work to be done by the interrupt handler to a + tasklet instead of hanlding everything at interrupt time. This + may improve the responsive of the host. + config ATM_FORE200E_TX_RETRY int "Maximum number of tx retries" depends on (PCI || SBUS) && (ATM_FORE200E_PCA || ATM_FORE200E_SBA) diff -Nru a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c --- a/drivers/atm/fore200e.c Fri Apr 16 14:52:03 2004 +++ b/drivers/atm/fore200e.c Fri Apr 16 14:52:03 2004 @@ -55,7 +55,7 @@ #include #endif -#if 0 /* defer interrupt work to a tasklet */ +#if defined(CONFIG_ATM_FORE200E_USE_TASKLET) /* defer interrupt work to a tasklet */ #define FORE200E_USE_TASKLET #endif @@ -1354,6 +1354,7 @@ } +#ifndef FORE200E_USE_TASKLET static void fore200e_irq(struct fore200e* fore200e) { @@ -1367,6 +1368,7 @@ fore200e_tx_irq(fore200e); spin_unlock_irqrestore(&fore200e->q_lock, flags); } +#endif static irqreturn_t From luto@myrealbox.com Fri Apr 23 22:08:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 22:09:07 -0700 (PDT) Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O58uKO018558 for ; Fri, 23 Apr 2004 22:08:56 -0700 Received: from luto.stanford.edu (luto.Stanford.EDU [128.12.71.50]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3O58mU0026121; Fri, 23 Apr 2004 22:08:48 -0700 Received: by luto.stanford.edu (Postfix, from userid 500) id 4EE961D52; Fri, 23 Apr 2004 22:09:32 -0700 (PDT) Date: Fri, 23 Apr 2004 22:08:25 -0700 From: Andy Lutomirski User-Agent: vi and postfix ;) MIME-Version: 1.0 To: romieu@fr.zoreil.com Cc: luto@myrealbox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [BROKEN PATCH] r8169 tx csum offload Content-Type: text/plain; charset=us-ascii Message-Id: <20040424050932.4EE961D52@luto.stanford.edu> X-archive-position: 4893 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Content-Length: 2209 Lines: 75 This applies after my patch from a couple minutes ago. The only problem is that it doesn't seem to do anything. I added a printk to the (skb->ip_summed == CHECKSUM_HW) check and it never triggered. I confirmed that sk_route_caps had NETIF_F_IP_CSUM set. What gives? --Andy Lutomirski Patch against 2.6.6-rc2-mm1. --- linux-2.6.6-rc2/drivers/net/r8169.c~r8169_tx_offload 2004-04-23 17:57:45.355820480 -0700 +++ linux-2.6.6-rc2/drivers/net/r8169.c 2004-04-23 20:30:49.634175536 -0700 @@ -55,6 +55,8 @@ #include #include #include +#include +#include #include @@ -301,6 +303,8 @@ enum _DescStatusBit { OWNbit = 0x80000000, EORbit = 0x40000000, + TCPCSbit = 0x00010000, + UDPCSbit = 0x00020000, FSbit = 0x20000000, LSbit = 0x10000000, }; @@ -533,6 +537,8 @@ .get_link = ethtool_op_get_link, .get_settings = rtl8169_get_settings, .set_settings = rtl8169_set_settings, + .get_tx_csum = ethtool_op_get_tx_csum, + .set_tx_csum = ethtool_op_set_tx_csum, }; static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, @@ -952,6 +958,7 @@ dev->watchdog_timeo = RTL8169_TX_TIMEOUT; dev->irq = pdev->irq; dev->base_addr = (unsigned long) ioaddr; + dev->features = NETIF_F_IP_CSUM; // dev->do_ioctl = mii_ioctl; tp = dev->priv; // private data // @@ -1428,6 +1435,7 @@ if (!(le32_to_cpu(tp->TxDescArray[entry].status) & OWNbit)) { dma_addr_t mapping; + u32 flags = 0; mapping = pci_map_single(tp->pci_dev, skb->data, len, PCI_DMA_TODEVICE); @@ -1435,8 +1443,19 @@ tp->Tx_skbuff[entry] = skb; tp->TxDescArray[entry].addr = cpu_to_le64(mapping); + if (skb->ip_summed == CHECKSUM_HW) { + const struct iphdr *ip = skb->nh.iph; + if (ip->protocol == IPPROTO_TCP) + flags = TCPCSbit; + else if (ip->protocol == IPPROTO_UDP) + flags = UDPCSbit; + else + BUG(); + } + tp->TxDescArray[entry].status = cpu_to_le32(OWNbit | FSbit | - LSbit | len | (EORbit * !((entry + 1) % NUM_TX_DESC))); + LSbit | len | (EORbit * !((entry + 1) % NUM_TX_DESC)) | + flags); RTL_W8(TxPoll, 0x40); //set polling bit From luto@myrealbox.com Fri Apr 23 22:08:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 22:09:11 -0700 (PDT) Received: from smtp1.Stanford.EDU (smtp1.Stanford.EDU [171.67.16.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O58uKO018560 for ; Fri, 23 Apr 2004 22:08:56 -0700 Received: from luto.stanford.edu (luto.Stanford.EDU [128.12.71.50]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3O58lmm026105; Fri, 23 Apr 2004 22:08:47 -0700 Received: by luto.stanford.edu (Postfix, from userid 500) id 14C341D4F; Fri, 23 Apr 2004 22:09:31 -0700 (PDT) Date: Fri, 23 Apr 2004 22:08:25 -0700 From: Andy Lutomirski User-Agent: vi and postfix ;) MIME-Version: 1.0 To: romieu@fr.zoreil.com Cc: luto@myrealbox.com, linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: [PATCH r8169] ethtool support and sane speed selection/detection Content-Type: text/plain; charset=us-ascii Message-Id: <20040424050931.14C341D4F@luto.stanford.edu> X-archive-position: 4894 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Content-Length: 16474 Lines: 593 This adds ethtool support to r8169. Some notes: I stole the RxUnderrun interrupt status bit because (1) I don't know what a recieve underrun is, (2) the specs say that bit is actually "link status changed" and (3) simple tests seem to confirm that. Speed selection doesn't actually set a forced mode but just sets autonegotiation to advertise only one speed. (This way there is no ugly special case for 1000Mbps.) The link status is no longer checked on startup because it is slow and, with ethtool support, unnecessary. As an added benefit, my 8001S often fails to negotiate 1000Mbps when the driver loads but will successfully negotiate it after a while. Running 'ethtool -s ethx autoneg on' fixes it, but that's absurd. This patch will, ten seconds after the driver starts, check if 1000Mbps is advertised but not selected, and, if so, force a renegotiation. --Andy Lutomirski Patch against 2.6.6-rc2-mm1. --- linux-2.6.6-rc2/drivers/net/r8169.c~r8169_ethtool 2004-04-22 19:34:55.697270344 -0700 +++ linux-2.6.6-rc2/drivers/net/r8169.c 2004-04-22 21:57:40.445230744 -0700 @@ -1,11 +1,12 @@ /* ========================================================================= - r8169.c: A RealTek RTL-8169 Gigabit Ethernet driver for Linux kernel 2.4.x. + r8169.c: A RealTek RTL-8169 Gigabit Ethernet driver for Linux kernel 2.6.x. -------------------------------------------------------------------- History: Feb 4 2002 - created initially by ShuChen . May 20 2002 - Add link status force-mode and TBI mode support. + Apr 22 2004 - Add ethtool support, clean up media selection. ========================================================================= 1. The media can be forced in 5 modes. Command: 'insmod r8169 media = SET_MEDIA' @@ -19,6 +20,9 @@ _1000_Full = 0x10 2. Support TBI mode. + + [UPDATE: Starting with version 1.3, the media parameter is deprecated. + Use ethtool instead.] ========================================================================= VERSION 1.1 <2002/10/4> @@ -33,6 +37,13 @@ - Copy mc_filter setup code from 8139cp (includes an optimization, and avoids set_bit use) +VERSION 1.3 <2004/04/22> (Andy Lutomirski - luto at myrealbox dot com) + + - Add ethtool support + - Add linkwatch support + - Don't wait for link at startup + - If gigabit isn't negotiated at startup, try again in ten seconds + */ #include @@ -50,7 +61,7 @@ #define DMA_64BIT_MASK 0xffffffffffffffffULL #define DMA_32BIT_MASK 0xffffffffULL -#define RTL8169_VERSION "1.2" +#define RTL8169_VERSION "1.3" #define MODULENAME "r8169" #define RTL8169_DRIVER_NAME MODULENAME " Gigabit Ethernet driver " RTL8169_VERSION #define PFX MODULENAME ": " @@ -101,7 +112,7 @@ #define RTL_MIN_IO_SIZE 0x80 #define RTL8169_TX_TIMEOUT (6*HZ) -#define RTL8169_PHY_TIMEOUT (HZ) +#define RTL8169_PHY_TIMEOUT (10*HZ) /* write/read MMIO register */ #define RTL_W8(reg, val8) writeb ((val8), ioaddr + (reg)) @@ -197,7 +208,7 @@ SWInt = 0x0100, TxDescUnavail = 0x80, RxFIFOOver = 0x40, - RxUnderrun = 0x20, + LinkChg = 0x20, RxOverflow = 0x10, TxErr = 0x08, TxOK = 0x04, @@ -327,8 +338,13 @@ struct sk_buff *Rx_skbuff[NUM_RX_DESC]; /* Rx data buffers */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ struct timer_list timer; - unsigned long phy_link_down_cnt; + int phy_reset_warned; + int phy_tried_renegotiate; u16 cp_cmd; + int if_up; + + int phy_auto_nego_reg; + int phy_1000_ctrl_reg; }; MODULE_AUTHOR("Realtek"); @@ -349,7 +365,7 @@ static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); static const u16 rtl8169_intr_mask = - RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const unsigned int rtl8169_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); @@ -393,6 +409,68 @@ return value; } +static void rtl8169_set_speed(struct net_device *dev, + u8 autoneg, u16 speed, u8 duplex) +{ + struct rtl8169_private *tp = dev->priv; + void *ioaddr = tp->mmio_addr; + unsigned long flags; + u8 status; + + int auto_nego, giga_ctrl; + + spin_lock_irqsave(&tp->lock, flags); + + status = RTL_R8(PHYstatus); + if ((status & TBI_Enable) && autoneg == AUTONEG_DISABLE) { + autoneg = AUTONEG_ENABLE; + printk(KERN_WARNING PFX + "%s: ignoring request to force speed in TBI mode\n", + dev->name); + } + + auto_nego = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); + auto_nego &= ~(PHY_Cap_10_Half | PHY_Cap_10_Full | + PHY_Cap_100_Half | PHY_Cap_100_Full); + giga_ctrl = mdio_read(ioaddr, PHY_1000_CTRL_REG); + giga_ctrl &= ~(PHY_Cap_1000_Full | PHY_Cap_Null); + + if (autoneg == AUTONEG_ENABLE) { + auto_nego |= (PHY_Cap_10_Half | PHY_Cap_10_Full | + PHY_Cap_100_Half | PHY_Cap_100_Full); + giga_ctrl |= PHY_Cap_1000_Full; + } else { + if (speed == SPEED_10) + auto_nego |= PHY_Cap_10_Half | PHY_Cap_10_Full; + else if (speed == SPEED_100) + auto_nego |= PHY_Cap_100_Half | PHY_Cap_100_Full; + + if (speed == SPEED_1000) + giga_ctrl |= PHY_Cap_1000_Full; + else + giga_ctrl |= PHY_Cap_Null; + + if (duplex == DUPLEX_HALF) + auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); + } + + tp->phy_auto_nego_reg = auto_nego; + tp->phy_1000_ctrl_reg = giga_ctrl; + + if(!(status & TBI_Enable)) { + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); + mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); + } + + mdio_write(ioaddr, PHY_CTRL_REG, + PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); + + if (tp->if_up && (giga_ctrl & PHY_Cap_1000_Full)) + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); + + spin_unlock_irqrestore(&tp->lock, flags); +} + static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { @@ -403,8 +481,58 @@ strcpy(info->bus_info, pci_name(tp->pci_dev)); } +static int rtl8169_get_settings(struct net_device *dev, + struct ethtool_cmd *cmd) +{ + struct rtl8169_private *tp = dev->priv; + void *ioaddr = tp->mmio_addr; + u8 status = RTL_R8(PHYstatus); + + cmd->supported = SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Full | + SUPPORTED_Autoneg | + SUPPORTED_TP; + + cmd->autoneg = 1; + cmd->advertising = ADVERTISED_TP | ADVERTISED_Autoneg; + if (tp->phy_auto_nego_reg & PHY_Cap_10_Half) + cmd->advertising |= ADVERTISED_10baseT_Half; + if (tp->phy_auto_nego_reg & PHY_Cap_10_Full) + cmd->advertising |= ADVERTISED_10baseT_Full; + if (tp->phy_auto_nego_reg & PHY_Cap_100_Half) + cmd->advertising |= ADVERTISED_100baseT_Half; + if (tp->phy_auto_nego_reg & PHY_Cap_100_Full) + cmd->advertising |= ADVERTISED_100baseT_Full; + if (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full) + cmd->advertising |= ADVERTISED_1000baseT_Full; + + if (status & _1000bpsF) cmd->speed = SPEED_1000; + else if (status & _100bps) cmd->speed = SPEED_100; + else if (status & _10bps) cmd->speed = SPEED_10; + + if (status & _1000bpsF || status & FullDup) + cmd->duplex = DUPLEX_FULL; + else + cmd->duplex = DUPLEX_HALF; + + return 0; +} + +static int rtl8169_set_settings(struct net_device *dev, + struct ethtool_cmd *cmd) +{ + rtl8169_set_speed(dev, cmd->autoneg, cmd->speed, cmd->duplex); + return 0; +} + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, + .get_link = ethtool_op_get_link, + .get_settings = rtl8169_get_settings, + .set_settings = rtl8169_set_settings, }; static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, @@ -569,55 +697,41 @@ mdio_write(ioaddr, 31, 0x0000); //w 31 2 0 0 } -static void rtl8169_hw_phy_reset(struct net_device *dev) -{ - struct rtl8169_private *tp = dev->priv; - void *ioaddr = tp->mmio_addr; - int i, val; - - printk(KERN_WARNING PFX "%s: Reset RTL8169s PHY\n", dev->name); - - val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; - mdio_write(ioaddr, 0, val); - - for (i = 50; i >= 0; i--) { - if (!(mdio_read(ioaddr, 0) & 0x8000)) - break; - udelay(100); /* Gross */ - } - - if (i < 0) { - printk(KERN_WARNING PFX "%s: no PHY Reset ack. Giving up.\n", - dev->name); - } -} - static void rtl8169_phy_timer(unsigned long __opaque) { struct net_device *dev = (struct net_device *)__opaque; struct rtl8169_private *tp = dev->priv; struct timer_list *timer = &tp->timer; void *ioaddr = tp->mmio_addr; + int val; + u8 status; assert(tp->mac_version > RTL_GIGA_MAC_VER_B); assert(tp->phy_version < RTL_GIGA_PHY_VER_G); - if (RTL_R8(PHYstatus) & LinkStatus) - tp->phy_link_down_cnt = 0; - else { - tp->phy_link_down_cnt++; - if (tp->phy_link_down_cnt >= 12) { - int reg; - - // If link on 1000, perform phy reset. - reg = mdio_read(ioaddr, PHY_1000_CTRL_REG); - if (reg & PHY_Cap_1000_Full) - rtl8169_hw_phy_reset(dev); + if (!(tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) + return; - tp->phy_link_down_cnt = 0; + status = RTL_R8(PHYstatus); + if(status & LinkStatus) { + if (!tp->phy_tried_renegotiate && !(status & _1000bpsF)) { + mdio_write(ioaddr, PHY_CTRL_REG, + PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); + tp->phy_tried_renegotiate = 1; } + return; + } + + if (tp->phy_reset_warned == 0) { + printk(KERN_WARNING PFX + "%s: Begin resetting PHY until link up\n", + dev->name); + tp->phy_reset_warned = 1; } + val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; + mdio_write(ioaddr, 0, val); + mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); } @@ -631,8 +745,6 @@ return; del_timer_sync(timer); - - tp->phy_link_down_cnt = 0; } static inline void rtl8169_request_timer(struct net_device *dev) @@ -644,7 +756,7 @@ (tp->phy_version >= RTL_GIGA_PHY_VER_G)) return; - tp->phy_link_down_cnt = 0; + tp->phy_reset_warned = 0; init_timer(timer); timer->expires = jiffies + RTL8169_PHY_TIMEOUT; @@ -804,7 +916,8 @@ static int board_idx = -1; static int printed_version = 0; int i, rc; - int option = -1, Cap10_100 = 0, Cap1000 = 0; + int option = -1; + int autoneg = AUTONEG_ENABLE, speed = SPEED_1000, duplex = DUPLEX_FULL; assert(pdev != NULL); assert(ent != NULL); @@ -888,94 +1001,51 @@ mdio_write(ioaddr, 0x0b, 0x0000); //w 0x0b 15 0 0 } - // if TBI is not endbled - if (!(RTL_R8(PHYstatus) & TBI_Enable)) { - int val = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); - - option = (board_idx >= MAX_UNITS) ? 0 : media[board_idx]; - // Force RTL8169 in 10/100/1000 Full/Half mode. - if (option > 0) { - printk(KERN_INFO "%s: Force-mode Enabled.\n", - dev->name); - Cap10_100 = 0, Cap1000 = 0; - switch (option) { - case _10_Half: - Cap10_100 = PHY_Cap_10_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _10_Full: - Cap10_100 = PHY_Cap_10_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Half: - Cap10_100 = PHY_Cap_100_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _1000_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_1000_Full; - break; - default: - break; - } - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, Cap10_100 | (val & 0x1F)); //leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_1000_CTRL_REG, Cap1000); - } else { - printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", - dev->name); - - // enable 10/100 Full/Half Mode, leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, - PHY_Cap_100_Full_Or_Less | (val & 0x1f)); - - // enable 1000 Full Mode - mdio_write(ioaddr, PHY_1000_CTRL_REG, - PHY_Cap_1000_Full); + rtl8169_request_timer(dev); + option = (board_idx >= MAX_UNITS) ? 0 : media[board_idx]; + if (option > 0) { + printk(KERN_WARNING PFX "%s: media option is deprecated.\n", + dev->name); + switch (option) { + case _10_Half: + autoneg = AUTONEG_DISABLE; + speed = SPEED_10; + duplex = DUPLEX_HALF; + break; + case _10_Full: + autoneg = AUTONEG_DISABLE; + speed = SPEED_10; + duplex = DUPLEX_FULL; + break; + case _100_Half: + autoneg = AUTONEG_DISABLE; + speed = SPEED_100; + duplex = DUPLEX_HALF; + break; + case _100_Full: + autoneg = AUTONEG_DISABLE; + speed = SPEED_100; + duplex = DUPLEX_FULL; + break; + case _1000_Full: + autoneg = AUTONEG_DISABLE; + speed = SPEED_1000; + duplex = DUPLEX_FULL; + break; + default: + break; } + } - // Enable auto-negotiation and restart auto-nigotiation - mdio_write(ioaddr, PHY_CTRL_REG, - PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); - udelay(100); - - // wait for auto-negotiation process - for (i = 10000; i > 0; i--) { - //check if auto-negotiation complete - if (mdio_read(ioaddr, PHY_STAT_REG) & - PHY_Auto_Neco_Comp) { - udelay(100); - option = RTL_R8(PHYstatus); - if (option & _1000bpsF) { - printk(KERN_INFO - "%s: 1000Mbps Full-duplex operation.\n", - dev->name); - } else { - printk(KERN_INFO - "%s: %sMbps %s-duplex operation.\n", - dev->name, - (option & _100bps) ? "100" : - "10", - (option & FullDup) ? "Full" : - "Half"); - } - break; - } else { - udelay(100); - } - } // end for-loop to wait for auto-negotiation process + rtl8169_set_speed(dev, autoneg, speed, duplex); - } else { + if (RTL_R8(PHYstatus) & TBI_Enable) { udelay(100); printk(KERN_INFO "%s: 1000Mbps Full-duplex operation, TBI Link %s!\n", dev->name, (RTL_R32(TBICSR) & TBILinkOK) ? "OK" : "Failed"); - } return 0; @@ -995,6 +1065,7 @@ pci_release_regions(pdev); pci_disable_device(pdev); + rtl8169_delete_timer(dev); free_netdev(dev); pci_set_drvdata(pdev, NULL); } @@ -1074,9 +1145,9 @@ if (retval < 0) goto err_free_rx; - rtl8169_hw_start(dev); + tp->if_up = 1; - rtl8169_request_timer(dev); + rtl8169_hw_start(dev); out: return retval; @@ -1153,13 +1224,23 @@ /* Enable all known interrupts by setting the interrupt mask. */ RTL_W16(IntrMask, rtl8169_intr_mask); + /* Check for link */ + spin_lock_irq(&tp->lock); + if (RTL_R8(PHYstatus) & LinkStatus) + netif_carrier_on(dev); + else { + netif_carrier_off(dev); + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); + } + spin_unlock_irq(&tp->lock); + netif_start_queue(dev); } static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { - desc->addr = 0x0badbadbadbadbad; + desc->addr = 0x0badbadbadbadbadULL; desc->status &= ~cpu_to_le32(OWNbit | RsvdMask); } @@ -1527,6 +1608,20 @@ printk(KERN_EMERG "%s: Rx buffers exhausted\n", dev->name); } +static void rtl8169_link_interrupt(struct net_device *dev, + struct rtl8169_private *tp, void *ioaddr) +{ + spin_lock(&tp->lock); + if (RTL_R8(PHYstatus) & LinkStatus) { + netif_carrier_on(dev); + tp->phy_reset_warned = 0; + } else { + netif_carrier_off(dev); + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); + } + spin_unlock(&tp->lock); +} + /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance, struct pt_regs *regs) @@ -1546,10 +1641,8 @@ break; handled = 1; -/* - if (status & RxUnderrun) - link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit; -*/ + + RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); @@ -1557,7 +1650,7 @@ break; // Rx interrupt - if (status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) { + if (status & (RxOK | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt @@ -1566,6 +1659,9 @@ rtl8169_tx_interrupt(dev, tp, ioaddr); spin_unlock(&tp->lock); } + // Link interrupt + if (status & LinkChg) + rtl8169_link_interrupt(dev, tp, ioaddr); boguscnt--; } while (boguscnt > 0); @@ -1588,8 +1684,6 @@ netif_stop_queue(dev); - rtl8169_delete_timer(dev); - spin_lock_irq(&tp->lock); /* Stop the chip's Tx and Rx DMA processes. */ @@ -1605,6 +1699,7 @@ spin_unlock_irq(&tp->lock); synchronize_irq(dev->irq); + tp->if_up = 0; free_irq(dev->irq, dev); rtl8169_tx_clear(tp); From scott.feldman@intel.com Fri Apr 23 22:30:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 22:30:10 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O5U3KO019414 for ; Fri, 23 Apr 2004 22:30:05 -0700 Received: from petasus-pilot.fm.intel.com (petasus-pilot.fm.intel.com [10.1.192.44]) by caduceus.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3O5U2sP022048; Sat, 24 Apr 2004 05:30:02 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by petasus-pilot.fm.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3O5U0Ba027111; Sat, 24 Apr 2004 05:30:15 GMT Received: from sfeldma-ich5.jf.intel.com ([134.134.3.54]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042322295408516 ; Fri, 23 Apr 2004 22:29:54 -0700 Date: Fri, 23 Apr 2004 22:25:41 -0700 (PDT) From: Scott Feldman To: jgarzik@pobox.com cc: netdev@oss.sgi.com, scott.feldman@intel.com Subject: [e100 2.5] ICH 10/H Tx hang fix Message-ID: ReplyTo: "Scott Feldman" MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-archive-position: 4895 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: scott.feldman@intel.com Precedence: bulk X-list: netdev Content-Length: 2106 Lines: 68 * Need to carry forward this workaround from old e100 driver to avoid a Tx hang on ICH systems linked at 10/Half. Workaround adds a stall before each Tx command queued by issuing a NOP command followed by 1us delay. Yuck! Otherwise HW locks hard. (Probably needed for eepro100 also ;-). ---------------- --- linux-2.5/drivers/net/e100.c 2004-04-20 15:52:24.000000000 -0700 +++ linux-2.5/drivers/net/e100.c.mod 2004-04-20 15:55:32.000000000 -0700 @@ -287,6 +287,7 @@ enum scb_cmd_hi { }; enum scb_cmd_lo { + cuc_nop = 0x00, ruc_start = 0x01, ruc_load_base = 0x06, cuc_start = 0x10, @@ -514,10 +515,11 @@ struct nic { /* End: frequently used values: keep adjacent for cache effect */ enum { - ich = (1 << 0), - promiscuous = (1 << 1), - multicast_all = (1 << 2), - wol_magic = (1 << 3), + ich = (1 << 0), + promiscuous = (1 << 1), + multicast_all = (1 << 2), + wol_magic = (1 << 3), + ich_10h_workaround = (1 << 4), } flags ____cacheline_aligned; enum mac mac; @@ -1225,6 +1227,12 @@ static void e100_watchdog(unsigned long /* Issue a multicast command to workaround a 557 lock up */ e100_set_multicast_list(nic->netdev); + if(nic->flags & ich && cmd.speed==SPEED_10 && cmd.duplex==DUPLEX_HALF) + /* Need SW workaround for ICH[x] 10Mbps/half duplex Tx hang. */ + nic->flags |= ich_10h_workaround; + else + nic->flags &= ~ich_10h_workaround; + mod_timer(&nic->watchdog, jiffies + E100_WATCHDOG_PERIOD); } @@ -1244,7 +1252,17 @@ static inline void e100_xmit_prepare(str static int e100_xmit_frame(struct sk_buff *skb, struct net_device *netdev) { struct nic *nic = netdev->priv; - int err = e100_exec_cb(nic, skb, e100_xmit_prepare); + int err; + + if(nic->flags & ich_10h_workaround) { + /* SW workaround for ICH[x] 10Mbps/half duplex Tx hang. + Issue a NOP command followed by a 1us delay before + issuing the Tx command. */ + e100_exec_cmd(nic, cuc_nop, 0); + udelay(1); + } + + err = e100_exec_cb(nic, skb, e100_xmit_prepare); switch(err) { case -ENOSPC: From rchaurasiya@cse.iitk.ac.in Fri Apr 23 22:32:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 23 Apr 2004 22:32:06 -0700 (PDT) Received: from mail2.iitk.ac.in ([203.197.196.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O5VxKO019724 for ; Fri, 23 Apr 2004 22:32:02 -0700 Received: from antivirus.cc.iitk.ac.in (antivirus.cc.iitk.ac.in [172.31.1.102]) by mail2.iitk.ac.in (8.12.8/8.12.8) with SMTP id i3O5ipaI006671 for ; Sat, 24 Apr 2004 11:15:06 +0530 Received: from mailhost.cse.iitk.ac.in ([172.27.16.2]) by antivirus.cc.iitk.ac.in (NAVGW 2.5.2.12) with SMTP id M2004042411011426129 for ; Sat, 24 Apr 2004 11:01:14 +0530 Received: from cseultra3 (cseultra3.cse.iitk.ac.in [172.27.16.3]) by mailhost.cse.iitk.ac.in (8.12.8/8.12.8) with ESMTP id i3O5UCL6009688 for ; Sat, 24 Apr 2004 11:00:12 +0530 Date: Sat, 24 Apr 2004 11:00:07 +0530 (IST) From: Ramesh Chaurasiya To: netdev@oss.sgi.com Subject: buffer overruns Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4896 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rchaurasiya@cse.iitk.ac.in Precedence: bulk X-list: netdev Content-Length: 551 Lines: 13 Hi, Whenever I try to receive traffic at more than 500 Mbps, many packets are being dropped as shown in ifconfig. There are many overruns and errors in Rx packets details of ifconfig. I am using Intel PRO 1000 Gigabit NIC, linux 2.4.20-8smp and dual processsor Xeon Machine with a 32bit/33 MHz PCI bus. What does this error means. Am I dropping packets at NIC/driver/kernel buffers/application socket? What new hardware should I use to overcome this. I am using latest e1000 drivers compiled with NAPI support. Please help me out. Thanks, Ramesh. From greearb@candelatech.com Sat Apr 24 00:55:39 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 00:55:42 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O7tdKO003448 for ; Sat, 24 Apr 2004 00:55:39 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i3O7w508030255; Sat, 24 Apr 2004 00:58:05 -0700 Message-ID: <408A1D73.5030705@candelatech.com> Date: Sat, 24 Apr 2004 00:55:31 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ramesh Chaurasiya CC: netdev@oss.sgi.com Subject: Re: buffer overruns References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4898 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev Content-Length: 853 Lines: 24 Ramesh Chaurasiya wrote: > Hi, > Whenever I try to receive traffic at more than 500 Mbps, many packets > are being dropped as shown in ifconfig. There are many overruns and errors > in Rx packets details of ifconfig. I am using Intel PRO 1000 Gigabit NIC, > linux 2.4.20-8smp and dual processsor Xeon Machine with a 32bit/33 MHz PCI > bus. What does this error means. Am I dropping packets at > NIC/driver/kernel buffers/application socket? What new hardware should I > use to overcome this. I am using latest e1000 drivers compiled with NAPI > support. Please help me out. > Thanks, > Ramesh. Get a 64-bit PCI-X bus, and set the RxDescriptors and TxDescriptors in the e1000 driver to 4096. With that, I can get about 999Mbps rx + tx on two ports. Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com From romieu@fr.zoreil.com Sat Apr 24 04:48:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 04:48:54 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OBmgKO012177 for ; Sat, 24 Apr 2004 04:48:43 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3OAituX026067; Sat, 24 Apr 2004 12:44:55 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3OAirKp026066; Sat, 24 Apr 2004 12:44:53 +0200 Date: Sat, 24 Apr 2004 12:44:53 +0200 From: Francois Romieu To: Andy Lutomirski Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com, jgarzik@pobox.com, Jon D Mason Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection Message-ID: <20040424124453.A25284@electric-eye.fr.zoreil.com> References: <20040424050931.14C341D4F@luto.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040424050931.14C341D4F@luto.stanford.edu>; from luto@myrealbox.com on Fri, Apr 23, 2004 at 10:08:25PM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 4899 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 1713 Lines: 44 [Jeff Garzik added to the loop] [If nobody disagrees, I'll remove l-k from the Cc: during the next round] Andy Lutomirski : > This adds ethtool support to r8169. Cool. > Some notes: I stole the RxUnderrun interrupt status bit because (1) I > don't know what a recieve underrun is, (2) the specs say that bit is > actually "link status changed" and (3) simple tests seem to confirm that. Ok, this bit is named 'LinkChg' in drivers/net/8139cp.c as well. > Speed selection doesn't actually set a forced mode but just sets > autonegotiation to advertise only one speed. (This way there is no ugly > special case for 1000Mbps.) > > The link status is no longer checked on startup because it is slow and, with > ethtool support, unnecessary. Just to clarify, it is still done in rtl8169_open() instead of rtl8169_init_one(). Even if it is a change of behavior in a supposedly stable serie, I guess it is ok as it moves the driver in the direction of the 8139cp driver. > As an added benefit, my 8001S often fails to negotiate 1000Mbps when the > driver loads but will successfully negotiate it after a while. Running > 'ethtool -s ethx autoneg on' fixes it, but that's absurd. This patch > will, ten seconds after the driver starts, check if 1000Mbps is advertised > but not selected, and, if so, force a renegotiation. So you can not reliably remove the phy timer and simply use the LinkChg status change, right ? Is everybody fine if I cook up a serie of patches for -netdev/-mm inclusion which includes: - your link related changes - start of a 8139cp.c genetic mutation on top of those - reworked Jon D Mason's NAPI changes ETA: this week end, start of incoming week. -- Ueimor From hadi@cyberus.ca Sat Apr 24 07:15:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 07:15:29 -0700 (PDT) Received: from mx02.cybersurf.com (mx02.cybersurf.com [209.197.145.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OEFOKO014466 for ; Sat, 24 Apr 2004 07:15:24 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx02.cybersurf.com with esmtp (Exim 4.30) id 1BHNwT-0002eH-Un for netdev@oss.sgi.com; Sat, 24 Apr 2004 10:15:41 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BHNw2-0000WP-K5; Sat, 24 Apr 2004 10:15:14 -0400 Subject: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: netdev@oss.sgi.com Cc: syrius.ml@no-log.org, Maxim Krasnyansky , Jeff Garzik , "David S. Miller" In-Reply-To: <1082719745.1057.27.camel@jzny.localdomain> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> Content-Type: text/plain Organization: jamalopolis Message-Id: <1082816083.1054.32.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Apr 2004 10:14:43 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4900 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 1782 Lines: 51 Maxim, When TUN_TUN_DEV is used, before the packet is injected into the netif_rx() only skb->mac.raw = skb->data is set; the other headers are not adjusted. Typically netdevs would do a skb_pull(skb,dev->hard_header_len) to make the adjustment. I have a feeling this is design intent thats why i didnt send you a patch. Jeff, Dave: Would it be fair to say when packets get injected into the stack by a netdev via netif_rx(), the skb headers are expected to be ponting into some specific places? I am not sure if theres a hard fastened rule defined anywhere. cheers, jamal On Fri, 2004-04-23 at 07:29, jamal wrote: > Hi there, > > On Thu, 2004-04-22 at 13:43, syrius.ml@no-log.org wrote: > > Hi, > > > > It oops when using the ingress qdisc + action mirred egress redirect > > filter on tun0. (no egress at all, no ingress on eth0) > > It doesn't oops using an ingress qdisc + a simple police+drop filter > > on tun0... > > Ok, so you have narrowed it down to mirred, tun and ingress qdisc - is > that correct? Were you using openvpn to recreate this? > BTW, would this happen if you dont issue the ping -f initially in above > setup? If yes, before you send create the problem can you send a few > pings through tap device and send me output of dmesg? > > I just did a simple test with a basic program and couldnt reproduce it. > I dont have the proper setup, can you do a basic test with some other > tunneling s/ware? > The doc for tun mentions: > http://vtun.sourceforge.net and http://perso.enst.fr/~beyssac/pipsec/ > Please compile in tun and dummy into the kernel. > > BTW, i think we should take this offline; send your response directly to > me. Anyone else interested in this conversation email both of us and we > will cc you. > > cheers, > jamal > > > > From luto@stanford.edu Sat Apr 24 08:06:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 08:06:37 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OF6RKO015898 for ; Sat, 24 Apr 2004 08:06:28 -0700 Received: from stanford.edu (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3OF6HbK006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Apr 2004 08:06:19 -0700 Message-ID: <408A8252.5040006@stanford.edu> Date: Sat, 24 Apr 2004 08:05:54 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: Andy Lutomirski , netdev@oss.sgi.com, jgarzik@pobox.com, Jon D Mason Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: <20040424050931.14C341D4F@luto.stanford.edu> <20040424124453.A25284@electric-eye.fr.zoreil.com> In-Reply-To: <20040424124453.A25284@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4902 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@stanford.edu Precedence: bulk X-list: netdev Content-Length: 2231 Lines: 59 Francois Romieu wrote: > [Jeff Garzik added to the loop] > [If nobody disagrees, I'll remove l-k from the Cc: during the next round] done - my bad. >>As an added benefit, my 8001S often fails to negotiate 1000Mbps when the >>driver loads but will successfully negotiate it after a while. Running >>'ethtool -s ethx autoneg on' fixes it, but that's absurd. This patch >>will, ten seconds after the driver starts, check if 1000Mbps is advertised >>but not selected, and, if so, force a renegotiation. > > > So you can not reliably remove the phy timer and simply use the LinkChg status > change, right ? Apparently. The timer only fires when necessary with my patch, though (see the return statements in rtl8169_phy_timer). BTW, what was it there for in the first place? I can get gigabit to fail to negotiate, but I always pick up a 100Mbps/full duplex link when that happens. I've never seen a complete absense of link. I left the original semantics around because I assumed there was a reason, but if it's unnecessary, then the timer should only need to fire once during the lifetime of the device (and the assorted bookkeeping can go away). > > Is everybody fine if I cook up a serie of patches for -netdev/-mm inclusion > which includes: > - your link related changes > - start of a 8139cp.c genetic mutation on top of those > - reworked Jon D Mason's NAPI changes Fine by me. One other question: I was once able to put the chipset into a state where it appeared to have lost all software control over the PHY (LinkChg never fired, the link always appeared to be down, changing allowed link modes, resetting the phy, and forcing renegotiation did nothing, but the link still worked). This problem survived reload of my driver, reload of the unmodified driver, a warm reboot and a cold reboot; I fixed it by turning off the computer, then unplugging the power supply, and then turning it on to discharge the standby voltage. Do you know any way to do an extra hard reset of the chipset? Any thoughts on what's wrong with my tx csum offload patch? If I can get that working, I'll do rx csum offload and TSO as well. --Andy > > ETA: this week end, start of incoming week. > > -- > Ueimor From romieu@fr.zoreil.com Sat Apr 24 09:04:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 09:04:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OG4fKO020680 for ; Sat, 24 Apr 2004 09:04:41 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3OF13uX027904; Sat, 24 Apr 2004 17:01:03 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3OF12Hf027903; Sat, 24 Apr 2004 17:01:02 +0200 Date: Sat, 24 Apr 2004 17:01:02 +0200 From: Francois Romieu To: Andy Lutomirski Cc: Andy Lutomirski , netdev@oss.sgi.com, jgarzik@pobox.com, Jon D Mason Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection Message-ID: <20040424170102.A27531@electric-eye.fr.zoreil.com> References: <20040424050931.14C341D4F@luto.stanford.edu> <20040424124453.A25284@electric-eye.fr.zoreil.com> <408A8252.5040006@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <408A8252.5040006@stanford.edu>; from luto@stanford.edu on Sat, Apr 24, 2004 at 08:05:54AM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 4903 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 2043 Lines: 50 Re, Andy Lutomirski : [...] > done - my bad. No problem. [...] > > So you can not reliably remove the phy timer and simply use the LinkChg > > status change, right ? > > Apparently. The timer only fires when necessary with my patch, though > (see the return statements in rtl8169_phy_timer). > > BTW, what was it there for in the first place? I can get gigabit to > fail to negotiate, but I always pick up a 100Mbps/full duplex link when > that happens. I've never seen a complete absense of link. I left the > original semantics around because I assumed there was a reason, but if > it's unnecessary, then the timer should only need to fire once during > the lifetime of the device (and the assorted bookkeeping can go away). The timer is a survival of Realtek's changes as they appeared in their release 1.6 of the driver but it does not necessarily means that it can not be done differently. As Jeff suggested/expects a merge of the r8169 driver within the 8139cp one, a removal of the timer would push the r8169 driver in the right direction. At least that's how I have read your patch this morning :o) [completely unresponsive r8169 chipset] > Do you know any way to do an extra hard reset of the chipset? It has already been reported but I have not digged it. A comparison of the registers of the device when it is functionnal/frost may shed some light on this issue. [...] > Any thoughts on what's wrong with my tx csum offload patch? If I can > get that working, I'll do rx csum offload and TSO as well. So far I have not had time to look closely at your TSO patch. If you want a working TSO support with minimal pain, getting some inspiration from the 8139cp driver would be imho the way to go. One can expect this kind of new functions (from a r8169 pov) to be gained from the merge with the 8139cp.c. So, if you want to publish some TSO patch, it would be nice to write it in such a way that it does not make the r8169 more different from the 8139cp driver than it currently is. -- Ueimor From jonmason@us.ibm.com Sat Apr 24 12:45:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 12:45:22 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OJj9KQ030987 for ; Sat, 24 Apr 2004 12:45:18 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3OJj387582186; Sat, 24 Apr 2004 15:45:03 -0400 Received: from d03nm130.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3OJj2OE194246; Sat, 24 Apr 2004 13:45:02 -0600 In-Reply-To: <408A8252.5040006@stanford.edu> To: Andy Lutomirski Cc: jgarzik@pobox.com, Andy Lutomirski , netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Francois Romieu MIME-Version: 1.0 Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Sat, 24 Apr 2004 14:44:59 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/24/2004 13:45:02, Serialize complete at 04/24/2004 13:45:02 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4904 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1821 Lines: 42 >>>As an added benefit, my 8001S often fails to negotiate 1000Mbps when the >>>driver loads but will successfully negotiate it after a while. Running >>>'ethtool -s ethx autoneg on' fixes it, but that's absurd. This patch >>>will, ten seconds after the driver starts, check if 1000Mbps is advertised >>>but not selected, and, if so, force a renegotiation. >> >> >> So you can not reliably remove the phy timer and simply use the LinkChg status >> change, right ? > >Apparently. The timer only fires when necessary with my patch, though >(see the return statements in rtl8169_phy_timer). > >BTW, what was it there for in the first place? I can get gigabit to >fail to negotiate, but I always pick up a 100Mbps/full duplex link when >that happens. I've never seen a complete absense of link. I left the >original semantics around because I assumed there was a reason, but if >it's unnecessary, then the timer should only need to fire once during >the lifetime of the device (and the assorted bookkeeping can go away). I have an 8110S version of the chipset, and I don't have any problems with it getting an improper link speed form the outset. Though, I am running point-to-point with an e1000 adapter. Are you running this through a switch? BTW, good work doing the link changes. Though it might be beneficial to do a "printk(KERN_INFO "%s: Link Down\n", dev->name);" in the interrupt handler to show that the link is down in the dmesg (and a Link Up message too). >> Is everybody fine if I cook up a series of patches for -netdev/-mm inclusion >> which includes: >> - your link related changes >> - start of a 8139cp.c genetic mutation on top of those >> - reworked Jon D Mason's NAPI changes Looks like a fair amount of work to convert 8139cp to r8169. Let me know if you need any help. From jonmason@us.ibm.com Sat Apr 24 13:00:12 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 13:00:16 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OK0BKO031440 for ; Sat, 24 Apr 2004 13:00:11 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3OJxr1T519718; Sat, 24 Apr 2004 15:59:53 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3OJxqHM373192; Sat, 24 Apr 2004 13:59:53 -0600 To: Francois Romieu Cc: jgarzik@pobox.com, netdev@oss.sgi.com MIME-Version: 1.0 Subject: Re: [PATCH] r8169 NAPI addition X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Sat, 24 Apr 2004 13:59:50 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/24/2004 13:59:52 Content-Type: multipart/mixed; boundary="=_mixed 006D687686256E80_=" X-archive-position: 4905 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 16135 Lines: 235 --=_mixed 006D687686256E80_= Content-Type: text/plain; charset="US-ASCII" > If I am not mistaken (1:55 AM here), either 1) you do not clear the RX > related bits of IntrStatus in r8169_interrupt() but you clear it in > rtl8169_poll() and you add local_irq_{en/dis}able() to rtl8169_poll() > (ala 8139cp.c) or 2) you modify r8169_interrupt() so that it can signal > to rtl8169_poll() that it cleared itself the Rx bits of IntrStatus whereas > rtl8169_poll() was running (ala epic100-netdev). > >If you hesitate, go for 1). 2) works but I have not benchmarketed it yet :o) Actually, I implemented it in a different way (though similar to #1). I have the Rx and TX bits not being cleared from the Interrupt status register while polling (which doesn't matter because they aren't in the interrupt mask). After the poll completes, the mask is reset to include the Tx and Rx bit. If any new packets that came in while it was doing the poll work, the interrupt will pop when the mask is reset (and the new work will get scheduled). When the interrupt handler gets called now, it will clear the Rx and Tx interrupt bits. I'm sure the code explains it better than the words above. :-) > >If you have doubts regarding your Tx part, feel free to send any code. The Tx code has been integrated with the latest version of my NAPI patch. It is actually working very well. Take a peek and let me know what you think. BTW, I did a little code clean-up in these changes. If you want me to split it out into a separate patch, just let me know. Thanks, Jon --=_mixed 006D687686256E80_= Content-Type: application/octet-stream; name="r8169.diff" Content-Disposition: attachment; filename="r8169.diff" Content-Transfer-Encoding: base64 LS0tIHI4MTY5LmMub3JpZwkyMDA0LTA0LTE4IDIyOjUxOjMzLjAwMDAwMDAwMCAtMDUwMAorKysg cjgxNjkuYwkyMDA0LTA0LTI0IDEwOjMwOjU1LjQzNTA2NTE1MiAtMDUwMApAQCAtOTMsOCArOTMs MTUgQEAgc3RhdGljIGludCBtdWx0aWNhc3RfZmlsdGVyX2xpbWl0ID0gMzI7CiAjZGVmaW5lIFJ4 UGFja2V0TWF4U2l6ZQkweDA4MDAJLyogTWF4aW11bSBzaXplIHN1cHBvcnRlZCBpcyAxNkstMSAq LwogI2RlZmluZSBJbnRlckZyYW1lR2FwCTB4MDMJLyogMyBtZWFucyBJbnRlckZyYW1lR2FwID0g dGhlIHNob3J0ZXN0IG9uZSAqLwogCi0jZGVmaW5lIE5VTV9UWF9ERVNDCTY0CS8qIE51bWJlciBv ZiBUeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisv KiBUaGUgbnVtYmVyIG9mIFJ4IGl0ZXJhdGlvbnMgcHJvY2Vzc2VkIChpZiBOQVBJIGVuYWJsZWQp ICovCisjZGVmaW5lIFI4MTY5X05BUElfV0VJR0hUCTY0CisKKyNkZWZpbmUgTlVNX1JYX0RFU0MJ MjU2CS8qIE51bWJlciBvZiBSeCBkZXNjcmlwdG9yIHJlZ2lzdGVycyAqLworI2Vsc2UKICNkZWZp bmUgTlVNX1JYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFJ4IGRlc2NyaXB0b3IgcmVnaXN0ZXJzICov CisjZW5kaWYKKyNkZWZpbmUgTlVNX1RYX0RFU0MJNjQJLyogTnVtYmVyIG9mIFR4IGRlc2NyaXB0 b3IgcmVnaXN0ZXJzICovCiAjZGVmaW5lIFJYX0JVRl9TSVpFCTE1MzYJLyogUnggQnVmZmVyIHNp emUgKi8KICNkZWZpbmUgUjgxNjlfVFhfUklOR19CWVRFUwkoTlVNX1RYX0RFU0MgKiBzaXplb2Yo c3RydWN0IFR4RGVzYykpCiAjZGVmaW5lIFI4MTY5X1JYX1JJTkdfQllURVMJKE5VTV9SWF9ERVND ICogc2l6ZW9mKHN0cnVjdCBSeERlc2MpKQpAQCAtMzIwLDE1ICszMjcsMTggQEAgc3RydWN0IHJ0 bDgxNjlfcHJpdmF0ZSB7CiAJdTMyIGN1cl90eDsgLyogSW5kZXggaW50byB0aGUgVHggZGVzY3Jp cHRvciBidWZmZXIgb2YgbmV4dCBSeCBwa3QuICovCiAJdTMyIGRpcnR5X3J4OwogCXUzMiBkaXJ0 eV90eDsKLQlzdHJ1Y3QgVHhEZXNjICpUeERlc2NBcnJheTsJLyogSW5kZXggb2YgMjU2LWFsaWdu bWVudCBUeCBEZXNjcmlwdG9yIGJ1ZmZlciAqLwotCXN0cnVjdCBSeERlc2MgKlJ4RGVzY0FycmF5 OwkvKiBJbmRleCBvZiAyNTYtYWxpZ25tZW50IFJ4IERlc2NyaXB0b3IgYnVmZmVyICovCisJc3Ry dWN0IFR4RGVzYyAqVHhEZXNjQXJyYXk7IC8qIEluZGV4IG9mIDI1Ni1hbGlnbm1lbnQgVHggRGVz Y3JpcHRvciBidWZmZXIgKi8KKwlzdHJ1Y3QgUnhEZXNjICpSeERlc2NBcnJheTsgLyogSW5kZXgg b2YgMjU2LWFsaWdubWVudCBSeCBEZXNjcmlwdG9yIGJ1ZmZlciAqLwogCWRtYV9hZGRyX3QgVHhQ aHlBZGRyOwogCWRtYV9hZGRyX3QgUnhQaHlBZGRyOwogCXN0cnVjdCBza19idWZmICpSeF9za2J1 ZmZbTlVNX1JYX0RFU0NdOwkvKiBSeCBkYXRhIGJ1ZmZlcnMgKi8KLQlzdHJ1Y3Qgc2tfYnVmZiAq VHhfc2tidWZmW05VTV9UWF9ERVNDXTsJLyogSW5kZXggb2YgVHJhbnNtaXQgZGF0YSBidWZmZXIg Ki8KKwlzdHJ1Y3Qgc2tfYnVmZiAqVHhfc2tidWZmW05VTV9UWF9ERVNDXTsJLyogSW5kZXggb2Yg VHggZGF0YSBidWZmZXIgKi8KIAlzdHJ1Y3QgdGltZXJfbGlzdCB0aW1lcjsKIAl1bnNpZ25lZCBs b25nIHBoeV9saW5rX2Rvd25fY250OwogCXUxNiBjcF9jbWQ7CisjaWZkZWYgQ09ORklHX1I4MTY5 X05BUEkKKwl1MTYgaW50cl9tYXNrOworI2VuZGlmCiB9OwogCiBNT0RVTEVfQVVUSE9SKCJSZWFs dGVrIik7CkBAIC0zNDcsNiArMzU3LDkgQEAgc3RhdGljIGludCBydGw4MTY5X2Nsb3NlKHN0cnVj dCBuZXRfZGV2aQogc3RhdGljIHZvaWQgcnRsODE2OV9zZXRfcnhfbW9kZShzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KTsKIHN0YXRpYyB2b2lkIHJ0bDgxNjlfdHhfdGltZW91dChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KTsKIHN0YXRpYyBzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqcnRsODE2OV9nZXRf c3RhdHMoc3RydWN0IG5ldF9kZXZpY2UgKm5ldGRldik7CisjaWZkZWYgQ09ORklHX1I4MTY5X05B UEkKK3N0YXRpYyBpbnQgcnRsODE2OV9wb2xsKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCAq YnVkZ2V0KTsKKyNlbmRpZgogCiBzdGF0aWMgY29uc3QgdTE2IHJ0bDgxNjlfaW50cl9tYXNrID0K ICAgICBSeFVuZGVycnVuIHwgUnhPdmVyZmxvdyB8IFJ4RklGT092ZXIgfCBUeEVyciB8IFR4T0sg fCBSeEVyciB8IFJ4T0s7CkBAIC02ODQsNyArNjk3LDggQEAgcnRsODE2OV9pbml0X2JvYXJkKHN0 cnVjdCBwY2lfZGV2ICpwZGV2LAogCS8vIGVuYWJsZSBkZXZpY2UgKGluY2wuIFBDSSBQTSB3YWtl dXAgYW5kIGhvdHBsdWcgc2V0dXApCiAJcmMgPSBwY2lfZW5hYmxlX2RldmljZShwZGV2KTsKIAlp ZiAocmMpIHsKLQkJcHJpbnRrKEtFUk5fRVJSIFBGWCAiJXM6IHVuYWJsZSB0byBlbmFibGUgZGV2 aWNlXG4iLCBwZGV2LT5zbG90X25hbWUpOworCQlwcmludGsoS0VSTl9FUlIgUEZYICIlczogdW5h YmxlIHRvIGVuYWJsZSBkZXZpY2VcbiIsIAorCQkJcGRldi0+c2xvdF9uYW1lKTsKIAkJZ290byBl cnJfb3V0OwogCX0KIApAQCAtNjk2LDcgKzcxMCw4IEBAIHJ0bDgxNjlfaW5pdF9ib2FyZChzdHJ1 Y3QgcGNpX2RldiAqcGRldiwKIAkJcGNpX3JlYWRfY29uZmlnX3dvcmQocGRldiwgcG1fY2FwICsg UENJX1BNX0NUUkwsICZwd3JfY29tbWFuZCk7CiAJCWFjcGlfaWRsZV9zdGF0ZSA9IHB3cl9jb21t YW5kICYgUENJX1BNX0NUUkxfU1RBVEVfTUFTSzsKIAl9IGVsc2UgewotCQlwcmludGsoS0VSTl9F UlIgUEZYICJDYW5ub3QgZmluZCBQb3dlck1hbmFnZW1lbnQgY2FwYWJpbGl0eSwgYWJvcnRpbmcu XG4iKTsKKwkJcHJpbnRrKEtFUk5fRVJSIFBGWCAiQ2Fubm90IGZpbmQgUG93ZXJNYW5hZ2VtZW50 IGNhcGFiaWxpdHksIiAKKwkJCSJhYm9ydGluZy5cbiIpOwogCQlnb3RvIGVycl9vdXRfZnJlZV9y ZXM7CiAJfQogCkBAIC03MjEsNyArNzM2LDggQEAgcnRsODE2OV9pbml0X2JvYXJkKHN0cnVjdCBw Y2lfZGV2ICpwZGV2LAogCiAJcmMgPSBwY2lfcmVxdWVzdF9yZWdpb25zKHBkZXYsIGRldi0+bmFt ZSk7CiAJaWYgKHJjKSB7Ci0JCXByaW50ayhLRVJOX0VSUiBQRlggIiVzOiBDb3VsZCBub3QgcmVx dWVzdCByZWdpb25zLlxuIiwgcGRldi0+c2xvdF9uYW1lKTsKKwkJcHJpbnRrKEtFUk5fRVJSIFBG WCAiJXM6IENvdWxkIG5vdCByZXF1ZXN0IHJlZ2lvbnMuXG4iLCAKKwkJCXBkZXYtPnNsb3RfbmFt ZSk7CiAJCWdvdG8gZXJyX291dF9kaXNhYmxlOwogCX0KIApAQCAtODIwLDcgKzgzNiw3IEBAIHJ0 bDgxNjlfaW5pdF9vbmUoc3RydWN0IHBjaV9kZXYgKnBkZXYsIGMKIAlpZiAocmMpCiAJCXJldHVy biByYzsKIAotCXRwID0gZGV2LT5wcml2OworCXRwID0gZGV2LT5wcml2OwkJLy8gcHJpdmF0ZSBk YXRhIC8vCiAJYXNzZXJ0KGlvYWRkciAhPSBOVUxMKTsKIAlhc3NlcnQoZGV2ICE9IE5VTEwpOwog CWFzc2VydCh0cCAhPSBOVUxMKTsKQEAgLTg0MCw4ICs4NTYsMTMgQEAgcnRsODE2OV9pbml0X29u ZShzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYwogCWRldi0+aXJxID0gcGRldi0+aXJxOwogCWRldi0+ YmFzZV9hZGRyID0gKHVuc2lnbmVkIGxvbmcpIGlvYWRkcjsKIC8vICAgICAgZGV2LT5kb19pb2N0 bCAgICAgICAgICAgPSBtaWlfaW9jdGw7CisjaWZkZWYgQ09ORklHX1I4MTY5X05BUEkKKwlkZXYt PnBvbGwgPSBydGw4MTY5X3BvbGw7CisJZGV2LT53ZWlnaHQgPSBSODE2OV9OQVBJX1dFSUdIVDsK KwlwcmludGsoS0VSTl9JTkZPICJyODE2OSBOQVBJIGVuYWJsZWRcbiIpOwogCi0JdHAgPSBkZXYt PnByaXY7CQkvLyBwcml2YXRlIGRhdGEgLy8KKwl0cC0+aW50cl9tYXNrID0gMDsKKyNlbmRpZgog CXRwLT5wY2lfZGV2ID0gcGRldjsKIAl0cC0+bW1pb19hZGRyID0gaW9hZGRyOwogCkBAIC05Njcs NyArOTg4LDcgQEAgcnRsODE2OV9pbml0X29uZShzdHJ1Y3QgcGNpX2RldiAqcGRldiwgYwogCQkJ fSBlbHNlIHsKIAkJCQl1ZGVsYXkoMTAwKTsKIAkJCX0KLQkJfQkJLy8gZW5kIGZvci1sb29wIHRv IHdhaXQgZm9yIGF1dG8tbmVnb3RpYXRpb24gcHJvY2VzcworCQl9CS8vIGVuZCBmb3ItbG9vcCB0 byB3YWl0IGZvciBhdXRvLW5lZ290aWF0aW9uIHByb2Nlc3MKIAogCX0gZWxzZSB7CiAJCXVkZWxh eSgxMDApOwpAQCAtOTc1LDcgKzk5Niw2IEBAIHJ0bDgxNjlfaW5pdF9vbmUoc3RydWN0IHBjaV9k ZXYgKnBkZXYsIGMKIAkJICAgICAgICIlczogMTAwME1icHMgRnVsbC1kdXBsZXggb3BlcmF0aW9u LCBUQkkgTGluayAlcyFcbiIsCiAJCSAgICAgICBkZXYtPm5hbWUsCiAJCSAgICAgICAoUlRMX1Iz MihUQklDU1IpICYgVEJJTGlua09LKSA/ICJPSyIgOiAiRmFpbGVkIik7Ci0KIAl9CiAKIAlyZXR1 cm4gMDsKQEAgLTExMTcsOCArMTEzNyw4IEBAIHJ0bDgxNjlfaHdfc3RhcnQoc3RydWN0IG5ldF9k ZXZpY2UgKmRldikKIAlSVExfVzE2KFJ4TWF4U2l6ZSwgUnhQYWNrZXRNYXhTaXplKTsKIAogCS8v IFNldCBSeCBDb25maWcgcmVnaXN0ZXIKLQlpID0gcnRsODE2OV9yeF9jb25maWcgfCAoUlRMX1Iz MihSeENvbmZpZykgJiBydGxfY2hpcF9pbmZvW3RwLT5jaGlwc2V0XS4KLQkJCQkgUnhDb25maWdN YXNrKTsKKwlpID0gcnRsODE2OV9yeF9jb25maWcgfCAoUlRMX1IzMihSeENvbmZpZykgJiAKKwkJ cnRsX2NoaXBfaW5mb1t0cC0+Y2hpcHNldF0uUnhDb25maWdNYXNrKTsKIAlSVExfVzMyKFJ4Q29u ZmlnLCBpKTsKIAogCS8qIFNldCBETUEgYnVyc3Qgc2l6ZSBhbmQgSW50ZXJmcmFtZSBHYXAgVGlt ZSAqLwpAQCAtMTEyOSw3ICsxMTQ5LDcgQEAgcnRsODE2OV9od19zdGFydChzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KQogCVJUTF9XMTYoQ1BsdXNDbWQsIHRwLT5jcF9jbWQpOwogCiAJaWYgKHRwLT5t YWNfdmVyc2lvbiA9PSBSVExfR0lHQV9NQUNfVkVSX0QpIHsKLQkJZHByaW50ayhLRVJOX0lORk8g UEZYICJTZXQgTUFDIFJlZyBDK0NSIE9mZnNldCAweEUwOiBiaXQtMyBhbmQgYml0LTE0IE1VU1Qg YmUgMVxuIik7CisJCWRwcmludGsoS0VSTl9JTkZPIFBGWCAiU2V0IE1BQyBSZWcgQytDUiBPZmZz ZXQgMHhFMDogYml0LTMgYW5kICIJCQkiYml0LTE0IE1VU1QgYmUgMVxuIik7CiAJCXRwLT5jcF9j bWQgfD0gKDEgPDwgMTQpIHwgUENJTXVsUlc7CiAJCVJUTF9XMTYoQ1BsdXNDbWQsIHRwLT5jcF9j bWQpOwogCX0KQEAgLTEzMDksNiArMTMyOSw3IEBAIHJ0bDgxNjlfdHhfdGltZW91dChzdHJ1Y3Qg bmV0X2RldmljZSAqZGUKIAl2b2lkICppb2FkZHIgPSB0cC0+bW1pb19hZGRyOwogCXU4IHRtcDg7 CiAKKwlwcmludGsoS0VSTl9JTkZPICIlczogVFggVGltZW91dFxuIiwgZGV2LT5uYW1lKTsKIAkv KiBkaXNhYmxlIFR4LCBpZiBub3QgYWxyZWFkeSAqLwogCXRtcDggPSBSVExfUjgoQ2hpcENtZCk7 CiAJaWYgKHRtcDggJiBDbWRUeEVuYikKQEAgLTEzODUsNyArMTQwNiw3IEBAIHN0YXRpYyB2b2lk CiBydGw4MTY5X3R4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgcnRs ODE2OV9wcml2YXRlICp0cCwKIAkJICAgICB2b2lkICppb2FkZHIpCiB7Ci0JdW5zaWduZWQgbG9u ZyBkaXJ0eV90eCwgdHhfbGVmdDsKKwl1MzIgZGlydHlfdHgsIHR4X2xlZnQ7CiAKIAlhc3NlcnQo ZGV2ICE9IE5VTEwpOwogCWFzc2VydCh0cCAhPSBOVUxMKTsKQEAgLTEzOTUsOSArMTQxNiw4IEBA IHJ0bDgxNjlfdHhfaW50ZXJydXB0KHN0cnVjdCBuZXRfZGV2aWNlICoKIAl0eF9sZWZ0ID0gdHAt PmN1cl90eCAtIGRpcnR5X3R4OwogCiAJd2hpbGUgKHR4X2xlZnQgPiAwKSB7Ci0JCWludCBlbnRy eSA9IGRpcnR5X3R4ICUgTlVNX1RYX0RFU0M7CisJCXUzMiBzdGF0dXMsIGVudHJ5ID0gZGlydHlf dHggJSBOVU1fVFhfREVTQzsKIAkJc3RydWN0IHNrX2J1ZmYgKnNrYiA9IHRwLT5UeF9za2J1ZmZb ZW50cnldOwotCQl1MzIgc3RhdHVzOwogCiAJCXJtYigpOwogCQlzdGF0dXMgPSBsZTMyX3RvX2Nw dSh0cC0+VHhEZXNjQXJyYXlbZW50cnldLnN0YXR1cyk7CkBAIC0xNDQ1LDEyICsxNDY1LDIxIEBA IHN0YXRpYyBpbmxpbmUgaW50IHJ0bDgxNjlfdHJ5X3J4X2NvcHkoc3QKIAlyZXR1cm4gcmV0Owog fQogCi1zdGF0aWMgdm9pZAorc3RhdGljIGlubGluZSB2b2lkIHJ0bDgxNjlfcnhfc2tiKHN0cnVj dCBza19idWZmICpza2IpCit7CisjaWZkZWYgQ09ORklHX1I4MTY5X05BUEkKKwluZXRpZl9yZWNl aXZlX3NrYihza2IpOwkJCQorI2Vsc2UKKwluZXRpZl9yeChza2IpOworI2VuZGlmCit9CisKK3N0 YXRpYyBpbnQgCiBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2LCBz dHJ1Y3QgcnRsODE2OV9wcml2YXRlICp0cCwKIAkJICAgICB2b2lkICppb2FkZHIpCiB7Ci0JdW5z aWduZWQgbG9uZyBjdXJfcngsIHJ4X2xlZnQ7CiAJaW50IGRlbHRhOworCXUzMiBjdXJfcngsIHJ4 X2xlZnQsIGNvdW50ID0gMDsKIAogCWFzc2VydChkZXYgIT0gTlVMTCk7CiAJYXNzZXJ0KHRwICE9 IE5VTEwpOwpAQCAtMTQ1OCwxMCArMTQ4NywxMiBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1 Y3QgbmV0X2RldmljZSAqCiAKIAljdXJfcnggPSB0cC0+Y3VyX3J4OwogCXJ4X2xlZnQgPSBOVU1f UlhfREVTQyArIHRwLT5kaXJ0eV9yeCAtIGN1cl9yeDsKKyNpZmRlZiBDT05GSUdfUjgxNjlfTkFQ SQorCXJ4X2xlZnQgPSBtaW4ocnhfbGVmdCwgKHUzMikgZGV2LT5xdW90YSk7CisjZW5kaWYKIAog CXdoaWxlIChyeF9sZWZ0ID4gMCkgewotCQlpbnQgZW50cnkgPSBjdXJfcnggJSBOVU1fUlhfREVT QzsKLQkJdTMyIHN0YXR1czsKKwkJdTMyIHN0YXR1cywgZW50cnkgPSBjdXJfcnggJSBOVU1fUlhf REVTQzsKIAogCQlybWIoKTsKIAkJc3RhdHVzID0gbGUzMl90b19jcHUodHAtPlJ4RGVzY0FycmF5 W2VudHJ5XS5zdGF0dXMpOwpAQCAtMTQ5Nyw3ICsxNTI4LDcgQEAgcnRsODE2OV9yeF9pbnRlcnJ1 cHQoc3RydWN0IG5ldF9kZXZpY2UgKgogCiAJCQlza2JfcHV0KHNrYiwgcGt0X3NpemUpOwogCQkJ c2tiLT5wcm90b2NvbCA9IGV0aF90eXBlX3RyYW5zKHNrYiwgZGV2KTsKLQkJCW5ldGlmX3J4KHNr Yik7CisJCQlydGw4MTY5X3J4X3NrYihza2IpOwogCiAJCQlkZXYtPmxhc3RfcnggPSBqaWZmaWVz OwogCQkJdHAtPnN0YXRzLnJ4X2J5dGVzICs9IHBrdF9zaXplOwpAQCAtMTUwNiwxNSArMTUzNywx NyBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAqCiAJCQogCQljdXJf cngrKzsgCiAJCXJ4X2xlZnQtLTsKKwkJY291bnQrKzsKIAl9CiAKIAl0cC0+Y3VyX3J4ID0gY3Vy X3J4OwogCiAJZGVsdGEgPSBydGw4MTY5X3J4X2ZpbGwodHAsIGRldiwgdHAtPmRpcnR5X3J4LCB0 cC0+Y3VyX3J4KTsKLQlpZiAoZGVsdGEgPiAwKQotCQl0cC0+ZGlydHlfcnggKz0gZGVsdGE7Ci0J ZWxzZSBpZiAoZGVsdGEgPCAwKQorCWlmIChkZWx0YSA8IDApIHsKIAkJcHJpbnRrKEtFUk5fSU5G TyAiJXM6IG5vIFJ4IGJ1ZmZlciBhbGxvY2F0ZWRcbiIsIGRldi0+bmFtZSk7CisJCWRlbHRhID0g MDsKKwl9CisJdHAtPmRpcnR5X3J4ICs9IGRlbHRhOwogCiAJLyoKIAkgKiBGSVhNRTogdW50aWwg dGhlcmUgaXMgcGVyaW9kaWMgdGltZXIgdG8gdHJ5IGFuZCByZWZpbGwgdGhlIHJpbmcsCkBAIC0x NTI1LDYgKzE1NTgsOCBAQCBydGw4MTY5X3J4X2ludGVycnVwdChzdHJ1Y3QgbmV0X2RldmljZSAq CiAJICovCiAJaWYgKHRwLT5kaXJ0eV9yeCArIE5VTV9SWF9ERVNDID09IHRwLT5jdXJfcngpCiAJ CXByaW50ayhLRVJOX0VNRVJHICIlczogUnggYnVmZmVycyBleGhhdXN0ZWRcbiIsIGRldi0+bmFt ZSk7CisKKwlyZXR1cm4gY291bnQ7CiB9CiAKIC8qIFRoZSBpbnRlcnJ1cHQgaGFuZGxlciBkb2Vz IGFsbCBvZiB0aGUgUnggdGhyZWFkIHdvcmsgYW5kIGNsZWFucyB1cCBhZnRlciB0aGUgVHggdGhy ZWFkLiAqLwpAQCAtMTU1MCwxNSArMTU4NSwzOCBAQCBydGw4MTY5X2ludGVycnVwdChpbnQgaXJx LCB2b2lkICpkZXZfaW5zCiAJCWlmIChzdGF0dXMgJiBSeFVuZGVycnVuKQogCQkJbGlua19jaGFu Z2VkID0gUlRMX1IxNiAoQ1NDUikgJiBDU0NSX0xpbmtDaGFuZ2VCaXQ7CiAqLworI2lmZGVmIENP TkZJR19SODE2OV9OQVBJCisJCXN0YXR1cyAmPSB+dHAtPmludHJfbWFzazsKKyNlbmRpZgogCQlS VExfVzE2KEludHJTdGF0dXMsCiAJCQkoc3RhdHVzICYgUnhGSUZPT3ZlcikgPyAoc3RhdHVzIHwg UnhPdmVyZmxvdykgOiBzdGF0dXMpOwotCisJCQogCQlpZiAoIShzdGF0dXMgJiBydGw4MTY5X2lu dHJfbWFzaykpCiAJCQlicmVhazsKIAorI2lmZGVmIENPTkZJR19SODE2OV9OQVBJCisJCWlmIChu ZXRpZl9yeF9zY2hlZHVsZV9wcmVwKGRldikpIHsKKwkJCVJUTF9XMTYoSW50ck1hc2ssIHJ0bDgx NjlfaW50cl9tYXNrIHwgCisJCQkJfihSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBS eEZJRk9PdmVyIHwKKwkJCQlUeE9LIHwgVHhFcnIpKTsKKwkJCXRwLT5pbnRyX21hc2sgPSBUeE9L IHwgVHhFcnIgfCAKKwkJCQlSeE9LIHwgUnhVbmRlcnJ1biB8IFJ4T3ZlcmZsb3cgfCBSeEZJRk9P dmVyOworCQkJX19uZXRpZl9yeF9zY2hlZHVsZShkZXYpOworCQl9IGVsc2UgeworCQkJcHJpbnRr KEtFUk5fSU5GTyAiJXM6IGludGVycnVwdCAleCB0YWtlbiBpbiBwb2xsXG4iLCAKKwkJCQlkZXYt Pm5hbWUsIHN0YXR1cyk7CQorCQkJUlRMX1cxNihJbnRyTWFzaywgcnRsODE2OV9pbnRyX21hc2sg fCAKKwkJCQl+KFJ4T0sgfCBSeFVuZGVycnVuIHwgUnhPdmVyZmxvdyB8IFJ4RklGT092ZXIgfAor CQkJCVR4T0sgfCBUeEVycikpOworCQkJdHAtPmludHJfbWFzayA9IFR4T0sgfCBUeEVyciB8IAor CQkJCVJ4T0sgfCBSeFVuZGVycnVuIHwgUnhPdmVyZmxvdyB8IFJ4RklGT092ZXI7CisJCX0KKwkJ YnJlYWs7CisjZWxzZQogCQkvLyBSeCBpbnRlcnJ1cHQgCiAJCWlmIChzdGF0dXMgJiAoUnhPSyB8 IFJ4VW5kZXJydW4gfCBSeE92ZXJmbG93IHwgUnhGSUZPT3ZlcikpIHsKIAkJCXJ0bDgxNjlfcnhf aW50ZXJydXB0KGRldiwgdHAsIGlvYWRkcik7CisKIAkJfQogCQkvLyBUeCBpbnRlcnJ1cHQKIAkJ aWYgKHN0YXR1cyAmIChUeE9LIHwgVHhFcnIpKSB7CkBAIC0xNTY3LDYgKzE2MjUsNyBAQCBydGw4 MTY5X2ludGVycnVwdChpbnQgaXJxLCB2b2lkICpkZXZfaW5zCiAJCQlzcGluX3VubG9jaygmdHAt PmxvY2spOwogCQl9CiAKKyNlbmRpZgogCQlib2d1c2NudC0tOwogCX0gd2hpbGUgKGJvZ3VzY250 ID4gMCk7CiAKQEAgLTE2OTIsNiArMTc1MSwzMCBAQCBzdGF0aWMgc3RydWN0IG5ldF9kZXZpY2Vf c3RhdHMgKnJ0bDgxNjlfCiAJcmV0dXJuICZ0cC0+c3RhdHM7CiB9CiAKKyNpZmRlZiBDT05GSUdf UjgxNjlfTkFQSQorc3RhdGljIGludCBydGw4MTY5X3BvbGwoc3RydWN0IG5ldF9kZXZpY2UgKmRl diwgaW50ICpidWRnZXQpCit7CisJdTMyIHdvcmtfZG9uZSA9IDAsIHdvcmtfdG9fZG8gPSBtaW4o KmJ1ZGdldCwgZGV2LT5xdW90YSk7CisJc3RydWN0IHJ0bDgxNjlfcHJpdmF0ZSAqdHAgPSBkZXYt PnByaXY7CisJdm9pZCAqaW9hZGRyID0gdHAtPm1taW9fYWRkcjsKKwkKKwl3b3JrX2RvbmUgPSBy dGw4MTY5X3J4X2ludGVycnVwdChkZXYsIHRwLCBpb2FkZHIpOworCXJ0bDgxNjlfdHhfaW50ZXJy dXB0KGRldiwgdHAsIGlvYWRkcik7CisJCisJKmJ1ZGdldCAtPSB3b3JrX2RvbmU7CisJZGV2LT5x dW90YSAtPSB3b3JrX2RvbmU7CisJCisJaWYgKCh3b3JrX2RvbmUgPCB3b3JrX3RvX2RvKSB8fCAh bmV0aWZfcnVubmluZyhkZXYpKSB7CisJCW5ldGlmX3J4X2NvbXBsZXRlKGRldik7CisJCXRwLT5p bnRyX21hc2sgPSAwOworCQlSVExfVzE2KEludHJNYXNrLCBydGw4MTY5X2ludHJfbWFzayk7CisJ CVJUTF9SMTYoSW50ck1hc2spOworCX0KKworCXJldHVybiAod29ya19kb25lID49IHdvcmtfdG9f ZG8pOworfQorI2VuZGlmCisKIHN0YXRpYyBzdHJ1Y3QgcGNpX2RyaXZlciBydGw4MTY5X3BjaV9k cml2ZXIgPSB7CiAJLm5hbWUJCT0gTU9EVUxFTkFNRSwKIAkuaWRfdGFibGUJPSBydGw4MTY5X3Bj aV90YmwsCg== --=_mixed 006D687686256E80_= Content-Type: application/octet-stream; name="Kconfig.diff" Content-Disposition: attachment; filename="Kconfig.diff" Content-Transfer-Encoding: base64 LS0tIEtjb25maWcub3JpZwkyMDA0LTA0LTIwIDEwOjMxOjE4LjY1MzQzMTkyMCAtMDUwMAorKysg S2NvbmZpZwkyMDA0LTA0LTIwIDEwOjMwOjA0Ljg4MTY0NjkzNiAtMDUwMApAQCAtMTk2Miw2ICsx OTYyLDEwIEBAIGNvbmZpZyBSODE2OQogCSAgVG8gY29tcGlsZSB0aGlzIGRyaXZlciBhcyBhIG1v ZHVsZSwgY2hvb3NlIE0gaGVyZTogdGhlIG1vZHVsZQogCSAgd2lsbCBiZSBjYWxsZWQgcjgxNjku ICBUaGlzIGlzIHJlY29tbWVuZGVkLgogCitjb25maWcgUjgxNjlfTkFQSQorCWJvb2wgIlVzZSBS eCBQb2xsaW5nIChOQVBJKSAoRVhQRVJJTUVOVEFMKSIKKwlkZXBlbmRzIG9uIFI4MTY5ICYmIEVY UEVSSU1FTlRBTCAKKwkKIGNvbmZpZyBTSzk4TElOCiAJdHJpc3RhdGUgIk1hcnZlbGwgWXVrb24g Q2hpcHNldCAvIFN5c0tvbm5lY3QgU0stOTh4eCBTdXBwb3J0IgogCWRlcGVuZHMgb24gUENJCg== --=_mixed 006D687686256E80_=-- From luto@myrealbox.com Sat Apr 24 13:03:10 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 13:03:15 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OK37KO031833; Sat, 24 Apr 2004 13:03:10 -0700 Received: from myrealbox.com (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3OK2xXT012939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Apr 2004 13:02:59 -0700 Message-ID: <408AC7DC.8060204@myrealbox.com> Date: Sat, 24 Apr 2004 13:02:36 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon D Mason CC: jgarzik@pobox.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Francois Romieu Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4906 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Content-Length: 1728 Lines: 39 Jon D Mason wrote: >>BTW, what was it there for in the first place? I can get gigabit to >>fail to negotiate, but I always pick up a 100Mbps/full duplex link when >>that happens. I've never seen a complete absense of link. I left the >>original semantics around because I assumed there was a reason, but if >>it's unnecessary, then the timer should only need to fire once during >>the lifetime of the device (and the assorted bookkeeping can go away). > > > I have an 8110S version of the chipset, and I don't have any problems with > it getting an improper link speed form the outset. Though, I am running > point-to-point with an e1000 adapter. Are you running this through a > switch? The 8001S was a typo -- mine is 8110S point-to-point with an e1000 on Windows. Strangely enough, I can't reproduce the problem today. It happened about 80% of the time yesterday, though. I don't think I changed anything. Maybe my cable's bad. In any case, if I'm the only one with this problem, and no one knows what the original purpose of the timer was, I'm ok with removing it entirely. I can work around this issue in userspace easily enough. > > BTW, good work doing the link changes. Though it might be beneficial to > do a "printk(KERN_INFO "%s: Link Down\n", dev->name);" in the interrupt > handler to show that the link is down in the dmesg (and a Link Up message > too). > I left it out b/c natsemi does it and it always annoys me ;) Is there a userspace tool for linkwatch? In any case, what's the preferred approach? natsemi notifies, tulip doesn't, and, IIRC, e1000 and tg3 don't. If the consensus is to notify, shouldn't it be done in netif_carrier_on and netif_carrier_off? --Andy From romieu@fr.zoreil.com Sat Apr 24 13:16:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 13:16:59 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OKGqKO032363 for ; Sat, 24 Apr 2004 13:16:55 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3OJDeuX029633; Sat, 24 Apr 2004 21:13:40 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3OJDd6t029632; Sat, 24 Apr 2004 21:13:39 +0200 Date: Sat, 24 Apr 2004 21:13:39 +0200 From: Francois Romieu To: Jon D Mason Cc: Andy Lutomirski , jgarzik@pobox.com, Andy Lutomirski , netdev@oss.sgi.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection Message-ID: <20040424211339.A29355@electric-eye.fr.zoreil.com> References: <408A8252.5040006@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jonmason@us.ibm.com on Sat, Apr 24, 2004 at 02:44:59PM -0500 X-Organisation: Land of Sunshine Inc. X-archive-position: 4907 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Content-Length: 288 Lines: 10 Jon D Mason : [...] > Looks like a fair amount of work to convert 8139cp to r8169. Let me know > if you need any help. Actually it is meant to be done in the opposite direction so as to avoid to duplicate most of the 8139cp driver in the r8169 driver. -- Ueimor From jonmason@us.ibm.com Sat Apr 24 13:19:58 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 13:20:01 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OKJ0KQ032676 for ; Sat, 24 Apr 2004 13:19:57 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3OKIlpj427804; Sat, 24 Apr 2004 16:18:48 -0400 Received: from d03nm130.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3OKIkOE210456; Sat, 24 Apr 2004 14:18:47 -0600 In-Reply-To: <408AC7DC.8060204@myrealbox.com> To: Andy Lutomirski Cc: jgarzik@pobox.com, netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, Francois Romieu MIME-Version: 1.0 Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Sat, 24 Apr 2004 15:18:45 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/24/2004 14:18:47, Serialize complete at 04/24/2004 14:18:47 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4908 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1210 Lines: 26 >The 8001S was a typo -- mine is 8110S point-to-point with an e1000 on >Windows. Strangely enough, I can't reproduce the problem today. It >happened about 80% of the time yesterday, though. I don't think I >changed anything. Maybe my cable's bad. > >In any case, if I'm the only one with this problem, and no one knows >what the original purpose of the timer was, I'm ok with removing it >entirely. I can work around this issue in userspace easily enough. Your setup sounds similar to mine, though my test machine is running gentoo. Anyway, I'll verify the speed settings it when I get home. >I left it out b/c natsemi does it and it always annoys me ;) Is there a >userspace tool for linkwatch? > >In any case, what's the preferred approach? natsemi notifies, tulip >doesn't, and, IIRC, e1000 and tg3 don't. If the consensus is to notify, >shouldn't it be done in netif_carrier_on and netif_carrier_off? I just checked e1000, and it does log the link status in the dmesg (line 1410 or so of e1000_main.c in the e1000_watchdog function). It also does the netif_carrier_on/off there too. If that is too much work in the interrupt handler, we can always do it via a timer. Thanks, Jon From sree_prash@yahoo.com Sat Apr 24 13:33:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 13:33:12 -0700 (PDT) Received: from web60208.mail.yahoo.com (web60208.mail.yahoo.com [216.109.118.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OKX7KO000765 for ; Sat, 24 Apr 2004 13:33:08 -0700 Message-ID: <20040424203301.76624.qmail@web60208.mail.yahoo.com> Received: from [66.218.69.220] by web60208.mail.yahoo.com via HTTP; Sat, 24 Apr 2004 13:33:01 PDT Date: Sat, 24 Apr 2004 13:33:01 -0700 (PDT) From: prashant s Subject: help on NAPI To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4909 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sree_prash@yahoo.com Precedence: bulk X-list: netdev Content-Length: 751 Lines: 24 sir, i have a doubt regarding the NAPI feature which is introduced in 2.6.3 linux. i did not find any performance difference between the NAPI driver (rtl 8139too 2.6.3 linux) and non NAPI driver(rtl 8139too 2.4.20 linux) both of them showed 94Mbps(packet size of 1500bytes). The network card which i used was a 100Mbps real tek card, and the machine was a p 4. but when i reduced the DMA receive ring size from 32K to 8k the NAPI driver showed 94Mbps where as the non NAPI driver showed 72Mbps. why is this performance difference when the ring size is reduced. waiting for your reply. prashant __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From jonmason@us.ibm.com Sat Apr 24 14:00:15 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 14:00:21 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OL08KO001395; Sat, 24 Apr 2004 14:00:15 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3OL00pj394418; Sat, 24 Apr 2004 17:00:00 -0400 Received: from d03nm130.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3OKxxOE200626; Sat, 24 Apr 2004 15:00:00 -0600 In-Reply-To: <20040424203301.76624.qmail@web60208.mail.yahoo.com> To: prashant s Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com MIME-Version: 1.0 Subject: Re: help on NAPI X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Sat, 24 Apr 2004 15:59:57 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/24/2004 15:00:00, Serialize complete at 04/24/2004 15:00:00 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3OL08KO001395 X-archive-position: 4910 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 1727 Lines: 60 Prashant, NAPI performance gain is only when then packets are small in size. Without NAPI, the number of interrupts per packet is high with small packets. This is mitigated by the polling functionality of NAPI, which handles the packets without (err...relatively few) have to take interrupts. It is better explained at "http://lxr.linux.no/source/Documentation/networking/NAPI_HOWTO.txt?v=2.6.5" With regard to better performance when using smaller ring sizes, this can be attributed to a knock-on effect of cache aligning the buffers. This occurs on all adapters, and the optimal descriptor ring size differs depending on your hardware. Thanks, Jon Mason jonmason@us.ibm.com Software Engineer Phone:(512)838.4162 Linux eServer I/O Fax: (512)838.3509 prashant s Sent by: netdev-bounce@oss.sgi.com 04/24/04 03:33 PM To: netdev@oss.sgi.com cc: Subject: help on NAPI sir, i have a doubt regarding the NAPI feature which is introduced in 2.6.3 linux. i did not find any performance difference between the NAPI driver (rtl 8139too 2.6.3 linux) and non NAPI driver(rtl 8139too 2.4.20 linux) both of them showed 94Mbps(packet size of 1500bytes). The network card which i used was a 100Mbps real tek card, and the machine was a p 4. but when i reduced the DMA receive ring size from 32K to 8k the NAPI driver showed 94Mbps where as the non NAPI driver showed 72Mbps. why is this performance difference when the ring size is reduced. waiting for your reply. prashant __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From gdh@binhex.EU.org Sat Apr 24 15:23:54 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 15:24:01 -0700 (PDT) Received: from binhex.EU.org (BOFH.binhex.EU.org [212.30.223.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OMNqKO002682 for ; Sat, 24 Apr 2004 15:23:53 -0700 Received: from yztiklettur.binhex.EU.org (yztiklettur.binhex.EU.org [IPv6:3ffe:b80:527:1:204:75ff:fe80:bb17]) by binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9) with ESMTP id i3OMNgEc012942; Sat, 24 Apr 2004 22:23:42 GMT Received: from yztiklettur.binhex.EU.org (localhost [127.0.0.1]) by yztiklettur.binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9) with ESMTP id i3OMNfdI010725; Sat, 24 Apr 2004 22:23:41 GMT Received: (from gdh@localhost) by yztiklettur.binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9/) id i3OMNfaD010724; Sat, 24 Apr 2004 22:23:41 GMT Date: Sat, 24 Apr 2004 22:23:41 +0000 From: =?iso-8859-1?Q?Gu=F0mundur_D=2E?= Haraldsson To: netdev@oss.sgi.com Cc: gdh@binhex.EU.org Subject: IPv6 kernel ooops Message-ID: <20040424222340.GA10595@binhex.EU.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Organization: binhex.EU.org X-To-Spammer: You spam me and you will get an anal probe. X-archive-position: 4911 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gdh@binhex.EU.org Precedence: bulk X-list: netdev Content-Length: 7001 Lines: 199 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi I got this oops on my machine tonight. I don't know what query to BIND caused it, but I've got an oops like this b= efore! [root@binhex gdh]# ksymoops -k /proc/ksyms -l /proc/modules -o /lib/module= s/2.4.22-1.2174.nptl/ -m /boot/System.map-2.4.22-1.2174.nptl < blah ksymoops 2.4.5 on i586 2.4.22-1.2174.nptl. Options used -V (default) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.22-1.2174.nptl/ (specified) -m /boot/System.map-2.4.22-1.2174.nptl (specified) Unable to handle kernel NULL pointer dereference at virtual address 0000000c c68d4fd5 *pde =3D 034ff067 Oops: 0000 CPU: 0 EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000000 ebx: c26271a0 ecx: c5e97bbc edx: 0000a7eb esi: 00000000 edi: c39d9d94 ebp: 091dc910 esp: c39d9d04 ds: 0068 es: 0068 ss: 0068 Process named (pid: 19424, stackpage=3Dc39d9000) Stack: c26271a0 0000a7eb c02112f0 00000000 c5e97bbc 00000000 c3b2f220 00000= 000=20 c03e2458 c39d9dc4 00000064 00000000 c39d9d94 c5e97b00 c68e2df1 c5e97= b00=20 c68e2a90 c39d9db4 c39d9d94 0000006c 00000000 ffffffff 00000040 c39d9= efc=20 Call Trace: [] output_maybe_reroute [kernel] 0x0 (0xc39d9d0c) [] udpv6_sendmsg [ipv6] 0x271 (0xc39d9d3c) [] udpv6_getfrag [ipv6] 0x0 (0xc39d9d44) [] udp_recvmsg [kernel] 0x5c (0xc39d9dcc) [] inet_sendmsg [kernel] 0x33 (0xc39d9e04) [] sock_sendmsg [kernel] 0x5d (0xc39d9e18) [] sys_sendmsg [kernel] 0x196 (0xc39d9e5c) [] setup_frame [kernel] 0x111 (0xc39d9eb0) [] handle_signal [kernel] 0xbd (0xc39d9edc) [] recalc_task_prio [kernel] 0xa0 (0xc39d9eec) [] __wake_up [kernel] 0x4b (0xc39d9f40) [] pipe_write [kernel] 0x178 (0xc39d9f68) [] sys_socketcall [kernel] 0x18c (0xc39d9f8c) [] system_call [kernel] 0x33 (0xc39d9fc0) Code: ff 50 0c 5e 85 c0 5f 0f 85 54 fa ff ff 8b 54 24 34 31 ed c7=20 >>EIP; c68d4fd5 <[ipv6]ip6_build_xmit+625/650> <=3D=3D=3D=3D=3D >>ebx; c26271a0 <_end+22418a8/6427768> >>ecx; c5e97bbc <_end+5ab22c4/6427768> >>edx; 0000a7eb Before first symbol >>edi; c39d9d94 <_end+35f449c/6427768> >>ebp; 091dc910 Before first symbol >>esp; c39d9d04 <_end+35f440c/6427768> Trace; c02112f0 Trace; c68e2df1 <[ipv6]udpv6_sendmsg+271/480> Trace; c68e2a90 <[ipv6]udpv6_getfrag+0/f0> Trace; c022bacc Trace; c0231e83 Trace; c01f195d Trace; c01f2b36 Trace; c0108d41 Trace; c01091cd Trace; c0116fb0 Trace; c0117e4b <__wake_up+4b/60> Trace; c0148098 Trace; c01f2f6c Trace; c01093a3 Code; c68d4fd5 <[ipv6]ip6_build_xmit+625/650> 00000000 <_EIP>: Code; c68d4fd5 <[ipv6]ip6_build_xmit+625/650> <=3D=3D=3D=3D=3D 0: ff 50 0c call *0xc(%eax) <=3D=3D=3D=3D=3D Code; c68d4fd8 <[ipv6]ip6_build_xmit+628/650> 3: 5e pop %esi Code; c68d4fd9 <[ipv6]ip6_build_xmit+629/650> 4: 85 c0 test %eax,%eax Code; c68d4fdb <[ipv6]ip6_build_xmit+62b/650> 6: 5f pop %edi Code; c68d4fdc <[ipv6]ip6_build_xmit+62c/650> 7: 0f 85 54 fa ff ff jne fffffa61 <_EIP+0xfffffa61> Code; c68d4fe2 <[ipv6]ip6_build_xmit+632/650> d: 8b 54 24 34 mov 0x34(%esp,1),%edx Code; c68d4fe6 <[ipv6]ip6_build_xmit+636/650> 11: 31 ed xor %ebp,%ebp Code; c68d4fe8 <[ipv6]ip6_build_xmit+638/650> 13: c7 00 00 00 00 00 movl $0x0,(%eax) Machine/OS info: Linux binhex.EU.org 2.4.22-1.2174.nptl #1 Wed Feb 18 14:02:36 EST 2004 i586= i586 i386 GNU/Linux =20 Gnu C 3.3.2 Gnu make 3.79.1 util-linux 2.11y mount 2.11y modutils 2.4.25 e2fsprogs 1.34 reiserfsprogs 3.6.8 quota-tools 3.06. PPP 2.4.1 isdn4k-utils 3.3 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 2.0.17 Net-tools 1.60 Kbd 1.08 Sh-utils 5.0 Modules Loaded nls_iso8859-1 autofs 3c59x ipv6 ipt_REJECT iptable_f= ilter ip_tables ext3 jbd loop lvm-mod processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 350.805 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow k6_mtrr bogomips : 699.59 nls_iso8859-1 3484 12 (autoclean) autofs 11156 0 (autoclean) (unused) 3c59x 29360 1 ipv6 173076 -1 ipt_REJECT 3960 19 (autoclean) iptable_filter 2348 1 (autoclean) ip_tables 14656 2 [ipt_REJECT iptable_filter] ext3 65508 3 (autoclean) jbd 47596 3 (autoclean) [ext3] loop 10808 36 (autoclean) lvm-mod 63552 0 Please CC to me, since I'm not on the list. Best regards,=20 Gu=F0mundur. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D | Gu=F0mundur D. Haraldsson | When you have eliminated the im= possible,| | gdh@binhex.EU.org | what ever remains, however improb= able, | | http://www.binhex.EU.org/ | must be the truth. | | | - Sherlock Holmes, "The sign of f= our" | |--------------------------------------------------------------------------= -------| | GPG key: lynx -dump http://vlug.eyjar.is/gdh/gpgkey.asc | gpg --import = | | Key fingerprint =3D DE6D A875 EA92 0699 9B49 8C49 2DBB 76BF ADD4 C933 = | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D // Spammers will be asphyxiated in pat=E9! --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAiujsLbt2v63UyTMRAq6tAKCjaLnY3FiGxbiwnFSLb7jDrg524ACePu3l KEKuaSADPEZ44ftcZ7ZQ7qw= =MYo1 -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From yoshfuji@wide.ad.jp Sat Apr 24 18:42:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 18:42:26 -0700 (PDT) Received: from yue.hongo.wide.ad.jp ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3P1gHKO004552 for ; Sat, 24 Apr 2004 18:42:20 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id 5771033CE5; Sun, 25 Apr 2004 10:42:18 +0900 (JST) Date: Sun, 25 Apr 2004 10:42:17 +0900 (JST) Message-Id: <20040425.104217.31070133.yoshfuji@wide.ad.jp> To: gdh@binhex.EU.org Cc: netdev@oss.sgi.com Subject: Re: IPv6 kernel ooops From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040424222340.GA10595@binhex.EU.org> References: <20040424222340.GA10595@binhex.EU.org> X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3P1gHKO004552 X-archive-position: 4912 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@wide.ad.jp Precedence: bulk X-list: netdev Content-Length: 744 Lines: 23 In article <20040424222340.GA10595@binhex.EU.org> (at Sat, 24 Apr 2004 22:23:41 +0000), Guðmundur D. Haraldsson says: > I got this oops on my machine tonight. > > I don't know what query to BIND caused it, but I've got an oops like this before! Is this reproducable? How frequently do you see this? > Call Trace: [] output_maybe_reroute [kernel] 0x0 (0xc39d9d0c) (Umm, I cannot find "output_maybe_reroute" in my source...) > [] udpv6_sendmsg [ipv6] 0x271 (0xc39d9d3c) > [] udpv6_getfrag [ipv6] 0x0 (0xc39d9d44) : Would you test latest rc (or bk tree), please? -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From yoshfuji@linux-ipv6.org Sat Apr 24 18:54:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 18:54:15 -0700 (PDT) Received: from yue.hongo.wide.ad.jp ([203.178.140.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3P1sAKO004950 for ; Sat, 24 Apr 2004 18:54:11 -0700 Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (Postfix) with ESMTP id AA9F433CE5; Sun, 25 Apr 2004 10:54:11 +0900 (JST) Date: Sun, 25 Apr 2004 10:54:11 +0900 (JST) Message-Id: <20040425.105411.127614608.yoshfuji@linux-ipv6.org> To: gdh@binhex.EU.org Cc: netdev@oss.sgi.com Subject: Re: IPv6 kernel ooops From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= In-Reply-To: <20040425.104217.31070133.yoshfuji@wide.ad.jp> References: <20040424222340.GA10595@binhex.EU.org> <20040425.104217.31070133.yoshfuji@wide.ad.jp> Organization: USAGI Project X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc X-Face: "5$Al-.M>NJ%a'@hhZdQm:."qn~PA^gq4o*>iCFToq*bAi#4FRtx}enhuQKz7fNqQz\BYU] $~O_5m-9'}MIs`XGwIEscw;e5b>n"B_?j/AkL~i/MEaZBLP X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.1 (AOI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id i3P1sAKO004950 X-archive-position: 4913 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: yoshfuji@linux-ipv6.org Precedence: bulk X-list: netdev Content-Length: 708 Lines: 18 In article <20040425.104217.31070133.yoshfuji@wide.ad.jp> (at Sun, 25 Apr 2004 10:42:17 +0900 (JST)), YOSHIFUJI Hideaki / å‰è—¤è‹±æ˜Ž says: > In article <20040424222340.GA10595@binhex.EU.org> (at Sat, 24 Apr 2004 22:23:41 +0000), Guðmundur D. Haraldsson says: > > > I got this oops on my machine tonight. > > > > I don't know what query to BIND caused it, but I've got an oops like this before! > > Is this reproducable? How frequently do you see this? Oh, sorry, I looked into 2.6.x. I've found it at net/ipv4/ip_output.c in 2.4.x. I haven't seen that oops before, as far as I can recall. Please try latest vanilla kernel (2.4.26 or so). Thanks. --yoshfuji From gdh@binhex.EU.org Sat Apr 24 19:14:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 19:14:55 -0700 (PDT) Received: from binhex.EU.org (BOFH.binhex.EU.org [212.30.223.106]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3P2EmKO005556 for ; Sat, 24 Apr 2004 19:14:51 -0700 Received: from yztiklettur.binhex.EU.org (yztiklettur.binhex.EU.org [IPv6:3ffe:b80:527:1:204:75ff:fe80:bb17]) by binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9) with ESMTP id i3P2EeEc015835; Sun, 25 Apr 2004 02:14:40 GMT Received: from yztiklettur.binhex.EU.org (localhost [127.0.0.1]) by yztiklettur.binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9) with ESMTP id i3P2E8dI012101; Sun, 25 Apr 2004 02:14:08 GMT Received: (from gdh@localhost) by yztiklettur.binhex.EU.org (8.12.9-20030918-gdh-p1/8.12.9/) id i3P2E8wv012100; Sun, 25 Apr 2004 02:14:08 GMT Date: Sun, 25 Apr 2004 02:14:07 +0000 From: =?iso-8859-1?Q?Gu=F0mundur_D=2E?= Haraldsson To: "YOSHIFUJI Hideaki / ?$B5HF#1QL@" Cc: netdev@oss.sgi.com Subject: Re: IPv6 kernel ooops Message-ID: <20040425021407.GA11856@binhex.EU.org> References: <20040424222340.GA10595@binhex.EU.org> <20040425.104217.31070133.yoshfuji@wide.ad.jp> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20040425.104217.31070133.yoshfuji@wide.ad.jp> User-Agent: Mutt/1.4.1i X-Organization: binhex.EU.org X-To-Spammer: You spam me and you will get an anal probe. X-archive-position: 4914 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: gdh@binhex.EU.org Precedence: bulk X-list: netdev Content-Length: 2527 Lines: 79 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable -*- YOSHIFUJI Hideaki / ?$B5HF#1QL@ [ 2004-04-25 01:4= 3 ]: > In article <20040424222340.GA10595@binhex.EU.org> (at Sat, 24 Apr 2004 22= :23:41 +0000), Gu=F0mundur D. Haraldsson says: >=20 > > I got this oops on my machine tonight. > > > > I don't know what query to BIND caused it, but I've got an oops like th= is before! >=20 > Is this reproducable? How frequently do you see this? I belive this is hard to reproduce, I had this once some months ago. >=20 >=20 > > Call Trace: [] output_maybe_reroute [kernel] 0x0 (0xc39d9d0= c) >=20 > (Umm, I cannot find "output_maybe_reroute" in my source...) >=20 > > [] udpv6_sendmsg [ipv6] 0x271 (0xc39d9d3c) > > [] udpv6_getfrag [ipv6] 0x0 (0xc39d9d44) > : Dunno... it's a RedHat kernel... some patch maybe? >=20 > Would you test latest rc (or bk tree), please? Well... I need a test-case first... Best regards, -Gudmundur. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D | Gu=F0mundur D. Haraldsson | When you have eliminated the im= possible,| | gdh@binhex.EU.org | what ever remains, however improb= able, | | http://www.binhex.EU.org/ | must be the truth. | | | - Sherlock Holmes, "The sign of f= our" | |--------------------------------------------------------------------------= -------| | GPG key: lynx -dump http://vlug.eyjar.is/gdh/gpgkey.asc | gpg --import = | | Key fingerprint =3D DE6D A875 EA92 0699 9B49 8C49 2DBB 76BF ADD4 C933 = | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D // Spammers will be asphyxiated in pat=E9! --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAix7vLbt2v63UyTMRAl4mAJ9b4XWLsgnu6ZLrbtA92UMd1Nm7wQCfbtM4 ZmKdhWCpkQa8qtSmkPt1DiI= =14db -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From jgarzik@pobox.com Sat Apr 24 19:22:04 2004 Received: with ECARTIS (v1.0.0; list netdev); Sat, 24 Apr 2004 19:22:07 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3P2LxKO005912 for ; Sat, 24 Apr 2004 19:22:03 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BHZHJ-0000Ik-KW; Sun, 25 Apr 2004 03:21:57 +0100 Message-ID: <408B20BA.7020009@pobox.com> Date: Sat, 24 Apr 2004 22:21:46 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Feldman CC: netdev@oss.sgi.com Subject: Re: [e100 2.5] ICH 10/H Tx hang fix References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4915 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Content-Length: 17 Lines: 2 applied, thanks From geert@linux-m68k.org Sun Apr 25 03:19:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 03:19:20 -0700 (PDT) Received: from witte.sonytel.be (witte.sonytel.be [80.88.33.193]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3PAJFKO021071 for ; Sun, 25 Apr 2004 03:19:16 -0700 Received: from waterleaf.sonytel.be (localhost [127.0.0.1]) by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i3PAJBJc028177; Sun, 25 Apr 2004 12:19:11 +0200 (MEST) Date: Sun, 25 Apr 2004 12:19:11 +0200 (MEST) From: Geert Uytterhoeven To: "David S. Miller" cc: Marcelo Tosatti , netdev@oss.sgi.com, Linux Kernel Development , linux-net@vger.kernel.org Subject: Re: [PATCH] pktgen dependency (was: Re: Linux 2.4.27-pre1) In-Reply-To: <20040423163938.013f362f.davem@redhat.com> Message-ID: References: <20040422130651.GB18358@logos.cnet> <20040423163938.013f362f.davem@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4916 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: geert@linux-m68k.org Precedence: bulk X-list: netdev Content-Length: 789 Lines: 26 On Fri, 23 Apr 2004, David S. Miller wrote: > On Fri, 23 Apr 2004 16:58:58 +0200 (MEST) > Geert Uytterhoeven wrote: > > > The packet generator doesn't compile if procfs is disabled. > > IIRC, there was an agreement that this dependency is needed: > > Applied, thanks Geert. Can you cook up a 2.6.x variant as well > if that is needed too? 2.6.6-rc2 already has config NET_PKTGEN tristate "Packet Generator (USE WITH CAUTION)" depends on PROC_FS Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From anton@ozlabs.org Sun Apr 25 09:27:53 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 09:27:58 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3PGRgKO006163 for ; Sun, 25 Apr 2004 09:27:42 -0700 Received: by ozlabs.org (Postfix, from userid 1010) id B59942BE83; Mon, 26 Apr 2004 02:00:22 +1000 (EST) Date: Sun, 25 Apr 2004 11:17:06 +1000 From: Anton Blanchard To: netdev@oss.sgi.com Cc: ja@ssi.bg Subject: [cryptic-lkml@bloodletting.com: Re: Testing Dual Ethernet via Loopback] Message-ID: <20040425011706.GD20714@krispykreme> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 4918 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: anton@samba.org Precedence: bulk X-list: netdev Content-Length: 1050 Lines: 30 Hi, We have found Julian Anastasov's send-to-self patch extremely useful in the lab. There seem to be a number of other people who agree, what are the chances of getting it merged into 2.6? Ive got a version rediffed against recent BK if required. Anton ----- Forwarded message from Nick Popoff ----- From: Nick Popoff To: Anton Blanchard , linux-kernel@vger.kernel.org Subject: Re: Testing Dual Ethernet via Loopback On Fri, 23 Apr 2004, Anton Blanchard wrote: > Sounds like you need the send-to-self patch: > http://www.ssi.bg/~ja/ > We've been using it a lot in the lab, it works well. I tried this out yesterday with Linux 2.6.5 at it worked like a charm. Thank you to everyone who replied with solutions and to the author of this patch! I thought the idea of pinging an invalid IP from one interface while snooping with ethereal on the other interface was very clever, but hard to use for performance testing. :-) ----- End forwarded message ----- From jonmason@us.ibm.com Sun Apr 25 14:10:13 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 14:10:18 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3PL9lKQ014171 for ; Sun, 25 Apr 2004 14:10:13 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3PL9WnU479394; Sun, 25 Apr 2004 17:09:32 -0400 Received: from d03nm130.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3PL9VIK178582; Sun, 25 Apr 2004 15:09:32 -0600 In-Reply-To: <20040424050931.14C341D4F@luto.stanford.edu> To: Andy Lutomirski Cc: netdev@oss.sgi.com, netdev-bounce@oss.sgi.com, romieu@fr.zoreil.com, jgarzik@pobox.com MIME-Version: 1.0 Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection X-Mailer: Lotus Notes Build V651_12042003 December 04, 2003 Message-ID: From: Jon D Mason Date: Sun, 25 Apr 2004 16:09:30 -0500 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.0.2CF2HF168 | December 5, 2003) at 04/25/2004 15:09:32, Serialize complete at 04/25/2004 15:09:32 Content-Type: text/plain; charset="US-ASCII" X-archive-position: 4919 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jonmason@us.ibm.com Precedence: bulk X-list: netdev Content-Length: 353 Lines: 10 Hey Andy, I hand patched my driver (which is probably my mistake), and I noticed a great increase in bring-up time. Good job! I noticed that the new driver never logs my speed in the dmesg (like the old driver did). I could use ethtool, but I'm all about backwards compatibility. So, it might be a good idea to have it in there too. Thanks, Jon From khc@pm.waw.pl Sun Apr 25 18:31:38 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 18:31:42 -0700 (PDT) Received: from hq.pm.waw.pl (hq.pm.waw.pl [195.116.170.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3Q1VaKO020938 for ; Sun, 25 Apr 2004 18:31:37 -0700 Received: by hq.pm.waw.pl (Postfix, from userid 10) id 6FC0D365; Mon, 26 Apr 2004 03:31:33 +0200 (CEST) Received: by defiant.pm.waw.pl (Postfix, from userid 500) id 68DCD302D5; Mon, 26 Apr 2004 03:30:41 +0200 (CEST) To: Jeff Garzik Cc: Subject: [PATCH] 2.6.x Tulip oops while doing eject/rmmod on live interface From: Krzysztof Halasa Date: Mon, 26 Apr 2004 03:30:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 4920 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: khc@pm.waw.pl Precedence: bulk X-list: netdev Content-Length: 842 Lines: 33 --=-=-= Hi, The attached patch fixes an "oops" in tulip driver when a live interface is deactivated (i.e. PC Card ejected or module unloaded) without being brought down first. Please apply to Linux 2.6. Thanks. -- Krzysztof Halasa, B*FH --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=tulip-rmmod.patch --- linux/drivers/net/tulip/tulip_core.c 19 Apr 2004 17:04:06 -0000 +++ linux.orig/drivers/net/tulip/tulip_core.c 26 Apr 2004 01:08:31 -0000 @@ -1761,11 +1761,11 @@ return; tp = netdev_priv(dev); + unregister_netdev(dev); pci_free_consistent (pdev, sizeof (struct tulip_rx_desc) * RX_RING_SIZE + sizeof (struct tulip_tx_desc) * TX_RING_SIZE, tp->rx_ring, tp->rx_ring_dma); - unregister_netdev (dev); if (tp->mtable) kfree (tp->mtable); #ifndef USE_IO_OPS --=-=-=-- From jgarzik@pobox.com Sun Apr 25 18:40:25 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 18:40:29 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3Q1eOKO021882 for ; Sun, 25 Apr 2004 18:40:25 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BHv6c-0002bX-SU; Mon, 26 Apr 2004 02:40:22 +0100 Message-ID: <408C687B.2000907@pobox.com> Date: Sun, 25 Apr 2004 21:40:11 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krzysztof Halasa CC: netdev@oss.sgi.com Subject: Re: [PATCH] 2.6.x Tulip oops while doing eject/rmmod on live interface References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4921 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: 294 Lines: 16 Krzysztof Halasa wrote: > Hi, > > The attached patch fixes an "oops" in tulip driver when a live interface > is deactivated (i.e. PC Card ejected or module unloaded) without being > brought down first. > > Please apply to Linux 2.6. Thanks. hmmm, yeah, looks like a bug. Thanks, Jeff From davem@redhat.com Sun Apr 25 21:37:19 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 21:37:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3Q4bIKO028194 for ; Sun, 25 Apr 2004 21:37:19 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3Q4bDKG002786; Mon, 26 Apr 2004 00:37:13 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3Q4bDv32556; Mon, 26 Apr 2004 00:37:13 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3Q4bBKv016789; Mon, 26 Apr 2004 00:37:12 -0400 Date: Sun, 25 Apr 2004 21:36:27 -0700 From: "David S. Miller" To: chas3@users.sourceforge.net Cc: chas@cmf.nrl.navy.mil, netdev@oss.sgi.com Subject: Re: [PATCH][ATM]: [fore200e] make use tasklet configurable (2 of 2) Message-Id: <20040425213627.43599868.davem@redhat.com> In-Reply-To: <200404240030.i3O0UbEI005507@ginger.cmf.nrl.navy.mil> References: <200404240030.i3O0UbEI005507@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4922 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 168 Lines: 6 On Fri, 23 Apr 2004 20:30:38 -0400 "chas williams (contractor)" wrote: > fore200e 0.3e part 2 of 2 for 2.6 kernels Both applied, thanks Chas. From davem@redhat.com Sun Apr 25 21:38:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Sun, 25 Apr 2004 21:39:03 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3Q4cwKO028322 for ; Sun, 25 Apr 2004 21:38:58 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3Q4ctKG002985; Mon, 26 Apr 2004 00:38:55 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3Q4ctv32692; Mon, 26 Apr 2004 00:38:55 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3Q4coKv017026; Mon, 26 Apr 2004 00:38:51 -0400 Date: Sun, 25 Apr 2004 21:38:06 -0700 From: "David S. Miller" To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, syrius.ml@no-log.org, maxk@qualcomm.com, jgarzik@pobox.com Subject: Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. Message-Id: <20040425213806.1edb6681.davem@redhat.com> In-Reply-To: <1082816083.1054.32.camel@jzny.localdomain> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> <1082816083.1054.32.camel@jzny.localdomain> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4923 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 400 Lines: 10 On 24 Apr 2004 10:14:43 -0400 jamal wrote: > Jeff, Dave: Would it be fair to say when packets get injected into the > stack by a netdev via netif_rx(), the skb headers are expected to be > ponting into some specific places? I am not sure if theres a hard > fastened rule defined anywhere. What do ipv4 tunnels do? They merely modify 'nh' and 'mac' ".raw" and pass the packet in. From abhijitk@veritas.com Mon Apr 26 05:13:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 05:13:33 -0700 (PDT) Received: from MTVMIME03.enterprise.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QCDSKO014320 for ; Mon, 26 Apr 2004 05:13:28 -0700 Received: from vxindia.veritas.com (unverified) by MTVMIME03.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 26 Apr 2004 05:13:22 -0700 Received: from localhost (abhijitk@localhost) by vxindia.veritas.com (8.11.6+Sun/8.9.3) with ESMTP id i3QC6ri25799 for ; Mon, 26 Apr 2004 17:36:53 +0530 (IST) X-Authentication-Warning: revati.vxindia.veritas.com: abhijitk owned process doing -bs Date: Mon, 26 Apr 2004 17:36:53 +0530 (IST) From: Abhijit Karmarkar X-X-Sender: abhijitk@revati To: netdev@oss.sgi.com Subject: variation in thruput w/ change in mtu on gige Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 4924 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abhijitk@veritas.com Precedence: bulk X-list: netdev Content-Length: 941 Lines: 32 Hi, i have observed that using jumbo frames (mtu=9000) decreases the thruput (i am timing one-way ttcp). trying w/ different mtu's i see 4096 give me the best numbers: mtu thruput ------------------------------- 1500 (default) ~846Mbps 4096 ~930Mbps <== highest 8192 ~806Mbps 9000 ~806Mbps 15K ~680Mbps my setup is: - 2 nodes connected directly (cross-over cable) - each node: 2-way, 2.4G Xeon. 4G RAM., running RHEL3 (2.4.21-4.ELsmp) - intel gige (82543GC), e1000 ver. (5.1.11-k1) i think the cards are: 64bit/66Mhz PCI. - ipv4.tcp_r/wmem and core.r/wmem_max set sufficiently high (512KB) - using ttcp to xfer ~8GB one-way. why doesn't my thruput increase with increase in MTU? is it because of small number of rx/txdescriptors on 82543GC (max=256?) or something else? are there any driver parameters that i can tune to get better numbers with larger MTUs? thanks, abhijit From cranium2003@yahoo.com Mon Apr 26 08:12:29 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 08:12:33 -0700 (PDT) Received: from web41403.mail.yahoo.com (web41403.mail.yahoo.com [66.218.93.69]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QFCTKO019017 for ; Mon, 26 Apr 2004 08:12:29 -0700 Message-ID: <20040426151220.85059.qmail@web41403.mail.yahoo.com> Received: from [61.11.18.134] by web41403.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 08:12:20 PDT Date: Mon, 26 Apr 2004 08:12:20 -0700 (PDT) From: Parag Nemade Subject: HELP ipt_hook: happy cracking message To: kernerl mail Cc: netdev@oss.sgi.com, linux-net@vger.kernel.org, netfilter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4925 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 613 Lines: 21 hi, i modified kernel so that it will create /proc/net/myproc file entry. the function of this entry is to crate a 16 byte char string from random no.s i used net_srandom and net_random and sys_time for that puspose. the problem is that i write program to generate string after 120 seconds but it is changing contents of myproc file every seconds. what can i do? Also i am getting ipt_hook: happy cracking. message again and again why? regards, parag. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From modica@sgi.com Mon Apr 26 08:16:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 08:16:41 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QFGaKO019366 for ; Mon, 26 Apr 2004 08:16:36 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3QF28BN004675 for ; Mon, 26 Apr 2004 10:02:08 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3QF28Ke37601041; Mon, 26 Apr 2004 10:02:08 -0500 (CDT) Received: from sgi.com (eagdhcp-232-158.americas.sgi.com [128.162.232.158]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3QF27Xa5382950; Mon, 26 Apr 2004 10:02:08 -0500 (CDT) Message-ID: <408D246F.8090404@sgi.com> Date: Mon, 26 Apr 2004 10:02:07 -0500 From: Steve Modica Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abhijit Karmarkar CC: netdev@oss.sgi.com Subject: Re: variation in thruput w/ change in mtu on gige References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4926 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: modica@sgi.com Precedence: bulk X-list: netdev Content-Length: 1470 Lines: 48 Probably page size. 4k is one page so those are probably the most efficient IOs. There must be some additional handling required to squeeze multiple pages into an MTU. Have you profiled things at all to see what additional code has to run in order to handle multiple pages? Steve Abhijit Karmarkar wrote: > Hi, > > i have observed that using jumbo frames (mtu=9000) decreases the thruput > (i am timing one-way ttcp). trying w/ different mtu's i see 4096 give > me the best numbers: > > mtu thruput > ------------------------------- > 1500 (default) ~846Mbps > 4096 ~930Mbps <== highest > 8192 ~806Mbps > 9000 ~806Mbps > 15K ~680Mbps > > my setup is: > - 2 nodes connected directly (cross-over cable) > - each node: 2-way, 2.4G Xeon. 4G RAM., running RHEL3 (2.4.21-4.ELsmp) > - intel gige (82543GC), e1000 ver. (5.1.11-k1) > i think the cards are: 64bit/66Mhz PCI. > - ipv4.tcp_r/wmem and core.r/wmem_max set sufficiently high (512KB) > - using ttcp to xfer ~8GB one-way. > > why doesn't my thruput increase with increase in MTU? is it because of > small number of rx/txdescriptors on 82543GC (max=256?) or something > else? > > are there any driver parameters that i can tune to get better numbers > with larger MTUs? > > thanks, > abhijit > -- Steve Modica work: 651-683-3224 MTS-Technical Lead "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me From cranium2003@yahoo.com Mon Apr 26 08:44:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 08:44:49 -0700 (PDT) Received: from web41402.mail.yahoo.com (web41402.mail.yahoo.com [66.218.93.68]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QFigKO023468 for ; Mon, 26 Apr 2004 08:44:44 -0700 Message-ID: <20040426154437.67657.qmail@web41402.mail.yahoo.com> Received: from [61.11.18.134] by web41402.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 08:44:37 PDT Date: Mon, 26 Apr 2004 08:44:37 -0700 (PDT) From: Parag Nemade Subject: ping takes much time to myself? To: net dev Cc: kernerl mail , linux net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4927 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: cranium2003@yahoo.com Precedence: bulk X-list: netdev Content-Length: 1124 Lines: 39 hello, i want to add my own variables with icmp header. so i modified icmp header and added 2 variables to make icmp header len is 16 bytes. but when i build kernel image and boot it and then ping to myself why am i still getting 8 bytes header i.e. 84 bytes packet and why not 92 bytes packet? 56 bytes data + 16 bytes icmp header + 20 bytes ip header = 92 bytes also ping results shown below takes much time to ping myself. what gone wrong? how to make it behave like normal ping? [root@localhost root]# ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=1488806 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=1489805 ms --- localhost.localdomain ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 1488806.484/1489305.976/1489805.469/500.981 ms [root@localhost root]# regards, parag. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From root@chaos.analogic.com Mon Apr 26 09:02:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 09:02:19 -0700 (PDT) Received: from chaos.analogic.com (chaos.analogic.com [204.178.40.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QG2FKO024063 for ; Mon, 26 Apr 2004 09:02:15 -0700 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.12.0.A) id i3QG2Tn01543; Mon, 26 Apr 2004 12:02:29 -0400 Date: Mon, 26 Apr 2004 12:02:29 -0400 (EDT) From: "Richard B. Johnson" X-X-Sender: root@chaos Reply-To: root@chaos.analogic.com To: Parag Nemade cc: net dev , kernerl mail , linux net Subject: Re: ping takes much time to myself? In-Reply-To: <20040426154437.67657.qmail@web41402.mail.yahoo.com> Message-ID: References: <20040426154437.67657.qmail@web41402.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4928 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: root@chaos.analogic.com Precedence: bulk X-list: netdev Content-Length: 902 Lines: 27 On Mon, 26 Apr 2004, Parag Nemade wrote: > hello, > i want to add my own variables with icmp header. > so i modified icmp header and added 2 variables to > make icmp header len is 16 bytes. but when i build > kernel image and boot it and then ping to myself why > am i still getting 8 bytes header i.e. 84 bytes packet > and why not 92 bytes packet? > 56 bytes data + 16 bytes icmp header + 20 bytes ip > header = 92 bytes > also ping results shown below takes much time to ping > myself. what gone wrong? how to make it behave like > normal ping? You don't modify the kernel to make a new ICMP packet! You modify `ping` or make your own. If you change the length of the header, it is no longer ICMP. Your tools will misinterpret what you have. Cheers, Dick Johnson Penguin : Linux version 2.4.26 on an i686 machine (5557.45 BogoMips). Note 96.31% of all statistics are fiction. From shemminger@osdl.org Mon Apr 26 10:12:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 10:12:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHCMKO026089 for ; Mon, 26 Apr 2004 10:12:22 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3QHCA229336; Mon, 26 Apr 2004 10:12:10 -0700 Date: Mon, 26 Apr 2004 10:12:10 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] tcp_vegas_cong_avoid doc Message-Id: <20040426101210.461726d2@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4929 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: 971 Lines: 22 Patch to update sysctl documentation to include tcp_vegas. Feel free to rewrite for better explanation. diff -Nru a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt --- a/Documentation/networking/ip-sysctl.txt Mon Apr 26 10:09:25 2004 +++ b/Documentation/networking/ip-sysctl.txt Mon Apr 26 10:09:25 2004 @@ -307,6 +307,15 @@ wired networks and throughput over wireless links. Default: 0 +tcp_vegas_cong_avoid - BOOLEAN + Enable TCP Vegas congestion avoidance algorithm. + TCP Vegas is a sender-side only change to TCP that anticipates + the onset of congestion by estimating the bandwidth. TCP Vegas + adjusts the sending rate by modifying the congestion + window. TCP Vegas should provide less packet loss, but is not + be as aggressive as TCP Reno. + Default:0 + ip_local_port_range - 2 INTEGERS Defines the local port range that is used by TCP and UDP to choose the local port. The first number is the first, the From luto@stanford.edu Mon Apr 26 10:42:00 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 10:42:09 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHfxKO028479 for ; Mon, 26 Apr 2004 10:41:59 -0700 Received: from stanford.edu (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3QHfkLD013955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Apr 2004 10:41:46 -0700 Message-ID: <408D49BF.40708@stanford.edu> Date: Mon, 26 Apr 2004 10:41:19 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon D Mason CC: Andy Lutomirski , netdev@oss.sgi.com, romieu@fr.zoreil.com, jgarzik@pobox.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4930 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@stanford.edu Precedence: bulk X-list: netdev Content-Length: 594 Lines: 21 Jon D Mason wrote: > Hey Andy, > I hand patched my driver (which is probably my mistake), and I noticed a > great increase in bring-up time. Good job! :) > > I noticed that the new driver never logs my speed in the dmesg (like the > old driver did). I could use ethtool, but I'm all about backwards > compatibility. So, it might be a good idea to have it in there too. OK. It'll have to go in the timer, though, which means won't work if we kill the timer. I'll wait until the driver stabilizes again so I don't just add one more patch with conflicts. --Andy > > Thanks, > Jon From luto@myrealbox.com Mon Apr 26 10:42:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 10:42:09 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHg1KO028480 for ; Mon, 26 Apr 2004 10:42:02 -0700 Received: from myrealbox.com (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3QHfrRC013958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Apr 2004 10:41:53 -0700 Message-ID: <408D49C7.2070802@myrealbox.com> Date: Mon, 26 Apr 2004 10:41:27 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jon D Mason CC: Andy Lutomirski , netdev@oss.sgi.com, romieu@fr.zoreil.com, jgarzik@pobox.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4931 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Content-Length: 594 Lines: 21 Jon D Mason wrote: > Hey Andy, > I hand patched my driver (which is probably my mistake), and I noticed a > great increase in bring-up time. Good job! :) > > I noticed that the new driver never logs my speed in the dmesg (like the > old driver did). I could use ethtool, but I'm all about backwards > compatibility. So, it might be a good idea to have it in there too. OK. It'll have to go in the timer, though, which means won't work if we kill the timer. I'll wait until the driver stabilizes again so I don't just add one more patch with conflicts. --Andy > > Thanks, > Jon From sree_prash@yahoo.com Mon Apr 26 11:40:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 11:40:49 -0700 (PDT) Received: from web60210.mail.yahoo.com (web60210.mail.yahoo.com [216.109.118.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QIejKO031305 for ; Mon, 26 Apr 2004 11:40:45 -0700 Message-ID: <20040426184039.91977.qmail@web60210.mail.yahoo.com> Received: from [202.88.229.25] by web60210.mail.yahoo.com via HTTP; Mon, 26 Apr 2004 11:40:39 PDT Date: Mon, 26 Apr 2004 11:40:39 -0700 (PDT) From: prashant s Subject: Regarding NAPI performance To: netdev@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 4933 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: sree_prash@yahoo.com Precedence: bulk X-list: netdev Content-Length: 888 Lines: 35 sir, i have a doubt on NAPI(feature which was introduced in linux 2.6.3).In which polling is used instead of interrupts when packets arrive at the network card. i did not find any performance difference between a non NAPI driver and a NAPI driver(this may be because i used large packets).Both of them showed 94Mbps,but when i reduced the "DMA receive ring size" from 32k to 8k, i got a performance difference. The ordinary driver without NAPI (rtl8139too in 2.4.20 linux) showed 72Mbps and the NAPI driver (rtl8139too in 2.6.3) showed 94Mbps,both having their ring size at 8k.The packet size i used was same as before. why is this difference when the ring size is reduced. waiting for your reply. prashant __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash From maxk@qualcomm.com Mon Apr 26 12:32:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 12:32:29 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QJWMKO004165 for ; Mon, 26 Apr 2004 12:32:23 -0700 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3QJVfU9010402; Mon, 26 Apr 2004 12:31:41 -0700 (PDT) Received: from [129.46.89.30] (workie.qualcomm.com [129.46.89.30]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i3QJVc3O002089; Mon, 26 Apr 2004 12:31:39 -0700 (PDT) Subject: Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. From: Max Krasnyansky To: hadi@cyberus.ca Cc: netdev@oss.sgi.com, syrius.ml@no-log.org, Jeff Garzik , "David S. Miller" In-Reply-To: <1082816083.1054.32.camel@jzny.localdomain> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> <1082816083.1054.32.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1083007898.7788.276.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 26 Apr 2004 12:31:38 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 4934 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: maxk@qualcomm.com Precedence: bulk X-list: netdev Content-Length: 704 Lines: 20 On Sat, 2004-04-24 at 07:14, jamal wrote: > Maxim, > > When TUN_TUN_DEV is used, before the packet is injected into > the netif_rx() only skb->mac.raw = skb->data is set; the other headers > are not adjusted. Typically netdevs would do a > skb_pull(skb,dev->hard_header_len) to make the adjustment. > I have a feeling this is design intent thats why i didnt send you a > patch. Well TUN does not have any hw headers so there is nothing to pull :). Basically it does what ever PPP driver does. Which is skb_pull(skb, 2); /* chop off protocol */ skb->dev = ppp->dev; skb->protocol = htons(npindex_to_ethertype[npi]); skb->mac.raw = skb->data; netif_rx(skb); Max From davem@redhat.com Mon Apr 26 16:33:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 16:33:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QNXIKO020359 for ; Mon, 26 Apr 2004 16:33:18 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3QNXDKG025192; Mon, 26 Apr 2004 19:33:13 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3QNXDv22829; Mon, 26 Apr 2004 19:33:13 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3QNXBKv023603; Mon, 26 Apr 2004 19:33:11 -0400 Date: Mon, 26 Apr 2004 16:32:21 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] tcp_vegas_cong_avoid doc Message-Id: <20040426163221.56a08130.davem@redhat.com> In-Reply-To: <20040426101210.461726d2@dell_ss3.pdx.osdl.net> References: <20040426101210.461726d2@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4935 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 1435 Lines: 38 On Mon, 26 Apr 2004 10:12:10 -0700 Stephen Hemminger wrote: > Patch to update sysctl documentation to include tcp_vegas. > Feel free to rewrite for better explanation. I applied this, only changing a minor grammatical error at the end. See attached... # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/04/26 16:31:03-07:00 shemminger@osdl.org # [TCP]: Add vegas sysctl docs. # # Documentation/networking/ip-sysctl.txt # 2004/04/26 16:30:36-07:00 shemminger@osdl.org +9 -0 # [TCP]: Add vegas sysctl docs. # diff -Nru a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt --- a/Documentation/networking/ip-sysctl.txt Mon Apr 26 16:31:29 2004 +++ b/Documentation/networking/ip-sysctl.txt Mon Apr 26 16:31:29 2004 @@ -307,6 +307,15 @@ wired networks and throughput over wireless links. Default: 0 +tcp_vegas_cong_avoid - BOOLEAN + Enable TCP Vegas congestion avoidance algorithm. + TCP Vegas is a sender-side only change to TCP that anticipates + the onset of congestion by estimating the bandwidth. TCP Vegas + adjusts the sending rate by modifying the congestion + window. TCP Vegas should provide less packet loss, but it is + not as aggressive as TCP Reno. + Default:0 + ip_local_port_range - 2 INTEGERS Defines the local port range that is used by TCP and UDP to choose the local port. The first number is the first, the From rusty@rustcorp.com.au Mon Apr 26 20:33:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 20:33:48 -0700 (PDT) Received: from ausmtp02.au.ibm.com (ausmtp02.au.ibm.com [202.81.18.187]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R3XgKO030008 for ; Mon, 26 Apr 2004 20:33:43 -0700 Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id i3R3XVKQ120270; Tue, 27 Apr 2004 13:33:31 +1000 Received: from ozlabs.au.ibm.com (ozlabs.au.ibm.com [9.190.163.12]) by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3R3Y5Rs071678; Tue, 27 Apr 2004 13:34:06 +1000 Received: from bach.ozlabs.ibm.com (bach.ozlabs.ibm.com [10.61.2.150]) by ozlabs.au.ibm.com (Postfix) with ESMTP id 14DA117DD8; Tue, 27 Apr 2004 13:33:32 +1000 (EST) Subject: Re: HELP ipt_hook: happy cracking message From: Rusty Russell To: Parag Nemade Cc: kernerl mail , netdev@oss.sgi.com, linux-net@vger.kernel.org, netfilter In-Reply-To: <20040426151220.85059.qmail@web41403.mail.yahoo.com> References: <20040426151220.85059.qmail@web41403.mail.yahoo.com> Content-Type: text/plain Message-Id: <1083036797.2150.14.camel@bach> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Apr 2004 13:33:17 +1000 Content-Transfer-Encoding: 7bit X-archive-position: 4937 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rusty@rustcorp.com.au Precedence: bulk X-list: netdev Content-Length: 756 Lines: 22 On Tue, 2004-04-27 at 01:12, Parag Nemade wrote: > hi, > i modified kernel so that it will create > /proc/net/myproc file entry. > the function of this entry is to crate a 16 byte char > string from random no.s > i used net_srandom and net_random and sys_time for > that puspose. the problem is that i write program to > generate string after 120 seconds but it is changing > contents of myproc file every seconds. what can i do? > Also i am getting ipt_hook: happy cracking. message > again and again why? You're sending out IP packets which don't even contain the IP header, and you're running connection tracking or some filtering. The message is not serious. Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell From abhijitk@veritas.com Mon Apr 26 21:53:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Mon, 26 Apr 2004 21:53:39 -0700 (PDT) Received: from MTVMIME02.enterprise.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R4raKO032643 for ; Mon, 26 Apr 2004 21:53:36 -0700 Received: from vxindia.veritas.com (unverified) by MTVMIME02.enterprise.veritas.com (Content Technologies SMTPRS 4.3.12) with ESMTP id ; Mon, 26 Apr 2004 21:53:29 -0700 Received: from localhost (abhijitk@localhost) by vxindia.veritas.com (8.11.6+Sun/8.9.3) with ESMTP id i3R4kv910554; Tue, 27 Apr 2004 10:16:57 +0530 (IST) X-Authentication-Warning: revati.vxindia.veritas.com: abhijitk owned process doing -bs Date: Tue, 27 Apr 2004 10:16:57 +0530 (IST) From: Abhijit Karmarkar X-X-Sender: abhijitk@revati To: Steve Modica cc: netdev@oss.sgi.com Subject: Re: variation in thruput w/ change in mtu on gige In-Reply-To: <408D246F.8090404@sgi.com> Message-ID: References: <408D246F.8090404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 4938 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: abhijitk@veritas.com Precedence: bulk X-list: netdev Content-Length: 3927 Lines: 125 On Mon, 26 Apr 2004, Steve Modica wrote: > Probably page size. 4k is one page so those are probably the most > efficient IOs. There must be some additional handling required to > squeeze multiple pages into an MTU. not sure. though i see copy_to_user() working harder on the rx side, in case of MTU=9K. > Have you profiled things at all to see what additional code has to run > in order to handle multiple pages? i did collect oprofile samples for my test runs (one-way flow, xmitting 38GB of data, using ttcp. same setup as earlier). here is a summary (top 10 functions, for vmlinux and e1000): for MTU=4096 (thruput = ~930Mbps) [At receiver] ---------------------------------------------------- samples % symbol name vmlinux: 28085 12.9316 default_idle 24891 11.4609 __generic_copy_to_user 12684 5.84026 tcp_v4_rcv 11794 5.43047 __kmem_cache_alloc 10966 5.04922 do_IRQ 10834 4.98844 __wake_up 8082 3.7213 try_to_wake_up 7214 3.32164 __mod_timer 6029 2.77601 net_rx_action 5854 2.69544 ip_route_input e1000: 52363 47.0657 e1000_intr 36977 33.2363 e1000_irq_enable 7435 6.68285 e1000_clean_tx_irq 5024 4.51575 e1000_clean_rx_irq 4764 4.28205 e1000_alloc_rx_buffers 4037 3.6286 e1000_clean 261 0.234596 e1000_tx_map 258 0.2319 e1000_rx_checksum 83 0.0746034 e1000_tx_queue 48 0.0431441 e1000_xmit_frame for MTU=9000 (thruput = ~806Mbps) [At receiver] ---------------------------------------------------- samples % symbol name vmlinux: 22533 20.7672 __generic_copy_to_user 12178 11.2237 default_idle 5893 5.43119 tcp_v4_rcv 5151 4.74733 __wake_up 5010 4.61738 __kmem_cache_alloc 4585 4.22569 do_IRQ 3592 3.31051 try_to_wake_up 2966 2.73356 __mod_timer 2683 2.47274 ip_route_input 2491 2.29579 eth_type_trans e1000: 20504 51.4349 e1000_intr 10064 25.2458 e1000_irq_enable 2860 7.17439 e1000_clean_tx_irq 2292 5.74955 e1000_clean_rx_irq 2261 5.67178 e1000_alloc_rx_buffers 1583 3.971 e1000_clean 132 0.331126 e1000_rx_checksum 108 0.270921 e1000_tx_map 35 0.0877985 e1000_tx_queue 17 0.042645 e1000_xmit_frame does that tell anything? also note that number of interrupts (e1000_intr) is slightly higher for larger MTU. [in case anybody needs the full profiles on both rx/tx side for differnet MTU's please let me know. i can mail them] thanks abhijit > > Steve > > Abhijit Karmarkar wrote: > > Hi, > > > > i have observed that using jumbo frames (mtu=9000) decreases the thruput > > (i am timing one-way ttcp). trying w/ different mtu's i see 4096 give > > me the best numbers: > > > > mtu thruput > > ------------------------------- > > 1500 (default) ~846Mbps > > 4096 ~930Mbps <== highest > > 8192 ~806Mbps > > 9000 ~806Mbps > > 15K ~680Mbps > > > > my setup is: > > - 2 nodes connected directly (cross-over cable) > > - each node: 2-way, 2.4G Xeon. 4G RAM., running RHEL3 (2.4.21-4.ELsmp) > > - intel gige (82543GC), e1000 ver. (5.1.11-k1) > > i think the cards are: 64bit/66Mhz PCI. > > - ipv4.tcp_r/wmem and core.r/wmem_max set sufficiently high (512KB) > > - using ttcp to xfer ~8GB one-way. > > > > why doesn't my thruput increase with increase in MTU? is it because of > > small number of rx/txdescriptors on 82543GC (max=256?) or something > > else? > > > > are there any driver parameters that i can tune to get better numbers > > with larger MTUs? > > > > thanks, > > abhijit > > > > > -- > Steve Modica > work: 651-683-3224 > MTS-Technical Lead > "Give a man a fish, and he will eat for a day, hit him with a fish and > he leaves you alone" - me > From Robert.Olsson@data.slu.se Tue Apr 27 00:54:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 00:54:35 -0700 (PDT) Received: from mail1.slu.se (mail1.slu.se [130.238.96.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R7sSKO007438 for ; Tue, 27 Apr 2004 00:54:31 -0700 Received: from robur.slu.se (robur.slu.se [130.238.98.12]) by mail1.slu.se (8.12.10/8.12.10) with ESMTP id i3R7sRoB000449; Tue, 27 Apr 2004 09:54:27 +0200 Received: by robur.slu.se (Postfix, from userid 1000) id 24506903D5; Tue, 27 Apr 2004 09:54:28 +0200 (CEST) From: Robert Olsson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16526.4532.22789.626062@robur.slu.se> Date: Tue, 27 Apr 2004 09:54:28 +0200 To: prashant s Cc: netdev@oss.sgi.com Subject: Regarding NAPI performance In-Reply-To: <20040426184039.91977.qmail@web60210.mail.yahoo.com> References: <20040426184039.91977.qmail@web60210.mail.yahoo.com> X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 4939 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: Robert.Olsson@data.slu.se Precedence: bulk X-list: netdev Content-Length: 574 Lines: 20 prashant s writes: > driver without NAPI (rtl8139too in 2.4.20 linux) > showed 72Mbps and the NAPI driver (rtl8139too in > 2.6.3) showed 94Mbps,both having their ring size at > 8k.The packet size i used was same as before. > why is this difference when the ring size is reduced. Well a good question. I would expect non-NAPI to perform equal to NAPI at low network load even w. small RX-rings. Any difference interrupt delay? NAPI can live without delay. Or some other driver difference? I have no experience with rtl8139too myself. Cheers. --ro From hadi@cyberus.ca Tue Apr 27 01:17:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 01:17:34 -0700 (PDT) Received: from mx01.cybersurf.com (mx01.cybersurf.com [209.197.145.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R8HSKO008246 for ; Tue, 27 Apr 2004 01:17:30 -0700 Received: from mail.cyberus.ca ([209.197.145.21]) by mx01.cybersurf.com with esmtp (Exim 4.20) id 1BIIFy-00080D-4m for netdev@oss.sgi.com; Mon, 26 Apr 2004 22:23:34 -0400 Received: from cpe0030ab124d2f-cm014500000962.cpe.net.cable.rogers.com ([24.103.99.32] helo=[10.0.0.21]) by mail.cyberus.ca with esmtp (Exim 4.20) id 1BIIFO-0000P7-Et; Mon, 26 Apr 2004 22:22:58 -0400 Subject: Re: tun device - bug or feature? WAS(Re: IMQ / new Dummy device post. From: jamal Reply-To: hadi@cyberus.ca To: Max Krasnyansky Cc: netdev@oss.sgi.com, syrius.ml@no-log.org, Jeff Garzik , "David S. Miller" In-Reply-To: <1083007898.7788.276.camel@localhost> References: <1082427350.1034.70.camel@jzny.localdomain> <1082639764.1059.81.camel@jzny.localdomain> <87oepjx65r.87n053x65r@87llknx65r.message.id> <1082719745.1057.27.camel@jzny.localdomain> <1082816083.1054.32.camel@jzny.localdomain> <1083007898.7788.276.camel@localhost> Content-Type: text/plain Organization: jamalopolis Message-Id: <1083032546.1039.271.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Apr 2004 22:22:26 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4940 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: hadi@cyberus.ca Precedence: bulk X-list: netdev Content-Length: 405 Lines: 13 On Mon, 2004-04-26 at 15:31, Max Krasnyansky wrote: > Well TUN does not have any hw headers so there is nothing to pull :). didnt notice the dev->hard_header_len being 0 before ;-> In that case it makes sense to have nothing to pull. Theres about 5 devices like that. I need to rethink a little on behavior of mirred with devices that have no hardware headers. I may speacial case them. cheers, jamal From kevin.curtis@farsite.co.uk Tue Apr 27 02:53:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 02:54:01 -0700 (PDT) Received: from relay2.ftech.net (relay2.ftech.net [195.200.0.97]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R9rqKO015374 for ; Tue, 27 Apr 2004 02:53:52 -0700 Received: from opal.ftech.net ([212.32.16.127] helo=mailgate.ftech.net) by relay2.ftech.net with esmtp (Exim 3.36-ftechp12 #2) id 1BI93L-0002Qv-00; Mon, 26 Apr 2004 17:33:55 +0100 Received: from pc9.faradsl.ftech.co.uk ([212.32.46.170] helo=GENERAL.hq.farsitecommunications.com) by mailgate.ftech.net with esmtp (Exim 3.36-ftechp12 #1) id 1BI939-00042D-00; Mon, 26 Apr 2004 17:33:43 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C42BAC.3CBC71C8" Subject: Update FarSync WAN driver in 2.4.25 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 26 Apr 2004 17:33:42 +0100 content-class: urn:content-classes:message Message-ID: <7C078C66B7752B438B88E11E5E20E72E25CD16@general.hq.farsitecommunications.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Update FarSync WAN driver in 2.4.25 Thread-Index: AcPrONGkVWQ5J07eSSa/6KR8S+rqGw== From: "Kevin Curtis" To: Cc: , , "Dermot Smith" X-archive-position: 4941 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kevin.curtis@farsite.co.uk Precedence: bulk X-list: netdev Content-Length: 351431 Lines: 4599 This is a multi-part message in MIME format. ------_=_NextPart_001_01C42BAC.3CBC71C8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, please find attached a patch to update the FarSync WAN driver in the 2.4 and 2.6 Kernels. The driver has been updated in the following ways: 1) Provides support for new FarSync cards T1U, T2U, T4U and TE1 2) Provides support for an E1 interface 3) Provides support for a variant of X.21 that allows transmit and receive clocks 4) Provide a raw socket interface directly to the data from the line. 5) Improves performance with less time in interrupts and more in BH's In the main the only files affected are the farsync.c and farsync.h files, although there have been some additions to the if.h file. Please try to include it in the 2.4.27 and 2.6.6 releases. Kind Regards Kevin Curtis Linux Development FarSite Communications Ltd http://www.farsite.co.uk tel: +44 1256 330461 fax: +44 1256 854931 ------_=_NextPart_001_01C42BAC.3CBC71C8 Content-Type: application/octet-stream; name="farsync2.6.patch" Content-Transfer-Encoding: base64 Content-Description: farsync2.6.patch Content-Disposition: attachment; filename="farsync2.6.patch" ZGlmZiAtdXJOIGxpbnV4LTIuNi40LXByZTEtb3JpZy9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5j IGxpbnV4L2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmMKLS0tIGxpbnV4LTIuNi40LXByZTEtb3Jp Zy9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5jCTIwMDQtMDMtMDEgMDk6MTc6MDguMDAwMDAwMDAw ICswMDAwCisrKyBsaW51eC9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5jCTIwMDQtMDMtMDEgMTI6 NTQ6MjIuMjk5Mjg1NzUyICswMDAwCkBAIC0xLDkgKzEsOSBAQAogLyoKLSAqICAgICAgRmFyU3lu YyBYMjEgZHJpdmVyIGZvciBMaW51eCAoZ2VuZXJpYyBIRExDIHZlcnNpb24pCisgKiAgICAgIEZh clN5bmMgV0FOIGRyaXZlciBmb3IgTGludXggKDIuNi54IGtlcm5lbCB2ZXJzaW9uKQogICoKICAq ICAgICAgQWN0dWFsbHkgc3luYyBkcml2ZXIgZm9yIFguMjEsIFYuMzUgYW5kIFYuMjQgb24gRmFy U3luYyBULXNlcmllcyBjYXJkcwogICoKLSAqICAgICAgQ29weXJpZ2h0IChDKSAyMDAxIEZhclNp dGUgQ29tbXVuaWNhdGlvbnMgTHRkLgorICogICAgICBDb3B5cmlnaHQgKEMpIDIwMDEtMjAwNCBG YXJTaXRlIENvbW11bmljYXRpb25zIEx0ZC4KICAqICAgICAgd3d3LmZhcnNpdGUuY28udWsKICAq CiAgKiAgICAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJp YnV0ZSBpdCBhbmQvb3IKQEAgLTExLDExICsxMSwxMyBAQAogICogICAgICBhcyBwdWJsaXNoZWQg YnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24KICAqICAgICAg MiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4K ICAqCi0gKiAgICAgIEF1dGhvcjogUi5KLkR1bmxvcCAgICAgIDxib2IuZHVubG9wQGZhcnNpdGUu Y28udWs+CisgKiAgICAgIEF1dGhvcjogICAgICBSLkouRHVubG9wICAgIDxib2IuZHVubG9wQGZh cnNpdGUuY28udWs+CisgKiAgICAgIE1haW50YWluZXI6ICBLZXZpbiBDdXJ0aXMgIDxrZXZpbi5j dXJ0aXNAZmFyc2l0ZS5jby51az4KICAqLwogCiAjaW5jbHVkZSA8bGludXgvbW9kdWxlLmg+CiAj aW5jbHVkZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVkZSA8bGludXgvdmVyc2lvbi5oPgogI2lu Y2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1ZGUgPGxpbnV4L2lvcG9ydC5oPgogI2luY2x1ZGUg PGxpbnV4L2luaXQuaD4KQEAgLTI1LDQ5ICsyNyw2MiBAQAogCiAjaW5jbHVkZSAiZmFyc3luYy5o IgogCi0KIC8qCiAgKiAgICAgIE1vZHVsZSBpbmZvCiAgKi8KIE1PRFVMRV9BVVRIT1IoIlIuSi5E dW5sb3AgPGJvYi5kdW5sb3BAZmFyc2l0ZS5jby51az4iKTsKLU1PRFVMRV9ERVNDUklQVElPTigi RmFyU3luYyBULVNlcmllcyBYMjEgZHJpdmVyLiBGYXJTaXRlIENvbW11bmljYXRpb25zIEx0ZC4i KTsKK01PRFVMRV9ERVNDUklQVElPTigiRmFyU3luYyBULVNlcmllcyBXQU4gZHJpdmVyLiBGYXJT aXRlIENvbW11bmljYXRpb25zIEx0ZC4iKTsKK01PRFVMRV9QQVJNKGZzdF90eHFfbG93LCAiaSIp OworTU9EVUxFX1BBUk0oZnN0X3R4cV9oaWdoLCAiaSIpOworTU9EVUxFX1BBUk0oZnN0X21heF9y ZWFkcywgImkiKTsKK01PRFVMRV9QQVJNKGZzdF9leGNsdWRlZF9jYXJkcywgImkiKTsKK01PRFVM RV9QQVJNKGZzdF9leGNsdWRlZF9saXN0LCAiMC0zMmkiKTsKIE1PRFVMRV9MSUNFTlNFKCJHUEwi KTsKIAogLyogICAgICBEcml2ZXIgY29uZmlndXJhdGlvbiBhbmQgZ2xvYmFsIHBhcmFtZXRlcnMK ICAqICAgICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CiAgKi8K IAotLyogICAgICBOdW1iZXIgb2YgcG9ydHMgKHBlciBjYXJkKSBzdXBwb3J0ZWQKKy8qICAgICAg TnVtYmVyIG9mIHBvcnRzIChwZXIgY2FyZCkgYW5kIGNhcmRzIHN1cHBvcnRlZAogICovCiAjZGVm aW5lIEZTVF9NQVhfUE9SVFMgICAgICAgICAgIDQKLQotCi0vKiAgICAgIFBDSSB2ZW5kb3IgYW5k IGRldmljZSBJRHMKLSAqLwotI2RlZmluZSBGU0NfUENJX1ZFTkRPUl9JRCAgICAgICAweDE2MTkg IC8qIEZhclNpdGUgQ29tbXVuaWNhdGlvbnMgTHRkICovCi0jZGVmaW5lIFQyUF9QQ0lfREVWSUNF X0lEICAgICAgIDB4MDQwMCAgLyogVDJQIFgyMSAyIHBvcnQgY2FyZCAqLwotI2RlZmluZSBUNFBf UENJX0RFVklDRV9JRCAgICAgICAweDA0NDAgIC8qIFQ0UCBYMjEgNCBwb3J0IGNhcmQgKi8KLQor I2RlZmluZSBGU1RfTUFYX0NBUkRTICAgICAgICAgICAzMgogCiAvKiAgICAgIERlZmF1bHQgcGFy YW1ldGVycyBmb3IgdGhlIGxpbmsKICAqLwotI2RlZmluZSBGU1RfVFhfUVVFVUVfTEVOICAgICAg ICAxMDAgICAgIC8qIEF0IDhNYnBzIGEgbG9uZ2VyIHF1ZXVlIGxlbmd0aCBpcwotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIHVzZWZ1bCwgdGhlIHN5bmNwcHAgbW9k dWxlIGZvcmNlcwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIHRo aXMgZG93biBhc3N1bWluZyBhIHNsb3dlciBsaW5lIEkKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKiBndWVzcy4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKi8KLSNkZWZpbmUgRlNUX01BWF9NVFUgICAgICAgICAgICAgODAwMCAgICAv KiBIdWdlIGJ1dCBwb3NzaWJsZSAqLwotI2RlZmluZSBGU1RfREVGX01UVSAgICAgICAgICAgICAx NTAwICAgIC8qIENvbW1vbiBzYW5lIHZhbHVlICovCisjZGVmaW5lIEZTVF9UWF9RVUVVRV9MRU4g ICAgICAgIDEwMAkvKiBBdCA4TWJwcyBhIGxvbmdlciBxdWV1ZSBsZW5ndGggaXMKKwkJCQkJICog dXNlZnVsLCB0aGUgc3luY3BwcCBtb2R1bGUgZm9yY2VzCisJCQkJCSAqIHRoaXMgZG93biBhc3N1 bWluZyBhIHNsb3dlciBsaW5lIEkKKwkJCQkJICogZ3Vlc3MuCisJCQkJCSAqLworI2RlZmluZSBG U1RfVFhRX0RFUFRIICAgICAgICAgICAxNgkvKiBUaGlzIG9uZSBpcyBmb3IgdGhlIGJ1ZmZlcmlu ZworCQkJCQkgKiBvZiBmcmFtZXMgb24gdGhlIHdheSBkb3duIHRvIHRoZSBjYXJkCisJCQkJCSAq IHNvIHRoYXQgd2UgY2FuIGtlZXAgdGhlIGNhcmQgYnVzeQorCQkJCQkgKiBhbmQgbWF4aW1pc2Ug dGhyb3VnaHB1dAorCQkJCQkgKi8KKyNkZWZpbmUgRlNUX0hJR0hfV0FURVJfTUFSSyAgICAgMTIJ LyogUG9pbnQgYXQgd2hpY2ggd2UgZmxvdyBjb250cm9sCisJCQkJCSAqIG5ldHdvcmsgbGF5ZXIg Ki8KKyNkZWZpbmUgRlNUX0xPV19XQVRFUl9NQVJLICAgICAgOAkvKiBQb2ludCBhdCB3aGljaCB3 ZSByZW1vdmUgZmxvdworCQkJCQkgKiBjb250cm9sIGZyb20gbmV0d29yayBsYXllciAqLworI2Rl ZmluZSBGU1RfTUFYX01UVSAgICAgICAgICAgICA4MDAwCS8qIEh1Z2UgYnV0IHBvc3NpYmxlICov CisjZGVmaW5lIEZTVF9ERUZfTVRVICAgICAgICAgICAgIDE1MDAJLyogQ29tbW9uIHNhbmUgdmFs dWUgKi8KIAogI2RlZmluZSBGU1RfVFhfVElNRU9VVCAgICAgICAgICAoMipIWikKIAotCiAjaWZk ZWYgQVJQSFJEX1JBV0hETEMKLSNkZWZpbmUgQVJQSFJEX01ZVFlQRSAgIEFSUEhSRF9SQVdIRExD ICAvKiBSYXcgZnJhbWVzICovCisjZGVmaW5lIEFSUEhSRF9NWVRZUEUgICBBUlBIUkRfUkFXSERM QwkvKiBSYXcgZnJhbWVzICovCiAjZWxzZQotI2RlZmluZSBBUlBIUkRfTVlUWVBFICAgQVJQSFJE X0hETEMgICAgIC8qIENpc2NvLUhETEMgKGtlZXBhbGl2ZXMgZXRjKSAqLworI2RlZmluZSBBUlBI UkRfTVlUWVBFICAgQVJQSFJEX0hETEMJLyogQ2lzY28tSERMQyAoa2VlcGFsaXZlcyBldGMpICov CiAjZW5kaWYKIAorLyoKKyAqIE1vZHVsZXMgcGFyYW1ldGVycyBhbmQgYXNzb2NpYXRlZCB2YXJh aWJsZXMKKyAqLworaW50IGZzdF90eHFfbG93ID0gRlNUX0xPV19XQVRFUl9NQVJLOworaW50IGZz dF90eHFfaGlnaCA9IEZTVF9ISUdIX1dBVEVSX01BUks7CitpbnQgZnN0X21heF9yZWFkcyA9IDc7 CitpbnQgZnN0X2V4Y2x1ZGVkX2NhcmRzID0gMDsKK2ludCBmc3RfZXhjbHVkZWRfbGlzdFtGU1Rf TUFYX0NBUkRTXTsKIAogLyogICAgICBDYXJkIHNoYXJlZCBtZW1vcnkgbGF5b3V0CiAgKiAgICAg ID09PT09PT09PT09PT09PT09PT09PT09PT0KQEAgLTg0LDU4ICs5OSw1NyBAQAogICogICAgICBi ZSB1c2VkIHRvIGNoZWNrIHRoYXQgd2UgaGF2ZSBub3QgZ290IG91dCBvZiBzdGVwIHdpdGggdGhl IGZpcm13YXJlCiAgKiAgICAgIGNvbnRhaW5lZCBpbiB0aGUgLkNERSBmaWxlcy4KICAqLwotI2Rl ZmluZSBTTUNfVkVSU0lPTiAxMQorI2RlZmluZSBTTUNfVkVSU0lPTiAyNAogCi0jZGVmaW5lIEZT VF9NRU1TSVpFIDB4MTAwMDAwICAgIC8qIFNpemUgb2YgY2FyZCBtZW1vcnkgKDFNYikgKi8KKyNk ZWZpbmUgRlNUX01FTVNJWkUgMHgxMDAwMDAJLyogU2l6ZSBvZiBjYXJkIG1lbW9yeSAoMU1iKSAq LwogCi0jZGVmaW5lIFNNQ19CQVNFIDB4MDAwMDIwMDBMICAgIC8qIEJhc2Ugb2Zmc2V0IG9mIHRo ZSBzaGFyZWQgbWVtb3J5IHdpbmRvdyBtYWluCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqIGNvbmZpZ3VyYXRpb24gc3RydWN0dXJlICovCi0jZGVmaW5lIEJGTV9CQVNFIDB4MDAw MTAwMDBMICAgIC8qIEJhc2Ugb2Zmc2V0IG9mIHRoZSBzaGFyZWQgbWVtb3J5IHdpbmRvdyBETUEK LSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogYnVmZmVycyAqLworI2RlZmluZSBT TUNfQkFTRSAweDAwMDAyMDAwTAkvKiBCYXNlIG9mZnNldCBvZiB0aGUgc2hhcmVkIG1lbW9yeSB3 aW5kb3cgbWFpbgorCQkJCSAqIGNvbmZpZ3VyYXRpb24gc3RydWN0dXJlICovCisjZGVmaW5lIEJG TV9CQVNFIDB4MDAwMTAwMDBMCS8qIEJhc2Ugb2Zmc2V0IG9mIHRoZSBzaGFyZWQgbWVtb3J5IHdp bmRvdyBETUEKKwkJCQkgKiBidWZmZXJzICovCiAKLSNkZWZpbmUgTEVOX1RYX0JVRkZFUiA4MTky ICAgICAgLyogU2l6ZSBvZiBwYWNrZXQgYnVmZmVycyAqLworI2RlZmluZSBMRU5fVFhfQlVGRkVS IDgxOTIJLyogU2l6ZSBvZiBwYWNrZXQgYnVmZmVycyAqLwogI2RlZmluZSBMRU5fUlhfQlVGRkVS IDgxOTIKIAotI2RlZmluZSBMRU5fU01BTExfVFhfQlVGRkVSIDI1NiAvKiBTaXplIG9mIG9ic29s ZXRlIGJ1ZmZzIHVzZWQgZm9yIERPUyBkaWFncyAqLworI2RlZmluZSBMRU5fU01BTExfVFhfQlVG RkVSIDI1NgkvKiBTaXplIG9mIG9ic29sZXRlIGJ1ZmZzIHVzZWQgZm9yIERPUyBkaWFncyAqLwog I2RlZmluZSBMRU5fU01BTExfUlhfQlVGRkVSIDI1NgogCi0jZGVmaW5lIE5VTV9UWF9CVUZGRVIg MiAgICAgICAgIC8qIE11c3QgYmUgcG93ZXIgb2YgMi4gRml4ZWQgYnkgZmlybXdhcmUgKi8KKyNk ZWZpbmUgTlVNX1RYX0JVRkZFUiAyCQkvKiBNdXN0IGJlIHBvd2VyIG9mIDIuIEZpeGVkIGJ5IGZp cm13YXJlICovCiAjZGVmaW5lIE5VTV9SWF9CVUZGRVIgOAogCiAvKiBJbnRlcnJ1cHQgcmV0cnkg dGltZSBpbiBtaWxsaXNlY29uZHMgKi8KICNkZWZpbmUgSU5UX1JFVFJZX1RJTUUgMgogCi0KIC8q ICAgICAgVGhlIEFtMTg2Q0gvQ0MgcHJvY2Vzc29ycyBzdXBwb3J0IGEgU21hcnRETUEgbW9kZSB1 c2luZyBjaXJjdWxhciBwb29scwogICogICAgICBvZiBidWZmZXIgZGVzY3JpcHRvcnMuIFRoZSBz dHJ1Y3R1cmUgaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGF0IHVzZWQKICAqICAgICAgaW4gdGhl IExBTkNFIEV0aGVybmV0IGNvbnRyb2xsZXJzLiBEZXRhaWxzIGF2YWlsYWJsZSBhcyBQREYgZnJv bSB0aGUKICAqICAgICAgQU1EIHdlYiBzaXRlOiBodHRwOi8vd3d3LmFtZC5jb20vcHJvZHVjdHMv ZXBkL3Byb2Nlc3NvcnMvXAogICogICAgICAgICAgICAgICAgICAgIDIuMTZiaXRjb250LzMuYW0x ODZjeGZhL2EyMTkxNC8yMTkxNC5wZGYKICAqLwotc3RydWN0IHR4ZGVzYyB7ICAgICAgICAgICAg ICAgICAvKiBUcmFuc21pdCBkZXNjcmlwdG9yICovCi0gICAgICAgIHZvbGF0aWxlIHUxNiBsYWRy OyAgICAgIC8qIExvdyBvcmRlciBhZGRyZXNzIG9mIHBhY2tldC4gVGhpcyBpcyBhCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAqIGxpbmVhciBhZGRyZXNzIGluIHRoZSBBbTE4NiBt ZW1vcnkgc3BhY2UKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCi0gICAgICAg IHZvbGF0aWxlIHU4ICBoYWRyOyAgICAgIC8qIEhpZ2ggb3JkZXIgYWRkcmVzcy4gTG93IDQgYml0 cyBvbmx5LCBoaWdoIDQKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogYml0cyBt dXN0IGJlIHplcm8KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCi0gICAgICAg IHZvbGF0aWxlIHU4ICBiaXRzOyAgICAgIC8qIFN0YXR1cyBhbmQgY29uZmlnICovCi0gICAgICAg IHZvbGF0aWxlIHUxNiBiY250OyAgICAgIC8qIDJzIGNvbXBsZW1lbnQgb2YgcGFja2V0IHNpemUg aW4gbG93IDE1IGJpdHMuCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIFRyYW5z bWl0IHRlcm1pbmFsIGNvdW50IGludGVycnVwdCBlbmFibGUgaW4KLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICogdG9wIGJpdC4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICovCi0gICAgICAgICAgICAgICAgIHUxNiB1bnVzZWQ7ICAgIC8qIE5vdCB1c2VkIGluIFR4 ICovCitzdHJ1Y3QgdHhkZXNjIHsJCQkvKiBUcmFuc21pdCBkZXNjcmlwdG9yICovCisJdm9sYXRp bGUgdTE2IGxhZHI7CS8qIExvdyBvcmRlciBhZGRyZXNzIG9mIHBhY2tldC4gVGhpcyBpcyBhCisJ CQkJICogbGluZWFyIGFkZHJlc3MgaW4gdGhlIEFtMTg2IG1lbW9yeSBzcGFjZQorCQkJCSAqLwor CXZvbGF0aWxlIHU4IGhhZHI7CS8qIEhpZ2ggb3JkZXIgYWRkcmVzcy4gTG93IDQgYml0cyBvbmx5 LCBoaWdoIDQKKwkJCQkgKiBiaXRzIG11c3QgYmUgemVybworCQkJCSAqLworCXZvbGF0aWxlIHU4 IGJpdHM7CS8qIFN0YXR1cyBhbmQgY29uZmlnICovCisJdm9sYXRpbGUgdTE2IGJjbnQ7CS8qIDJz IGNvbXBsZW1lbnQgb2YgcGFja2V0IHNpemUgaW4gbG93IDE1IGJpdHMuCisJCQkJICogVHJhbnNt aXQgdGVybWluYWwgY291bnQgaW50ZXJydXB0IGVuYWJsZSBpbgorCQkJCSAqIHRvcCBiaXQuCisJ CQkJICovCisJdTE2IHVudXNlZDsJCS8qIE5vdCB1c2VkIGluIFR4ICovCiB9OwogCi1zdHJ1Y3Qg cnhkZXNjIHsgICAgICAgICAgICAgICAgIC8qIFJlY2VpdmUgZGVzY3JpcHRvciAqLwotICAgICAg ICB2b2xhdGlsZSB1MTYgbGFkcjsgICAgICAvKiBMb3cgb3JkZXIgYWRkcmVzcyBvZiBwYWNrZXQg Ki8KLSAgICAgICAgdm9sYXRpbGUgdTggIGhhZHI7ICAgICAgLyogSGlnaCBvcmRlciBhZGRyZXNz ICovCi0gICAgICAgIHZvbGF0aWxlIHU4ICBiaXRzOyAgICAgIC8qIFN0YXR1cyBhbmQgY29uZmln ICovCi0gICAgICAgIHZvbGF0aWxlIHUxNiBiY250OyAgICAgIC8qIDJzIGNvbXBsZW1lbnQgb2Yg YnVmZmVyIHNpemUgaW4gbG93IDE1IGJpdHMuCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqIFJlY2VpdmUgdGVybWluYWwgY291bnQgaW50ZXJydXB0IGVuYWJsZSBpbgotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKiB0b3AgYml0LgotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKi8KLSAgICAgICAgdm9sYXRpbGUgdTE2IG1jbnQ7ICAgICAgLyogTWVz c2FnZSBieXRlIGNvdW50ICgxNSBiaXRzKSAqLworc3RydWN0IHJ4ZGVzYyB7CQkJLyogUmVjZWl2 ZSBkZXNjcmlwdG9yICovCisJdm9sYXRpbGUgdTE2IGxhZHI7CS8qIExvdyBvcmRlciBhZGRyZXNz IG9mIHBhY2tldCAqLworCXZvbGF0aWxlIHU4IGhhZHI7CS8qIEhpZ2ggb3JkZXIgYWRkcmVzcyAq LworCXZvbGF0aWxlIHU4IGJpdHM7CS8qIFN0YXR1cyBhbmQgY29uZmlnICovCisJdm9sYXRpbGUg dTE2IGJjbnQ7CS8qIDJzIGNvbXBsZW1lbnQgb2YgYnVmZmVyIHNpemUgaW4gbG93IDE1IGJpdHMu CisJCQkJICogUmVjZWl2ZSB0ZXJtaW5hbCBjb3VudCBpbnRlcnJ1cHQgZW5hYmxlIGluCisJCQkJ ICogdG9wIGJpdC4KKwkJCQkgKi8KKwl2b2xhdGlsZSB1MTYgbWNudDsJLyogTWVzc2FnZSBieXRl IGNvdW50ICgxNSBiaXRzKSAqLwogfTsKIAogLyogQ29udmVydCBhIGxlbmd0aCBpbnRvIHRoZSAx NSBiaXQgMidzIGNvbXBsZW1lbnQgKi8KQEAgLTE0Niw1NyArMTYwLDk5IEBACiAjZGVmaW5lIGNu dl9iY250KGxlbikgICAoLShsZW4pKQogCiAvKiBTdGF0dXMgYW5kIGNvbmZpZyBiaXRzIGZvciB0 aGUgYWJvdmUgKi8KLSNkZWZpbmUgRE1BX09XTiAgICAgICAgIDB4ODAgICAgICAgICAgICAvKiBT bWFydERNQSBvd25zIHRoZSBkZXNjcmlwdG9yICovCi0jZGVmaW5lIFRYX1NUUCAgICAgICAgICAw eDAyICAgICAgICAgICAgLyogVHg6IHN0YXJ0IG9mIHBhY2tldCAqLwotI2RlZmluZSBUWF9FTlAg ICAgICAgICAgMHgwMSAgICAgICAgICAgIC8qIFR4OiBlbmQgb2YgcGFja2V0ICovCi0jZGVmaW5l IFJYX0VSUiAgICAgICAgICAweDQwICAgICAgICAgICAgLyogUng6IGVycm9yIChPUiBvZiBuZXh0 IDQgYml0cykgKi8KLSNkZWZpbmUgUlhfRlJBTSAgICAgICAgIDB4MjAgICAgICAgICAgICAvKiBS eDogZnJhbWluZyBlcnJvciAqLwotI2RlZmluZSBSWF9PRkxPICAgICAgICAgMHgxMCAgICAgICAg ICAgIC8qIFJ4OiBvdmVyZmxvdyBlcnJvciAqLwotI2RlZmluZSBSWF9DUkMgICAgICAgICAgMHgw OCAgICAgICAgICAgIC8qIFJ4OiBDUkMgZXJyb3IgKi8KLSNkZWZpbmUgUlhfSEJVRiAgICAgICAg IDB4MDQgICAgICAgICAgICAvKiBSeDogYnVmZmVyIGVycm9yICovCi0jZGVmaW5lIFJYX1NUUCAg ICAgICAgICAweDAyICAgICAgICAgICAgLyogUng6IHN0YXJ0IG9mIHBhY2tldCAqLwotI2RlZmlu ZSBSWF9FTlAgICAgICAgICAgMHgwMSAgICAgICAgICAgIC8qIFJ4OiBlbmQgb2YgcGFja2V0ICov Ci0KKyNkZWZpbmUgRE1BX09XTiAgICAgICAgIDB4ODAJLyogU21hcnRETUEgb3ducyB0aGUgZGVz Y3JpcHRvciAqLworI2RlZmluZSBUWF9TVFAgICAgICAgICAgMHgwMgkvKiBUeDogc3RhcnQgb2Yg cGFja2V0ICovCisjZGVmaW5lIFRYX0VOUCAgICAgICAgICAweDAxCS8qIFR4OiBlbmQgb2YgcGFj a2V0ICovCisjZGVmaW5lIFJYX0VSUiAgICAgICAgICAweDQwCS8qIFJ4OiBlcnJvciAoT1Igb2Yg bmV4dCA0IGJpdHMpICovCisjZGVmaW5lIFJYX0ZSQU0gICAgICAgICAweDIwCS8qIFJ4OiBmcmFt aW5nIGVycm9yICovCisjZGVmaW5lIFJYX09GTE8gICAgICAgICAweDEwCS8qIFJ4OiBvdmVyZmxv dyBlcnJvciAqLworI2RlZmluZSBSWF9DUkMgICAgICAgICAgMHgwOAkvKiBSeDogQ1JDIGVycm9y ICovCisjZGVmaW5lIFJYX0hCVUYgICAgICAgICAweDA0CS8qIFJ4OiBidWZmZXIgZXJyb3IgKi8K KyNkZWZpbmUgUlhfU1RQICAgICAgICAgIDB4MDIJLyogUng6IHN0YXJ0IG9mIHBhY2tldCAqLwor I2RlZmluZSBSWF9FTlAgICAgICAgICAgMHgwMQkvKiBSeDogZW5kIG9mIHBhY2tldCAqLwogCi0v KiBJbnRlcnJ1cHRzIGZyb20gdGhlIGNhcmQgYXJlIGNhdXNlZCBieSB2YXJpb3VzIGV2ZW50cyBh bmQgdGhlc2UgYXJlIHByZXNlbnRlZAorLyogSW50ZXJydXB0cyBmcm9tIHRoZSBjYXJkIGFyZSBj YXVzZWQgYnkgdmFyaW91cyBldmVudHMgd2hpY2ggYXJlIHByZXNlbnRlZAogICogaW4gYSBjaXJj dWxhciBidWZmZXIgYXMgc2V2ZXJhbCBldmVudHMgbWF5IGJlIHByb2Nlc3NlZCBvbiBvbmUgcGh5 c2ljYWwgaW50CiAgKi8KICNkZWZpbmUgTUFYX0NJUkJVRkYgICAgIDMyCiAKIHN0cnVjdCBjaXJi dWZmIHsKLSAgICAgICAgdTggcmRpbmRleDsgICAgICAgICAgICAgLyogcmVhZCwgdGhlbiBpbmNy ZW1lbnQgYW5kIHdyYXAgKi8KLSAgICAgICAgdTggd3JpbmRleDsgICAgICAgICAgICAgLyogd3Jp dGUsIHRoZW4gaW5jcmVtZW50IGFuZCB3cmFwICovCi0gICAgICAgIHU4IGV2bnRidWZmW01BWF9D SVJCVUZGXTsKKwl1OCByZGluZGV4OwkJLyogcmVhZCwgdGhlbiBpbmNyZW1lbnQgYW5kIHdyYXAg Ki8KKwl1OCB3cmluZGV4OwkJLyogd3JpdGUsIHRoZW4gaW5jcmVtZW50IGFuZCB3cmFwICovCisJ dTggZXZudGJ1ZmZbTUFYX0NJUkJVRkZdOwogfTsKIAogLyogSW50ZXJydXB0IGV2ZW50IGNvZGVz LgogICogV2hlcmUgYXBwcm9wcmlhdGUgdGhlIHR3byBsb3cgb3JkZXIgYml0cyBpbmRpY2F0ZSB0 aGUgcG9ydCBudW1iZXIKICAqLwotI2RlZmluZSBDVExBX0NIRyAgICAgICAgMHgxOCAgICAvKiBD b250cm9sIHNpZ25hbCBjaGFuZ2VkICovCisjZGVmaW5lIENUTEFfQ0hHICAgICAgICAweDE4CS8q IENvbnRyb2wgc2lnbmFsIGNoYW5nZWQgKi8KICNkZWZpbmUgQ1RMQl9DSEcgICAgICAgIDB4MTkK ICNkZWZpbmUgQ1RMQ19DSEcgICAgICAgIDB4MUEKICNkZWZpbmUgQ1RMRF9DSEcgICAgICAgIDB4 MUIKIAotI2RlZmluZSBJTklUX0NQTFQgICAgICAgMHgyMCAgICAvKiBJbml0aWFsaXNhdGlvbiBj b21wbGV0ZSAqLwotI2RlZmluZSBJTklUX0ZBSUwgICAgICAgMHgyMSAgICAvKiBJbml0aWFsaXNh dGlvbiBmYWlsZWQgKi8KKyNkZWZpbmUgSU5JVF9DUExUICAgICAgIDB4MjAJLyogSW5pdGlhbGlz YXRpb24gY29tcGxldGUgKi8KKyNkZWZpbmUgSU5JVF9GQUlMICAgICAgIDB4MjEJLyogSW5pdGlh bGlzYXRpb24gZmFpbGVkICovCiAKLSNkZWZpbmUgQUJUQV9TRU5UICAgICAgIDB4MjQgICAgLyog QWJvcnQgc2VudCAqLworI2RlZmluZSBBQlRBX1NFTlQgICAgICAgMHgyNAkvKiBBYm9ydCBzZW50 ICovCiAjZGVmaW5lIEFCVEJfU0VOVCAgICAgICAweDI1CiAjZGVmaW5lIEFCVENfU0VOVCAgICAg ICAweDI2CiAjZGVmaW5lIEFCVERfU0VOVCAgICAgICAweDI3CiAKLSNkZWZpbmUgVFhBX1VOREYg ICAgICAgIDB4MjggICAgLyogVHJhbnNtaXNzaW9uIHVuZGVyZmxvdyAqLworI2RlZmluZSBUWEFf VU5ERiAgICAgICAgMHgyOAkvKiBUcmFuc21pc3Npb24gdW5kZXJmbG93ICovCiAjZGVmaW5lIFRY Ql9VTkRGICAgICAgICAweDI5CiAjZGVmaW5lIFRYQ19VTkRGICAgICAgICAweDJBCiAjZGVmaW5l IFRYRF9VTkRGICAgICAgICAweDJCCiAKKyNkZWZpbmUgRjU2X0lOVCAgICAgICAgIDB4MkMKKyNk ZWZpbmUgTTMyX0lOVCAgICAgICAgIDB4MkQKKworI2RlZmluZSBURTFfQUxNQSAgICAgICAgMHgz MAogCiAvKiBQb3J0IHBoeXNpY2FsIGNvbmZpZ3VyYXRpb24uIFNlZSBmYXJzeW5jLmggZm9yIGZp ZWxkIHZhbHVlcyAqLwogc3RydWN0IHBvcnRfY2ZnIHsKLSAgICAgICAgdTE2ICBsaW5lSW50ZXJm YWNlOyAgICAgLyogUGh5c2ljYWwgaW50ZXJmYWNlIHR5cGUgKi8KLSAgICAgICAgdTggICB4MjVv cDsgICAgICAgICAgICAgLyogVW51c2VkIGF0IHByZXNlbnQgKi8KLSAgICAgICAgdTggICBpbnRl cm5hbENsb2NrOyAgICAgLyogMSA9PiBpbnRlcm5hbCBjbG9jaywgMCA9PiBleHRlcm5hbCAqLwot ICAgICAgICB1MzIgIGxpbmVTcGVlZDsgICAgICAgICAvKiBTcGVlZCBpbiBicHMgKi8KKwl1MTYg bGluZUludGVyZmFjZTsJLyogUGh5c2ljYWwgaW50ZXJmYWNlIHR5cGUgKi8KKwl1OCB4MjVvcDsJ CS8qIFVudXNlZCBhdCBwcmVzZW50ICovCisJdTggaW50ZXJuYWxDbG9jazsJLyogMSA9PiBpbnRl cm5hbCBjbG9jaywgMCA9PiBleHRlcm5hbCAqLworCXU4IHRyYW5zcGFyZW50TW9kZTsJLyogMSA9 PiBvbiwgMCA9PiBvZmYgKi8KKwl1OCBpbnZlcnRDbG9jazsJCS8qIDAgPT4gbm9ybWFsLCAxID0+ IGludmVydGVkICovCisJdTggcGFkQnl0ZXNbNl07CQkvKiBQYWRkaW5nICovCisJdTMyIGxpbmVT cGVlZDsJCS8qIFNwZWVkIGluIGJwcyAqLworfTsKKworLyogVEUxIHBvcnQgcGh5c2ljYWwgY29u ZmlndXJhdGlvbiAqLworc3RydWN0IHN1X2NvbmZpZyB7CisJdTMyIGRhdGFSYXRlOworCXU4IGNs b2NraW5nOworCXU4IGZyYW1pbmc7CisJdTggc3RydWN0dXJlOworCXU4IGludGVyZmFjZTsKKwl1 OCBjb2Rpbmc7CisJdTggbGluZUJ1aWxkT3V0OworCXU4IGVxdWFsaXplcjsKKwl1OCB0cmFuc3Bh cmVudE1vZGU7CisJdTggbG9vcE1vZGU7CisJdTggcmFuZ2U7CisJdTggdHhCdWZmZXJNb2RlOwor CXU4IHJ4QnVmZmVyTW9kZTsKKwl1OCBzdGFydGluZ1Nsb3Q7CisJdTggbG9zVGhyZXNob2xkOwor CXU4IGVuYWJsZUlkbGVDb2RlOworCXU4IGlkbGVDb2RlOworCXU4IHNwYXJlWzQ0XTsKK307CisK Ky8qIFRFMSBTdGF0dXMgKi8KK3N0cnVjdCBzdV9zdGF0dXMgeworCXUzMiByZWNlaXZlQnVmZmVy RGVsYXk7CisJdTMyIGZyYW1pbmdFcnJvckNvdW50OworCXUzMiBjb2RlVmlvbGF0aW9uQ291bnQ7 CisJdTMyIGNyY0Vycm9yQ291bnQ7CisJdTMyIGxpbmVBdHRlbnVhdGlvbjsKKwl1OCBwb3J0U3Rh cnRlZDsKKwl1OCBsb3NzT2ZTaWduYWw7CisJdTggcmVjZWl2ZVJlbW90ZUFsYXJtOworCXU4IGFs YXJtSW5kaWNhdGlvblNpZ25hbDsKKwl1OCBzcGFyZVs0MF07CiB9OwogCiAvKiBGaW5hbGx5IHNs aW5nIGFsbCB0aGUgYWJvdmUgdG9nZXRoZXIgaW50byB0aGUgc2hhcmVkIG1lbW9yeSBzdHJ1Y3R1 cmUuCkBAIC0yMDYsMTU0ICsyNjIsMjE2IEBACiAgKiBTZWUgZmFyc3luYy5oIGZvciBzb21lIGZp ZWxkIHZhbHVlcy4KICAqLwogc3RydWN0IGZzdF9zaGFyZWQgewotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvKiBETUEgZGVzY3JpcHRvciByaW5ncyAqLwotICAgICAgICBzdHJ1Y3Qg cnhkZXNjIHJ4RGVzY3JSaW5nW0ZTVF9NQVhfUE9SVFNdW05VTV9SWF9CVUZGRVJdOwotICAgICAg ICBzdHJ1Y3QgdHhkZXNjIHR4RGVzY3JSaW5nW0ZTVF9NQVhfUE9SVFNdW05VTV9UWF9CVUZGRVJd OworCS8qIERNQSBkZXNjcmlwdG9yIHJpbmdzICovCisJc3RydWN0IHJ4ZGVzYyByeERlc2NyUmlu Z1tGU1RfTUFYX1BPUlRTXVtOVU1fUlhfQlVGRkVSXTsKKwlzdHJ1Y3QgdHhkZXNjIHR4RGVzY3JS aW5nW0ZTVF9NQVhfUE9SVFNdW05VTV9UWF9CVUZGRVJdOworCisJLyogT2Jzb2xldGUgc21hbGwg YnVmZmVycyAqLworCXU4IHNtYWxsUnhCdWZmZXJbRlNUX01BWF9QT1JUU11bTlVNX1JYX0JVRkZF Ul1bTEVOX1NNQUxMX1JYX0JVRkZFUl07CisJdTggc21hbGxUeEJ1ZmZlcltGU1RfTUFYX1BPUlRT XVtOVU1fVFhfQlVGRkVSXVtMRU5fU01BTExfVFhfQlVGRkVSXTsKIAotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvKiBPYnNvbGV0ZSBzbWFsbCBidWZmZXJzICovCi0gICAgICAgIHU4 ICBzbWFsbFJ4QnVmZmVyW0ZTVF9NQVhfUE9SVFNdW05VTV9SWF9CVUZGRVJdW0xFTl9TTUFMTF9S WF9CVUZGRVJdOwotICAgICAgICB1OCAgc21hbGxUeEJ1ZmZlcltGU1RfTUFYX1BPUlRTXVtOVU1f VFhfQlVGRkVSXVtMRU5fU01BTExfVFhfQlVGRkVSXTsKKwl1OCB0YXNrU3RhdHVzOwkJLyogMHgw MCA9PiBpbml0aWFsaXNpbmcsIDB4MDEgPT4gcnVubmluZywKKwkJCQkgKiAweEZGID0+IGhhbHRl ZAorCQkJCSAqLwogCi0gICAgICAgIHU4ICB0YXNrU3RhdHVzOyAgICAgICAgIC8qIDB4MDAgPT4g aW5pdGlhbGlzaW5nLCAweDAxID0+IHJ1bm5pbmcsCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqIDB4RkYgPT4gaGFsdGVkCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAqLworCXU4IGludGVycnVwdEhhbmRzaGFrZTsJLyogU2V0IHRvIDB4MDEgYnkgYWRhcHRlciB0 byBzaWduYWwgaW50ZXJydXB0LAorCQkJCSAqIHNldCB0byAweEVFIGJ5IGhvc3QgdG8gYWNrbm93 bGVkZ2UgaW50ZXJydXB0CisJCQkJICovCiAKLSAgICAgICAgdTggIGludGVycnVwdEhhbmRzaGFr ZTsgLyogU2V0IHRvIDB4MDEgYnkgYWRhcHRlciB0byBzaWduYWwgaW50ZXJydXB0LAotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBzZXQgdG8gMHhFRSBieSBob3N0IHRvIGFja25v d2xlZGdlIGludGVycnVwdAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKwl1 MTYgc21jVmVyc2lvbjsJCS8qIE11c3QgbWF0Y2ggU01DX1ZFUlNJT04gKi8KIAotICAgICAgICB1 MTYgc21jVmVyc2lvbjsgICAgICAgICAvKiBNdXN0IG1hdGNoIFNNQ19WRVJTSU9OICovCisJdTMy IHNtY0Zpcm13YXJlVmVyc2lvbjsJLyogMHhJSVZWUlJCQiB3aGVyZSBJSSA9IHByb2R1Y3QgSUQs IFZWID0gbWFqb3IKKwkJCQkgKiB2ZXJzaW9uLCBSUiA9IHJldmlzaW9uIGFuZCBCQiA9IGJ1aWxk CisJCQkJICovCiAKLSAgICAgICAgdTMyIHNtY0Zpcm13YXJlVmVyc2lvbjsgLyogMHhJSVZWUlJC QiB3aGVyZSBJSSA9IHByb2R1Y3QgSUQsIFZWID0gbWFqb3IKLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICogdmVyc2lvbiwgUlIgPSByZXZpc2lvbiBhbmQgQkIgPSBidWlsZAotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKwl1MTYgdHhhX2RvbmU7CQkvKiBPYnNv bGV0ZSBjb21wbGV0aW9uIGZsYWdzICovCisJdTE2IHJ4YV9kb25lOworCXUxNiB0eGJfZG9uZTsK Kwl1MTYgcnhiX2RvbmU7CisJdTE2IHR4Y19kb25lOworCXUxNiByeGNfZG9uZTsKKwl1MTYgdHhk X2RvbmU7CisJdTE2IHJ4ZF9kb25lOwogCi0gICAgICAgIHUxNiB0eGFfZG9uZTsgICAgICAgICAg IC8qIE9ic29sZXRlIGNvbXBsZXRpb24gZmxhZ3MgKi8KLSAgICAgICAgdTE2IHJ4YV9kb25lOwot ICAgICAgICB1MTYgdHhiX2RvbmU7Ci0gICAgICAgIHUxNiByeGJfZG9uZTsKLSAgICAgICAgdTE2 IHR4Y19kb25lOwotICAgICAgICB1MTYgcnhjX2RvbmU7Ci0gICAgICAgIHUxNiB0eGRfZG9uZTsK LSAgICAgICAgdTE2IHJ4ZF9kb25lOworCXUxNiBtYWlsYm94WzRdOwkJLyogRGlhZ25vc3RpY3Mg bWFpbGJveC4gTm90IHVzZWQgKi8KIAotICAgICAgICB1MTYgbWFpbGJveFs0XTsgICAgICAgICAv KiBEaWFnbm9zdGljcyBtYWlsYm94LiBOb3QgdXNlZCAqLworCXN0cnVjdCBjaXJidWZmIGludGVy cnVwdEV2ZW50OwkvKiBpbnRlcnJ1cHQgY2F1c2VzICovCiAKLSAgICAgICAgc3RydWN0IGNpcmJ1 ZmYgaW50ZXJydXB0RXZlbnQ7ICAvKiBpbnRlcnJ1cHQgY2F1c2VzICovCisJdTMyIHYyNElwU3Rz W0ZTVF9NQVhfUE9SVFNdOwkvKiBWLjI0IGNvbnRyb2wgaW5wdXQgc3RhdHVzICovCisJdTMyIHYy NE9wU3RzW0ZTVF9NQVhfUE9SVFNdOwkvKiBWLjI0IGNvbnRyb2wgb3V0cHV0IHN0YXR1cyAqLwog Ci0gICAgICAgIHUzMiB2MjRJcFN0c1tGU1RfTUFYX1BPUlRTXTsgICAgLyogVi4yNCBjb250cm9s IGlucHV0IHN0YXR1cyAqLwotICAgICAgICB1MzIgdjI0T3BTdHNbRlNUX01BWF9QT1JUU107ICAg IC8qIFYuMjQgY29udHJvbCBvdXRwdXQgc3RhdHVzICovCisJc3RydWN0IHBvcnRfY2ZnIHBvcnRD b25maWdbRlNUX01BWF9QT1JUU107CiAKLSAgICAgICAgc3RydWN0IHBvcnRfY2ZnIHBvcnRDb25m aWdbRlNUX01BWF9QT1JUU107CisJdTE2IGNsb2NrU3RhdHVzW0ZTVF9NQVhfUE9SVFNdOwkvKiBs c2I6IDA9PiBwcmVzZW50LCAxPT4gYWJzZW50ICovCiAKLSAgICAgICAgdTE2IGNsb2NrU3RhdHVz W0ZTVF9NQVhfUE9SVFNdOyAvKiBsc2I6IDA9PiBwcmVzZW50LCAxPT4gYWJzZW50ICovCisJdTE2 IGNhYmxlU3RhdHVzOwkvKiBsc2I6IDA9PiBwcmVzZW50LCAxPT4gYWJzZW50ICovCiAKLSAgICAg ICAgdTE2IGNhYmxlU3RhdHVzOyAgICAgICAgICAgICAgICAvKiBsc2I6IDA9PiBwcmVzZW50LCAx PT4gYWJzZW50ICovCisJdTE2IHR4RGVzY3JJbmRleFtGU1RfTUFYX1BPUlRTXTsJLyogdHJhbnNt aXQgZGVzY3JpcHRvciByaW5nIGluZGV4ICovCisJdTE2IHJ4RGVzY3JJbmRleFtGU1RfTUFYX1BP UlRTXTsJLyogcmVjZWl2ZSBkZXNjcmlwdG9yIHJpbmcgaW5kZXggKi8KIAotICAgICAgICB1MTYg dHhEZXNjckluZGV4W0ZTVF9NQVhfUE9SVFNdOyAvKiB0cmFuc21pdCBkZXNjcmlwdG9yIHJpbmcg aW5kZXggKi8KLSAgICAgICAgdTE2IHJ4RGVzY3JJbmRleFtGU1RfTUFYX1BPUlRTXTsgLyogcmVj ZWl2ZSBkZXNjcmlwdG9yIHJpbmcgaW5kZXggKi8KKwl1MTYgcG9ydE1haWxib3hbRlNUX01BWF9Q T1JUU11bMl07CS8qIGNvbW1hbmQsIG1vZGlmaWVyICovCisJdTE2IGNhcmRNYWlsYm94WzRdOwkv KiBOb3QgdXNlZCAqLwogCi0gICAgICAgIHUxNiBwb3J0TWFpbGJveFtGU1RfTUFYX1BPUlRTXVsy XTsgICAgICAvKiBjb21tYW5kLCBtb2RpZmllciAqLwotICAgICAgICB1MTYgY2FyZE1haWxib3hb NF07ICAgICAgICAgICAgICAgICAgICAgLyogTm90IHVzZWQgKi8KKwkvKiBOdW1iZXIgb2YgdGlt ZXMgdGhlIGNhcmQgdGhpbmtzIHRoZSBob3N0IGhhcworCSAqIG1pc3NlZCBhbiBpbnRlcnJ1cHQg Ynkgbm90IGFja25vd2xlZGdpbmcKKwkgKiB3aXRoaW4gMm1TIChJIGd1ZXNzIE5UIGhhcyBwcm9i bGVtcykKKwkgKi8KKwl1MzIgaW50ZXJydXB0UmV0cnlDb3VudDsKIAotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAvKiBOdW1iZXIgb2YgdGltZXMgdGhhdCBjYXJkIHRoaW5rcyB0aGUg aG9zdCBoYXMKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogbWlzc2VkIGFuIGlu dGVycnVwdCBieSBub3QgYWNrbm93bGVkZ2luZwotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKiB3aXRoaW4gMm1TIChJIGd1ZXNzIE5UIGhhcyBwcm9ibGVtcykKLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICovCi0gICAgICAgIHUzMiBpbnRlcnJ1cHRSZXRyeUNvdW50 OworCS8qIERyaXZlciBwcml2YXRlIGRhdGEgdXNlZCBhcyBhbiBJRC4gV2UnbGwgbm90CisJICog dXNlIHRoaXMgYXMgSSdkIHJhdGhlciBrZWVwIHN1Y2ggdGhpbmdzCisJICogaW4gbWFpbiBtZW1v cnkgcmF0aGVyIHRoYW4gb24gdGhlIFBDSSBidXMKKwkgKi8KKwl1MzIgcG9ydEhhbmRsZVtGU1Rf TUFYX1BPUlRTXTsKIAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvKiBEcml2ZXIg cHJpdmF0ZSBkYXRhIHVzZWQgYXMgYW4gSUQuIFdlJ2xsIG5vdAotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKiB1c2UgdGhpcyBvbiBMaW51eCBJJ2QgcmF0aGVyIGtlZXAgc3VjaCB0 aGluZ3MKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogaW4gbWFpbiBtZW1vcnkg cmF0aGVyIHRoYW4gb24gdGhlIFBDSSBidXMKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICovCi0gICAgICAgIHUzMiBwb3J0SGFuZGxlW0ZTVF9NQVhfUE9SVFNdOworCS8qIENvdW50 IG9mIFR4IHVuZGVyZmxvd3MgZm9yIHN0YXRzICovCisJdTMyIHRyYW5zbWl0QnVmZmVyVW5kZXJm bG93W0ZTVF9NQVhfUE9SVFNdOwogCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8q IENvdW50IG9mIFR4IHVuZGVyZmxvd3MgZm9yIHN0YXRzICovCi0gICAgICAgIHUzMiB0cmFuc21p dEJ1ZmZlclVuZGVyZmxvd1tGU1RfTUFYX1BPUlRTXTsKKwkvKiBEZWJvdW5jZWQgVi4yNCBjb250 cm9sIGlucHV0IHN0YXR1cyAqLworCXUzMiB2MjREZWJvdW5jZWRTdHNbRlNUX01BWF9QT1JUU107 CiAKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogRGVib3VuY2VkIFYuMjQgY29u dHJvbCBpbnB1dCBzdGF0dXMgKi8KLSAgICAgICAgdTMyIHYyNERlYm91bmNlZFN0c1tGU1RfTUFY X1BPUlRTXTsKKwkvKiBBZGFwdGVyIGRlYm91bmNlIHRpbWVycy4gRG9uJ3QgdG91Y2ggKi8KKwl1 MzIgY3RzVGltZXJbRlNUX01BWF9QT1JUU107CisJdTMyIGN0c1RpbWVyUnVuW0ZTVF9NQVhfUE9S VFNdOworCXUzMiBkY2RUaW1lcltGU1RfTUFYX1BPUlRTXTsKKwl1MzIgZGNkVGltZXJSdW5bRlNU X01BWF9QT1JUU107CiAKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogQWRhcHRl ciBkZWJvdW5jZSB0aW1lcnMuIERvbid0IHRvdWNoICovCi0gICAgICAgIHUzMiBjdHNUaW1lcltG U1RfTUFYX1BPUlRTXTsKLSAgICAgICAgdTMyIGN0c1RpbWVyUnVuW0ZTVF9NQVhfUE9SVFNdOwot ICAgICAgICB1MzIgZGNkVGltZXJbRlNUX01BWF9QT1JUU107Ci0gICAgICAgIHUzMiBkY2RUaW1l clJ1bltGU1RfTUFYX1BPUlRTXTsKKwl1MzIgbnVtYmVyT2ZQb3J0czsJLyogTnVtYmVyIG9mIHBv cnRzIGRldGVjdGVkIGF0IHN0YXJ0dXAgKi8KIAotICAgICAgICB1MzIgbnVtYmVyT2ZQb3J0czsg ICAgICAvKiBOdW1iZXIgb2YgcG9ydHMgZGV0ZWN0ZWQgYXQgc3RhcnR1cCAqLworCXUxNiBfcmVz ZXJ2ZWRbNjRdOwogCi0gICAgICAgIHUxNiBfcmVzZXJ2ZWRbNjRdOworCXUxNiBjYXJkTW9kZTsJ CS8qIEJpdC1tYXNrIHRvIGVuYWJsZSBmZWF0dXJlczoKKwkJCQkgKiBCaXQgMDogMSBlbmFibGVz IExFRCBpZGVudGlmeSBtb2RlCisJCQkJICovCiAKLSAgICAgICAgdTE2IGNhcmRNb2RlOyAgICAg ICAgICAgLyogQml0LW1hc2sgdG8gZW5hYmxlIGZlYXR1cmVzOgotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKiBCaXQgMDogMSBlbmFibGVzIExFRCBpZGVudGlmeSBtb2RlCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLworCXUxNiBwb3J0U2NoZWR1bGVPZmZzZXQ7 CiAKLSAgICAgICAgdTE2IHBvcnRTY2hlZHVsZU9mZnNldDsKKwlzdHJ1Y3Qgc3VfY29uZmlnIHN1 Q29uZmlnOwkvKiBURTEgQml0cyAqLworCXN0cnVjdCBzdV9zdGF0dXMgc3VTdGF0dXM7CiAKLSAg ICAgICAgdTMyIGVuZE9mU21jU2lnbmF0dXJlOyAgLyogZW5kT2ZTbWNTaWduYXR1cmUgTVVTVCBi ZSB0aGUgbGFzdCBtZW1iZXIgb2YKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICog dGhlIHN0cnVjdHVyZSBhbmQgbWFya3MgdGhlIGVuZCBvZiB0aGUgc2hhcmVkCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAqIG1lbW9yeS4gQWRhcHRlciBjb2RlIGluaXRpYWxpemVz IGl0cyB2YWx1ZSBhcwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBFTkRfU0lH LgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKwl1MzIgZW5kT2ZTbWNTaWdu YXR1cmU7CS8qIGVuZE9mU21jU2lnbmF0dXJlIE1VU1QgYmUgdGhlIGxhc3QgbWVtYmVyIG9mCisJ CQkJICogdGhlIHN0cnVjdHVyZSBhbmQgbWFya3MgdGhlIGVuZCBvZiBzaGFyZWQKKwkJCQkgKiBt ZW1vcnkuIEFkYXB0ZXIgY29kZSBpbml0aWFsaXplcyBpdCBhcworCQkJCSAqIEVORF9TSUcuCisJ CQkJICovCiB9OwogCiAvKiBlbmRPZlNtY1NpZ25hdHVyZSB2YWx1ZSAqLwogI2RlZmluZSBFTkRf U0lHICAgICAgICAgICAgICAgICAweDEyMzQ1Njc4CiAKIC8qIE1haWxib3ggdmFsdWVzLiAocG9y dE1haWxib3gpICovCi0jZGVmaW5lIE5PUCAgICAgICAgICAgICAwICAgICAgIC8qIE5vIG9wZXJh dGlvbiAqLwotI2RlZmluZSBBQ0sgICAgICAgICAgICAgMSAgICAgICAvKiBQb3NpdGl2ZSBhY2tu b3dsZWRnZW1lbnQgdG8gUEMgZHJpdmVyICovCi0jZGVmaW5lIE5BSyAgICAgICAgICAgICAyICAg ICAgIC8qIE5lZ2F0aXZlIGFja25vd2xlZGdlbWVudCB0byBQQyBkcml2ZXIgKi8KLSNkZWZpbmUg U1RBUlRQT1JUICAgICAgIDMgICAgICAgLyogU3RhcnQgYW4gSERMQyBwb3J0ICovCi0jZGVmaW5l IFNUT1BQT1JUICAgICAgICA0ICAgICAgIC8qIFN0b3AgYW4gSERMQyBwb3J0ICovCi0jZGVmaW5l IEFCT1JUVFggICAgICAgICA1ICAgICAgIC8qIEFib3J0IHRoZSB0cmFuc21pdHRlciBmb3IgYSBw b3J0ICovCi0jZGVmaW5lIFNFVFYyNE8gICAgICAgICA2ICAgICAgIC8qIFNldCBWMjQgb3V0cHV0 cyAqLworI2RlZmluZSBOT1AgICAgICAgICAgICAgMAkvKiBObyBvcGVyYXRpb24gKi8KKyNkZWZp bmUgQUNLICAgICAgICAgICAgIDEJLyogUG9zaXRpdmUgYWNrbm93bGVkZ2VtZW50IHRvIFBDIGRy aXZlciAqLworI2RlZmluZSBOQUsgICAgICAgICAgICAgMgkvKiBOZWdhdGl2ZSBhY2tub3dsZWRn ZW1lbnQgdG8gUEMgZHJpdmVyICovCisjZGVmaW5lIFNUQVJUUE9SVCAgICAgICAzCS8qIFN0YXJ0 IGFuIEhETEMgcG9ydCAqLworI2RlZmluZSBTVE9QUE9SVCAgICAgICAgNAkvKiBTdG9wIGFuIEhE TEMgcG9ydCAqLworI2RlZmluZSBBQk9SVFRYICAgICAgICAgNQkvKiBBYm9ydCB0aGUgdHJhbnNt aXR0ZXIgZm9yIGEgcG9ydCAqLworI2RlZmluZSBTRVRWMjRPICAgICAgICAgNgkvKiBTZXQgVjI0 IG91dHB1dHMgKi8KKworLyogUExYIENoaXAgUmVnaXN0ZXIgT2Zmc2V0cyAqLworI2RlZmluZSBD TlRSTF85MDUyICAgICAgMHg1MAkvKiBDb250cm9sIFJlZ2lzdGVyICovCisjZGVmaW5lIENOVFJM XzkwNTQgICAgICAweDZjCS8qIENvbnRyb2wgUmVnaXN0ZXIgKi8KIAorI2RlZmluZSBJTlRDU1Jf OTA1MiAgICAgMHg0YwkvKiBJbnRlcnJ1cHQgY29udHJvbC9zdGF0dXMgcmVnaXN0ZXIgKi8KKyNk ZWZpbmUgSU5UQ1NSXzkwNTQgICAgIDB4NjgJLyogSW50ZXJydXB0IGNvbnRyb2wvc3RhdHVzIHJl Z2lzdGVyICovCisKKy8qIDkwNTQgRE1BIFJlZ2lzdGVycyAqLworLyoKKyAqIE5vdGUgdGhhdCB3 ZSB3aWxsIGJlIHVzaW5nIERNQSBDaGFubmVsIDAgZm9yIGNvcHlpbmcgcnggZGF0YQorICogYW5k IENoYW5uZWwgMSBmb3IgY29weWluZyB0eCBkYXRhCisgKi8KKyNkZWZpbmUgRE1BTU9ERTAgICAg ICAgIDB4ODAKKyNkZWZpbmUgRE1BUEFEUjAgICAgICAgIDB4ODQKKyNkZWZpbmUgRE1BTEFEUjAg ICAgICAgIDB4ODgKKyNkZWZpbmUgRE1BU0laMCAgICAgICAgIDB4OGMKKyNkZWZpbmUgRE1BRFBS MCAgICAgICAgIDB4OTAKKyNkZWZpbmUgRE1BTU9ERTEgICAgICAgIDB4OTQKKyNkZWZpbmUgRE1B UEFEUjEgICAgICAgIDB4OTgKKyNkZWZpbmUgRE1BTEFEUjEgICAgICAgIDB4OWMKKyNkZWZpbmUg RE1BU0laMSAgICAgICAgIDB4YTAKKyNkZWZpbmUgRE1BRFBSMSAgICAgICAgIDB4YTQKKyNkZWZp bmUgRE1BQ1NSMCAgICAgICAgIDB4YTgKKyNkZWZpbmUgRE1BQ1NSMSAgICAgICAgIDB4YTkKKyNk ZWZpbmUgRE1BQVJCICAgICAgICAgIDB4YWMKKyNkZWZpbmUgRE1BVEhSICAgICAgICAgIDB4YjAK KyNkZWZpbmUgRE1BREFDMCAgICAgICAgIDB4YjQKKyNkZWZpbmUgRE1BREFDMSAgICAgICAgIDB4 YjgKKyNkZWZpbmUgRE1BTUFSQlIgICAgICAgIDB4YWMKKworI2RlZmluZSBGU1RfTUlOX0RNQV9M RU4gNjQKKyNkZWZpbmUgRlNUX1JYX0RNQV9JTlQgIDB4MDEKKyNkZWZpbmUgRlNUX1RYX0RNQV9J TlQgIDB4MDIKKyNkZWZpbmUgRlNUX0NBUkRfSU5UICAgIDB4MDQKIAogLyogTGFyZ2VyIGJ1ZmZl cnMgYXJlIHBvc2l0aW9uZWQgaW4gbWVtb3J5IGF0IG9mZnNldCBCRk1fQkFTRSAqLwogc3RydWN0 IGJ1Zl93aW5kb3cgewotICAgICAgICB1OCB0eEJ1ZmZlcltGU1RfTUFYX1BPUlRTXVtOVU1fVFhf QlVGRkVSXVtMRU5fVFhfQlVGRkVSXTsKLSAgICAgICAgdTggcnhCdWZmZXJbRlNUX01BWF9QT1JU U11bTlVNX1JYX0JVRkZFUl1bTEVOX1JYX0JVRkZFUl07CisJdTggdHhCdWZmZXJbRlNUX01BWF9Q T1JUU11bTlVNX1RYX0JVRkZFUl1bTEVOX1RYX0JVRkZFUl07CisJdTggcnhCdWZmZXJbRlNUX01B WF9QT1JUU11bTlVNX1JYX0JVRkZFUl1bTEVOX1JYX0JVRkZFUl07CiB9OwogCiAvKiBDYWxjdWxh dGUgb2Zmc2V0IG9mIGEgYnVmZmVyIG9iamVjdCB3aXRoaW4gdGhlIHNoYXJlZCBtZW1vcnkgd2lu ZG93ICovCi0jZGVmaW5lIEJVRl9PRkZTRVQoWCkgICBvZmZzZXRvZihzdHJ1Y3QgYnVmX3dpbmRv dywgWCkKKyNkZWZpbmUgQlVGX09GRlNFVChYKSAgICgodW5zaWduZWQgaW50KSYoKChzdHJ1Y3Qg YnVmX3dpbmRvdyAqKUJGTV9CQVNFKS0+WCkpCiAKICNwcmFnbWEgcGFjaygpCiAKLQogLyogICAg ICBEZXZpY2UgZHJpdmVyIHByaXZhdGUgaW5mb3JtYXRpb24KICAqICAgICAgPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09CiAgKi8KIC8qICAgICAgUGVyIHBvcnQgKGxpbmUgb3IgY2hh bm5lbCkgaW5mb3JtYXRpb24KICAqLwogc3RydWN0IGZzdF9wb3J0X2luZm8gewotICAgICAgICBz dHJ1Y3QgbmV0X2RldmljZSAgICAgICpkZXY7Ci0gICAgICAgIHN0cnVjdCBmc3RfY2FyZF9pbmZv ICAgKmNhcmQ7ICAgLyogQ2FyZCB3ZSdyZSBhc3NvY2lhdGVkIHdpdGggKi8KLSAgICAgICAgaW50 ICAgICAgICAgICAgICAgICAgICAgaW5kZXg7ICAvKiBQb3J0IGluZGV4IG9uIHRoZSBjYXJkICov Ci0gICAgICAgIGludCAgICAgICAgICAgICAgICAgICAgIGh3aWY7ICAgLyogTGluZSBoYXJkd2Fy ZSAobGluZUludGVyZmFjZSBjb3B5KSAqLwotICAgICAgICBpbnQgICAgICAgICAgICAgICAgICAg ICBydW47ICAgIC8qIFBvcnQgaXMgcnVubmluZyAqLwotICAgICAgICBpbnQgICAgICAgICAgICAg ICAgICAgICByeHBvczsgIC8qIE5leHQgUnggYnVmZmVyIHRvIHVzZSAqLwotICAgICAgICBpbnQg ICAgICAgICAgICAgICAgICAgICB0eHBvczsgIC8qIE5leHQgVHggYnVmZmVyIHRvIHVzZSAqLwot ICAgICAgICBpbnQgICAgICAgICAgICAgICAgICAgICB0eGlwb3M7IC8qIE5leHQgVHggYnVmZmVy IHRvIGNoZWNrIGZvciBmcmVlICovCi0gICAgICAgIGludCAgICAgICAgICAgICAgICAgICAgIHR4 Y250OyAgLyogQ291bnQgb2YgVHggYnVmZmVycyBpbiB1c2UgKi8KKyAgICAgICAgc3RydWN0IG5l dF9kZXZpY2UgKmRldjsgLyogRGV2aWNlIHN0cnVjdCAtIG11c3QgYmUgZmlyc3QgKi8KKwlzdHJ1 Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZDsJLyogQ2FyZCB3ZSdyZSBhc3NvY2lhdGVkIHdpdGggKi8K KwlpbnQgaW5kZXg7CQkvKiBQb3J0IGluZGV4IG9uIHRoZSBjYXJkICovCisJaW50IGh3aWY7CQkv KiBMaW5lIGhhcmR3YXJlIChsaW5lSW50ZXJmYWNlIGNvcHkpICovCisJaW50IHJ1bjsJCS8qIFBv cnQgaXMgcnVubmluZyAqLworCWludCBtb2RlOwkJLyogTm9ybWFsIG9yIEZhclN5bmMgcmF3ICov CisJaW50IHJ4cG9zOwkJLyogTmV4dCBSeCBidWZmZXIgdG8gdXNlICovCisJaW50IHR4cG9zOwkJ LyogTmV4dCBUeCBidWZmZXIgdG8gdXNlICovCisJaW50IHR4aXBvczsJCS8qIE5leHQgVHggYnVm ZmVyIHRvIGNoZWNrIGZvciBmcmVlICovCisJaW50IHN0YXJ0OwkJLyogSW5kaWNhdGlvbiBvZiBz dGFydC9zdG9wIHRvIG5ldHdvcmsgKi8KKwkvKgorCSAqIEEgc2l4dGVlbiBlbnRyeSB0cmFuc21p dCBxdWV1ZQorCSAqLworCWludCB0eHFzOwkJLyogaW5kZXggdG8gZ2V0IG5leHQgYnVmZmVyIHRv IHR4ICovCisJaW50IHR4cWU7CQkvKiBpbmRleCB0byBxdWV1ZSBuZXh0IHBhY2tldCAqLworCXN0 cnVjdCBza19idWZmICp0eHFbRlNUX1RYUV9ERVBUSF07CS8qIFRoZSBxdWV1ZSAqLworCWludCBy eHFkZXB0aDsKIH07CiAKIC8qICAgICAgUGVyIGNhcmQgaW5mb3JtYXRpb24KICAqLwogc3RydWN0 IGZzdF9jYXJkX2luZm8gewotICAgICAgICBjaGFyICAgICAgICAgICptZW07ICAgICAgICAgICAg IC8qIENhcmQgbWVtb3J5IG1hcHBlZCB0byBrZXJuZWwgc3BhY2UgKi8KLSAgICAgICAgY2hhciAg ICAgICAgICAqY3RsbWVtOyAgICAgICAgICAvKiBDb250cm9sIG1lbW9yeSBmb3IgUENJIGNhcmRz ICovCi0gICAgICAgIHVuc2lnbmVkIGludCAgIHBoeXNfbWVtOyAgICAgICAgLyogUGh5c2ljYWwg bWVtb3J5IHdpbmRvdyBhZGRyZXNzICovCi0gICAgICAgIHVuc2lnbmVkIGludCAgIHBoeXNfY3Rs bWVtOyAgICAgLyogUGh5c2ljYWwgY29udHJvbCBtZW1vcnkgYWRkcmVzcyAqLwotICAgICAgICB1 bnNpZ25lZCBpbnQgICBpcnE7ICAgICAgICAgICAgIC8qIEludGVycnVwdCByZXF1ZXN0IGxpbmUg bnVtYmVyICovCi0gICAgICAgIHVuc2lnbmVkIGludCAgIG5wb3J0czsgICAgICAgICAgLyogTnVt YmVyIG9mIHNlcmlhbCBwb3J0cyAqLwotICAgICAgICB1bnNpZ25lZCBpbnQgICB0eXBlOyAgICAg ICAgICAgIC8qIFR5cGUgaW5kZXggb2YgY2FyZCAqLwotICAgICAgICB1bnNpZ25lZCBpbnQgICBz dGF0ZTsgICAgICAgICAgIC8qIFN0YXRlIG9mIGNhcmQgKi8KLSAgICAgICAgc3BpbmxvY2tfdCAg ICAgY2FyZF9sb2NrOyAgICAgICAvKiBMb2NrIGZvciBTTVAgYWNjZXNzICovCi0gICAgICAgIHVu c2lnbmVkIHNob3J0IHBjaV9jb25mOyAgICAgICAgLyogUENJIGNhcmQgY29uZmlnIGluIEkvTyBz cGFjZSAqLwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIFBlciBw b3J0IGluZm8gKi8KLSAgICAgICAgc3RydWN0IGZzdF9wb3J0X2luZm8gcG9ydHNbIEZTVF9NQVhf UE9SVFMgXTsKKwljaGFyICptZW07CQkvKiBDYXJkIG1lbW9yeSBtYXBwZWQgdG8ga2VybmVsIHNw YWNlICovCisJY2hhciAqY3RsbWVtOwkJLyogQ29udHJvbCBtZW1vcnkgZm9yIFBDSSBjYXJkcyAq LworCXVuc2lnbmVkIGludCBwaHlzX21lbTsJLyogUGh5c2ljYWwgbWVtb3J5IHdpbmRvdyBhZGRy ZXNzICovCisJdW5zaWduZWQgaW50IHBoeXNfY3RsbWVtOwkvKiBQaHlzaWNhbCBjb250cm9sIG1l bW9yeSBhZGRyZXNzICovCisJdW5zaWduZWQgaW50IGlycTsJLyogSW50ZXJydXB0IHJlcXVlc3Qg bGluZSBudW1iZXIgKi8KKwl1bnNpZ25lZCBpbnQgbnBvcnRzOwkvKiBOdW1iZXIgb2Ygc2VyaWFs IHBvcnRzICovCisJdW5zaWduZWQgaW50IHR5cGU7CS8qIFR5cGUgaW5kZXggb2YgY2FyZCAqLwor CXVuc2lnbmVkIGludCBzdGF0ZTsJLyogU3RhdGUgb2YgY2FyZCAqLworCXNwaW5sb2NrX3QgY2Fy ZF9sb2NrOwkvKiBMb2NrIGZvciBTTVAgYWNjZXNzICovCisJdW5zaWduZWQgc2hvcnQgcGNpX2Nv bmY7CS8qIFBDSSBjYXJkIGNvbmZpZyBpbiBJL08gc3BhY2UgKi8KKwkvKiBQZXIgcG9ydCBpbmZv ICovCisJc3RydWN0IGZzdF9wb3J0X2luZm8gcG9ydHNbRlNUX01BWF9QT1JUU107CisJc3RydWN0 IHBjaV9kZXYgKmRldmljZTsJLyogSW5mb3JtYXRpb24gYWJvdXQgdGhlIHBjaSBkZXZpY2UgKi8K KwlpbnQgY2FyZF9ubzsJCS8qIEluc3Qgb2YgdGhlIGNhcmQgb24gdGhlIHN5c3RlbSAqLworCWlu dCBmYW1pbHk7CQkvKiBUeFAgb3IgVHhVICovCisJaW50IGRtYXJ4X2luX3Byb2dyZXNzOworCWlu dCBkbWF0eF9pbl9wcm9ncmVzczsKKwl1bnNpZ25lZCBsb25nIGludF9jb3VudDsKKwl1bnNpZ25l ZCBsb25nIGludF90aW1lX2F2ZTsKKwl2b2lkICpyeF9kbWFfaGFuZGxlX2hvc3Q7CisJZG1hX2Fk ZHJfdCByeF9kbWFfaGFuZGxlX2NhcmQ7CisJdm9pZCAqdHhfZG1hX2hhbmRsZV9ob3N0OworCWRt YV9hZGRyX3QgdHhfZG1hX2hhbmRsZV9jYXJkOworCXN0cnVjdCBza19idWZmICpkbWFfc2tiX3J4 OworCXN0cnVjdCBmc3RfcG9ydF9pbmZvICpkbWFfcG9ydF9yeDsKKwlzdHJ1Y3QgZnN0X3BvcnRf aW5mbyAqZG1hX3BvcnRfdHg7CisJaW50IGRtYV9sZW5fcng7CisJaW50IGRtYV9sZW5fdHg7CisJ aW50IGRtYV90eHBvczsKKwlpbnQgZG1hX3J4cG9zOwogfTsKIAogLyogQ29udmVydCBhbiBIRExD IGRldmljZSBwb2ludGVyIGludG8gYSBwb3J0IGluZm8gcG9pbnRlciBhbmQgc2ltaWxhciAqLwpA QCAtMzgwLDcgKzQ5OCw2IEBACiAjZGVmaW5lIEZTVF9XUlcoQyxFLFcpICB3cml0ZXcgKChXKSwg KEMpLT5tZW0gKyBXSU5fT0ZGU0VUKEUpKQogI2RlZmluZSBGU1RfV1JMKEMsRSxMKSAgd3JpdGVs ICgoTCksIChDKS0+bWVtICsgV0lOX09GRlNFVChFKSkKIAotCiAvKgogICogICAgICBEZWJ1ZyBz dXBwb3J0CiAgKi8KQEAgLTM5OSwzMCArNTE2LDE1MSBAQAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBwcmludGsgKCBLRVJOX0RFQlVHIEZTVF9OQU1FICI6ICIgZm10LCAjIyBBICkK IAogI2Vsc2UKLSMgZGVmaW5lIGRiZyhYLi4uKSAgICAgIC8qIE5PUCAqLworI2RlZmluZSBkYmco WC4uLikJCS8qIE5PUCAqLwogI2VuZGlmCiAKLQogLyogICAgICBQcmludGluZyBzaG9ydCBjdXRz CiAgKi8KICNkZWZpbmUgcHJpbnRrX2VycihmbXQsQS4uLikgICAgcHJpbnRrICggS0VSTl9FUlIg ICAgIEZTVF9OQU1FICI6ICIgZm10LCAjIyBBICkKICNkZWZpbmUgcHJpbnRrX3dhcm4oZm10LEEu Li4pICAgcHJpbnRrICggS0VSTl9XQVJOSU5HIEZTVF9OQU1FICI6ICIgZm10LCAjIyBBICkKICNk ZWZpbmUgcHJpbnRrX2luZm8oZm10LEEuLi4pICAgcHJpbnRrICggS0VSTl9JTkZPICAgIEZTVF9O QU1FICI6ICIgZm10LCAjIyBBICkKIAotCiAvKgogICogICAgICBQQ0kgSUQgbG9va3VwIHRhYmxl CiAgKi8KLXN0YXRpYyBzdHJ1Y3QgcGNpX2RldmljZV9pZCBmc3RfcGNpX2Rldl9pZFtdID0gewot ICAgICAgICB7IEZTQ19QQ0lfVkVORE9SX0lELCBUMlBfUENJX0RFVklDRV9JRCwgUENJX0FOWV9J RCwgUENJX0FOWV9JRCwgMCwgMCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBGU1RfVFlQRV9UMlAgfSwKLSAgICAgICAgeyBGU0NfUENJX1ZFTkRPUl9JRCwgVDRQX1BD SV9ERVZJQ0VfSUQsIFBDSV9BTllfSUQsIFBDSV9BTllfSUQsIDAsIDAsCi0gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRlNUX1RZUEVfVDRQIH0sCi0gICAgICAgIHsgMCwg fSAgICAgICAgICAgICAgICAgICAgICAgICAgLyogRW5kICovCitzdGF0aWMgc3RydWN0IHBjaV9k ZXZpY2VfaWQgZnN0X3BjaV9kZXZfaWRbXSBfX2RldmluaXRkYXRhID0geworCXtQQ0lfVkVORE9S X0lEX0ZBUlNJVEUsIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9UMlAsIFBDSV9BTllfSUQsIAorCSBQ Q0lfQU5ZX0lELCAwLCAwLCBGU1RfVFlQRV9UMlB9LAorCisJe1BDSV9WRU5ET1JfSURfRkFSU0lU RSwgUENJX0RFVklDRV9JRF9GQVJTSVRFX1Q0UCwgUENJX0FOWV9JRCwgCisJIFBDSV9BTllfSUQs IDAsIDAsIEZTVF9UWVBFX1Q0UH0sCisKKwl7UENJX1ZFTkRPUl9JRF9GQVJTSVRFLCBQQ0lfREVW SUNFX0lEX0ZBUlNJVEVfVDFVLCBQQ0lfQU5ZX0lELCAKKwkgUENJX0FOWV9JRCwgMCwgMCwgRlNU X1RZUEVfVDFVfSwKKworCXtQQ0lfVkVORE9SX0lEX0ZBUlNJVEUsIFBDSV9ERVZJQ0VfSURfRkFS U0lURV9UMlUsIFBDSV9BTllfSUQsIAorCSBQQ0lfQU5ZX0lELCAwLCAwLCBGU1RfVFlQRV9UMlV9 LAorCisJe1BDSV9WRU5ET1JfSURfRkFSU0lURSwgUENJX0RFVklDRV9JRF9GQVJTSVRFX1Q0VSwg UENJX0FOWV9JRCwgCisJIFBDSV9BTllfSUQsIDAsIDAsIEZTVF9UWVBFX1Q0VX0sCisKKwl7UENJ X1ZFTkRPUl9JRF9GQVJTSVRFLCBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVEUxLCBQQ0lfQU5ZX0lE LCAKKwkgUENJX0FOWV9JRCwgMCwgMCwgRlNUX1RZUEVfVEUxfSwKKworCXtQQ0lfVkVORE9SX0lE X0ZBUlNJVEUsIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9URTFDLCBQQ0lfQU5ZX0lELCAKKwkgUENJ X0FOWV9JRCwgMCwgMCwgRlNUX1RZUEVfVEUxfSwKKwl7MCx9CQkJLyogRW5kICovCiB9OwogCi1N T0RVTEVfREVWSUNFX1RBQkxFICggcGNpLCBmc3RfcGNpX2Rldl9pZCApOworTU9EVUxFX0RFVklD RV9UQUJMRShwY2ksIGZzdF9wY2lfZGV2X2lkKTsKKworLyoKKyAqICAgICAgRGV2aWNlIERyaXZl ciBXb3JrIFF1ZXVlcworICoKKyAqICAgICAgU28gdGhhdCB3ZSBkb24ndCBzcGVuZCB0b28gbXVj aCB0aW1lIHByb2Nlc3NpbmcgZXZlbnRzIGluIHRoZSAKKyAqICAgICAgSW50ZXJydXB0IFNlcnZp Y2Ugcm91dGluZSwgd2Ugd2lsbCBkZWNsYXJlIGEgd29yayBxdWV1ZSBwZXIgQ2FyZCAKKyAqICAg ICAgYW5kIG1ha2UgdGhlIElTUiBzY2hlZHVsZSBhIHRhc2sgaW4gdGhlIHF1ZXVlIGZvciBsYXRl ciBleGVjdXRpb24uCisgKiAgICAgIEluIHRoZSAyLjQgS2VybmVsIHdlIHVzZWQgdG8gdXNlIHRo ZSBpbW1lZGlhdGUgcXVldWUgZm9yIEJIJ3MKKyAqICAgICAgTm93IHRoYXQgdGhleSBhcmUgZ29u ZSwgdGFza2xldHMgc2VlbSB0byBiZSBtdWNoIGJldHRlciB0aGFuIHdvcmsgCisgKiAgICAgIHF1 ZXVlcy4KKyAqLworCitzdGF0aWMgdm9pZCBkb19ib3R0b21faGFsZl90eChzdHJ1Y3QgZnN0X2Nh cmRfaW5mbyAqY2FyZCk7CitzdGF0aWMgdm9pZCBkb19ib3R0b21faGFsZl9yeChzdHJ1Y3QgZnN0 X2NhcmRfaW5mbyAqY2FyZCk7CitzdGF0aWMgdm9pZCBmc3RfcHJvY2Vzc190eF93b3JrX3EodW5z aWduZWQgbG9uZyB3b3JrX3EpOworc3RhdGljIHZvaWQgZnN0X3Byb2Nlc3NfaW50X3dvcmtfcSh1 bnNpZ25lZCBsb25nIHdvcmtfcSk7CisKK0RFQ0xBUkVfVEFTS0xFVChmc3RfdHhfdGFzaywgZnN0 X3Byb2Nlc3NfdHhfd29ya19xLCAwKTsKK0RFQ0xBUkVfVEFTS0xFVChmc3RfaW50X3Rhc2ssIGZz dF9wcm9jZXNzX2ludF93b3JrX3EsIDApOworCitzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqZnN0X2Nh cmRfYXJyYXlbRlNUX01BWF9DQVJEU107CitzcGlubG9ja190IGZzdF93b3JrX3FfbG9jazsKK3U2 NCBmc3Rfd29ya190eHE7Cit1NjQgZnN0X3dvcmtfaW50cTsKKworc3RhdGljIHZvaWQKK2ZzdF9x X3dvcmtfaXRlbSh1NjQgKiBxdWV1ZSwgaW50IGNhcmRfaW5kZXgpCit7CisJdW5zaWduZWQgbG9u ZyBmbGFnczsKKwl1NjQgbWFzazsKKworCS8qCisJICogR3JhYiB0aGUgcXVldWUgZXhjbHVzaXZl bHkKKwkgKi8KKwlzcGluX2xvY2tfaXJxc2F2ZSgmZnN0X3dvcmtfcV9sb2NrLCBmbGFncyk7CisK KwkvKgorCSAqIE1ha2luZyBhbiBlbnRyeSBpbiB0aGUgcXVldWUgaXMgc2ltcGx5IGEgbWF0dGVy IG9mIHNldHRpbmcKKwkgKiBhIGJpdCBmb3IgdGhlIGNhcmQgaW5kaWNhdGluZyB0aGF0IHRoZXJl IGlzIHdvcmsgdG8gZG8gaW4gdGhlCisJICogYm90dG9tIGhhbGYgZm9yIHRoZSBjYXJkLiAgTm90 ZSB0aGUgbGltaXRhdGlvbiBvZiA2NCBjYXJkcy4KKwkgKiBUaGF0IG91Z2h0IHRvIGJlIGVub3Vn aAorCSAqLworCW1hc2sgPSAxIDw8IGNhcmRfaW5kZXg7CisJKnF1ZXVlIHw9IG1hc2s7CisJc3Bp bl91bmxvY2tfaXJxcmVzdG9yZSgmZnN0X3dvcmtfcV9sb2NrLCBmbGFncyk7Cit9CisKK3N0YXRp YyB2b2lkCitmc3RfcHJvY2Vzc190eF93b3JrX3EodW5zaWduZWQgbG9uZyAvKnZvaWQgKiovd29y a19xKQoreworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJdTY0IHdvcmtfdHhxOworCWludCBpOwor CisJLyoKKwkgKiBHcmFiIHRoZSBxdWV1ZSBleGNsdXNpdmVseQorCSAqLworCWRiZyhEQkdfVFgs ICJmc3RfcHJvY2Vzc190eF93b3JrX3FcbiIpOworCXNwaW5fbG9ja19pcnFzYXZlKCZmc3Rfd29y a19xX2xvY2ssIGZsYWdzKTsKKwl3b3JrX3R4cSA9IGZzdF93b3JrX3R4cTsKKwlmc3Rfd29ya190 eHEgPSAwOworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmZzdF93b3JrX3FfbG9jaywgZmxhZ3Mp OworCisJLyoKKwkgKiBDYWxsIHRoZSBib3R0b20gaGFsZiBmb3IgZWFjaCBjYXJkIHdpdGggd29y ayB3YWl0aW5nCisJICovCisJZm9yIChpID0gMDsgaSA8IEZTVF9NQVhfQ0FSRFM7IGkrKykgewor CQlpZiAod29ya190eHEgJiAweDAxKSB7CisJCQlpZiAoZnN0X2NhcmRfYXJyYXlbaV0gIT0gTlVM TCkgeworCQkJCWRiZyhEQkdfVFgsICJDYWxsaW5nIHR4IGJoIGZvciBjYXJkICVkXG4iLCBpKTsK KwkJCQlkb19ib3R0b21faGFsZl90eChmc3RfY2FyZF9hcnJheVtpXSk7CisJCQl9CisJCX0KKwkJ d29ya190eHEgPSB3b3JrX3R4cSA+PiAxOworCX0KK30KIAorc3RhdGljIHZvaWQKK2ZzdF9wcm9j ZXNzX2ludF93b3JrX3EodW5zaWduZWQgbG9uZyAvKnZvaWQgKiovd29ya19xKQoreworCXVuc2ln bmVkIGxvbmcgZmxhZ3M7CisJdTY0IHdvcmtfaW50cTsKKwlpbnQgaTsKKworCS8qCisJICogR3Jh YiB0aGUgcXVldWUgZXhjbHVzaXZlbHkKKwkgKi8KKwlkYmcoREJHX0lOVFIsICJmc3RfcHJvY2Vz c19pbnRfd29ya19xXG4iKTsKKwlzcGluX2xvY2tfaXJxc2F2ZSgmZnN0X3dvcmtfcV9sb2NrLCBm bGFncyk7CisJd29ya19pbnRxID0gZnN0X3dvcmtfaW50cTsKKwlmc3Rfd29ya19pbnRxID0gMDsK KwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZmc3Rfd29ya19xX2xvY2ssIGZsYWdzKTsKKworCS8q CisJICogQ2FsbCB0aGUgYm90dG9tIGhhbGYgZm9yIGVhY2ggY2FyZCB3aXRoIHdvcmsgd2FpdGlu ZworCSAqLworCWZvciAoaSA9IDA7IGkgPCBGU1RfTUFYX0NBUkRTOyBpKyspIHsKKwkJaWYgKHdv cmtfaW50cSAmIDB4MDEpIHsKKwkJCWlmIChmc3RfY2FyZF9hcnJheVtpXSAhPSBOVUxMKSB7CisJ CQkJZGJnKERCR19JTlRSLAorCQkJCSAgICAiQ2FsbGluZyByeCAmIHR4IGJoIGZvciBjYXJkICVk XG4iLCBpKTsKKwkJCQlkb19ib3R0b21faGFsZl9yeChmc3RfY2FyZF9hcnJheVtpXSk7CisJCQkJ ZG9fYm90dG9tX2hhbGZfdHgoZnN0X2NhcmRfYXJyYXlbaV0pOworCQkJfQorCQl9CisJCXdvcmtf aW50cSA9IHdvcmtfaW50cSA+PiAxOworCX0KK30KIAogLyogICAgICBDYXJkIGNvbnRyb2wgZnVu Y3Rpb25zCiAgKiAgICAgID09PT09PT09PT09PT09PT09PT09PT0KQEAgLTQzMiwxMDA1ICs2NzAs MTcyNSBAQAogICogVXNlZCB0byBiZSBhIHNpbXBsZSB3cml0ZSB0byBjYXJkIGNvbnRyb2wgc3Bh Y2UgYnV0IGEgZ2xpdGNoIGluIHRoZSBsYXRlc3QKICAqIEFNRCBBbTE4NkNIIHByb2Nlc3NvciBt ZWFucyB0aGF0IHdlIG5vdyBoYXZlIHRvIGRvIGl0IGJ5IGFzc2VydGluZyBhbmQgZGUtCiAgKiBh c3NlcnRpbmcgdGhlIFBMWCBjaGlwIFBDSSBBZGFwdGVyIFNvZnR3YXJlIFJlc2V0LiBCaXQgMzAg aW4gQ05UUkwgcmVnaXN0ZXIKLSAqIGF0IG9mZnNldCAweDUwLgorICogYXQgb2Zmc2V0IDkwNTJf Q05UUkwuICBOb3RlIHRoZSB1cGRhdGVzIGZvciB0aGUgVFhVLgogICovCiBzdGF0aWMgaW5saW5l IHZvaWQKLWZzdF9jcHVyZXNldCAoIHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkICkKK2ZzdF9j cHVyZXNldChzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCkKIHsKLSAgICAgICAgdW5zaWduZWQg aW50IHJlZ3ZhbDsKKwl1bnNpZ25lZCBjaGFyIGludGVycnVwdF9saW5lX3JlZ2lzdGVyOworCXVu c2lnbmVkIGxvbmcgaiA9IGppZmZpZXMgKyAxOworCXVuc2lnbmVkIGludCByZWd2YWw7CisKKwlp ZiAoY2FyZC0+ZmFtaWx5ID09IEZTVF9GQU1JTFlfVFhVKSB7CisJCWlmIChwY2lfcmVhZF9jb25m aWdfYnl0ZQorCQkgICAgKGNhcmQtPmRldmljZSwgUENJX0lOVEVSUlVQVF9MSU5FLCAmaW50ZXJy dXB0X2xpbmVfcmVnaXN0ZXIpKSB7CisJCQlkYmcoREJHX0FTUywKKwkJCSAgICAiRXJyb3IgaW4g cmVhZGluZyBpbnRlcnJ1cHQgbGluZSByZWdpc3RlclxuIik7CisJCX0KKwkJLyoKKwkJICogQXNz ZXJ0IFBMWCBzb2Z0d2FyZSByZXNldCBhbmQgQW0xODYgaGFyZHdhcmUgcmVzZXQKKwkJICogYW5k IHRoZW4gZGVhc3NlcnQgdGhlIFBMWCBzb2Z0d2FyZSByZXNldCBidXQgMTg2IHN0aWxsIGluIHJl c2V0CisJCSAqLworCQlvdXR3KDB4NDQwZiwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDU0ICsg Mik7CisJCW91dHcoMHgwNDBmLCBjYXJkLT5wY2lfY29uZiArIENOVFJMXzkwNTQgKyAyKTsKKwkJ LyoKKwkJICogV2UgYXJlIGRlbGF5aW5nIGhlcmUgdG8gYWxsb3cgdGhlIDkwNTQgdG8gcmVzZXQg aXRzZWxmCisJCSAqLworCQlqID0gamlmZmllcyArIDE7CisJCXdoaWxlIChqaWZmaWVzIDwgaikK KwkJCS8qIERvIG5vdGhpbmcgKi8gOworCQlvdXR3KDB4MjQwZiwgY2FyZC0+cGNpX2NvbmYgKyBD TlRSTF85MDU0ICsgMik7CisJCS8qCisJCSAqIFdlIGFyZSBkZWxheWluZyBoZXJlIHRvIGFsbG93 IHRoZSA5MDU0IHRvIHJlbG9hZCBpdHMgZWVwcm9tCisJCSAqLworCQlqID0gamlmZmllcyArIDE7 CisJCXdoaWxlIChqaWZmaWVzIDwgaikKKwkJCS8qIERvIG5vdGhpbmcgKi8gOworCQlvdXR3KDB4 MDQwZiwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDU0ICsgMik7CisKKwkJaWYgKHBjaV93cml0 ZV9jb25maWdfYnl0ZQorCQkgICAgKGNhcmQtPmRldmljZSwgUENJX0lOVEVSUlVQVF9MSU5FLCBp bnRlcnJ1cHRfbGluZV9yZWdpc3RlcikpIHsKKwkJCWRiZyhEQkdfQVNTLAorCQkJICAgICJFcnJv ciBpbiB3cml0aW5nIGludGVycnVwdCBsaW5lIHJlZ2lzdGVyXG4iKTsKKwkJfQogCi0gICAgICAg IHJlZ3ZhbCA9IGlubCAoIGNhcmQtPnBjaV9jb25mICsgMHg1MCApOworCX0gZWxzZSB7CisJCXJl Z3ZhbCA9IGlubChjYXJkLT5wY2lfY29uZiArIENOVFJMXzkwNTIpOwogCi0gICAgICAgIG91dGwg KCByZWd2YWwgfCAgMHg0MDAwMDAwMCwgY2FyZC0+cGNpX2NvbmYgKyAweDUwICk7Ci0gICAgICAg IG91dGwgKCByZWd2YWwgJiB+MHg0MDAwMDAwMCwgY2FyZC0+cGNpX2NvbmYgKyAweDUwICk7CisJ CW91dGwocmVndmFsIHwgMHg0MDAwMDAwMCwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDUyKTsK KwkJb3V0bChyZWd2YWwgJiB+MHg0MDAwMDAwMCwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDUy KTsKKwl9CiB9CiAKIC8qICAgICAgUmVsZWFzZSB0aGUgcHJvY2Vzc29yIGZyb20gcmVzZXQKICAq Lwogc3RhdGljIGlubGluZSB2b2lkCi1mc3RfY3B1cmVsZWFzZSAoIHN0cnVjdCBmc3RfY2FyZF9p bmZvICpjYXJkICkKK2ZzdF9jcHVyZWxlYXNlKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkKQog ewotICAgICAgICAodm9pZCkgcmVhZGIgKCBjYXJkLT5jdGxtZW0gKTsKKwlpZiAoY2FyZC0+ZmFt aWx5ID09IEZTVF9GQU1JTFlfVFhVKSB7CisJCS8qCisJCSAqIEZvcmNlIHBvc3RlZCB3cml0ZXMg dG8gY29tcGxldGUKKwkJICovCisJCSh2b2lkKSByZWFkYihjYXJkLT5tZW0pOworCisJCS8qCisJ CSAqIFJlbGVhc2UgTFJFU0VUIERPID0gMQorCQkgKiBUaGVuIHJlbGVhc2UgTG9jYWwgSG9sZCwg RE8gPSAxCisJCSAqLworCQlvdXR3KDB4MDQwZSwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDU0 ICsgMik7CisJCW91dHcoMHgwNDBmLCBjYXJkLT5wY2lfY29uZiArIENOVFJMXzkwNTQgKyAyKTsK Kwl9IGVsc2UgeworCQkodm9pZCkgcmVhZGIoY2FyZC0+Y3RsbWVtKTsKKwl9CiB9CiAKIC8qICAg ICAgQ2xlYXIgdGhlIGNhcmRzIGludGVycnVwdCBmbGFnCiAgKi8KIHN0YXRpYyBpbmxpbmUgdm9p ZAotZnN0X2NsZWFyX2ludHIgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCApCitmc3RfY2xl YXJfaW50cihzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCkKK3sKKwlpZiAoY2FyZC0+ZmFtaWx5 ID09IEZTVF9GQU1JTFlfVFhVKSB7CisJCSh2b2lkKSByZWFkYihjYXJkLT5jdGxtZW0pOworCX0g ZWxzZSB7CisJCS8qIFBva2UgdGhlIGFwcHJvcHJpYXRlIFBMWCBjaGlwIHJlZ2lzdGVyIChzYW1l IGFzIGVuYWJsaW5nIGludGVycnVwdHMpCisJCSAqLworCQlvdXR3KDB4MDU0MywgY2FyZC0+cGNp X2NvbmYgKyBJTlRDU1JfOTA1Mik7CisJfQorfQorCisvKiAgICAgIEVuYWJsZSBjYXJkIGludGVy cnVwdHMKKyAqLworc3RhdGljIGlubGluZSB2b2lkCitmc3RfZW5hYmxlX2ludHIoc3RydWN0IGZz dF9jYXJkX2luZm8gKmNhcmQpCiB7Ci0gICAgICAgIC8qIFBva2UgdGhlIGFwcHJvcHJpYXRlIFBM WCBjaGlwIHJlZ2lzdGVyIChzYW1lIGFzIGVuYWJsaW5nIGludGVycnVwdHMpCi0gICAgICAgICAq LwotICAgICAgICBvdXR3ICggMHgwNTQzLCBjYXJkLT5wY2lfY29uZiArIDB4NEMgKTsKKwlpZiAo Y2FyZC0+ZmFtaWx5ID09IEZTVF9GQU1JTFlfVFhVKSB7CisJCW91dGwoMHgwZjBjMDkwMCwgY2Fy ZC0+cGNpX2NvbmYgKyBJTlRDU1JfOTA1NCk7CisJfSBlbHNlIHsKKwkJb3V0dygweDA1NDMsIGNh cmQtPnBjaV9jb25mICsgSU5UQ1NSXzkwNTIpOworCX0KIH0KIAogLyogICAgICBEaXNhYmxlIGNh cmQgaW50ZXJydXB0cwogICovCiBzdGF0aWMgaW5saW5lIHZvaWQKLWZzdF9kaXNhYmxlX2ludHIg KCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCApCitmc3RfZGlzYWJsZV9pbnRyKHN0cnVjdCBm c3RfY2FyZF9pbmZvICpjYXJkKQoreworCWlmIChjYXJkLT5mYW1pbHkgPT0gRlNUX0ZBTUlMWV9U WFUpIHsKKwkJb3V0bCgweDAwMDAwMDAwLCBjYXJkLT5wY2lfY29uZiArIElOVENTUl85MDU0KTsK Kwl9IGVsc2UgeworCQlvdXR3KDB4MDAwMCwgY2FyZC0+cGNpX2NvbmYgKyBJTlRDU1JfOTA1Mik7 CisJfQorfQorCisvKiAgICAgIFByb2Nlc3MgdGhlIHJlc3VsdCBvZiB0cnlpbmcgdG8gcGFzcyBh IHJlY2lldmVkIGZyYW1lIHVwIHRoZSBzdGFjaworICovCitzdGF0aWMgdm9pZAorZnN0X3Byb2Nl c3Nfcnhfc3RhdHVzKGludCByeF9zdGF0dXMsIGNoYXIgKm5hbWUpCiB7Ci0gICAgICAgIG91dHcg KCAweDAwMDAsIGNhcmQtPnBjaV9jb25mICsgMHg0QyApOworCXN3aXRjaCAocnhfc3RhdHVzKSB7 CisJY2FzZSBORVRfUlhfU1VDQ0VTUzoKKwkJeworCQkJLyoKKwkJCSAqIE5vdGhpbmcgdG8gZG8g aGVyZQorCQkJICovCisJCQlicmVhazsKKwkJfQorCisJY2FzZSBORVRfUlhfQ05fTE9XOgorCQl7 CisJCQlkYmcoREJHX0FTUywgIiVzOiBSZWNlaXZlIExvdyBDb25nZXN0aW9uXG4iLCBuYW1lKTsK KwkJCWJyZWFrOworCQl9CisKKwljYXNlIE5FVF9SWF9DTl9NT0Q6CisJCXsKKwkJCWRiZyhEQkdf QVNTLCAiJXM6IFJlY2VpdmUgTW9kZXJhdGUgQ29uZ2VzdGlvblxuIiwgbmFtZSk7CisJCQlicmVh azsKKwkJfQorCisJY2FzZSBORVRfUlhfQ05fSElHSDoKKwkJeworCQkJZGJnKERCR19BU1MsICIl czogUmVjZWl2ZSBIaWdoIENvbmdlc3Rpb25cbiIsIG5hbWUpOworCQkJYnJlYWs7CisJCX0KKwor CWNhc2UgTkVUX1JYX0RST1A6CisJCXsKKwkJCWRiZyhEQkdfQVNTLCAiJXM6IFJlY2VpdmVkIHBh Y2tldCBkcm9wcGVkXG4iLCBuYW1lKTsKKwkJCWJyZWFrOworCQl9CisJfQogfQogCisvKiAgICAg IEluaXRpbGFpc2UgRE1BIGZvciBQTFggOTA1NAorICovCitzdGF0aWMgaW5saW5lIHZvaWQKK2Zz dF9pbml0X2RtYShzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCkKK3sKKwkvKgorCSAqIFRoaXMg aXMgb25seSByZXF1aXJlZCBmb3IgdGhlIFBMWCA5MDU0CisJICovCisJaWYgKGNhcmQtPmZhbWls eSA9PSBGU1RfRkFNSUxZX1RYVSkgeworCSAgICAgICAgcGNpX3NldF9tYXN0ZXIoY2FyZC0+ZGV2 aWNlKTsKKwkJb3V0bCgweDAwMDIwNDQxLCBjYXJkLT5wY2lfY29uZiArIERNQU1PREUwKTsKKwkJ b3V0bCgweDAwMDIwNDQxLCBjYXJkLT5wY2lfY29uZiArIERNQU1PREUxKTsKKwkJb3V0bCgweDAs IGNhcmQtPnBjaV9jb25mICsgRE1BVEhSKTsKKwl9Cit9CisKKy8qICAgICAgVHggZG1hIGNvbXBs ZXRlIGludGVycnVwdAorICovCitzdGF0aWMgdm9pZAorZnN0X3R4X2RtYV9jb21wbGV0ZShzdHJ1 Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsCisJCSAg ICBpbnQgbGVuLCBpbnQgdHhwb3MpCit7CisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IHBvcnRf dG9fZGV2KHBvcnQpOworCXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpzdGF0cyA9IGhkbGNfc3Rh dHMoZGV2KTsKKworCS8qCisJICogRXZlcnl0aGluZyBpcyBub3cgc2V0LCBqdXN0IHRlbGwgdGhl IGNhcmQgdG8gZ28KKwkgKi8KKwlkYmcoREJHX1RYLCAiZnN0X3R4X2RtYV9jb21wbGV0ZVxuIik7 CisJRlNUX1dSQihjYXJkLCB0eERlc2NyUmluZ1twb3J0LT5pbmRleF1bdHhwb3NdLmJpdHMsCisJ CURNQV9PV04gfCBUWF9TVFAgfCBUWF9FTlApOworCXN0YXRzLT50eF9wYWNrZXRzKys7CisJc3Rh dHMtPnR4X2J5dGVzICs9IGxlbjsKKwlkZXYtPnRyYW5zX3N0YXJ0ID0gamlmZmllczsKK30KKwor LyogICAgICBSeCBkbWEgY29tcGxldGUgaW50ZXJydXB0CisgKi8KK3N0YXRpYyB2b2lkCitmc3Rf cnhfZG1hX2NvbXBsZXRlKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3Bv cnRfaW5mbyAqcG9ydCwKKwkJICAgIGludCBsZW4sIHN0cnVjdCBza19idWZmICpza2IsIGludCBy eHApCit7CisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IHBvcnRfdG9fZGV2KHBvcnQpOworCXN0 cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpzdGF0cyA9IGhkbGNfc3RhdHMoZGV2KTsKKwlpbnQgcGk7 CisJaW50IHJ4X3N0YXR1czsKKworCWRiZyhEQkdfVFgsICJmc3RfcnhfZG1hX2NvbXBsZXRlXG4i KTsKKwlwaSA9IHBvcnQtPmluZGV4OworCW1lbWNweShza2JfcHV0KHNrYiwgbGVuKSwgY2FyZC0+ cnhfZG1hX2hhbmRsZV9ob3N0LCBsZW4pOworCisJLyogUmVzZXQgYnVmZmVyIGRlc2NyaXB0b3Ig Ki8KKwlGU1RfV1JCKGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtyeHBdLmJpdHMsIERNQV9PV04pOwor CisJLyogVXBkYXRlIHN0YXRzICovCisJc3RhdHMtPnJ4X3BhY2tldHMrKzsKKwlzdGF0cy0+cnhf Ynl0ZXMgKz0gbGVuOworCisJLyogUHVzaCB1cHN0cmVhbSAqLworCWRiZyhEQkdfUlgsICJQdXNo aW5nIHRoZSBmcmFtZSB1cCB0aGUgc3RhY2tcbiIpOworCXNrYi0+bWFjLnJhdyA9IHNrYi0+ZGF0 YTsKKwlza2ItPmRldiA9IGRldjsKKwlpZiAocG9ydC0+bW9kZSA9PSBGU1RfUkFXKSB7CisJCS8q CisJCSAqIE1hcmsgaXQgZm9yIG91ciBvd24gcmF3IHNvY2tldHMgaW50ZXJmYWNlCisJCSAqLwor CQlza2ItPnByb3RvY29sID0gaHRvbnMoRVRIX1BfQ1VTVCk7CisJCXNrYi0+cGt0X3R5cGUgPSBQ QUNLRVRfSE9TVDsKKwl9IGVsc2UgeworCQlza2ItPnByb3RvY29sID0gaGRsY190eXBlX3RyYW5z KHNrYiwgc2tiLT5kZXYpOworCX0KKwlyeF9zdGF0dXMgPSBuZXRpZl9yeChza2IpOworCWZzdF9w cm9jZXNzX3J4X3N0YXR1cyhyeF9zdGF0dXMsIHBvcnRfdG9fZGV2KHBvcnQpLT5uYW1lKTsKKwlp ZiAocnhfc3RhdHVzID09IE5FVF9SWF9EUk9QKQorCQlzdGF0cy0+cnhfZHJvcHBlZCsrOworCWRl di0+bGFzdF9yeCA9IGppZmZpZXM7Cit9CisKKy8qCisgKiAgICAgIFJlY2VpdmUgYSBmcmFtZSB0 aHJvdWdoIHRoZSBETUEKKyAqLworc3RhdGljIGlubGluZSB2b2lkCitmc3RfcnhfZG1hKHN0cnVj dCBmc3RfY2FyZF9pbmZvICpjYXJkLCB1bnNpZ25lZCBjaGFyICpza2IsCisJICAgdW5zaWduZWQg Y2hhciAqbWVtLCBpbnQgbGVuKQoreworCS8qCisJICogVGhpcyByb3V0aW5lIHdpbGwgc2V0dXAg dGhlIERNQSBhbmQgc3RhcnQgaXQKKwkgKi8KKworCWRiZyhEQkdfUlgsICJJbiBmc3RfcnhfZG1h ICVwICVwICVkXG4iLCBza2IsIG1lbSwgbGVuKTsKKwlpZiAoY2FyZC0+ZG1hcnhfaW5fcHJvZ3Jl c3MpIHsKKwkJZGJnKERCR19BU1MsICJJbiBmc3RfcnhfZG1hIHdoaWxlIGRtYSBpbiBwcm9ncmVz c1xuIik7CisJfQorCisJb3V0bCgodW5zaWduZWQgbG9uZykgc2tiLCBjYXJkLT5wY2lfY29uZiAr IERNQVBBRFIwKTsJLyogQ29weSB0byBoZXJlICovCisJb3V0bCgodW5zaWduZWQgbG9uZykgbWVt LCBjYXJkLT5wY2lfY29uZiArIERNQUxBRFIwKTsJLyogZnJvbSBoZXJlICovCisJb3V0bChsZW4s IGNhcmQtPnBjaV9jb25mICsgRE1BU0laMCk7CS8qIGZvciB0aGlzIGxlbmd0aCAqLworCW91dGwo MHgwMDAwMDAwMGMsIGNhcmQtPnBjaV9jb25mICsgRE1BRFBSMCk7CS8qIEluIHRoaXMgZGlyZWN0 aW9uICovCisKKwkvKgorCSAqIFdlIHVzZSB0aGUgZG1hcnhfaW5fcHJvZ3Jlc3MgZmxhZyB0byBm bGFnIHRoZSBjaGFubmVsIGFzIGJ1c3kKKwkgKi8KKwljYXJkLT5kbWFyeF9pbl9wcm9ncmVzcyA9 IDE7CisJb3V0YigweDAzLCBjYXJkLT5wY2lfY29uZiArIERNQUNTUjApOwkvKiBTdGFydCB0aGUg dHJhbnNmZXIgKi8KK30KKworLyoKKyAqICAgICAgU2VuZCBhIGZyYW1lIHRocm91Z2ggdGhlIERN QQorICovCitzdGF0aWMgaW5saW5lIHZvaWQKK2ZzdF90eF9kbWEoc3RydWN0IGZzdF9jYXJkX2lu Zm8gKmNhcmQsIHVuc2lnbmVkIGNoYXIgKnNrYiwKKwkgICB1bnNpZ25lZCBjaGFyICptZW0sIGlu dCBsZW4pCit7CisJLyoKKwkgKiBUaGlzIHJvdXRpbmUgd2lsbCBzZXR1cCB0aGUgRE1BIGFuZCBz dGFydCBpdC4KKwkgKi8KKworCWRiZyhEQkdfVFgsICJJbiBmc3RfdHhfZG1hICVwICVwICVkXG4i LCBza2IsIG1lbSwgbGVuKTsKKwlpZiAoY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MpIHsKKwkJZGJn KERCR19BU1MsICJJbiBmc3RfdHhfZG1hIHdoaWxlIGRtYSBpbiBwcm9ncmVzc1xuIik7CisJfQor CisJb3V0bCgodW5zaWduZWQgbG9uZykgc2tiLCBjYXJkLT5wY2lfY29uZiArIERNQVBBRFIxKTsJ LyogQ29weSBmcm9tIGhlcmUgKi8KKwlvdXRsKCh1bnNpZ25lZCBsb25nKSBtZW0sIGNhcmQtPnBj aV9jb25mICsgRE1BTEFEUjEpOwkvKiB0byBoZXJlICovCisJb3V0bChsZW4sIGNhcmQtPnBjaV9j b25mICsgRE1BU0laMSk7CS8qIGZvciB0aGlzIGxlbmd0aCAqLworCW91dGwoMHgwMDAwMDAwMDQs IGNhcmQtPnBjaV9jb25mICsgRE1BRFBSMSk7CS8qIEluIHRoaXMgZGlyZWN0aW9uICovCisKKwkv KgorCSAqIFdlIHVzZSB0aGUgZG1hdHhfaW5fcHJvZ3Jlc3MgdG8gZmxhZyB0aGUgY2hhbm5lbCBh cyBidXN5CisJICovCisJY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MgPSAxOworCW91dGIoMHgwMywg Y2FyZC0+cGNpX2NvbmYgKyBETUFDU1IxKTsJLyogU3RhcnQgdGhlIHRyYW5zZmVyICovCit9CiAK IC8qICAgICAgSXNzdWUgYSBNYWlsYm94IGNvbW1hbmQgZm9yIGEgcG9ydC4KICAqICAgICAgTm90 ZSB3ZSBpc3N1ZSB0aGVtIG9uIGEgZmlyZSBhbmQgZm9yZ2V0IGJhc2lzLCBub3QgZXhwZWN0aW5n IHRvIHNlZSBhbgogICogICAgICBlcnJvciBhbmQgbm90IHdhaXRpbmcgZm9yIGNvbXBsZXRpb24u CiAgKi8KIHN0YXRpYyB2b2lkCi1mc3RfaXNzdWVfY21kICggc3RydWN0IGZzdF9wb3J0X2luZm8g KnBvcnQsIHVuc2lnbmVkIHNob3J0IGNtZCApCitmc3RfaXNzdWVfY21kKHN0cnVjdCBmc3RfcG9y dF9pbmZvICpwb3J0LCB1bnNpZ25lZCBzaG9ydCBjbWQpCiB7Ci0gICAgICAgIHN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkOwotICAgICAgICB1bnNpZ25lZCBzaG9ydCBtYnZhbDsKLSAgICAgICAg dW5zaWduZWQgbG9uZyBmbGFnczsKLSAgICAgICAgaW50IHNhZmV0eTsKLQotICAgICAgICBjYXJk ID0gcG9ydC0+Y2FyZDsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUgKCAmY2FyZC0+Y2FyZF9s b2NrLCBmbGFncyApOwotICAgICAgICBtYnZhbCA9IEZTVF9SRFcgKCBjYXJkLCBwb3J0TWFpbGJv eFtwb3J0LT5pbmRleF1bMF0pOwotCi0gICAgICAgIHNhZmV0eSA9IDA7Ci0gICAgICAgIC8qIFdh aXQgZm9yIGFueSBwcmV2aW91cyBjb21tYW5kIHRvIGNvbXBsZXRlICovCi0gICAgICAgIHdoaWxl ICggbWJ2YWwgPiBOQUsgKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgc3Bpbl91bmxvY2tf aXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0gICAgICAgICAgICAgICAg c2NoZWR1bGVfdGltZW91dCAoIDEgKTsKLSAgICAgICAgICAgICAgICBzcGluX2xvY2tfaXJxc2F2 ZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0KLSAgICAgICAgICAgICAgICBpZiAoICsr c2FmZXR5ID4gMTAwMCApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICAg ICAgcHJpbnRrX2VyciAoIk1haWxib3ggc2FmZXR5IHRpbWVvdXRcbiIpOwotICAgICAgICAgICAg ICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgICAgICAgICAgfQorCXN0cnVjdCBmc3RfY2FyZF9p bmZvICpjYXJkOworCXVuc2lnbmVkIHNob3J0IG1idmFsOworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7 CisJaW50IHNhZmV0eTsKKworCWNhcmQgPSBwb3J0LT5jYXJkOworCXNwaW5fbG9ja19pcnFzYXZl KCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwltYnZhbCA9IEZTVF9SRFcoY2FyZCwgcG9ydE1h aWxib3hbcG9ydC0+aW5kZXhdWzBdKTsKKworCXNhZmV0eSA9IDA7CisJLyogV2FpdCBmb3IgYW55 IHByZXZpb3VzIGNvbW1hbmQgdG8gY29tcGxldGUgKi8KKwl3aGlsZSAobWJ2YWwgPiBOQUspIHsK KwkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJCXNj aGVkdWxlX3RpbWVvdXQoMSk7CisJCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJkX2xvY2ss IGZsYWdzKTsKKworCQlpZiAoKytzYWZldHkgPiAyMDAwKSB7CisJCQlwcmludGtfZXJyKCJNYWls Ym94IHNhZmV0eSB0aW1lb3V0XG4iKTsKKwkJCWJyZWFrOworCQl9CisKKwkJbWJ2YWwgPSBGU1Rf UkRXKGNhcmQsIHBvcnRNYWlsYm94W3BvcnQtPmluZGV4XVswXSk7CisJfQorCWlmIChzYWZldHkg PiAwKSB7CisJCWRiZyhEQkdfQ01ELCAiTWFpbGJveCBjbGVhciBhZnRlciAlZCBqaWZmaWVzXG4i LCBzYWZldHkpOworCX0KKwlpZiAobWJ2YWwgPT0gTkFLKSB7CisJCWRiZyhEQkdfQ01ELCAiaXNz dWVfY21kOiBwcmV2aW91cyBjb21tYW5kIHdhcyBOQUsnZFxuIik7CisJfQogCi0gICAgICAgICAg ICAgICAgbWJ2YWwgPSBGU1RfUkRXICggY2FyZCwgcG9ydE1haWxib3hbcG9ydC0+aW5kZXhdWzBd KTsKLSAgICAgICAgfQotICAgICAgICBpZiAoIHNhZmV0eSA+IDAgKQotICAgICAgICB7Ci0gICAg ICAgICAgICAgICAgZGJnICggREJHX0NNRCwiTWFpbGJveCBjbGVhciBhZnRlciAlZCBqaWZmaWVz XG4iLCBzYWZldHkgKTsKLSAgICAgICAgfQotICAgICAgICBpZiAoIG1idmFsID09IE5BSyApCi0g ICAgICAgIHsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfQ01ELCJpc3N1ZV9jbWQ6IHByZXZp b3VzIGNvbW1hbmQgd2FzIE5BSydkXG4iKTsKLSAgICAgICAgfQotCi0gICAgICAgIEZTVF9XUlcg KCBjYXJkLCBwb3J0TWFpbGJveFtwb3J0LT5pbmRleF1bMF0sIGNtZCApOwotCi0gICAgICAgIGlm ICggY21kID09IEFCT1JUVFggfHwgY21kID09IFNUQVJUUE9SVCApCi0gICAgICAgIHsKLSAgICAg ICAgICAgICAgICBwb3J0LT50eHBvcyAgPSAwOwotICAgICAgICAgICAgICAgIHBvcnQtPnR4aXBv cyA9IDA7Ci0gICAgICAgICAgICAgICAgcG9ydC0+dHhjbnQgID0gMDsKLSAgICAgICAgfQorCUZT VF9XUlcoY2FyZCwgcG9ydE1haWxib3hbcG9ydC0+aW5kZXhdWzBdLCBjbWQpOwogCi0gICAgICAg IHNwaW5fdW5sb2NrX2lycXJlc3RvcmUgKCAmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOwotfQor CWlmIChjbWQgPT0gQUJPUlRUWCB8fCBjbWQgPT0gU1RBUlRQT1JUKSB7CisJCXBvcnQtPnR4cG9z ID0gMDsKKwkJcG9ydC0+dHhpcG9zID0gMDsKKwkJcG9ydC0+c3RhcnQgPSAwOworCX0KIAorCXNw aW5fdW5sb2NrX2lycXJlc3RvcmUoJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MpOworfQogCiAvKiAg ICAgIFBvcnQgb3V0cHV0IHNpZ25hbHMgY29udHJvbAogICovCiBzdGF0aWMgaW5saW5lIHZvaWQK LWZzdF9vcF9yYWlzZSAoIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LCB1bnNpZ25lZCBpbnQg b3V0cHV0cyApCitmc3Rfb3BfcmFpc2Uoc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsIHVuc2ln bmVkIGludCBvdXRwdXRzKQogewotICAgICAgICBvdXRwdXRzIHw9IEZTVF9SREwgKCBwb3J0LT5j YXJkLCB2MjRPcFN0c1twb3J0LT5pbmRleF0pOwotICAgICAgICBGU1RfV1JMICggcG9ydC0+Y2Fy ZCwgdjI0T3BTdHNbcG9ydC0+aW5kZXhdLCBvdXRwdXRzICk7CisJb3V0cHV0cyB8PSBGU1RfUkRM KHBvcnQtPmNhcmQsIHYyNE9wU3RzW3BvcnQtPmluZGV4XSk7CisJRlNUX1dSTChwb3J0LT5jYXJk LCB2MjRPcFN0c1twb3J0LT5pbmRleF0sIG91dHB1dHMpOwogCi0gICAgICAgIGlmICggcG9ydC0+ cnVuICkKLSAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9ydCwgU0VUVjI0TyApOwor CWlmIChwb3J0LT5ydW4pCisJCWZzdF9pc3N1ZV9jbWQocG9ydCwgU0VUVjI0Tyk7CiB9CiAKIHN0 YXRpYyBpbmxpbmUgdm9pZAotZnN0X29wX2xvd2VyICggc3RydWN0IGZzdF9wb3J0X2luZm8gKnBv cnQsIHVuc2lnbmVkIGludCBvdXRwdXRzICkKK2ZzdF9vcF9sb3dlcihzdHJ1Y3QgZnN0X3BvcnRf aW5mbyAqcG9ydCwgdW5zaWduZWQgaW50IG91dHB1dHMpCiB7Ci0gICAgICAgIG91dHB1dHMgPSB+ b3V0cHV0cyAmIEZTVF9SREwgKCBwb3J0LT5jYXJkLCB2MjRPcFN0c1twb3J0LT5pbmRleF0pOwot ICAgICAgICBGU1RfV1JMICggcG9ydC0+Y2FyZCwgdjI0T3BTdHNbcG9ydC0+aW5kZXhdLCBvdXRw dXRzICk7CisJb3V0cHV0cyA9IH5vdXRwdXRzICYgRlNUX1JETChwb3J0LT5jYXJkLCB2MjRPcFN0 c1twb3J0LT5pbmRleF0pOworCUZTVF9XUkwocG9ydC0+Y2FyZCwgdjI0T3BTdHNbcG9ydC0+aW5k ZXhdLCBvdXRwdXRzKTsKIAotICAgICAgICBpZiAoIHBvcnQtPnJ1biApCi0gICAgICAgICAgICAg ICAgZnN0X2lzc3VlX2NtZCAoIHBvcnQsIFNFVFYyNE8gKTsKKwlpZiAocG9ydC0+cnVuKQorCQlm c3RfaXNzdWVfY21kKHBvcnQsIFNFVFYyNE8pOwogfQogCi0KIC8qCiAgKiAgICAgIFNldHVwIHBv cnQgUnggYnVmZmVycwogICovCiBzdGF0aWMgdm9pZAotZnN0X3J4X2NvbmZpZyAoIHN0cnVjdCBm c3RfcG9ydF9pbmZvICpwb3J0ICkKK2ZzdF9yeF9jb25maWcoc3RydWN0IGZzdF9wb3J0X2luZm8g KnBvcnQpCiB7Ci0gICAgICAgIGludCBpOwotICAgICAgICBpbnQgcGk7Ci0gICAgICAgIHVuc2ln bmVkIGludCBvZmZzZXQ7Ci0gICAgICAgIHVuc2lnbmVkIGxvbmcgZmxhZ3M7Ci0gICAgICAgIHN0 cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOwotCi0gICAgICAgIHBpICAgPSBwb3J0LT5pbmRleDsK LSAgICAgICAgY2FyZCA9IHBvcnQtPmNhcmQ7Ci0gICAgICAgIHNwaW5fbG9ja19pcnFzYXZlICgg JmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MgKTsKLSAgICAgICAgZm9yICggaSA9IDAgOyBpIDwgTlVN X1JYX0JVRkZFUiA7IGkrKyApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBvZmZzZXQgPSBC VUZfT0ZGU0VUICggcnhCdWZmZXJbcGldW2ldWzBdKTsKLQotICAgICAgICAgICAgICAgIEZTVF9X UlcgKCBjYXJkLCByeERlc2NyUmluZ1twaV1baV0ubGFkciwgKHUxNikgb2Zmc2V0ICk7Ci0gICAg ICAgICAgICAgICAgRlNUX1dSQiAoIGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtpXS5oYWRyLCAodTgp KCBvZmZzZXQgPj4gMTYgKSk7Ci0gICAgICAgICAgICAgICAgRlNUX1dSVyAoIGNhcmQsIHJ4RGVz Y3JSaW5nW3BpXVtpXS5iY250LAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGNudl9iY250ICggTEVOX1JYX0JVRkZFUiApKTsKLSAgICAgICAgICAgICAgICBGU1RfV1JX ICggY2FyZCwgcnhEZXNjclJpbmdbcGldW2ldLm1jbnQsIDAgKTsKLSAgICAgICAgICAgICAgICBG U1RfV1JCICggY2FyZCwgcnhEZXNjclJpbmdbcGldW2ldLmJpdHMsIERNQV9PV04gKTsKLSAgICAg ICAgfQotICAgICAgICBwb3J0LT5yeHBvcyAgPSAwOwotICAgICAgICBzcGluX3VubG9ja19pcnFy ZXN0b3JlICggJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MgKTsKKwlpbnQgaTsKKwlpbnQgcGk7CisJ dW5zaWduZWQgaW50IG9mZnNldDsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCXN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkOworCisJcGkgPSBwb3J0LT5pbmRleDsKKwljYXJkID0gcG9ydC0+Y2Fy ZDsKKwlzcGluX2xvY2tfaXJxc2F2ZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJZm9yIChp ID0gMDsgaSA8IE5VTV9SWF9CVUZGRVI7IGkrKykgeworCQlvZmZzZXQgPSBCVUZfT0ZGU0VUKHJ4 QnVmZmVyW3BpXVtpXVswXSk7CisKKwkJRlNUX1dSVyhjYXJkLCByeERlc2NyUmluZ1twaV1baV0u bGFkciwgKHUxNikgb2Zmc2V0KTsKKwkJRlNUX1dSQihjYXJkLCByeERlc2NyUmluZ1twaV1baV0u aGFkciwgKHU4KSAob2Zmc2V0ID4+IDE2KSk7CisJCUZTVF9XUlcoY2FyZCwgcnhEZXNjclJpbmdb cGldW2ldLmJjbnQsIGNudl9iY250KExFTl9SWF9CVUZGRVIpKTsKKwkJRlNUX1dSVyhjYXJkLCBy eERlc2NyUmluZ1twaV1baV0ubWNudCwgTEVOX1JYX0JVRkZFUik7CisJCUZTVF9XUkIoY2FyZCwg cnhEZXNjclJpbmdbcGldW2ldLmJpdHMsIERNQV9PV04pOworCX0KKwlwb3J0LT5yeHBvcyA9IDA7 CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CiB9CiAK LQogLyoKICAqICAgICAgU2V0dXAgcG9ydCBUeCBidWZmZXJzCiAgKi8KIHN0YXRpYyB2b2lkCi1m c3RfdHhfY29uZmlnICggc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQgKQorZnN0X3R4X2NvbmZp ZyhzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCkKIHsKLSAgICAgICAgaW50IGk7Ci0gICAgICAg IGludCBwaTsKLSAgICAgICAgdW5zaWduZWQgaW50IG9mZnNldDsKLSAgICAgICAgdW5zaWduZWQg bG9uZyBmbGFnczsKLSAgICAgICAgc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7Ci0KLSAgICAg ICAgcGkgICA9IHBvcnQtPmluZGV4OwotICAgICAgICBjYXJkID0gcG9ydC0+Y2FyZDsKLSAgICAg ICAgc3Bpbl9sb2NrX2lycXNhdmUgKCAmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOwotICAgICAg ICBmb3IgKCBpID0gMCA7IGkgPCBOVU1fVFhfQlVGRkVSIDsgaSsrICkKLSAgICAgICAgewotICAg ICAgICAgICAgICAgIG9mZnNldCA9IEJVRl9PRkZTRVQgKCB0eEJ1ZmZlcltwaV1baV1bMF0pOwot Ci0gICAgICAgICAgICAgICAgRlNUX1dSVyAoIGNhcmQsIHR4RGVzY3JSaW5nW3BpXVtpXS5sYWRy LCAodTE2KSBvZmZzZXQgKTsKLSAgICAgICAgICAgICAgICBGU1RfV1JCICggY2FyZCwgdHhEZXNj clJpbmdbcGldW2ldLmhhZHIsICh1OCkoIG9mZnNldCA+PiAxNiApKTsKLSAgICAgICAgICAgICAg ICBGU1RfV1JXICggY2FyZCwgdHhEZXNjclJpbmdbcGldW2ldLmJjbnQsIDAgKTsKLSAgICAgICAg ICAgICAgICBGU1RfV1JCICggY2FyZCwgdHhEZXNjclJpbmdbcGldW2ldLmJpdHMsIDAgKTsKLSAg ICAgICAgfQotICAgICAgICBwb3J0LT50eHBvcyAgPSAwOwotICAgICAgICBwb3J0LT50eGlwb3Mg PSAwOwotICAgICAgICBwb3J0LT50eGNudCAgPSAwOwotICAgICAgICBzcGluX3VubG9ja19pcnFy ZXN0b3JlICggJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MgKTsKKwlpbnQgaTsKKwlpbnQgcGk7CisJ dW5zaWduZWQgaW50IG9mZnNldDsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCXN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkOworCisJcGkgPSBwb3J0LT5pbmRleDsKKwljYXJkID0gcG9ydC0+Y2Fy ZDsKKwlzcGluX2xvY2tfaXJxc2F2ZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJZm9yIChp ID0gMDsgaSA8IE5VTV9UWF9CVUZGRVI7IGkrKykgeworCQlvZmZzZXQgPSBCVUZfT0ZGU0VUKHR4 QnVmZmVyW3BpXVtpXVswXSk7CisKKwkJRlNUX1dSVyhjYXJkLCB0eERlc2NyUmluZ1twaV1baV0u bGFkciwgKHUxNikgb2Zmc2V0KTsKKwkJRlNUX1dSQihjYXJkLCB0eERlc2NyUmluZ1twaV1baV0u aGFkciwgKHU4KSAob2Zmc2V0ID4+IDE2KSk7CisJCUZTVF9XUlcoY2FyZCwgdHhEZXNjclJpbmdb cGldW2ldLmJjbnQsIDApOworCQlGU1RfV1JCKGNhcmQsIHR4RGVzY3JSaW5nW3BpXVtpXS5iaXRz LCAwKTsKKwl9CisJcG9ydC0+dHhwb3MgPSAwOworCXBvcnQtPnR4aXBvcyA9IDA7CisJcG9ydC0+ c3RhcnQgPSAwOworCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmNhcmQtPmNhcmRfbG9jaywgZmxh Z3MpOwogfQogCisvKiAgICAgIFRFMSBBbGFybSBjaGFuZ2UgaW50ZXJydXB0IGV2ZW50CisgKi8K K3N0YXRpYyB2b2lkCitmc3RfaW50cl90ZTFfYWxhcm0oc3RydWN0IGZzdF9jYXJkX2luZm8gKmNh cmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0KQoreworCXU4IGxvczsKKwl1OCBycmE7CisJ dTggYWlzOworCisJbG9zID0gRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5sb3NzT2ZTaWduYWwpOwor CXJyYSA9IEZTVF9SREIoY2FyZCwgc3VTdGF0dXMucmVjZWl2ZVJlbW90ZUFsYXJtKTsKKwlhaXMg PSBGU1RfUkRCKGNhcmQsIHN1U3RhdHVzLmFsYXJtSW5kaWNhdGlvblNpZ25hbCk7CisKKwlpZiAo bG9zKSB7CisJCS8qCisJCSAqIExvc3QgdGhlIGxpbmsKKwkJICovCisJCWlmIChuZXRpZl9jYXJy aWVyX29rKHBvcnRfdG9fZGV2KHBvcnQpKSkgeworCQkJZGJnKERCR19JTlRSLCAiTmV0IGNhcnJp ZXIgb2ZmXG4iKTsKKwkJCW5ldGlmX2NhcnJpZXJfb2ZmKHBvcnRfdG9fZGV2KHBvcnQpKTsKKwkJ fQorCX0gZWxzZSB7CisJCS8qCisJCSAqIExpbmsgYXZhaWxhYmxlCisJCSAqLworCQlpZiAoIW5l dGlmX2NhcnJpZXJfb2socG9ydF90b19kZXYocG9ydCkpKSB7CisJCQlkYmcoREJHX0lOVFIsICJO ZXQgY2FycmllciBvblxuIik7CisJCQluZXRpZl9jYXJyaWVyX29uKHBvcnRfdG9fZGV2KHBvcnQp KTsKKwkJfQorCX0KKworCWlmIChsb3MpCisJCWRiZyhEQkdfSU5UUiwgIkFzc2VydCBMT1MgQWxh cm1cbiIpOworCWVsc2UKKwkJZGJnKERCR19JTlRSLCAiRGUtYXNzZXJ0IExPUyBBbGFybVxuIik7 CisJaWYgKHJyYSkKKwkJZGJnKERCR19JTlRSLCAiQXNzZXJ0IFJSQSBBbGFybVxuIik7CisJZWxz ZQorCQlkYmcoREJHX0lOVFIsICJEZS1hc3NlcnQgUlJBIEFsYXJtXG4iKTsKKworCWlmIChhaXMp CisJCWRiZyhEQkdfSU5UUiwgIkFzc2VydCBBSVMgQWxhcm1cbiIpOworCWVsc2UKKwkJZGJnKERC R19JTlRSLCAiRGUtYXNzZXJ0IEFJUyBBbGFybVxuIik7Cit9CiAKIC8qICAgICAgQ29udHJvbCBz aWduYWwgY2hhbmdlIGludGVycnVwdCBldmVudAogICovCi1zdGF0aWMgaXJxcmV0dXJuX3QKLWZz dF9pbnRyX2N0bGNoZyAoIHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3Bv cnRfaW5mbyAqcG9ydCApCitzdGF0aWMgdm9pZAorZnN0X2ludHJfY3RsY2hnKHN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCkKIHsKLSAgICAgICAg aW50IHNpZ25hbHM7CisJaW50IHNpZ25hbHM7CiAKLSAgICAgICAgc2lnbmFscyA9IEZTVF9SREwg KCBjYXJkLCB2MjREZWJvdW5jZWRTdHNbcG9ydC0+aW5kZXhdKTsKKwlzaWduYWxzID0gRlNUX1JE TChjYXJkLCB2MjREZWJvdW5jZWRTdHNbcG9ydC0+aW5kZXhdKTsKIAotICAgICAgICBpZiAoIHNp Z25hbHMgJiAoKCBwb3J0LT5od2lmID09IFgyMSApID8gSVBTVFNfSU5ESUNBVEUgOiBJUFNUU19E Q0QgKSkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIGlmICggISBuZXRpZl9jYXJyaWVyX29r ICggcG9ydF90b19kZXYgKCBwb3J0ICkpKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAg ICAgICAgICAgICAgIGRiZyAoIERCR19JTlRSLCJEQ0QgYWN0aXZlXG4iKTsKLSAgICAgICAgICAg ICAgICAgICAgICAgIG5ldGlmX2NhcnJpZXJfb24gKCBwb3J0X3RvX2RldiAoIHBvcnQgKSk7Ci0g ICAgICAgICAgICAgICAgfQotICAgICAgICB9Ci0gICAgICAgIGVsc2UKLSAgICAgICAgewotICAg ICAgICAgICAgICAgIGlmICggbmV0aWZfY2Fycmllcl9vayAoIHBvcnRfdG9fZGV2ICggcG9ydCAp KSkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBkYmcgKCBEQkdf SU5UUiwiRENEIGxvc3RcbiIpOwotICAgICAgICAgICAgICAgICAgICAgICAgbmV0aWZfY2Fycmll cl9vZmYgKCBwb3J0X3RvX2RldiAoIHBvcnQgKSk7Ci0gICAgICAgICAgICAgICAgfQotICAgICAg ICB9Ci0JcmV0dXJuIElSUV9IQU5ETEVEOworCWlmIChzaWduYWxzICYgKCgocG9ydC0+aHdpZiA9 PSBYMjEpIHx8IChwb3J0LT5od2lmID09IFgyMUQpKQorCQkgICAgICAgPyBJUFNUU19JTkRJQ0FU RSA6IElQU1RTX0RDRCkpIHsKKwkJaWYgKCFuZXRpZl9jYXJyaWVyX29rKHBvcnRfdG9fZGV2KHBv cnQpKSkgeworCQkJZGJnKERCR19JTlRSLCAiRENEIGFjdGl2ZVxuIik7CisJCQluZXRpZl9jYXJy aWVyX29uKHBvcnRfdG9fZGV2KHBvcnQpKTsKKwkJfQorCX0gZWxzZSB7CisJCWlmIChuZXRpZl9j YXJyaWVyX29rKHBvcnRfdG9fZGV2KHBvcnQpKSkgeworCQkJZGJnKERCR19JTlRSLCAiRENEIGxv c3RcbiIpOworCQkJbmV0aWZfY2Fycmllcl9vZmYocG9ydF90b19kZXYocG9ydCkpOworCQl9CisJ fQorfQorCisvKiAgICAgIExvZyBSeCBFcnJvcnMKKyAqLworc3RhdGljIHZvaWQKK2ZzdF9sb2df cnhfZXJyb3Ioc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZv ICpwb3J0LAorCQkgdW5zaWduZWQgY2hhciBkbWFiaXRzLCBpbnQgcnhwLCB1bnNpZ25lZCBzaG9y dCBsZW4pCit7CisJc3RydWN0IG5ldF9kZXZpY2UgKmRldiA9IHBvcnRfdG9fZGV2KHBvcnQpOwor CXN0cnVjdCBuZXRfZGV2aWNlX3N0YXRzICpzdGF0cyA9IGhkbGNfc3RhdHMoZGV2KTsKKworCS8q IAorCSAqIEluY3JlbWVudCB0aGUgYXBwcm9wcmlhdGUgZXJyb3IgY291bnRlcgorCSAqLworCXN0 YXRzLT5yeF9lcnJvcnMrKzsKKwlpZiAoZG1hYml0cyAmIFJYX09GTE8pIHsKKwkJc3RhdHMtPnJ4 X2ZpZm9fZXJyb3JzKys7CisJCWRiZyhEQkdfQVNTLCAiUnggZmlmbyBlcnJvciBvbiBjYXJkICVk IHBvcnQgJWQgYnVmZmVyICVkXG4iLAorCQkgICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgs IHJ4cCk7CisJfQorCWlmIChkbWFiaXRzICYgUlhfQ1JDKSB7CisJCXN0YXRzLT5yeF9jcmNfZXJy b3JzKys7CisJCWRiZyhEQkdfQVNTLCAiUnggY3JjIGVycm9yIG9uIGNhcmQgJWQgcG9ydCAlZFxu IiwKKwkJICAgIGNhcmQtPmNhcmRfbm8sIHBvcnQtPmluZGV4KTsKKwl9CisJaWYgKGRtYWJpdHMg JiBSWF9GUkFNKSB7CisJCXN0YXRzLT5yeF9mcmFtZV9lcnJvcnMrKzsKKwkJZGJnKERCR19BU1Ms ICJSeCBmcmFtZSBlcnJvciBvbiBjYXJkICVkIHBvcnQgJWRcbiIsCisJCSAgICBjYXJkLT5jYXJk X25vLCBwb3J0LT5pbmRleCk7CisJfQorCWlmIChkbWFiaXRzID09IChSWF9TVFAgfCBSWF9FTlAp KSB7CisJCXN0YXRzLT5yeF9sZW5ndGhfZXJyb3JzKys7CisJCWRiZyhEQkdfQVNTLCAiUnggbGVu Z3RoIGVycm9yICglZCkgb24gY2FyZCAlZCBwb3J0ICVkXG4iLAorCQkgICAgbGVuLCBjYXJkLT5j YXJkX25vLCBwb3J0LT5pbmRleCk7CisJfQogfQogCisvKiAgICAgIFJ4IEVycm9yIFJlY292ZXJ5 CisgKi8KK3N0YXRpYyB2b2lkCitmc3RfcmVjb3Zlcl9yeF9lcnJvcihzdHJ1Y3QgZnN0X2NhcmRf aW5mbyAqY2FyZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsCisJCSAgICAgdW5zaWduZWQg Y2hhciBkbWFiaXRzLCBpbnQgcnhwLCB1bnNpZ25lZCBzaG9ydCBsZW4pCit7CisJaW50IGk7CisJ aW50IHBpOworCisJcGkgPSBwb3J0LT5pbmRleDsKKwkvKiAKKwkgKiBEaXNjYXJkIGJ1ZmZlciBk ZXNjcmlwdG9ycyB1bnRpbCB3ZSBzZWUgdGhlIHN0YXJ0IG9mIHRoZQorCSAqIG5leHQgZnJhbWUu ICBOb3RlIHRoYXQgZm9yIGxvbmcgZnJhbWVzIHRoaXMgY291bGQgYmUgaW4KKwkgKiBhIHN1YnNl cXVlbnQgaW50ZXJydXB0LiAKKwkgKi8KKwlpID0gMDsKKwl3aGlsZSAoKGRtYWJpdHMgJiAoRE1B X09XTiB8IFJYX1NUUCkpID09IDApIHsKKwkJRlNUX1dSQihjYXJkLCByeERlc2NyUmluZ1twaV1b cnhwXS5iaXRzLCBETUFfT1dOKTsKKwkJcnhwID0gKHJ4cCsxKSAlIE5VTV9SWF9CVUZGRVI7CisJ CWlmICgrK2kgPiBOVU1fUlhfQlVGRkVSKSB7CisJCQlkYmcoREJHX0FTUywgImludHJfcng6IERp c2NhcmRpbmcgbW9yZSBidWZzIgorCQkJICAgICIgdGhhbiB3ZSBoYXZlXG4iKTsKKwkJCWJyZWFr OworCQl9CisJCWRtYWJpdHMgPSBGU1RfUkRCKGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtyeHBdLmJp dHMpOworCQlkYmcoREJHX0FTUywgIkRNQSBCaXRzIG9mIG5leHQgYnVmZmVyIHdhcyAleFxuIiwg ZG1hYml0cyk7CisJfQorCWRiZyhEQkdfQVNTLCAiVGhlcmUgd2VyZSAlZCBzdWJzZXF1ZW50IGJ1 ZmZlcnMgaW4gZXJyb3JcbiIsIGkpOworCisJLyogRGlzY2FyZCB0aGUgdGVybWluYWwgYnVmZmVy ICovCisJaWYgKCEoZG1hYml0cyAmIERNQV9PV04pKSB7CisJCUZTVF9XUkIoY2FyZCwgcnhEZXNj clJpbmdbcGldW3J4cF0uYml0cywgRE1BX09XTik7CisJCXJ4cCA9IChyeHArMSkgJSBOVU1fUlhf QlVGRkVSOworCX0KKwlwb3J0LT5yeHBvcyA9IHJ4cDsKKwlyZXR1cm47CisKK30KIAogLyogICAg ICBSeCBjb21wbGV0ZSBpbnRlcnJ1cHQKICAqLwogc3RhdGljIHZvaWQKLWZzdF9pbnRyX3J4ICgg c3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0ICkK K2ZzdF9pbnRyX3J4KHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRf aW5mbyAqcG9ydCkKIHsKLSAgICAgICAgdW5zaWduZWQgY2hhciBkbWFiaXRzOwotICAgICAgICBp bnQgcGk7Ci0gICAgICAgIGludCByeHA7Ci0gICAgICAgIHVuc2lnbmVkIHNob3J0IGxlbjsKLSAg ICAgICAgc3RydWN0IHNrX2J1ZmYgKnNrYjsKKwl1bnNpZ25lZCBjaGFyIGRtYWJpdHM7CisJaW50 IHBpOworCWludCByeHA7CisJaW50IHJ4X3N0YXR1czsKKwl1bnNpZ25lZCBzaG9ydCBsZW47CisJ c3RydWN0IHNrX2J1ZmYgKnNrYjsKIAlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gcG9ydF90b19k ZXYocG9ydCk7CiAJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnN0YXRzID0gaGRsY19zdGF0cyhk ZXYpOwotICAgICAgICBpbnQgaTsKIAorCS8qIENoZWNrIHdlIGhhdmUgYSBidWZmZXIgdG8gcHJv Y2VzcyAqLworCXBpID0gcG9ydC0+aW5kZXg7CisJcnhwID0gcG9ydC0+cnhwb3M7CisJZG1hYml0 cyA9IEZTVF9SREIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cyk7CisJaWYgKGRtYWJp dHMgJiBETUFfT1dOKSB7CisJCWRiZyhEQkdfUlggfCBEQkdfSU5UUiwgImludHJfcng6IE5vIGJ1 ZmZlciBwb3J0ICVkIHBvcyAlZFxuIiwKKwkJICAgIHBpLCByeHApOworCQlyZXR1cm47CisJfQor CWlmIChjYXJkLT5kbWFyeF9pbl9wcm9ncmVzcykgeworCQlyZXR1cm47CisJfQogCi0gICAgICAg IC8qIENoZWNrIHdlIGhhdmUgYSBidWZmZXIgdG8gcHJvY2VzcyAqLwotICAgICAgICBwaSAgPSBw b3J0LT5pbmRleDsKLSAgICAgICAgcnhwID0gcG9ydC0+cnhwb3M7Ci0gICAgICAgIGRtYWJpdHMg PSBGU1RfUkRCICggY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cyApOwotICAgICAgICBp ZiAoIGRtYWJpdHMgJiBETUFfT1dOICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIGRiZyAo IERCR19SWCB8IERCR19JTlRSLCJpbnRyX3J4OiBObyBidWZmZXIgcG9ydCAlZCBwb3MgJWRcbiIs Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcGksIHJ4cCApOwotICAg ICAgICAgICAgICAgIHJldHVybjsKLSAgICAgICAgfQotCi0gICAgICAgIC8qIEdldCBidWZmZXIg bGVuZ3RoICovCi0gICAgICAgIGxlbiA9IEZTVF9SRFcgKCBjYXJkLCByeERlc2NyUmluZ1twaV1b cnhwXS5tY250ICk7Ci0gICAgICAgIC8qIERpc2NhcmQgdGhlIENSQyAqLwotICAgICAgICBsZW4g LT0gMjsKLQotICAgICAgICAvKiBDaGVjayBidWZmZXIgbGVuZ3RoIGFuZCBmb3Igb3RoZXIgZXJy b3JzLiBXZSBpbnNpc3Qgb24gb25lIHBhY2tldAotICAgICAgICAgKiBpbiBvbmUgYnVmZmVyLiBU aGlzIHNpbXBsaWZpZXMgdGhpbmdzIGdyZWF0bHkgYW5kIHNpbmNlIHdlJ3ZlCi0gICAgICAgICAq IGFsbG9jYXRlZCA4SyBpdCBzaG91bGRuJ3QgYmUgYSByZWFsIHdvcmxkIGxpbWl0YXRpb24KLSAg ICAgICAgICovCi0gICAgICAgIGRiZyAoIERCR19SWCwiaW50cl9yeDogJWQsJWQ6IGZsYWdzICV4 IGxlbiAlZFxuIiwgcGksIHJ4cCwgZG1hYml0cywKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBsZW4gKTsKLSAgICAgICAgaWYgKCBkbWFiaXRzICE9ICggUlhfU1RQIHwg UlhfRU5QICkgfHwgbGVuID4gTEVOX1JYX0JVRkZFUiAtIDIgKQotICAgICAgICB7Ci0gICAgICAg ICAgICAgICAgc3RhdHMtPnJ4X2Vycm9ycysrOwotCi0gICAgICAgICAgICAgICAgLyogVXBkYXRl IGVycm9yIHN0YXRzIGFuZCBkaXNjYXJkIGJ1ZmZlciAqLwotICAgICAgICAgICAgICAgIGlmICgg ZG1hYml0cyAmIFJYX09GTE8gKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAg ICAgICAgIHN0YXRzLT5yeF9maWZvX2Vycm9ycysrOwotICAgICAgICAgICAgICAgIH0KLSAgICAg ICAgICAgICAgICBpZiAoIGRtYWJpdHMgJiBSWF9DUkMgKQotICAgICAgICAgICAgICAgIHsKLSAg ICAgICAgICAgICAgICAgICAgICAgIHN0YXRzLT5yeF9jcmNfZXJyb3JzKys7Ci0gICAgICAgICAg ICAgICAgfQotICAgICAgICAgICAgICAgIGlmICggZG1hYml0cyAmIFJYX0ZSQU0gKQotICAgICAg ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIHN0YXRzLT5yeF9mcmFtZV9lcnJv cnMrKzsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgICAgICAgICAgaWYgKCBkbWFiaXRzID09 ICggUlhfU1RQIHwgUlhfRU5QICkpCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAg ICAgICAgICAgc3RhdHMtPnJ4X2xlbmd0aF9lcnJvcnMrKzsKLSAgICAgICAgICAgICAgICB9CisJ LyogR2V0IGJ1ZmZlciBsZW5ndGggKi8KKwlsZW4gPSBGU1RfUkRXKGNhcmQsIHJ4RGVzY3JSaW5n W3BpXVtyeHBdLm1jbnQpOworCS8qIERpc2NhcmQgdGhlIENSQyAqLworCWxlbiAtPSAyOworCWlm IChsZW4gPT0gMCkgeworCQkvKgorCQkgKiBUaGlzIHNlZW1zIHRvIGhhcHBlbiBvbiB0aGUgVEUx IGludGVyZmFjZSBzb21ldGltZXMKKwkJICogc28gdGhyb3cgdGhlIGZyYW1lIGF3YXkgYW5kIGxv ZyB0aGUgZXZlbnQuCisJCSAqLworCQlwcmludGtfZXJyKCJGcmFtZSByZWNlaXZlZCB3aXRoIDAg bGVuZ3RoLiBDYXJkICVkIFBvcnQgJWRcbiIsCisJCQkgICBjYXJkLT5jYXJkX25vLCBwb3J0LT5p bmRleCk7CisJCS8qIFJldHVybiBkZXNjcmlwdG9yIHRvIGNhcmQgKi8KKwkJRlNUX1dSQihjYXJk LCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dOKTsKKworCQlyeHAgPSAocnhwKzEp ICUgTlVNX1JYX0JVRkZFUjsKKwkJcG9ydC0+cnhwb3MgPSByeHA7CisJCXJldHVybjsKKwl9CiAK LSAgICAgICAgICAgICAgICAvKiBEaXNjYXJkIGJ1ZmZlciBkZXNjcmlwdG9ycyB1bnRpbCB3ZSBz ZWUgdGhlIGVuZCBvZiBwYWNrZXQKLSAgICAgICAgICAgICAgICAgKiBtYXJrZXIKLSAgICAgICAg ICAgICAgICAgKi8KLSAgICAgICAgICAgICAgICBpID0gMDsKLSAgICAgICAgICAgICAgICB3aGls ZSAoKCBkbWFiaXRzICYgKCBETUFfT1dOIHwgUlhfRU5QICkpID09IDAgKQotICAgICAgICAgICAg ICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIEZTVF9XUkIgKCBjYXJkLCByeERlc2NyUmlu Z1twaV1bcnhwXS5iaXRzLCBETUFfT1dOICk7Ci0gICAgICAgICAgICAgICAgICAgICAgICBpZiAo ICsrcnhwID49IE5VTV9SWF9CVUZGRVIgKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICByeHAgPSAwOwotICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCArK2kgPiBOVU1fUlhfQlVG RkVSICkKLSAgICAgICAgICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZGJnICggREJHX0FTUywiaW50cl9yeDogRGlzY2FyZGluZyBtb3JlIGJ1ZnMiCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiIHRoYW4gd2Ug aGF2ZVxuIik7Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOwotICAgICAg ICAgICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgICAgICAgICAgZG1hYml0cyA9IEZT VF9SREIgKCBjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzICk7Ci0gICAgICAgICAgICAg ICAgfQorCS8qIENoZWNrIGJ1ZmZlciBsZW5ndGggYW5kIGZvciBvdGhlciBlcnJvcnMuIFdlIGlu c2lzdCBvbiBvbmUgcGFja2V0CisJICogaW4gb25lIGJ1ZmZlci4gVGhpcyBzaW1wbGlmaWVzIHRo aW5ncyBncmVhdGx5IGFuZCBzaW5jZSB3ZSd2ZQorCSAqIGFsbG9jYXRlZCA4SyBpdCBzaG91bGRu J3QgYmUgYSByZWFsIHdvcmxkIGxpbWl0YXRpb24KKwkgKi8KKwlkYmcoREJHX1JYLCAiaW50cl9y eDogJWQsJWQ6IGZsYWdzICV4IGxlbiAlZFxuIiwgcGksIHJ4cCwgZG1hYml0cywgbGVuKTsKKwlp ZiAoZG1hYml0cyAhPSAoUlhfU1RQIHwgUlhfRU5QKSB8fCBsZW4gPiBMRU5fUlhfQlVGRkVSIC0g MikgeworCQlmc3RfbG9nX3J4X2Vycm9yKGNhcmQsIHBvcnQsIGRtYWJpdHMsIHJ4cCwgbGVuKTsK KwkJZnN0X3JlY292ZXJfcnhfZXJyb3IoY2FyZCwgcG9ydCwgZG1hYml0cywgcnhwLCBsZW4pOwor CQlyZXR1cm47CisJfQogCi0gICAgICAgICAgICAgICAgLyogRGlzY2FyZCB0aGUgdGVybWluYWwg YnVmZmVyICovCi0gICAgICAgICAgICAgICAgaWYgKCAhICggZG1hYml0cyAmIERNQV9PV04gKSkK LSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBGU1RfV1JCICggY2Fy ZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywgRE1BX09XTiApOwotICAgICAgICAgICAgICAg ICAgICAgICAgaWYgKCArK3J4cCA+PSBOVU1fUlhfQlVGRkVSICkKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcnhwID0gMDsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgICAgICAg ICAgcG9ydC0+cnhwb3MgPSByeHA7Ci0gICAgICAgICAgICAgICAgcmV0dXJuOwotICAgICAgICB9 Ci0KLSAgICAgICAgLyogQWxsb2NhdGUgU0tCICovCi0gICAgICAgIGlmICgoIHNrYiA9IGRldl9h bGxvY19za2IgKCBsZW4gKSkgPT0gTlVMTCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBk YmcgKCBEQkdfUlgsImludHJfcng6IGNhbid0IGFsbG9jYXRlIGJ1ZmZlclxuIik7Ci0KLSAgICAg ICAgICAgICAgICBzdGF0cy0+cnhfZHJvcHBlZCsrOwotCi0gICAgICAgICAgICAgICAgLyogUmV0 dXJuIGRlc2NyaXB0b3IgdG8gY2FyZCAqLwotICAgICAgICAgICAgICAgIEZTVF9XUkIgKCBjYXJk LCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dOICk7Ci0KLSAgICAgICAgICAgICAg ICBpZiAoICsrcnhwID49IE5VTV9SWF9CVUZGRVIgKQotICAgICAgICAgICAgICAgICAgICAgICAg cG9ydC0+cnhwb3MgPSAwOwotICAgICAgICAgICAgICAgIGVsc2UKLSAgICAgICAgICAgICAgICAg ICAgICAgIHBvcnQtPnJ4cG9zID0gcnhwOwotICAgICAgICAgICAgICAgIHJldHVybjsKLSAgICAg ICAgfQotCi0gICAgICAgIG1lbWNweV9mcm9taW8gKCBza2JfcHV0ICggc2tiLCBsZW4gKSwKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FyZC0+bWVtICsgQlVGX09GRlNFVCAoIHJ4 QnVmZmVyW3BpXVtyeHBdWzBdKSwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVu ICk7Ci0KLSAgICAgICAgLyogUmVzZXQgYnVmZmVyIGRlc2NyaXB0b3IgKi8KLSAgICAgICAgRlNU X1dSQiAoIGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtyeHBdLmJpdHMsIERNQV9PV04gKTsKLSAgICAg ICAgaWYgKCArK3J4cCA+PSBOVU1fUlhfQlVGRkVSICkKLSAgICAgICAgICAgICAgICBwb3J0LT5y eHBvcyA9IDA7Ci0gICAgICAgIGVsc2UKLSAgICAgICAgICAgICAgICBwb3J0LT5yeHBvcyA9IHJ4 cDsKLQotICAgICAgICAvKiBVcGRhdGUgc3RhdHMgKi8KLSAgICAgICAgc3RhdHMtPnJ4X3BhY2tl dHMrKzsKLSAgICAgICAgc3RhdHMtPnJ4X2J5dGVzICs9IGxlbjsKLQotICAgICAgICAvKiBQdXNo IHVwc3RyZWFtICovCi0gICAgICAgIHNrYi0+bWFjLnJhdyA9IHNrYi0+ZGF0YTsKLSAgICAgICAg c2tiLT5kZXYgPSBkZXY7Ci0gICAgICAgIHNrYi0+cHJvdG9jb2wgPSBoZGxjX3R5cGVfdHJhbnMo c2tiLCBza2ItPmRldik7Ci0gICAgICAgIG5ldGlmX3J4ICggc2tiICk7CisJLyogQWxsb2NhdGUg U0tCICovCisJaWYgKChza2IgPSBkZXZfYWxsb2Nfc2tiKGxlbikpID09IE5VTEwpIHsKKwkJZGJn KERCR19SWCwgImludHJfcng6IGNhbid0IGFsbG9jYXRlIGJ1ZmZlclxuIik7CisKKwkJc3RhdHMt PnJ4X2Ryb3BwZWQrKzsKKworCQkvKiBSZXR1cm4gZGVzY3JpcHRvciB0byBjYXJkICovCisJCUZT VF9XUkIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywgRE1BX09XTik7CisKKwkJcnhw ID0gKHJ4cCsxKSAlIE5VTV9SWF9CVUZGRVI7CisJCXBvcnQtPnJ4cG9zID0gcnhwOworCQlyZXR1 cm47CisJfQogCi0gICAgICAgIGRldi0+bGFzdF9yeCA9IGppZmZpZXM7CisJLyoKKwkgKiBXZSBr bm93IHRoZSBsZW5ndGggd2UgbmVlZCB0byByZWNlaXZlLCBsZW4uCisJICogSXQncyBub3Qgd29y dGggdXNpbmcgdGhlIERNQSBmb3IgcmVhZHMgb2YgbGVzcyB0aGFuCisJICogRlNUX01JTl9ETUFf TEVOCisJICovCisKKwlpZiAoKGxlbiA8IEZTVF9NSU5fRE1BX0xFTikgfHwgKGNhcmQtPmZhbWls eSA9PSBGU1RfRkFNSUxZX1RYUCkpIHsKKwkJbWVtY3B5X2Zyb21pbyhza2JfcHV0KHNrYiwgbGVu KSwKKwkJCSAgICAgIGNhcmQtPm1lbSArIEJVRl9PRkZTRVQocnhCdWZmZXJbcGldW3J4cF1bMF0p LAorCQkJICAgICAgbGVuKTsKKworCQkvKiBSZXNldCBidWZmZXIgZGVzY3JpcHRvciAqLworCQlG U1RfV1JCKGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtyeHBdLmJpdHMsIERNQV9PV04pOworCisJCS8q IFVwZGF0ZSBzdGF0cyAqLworCQlzdGF0cy0+cnhfcGFja2V0cysrOworCQlzdGF0cy0+cnhfYnl0 ZXMgKz0gbGVuOworCisJCS8qIFB1c2ggdXBzdHJlYW0gKi8KKwkJZGJnKERCR19SWCwgIlB1c2hp bmcgZnJhbWUgdXAgdGhlIHN0YWNrXG4iKTsKKwkJc2tiLT5tYWMucmF3ID0gc2tiLT5kYXRhOwor CQlza2ItPmRldiA9IGRldjsKKwkJaWYgKHBvcnQtPm1vZGUgPT0gRlNUX1JBVykgeworCQkJLyoK KwkJCSAqIE1hcmsgaXQgZm9yIG91ciBvd24gcmF3IHNvY2tldHMgaW50ZXJmYWNlCisJCQkgKi8K KwkJCXNrYi0+cHJvdG9jb2wgPSBodG9ucyhFVEhfUF9DVVNUKTsKKwkJCXNrYi0+cGt0X3R5cGUg PSBQQUNLRVRfSE9TVDsKKwkJfSBlbHNlIHsKKwkJCXNrYi0+cHJvdG9jb2wgPSBoZGxjX3R5cGVf dHJhbnMoc2tiLCBza2ItPmRldik7CisJCX0KKwkJcnhfc3RhdHVzID0gbmV0aWZfcngoc2tiKTsK KwkJZnN0X3Byb2Nlc3Nfcnhfc3RhdHVzKHJ4X3N0YXR1cywgcG9ydF90b19kZXYocG9ydCktPm5h bWUpOworCQlpZiAocnhfc3RhdHVzID09IE5FVF9SWF9EUk9QKSB7CisJCQlzdGF0cy0+cnhfZHJv cHBlZCsrOworCQl9CisJCWRldi0+bGFzdF9yeCA9IGppZmZpZXM7CisJfSBlbHNlIHsKKwkJY2Fy ZC0+ZG1hX3NrYl9yeCA9IHNrYjsKKwkJY2FyZC0+ZG1hX3BvcnRfcnggPSBwb3J0OworCQljYXJk LT5kbWFfbGVuX3J4ID0gbGVuOworCQljYXJkLT5kbWFfcnhwb3MgPSByeHA7CisJCWZzdF9yeF9k bWEoY2FyZCwgKGNoYXIgKikgY2FyZC0+cnhfZG1hX2hhbmRsZV9jYXJkLAorCQkJICAgKGNoYXIg KikgQlVGX09GRlNFVChyeEJ1ZmZlcltwaV1bcnhwXVswXSksIGxlbik7CisJfQorCWlmIChyeHAg IT0gcG9ydC0+cnhwb3MpIHsKKwkJZGJnKERCR19BU1MsICJBYm91dCB0byBpbmNyZW1lbnQgcnhw b3MgYnkgbW9yZSB0aGFuIDFcbiIpOworCQlkYmcoREJHX0FTUywgInJ4cCA9ICVkIHJ4cG9zID0g JWRcbiIsIHJ4cCwgcG9ydC0+cnhwb3MpOworCX0KKwlyeHAgPSAocnhwKzEpICUgTlVNX1JYX0JV RkZFUjsKKwlwb3J0LT5yeHBvcyA9IHJ4cDsKIH0KIAorLyoKKyAqICAgICAgVGhlIGJvdHRvbSBo YWxmcyB0byB0aGUgSVNSCisgKgorICovCisKK3N0YXRpYyB2b2lkCitkb19ib3R0b21faGFsZl90 eChzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCkKK3sKKwlzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAq cG9ydDsKKwlpbnQgcGk7CisJaW50IHR4cV9sZW5ndGg7CisJc3RydWN0IHNrX2J1ZmYgKnNrYjsK Kwl1bnNpZ25lZCBsb25nIGZsYWdzOworCXN0cnVjdCBuZXRfZGV2aWNlICpkZXY7CisJc3RydWN0 IG5ldF9kZXZpY2Vfc3RhdHMgKnN0YXRzOworCisJLyoKKwkgKiAgRmluZCBhIGZyZWUgYnVmZmVy IGZvciB0aGUgdHJhbnNtaXQKKwkgKiAgU3RlcCB0aHJvdWdoIGVhY2ggcG9ydCBvbiB0aGlzIGNh cmQKKwkgKi8KKworCWRiZyhEQkdfVFgsICJkb19ib3R0b21faGFsZl90eFxuIik7CisJZm9yIChw aSA9IDAsIHBvcnQgPSBjYXJkLT5wb3J0czsgcGkgPCBjYXJkLT5ucG9ydHM7IHBpKyssIHBvcnQr KykgeworCQlpZiAoIXBvcnQtPnJ1bikKKwkJCWNvbnRpbnVlOworCisgICAgICAgICAgICAgICAg ZGV2ID0gcG9ydF90b19kZXYocG9ydCk7CisgICAgICAgICAgICAgICAgc3RhdHMgPSBoZGxjX3N0 YXRzKGRldik7CisJCXdoaWxlICghCisJCSAgICAgICAoRlNUX1JEQihjYXJkLCB0eERlc2NyUmlu Z1twaV1bcG9ydC0+dHhwb3NdLmJpdHMpICYKKwkJCURNQV9PV04pCisgICAgICAgICAgICAgICAg ICAgICAgICYmICEoY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MpKSB7CisJCQkvKgorCQkJICogVGhl cmUgZG9lc24ndCBzZWVtIHRvIGJlIGEgdHhkb25lIGV2ZW50IHBlci1zZQorCQkJICogV2Ugc2Vl bSB0byBoYXZlIHRvIGRlZHVjZSBpdCwgYnkgY2hlY2tpbmcgdGhlIERNQV9PV04KKwkJCSAqIGJp dCBvbiB0aGUgbmV4dCBidWZmZXIgd2UgdGhpbmsgd2UgY2FuIHVzZQorCQkJICovCisJCQlzcGlu X2xvY2tfaXJxc2F2ZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJCQlpZiAoKHR4cV9sZW5n dGggPSBwb3J0LT50eHFlIC0gcG9ydC0+dHhxcykgPCAwKSB7CisJCQkJLyoKKwkJCQkgKiBUaGlz IGlzIHRoZSBjYXNlIHdoZXJlIG9uZSBoYXMgd3JhcHBlZCBhbmQgdGhlCisJCQkJICogbWF0aHMg Z2l2ZXMgdXMgYSBuZWdhdGl2ZSBudW1iZXIKKwkJCQkgKi8KKwkJCQl0eHFfbGVuZ3RoID0gdHhx X2xlbmd0aCArIEZTVF9UWFFfREVQVEg7CisJCQl9CisJCQlzcGluX3VubG9ja19pcnFyZXN0b3Jl KCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwkJCWlmICh0eHFfbGVuZ3RoID4gMCkgeworCQkJ CS8qCisJCQkJICogVGhlcmUgaXMgc29tZXRoaW5nIHRvIHNlbmQKKwkJCQkgKi8KKwkJCQlzcGlu X2xvY2tfaXJxc2F2ZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJCQkJc2tiID0gcG9ydC0+ dHhxW3BvcnQtPnR4cXNdOworCQkJCXBvcnQtPnR4cXMrKzsKKwkJCQlpZiAocG9ydC0+dHhxcyA9 PSBGU1RfVFhRX0RFUFRIKSB7CisJCQkJCXBvcnQtPnR4cXMgPSAwOworCQkJCX0KKwkJCQlzcGlu X3VubG9ja19pcnFyZXN0b3JlKCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwkJCQkvKgorCQkJ CSAqIGNvcHkgdGhlIGRhdGEgYW5kIHNldCB0aGUgcmVxdWlyZWQgaW5kaWNhdG9ycyBvbiB0aGUK KwkJCQkgKiBjYXJkLgorCQkJCSAqLworCQkJCUZTVF9XUlcoY2FyZCwgdHhEZXNjclJpbmdbcGld W3BvcnQtPnR4cG9zXS5iY250LAorCQkJCQljbnZfYmNudChza2ItPmxlbikpOworCQkJCWlmICgo c2tiLT5sZW4gPCBGU1RfTUlOX0RNQV9MRU4pCisJCQkJICAgIHx8IChjYXJkLT5mYW1pbHkgPT0g RlNUX0ZBTUlMWV9UWFApKSB7CisJCQkJCS8qIEVucXVldWUgdGhlIHBhY2tldCB3aXRoIG5vcm1h bCBpbyAqLworCQkJCQltZW1jcHlfdG9pbyhjYXJkLT5tZW0gKworCQkJCQkJICAgIEJVRl9PRkZT RVQodHhCdWZmZXJbcGldCisJCQkJCQkJICAgICAgIFtwb3J0LT4KKwkJCQkJCQkJdHhwb3NdWzBd KSwKKwkJCQkJCSAgICBza2ItPmRhdGEsIHNrYi0+bGVuKTsKKwkJCQkJRlNUX1dSQihjYXJkLAor CQkJCQkJdHhEZXNjclJpbmdbcGldW3BvcnQtPnR4cG9zXS4KKwkJCQkJCWJpdHMsCisJCQkJCQlE TUFfT1dOIHwgVFhfU1RQIHwgVFhfRU5QKTsKKwkJCQkJc3RhdHMtPnR4X3BhY2tldHMrKzsKKwkJ CQkJc3RhdHMtPnR4X2J5dGVzICs9IHNrYi0+bGVuOworCQkJCQlkZXYtPnRyYW5zX3N0YXJ0ID0g amlmZmllczsKKwkJCQl9IGVsc2UgeworCQkJCQkvKiBPciBkbyBpdCB0aHJvdWdoIGRtYSAqLwor CQkJCQltZW1jcHkoY2FyZC0+dHhfZG1hX2hhbmRsZV9ob3N0LAorCQkJCQkgICAgICAgc2tiLT5k YXRhLCBza2ItPmxlbik7CisJCQkJCWNhcmQtPmRtYV9wb3J0X3R4ID0gcG9ydDsKKwkJCQkJY2Fy ZC0+ZG1hX2xlbl90eCA9IHNrYi0+bGVuOworCQkJCQljYXJkLT5kbWFfdHhwb3MgPSBwb3J0LT50 eHBvczsKKwkJCQkJZnN0X3R4X2RtYShjYXJkLAorCQkJCQkJICAgKGNoYXIgKikgY2FyZC0+CisJ CQkJCQkgICB0eF9kbWFfaGFuZGxlX2NhcmQsCisJCQkJCQkgICAoY2hhciAqKQorCQkJCQkJICAg QlVGX09GRlNFVCh0eEJ1ZmZlcltwaV0KKwkJCQkJCQkgICAgICBbcG9ydC0+dHhwb3NdWzBdKSwK KwkJCQkJCSAgIHNrYi0+bGVuKTsKKwkJCQl9CisJCQkJaWYgKCsrcG9ydC0+dHhwb3MgPj0gTlVN X1RYX0JVRkZFUikKKwkJCQkJcG9ydC0+dHhwb3MgPSAwOworCQkJCS8qCisJCQkJICogSWYgd2Ug aGF2ZSBmbG93IGNvbnRyb2wgb24sIGNhbiB3ZSBub3cgcmVsZWFzZSBpdD8KKwkJCQkgKi8KKwkJ CQlpZiAocG9ydC0+c3RhcnQpIHsKKwkJCQkJaWYgKHR4cV9sZW5ndGggPCBmc3RfdHhxX2xvdykg eworCQkJCQkJbmV0aWZfd2FrZV9xdWV1ZShwb3J0X3RvX2RldgorCQkJCQkJCQkgKHBvcnQpKTsK KwkJCQkJCXBvcnQtPnN0YXJ0ID0gMDsKKwkJCQkJfQorCQkJCX0KKwkJCQlkZXZfa2ZyZWVfc2ti KHNrYik7CisJCQl9IGVsc2UgeworCQkJCS8qCisJCQkJICogTm90aGluZyB0byBzZW5kIHNvIGJy ZWFrIG91dCBvZiB0aGUgd2hpbGUgbG9vcAorCQkJCSAqLworCQkJCWJyZWFrOworCQkJfQorCQl9 CisJfQorfQorCitzdGF0aWMgdm9pZAorZG9fYm90dG9tX2hhbGZfcngoc3RydWN0IGZzdF9jYXJk X2luZm8gKmNhcmQpCit7CisJc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7CisJaW50IHBpOwor CWludCByeF9jb3VudCA9IDA7CisKKwkvKiBDaGVjayBmb3IgcnggY29tcGxldGlvbnMgb24gYWxs IHBvcnRzIG9uIHRoaXMgY2FyZCAqLworCWRiZyhEQkdfUlgsICJkb19ib3R0b21faGFsZl9yeFxu Iik7CisJZm9yIChwaSA9IDAsIHBvcnQgPSBjYXJkLT5wb3J0czsgcGkgPCBjYXJkLT5ucG9ydHM7 IHBpKyssIHBvcnQrKykgeworCQlpZiAoIXBvcnQtPnJ1bikKKwkJCWNvbnRpbnVlOworCisJCXdo aWxlICghKEZTVF9SREIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3BvcnQtPnJ4cG9zXS5iaXRzKQor CQkJICYgRE1BX09XTikgJiYgIShjYXJkLT5kbWFyeF9pbl9wcm9ncmVzcykpIHsKKwkJCWlmIChy eF9jb3VudCA+IGZzdF9tYXhfcmVhZHMpIHsKKwkJCQkvKgorCQkJCSAqIERvbid0IHNwZW5kIGZv cmV2ZXIgaW4gcmVjZWl2ZSBwcm9jZXNzaW5nCisJCQkJICogU2NoZWR1bGUgYW5vdGhlciBldmVu dAorCQkJCSAqLworCQkJCWZzdF9xX3dvcmtfaXRlbSgmZnN0X3dvcmtfaW50cSwgY2FyZC0+Y2Fy ZF9ubyk7CisJCQkJdGFza2xldF9zY2hlZHVsZSgmZnN0X2ludF90YXNrKTsKKwkJCQlicmVhazsJ LyogTGVhdmUgdGhlIGxvb3AgKi8KKwkJCX0KKwkJCWZzdF9pbnRyX3J4KGNhcmQsIHBvcnQpOwor CQkJcnhfY291bnQrKzsKKwkJfQorCX0KK30KIAogLyoKICAqICAgICAgVGhlIGludGVycnVwdCBz ZXJ2aWNlIHJvdXRpbmUKICAqICAgICAgRGV2X2lkIGlzIG91ciBmc3RfY2FyZF9pbmZvIHBvaW50 ZXIKICAqLwotc3RhdGljIGlycXJldHVybl90Ci1mc3RfaW50ciAoIGludCBpcnEsIHZvaWQgKmRl dl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MgKQoraXJxcmV0dXJuX3QKK2ZzdF9pbnRyKGludCBp cnEsIHZvaWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpCiB7Ci0gICAgICAgIHN0cnVj dCBmc3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9y dDsKLSAgICAgICAgaW50IHJkaWR4OyAgICAgICAgICAgICAgICAgICAgICAvKiBFdmVudCBidWZm ZXIgaW5kaWNlcyAqLwotICAgICAgICBpbnQgd3JpZHg7Ci0gICAgICAgIGludCBldmVudDsgICAg ICAgICAgICAgICAgICAgICAgLyogQWN0dWFsIGV2ZW50IGZvciBwcm9jZXNzaW5nICovCi0gICAg ICAgIGludCBwaTsKLQotICAgICAgICBpZiAoKCBjYXJkID0gZGV2X2lkICkgPT0gTlVMTCApCi0g ICAgICAgIHsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfSU5UUiwiaW50cjogc3B1cmlvdXMg JWRcbiIsIGlycSApOwotICAgICAgICAgICAgICAgIHJldHVybiBJUlFfTk9ORTsKLSAgICAgICAg fQotCi0gICAgICAgIGRiZyAoIERCR19JTlRSLCJpbnRyOiAlZCAlcFxuIiwgaXJxLCBjYXJkICk7 Ci0KLSAgICAgICAgc3Bpbl9sb2NrICggJmNhcmQtPmNhcmRfbG9jayApOwotCi0gICAgICAgIC8q IENsZWFyIGFuZCByZXByaW1lIHRoZSBpbnRlcnJ1cHQgc291cmNlICovCi0gICAgICAgIGZzdF9j bGVhcl9pbnRyICggY2FyZCApOwotCi0gICAgICAgIC8qIFNldCB0aGUgc29mdHdhcmUgYWNrbm93 bGVkZ2UgKi8KLSAgICAgICAgRlNUX1dSQiAoIGNhcmQsIGludGVycnVwdEhhbmRzaGFrZSwgMHhF RSApOwotCi0gICAgICAgIC8qIERyYWluIHRoZSBldmVudCBxdWV1ZSAqLwotICAgICAgICByZGlk eCA9IEZTVF9SREIgKCBjYXJkLCBpbnRlcnJ1cHRFdmVudC5yZGluZGV4ICk7Ci0gICAgICAgIHdy aWR4ID0gRlNUX1JEQiAoIGNhcmQsIGludGVycnVwdEV2ZW50LndyaW5kZXggKTsKLSAgICAgICAg d2hpbGUgKCByZGlkeCAhPSB3cmlkeCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBldmVu dCA9IEZTVF9SREIgKCBjYXJkLCBpbnRlcnJ1cHRFdmVudC5ldm50YnVmZltyZGlkeF0pOwotCi0g ICAgICAgICAgICAgICAgcG9ydCA9ICZjYXJkLT5wb3J0c1tldmVudCAmIDB4MDNdOwotCi0gICAg ICAgICAgICAgICAgZGJnICggREJHX0lOVFIsImludHI6ICV4XG4iLCBldmVudCApOwotCi0gICAg ICAgICAgICAgICAgc3dpdGNoICggZXZlbnQgKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAg ICAgICAgICBjYXNlIENUTEFfQ0hHOgotICAgICAgICAgICAgICAgIGNhc2UgQ1RMQl9DSEc6Ci0g ICAgICAgICAgICAgICAgY2FzZSBDVExDX0NIRzoKLSAgICAgICAgICAgICAgICBjYXNlIENUTERf Q0hHOgotICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBwb3J0LT5ydW4gKQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBmc3RfaW50cl9jdGxjaGcgKCBjYXJkLCBwb3J0ICk7Ci0g ICAgICAgICAgICAgICAgICAgICAgICBicmVhazsKLQotICAgICAgICAgICAgICAgIGNhc2UgQUJU QV9TRU5UOgotICAgICAgICAgICAgICAgIGNhc2UgQUJUQl9TRU5UOgotICAgICAgICAgICAgICAg IGNhc2UgQUJUQ19TRU5UOgotICAgICAgICAgICAgICAgIGNhc2UgQUJURF9TRU5UOgotICAgICAg ICAgICAgICAgICAgICAgICAgZGJnICggREJHX1RYLCJBYm9ydCBjb21wbGV0ZSBwb3J0ICVkXG4i LCBldmVudCAmIDB4MDMgKTsKLSAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOworCXN0cnVj dCBmc3RfY2FyZF9pbmZvICpjYXJkOworCXN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0OworCWlu dCByZGlkeDsJCS8qIEV2ZW50IGJ1ZmZlciBpbmRpY2VzICovCisJaW50IHdyaWR4OworCWludCBl dmVudDsJCS8qIEFjdHVhbCBldmVudCBmb3IgcHJvY2Vzc2luZyAqLworCXVuc2lnbmVkIGludCBk bWFfaW50Y3NyID0gMDsKKwl1bnNpZ25lZCBpbnQgZG9fY2FyZF9pbnRlcnJ1cHQ7CisJdW5zaWdu ZWQgaW50IGludF9yZXRyeV9jb3VudDsKKworCWlmICgoY2FyZCA9IGRldl9pZCkgPT0gTlVMTCkg eworCQlkYmcoREJHX0lOVFIsICJpbnRyOiBzcHVyaW91cyAlZFxuIiwgaXJxKTsKKwkJcmV0dXJu IElSUV9OT05FOworCX0KIAotICAgICAgICAgICAgICAgIGNhc2UgVFhBX1VOREY6Ci0gICAgICAg ICAgICAgICAgY2FzZSBUWEJfVU5ERjoKLSAgICAgICAgICAgICAgICBjYXNlIFRYQ19VTkRGOgot ICAgICAgICAgICAgICAgIGNhc2UgVFhEX1VOREY6Ci0gICAgICAgICAgICAgICAgICAgICAgICAv KiBEaWZmaWN1bHQgdG8gc2VlIGhvdyB3ZSdkIGdldCB0aGlzIGdpdmVuIHRoYXQgd2UKLSAgICAg ICAgICAgICAgICAgICAgICAgICAqIGFsd2F5cyBsb2FkIHVwIHRoZSBlbnRpcmUgcGFja2V0IGZv ciBETUEuCi0gICAgICAgICAgICAgICAgICAgICAgICAgKi8KLSAgICAgICAgICAgICAgICAgICAg ICAgIGRiZyAoIERCR19UWCwiVHggdW5kZXJmbG93IHBvcnQgJWRcbiIsIGV2ZW50ICYgMHgwMyAp OwotICAgICAgICAgICAgICAgICAgICAgICAgaGRsY19zdGF0cyhwb3J0X3RvX2Rldihwb3J0KSkt PnR4X2Vycm9ycysrOwotICAgICAgICAgICAgICAgICAgICAgICAgaGRsY19zdGF0cyhwb3J0X3Rv X2Rldihwb3J0KSktPnR4X2ZpZm9fZXJyb3JzKys7Ci0gICAgICAgICAgICAgICAgICAgICAgICBi cmVhazsKKwkvKgorCSAqIENoZWNrIHRvIHNlZSBpZiB0aGUgaW50ZXJydXB0IHdhcyBmb3IgdGhp cyBjYXJkCisJICogcmV0dXJuIGlmIG5vdAorCSAqIE5vdGUgdGhhdCB0aGUgY2FsbCB0byBjbGVh ciB0aGUgaW50ZXJydXB0IGlzIGltcG9ydGFudAorCSAqLworCWRiZyhEQkdfSU5UUiwgImludHI6 ICVkICVwXG4iLCBpcnEsIGNhcmQpOworCWlmIChjYXJkLT5zdGF0ZSAhPSBGU1RfUlVOTklORykg eworCQlwcmludGtfZXJyCisJCSAgICAoIkludGVycnVwdCByZWNlaXZlZCBmb3IgY2FyZCAlZCBp biBhIG5vbiBydW5uaW5nIHN0YXRlICglZClcbiIsCisJCSAgICAgY2FyZC0+Y2FyZF9ubywgY2Fy ZC0+c3RhdGUpOworCisJCS8qIAorCQkgKiBJdCBpcyBwb3NzaWJsZSB0byByZWFsbHkgYmUgcnVu bmluZywgaS5lLiB3ZSBoYXZlIHJlLWxvYWRlZAorCQkgKiBhIHJ1bm5pbmcgY2FyZAorCQkgKiBD bGVhciBhbmQgcmVwcmltZSB0aGUgaW50ZXJydXB0IHNvdXJjZSAKKwkJICovCisJCWZzdF9jbGVh cl9pbnRyKGNhcmQpOworCQlyZXR1cm4gSVJRX0hBTkRMRUQ7CisJfQogCi0gICAgICAgICAgICAg ICAgY2FzZSBJTklUX0NQTFQ6Ci0gICAgICAgICAgICAgICAgICAgICAgICBkYmcgKCBEQkdfSU5J VCwiQ2FyZCBpbml0IE9LIGludHJcbiIpOwotICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7 CisJLyogQ2xlYXIgYW5kIHJlcHJpbWUgdGhlIGludGVycnVwdCBzb3VyY2UgKi8KKwlmc3RfY2xl YXJfaW50cihjYXJkKTsKIAotICAgICAgICAgICAgICAgIGNhc2UgSU5JVF9GQUlMOgotICAgICAg ICAgICAgICAgICAgICAgICAgZGJnICggREJHX0lOSVQsIkNhcmQgaW5pdCBGQUlMRUQgaW50clxu Iik7Ci0gICAgICAgICAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9JRkFJTEVEOwot ICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7CisJLyoKKwkgKiBJcyB0aGUgaW50ZXJydXB0 IGZvciB0aGlzIGNhcmQgKGhhbmRzaGFrZSA9PSAxKQorCSAqLworCWRvX2NhcmRfaW50ZXJydXB0 ID0gMDsKKwlpZiAoRlNUX1JEQihjYXJkLCBpbnRlcnJ1cHRIYW5kc2hha2UpID09IDEpIHsKKwkJ ZG9fY2FyZF9pbnRlcnJ1cHQgKz0gRlNUX0NBUkRfSU5UOworCQkvKiBTZXQgdGhlIHNvZnR3YXJl IGFja25vd2xlZGdlICovCisJCUZTVF9XUkIoY2FyZCwgaW50ZXJydXB0SGFuZHNoYWtlLCAweEVF KTsKKwl9CisJaWYgKGNhcmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYVSkgeworCQkvKgorCQkg KiBJcyBpdCBhIERNQSBJbnRlcnJ1cHQKKwkJICovCisJCWRtYV9pbnRjc3IgPSBpbmwoY2FyZC0+ cGNpX2NvbmYgKyBJTlRDU1JfOTA1NCk7CisJCWlmIChkbWFfaW50Y3NyICYgMHgwMDIwMDAwMCkg eworCQkJLyoKKwkJCSAqIERNQSBDaGFubmVsIDAgKFJ4IHRyYW5zZmVyIGNvbXBsZXRlKQorCQkJ ICovCisJCQlkYmcoREJHX1JYLCAiRE1BIFJ4IHhmZXIgY29tcGxldGVcbiIpOworCQkJb3V0Yigw eDgsIGNhcmQtPnBjaV9jb25mICsgRE1BQ1NSMCk7CisJCQlmc3RfcnhfZG1hX2NvbXBsZXRlKGNh cmQsIGNhcmQtPmRtYV9wb3J0X3J4LAorCQkJCQkgICAgY2FyZC0+ZG1hX2xlbl9yeCwgY2FyZC0+ ZG1hX3NrYl9yeCwKKwkJCQkJICAgIGNhcmQtPmRtYV9yeHBvcyk7CisJCQljYXJkLT5kbWFyeF9p bl9wcm9ncmVzcyA9IDA7CisJCQlkb19jYXJkX2ludGVycnVwdCArPSBGU1RfUlhfRE1BX0lOVDsK KwkJfQorCQlpZiAoZG1hX2ludGNzciAmIDB4MDA0MDAwMDApIHsKKwkJCS8qCisJCQkgKiBETUEg Q2hhbm5lbCAxIChUeCB0cmFuc2ZlciBjb21wbGV0ZSkKKwkJCSAqLworCQkJZGJnKERCR19UWCwg IkRNQSBUeCB4ZmVyIGNvbXBsZXRlXG4iKTsKKwkJCW91dGIoMHg4LCBjYXJkLT5wY2lfY29uZiAr IERNQUNTUjEpOworCQkJZnN0X3R4X2RtYV9jb21wbGV0ZShjYXJkLCBjYXJkLT5kbWFfcG9ydF90 eCwKKwkJCQkJICAgIGNhcmQtPmRtYV9sZW5fdHgsIGNhcmQtPmRtYV90eHBvcyk7CisJCQljYXJk LT5kbWF0eF9pbl9wcm9ncmVzcyA9IDA7CisJCQlkb19jYXJkX2ludGVycnVwdCArPSBGU1RfVFhf RE1BX0lOVDsKKwkJfQorCX0KIAotICAgICAgICAgICAgICAgIGRlZmF1bHQ6Ci0gICAgICAgICAg ICAgICAgICAgICAgICBwcmludGtfZXJyICgiaW50cjogdW5rbm93biBjYXJkIGV2ZW50IGNvZGUu IGlnbm9yZWRcbiIpOwotICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgICAg ICAgICAgfQorCS8qCisJICogSGF2ZSB3ZSBiZWVuIG1pc3NpbmcgSW50ZXJydXB0cworCSAqLwor CWludF9yZXRyeV9jb3VudCA9IEZTVF9SREwoY2FyZCwgaW50ZXJydXB0UmV0cnlDb3VudCk7CisJ aWYgKGludF9yZXRyeV9jb3VudCkgeworCQlkYmcoREJHX0FTUywgIkNhcmQgJWQgaW50X3JldHJ5 X2NvdW50IGlzICAlZFxuIiwKKwkJICAgIGNhcmQtPmNhcmRfbm8sIGludF9yZXRyeV9jb3VudCk7 CisJCUZTVF9XUkwoY2FyZCwgaW50ZXJydXB0UmV0cnlDb3VudCwgMCk7CisJfQogCi0gICAgICAg ICAgICAgICAgLyogQnVtcCBhbmQgd3JhcCB0aGUgaW5kZXggKi8KLSAgICAgICAgICAgICAgICBp ZiAoICsrcmRpZHggPj0gTUFYX0NJUkJVRkYgKQotICAgICAgICAgICAgICAgICAgICAgICAgcmRp ZHggPSAwOwotICAgICAgICB9Ci0gICAgICAgIEZTVF9XUkIgKCBjYXJkLCBpbnRlcnJ1cHRFdmVu dC5yZGluZGV4LCByZGlkeCApOwotCi0gICAgICAgIGZvciAoIHBpID0gMCwgcG9ydCA9IGNhcmQt PnBvcnRzIDsgcGkgPCBjYXJkLT5ucG9ydHMgOyBwaSsrLCBwb3J0KysgKQotICAgICAgICB7Ci0g ICAgICAgICAgICAgICAgaWYgKCAhIHBvcnQtPnJ1biApCi0gICAgICAgICAgICAgICAgICAgICAg ICBjb250aW51ZTsKLQotICAgICAgICAgICAgICAgIC8qIENoZWNrIGZvciByeCBjb21wbGV0aW9u cyAqLwotICAgICAgICAgICAgICAgIHdoaWxlICggISAoIEZTVF9SREIgKCBjYXJkLCByeERlc2Ny UmluZ1twaV1bcG9ydC0+cnhwb3NdLmJpdHMgKQotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICYgRE1BX09XTiApKQotICAgICAg ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIGZzdF9pbnRyX3J4ICggY2FyZCwg cG9ydCApOwotICAgICAgICAgICAgICAgIH0KKwlpZiAoIWRvX2NhcmRfaW50ZXJydXB0KSB7CisJ CXJldHVybiBJUlFfSEFORExFRDsKKwl9CiAKLSAgICAgICAgICAgICAgICAvKiBDaGVjayBmb3Ig VHggY29tcGxldGlvbnMgKi8KLSAgICAgICAgICAgICAgICB3aGlsZSAoIHBvcnQtPnR4Y250ID4g MCAmJiAhICggRlNUX1JEQiAoIGNhcmQsCi0gICAgICAgICAgICAgICAgICAgICAgICB0eERlc2Ny UmluZ1twaV1bcG9ydC0+dHhpcG9zXS5iaXRzICkgJiBETUFfT1dOICkpCi0gICAgICAgICAgICAg ICAgewotICAgICAgICAgICAgICAgICAgICAgICAgLS1wb3J0LT50eGNudDsKLSAgICAgICAgICAg ICAgICAgICAgICAgIGlmICggKytwb3J0LT50eGlwb3MgPj0gTlVNX1RYX0JVRkZFUiApCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHBvcnQtPnR4aXBvcyA9IDA7Ci0gICAgICAgICAg ICAgICAgICAgICAgICBuZXRpZl93YWtlX3F1ZXVlICggcG9ydF90b19kZXYgKCBwb3J0ICkpOwot ICAgICAgICAgICAgICAgIH0KLSAgICAgICAgfQorCS8qIFNjZWhkdWxlIHRoZSBib3R0b20gaGFs ZiBvZiB0aGUgSVNSICovCisJZnN0X3Ffd29ya19pdGVtKCZmc3Rfd29ya19pbnRxLCBjYXJkLT5j YXJkX25vKTsKKwl0YXNrbGV0X3NjaGVkdWxlKCZmc3RfaW50X3Rhc2spOworCisJLyogRHJhaW4g dGhlIGV2ZW50IHF1ZXVlICovCisJcmRpZHggPSBGU1RfUkRCKGNhcmQsIGludGVycnVwdEV2ZW50 LnJkaW5kZXgpICYgMHgxZjsKKwl3cmlkeCA9IEZTVF9SREIoY2FyZCwgaW50ZXJydXB0RXZlbnQu d3JpbmRleCkgJiAweDFmOworCXdoaWxlIChyZGlkeCAhPSB3cmlkeCkgeworCQlldmVudCA9IEZT VF9SREIoY2FyZCwgaW50ZXJydXB0RXZlbnQuZXZudGJ1ZmZbcmRpZHhdKTsKKwkJcG9ydCA9ICZj YXJkLT5wb3J0c1tldmVudCAmIDB4MDNdOworCisJCWRiZyhEQkdfSU5UUiwgIlByb2Nlc3Npbmcg SW50ZXJydXB0IGV2ZW50OiAleFxuIiwgZXZlbnQpOworCisJCXN3aXRjaCAoZXZlbnQpIHsKKwkJ Y2FzZSBURTFfQUxNQToKKwkJCWRiZyhEQkdfSU5UUiwgIlRFMSBBbGFybSBpbnRyXG4iKTsKKwkJ CWlmIChwb3J0LT5ydW4pCisJCQkJZnN0X2ludHJfdGUxX2FsYXJtKGNhcmQsIHBvcnQpOworCQkJ YnJlYWs7CisKKwkJY2FzZSBDVExBX0NIRzoKKwkJY2FzZSBDVExCX0NIRzoKKwkJY2FzZSBDVExD X0NIRzoKKwkJY2FzZSBDVExEX0NIRzoKKwkJCWlmIChwb3J0LT5ydW4pCisJCQkJZnN0X2ludHJf Y3RsY2hnKGNhcmQsIHBvcnQpOworCQkJYnJlYWs7CisKKwkJY2FzZSBBQlRBX1NFTlQ6CisJCWNh c2UgQUJUQl9TRU5UOgorCQljYXNlIEFCVENfU0VOVDoKKwkJY2FzZSBBQlREX1NFTlQ6CisJCQlk YmcoREJHX1RYLCAiQWJvcnQgY29tcGxldGUgcG9ydCAlZFxuIiwgcG9ydC0+aW5kZXgpOworCQkJ YnJlYWs7CisKKwkJY2FzZSBUWEFfVU5ERjoKKwkJY2FzZSBUWEJfVU5ERjoKKwkJY2FzZSBUWENf VU5ERjoKKwkJY2FzZSBUWERfVU5ERjoKKwkJCS8qIERpZmZpY3VsdCB0byBzZWUgaG93IHdlJ2Qg Z2V0IHRoaXMgZ2l2ZW4gdGhhdCB3ZQorCQkJICogYWx3YXlzIGxvYWQgdXAgdGhlIGVudGlyZSBw YWNrZXQgZm9yIERNQS4KKwkJCSAqLworCQkJZGJnKERCR19UWCwgIlR4IHVuZGVyZmxvdyBwb3J0 ICVkXG4iLCBwb3J0LT5pbmRleCk7CisgICAgICAgICAgICAgICAgICAgICAgICBoZGxjX3N0YXRz KHBvcnRfdG9fZGV2KHBvcnQpKS0+dHhfZXJyb3JzKys7CisgICAgICAgICAgICAgICAgICAgICAg ICBoZGxjX3N0YXRzKHBvcnRfdG9fZGV2KHBvcnQpKS0+dHhfZmlmb19lcnJvcnM7CisJCQlkYmco REJHX0FTUywgIlR4IHVuZGVyZmxvdyBvbiBjYXJkICVkIHBvcnQgJWRcbiIsCisJCQkgICAgY2Fy ZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgpOworCQkJYnJlYWs7CisKKwkJY2FzZSBJTklUX0NQTFQ6 CisJCQlkYmcoREJHX0lOSVQsICJDYXJkIGluaXQgT0sgaW50clxuIik7CisJCQlicmVhazsKKwor CQljYXNlIElOSVRfRkFJTDoKKwkJCWRiZyhEQkdfSU5JVCwgIkNhcmQgaW5pdCBGQUlMRUQgaW50 clxuIik7CisJCQljYXJkLT5zdGF0ZSA9IEZTVF9JRkFJTEVEOworCQkJYnJlYWs7CisKKwkJZGVm YXVsdDoKKwkJCXByaW50a19lcnIoImludHI6IHVua25vd24gY2FyZCBldmVudCAlZC4gaWdub3Jl ZFxuIiwKKwkJCQkgICBldmVudCk7CisJCQlicmVhazsKKwkJfQogCi0gICAgICAgIHNwaW5fdW5s b2NrICggJmNhcmQtPmNhcmRfbG9jayApOwotCXJldHVybiBJUlFfSEFORExFRDsKKwkJLyogQnVt cCBhbmQgd3JhcCB0aGUgaW5kZXggKi8KKwkJaWYgKCsrcmRpZHggPj0gTUFYX0NJUkJVRkYpCisJ CQlyZGlkeCA9IDA7CisJfQorCUZTVF9XUkIoY2FyZCwgaW50ZXJydXB0RXZlbnQucmRpbmRleCwg cmRpZHgpOworICAgICAgICByZXR1cm4gSVJRX0hBTkRMRUQ7CiB9CiAKLQogLyogICAgICBDaGVj ayB0aGF0IHRoZSBzaGFyZWQgbWVtb3J5IGNvbmZpZ3VyYXRpb24gaXMgb25lIHRoYXQgd2UgY2Fu IGhhbmRsZQogICogICAgICBhbmQgdGhhdCBzb21lIGJhc2ljIHBhcmFtZXRlcnMgYXJlIGNvcnJl Y3QKICAqLwogc3RhdGljIHZvaWQKLWNoZWNrX3N0YXJ0ZWRfb2sgKCBzdHJ1Y3QgZnN0X2NhcmRf aW5mbyAqY2FyZCApCitjaGVja19zdGFydGVkX29rKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJk KQogewotICAgICAgICBpbnQgaTsKKwlpbnQgaTsKIAotICAgICAgICAvKiBDaGVjayBzdHJ1Y3R1 cmUgdmVyc2lvbiBhbmQgZW5kIG1hcmtlciAqLwotICAgICAgICBpZiAoIEZTVF9SRFcgKCBjYXJk LCBzbWNWZXJzaW9uICkgIT0gU01DX1ZFUlNJT04gKQotICAgICAgICB7Ci0gICAgICAgICAgICAg ICAgcHJpbnRrX2VyciAoIkJhZCBzaGFyZWQgbWVtb3J5IHZlcnNpb24gJWQgZXhwZWN0ZWQgJWRc biIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZTVF9SRFcgKCBjYXJkLCBzbWNW ZXJzaW9uICksIFNNQ19WRVJTSU9OICk7Ci0gICAgICAgICAgICAgICAgY2FyZC0+c3RhdGUgPSBG U1RfQkFEVkVSU0lPTjsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0gICAgICAgIH0KLSAgICAg ICAgaWYgKCBGU1RfUkRMICggY2FyZCwgZW5kT2ZTbWNTaWduYXR1cmUgKSAhPSBFTkRfU0lHICkK LSAgICAgICAgewotICAgICAgICAgICAgICAgIHByaW50a19lcnIgKCJNaXNzaW5nIHNoYXJlZCBt ZW1vcnkgc2lnbmF0dXJlXG4iKTsKLSAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9C QURWRVJTSU9OOwotICAgICAgICAgICAgICAgIHJldHVybjsKLSAgICAgICAgfQotICAgICAgICAv KiBGaXJtd2FyZSBzdGF0dXMgZmxhZywgMHgwMCA9IGluaXRpYWxpc2luZywgMHgwMSA9IE9LLCAw eEZGID0gZmFpbCAqLwotICAgICAgICBpZiAoKCBpID0gRlNUX1JEQiAoIGNhcmQsIHRhc2tTdGF0 dXMgKSkgPT0gMHgwMSApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9 IEZTVF9SVU5OSU5HOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UgaWYgKCBpID09IDB4RkYgKQot ICAgICAgICB7Ci0gICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIkZpcm13YXJlIGluaXRpYWxp c2F0aW9uIGZhaWxlZC4gQ2FyZCBoYWx0ZWRcbiIpOwotICAgICAgICAgICAgICAgIGNhcmQtPnN0 YXRlID0gRlNUX0hBTFRFRDsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0gICAgICAgIH0KLSAg ICAgICAgZWxzZSBpZiAoIGkgIT0gMHgwMCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBw cmludGtfZXJyICgiVW5rbm93biBmaXJtd2FyZSBzdGF0dXMgMHgleFxuIiwgaSApOwotICAgICAg ICAgICAgICAgIGNhcmQtPnN0YXRlID0gRlNUX0hBTFRFRDsKLSAgICAgICAgICAgICAgICByZXR1 cm47Ci0gICAgICAgIH0KLQotICAgICAgICAvKiBGaW5hbGx5IGNoZWNrIHRoZSBudW1iZXIgb2Yg cG9ydHMgcmVwb3J0ZWQgYnkgZmlybXdhcmUgYWdhaW5zdCB0aGUKLSAgICAgICAgICogbnVtYmVy IHdlIGFzc3VtZWQgYXQgY2FyZCBkZXRlY3Rpb24uIFNob3VsZCBuZXZlciBoYXBwZW4gd2l0aAot ICAgICAgICAgKiBleGlzdGluZyBmaXJtd2FyZSBldGMgc28gd2UganVzdCByZXBvcnQgaXQgZm9y IHRoZSBtb21lbnQuCi0gICAgICAgICAqLwotICAgICAgICBpZiAoIEZTVF9SREwgKCBjYXJkLCBu dW1iZXJPZlBvcnRzICkgIT0gY2FyZC0+bnBvcnRzICkKLSAgICAgICAgewotICAgICAgICAgICAg ICAgIHByaW50a193YXJuICgiUG9ydCBjb3VudCBtaXNtYXRjaC4iCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICIgRmlybXdhcmUgdGhpbmtzICVkIHdlIHNheSAlZFxuIiwKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRlNUX1JETCAoIGNhcmQsIG51bWJlck9mUG9ydHMg KSwgY2FyZC0+bnBvcnRzICk7Ci0gICAgICAgIH0KLX0KKwkvKiBDaGVjayBzdHJ1Y3R1cmUgdmVy c2lvbiBhbmQgZW5kIG1hcmtlciAqLworCWlmIChGU1RfUkRXKGNhcmQsIHNtY1ZlcnNpb24pICE9 IFNNQ19WRVJTSU9OKSB7CisJCXByaW50a19lcnIoIkJhZCBzaGFyZWQgbWVtb3J5IHZlcnNpb24g JWQgZXhwZWN0ZWQgJWRcbiIsCisJCQkgICBGU1RfUkRXKGNhcmQsIHNtY1ZlcnNpb24pLCBTTUNf VkVSU0lPTik7CisJCWNhcmQtPnN0YXRlID0gRlNUX0JBRFZFUlNJT047CisJCXJldHVybjsKKwl9 CisJaWYgKEZTVF9SREwoY2FyZCwgZW5kT2ZTbWNTaWduYXR1cmUpICE9IEVORF9TSUcpIHsKKwkJ cHJpbnRrX2VycigiTWlzc2luZyBzaGFyZWQgbWVtb3J5IHNpZ25hdHVyZVxuIik7CisJCWNhcmQt PnN0YXRlID0gRlNUX0JBRFZFUlNJT047CisJCXJldHVybjsKKwl9CisJLyogRmlybXdhcmUgc3Rh dHVzIGZsYWcsIDB4MDAgPSBpbml0aWFsaXNpbmcsIDB4MDEgPSBPSywgMHhGRiA9IGZhaWwgKi8K KwlpZiAoKGkgPSBGU1RfUkRCKGNhcmQsIHRhc2tTdGF0dXMpKSA9PSAweDAxKSB7CisJCWNhcmQt PnN0YXRlID0gRlNUX1JVTk5JTkc7CisJfSBlbHNlIGlmIChpID09IDB4RkYpIHsKKwkJcHJpbnRr X2VycigiRmlybXdhcmUgaW5pdGlhbGlzYXRpb24gZmFpbGVkLiBDYXJkIGhhbHRlZFxuIik7CisJ CWNhcmQtPnN0YXRlID0gRlNUX0hBTFRFRDsKKwkJcmV0dXJuOworCX0gZWxzZSBpZiAoaSAhPSAw eDAwKSB7CisJCXByaW50a19lcnIoIlVua25vd24gZmlybXdhcmUgc3RhdHVzIDB4JXhcbiIsIGkp OworCQljYXJkLT5zdGF0ZSA9IEZTVF9IQUxURUQ7CisJCXJldHVybjsKKwl9CiAKKwkvKiBGaW5h bGx5IGNoZWNrIHRoZSBudW1iZXIgb2YgcG9ydHMgcmVwb3J0ZWQgYnkgZmlybXdhcmUgYWdhaW5z dCB0aGUKKwkgKiBudW1iZXIgd2UgYXNzdW1lZCBhdCBjYXJkIGRldGVjdGlvbi4gU2hvdWxkIG5l dmVyIGhhcHBlbiB3aXRoCisJICogZXhpc3RpbmcgZmlybXdhcmUgZXRjIHNvIHdlIGp1c3QgcmVw b3J0IGl0IGZvciB0aGUgbW9tZW50LgorCSAqLworCWlmIChGU1RfUkRMKGNhcmQsIG51bWJlck9m UG9ydHMpICE9IGNhcmQtPm5wb3J0cykgeworCQlwcmludGtfd2FybigiUG9ydCBjb3VudCBtaXNt YXRjaCBvbiBjYXJkICVkLiIKKwkJCSAgICAiIEZpcm13YXJlIHRoaW5rcyAlZCB3ZSBzYXkgJWRc biIsIGNhcmQtPmNhcmRfbm8sCisJCQkgICAgRlNUX1JETChjYXJkLCBudW1iZXJPZlBvcnRzKSwg Y2FyZC0+bnBvcnRzKTsKKwl9Cit9CiAKIHN0YXRpYyBpbnQKLXNldF9jb25mX2Zyb21faW5mbyAo IHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCwK LSAgICAgICAgICAgICAgICBzdHJ1Y3QgZnN0aW9jX2luZm8gKmluZm8gKQorc2V0X2NvbmZfZnJv bV9pbmZvKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAq cG9ydCwKKwkJICAgc3RydWN0IGZzdGlvY19pbmZvICppbmZvKQogewotICAgICAgICBpbnQgZXJy OworCWludCBlcnI7CisJdW5zaWduZWQgY2hhciBteV9mcmFtaW5nOwogCi0gICAgICAgIC8qIFNl dCB0aGluZ3MgYWNjb3JkaW5nIHRvIHRoZSB1c2VyIHNldCB2YWxpZCBmbGFncy4KLSAgICAgICAg ICogU2V2ZXJhbCBvZiB0aGUgb2xkIG9wdGlvbnMgaGF2ZSBiZWVuIGludmFsaWRhdGVkL3JlcGxh Y2VkIGJ5IHRoZQotICAgICAgICAgKiBnZW5lcmljIEhETEMgcGFja2FnZS4KLSAgICAgICAgICov Ci0gICAgICAgIGVyciA9IDA7Ci0gICAgICAgIGlmICggaW5mby0+dmFsaWQgJiBGU1RWQUxfUFJP VE8gKQotICAgICAgICAgICAgICAgIGVyciA9IC1FSU5WQUw7Ci0gICAgICAgIGlmICggaW5mby0+ dmFsaWQgJiBGU1RWQUxfQ0FCTEUgKQotICAgICAgICAgICAgICAgIGVyciA9IC1FSU5WQUw7Ci0g ICAgICAgIGlmICggaW5mby0+dmFsaWQgJiBGU1RWQUxfU1BFRUQgKQotICAgICAgICAgICAgICAg IGVyciA9IC1FSU5WQUw7CisJLyogU2V0IHRoaW5ncyBhY2NvcmRpbmcgdG8gdGhlIHVzZXIgc2V0 IHZhbGlkIGZsYWdzIAorCSAqIFNldmVyYWwgb2YgdGhlIG9sZCBvcHRpb25zIGhhdmUgYmVlbiBp bnZhbGlkYXRlZC9yZXBsYWNlZCBieSB0aGUgCisJICogZ2VuZXJpYyBoZGxjIHBhY2thZ2UuCisJ ICovCisJZXJyID0gMDsKKwlpZiAoaW5mby0+dmFsaWQgJiBGU1RWQUxfUFJPVE8pIHsKKwkJaWYg KGluZm8tPnByb3RvID09IEZTVF9SQVcpCisJCQlwb3J0LT5tb2RlID0gRlNUX1JBVzsKKwkJZWxz ZQorCQkJcG9ydC0+bW9kZSA9IEZTVF9HRU5fSERMQzsKKwl9CisKKwlpZiAoaW5mby0+dmFsaWQg JiBGU1RWQUxfQ0FCTEUpCisJCWVyciA9IC1FSU5WQUw7CisKKwlpZiAoaW5mby0+dmFsaWQgJiBG U1RWQUxfU1BFRUQpCisJCWVyciA9IC1FSU5WQUw7CiAKLSAgICAgICAgaWYgKCBpbmZvLT52YWxp ZCAmIEZTVFZBTF9NT0RFICkKLSAgICAgICAgICAgICAgICBGU1RfV1JXICggY2FyZCwgY2FyZE1v ZGUsIGluZm8tPmNhcmRNb2RlICk7CisJaWYgKGluZm8tPnZhbGlkICYgRlNUVkFMX1BIQVNFKQor CQlGU1RfV1JCKGNhcmQsIHBvcnRDb25maWdbcG9ydC0+aW5kZXhdLmludmVydENsb2NrLAorCQkJ aW5mby0+aW52ZXJ0Q2xvY2spOworCWlmIChpbmZvLT52YWxpZCAmIEZTVFZBTF9NT0RFKQorCQlG U1RfV1JXKGNhcmQsIGNhcmRNb2RlLCBpbmZvLT5jYXJkTW9kZSk7CisJaWYgKGluZm8tPnZhbGlk ICYgRlNUVkFMX1RFMSkgeworCQlGU1RfV1JMKGNhcmQsIHN1Q29uZmlnLmRhdGFSYXRlLCBpbmZv LT5saW5lU3BlZWQpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmNsb2NraW5nLCBpbmZvLT5j bG9ja1NvdXJjZSk7CisJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0UxOworCQlpZiAoaW5mby0+ZnJh bWluZyA9PSBFMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0UxOworCQlpZiAoaW5mby0+ZnJh bWluZyA9PSBUMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX1QxOworCQlpZiAoaW5mby0+ZnJh bWluZyA9PSBKMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0oxOworCQlGU1RfV1JCKGNhcmQs IHN1Q29uZmlnLmZyYW1pbmcsIG15X2ZyYW1pbmcpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmln LnN0cnVjdHVyZSwgaW5mby0+c3RydWN0dXJlKTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5p bnRlcmZhY2UsIGluZm8tPmludGVyZmFjZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcuY29k aW5nLCBpbmZvLT5jb2RpbmcpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmxpbmVCdWlsZE91 dCwgaW5mby0+bGluZUJ1aWxkT3V0KTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5lcXVhbGl6 ZXIsIGluZm8tPmVxdWFsaXplcik7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcudHJhbnNwYXJl bnRNb2RlLCBpbmZvLT50cmFuc3BhcmVudE1vZGUpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmln Lmxvb3BNb2RlLCBpbmZvLT5sb29wTW9kZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcucmFu Z2UsIGluZm8tPnJhbmdlKTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy50eEJ1ZmZlck1vZGUs IGluZm8tPnR4QnVmZmVyTW9kZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcucnhCdWZmZXJN b2RlLCBpbmZvLT5yeEJ1ZmZlck1vZGUpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLnN0YXJ0 aW5nU2xvdCwgaW5mby0+c3RhcnRpbmdTbG90KTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5s b3NUaHJlc2hvbGQsIGluZm8tPmxvc1RocmVzaG9sZCk7CisJCWlmIChpbmZvLT5pZGxlQ29kZSkK KwkJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcuZW5hYmxlSWRsZUNvZGUsIDEpOworCQllbHNlCisJ CQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmVuYWJsZUlkbGVDb2RlLCAwKTsKKwkJRlNUX1dSQihj YXJkLCBzdUNvbmZpZy5pZGxlQ29kZSwgaW5mby0+aWRsZUNvZGUpOworI2lmIEZTVF9ERUJVRwor CQlpZiAoaW5mby0+dmFsaWQgJiBGU1RWQUxfVEUxKSB7CisJCQlwcmludGsoIlNldHRpbmcgVEUx IGRhdGFcbiIpOworCQkJcHJpbnRrKCJMaW5lIFNwZWVkID0gJWRcbiIsIGluZm8tPmxpbmVTcGVl ZCk7CisJCQlwcmludGsoIlN0YXJ0IHNsb3QgPSAlZFxuIiwgaW5mby0+c3RhcnRpbmdTbG90KTsK KwkJCXByaW50aygiQ2xvY2sgc291cmNlID0gJWRcbiIsIGluZm8tPmNsb2NrU291cmNlKTsKKwkJ CXByaW50aygiRnJhbWluZyA9ICVkXG4iLCBteV9mcmFtaW5nKTsKKwkJCXByaW50aygiU3RydWN0 dXJlID0gJWRcbiIsIGluZm8tPnN0cnVjdHVyZSk7CisJCQlwcmludGsoImludGVyZmFjZSA9ICVk XG4iLCBpbmZvLT5pbnRlcmZhY2UpOworCQkJcHJpbnRrKCJDb2RpbmcgPSAlZFxuIiwgaW5mby0+ Y29kaW5nKTsKKwkJCXByaW50aygiTGluZSBidWlsZCBvdXQgPSAlZFxuIiwgaW5mby0+bGluZUJ1 aWxkT3V0KTsKKwkJCXByaW50aygiRXF1YWxpc2VyID0gJWRcbiIsIGluZm8tPmVxdWFsaXplcik7 CisJCQlwcmludGsoIlRyYW5zcGFyZW50IG1vZGUgPSAlZFxuIiwKKwkJCSAgICAgICBpbmZvLT50 cmFuc3BhcmVudE1vZGUpOworCQkJcHJpbnRrKCJMb29wIG1vZGUgPSAlZFxuIiwgaW5mby0+bG9v cE1vZGUpOworCQkJcHJpbnRrKCJSYW5nZSA9ICVkXG4iLCBpbmZvLT5yYW5nZSk7CisJCQlwcmlu dGsoIlR4IEJ1ZmZlciBtb2RlID0gJWRcbiIsIGluZm8tPnR4QnVmZmVyTW9kZSk7CisJCQlwcmlu dGsoIlJ4IEJ1ZmZlciBtb2RlID0gJWRcbiIsIGluZm8tPnJ4QnVmZmVyTW9kZSk7CisJCQlwcmlu dGsoIkxPUyBUaHJlc2hvbGQgPSAlZFxuIiwgaW5mby0+bG9zVGhyZXNob2xkKTsKKwkJCXByaW50 aygiSWRsZSBDb2RlID0gJWRcbiIsIGluZm8tPmlkbGVDb2RlKTsKKwkJfQorI2VuZGlmCisJfQog I2lmIEZTVF9ERUJVRwotICAgICAgICBpZiAoIGluZm8tPnZhbGlkICYgRlNUVkFMX0RFQlVHICkK LSAgICAgICAgICAgICAgICBmc3RfZGVidWdfbWFzayA9IGluZm8tPmRlYnVnOworCWlmIChpbmZv LT52YWxpZCAmIEZTVFZBTF9ERUJVRykgeworCQlmc3RfZGVidWdfbWFzayA9IGluZm8tPmRlYnVn OworCX0KICNlbmRpZgogCi0gICAgICAgIHJldHVybiBlcnI7CisJcmV0dXJuIGVycjsKIH0KIAog c3RhdGljIHZvaWQKLWdhdGhlcl9jb25mX2luZm8gKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2Fy ZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsCi0gICAgICAgICAgICAgICAgc3RydWN0IGZz dGlvY19pbmZvICppbmZvICkKK2dhdGhlcl9jb25mX2luZm8oc3RydWN0IGZzdF9jYXJkX2luZm8g KmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCQkgc3RydWN0IGZzdGlvY19pbmZv ICppbmZvKQogewotICAgICAgICBpbnQgaTsKKwlpbnQgaTsKIAotICAgICAgICBtZW1zZXQgKCBp bmZvLCAwLCBzaXplb2YgKCBzdHJ1Y3QgZnN0aW9jX2luZm8gKSk7CisJbWVtc2V0KGluZm8sIDAs IHNpemVvZiAoc3RydWN0IGZzdGlvY19pbmZvKSk7CiAKLSAgICAgICAgaSA9IHBvcnQtPmluZGV4 OwotICAgICAgICBpbmZvLT5ucG9ydHMgPSBjYXJkLT5ucG9ydHM7Ci0gICAgICAgIGluZm8tPnR5 cGUgICA9IGNhcmQtPnR5cGU7Ci0gICAgICAgIGluZm8tPnN0YXRlICA9IGNhcmQtPnN0YXRlOwot ICAgICAgICBpbmZvLT5wcm90byAgPSBGU1RfR0VOX0hETEM7Ci0gICAgICAgIGluZm8tPmluZGV4 ICA9IGk7CisJaSA9IHBvcnQtPmluZGV4OworCWluZm8tPmtlcm5lbFZlcnNpb24gPSBMSU5VWF9W RVJTSU9OX0NPREU7CisJaW5mby0+bnBvcnRzID0gY2FyZC0+bnBvcnRzOworCWluZm8tPnR5cGUg PSBjYXJkLT50eXBlOworCWluZm8tPnN0YXRlID0gY2FyZC0+c3RhdGU7CisJaW5mby0+cHJvdG8g PSBGU1RfR0VOX0hETEM7CisJaW5mby0+aW5kZXggPSBpOwogI2lmIEZTVF9ERUJVRwotICAgICAg ICBpbmZvLT5kZWJ1ZyAgPSBmc3RfZGVidWdfbWFzazsKKwlpbmZvLT5kZWJ1ZyA9IGZzdF9kZWJ1 Z19tYXNrOwogI2VuZGlmCiAKLSAgICAgICAgLyogT25seSBtYXJrIGluZm9ybWF0aW9uIGFzIHZh bGlkIGlmIGNhcmQgaXMgcnVubmluZy4KLSAgICAgICAgICogQ29weSB0aGUgZGF0YSBhbnl3YXkg aW4gY2FzZSBpdCBpcyB1c2VmdWwgZm9yIGRpYWdub3N0aWNzCi0gICAgICAgICAqLwotICAgICAg ICBpbmZvLT52YWxpZAotICAgICAgICAgICAgICAgID0gKCggY2FyZC0+c3RhdGUgPT0gRlNUX1JV Tk5JTkcgKSA/IEZTVFZBTF9BTEwgOiBGU1RWQUxfQ0FSRCApCisJLyogT25seSBtYXJrIGluZm9y bWF0aW9uIGFzIHZhbGlkIGlmIGNhcmQgaXMgcnVubmluZy4KKwkgKiBDb3B5IHRoZSBkYXRhIGFu eXdheSBpbiBjYXNlIGl0IGlzIHVzZWZ1bCBmb3IgZGlhZ25vc3RpY3MKKwkgKi8KKwlpbmZvLT52 YWxpZCA9ICgoY2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5JTkcpID8gRlNUVkFMX0FMTCA6IEZTVFZB TF9DQVJEKQogI2lmIEZTVF9ERUJVRwotICAgICAgICAgICAgICAgIHwgRlNUVkFMX0RFQlVHCisJ ICAgIHwgRlNUVkFMX0RFQlVHCiAjZW5kaWYKLSAgICAgICAgICAgICAgICA7CisJICAgIDsKIAot ICAgICAgICBpbmZvLT5saW5lSW50ZXJmYWNlID0gRlNUX1JEVyAoIGNhcmQsIHBvcnRDb25maWdb aV0ubGluZUludGVyZmFjZSApOwotICAgICAgICBpbmZvLT5pbnRlcm5hbENsb2NrID0gRlNUX1JE QiAoIGNhcmQsIHBvcnRDb25maWdbaV0uaW50ZXJuYWxDbG9jayApOwotICAgICAgICBpbmZvLT5s aW5lU3BlZWQgICAgID0gRlNUX1JETCAoIGNhcmQsIHBvcnRDb25maWdbaV0ubGluZVNwZWVkICk7 Ci0gICAgICAgIGluZm8tPnYyNElwU3RzICAgICAgPSBGU1RfUkRMICggY2FyZCwgdjI0SXBTdHNb aV0gKTsKLSAgICAgICAgaW5mby0+djI0T3BTdHMgICAgICA9IEZTVF9SREwgKCBjYXJkLCB2MjRP cFN0c1tpXSApOwotICAgICAgICBpbmZvLT5jbG9ja1N0YXR1cyAgID0gRlNUX1JEVyAoIGNhcmQs IGNsb2NrU3RhdHVzW2ldICk7Ci0gICAgICAgIGluZm8tPmNhYmxlU3RhdHVzICAgPSBGU1RfUkRX ICggY2FyZCwgY2FibGVTdGF0dXMgKTsKLSAgICAgICAgaW5mby0+Y2FyZE1vZGUgICAgICA9IEZT VF9SRFcgKCBjYXJkLCBjYXJkTW9kZSApOwotICAgICAgICBpbmZvLT5zbWNGaXJtd2FyZVZlcnNp b24gID0gRlNUX1JETCAoIGNhcmQsIHNtY0Zpcm13YXJlVmVyc2lvbiApOworCWluZm8tPmxpbmVJ bnRlcmZhY2UgPSBGU1RfUkRXKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZUludGVyZmFjZSk7CisJ aW5mby0+aW50ZXJuYWxDbG9jayA9IEZTVF9SREIoY2FyZCwgcG9ydENvbmZpZ1tpXS5pbnRlcm5h bENsb2NrKTsKKwlpbmZvLT5saW5lU3BlZWQgPSBGU1RfUkRMKGNhcmQsIHBvcnRDb25maWdbaV0u bGluZVNwZWVkKTsKKwlpbmZvLT5pbnZlcnRDbG9jayA9IEZTVF9SREIoY2FyZCwgcG9ydENvbmZp Z1tpXS5pbnZlcnRDbG9jayk7CisJaW5mby0+djI0SXBTdHMgPSBGU1RfUkRMKGNhcmQsIHYyNElw U3RzW2ldKTsKKwlpbmZvLT52MjRPcFN0cyA9IEZTVF9SREwoY2FyZCwgdjI0T3BTdHNbaV0pOwor CWluZm8tPmNsb2NrU3RhdHVzID0gRlNUX1JEVyhjYXJkLCBjbG9ja1N0YXR1c1tpXSk7CisJaW5m by0+Y2FibGVTdGF0dXMgPSBGU1RfUkRXKGNhcmQsIGNhYmxlU3RhdHVzKTsKKwlpbmZvLT5jYXJk TW9kZSA9IEZTVF9SRFcoY2FyZCwgY2FyZE1vZGUpOworCWluZm8tPnNtY0Zpcm13YXJlVmVyc2lv biA9IEZTVF9SREwoY2FyZCwgc21jRmlybXdhcmVWZXJzaW9uKTsKKworCS8qCisJICogVGhlIFQy VSBjYW4gcmVwb3J0IGNhYmxlIHByZXNlbmNlIGZvciBib3RoIEEgb3IgQgorCSAqIGluIGJpdHMg MCBhbmQgMSBvZiBjYWJsZVN0YXR1cy4gIFNlZSB3aGljaCBwb3J0IHdlIGFyZSBhbmQgCisJICog ZG8gdGhlIG1hcHBpbmcuCisJICovCisJaWYgKGNhcmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RY VSkgeworCQlpZiAocG9ydC0+aW5kZXggPT0gMCkgeworCQkJLyoKKwkJCSAqIFBvcnQgQQorCQkJ ICovCisJCQlpbmZvLT5jYWJsZVN0YXR1cyA9IGluZm8tPmNhYmxlU3RhdHVzICYgMTsKKwkJfSBl bHNlIHsKKwkJCS8qCisJCQkgKiBQb3J0IEIKKwkJCSAqLworCQkJaW5mby0+Y2FibGVTdGF0dXMg PSBpbmZvLT5jYWJsZVN0YXR1cyA+PiAxOworCQkJaW5mby0+Y2FibGVTdGF0dXMgPSBpbmZvLT5j YWJsZVN0YXR1cyAmIDE7CisJCX0KKwl9CisJLyoKKwkgKiBTb21lIGFkZGl0aW9uYWwgYml0cyBp ZiB3ZSBhcmUgVEUxCisJICovCisJaWYgKGNhcmQtPnR5cGUgPT0gRlNUX1RZUEVfVEUxKSB7CisJ CWluZm8tPmxpbmVTcGVlZCA9IEZTVF9SREwoY2FyZCwgc3VDb25maWcuZGF0YVJhdGUpOworCQlp bmZvLT5jbG9ja1NvdXJjZSA9IEZTVF9SREIoY2FyZCwgc3VDb25maWcuY2xvY2tpbmcpOworCQlp bmZvLT5mcmFtaW5nID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5mcmFtaW5nKTsKKwkJaW5mby0+ c3RydWN0dXJlID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5zdHJ1Y3R1cmUpOworCQlpbmZvLT5p bnRlcmZhY2UgPSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLmludGVyZmFjZSk7CisJCWluZm8tPmNv ZGluZyA9IEZTVF9SREIoY2FyZCwgc3VDb25maWcuY29kaW5nKTsKKwkJaW5mby0+bGluZUJ1aWxk T3V0ID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5saW5lQnVpbGRPdXQpOworCQlpbmZvLT5lcXVh bGl6ZXIgPSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLmVxdWFsaXplcik7CisJCWluZm8tPmxvb3BN b2RlID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5sb29wTW9kZSk7CisJCWluZm8tPnJhbmdlID0g RlNUX1JEQihjYXJkLCBzdUNvbmZpZy5yYW5nZSk7CisJCWluZm8tPnR4QnVmZmVyTW9kZSA9IEZT VF9SREIoY2FyZCwgc3VDb25maWcudHhCdWZmZXJNb2RlKTsKKwkJaW5mby0+cnhCdWZmZXJNb2Rl ID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5yeEJ1ZmZlck1vZGUpOworCQlpbmZvLT5zdGFydGlu Z1Nsb3QgPSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLnN0YXJ0aW5nU2xvdCk7CisJCWluZm8tPmxv c1RocmVzaG9sZCA9IEZTVF9SREIoY2FyZCwgc3VDb25maWcubG9zVGhyZXNob2xkKTsKKwkJaWYg KEZTVF9SREIoY2FyZCwgc3VDb25maWcuZW5hYmxlSWRsZUNvZGUpKQorCQkJaW5mby0+aWRsZUNv ZGUgPSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLmlkbGVDb2RlKTsKKwkJZWxzZQorCQkJaW5mby0+ aWRsZUNvZGUgPSAwOworCQlpbmZvLT5yZWNlaXZlQnVmZmVyRGVsYXkgPQorCQkgICAgRlNUX1JE TChjYXJkLCBzdVN0YXR1cy5yZWNlaXZlQnVmZmVyRGVsYXkpOworCQlpbmZvLT5mcmFtaW5nRXJy b3JDb3VudCA9CisJCSAgICBGU1RfUkRMKGNhcmQsIHN1U3RhdHVzLmZyYW1pbmdFcnJvckNvdW50 KTsKKwkJaW5mby0+Y29kZVZpb2xhdGlvbkNvdW50ID0KKwkJICAgIEZTVF9SREwoY2FyZCwgc3VT dGF0dXMuY29kZVZpb2xhdGlvbkNvdW50KTsKKwkJaW5mby0+Y3JjRXJyb3JDb3VudCA9IEZTVF9S REwoY2FyZCwgc3VTdGF0dXMuY3JjRXJyb3JDb3VudCk7CisJCWluZm8tPmxpbmVBdHRlbnVhdGlv biA9IEZTVF9SREwoY2FyZCwgc3VTdGF0dXMubGluZUF0dGVudWF0aW9uKTsKKwkJaW5mby0+bG9z c09mU2lnbmFsID0gRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5sb3NzT2ZTaWduYWwpOworCQlpbmZv LT5yZWNlaXZlUmVtb3RlQWxhcm0gPQorCQkgICAgRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5yZWNl aXZlUmVtb3RlQWxhcm0pOworCQlpbmZvLT5hbGFybUluZGljYXRpb25TaWduYWwgPQorCQkgICAg RlNUX1JEQihjYXJkLCBzdVN0YXR1cy5hbGFybUluZGljYXRpb25TaWduYWwpOworCX0KIH0KIAot CiBzdGF0aWMgaW50Ci1mc3Rfc2V0X2lmYWNlICggc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQs IHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAotICAgICAgICAgICAgICAgIHN0cnVjdCBpZnJl cSAqaWZyICkKK2ZzdF9zZXRfaWZhY2Uoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVj dCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCSAgICAgIHN0cnVjdCBpZnJlcSAqaWZyKQogewotICAg ICAgICBzeW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5jOwotICAgICAgICBpbnQgaTsKKwlzeW5jX3Nl cmlhbF9zZXR0aW5ncyBzeW5jOworCWludCBpOworCisJaWYgKGlmci0+aWZyX3NldHRpbmdzLnNp emUgIT0gc2l6ZW9mIChzeW5jKSkgeworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwlpZiAoY29w eV9mcm9tX3VzZXIKKwkgICAgKCZzeW5jLCBpZnItPmlmcl9zZXR0aW5ncy5pZnNfaWZzdS5zeW5j LCBzaXplb2YgKHN5bmMpKSkgeworCQlyZXR1cm4gLUVGQVVMVDsKKwl9CiAKLSAgICAgICAgaWYg KGNvcHlfZnJvbV91c2VyICgmc3luYywgaWZyLT5pZnJfc2V0dGluZ3MuaWZzX2lmc3Uuc3luYywK LQkJCSAgICBzaXplb2YgKHN5bmMpKSkKLSAgICAgICAgICAgICAgICByZXR1cm4gLUVGQVVMVDsK LQotICAgICAgICBpZiAoIHN5bmMubG9vcGJhY2sgKQotICAgICAgICAgICAgICAgIHJldHVybiAt RUlOVkFMOwotCi0gICAgICAgIGkgPSBwb3J0LT5pbmRleDsKLQotICAgICAgICBzd2l0Y2ggKGlm ci0+aWZyX3NldHRpbmdzLnR5cGUpCi0gICAgICAgIHsKLSAgICAgICAgY2FzZSBJRl9JRkFDRV9W MzU6Ci0gICAgICAgICAgICAgICAgRlNUX1dSVyAoIGNhcmQsIHBvcnRDb25maWdbaV0ubGluZUlu dGVyZmFjZSwgVjM1ICk7Ci0gICAgICAgICAgICAgICAgcG9ydC0+aHdpZiA9IFYzNTsKLSAgICAg ICAgICAgICAgICBicmVhazsKLQotICAgICAgICBjYXNlIElGX0lGQUNFX1YyNDoKLSAgICAgICAg ICAgICAgICBGU1RfV1JXICggY2FyZCwgcG9ydENvbmZpZ1tpXS5saW5lSW50ZXJmYWNlLCBWMjQg KTsKLSAgICAgICAgICAgICAgICBwb3J0LT5od2lmID0gVjI0OwotICAgICAgICAgICAgICAgIGJy ZWFrOwotCi0gICAgICAgIGNhc2UgSUZfSUZBQ0VfWDIxOgotICAgICAgICAgICAgICAgIEZTVF9X UlcgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZhY2UsIFgyMSApOwotICAgICAgICAg ICAgICAgIHBvcnQtPmh3aWYgPSBYMjE7Ci0gICAgICAgICAgICAgICAgYnJlYWs7Ci0KLSAgICAg ICAgY2FzZSBJRl9JRkFDRV9TWU5DX1NFUklBTDoKLSAgICAgICAgICAgICAgICBicmVhazsKLQot ICAgICAgICBkZWZhdWx0OgotICAgICAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOwotICAgICAg ICB9Ci0KLSAgICAgICAgc3dpdGNoICggc3luYy5jbG9ja190eXBlICkKLSAgICAgICAgewotICAg ICAgICBjYXNlIENMT0NLX0VYVDoKLSAgICAgICAgICAgICAgICBGU1RfV1JCICggY2FyZCwgcG9y dENvbmZpZ1tpXS5pbnRlcm5hbENsb2NrLCBFWFRDTEsgKTsKLSAgICAgICAgICAgICAgICBicmVh azsKLQotICAgICAgICBjYXNlIENMT0NLX0lOVDoKLSAgICAgICAgICAgICAgICBGU1RfV1JCICgg Y2FyZCwgcG9ydENvbmZpZ1tpXS5pbnRlcm5hbENsb2NrLCBJTlRDTEsgKTsKLSAgICAgICAgICAg ICAgICBicmVhazsKLQotICAgICAgICBkZWZhdWx0OgotICAgICAgICAgICAgICAgIHJldHVybiAt RUlOVkFMOwotICAgICAgICB9Ci0gICAgICAgIEZTVF9XUkwgKCBjYXJkLCBwb3J0Q29uZmlnW2ld LmxpbmVTcGVlZCwgc3luYy5jbG9ja19yYXRlICk7Ci0gICAgICAgIHJldHVybiAwOworCWlmIChz eW5jLmxvb3BiYWNrKQorCQlyZXR1cm4gLUVJTlZBTDsKKworCWkgPSBwb3J0LT5pbmRleDsKKwor CXN3aXRjaCAoaWZyLT5pZnJfc2V0dGluZ3MudHlwZSkgeworCWNhc2UgSUZfSUZBQ0VfVjM1Ogor CQlGU1RfV1JXKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZUludGVyZmFjZSwgVjM1KTsKKwkJcG9y dC0+aHdpZiA9IFYzNTsKKwkJYnJlYWs7CisKKwljYXNlIElGX0lGQUNFX1YyNDoKKwkJRlNUX1dS VyhjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZhY2UsIFYyNCk7CisJCXBvcnQtPmh3aWYg PSBWMjQ7CisJCWJyZWFrOworCisJY2FzZSBJRl9JRkFDRV9YMjE6CisJCUZTVF9XUlcoY2FyZCwg cG9ydENvbmZpZ1tpXS5saW5lSW50ZXJmYWNlLCBYMjEpOworCQlwb3J0LT5od2lmID0gWDIxOwor CQlicmVhazsKKworCWNhc2UgSUZfSUZBQ0VfWDIxRDoKKwkJRlNUX1dSVyhjYXJkLCBwb3J0Q29u ZmlnW2ldLmxpbmVJbnRlcmZhY2UsIFgyMUQpOworCQlwb3J0LT5od2lmID0gWDIxRDsKKwkJYnJl YWs7CisKKwljYXNlIElGX0lGQUNFX1QxOgorCQlGU1RfV1JXKGNhcmQsIHBvcnRDb25maWdbaV0u bGluZUludGVyZmFjZSwgVDEpOworCQlwb3J0LT5od2lmID0gVDE7CisJCWJyZWFrOworCisJY2Fz ZSBJRl9JRkFDRV9FMToKKwkJRlNUX1dSVyhjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZh Y2UsIEUxKTsKKwkJcG9ydC0+aHdpZiA9IEUxOworCQlicmVhazsKKworCWNhc2UgSUZfSUZBQ0Vf U1lOQ19TRVJJQUw6CisJCWJyZWFrOworCisJZGVmYXVsdDoKKwkJcmV0dXJuIC1FSU5WQUw7CisJ fQorCisJc3dpdGNoIChzeW5jLmNsb2NrX3R5cGUpIHsKKwljYXNlIENMT0NLX0VYVDoKKwkJRlNU X1dSQihjYXJkLCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xvY2ssIEVYVENMSyk7CisJCWJyZWFr OworCisJY2FzZSBDTE9DS19JTlQ6CisJCUZTVF9XUkIoY2FyZCwgcG9ydENvbmZpZ1tpXS5pbnRl cm5hbENsb2NrLCBJTlRDTEspOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCXJldHVybiAtRUlO VkFMOworCX0KKwlGU1RfV1JMKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZVNwZWVkLCBzeW5jLmNs b2NrX3JhdGUpOworCXJldHVybiAwOwogfQogCiBzdGF0aWMgaW50Ci1mc3RfZ2V0X2lmYWNlICgg c3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAot ICAgICAgICAgICAgICAgIHN0cnVjdCBpZnJlcSAqaWZyICkKK2ZzdF9nZXRfaWZhY2Uoc3RydWN0 IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCSAgICAg IHN0cnVjdCBpZnJlcSAqaWZyKQogewotICAgICAgICBzeW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5j OwotICAgICAgICBpbnQgaTsKKwlzeW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5jOworCWludCBpOwor CisJLyogRmlyc3QgY2hlY2sgd2hhdCBsaW5lIHR5cGUgaXMgc2V0LCB3ZSdsbCBkZWZhdWx0IHRv IHJlcG9ydGluZyBYLjIxCisJICogaWYgbm90aGluZyBpcyBzZXQgYXMgSUZfSUZBQ0VfU1lOQ19T RVJJQUwgaW1wbGllcyBpdCBjYW4ndCBiZQorCSAqIGNoYW5nZWQKKwkgKi8KKwlzd2l0Y2ggKHBv cnQtPmh3aWYpIHsKKwljYXNlIEUxOgorCQlpZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZfSUZB Q0VfRTE7CisJCWJyZWFrOworCWNhc2UgVDE6CisJCWlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJ Rl9JRkFDRV9UMTsKKwkJYnJlYWs7CisJY2FzZSBWMzU6CisJCWlmci0+aWZyX3NldHRpbmdzLnR5 cGUgPSBJRl9JRkFDRV9WMzU7CisJCWJyZWFrOworCWNhc2UgVjI0OgorCQlpZnItPmlmcl9zZXR0 aW5ncy50eXBlID0gSUZfSUZBQ0VfVjI0OworCQlicmVhazsKKwljYXNlIFgyMUQ6CisJCWlmci0+ aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9YMjFEOworCQlicmVhazsKKwljYXNlIFgyMToK KwlkZWZhdWx0OgorCQlpZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZfSUZBQ0VfWDIxOworCQli cmVhazsKKwl9CisJaWYgKGlmci0+aWZyX3NldHRpbmdzLnNpemUgPT0gMCkgeworCQlyZXR1cm4g MDsJLyogb25seSB0eXBlIHJlcXVlc3RlZCAqLworCX0KKwlpZiAoaWZyLT5pZnJfc2V0dGluZ3Mu c2l6ZSA8IHNpemVvZiAoc3luYykpIHsKKwkJcmV0dXJuIC1FTk9NRU07CisJfQogCi0gICAgICAg IC8qIEZpcnN0IGNoZWNrIHdoYXQgbGluZSB0eXBlIGlzIHNldCwgd2UnbGwgZGVmYXVsdCB0byBy ZXBvcnRpbmcgWC4yMQotICAgICAgICAgKiBpZiBub3RoaW5nIGlzIHNldCBhcyBJRl9JRkFDRV9T WU5DX1NFUklBTCBpbXBsaWVzIGl0IGNhbid0IGJlCi0gICAgICAgICAqIGNoYW5nZWQKLSAgICAg ICAgICovCi0gICAgICAgIHN3aXRjaCAoIHBvcnQtPmh3aWYgKQotICAgICAgICB7Ci0gICAgICAg IGNhc2UgVjM1OgotICAgICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9J RkFDRV9WMzU7Ci0gICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgVjI0OgotICAg ICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9WMjQ7Ci0gICAg ICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgWDIxOgotICAgICAgICBkZWZhdWx0Ogot ICAgICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9YMjE7Ci0g ICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIH0KLQotCWlmIChpZnItPmlmcl9zZXR0aW5n cy5zaXplIDwgc2l6ZW9mKHN5bmMpKSB7Ci0JCWlmci0+aWZyX3NldHRpbmdzLnNpemUgPSBzaXpl b2Yoc3luYyk7IC8qIGRhdGEgc2l6ZSB3YW50ZWQgKi8KLQkJcmV0dXJuIC1FTk9CVUZTOwotCX0K LQotICAgICAgICBpID0gcG9ydC0+aW5kZXg7Ci0gICAgICAgIHN5bmMuY2xvY2tfcmF0ZSA9IEZT VF9SREwgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVTcGVlZCApOwotICAgICAgICAvKiBMdWNr eSBjYXJkIGFuZCBsaW51eCB1c2Ugc2FtZSBlbmNvZGluZyBoZXJlICovCi0gICAgICAgIHN5bmMu Y2xvY2tfdHlwZSA9IEZTVF9SREIgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xvY2sg KTsKLSAgICAgICAgc3luYy5sb29wYmFjayA9IDA7Ci0KLSAgICAgICAgaWYgKGNvcHlfdG9fdXNl ciAoaWZyLT5pZnJfc2V0dGluZ3MuaWZzX2lmc3Uuc3luYywgJnN5bmMsCi0JCQkgIHNpemVvZihz eW5jKSkpCi0gICAgICAgICAgICAgICAgcmV0dXJuIC1FRkFVTFQ7CisJaSA9IHBvcnQtPmluZGV4 OworCXN5bmMuY2xvY2tfcmF0ZSA9IEZTVF9SREwoY2FyZCwgcG9ydENvbmZpZ1tpXS5saW5lU3Bl ZWQpOworCS8qIEx1Y2t5IGNhcmQgYW5kIGxpbnV4IHVzZSBzYW1lIGVuY29kaW5nIGhlcmUgKi8K KwlzeW5jLmNsb2NrX3R5cGUgPSBGU1RfUkRCKGNhcmQsIHBvcnRDb25maWdbaV0uaW50ZXJuYWxD bG9jaykgPT0KKwkgICAgSU5UQ0xLID8gQ0xPQ0tfSU5UIDogQ0xPQ0tfRVhUOworCXN5bmMubG9v cGJhY2sgPSAwOwogCi0gICAgICAgIHJldHVybiAwOwotfQorCWlmIChjb3B5X3RvX3VzZXIoaWZy LT5pZnJfc2V0dGluZ3MuaWZzX2lmc3Uuc3luYywgJnN5bmMsIHNpemVvZiAoc3luYykpKSB7CisJ CXJldHVybiAtRUZBVUxUOworCX0KIAorCWlmci0+aWZyX3NldHRpbmdzLnNpemUgPSBzaXplb2Yg KHN5bmMpOworCXJldHVybiAwOworfQogCiBzdGF0aWMgaW50Ci1mc3RfaW9jdGwgKCBzdHJ1Y3Qg bmV0X2RldmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKmlmciwgaW50IGNtZCApCitmc3RfaW9jdGwo c3RydWN0IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICppZnIsIGludCBjbWQpCiB7Ci0g ICAgICAgIHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICBzdHJ1Y3QgZnN0X3Bv cnRfaW5mbyAqcG9ydDsKLSAgICAgICAgc3RydWN0IGZzdGlvY193cml0ZSB3cnRoZHI7Ci0gICAg ICAgIHN0cnVjdCBmc3Rpb2NfaW5mbyBpbmZvOwotICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdz OwotCi0gICAgICAgIGRiZyAoIERCR19JT0NUTCwiaW9jdGw6ICV4LCAlcFxuIiwgY21kLCBpZnIt Pmlmcl9kYXRhICk7Ci0KLSAgICAgICAgcG9ydCA9IGRldl90b19wb3J0ICggZGV2ICk7Ci0gICAg ICAgIGNhcmQgPSBwb3J0LT5jYXJkOwotCi0gICAgICAgIGlmICggIWNhcGFibGUgKCBDQVBfTkVU X0FETUlOICkpCi0gICAgICAgICAgICAgICAgcmV0dXJuIC1FUEVSTTsKLQotICAgICAgICBzd2l0 Y2ggKCBjbWQgKQotICAgICAgICB7Ci0gICAgICAgIGNhc2UgRlNUQ1BVUkVTRVQ6Ci0gICAgICAg ICAgICAgICAgZnN0X2NwdXJlc2V0ICggY2FyZCApOwotICAgICAgICAgICAgICAgIGNhcmQtPnN0 YXRlID0gRlNUX1JFU0VUOwotICAgICAgICAgICAgICAgIHJldHVybiAwOwotCi0gICAgICAgIGNh c2UgRlNUQ1BVUkVMRUFTRToKLSAgICAgICAgICAgICAgICBmc3RfY3B1cmVsZWFzZSAoIGNhcmQg KTsKLSAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9TVEFSVElORzsKLSAgICAgICAg ICAgICAgICByZXR1cm4gMDsKLQotICAgICAgICBjYXNlIEZTVFdSSVRFOiAgICAgICAgICAgICAg ICAgIC8qIENvZGUgd3JpdGUgKGRvd25sb2FkKSAqLwotCi0gICAgICAgICAgICAgICAgLyogRmly c3QgY29weSBpbiB0aGUgaGVhZGVyIHdpdGggdGhlIGxlbmd0aCBhbmQgb2Zmc2V0IG9mIGRhdGEK LSAgICAgICAgICAgICAgICAgKiB0byB3cml0ZQotICAgICAgICAgICAgICAgICAqLwotICAgICAg ICAgICAgICAgIGlmICggaWZyLT5pZnJfZGF0YSA9PSBOVUxMICkKLSAgICAgICAgICAgICAgICB7 Ci0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsKLSAgICAgICAgICAgICAg ICB9Ci0gICAgICAgICAgICAgICAgaWYgKCBjb3B5X2Zyb21fdXNlciAoICZ3cnRoZHIsIGlmci0+ aWZyX2RhdGEsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9m ICggc3RydWN0IGZzdGlvY193cml0ZSApKSkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAg ICAgICAgICAgICAgICByZXR1cm4gLUVGQVVMVDsKLSAgICAgICAgICAgICAgICB9CisJc3RydWN0 IGZzdF9jYXJkX2luZm8gKmNhcmQ7CisJc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7CisJc3Ry dWN0IGZzdGlvY193cml0ZSB3cnRoZHI7CisJc3RydWN0IGZzdGlvY19pbmZvIGluZm87CisJdW5z aWduZWQgbG9uZyBmbGFnczsKIAotICAgICAgICAgICAgICAgIC8qIFNhbml0eSBjaGVjayB0aGUg cGFyYW1ldGVycy4gV2UgZG9uJ3Qgc3VwcG9ydCBwYXJ0aWFsIHdyaXRlcwotICAgICAgICAgICAg ICAgICAqIHdoZW4gZ29pbmcgb3ZlciB0aGUgdG9wCi0gICAgICAgICAgICAgICAgICovCi0gICAg ICAgICAgICAgICAgaWYgKCB3cnRoZHIuc2l6ZSA+IEZTVF9NRU1TSVpFIHx8IHdydGhkci5vZmZz ZXQgPiBGU1RfTUVNU0laRQotCQkJCXx8IHdydGhkci5zaXplICsgd3J0aGRyLm9mZnNldCA+IEZT VF9NRU1TSVpFICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBy ZXR1cm4gLUVOWElPOwotICAgICAgICAgICAgICAgIH0KKwlkYmcoREJHX0lPQ1RMLCAiaW9jdGw6 ICV4LCAlcFxuIiwgY21kLCBpZnItPmlmcl9kYXRhKTsKIAotICAgICAgICAgICAgICAgIC8qIE5v dyBjb3B5IHRoZSBkYXRhIHRvIHRoZSBjYXJkLgotICAgICAgICAgICAgICAgICAqIFRoaXMgd2ls bCBwcm9iYWJseSBicmVhayBvbiBzb21lIGFyY2hpdGVjdHVyZXMuCi0gICAgICAgICAgICAgICAg ICogSSdsbCBmaXggaXQgd2hlbiBJIGhhdmUgc29tZXRoaW5nIHRvIHRlc3Qgb24uCi0gICAgICAg ICAgICAgICAgICovCi0gICAgICAgICAgICAgICAgaWYgKCBjb3B5X2Zyb21fdXNlciAoIGNhcmQt Pm1lbSArIHdydGhkci5vZmZzZXQsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlm ci0+aWZyX2RhdGEgKyBzaXplb2YgKCBzdHJ1Y3QgZnN0aW9jX3dyaXRlICksCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHdydGhkci5zaXplICkpCi0gICAgICAgICAgICAgICAgewot ICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIC1FRkFVTFQ7Ci0gICAgICAgICAgICAgICAg fQorCXBvcnQgPSBkZXZfdG9fcG9ydChkZXYpOworCWNhcmQgPSBwb3J0LT5jYXJkOwogCi0gICAg ICAgICAgICAgICAgLyogV3JpdGVzIHRvIHRoZSBtZW1vcnkgb2YgYSBjYXJkIGluIHRoZSByZXNl dCBzdGF0ZSBjb25zdGl0dXRlCi0gICAgICAgICAgICAgICAgICogYSBkb3dubG9hZAotICAgICAg ICAgICAgICAgICAqLwotICAgICAgICAgICAgICAgIGlmICggY2FyZC0+c3RhdGUgPT0gRlNUX1JF U0VUICkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBjYXJkLT5z dGF0ZSA9IEZTVF9ET1dOTE9BRDsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgICAgICAgICAg cmV0dXJuIDA7CisJaWYgKCFjYXBhYmxlKENBUF9ORVRfQURNSU4pKQorCQlyZXR1cm4gLUVQRVJN OwogCi0gICAgICAgIGNhc2UgRlNUR0VUQ09ORjoKKwlzd2l0Y2ggKGNtZCkgeworCWNhc2UgRlNU Q1BVUkVTRVQ6CisJCWZzdF9jcHVyZXNldChjYXJkKTsKKwkJY2FyZC0+c3RhdGUgPSBGU1RfUkVT RVQ7CisJCXJldHVybiAwOwogCi0gICAgICAgICAgICAgICAgLyogSWYgY2FyZCBoYXMganVzdCBi ZWVuIHN0YXJ0ZWQgY2hlY2sgdGhlIHNoYXJlZCBtZW1vcnkgY29uZmlnCi0gICAgICAgICAgICAg ICAgICogdmVyc2lvbiBhbmQgbWFya2VyCi0gICAgICAgICAgICAgICAgICovCi0gICAgICAgICAg ICAgICAgaWYgKCBjYXJkLT5zdGF0ZSA9PSBGU1RfU1RBUlRJTkcgKQotICAgICAgICAgICAgICAg IHsKLSAgICAgICAgICAgICAgICAgICAgICAgIGNoZWNrX3N0YXJ0ZWRfb2sgKCBjYXJkICk7Ci0K LSAgICAgICAgICAgICAgICAgICAgICAgIC8qIElmIGV2ZXJ5dGhpbmcgY2hlY2tlZCBvdXQgZW5h YmxlIGNhcmQgaW50ZXJydXB0cyAqLwotICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCBjYXJk LT5zdGF0ZSA9PSBGU1RfUlVOTklORyApCi0gICAgICAgICAgICAgICAgICAgICAgICB7Ci0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNwaW5fbG9ja19pcnFzYXZlICggJmNhcmQtPmNh cmRfbG9jaywgZmxhZ3MgKTsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZnN0X2Ns ZWFyX2ludHIgKCBjYXJkICk7Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZTVF9X UkIgKCBjYXJkLCBpbnRlcnJ1cHRIYW5kc2hha2UsIDB4RUUgKTsKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ss Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZmxhZ3MgKTsKLSAgICAgICAgICAgICAgICAgICAgICAgIH0KLSAgICAgICAgICAg ICAgICB9CisJY2FzZSBGU1RDUFVSRUxFQVNFOgorCQlmc3RfY3B1cmVsZWFzZShjYXJkKTsKKwkJ Y2FyZC0+c3RhdGUgPSBGU1RfU1RBUlRJTkc7CisJCXJldHVybiAwOwogCi0gICAgICAgICAgICAg ICAgaWYgKCBpZnItPmlmcl9kYXRhID09IE5VTEwgKQotICAgICAgICAgICAgICAgIHsKLSAgICAg ICAgICAgICAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOwotICAgICAgICAgICAgICAgIH0KKwlj YXNlIEZTVFdSSVRFOgkJLyogQ29kZSB3cml0ZSAoZG93bmxvYWQpICovCiAKLSAgICAgICAgICAg ICAgICBnYXRoZXJfY29uZl9pbmZvICggY2FyZCwgcG9ydCwgJmluZm8gKTsKKwkJLyogRmlyc3Qg Y29weSBpbiB0aGUgaGVhZGVyIHdpdGggdGhlIGxlbmd0aCBhbmQgb2Zmc2V0IG9mIGRhdGEKKwkJ ICogdG8gd3JpdGUKKwkJICovCisJCWlmIChpZnItPmlmcl9kYXRhID09IE5VTEwpIHsKKwkJCXJl dHVybiAtRUlOVkFMOworCQl9CisJCWlmIChjb3B5X2Zyb21fdXNlcigmd3J0aGRyLCBpZnItPmlm cl9kYXRhLAorCQkJCSAgIHNpemVvZiAoc3RydWN0IGZzdGlvY193cml0ZSkpKSB7CisJCQlyZXR1 cm4gLUVGQVVMVDsKKwkJfQogCi0gICAgICAgICAgICAgICAgaWYgKCBjb3B5X3RvX3VzZXIgKCBp ZnItPmlmcl9kYXRhLCAmaW5mbywgc2l6ZW9mICggaW5mbyApKSkKLSAgICAgICAgICAgICAgICB7 Ci0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVGQVVMVDsKLSAgICAgICAgICAgICAg ICB9Ci0gICAgICAgICAgICAgICAgcmV0dXJuIDA7CisJCS8qIFNhbml0eSBjaGVjayB0aGUgcGFy YW1ldGVycy4gV2UgZG9uJ3Qgc3VwcG9ydCBwYXJ0aWFsIHdyaXRlcworCQkgKiB3aGVuIGdvaW5n IG92ZXIgdGhlIHRvcAorCQkgKi8KKwkJaWYgKHdydGhkci5zaXplID4gRlNUX01FTVNJWkUgfHwg d3J0aGRyLm9mZnNldCA+IEZTVF9NRU1TSVpFCisJCSAgICB8fCB3cnRoZHIuc2l6ZSArIHdydGhk ci5vZmZzZXQgPiBGU1RfTUVNU0laRSkgeworCQkJcmV0dXJuIC1FTlhJTzsKKwkJfQogCi0gICAg ICAgIGNhc2UgRlNUU0VUQ09ORjoKKwkJLyogTm93IGNvcHkgdGhlIGRhdGEgdG8gdGhlIGNhcmQu CisJCSAqIFRoaXMgd2lsbCBwcm9iYWJseSBicmVhayBvbiBzb21lIGFyY2hpdGVjdHVyZXMuCisJ CSAqIEknbGwgZml4IGl0IHdoZW4gSSBoYXZlIHNvbWV0aGluZyB0byB0ZXN0IG9uLgorCQkgKi8K KwkJaWYgKGNvcHlfZnJvbV91c2VyKGNhcmQtPm1lbSArIHdydGhkci5vZmZzZXQsCisJCQkJICAg aWZyLT5pZnJfZGF0YSArIHNpemVvZiAoc3RydWN0IGZzdGlvY193cml0ZSksCisJCQkJICAgd3J0 aGRyLnNpemUpKSB7CisJCQlyZXR1cm4gLUVGQVVMVDsKKwkJfQogCi0gICAgICAgICAgICAgICAg LyogTW9zdCBvZiB0aGUgc2V0dGluZyBoYXZlIGJlZW4gbW92ZWQgdG8gdGhlIGdlbmVyaWMgaW9j dGxzCi0gICAgICAgICAgICAgICAgICogdGhpcyBqdXN0IGNvdmVycyBkZWJ1ZyBhbmQgYm9hcmQg aWRlbnQgbW9kZSBub3cKLSAgICAgICAgICAgICAgICAgKi8KLSAgICAgICAgICAgICAgICBpZiAo IGNvcHlfZnJvbV91c2VyICggJmluZm8sICBpZnItPmlmcl9kYXRhLCBzaXplb2YgKCBpbmZvICkp KQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAtRUZB VUxUOwotICAgICAgICAgICAgICAgIH0KKwkJLyogV3JpdGVzIHRvIHRoZSBtZW1vcnkgb2YgYSBj YXJkIGluIHRoZSByZXNldCBzdGF0ZSBjb25zdGl0dXRlCisJCSAqIGEgZG93bmxvYWQKKwkJICov CisJCWlmIChjYXJkLT5zdGF0ZSA9PSBGU1RfUkVTRVQpIHsKKwkJCWNhcmQtPnN0YXRlID0gRlNU X0RPV05MT0FEOworCQl9CisJCXJldHVybiAwOwogCi0gICAgICAgICAgICAgICAgcmV0dXJuIHNl dF9jb25mX2Zyb21faW5mbyAoIGNhcmQsIHBvcnQsICZpbmZvICk7CisJY2FzZSBGU1RHRVRDT05G OgogCi0gICAgICAgIGNhc2UgU0lPQ1dBTkRFVjoKLSAgICAgICAgICAgICAgICBzd2l0Y2ggKGlm ci0+aWZyX3NldHRpbmdzLnR5cGUpCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAg IGNhc2UgSUZfR0VUX0lGQUNFOgotICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIGZzdF9n ZXRfaWZhY2UgKCBjYXJkLCBwb3J0LCBpZnIgKTsKLQotICAgICAgICAgICAgICAgIGNhc2UgSUZf SUZBQ0VfU1lOQ19TRVJJQUw6Ci0gICAgICAgICAgICAgICAgY2FzZSBJRl9JRkFDRV9WMzU6Ci0g ICAgICAgICAgICAgICAgY2FzZSBJRl9JRkFDRV9WMjQ6Ci0gICAgICAgICAgICAgICAgY2FzZSBJ Rl9JRkFDRV9YMjE6Ci0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gZnN0X3NldF9pZmFj ZSAoIGNhcmQsIHBvcnQsIGlmciApOworCQkvKiBJZiBjYXJkIGhhcyBqdXN0IGJlZW4gc3RhcnRl ZCBjaGVjayB0aGUgc2hhcmVkIG1lbW9yeSBjb25maWcKKwkJICogdmVyc2lvbiBhbmQgbWFya2Vy CisJCSAqLworCQlpZiAoY2FyZC0+c3RhdGUgPT0gRlNUX1NUQVJUSU5HKSB7CisJCQljaGVja19z dGFydGVkX29rKGNhcmQpOwogCi0gICAgICAgICAgICAgICAgZGVmYXVsdDoKLSAgICAgICAgICAg ICAgICAgICAgICAgIHJldHVybiBoZGxjX2lvY3RsICggZGV2LCBpZnIsIGNtZCApOwotICAgICAg ICAgICAgICAgIH0KKwkJCS8qIElmIGV2ZXJ5dGhpbmcgY2hlY2tlZCBvdXQgZW5hYmxlIGNhcmQg aW50ZXJydXB0cyAqLworCQkJaWYgKGNhcmQtPnN0YXRlID09IEZTVF9SVU5OSU5HKSB7CisJCQkJ c3Bpbl9sb2NrX2lycXNhdmUoJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MpOworCQkJCWZzdF9lbmFi bGVfaW50cihjYXJkKTsKKwkJCQlGU1RfV1JCKGNhcmQsIGludGVycnVwdEhhbmRzaGFrZSwgMHhF RSk7CisJCQkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7 CisJCQl9CisJCX0KIAotICAgICAgICBkZWZhdWx0OgotICAgICAgICAgICAgICAgIC8qIE5vdCBv bmUgb2Ygb3Vycy4gUGFzcyB0aHJvdWdoIHRvIEhETEMgcGFja2FnZSAqLwotICAgICAgICAgICAg ICAgIHJldHVybiBoZGxjX2lvY3RsICggZGV2LCBpZnIsIGNtZCApOwotICAgICAgICB9Ci19CisJ CWlmIChpZnItPmlmcl9kYXRhID09IE5VTEwpIHsKKwkJCXJldHVybiAtRUlOVkFMOworCQl9CiAK KwkJZ2F0aGVyX2NvbmZfaW5mbyhjYXJkLCBwb3J0LCAmaW5mbyk7CiAKLXN0YXRpYyB2b2lkCi1m c3Rfb3BlbnBvcnQgKCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCApCi17Ci0gICAgICAgIGlu dCBzaWduYWxzOworCQlpZiAoY29weV90b191c2VyKGlmci0+aWZyX2RhdGEsICZpbmZvLCBzaXpl b2YgKGluZm8pKSkgeworCQkJcmV0dXJuIC1FRkFVTFQ7CisJCX0KKwkJcmV0dXJuIDA7CiAKLSAg ICAgICAgLyogT25seSBpbml0IHRoaW5ncyBpZiBjYXJkIGlzIGFjdHVhbGx5IHJ1bm5pbmcuIFRo aXMgYWxsb3dzIG9wZW4gdG8KLSAgICAgICAgICogc3VjY2VlZCBmb3IgZG93bmxvYWRzIGV0Yy4K LSAgICAgICAgICovCi0gICAgICAgIGlmICggcG9ydC0+Y2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5J TkcgKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgaWYgKCBwb3J0LT5ydW4gKQotICAgICAg ICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIGRiZyAoIERCR19PUEVOLCJvcGVu OiBmb3VuZCBwb3J0IGFscmVhZHkgcnVubmluZ1xuIik7CisJY2FzZSBGU1RTRVRDT05GOgogCi0g ICAgICAgICAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9ydCwgU1RPUFBPUlQgKTsK LSAgICAgICAgICAgICAgICAgICAgICAgIHBvcnQtPnJ1biA9IDA7Ci0gICAgICAgICAgICAgICAg fQorCQkvKgorCQkgKiBNb3N0IG9mIHRoZSBzZXR0aW5ncyBoYXZlIGJlZW4gbW92ZWQgdG8gdGhl IGdlbmVyaWMgaW9jdGxzCisJCSAqIHRoaXMganVzdCBjb3ZlcnMgZGVidWcgYW5kIGJvYXJkIGlk ZW50IG5vdworCQkgKi8KKworCQlpZiAoY2FyZC0+c3RhdGUgIT0gRlNUX1JVTk5JTkcpIHsKKwkJ CXByaW50a19lcnIKKwkJCSAgICAoIkF0dGVtcHQgdG8gY29uZmlndXJlIGNhcmQgJWQgaW4gbm9u LXJ1bm5pbmcgc3RhdGUgKCVkKVxuIiwKKwkJCSAgICAgY2FyZC0+Y2FyZF9ubywgY2FyZC0+c3Rh dGUpOworCQkJcmV0dXJuIC1FSU87CisJCX0KKwkJaWYgKGNvcHlfZnJvbV91c2VyKCZpbmZvLCBp ZnItPmlmcl9kYXRhLCBzaXplb2YgKGluZm8pKSkgeworCQkJcmV0dXJuIC1FRkFVTFQ7CisJCX0K IAotICAgICAgICAgICAgICAgIGZzdF9yeF9jb25maWcgKCBwb3J0ICk7Ci0gICAgICAgICAgICAg ICAgZnN0X3R4X2NvbmZpZyAoIHBvcnQgKTsKLSAgICAgICAgICAgICAgICBmc3Rfb3BfcmFpc2Ug KCBwb3J0LCBPUFNUU19SVFMgfCBPUFNUU19EVFIgKTsKKwkJcmV0dXJuIHNldF9jb25mX2Zyb21f aW5mbyhjYXJkLCBwb3J0LCAmaW5mbyk7CiAKLSAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21k ICggcG9ydCwgU1RBUlRQT1JUICk7Ci0gICAgICAgICAgICAgICAgcG9ydC0+cnVuID0gMTsKKwlj YXNlIFNJT0NXQU5ERVY6CisJCXN3aXRjaCAoaWZyLT5pZnJfc2V0dGluZ3MudHlwZSkgeworCQlj YXNlIElGX0dFVF9JRkFDRToKKwkJCXJldHVybiBmc3RfZ2V0X2lmYWNlKGNhcmQsIHBvcnQsIGlm cik7CisKKwkJY2FzZSBJRl9JRkFDRV9TWU5DX1NFUklBTDoKKwkJY2FzZSBJRl9JRkFDRV9WMzU6 CisJCWNhc2UgSUZfSUZBQ0VfVjI0OgorCQljYXNlIElGX0lGQUNFX1gyMToKKwkJY2FzZSBJRl9J RkFDRV9YMjFEOgorCQljYXNlIElGX0lGQUNFX1QxOgorCQljYXNlIElGX0lGQUNFX0UxOgorCQkJ cmV0dXJuIGZzdF9zZXRfaWZhY2UoY2FyZCwgcG9ydCwgaWZyKTsKKworCQljYXNlIElGX1BST1RP X1JBVzoKKwkJCXBvcnQtPm1vZGUgPSBGU1RfUkFXOworCQkJcmV0dXJuIDA7CisKKwkJY2FzZSBJ Rl9HRVRfUFJPVE86CisJCQlpZiAocG9ydC0+bW9kZSA9PSBGU1RfUkFXKSB7CisJCQkJaWZyLT5p ZnJfc2V0dGluZ3MudHlwZSA9IElGX1BST1RPX1JBVzsKKwkJCQlyZXR1cm4gMDsKKwkJCX0KKwkJ CXJldHVybiBoZGxjX2lvY3RsKGRldiwgaWZyLCBjbWQpOworCisJCWRlZmF1bHQ6CisJCQlwb3J0 LT5tb2RlID0gRlNUX0dFTl9IRExDOworCQkJZGJnKERCR19JT0NUTCwgIlBhc3NpbmcgdGhpcyB0 eXBlIHRvIGhkbGMgJXhcbiIsCisJCQkgICAgaWZyLT5pZnJfc2V0dGluZ3MudHlwZSk7CisJCQly ZXR1cm4gaGRsY19pb2N0bChkZXYsIGlmciwgY21kKTsKKwkJfQogCi0gICAgICAgICAgICAgICAg c2lnbmFscyA9IEZTVF9SREwgKCBwb3J0LT5jYXJkLCB2MjREZWJvdW5jZWRTdHNbcG9ydC0+aW5k ZXhdKTsKLSAgICAgICAgICAgICAgICBpZiAoIHNpZ25hbHMgJiAoKCBwb3J0LT5od2lmID09IFgy MSApID8gSVBTVFNfSU5ESUNBVEUKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDogSVBTVFNfRENEICkpCi0gICAgICAgICAgICAgICAgICAgICAg ICBuZXRpZl9jYXJyaWVyX29uICggcG9ydF90b19kZXYgKCBwb3J0ICkpOwotICAgICAgICAgICAg ICAgIGVsc2UKLSAgICAgICAgICAgICAgICAgICAgICAgIG5ldGlmX2NhcnJpZXJfb2ZmICggcG9y dF90b19kZXYgKCBwb3J0ICkpOwotICAgICAgICB9CisJZGVmYXVsdDoKKwkJLyogTm90IG9uZSBv ZiBvdXJzLiBQYXNzIHRocm91Z2ggdG8gSERMQyBwYWNrYWdlICovCisJCXJldHVybiBoZGxjX2lv Y3RsKGRldiwgaWZyLCBjbWQpOworCX0KIH0KIAogc3RhdGljIHZvaWQKLWZzdF9jbG9zZXBvcnQg KCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCApCitmc3Rfb3BlbnBvcnQoc3RydWN0IGZzdF9w b3J0X2luZm8gKnBvcnQpCiB7Ci0gICAgICAgIGlmICggcG9ydC0+Y2FyZC0+c3RhdGUgPT0gRlNU X1JVTk5JTkcgKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgaWYgKCBwb3J0LT5ydW4gKQot ICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIHBvcnQtPnJ1biA9IDA7 Ci0gICAgICAgICAgICAgICAgICAgICAgICBmc3Rfb3BfbG93ZXIgKCBwb3J0LCBPUFNUU19SVFMg fCBPUFNUU19EVFIgKTsKKwlpbnQgc2lnbmFsczsKKwlpbnQgdHhxX2xlbmd0aDsKKworCS8qIE9u bHkgaW5pdCB0aGluZ3MgaWYgY2FyZCBpcyBhY3R1YWxseSBydW5uaW5nLiBUaGlzIGFsbG93cyBv cGVuIHRvCisJICogc3VjY2VlZCBmb3IgZG93bmxvYWRzIGV0Yy4KKwkgKi8KKwlpZiAocG9ydC0+ Y2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5JTkcpIHsKKwkJaWYgKHBvcnQtPnJ1bikgeworCQkJZGJn KERCR19PUEVOLCAib3BlbjogZm91bmQgcG9ydCBhbHJlYWR5IHJ1bm5pbmdcbiIpOworCisJCQlm c3RfaXNzdWVfY21kKHBvcnQsIFNUT1BQT1JUKTsKKwkJCXBvcnQtPnJ1biA9IDA7CisJCX0KKwor CQlmc3RfcnhfY29uZmlnKHBvcnQpOworCQlmc3RfdHhfY29uZmlnKHBvcnQpOworCQlmc3Rfb3Bf cmFpc2UocG9ydCwgT1BTVFNfUlRTIHwgT1BTVFNfRFRSKTsKKworCQlmc3RfaXNzdWVfY21kKHBv cnQsIFNUQVJUUE9SVCk7CisJCXBvcnQtPnJ1biA9IDE7CisKKwkJc2lnbmFscyA9IEZTVF9SREwo cG9ydC0+Y2FyZCwgdjI0RGVib3VuY2VkU3RzW3BvcnQtPmluZGV4XSk7CisJCWlmIChzaWduYWxz ICYgKCgocG9ydC0+aHdpZiA9PSBYMjEpIHx8IChwb3J0LT5od2lmID09IFgyMUQpKQorCQkJICAg ICAgID8gSVBTVFNfSU5ESUNBVEUgOiBJUFNUU19EQ0QpKQorCQkJbmV0aWZfY2Fycmllcl9vbihw b3J0X3RvX2Rldihwb3J0KSk7CisJCWVsc2UKKwkJCW5ldGlmX2NhcnJpZXJfb2ZmKHBvcnRfdG9f ZGV2KHBvcnQpKTsKKworCQl0eHFfbGVuZ3RoID0gcG9ydC0+dHhxZSAtIHBvcnQtPnR4cXM7CisJ CXBvcnQtPnR4cWUgPSAwOworCQlwb3J0LT50eHFzID0gMDsKKwl9CiAKLSAgICAgICAgICAgICAg ICAgICAgICAgIGZzdF9pc3N1ZV9jbWQgKCBwb3J0LCBTVE9QUE9SVCApOwotICAgICAgICAgICAg ICAgIH0KLSAgICAgICAgICAgICAgICBlbHNlCi0gICAgICAgICAgICAgICAgewotICAgICAgICAg ICAgICAgICAgICAgICAgZGJnICggREJHX09QRU4sImNsb3NlOiBwb3J0IG5vdCBydW5uaW5nXG4i KTsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgIH0KIH0KIAorc3RhdGljIHZvaWQKK2ZzdF9j bG9zZXBvcnQoc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQpCit7CisJaWYgKHBvcnQtPmNhcmQt PnN0YXRlID09IEZTVF9SVU5OSU5HKSB7CisJCWlmIChwb3J0LT5ydW4pIHsKKwkJCXBvcnQtPnJ1 biA9IDA7CisJCQlmc3Rfb3BfbG93ZXIocG9ydCwgT1BTVFNfUlRTIHwgT1BTVFNfRFRSKTsKKwor CQkJZnN0X2lzc3VlX2NtZChwb3J0LCBTVE9QUE9SVCk7CisJCX0gZWxzZSB7CisJCQlkYmcoREJH X09QRU4sICJjbG9zZTogcG9ydCBub3QgcnVubmluZ1xuIik7CisJCX0KKwl9Cit9CiAKIHN0YXRp YyBpbnQKLWZzdF9vcGVuICggc3RydWN0IG5ldF9kZXZpY2UgKmRldiApCitmc3Rfb3BlbihzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2KQogewotICAgICAgICBpbnQgZXJyOworCWludCBlcnI7CisJc3Ry dWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7CiAKLSAgICAgICAgZXJyID0gaGRsY19vcGVuIChkZXYp OwotICAgICAgICBpZiAoIGVyciApCi0gICAgICAgICAgICAgICAgcmV0dXJuIGVycjsKKwlwb3J0 ID0gZGV2X3RvX3BvcnQoZGV2KTsKKwlpZiAoIXRyeV9tb2R1bGVfZ2V0KFRISVNfTU9EVUxFKSkK KyAgICAgICAgICByZXR1cm4gLUVCVVNZOworCisJaWYgKHBvcnQtPm1vZGUgIT0gRlNUX1JBVykg eworCQllcnIgPSBoZGxjX29wZW4oZGV2KTsKKwkJaWYgKGVycikKKwkJCXJldHVybiBlcnI7CisJ fQogCi0gICAgICAgIGZzdF9vcGVucG9ydCAoIGRldl90b19wb3J0ICggZGV2ICkpOwotICAgICAg ICBuZXRpZl93YWtlX3F1ZXVlICggZGV2ICk7Ci0gICAgICAgIHJldHVybiAwOworCWZzdF9vcGVu cG9ydChwb3J0KTsKKwluZXRpZl93YWtlX3F1ZXVlKGRldik7CisJcmV0dXJuIDA7CiB9CiAKIHN0 YXRpYyBpbnQKLWZzdF9jbG9zZSAoIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYgKQorZnN0X2Nsb3Nl KHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCiB7Ci0gICAgICAgIG5ldGlmX3N0b3BfcXVldWUgKCBk ZXYgKTsKLSAgICAgICAgZnN0X2Nsb3NlcG9ydCAoIGRldl90b19wb3J0ICggZGV2ICkpOwotICAg ICAgICBoZGxjX2Nsb3NlICggZGV2ICk7Ci0gICAgICAgIHJldHVybiAwOworCXN0cnVjdCBmc3Rf cG9ydF9pbmZvICpwb3J0OworCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOworCXVuc2lnbmVk IGNoYXIgdHhfZG1hX2RvbmU7CisJdW5zaWduZWQgY2hhciByeF9kbWFfZG9uZTsKKworCXBvcnQg PSBkZXZfdG9fcG9ydChkZXYpOworCWNhcmQgPSBwb3J0LT5jYXJkOworCisJdHhfZG1hX2RvbmUg PSBpbmIoY2FyZC0+cGNpX2NvbmYgKyBETUFDU1IxKTsKKwlyeF9kbWFfZG9uZSA9IGluYihjYXJk LT5wY2lfY29uZiArIERNQUNTUjApOworCWRiZyhEQkdfT1BFTiwKKwkgICAgIlBvcnQgQ2xvc2U6 IHR4X2RtYV9pbl9wcm9ncmVzcyA9ICVkICgleCkgcnhfZG1hX2luX3Byb2dyZXNzID0gJWQgKCV4 KVxuIiwKKwkgICAgY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MsIHR4X2RtYV9kb25lLCBjYXJkLT5k bWFyeF9pbl9wcm9ncmVzcywKKwkgICAgcnhfZG1hX2RvbmUpOworCisJbmV0aWZfc3RvcF9xdWV1 ZShkZXYpOworCWZzdF9jbG9zZXBvcnQoZGV2X3RvX3BvcnQoZGV2KSk7CisJaWYgKHBvcnQtPm1v ZGUgIT0gRlNUX1JBVykgeworCQloZGxjX2Nsb3NlKGRldik7CisJfQorCW1vZHVsZV9wdXQoVEhJ U19NT0RVTEUpOworCXJldHVybiAwOwogfQogCiBzdGF0aWMgaW50Ci1mc3RfYXR0YWNoICggc3Ry dWN0IG5ldF9kZXZpY2UgKmRldiwgdW5zaWduZWQgc2hvcnQgZW5jb2RpbmcsIHVuc2lnbmVkIHNo b3J0IHBhcml0eSApCitmc3RfYXR0YWNoKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIHVuc2lnbmVk IHNob3J0IGVuY29kaW5nLCB1bnNpZ25lZCBzaG9ydCBwYXJpdHkpCiB7Ci0gICAgICAgIC8qIFNl dHRpbmcgY3VycmVudGx5IGZpeGVkIGluIEZhclN5bmMgY2FyZCBzbyB3ZSBjaGVjayBhbmQgZm9y Z2V0ICovCi0gICAgICAgIGlmICggZW5jb2RpbmcgIT0gRU5DT0RJTkdfTlJaIHx8IHBhcml0eSAh PSBQQVJJVFlfQ1JDMTZfUFIxX0NDSVRUICkKLSAgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZB TDsKLSAgICAgICAgcmV0dXJuIDA7CisJLyoKKwkgKiBTZXR0aW5nIGN1cnJlbnRseSBmaXhlZCBp biBGYXJTeW5jIGNhcmQgc28gd2UgY2hlY2sgYW5kIGZvcmdldAorCSAqLworCWlmIChlbmNvZGlu ZyAhPSBFTkNPRElOR19OUlogfHwgcGFyaXR5ICE9IFBBUklUWV9DUkMxNl9QUjFfQ0NJVFQpCisJ CXJldHVybiAtRUlOVkFMOworCXJldHVybiAwOwogfQogCi0KIHN0YXRpYyB2b2lkCi1mc3RfdHhf dGltZW91dCAoIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYgKQorZnN0X3R4X3RpbWVvdXQoc3RydWN0 IG5ldF9kZXZpY2UgKmRldikKIHsKLSAgICAgICAgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7 CisJc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7CisJc3RydWN0IGZzdF9jYXJkX2luZm8gKmNh cmQ7CiAJc3RydWN0IG5ldF9kZXZpY2Vfc3RhdHMgKnN0YXRzID0gaGRsY19zdGF0cyhkZXYpOwog Ci0gICAgICAgIGRiZyAoIERCR19JTlRSIHwgREJHX1RYLCJ0eF90aW1lb3V0XG4iKTsKLQotICAg ICAgICBwb3J0ID0gZGV2X3RvX3BvcnQgKCBkZXYgKTsKLQotICAgICAgICBzdGF0cy0+dHhfZXJy b3JzKys7Ci0gICAgICAgIHN0YXRzLT50eF9hYm9ydGVkX2Vycm9ycysrOwotCi0gICAgICAgIGlm ICggcG9ydC0+dHhjbnQgPiAwICkKLSAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9y dCwgQUJPUlRUWCApOwotCi0gICAgICAgIGRldi0+dHJhbnNfc3RhcnQgPSBqaWZmaWVzOwotICAg ICAgICBuZXRpZl93YWtlX3F1ZXVlICggZGV2ICk7CisJcG9ydCA9IGRldl90b19wb3J0KGRldik7 CisJY2FyZCA9IHBvcnQtPmNhcmQ7CisJc3RhdHMtPnR4X2Vycm9ycysrOworCXN0YXRzLT50eF9h Ym9ydGVkX2Vycm9ycysrOworCWRiZyhEQkdfQVNTLCAiVHggdGltZW91dCBjYXJkICVkIHBvcnQg JWRcbiIsCisJICAgIGNhcmQtPmNhcmRfbm8sIHBvcnQtPmluZGV4KTsKKwlmc3RfaXNzdWVfY21k KHBvcnQsIEFCT1JUVFgpOworCisJZGV2LT50cmFuc19zdGFydCA9IGppZmZpZXM7CisJbmV0aWZf d2FrZV9xdWV1ZShkZXYpOworCXBvcnQtPnN0YXJ0ID0gMDsKIH0KIAotCiBzdGF0aWMgaW50Ci1m c3Rfc3RhcnRfeG1pdCAoIHN0cnVjdCBza19idWZmICpza2IsIHN0cnVjdCBuZXRfZGV2aWNlICpk ZXYgKQorZnN0X3N0YXJ0X3htaXQoc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5ldF9kZXZp Y2UgKmRldikKIHsKKwlzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZDsKKwlzdHJ1Y3QgZnN0X3Bv cnRfaW5mbyAqcG9ydDsKIAlzdHJ1Y3QgbmV0X2RldmljZV9zdGF0cyAqc3RhdHMgPSBoZGxjX3N0 YXRzKGRldik7Ci0gICAgICAgIHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICBz dHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydDsKLSAgICAgICAgdW5zaWduZWQgY2hhciBkbWFiaXRz OwotICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwotICAgICAgICBpbnQgcGk7Ci0gICAgICAg IGludCB0eHA7Ci0KLSAgICAgICAgcG9ydCA9IGRldl90b19wb3J0ICggZGV2ICk7Ci0gICAgICAg IGNhcmQgPSBwb3J0LT5jYXJkOwotCi0gICAgICAgIC8qIERyb3AgcGFja2V0IHdpdGggZXJyb3Ig aWYgd2UgZG9uJ3QgaGF2ZSBjYXJyaWVyICovCi0gICAgICAgIGlmICggISBuZXRpZl9jYXJyaWVy X29rICggZGV2ICkpCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBkZXZfa2ZyZWVfc2tiICgg c2tiICk7Ci0gICAgICAgICAgICAgICAgc3RhdHMtPnR4X2Vycm9ycysrOwotICAgICAgICAgICAg ICAgIHN0YXRzLT50eF9jYXJyaWVyX2Vycm9ycysrOwotICAgICAgICAgICAgICAgIHJldHVybiAw OwotICAgICAgICB9Ci0KLSAgICAgICAgLyogRHJvcCBpdCBpZiBpdCdzIHRvbyBiaWchIE1UVSBm YWlsdXJlID8gKi8KLSAgICAgICAgaWYgKCBza2ItPmxlbiA+IExFTl9UWF9CVUZGRVIgKQotICAg ICAgICB7Ci0gICAgICAgICAgICAgICAgZGJnICggREJHX1RYLCJQYWNrZXQgdG9vIGxhcmdlICVk IHZzICVkXG4iLCBza2ItPmxlbiwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIExFTl9UWF9CVUZGRVIgKTsKLSAgICAgICAgICAgICAgICBkZXZfa2ZyZWVf c2tiICggc2tiICk7Ci0gICAgICAgICAgICAgICAgc3RhdHMtPnR4X2Vycm9ycysrOwotICAgICAg ICAgICAgICAgIHJldHVybiAwOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogQ2hlY2sgd2UgaGF2 ZSBhIGJ1ZmZlciAqLwotICAgICAgICBwaSA9IHBvcnQtPmluZGV4OwotICAgICAgICBzcGluX2xv Y2tfaXJxc2F2ZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0gICAgICAgIHR4cCA9IHBv cnQtPnR4cG9zOwotICAgICAgICBkbWFiaXRzID0gRlNUX1JEQiAoIGNhcmQsIHR4RGVzY3JSaW5n W3BpXVt0eHBdLmJpdHMgKTsKLSAgICAgICAgaWYgKCBkbWFiaXRzICYgRE1BX09XTiApCi0gICAg ICAgIHsKLSAgICAgICAgICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlICggJmNhcmQtPmNh cmRfbG9jaywgZmxhZ3MgKTsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfVFgsIk91dCBvZiBU eCBidWZmZXJzXG4iKTsKLSAgICAgICAgICAgICAgICBkZXZfa2ZyZWVfc2tiICggc2tiICk7Ci0g ICAgICAgICAgICAgICAgc3RhdHMtPnR4X2Vycm9ycysrOwotICAgICAgICAgICAgICAgIHJldHVy biAwOwotICAgICAgICB9Ci0gICAgICAgIGlmICggKytwb3J0LT50eHBvcyA+PSBOVU1fVFhfQlVG RkVSICkKLSAgICAgICAgICAgICAgICBwb3J0LT50eHBvcyA9IDA7Ci0KLSAgICAgICAgaWYgKCAr K3BvcnQtPnR4Y250ID49IE5VTV9UWF9CVUZGRVIgKQotICAgICAgICAgICAgICAgIG5ldGlmX3N0 b3BfcXVldWUgKCBkZXYgKTsKLQotICAgICAgICAvKiBSZWxlYXNlIHRoZSBjYXJkIGxvY2sgYmVm b3JlIHdlIGNvcHkgdGhlIGRhdGEgYXMgd2Ugbm93IGhhdmUKLSAgICAgICAgICogZXhjbHVzaXZl IGFjY2VzcyB0byB0aGUgYnVmZmVyLgotICAgICAgICAgKi8KLSAgICAgICAgc3Bpbl91bmxvY2tf aXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0KLSAgICAgICAgLyogRW5x dWV1ZSB0aGUgcGFja2V0ICovCi0gICAgICAgIG1lbWNweV90b2lvICggY2FyZC0+bWVtICsgQlVG X09GRlNFVCAoIHR4QnVmZmVyW3BpXVt0eHBdWzBdKSwKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHNrYi0+ZGF0YSwgc2tiLT5sZW4gKTsKLSAgICAgICAg RlNUX1dSVyAoIGNhcmQsIHR4RGVzY3JSaW5nW3BpXVt0eHBdLmJjbnQsIGNudl9iY250ICggc2ti LT5sZW4gKSk7Ci0gICAgICAgIEZTVF9XUkIgKCBjYXJkLCB0eERlc2NyUmluZ1twaV1bdHhwXS5i aXRzLCBETUFfT1dOIHwgVFhfU1RQIHwgVFhfRU5QICk7CisJdW5zaWduZWQgbG9uZyBmbGFnczsK KwlpbnQgdHhxX2xlbmd0aDsKIAotICAgICAgICBzdGF0cy0+dHhfcGFja2V0cysrOwotICAgICAg ICBzdGF0cy0+dHhfYnl0ZXMgKz0gc2tiLT5sZW47CisJcG9ydCA9IGRldl90b19wb3J0KGRldik7 CisJY2FyZCA9IHBvcnQtPmNhcmQ7CisJZGJnKERCR19UWCwgImZzdF9zdGFydF94bWl0OiBsZW5n dGggPSAlZFxuIiwgc2tiLT5sZW4pOworCisJLyogRHJvcCBwYWNrZXQgd2l0aCBlcnJvciBpZiB3 ZSBkb24ndCBoYXZlIGNhcnJpZXIgKi8KKwlpZiAoIW5ldGlmX2NhcnJpZXJfb2soZGV2KSkgewor CQlkZXZfa2ZyZWVfc2tiKHNrYik7CisJCXN0YXRzLT50eF9lcnJvcnMrKzsKKwkJc3RhdHMtPnR4 X2NhcnJpZXJfZXJyb3JzKys7CisJCWRiZyhEQkdfQVNTLAorCQkgICAgIlRyaWVkIHRvIHRyYW5z bWl0IGJ1dCBubyBjYXJyaWVyIG9uIGNhcmQgJWQgcG9ydCAlZFxuIiwKKwkJICAgIGNhcmQtPmNh cmRfbm8sIHBvcnQtPmluZGV4KTsKKwkJcmV0dXJuIDA7CisJfQogCi0gICAgICAgIGRldl9rZnJl ZV9za2IgKCBza2IgKTsKKwkvKiBEcm9wIGl0IGlmIGl0J3MgdG9vIGJpZyEgTVRVIGZhaWx1cmUg PyAqLworCWlmIChza2ItPmxlbiA+IExFTl9UWF9CVUZGRVIpIHsKKwkJZGJnKERCR19BU1MsICJQ YWNrZXQgdG9vIGxhcmdlICVkIHZzICVkXG4iLCBza2ItPmxlbiwKKwkJICAgIExFTl9UWF9CVUZG RVIpOworCQlkZXZfa2ZyZWVfc2tiKHNrYik7CisJCXN0YXRzLT50eF9lcnJvcnMrKzsKKwkJcmV0 dXJuIDA7CisJfQogCi0gICAgICAgIGRldi0+dHJhbnNfc3RhcnQgPSBqaWZmaWVzOwotICAgICAg ICByZXR1cm4gMDsKLX0KKwkvKgorCSAqIFdlIGFyZSBhbHdheXMgZ29pbmcgdG8gcXVldWUgdGhl IHBhY2tldAorCSAqIHNvIHRoYXQgdGhlIGJvdHRvbSBoYWxmIGlzIHRoZSBvbmx5IHBsYWNlIHdl IHR4IGZyb20KKwkgKiBDaGVjayB0aGVyZSBpcyByb29tIGluIHRoZSBwb3J0IHR4cQorCSAqLwor CXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwlpZiAoKHR4cV9s ZW5ndGggPSBwb3J0LT50eHFlIC0gcG9ydC0+dHhxcykgPCAwKSB7CisJCS8qCisJCSAqIFRoaXMg aXMgdGhlIGNhc2Ugd2hlcmUgdGhlIG5leHQgZnJlZSBoYXMgd3JhcHBlZCBidXQgdGhlCisJCSAq IGxhc3QgdXNlZCBoYXNuJ3QKKwkJICovCisJCXR4cV9sZW5ndGggPSB0eHFfbGVuZ3RoICsgRlNU X1RYUV9ERVBUSDsKKwl9CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9sb2Nr LCBmbGFncyk7CisJaWYgKHR4cV9sZW5ndGggPiBmc3RfdHhxX2hpZ2gpIHsKKwkJLyoKKwkJICog V2UgaGF2ZSBnb3QgZW5vdWdoIGJ1ZmZlcnMgaW4gdGhlIHBpcGVsaW5lLiAgQXNrIHRoZSBuZXR3 b3JrCisJCSAqIGxheWVyIHRvIHN0b3Agc2VuZGluZyBmcmFtZXMgZG93bgorCQkgKi8KKwkJbmV0 aWZfc3RvcF9xdWV1ZShkZXYpOworCQlwb3J0LT5zdGFydCA9IDE7CS8qIEknbSB1c2luZyB0aGlz IHRvIHNpZ25hbCBzdG9wIHNlbnQgdXAgKi8KKwl9CisKKwlpZiAodHhxX2xlbmd0aCA9PSBGU1Rf VFhRX0RFUFRIIC0gMSkgeworCQkvKgorCQkgKiBUaGlzIHNob3VsZG4ndCBoYXZlIGhhcHBlbmVk IGJ1dCBzdWNoIGlzIGxpZmUKKwkJICovCisJCWRldl9rZnJlZV9za2Ioc2tiKTsKKwkJc3RhdHMt PnR4X2Vycm9ycysrOworCQlkYmcoREJHX0FTUywgIlR4IHF1ZXVlIG92ZXJmbG93IGNhcmQgJWQg cG9ydCAlZFxuIiwKKwkJICAgIGNhcmQtPmNhcmRfbm8sIHBvcnQtPmluZGV4KTsKKwkJcmV0dXJu IDA7CisJfQorCisJLyoKKwkgKiBxdWV1ZSB0aGUgYnVmZmVyCisJICovCisJc3Bpbl9sb2NrX2ly cXNhdmUoJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MpOworCXBvcnQtPnR4cVtwb3J0LT50eHFlXSA9 IHNrYjsKKwlwb3J0LT50eHFlKys7CisJaWYgKHBvcnQtPnR4cWUgPT0gRlNUX1RYUV9ERVBUSCkK KwkJcG9ydC0+dHhxZSA9IDA7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9s b2NrLCBmbGFncyk7CisKKwkvKiBTY2VoZHVsZSB0aGUgYm90dG9tIGhhbGYgd2hpY2ggbm93IGRv ZXMgdHJhbnNtaXQgcHJvY2Vzc2luZyAqLworCWZzdF9xX3dvcmtfaXRlbSgmZnN0X3dvcmtfdHhx LCBjYXJkLT5jYXJkX25vKTsKKwl0YXNrbGV0X3NjaGVkdWxlKCZmc3RfdHhfdGFzayk7CiAKKwly ZXR1cm4gMDsKK30KIAogLyoKICAqICAgICAgQ2FyZCBzZXR1cCBoYXZpbmcgY2hlY2tlZCBoYXJk d2FyZSByZXNvdXJjZXMuCkBAIC0xNDQwLDIyICsyMzk4LDI2IEBACiAgKiAgICAgIGRpc2FibGVk LgogICovCiBzdGF0aWMgY2hhciAqdHlwZV9zdHJpbmdzW10gX19kZXZpbml0ZGF0YSA9IHsKLSAg ICAgICAgIm5vIGhhcmR3YXJlIiwgICAgICAgICAgICAgICAgICAvKiBTaG91bGQgbmV2ZXIgYmUg c2VlbiAqLwotICAgICAgICAiRmFyU3luYyBUMlAiLAotICAgICAgICAiRmFyU3luYyBUNFAiCisJ Im5vIGhhcmR3YXJlIiwJCS8qIFNob3VsZCBuZXZlciBiZSBzZWVuICovCisJIkZhclN5bmMgVDJQ IiwKKwkiRmFyU3luYyBUNFAiLAorCSJGYXJTeW5jIFQxVSIsCisJIkZhclN5bmMgVDJVIiwKKwki RmFyU3luYyBUNFUiLAorCSJGYXJTeW5jIFRFMSIKIH07CiAKIHN0YXRpYyB2b2lkIF9fZGV2aW5p dAotZnN0X2luaXRfY2FyZCAoIHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkICkKK2ZzdF9pbml0 X2NhcmQoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQpCiB7Ci0gICAgICAgIGludCBpOwotICAg ICAgICBpbnQgZXJyOworCWludCBpOworCWludCBlcnI7CiAKLSAgICAgICAgLyogV2UncmUgd29y a2luZyBvbiBhIG51bWJlciBvZiBwb3J0cyBiYXNlZCBvbiB0aGUgY2FyZCBJRC4gSWYgdGhlCi0g ICAgICAgICAqIGZpcm13YXJlIGRldGVjdHMgc29tZXRoaW5nIGRpZmZlcmVudCBsYXRlciAoc2hv dWxkIG5ldmVyIGhhcHBlbikKLSAgICAgICAgICogd2UnbGwgaGF2ZSB0byByZXZpc2UgaXQgaW4g c29tZSB3YXkgdGhlbi4KLSAgICAgICAgICovCi0gICAgICAgIGZvciAoIGkgPSAwIDsgaSA8IGNh cmQtPm5wb3J0cyA7IGkrKyApIHsKKwkvKiBXZSdyZSB3b3JraW5nIG9uIGEgbnVtYmVyIG9mIHBv cnRzIGJhc2VkIG9uIHRoZSBjYXJkIElELiBJZiB0aGUKKwkgKiBmaXJtd2FyZSBkZXRlY3RzIHNv bWV0aGluZyBkaWZmZXJlbnQgbGF0ZXIgKHNob3VsZCBuZXZlciBoYXBwZW4pCisJICogd2UnbGwg aGF2ZSB0byByZXZpc2UgaXQgaW4gc29tZSB3YXkgdGhlbi4KKwkgKi8KKwlmb3IgKGkgPSAwOyBp IDwgY2FyZC0+bnBvcnRzOyBpKyspIHsKICAgICAgICAgICAgICAgICBlcnIgPSByZWdpc3Rlcl9o ZGxjX2RldmljZShjYXJkLT5wb3J0c1tpXS5kZXYpOwogICAgICAgICAgICAgICAgIGlmIChlcnIg PCAwKSB7CiAJCQlpbnQgajsKQEAgLTE0NjgsNjIgKzI0MzAsMTIwIEBACiAgICAgICAgICAgICAg ICAgICAgICAgICBjYXJkLT5ucG9ydHMgPSBpOwogICAgICAgICAgICAgICAgICAgICAgICAgYnJl YWs7CiAgICAgICAgICAgICAgICAgfQotICAgICAgICB9CisJfQogCi0gICAgICAgIHByaW50ayAo IEtFUk5fSU5GTyAiJXMtJXM6ICVzIElSUSVkLCAlZCBwb3J0c1xuIiwKLSAgICAgICAgICAgICAg ICAgICAgICAgIHBvcnRfdG9fZGV2KCZjYXJkLT5wb3J0c1swXSktPm5hbWUsCi0gICAgICAgICAg ICAgICAgICAgICAgICBwb3J0X3RvX2RldigmY2FyZC0+cG9ydHNbY2FyZC0+bnBvcnRzLTFdKS0+ bmFtZSwKLSAgICAgICAgICAgICAgICAgICAgICAgIHR5cGVfc3RyaW5nc1tjYXJkLT50eXBlXSwg Y2FyZC0+aXJxLCBjYXJkLT5ucG9ydHMgKTsKKwlwcmludGtfaW5mbygiJXMtJXM6ICVzIElSUSVk LCAlZCBwb3J0c1xuIiwKKwkgICAgICAgcG9ydF90b19kZXYoJmNhcmQtPnBvcnRzWzBdKS0+bmFt ZSwKKwkgICAgICAgcG9ydF90b19kZXYoJmNhcmQtPnBvcnRzW2NhcmQtPm5wb3J0cyAtIDFdKS0+ bmFtZSwKKwkgICAgICAgdHlwZV9zdHJpbmdzW2NhcmQtPnR5cGVdLCBjYXJkLT5pcnEsIGNhcmQt Pm5wb3J0cyk7CiB9CiAKLQogLyoKICAqICAgICAgSW5pdGlhbGlzZSBjYXJkIHdoZW4gZGV0ZWN0 ZWQuCiAgKiAgICAgIFJldHVybnMgMCB0byBpbmRpY2F0ZSBzdWNjZXNzLCBvciBlcnJubyBvdGhl cndpc2UuCiAgKi8KIHN0YXRpYyBpbnQgX19kZXZpbml0Ci1mc3RfYWRkX29uZSAoIHN0cnVjdCBw Y2lfZGV2ICpwZGV2LCBjb25zdCBzdHJ1Y3QgcGNpX2RldmljZV9pZCAqZW50ICkKK2ZzdF9hZGRf b25lKHN0cnVjdCBwY2lfZGV2ICpwZGV2LCBjb25zdCBzdHJ1Y3QgcGNpX2RldmljZV9pZCAqZW50 KQogewotICAgICAgICBzdGF0aWMgaW50IGZpcnN0dGltZV9kb25lID0gMDsKLSAgICAgICAgc3Ry dWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7Ci0gICAgICAgIGludCBlcnIgPSAwOworCXN0YXRpYyBp bnQgZmlyc3R0aW1lX2RvbmUgPSAwOworCXN0YXRpYyBpbnQgbm9fb2ZfY2FyZHNfYWRkZWQgPSAw OworCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOworCWludCBlcnIgPSAwOwogCWludCBpOwog Ci0gICAgICAgIGlmICggISBmaXJzdHRpbWVfZG9uZSApCi0gICAgICAgIHsKLSAgICAgICAgICAg ICAgICBwcmludGsgKCBLRVJOX0lORk8gIkZhclN5bmMgWDIxIGRyaXZlciAiIEZTVF9VU0VSX1ZF UlNJT04KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIiAoYykgMjAwMSBGYXJTaXRl IENvbW11bmljYXRpb25zIEx0ZC5cbiIpOwotICAgICAgICAgICAgICAgIGZpcnN0dGltZV9kb25l ID0gMTsKLSAgICAgICAgfQotCi0gICAgICAgIC8qIEFsbG9jYXRlIGRyaXZlciBwcml2YXRlIGRh dGEgKi8KLSAgICAgICAgY2FyZCA9IGttYWxsb2MgKCBzaXplb2YgKCBzdHJ1Y3QgZnN0X2NhcmRf aW5mbyApLCAgR0ZQX0tFUk5FTCk7Ci0gICAgICAgIGlmIChjYXJkID09IE5VTEwpCi0gICAgICAg IHsKLSAgICAgICAgICAgICAgICBwcmludGtfZXJyICgiRmFyU3luYyBjYXJkIGZvdW5kIGJ1dCBp bnN1ZmZpY2llbnQgbWVtb3J5IGZvciIKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IiBkcml2ZXIgc3RvcmFnZVxuIik7Ci0gICAgICAgICAgICAgICAgcmV0dXJuIC1FTk9NRU07Ci0g ICAgICAgIH0KLSAgICAgICAgbWVtc2V0ICggY2FyZCwgMCwgc2l6ZW9mICggc3RydWN0IGZzdF9j YXJkX2luZm8gKSk7Ci0KLSAgICAgICAgLyogVHJ5IHRvIGVuYWJsZSB0aGUgZGV2aWNlICovCi0g ICAgICAgIGlmICgoIGVyciA9IHBjaV9lbmFibGVfZGV2aWNlICggcGRldiApKSAhPSAwICkKLSAg ICAgICAgewotICAgICAgICAgICAgICAgIHByaW50a19lcnIgKCJGYWlsZWQgdG8gZW5hYmxlIGNh cmQuIEVyciAlZFxuIiwgLWVyciApOwotICAgICAgICAgICAgICAgIGdvdG8gZXJyb3JfZnJlZV9j YXJkOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogUmVjb3JkIGluZm8gd2UgbmVlZCovCi0gICAg ICAgIGNhcmQtPmlycSAgICAgICAgID0gcGRldi0+aXJxOwotICAgICAgICBjYXJkLT5wY2lfY29u ZiAgICA9IHBjaV9yZXNvdXJjZV9zdGFydCAoIHBkZXYsIDEgKTsKLSAgICAgICAgY2FyZC0+cGh5 c19tZW0gICAgPSBwY2lfcmVzb3VyY2Vfc3RhcnQgKCBwZGV2LCAyICk7Ci0gICAgICAgIGNhcmQt PnBoeXNfY3RsbWVtID0gcGNpX3Jlc291cmNlX3N0YXJ0ICggcGRldiwgMyApOworCWlmICghZmly c3R0aW1lX2RvbmUpIHsKKwkJcHJpbnRrX2luZm8oIkZhclN5bmMgV0FOIGRyaXZlciAiIEZTVF9V U0VSX1ZFUlNJT04KKwkJICAgICAgICIgKGMpIDIwMDEtMjAwNCBGYXJTaXRlIENvbW11bmljYXRp b25zIEx0ZC5cbiIpOworCQlmaXJzdHRpbWVfZG9uZSA9IDE7CisJCWRiZyhEQkdfQVNTLCAiVGhl IHZhbHVlIG9mIGRlYnVnIG1hc2sgaXMgJXhcbiIsIGZzdF9kZWJ1Z19tYXNrKTsKKwl9CisKKwkv KgorCSAqIFdlIGFyZSBnb2luZyB0byBiZSBjbGV2ZXIgYW5kIGFsbG93IGNlcnRhaW4gY2FyZHMg bm90IHRvIGJlCisJICogY29uZmlndXJlZC4gIEFuIGV4Y2x1ZGUgbGlzdCBjYW4gYmUgcHJvdmlk ZWQgaW4gL2V0Yy9tb2R1bGVzLmNvbmYKKwkgKi8KKwlpZiAoZnN0X2V4Y2x1ZGVkX2NhcmRzICE9 IDApIHsKKwkJLyoKKwkJICogVGhlcmUgYXJlIGNhcmRzIHRvIGV4Y2x1ZGUKKwkJICoKKwkJICov CisJCWZvciAoaSA9IDA7IGkgPCBmc3RfZXhjbHVkZWRfY2FyZHM7IGkrKykgeworCQkJaWYgKChw ZGV2LT5kZXZmbikgPj4gMyA9PSBmc3RfZXhjbHVkZWRfbGlzdFtpXSkgeworCQkJCXByaW50a19p bmZvKCJGYXJTeW5jIFBDSSBkZXZpY2UgJWQgbm90IGFzc2lnbmVkXG4iLAorCQkJCSAgICAgICAo cGRldi0+ZGV2Zm4pID4+IDMpOworCQkJCXJldHVybiAtRUJVU1k7CisJCQl9CisJCX0KKwl9CisK KwkvKiBBbGxvY2F0ZSBkcml2ZXIgcHJpdmF0ZSBkYXRhICovCisJY2FyZCA9IGttYWxsb2Moc2l6 ZW9mIChzdHJ1Y3QgZnN0X2NhcmRfaW5mbyksIEdGUF9LRVJORUwpOworCWlmIChjYXJkID09IE5V TEwpIHsKKwkJcHJpbnRrX2VycigiRmFyU3luYyBjYXJkIGZvdW5kIGJ1dCBpbnN1ZmZpY2llbnQg bWVtb3J5IGZvciIKKwkJCSAgICIgZHJpdmVyIHN0b3JhZ2VcbiIpOworCQlyZXR1cm4gLUVOT01F TTsKKwl9CisJbWVtc2V0KGNhcmQsIDAsIHNpemVvZiAoc3RydWN0IGZzdF9jYXJkX2luZm8pKTsK KworCS8qIFRyeSB0byBlbmFibGUgdGhlIGRldmljZSAqLworCWlmICgoZXJyID0gcGNpX2VuYWJs ZV9kZXZpY2UocGRldikpICE9IDApIHsKKwkJcHJpbnRrX2VycigiRmFpbGVkIHRvIGVuYWJsZSBj YXJkLiBFcnIgJWRcbiIsIC1lcnIpOworCQlrZnJlZShjYXJkKTsKKwkJcmV0dXJuIGVycjsKKwl9 CisKKwlpZiAoKGVyciA9IHBjaV9yZXF1ZXN0X3JlZ2lvbnMocGRldiwgIkZhclN5bmMiKSkgIT0w KSB7CisJICAgICAgICBwcmludGtfZXJyKCJGYWlsZWQgdG8gYWxsb2NhdGUgcmVnaW9ucy4gRXJy ICVkXG4iLCAtZXJyKTsKKwkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOworCQlrZnJlZShjYXJk KTsKKwkgICAgICAgIHJldHVybiBlcnI7CisJfQorCisJLyogR2V0IHZpcnR1YWwgYWRkcmVzc2Vz IG9mIG1lbW9yeSByZWdpb25zICovCisJY2FyZC0+cGNpX2NvbmYgPSBwY2lfcmVzb3VyY2Vfc3Rh cnQocGRldiwgMSk7CisJY2FyZC0+cGh5c19tZW0gPSBwY2lfcmVzb3VyY2Vfc3RhcnQocGRldiwg Mik7CisJY2FyZC0+cGh5c19jdGxtZW0gPSBwY2lfcmVzb3VyY2Vfc3RhcnQocGRldiwgMyk7CisJ aWYgKChjYXJkLT5tZW0gPSBpb3JlbWFwKGNhcmQtPnBoeXNfbWVtLCBGU1RfTUVNU0laRSkpID09 IE5VTEwpIHsKKwkJcHJpbnRrX2VycigiUGh5c2ljYWwgbWVtb3J5IHJlbWFwIGZhaWxlZFxuIik7 CisJCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7CisJCXBjaV9kaXNhYmxlX2RldmljZShwZGV2 KTsKKwkJa2ZyZWUoY2FyZCk7CisJCXJldHVybiAtRU5PREVWOworCX0KKwlpZiAoKGNhcmQtPmN0 bG1lbSA9IGlvcmVtYXAoY2FyZC0+cGh5c19jdGxtZW0sIDB4MTApKSA9PSBOVUxMKSB7CisJCXBy aW50a19lcnIoIkNvbnRyb2wgbWVtb3J5IHJlbWFwIGZhaWxlZFxuIik7CisJCXBjaV9yZWxlYXNl X3JlZ2lvbnMocGRldik7CisJCXBjaV9kaXNhYmxlX2RldmljZShwZGV2KTsKKwkJa2ZyZWUoY2Fy ZCk7CisJCXJldHVybiAtRU5PREVWOworCX0KKwlkYmcoREJHX1BDSSwgImtlcm5lbCBtZW0gJXAs IGN0bG1lbSAlcFxuIiwgY2FyZC0+bWVtLCBjYXJkLT5jdGxtZW0pOwogCi0gICAgICAgIGNhcmQt PnR5cGUgICAgICAgID0gZW50LT5kcml2ZXJfZGF0YTsKLSAgICAgICAgY2FyZC0+bnBvcnRzICAg ICAgPSAoIGVudC0+ZHJpdmVyX2RhdGEgPT0gRlNUX1RZUEVfVDJQICkgPyAyIDogNDsKKwkvKiBS ZWdpc3RlciB0aGUgaW50ZXJydXB0IGhhbmRsZXIgKi8KKwlpZiAocmVxdWVzdF9pcnEocGRldi0+ aXJxLCBmc3RfaW50ciwgU0FfU0hJUlEsIEZTVF9ERVZfTkFNRSwgY2FyZCkpIHsKKwkJcHJpbnRr X2VycigiVW5hYmxlIHRvIHJlZ2lzdGVyIGludGVycnVwdCAlZFxuIiwgY2FyZC0+aXJxKTsKKwkJ cGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2KTsKKwkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOwor CQlpb3VubWFwKGNhcmQtPmN0bG1lbSk7CisJCWlvdW5tYXAoY2FyZC0+bWVtKTsKKwkJa2ZyZWUo Y2FyZCk7CisJCXJldHVybiAtRU5PREVWOworCX0KIAotICAgICAgICBjYXJkLT5zdGF0ZSAgICAg ICA9IEZTVF9VTklOSVQ7CisJLyogUmVjb3JkIGluZm8gd2UgbmVlZCAqLworCWNhcmQtPmlycSA9 IHBkZXYtPmlycTsKKwljYXJkLT50eXBlID0gZW50LT5kcml2ZXJfZGF0YTsKKwljYXJkLT5mYW1p bHkgPSAoKGVudC0+ZHJpdmVyX2RhdGEgPT0gRlNUX1RZUEVfVDJQKSB8fAorCQkJKGVudC0+ZHJp dmVyX2RhdGEgPT0gRlNUX1RZUEVfVDRQKSkKKwkgICAgPyBGU1RfRkFNSUxZX1RYUCA6IEZTVF9G QU1JTFlfVFhVOworCWlmICgoZW50LT5kcml2ZXJfZGF0YSA9PSBGU1RfVFlQRV9UMVUpIHx8CisJ ICAgIChlbnQtPmRyaXZlcl9kYXRhID09IEZTVF9UWVBFX1RFMSkpCisJCWNhcmQtPm5wb3J0cyA9 IDE7CisJZWxzZQorCQljYXJkLT5ucG9ydHMgPSAoKGVudC0+ZHJpdmVyX2RhdGEgPT0gRlNUX1RZ UEVfVDJQKSB8fAorCQkJCShlbnQtPmRyaXZlcl9kYXRhID09IEZTVF9UWVBFX1QyVSkpID8gMiA6 IDQ7CiAKKwljYXJkLT5zdGF0ZSA9IEZTVF9VTklOSVQ7CiAgICAgICAgIHNwaW5fbG9ja19pbml0 ICggJmNhcmQtPmNhcmRfbG9jayApOwogCiAgICAgICAgIGZvciAoIGkgPSAwIDsgaSA8IGNhcmQt Pm5wb3J0cyA7IGkrKyApIHsKQEAgLTE1MzMsNyArMjU1MywxMyBAQAogCQkJd2hpbGUgKGktLSkK IAkJCQlmcmVlX25ldGRldihjYXJkLT5wb3J0c1tpXS5kZXYpOwogCQkJcHJpbnRrX2VyciAoIkZh clN5bmM6IG91dCBvZiBtZW1vcnlcbiIpOwotCQkJZ290byBlcnJvcl9mcmVlX2NhcmQ7CisgICAg ICAgICAgICAgICAgICAgICAgICBmcmVlX2lycShjYXJkLT5pcnEsIGNhcmQpOworICAgICAgICAg ICAgICAgICAgICAgICAgcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2KTsKKyAgICAgICAgICAgICAg ICAgICAgICAgIHBjaV9kaXNhYmxlX2RldmljZShwZGV2KTsKKyAgICAgICAgICAgICAgICAgICAg ICAgIGlvdW5tYXAoY2FyZC0+Y3RsbWVtKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGlvdW5t YXAoY2FyZC0+bWVtKTsKKyAgICAgICAgICAgICAgICAgICAgICAgIGtmcmVlKGNhcmQpOworICAg ICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIC1FTk9ERVY7CiAJCX0KIAkJY2FyZC0+cG9ydHNb aV0uZGV2ICAgID0gZGV2OwogICAgICAgICAgICAgICAgIGNhcmQtPnBvcnRzW2ldLmNhcmQgICA9 IGNhcmQ7CkBAIC0xNTY0LDEyOCArMjU5MCw5NSBAQAogICAgICAgICAgICAgICAgIGhkbGMtPnht aXQgICA9IGZzdF9zdGFydF94bWl0OwogCX0KIAotICAgICAgICBkYmcgKCBEQkdfUENJLCJ0eXBl ICVkIG5wb3J0cyAlZCBpcnEgJWRcbiIsIGNhcmQtPnR5cGUsCi0gICAgICAgICAgICAgICAgICAg ICAgICBjYXJkLT5ucG9ydHMsIGNhcmQtPmlycSApOwotICAgICAgICBkYmcgKCBEQkdfUENJLCJj b25mICUwNHggbWVtICUwOHggY3RsbWVtICUwOHhcbiIsCi0gICAgICAgICAgICAgICAgICAgICAg ICBjYXJkLT5wY2lfY29uZiwgY2FyZC0+cGh5c19tZW0sIGNhcmQtPnBoeXNfY3RsbWVtICk7Ci0K LSAgICAgICAgLyogQ2hlY2sgd2UgY2FuIGdldCBhY2Nlc3MgdG8gdGhlIG1lbW9yeSBhbmQgSS9P IHJlZ2lvbnMgKi8KLSAgICAgICAgaWYgKCAhIHJlcXVlc3RfcmVnaW9uICggY2FyZC0+cGNpX2Nv bmYsIDB4ODAsIlBMWCBjb25maWcgcmVncyIpKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAg cHJpbnRrX2VyciAoIlVuYWJsZSB0byBnZXQgY29uZmlnIEkvTyBAIDB4JTA0WFxuIiwKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNhcmQtPnBjaV9jb25m ICk7Ci0gICAgICAgICAgICAgICAgZXJyID0gLUVOT0RFVjsKLSAgICAgICAgICAgICAgICBnb3Rv IGVycm9yX2ZyZWVfcG9ydHM7Ci0gICAgICAgIH0KLSAgICAgICAgaWYgKCAhIHJlcXVlc3RfbWVt X3JlZ2lvbiAoIGNhcmQtPnBoeXNfbWVtLCBGU1RfTUVNU0laRSwiU2hhcmVkIFJBTSIpKQotICAg ICAgICB7Ci0gICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIlVuYWJsZSB0byBnZXQgbWFpbiBt ZW1vcnkgQCAweCUwOFhcbiIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBjYXJkLT5waHlzX21lbSApOwotICAgICAgICAgICAgICAgIGVyciA9IC1FTk9E RVY7Ci0gICAgICAgICAgICAgICAgZ290byBlcnJvcl9yZWxlYXNlX2lvOwotICAgICAgICB9Ci0g ICAgICAgIGlmICggISByZXF1ZXN0X21lbV9yZWdpb24gKCBjYXJkLT5waHlzX2N0bG1lbSwgMHgx MCwiQ29udHJvbCBtZW1vcnkiKSkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIHByaW50a19l cnIgKCJVbmFibGUgdG8gZ2V0IGNvbnRyb2wgbWVtb3J5IEAgMHglMDhYXG4iLAotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2FyZC0+cGh5c19jdGxtZW0g KTsKLSAgICAgICAgICAgICAgICBlcnIgPSAtRU5PREVWOwotICAgICAgICAgICAgICAgIGdvdG8g ZXJyb3JfcmVsZWFzZV9tZW07Ci0gICAgICAgIH0KLQotCi0gICAgICAgIC8qIEdldCB2aXJ0dWFs IGFkZHJlc3NlcyBvZiBtZW1vcnkgcmVnaW9ucyAqLwotICAgICAgICBpZiAoKCBjYXJkLT5tZW0g PSBpb3JlbWFwICggY2FyZC0+cGh5c19tZW0sIEZTVF9NRU1TSVpFICkpID09IE5VTEwgKQotICAg ICAgICB7Ci0gICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIlBoeXNpY2FsIG1lbW9yeSByZW1h cCBmYWlsZWRcbiIpOwotICAgICAgICAgICAgICAgIGVyciA9IC1FTk9ERVY7Ci0gICAgICAgICAg ICAgICAgZ290byBlcnJvcl9yZWxlYXNlX2N0bG1lbTsKLSAgICAgICAgfQotICAgICAgICBpZiAo KCBjYXJkLT5jdGxtZW0gPSBpb3JlbWFwICggY2FyZC0+cGh5c19jdGxtZW0sIDB4MTAgKSkgPT0g TlVMTCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBwcmludGtfZXJyICgiQ29udHJvbCBt ZW1vcnkgcmVtYXAgZmFpbGVkXG4iKTsKLSAgICAgICAgICAgICAgICBlcnIgPSAtRU5PREVWOwot ICAgICAgICAgICAgICAgIGdvdG8gZXJyb3JfdW5tYXBfbWVtOwotICAgICAgICB9Ci0gICAgICAg IGRiZyAoIERCR19QQ0ksImtlcm5lbCBtZW0gJXAsIGN0bG1lbSAlcFxuIiwgY2FyZC0+bWVtLCBj YXJkLT5jdGxtZW0pOwotCi0gICAgICAgIC8qIFJlc2V0IHRoZSBjYXJkJ3MgcHJvY2Vzc29yICov Ci0gICAgICAgIGZzdF9jcHVyZXNldCAoIGNhcmQgKTsKLSAgICAgICAgY2FyZC0+c3RhdGUgPSBG U1RfUkVTRVQ7Ci0KLSAgICAgICAgLyogUmVnaXN0ZXIgdGhlIGludGVycnVwdCBoYW5kbGVyICov Ci0gICAgICAgIGlmICggcmVxdWVzdF9pcnEgKCBjYXJkLT5pcnEsIGZzdF9pbnRyLCBTQV9TSElS USwgRlNUX0RFVl9OQU1FLCBjYXJkICkpCi0gICAgICAgIHsKLQotICAgICAgICAgICAgICAgIHBy aW50a19lcnIgKCJVbmFibGUgdG8gcmVnaXN0ZXIgaW50ZXJydXB0ICVkXG4iLCBjYXJkLT5pcnEg KTsKLSAgICAgICAgICAgICAgICBlcnIgPSAtRU5PREVWOwotICAgICAgICAgICAgICAgIGdvdG8g ZXJyb3JfdW5tYXBfY3RsbWVtOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogUmVjb3JkIGRyaXZl ciBkYXRhIGZvciBsYXRlciB1c2UgKi8KLSAgICAgICAgcGNpX3NldF9kcnZkYXRhKHBkZXYsIGNh cmQpOwotCi0gICAgICAgIC8qIFJlbWFpbmRlciBvZiBjYXJkIHNldHVwICovCi0gICAgICAgIGZz dF9pbml0X2NhcmQgKCBjYXJkICk7Ci0KLSAgICAgICAgcmV0dXJuIDA7ICAgICAgICAgICAgICAg ICAgICAgICAvKiBTdWNjZXNzICovCi0KLQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC8qIEZhaWx1cmUuIFJlbGVhc2UgcmVzb3VyY2VzICovCi1lcnJvcl91bm1hcF9j dGxtZW06Ci0gICAgICAgIGlvdW5tYXAgKCBjYXJkLT5jdGxtZW0gKTsKLQotZXJyb3JfdW5tYXBf bWVtOgotICAgICAgICBpb3VubWFwICggY2FyZC0+bWVtICk7Ci0KLWVycm9yX3JlbGVhc2VfY3Rs bWVtOgotICAgICAgICByZWxlYXNlX21lbV9yZWdpb24gKCBjYXJkLT5waHlzX2N0bG1lbSwgMHgx MCApOwotCi1lcnJvcl9yZWxlYXNlX21lbToKLSAgICAgICAgcmVsZWFzZV9tZW1fcmVnaW9uICgg Y2FyZC0+cGh5c19tZW0sIEZTVF9NRU1TSVpFICk7Ci0KLWVycm9yX3JlbGVhc2VfaW86Ci0gICAg ICAgIHJlbGVhc2VfcmVnaW9uICggY2FyZC0+cGNpX2NvbmYsIDB4ODAgKTsKLQotZXJyb3JfZnJl ZV9wb3J0czoKLQlmb3IgKGkgPSAwOyBpIDwgY2FyZC0+bnBvcnRzOyBpKyspCi0JCWZyZWVfbmV0 ZGV2KGNhcmQtPnBvcnRzW2ldLmRldik7Ci1lcnJvcl9mcmVlX2NhcmQ6Ci0gICAgICAgIGtmcmVl ICggY2FyZCApOwotICAgICAgICByZXR1cm4gZXJyOwotfQorCWNhcmQtPmRldmljZSA9IHBkZXY7 CiAKKwlkYmcoREJHX1BDSSwgInR5cGUgJWQgbnBvcnRzICVkIGlycSAlZFxuIiwgY2FyZC0+dHlw ZSwKKwkgICAgY2FyZC0+bnBvcnRzLCBjYXJkLT5pcnEpOworCWRiZyhEQkdfUENJLCAiY29uZiAl MDR4IG1lbSAlMDh4IGN0bG1lbSAlMDh4XG4iLAorCSAgICBjYXJkLT5wY2lfY29uZiwgY2FyZC0+ cGh5c19tZW0sIGNhcmQtPnBoeXNfY3RsbWVtKTsKKworCS8qIFJlc2V0IHRoZSBjYXJkJ3MgcHJv Y2Vzc29yICovCisJZnN0X2NwdXJlc2V0KGNhcmQpOworCWNhcmQtPnN0YXRlID0gRlNUX1JFU0VU OworCisJLyogSW5pdGlhbGlzZSBETUEgKGlmIHJlcXVpcmVkKSAqLworCWZzdF9pbml0X2RtYShj YXJkKTsKKworCS8qIFJlY29yZCBkcml2ZXIgZGF0YSBmb3IgbGF0ZXIgdXNlICovCisJcGNpX3Nl dF9kcnZkYXRhKHBkZXYsIGNhcmQpOworCisJLyogUmVtYWluZGVyIG9mIGNhcmQgc2V0dXAgKi8K Kwlmc3RfY2FyZF9hcnJheVtub19vZl9jYXJkc19hZGRlZF0gPSBjYXJkOworCWNhcmQtPmNhcmRf bm8gPSBub19vZl9jYXJkc19hZGRlZCsrOwkvKiBSZWNvcmQgaW5zdGFuY2UgYW5kIGJ1bXAgaXQg Ki8KKwlmc3RfaW5pdF9jYXJkKGNhcmQpOworCWlmIChjYXJkLT5mYW1pbHkgPT0gRlNUX0ZBTUlM WV9UWFUpIHsKKwkJLyoKKwkJICogQWxsb2NhdGUgYSBkbWEgYnVmZmVyIGZvciB0cmFuc21pdCBh bmQgcmVjZWl2ZXMKKwkJICovCisJCWNhcmQtPnJ4X2RtYV9oYW5kbGVfaG9zdCA9CisJCSAgICBw Y2lfYWxsb2NfY29uc2lzdGVudChjYXJkLT5kZXZpY2UsIEZTVF9NQVhfTVRVLAorCQkJCQkgJmNh cmQtPnJ4X2RtYV9oYW5kbGVfY2FyZCk7CisJCWlmIChjYXJkLT5yeF9kbWFfaGFuZGxlX2hvc3Qg PT0gTlVMTCkgeworCQkJcHJpbnRrX2VycigiQ291bGQgbm90IGFsbG9jYXRlIHJ4IGRtYSBidWZm ZXJcbiIpOworCQkJZnN0X2Rpc2FibGVfaW50cihjYXJkKTsKKwkJCXBjaV9yZWxlYXNlX3JlZ2lv bnMocGRldik7CisJCQlwY2lfZGlzYWJsZV9kZXZpY2UocGRldik7CisJCQlpb3VubWFwKGNhcmQt PmN0bG1lbSk7CisJCQlpb3VubWFwKGNhcmQtPm1lbSk7CisJCQlrZnJlZShjYXJkKTsKKwkJCXJl dHVybiAtRU5PTUVNOworCQl9CisJCWNhcmQtPnR4X2RtYV9oYW5kbGVfaG9zdCA9CisJCSAgICBw Y2lfYWxsb2NfY29uc2lzdGVudChjYXJkLT5kZXZpY2UsIEZTVF9NQVhfTVRVLAorCQkJCQkgJmNh cmQtPnR4X2RtYV9oYW5kbGVfY2FyZCk7CisJCWlmIChjYXJkLT50eF9kbWFfaGFuZGxlX2hvc3Qg PT0gTlVMTCkgeworCQkJcHJpbnRrX2VycigiQ291bGQgbm90IGFsbG9jYXRlIHR4IGRtYSBidWZm ZXJcbiIpOworCQkJZnN0X2Rpc2FibGVfaW50cihjYXJkKTsKKwkJCXBjaV9yZWxlYXNlX3JlZ2lv bnMocGRldik7CisJCQlwY2lfZGlzYWJsZV9kZXZpY2UocGRldik7CisJCQlpb3VubWFwKGNhcmQt PmN0bG1lbSk7CisJCQlpb3VubWFwKGNhcmQtPm1lbSk7CisJCQlrZnJlZShjYXJkKTsKKwkJCXJl dHVybiAtRU5PTUVNOworCQl9CisJfQorCXJldHVybiAwOwkJLyogU3VjY2VzcyAqLworfQogCiAv KgogICogICAgICBDbGVhbnVwIGFuZCBjbG9zZSBkb3duIGEgY2FyZAogICovCiBzdGF0aWMgdm9p ZCBfX2RldmV4aXQKLWZzdF9yZW1vdmVfb25lICggc3RydWN0IHBjaV9kZXYgKnBkZXYgKQorZnN0 X3JlbW92ZV9vbmUoc3RydWN0IHBjaV9kZXYgKnBkZXYpCiB7Ci0gICAgICAgIHN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkOwotICAgICAgICBpbnQgaTsKKwlzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAq Y2FyZDsKKwlpbnQgaTsKIAotICAgICAgICBjYXJkID0gcGNpX2dldF9kcnZkYXRhKHBkZXYpOwor CWNhcmQgPSBwY2lfZ2V0X2RydmRhdGEocGRldik7CiAKLSAgICAgICAgZm9yICggaSA9IDAgOyBp IDwgY2FyZC0+bnBvcnRzIDsgaSsrICkKLSAgICAgICAgeworCWZvciAoaSA9IDA7IGkgPCBjYXJk LT5ucG9ydHM7IGkrKykgewogCQlzdHJ1Y3QgbmV0X2RldmljZSAqZGV2ID0gcG9ydF90b19kZXYo JmNhcmQtPnBvcnRzW2ldKTsKLSAgICAgICAgICAgICAgICB1bnJlZ2lzdGVyX2hkbGNfZGV2aWNl KGRldik7Ci0gICAgICAgIH0KLQotICAgICAgICBmc3RfZGlzYWJsZV9pbnRyICggY2FyZCApOwot ICAgICAgICBmcmVlX2lycSAoIGNhcmQtPmlycSwgY2FyZCApOwotCi0gICAgICAgIGlvdW5tYXAg KCBjYXJkLT5jdGxtZW0gKTsKLSAgICAgICAgaW91bm1hcCAoIGNhcmQtPm1lbSApOwotCi0gICAg ICAgIHJlbGVhc2VfbWVtX3JlZ2lvbiAoIGNhcmQtPnBoeXNfY3RsbWVtLCAweDEwICk7Ci0gICAg ICAgIHJlbGVhc2VfbWVtX3JlZ2lvbiAoIGNhcmQtPnBoeXNfbWVtLCBGU1RfTUVNU0laRSApOwot ICAgICAgICByZWxlYXNlX3JlZ2lvbiAoIGNhcmQtPnBjaV9jb25mLCAweDgwICk7CisJCXVucmVn aXN0ZXJfaGRsY19kZXZpY2UoZGV2KTsKKwl9CiAKLQlmb3IgKGkgPSAwOyBpIDwgY2FyZC0+bnBv cnRzOyBpKyspCi0JCWZyZWVfbmV0ZGV2KGNhcmQtPnBvcnRzW2ldLmRldik7CisJZnN0X2Rpc2Fi bGVfaW50cihjYXJkKTsKKwlmcmVlX2lycShjYXJkLT5pcnEsIGNhcmQpOwogCi0gICAgICAgIGtm cmVlICggY2FyZCApOworCWlvdW5tYXAoY2FyZC0+Y3RsbWVtKTsKKwlpb3VubWFwKGNhcmQtPm1l bSk7CisJcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2KTsKKwlpZiAoY2FyZC0+ZmFtaWx5ID09IEZT VF9GQU1JTFlfVFhVKSB7CisJCS8qCisJCSAqIEZyZWUgZG1hIGJ1ZmZlcnMKKwkJICovCisJCXBj aV9mcmVlX2NvbnNpc3RlbnQoY2FyZC0+ZGV2aWNlLCBGU1RfTUFYX01UVSwKKwkJCQkgICAgY2Fy ZC0+cnhfZG1hX2hhbmRsZV9ob3N0LAorCQkJCSAgICBjYXJkLT5yeF9kbWFfaGFuZGxlX2NhcmQp OworCQlwY2lfZnJlZV9jb25zaXN0ZW50KGNhcmQtPmRldmljZSwgRlNUX01BWF9NVFUsCisJCQkJ ICAgIGNhcmQtPnR4X2RtYV9oYW5kbGVfaG9zdCwKKwkJCQkgICAgY2FyZC0+dHhfZG1hX2hhbmRs ZV9jYXJkKTsKKwl9CisJZnN0X2NhcmRfYXJyYXlbY2FyZC0+Y2FyZF9ub10gPSBOVUxMOwogfQog CiBzdGF0aWMgc3RydWN0IHBjaV9kcml2ZXIgZnN0X2RyaXZlciA9IHsKQEAgLTE3MDAsMTUgKzI2 OTMsMjAgQEAKIHN0YXRpYyBpbnQgX19pbml0CiBmc3RfaW5pdCh2b2lkKQogewotICAgICAgICBy ZXR1cm4gcGNpX21vZHVsZV9pbml0ICggJmZzdF9kcml2ZXIgKTsKKwlpbnQgaTsKKworCWZvciAo aSA9IDA7IGkgPCBGU1RfTUFYX0NBUkRTOyBpKyspCisJCWZzdF9jYXJkX2FycmF5W2ldID0gTlVM TDsKKwlzcGluX2xvY2tfaW5pdCgmZnN0X3dvcmtfcV9sb2NrKTsKKwlyZXR1cm4gcGNpX21vZHVs ZV9pbml0KCZmc3RfZHJpdmVyKTsKIH0KIAogc3RhdGljIHZvaWQgX19leGl0CiBmc3RfY2xlYW51 cF9tb2R1bGUodm9pZCkKIHsKLSAgICAgICAgcGNpX3VucmVnaXN0ZXJfZHJpdmVyICggJmZzdF9k cml2ZXIgKTsKKwlwcmludGtfaW5mbygiRmFyU3luYyBXQU4gZHJpdmVyIHVubG9hZGluZ1xuIik7 CisJcGNpX3VucmVnaXN0ZXJfZHJpdmVyKCZmc3RfZHJpdmVyKTsKIH0KIAotbW9kdWxlX2luaXQg KCBmc3RfaW5pdCApOwotbW9kdWxlX2V4aXQgKCBmc3RfY2xlYW51cF9tb2R1bGUgKTsKLQorbW9k dWxlX2luaXQoZnN0X2luaXQpOworbW9kdWxlX2V4aXQoZnN0X2NsZWFudXBfbW9kdWxlKTsKZGlm ZiAtdXJOIGxpbnV4LTIuNi40LXByZTEtb3JpZy9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5oIGxp bnV4L2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmgKLS0tIGxpbnV4LTIuNi40LXByZTEtb3JpZy9k cml2ZXJzL25ldC93YW4vZmFyc3luYy5oCTIwMDQtMDMtMDEgMDk6MTc6MDguMDAwMDAwMDAwICsw MDAwCisrKyBsaW51eC9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5oCTIwMDQtMDMtMDEgMDk6MjU6 MjUuMDAwMDAwMDAwICswMDAwCkBAIC0zMiw4ICszMiwxMyBAQAogICogICAgICBBIHNob3J0IGNv bW1vbiBwcmVmaXggaXMgdXNlZnVsIGZvciByb3V0aW5lcyB3aXRoaW4gdGhlIGRyaXZlciB0byBh dm9pZAogICogICAgICBjb25mbGljdCB3aXRoIG90aGVyIHNpbWlsYXIgZHJpdmVycyBhbmQgSSBj aG9zZW4gdG8gdXNlICJmc3RfIiBmb3IgdGhpcwogICogICAgICBwdXJwb3NlIChGYXJTaXRlIFQt c2VyaWVzKS4KKyAqCisgKiAgICAgIEZpbmFsbHkgdGhlIGRldmljZSBkcml2ZXIgbmVlZHMgYSBz aG9ydCBuZXR3b3JrIGludGVyZmFjZSBuYW1lLiBTaW5jZQorICogICAgICAiaGRsYyIgaXMgYWxy ZWFkeSBpbiB1c2UgSSd2ZSBjaG9zZW4gdGhlIGV2ZW4gbGVzcyBpbmZvcm1hdGl2ZSAic3luYyIK KyAqICAgICAgZm9yIHRoZSBwcmVzZW50LgogICovCiAjZGVmaW5lIEZTVF9OQU1FICAgICAgICAg ICAgICAgICJmc3QiICAgICAgICAgICAvKiBJbiBkZWJ1Zy9pbmZvIGV0YyAqLworI2RlZmluZSBG U1RfTkRFVl9OQU1FICAgICAgICAgICAic3luYyIgICAgICAgICAgLyogRm9yIG5ldCBpbnRlcmZh Y2UgKi8KICNkZWZpbmUgRlNUX0RFVl9OQU1FICAgICAgICAgICAgImZhcnN5bmMiICAgICAgIC8q IEZvciBtaXNjIGludGVyZmFjZXMgKi8KIAogCkBAIC00NSw3ICs1MCw3IEBACiAgKiAgICAgIGhh dmUgaW5kaXZpZHVhbCB2ZXJzaW9ucyAob3IgSURzKSB0aGF0IG1vdmUgbXVjaCBmYXN0ZXIgdGhh biB0aGUKICAqICAgICAgdGhlIHJlbGVhc2UgdmVyc2lvbiBhcyBpbmRpdmlkdWFsIHVwZGF0ZXMg YXJlIHRyYWNrZWQuCiAgKi8KLSNkZWZpbmUgRlNUX1VTRVJfVkVSU0lPTiAgICAgICAgIjAuMDki CisjZGVmaW5lIEZTVF9VU0VSX1ZFUlNJT04gICAgICAgICIxLjA0IgogCiAKIC8qICAgICAgSW9j dGwgY2FsbCBjb21tYW5kIHZhbHVlcwpAQCAtMTAwLDYgKzEwNSw3IEBACiAgICAgICAgIHVuc2ln bmVkIGludCAgIHN0YXRlOyAgICAgICAgICAgLyogU3RhdGUgb2YgY2FyZCAqLwogICAgICAgICB1 bnNpZ25lZCBpbnQgICBpbmRleDsgICAgICAgICAgIC8qIEluZGV4IG9mIHBvcnQgaW9jdGwgd2Fz IGlzc3VlZCBvbiAqLwogICAgICAgICB1bnNpZ25lZCBpbnQgICBzbWNGaXJtd2FyZVZlcnNpb247 CisgICAgICAgIHVuc2lnbmVkIGxvbmcgIGtlcm5lbFZlcnNpb247ICAgLyogV2hhdCBLZXJuZWwg dmVyc2lvbiB3ZSBhcmUgd29ya2luZyB3aXRoICovCiAgICAgICAgIHVuc2lnbmVkIHNob3J0IGxp bmVJbnRlcmZhY2U7ICAgLyogUGh5c2ljYWwgaW50ZXJmYWNlIHR5cGUgKi8KICAgICAgICAgdW5z aWduZWQgY2hhciAgcHJvdG87ICAgICAgICAgICAvKiBMaW5lIHByb3RvY29sICovCiAgICAgICAg IHVuc2lnbmVkIGNoYXIgIGludGVybmFsQ2xvY2s7ICAgLyogMSA9PiBpbnRlcm5hbCBjbG9jaywg MCA9PiBleHRlcm5hbCAqLwpAQCAtMTEwLDYgKzExNiwzMSBAQAogICAgICAgICB1bnNpZ25lZCBz aG9ydCBjYWJsZVN0YXR1czsgICAgIC8qIGxzYjogMD0+IHByZXNlbnQsIDE9PiBhYnNlbnQgKi8K ICAgICAgICAgdW5zaWduZWQgc2hvcnQgY2FyZE1vZGU7ICAgICAgICAvKiBsc2I6IExFRCBpZCBt b2RlICovCiAgICAgICAgIHVuc2lnbmVkIHNob3J0IGRlYnVnOyAgICAgICAgICAgLyogRGVidWcg ZmxhZ3MgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgdHJhbnNwYXJlbnRNb2RlOyAvKiBOb3Qg dXNlZCBhbHdheXMgMCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBpbnZlcnRDbG9jazsgICAg IC8qIEludmVydCBjbG9jayBmZWF0dXJlIGZvciBzeW5jaW5nICovCisgICAgICAgIHVuc2lnbmVk IGNoYXIgIHN0YXJ0aW5nU2xvdDsgICAgLyogVGltZSBzbG90IHRvIHVzZSBmb3Igc3RhcnQgb2Yg dHggKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgY2xvY2tTb3VyY2U7ICAgICAvKiBFeHRlcm5h bCBvciBpbnRlcm5hbCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBmcmFtaW5nOyAgICAgICAg IC8qIEUxLCBUMSBvciBKMSAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBzdHJ1Y3R1cmU7ICAg ICAgIC8qIHVuZnJhbWVkLCBkb3VibGUsIGNyYzQsIGY0LCBmMTIsICovCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogZjI0IGY3MiAqLworICAgICAgICB1bnNpZ25l ZCBjaGFyICBpbnRlcmZhY2U7ICAgICAgIC8qIHJqNDhjIG9yIGJuYyAqLworICAgICAgICB1bnNp Z25lZCBjaGFyICBjb2Rpbmc7ICAgICAgICAgIC8qIGhkYjMgYjh6cyAqLworICAgICAgICB1bnNp Z25lZCBjaGFyICBsaW5lQnVpbGRPdXQ7ICAgIC8qIDAsIC03LjUsIC0xNSwgLTIyICovCisgICAg ICAgIHVuc2lnbmVkIGNoYXIgIGVxdWFsaXplcjsgICAgICAgLyogc2hvcnQgb3IgbG9uIGhhdWwg c2V0dGluZ3MgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgbG9vcE1vZGU7ICAgICAgICAvKiB2 YXJpb3VzIGxvb3BiYWNrcyAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICByYW5nZTsgICAgICAg ICAgIC8qIGNhYmxlIGxlbmd0aHMgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgdHhCdWZmZXJN b2RlOyAgICAvKiB0eCBlbGFzdGljIGJ1ZmZlciBkZXB0aCAqLworICAgICAgICB1bnNpZ25lZCBj aGFyICByeEJ1ZmZlck1vZGU7ICAgIC8qIHJ4IGVsYXN0aWMgYnVmZmVyIGRlcHRoICovCisgICAg ICAgIHVuc2lnbmVkIGNoYXIgIGxvc1RocmVzaG9sZDsgICAgLyogQXR0ZW51YXRpb24gb24gTE9T IHNpZ25hbCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBpZGxlQ29kZTsgICAgICAgIC8qIFZh bHVlIHRvIHNlbmQgYXMgaWRsZSB0aW1lc2xvdCAqLworICAgICAgICB1bnNpZ25lZCBpbnQgICBy ZWNlaXZlQnVmZmVyRGVsYXk7IC8qIGRlbGF5IHRocm8gcnggYnVmZmVyIHRpbWVzbG90cyAqLwor ICAgICAgICB1bnNpZ25lZCBpbnQgICBmcmFtaW5nRXJyb3JDb3VudDsgLyogZnJhbWluZyBlcnJv cnMgKi8KKyAgICAgICAgdW5zaWduZWQgaW50ICAgY29kZVZpb2xhdGlvbkNvdW50OyAvKiBjb2Rl IHZpb2xhdGlvbnMgKi8KKyAgICAgICAgdW5zaWduZWQgaW50ICAgY3JjRXJyb3JDb3VudDsgICAv KiBDUkMgZXJyb3JzICovCisgICAgICAgIGludCAgICAgICAgICAgIGxpbmVBdHRlbnVhdGlvbjsg LyogaW4gZEIqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBsb3NzT2ZTaWduYWw7CisgICAgICAg IHVuc2lnbmVkIHNob3J0IHJlY2VpdmVSZW1vdGVBbGFybTsKKyAgICAgICAgdW5zaWduZWQgc2hv cnQgYWxhcm1JbmRpY2F0aW9uU2lnbmFsOwogfTsKIAogLyogInZhbGlkIiBiaXRtYXNrICovCkBA IC0xMzEsMTMgKzE2MiwyMyBAQAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqLwogI2RlZmluZSBGU1RWQUxfUFJPVE8gICAgMHgwMDAwMDIwMCAgICAgIC8qIHByb3Rv ICovCiAjZGVmaW5lIEZTVFZBTF9NT0RFICAgICAweDAwMDAwNDAwICAgICAgLyogY2FyZE1vZGUg Ki8KKyNkZWZpbmUgRlNUVkFMX1BIQVNFICAgIDB4MDAwMDA4MDAgICAgICAvKiBDbG9jayBwaGFz ZSAqLworI2RlZmluZSBGU1RWQUxfVEUxICAgICAgMHgwMDAwMTAwMCAgICAgIC8qIFQxRTEgQ29u ZmlndXJhdGlvbiAqLwogI2RlZmluZSBGU1RWQUxfREVCVUcgICAgMHg4MDAwMDAwMCAgICAgIC8q IGRlYnVnICovCi0jZGVmaW5lIEZTVFZBTF9BTEwgICAgICAweDAwMDAwN0ZGICAgICAgLyogTm90 ZTogZG9lcyBub3QgaW5jbHVkZSBERUJVRyBmbGFnICovCisjZGVmaW5lIEZTVFZBTF9BTEwgICAg ICAweDAwMDAxRkZGICAgICAgLyogTm90ZTogZG9lcyBub3QgaW5jbHVkZSBERUJVRyBmbGFnICov CiAKIC8qICJ0eXBlIiAqLwogI2RlZmluZSBGU1RfVFlQRV9OT05FICAgMCAgICAgICAgICAgICAg IC8qIFByb2JhYmx5IHNob3VsZCBuZXZlciBoYXBwZW4gKi8KICNkZWZpbmUgRlNUX1RZUEVfVDJQ ICAgIDEgICAgICAgICAgICAgICAvKiBUMlAgWDIxIDIgcG9ydCBjYXJkICovCiAjZGVmaW5lIEZT VF9UWVBFX1Q0UCAgICAyICAgICAgICAgICAgICAgLyogVDRQIFgyMSA0IHBvcnQgY2FyZCAqLwor I2RlZmluZSBGU1RfVFlQRV9UMVUgICAgMyAgICAgICAgICAgICAgIC8qIFQxVSBYMjEgMSBwb3J0 IGNhcmQgKi8KKyNkZWZpbmUgRlNUX1RZUEVfVDJVICAgIDQgICAgICAgICAgICAgICAvKiBUMlUg WDIxIDIgcG9ydCBjYXJkICovCisjZGVmaW5lIEZTVF9UWVBFX1Q0VSAgICA1ICAgICAgICAgICAg ICAgLyogVDRVIFgyMSA0IHBvcnQgY2FyZCAqLworI2RlZmluZSBGU1RfVFlQRV9URTEgICAgNiAg ICAgICAgICAgICAgIC8qIFQxRTEgWDIxIDEgcG9ydCBjYXJkICovCisKKy8qICJmYW1pbHkiICov CisjZGVmaW5lIEZTVF9GQU1JTFlfVFhQICAwICAgICAgICAgICAgICAgLyogVDJQIG9yIFQ0UCAq LworI2RlZmluZSBGU1RfRkFNSUxZX1RYVSAgMSAgICAgICAgICAgICAgIC8qIFQxVSBvciBUMlUg b3IgVDRVICovCiAKIC8qICJzdGF0ZSIgKi8KICNkZWZpbmUgRlNUX1VOSU5JVCAgICAgIDAgICAg ICAgICAgICAgICAvKiBSYXcgdW5pbml0aWFsaXNlZCBzdGF0ZSBmb2xsb3dpbmcKQEAgLTE1NSw2 ICsxOTYsMTAgQEAKICNkZWZpbmUgVjI0ICAgICAgICAgICAgIDEKICNkZWZpbmUgWDIxICAgICAg ICAgICAgIDIKICNkZWZpbmUgVjM1ICAgICAgICAgICAgIDMKKyNkZWZpbmUgWDIxRCAgICAgICAg ICAgIDQKKyNkZWZpbmUgVDEgICAgICAgICAgICAgIDUKKyNkZWZpbmUgRTEgICAgICAgICAgICAg IDYKKyNkZWZpbmUgSjEgICAgICAgICAgICAgIDcKIAogLyogInByb3RvIiAqLwogI2RlZmluZSBG U1RfSERMQyAgICAgICAgMSAgICAgICAgICAgICAgIC8qIENpc2NvIGNvbXBhdGlibGUgSERMQyAq LwpAQCAtMTg3LDYgKzIzMiw5NyBAQAogLyogImNhcmRNb2RlIiBiaXRtYXNrICovCiAjZGVmaW5l IENBUkRfTU9ERV9JREVOVElGWSAgICAgIDB4MDAwMQogCisvKiAKKyAqIENvbnN0YW50cyBmb3Ig VDEvRTEgY29uZmlndXJhdGlvbgorICovCisKKy8qCisgKiBDbG9jayBzb3VyY2UKKyAqLworI2Rl ZmluZSBDTE9DS0lOR19TTEFWRSAgICAgICAwCisjZGVmaW5lIENMT0NLSU5HX01BU1RFUiAgICAg IDEKKworLyoKKyAqIEZyYW1pbmcKKyAqLworI2RlZmluZSBGUkFNSU5HX0UxICAgICAgICAgICAw CisjZGVmaW5lIEZSQU1JTkdfSjEgICAgICAgICAgIDEKKyNkZWZpbmUgRlJBTUlOR19UMSAgICAg ICAgICAgMgorCisvKgorICogU3RydWN0dXJlCisgKi8KKyNkZWZpbmUgU1RSVUNUVVJFX1VORlJB TUVEICAgMAorI2RlZmluZSBTVFJVQ1RVUkVfRTFfRE9VQkxFICAxCisjZGVmaW5lIFNUUlVDVFVS RV9FMV9DUkM0ICAgIDIKKyNkZWZpbmUgU1RSVUNUVVJFX0UxX0NSQzRNICAgMworI2RlZmluZSBT VFJVQ1RVUkVfVDFfNCAgICAgICA0CisjZGVmaW5lIFNUUlVDVFVSRV9UMV8xMiAgICAgIDUKKyNk ZWZpbmUgU1RSVUNUVVJFX1QxXzI0ICAgICAgNgorI2RlZmluZSBTVFJVQ1RVUkVfVDFfNzIgICAg ICA3CisKKy8qCisgKiBJbnRlcmZhY2UKKyAqLworI2RlZmluZSBJTlRFUkZBQ0VfUko0OEMgICAg ICAwCisjZGVmaW5lIElOVEVSRkFDRV9CTkMgICAgICAgIDEKKworLyoKKyAqIENvZGluZworICov CisKKyNkZWZpbmUgQ09ESU5HX0hEQjMgICAgICAgICAgMAorI2RlZmluZSBDT0RJTkdfTlJaICAg ICAgICAgICAxCisjZGVmaW5lIENPRElOR19DTUkgICAgICAgICAgIDIKKyNkZWZpbmUgQ09ESU5H X0NNSV9IREIzICAgICAgMworI2RlZmluZSBDT0RJTkdfQ01JX0I4WlMgICAgICA0CisjZGVmaW5l IENPRElOR19BTUkgICAgICAgICAgIDUKKyNkZWZpbmUgQ09ESU5HX0FNSV9aQ1MgICAgICAgNgor I2RlZmluZSBDT0RJTkdfQjhaUyAgICAgICAgICA3CisKKy8qCisgKiBMaW5lIEJ1aWxkIE91dAor ICovCisjZGVmaW5lIExCT18wZEIgICAgICAgICAgICAgIDAKKyNkZWZpbmUgTEJPXzdkQjUgICAg ICAgICAgICAgMQorI2RlZmluZSBMQk9fMTVkQiAgICAgICAgICAgICAyCisjZGVmaW5lIExCT18y MmRCNSAgICAgICAgICAgIDMKKworLyoKKyAqIFJhbmdlIGZvciBsb25nIGhhdWwgdDEgPiA2NTVm dAorICovCisjZGVmaW5lIFJBTkdFXzBfMTMzX0ZUICAgICAgIDAKKyNkZWZpbmUgUkFOR0VfMF80 MF9NICAgICAgICAgUkFOR0VfMF8xMzNfRlQKKyNkZWZpbmUgUkFOR0VfMTMzXzI2Nl9GVCAgICAg MQorI2RlZmluZSBSQU5HRV80MF84MV9NICAgICAgICBSQU5HRV8xMzNfMjY2X0ZUCisjZGVmaW5l IFJBTkdFXzI2Nl8zOTlfRlQgICAgIDIKKyNkZWZpbmUgUkFOR0VfODFfMTIyX00gICAgICAgUkFO R0VfMjY2XzM5OV9GVAorI2RlZmluZSBSQU5HRV8zOTlfNTMzX0ZUICAgICAzCisjZGVmaW5lIFJB TkdFXzEyMl8xNjJfTSAgICAgICBSQU5HRV8zOTlfNTMzX0ZUCisjZGVmaW5lIFJBTkdFXzUzM182 NTVfRlQgICAgIDQKKyNkZWZpbmUgUkFOR0VfMTYyXzIwMF9NICAgICAgUkFOR0VfNTMzXzY1NV9G VAorLyoKKyAqIFJlY2VpdmUgRXF1YWxpc2VyCisgKi8KKyNkZWZpbmUgRVFVQUxJWkVSX1NIT1JU ICAgICAgMAorI2RlZmluZSBFUVVBTElaRVJfTE9ORyAgICAgICAxCisKKy8qCisgKiBMb29wIG1v ZGVzCisgKi8KKyNkZWZpbmUgTE9PUF9OT05FICAgICAgICAgICAgMAorI2RlZmluZSBMT09QX0xP Q0FMICAgICAgICAgICAxCisjZGVmaW5lIExPT1BfUEFZTE9BRF9FWENfVFMwIDIKKyNkZWZpbmUg TE9PUF9QQVlMT0FEX0lOQ19UUzAgMworI2RlZmluZSBMT09QX1JFTU9URSAgICAgICAgICA0CisK Ky8qCisgKiBCdWZmZXIgbW9kZXMKKyAqLworI2RlZmluZSBCVUZGRVJfMl9GUkFNRSAgICAgICAw CisjZGVmaW5lIEJVRkZFUl8xX0ZSQU1FICAgICAgIDEKKyNkZWZpbmUgQlVGRkVSXzk2X0JJVCAg ICAgICAgMgorI2RlZmluZSBCVUZGRVJfTk9ORSAgICAgICAgICAzCiAKIC8qICAgICAgRGVidWcg c3VwcG9ydAogICoKZGlmZiAtdXJOIGxpbnV4LTIuNi40LXByZTEtb3JpZy9pbmNsdWRlL2xpbnV4 L2lmLmggbGludXgvaW5jbHVkZS9saW51eC9pZi5oCi0tLSBsaW51eC0yLjYuNC1wcmUxLW9yaWcv aW5jbHVkZS9saW51eC9pZi5oCTIwMDQtMDMtMDEgMDk6MTc6MzYuMDAwMDAwMDAwICswMDAwCisr KyBsaW51eC9pbmNsdWRlL2xpbnV4L2lmLmgJMjAwNC0wMy0wMSAwOToyNToyNS4wMDAwMDAwMDAg KzAwMDAKQEAgLTYyLDYgKzYyLDcgQEAKICNkZWZpbmUgSUZfSUZBQ0VfVDEJMHgxMDAzCQkvKiBU MSB0ZWxjbyBzZXJpYWwgaW50ZXJmYWNlCSovCiAjZGVmaW5lIElGX0lGQUNFX0UxCTB4MTAwNAkJ LyogRTEgdGVsY28gc2VyaWFsIGludGVyZmFjZQkqLwogI2RlZmluZSBJRl9JRkFDRV9TWU5DX1NF UklBTCAweDEwMDUJLyogY2FuJ3QgYmUgc2V0IGJ5IHNvZnR3YXJlCSovCisjZGVmaW5lIElGX0lG QUNFX1gyMUQgICAweDEwMDYgICAgICAgICAgLyogWC4yMSBEdWFsIENsb2NraW5nIChGYXJTaXRl KSAqLwogCiAvKiBGb3IgZGVmaW5pdGlvbnMgc2VlIGhkbGMuaCAqLwogI2RlZmluZSBJRl9QUk9U T19IRExDCTB4MjAwMAkJLyogcmF3IEhETEMgcHJvdG9jb2wJCSovCkBAIC03Niw2ICs3Nyw3IEBA CiAjZGVmaW5lIElGX1BST1RPX0ZSX0RFTF9FVEhfUFZDIDB4MjAwOQkvKiAgRGVsZXRlIEZSIEV0 aGVybmV0LWJyaWRnZWQgUFZDICovCiAjZGVmaW5lIElGX1BST1RPX0ZSX1BWQwkweDIwMEEJCS8q IGZvciByZWFkaW5nIFBWQyBzdGF0dXMJKi8KICNkZWZpbmUgSUZfUFJPVE9fRlJfRVRIX1BWQyAw eDIwMEIKKyNkZWZpbmUgSUZfUFJPVE9fUkFXICAgIDB4MjAwQyAgICAgICAgICAvKiBSQVcgU29j a2V0ICAgICAgICAgICAgICAgICAgICovCiAKIAogLyoKZGlmZiAtdXJOIGxpbnV4LTIuNi40LXBy ZTEtb3JpZy9pbmNsdWRlL2xpbnV4L3BjaV9pZHMuaCBsaW51eC9pbmNsdWRlL2xpbnV4L3BjaV9p ZHMuaAotLS0gbGludXgtMi42LjQtcHJlMS1vcmlnL2luY2x1ZGUvbGludXgvcGNpX2lkcy5oCTIw MDQtMDMtMDEgMDk6MTc6MzUuMDAwMDAwMDAwICswMDAwCisrKyBsaW51eC9pbmNsdWRlL2xpbnV4 L3BjaV9pZHMuaAkyMDA0LTAzLTAxIDA5OjI1OjI1LjAwMDAwMDAwMCArMDAwMApAQCAtMTg1NCw2 ICsxODU0LDE1IEBACiAjZGVmaW5lIFBDSV9ERVZJQ0VfSURfTUFDUk9MSU5LX01DQ1I4CTB4MjAw MAogI2RlZmluZSBQQ0lfREVWSUNFX0lEX01BQ1JPTElOS19NQ0NSCTB4MjAwMQogCisjZGVmaW5l IFBDSV9WRU5ET1JfSURfRkFSU0lURSAgICAgICAgICAgMHgxNjE5CisjZGVmaW5lIFBDSV9ERVZJ Q0VfSURfRkFSU0lURV9UMlAgICAgICAgMHgwNDAwCisjZGVmaW5lIFBDSV9ERVZJQ0VfSURfRkFS U0lURV9UNFAgICAgICAgMHgwNDQwCisjZGVmaW5lIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9UMVUg ICAgICAgMHgwNjEwCisjZGVmaW5lIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9UMlUgICAgICAgMHgw NjIwCisjZGVmaW5lIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9UNFUgICAgICAgMHgwNjQwCisjZGVm aW5lIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9URTEgICAgICAgMHgxNjEwCisjZGVmaW5lIFBDSV9E RVZJQ0VfSURfRkFSU0lURV9URTFDICAgICAgMHgxNjEyCisKICNkZWZpbmUgUENJX1ZFTkRPUl9J RF9BTFRJTUEJCTB4MTczYgogI2RlZmluZSBQQ0lfREVWSUNFX0lEX0FMVElNQV9BQzEwMDAJMHgw M2U4CiAjZGVmaW5lIFBDSV9ERVZJQ0VfSURfQUxUSU1BX0FDMTAwMQkweDAzZTkK ------_=_NextPart_001_01C42BAC.3CBC71C8 Content-Type: application/octet-stream; name="farsync2.4.patch" Content-Transfer-Encoding: base64 Content-Description: farsync2.4.patch Content-Disposition: attachment; filename="farsync2.4.patch" ZGlmZiAtdXJOIGxpbnV4LTIuNC4yNy1wcmUxL2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmMgbGlu dXgtMi40LjI3LXByZTEtbmV3L2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmMKLS0tIGxpbnV4LTIu NC4yNy1wcmUxL2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmMJMjAwMy0xMS0yOCAxODoyNjoyMC4w MDAwMDAwMDAgKzAwMDAKKysrIGxpbnV4LTIuNC4yNy1wcmUxLW5ldy9kcml2ZXJzL25ldC93YW4v ZmFyc3luYy5jCTIwMDQtMDQtMjYgMTg6NTg6MDMuMDAwMDAwMDAwICswMTAwCkBAIC0xLDkgKzEs OSBAQAogLyoKLSAqICAgICAgRmFyU3luYyBYMjEgZHJpdmVyIGZvciBMaW51eCAoZ2VuZXJpYyBI RExDIHZlcnNpb24pCisgKiAgICAgIEZhclN5bmMgV0FOIGRyaXZlciBmb3IgTGludXggKDIuNC54 IGtlcm5lbCB2ZXJzaW9uKQogICoKICAqICAgICAgQWN0dWFsbHkgc3luYyBkcml2ZXIgZm9yIFgu MjEsIFYuMzUgYW5kIFYuMjQgb24gRmFyU3luYyBULXNlcmllcyBjYXJkcwogICoKLSAqICAgICAg Q29weXJpZ2h0IChDKSAyMDAxIEZhclNpdGUgQ29tbXVuaWNhdGlvbnMgTHRkLgorICogICAgICBD b3B5cmlnaHQgKEMpIDIwMDEtMjAwNCBGYXJTaXRlIENvbW11bmljYXRpb25zIEx0ZC4KICAqICAg ICAgd3d3LmZhcnNpdGUuY28udWsKICAqCiAgKiAgICAgIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNv ZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3IKQEAgLTExLDY2ICsxMSw4MSBA QAogICogICAgICBhcyBwdWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsg ZWl0aGVyIHZlcnNpb24KICAqICAgICAgMiBvZiB0aGUgTGljZW5zZSwgb3IgKGF0IHlvdXIgb3B0 aW9uKSBhbnkgbGF0ZXIgdmVyc2lvbi4KICAqCi0gKiAgICAgIEF1dGhvcjogUi5KLkR1bmxvcCAg ICAgIDxib2IuZHVubG9wQGZhcnNpdGUuY28udWs+CisgKiAgICAgIEF1dGhvcjogICAgICBSLkou RHVubG9wICAgIDxib2IuZHVubG9wQGZhcnNpdGUuY28udWs+CisgKiAgICAgIE1haW50YWluZXI6 ICBLZXZpbiBDdXJ0aXMgIDxrZXZpbi5jdXJ0aXNAZmFyc2l0ZS5jby51az4KICAqLwogCiAjaW5j bHVkZSA8bGludXgvbW9kdWxlLmg+CiAjaW5jbHVkZSA8bGludXgva2VybmVsLmg+CisjaW5jbHVk ZSA8bGludXgvdmVyc2lvbi5oPgogI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgogI2luY2x1ZGUgPGxp bnV4L2lvcG9ydC5oPgogI2luY2x1ZGUgPGxpbnV4L2luaXQuaD4KICNpbmNsdWRlIDxhc20vdWFj Y2Vzcy5oPgogI2luY2x1ZGUgPGxpbnV4L2lmLmg+CiAjaW5jbHVkZSA8bGludXgvaGRsYy5oPgor I2luY2x1ZGUgPGFzbS9kZWxheS5oPgogCiAjaW5jbHVkZSAiZmFyc3luYy5oIgogCi0KIC8qCiAg KiAgICAgIE1vZHVsZSBpbmZvCiAgKi8KIE1PRFVMRV9BVVRIT1IoIlIuSi5EdW5sb3AgPGJvYi5k dW5sb3BAZmFyc2l0ZS5jby51az4iKTsKLU1PRFVMRV9ERVNDUklQVElPTigiRmFyU3luYyBULVNl cmllcyBYMjEgZHJpdmVyLiBGYXJTaXRlIENvbW11bmljYXRpb25zIEx0ZC4iKTsKK01PRFVMRV9E RVNDUklQVElPTigiRmFyU3luYyBULVNlcmllcyBXQU4gZHJpdmVyLiBGYXJTaXRlIENvbW11bmlj YXRpb25zIEx0ZC4iKTsKK01PRFVMRV9QQVJNKGZzdF90eHFfbG93LCAiaSIpOworTU9EVUxFX1BB Uk0oZnN0X3R4cV9oaWdoLCAiaSIpOworTU9EVUxFX1BBUk0oZnN0X21heF9yZWFkcywgImkiKTsK K01PRFVMRV9QQVJNKGZzdF9leGNsdWRlZF9jYXJkcywgImkiKTsKK01PRFVMRV9QQVJNKGZzdF9l eGNsdWRlZF9saXN0LCAiMC0zMmkiKTsKIE1PRFVMRV9MSUNFTlNFKCJHUEwiKTsKIAogRVhQT1JU X05PX1NZTUJPTFM7CiAKLQogLyogICAgICBEcml2ZXIgY29uZmlndXJhdGlvbiBhbmQgZ2xvYmFs IHBhcmFtZXRlcnMKICAqICAgICAgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09CiAgKi8KIAotLyogICAgICBOdW1iZXIgb2YgcG9ydHMgKHBlciBjYXJkKSBzdXBwb3J0 ZWQKKy8qICAgICAgTnVtYmVyIG9mIHBvcnRzIChwZXIgY2FyZCkgYW5kIGNhcmRzIHN1cHBvcnRl ZAogICovCiAjZGVmaW5lIEZTVF9NQVhfUE9SVFMgICAgICAgICAgIDQKLQotCi0vKiAgICAgIFBD SSB2ZW5kb3IgYW5kIGRldmljZSBJRHMKLSAqLwotI2RlZmluZSBGU0NfUENJX1ZFTkRPUl9JRCAg ICAgICAweDE2MTkgIC8qIEZhclNpdGUgQ29tbXVuaWNhdGlvbnMgTHRkICovCi0jZGVmaW5lIFQy UF9QQ0lfREVWSUNFX0lEICAgICAgIDB4MDQwMCAgLyogVDJQIFgyMSAyIHBvcnQgY2FyZCAqLwot I2RlZmluZSBUNFBfUENJX0RFVklDRV9JRCAgICAgICAweDA0NDAgIC8qIFQ0UCBYMjEgNCBwb3J0 IGNhcmQgKi8KLQorI2RlZmluZSBGU1RfTUFYX0NBUkRTICAgICAgICAgICAzMgogCiAvKiAgICAg IERlZmF1bHQgcGFyYW1ldGVycyBmb3IgdGhlIGxpbmsKICAqLwotI2RlZmluZSBGU1RfVFhfUVVF VUVfTEVOICAgICAgICAxMDAgICAgIC8qIEF0IDhNYnBzIGEgbG9uZ2VyIHF1ZXVlIGxlbmd0aCBp cwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIHVzZWZ1bCwgdGhl IHN5bmNwcHAgbW9kdWxlIGZvcmNlcwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqIHRoaXMgZG93biBhc3N1bWluZyBhIHNsb3dlciBsaW5lIEkKLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBndWVzcy4KLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKi8KLSNkZWZpbmUgRlNUX01BWF9NVFUgICAgICAgICAg ICAgODAwMCAgICAvKiBIdWdlIGJ1dCBwb3NzaWJsZSAqLwotI2RlZmluZSBGU1RfREVGX01UVSAg ICAgICAgICAgICAxNTAwICAgIC8qIENvbW1vbiBzYW5lIHZhbHVlICovCisjZGVmaW5lIEZTVF9U WF9RVUVVRV9MRU4gICAgICAgIDEwMAkvKiBBdCA4TWJwcyBhIGxvbmdlciBxdWV1ZSBsZW5ndGgg aXMKKwkJCQkJICogdXNlZnVsLCB0aGUgc3luY3BwcCBtb2R1bGUgZm9yY2VzCisJCQkJCSAqIHRo aXMgZG93biBhc3N1bWluZyBhIHNsb3dlciBsaW5lIEkKKwkJCQkJICogZ3Vlc3MuCisJCQkJCSAq LworI2RlZmluZSBGU1RfVFhRX0RFUFRIICAgICAgICAgICAxNgkvKiBUaGlzIG9uZSBpcyBmb3Ig dGhlIGJ1ZmZlcmluZworCQkJCQkgKiBvZiBmcmFtZXMgb24gdGhlIHdheSBkb3duIHRvIHRoZSBj YXJkCisJCQkJCSAqIHNvIHRoYXQgd2UgY2FuIGtlZXAgdGhlIGNhcmQgYnVzeQorCQkJCQkgKiBh bmQgbWF4aW1pc2UgdGhyb3VnaHB1dAorCQkJCQkgKi8KKyNkZWZpbmUgRlNUX0hJR0hfV0FURVJf TUFSSyAgICAgMTIJLyogUG9pbnQgYXQgd2hpY2ggd2UgZmxvdyBjb250cm9sCisJCQkJCSAqIG5l dHdvcmsgbGF5ZXIgKi8KKyNkZWZpbmUgRlNUX0xPV19XQVRFUl9NQVJLICAgICAgOAkvKiBQb2lu dCBhdCB3aGljaCB3ZSByZW1vdmUgZmxvdworCQkJCQkgKiBjb250cm9sIGZyb20gbmV0d29yayBs YXllciAqLworI2RlZmluZSBGU1RfTUFYX01UVSAgICAgICAgICAgICA4MDAwCS8qIEh1Z2UgYnV0 IHBvc3NpYmxlICovCisjZGVmaW5lIEZTVF9ERUZfTVRVICAgICAgICAgICAgIDE1MDAJLyogQ29t bW9uIHNhbmUgdmFsdWUgKi8KIAogI2RlZmluZSBGU1RfVFhfVElNRU9VVCAgICAgICAgICAoMipI WikKIAotCiAjaWZkZWYgQVJQSFJEX1JBV0hETEMKLSNkZWZpbmUgQVJQSFJEX01ZVFlQRSAgIEFS UEhSRF9SQVdIRExDICAvKiBSYXcgZnJhbWVzICovCisjZGVmaW5lIEFSUEhSRF9NWVRZUEUgICBB UlBIUkRfUkFXSERMQwkvKiBSYXcgZnJhbWVzICovCiAjZWxzZQotI2RlZmluZSBBUlBIUkRfTVlU WVBFICAgQVJQSFJEX0hETEMgICAgIC8qIENpc2NvLUhETEMgKGtlZXBhbGl2ZXMgZXRjKSAqLwor I2RlZmluZSBBUlBIUkRfTVlUWVBFICAgQVJQSFJEX0hETEMJLyogQ2lzY28tSERMQyAoa2VlcGFs aXZlcyBldGMpICovCiAjZW5kaWYKIAorLyoKKyAqIE1vZHVsZXMgcGFyYW1ldGVycyBhbmQgYXNz b2NpYXRlZCB2YXJhaWJsZXMKKyAqLworaW50IGZzdF90eHFfbG93ID0gRlNUX0xPV19XQVRFUl9N QVJLOworaW50IGZzdF90eHFfaGlnaCA9IEZTVF9ISUdIX1dBVEVSX01BUks7CitpbnQgZnN0X21h eF9yZWFkcyA9IDc7CitpbnQgZnN0X2V4Y2x1ZGVkX2NhcmRzID0gMDsKK2ludCBmc3RfZXhjbHVk ZWRfbGlzdFtGU1RfTUFYX0NBUkRTXTsKIAogLyogICAgICBDYXJkIHNoYXJlZCBtZW1vcnkgbGF5 b3V0CiAgKiAgICAgID09PT09PT09PT09PT09PT09PT09PT09PT0KQEAgLTg3LDU4ICsxMDIsNTcg QEAKICAqICAgICAgYmUgdXNlZCB0byBjaGVjayB0aGF0IHdlIGhhdmUgbm90IGdvdCBvdXQgb2Yg c3RlcCB3aXRoIHRoZSBmaXJtd2FyZQogICogICAgICBjb250YWluZWQgaW4gdGhlIC5DREUgZmls ZXMuCiAgKi8KLSNkZWZpbmUgU01DX1ZFUlNJT04gMTEKKyNkZWZpbmUgU01DX1ZFUlNJT04gMjQK IAotI2RlZmluZSBGU1RfTUVNU0laRSAweDEwMDAwMCAgICAvKiBTaXplIG9mIGNhcmQgbWVtb3J5 ICgxTWIpICovCisjZGVmaW5lIEZTVF9NRU1TSVpFIDB4MTAwMDAwCS8qIFNpemUgb2YgY2FyZCBt ZW1vcnkgKDFNYikgKi8KIAotI2RlZmluZSBTTUNfQkFTRSAweDAwMDAyMDAwTCAgICAvKiBCYXNl IG9mZnNldCBvZiB0aGUgc2hhcmVkIG1lbW9yeSB3aW5kb3cgbWFpbgotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKiBjb25maWd1cmF0aW9uIHN0cnVjdHVyZSAqLwotI2RlZmluZSBC Rk1fQkFTRSAweDAwMDEwMDAwTCAgICAvKiBCYXNlIG9mZnNldCBvZiB0aGUgc2hhcmVkIG1lbW9y eSB3aW5kb3cgRE1BCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIGJ1ZmZlcnMg Ki8KKyNkZWZpbmUgU01DX0JBU0UgMHgwMDAwMjAwMEwJLyogQmFzZSBvZmZzZXQgb2YgdGhlIHNo YXJlZCBtZW1vcnkgd2luZG93IG1haW4KKwkJCQkgKiBjb25maWd1cmF0aW9uIHN0cnVjdHVyZSAq LworI2RlZmluZSBCRk1fQkFTRSAweDAwMDEwMDAwTAkvKiBCYXNlIG9mZnNldCBvZiB0aGUgc2hh cmVkIG1lbW9yeSB3aW5kb3cgRE1BCisJCQkJICogYnVmZmVycyAqLwogCi0jZGVmaW5lIExFTl9U WF9CVUZGRVIgODE5MiAgICAgIC8qIFNpemUgb2YgcGFja2V0IGJ1ZmZlcnMgKi8KKyNkZWZpbmUg TEVOX1RYX0JVRkZFUiA4MTkyCS8qIFNpemUgb2YgcGFja2V0IGJ1ZmZlcnMgKi8KICNkZWZpbmUg TEVOX1JYX0JVRkZFUiA4MTkyCiAKLSNkZWZpbmUgTEVOX1NNQUxMX1RYX0JVRkZFUiAyNTYgLyog U2l6ZSBvZiBvYnNvbGV0ZSBidWZmcyB1c2VkIGZvciBET1MgZGlhZ3MgKi8KKyNkZWZpbmUgTEVO X1NNQUxMX1RYX0JVRkZFUiAyNTYJLyogU2l6ZSBvZiBvYnNvbGV0ZSBidWZmcyB1c2VkIGZvciBE T1MgZGlhZ3MgKi8KICNkZWZpbmUgTEVOX1NNQUxMX1JYX0JVRkZFUiAyNTYKIAotI2RlZmluZSBO VU1fVFhfQlVGRkVSIDIgICAgICAgICAvKiBNdXN0IGJlIHBvd2VyIG9mIDIuIEZpeGVkIGJ5IGZp cm13YXJlICovCisjZGVmaW5lIE5VTV9UWF9CVUZGRVIgMgkJLyogTXVzdCBiZSBwb3dlciBvZiAy LiBGaXhlZCBieSBmaXJtd2FyZSAqLwogI2RlZmluZSBOVU1fUlhfQlVGRkVSIDgKIAogLyogSW50 ZXJydXB0IHJldHJ5IHRpbWUgaW4gbWlsbGlzZWNvbmRzICovCiAjZGVmaW5lIElOVF9SRVRSWV9U SU1FIDIKIAotCiAvKiAgICAgIFRoZSBBbTE4NkNIL0NDIHByb2Nlc3NvcnMgc3VwcG9ydCBhIFNt YXJ0RE1BIG1vZGUgdXNpbmcgY2lyY3VsYXIgcG9vbHMKICAqICAgICAgb2YgYnVmZmVyIGRlc2Ny aXB0b3JzLiBUaGUgc3RydWN0dXJlIGlzIGFsbW9zdCBpZGVudGljYWwgdG8gdGhhdCB1c2VkCiAg KiAgICAgIGluIHRoZSBMQU5DRSBFdGhlcm5ldCBjb250cm9sbGVycy4gRGV0YWlscyBhdmFpbGFi bGUgYXMgUERGIGZyb20gdGhlCiAgKiAgICAgIEFNRCB3ZWIgc2l0ZTogaHR0cDovL3d3dy5hbWQu Y29tL3Byb2R1Y3RzL2VwZC9wcm9jZXNzb3JzL1wKICAqICAgICAgICAgICAgICAgICAgICAyLjE2 Yml0Y29udC8zLmFtMTg2Y3hmYS9hMjE5MTQvMjE5MTQucGRmCiAgKi8KLXN0cnVjdCB0eGRlc2Mg eyAgICAgICAgICAgICAgICAgLyogVHJhbnNtaXQgZGVzY3JpcHRvciAqLwotICAgICAgICB2b2xh dGlsZSB1MTYgbGFkcjsgICAgICAvKiBMb3cgb3JkZXIgYWRkcmVzcyBvZiBwYWNrZXQuIFRoaXMg aXMgYQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBsaW5lYXIgYWRkcmVzcyBp biB0aGUgQW0xODYgbWVtb3J5IHNwYWNlCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAqLwotICAgICAgICB2b2xhdGlsZSB1OCAgaGFkcjsgICAgICAvKiBIaWdoIG9yZGVyIGFkZHJl c3MuIExvdyA0IGJpdHMgb25seSwgaGlnaCA0Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAqIGJpdHMgbXVzdCBiZSB6ZXJvCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAqLwotICAgICAgICB2b2xhdGlsZSB1OCAgYml0czsgICAgICAvKiBTdGF0dXMgYW5kIGNvbmZp ZyAqLwotICAgICAgICB2b2xhdGlsZSB1MTYgYmNudDsgICAgICAvKiAycyBjb21wbGVtZW50IG9m IHBhY2tldCBzaXplIGluIGxvdyAxNSBiaXRzLgotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKiBUcmFuc21pdCB0ZXJtaW5hbCBjb3VudCBpbnRlcnJ1cHQgZW5hYmxlIGluCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIHRvcCBiaXQuCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqLwotICAgICAgICAgICAgICAgICB1MTYgdW51c2VkOyAgICAvKiBO b3QgdXNlZCBpbiBUeCAqLworc3RydWN0IHR4ZGVzYyB7CQkJLyogVHJhbnNtaXQgZGVzY3JpcHRv ciAqLworCXZvbGF0aWxlIHUxNiBsYWRyOwkvKiBMb3cgb3JkZXIgYWRkcmVzcyBvZiBwYWNrZXQu IFRoaXMgaXMgYQorCQkJCSAqIGxpbmVhciBhZGRyZXNzIGluIHRoZSBBbTE4NiBtZW1vcnkgc3Bh Y2UKKwkJCQkgKi8KKwl2b2xhdGlsZSB1OCBoYWRyOwkvKiBIaWdoIG9yZGVyIGFkZHJlc3MuIExv dyA0IGJpdHMgb25seSwgaGlnaCA0CisJCQkJICogYml0cyBtdXN0IGJlIHplcm8KKwkJCQkgKi8K Kwl2b2xhdGlsZSB1OCBiaXRzOwkvKiBTdGF0dXMgYW5kIGNvbmZpZyAqLworCXZvbGF0aWxlIHUx NiBiY250OwkvKiAycyBjb21wbGVtZW50IG9mIHBhY2tldCBzaXplIGluIGxvdyAxNSBiaXRzLgor CQkJCSAqIFRyYW5zbWl0IHRlcm1pbmFsIGNvdW50IGludGVycnVwdCBlbmFibGUgaW4KKwkJCQkg KiB0b3AgYml0LgorCQkJCSAqLworCXUxNiB1bnVzZWQ7CQkvKiBOb3QgdXNlZCBpbiBUeCAqLwog fTsKIAotc3RydWN0IHJ4ZGVzYyB7ICAgICAgICAgICAgICAgICAvKiBSZWNlaXZlIGRlc2NyaXB0 b3IgKi8KLSAgICAgICAgdm9sYXRpbGUgdTE2IGxhZHI7ICAgICAgLyogTG93IG9yZGVyIGFkZHJl c3Mgb2YgcGFja2V0ICovCi0gICAgICAgIHZvbGF0aWxlIHU4ICBoYWRyOyAgICAgIC8qIEhpZ2gg b3JkZXIgYWRkcmVzcyAqLwotICAgICAgICB2b2xhdGlsZSB1OCAgYml0czsgICAgICAvKiBTdGF0 dXMgYW5kIGNvbmZpZyAqLwotICAgICAgICB2b2xhdGlsZSB1MTYgYmNudDsgICAgICAvKiAycyBj b21wbGVtZW50IG9mIGJ1ZmZlciBzaXplIGluIGxvdyAxNSBiaXRzLgotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgKiBSZWNlaXZlIHRlcm1pbmFsIGNvdW50IGludGVycnVwdCBlbmFi bGUgaW4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdG9wIGJpdC4KLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCi0gICAgICAgIHZvbGF0aWxlIHUxNiBtY250 OyAgICAgIC8qIE1lc3NhZ2UgYnl0ZSBjb3VudCAoMTUgYml0cykgKi8KK3N0cnVjdCByeGRlc2Mg ewkJCS8qIFJlY2VpdmUgZGVzY3JpcHRvciAqLworCXZvbGF0aWxlIHUxNiBsYWRyOwkvKiBMb3cg b3JkZXIgYWRkcmVzcyBvZiBwYWNrZXQgKi8KKwl2b2xhdGlsZSB1OCBoYWRyOwkvKiBIaWdoIG9y ZGVyIGFkZHJlc3MgKi8KKwl2b2xhdGlsZSB1OCBiaXRzOwkvKiBTdGF0dXMgYW5kIGNvbmZpZyAq LworCXZvbGF0aWxlIHUxNiBiY250OwkvKiAycyBjb21wbGVtZW50IG9mIGJ1ZmZlciBzaXplIGlu IGxvdyAxNSBiaXRzLgorCQkJCSAqIFJlY2VpdmUgdGVybWluYWwgY291bnQgaW50ZXJydXB0IGVu YWJsZSBpbgorCQkJCSAqIHRvcCBiaXQuCisJCQkJICovCisJdm9sYXRpbGUgdTE2IG1jbnQ7CS8q IE1lc3NhZ2UgYnl0ZSBjb3VudCAoMTUgYml0cykgKi8KIH07CiAKIC8qIENvbnZlcnQgYSBsZW5n dGggaW50byB0aGUgMTUgYml0IDIncyBjb21wbGVtZW50ICovCkBAIC0xNDksNTcgKzE2Myw5OSBA QAogI2RlZmluZSBjbnZfYmNudChsZW4pICAgKC0obGVuKSkKIAogLyogU3RhdHVzIGFuZCBjb25m aWcgYml0cyBmb3IgdGhlIGFib3ZlICovCi0jZGVmaW5lIERNQV9PV04gICAgICAgICAweDgwICAg ICAgICAgICAgLyogU21hcnRETUEgb3ducyB0aGUgZGVzY3JpcHRvciAqLwotI2RlZmluZSBUWF9T VFAgICAgICAgICAgMHgwMiAgICAgICAgICAgIC8qIFR4OiBzdGFydCBvZiBwYWNrZXQgKi8KLSNk ZWZpbmUgVFhfRU5QICAgICAgICAgIDB4MDEgICAgICAgICAgICAvKiBUeDogZW5kIG9mIHBhY2tl dCAqLwotI2RlZmluZSBSWF9FUlIgICAgICAgICAgMHg0MCAgICAgICAgICAgIC8qIFJ4OiBlcnJv ciAoT1Igb2YgbmV4dCA0IGJpdHMpICovCi0jZGVmaW5lIFJYX0ZSQU0gICAgICAgICAweDIwICAg ICAgICAgICAgLyogUng6IGZyYW1pbmcgZXJyb3IgKi8KLSNkZWZpbmUgUlhfT0ZMTyAgICAgICAg IDB4MTAgICAgICAgICAgICAvKiBSeDogb3ZlcmZsb3cgZXJyb3IgKi8KLSNkZWZpbmUgUlhfQ1JD ICAgICAgICAgIDB4MDggICAgICAgICAgICAvKiBSeDogQ1JDIGVycm9yICovCi0jZGVmaW5lIFJY X0hCVUYgICAgICAgICAweDA0ICAgICAgICAgICAgLyogUng6IGJ1ZmZlciBlcnJvciAqLwotI2Rl ZmluZSBSWF9TVFAgICAgICAgICAgMHgwMiAgICAgICAgICAgIC8qIFJ4OiBzdGFydCBvZiBwYWNr ZXQgKi8KLSNkZWZpbmUgUlhfRU5QICAgICAgICAgIDB4MDEgICAgICAgICAgICAvKiBSeDogZW5k IG9mIHBhY2tldCAqLwotCisjZGVmaW5lIERNQV9PV04gICAgICAgICAweDgwCS8qIFNtYXJ0RE1B IG93bnMgdGhlIGRlc2NyaXB0b3IgKi8KKyNkZWZpbmUgVFhfU1RQICAgICAgICAgIDB4MDIJLyog VHg6IHN0YXJ0IG9mIHBhY2tldCAqLworI2RlZmluZSBUWF9FTlAgICAgICAgICAgMHgwMQkvKiBU eDogZW5kIG9mIHBhY2tldCAqLworI2RlZmluZSBSWF9FUlIgICAgICAgICAgMHg0MAkvKiBSeDog ZXJyb3IgKE9SIG9mIG5leHQgNCBiaXRzKSAqLworI2RlZmluZSBSWF9GUkFNICAgICAgICAgMHgy MAkvKiBSeDogZnJhbWluZyBlcnJvciAqLworI2RlZmluZSBSWF9PRkxPICAgICAgICAgMHgxMAkv KiBSeDogb3ZlcmZsb3cgZXJyb3IgKi8KKyNkZWZpbmUgUlhfQ1JDICAgICAgICAgIDB4MDgJLyog Ung6IENSQyBlcnJvciAqLworI2RlZmluZSBSWF9IQlVGICAgICAgICAgMHgwNAkvKiBSeDogYnVm ZmVyIGVycm9yICovCisjZGVmaW5lIFJYX1NUUCAgICAgICAgICAweDAyCS8qIFJ4OiBzdGFydCBv ZiBwYWNrZXQgKi8KKyNkZWZpbmUgUlhfRU5QICAgICAgICAgIDB4MDEJLyogUng6IGVuZCBvZiBw YWNrZXQgKi8KIAotLyogSW50ZXJydXB0cyBmcm9tIHRoZSBjYXJkIGFyZSBjYXVzZWQgYnkgdmFy aW91cyBldmVudHMgYW5kIHRoZXNlIGFyZSBwcmVzZW50ZWQKKy8qIEludGVycnVwdHMgZnJvbSB0 aGUgY2FyZCBhcmUgY2F1c2VkIGJ5IHZhcmlvdXMgZXZlbnRzIHdoaWNoIGFyZSBwcmVzZW50ZWQK ICAqIGluIGEgY2lyY3VsYXIgYnVmZmVyIGFzIHNldmVyYWwgZXZlbnRzIG1heSBiZSBwcm9jZXNz ZWQgb24gb25lIHBoeXNpY2FsIGludAogICovCiAjZGVmaW5lIE1BWF9DSVJCVUZGICAgICAzMgog CiBzdHJ1Y3QgY2lyYnVmZiB7Ci0gICAgICAgIHU4IHJkaW5kZXg7ICAgICAgICAgICAgIC8qIHJl YWQsIHRoZW4gaW5jcmVtZW50IGFuZCB3cmFwICovCi0gICAgICAgIHU4IHdyaW5kZXg7ICAgICAg ICAgICAgIC8qIHdyaXRlLCB0aGVuIGluY3JlbWVudCBhbmQgd3JhcCAqLwotICAgICAgICB1OCBl dm50YnVmZltNQVhfQ0lSQlVGRl07CisJdTggcmRpbmRleDsJCS8qIHJlYWQsIHRoZW4gaW5jcmVt ZW50IGFuZCB3cmFwICovCisJdTggd3JpbmRleDsJCS8qIHdyaXRlLCB0aGVuIGluY3JlbWVudCBh bmQgd3JhcCAqLworCXU4IGV2bnRidWZmW01BWF9DSVJCVUZGXTsKIH07CiAKIC8qIEludGVycnVw dCBldmVudCBjb2Rlcy4KICAqIFdoZXJlIGFwcHJvcHJpYXRlIHRoZSB0d28gbG93IG9yZGVyIGJp dHMgaW5kaWNhdGUgdGhlIHBvcnQgbnVtYmVyCiAgKi8KLSNkZWZpbmUgQ1RMQV9DSEcgICAgICAg IDB4MTggICAgLyogQ29udHJvbCBzaWduYWwgY2hhbmdlZCAqLworI2RlZmluZSBDVExBX0NIRyAg ICAgICAgMHgxOAkvKiBDb250cm9sIHNpZ25hbCBjaGFuZ2VkICovCiAjZGVmaW5lIENUTEJfQ0hH ICAgICAgICAweDE5CiAjZGVmaW5lIENUTENfQ0hHICAgICAgICAweDFBCiAjZGVmaW5lIENUTERf Q0hHICAgICAgICAweDFCCiAKLSNkZWZpbmUgSU5JVF9DUExUICAgICAgIDB4MjAgICAgLyogSW5p dGlhbGlzYXRpb24gY29tcGxldGUgKi8KLSNkZWZpbmUgSU5JVF9GQUlMICAgICAgIDB4MjEgICAg LyogSW5pdGlhbGlzYXRpb24gZmFpbGVkICovCisjZGVmaW5lIElOSVRfQ1BMVCAgICAgICAweDIw CS8qIEluaXRpYWxpc2F0aW9uIGNvbXBsZXRlICovCisjZGVmaW5lIElOSVRfRkFJTCAgICAgICAw eDIxCS8qIEluaXRpYWxpc2F0aW9uIGZhaWxlZCAqLwogCi0jZGVmaW5lIEFCVEFfU0VOVCAgICAg ICAweDI0ICAgIC8qIEFib3J0IHNlbnQgKi8KKyNkZWZpbmUgQUJUQV9TRU5UICAgICAgIDB4MjQJ LyogQWJvcnQgc2VudCAqLwogI2RlZmluZSBBQlRCX1NFTlQgICAgICAgMHgyNQogI2RlZmluZSBB QlRDX1NFTlQgICAgICAgMHgyNgogI2RlZmluZSBBQlREX1NFTlQgICAgICAgMHgyNwogCi0jZGVm aW5lIFRYQV9VTkRGICAgICAgICAweDI4ICAgIC8qIFRyYW5zbWlzc2lvbiB1bmRlcmZsb3cgKi8K KyNkZWZpbmUgVFhBX1VOREYgICAgICAgIDB4MjgJLyogVHJhbnNtaXNzaW9uIHVuZGVyZmxvdyAq LwogI2RlZmluZSBUWEJfVU5ERiAgICAgICAgMHgyOQogI2RlZmluZSBUWENfVU5ERiAgICAgICAg MHgyQQogI2RlZmluZSBUWERfVU5ERiAgICAgICAgMHgyQgogCisjZGVmaW5lIEY1Nl9JTlQgICAg ICAgICAweDJDCisjZGVmaW5lIE0zMl9JTlQgICAgICAgICAweDJECisKKyNkZWZpbmUgVEUxX0FM TUEgICAgICAgIDB4MzAKIAogLyogUG9ydCBwaHlzaWNhbCBjb25maWd1cmF0aW9uLiBTZWUgZmFy c3luYy5oIGZvciBmaWVsZCB2YWx1ZXMgKi8KIHN0cnVjdCBwb3J0X2NmZyB7Ci0gICAgICAgIHUx NiAgbGluZUludGVyZmFjZTsgICAgIC8qIFBoeXNpY2FsIGludGVyZmFjZSB0eXBlICovCi0gICAg ICAgIHU4ICAgeDI1b3A7ICAgICAgICAgICAgIC8qIFVudXNlZCBhdCBwcmVzZW50ICovCi0gICAg ICAgIHU4ICAgaW50ZXJuYWxDbG9jazsgICAgIC8qIDEgPT4gaW50ZXJuYWwgY2xvY2ssIDAgPT4g ZXh0ZXJuYWwgKi8KLSAgICAgICAgdTMyICBsaW5lU3BlZWQ7ICAgICAgICAgLyogU3BlZWQgaW4g YnBzICovCisJdTE2IGxpbmVJbnRlcmZhY2U7CS8qIFBoeXNpY2FsIGludGVyZmFjZSB0eXBlICov CisJdTggeDI1b3A7CQkvKiBVbnVzZWQgYXQgcHJlc2VudCAqLworCXU4IGludGVybmFsQ2xvY2s7 CS8qIDEgPT4gaW50ZXJuYWwgY2xvY2ssIDAgPT4gZXh0ZXJuYWwgKi8KKwl1OCB0cmFuc3BhcmVu dE1vZGU7CS8qIDEgPT4gb24sIDAgPT4gb2ZmICovCisJdTggaW52ZXJ0Q2xvY2s7CQkvKiAwID0+ IG5vcm1hbCwgMSA9PiBpbnZlcnRlZCAqLworCXU4IHBhZEJ5dGVzWzZdOwkJLyogUGFkZGluZyAq LworCXUzMiBsaW5lU3BlZWQ7CQkvKiBTcGVlZCBpbiBicHMgKi8KK307CisKKy8qIFRFMSBwb3J0 IHBoeXNpY2FsIGNvbmZpZ3VyYXRpb24gKi8KK3N0cnVjdCBzdV9jb25maWcgeworCXUzMiBkYXRh UmF0ZTsKKwl1OCBjbG9ja2luZzsKKwl1OCBmcmFtaW5nOworCXU4IHN0cnVjdHVyZTsKKwl1OCBp bnRlcmZhY2U7CisJdTggY29kaW5nOworCXU4IGxpbmVCdWlsZE91dDsKKwl1OCBlcXVhbGl6ZXI7 CisJdTggdHJhbnNwYXJlbnRNb2RlOworCXU4IGxvb3BNb2RlOworCXU4IHJhbmdlOworCXU4IHR4 QnVmZmVyTW9kZTsKKwl1OCByeEJ1ZmZlck1vZGU7CisJdTggc3RhcnRpbmdTbG90OworCXU4IGxv c1RocmVzaG9sZDsKKwl1OCBlbmFibGVJZGxlQ29kZTsKKwl1OCBpZGxlQ29kZTsKKwl1OCBzcGFy ZVs0NF07Cit9OworCisvKiBURTEgU3RhdHVzICovCitzdHJ1Y3Qgc3Vfc3RhdHVzIHsKKwl1MzIg cmVjZWl2ZUJ1ZmZlckRlbGF5OworCXUzMiBmcmFtaW5nRXJyb3JDb3VudDsKKwl1MzIgY29kZVZp b2xhdGlvbkNvdW50OworCXUzMiBjcmNFcnJvckNvdW50OworCXUzMiBsaW5lQXR0ZW51YXRpb247 CisJdTggcG9ydFN0YXJ0ZWQ7CisJdTggbG9zc09mU2lnbmFsOworCXU4IHJlY2VpdmVSZW1vdGVB bGFybTsKKwl1OCBhbGFybUluZGljYXRpb25TaWduYWw7CisJdTggc3BhcmVbNDBdOwogfTsKIAog LyogRmluYWxseSBzbGluZyBhbGwgdGhlIGFib3ZlIHRvZ2V0aGVyIGludG8gdGhlIHNoYXJlZCBt ZW1vcnkgc3RydWN0dXJlLgpAQCAtMjA5LDExNCArMjY1LDE1MSBAQAogICogU2VlIGZhcnN5bmMu aCBmb3Igc29tZSBmaWVsZCB2YWx1ZXMuCiAgKi8KIHN0cnVjdCBmc3Rfc2hhcmVkIHsKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogRE1BIGRlc2NyaXB0b3IgcmluZ3MgKi8KLSAg ICAgICAgc3RydWN0IHJ4ZGVzYyByeERlc2NyUmluZ1tGU1RfTUFYX1BPUlRTXVtOVU1fUlhfQlVG RkVSXTsKLSAgICAgICAgc3RydWN0IHR4ZGVzYyB0eERlc2NyUmluZ1tGU1RfTUFYX1BPUlRTXVtO VU1fVFhfQlVGRkVSXTsKKwkvKiBETUEgZGVzY3JpcHRvciByaW5ncyAqLworCXN0cnVjdCByeGRl c2MgcnhEZXNjclJpbmdbRlNUX01BWF9QT1JUU11bTlVNX1JYX0JVRkZFUl07CisJc3RydWN0IHR4 ZGVzYyB0eERlc2NyUmluZ1tGU1RfTUFYX1BPUlRTXVtOVU1fVFhfQlVGRkVSXTsKKworCS8qIE9i c29sZXRlIHNtYWxsIGJ1ZmZlcnMgKi8KKwl1OCBzbWFsbFJ4QnVmZmVyW0ZTVF9NQVhfUE9SVFNd W05VTV9SWF9CVUZGRVJdW0xFTl9TTUFMTF9SWF9CVUZGRVJdOworCXU4IHNtYWxsVHhCdWZmZXJb RlNUX01BWF9QT1JUU11bTlVNX1RYX0JVRkZFUl1bTEVOX1NNQUxMX1RYX0JVRkZFUl07CiAKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogT2Jzb2xldGUgc21hbGwgYnVmZmVycyAq LwotICAgICAgICB1OCAgc21hbGxSeEJ1ZmZlcltGU1RfTUFYX1BPUlRTXVtOVU1fUlhfQlVGRkVS XVtMRU5fU01BTExfUlhfQlVGRkVSXTsKLSAgICAgICAgdTggIHNtYWxsVHhCdWZmZXJbRlNUX01B WF9QT1JUU11bTlVNX1RYX0JVRkZFUl1bTEVOX1NNQUxMX1RYX0JVRkZFUl07CisJdTggdGFza1N0 YXR1czsJCS8qIDB4MDAgPT4gaW5pdGlhbGlzaW5nLCAweDAxID0+IHJ1bm5pbmcsCisJCQkJICog MHhGRiA9PiBoYWx0ZWQKKwkJCQkgKi8KIAotICAgICAgICB1OCAgdGFza1N0YXR1czsgICAgICAg ICAvKiAweDAwID0+IGluaXRpYWxpc2luZywgMHgwMSA9PiBydW5uaW5nLAotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKiAweEZGID0+IGhhbHRlZAotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKi8KKwl1OCBpbnRlcnJ1cHRIYW5kc2hha2U7CS8qIFNldCB0byAweDAx IGJ5IGFkYXB0ZXIgdG8gc2lnbmFsIGludGVycnVwdCwKKwkJCQkgKiBzZXQgdG8gMHhFRSBieSBo b3N0IHRvIGFja25vd2xlZGdlIGludGVycnVwdAorCQkJCSAqLwogCi0gICAgICAgIHU4ICBpbnRl cnJ1cHRIYW5kc2hha2U7IC8qIFNldCB0byAweDAxIGJ5IGFkYXB0ZXIgdG8gc2lnbmFsIGludGVy cnVwdCwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICogc2V0IHRvIDB4RUUgYnkg aG9zdCB0byBhY2tub3dsZWRnZSBpbnRlcnJ1cHQKLSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICovCisJdTE2IHNtY1ZlcnNpb247CQkvKiBNdXN0IG1hdGNoIFNNQ19WRVJTSU9OICov CiAKLSAgICAgICAgdTE2IHNtY1ZlcnNpb247ICAgICAgICAgLyogTXVzdCBtYXRjaCBTTUNfVkVS U0lPTiAqLworCXUzMiBzbWNGaXJtd2FyZVZlcnNpb247CS8qIDB4SUlWVlJSQkIgd2hlcmUgSUkg PSBwcm9kdWN0IElELCBWViA9IG1ham9yCisJCQkJICogdmVyc2lvbiwgUlIgPSByZXZpc2lvbiBh bmQgQkIgPSBidWlsZAorCQkJCSAqLwogCi0gICAgICAgIHUzMiBzbWNGaXJtd2FyZVZlcnNpb247 IC8qIDB4SUlWVlJSQkIgd2hlcmUgSUkgPSBwcm9kdWN0IElELCBWViA9IG1ham9yCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAqIHZlcnNpb24sIFJSID0gcmV2aXNpb24gYW5kIEJC ID0gYnVpbGQKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisJdTE2IHR4YV9k b25lOwkJLyogT2Jzb2xldGUgY29tcGxldGlvbiBmbGFncyAqLworCXUxNiByeGFfZG9uZTsKKwl1 MTYgdHhiX2RvbmU7CisJdTE2IHJ4Yl9kb25lOworCXUxNiB0eGNfZG9uZTsKKwl1MTYgcnhjX2Rv bmU7CisJdTE2IHR4ZF9kb25lOworCXUxNiByeGRfZG9uZTsKIAotICAgICAgICB1MTYgdHhhX2Rv bmU7ICAgICAgICAgICAvKiBPYnNvbGV0ZSBjb21wbGV0aW9uIGZsYWdzICovCi0gICAgICAgIHUx NiByeGFfZG9uZTsKLSAgICAgICAgdTE2IHR4Yl9kb25lOwotICAgICAgICB1MTYgcnhiX2RvbmU7 Ci0gICAgICAgIHUxNiB0eGNfZG9uZTsKLSAgICAgICAgdTE2IHJ4Y19kb25lOwotICAgICAgICB1 MTYgdHhkX2RvbmU7Ci0gICAgICAgIHUxNiByeGRfZG9uZTsKKwl1MTYgbWFpbGJveFs0XTsJCS8q IERpYWdub3N0aWNzIG1haWxib3guIE5vdCB1c2VkICovCiAKLSAgICAgICAgdTE2IG1haWxib3hb NF07ICAgICAgICAgLyogRGlhZ25vc3RpY3MgbWFpbGJveC4gTm90IHVzZWQgKi8KKwlzdHJ1Y3Qg Y2lyYnVmZiBpbnRlcnJ1cHRFdmVudDsJLyogaW50ZXJydXB0IGNhdXNlcyAqLwogCi0gICAgICAg IHN0cnVjdCBjaXJidWZmIGludGVycnVwdEV2ZW50OyAgLyogaW50ZXJydXB0IGNhdXNlcyAqLwor CXUzMiB2MjRJcFN0c1tGU1RfTUFYX1BPUlRTXTsJLyogVi4yNCBjb250cm9sIGlucHV0IHN0YXR1 cyAqLworCXUzMiB2MjRPcFN0c1tGU1RfTUFYX1BPUlRTXTsJLyogVi4yNCBjb250cm9sIG91dHB1 dCBzdGF0dXMgKi8KIAotICAgICAgICB1MzIgdjI0SXBTdHNbRlNUX01BWF9QT1JUU107ICAgIC8q IFYuMjQgY29udHJvbCBpbnB1dCBzdGF0dXMgKi8KLSAgICAgICAgdTMyIHYyNE9wU3RzW0ZTVF9N QVhfUE9SVFNdOyAgICAvKiBWLjI0IGNvbnRyb2wgb3V0cHV0IHN0YXR1cyAqLworCXN0cnVjdCBw b3J0X2NmZyBwb3J0Q29uZmlnW0ZTVF9NQVhfUE9SVFNdOwogCi0gICAgICAgIHN0cnVjdCBwb3J0 X2NmZyBwb3J0Q29uZmlnW0ZTVF9NQVhfUE9SVFNdOworCXUxNiBjbG9ja1N0YXR1c1tGU1RfTUFY X1BPUlRTXTsJLyogbHNiOiAwPT4gcHJlc2VudCwgMT0+IGFic2VudCAqLwogCi0gICAgICAgIHUx NiBjbG9ja1N0YXR1c1tGU1RfTUFYX1BPUlRTXTsgLyogbHNiOiAwPT4gcHJlc2VudCwgMT0+IGFi c2VudCAqLworCXUxNiBjYWJsZVN0YXR1czsJLyogbHNiOiAwPT4gcHJlc2VudCwgMT0+IGFic2Vu dCAqLwogCi0gICAgICAgIHUxNiBjYWJsZVN0YXR1czsgICAgICAgICAgICAgICAgLyogbHNiOiAw PT4gcHJlc2VudCwgMT0+IGFic2VudCAqLworCXUxNiB0eERlc2NySW5kZXhbRlNUX01BWF9QT1JU U107CS8qIHRyYW5zbWl0IGRlc2NyaXB0b3IgcmluZyBpbmRleCAqLworCXUxNiByeERlc2NySW5k ZXhbRlNUX01BWF9QT1JUU107CS8qIHJlY2VpdmUgZGVzY3JpcHRvciByaW5nIGluZGV4ICovCiAK LSAgICAgICAgdTE2IHR4RGVzY3JJbmRleFtGU1RfTUFYX1BPUlRTXTsgLyogdHJhbnNtaXQgZGVz Y3JpcHRvciByaW5nIGluZGV4ICovCi0gICAgICAgIHUxNiByeERlc2NySW5kZXhbRlNUX01BWF9Q T1JUU107IC8qIHJlY2VpdmUgZGVzY3JpcHRvciByaW5nIGluZGV4ICovCisJdTE2IHBvcnRNYWls Ym94W0ZTVF9NQVhfUE9SVFNdWzJdOwkvKiBjb21tYW5kLCBtb2RpZmllciAqLworCXUxNiBjYXJk TWFpbGJveFs0XTsJLyogTm90IHVzZWQgKi8KIAotICAgICAgICB1MTYgcG9ydE1haWxib3hbRlNU X01BWF9QT1JUU11bMl07ICAgICAgLyogY29tbWFuZCwgbW9kaWZpZXIgKi8KLSAgICAgICAgdTE2 IGNhcmRNYWlsYm94WzRdOyAgICAgICAgICAgICAgICAgICAgIC8qIE5vdCB1c2VkICovCisJLyog TnVtYmVyIG9mIHRpbWVzIHRoZSBjYXJkIHRoaW5rcyB0aGUgaG9zdCBoYXMKKwkgKiBtaXNzZWQg YW4gaW50ZXJydXB0IGJ5IG5vdCBhY2tub3dsZWRnaW5nCisJICogd2l0aGluIDJtUyAoSSBndWVz cyBOVCBoYXMgcHJvYmxlbXMpCisJICovCisJdTMyIGludGVycnVwdFJldHJ5Q291bnQ7CiAKLSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogTnVtYmVyIG9mIHRpbWVzIHRoYXQgY2Fy ZCB0aGlua3MgdGhlIGhvc3QgaGFzCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAq IG1pc3NlZCBhbiBpbnRlcnJ1cHQgYnkgbm90IGFja25vd2xlZGdpbmcKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICogd2l0aGluIDJtUyAoSSBndWVzcyBOVCBoYXMgcHJvYmxlbXMp Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqLwotICAgICAgICB1MzIgaW50ZXJy dXB0UmV0cnlDb3VudDsKKwkvKiBEcml2ZXIgcHJpdmF0ZSBkYXRhIHVzZWQgYXMgYW4gSUQuIFdl J2xsIG5vdAorCSAqIHVzZSB0aGlzIGFzIEknZCByYXRoZXIga2VlcCBzdWNoIHRoaW5ncworCSAq IGluIG1haW4gbWVtb3J5IHJhdGhlciB0aGFuIG9uIHRoZSBQQ0kgYnVzCisJICovCisJdTMyIHBv cnRIYW5kbGVbRlNUX01BWF9QT1JUU107CiAKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLyogRHJpdmVyIHByaXZhdGUgZGF0YSB1c2VkIGFzIGFuIElELiBXZSdsbCBub3QKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICogdXNlIHRoaXMgb24gTGludXggSSdkIHJhdGhl ciBrZWVwIHN1Y2ggdGhpbmdzCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAqIGlu IG1haW4gbWVtb3J5IHJhdGhlciB0aGFuIG9uIHRoZSBQQ0kgYnVzCi0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAqLwotICAgICAgICB1MzIgcG9ydEhhbmRsZVtGU1RfTUFYX1BPUlRT XTsKKwkvKiBDb3VudCBvZiBUeCB1bmRlcmZsb3dzIGZvciBzdGF0cyAqLworCXUzMiB0cmFuc21p dEJ1ZmZlclVuZGVyZmxvd1tGU1RfTUFYX1BPUlRTXTsKIAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvKiBDb3VudCBvZiBUeCB1bmRlcmZsb3dzIGZvciBzdGF0cyAqLwotICAgICAg ICB1MzIgdHJhbnNtaXRCdWZmZXJVbmRlcmZsb3dbRlNUX01BWF9QT1JUU107CisJLyogRGVib3Vu Y2VkIFYuMjQgY29udHJvbCBpbnB1dCBzdGF0dXMgKi8KKwl1MzIgdjI0RGVib3VuY2VkU3RzW0ZT VF9NQVhfUE9SVFNdOwogCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIERlYm91 bmNlZCBWLjI0IGNvbnRyb2wgaW5wdXQgc3RhdHVzICovCi0gICAgICAgIHUzMiB2MjREZWJvdW5j ZWRTdHNbRlNUX01BWF9QT1JUU107CisJLyogQWRhcHRlciBkZWJvdW5jZSB0aW1lcnMuIERvbid0 IHRvdWNoICovCisJdTMyIGN0c1RpbWVyW0ZTVF9NQVhfUE9SVFNdOworCXUzMiBjdHNUaW1lclJ1 bltGU1RfTUFYX1BPUlRTXTsKKwl1MzIgZGNkVGltZXJbRlNUX01BWF9QT1JUU107CisJdTMyIGRj ZFRpbWVyUnVuW0ZTVF9NQVhfUE9SVFNdOwogCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8qIEFkYXB0ZXIgZGVib3VuY2UgdGltZXJzLiBEb24ndCB0b3VjaCAqLwotICAgICAgICB1 MzIgY3RzVGltZXJbRlNUX01BWF9QT1JUU107Ci0gICAgICAgIHUzMiBjdHNUaW1lclJ1bltGU1Rf TUFYX1BPUlRTXTsKLSAgICAgICAgdTMyIGRjZFRpbWVyW0ZTVF9NQVhfUE9SVFNdOwotICAgICAg ICB1MzIgZGNkVGltZXJSdW5bRlNUX01BWF9QT1JUU107CisJdTMyIG51bWJlck9mUG9ydHM7CS8q IE51bWJlciBvZiBwb3J0cyBkZXRlY3RlZCBhdCBzdGFydHVwICovCiAKLSAgICAgICAgdTMyIG51 bWJlck9mUG9ydHM7ICAgICAgLyogTnVtYmVyIG9mIHBvcnRzIGRldGVjdGVkIGF0IHN0YXJ0dXAg Ki8KKwl1MTYgX3Jlc2VydmVkWzY0XTsKIAotICAgICAgICB1MTYgX3Jlc2VydmVkWzY0XTsKKwl1 MTYgY2FyZE1vZGU7CQkvKiBCaXQtbWFzayB0byBlbmFibGUgZmVhdHVyZXM6CisJCQkJICogQml0 IDA6IDEgZW5hYmxlcyBMRUQgaWRlbnRpZnkgbW9kZQorCQkJCSAqLwogCi0gICAgICAgIHUxNiBj YXJkTW9kZTsgICAgICAgICAgIC8qIEJpdC1tYXNrIHRvIGVuYWJsZSBmZWF0dXJlczoKLSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICogQml0IDA6IDEgZW5hYmxlcyBMRUQgaWRlbnRp ZnkgbW9kZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8KKwl1MTYgcG9ydFNj aGVkdWxlT2Zmc2V0OwogCi0gICAgICAgIHUxNiBwb3J0U2NoZWR1bGVPZmZzZXQ7CisJc3RydWN0 IHN1X2NvbmZpZyBzdUNvbmZpZzsJLyogVEUxIEJpdHMgKi8KKwlzdHJ1Y3Qgc3Vfc3RhdHVzIHN1 U3RhdHVzOwogCi0gICAgICAgIHUzMiBlbmRPZlNtY1NpZ25hdHVyZTsgIC8qIGVuZE9mU21jU2ln bmF0dXJlIE1VU1QgYmUgdGhlIGxhc3QgbWVtYmVyIG9mCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAqIHRoZSBzdHJ1Y3R1cmUgYW5kIG1hcmtzIHRoZSBlbmQgb2YgdGhlIHNoYXJl ZAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKiBtZW1vcnkuIEFkYXB0ZXIgY29k ZSBpbml0aWFsaXplcyBpdHMgdmFsdWUgYXMKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICogRU5EX1NJRy4KLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICovCisJdTMy IGVuZE9mU21jU2lnbmF0dXJlOwkvKiBlbmRPZlNtY1NpZ25hdHVyZSBNVVNUIGJlIHRoZSBsYXN0 IG1lbWJlciBvZgorCQkJCSAqIHRoZSBzdHJ1Y3R1cmUgYW5kIG1hcmtzIHRoZSBlbmQgb2Ygc2hh cmVkCisJCQkJICogbWVtb3J5LiBBZGFwdGVyIGNvZGUgaW5pdGlhbGl6ZXMgaXQgYXMKKwkJCQkg KiBFTkRfU0lHLgorCQkJCSAqLwogfTsKIAogLyogZW5kT2ZTbWNTaWduYXR1cmUgdmFsdWUgKi8K ICNkZWZpbmUgRU5EX1NJRyAgICAgICAgICAgICAgICAgMHgxMjM0NTY3OAogCiAvKiBNYWlsYm94 IHZhbHVlcy4gKHBvcnRNYWlsYm94KSAqLwotI2RlZmluZSBOT1AgICAgICAgICAgICAgMCAgICAg ICAvKiBObyBvcGVyYXRpb24gKi8KLSNkZWZpbmUgQUNLICAgICAgICAgICAgIDEgICAgICAgLyog UG9zaXRpdmUgYWNrbm93bGVkZ2VtZW50IHRvIFBDIGRyaXZlciAqLwotI2RlZmluZSBOQUsgICAg ICAgICAgICAgMiAgICAgICAvKiBOZWdhdGl2ZSBhY2tub3dsZWRnZW1lbnQgdG8gUEMgZHJpdmVy ICovCi0jZGVmaW5lIFNUQVJUUE9SVCAgICAgICAzICAgICAgIC8qIFN0YXJ0IGFuIEhETEMgcG9y dCAqLwotI2RlZmluZSBTVE9QUE9SVCAgICAgICAgNCAgICAgICAvKiBTdG9wIGFuIEhETEMgcG9y dCAqLwotI2RlZmluZSBBQk9SVFRYICAgICAgICAgNSAgICAgICAvKiBBYm9ydCB0aGUgdHJhbnNt aXR0ZXIgZm9yIGEgcG9ydCAqLwotI2RlZmluZSBTRVRWMjRPICAgICAgICAgNiAgICAgICAvKiBT ZXQgVjI0IG91dHB1dHMgKi8KKyNkZWZpbmUgTk9QICAgICAgICAgICAgIDAJLyogTm8gb3BlcmF0 aW9uICovCisjZGVmaW5lIEFDSyAgICAgICAgICAgICAxCS8qIFBvc2l0aXZlIGFja25vd2xlZGdl bWVudCB0byBQQyBkcml2ZXIgKi8KKyNkZWZpbmUgTkFLICAgICAgICAgICAgIDIJLyogTmVnYXRp dmUgYWNrbm93bGVkZ2VtZW50IHRvIFBDIGRyaXZlciAqLworI2RlZmluZSBTVEFSVFBPUlQgICAg ICAgMwkvKiBTdGFydCBhbiBIRExDIHBvcnQgKi8KKyNkZWZpbmUgU1RPUFBPUlQgICAgICAgIDQJ LyogU3RvcCBhbiBIRExDIHBvcnQgKi8KKyNkZWZpbmUgQUJPUlRUWCAgICAgICAgIDUJLyogQWJv cnQgdGhlIHRyYW5zbWl0dGVyIGZvciBhIHBvcnQgKi8KKyNkZWZpbmUgU0VUVjI0TyAgICAgICAg IDYJLyogU2V0IFYyNCBvdXRwdXRzICovCisKKy8qIFBMWCBDaGlwIFJlZ2lzdGVyIE9mZnNldHMg Ki8KKyNkZWZpbmUgQ05UUkxfOTA1MiAgICAgIDB4NTAJLyogQ29udHJvbCBSZWdpc3RlciAqLwor I2RlZmluZSBDTlRSTF85MDU0ICAgICAgMHg2YwkvKiBDb250cm9sIFJlZ2lzdGVyICovCiAKKyNk ZWZpbmUgSU5UQ1NSXzkwNTIgICAgIDB4NGMJLyogSW50ZXJydXB0IGNvbnRyb2wvc3RhdHVzIHJl Z2lzdGVyICovCisjZGVmaW5lIElOVENTUl85MDU0ICAgICAweDY4CS8qIEludGVycnVwdCBjb250 cm9sL3N0YXR1cyByZWdpc3RlciAqLworCisvKiA5MDU0IERNQSBSZWdpc3RlcnMgKi8KKy8qCisg KiBOb3RlIHRoYXQgd2Ugd2lsbCBiZSB1c2luZyBETUEgQ2hhbm5lbCAwIGZvciBjb3B5aW5nIHJ4 IGRhdGEKKyAqIGFuZCBDaGFubmVsIDEgZm9yIGNvcHlpbmcgdHggZGF0YQorICovCisjZGVmaW5l IERNQU1PREUwICAgICAgICAweDgwCisjZGVmaW5lIERNQVBBRFIwICAgICAgICAweDg0CisjZGVm aW5lIERNQUxBRFIwICAgICAgICAweDg4CisjZGVmaW5lIERNQVNJWjAgICAgICAgICAweDhjCisj ZGVmaW5lIERNQURQUjAgICAgICAgICAweDkwCisjZGVmaW5lIERNQU1PREUxICAgICAgICAweDk0 CisjZGVmaW5lIERNQVBBRFIxICAgICAgICAweDk4CisjZGVmaW5lIERNQUxBRFIxICAgICAgICAw eDljCisjZGVmaW5lIERNQVNJWjEgICAgICAgICAweGEwCisjZGVmaW5lIERNQURQUjEgICAgICAg ICAweGE0CisjZGVmaW5lIERNQUNTUjAgICAgICAgICAweGE4CisjZGVmaW5lIERNQUNTUjEgICAg ICAgICAweGE5CisjZGVmaW5lIERNQUFSQiAgICAgICAgICAweGFjCisjZGVmaW5lIERNQVRIUiAg ICAgICAgICAweGIwCisjZGVmaW5lIERNQURBQzAgICAgICAgICAweGI0CisjZGVmaW5lIERNQURB QzEgICAgICAgICAweGI4CisjZGVmaW5lIERNQU1BUkJSICAgICAgICAweGFjCisKKyNkZWZpbmUg RlNUX01JTl9ETUFfTEVOIDY0CisjZGVmaW5lIEZTVF9SWF9ETUFfSU5UICAweDAxCisjZGVmaW5l IEZTVF9UWF9ETUFfSU5UICAweDAyCisjZGVmaW5lIEZTVF9DQVJEX0lOVCAgICAweDA0CiAKIC8q IExhcmdlciBidWZmZXJzIGFyZSBwb3NpdGlvbmVkIGluIG1lbW9yeSBhdCBvZmZzZXQgQkZNX0JB U0UgKi8KIHN0cnVjdCBidWZfd2luZG93IHsKLSAgICAgICAgdTggdHhCdWZmZXJbRlNUX01BWF9Q T1JUU11bTlVNX1RYX0JVRkZFUl1bTEVOX1RYX0JVRkZFUl07Ci0gICAgICAgIHU4IHJ4QnVmZmVy W0ZTVF9NQVhfUE9SVFNdW05VTV9SWF9CVUZGRVJdW0xFTl9SWF9CVUZGRVJdOworCXU4IHR4QnVm ZmVyW0ZTVF9NQVhfUE9SVFNdW05VTV9UWF9CVUZGRVJdW0xFTl9UWF9CVUZGRVJdOworCXU4IHJ4 QnVmZmVyW0ZTVF9NQVhfUE9SVFNdW05VTV9SWF9CVUZGRVJdW0xFTl9SWF9CVUZGRVJdOwogfTsK IAogLyogQ2FsY3VsYXRlIG9mZnNldCBvZiBhIGJ1ZmZlciBvYmplY3Qgd2l0aGluIHRoZSBzaGFy ZWQgbWVtb3J5IHdpbmRvdyAqLwpAQCAtMzI0LDM5ICs0MTcsNjQgQEAKIAogI3ByYWdtYSBwYWNr KCkKIAotCiAvKiAgICAgIERldmljZSBkcml2ZXIgcHJpdmF0ZSBpbmZvcm1hdGlvbgogICogICAg ICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KICAqLwogLyogICAgICBQZXIgcG9y dCAobGluZSBvciBjaGFubmVsKSBpbmZvcm1hdGlvbgogICovCiBzdHJ1Y3QgZnN0X3BvcnRfaW5m byB7Ci0gICAgICAgIGhkbGNfZGV2aWNlICAgICAgICAgICAgIGhkbGM7ICAgLyogSERMQyBkZXZp Y2Ugc3RydWN0IC0gbXVzdCBiZSBmaXJzdCAqLwotICAgICAgICBzdHJ1Y3QgZnN0X2NhcmRfaW5m byAgICpjYXJkOyAgIC8qIENhcmQgd2UncmUgYXNzb2NpYXRlZCB3aXRoICovCi0gICAgICAgIGlu dCAgICAgICAgICAgICAgICAgICAgIGluZGV4OyAgLyogUG9ydCBpbmRleCBvbiB0aGUgY2FyZCAq LwotICAgICAgICBpbnQgICAgICAgICAgICAgICAgICAgICBod2lmOyAgIC8qIExpbmUgaGFyZHdh cmUgKGxpbmVJbnRlcmZhY2UgY29weSkgKi8KLSAgICAgICAgaW50ICAgICAgICAgICAgICAgICAg ICAgcnVuOyAgICAvKiBQb3J0IGlzIHJ1bm5pbmcgKi8KLSAgICAgICAgaW50ICAgICAgICAgICAg ICAgICAgICAgcnhwb3M7ICAvKiBOZXh0IFJ4IGJ1ZmZlciB0byB1c2UgKi8KLSAgICAgICAgaW50 ICAgICAgICAgICAgICAgICAgICAgdHhwb3M7ICAvKiBOZXh0IFR4IGJ1ZmZlciB0byB1c2UgKi8K LSAgICAgICAgaW50ICAgICAgICAgICAgICAgICAgICAgdHhpcG9zOyAvKiBOZXh0IFR4IGJ1ZmZl ciB0byBjaGVjayBmb3IgZnJlZSAqLwotICAgICAgICBpbnQgICAgICAgICAgICAgICAgICAgICB0 eGNudDsgIC8qIENvdW50IG9mIFR4IGJ1ZmZlcnMgaW4gdXNlICovCisJaGRsY19kZXZpY2UgaGRs YzsJLyogSERMQyBkZXZpY2Ugc3RydWN0IC0gbXVzdCBiZSBmaXJzdCAqLworCXN0cnVjdCBmc3Rf Y2FyZF9pbmZvICpjYXJkOwkvKiBDYXJkIHdlJ3JlIGFzc29jaWF0ZWQgd2l0aCAqLworCWludCBp bmRleDsJCS8qIFBvcnQgaW5kZXggb24gdGhlIGNhcmQgKi8KKwlpbnQgaHdpZjsJCS8qIExpbmUg aGFyZHdhcmUgKGxpbmVJbnRlcmZhY2UgY29weSkgKi8KKwlpbnQgcnVuOwkJLyogUG9ydCBpcyBy dW5uaW5nICovCisJaW50IG1vZGU7CQkvKiBOb3JtYWwgb3IgRmFyU3luYyByYXcgKi8KKwlpbnQg cnhwb3M7CQkvKiBOZXh0IFJ4IGJ1ZmZlciB0byB1c2UgKi8KKwlpbnQgdHhwb3M7CQkvKiBOZXh0 IFR4IGJ1ZmZlciB0byB1c2UgKi8KKwlpbnQgdHhpcG9zOwkJLyogTmV4dCBUeCBidWZmZXIgdG8g Y2hlY2sgZm9yIGZyZWUgKi8KKwlpbnQgc3RhcnQ7CQkvKiBJbmRpY2F0aW9uIG9mIHN0YXJ0L3N0 b3AgdG8gbmV0d29yayAqLworCS8qCisJICogQSBzaXh0ZWVuIGVudHJ5IHRyYW5zbWl0IHF1ZXVl CisJICovCisJaW50IHR4cXM7CQkvKiBpbmRleCB0byBnZXQgbmV4dCBidWZmZXIgdG8gdHggKi8K KwlpbnQgdHhxZTsJCS8qIGluZGV4IHRvIHF1ZXVlIG5leHQgcGFja2V0ICovCisJc3RydWN0IHNr X2J1ZmYgKnR4cVtGU1RfVFhRX0RFUFRIXTsJLyogVGhlIHF1ZXVlICovCisJaW50IHJ4cWRlcHRo OwogfTsKIAogLyogICAgICBQZXIgY2FyZCBpbmZvcm1hdGlvbgogICovCiBzdHJ1Y3QgZnN0X2Nh cmRfaW5mbyB7Ci0gICAgICAgIGNoYXIgICAgICAgICAgKm1lbTsgICAgICAgICAgICAgLyogQ2Fy ZCBtZW1vcnkgbWFwcGVkIHRvIGtlcm5lbCBzcGFjZSAqLwotICAgICAgICBjaGFyICAgICAgICAg ICpjdGxtZW07ICAgICAgICAgIC8qIENvbnRyb2wgbWVtb3J5IGZvciBQQ0kgY2FyZHMgKi8KLSAg ICAgICAgdW5zaWduZWQgaW50ICAgcGh5c19tZW07ICAgICAgICAvKiBQaHlzaWNhbCBtZW1vcnkg d2luZG93IGFkZHJlc3MgKi8KLSAgICAgICAgdW5zaWduZWQgaW50ICAgcGh5c19jdGxtZW07ICAg ICAvKiBQaHlzaWNhbCBjb250cm9sIG1lbW9yeSBhZGRyZXNzICovCi0gICAgICAgIHVuc2lnbmVk IGludCAgIGlycTsgICAgICAgICAgICAgLyogSW50ZXJydXB0IHJlcXVlc3QgbGluZSBudW1iZXIg Ki8KLSAgICAgICAgdW5zaWduZWQgaW50ICAgbnBvcnRzOyAgICAgICAgICAvKiBOdW1iZXIgb2Yg c2VyaWFsIHBvcnRzICovCi0gICAgICAgIHVuc2lnbmVkIGludCAgIHR5cGU7ICAgICAgICAgICAg LyogVHlwZSBpbmRleCBvZiBjYXJkICovCi0gICAgICAgIHVuc2lnbmVkIGludCAgIHN0YXRlOyAg ICAgICAgICAgLyogU3RhdGUgb2YgY2FyZCAqLwotICAgICAgICBzcGlubG9ja190ICAgICBjYXJk X2xvY2s7ICAgICAgIC8qIExvY2sgZm9yIFNNUCBhY2Nlc3MgKi8KLSAgICAgICAgdW5zaWduZWQg c2hvcnQgcGNpX2NvbmY7ICAgICAgICAvKiBQQ0kgY2FyZCBjb25maWcgaW4gSS9PIHNwYWNlICov Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogUGVyIHBvcnQgaW5m byAqLwotICAgICAgICBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyBwb3J0c1sgRlNUX01BWF9QT1JUUyBd OworCWNoYXIgKm1lbTsJCS8qIENhcmQgbWVtb3J5IG1hcHBlZCB0byBrZXJuZWwgc3BhY2UgKi8K KwljaGFyICpjdGxtZW07CQkvKiBDb250cm9sIG1lbW9yeSBmb3IgUENJIGNhcmRzICovCisJdW5z aWduZWQgaW50IHBoeXNfbWVtOwkvKiBQaHlzaWNhbCBtZW1vcnkgd2luZG93IGFkZHJlc3MgKi8K Kwl1bnNpZ25lZCBpbnQgcGh5c19jdGxtZW07CS8qIFBoeXNpY2FsIGNvbnRyb2wgbWVtb3J5IGFk ZHJlc3MgKi8KKwl1bnNpZ25lZCBpbnQgaXJxOwkvKiBJbnRlcnJ1cHQgcmVxdWVzdCBsaW5lIG51 bWJlciAqLworCXVuc2lnbmVkIGludCBucG9ydHM7CS8qIE51bWJlciBvZiBzZXJpYWwgcG9ydHMg Ki8KKwl1bnNpZ25lZCBpbnQgdHlwZTsJLyogVHlwZSBpbmRleCBvZiBjYXJkICovCisJdW5zaWdu ZWQgaW50IHN0YXRlOwkvKiBTdGF0ZSBvZiBjYXJkICovCisJc3BpbmxvY2tfdCBjYXJkX2xvY2s7 CS8qIExvY2sgZm9yIFNNUCBhY2Nlc3MgKi8KKwl1bnNpZ25lZCBzaG9ydCBwY2lfY29uZjsJLyog UENJIGNhcmQgY29uZmlnIGluIEkvTyBzcGFjZSAqLworCS8qIFBlciBwb3J0IGluZm8gKi8KKwlz dHJ1Y3QgZnN0X3BvcnRfaW5mbyBwb3J0c1tGU1RfTUFYX1BPUlRTXTsKKwlzdHJ1Y3QgcGNpX2Rl diAqZGV2aWNlOwkvKiBJbmZvcm1hdGlvbiBhYm91dCB0aGUgcGNpIGRldmljZSAqLworCWludCBj YXJkX25vOwkJLyogSW5zdCBvZiB0aGUgY2FyZCBvbiB0aGUgc3lzdGVtICovCisJaW50IGZhbWls eTsJCS8qIFR4UCBvciBUeFUgKi8KKwlpbnQgZG1hcnhfaW5fcHJvZ3Jlc3M7CisJaW50IGRtYXR4 X2luX3Byb2dyZXNzOworCXVuc2lnbmVkIGxvbmcgaW50X2NvdW50OworCXVuc2lnbmVkIGxvbmcg aW50X3RpbWVfYXZlOworCXZvaWQgKnJ4X2RtYV9oYW5kbGVfaG9zdDsKKwlkbWFfYWRkcl90IHJ4 X2RtYV9oYW5kbGVfY2FyZDsKKwl2b2lkICp0eF9kbWFfaGFuZGxlX2hvc3Q7CisJZG1hX2FkZHJf dCB0eF9kbWFfaGFuZGxlX2NhcmQ7CisJc3RydWN0IHNrX2J1ZmYgKmRtYV9za2Jfcng7CisJc3Ry dWN0IGZzdF9wb3J0X2luZm8gKmRtYV9wb3J0X3J4OworCXN0cnVjdCBmc3RfcG9ydF9pbmZvICpk bWFfcG9ydF90eDsKKwlpbnQgZG1hX2xlbl9yeDsKKwlpbnQgZG1hX2xlbl90eDsKKwlpbnQgZG1h X3R4cG9zOworCWludCBkbWFfcnhwb3M7CiB9OwogCiAvKiBDb252ZXJ0IGFuIEhETEMgZGV2aWNl IHBvaW50ZXIgaW50byBhIHBvcnQgaW5mbyBwb2ludGVyIGFuZCBzaW1pbGFyICovCkBAIC0zNjQs NyArNDgyLDYgQEAKICNkZWZpbmUgZGV2X3RvX3BvcnQoRCkgIGhkbGNfdG9fcG9ydChkZXZfdG9f aGRsYyhEKSkKICNkZWZpbmUgcG9ydF90b19kZXYoUCkgIGhkbGNfdG9fZGV2KCYoUCktPmhkbGMp CiAKLQogLyoKICAqICAgICAgU2hhcmVkIG1lbW9yeSB3aW5kb3cgYWNjZXNzIG1hY3JvcwogICoK QEAgLTM4NCw3ICs1MDEsNiBAQAogI2RlZmluZSBGU1RfV1JXKEMsRSxXKSAgd3JpdGV3ICgoVyks IChDKS0+bWVtICsgV0lOX09GRlNFVChFKSkKICNkZWZpbmUgRlNUX1dSTChDLEUsTCkgIHdyaXRl bCAoKEwpLCAoQyktPm1lbSArIFdJTl9PRkZTRVQoRSkpCiAKLQogLyoKICAqICAgICAgRGVidWcg c3VwcG9ydAogICovCkBAIC00MDMsMzAgKzUxOSwxNDggQEAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgcHJpbnRrICggS0VSTl9ERUJVRyBGU1RfTkFNRSAiOiAiIGZtdCwgIyMgQSAp CiAKICNlbHNlCi0jIGRlZmluZSBkYmcoWC4uLikgICAgICAvKiBOT1AgKi8KKyNkZWZpbmUgZGJn KFguLi4pCQkvKiBOT1AgKi8KICNlbmRpZgogCi0KIC8qICAgICAgUHJpbnRpbmcgc2hvcnQgY3V0 cwogICovCiAjZGVmaW5lIHByaW50a19lcnIoZm10LEEuLi4pICAgIHByaW50ayAoIEtFUk5fRVJS ICAgICBGU1RfTkFNRSAiOiAiIGZtdCwgIyMgQSApCiAjZGVmaW5lIHByaW50a193YXJuKGZtdCxB Li4uKSAgIHByaW50ayAoIEtFUk5fV0FSTklORyBGU1RfTkFNRSAiOiAiIGZtdCwgIyMgQSApCiAj ZGVmaW5lIHByaW50a19pbmZvKGZtdCxBLi4uKSAgIHByaW50ayAoIEtFUk5fSU5GTyAgICBGU1Rf TkFNRSAiOiAiIGZtdCwgIyMgQSApCiAKLQogLyoKICAqICAgICAgUENJIElEIGxvb2t1cCB0YWJs ZQogICovCiBzdGF0aWMgc3RydWN0IHBjaV9kZXZpY2VfaWQgZnN0X3BjaV9kZXZfaWRbXSBfX2Rl dmluaXRkYXRhID0gewotICAgICAgICB7IEZTQ19QQ0lfVkVORE9SX0lELCBUMlBfUENJX0RFVklD RV9JRCwgUENJX0FOWV9JRCwgUENJX0FOWV9JRCwgMCwgMCwKLSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBGU1RfVFlQRV9UMlAgfSwKLSAgICAgICAgeyBGU0NfUENJX1ZF TkRPUl9JRCwgVDRQX1BDSV9ERVZJQ0VfSUQsIFBDSV9BTllfSUQsIFBDSV9BTllfSUQsIDAsIDAs Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRlNUX1RZUEVfVDRQIH0s Ci0gICAgICAgIHsgMCwgfSAgICAgICAgICAgICAgICAgICAgICAgICAgLyogRW5kICovCisJe1BD SV9WRU5ET1JfSURfRkFSU0lURSwgUENJX0RFVklDRV9JRF9GQVJTSVRFX1QyUCwgUENJX0FOWV9J RCwgCisJIFBDSV9BTllfSUQsIDAsIDAsIEZTVF9UWVBFX1QyUH0sCisKKwl7UENJX1ZFTkRPUl9J RF9GQVJTSVRFLCBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVDRQLCBQQ0lfQU5ZX0lELCAKKwkgUENJ X0FOWV9JRCwgMCwgMCwgRlNUX1RZUEVfVDRQfSwKKworCXtQQ0lfVkVORE9SX0lEX0ZBUlNJVEUs IFBDSV9ERVZJQ0VfSURfRkFSU0lURV9UMVUsIFBDSV9BTllfSUQsIAorCSBQQ0lfQU5ZX0lELCAw LCAwLCBGU1RfVFlQRV9UMVV9LAorCisJe1BDSV9WRU5ET1JfSURfRkFSU0lURSwgUENJX0RFVklD RV9JRF9GQVJTSVRFX1QyVSwgUENJX0FOWV9JRCwgCisJIFBDSV9BTllfSUQsIDAsIDAsIEZTVF9U WVBFX1QyVX0sCisKKwl7UENJX1ZFTkRPUl9JRF9GQVJTSVRFLCBQQ0lfREVWSUNFX0lEX0ZBUlNJ VEVfVDRVLCBQQ0lfQU5ZX0lELCAKKwkgUENJX0FOWV9JRCwgMCwgMCwgRlNUX1RZUEVfVDRVfSwK KworCXtQQ0lfVkVORE9SX0lEX0ZBUlNJVEUsIFBDSV9ERVZJQ0VfSURfRkFSU0lURV9URTEsIFBD SV9BTllfSUQsIAorCSBQQ0lfQU5ZX0lELCAwLCAwLCBGU1RfVFlQRV9URTF9LAorCisJe1BDSV9W RU5ET1JfSURfRkFSU0lURSwgUENJX0RFVklDRV9JRF9GQVJTSVRFX1RFMUMsIFBDSV9BTllfSUQs IAorCSBQQ0lfQU5ZX0lELCAwLCAwLCBGU1RfVFlQRV9URTF9LAorCXswLH0JCQkvKiBFbmQgKi8K IH07CiAKLU1PRFVMRV9ERVZJQ0VfVEFCTEUgKCBwY2ksIGZzdF9wY2lfZGV2X2lkICk7CitNT0RV TEVfREVWSUNFX1RBQkxFKHBjaSwgZnN0X3BjaV9kZXZfaWQpOworCisvKgorICogICAgICBEZXZp Y2UgRHJpdmVyIFdvcmsgUXVldWVzCisgKgorICogICAgICBTbyB0aGF0IHdlIGRvbid0IHNwZW5k IHRvbyBtdWNoIHRpbWUgcHJvY2Vzc2luZyBldmVudHMgaW4gdGhlIAorICogICAgICBJbnRlcnJ1 cHQgU2VydmljZSByb3V0aW5lLCB3ZSB3aWxsIGRlY2xhcmUgYSB3b3JrIHF1ZXVlIHBlciBDYXJk IAorICogICAgICBhbmQgbWFrZSB0aGUgSVNSIHNjaGVkdWxlIGEgdGFzayBpbiB0aGUgcXVldWUg Zm9yIGxhdGVyIGV4ZWN1dGlvbi4KKyAqLworCitzdGF0aWMgdm9pZCBkb19ib3R0b21faGFsZl90 eChzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCk7CitzdGF0aWMgdm9pZCBkb19ib3R0b21faGFs Zl9yeChzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCk7CitzdGF0aWMgdm9pZCBmc3RfcHJvY2Vz c190eF93b3JrX3EodW5zaWduZWQgbG9uZyB3b3JrX3EpOworc3RhdGljIHZvaWQgZnN0X3Byb2Nl c3NfaW50X3dvcmtfcSh1bnNpZ25lZCBsb25nIHdvcmtfcSk7CisKK0RFQ0xBUkVfVEFTS0xFVChm c3RfdHhfdGFzaywgZnN0X3Byb2Nlc3NfdHhfd29ya19xLCAwKTsKK0RFQ0xBUkVfVEFTS0xFVChm c3RfaW50X3Rhc2ssIGZzdF9wcm9jZXNzX2ludF93b3JrX3EsIDApOworCitzdHJ1Y3QgZnN0X2Nh cmRfaW5mbyAqZnN0X2NhcmRfYXJyYXlbRlNUX01BWF9DQVJEU107CitzcGlubG9ja190IGZzdF93 b3JrX3FfbG9jazsKK3U2NCBmc3Rfd29ya190eHE7Cit1NjQgZnN0X3dvcmtfaW50cTsKKworc3Rh dGljIHZvaWQKK2ZzdF9xX3dvcmtfaXRlbSh1NjQgKiBxdWV1ZSwgaW50IGNhcmRfaW5kZXgpCit7 CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwl1NjQgbWFzazsKIAorCS8qCisJICogR3JhYiB0aGUg cXVldWUgZXhjbHVzaXZlbHkKKwkgKi8KKwlzcGluX2xvY2tfaXJxc2F2ZSgmZnN0X3dvcmtfcV9s b2NrLCBmbGFncyk7CisKKwkvKgorCSAqIE1ha2luZyBhbiBlbnRyeSBpbiB0aGUgcXVldWUgaXMg c2ltcGx5IGEgbWF0dGVyIG9mIHNldHRpbmcKKwkgKiBhIGJpdCBmb3IgdGhlIGNhcmQgaW5kaWNh dGluZyB0aGF0IHRoZXJlIGlzIHdvcmsgdG8gZG8gaW4gdGhlCisJICogYm90dG9tIGhhbGYgZm9y IHRoZSBjYXJkLiAgTm90ZSB0aGUgbGltaXRhdGlvbiBvZiA2NCBjYXJkcy4KKwkgKiBUaGF0IG91 Z2h0IHRvIGJlIGVub3VnaAorCSAqLworCW1hc2sgPSAxIDw8IGNhcmRfaW5kZXg7CisJKnF1ZXVl IHw9IG1hc2s7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZnN0X3dvcmtfcV9sb2NrLCBmbGFn cyk7Cit9CisKK3N0YXRpYyB2b2lkCitmc3RfcHJvY2Vzc190eF93b3JrX3EodW5zaWduZWQgbG9u ZyB3b3JrX3EpCit7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKwl1NjQgd29ya190eHE7CisJaW50 IGk7CisKKwkvKgorCSAqIEdyYWIgdGhlIHF1ZXVlIGV4Y2x1c2l2ZWx5CisJICovCisJZGJnKERC R19UWCwgImZzdF9wcm9jZXNzX3R4X3dvcmtfcVxuIik7CisJc3Bpbl9sb2NrX2lycXNhdmUoJmZz dF93b3JrX3FfbG9jaywgZmxhZ3MpOworCXdvcmtfdHhxID0gZnN0X3dvcmtfdHhxOworCWZzdF93 b3JrX3R4cSA9IDA7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmZnN0X3dvcmtfcV9sb2NrLCBm bGFncyk7CisKKwkvKgorCSAqIENhbGwgdGhlIGJvdHRvbSBoYWxmIGZvciBlYWNoIGNhcmQgd2l0 aCB3b3JrIHdhaXRpbmcKKwkgKi8KKwlmb3IgKGkgPSAwOyBpIDwgRlNUX01BWF9DQVJEUzsgaSsr KSB7CisJCWlmICh3b3JrX3R4cSAmIDB4MDEpIHsKKwkJCWlmIChmc3RfY2FyZF9hcnJheVtpXSAh PSBOVUxMKSB7CisJCQkJZGJnKERCR19UWCwgIkNhbGxpbmcgdHggYmggZm9yIGNhcmQgJWRcbiIs IGkpOworCQkJCWRvX2JvdHRvbV9oYWxmX3R4KGZzdF9jYXJkX2FycmF5W2ldKTsKKwkJCX0KKwkJ fQorCQl3b3JrX3R4cSA9IHdvcmtfdHhxID4+IDE7CisJfQorfQorCitzdGF0aWMgdm9pZAorZnN0 X3Byb2Nlc3NfaW50X3dvcmtfcSh1bnNpZ25lZCBsb25nIHdvcmtfcSkKK3sKKwl1bnNpZ25lZCBs b25nIGZsYWdzOworCXU2NCB3b3JrX2ludHE7CisJaW50IGk7CisKKwkvKgorCSAqIEdyYWIgdGhl IHF1ZXVlIGV4Y2x1c2l2ZWx5CisJICovCisJZGJnKERCR19JTlRSLCAiZnN0X3Byb2Nlc3NfaW50 X3dvcmtfcVxuIik7CisJc3Bpbl9sb2NrX2lycXNhdmUoJmZzdF93b3JrX3FfbG9jaywgZmxhZ3Mp OworCXdvcmtfaW50cSA9IGZzdF93b3JrX2ludHE7CisJZnN0X3dvcmtfaW50cSA9IDA7CisJc3Bp bl91bmxvY2tfaXJxcmVzdG9yZSgmZnN0X3dvcmtfcV9sb2NrLCBmbGFncyk7CisKKwkvKgorCSAq IENhbGwgdGhlIGJvdHRvbSBoYWxmIGZvciBlYWNoIGNhcmQgd2l0aCB3b3JrIHdhaXRpbmcKKwkg Ki8KKwlmb3IgKGkgPSAwOyBpIDwgRlNUX01BWF9DQVJEUzsgaSsrKSB7CisJCWlmICh3b3JrX2lu dHEgJiAweDAxKSB7CisJCQlpZiAoZnN0X2NhcmRfYXJyYXlbaV0gIT0gTlVMTCkgeworCQkJCWRi ZyhEQkdfSU5UUiwKKwkJCQkgICAgIkNhbGxpbmcgcnggJiB0eCBiaCBmb3IgY2FyZCAlZFxuIiwg aSk7CisJCQkJZG9fYm90dG9tX2hhbGZfcngoZnN0X2NhcmRfYXJyYXlbaV0pOworCQkJCWRvX2Jv dHRvbV9oYWxmX3R4KGZzdF9jYXJkX2FycmF5W2ldKTsKKwkJCX0KKwkJfQorCQl3b3JrX2ludHEg PSB3b3JrX2ludHEgPj4gMTsKKwl9Cit9CiAKIC8qICAgICAgQ2FyZCBjb250cm9sIGZ1bmN0aW9u cwogICogICAgICA9PT09PT09PT09PT09PT09PT09PT09CkBAIC00MzYsMTAwMiArNjcwLDE3MDkg QEAKICAqIFVzZWQgdG8gYmUgYSBzaW1wbGUgd3JpdGUgdG8gY2FyZCBjb250cm9sIHNwYWNlIGJ1 dCBhIGdsaXRjaCBpbiB0aGUgbGF0ZXN0CiAgKiBBTUQgQW0xODZDSCBwcm9jZXNzb3IgbWVhbnMg dGhhdCB3ZSBub3cgaGF2ZSB0byBkbyBpdCBieSBhc3NlcnRpbmcgYW5kIGRlLQogICogYXNzZXJ0 aW5nIHRoZSBQTFggY2hpcCBQQ0kgQWRhcHRlciBTb2Z0d2FyZSBSZXNldC4gQml0IDMwIGluIENO VFJMIHJlZ2lzdGVyCi0gKiBhdCBvZmZzZXQgMHg1MC4KKyAqIGF0IG9mZnNldCA5MDUyX0NOVFJM LiAgTm90ZSB0aGUgdXBkYXRlcyBmb3IgdGhlIFRYVS4KICAqLwogc3RhdGljIGlubGluZSB2b2lk Ci1mc3RfY3B1cmVzZXQgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCApCitmc3RfY3B1cmVz ZXQoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQpCiB7Ci0gICAgICAgIHVuc2lnbmVkIGludCBy ZWd2YWw7CisJdW5zaWduZWQgY2hhciBpbnRlcnJ1cHRfbGluZV9yZWdpc3RlcjsKKwl1bnNpZ25l ZCBsb25nIGogPSBqaWZmaWVzICsgMTsKKwl1bnNpZ25lZCBpbnQgcmVndmFsOworCisJaWYgKGNh cmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYVSkgeworCQlpZiAocGNpX3JlYWRfY29uZmlnX2J5 dGUKKwkJICAgIChjYXJkLT5kZXZpY2UsIFBDSV9JTlRFUlJVUFRfTElORSwgJmludGVycnVwdF9s aW5lX3JlZ2lzdGVyKSkgeworCQkJZGJnKERCR19BU1MsCisJCQkgICAgIkVycm9yIGluIHJlYWRp bmcgaW50ZXJydXB0IGxpbmUgcmVnaXN0ZXJcbiIpOworCQl9CisJCS8qCisJCSAqIEFzc2VydCBQ TFggc29mdHdhcmUgcmVzZXQgYW5kIEFtMTg2IGhhcmR3YXJlIHJlc2V0CisJCSAqIGFuZCB0aGVu IGRlYXNzZXJ0IHRoZSBQTFggc29mdHdhcmUgcmVzZXQgYnV0IDE4NiBzdGlsbCBpbiByZXNldAor CQkgKi8KKwkJb3V0dygweDQ0MGYsIGNhcmQtPnBjaV9jb25mICsgQ05UUkxfOTA1NCArIDIpOwor CQlvdXR3KDB4MDQwZiwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDU0ICsgMik7CisJCS8qCisJ CSAqIFdlIGFyZSBkZWxheWluZyBoZXJlIHRvIGFsbG93IHRoZSA5MDU0IHRvIHJlc2V0IGl0c2Vs ZgorCQkgKi8KKwkJaiA9IGppZmZpZXMgKyAxOworCQl3aGlsZSAoamlmZmllcyA8IGopCisJCQkv KiBEbyBub3RoaW5nICovIDsKKwkJb3V0dygweDI0MGYsIGNhcmQtPnBjaV9jb25mICsgQ05UUkxf OTA1NCArIDIpOworCQkvKgorCQkgKiBXZSBhcmUgZGVsYXlpbmcgaGVyZSB0byBhbGxvdyB0aGUg OTA1NCB0byByZWxvYWQgaXRzIGVlcHJvbQorCQkgKi8KKwkJaiA9IGppZmZpZXMgKyAxOworCQl3 aGlsZSAoamlmZmllcyA8IGopCisJCQkvKiBEbyBub3RoaW5nICovIDsKKwkJb3V0dygweDA0MGYs IGNhcmQtPnBjaV9jb25mICsgQ05UUkxfOTA1NCArIDIpOworCisJCWlmIChwY2lfd3JpdGVfY29u ZmlnX2J5dGUKKwkJICAgIChjYXJkLT5kZXZpY2UsIFBDSV9JTlRFUlJVUFRfTElORSwgaW50ZXJy dXB0X2xpbmVfcmVnaXN0ZXIpKSB7CisJCQlkYmcoREJHX0FTUywKKwkJCSAgICAiRXJyb3IgaW4g d3JpdGluZyBpbnRlcnJ1cHQgbGluZSByZWdpc3RlclxuIik7CisJCX0KIAotICAgICAgICByZWd2 YWwgPSBpbmwgKCBjYXJkLT5wY2lfY29uZiArIDB4NTAgKTsKKwl9IGVsc2UgeworCQlyZWd2YWwg PSBpbmwoY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDUyKTsKIAotICAgICAgICBvdXRsICggcmVn dmFsIHwgIDB4NDAwMDAwMDAsIGNhcmQtPnBjaV9jb25mICsgMHg1MCApOwotICAgICAgICBvdXRs ICggcmVndmFsICYgfjB4NDAwMDAwMDAsIGNhcmQtPnBjaV9jb25mICsgMHg1MCApOworCQlvdXRs KHJlZ3ZhbCB8IDB4NDAwMDAwMDAsIGNhcmQtPnBjaV9jb25mICsgQ05UUkxfOTA1Mik7CisJCW91 dGwocmVndmFsICYgfjB4NDAwMDAwMDAsIGNhcmQtPnBjaV9jb25mICsgQ05UUkxfOTA1Mik7CisJ fQogfQogCiAvKiAgICAgIFJlbGVhc2UgdGhlIHByb2Nlc3NvciBmcm9tIHJlc2V0CiAgKi8KIHN0 YXRpYyBpbmxpbmUgdm9pZAotZnN0X2NwdXJlbGVhc2UgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAq Y2FyZCApCitmc3RfY3B1cmVsZWFzZShzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCkKIHsKLSAg ICAgICAgKHZvaWQpIHJlYWRiICggY2FyZC0+Y3RsbWVtICk7CisJaWYgKGNhcmQtPmZhbWlseSA9 PSBGU1RfRkFNSUxZX1RYVSkgeworCQkvKgorCQkgKiBGb3JjZSBwb3N0ZWQgd3JpdGVzIHRvIGNv bXBsZXRlCisJCSAqLworCQkodm9pZCkgcmVhZGIoY2FyZC0+bWVtKTsKKworCQkvKgorCQkgKiBS ZWxlYXNlIExSRVNFVCBETyA9IDEKKwkJICogVGhlbiByZWxlYXNlIExvY2FsIEhvbGQsIERPID0g MQorCQkgKi8KKwkJb3V0dygweDA0MGUsIGNhcmQtPnBjaV9jb25mICsgQ05UUkxfOTA1NCArIDIp OworCQlvdXR3KDB4MDQwZiwgY2FyZC0+cGNpX2NvbmYgKyBDTlRSTF85MDU0ICsgMik7CisJfSBl bHNlIHsKKwkJKHZvaWQpIHJlYWRiKGNhcmQtPmN0bG1lbSk7CisJfQogfQogCiAvKiAgICAgIENs ZWFyIHRoZSBjYXJkcyBpbnRlcnJ1cHQgZmxhZwogICovCiBzdGF0aWMgaW5saW5lIHZvaWQKLWZz dF9jbGVhcl9pbnRyICggc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQgKQorZnN0X2NsZWFyX2lu dHIoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQpCiB7Ci0gICAgICAgIC8qIFBva2UgdGhlIGFw cHJvcHJpYXRlIFBMWCBjaGlwIHJlZ2lzdGVyIChzYW1lIGFzIGVuYWJsaW5nIGludGVycnVwdHMp Ci0gICAgICAgICAqLwotICAgICAgICBvdXR3ICggMHgwNTQzLCBjYXJkLT5wY2lfY29uZiArIDB4 NEMgKTsKKwlpZiAoY2FyZC0+ZmFtaWx5ID09IEZTVF9GQU1JTFlfVFhVKSB7CisJCSh2b2lkKSBy ZWFkYihjYXJkLT5jdGxtZW0pOworCX0gZWxzZSB7CisJCS8qIFBva2UgdGhlIGFwcHJvcHJpYXRl IFBMWCBjaGlwIHJlZ2lzdGVyIChzYW1lIGFzIGVuYWJsaW5nIGludGVycnVwdHMpCisJCSAqLwor CQlvdXR3KDB4MDU0MywgY2FyZC0+cGNpX2NvbmYgKyBJTlRDU1JfOTA1Mik7CisJfQorfQorCisv KiAgICAgIEVuYWJsZSBjYXJkIGludGVycnVwdHMKKyAqLworc3RhdGljIGlubGluZSB2b2lkCitm c3RfZW5hYmxlX2ludHIoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQpCit7CisJaWYgKGNhcmQt PmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYVSkgeworCQlvdXRsKDB4MGYwYzA5MDAsIGNhcmQtPnBj aV9jb25mICsgSU5UQ1NSXzkwNTQpOworCX0gZWxzZSB7CisJCW91dHcoMHgwNTQzLCBjYXJkLT5w Y2lfY29uZiArIElOVENTUl85MDUyKTsKKwl9CiB9CiAKIC8qICAgICAgRGlzYWJsZSBjYXJkIGlu dGVycnVwdHMKICAqLwogc3RhdGljIGlubGluZSB2b2lkCi1mc3RfZGlzYWJsZV9pbnRyICggc3Ry dWN0IGZzdF9jYXJkX2luZm8gKmNhcmQgKQorZnN0X2Rpc2FibGVfaW50cihzdHJ1Y3QgZnN0X2Nh cmRfaW5mbyAqY2FyZCkKIHsKLSAgICAgICAgb3V0dyAoIDB4MDAwMCwgY2FyZC0+cGNpX2NvbmYg KyAweDRDICk7CisJaWYgKGNhcmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYVSkgeworCQlvdXRs KDB4MDAwMDAwMDAsIGNhcmQtPnBjaV9jb25mICsgSU5UQ1NSXzkwNTQpOworCX0gZWxzZSB7CisJ CW91dHcoMHgwMDAwLCBjYXJkLT5wY2lfY29uZiArIElOVENTUl85MDUyKTsKKwl9CiB9CiAKKy8q ICAgICAgUHJvY2VzcyB0aGUgcmVzdWx0IG9mIHRyeWluZyB0byBwYXNzIGEgcmVjaWV2ZWQgZnJh bWUgdXAgdGhlIHN0YWNrCisgKi8KK3N0YXRpYyB2b2lkCitmc3RfcHJvY2Vzc19yeF9zdGF0dXMo aW50IHJ4X3N0YXR1cywgY2hhciAqbmFtZSkKK3sKKwlzd2l0Y2ggKHJ4X3N0YXR1cykgeworCWNh c2UgTkVUX1JYX1NVQ0NFU1M6CisJCXsKKwkJCS8qCisJCQkgKiBOb3RoaW5nIHRvIGRvIGhlcmUK KwkJCSAqLworCQkJYnJlYWs7CisJCX0KKworCWNhc2UgTkVUX1JYX0NOX0xPVzoKKwkJeworCQkJ ZGJnKERCR19BU1MsICIlczogUmVjZWl2ZSBMb3cgQ29uZ2VzdGlvblxuIiwgbmFtZSk7CisJCQli cmVhazsKKwkJfQorCisJY2FzZSBORVRfUlhfQ05fTU9EOgorCQl7CisJCQlkYmcoREJHX0FTUywg IiVzOiBSZWNlaXZlIE1vZGVyYXRlIENvbmdlc3Rpb25cbiIsIG5hbWUpOworCQkJYnJlYWs7CisJ CX0KKworCWNhc2UgTkVUX1JYX0NOX0hJR0g6CisJCXsKKwkJCWRiZyhEQkdfQVNTLCAiJXM6IFJl Y2VpdmUgSGlnaCBDb25nZXN0aW9uXG4iLCBuYW1lKTsKKwkJCWJyZWFrOworCQl9CisKKwljYXNl IE5FVF9SWF9EUk9QOgorCQl7CisJCQlkYmcoREJHX0FTUywgIiVzOiBSZWNlaXZlZCBwYWNrZXQg ZHJvcHBlZFxuIiwgbmFtZSk7CisJCQlicmVhazsKKwkJfQorCX0KK30KKworLyogICAgICBJbml0 aWxhaXNlIERNQSBmb3IgUExYIDkwNTQKKyAqLworc3RhdGljIGlubGluZSB2b2lkCitmc3RfaW5p dF9kbWEoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQpCit7CisJLyoKKwkgKiBUaGlzIGlzIG9u bHkgcmVxdWlyZWQgZm9yIHRoZSBQTFggOTA1NAorCSAqLworCWlmIChjYXJkLT5mYW1pbHkgPT0g RlNUX0ZBTUlMWV9UWFUpIHsKKwkgICAgICAgIHBjaV9zZXRfbWFzdGVyKGNhcmQtPmRldmljZSk7 CisJCW91dGwoMHgwMDAyMDQ0MSwgY2FyZC0+cGNpX2NvbmYgKyBETUFNT0RFMCk7CisJCW91dGwo MHgwMDAyMDQ0MSwgY2FyZC0+cGNpX2NvbmYgKyBETUFNT0RFMSk7CisJCW91dGwoMHgwLCBjYXJk LT5wY2lfY29uZiArIERNQVRIUik7CisJfQorfQorCisvKiAgICAgIFR4IGRtYSBjb21wbGV0ZSBp bnRlcnJ1cHQKKyAqLworc3RhdGljIHZvaWQKK2ZzdF90eF9kbWFfY29tcGxldGUoc3RydWN0IGZz dF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCQkgICAgaW50 IGxlbiwgaW50IHR4cG9zKQoreworCS8qCisJICogRXZlcnl0aGluZyBpcyBub3cgc2V0LCBqdXN0 IHRlbGwgdGhlIGNhcmQgdG8gZ28KKwkgKi8KKwlkYmcoREJHX1RYLCAiZnN0X3R4X2RtYV9jb21w bGV0ZVxuIik7CisJRlNUX1dSQihjYXJkLCB0eERlc2NyUmluZ1twb3J0LT5pbmRleF1bdHhwb3Nd LmJpdHMsCisJCURNQV9PV04gfCBUWF9TVFAgfCBUWF9FTlApOworCXBvcnQtPmhkbGMuc3RhdHMu dHhfcGFja2V0cysrOworCXBvcnQtPmhkbGMuc3RhdHMudHhfYnl0ZXMgKz0gbGVuOworCXBvcnRf dG9fZGV2KHBvcnQpLT50cmFuc19zdGFydCA9IGppZmZpZXM7Cit9CisKKy8qICAgICAgUnggZG1h IGNvbXBsZXRlIGludGVycnVwdAorICovCitzdGF0aWMgdm9pZAorZnN0X3J4X2RtYV9jb21wbGV0 ZShzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQs CisJCSAgICBpbnQgbGVuLCBzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBpbnQgcnhwKQoreworCisJaW50 IHBpOworCWludCByeF9zdGF0dXM7CisKKwlkYmcoREJHX1RYLCAiZnN0X3J4X2RtYV9jb21wbGV0 ZVxuIik7CisJcGkgPSBwb3J0LT5pbmRleDsKKwltZW1jcHkoc2tiX3B1dChza2IsIGxlbiksIGNh cmQtPnJ4X2RtYV9oYW5kbGVfaG9zdCwgbGVuKTsKKworCS8qIFJlc2V0IGJ1ZmZlciBkZXNjcmlw dG9yICovCisJRlNUX1dSQihjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dO KTsKKworCS8qIFVwZGF0ZSBzdGF0cyAqLworCXBvcnQtPmhkbGMuc3RhdHMucnhfcGFja2V0cysr OworCXBvcnQtPmhkbGMuc3RhdHMucnhfYnl0ZXMgKz0gbGVuOworCisJLyogUHVzaCB1cHN0cmVh bSAqLworCWRiZyhEQkdfUlgsICJQdXNoaW5nIHRoZSBmcmFtZSB1cCB0aGUgc3RhY2tcbiIpOwor CXNrYi0+bWFjLnJhdyA9IHNrYi0+ZGF0YTsKKwlza2ItPmRldiA9IGhkbGNfdG9fZGV2KCZwb3J0 LT5oZGxjKTsKKwlpZiAocG9ydC0+bW9kZSA9PSBGU1RfUkFXKSB7CisJCS8qCisJCSAqIE1hcmsg aXQgZm9yIG91ciBvd24gcmF3IHNvY2tldHMgaW50ZXJmYWNlCisJCSAqLworCQlza2ItPnByb3Rv Y29sID0gaHRvbnMoRVRIX1BfQ1VTVCk7CisJCXNrYi0+cGt0X3R5cGUgPSBQQUNLRVRfSE9TVDsK Kwl9IGVsc2UgeworCQlza2ItPnByb3RvY29sID0gaGRsY190eXBlX3RyYW5zKHNrYiwgc2tiLT5k ZXYpOworCX0KKwlyeF9zdGF0dXMgPSBuZXRpZl9yeChza2IpOworCWZzdF9wcm9jZXNzX3J4X3N0 YXR1cyhyeF9zdGF0dXMsIHBvcnRfdG9fZGV2KHBvcnQpLT5uYW1lKTsKKwlpZiAocnhfc3RhdHVz ID09IE5FVF9SWF9EUk9QKQorCQlwb3J0LT5oZGxjLnN0YXRzLnJ4X2Ryb3BwZWQrKzsKKwlwb3J0 X3RvX2Rldihwb3J0KS0+bGFzdF9yeCA9IGppZmZpZXM7Cit9CisKKy8qCisgKiAgICAgIFJlY2Vp dmUgYSBmcmFtZSB0aHJvdWdoIHRoZSBETUEKKyAqLworc3RhdGljIGlubGluZSB2b2lkCitmc3Rf cnhfZG1hKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCB1bnNpZ25lZCBjaGFyICpza2IsCisJ ICAgdW5zaWduZWQgY2hhciAqbWVtLCBpbnQgbGVuKQoreworCS8qCisJICogVGhpcyByb3V0aW5l IHdpbGwgc2V0dXAgdGhlIERNQSBhbmQgc3RhcnQgaXQKKwkgKi8KKworCWRiZyhEQkdfUlgsICJJ biBmc3RfcnhfZG1hICVwICVwICVkXG4iLCBza2IsIG1lbSwgbGVuKTsKKwlpZiAoY2FyZC0+ZG1h cnhfaW5fcHJvZ3Jlc3MpIHsKKwkJZGJnKERCR19BU1MsICJJbiBmc3RfcnhfZG1hIHdoaWxlIGRt YSBpbiBwcm9ncmVzc1xuIik7CisJfQorCisJb3V0bCgodW5zaWduZWQgbG9uZykgc2tiLCBjYXJk LT5wY2lfY29uZiArIERNQVBBRFIwKTsJLyogQ29weSB0byBoZXJlICovCisJb3V0bCgodW5zaWdu ZWQgbG9uZykgbWVtLCBjYXJkLT5wY2lfY29uZiArIERNQUxBRFIwKTsJLyogZnJvbSBoZXJlICov CisJb3V0bChsZW4sIGNhcmQtPnBjaV9jb25mICsgRE1BU0laMCk7CS8qIGZvciB0aGlzIGxlbmd0 aCAqLworCW91dGwoMHgwMDAwMDAwMGMsIGNhcmQtPnBjaV9jb25mICsgRE1BRFBSMCk7CS8qIElu IHRoaXMgZGlyZWN0aW9uICovCisKKwkvKgorCSAqIFdlIHVzZSB0aGUgZG1hcnhfaW5fcHJvZ3Jl c3MgZmxhZyB0byBmbGFnIHRoZSBjaGFubmVsIGFzIGJ1c3kKKwkgKi8KKwljYXJkLT5kbWFyeF9p bl9wcm9ncmVzcyA9IDE7CisJb3V0YigweDAzLCBjYXJkLT5wY2lfY29uZiArIERNQUNTUjApOwkv KiBTdGFydCB0aGUgdHJhbnNmZXIgKi8KK30KKworLyoKKyAqICAgICAgU2VuZCBhIGZyYW1lIHRo cm91Z2ggdGhlIERNQQorICovCitzdGF0aWMgaW5saW5lIHZvaWQKK2ZzdF90eF9kbWEoc3RydWN0 IGZzdF9jYXJkX2luZm8gKmNhcmQsIHVuc2lnbmVkIGNoYXIgKnNrYiwKKwkgICB1bnNpZ25lZCBj aGFyICptZW0sIGludCBsZW4pCit7CisJLyoKKwkgKiBUaGlzIHJvdXRpbmUgd2lsbCBzZXR1cCB0 aGUgRE1BIGFuZCBzdGFydCBpdC4KKwkgKi8KKworCWRiZyhEQkdfVFgsICJJbiBmc3RfdHhfZG1h ICVwICVwICVkXG4iLCBza2IsIG1lbSwgbGVuKTsKKwlpZiAoY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jl c3MpIHsKKwkJZGJnKERCR19BU1MsICJJbiBmc3RfdHhfZG1hIHdoaWxlIGRtYSBpbiBwcm9ncmVz c1xuIik7CisJfQorCisJb3V0bCgodW5zaWduZWQgbG9uZykgc2tiLCBjYXJkLT5wY2lfY29uZiAr IERNQVBBRFIxKTsJLyogQ29weSBmcm9tIGhlcmUgKi8KKwlvdXRsKCh1bnNpZ25lZCBsb25nKSBt ZW0sIGNhcmQtPnBjaV9jb25mICsgRE1BTEFEUjEpOwkvKiB0byBoZXJlICovCisJb3V0bChsZW4s IGNhcmQtPnBjaV9jb25mICsgRE1BU0laMSk7CS8qIGZvciB0aGlzIGxlbmd0aCAqLworCW91dGwo MHgwMDAwMDAwMDQsIGNhcmQtPnBjaV9jb25mICsgRE1BRFBSMSk7CS8qIEluIHRoaXMgZGlyZWN0 aW9uICovCisKKwkvKgorCSAqIFdlIHVzZSB0aGUgZG1hdHhfaW5fcHJvZ3Jlc3MgdG8gZmxhZyB0 aGUgY2hhbm5lbCBhcyBidXN5CisJICovCisJY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MgPSAxOwor CW91dGIoMHgwMywgY2FyZC0+cGNpX2NvbmYgKyBETUFDU1IxKTsJLyogU3RhcnQgdGhlIHRyYW5z ZmVyICovCit9CiAKIC8qICAgICAgSXNzdWUgYSBNYWlsYm94IGNvbW1hbmQgZm9yIGEgcG9ydC4K ICAqICAgICAgTm90ZSB3ZSBpc3N1ZSB0aGVtIG9uIGEgZmlyZSBhbmQgZm9yZ2V0IGJhc2lzLCBu b3QgZXhwZWN0aW5nIHRvIHNlZSBhbgogICogICAgICBlcnJvciBhbmQgbm90IHdhaXRpbmcgZm9y IGNvbXBsZXRpb24uCiAgKi8KIHN0YXRpYyB2b2lkCi1mc3RfaXNzdWVfY21kICggc3RydWN0IGZz dF9wb3J0X2luZm8gKnBvcnQsIHVuc2lnbmVkIHNob3J0IGNtZCApCitmc3RfaXNzdWVfY21kKHN0 cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LCB1bnNpZ25lZCBzaG9ydCBjbWQpCiB7Ci0gICAgICAg IHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICB1bnNpZ25lZCBzaG9ydCBtYnZh bDsKLSAgICAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsKLSAgICAgICAgaW50IHNhZmV0eTsKLQot ICAgICAgICBjYXJkID0gcG9ydC0+Y2FyZDsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUgKCAm Y2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOwotICAgICAgICBtYnZhbCA9IEZTVF9SRFcgKCBjYXJk LCBwb3J0TWFpbGJveFtwb3J0LT5pbmRleF1bMF0pOwotCi0gICAgICAgIHNhZmV0eSA9IDA7Ci0g ICAgICAgIC8qIFdhaXQgZm9yIGFueSBwcmV2aW91cyBjb21tYW5kIHRvIGNvbXBsZXRlICovCi0g ICAgICAgIHdoaWxlICggbWJ2YWwgPiBOQUsgKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAg c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0gICAg ICAgICAgICAgICAgc2NoZWR1bGVfdGltZW91dCAoIDEgKTsKLSAgICAgICAgICAgICAgICBzcGlu X2xvY2tfaXJxc2F2ZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0KLSAgICAgICAgICAg ICAgICBpZiAoICsrc2FmZXR5ID4gMTAwMCApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAg ICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIk1haWxib3ggc2FmZXR5IHRpbWVvdXRcbiIpOwot ICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgICAgICAgICAgfQotCi0gICAg ICAgICAgICAgICAgbWJ2YWwgPSBGU1RfUkRXICggY2FyZCwgcG9ydE1haWxib3hbcG9ydC0+aW5k ZXhdWzBdKTsKLSAgICAgICAgfQotICAgICAgICBpZiAoIHNhZmV0eSA+IDAgKQotICAgICAgICB7 Ci0gICAgICAgICAgICAgICAgZGJnICggREJHX0NNRCwiTWFpbGJveCBjbGVhciBhZnRlciAlZCBq aWZmaWVzXG4iLCBzYWZldHkgKTsKLSAgICAgICAgfQotICAgICAgICBpZiAoIG1idmFsID09IE5B SyApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfQ01ELCJpc3N1ZV9jbWQ6 IHByZXZpb3VzIGNvbW1hbmQgd2FzIE5BSydkXG4iKTsKLSAgICAgICAgfQotCi0gICAgICAgIEZT VF9XUlcgKCBjYXJkLCBwb3J0TWFpbGJveFtwb3J0LT5pbmRleF1bMF0sIGNtZCApOwotCi0gICAg ICAgIGlmICggY21kID09IEFCT1JUVFggfHwgY21kID09IFNUQVJUUE9SVCApCi0gICAgICAgIHsK LSAgICAgICAgICAgICAgICBwb3J0LT50eHBvcyAgPSAwOwotICAgICAgICAgICAgICAgIHBvcnQt PnR4aXBvcyA9IDA7Ci0gICAgICAgICAgICAgICAgcG9ydC0+dHhjbnQgID0gMDsKLSAgICAgICAg fQorCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOworCXVuc2lnbmVkIHNob3J0IG1idmFsOwor CXVuc2lnbmVkIGxvbmcgZmxhZ3M7CisJaW50IHNhZmV0eTsKKworCWNhcmQgPSBwb3J0LT5jYXJk OworCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwltYnZhbCA9 IEZTVF9SRFcoY2FyZCwgcG9ydE1haWxib3hbcG9ydC0+aW5kZXhdWzBdKTsKKworCXNhZmV0eSA9 IDA7CisJLyogV2FpdCBmb3IgYW55IHByZXZpb3VzIGNvbW1hbmQgdG8gY29tcGxldGUgKi8KKwl3 aGlsZSAobWJ2YWwgPiBOQUspIHsKKwkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2Fy ZF9sb2NrLCBmbGFncyk7CisJCXNjaGVkdWxlX3RpbWVvdXQoMSk7CisJCXNwaW5fbG9ja19pcnFz YXZlKCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKworCQlpZiAoKytzYWZldHkgPiAyMDAwKSB7 CisJCQlwcmludGtfZXJyKCJNYWlsYm94IHNhZmV0eSB0aW1lb3V0XG4iKTsKKwkJCWJyZWFrOwor CQl9CiAKLSAgICAgICAgc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ss IGZsYWdzICk7Ci19CisJCW1idmFsID0gRlNUX1JEVyhjYXJkLCBwb3J0TWFpbGJveFtwb3J0LT5p bmRleF1bMF0pOworCX0KKwlpZiAoc2FmZXR5ID4gMCkgeworCQlkYmcoREJHX0NNRCwgIk1haWxi b3ggY2xlYXIgYWZ0ZXIgJWQgamlmZmllc1xuIiwgc2FmZXR5KTsKKwl9CisJaWYgKG1idmFsID09 IE5BSykgeworCQlkYmcoREJHX0NNRCwgImlzc3VlX2NtZDogcHJldmlvdXMgY29tbWFuZCB3YXMg TkFLJ2RcbiIpOworCX0KKworCUZTVF9XUlcoY2FyZCwgcG9ydE1haWxib3hbcG9ydC0+aW5kZXhd WzBdLCBjbWQpOwogCisJaWYgKGNtZCA9PSBBQk9SVFRYIHx8IGNtZCA9PSBTVEFSVFBPUlQpIHsK KwkJcG9ydC0+dHhwb3MgPSAwOworCQlwb3J0LT50eGlwb3MgPSAwOworCQlwb3J0LT5zdGFydCA9 IDA7CisJfQorCisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+Y2FyZF9sb2NrLCBmbGFn cyk7Cit9CiAKIC8qICAgICAgUG9ydCBvdXRwdXQgc2lnbmFscyBjb250cm9sCiAgKi8KIHN0YXRp YyBpbmxpbmUgdm9pZAotZnN0X29wX3JhaXNlICggc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQs IHVuc2lnbmVkIGludCBvdXRwdXRzICkKK2ZzdF9vcF9yYWlzZShzdHJ1Y3QgZnN0X3BvcnRfaW5m byAqcG9ydCwgdW5zaWduZWQgaW50IG91dHB1dHMpCiB7Ci0gICAgICAgIG91dHB1dHMgfD0gRlNU X1JETCAoIHBvcnQtPmNhcmQsIHYyNE9wU3RzW3BvcnQtPmluZGV4XSk7Ci0gICAgICAgIEZTVF9X UkwgKCBwb3J0LT5jYXJkLCB2MjRPcFN0c1twb3J0LT5pbmRleF0sIG91dHB1dHMgKTsKKwlvdXRw dXRzIHw9IEZTVF9SREwocG9ydC0+Y2FyZCwgdjI0T3BTdHNbcG9ydC0+aW5kZXhdKTsKKwlGU1Rf V1JMKHBvcnQtPmNhcmQsIHYyNE9wU3RzW3BvcnQtPmluZGV4XSwgb3V0cHV0cyk7CiAKLSAgICAg ICAgaWYgKCBwb3J0LT5ydW4gKQotICAgICAgICAgICAgICAgIGZzdF9pc3N1ZV9jbWQgKCBwb3J0 LCBTRVRWMjRPICk7CisJaWYgKHBvcnQtPnJ1bikKKwkJZnN0X2lzc3VlX2NtZChwb3J0LCBTRVRW MjRPKTsKIH0KIAogc3RhdGljIGlubGluZSB2b2lkCi1mc3Rfb3BfbG93ZXIgKCBzdHJ1Y3QgZnN0 X3BvcnRfaW5mbyAqcG9ydCwgdW5zaWduZWQgaW50IG91dHB1dHMgKQorZnN0X29wX2xvd2VyKHN0 cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LCB1bnNpZ25lZCBpbnQgb3V0cHV0cykKIHsKLSAgICAg ICAgb3V0cHV0cyA9IH5vdXRwdXRzICYgRlNUX1JETCAoIHBvcnQtPmNhcmQsIHYyNE9wU3RzW3Bv cnQtPmluZGV4XSk7Ci0gICAgICAgIEZTVF9XUkwgKCBwb3J0LT5jYXJkLCB2MjRPcFN0c1twb3J0 LT5pbmRleF0sIG91dHB1dHMgKTsKKwlvdXRwdXRzID0gfm91dHB1dHMgJiBGU1RfUkRMKHBvcnQt PmNhcmQsIHYyNE9wU3RzW3BvcnQtPmluZGV4XSk7CisJRlNUX1dSTChwb3J0LT5jYXJkLCB2MjRP cFN0c1twb3J0LT5pbmRleF0sIG91dHB1dHMpOwogCi0gICAgICAgIGlmICggcG9ydC0+cnVuICkK LSAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9ydCwgU0VUVjI0TyApOworCWlmIChw b3J0LT5ydW4pCisJCWZzdF9pc3N1ZV9jbWQocG9ydCwgU0VUVjI0Tyk7CiB9CiAKLQogLyoKICAq ICAgICAgU2V0dXAgcG9ydCBSeCBidWZmZXJzCiAgKi8KIHN0YXRpYyB2b2lkCi1mc3RfcnhfY29u ZmlnICggc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQgKQorZnN0X3J4X2NvbmZpZyhzdHJ1Y3Qg ZnN0X3BvcnRfaW5mbyAqcG9ydCkKIHsKLSAgICAgICAgaW50IGk7Ci0gICAgICAgIGludCBwaTsK LSAgICAgICAgdW5zaWduZWQgaW50IG9mZnNldDsKLSAgICAgICAgdW5zaWduZWQgbG9uZyBmbGFn czsKLSAgICAgICAgc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7Ci0KLSAgICAgICAgcGkgICA9 IHBvcnQtPmluZGV4OwotICAgICAgICBjYXJkID0gcG9ydC0+Y2FyZDsKLSAgICAgICAgc3Bpbl9s b2NrX2lycXNhdmUgKCAmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOwotICAgICAgICBmb3IgKCBp ID0gMCA7IGkgPCBOVU1fUlhfQlVGRkVSIDsgaSsrICkKLSAgICAgICAgewotICAgICAgICAgICAg ICAgIG9mZnNldCA9IEJVRl9PRkZTRVQgKCByeEJ1ZmZlcltwaV1baV1bMF0pOwotCi0gICAgICAg ICAgICAgICAgRlNUX1dSVyAoIGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtpXS5sYWRyLCAodTE2KSBv ZmZzZXQgKTsKLSAgICAgICAgICAgICAgICBGU1RfV1JCICggY2FyZCwgcnhEZXNjclJpbmdbcGld W2ldLmhhZHIsICh1OCkoIG9mZnNldCA+PiAxNiApKTsKLSAgICAgICAgICAgICAgICBGU1RfV1JX ICggY2FyZCwgcnhEZXNjclJpbmdbcGldW2ldLmJjbnQsCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY252X2JjbnQgKCBMRU5fUlhfQlVGRkVSICkpOwotICAgICAgICAg ICAgICAgIEZTVF9XUlcgKCBjYXJkLCByeERlc2NyUmluZ1twaV1baV0ubWNudCwgMCApOwotICAg ICAgICAgICAgICAgIEZTVF9XUkIgKCBjYXJkLCByeERlc2NyUmluZ1twaV1baV0uYml0cywgRE1B X09XTiApOwotICAgICAgICB9Ci0gICAgICAgIHBvcnQtPnJ4cG9zICA9IDA7Ci0gICAgICAgIHNw aW5fdW5sb2NrX2lycXJlc3RvcmUgKCAmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOworCWludCBp OworCWludCBwaTsKKwl1bnNpZ25lZCBpbnQgb2Zmc2V0OworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7 CisJc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7CisKKwlwaSA9IHBvcnQtPmluZGV4OworCWNh cmQgPSBwb3J0LT5jYXJkOworCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJkX2xvY2ssIGZs YWdzKTsKKwlmb3IgKGkgPSAwOyBpIDwgTlVNX1JYX0JVRkZFUjsgaSsrKSB7CisJCW9mZnNldCA9 IEJVRl9PRkZTRVQocnhCdWZmZXJbcGldW2ldWzBdKTsKKworCQlGU1RfV1JXKGNhcmQsIHJ4RGVz Y3JSaW5nW3BpXVtpXS5sYWRyLCAodTE2KSBvZmZzZXQpOworCQlGU1RfV1JCKGNhcmQsIHJ4RGVz Y3JSaW5nW3BpXVtpXS5oYWRyLCAodTgpIChvZmZzZXQgPj4gMTYpKTsKKwkJRlNUX1dSVyhjYXJk LCByeERlc2NyUmluZ1twaV1baV0uYmNudCwgY252X2JjbnQoTEVOX1JYX0JVRkZFUikpOworCQlG U1RfV1JXKGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtpXS5tY250LCBMRU5fUlhfQlVGRkVSKTsKKwkJ RlNUX1dSQihjYXJkLCByeERlc2NyUmluZ1twaV1baV0uYml0cywgRE1BX09XTik7CisJfQorCXBv cnQtPnJ4cG9zID0gMDsKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZjYXJkLT5jYXJkX2xvY2ss IGZsYWdzKTsKIH0KIAotCiAvKgogICogICAgICBTZXR1cCBwb3J0IFR4IGJ1ZmZlcnMKICAqLwog c3RhdGljIHZvaWQKLWZzdF90eF9jb25maWcgKCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCAp Citmc3RfdHhfY29uZmlnKHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0KQogewotICAgICAgICBp bnQgaTsKLSAgICAgICAgaW50IHBpOwotICAgICAgICB1bnNpZ25lZCBpbnQgb2Zmc2V0OwotICAg ICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwotICAgICAgICBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAq Y2FyZDsKLQotICAgICAgICBwaSAgID0gcG9ydC0+aW5kZXg7Ci0gICAgICAgIGNhcmQgPSBwb3J0 LT5jYXJkOwotICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZs YWdzICk7Ci0gICAgICAgIGZvciAoIGkgPSAwIDsgaSA8IE5VTV9UWF9CVUZGRVIgOyBpKysgKQot ICAgICAgICB7Ci0gICAgICAgICAgICAgICAgb2Zmc2V0ID0gQlVGX09GRlNFVCAoIHR4QnVmZmVy W3BpXVtpXVswXSk7Ci0KLSAgICAgICAgICAgICAgICBGU1RfV1JXICggY2FyZCwgdHhEZXNjclJp bmdbcGldW2ldLmxhZHIsICh1MTYpIG9mZnNldCApOwotICAgICAgICAgICAgICAgIEZTVF9XUkIg KCBjYXJkLCB0eERlc2NyUmluZ1twaV1baV0uaGFkciwgKHU4KSggb2Zmc2V0ID4+IDE2ICkpOwot ICAgICAgICAgICAgICAgIEZTVF9XUlcgKCBjYXJkLCB0eERlc2NyUmluZ1twaV1baV0uYmNudCwg MCApOwotICAgICAgICAgICAgICAgIEZTVF9XUkIgKCBjYXJkLCB0eERlc2NyUmluZ1twaV1baV0u Yml0cywgMCApOwotICAgICAgICB9Ci0gICAgICAgIHBvcnQtPnR4cG9zICA9IDA7Ci0gICAgICAg IHBvcnQtPnR4aXBvcyA9IDA7Ci0gICAgICAgIHBvcnQtPnR4Y250ICA9IDA7Ci0gICAgICAgIHNw aW5fdW5sb2NrX2lycXJlc3RvcmUgKCAmY2FyZC0+Y2FyZF9sb2NrLCBmbGFncyApOworCWludCBp OworCWludCBwaTsKKwl1bnNpZ25lZCBpbnQgb2Zmc2V0OworCXVuc2lnbmVkIGxvbmcgZmxhZ3M7 CisJc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7CisKKwlwaSA9IHBvcnQtPmluZGV4OworCWNh cmQgPSBwb3J0LT5jYXJkOworCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJkX2xvY2ssIGZs YWdzKTsKKwlmb3IgKGkgPSAwOyBpIDwgTlVNX1RYX0JVRkZFUjsgaSsrKSB7CisJCW9mZnNldCA9 IEJVRl9PRkZTRVQodHhCdWZmZXJbcGldW2ldWzBdKTsKKworCQlGU1RfV1JXKGNhcmQsIHR4RGVz Y3JSaW5nW3BpXVtpXS5sYWRyLCAodTE2KSBvZmZzZXQpOworCQlGU1RfV1JCKGNhcmQsIHR4RGVz Y3JSaW5nW3BpXVtpXS5oYWRyLCAodTgpIChvZmZzZXQgPj4gMTYpKTsKKwkJRlNUX1dSVyhjYXJk LCB0eERlc2NyUmluZ1twaV1baV0uYmNudCwgMCk7CisJCUZTVF9XUkIoY2FyZCwgdHhEZXNjclJp bmdbcGldW2ldLmJpdHMsIDApOworCX0KKwlwb3J0LT50eHBvcyA9IDA7CisJcG9ydC0+dHhpcG9z ID0gMDsKKwlwb3J0LT5zdGFydCA9IDA7CisJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2FyZC0+ Y2FyZF9sb2NrLCBmbGFncyk7CiB9CiAKKy8qICAgICAgVEUxIEFsYXJtIGNoYW5nZSBpbnRlcnJ1 cHQgZXZlbnQKKyAqLworc3RhdGljIHZvaWQKK2ZzdF9pbnRyX3RlMV9hbGFybShzdHJ1Y3QgZnN0 X2NhcmRfaW5mbyAqY2FyZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQpCit7CisJdTggbG9z OworCXU4IHJyYTsKKwl1OCBhaXM7CisKKwlsb3MgPSBGU1RfUkRCKGNhcmQsIHN1U3RhdHVzLmxv c3NPZlNpZ25hbCk7CisJcnJhID0gRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5yZWNlaXZlUmVtb3Rl QWxhcm0pOworCWFpcyA9IEZTVF9SREIoY2FyZCwgc3VTdGF0dXMuYWxhcm1JbmRpY2F0aW9uU2ln bmFsKTsKKworCWlmIChsb3MpIHsKKwkJLyoKKwkJICogTG9zdCB0aGUgbGluaworCQkgKi8KKwkJ aWYgKG5ldGlmX2NhcnJpZXJfb2socG9ydF90b19kZXYocG9ydCkpKSB7CisJCQlkYmcoREJHX0lO VFIsICJOZXQgY2FycmllciBvZmZcbiIpOworCQkJbmV0aWZfY2Fycmllcl9vZmYocG9ydF90b19k ZXYocG9ydCkpOworCQl9CisJfSBlbHNlIHsKKwkJLyoKKwkJICogTGluayBhdmFpbGFibGUKKwkJ ICovCisJCWlmICghbmV0aWZfY2Fycmllcl9vayhwb3J0X3RvX2Rldihwb3J0KSkpIHsKKwkJCWRi ZyhEQkdfSU5UUiwgIk5ldCBjYXJyaWVyIG9uXG4iKTsKKwkJCW5ldGlmX2NhcnJpZXJfb24ocG9y dF90b19kZXYocG9ydCkpOworCQl9CisJfQorCisJaWYgKGxvcykKKwkJZGJnKERCR19JTlRSLCAi QXNzZXJ0IExPUyBBbGFybVxuIik7CisJZWxzZQorCQlkYmcoREJHX0lOVFIsICJEZS1hc3NlcnQg TE9TIEFsYXJtXG4iKTsKKwlpZiAocnJhKQorCQlkYmcoREJHX0lOVFIsICJBc3NlcnQgUlJBIEFs YXJtXG4iKTsKKwllbHNlCisJCWRiZyhEQkdfSU5UUiwgIkRlLWFzc2VydCBSUkEgQWxhcm1cbiIp OworCisJaWYgKGFpcykKKwkJZGJnKERCR19JTlRSLCAiQXNzZXJ0IEFJUyBBbGFybVxuIik7CisJ ZWxzZQorCQlkYmcoREJHX0lOVFIsICJEZS1hc3NlcnQgQUlTIEFsYXJtXG4iKTsKK30KIAogLyog ICAgICBDb250cm9sIHNpZ25hbCBjaGFuZ2UgaW50ZXJydXB0IGV2ZW50CiAgKi8KIHN0YXRpYyB2 b2lkCi1mc3RfaW50cl9jdGxjaGcgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCwgc3RydWN0 IGZzdF9wb3J0X2luZm8gKnBvcnQgKQorZnN0X2ludHJfY3RsY2hnKHN0cnVjdCBmc3RfY2FyZF9p bmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCkKIHsKLSAgICAgICAgaW50IHNp Z25hbHM7CisJaW50IHNpZ25hbHM7CisKKwlzaWduYWxzID0gRlNUX1JETChjYXJkLCB2MjREZWJv dW5jZWRTdHNbcG9ydC0+aW5kZXhdKTsKIAotICAgICAgICBzaWduYWxzID0gRlNUX1JETCAoIGNh cmQsIHYyNERlYm91bmNlZFN0c1twb3J0LT5pbmRleF0pOworCWlmIChzaWduYWxzICYgKCgocG9y dC0+aHdpZiA9PSBYMjEpIHx8IChwb3J0LT5od2lmID09IFgyMUQpKQorCQkgICAgICAgPyBJUFNU U19JTkRJQ0FURSA6IElQU1RTX0RDRCkpIHsKKwkJaWYgKCFuZXRpZl9jYXJyaWVyX29rKHBvcnRf dG9fZGV2KHBvcnQpKSkgeworCQkJZGJnKERCR19JTlRSLCAiRENEIGFjdGl2ZVxuIik7CisJCQlu ZXRpZl9jYXJyaWVyX29uKHBvcnRfdG9fZGV2KHBvcnQpKTsKKwkJfQorCX0gZWxzZSB7CisJCWlm IChuZXRpZl9jYXJyaWVyX29rKHBvcnRfdG9fZGV2KHBvcnQpKSkgeworCQkJZGJnKERCR19JTlRS LCAiRENEIGxvc3RcbiIpOworCQkJbmV0aWZfY2Fycmllcl9vZmYocG9ydF90b19kZXYocG9ydCkp OworCQl9CisJfQorfQogCi0gICAgICAgIGlmICggc2lnbmFscyAmICgoIHBvcnQtPmh3aWYgPT0g WDIxICkgPyBJUFNUU19JTkRJQ0FURSA6IElQU1RTX0RDRCApKQotICAgICAgICB7Ci0gICAgICAg ICAgICAgICAgaWYgKCAhIG5ldGlmX2NhcnJpZXJfb2sgKCBwb3J0X3RvX2RldiAoIHBvcnQgKSkp Ci0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICAgICAgZGJnICggREJHX0lO VFIsIkRDRCBhY3RpdmVcbiIpOwotICAgICAgICAgICAgICAgICAgICAgICAgbmV0aWZfY2Fycmll cl9vbiAoIHBvcnRfdG9fZGV2ICggcG9ydCApKTsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAg IH0KLSAgICAgICAgZWxzZQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgaWYgKCBuZXRpZl9j YXJyaWVyX29rICggcG9ydF90b19kZXYgKCBwb3J0ICkpKQotICAgICAgICAgICAgICAgIHsKLSAg ICAgICAgICAgICAgICAgICAgICAgIGRiZyAoIERCR19JTlRSLCJEQ0QgbG9zdFxuIik7Ci0gICAg ICAgICAgICAgICAgICAgICAgICBuZXRpZl9jYXJyaWVyX29mZiAoIHBvcnRfdG9fZGV2ICggcG9y dCApKTsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAgIH0KKy8qICAgICAgTG9nIFJ4IEVycm9y cworICovCitzdGF0aWMgdm9pZAorZnN0X2xvZ19yeF9lcnJvcihzdHJ1Y3QgZnN0X2NhcmRfaW5m byAqY2FyZCwgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsCisJCSB1bnNpZ25lZCBjaGFyIGRt YWJpdHMsIGludCByeHAsIHVuc2lnbmVkIHNob3J0IGxlbikKK3sKKwkvKiAKKwkgKiBJbmNyZW1l bnQgdGhlIGFwcHJvcHJpYXRlIGVycm9yIGNvdW50ZXIKKwkgKi8KKwlwb3J0LT5oZGxjLnN0YXRz LnJ4X2Vycm9ycysrOworCWlmIChkbWFiaXRzICYgUlhfT0ZMTykgeworCQlwb3J0LT5oZGxjLnN0 YXRzLnJ4X2ZpZm9fZXJyb3JzKys7CisJCWRiZyhEQkdfQVNTLCAiUnggZmlmbyBlcnJvciBvbiBj YXJkICVkIHBvcnQgJWQgYnVmZmVyICVkXG4iLAorCQkgICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+ aW5kZXgsIHJ4cCk7CisJfQorCWlmIChkbWFiaXRzICYgUlhfQ1JDKSB7CisJCXBvcnQtPmhkbGMu c3RhdHMucnhfY3JjX2Vycm9ycysrOworCQlkYmcoREJHX0FTUywgIlJ4IGNyYyBlcnJvciBvbiBj YXJkICVkIHBvcnQgJWRcbiIsCisJCSAgICBjYXJkLT5jYXJkX25vLCBwb3J0LT5pbmRleCk7CisJ fQorCWlmIChkbWFiaXRzICYgUlhfRlJBTSkgeworCQlwb3J0LT5oZGxjLnN0YXRzLnJ4X2ZyYW1l X2Vycm9ycysrOworCQlkYmcoREJHX0FTUywgIlJ4IGZyYW1lIGVycm9yIG9uIGNhcmQgJWQgcG9y dCAlZFxuIiwKKwkJICAgIGNhcmQtPmNhcmRfbm8sIHBvcnQtPmluZGV4KTsKKwl9CisJaWYgKGRt YWJpdHMgPT0gKFJYX1NUUCB8IFJYX0VOUCkpIHsKKwkJcG9ydC0+aGRsYy5zdGF0cy5yeF9sZW5n dGhfZXJyb3JzKys7CisJCWRiZyhEQkdfQVNTLCAiUnggbGVuZ3RoIGVycm9yICglZCkgb24gY2Fy ZCAlZCBwb3J0ICVkXG4iLAorCQkgICAgbGVuLCBjYXJkLT5jYXJkX25vLCBwb3J0LT5pbmRleCk7 CisJfQogfQogCisvKiAgICAgIFJ4IEVycm9yIFJlY292ZXJ5CisgKi8KK3N0YXRpYyB2b2lkCitm c3RfcmVjb3Zlcl9yeF9lcnJvcihzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCwgc3RydWN0IGZz dF9wb3J0X2luZm8gKnBvcnQsCisJCSAgICAgdW5zaWduZWQgY2hhciBkbWFiaXRzLCBpbnQgcnhw LCB1bnNpZ25lZCBzaG9ydCBsZW4pCit7CisJaW50IGk7CisJaW50IHBpOworCisJcGkgPSBwb3J0 LT5pbmRleDsKKwkvKiAKKwkgKiBEaXNjYXJkIGJ1ZmZlciBkZXNjcmlwdG9ycyB1bnRpbCB3ZSBz ZWUgdGhlIHN0YXJ0IG9mIHRoZQorCSAqIG5leHQgZnJhbWUuICBOb3RlIHRoYXQgZm9yIGxvbmcg ZnJhbWVzIHRoaXMgY291bGQgYmUgaW4KKwkgKiBhIHN1YnNlcXVlbnQgaW50ZXJydXB0LiAKKwkg Ki8KKwlpID0gMDsKKwl3aGlsZSAoKGRtYWJpdHMgJiAoRE1BX09XTiB8IFJYX1NUUCkpID09IDAp IHsKKwkJRlNUX1dSQihjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dOKTsK KwkJcnhwID0gKHJ4cCsxKSAlIE5VTV9SWF9CVUZGRVI7CisJCWlmICgrK2kgPiBOVU1fUlhfQlVG RkVSKSB7CisJCQlkYmcoREJHX0FTUywgImludHJfcng6IERpc2NhcmRpbmcgbW9yZSBidWZzIgor CQkJICAgICIgdGhhbiB3ZSBoYXZlXG4iKTsKKwkJCWJyZWFrOworCQl9CisJCWRtYWJpdHMgPSBG U1RfUkRCKGNhcmQsIHJ4RGVzY3JSaW5nW3BpXVtyeHBdLmJpdHMpOworCQlkYmcoREJHX0FTUywg IkRNQSBCaXRzIG9mIG5leHQgYnVmZmVyIHdhcyAleFxuIiwgZG1hYml0cyk7CisJfQorCWRiZyhE QkdfQVNTLCAiVGhlcmUgd2VyZSAlZCBzdWJzZXF1ZW50IGJ1ZmZlcnMgaW4gZXJyb3JcbiIsIGkp OworCisJLyogRGlzY2FyZCB0aGUgdGVybWluYWwgYnVmZmVyICovCisJaWYgKCEoZG1hYml0cyAm IERNQV9PV04pKSB7CisJCUZTVF9XUkIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywg RE1BX09XTik7CisJCXJ4cCA9IChyeHArMSkgJSBOVU1fUlhfQlVGRkVSOworCX0KKwlwb3J0LT5y eHBvcyA9IHJ4cDsKKwlyZXR1cm47CisKK30KIAogLyogICAgICBSeCBjb21wbGV0ZSBpbnRlcnJ1 cHQKICAqLwogc3RhdGljIHZvaWQKLWZzdF9pbnRyX3J4ICggc3RydWN0IGZzdF9jYXJkX2luZm8g KmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0ICkKK2ZzdF9pbnRyX3J4KHN0cnVjdCBm c3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCkKIHsKLSAgICAg ICAgdW5zaWduZWQgY2hhciBkbWFiaXRzOwotICAgICAgICBpbnQgcGk7Ci0gICAgICAgIGludCBy eHA7Ci0gICAgICAgIHVuc2lnbmVkIHNob3J0IGxlbjsKLSAgICAgICAgc3RydWN0IHNrX2J1ZmYg KnNrYjsKLSAgICAgICAgaW50IGk7Ci0KLQotICAgICAgICAvKiBDaGVjayB3ZSBoYXZlIGEgYnVm ZmVyIHRvIHByb2Nlc3MgKi8KLSAgICAgICAgcGkgID0gcG9ydC0+aW5kZXg7Ci0gICAgICAgIHJ4 cCA9IHBvcnQtPnJ4cG9zOwotICAgICAgICBkbWFiaXRzID0gRlNUX1JEQiAoIGNhcmQsIHJ4RGVz Y3JSaW5nW3BpXVtyeHBdLmJpdHMgKTsKLSAgICAgICAgaWYgKCBkbWFiaXRzICYgRE1BX09XTiAp Ci0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfUlggfCBEQkdfSU5UUiwiaW50 cl9yeDogTm8gYnVmZmVyIHBvcnQgJWQgcG9zICVkXG4iLAotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHBpLCByeHAgKTsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0g ICAgICAgIH0KLQotICAgICAgICAvKiBHZXQgYnVmZmVyIGxlbmd0aCAqLwotICAgICAgICBsZW4g PSBGU1RfUkRXICggY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0ubWNudCApOwotICAgICAgICAv KiBEaXNjYXJkIHRoZSBDUkMgKi8KLSAgICAgICAgbGVuIC09IDI7Ci0KLSAgICAgICAgLyogQ2hl Y2sgYnVmZmVyIGxlbmd0aCBhbmQgZm9yIG90aGVyIGVycm9ycy4gV2UgaW5zaXN0IG9uIG9uZSBw YWNrZXQKLSAgICAgICAgICogaW4gb25lIGJ1ZmZlci4gVGhpcyBzaW1wbGlmaWVzIHRoaW5ncyBn cmVhdGx5IGFuZCBzaW5jZSB3ZSd2ZQotICAgICAgICAgKiBhbGxvY2F0ZWQgOEsgaXQgc2hvdWxk bid0IGJlIGEgcmVhbCB3b3JsZCBsaW1pdGF0aW9uCi0gICAgICAgICAqLwotICAgICAgICBkYmcg KCBEQkdfUlgsImludHJfcng6ICVkLCVkOiBmbGFncyAleCBsZW4gJWRcbiIsIHBpLCByeHAsIGRt YWJpdHMsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVuICk7Ci0g ICAgICAgIGlmICggZG1hYml0cyAhPSAoIFJYX1NUUCB8IFJYX0VOUCApIHx8IGxlbiA+IExFTl9S WF9CVUZGRVIgLSAyICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIHBvcnQtPmhkbGMuc3Rh dHMucnhfZXJyb3JzKys7Ci0KLSAgICAgICAgICAgICAgICAvKiBVcGRhdGUgZXJyb3Igc3RhdHMg YW5kIGRpc2NhcmQgYnVmZmVyICovCi0gICAgICAgICAgICAgICAgaWYgKCBkbWFiaXRzICYgUlhf T0ZMTyApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICAgICAgcG9ydC0+ aGRsYy5zdGF0cy5yeF9maWZvX2Vycm9ycysrOwotICAgICAgICAgICAgICAgIH0KLSAgICAgICAg ICAgICAgICBpZiAoIGRtYWJpdHMgJiBSWF9DUkMgKQotICAgICAgICAgICAgICAgIHsKLSAgICAg ICAgICAgICAgICAgICAgICAgIHBvcnQtPmhkbGMuc3RhdHMucnhfY3JjX2Vycm9ycysrOwotICAg ICAgICAgICAgICAgIH0KLSAgICAgICAgICAgICAgICBpZiAoIGRtYWJpdHMgJiBSWF9GUkFNICkK LSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICBwb3J0LT5oZGxjLnN0 YXRzLnJ4X2ZyYW1lX2Vycm9ycysrOwotICAgICAgICAgICAgICAgIH0KLSAgICAgICAgICAgICAg ICBpZiAoIGRtYWJpdHMgPT0gKCBSWF9TVFAgfCBSWF9FTlAgKSkKLSAgICAgICAgICAgICAgICB7 Ci0gICAgICAgICAgICAgICAgICAgICAgICBwb3J0LT5oZGxjLnN0YXRzLnJ4X2xlbmd0aF9lcnJv cnMrKzsKLSAgICAgICAgICAgICAgICB9Ci0KLSAgICAgICAgICAgICAgICAvKiBEaXNjYXJkIGJ1 ZmZlciBkZXNjcmlwdG9ycyB1bnRpbCB3ZSBzZWUgdGhlIGVuZCBvZiBwYWNrZXQKLSAgICAgICAg ICAgICAgICAgKiBtYXJrZXIKLSAgICAgICAgICAgICAgICAgKi8KLSAgICAgICAgICAgICAgICBp ID0gMDsKLSAgICAgICAgICAgICAgICB3aGlsZSAoKCBkbWFiaXRzICYgKCBETUFfT1dOIHwgUlhf RU5QICkpID09IDAgKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAg IEZTVF9XUkIgKCBjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dOICk7Ci0g ICAgICAgICAgICAgICAgICAgICAgICBpZiAoICsrcnhwID49IE5VTV9SWF9CVUZGRVIgKQotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICByeHAgPSAwOwotICAgICAgICAgICAgICAgICAg ICAgICAgaWYgKCArK2kgPiBOVU1fUlhfQlVGRkVSICkKLSAgICAgICAgICAgICAgICAgICAgICAg IHsKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZGJnICggREJHX0FTUywiaW50cl9y eDogRGlzY2FyZGluZyBtb3JlIGJ1ZnMiCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAiIHRoYW4gd2UgaGF2ZVxuIik7Ci0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGJyZWFrOwotICAgICAgICAgICAgICAgICAgICAgICAgfQotICAgICAgICAg ICAgICAgICAgICAgICAgZG1hYml0cyA9IEZTVF9SREIgKCBjYXJkLCByeERlc2NyUmluZ1twaV1b cnhwXS5iaXRzICk7Ci0gICAgICAgICAgICAgICAgfQotCi0gICAgICAgICAgICAgICAgLyogRGlz Y2FyZCB0aGUgdGVybWluYWwgYnVmZmVyICovCi0gICAgICAgICAgICAgICAgaWYgKCAhICggZG1h Yml0cyAmIERNQV9PV04gKSkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAgICAg ICAgICBGU1RfV1JCICggY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywgRE1BX09XTiAp OwotICAgICAgICAgICAgICAgICAgICAgICAgaWYgKCArK3J4cCA+PSBOVU1fUlhfQlVGRkVSICkK LSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcnhwID0gMDsKLSAgICAgICAgICAgICAg ICB9Ci0gICAgICAgICAgICAgICAgcG9ydC0+cnhwb3MgPSByeHA7Ci0gICAgICAgICAgICAgICAg cmV0dXJuOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogQWxsb2NhdGUgU0tCICovCi0gICAgICAg IGlmICgoIHNrYiA9IGRldl9hbGxvY19za2IgKCBsZW4gKSkgPT0gTlVMTCApCi0gICAgICAgIHsK LSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfUlgsImludHJfcng6IGNhbid0IGFsbG9jYXRlIGJ1 ZmZlclxuIik7Ci0KLSAgICAgICAgICAgICAgICBwb3J0LT5oZGxjLnN0YXRzLnJ4X2Ryb3BwZWQr KzsKLQotICAgICAgICAgICAgICAgIC8qIFJldHVybiBkZXNjcmlwdG9yIHRvIGNhcmQgKi8KLSAg ICAgICAgICAgICAgICBGU1RfV1JCICggY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywg RE1BX09XTiApOwotCi0gICAgICAgICAgICAgICAgaWYgKCArK3J4cCA+PSBOVU1fUlhfQlVGRkVS ICkKLSAgICAgICAgICAgICAgICAgICAgICAgIHBvcnQtPnJ4cG9zID0gMDsKLSAgICAgICAgICAg ICAgICBlbHNlCi0gICAgICAgICAgICAgICAgICAgICAgICBwb3J0LT5yeHBvcyA9IHJ4cDsKLSAg ICAgICAgICAgICAgICByZXR1cm47Ci0gICAgICAgIH0KLQotICAgICAgICBtZW1jcHlfZnJvbWlv ICggc2tiX3B1dCAoIHNrYiwgbGVuICksCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNhcmQtPm1lbSArIEJVRl9PRkZTRVQgKCByeEJ1ZmZlcltwaV1bcnhwXVswXSksCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGxlbiApOwotCi0gICAgICAgIC8qIFJlc2V0IGJ1ZmZl ciBkZXNjcmlwdG9yICovCi0gICAgICAgIEZTVF9XUkIgKCBjYXJkLCByeERlc2NyUmluZ1twaV1b cnhwXS5iaXRzLCBETUFfT1dOICk7Ci0gICAgICAgIGlmICggKytyeHAgPj0gTlVNX1JYX0JVRkZF UiApCi0gICAgICAgICAgICAgICAgcG9ydC0+cnhwb3MgPSAwOwotICAgICAgICBlbHNlCi0gICAg ICAgICAgICAgICAgcG9ydC0+cnhwb3MgPSByeHA7Ci0KLSAgICAgICAgLyogVXBkYXRlIHN0YXRz ICovCi0gICAgICAgIHBvcnQtPmhkbGMuc3RhdHMucnhfcGFja2V0cysrOwotICAgICAgICBwb3J0 LT5oZGxjLnN0YXRzLnJ4X2J5dGVzICs9IGxlbjsKLQotICAgICAgICAvKiBQdXNoIHVwc3RyZWFt ICovCi0gICAgICAgIHNrYi0+bWFjLnJhdyA9IHNrYi0+ZGF0YTsKLSAgICAgICAgc2tiLT5kZXYg PSBoZGxjX3RvX2RldiAoICZwb3J0LT5oZGxjICk7Ci0gICAgICAgIHNrYi0+cHJvdG9jb2wgPSBo ZGxjX3R5cGVfdHJhbnMoc2tiLCBza2ItPmRldik7Ci0gICAgICAgIG5ldGlmX3J4ICggc2tiICk7 CisJdW5zaWduZWQgY2hhciBkbWFiaXRzOworCWludCBwaTsKKwlpbnQgcnhwOworCWludCByeF9z dGF0dXM7CisJdW5zaWduZWQgc2hvcnQgbGVuOworCXN0cnVjdCBza19idWZmICpza2I7CisKKwkv KiBDaGVjayB3ZSBoYXZlIGEgYnVmZmVyIHRvIHByb2Nlc3MgKi8KKwlwaSA9IHBvcnQtPmluZGV4 OworCXJ4cCA9IHBvcnQtPnJ4cG9zOworCWRtYWJpdHMgPSBGU1RfUkRCKGNhcmQsIHJ4RGVzY3JS aW5nW3BpXVtyeHBdLmJpdHMpOworCWlmIChkbWFiaXRzICYgRE1BX09XTikgeworCQlkYmcoREJH X1JYIHwgREJHX0lOVFIsICJpbnRyX3J4OiBObyBidWZmZXIgcG9ydCAlZCBwb3MgJWRcbiIsCisJ CSAgICBwaSwgcnhwKTsKKwkJcmV0dXJuOworCX0KKwlpZiAoY2FyZC0+ZG1hcnhfaW5fcHJvZ3Jl c3MpIHsKKwkJcmV0dXJuOworCX0KKworCS8qIEdldCBidWZmZXIgbGVuZ3RoICovCisJbGVuID0g RlNUX1JEVyhjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5tY250KTsKKwkvKiBEaXNjYXJkIHRo ZSBDUkMgKi8KKwlsZW4gLT0gMjsKKwlpZiAobGVuID09IDApIHsKKwkJLyoKKwkJICogVGhpcyBz ZWVtcyB0byBoYXBwZW4gb24gdGhlIFRFMSBpbnRlcmZhY2Ugc29tZXRpbWVzCisJCSAqIHNvIHRo cm93IHRoZSBmcmFtZSBhd2F5IGFuZCBsb2cgdGhlIGV2ZW50LgorCQkgKi8KKwkJcHJpbnRrX2Vy cigiRnJhbWUgcmVjZWl2ZWQgd2l0aCAwIGxlbmd0aC4gQ2FyZCAlZCBQb3J0ICVkXG4iLAorCQkJ ICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgpOworCQkvKiBSZXR1cm4gZGVzY3JpcHRvciB0 byBjYXJkICovCisJCUZTVF9XUkIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0cywgRE1B X09XTik7CisKKwkJcnhwID0gKHJ4cCsxKSAlIE5VTV9SWF9CVUZGRVI7CisJCXBvcnQtPnJ4cG9z ID0gcnhwOworCQlyZXR1cm47CisJfQogCi0gICAgICAgIHBvcnRfdG9fZGV2ICggcG9ydCApLT5s YXN0X3J4ID0gamlmZmllczsKKwkvKiBDaGVjayBidWZmZXIgbGVuZ3RoIGFuZCBmb3Igb3RoZXIg ZXJyb3JzLiBXZSBpbnNpc3Qgb24gb25lIHBhY2tldAorCSAqIGluIG9uZSBidWZmZXIuIFRoaXMg c2ltcGxpZmllcyB0aGluZ3MgZ3JlYXRseSBhbmQgc2luY2Ugd2UndmUKKwkgKiBhbGxvY2F0ZWQg OEsgaXQgc2hvdWxkbid0IGJlIGEgcmVhbCB3b3JsZCBsaW1pdGF0aW9uCisJICovCisJZGJnKERC R19SWCwgImludHJfcng6ICVkLCVkOiBmbGFncyAleCBsZW4gJWRcbiIsIHBpLCByeHAsIGRtYWJp dHMsIGxlbik7CisJaWYgKGRtYWJpdHMgIT0gKFJYX1NUUCB8IFJYX0VOUCkgfHwgbGVuID4gTEVO X1JYX0JVRkZFUiAtIDIpIHsKKwkJZnN0X2xvZ19yeF9lcnJvcihjYXJkLCBwb3J0LCBkbWFiaXRz LCByeHAsIGxlbik7CisJCWZzdF9yZWNvdmVyX3J4X2Vycm9yKGNhcmQsIHBvcnQsIGRtYWJpdHMs IHJ4cCwgbGVuKTsKKwkJcmV0dXJuOworCX0KKworCS8qIEFsbG9jYXRlIFNLQiAqLworCWlmICgo c2tiID0gZGV2X2FsbG9jX3NrYihsZW4pKSA9PSBOVUxMKSB7CisJCWRiZyhEQkdfUlgsICJpbnRy X3J4OiBjYW4ndCBhbGxvY2F0ZSBidWZmZXJcbiIpOworCisJCXBvcnQtPmhkbGMuc3RhdHMucnhf ZHJvcHBlZCsrOworCisJCS8qIFJldHVybiBkZXNjcmlwdG9yIHRvIGNhcmQgKi8KKwkJRlNUX1dS QihjYXJkLCByeERlc2NyUmluZ1twaV1bcnhwXS5iaXRzLCBETUFfT1dOKTsKKworCQlyeHAgPSAo cnhwKzEpICUgTlVNX1JYX0JVRkZFUjsKKwkJcG9ydC0+cnhwb3MgPSByeHA7CisJCXJldHVybjsK Kwl9CisKKwkvKgorCSAqIFdlIGtub3cgdGhlIGxlbmd0aCB3ZSBuZWVkIHRvIHJlY2VpdmUsIGxl bi4KKwkgKiBJdCdzIG5vdCB3b3J0aCB1c2luZyB0aGUgRE1BIGZvciByZWFkcyBvZiBsZXNzIHRo YW4KKwkgKiBGU1RfTUlOX0RNQV9MRU4KKwkgKi8KKworCWlmICgobGVuIDwgRlNUX01JTl9ETUFf TEVOKSB8fCAoY2FyZC0+ZmFtaWx5ID09IEZTVF9GQU1JTFlfVFhQKSkgeworCQltZW1jcHlfZnJv bWlvKHNrYl9wdXQoc2tiLCBsZW4pLAorCQkJICAgICAgY2FyZC0+bWVtICsgQlVGX09GRlNFVChy eEJ1ZmZlcltwaV1bcnhwXVswXSksCisJCQkgICAgICBsZW4pOworCisJCS8qIFJlc2V0IGJ1ZmZl ciBkZXNjcmlwdG9yICovCisJCUZTVF9XUkIoY2FyZCwgcnhEZXNjclJpbmdbcGldW3J4cF0uYml0 cywgRE1BX09XTik7CisKKwkJLyogVXBkYXRlIHN0YXRzICovCisJCXBvcnQtPmhkbGMuc3RhdHMu cnhfcGFja2V0cysrOworCQlwb3J0LT5oZGxjLnN0YXRzLnJ4X2J5dGVzICs9IGxlbjsKKworCQkv KiBQdXNoIHVwc3RyZWFtICovCisJCWRiZyhEQkdfUlgsICJQdXNoaW5nIGZyYW1lIHVwIHRoZSBz dGFja1xuIik7CisJCXNrYi0+bWFjLnJhdyA9IHNrYi0+ZGF0YTsKKwkJc2tiLT5kZXYgPSBoZGxj X3RvX2RldigmcG9ydC0+aGRsYyk7CisJCWlmIChwb3J0LT5tb2RlID09IEZTVF9SQVcpIHsKKwkJ CS8qCisJCQkgKiBNYXJrIGl0IGZvciBvdXIgb3duIHJhdyBzb2NrZXRzIGludGVyZmFjZQorCQkJ ICovCisJCQlza2ItPnByb3RvY29sID0gaHRvbnMoRVRIX1BfQ1VTVCk7CisJCQlza2ItPnBrdF90 eXBlID0gUEFDS0VUX0hPU1Q7CisJCX0gZWxzZSB7CisJCQlza2ItPnByb3RvY29sID0gaGRsY190 eXBlX3RyYW5zKHNrYiwgc2tiLT5kZXYpOworCQl9CisJCXJ4X3N0YXR1cyA9IG5ldGlmX3J4KHNr Yik7CisJCWZzdF9wcm9jZXNzX3J4X3N0YXR1cyhyeF9zdGF0dXMsIHBvcnRfdG9fZGV2KHBvcnQp LT5uYW1lKTsKKwkJaWYgKHJ4X3N0YXR1cyA9PSBORVRfUlhfRFJPUCkgeworCQkJcG9ydC0+aGRs Yy5zdGF0cy5yeF9kcm9wcGVkKys7CisJCX0KKwkJcG9ydF90b19kZXYocG9ydCktPmxhc3Rfcngg PSBqaWZmaWVzOworCX0gZWxzZSB7CisJCWNhcmQtPmRtYV9za2JfcnggPSBza2I7CisJCWNhcmQt PmRtYV9wb3J0X3J4ID0gcG9ydDsKKwkJY2FyZC0+ZG1hX2xlbl9yeCA9IGxlbjsKKwkJY2FyZC0+ ZG1hX3J4cG9zID0gcnhwOworCQlmc3RfcnhfZG1hKGNhcmQsIChjaGFyICopIGNhcmQtPnJ4X2Rt YV9oYW5kbGVfY2FyZCwKKwkJCSAgIChjaGFyICopIEJVRl9PRkZTRVQocnhCdWZmZXJbcGldW3J4 cF1bMF0pLCBsZW4pOworCX0KKwlpZiAocnhwICE9IHBvcnQtPnJ4cG9zKSB7CisJCWRiZyhEQkdf QVNTLCAiQWJvdXQgdG8gaW5jcmVtZW50IHJ4cG9zIGJ5IG1vcmUgdGhhbiAxXG4iKTsKKwkJZGJn KERCR19BU1MsICJyeHAgPSAlZCByeHBvcyA9ICVkXG4iLCByeHAsIHBvcnQtPnJ4cG9zKTsKKwl9 CisJcnhwID0gKHJ4cCsxKSAlIE5VTV9SWF9CVUZGRVI7CisJcG9ydC0+cnhwb3MgPSByeHA7CiB9 CiAKKy8qCisgKiAgICAgIFRoZSBib3R0b20gaGFsZnMgdG8gdGhlIElTUgorICoKKyAqLworCitz dGF0aWMgdm9pZAorZG9fYm90dG9tX2hhbGZfdHgoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQp Cit7CisJc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7CisJaW50IHBpOworCWludCB0eHFfbGVu Z3RoOworCXN0cnVjdCBza19idWZmICpza2I7CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCS8q CisJICogIEZpbmQgYSBmcmVlIGJ1ZmZlciBmb3IgdGhlIHRyYW5zbWl0CisJICogIFN0ZXAgdGhy b3VnaCBlYWNoIHBvcnQgb24gdGhpcyBjYXJkCisJICovCisKKwlkYmcoREJHX1RYLCAiZG9fYm90 dG9tX2hhbGZfdHhcbiIpOworCWZvciAocGkgPSAwLCBwb3J0ID0gY2FyZC0+cG9ydHM7IHBpIDwg Y2FyZC0+bnBvcnRzOyBwaSsrLCBwb3J0KyspIHsKKwkJaWYgKCFwb3J0LT5ydW4pCisJCQljb250 aW51ZTsKKworCQl3aGlsZSAoIQorCQkgICAgICAgKEZTVF9SREIoY2FyZCwgdHhEZXNjclJpbmdb cGldW3BvcnQtPnR4cG9zXS5iaXRzKSAmCisJCQlETUFfT1dOKQorJiYgIShjYXJkLT5kbWF0eF9p bl9wcm9ncmVzcykpIHsKKwkJCS8qCisJCQkgKiBUaGVyZSBkb2Vzbid0IHNlZW0gdG8gYmUgYSB0 eGRvbmUgZXZlbnQgcGVyLXNlCisJCQkgKiBXZSBzZWVtIHRvIGhhdmUgdG8gZGVkdWNlIGl0LCBi eSBjaGVja2luZyB0aGUgRE1BX09XTgorCQkJICogYml0IG9uIHRoZSBuZXh0IGJ1ZmZlciB3ZSB0 aGluayB3ZSBjYW4gdXNlCisJCQkgKi8KKwkJCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJk X2xvY2ssIGZsYWdzKTsKKwkJCWlmICgodHhxX2xlbmd0aCA9IHBvcnQtPnR4cWUgLSBwb3J0LT50 eHFzKSA8IDApIHsKKwkJCQkvKgorCQkJCSAqIFRoaXMgaXMgdGhlIGNhc2Ugd2hlcmUgb25lIGhh cyB3cmFwcGVkIGFuZCB0aGUKKwkJCQkgKiBtYXRocyBnaXZlcyB1cyBhIG5lZ2F0aXZlIG51bWJl cgorCQkJCSAqLworCQkJCXR4cV9sZW5ndGggPSB0eHFfbGVuZ3RoICsgRlNUX1RYUV9ERVBUSDsK KwkJCX0KKwkJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmNhcmQtPmNhcmRfbG9jaywgZmxhZ3Mp OworCQkJaWYgKHR4cV9sZW5ndGggPiAwKSB7CisJCQkJLyoKKwkJCQkgKiBUaGVyZSBpcyBzb21l dGhpbmcgdG8gc2VuZAorCQkJCSAqLworCQkJCXNwaW5fbG9ja19pcnFzYXZlKCZjYXJkLT5jYXJk X2xvY2ssIGZsYWdzKTsKKwkJCQlza2IgPSBwb3J0LT50eHFbcG9ydC0+dHhxc107CisJCQkJcG9y dC0+dHhxcysrOworCQkJCWlmIChwb3J0LT50eHFzID09IEZTVF9UWFFfREVQVEgpIHsKKwkJCQkJ cG9ydC0+dHhxcyA9IDA7CisJCQkJfQorCQkJCXNwaW5fdW5sb2NrX2lycXJlc3RvcmUoJmNhcmQt PmNhcmRfbG9jaywgZmxhZ3MpOworCQkJCS8qCisJCQkJICogY29weSB0aGUgZGF0YSBhbmQgc2V0 IHRoZSByZXF1aXJlZCBpbmRpY2F0b3JzIG9uIHRoZQorCQkJCSAqIGNhcmQuCisJCQkJICovCisJ CQkJRlNUX1dSVyhjYXJkLCB0eERlc2NyUmluZ1twaV1bcG9ydC0+dHhwb3NdLmJjbnQsCisJCQkJ CWNudl9iY250KHNrYi0+bGVuKSk7CisJCQkJaWYgKChza2ItPmxlbiA8IEZTVF9NSU5fRE1BX0xF TikKKwkJCQkgICAgfHwgKGNhcmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYUCkpIHsKKwkJCQkJ LyogRW5xdWV1ZSB0aGUgcGFja2V0IHdpdGggbm9ybWFsIGlvICovCisJCQkJCW1lbWNweV90b2lv KGNhcmQtPm1lbSArCisJCQkJCQkgICAgQlVGX09GRlNFVCh0eEJ1ZmZlcltwaV0KKwkJCQkJCQkg ICAgICAgW3BvcnQtPgorCQkJCQkJCQl0eHBvc11bMF0pLAorCQkJCQkJICAgIHNrYi0+ZGF0YSwg c2tiLT5sZW4pOworCQkJCQlGU1RfV1JCKGNhcmQsCisJCQkJCQl0eERlc2NyUmluZ1twaV1bcG9y dC0+dHhwb3NdLgorCQkJCQkJYml0cywKKwkJCQkJCURNQV9PV04gfCBUWF9TVFAgfCBUWF9FTlAp OworCQkJCQlwb3J0LT5oZGxjLnN0YXRzLnR4X3BhY2tldHMrKzsKKwkJCQkJcG9ydC0+aGRsYy5z dGF0cy50eF9ieXRlcyArPSBza2ItPmxlbjsKKwkJCQkJcG9ydF90b19kZXYocG9ydCktPnRyYW5z X3N0YXJ0ID0KKwkJCQkJICAgIGppZmZpZXM7CisJCQkJfSBlbHNlIHsKKwkJCQkJLyogT3IgZG8g aXQgdGhyb3VnaCBkbWEgKi8KKwkJCQkJbWVtY3B5KGNhcmQtPnR4X2RtYV9oYW5kbGVfaG9zdCwK KwkJCQkJICAgICAgIHNrYi0+ZGF0YSwgc2tiLT5sZW4pOworCQkJCQljYXJkLT5kbWFfcG9ydF90 eCA9IHBvcnQ7CisJCQkJCWNhcmQtPmRtYV9sZW5fdHggPSBza2ItPmxlbjsKKwkJCQkJY2FyZC0+ ZG1hX3R4cG9zID0gcG9ydC0+dHhwb3M7CisJCQkJCWZzdF90eF9kbWEoY2FyZCwKKwkJCQkJCSAg IChjaGFyICopIGNhcmQtPgorCQkJCQkJICAgdHhfZG1hX2hhbmRsZV9jYXJkLAorCQkJCQkJICAg KGNoYXIgKikKKwkJCQkJCSAgIEJVRl9PRkZTRVQodHhCdWZmZXJbcGldCisJCQkJCQkJICAgICAg W3BvcnQtPnR4cG9zXVswXSksCisJCQkJCQkgICBza2ItPmxlbik7CisJCQkJfQorCQkJCWlmICgr K3BvcnQtPnR4cG9zID49IE5VTV9UWF9CVUZGRVIpCisJCQkJCXBvcnQtPnR4cG9zID0gMDsKKwkJ CQkvKgorCQkJCSAqIElmIHdlIGhhdmUgZmxvdyBjb250cm9sIG9uLCBjYW4gd2Ugbm93IHJlbGVh c2UgaXQ/CisJCQkJICovCisJCQkJaWYgKHBvcnQtPnN0YXJ0KSB7CisJCQkJCWlmICh0eHFfbGVu Z3RoIDwgZnN0X3R4cV9sb3cpIHsKKwkJCQkJCW5ldGlmX3dha2VfcXVldWUocG9ydF90b19kZXYK KwkJCQkJCQkJIChwb3J0KSk7CisJCQkJCQlwb3J0LT5zdGFydCA9IDA7CisJCQkJCX0KKwkJCQl9 CisJCQkJZGV2X2tmcmVlX3NrYihza2IpOworCQkJfSBlbHNlIHsKKwkJCQkvKgorCQkJCSAqIE5v dGhpbmcgdG8gc2VuZCBzbyBicmVhayBvdXQgb2YgdGhlIHdoaWxlIGxvb3AKKwkJCQkgKi8KKwkJ CQlicmVhazsKKwkJCX0KKwkJfQorCX0KK30KKworc3RhdGljIHZvaWQKK2RvX2JvdHRvbV9oYWxm X3J4KHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkKQoreworCXN0cnVjdCBmc3RfcG9ydF9pbmZv ICpwb3J0OworCWludCBwaTsKKwlpbnQgcnhfY291bnQgPSAwOworCisJLyogQ2hlY2sgZm9yIHJ4 IGNvbXBsZXRpb25zIG9uIGFsbCBwb3J0cyBvbiB0aGlzIGNhcmQgKi8KKwlkYmcoREJHX1JYLCAi ZG9fYm90dG9tX2hhbGZfcnhcbiIpOworCWZvciAocGkgPSAwLCBwb3J0ID0gY2FyZC0+cG9ydHM7 IHBpIDwgY2FyZC0+bnBvcnRzOyBwaSsrLCBwb3J0KyspIHsKKwkJaWYgKCFwb3J0LT5ydW4pCisJ CQljb250aW51ZTsKKwkJd2hpbGUgKCEoRlNUX1JEQihjYXJkLCByeERlc2NyUmluZ1twaV1bcG9y dC0+cnhwb3NdLmJpdHMpCisJCQkgJiBETUFfT1dOKSAmJiAhKGNhcmQtPmRtYXJ4X2luX3Byb2dy ZXNzKSkgeworCQkJaWYgKHJ4X2NvdW50ID4gZnN0X21heF9yZWFkcykgeworCQkJCS8qCisJCQkJ ICogRG9uJ3Qgc3BlbmQgZm9yZXZlciBpbiByZWNlaXZlIHByb2Nlc3NpbmcKKwkJCQkgKiBTY2hl ZHVsZSBhbm90aGVyIGV2ZW50CisJCQkJICovCisJCQkJZnN0X3Ffd29ya19pdGVtKCZmc3Rfd29y a19pbnRxLCBjYXJkLT5jYXJkX25vKTsKKwkJCQl0YXNrbGV0X3NjaGVkdWxlKCZmc3RfaW50X3Rh c2spOworCQkJCWJyZWFrOwkvKiBMZWF2ZSB0aGUgbG9vcCAqLworCQkJfQorCQkJZnN0X2ludHJf cngoY2FyZCwgcG9ydCk7CisJCQlyeF9jb3VudCsrOworCQl9CisJfQorfQogCiAvKgogICogICAg ICBUaGUgaW50ZXJydXB0IHNlcnZpY2Ugcm91dGluZQogICogICAgICBEZXZfaWQgaXMgb3VyIGZz dF9jYXJkX2luZm8gcG9pbnRlcgogICovCiBzdGF0aWMgdm9pZAotZnN0X2ludHIgKCBpbnQgaXJx LCB2b2lkICpkZXZfaWQsIHN0cnVjdCBwdF9yZWdzICpyZWdzICkKK2ZzdF9pbnRyKGludCBpcnEs IHZvaWQgKmRldl9pZCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpCiB7Ci0gICAgICAgIHN0cnVjdCBm c3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydDsK LSAgICAgICAgaW50IHJkaWR4OyAgICAgICAgICAgICAgICAgICAgICAvKiBFdmVudCBidWZmZXIg aW5kaWNlcyAqLwotICAgICAgICBpbnQgd3JpZHg7Ci0gICAgICAgIGludCBldmVudDsgICAgICAg ICAgICAgICAgICAgICAgLyogQWN0dWFsIGV2ZW50IGZvciBwcm9jZXNzaW5nICovCi0gICAgICAg IGludCBwaTsKLQotICAgICAgICBpZiAoKCBjYXJkID0gZGV2X2lkICkgPT0gTlVMTCApCi0gICAg ICAgIHsKLSAgICAgICAgICAgICAgICBkYmcgKCBEQkdfSU5UUiwiaW50cjogc3B1cmlvdXMgJWRc biIsIGlycSApOwotICAgICAgICAgICAgICAgIHJldHVybjsKLSAgICAgICAgfQotCi0gICAgICAg IGRiZyAoIERCR19JTlRSLCJpbnRyOiAlZCAlcFxuIiwgaXJxLCBjYXJkICk7Ci0KLSAgICAgICAg c3Bpbl9sb2NrICggJmNhcmQtPmNhcmRfbG9jayApOwotCi0gICAgICAgIC8qIENsZWFyIGFuZCBy ZXByaW1lIHRoZSBpbnRlcnJ1cHQgc291cmNlICovCi0gICAgICAgIGZzdF9jbGVhcl9pbnRyICgg Y2FyZCApOwotCi0gICAgICAgIC8qIFNldCB0aGUgc29mdHdhcmUgYWNrbm93bGVkZ2UgKi8KLSAg ICAgICAgRlNUX1dSQiAoIGNhcmQsIGludGVycnVwdEhhbmRzaGFrZSwgMHhFRSApOwotCi0gICAg ICAgIC8qIERyYWluIHRoZSBldmVudCBxdWV1ZSAqLwotICAgICAgICByZGlkeCA9IEZTVF9SREIg KCBjYXJkLCBpbnRlcnJ1cHRFdmVudC5yZGluZGV4ICk7Ci0gICAgICAgIHdyaWR4ID0gRlNUX1JE QiAoIGNhcmQsIGludGVycnVwdEV2ZW50LndyaW5kZXggKTsKLSAgICAgICAgd2hpbGUgKCByZGlk eCAhPSB3cmlkeCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBldmVudCA9IEZTVF9SREIg KCBjYXJkLCBpbnRlcnJ1cHRFdmVudC5ldm50YnVmZltyZGlkeF0pOwotCi0gICAgICAgICAgICAg ICAgcG9ydCA9ICZjYXJkLT5wb3J0c1tldmVudCAmIDB4MDNdOwotCi0gICAgICAgICAgICAgICAg ZGJnICggREJHX0lOVFIsImludHI6ICV4XG4iLCBldmVudCApOwotCi0gICAgICAgICAgICAgICAg c3dpdGNoICggZXZlbnQgKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICBjYXNl IENUTEFfQ0hHOgotICAgICAgICAgICAgICAgIGNhc2UgQ1RMQl9DSEc6Ci0gICAgICAgICAgICAg ICAgY2FzZSBDVExDX0NIRzoKLSAgICAgICAgICAgICAgICBjYXNlIENUTERfQ0hHOgotICAgICAg ICAgICAgICAgICAgICAgICAgaWYgKCBwb3J0LT5ydW4gKQotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBmc3RfaW50cl9jdGxjaGcgKCBjYXJkLCBwb3J0ICk7Ci0gICAgICAgICAgICAg ICAgICAgICAgICBicmVhazsKLQotICAgICAgICAgICAgICAgIGNhc2UgQUJUQV9TRU5UOgotICAg ICAgICAgICAgICAgIGNhc2UgQUJUQl9TRU5UOgotICAgICAgICAgICAgICAgIGNhc2UgQUJUQ19T RU5UOgotICAgICAgICAgICAgICAgIGNhc2UgQUJURF9TRU5UOgotICAgICAgICAgICAgICAgICAg ICAgICAgZGJnICggREJHX1RYLCJBYm9ydCBjb21wbGV0ZSBwb3J0ICVkXG4iLCBldmVudCAmIDB4 MDMgKTsKLSAgICAgICAgICAgICAgICAgICAgICAgIGJyZWFrOwotCi0gICAgICAgICAgICAgICAg Y2FzZSBUWEFfVU5ERjoKLSAgICAgICAgICAgICAgICBjYXNlIFRYQl9VTkRGOgotICAgICAgICAg ICAgICAgIGNhc2UgVFhDX1VOREY6Ci0gICAgICAgICAgICAgICAgY2FzZSBUWERfVU5ERjoKLSAg ICAgICAgICAgICAgICAgICAgICAgIC8qIERpZmZpY3VsdCB0byBzZWUgaG93IHdlJ2QgZ2V0IHRo aXMgZ2l2ZW4gdGhhdCB3ZQotICAgICAgICAgICAgICAgICAgICAgICAgICogYWx3YXlzIGxvYWQg dXAgdGhlIGVudGlyZSBwYWNrZXQgZm9yIERNQS4KLSAgICAgICAgICAgICAgICAgICAgICAgICAq LwotICAgICAgICAgICAgICAgICAgICAgICAgZGJnICggREJHX1RYLCJUeCB1bmRlcmZsb3cgcG9y dCAlZFxuIiwgZXZlbnQgJiAweDAzICk7Ci0gICAgICAgICAgICAgICAgICAgICAgICBwb3J0LT5o ZGxjLnN0YXRzLnR4X2Vycm9ycysrOwotICAgICAgICAgICAgICAgICAgICAgICAgcG9ydC0+aGRs Yy5zdGF0cy50eF9maWZvX2Vycm9ycysrOwotICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7 Ci0KLSAgICAgICAgICAgICAgICBjYXNlIElOSVRfQ1BMVDoKLSAgICAgICAgICAgICAgICAgICAg ICAgIGRiZyAoIERCR19JTklULCJDYXJkIGluaXQgT0sgaW50clxuIik7Ci0gICAgICAgICAgICAg ICAgICAgICAgICBicmVhazsKLQotICAgICAgICAgICAgICAgIGNhc2UgSU5JVF9GQUlMOgotICAg ICAgICAgICAgICAgICAgICAgICAgZGJnICggREJHX0lOSVQsIkNhcmQgaW5pdCBGQUlMRUQgaW50 clxuIik7Ci0gICAgICAgICAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9JRkFJTEVE OwotICAgICAgICAgICAgICAgICAgICAgICAgYnJlYWs7Ci0KLSAgICAgICAgICAgICAgICBkZWZh dWx0OgotICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoImludHI6IHVua25vd24g Y2FyZCBldmVudCBjb2RlLiBpZ25vcmVkXG4iKTsKLSAgICAgICAgICAgICAgICAgICAgICAgIGJy ZWFrOwotICAgICAgICAgICAgICAgIH0KLQotICAgICAgICAgICAgICAgIC8qIEJ1bXAgYW5kIHdy YXAgdGhlIGluZGV4ICovCi0gICAgICAgICAgICAgICAgaWYgKCArK3JkaWR4ID49IE1BWF9DSVJC VUZGICkKLSAgICAgICAgICAgICAgICAgICAgICAgIHJkaWR4ID0gMDsKLSAgICAgICAgfQotICAg ICAgICBGU1RfV1JCICggY2FyZCwgaW50ZXJydXB0RXZlbnQucmRpbmRleCwgcmRpZHggKTsKLQot ICAgICAgICBmb3IgKCBwaSA9IDAsIHBvcnQgPSBjYXJkLT5wb3J0cyA7IHBpIDwgY2FyZC0+bnBv cnRzIDsgcGkrKywgcG9ydCsrICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIGlmICggISBw b3J0LT5ydW4gKQotICAgICAgICAgICAgICAgICAgICAgICAgY29udGludWU7Ci0KLSAgICAgICAg ICAgICAgICAvKiBDaGVjayBmb3IgcnggY29tcGxldGlvbnMgKi8KLSAgICAgICAgICAgICAgICB3 aGlsZSAoICEgKCBGU1RfUkRCICggY2FyZCwgcnhEZXNjclJpbmdbcGldW3BvcnQtPnJ4cG9zXS5i aXRzICkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmIERNQV9PV04gKSkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAg ICAgICAgICAgICAgICBmc3RfaW50cl9yeCAoIGNhcmQsIHBvcnQgKTsKLSAgICAgICAgICAgICAg ICB9Ci0KLSAgICAgICAgICAgICAgICAvKiBDaGVjayBmb3IgVHggY29tcGxldGlvbnMgKi8KLSAg ICAgICAgICAgICAgICB3aGlsZSAoIHBvcnQtPnR4Y250ID4gMCAmJiAhICggRlNUX1JEQiAoIGNh cmQsCi0gICAgICAgICAgICAgICAgICAgICAgICB0eERlc2NyUmluZ1twaV1bcG9ydC0+dHhpcG9z XS5iaXRzICkgJiBETUFfT1dOICkpCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAg ICAgICAgICAgLS1wb3J0LT50eGNudDsKLSAgICAgICAgICAgICAgICAgICAgICAgIGlmICggKytw b3J0LT50eGlwb3MgPj0gTlVNX1RYX0JVRkZFUiApCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHBvcnQtPnR4aXBvcyA9IDA7Ci0gICAgICAgICAgICAgICAgICAgICAgICBuZXRpZl93 YWtlX3F1ZXVlICggcG9ydF90b19kZXYgKCBwb3J0ICkpOwotICAgICAgICAgICAgICAgIH0KLSAg ICAgICAgfQorCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOworCXN0cnVjdCBmc3RfcG9ydF9p bmZvICpwb3J0OworCWludCByZGlkeDsJCS8qIEV2ZW50IGJ1ZmZlciBpbmRpY2VzICovCisJaW50 IHdyaWR4OworCWludCBldmVudDsJCS8qIEFjdHVhbCBldmVudCBmb3IgcHJvY2Vzc2luZyAqLwor CXVuc2lnbmVkIGludCBkbWFfaW50Y3NyID0gMDsKKwl1bnNpZ25lZCBpbnQgZG9fY2FyZF9pbnRl cnJ1cHQ7CisJdW5zaWduZWQgaW50IGludF9yZXRyeV9jb3VudDsKKworCWlmICgoY2FyZCA9IGRl dl9pZCkgPT0gTlVMTCkgeworCQlkYmcoREJHX0lOVFIsICJpbnRyOiBzcHVyaW91cyAlZFxuIiwg aXJxKTsKKwkJcmV0dXJuOworCX0KIAotICAgICAgICBzcGluX3VubG9jayAoICZjYXJkLT5jYXJk X2xvY2sgKTsKLX0KKwkvKgorCSAqIENoZWNrIHRvIHNlZSBpZiB0aGUgaW50ZXJydXB0IHdhcyBm b3IgdGhpcyBjYXJkCisJICogcmV0dXJuIGlmIG5vdAorCSAqIE5vdGUgdGhhdCB0aGUgY2FsbCB0 byBjbGVhciB0aGUgaW50ZXJydXB0IGlzIGltcG9ydGFudAorCSAqLworCWRiZyhEQkdfSU5UUiwg ImludHI6ICVkICVwXG4iLCBpcnEsIGNhcmQpOworCWlmIChjYXJkLT5zdGF0ZSAhPSBGU1RfUlVO TklORykgeworCQlwcmludGtfZXJyCisJCSAgICAoIkludGVycnVwdCByZWNlaXZlZCBmb3IgY2Fy ZCAlZCBpbiBhIG5vbiBydW5uaW5nIHN0YXRlICglZClcbiIsCisJCSAgICAgY2FyZC0+Y2FyZF9u bywgY2FyZC0+c3RhdGUpOworCisJCS8qIAorCQkgKiBJdCBpcyBwb3NzaWJsZSB0byByZWFsbHkg YmUgcnVubmluZywgaS5lLiB3ZSBoYXZlIHJlLWxvYWRlZAorCQkgKiBhIHJ1bm5pbmcgY2FyZAor CQkgKiBDbGVhciBhbmQgcmVwcmltZSB0aGUgaW50ZXJydXB0IHNvdXJjZSAKKwkJICovCisJCWZz dF9jbGVhcl9pbnRyKGNhcmQpOworCQlyZXR1cm47CisJfQorCisJLyogQ2xlYXIgYW5kIHJlcHJp bWUgdGhlIGludGVycnVwdCBzb3VyY2UgKi8KKwlmc3RfY2xlYXJfaW50cihjYXJkKTsKKworCS8q CisJICogSXMgdGhlIGludGVycnVwdCBmb3IgdGhpcyBjYXJkIChoYW5kc2hha2UgPT0gMSkKKwkg Ki8KKwlkb19jYXJkX2ludGVycnVwdCA9IDA7CisJaWYgKEZTVF9SREIoY2FyZCwgaW50ZXJydXB0 SGFuZHNoYWtlKSA9PSAxKSB7CisJCWRvX2NhcmRfaW50ZXJydXB0ICs9IEZTVF9DQVJEX0lOVDsK KwkJLyogU2V0IHRoZSBzb2Z0d2FyZSBhY2tub3dsZWRnZSAqLworCQlGU1RfV1JCKGNhcmQsIGlu dGVycnVwdEhhbmRzaGFrZSwgMHhFRSk7CisJfQorCWlmIChjYXJkLT5mYW1pbHkgPT0gRlNUX0ZB TUlMWV9UWFUpIHsKKwkJLyoKKwkJICogSXMgaXQgYSBETUEgSW50ZXJydXB0CisJCSAqLworCQlk bWFfaW50Y3NyID0gaW5sKGNhcmQtPnBjaV9jb25mICsgSU5UQ1NSXzkwNTQpOworCQlpZiAoZG1h X2ludGNzciAmIDB4MDAyMDAwMDApIHsKKwkJCS8qCisJCQkgKiBETUEgQ2hhbm5lbCAwIChSeCB0 cmFuc2ZlciBjb21wbGV0ZSkKKwkJCSAqLworCQkJZGJnKERCR19SWCwgIkRNQSBSeCB4ZmVyIGNv bXBsZXRlXG4iKTsKKwkJCW91dGIoMHg4LCBjYXJkLT5wY2lfY29uZiArIERNQUNTUjApOworCQkJ ZnN0X3J4X2RtYV9jb21wbGV0ZShjYXJkLCBjYXJkLT5kbWFfcG9ydF9yeCwKKwkJCQkJICAgIGNh cmQtPmRtYV9sZW5fcngsIGNhcmQtPmRtYV9za2JfcngsCisJCQkJCSAgICBjYXJkLT5kbWFfcnhw b3MpOworCQkJY2FyZC0+ZG1hcnhfaW5fcHJvZ3Jlc3MgPSAwOworCQkJZG9fY2FyZF9pbnRlcnJ1 cHQgKz0gRlNUX1JYX0RNQV9JTlQ7CisJCX0KKwkJaWYgKGRtYV9pbnRjc3IgJiAweDAwNDAwMDAw KSB7CisJCQkvKgorCQkJICogRE1BIENoYW5uZWwgMSAoVHggdHJhbnNmZXIgY29tcGxldGUpCisJ CQkgKi8KKwkJCWRiZyhEQkdfVFgsICJETUEgVHggeGZlciBjb21wbGV0ZVxuIik7CisJCQlvdXRi KDB4OCwgY2FyZC0+cGNpX2NvbmYgKyBETUFDU1IxKTsKKwkJCWZzdF90eF9kbWFfY29tcGxldGUo Y2FyZCwgY2FyZC0+ZG1hX3BvcnRfdHgsCisJCQkJCSAgICBjYXJkLT5kbWFfbGVuX3R4LCBjYXJk LT5kbWFfdHhwb3MpOworCQkJY2FyZC0+ZG1hdHhfaW5fcHJvZ3Jlc3MgPSAwOworCQkJZG9fY2Fy ZF9pbnRlcnJ1cHQgKz0gRlNUX1RYX0RNQV9JTlQ7CisJCX0KKwl9CiAKKwkvKgorCSAqIEhhdmUg d2UgYmVlbiBtaXNzaW5nIEludGVycnVwdHMKKwkgKi8KKwlpbnRfcmV0cnlfY291bnQgPSBGU1Rf UkRMKGNhcmQsIGludGVycnVwdFJldHJ5Q291bnQpOworCWlmIChpbnRfcmV0cnlfY291bnQpIHsK KwkJZGJnKERCR19BU1MsICJDYXJkICVkIGludF9yZXRyeV9jb3VudCBpcyAgJWRcbiIsCisJCSAg ICBjYXJkLT5jYXJkX25vLCBpbnRfcmV0cnlfY291bnQpOworCQlGU1RfV1JMKGNhcmQsIGludGVy cnVwdFJldHJ5Q291bnQsIDApOworCX0KKworCWlmICghZG9fY2FyZF9pbnRlcnJ1cHQpIHsKKwkJ cmV0dXJuOworCX0KKworCS8qIFNjZWhkdWxlIHRoZSBib3R0b20gaGFsZiBvZiB0aGUgSVNSICov CisJZnN0X3Ffd29ya19pdGVtKCZmc3Rfd29ya19pbnRxLCBjYXJkLT5jYXJkX25vKTsKKwl0YXNr bGV0X3NjaGVkdWxlKCZmc3RfaW50X3Rhc2spOworCisJLyogRHJhaW4gdGhlIGV2ZW50IHF1ZXVl ICovCisJcmRpZHggPSBGU1RfUkRCKGNhcmQsIGludGVycnVwdEV2ZW50LnJkaW5kZXgpICYgMHgx ZjsKKwl3cmlkeCA9IEZTVF9SREIoY2FyZCwgaW50ZXJydXB0RXZlbnQud3JpbmRleCkgJiAweDFm OworCXdoaWxlIChyZGlkeCAhPSB3cmlkeCkgeworCQlldmVudCA9IEZTVF9SREIoY2FyZCwgaW50 ZXJydXB0RXZlbnQuZXZudGJ1ZmZbcmRpZHhdKTsKKwkJcG9ydCA9ICZjYXJkLT5wb3J0c1tldmVu dCAmIDB4MDNdOworCisJCWRiZyhEQkdfSU5UUiwgIlByb2Nlc3NpbmcgSW50ZXJydXB0IGV2ZW50 OiAleFxuIiwgZXZlbnQpOworCisJCXN3aXRjaCAoZXZlbnQpIHsKKwkJY2FzZSBURTFfQUxNQToK KwkJCWRiZyhEQkdfSU5UUiwgIlRFMSBBbGFybSBpbnRyXG4iKTsKKwkJCWlmIChwb3J0LT5ydW4p CisJCQkJZnN0X2ludHJfdGUxX2FsYXJtKGNhcmQsIHBvcnQpOworCQkJYnJlYWs7CisKKwkJY2Fz ZSBDVExBX0NIRzoKKwkJY2FzZSBDVExCX0NIRzoKKwkJY2FzZSBDVExDX0NIRzoKKwkJY2FzZSBD VExEX0NIRzoKKwkJCWlmIChwb3J0LT5ydW4pCisJCQkJZnN0X2ludHJfY3RsY2hnKGNhcmQsIHBv cnQpOworCQkJYnJlYWs7CisKKwkJY2FzZSBBQlRBX1NFTlQ6CisJCWNhc2UgQUJUQl9TRU5UOgor CQljYXNlIEFCVENfU0VOVDoKKwkJY2FzZSBBQlREX1NFTlQ6CisJCQlkYmcoREJHX1RYLCAiQWJv cnQgY29tcGxldGUgcG9ydCAlZFxuIiwgcG9ydC0+aW5kZXgpOworCQkJYnJlYWs7CisKKwkJY2Fz ZSBUWEFfVU5ERjoKKwkJY2FzZSBUWEJfVU5ERjoKKwkJY2FzZSBUWENfVU5ERjoKKwkJY2FzZSBU WERfVU5ERjoKKwkJCS8qIERpZmZpY3VsdCB0byBzZWUgaG93IHdlJ2QgZ2V0IHRoaXMgZ2l2ZW4g dGhhdCB3ZQorCQkJICogYWx3YXlzIGxvYWQgdXAgdGhlIGVudGlyZSBwYWNrZXQgZm9yIERNQS4K KwkJCSAqLworCQkJZGJnKERCR19UWCwgIlR4IHVuZGVyZmxvdyBwb3J0ICVkXG4iLCBwb3J0LT5p bmRleCk7CisKKwkJCXBvcnQtPmhkbGMuc3RhdHMudHhfZXJyb3JzKys7CisJCQlwb3J0LT5oZGxj LnN0YXRzLnR4X2ZpZm9fZXJyb3JzKys7CisJCQlkYmcoREJHX0FTUywgIlR4IHVuZGVyZmxvdyBv biBjYXJkICVkIHBvcnQgJWRcbiIsCisJCQkgICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgp OworCQkJYnJlYWs7CisKKwkJY2FzZSBJTklUX0NQTFQ6CisJCQlkYmcoREJHX0lOSVQsICJDYXJk IGluaXQgT0sgaW50clxuIik7CisJCQlicmVhazsKKworCQljYXNlIElOSVRfRkFJTDoKKwkJCWRi ZyhEQkdfSU5JVCwgIkNhcmQgaW5pdCBGQUlMRUQgaW50clxuIik7CisJCQljYXJkLT5zdGF0ZSA9 IEZTVF9JRkFJTEVEOworCQkJYnJlYWs7CisKKwkJZGVmYXVsdDoKKwkJCXByaW50a19lcnIoImlu dHI6IHVua25vd24gY2FyZCBldmVudCAlZC4gaWdub3JlZFxuIiwKKwkJCQkgICBldmVudCk7CisJ CQlicmVhazsKKwkJfQorCisJCS8qIEJ1bXAgYW5kIHdyYXAgdGhlIGluZGV4ICovCisJCWlmICgr K3JkaWR4ID49IE1BWF9DSVJCVUZGKQorCQkJcmRpZHggPSAwOworCX0KKwlGU1RfV1JCKGNhcmQs IGludGVycnVwdEV2ZW50LnJkaW5kZXgsIHJkaWR4KTsKK30KIAogLyogICAgICBDaGVjayB0aGF0 IHRoZSBzaGFyZWQgbWVtb3J5IGNvbmZpZ3VyYXRpb24gaXMgb25lIHRoYXQgd2UgY2FuIGhhbmRs ZQogICogICAgICBhbmQgdGhhdCBzb21lIGJhc2ljIHBhcmFtZXRlcnMgYXJlIGNvcnJlY3QKICAq Lwogc3RhdGljIHZvaWQKLWNoZWNrX3N0YXJ0ZWRfb2sgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAq Y2FyZCApCitjaGVja19zdGFydGVkX29rKHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkKQogewot ICAgICAgICBpbnQgaTsKKwlpbnQgaTsKIAotICAgICAgICAvKiBDaGVjayBzdHJ1Y3R1cmUgdmVy c2lvbiBhbmQgZW5kIG1hcmtlciAqLwotICAgICAgICBpZiAoIEZTVF9SRFcgKCBjYXJkLCBzbWNW ZXJzaW9uICkgIT0gU01DX1ZFUlNJT04gKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgcHJp bnRrX2VyciAoIkJhZCBzaGFyZWQgbWVtb3J5IHZlcnNpb24gJWQgZXhwZWN0ZWQgJWRcbiIsCi0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZTVF9SRFcgKCBjYXJkLCBzbWNWZXJzaW9u ICksIFNNQ19WRVJTSU9OICk7Ci0gICAgICAgICAgICAgICAgY2FyZC0+c3RhdGUgPSBGU1RfQkFE VkVSU0lPTjsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0gICAgICAgIH0KLSAgICAgICAgaWYg KCBGU1RfUkRMICggY2FyZCwgZW5kT2ZTbWNTaWduYXR1cmUgKSAhPSBFTkRfU0lHICkKLSAgICAg ICAgewotICAgICAgICAgICAgICAgIHByaW50a19lcnIgKCJNaXNzaW5nIHNoYXJlZCBtZW1vcnkg c2lnbmF0dXJlXG4iKTsKLSAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9CQURWRVJT SU9OOwotICAgICAgICAgICAgICAgIHJldHVybjsKLSAgICAgICAgfQotICAgICAgICAvKiBGaXJt d2FyZSBzdGF0dXMgZmxhZywgMHgwMCA9IGluaXRpYWxpc2luZywgMHgwMSA9IE9LLCAweEZGID0g ZmFpbCAqLwotICAgICAgICBpZiAoKCBpID0gRlNUX1JEQiAoIGNhcmQsIHRhc2tTdGF0dXMgKSkg PT0gMHgwMSApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9S VU5OSU5HOwotICAgICAgICB9Ci0gICAgICAgIGVsc2UgaWYgKCBpID09IDB4RkYgKQotICAgICAg ICB7Ci0gICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIkZpcm13YXJlIGluaXRpYWxpc2F0aW9u IGZhaWxlZC4gQ2FyZCBoYWx0ZWRcbiIpOwotICAgICAgICAgICAgICAgIGNhcmQtPnN0YXRlID0g RlNUX0hBTFRFRDsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0gICAgICAgIH0KLSAgICAgICAg ZWxzZSBpZiAoIGkgIT0gMHgwMCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBwcmludGtf ZXJyICgiVW5rbm93biBmaXJtd2FyZSBzdGF0dXMgMHgleFxuIiwgaSApOwotICAgICAgICAgICAg ICAgIGNhcmQtPnN0YXRlID0gRlNUX0hBTFRFRDsKLSAgICAgICAgICAgICAgICByZXR1cm47Ci0g ICAgICAgIH0KLQotICAgICAgICAvKiBGaW5hbGx5IGNoZWNrIHRoZSBudW1iZXIgb2YgcG9ydHMg cmVwb3J0ZWQgYnkgZmlybXdhcmUgYWdhaW5zdCB0aGUKLSAgICAgICAgICogbnVtYmVyIHdlIGFz c3VtZWQgYXQgY2FyZCBkZXRlY3Rpb24uIFNob3VsZCBuZXZlciBoYXBwZW4gd2l0aAotICAgICAg ICAgKiBleGlzdGluZyBmaXJtd2FyZSBldGMgc28gd2UganVzdCByZXBvcnQgaXQgZm9yIHRoZSBt b21lbnQuCi0gICAgICAgICAqLwotICAgICAgICBpZiAoIEZTVF9SREwgKCBjYXJkLCBudW1iZXJP ZlBvcnRzICkgIT0gY2FyZC0+bnBvcnRzICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIHBy aW50a193YXJuICgiUG9ydCBjb3VudCBtaXNtYXRjaC4iCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICIgRmlybXdhcmUgdGhpbmtzICVkIHdlIHNheSAlZFxuIiwKLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRlNUX1JETCAoIGNhcmQsIG51bWJlck9mUG9ydHMgKSwgY2Fy ZC0+bnBvcnRzICk7Ci0gICAgICAgIH0KLX0KKwkvKiBDaGVjayBzdHJ1Y3R1cmUgdmVyc2lvbiBh bmQgZW5kIG1hcmtlciAqLworCWlmIChGU1RfUkRXKGNhcmQsIHNtY1ZlcnNpb24pICE9IFNNQ19W RVJTSU9OKSB7CisJCXByaW50a19lcnIoIkJhZCBzaGFyZWQgbWVtb3J5IHZlcnNpb24gJWQgZXhw ZWN0ZWQgJWRcbiIsCisJCQkgICBGU1RfUkRXKGNhcmQsIHNtY1ZlcnNpb24pLCBTTUNfVkVSU0lP Tik7CisJCWNhcmQtPnN0YXRlID0gRlNUX0JBRFZFUlNJT047CisJCXJldHVybjsKKwl9CisJaWYg KEZTVF9SREwoY2FyZCwgZW5kT2ZTbWNTaWduYXR1cmUpICE9IEVORF9TSUcpIHsKKwkJcHJpbnRr X2VycigiTWlzc2luZyBzaGFyZWQgbWVtb3J5IHNpZ25hdHVyZVxuIik7CisJCWNhcmQtPnN0YXRl ID0gRlNUX0JBRFZFUlNJT047CisJCXJldHVybjsKKwl9CisJLyogRmlybXdhcmUgc3RhdHVzIGZs YWcsIDB4MDAgPSBpbml0aWFsaXNpbmcsIDB4MDEgPSBPSywgMHhGRiA9IGZhaWwgKi8KKwlpZiAo KGkgPSBGU1RfUkRCKGNhcmQsIHRhc2tTdGF0dXMpKSA9PSAweDAxKSB7CisJCWNhcmQtPnN0YXRl ID0gRlNUX1JVTk5JTkc7CisJfSBlbHNlIGlmIChpID09IDB4RkYpIHsKKwkJcHJpbnRrX2Vycigi RmlybXdhcmUgaW5pdGlhbGlzYXRpb24gZmFpbGVkLiBDYXJkIGhhbHRlZFxuIik7CisJCWNhcmQt PnN0YXRlID0gRlNUX0hBTFRFRDsKKwkJcmV0dXJuOworCX0gZWxzZSBpZiAoaSAhPSAweDAwKSB7 CisJCXByaW50a19lcnIoIlVua25vd24gZmlybXdhcmUgc3RhdHVzIDB4JXhcbiIsIGkpOworCQlj YXJkLT5zdGF0ZSA9IEZTVF9IQUxURUQ7CisJCXJldHVybjsKKwl9CiAKKwkvKiBGaW5hbGx5IGNo ZWNrIHRoZSBudW1iZXIgb2YgcG9ydHMgcmVwb3J0ZWQgYnkgZmlybXdhcmUgYWdhaW5zdCB0aGUK KwkgKiBudW1iZXIgd2UgYXNzdW1lZCBhdCBjYXJkIGRldGVjdGlvbi4gU2hvdWxkIG5ldmVyIGhh cHBlbiB3aXRoCisJICogZXhpc3RpbmcgZmlybXdhcmUgZXRjIHNvIHdlIGp1c3QgcmVwb3J0IGl0 IGZvciB0aGUgbW9tZW50LgorCSAqLworCWlmIChGU1RfUkRMKGNhcmQsIG51bWJlck9mUG9ydHMp ICE9IGNhcmQtPm5wb3J0cykgeworCQlwcmludGtfd2FybigiUG9ydCBjb3VudCBtaXNtYXRjaCBv biBjYXJkICVkLiIKKwkJCSAgICAiIEZpcm13YXJlIHRoaW5rcyAlZCB3ZSBzYXkgJWRcbiIsIGNh cmQtPmNhcmRfbm8sCisJCQkgICAgRlNUX1JETChjYXJkLCBudW1iZXJPZlBvcnRzKSwgY2FyZC0+ bnBvcnRzKTsKKwl9Cit9CiAKIHN0YXRpYyBpbnQKLXNldF9jb25mX2Zyb21faW5mbyAoIHN0cnVj dCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCwKLSAgICAg ICAgICAgICAgICBzdHJ1Y3QgZnN0aW9jX2luZm8gKmluZm8gKQorc2V0X2NvbmZfZnJvbV9pbmZv KHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkLCBzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydCwK KwkJICAgc3RydWN0IGZzdGlvY19pbmZvICppbmZvKQogewotICAgICAgICBpbnQgZXJyOworCWlu dCBlcnI7CisJdW5zaWduZWQgY2hhciBteV9mcmFtaW5nOwogCi0gICAgICAgIC8qIFNldCB0aGlu Z3MgYWNjb3JkaW5nIHRvIHRoZSB1c2VyIHNldCB2YWxpZCBmbGFncy4KLSAgICAgICAgICogU2V2 ZXJhbCBvZiB0aGUgb2xkIG9wdGlvbnMgaGF2ZSBiZWVuIGludmFsaWRhdGVkL3JlcGxhY2VkIGJ5 IHRoZQotICAgICAgICAgKiBnZW5lcmljIEhETEMgcGFja2FnZS4KLSAgICAgICAgICovCi0gICAg ICAgIGVyciA9IDA7Ci0gICAgICAgIGlmICggaW5mby0+dmFsaWQgJiBGU1RWQUxfUFJPVE8gKQot ICAgICAgICAgICAgICAgIGVyciA9IC1FSU5WQUw7Ci0gICAgICAgIGlmICggaW5mby0+dmFsaWQg JiBGU1RWQUxfQ0FCTEUgKQotICAgICAgICAgICAgICAgIGVyciA9IC1FSU5WQUw7Ci0gICAgICAg IGlmICggaW5mby0+dmFsaWQgJiBGU1RWQUxfU1BFRUQgKQotICAgICAgICAgICAgICAgIGVyciA9 IC1FSU5WQUw7CisJLyogU2V0IHRoaW5ncyBhY2NvcmRpbmcgdG8gdGhlIHVzZXIgc2V0IHZhbGlk IGZsYWdzIAorCSAqIFNldmVyYWwgb2YgdGhlIG9sZCBvcHRpb25zIGhhdmUgYmVlbiBpbnZhbGlk YXRlZC9yZXBsYWNlZCBieSB0aGUgCisJICogZ2VuZXJpYyBoZGxjIHBhY2thZ2UuCisJICovCisJ ZXJyID0gMDsKKwlpZiAoaW5mby0+dmFsaWQgJiBGU1RWQUxfUFJPVE8pIHsKKwkJaWYgKGluZm8t PnByb3RvID09IEZTVF9SQVcpCisJCQlwb3J0LT5tb2RlID0gRlNUX1JBVzsKKwkJZWxzZQorCQkJ cG9ydC0+bW9kZSA9IEZTVF9HRU5fSERMQzsKKwl9CisKKwlpZiAoaW5mby0+dmFsaWQgJiBGU1RW QUxfQ0FCTEUpCisJCWVyciA9IC1FSU5WQUw7CiAKLSAgICAgICAgaWYgKCBpbmZvLT52YWxpZCAm IEZTVFZBTF9NT0RFICkKLSAgICAgICAgICAgICAgICBGU1RfV1JXICggY2FyZCwgY2FyZE1vZGUs IGluZm8tPmNhcmRNb2RlICk7CisJaWYgKGluZm8tPnZhbGlkICYgRlNUVkFMX1NQRUVEKQorCQll cnIgPSAtRUlOVkFMOworCisJaWYgKGluZm8tPnZhbGlkICYgRlNUVkFMX1BIQVNFKQorCQlGU1Rf V1JCKGNhcmQsIHBvcnRDb25maWdbcG9ydC0+aW5kZXhdLmludmVydENsb2NrLAorCQkJaW5mby0+ aW52ZXJ0Q2xvY2spOworCWlmIChpbmZvLT52YWxpZCAmIEZTVFZBTF9NT0RFKQorCQlGU1RfV1JX KGNhcmQsIGNhcmRNb2RlLCBpbmZvLT5jYXJkTW9kZSk7CisJaWYgKGluZm8tPnZhbGlkICYgRlNU VkFMX1RFMSkgeworCQlGU1RfV1JMKGNhcmQsIHN1Q29uZmlnLmRhdGFSYXRlLCBpbmZvLT5saW5l U3BlZWQpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmNsb2NraW5nLCBpbmZvLT5jbG9ja1Nv dXJjZSk7CisJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0UxOworCQlpZiAoaW5mby0+ZnJhbWluZyA9 PSBFMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0UxOworCQlpZiAoaW5mby0+ZnJhbWluZyA9 PSBUMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX1QxOworCQlpZiAoaW5mby0+ZnJhbWluZyA9 PSBKMSkKKwkJCW15X2ZyYW1pbmcgPSBGUkFNSU5HX0oxOworCQlGU1RfV1JCKGNhcmQsIHN1Q29u ZmlnLmZyYW1pbmcsIG15X2ZyYW1pbmcpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLnN0cnVj dHVyZSwgaW5mby0+c3RydWN0dXJlKTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5pbnRlcmZh Y2UsIGluZm8tPmludGVyZmFjZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcuY29kaW5nLCBp bmZvLT5jb2RpbmcpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmxpbmVCdWlsZE91dCwgaW5m by0+bGluZUJ1aWxkT3V0KTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5lcXVhbGl6ZXIsIGlu Zm8tPmVxdWFsaXplcik7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcudHJhbnNwYXJlbnRNb2Rl LCBpbmZvLT50cmFuc3BhcmVudE1vZGUpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLmxvb3BN b2RlLCBpbmZvLT5sb29wTW9kZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcucmFuZ2UsIGlu Zm8tPnJhbmdlKTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy50eEJ1ZmZlck1vZGUsIGluZm8t PnR4QnVmZmVyTW9kZSk7CisJCUZTVF9XUkIoY2FyZCwgc3VDb25maWcucnhCdWZmZXJNb2RlLCBp bmZvLT5yeEJ1ZmZlck1vZGUpOworCQlGU1RfV1JCKGNhcmQsIHN1Q29uZmlnLnN0YXJ0aW5nU2xv dCwgaW5mby0+c3RhcnRpbmdTbG90KTsKKwkJRlNUX1dSQihjYXJkLCBzdUNvbmZpZy5sb3NUaHJl c2hvbGQsIGluZm8tPmxvc1RocmVzaG9sZCk7CisJCWlmIChpbmZvLT5pZGxlQ29kZSkKKwkJCUZT VF9XUkIoY2FyZCwgc3VDb25maWcuZW5hYmxlSWRsZUNvZGUsIDEpOworCQllbHNlCisJCQlGU1Rf V1JCKGNhcmQsIHN1Q29uZmlnLmVuYWJsZUlkbGVDb2RlLCAwKTsKKwkJRlNUX1dSQihjYXJkLCBz dUNvbmZpZy5pZGxlQ29kZSwgaW5mby0+aWRsZUNvZGUpOwogI2lmIEZTVF9ERUJVRwotICAgICAg ICBpZiAoIGluZm8tPnZhbGlkICYgRlNUVkFMX0RFQlVHICkKLSAgICAgICAgICAgICAgICBmc3Rf ZGVidWdfbWFzayA9IGluZm8tPmRlYnVnOworCQlpZiAoaW5mby0+dmFsaWQgJiBGU1RWQUxfVEUx KSB7CisJCQlwcmludGsoIlNldHRpbmcgVEUxIGRhdGFcbiIpOworCQkJcHJpbnRrKCJMaW5lIFNw ZWVkID0gJWRcbiIsIGluZm8tPmxpbmVTcGVlZCk7CisJCQlwcmludGsoIlN0YXJ0IHNsb3QgPSAl ZFxuIiwgaW5mby0+c3RhcnRpbmdTbG90KTsKKwkJCXByaW50aygiQ2xvY2sgc291cmNlID0gJWRc biIsIGluZm8tPmNsb2NrU291cmNlKTsKKwkJCXByaW50aygiRnJhbWluZyA9ICVkXG4iLCBteV9m cmFtaW5nKTsKKwkJCXByaW50aygiU3RydWN0dXJlID0gJWRcbiIsIGluZm8tPnN0cnVjdHVyZSk7 CisJCQlwcmludGsoImludGVyZmFjZSA9ICVkXG4iLCBpbmZvLT5pbnRlcmZhY2UpOworCQkJcHJp bnRrKCJDb2RpbmcgPSAlZFxuIiwgaW5mby0+Y29kaW5nKTsKKwkJCXByaW50aygiTGluZSBidWls ZCBvdXQgPSAlZFxuIiwgaW5mby0+bGluZUJ1aWxkT3V0KTsKKwkJCXByaW50aygiRXF1YWxpc2Vy ID0gJWRcbiIsIGluZm8tPmVxdWFsaXplcik7CisJCQlwcmludGsoIlRyYW5zcGFyZW50IG1vZGUg PSAlZFxuIiwKKwkJCSAgICAgICBpbmZvLT50cmFuc3BhcmVudE1vZGUpOworCQkJcHJpbnRrKCJM b29wIG1vZGUgPSAlZFxuIiwgaW5mby0+bG9vcE1vZGUpOworCQkJcHJpbnRrKCJSYW5nZSA9ICVk XG4iLCBpbmZvLT5yYW5nZSk7CisJCQlwcmludGsoIlR4IEJ1ZmZlciBtb2RlID0gJWRcbiIsIGlu Zm8tPnR4QnVmZmVyTW9kZSk7CisJCQlwcmludGsoIlJ4IEJ1ZmZlciBtb2RlID0gJWRcbiIsIGlu Zm8tPnJ4QnVmZmVyTW9kZSk7CisJCQlwcmludGsoIkxPUyBUaHJlc2hvbGQgPSAlZFxuIiwgaW5m by0+bG9zVGhyZXNob2xkKTsKKwkJCXByaW50aygiSWRsZSBDb2RlID0gJWRcbiIsIGluZm8tPmlk bGVDb2RlKTsKKwkJfQorI2VuZGlmCisJfQorI2lmIEZTVF9ERUJVRworCWlmIChpbmZvLT52YWxp ZCAmIEZTVFZBTF9ERUJVRykgeworCQlmc3RfZGVidWdfbWFzayA9IGluZm8tPmRlYnVnOworCX0K ICNlbmRpZgogCi0gICAgICAgIHJldHVybiBlcnI7CisJcmV0dXJuIGVycjsKIH0KIAogc3RhdGlj IHZvaWQKLWdhdGhlcl9jb25mX2luZm8gKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCwgc3Ry dWN0IGZzdF9wb3J0X2luZm8gKnBvcnQsCi0gICAgICAgICAgICAgICAgc3RydWN0IGZzdGlvY19p bmZvICppbmZvICkKK2dhdGhlcl9jb25mX2luZm8oc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQs IHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCQkgc3RydWN0IGZzdGlvY19pbmZvICppbmZv KQogewotICAgICAgICBpbnQgaTsKKwlpbnQgaTsKIAotICAgICAgICBtZW1zZXQgKCBpbmZvLCAw LCBzaXplb2YgKCBzdHJ1Y3QgZnN0aW9jX2luZm8gKSk7CisJbWVtc2V0KGluZm8sIDAsIHNpemVv ZiAoc3RydWN0IGZzdGlvY19pbmZvKSk7CiAKLSAgICAgICAgaSA9IHBvcnQtPmluZGV4OwotICAg ICAgICBpbmZvLT5ucG9ydHMgPSBjYXJkLT5ucG9ydHM7Ci0gICAgICAgIGluZm8tPnR5cGUgICA9 IGNhcmQtPnR5cGU7Ci0gICAgICAgIGluZm8tPnN0YXRlICA9IGNhcmQtPnN0YXRlOwotICAgICAg ICBpbmZvLT5wcm90byAgPSBGU1RfR0VOX0hETEM7Ci0gICAgICAgIGluZm8tPmluZGV4ICA9IGk7 CisJaSA9IHBvcnQtPmluZGV4OworCWluZm8tPmtlcm5lbFZlcnNpb24gPSBMSU5VWF9WRVJTSU9O X0NPREU7CisJaW5mby0+bnBvcnRzID0gY2FyZC0+bnBvcnRzOworCWluZm8tPnR5cGUgPSBjYXJk LT50eXBlOworCWluZm8tPnN0YXRlID0gY2FyZC0+c3RhdGU7CisJaW5mby0+cHJvdG8gPSBGU1Rf R0VOX0hETEM7CisJaW5mby0+aW5kZXggPSBpOwogI2lmIEZTVF9ERUJVRwotICAgICAgICBpbmZv LT5kZWJ1ZyAgPSBmc3RfZGVidWdfbWFzazsKKwlpbmZvLT5kZWJ1ZyA9IGZzdF9kZWJ1Z19tYXNr OwogI2VuZGlmCiAKLSAgICAgICAgLyogT25seSBtYXJrIGluZm9ybWF0aW9uIGFzIHZhbGlkIGlm IGNhcmQgaXMgcnVubmluZy4KLSAgICAgICAgICogQ29weSB0aGUgZGF0YSBhbnl3YXkgaW4gY2Fz ZSBpdCBpcyB1c2VmdWwgZm9yIGRpYWdub3N0aWNzCi0gICAgICAgICAqLwotICAgICAgICBpbmZv LT52YWxpZAotICAgICAgICAgICAgICAgID0gKCggY2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5JTkcg KSA/IEZTVFZBTF9BTEwgOiBGU1RWQUxfQ0FSRCApCisJLyogT25seSBtYXJrIGluZm9ybWF0aW9u IGFzIHZhbGlkIGlmIGNhcmQgaXMgcnVubmluZy4KKwkgKiBDb3B5IHRoZSBkYXRhIGFueXdheSBp biBjYXNlIGl0IGlzIHVzZWZ1bCBmb3IgZGlhZ25vc3RpY3MKKwkgKi8KKwlpbmZvLT52YWxpZCA9 ICgoY2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5JTkcpID8gRlNUVkFMX0FMTCA6IEZTVFZBTF9DQVJE KQogI2lmIEZTVF9ERUJVRwotICAgICAgICAgICAgICAgIHwgRlNUVkFMX0RFQlVHCisJICAgIHwg RlNUVkFMX0RFQlVHCiAjZW5kaWYKLSAgICAgICAgICAgICAgICA7CisJICAgIDsKIAotICAgICAg ICBpbmZvLT5saW5lSW50ZXJmYWNlID0gRlNUX1JEVyAoIGNhcmQsIHBvcnRDb25maWdbaV0ubGlu ZUludGVyZmFjZSApOwotICAgICAgICBpbmZvLT5pbnRlcm5hbENsb2NrID0gRlNUX1JEQiAoIGNh cmQsIHBvcnRDb25maWdbaV0uaW50ZXJuYWxDbG9jayApOwotICAgICAgICBpbmZvLT5saW5lU3Bl ZWQgICAgID0gRlNUX1JETCAoIGNhcmQsIHBvcnRDb25maWdbaV0ubGluZVNwZWVkICk7Ci0gICAg ICAgIGluZm8tPnYyNElwU3RzICAgICAgPSBGU1RfUkRMICggY2FyZCwgdjI0SXBTdHNbaV0gKTsK LSAgICAgICAgaW5mby0+djI0T3BTdHMgICAgICA9IEZTVF9SREwgKCBjYXJkLCB2MjRPcFN0c1tp XSApOwotICAgICAgICBpbmZvLT5jbG9ja1N0YXR1cyAgID0gRlNUX1JEVyAoIGNhcmQsIGNsb2Nr U3RhdHVzW2ldICk7Ci0gICAgICAgIGluZm8tPmNhYmxlU3RhdHVzICAgPSBGU1RfUkRXICggY2Fy ZCwgY2FibGVTdGF0dXMgKTsKLSAgICAgICAgaW5mby0+Y2FyZE1vZGUgICAgICA9IEZTVF9SRFcg KCBjYXJkLCBjYXJkTW9kZSApOwotICAgICAgICBpbmZvLT5zbWNGaXJtd2FyZVZlcnNpb24gID0g RlNUX1JETCAoIGNhcmQsIHNtY0Zpcm13YXJlVmVyc2lvbiApOworCWluZm8tPmxpbmVJbnRlcmZh Y2UgPSBGU1RfUkRXKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZUludGVyZmFjZSk7CisJaW5mby0+ aW50ZXJuYWxDbG9jayA9IEZTVF9SREIoY2FyZCwgcG9ydENvbmZpZ1tpXS5pbnRlcm5hbENsb2Nr KTsKKwlpbmZvLT5saW5lU3BlZWQgPSBGU1RfUkRMKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZVNw ZWVkKTsKKwlpbmZvLT5pbnZlcnRDbG9jayA9IEZTVF9SREIoY2FyZCwgcG9ydENvbmZpZ1tpXS5p bnZlcnRDbG9jayk7CisJaW5mby0+djI0SXBTdHMgPSBGU1RfUkRMKGNhcmQsIHYyNElwU3RzW2ld KTsKKwlpbmZvLT52MjRPcFN0cyA9IEZTVF9SREwoY2FyZCwgdjI0T3BTdHNbaV0pOworCWluZm8t PmNsb2NrU3RhdHVzID0gRlNUX1JEVyhjYXJkLCBjbG9ja1N0YXR1c1tpXSk7CisJaW5mby0+Y2Fi bGVTdGF0dXMgPSBGU1RfUkRXKGNhcmQsIGNhYmxlU3RhdHVzKTsKKwlpbmZvLT5jYXJkTW9kZSA9 IEZTVF9SRFcoY2FyZCwgY2FyZE1vZGUpOworCWluZm8tPnNtY0Zpcm13YXJlVmVyc2lvbiA9IEZT VF9SREwoY2FyZCwgc21jRmlybXdhcmVWZXJzaW9uKTsKKworCS8qCisJICogVGhlIFQyVSBjYW4g cmVwb3J0IGNhYmxlIHByZXNlbmNlIGZvciBib3RoIEEgb3IgQgorCSAqIGluIGJpdHMgMCBhbmQg MSBvZiBjYWJsZVN0YXR1cy4gIFNlZSB3aGljaCBwb3J0IHdlIGFyZSBhbmQgCisJICogZG8gdGhl IG1hcHBpbmcuCisJICovCisJaWYgKGNhcmQtPmZhbWlseSA9PSBGU1RfRkFNSUxZX1RYVSkgewor CQlpZiAocG9ydC0+aW5kZXggPT0gMCkgeworCQkJLyoKKwkJCSAqIFBvcnQgQQorCQkJICovCisJ CQlpbmZvLT5jYWJsZVN0YXR1cyA9IGluZm8tPmNhYmxlU3RhdHVzICYgMTsKKwkJfSBlbHNlIHsK KwkJCS8qCisJCQkgKiBQb3J0IEIKKwkJCSAqLworCQkJaW5mby0+Y2FibGVTdGF0dXMgPSBpbmZv LT5jYWJsZVN0YXR1cyA+PiAxOworCQkJaW5mby0+Y2FibGVTdGF0dXMgPSBpbmZvLT5jYWJsZVN0 YXR1cyAmIDE7CisJCX0KKwl9CisJLyoKKwkgKiBTb21lIGFkZGl0aW9uYWwgYml0cyBpZiB3ZSBh cmUgVEUxCisJICovCisJaWYgKGNhcmQtPnR5cGUgPT0gRlNUX1RZUEVfVEUxKSB7CisJCWluZm8t PmxpbmVTcGVlZCA9IEZTVF9SREwoY2FyZCwgc3VDb25maWcuZGF0YVJhdGUpOworCQlpbmZvLT5j bG9ja1NvdXJjZSA9IEZTVF9SREIoY2FyZCwgc3VDb25maWcuY2xvY2tpbmcpOworCQlpbmZvLT5m cmFtaW5nID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5mcmFtaW5nKTsKKwkJaW5mby0+c3RydWN0 dXJlID0gRlNUX1JEQihjYXJkLCBzdUNvbmZpZy5zdHJ1Y3R1cmUpOworCQlpbmZvLT5pbnRlcmZh Y2UgPSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLmludGVyZmFjZSk7CisJCWluZm8tPmNvZGluZyA9 IEZTVF9SREIoY2FyZCwgc3VDb25maWcuY29kaW5nKTsKKwkJaW5mby0+bGluZUJ1aWxkT3V0ID0g RlNUX1JEQihjYXJkLCBzdUNvbmZpZy5saW5lQnVpbGRPdXQpOworCQlpbmZvLT5lcXVhbGl6ZXIg PSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLmVxdWFsaXplcik7CisJCWluZm8tPmxvb3BNb2RlID0g RlNUX1JEQihjYXJkLCBzdUNvbmZpZy5sb29wTW9kZSk7CisJCWluZm8tPnJhbmdlID0gRlNUX1JE QihjYXJkLCBzdUNvbmZpZy5yYW5nZSk7CisJCWluZm8tPnR4QnVmZmVyTW9kZSA9IEZTVF9SREIo Y2FyZCwgc3VDb25maWcudHhCdWZmZXJNb2RlKTsKKwkJaW5mby0+cnhCdWZmZXJNb2RlID0gRlNU X1JEQihjYXJkLCBzdUNvbmZpZy5yeEJ1ZmZlck1vZGUpOworCQlpbmZvLT5zdGFydGluZ1Nsb3Qg PSBGU1RfUkRCKGNhcmQsIHN1Q29uZmlnLnN0YXJ0aW5nU2xvdCk7CisJCWluZm8tPmxvc1RocmVz aG9sZCA9IEZTVF9SREIoY2FyZCwgc3VDb25maWcubG9zVGhyZXNob2xkKTsKKwkJaWYgKEZTVF9S REIoY2FyZCwgc3VDb25maWcuZW5hYmxlSWRsZUNvZGUpKQorCQkJaW5mby0+aWRsZUNvZGUgPSBG U1RfUkRCKGNhcmQsIHN1Q29uZmlnLmlkbGVDb2RlKTsKKwkJZWxzZQorCQkJaW5mby0+aWRsZUNv ZGUgPSAwOworCQlpbmZvLT5yZWNlaXZlQnVmZmVyRGVsYXkgPQorCQkgICAgRlNUX1JETChjYXJk LCBzdVN0YXR1cy5yZWNlaXZlQnVmZmVyRGVsYXkpOworCQlpbmZvLT5mcmFtaW5nRXJyb3JDb3Vu dCA9CisJCSAgICBGU1RfUkRMKGNhcmQsIHN1U3RhdHVzLmZyYW1pbmdFcnJvckNvdW50KTsKKwkJ aW5mby0+Y29kZVZpb2xhdGlvbkNvdW50ID0KKwkJICAgIEZTVF9SREwoY2FyZCwgc3VTdGF0dXMu Y29kZVZpb2xhdGlvbkNvdW50KTsKKwkJaW5mby0+Y3JjRXJyb3JDb3VudCA9IEZTVF9SREwoY2Fy ZCwgc3VTdGF0dXMuY3JjRXJyb3JDb3VudCk7CisJCWluZm8tPmxpbmVBdHRlbnVhdGlvbiA9IEZT VF9SREwoY2FyZCwgc3VTdGF0dXMubGluZUF0dGVudWF0aW9uKTsKKwkJaW5mby0+bG9zc09mU2ln bmFsID0gRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5sb3NzT2ZTaWduYWwpOworCQlpbmZvLT5yZWNl aXZlUmVtb3RlQWxhcm0gPQorCQkgICAgRlNUX1JEQihjYXJkLCBzdVN0YXR1cy5yZWNlaXZlUmVt b3RlQWxhcm0pOworCQlpbmZvLT5hbGFybUluZGljYXRpb25TaWduYWwgPQorCQkgICAgRlNUX1JE QihjYXJkLCBzdVN0YXR1cy5hbGFybUluZGljYXRpb25TaWduYWwpOworCX0KIH0KIAotCiBzdGF0 aWMgaW50Ci1mc3Rfc2V0X2lmYWNlICggc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVj dCBmc3RfcG9ydF9pbmZvICpwb3J0LAotICAgICAgICAgICAgICAgIHN0cnVjdCBpZnJlcSAqaWZy ICkKK2ZzdF9zZXRfaWZhY2Uoc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3Rf cG9ydF9pbmZvICpwb3J0LAorCSAgICAgIHN0cnVjdCBpZnJlcSAqaWZyKQogewotICAgICAgICBz eW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5jOwotICAgICAgICBpbnQgaTsKKwlzeW5jX3NlcmlhbF9z ZXR0aW5ncyBzeW5jOworCWludCBpOworCisJaWYgKGlmci0+aWZyX3NldHRpbmdzLnNpemUgIT0g c2l6ZW9mIChzeW5jKSkgeworCQlyZXR1cm4gLUVOT01FTTsKKwl9CisKKwlpZiAoY29weV9mcm9t X3VzZXIKKwkgICAgKCZzeW5jLCBpZnItPmlmcl9zZXR0aW5ncy5pZnNfaWZzdS5zeW5jLCBzaXpl b2YgKHN5bmMpKSkgeworCQlyZXR1cm4gLUVGQVVMVDsKKwl9CisKKwlpZiAoc3luYy5sb29wYmFj aykKKwkJcmV0dXJuIC1FSU5WQUw7CisKKwlpID0gcG9ydC0+aW5kZXg7CisKKwlzd2l0Y2ggKGlm ci0+aWZyX3NldHRpbmdzLnR5cGUpIHsKKwljYXNlIElGX0lGQUNFX1YzNToKKwkJRlNUX1dSVyhj YXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZhY2UsIFYzNSk7CisJCXBvcnQtPmh3aWYgPSBW MzU7CisJCWJyZWFrOworCisJY2FzZSBJRl9JRkFDRV9WMjQ6CisJCUZTVF9XUlcoY2FyZCwgcG9y dENvbmZpZ1tpXS5saW5lSW50ZXJmYWNlLCBWMjQpOworCQlwb3J0LT5od2lmID0gVjI0OworCQli cmVhazsKKworCWNhc2UgSUZfSUZBQ0VfWDIxOgorCQlGU1RfV1JXKGNhcmQsIHBvcnRDb25maWdb aV0ubGluZUludGVyZmFjZSwgWDIxKTsKKwkJcG9ydC0+aHdpZiA9IFgyMTsKKwkJYnJlYWs7CisK KwljYXNlIElGX0lGQUNFX1gyMUQ6CisJCUZTVF9XUlcoY2FyZCwgcG9ydENvbmZpZ1tpXS5saW5l SW50ZXJmYWNlLCBYMjFEKTsKKwkJcG9ydC0+aHdpZiA9IFgyMUQ7CisJCWJyZWFrOworCisJY2Fz ZSBJRl9JRkFDRV9UMToKKwkJRlNUX1dSVyhjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZh Y2UsIFQxKTsKKwkJcG9ydC0+aHdpZiA9IFQxOworCQlicmVhazsKKworCWNhc2UgSUZfSUZBQ0Vf RTE6CisJCUZTVF9XUlcoY2FyZCwgcG9ydENvbmZpZ1tpXS5saW5lSW50ZXJmYWNlLCBFMSk7CisJ CXBvcnQtPmh3aWYgPSBFMTsKKwkJYnJlYWs7CisKKwljYXNlIElGX0lGQUNFX1NZTkNfU0VSSUFM OgorCQlicmVhazsKKworCWRlZmF1bHQ6CisJCXJldHVybiAtRUlOVkFMOworCX0KIAotICAgICAg ICBpZiAoY29weV9mcm9tX3VzZXIgKCZzeW5jLCBpZnItPmlmcl9zZXR0aW5ncy5pZnNfaWZzdS5z eW5jLAotCQkJICAgIHNpemVvZiAoc3luYykpKQotICAgICAgICAgICAgICAgIHJldHVybiAtRUZB VUxUOwotCi0gICAgICAgIGlmICggc3luYy5sb29wYmFjayApCi0gICAgICAgICAgICAgICAgcmV0 dXJuIC1FSU5WQUw7Ci0KLSAgICAgICAgaSA9IHBvcnQtPmluZGV4OwotCi0gICAgICAgIHN3aXRj aCAoaWZyLT5pZnJfc2V0dGluZ3MudHlwZSkKLSAgICAgICAgewotICAgICAgICBjYXNlIElGX0lG QUNFX1YzNToKLSAgICAgICAgICAgICAgICBGU1RfV1JXICggY2FyZCwgcG9ydENvbmZpZ1tpXS5s aW5lSW50ZXJmYWNlLCBWMzUgKTsKLSAgICAgICAgICAgICAgICBwb3J0LT5od2lmID0gVjM1Owot ICAgICAgICAgICAgICAgIGJyZWFrOwotCi0gICAgICAgIGNhc2UgSUZfSUZBQ0VfVjI0OgotICAg ICAgICAgICAgICAgIEZTVF9XUlcgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVJbnRlcmZhY2Us IFYyNCApOwotICAgICAgICAgICAgICAgIHBvcnQtPmh3aWYgPSBWMjQ7Ci0gICAgICAgICAgICAg ICAgYnJlYWs7Ci0KLSAgICAgICAgY2FzZSBJRl9JRkFDRV9YMjE6Ci0gICAgICAgICAgICAgICAg RlNUX1dSVyAoIGNhcmQsIHBvcnRDb25maWdbaV0ubGluZUludGVyZmFjZSwgWDIxICk7Ci0gICAg ICAgICAgICAgICAgcG9ydC0+aHdpZiA9IFgyMTsKLSAgICAgICAgICAgICAgICBicmVhazsKLQot ICAgICAgICBjYXNlIElGX0lGQUNFX1NZTkNfU0VSSUFMOgotICAgICAgICAgICAgICAgIGJyZWFr OwotCi0gICAgICAgIGRlZmF1bHQ6Ci0gICAgICAgICAgICAgICAgcmV0dXJuIC1FSU5WQUw7Ci0g ICAgICAgIH0KLQotICAgICAgICBzd2l0Y2ggKCBzeW5jLmNsb2NrX3R5cGUgKQotICAgICAgICB7 Ci0gICAgICAgIGNhc2UgQ0xPQ0tfRVhUOgotICAgICAgICAgICAgICAgIEZTVF9XUkIgKCBjYXJk LCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xvY2ssIEVYVENMSyApOwotICAgICAgICAgICAgICAg IGJyZWFrOwotCi0gICAgICAgIGNhc2UgQ0xPQ0tfSU5UOgotICAgICAgICAgICAgICAgIEZTVF9X UkIgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xvY2ssIElOVENMSyApOwotICAgICAg ICAgICAgICAgIGJyZWFrOwotCi0gICAgICAgIGRlZmF1bHQ6Ci0gICAgICAgICAgICAgICAgcmV0 dXJuIC1FSU5WQUw7Ci0gICAgICAgIH0KLSAgICAgICAgRlNUX1dSTCAoIGNhcmQsIHBvcnRDb25m aWdbaV0ubGluZVNwZWVkLCBzeW5jLmNsb2NrX3JhdGUgKTsKLSAgICAgICAgcmV0dXJuIDA7CisJ c3dpdGNoIChzeW5jLmNsb2NrX3R5cGUpIHsKKwljYXNlIENMT0NLX0VYVDoKKwkJRlNUX1dSQihj YXJkLCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xvY2ssIEVYVENMSyk7CisJCWJyZWFrOworCisJ Y2FzZSBDTE9DS19JTlQ6CisJCUZTVF9XUkIoY2FyZCwgcG9ydENvbmZpZ1tpXS5pbnRlcm5hbENs b2NrLCBJTlRDTEspOworCQlicmVhazsKKworCWRlZmF1bHQ6CisJCXJldHVybiAtRUlOVkFMOwor CX0KKwlGU1RfV1JMKGNhcmQsIHBvcnRDb25maWdbaV0ubGluZVNwZWVkLCBzeW5jLmNsb2NrX3Jh dGUpOworCXJldHVybiAwOwogfQogCiBzdGF0aWMgaW50Ci1mc3RfZ2V0X2lmYWNlICggc3RydWN0 IGZzdF9jYXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAotICAgICAg ICAgICAgICAgIHN0cnVjdCBpZnJlcSAqaWZyICkKK2ZzdF9nZXRfaWZhY2Uoc3RydWN0IGZzdF9j YXJkX2luZm8gKmNhcmQsIHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0LAorCSAgICAgIHN0cnVj dCBpZnJlcSAqaWZyKQogewotICAgICAgICBzeW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5jOwotICAg ICAgICBpbnQgaTsKKwlzeW5jX3NlcmlhbF9zZXR0aW5ncyBzeW5jOworCWludCBpOwogCi0gICAg ICAgIC8qIEZpcnN0IGNoZWNrIHdoYXQgbGluZSB0eXBlIGlzIHNldCwgd2UnbGwgZGVmYXVsdCB0 byByZXBvcnRpbmcgWC4yMQotICAgICAgICAgKiBpZiBub3RoaW5nIGlzIHNldCBhcyBJRl9JRkFD RV9TWU5DX1NFUklBTCBpbXBsaWVzIGl0IGNhbid0IGJlCi0gICAgICAgICAqIGNoYW5nZWQKLSAg ICAgICAgICovCi0gICAgICAgIHN3aXRjaCAoIHBvcnQtPmh3aWYgKQotICAgICAgICB7Ci0gICAg ICAgIGNhc2UgVjM1OgotICAgICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJ Rl9JRkFDRV9WMzU7Ci0gICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgVjI0Ogot ICAgICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9WMjQ7Ci0g ICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIGNhc2UgWDIxOgotICAgICAgICBkZWZhdWx0 OgotICAgICAgICAgICAgICAgIGlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9YMjE7 Ci0gICAgICAgICAgICAgICAgYnJlYWs7Ci0gICAgICAgIH0KLQotCWlmIChpZnItPmlmcl9zZXR0 aW5ncy5zaXplIDwgc2l6ZW9mKHN5bmMpKSB7Ci0JCWlmci0+aWZyX3NldHRpbmdzLnNpemUgPSBz aXplb2Yoc3luYyk7IC8qIGRhdGEgc2l6ZSB3YW50ZWQgKi8KLQkJcmV0dXJuIC1FTk9CVUZTOwot CX0KLQotICAgICAgICBpID0gcG9ydC0+aW5kZXg7Ci0gICAgICAgIHN5bmMuY2xvY2tfcmF0ZSA9 IEZTVF9SREwgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmxpbmVTcGVlZCApOwotICAgICAgICAvKiBM dWNreSBjYXJkIGFuZCBsaW51eCB1c2Ugc2FtZSBlbmNvZGluZyBoZXJlICovCi0gICAgICAgIHN5 bmMuY2xvY2tfdHlwZSA9IEZTVF9SREIgKCBjYXJkLCBwb3J0Q29uZmlnW2ldLmludGVybmFsQ2xv Y2sgKTsKLSAgICAgICAgc3luYy5sb29wYmFjayA9IDA7Ci0KLSAgICAgICAgaWYgKGNvcHlfdG9f dXNlciAoaWZyLT5pZnJfc2V0dGluZ3MuaWZzX2lmc3Uuc3luYywgJnN5bmMsCi0JCQkgIHNpemVv ZihzeW5jKSkpCi0gICAgICAgICAgICAgICAgcmV0dXJuIC1FRkFVTFQ7CisJLyogRmlyc3QgY2hl Y2sgd2hhdCBsaW5lIHR5cGUgaXMgc2V0LCB3ZSdsbCBkZWZhdWx0IHRvIHJlcG9ydGluZyBYLjIx CisJICogaWYgbm90aGluZyBpcyBzZXQgYXMgSUZfSUZBQ0VfU1lOQ19TRVJJQUwgaW1wbGllcyBp dCBjYW4ndCBiZQorCSAqIGNoYW5nZWQKKwkgKi8KKwlzd2l0Y2ggKHBvcnQtPmh3aWYpIHsKKwlj YXNlIEUxOgorCQlpZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZfSUZBQ0VfRTE7CisJCWJyZWFr OworCWNhc2UgVDE6CisJCWlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9UMTsKKwkJ YnJlYWs7CisJY2FzZSBWMzU6CisJCWlmci0+aWZyX3NldHRpbmdzLnR5cGUgPSBJRl9JRkFDRV9W MzU7CisJCWJyZWFrOworCWNhc2UgVjI0OgorCQlpZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZf SUZBQ0VfVjI0OworCQlicmVhazsKKwljYXNlIFgyMUQ6CisJCWlmci0+aWZyX3NldHRpbmdzLnR5 cGUgPSBJRl9JRkFDRV9YMjFEOworCQlicmVhazsKKwljYXNlIFgyMToKKwlkZWZhdWx0OgorCQlp ZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZfSUZBQ0VfWDIxOworCQlicmVhazsKKwl9CisJaWYg KGlmci0+aWZyX3NldHRpbmdzLnNpemUgPT0gMCkgeworCQlyZXR1cm4gMDsJLyogb25seSB0eXBl IHJlcXVlc3RlZCAqLworCX0KKwlpZiAoaWZyLT5pZnJfc2V0dGluZ3Muc2l6ZSA8IHNpemVvZiAo c3luYykpIHsKKwkJcmV0dXJuIC1FTk9NRU07CisJfQogCi0gICAgICAgIHJldHVybiAwOwotfQor CWkgPSBwb3J0LT5pbmRleDsKKwlzeW5jLmNsb2NrX3JhdGUgPSBGU1RfUkRMKGNhcmQsIHBvcnRD b25maWdbaV0ubGluZVNwZWVkKTsKKwkvKiBMdWNreSBjYXJkIGFuZCBsaW51eCB1c2Ugc2FtZSBl bmNvZGluZyBoZXJlICovCisJc3luYy5jbG9ja190eXBlID0gRlNUX1JEQihjYXJkLCBwb3J0Q29u ZmlnW2ldLmludGVybmFsQ2xvY2spID09CisJICAgIElOVENMSyA/IENMT0NLX0lOVCA6IENMT0NL X0VYVDsKKwlzeW5jLmxvb3BiYWNrID0gMDsKKworCWlmIChjb3B5X3RvX3VzZXIoaWZyLT5pZnJf c2V0dGluZ3MuaWZzX2lmc3Uuc3luYywgJnN5bmMsIHNpemVvZiAoc3luYykpKSB7CisJCXJldHVy biAtRUZBVUxUOworCX0KIAorCWlmci0+aWZyX3NldHRpbmdzLnNpemUgPSBzaXplb2YgKHN5bmMp OworCXJldHVybiAwOworfQogCiBzdGF0aWMgaW50Ci1mc3RfaW9jdGwgKCBzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2LCBzdHJ1Y3QgaWZyZXEgKmlmciwgaW50IGNtZCApCitmc3RfaW9jdGwoc3RydWN0 IG5ldF9kZXZpY2UgKmRldiwgc3RydWN0IGlmcmVxICppZnIsIGludCBjbWQpCiB7Ci0gICAgICAg IHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOwotICAgICAgICBzdHJ1Y3QgZnN0X3BvcnRfaW5m byAqcG9ydDsKLSAgICAgICAgc3RydWN0IGZzdGlvY193cml0ZSB3cnRoZHI7Ci0gICAgICAgIHN0 cnVjdCBmc3Rpb2NfaW5mbyBpbmZvOwotICAgICAgICB1bnNpZ25lZCBsb25nIGZsYWdzOwotCi0g ICAgICAgIGRiZyAoIERCR19JT0NUTCwiaW9jdGw6ICV4LCAlcFxuIiwgY21kLCBpZnItPmlmcl9k YXRhICk7Ci0KLSAgICAgICAgcG9ydCA9IGRldl90b19wb3J0ICggZGV2ICk7Ci0gICAgICAgIGNh cmQgPSBwb3J0LT5jYXJkOwotCi0gICAgICAgIGlmICggIWNhcGFibGUgKCBDQVBfTkVUX0FETUlO ICkpCi0gICAgICAgICAgICAgICAgcmV0dXJuIC1FUEVSTTsKLQotICAgICAgICBzd2l0Y2ggKCBj bWQgKQotICAgICAgICB7Ci0gICAgICAgIGNhc2UgRlNUQ1BVUkVTRVQ6Ci0gICAgICAgICAgICAg ICAgZnN0X2NwdXJlc2V0ICggY2FyZCApOwotICAgICAgICAgICAgICAgIGNhcmQtPnN0YXRlID0g RlNUX1JFU0VUOwotICAgICAgICAgICAgICAgIHJldHVybiAwOwotCi0gICAgICAgIGNhc2UgRlNU Q1BVUkVMRUFTRToKLSAgICAgICAgICAgICAgICBmc3RfY3B1cmVsZWFzZSAoIGNhcmQgKTsKLSAg ICAgICAgICAgICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9TVEFSVElORzsKLSAgICAgICAgICAgICAg ICByZXR1cm4gMDsKLQotICAgICAgICBjYXNlIEZTVFdSSVRFOiAgICAgICAgICAgICAgICAgIC8q IENvZGUgd3JpdGUgKGRvd25sb2FkKSAqLwotCi0gICAgICAgICAgICAgICAgLyogRmlyc3QgY29w eSBpbiB0aGUgaGVhZGVyIHdpdGggdGhlIGxlbmd0aCBhbmQgb2Zmc2V0IG9mIGRhdGEKLSAgICAg ICAgICAgICAgICAgKiB0byB3cml0ZQotICAgICAgICAgICAgICAgICAqLwotICAgICAgICAgICAg ICAgIGlmICggaWZyLT5pZnJfZGF0YSA9PSBOVUxMICkKLSAgICAgICAgICAgICAgICB7Ci0gICAg ICAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVJTlZBTDsKLSAgICAgICAgICAgICAgICB9Ci0g ICAgICAgICAgICAgICAgaWYgKCBjb3B5X2Zyb21fdXNlciAoICZ3cnRoZHIsIGlmci0+aWZyX2Rh dGEsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc2l6ZW9mICggc3Ry dWN0IGZzdGlvY193cml0ZSApKSkKLSAgICAgICAgICAgICAgICB7Ci0gICAgICAgICAgICAgICAg ICAgICAgICByZXR1cm4gLUVGQVVMVDsKLSAgICAgICAgICAgICAgICB9Ci0KLSAgICAgICAgICAg ICAgICAvKiBTYW5pdHkgY2hlY2sgdGhlIHBhcmFtZXRlcnMuIFdlIGRvbid0IHN1cHBvcnQgcGFy dGlhbCB3cml0ZXMKLSAgICAgICAgICAgICAgICAgKiB3aGVuIGdvaW5nIG92ZXIgdGhlIHRvcAot ICAgICAgICAgICAgICAgICAqLwotICAgICAgICAgICAgICAgIGlmICggd3J0aGRyLnNpemUgPiBG U1RfTUVNU0laRSB8fCB3cnRoZHIub2Zmc2V0ID4gRlNUX01FTVNJWkUKLQkJCQl8fCB3cnRoZHIu c2l6ZSArIHdydGhkci5vZmZzZXQgPiBGU1RfTUVNU0laRSApCi0gICAgICAgICAgICAgICAgewot ICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIC1FTlhJTzsKLSAgICAgICAgICAgICAgICB9 Ci0KLSAgICAgICAgICAgICAgICAvKiBOb3cgY29weSB0aGUgZGF0YSB0byB0aGUgY2FyZC4KLSAg ICAgICAgICAgICAgICAgKiBUaGlzIHdpbGwgcHJvYmFibHkgYnJlYWsgb24gc29tZSBhcmNoaXRl Y3R1cmVzLgotICAgICAgICAgICAgICAgICAqIEknbGwgZml4IGl0IHdoZW4gSSBoYXZlIHNvbWV0 aGluZyB0byB0ZXN0IG9uLgotICAgICAgICAgICAgICAgICAqLwotICAgICAgICAgICAgICAgIGlm ICggY29weV9mcm9tX3VzZXIgKCBjYXJkLT5tZW0gKyB3cnRoZHIub2Zmc2V0LAotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBpZnItPmlmcl9kYXRhICsgc2l6ZW9mICggc3RydWN0IGZz dGlvY193cml0ZSApLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cnRoZHIuc2l6 ZSApKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAt RUZBVUxUOwotICAgICAgICAgICAgICAgIH0KLQotICAgICAgICAgICAgICAgIC8qIFdyaXRlcyB0 byB0aGUgbWVtb3J5IG9mIGEgY2FyZCBpbiB0aGUgcmVzZXQgc3RhdGUgY29uc3RpdHV0ZQotICAg ICAgICAgICAgICAgICAqIGEgZG93bmxvYWQKLSAgICAgICAgICAgICAgICAgKi8KLSAgICAgICAg ICAgICAgICBpZiAoIGNhcmQtPnN0YXRlID09IEZTVF9SRVNFVCApCi0gICAgICAgICAgICAgICAg ewotICAgICAgICAgICAgICAgICAgICAgICAgY2FyZC0+c3RhdGUgPSBGU1RfRE9XTkxPQUQ7Ci0g ICAgICAgICAgICAgICAgfQotICAgICAgICAgICAgICAgIHJldHVybiAwOwotCi0gICAgICAgIGNh c2UgRlNUR0VUQ09ORjoKLQotICAgICAgICAgICAgICAgIC8qIElmIGNhcmQgaGFzIGp1c3QgYmVl biBzdGFydGVkIGNoZWNrIHRoZSBzaGFyZWQgbWVtb3J5IGNvbmZpZwotICAgICAgICAgICAgICAg ICAqIHZlcnNpb24gYW5kIG1hcmtlcgotICAgICAgICAgICAgICAgICAqLwotICAgICAgICAgICAg ICAgIGlmICggY2FyZC0+c3RhdGUgPT0gRlNUX1NUQVJUSU5HICkKLSAgICAgICAgICAgICAgICB7 Ci0gICAgICAgICAgICAgICAgICAgICAgICBjaGVja19zdGFydGVkX29rICggY2FyZCApOwotCi0g ICAgICAgICAgICAgICAgICAgICAgICAvKiBJZiBldmVyeXRoaW5nIGNoZWNrZWQgb3V0IGVuYWJs ZSBjYXJkIGludGVycnVwdHMgKi8KLSAgICAgICAgICAgICAgICAgICAgICAgIGlmICggY2FyZC0+ c3RhdGUgPT0gRlNUX1JVTk5JTkcgKQotICAgICAgICAgICAgICAgICAgICAgICAgewotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzcGluX2xvY2tfaXJxc2F2ZSAoICZjYXJkLT5jYXJk X2xvY2ssIGZsYWdzICk7Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZzdF9jbGVh cl9pbnRyICggY2FyZCApOwotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGU1RfV1JC ICggY2FyZCwgaW50ZXJydXB0SGFuZHNoYWtlLCAweEVFICk7Ci0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHNwaW5fdW5sb2NrX2lycXJlc3RvcmUgKCAmY2FyZC0+Y2FyZF9sb2NrLAot ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGZsYWdzICk7Ci0gICAgICAgICAgICAgICAgICAgICAgICB9Ci0gICAgICAgICAgICAg ICAgfQotCi0gICAgICAgICAgICAgICAgaWYgKCBpZnItPmlmcl9kYXRhID09IE5VTEwgKQotICAg ICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOwot ICAgICAgICAgICAgICAgIH0KLQotICAgICAgICAgICAgICAgIGdhdGhlcl9jb25mX2luZm8gKCBj YXJkLCBwb3J0LCAmaW5mbyApOwotCi0gICAgICAgICAgICAgICAgaWYgKCBjb3B5X3RvX3VzZXIg KCBpZnItPmlmcl9kYXRhLCAmaW5mbywgc2l6ZW9mICggaW5mbyApKSkKLSAgICAgICAgICAgICAg ICB7Ci0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gLUVGQVVMVDsKLSAgICAgICAgICAg ICAgICB9Ci0gICAgICAgICAgICAgICAgcmV0dXJuIDA7Ci0KLSAgICAgICAgY2FzZSBGU1RTRVRD T05GOgotCi0gICAgICAgICAgICAgICAgLyogTW9zdCBvZiB0aGUgc2V0dGluZyBoYXZlIGJlZW4g bW92ZWQgdG8gdGhlIGdlbmVyaWMgaW9jdGxzCi0gICAgICAgICAgICAgICAgICogdGhpcyBqdXN0 IGNvdmVycyBkZWJ1ZyBhbmQgYm9hcmQgaWRlbnQgbW9kZSBub3cKLSAgICAgICAgICAgICAgICAg Ki8KLSAgICAgICAgICAgICAgICBpZiAoIGNvcHlfZnJvbV91c2VyICggJmluZm8sICBpZnItPmlm cl9kYXRhLCBzaXplb2YgKCBpbmZvICkpKQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAg ICAgICAgICAgICAgIHJldHVybiAtRUZBVUxUOwotICAgICAgICAgICAgICAgIH0KLQotICAgICAg ICAgICAgICAgIHJldHVybiBzZXRfY29uZl9mcm9tX2luZm8gKCBjYXJkLCBwb3J0LCAmaW5mbyAp OwotCi0gICAgICAgIGNhc2UgU0lPQ1dBTkRFVjoKLSAgICAgICAgICAgICAgICBzd2l0Y2ggKGlm ci0+aWZyX3NldHRpbmdzLnR5cGUpCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAg IGNhc2UgSUZfR0VUX0lGQUNFOgotICAgICAgICAgICAgICAgICAgICAgICAgcmV0dXJuIGZzdF9n ZXRfaWZhY2UgKCBjYXJkLCBwb3J0LCBpZnIgKTsKLQotICAgICAgICAgICAgICAgIGNhc2UgSUZf SUZBQ0VfU1lOQ19TRVJJQUw6Ci0gICAgICAgICAgICAgICAgY2FzZSBJRl9JRkFDRV9WMzU6Ci0g ICAgICAgICAgICAgICAgY2FzZSBJRl9JRkFDRV9WMjQ6Ci0gICAgICAgICAgICAgICAgY2FzZSBJ Rl9JRkFDRV9YMjE6Ci0gICAgICAgICAgICAgICAgICAgICAgICByZXR1cm4gZnN0X3NldF9pZmFj ZSAoIGNhcmQsIHBvcnQsIGlmciApOwotCi0gICAgICAgICAgICAgICAgZGVmYXVsdDoKLSAgICAg ICAgICAgICAgICAgICAgICAgIHJldHVybiBoZGxjX2lvY3RsICggZGV2LCBpZnIsIGNtZCApOwot ICAgICAgICAgICAgICAgIH0KLQotICAgICAgICBkZWZhdWx0OgotICAgICAgICAgICAgICAgIC8q IE5vdCBvbmUgb2Ygb3Vycy4gUGFzcyB0aHJvdWdoIHRvIEhETEMgcGFja2FnZSAqLwotICAgICAg ICAgICAgICAgIHJldHVybiBoZGxjX2lvY3RsICggZGV2LCBpZnIsIGNtZCApOwotICAgICAgICB9 Ci19Ci0KLQotc3RhdGljIHZvaWQKLWZzdF9vcGVucG9ydCAoIHN0cnVjdCBmc3RfcG9ydF9pbmZv ICpwb3J0ICkKLXsKLSAgICAgICAgaW50IHNpZ25hbHM7Ci0KLSAgICAgICAgLyogT25seSBpbml0 IHRoaW5ncyBpZiBjYXJkIGlzIGFjdHVhbGx5IHJ1bm5pbmcuIFRoaXMgYWxsb3dzIG9wZW4gdG8K LSAgICAgICAgICogc3VjY2VlZCBmb3IgZG93bmxvYWRzIGV0Yy4KLSAgICAgICAgICovCi0gICAg ICAgIGlmICggcG9ydC0+Y2FyZC0+c3RhdGUgPT0gRlNUX1JVTk5JTkcgKQotICAgICAgICB7Ci0g ICAgICAgICAgICAgICAgaWYgKCBwb3J0LT5ydW4gKQotICAgICAgICAgICAgICAgIHsKLSAgICAg ICAgICAgICAgICAgICAgICAgIGRiZyAoIERCR19PUEVOLCJvcGVuOiBmb3VuZCBwb3J0IGFscmVh ZHkgcnVubmluZ1xuIik7Ci0KLSAgICAgICAgICAgICAgICAgICAgICAgIGZzdF9pc3N1ZV9jbWQg KCBwb3J0LCBTVE9QUE9SVCApOwotICAgICAgICAgICAgICAgICAgICAgICAgcG9ydC0+cnVuID0g MDsKLSAgICAgICAgICAgICAgICB9Ci0KLSAgICAgICAgICAgICAgICBmc3RfcnhfY29uZmlnICgg cG9ydCApOwotICAgICAgICAgICAgICAgIGZzdF90eF9jb25maWcgKCBwb3J0ICk7Ci0gICAgICAg ICAgICAgICAgZnN0X29wX3JhaXNlICggcG9ydCwgT1BTVFNfUlRTIHwgT1BTVFNfRFRSICk7Ci0K LSAgICAgICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9ydCwgU1RBUlRQT1JUICk7Ci0gICAg ICAgICAgICAgICAgcG9ydC0+cnVuID0gMTsKLQotICAgICAgICAgICAgICAgIHNpZ25hbHMgPSBG U1RfUkRMICggcG9ydC0+Y2FyZCwgdjI0RGVib3VuY2VkU3RzW3BvcnQtPmluZGV4XSk7Ci0gICAg ICAgICAgICAgICAgaWYgKCBzaWduYWxzICYgKCggcG9ydC0+aHdpZiA9PSBYMjEgKSA/IElQU1RT X0lORElDQVRFCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA6IElQU1RTX0RDRCApKQotICAgICAgICAgICAgICAgICAgICAgICAgbmV0aWZfY2Fy cmllcl9vbiAoIHBvcnRfdG9fZGV2ICggcG9ydCApKTsKLSAgICAgICAgICAgICAgICBlbHNlCi0g ICAgICAgICAgICAgICAgICAgICAgICBuZXRpZl9jYXJyaWVyX29mZiAoIHBvcnRfdG9fZGV2ICgg cG9ydCApKTsKLSAgICAgICAgfQotfQotCi1zdGF0aWMgdm9pZAotZnN0X2Nsb3NlcG9ydCAoIHN0 cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0ICkKLXsKLSAgICAgICAgaWYgKCBwb3J0LT5jYXJkLT5z dGF0ZSA9PSBGU1RfUlVOTklORyApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBpZiAoIHBv cnQtPnJ1biApCi0gICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICAgICAgcG9y dC0+cnVuID0gMDsKLSAgICAgICAgICAgICAgICAgICAgICAgIGZzdF9vcF9sb3dlciAoIHBvcnQs IE9QU1RTX1JUUyB8IE9QU1RTX0RUUiApOwotCi0gICAgICAgICAgICAgICAgICAgICAgICBmc3Rf aXNzdWVfY21kICggcG9ydCwgU1RPUFBPUlQgKTsKLSAgICAgICAgICAgICAgICB9Ci0gICAgICAg ICAgICAgICAgZWxzZQotICAgICAgICAgICAgICAgIHsKLSAgICAgICAgICAgICAgICAgICAgICAg IGRiZyAoIERCR19PUEVOLCJjbG9zZTogcG9ydCBub3QgcnVubmluZ1xuIik7Ci0gICAgICAgICAg ICAgICAgfQotICAgICAgICB9CisJc3RydWN0IGZzdF9jYXJkX2luZm8gKmNhcmQ7CisJc3RydWN0 IGZzdF9wb3J0X2luZm8gKnBvcnQ7CisJc3RydWN0IGZzdGlvY193cml0ZSB3cnRoZHI7CisJc3Ry dWN0IGZzdGlvY19pbmZvIGluZm87CisJdW5zaWduZWQgbG9uZyBmbGFnczsKKworCWRiZyhEQkdf SU9DVEwsICJpb2N0bDogJXgsICVwXG4iLCBjbWQsIGlmci0+aWZyX2RhdGEpOworCisJcG9ydCA9 IGRldl90b19wb3J0KGRldik7CisJY2FyZCA9IHBvcnQtPmNhcmQ7CisKKwlpZiAoIWNhcGFibGUo Q0FQX05FVF9BRE1JTikpCisJCXJldHVybiAtRVBFUk07CisKKwlzd2l0Y2ggKGNtZCkgeworCWNh c2UgRlNUQ1BVUkVTRVQ6CisJCWZzdF9jcHVyZXNldChjYXJkKTsKKwkJY2FyZC0+c3RhdGUgPSBG U1RfUkVTRVQ7CisJCXJldHVybiAwOworCisJY2FzZSBGU1RDUFVSRUxFQVNFOgorCQlmc3RfY3B1 cmVsZWFzZShjYXJkKTsKKwkJY2FyZC0+c3RhdGUgPSBGU1RfU1RBUlRJTkc7CisJCXJldHVybiAw OworCisJY2FzZSBGU1RXUklURToJCS8qIENvZGUgd3JpdGUgKGRvd25sb2FkKSAqLworCisJCS8q IEZpcnN0IGNvcHkgaW4gdGhlIGhlYWRlciB3aXRoIHRoZSBsZW5ndGggYW5kIG9mZnNldCBvZiBk YXRhCisJCSAqIHRvIHdyaXRlCisJCSAqLworCQlpZiAoaWZyLT5pZnJfZGF0YSA9PSBOVUxMKSB7 CisJCQlyZXR1cm4gLUVJTlZBTDsKKwkJfQorCQlpZiAoY29weV9mcm9tX3VzZXIoJndydGhkciwg aWZyLT5pZnJfZGF0YSwKKwkJCQkgICBzaXplb2YgKHN0cnVjdCBmc3Rpb2Nfd3JpdGUpKSkgewor CQkJcmV0dXJuIC1FRkFVTFQ7CisJCX0KKworCQkvKiBTYW5pdHkgY2hlY2sgdGhlIHBhcmFtZXRl cnMuIFdlIGRvbid0IHN1cHBvcnQgcGFydGlhbCB3cml0ZXMKKwkJICogd2hlbiBnb2luZyBvdmVy IHRoZSB0b3AKKwkJICovCisJCWlmICh3cnRoZHIuc2l6ZSA+IEZTVF9NRU1TSVpFIHx8IHdydGhk ci5vZmZzZXQgPiBGU1RfTUVNU0laRQorCQkgICAgfHwgd3J0aGRyLnNpemUgKyB3cnRoZHIub2Zm c2V0ID4gRlNUX01FTVNJWkUpIHsKKwkJCXJldHVybiAtRU5YSU87CisJCX0KKworCQkvKiBOb3cg Y29weSB0aGUgZGF0YSB0byB0aGUgY2FyZC4KKwkJICogVGhpcyB3aWxsIHByb2JhYmx5IGJyZWFr IG9uIHNvbWUgYXJjaGl0ZWN0dXJlcy4KKwkJICogSSdsbCBmaXggaXQgd2hlbiBJIGhhdmUgc29t ZXRoaW5nIHRvIHRlc3Qgb24uCisJCSAqLworCQlpZiAoY29weV9mcm9tX3VzZXIoY2FyZC0+bWVt ICsgd3J0aGRyLm9mZnNldCwKKwkJCQkgICBpZnItPmlmcl9kYXRhICsgc2l6ZW9mIChzdHJ1Y3Qg ZnN0aW9jX3dyaXRlKSwKKwkJCQkgICB3cnRoZHIuc2l6ZSkpIHsKKwkJCXJldHVybiAtRUZBVUxU OworCQl9CisKKwkJLyogV3JpdGVzIHRvIHRoZSBtZW1vcnkgb2YgYSBjYXJkIGluIHRoZSByZXNl dCBzdGF0ZSBjb25zdGl0dXRlCisJCSAqIGEgZG93bmxvYWQKKwkJICovCisJCWlmIChjYXJkLT5z dGF0ZSA9PSBGU1RfUkVTRVQpIHsKKwkJCWNhcmQtPnN0YXRlID0gRlNUX0RPV05MT0FEOworCQl9 CisJCXJldHVybiAwOworCisJY2FzZSBGU1RHRVRDT05GOgorCisJCS8qIElmIGNhcmQgaGFzIGp1 c3QgYmVlbiBzdGFydGVkIGNoZWNrIHRoZSBzaGFyZWQgbWVtb3J5IGNvbmZpZworCQkgKiB2ZXJz aW9uIGFuZCBtYXJrZXIKKwkJICovCisJCWlmIChjYXJkLT5zdGF0ZSA9PSBGU1RfU1RBUlRJTkcp IHsKKwkJCWNoZWNrX3N0YXJ0ZWRfb2soY2FyZCk7CisKKwkJCS8qIElmIGV2ZXJ5dGhpbmcgY2hl Y2tlZCBvdXQgZW5hYmxlIGNhcmQgaW50ZXJydXB0cyAqLworCQkJaWYgKGNhcmQtPnN0YXRlID09 IEZTVF9SVU5OSU5HKSB7CisJCQkJc3Bpbl9sb2NrX2lycXNhdmUoJmNhcmQtPmNhcmRfbG9jaywg ZmxhZ3MpOworCQkJCWZzdF9lbmFibGVfaW50cihjYXJkKTsKKwkJCQlGU1RfV1JCKGNhcmQsIGlu dGVycnVwdEhhbmRzaGFrZSwgMHhFRSk7CisJCQkJc3Bpbl91bmxvY2tfaXJxcmVzdG9yZSgmY2Fy ZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJCQl9CisJCX0KKworCQlpZiAoaWZyLT5pZnJfZGF0YSA9 PSBOVUxMKSB7CisJCQlyZXR1cm4gLUVJTlZBTDsKKwkJfQorCisJCWdhdGhlcl9jb25mX2luZm8o Y2FyZCwgcG9ydCwgJmluZm8pOworCisJCWlmIChjb3B5X3RvX3VzZXIoaWZyLT5pZnJfZGF0YSwg JmluZm8sIHNpemVvZiAoaW5mbykpKSB7CisJCQlyZXR1cm4gLUVGQVVMVDsKKwkJfQorCQlyZXR1 cm4gMDsKKworCWNhc2UgRlNUU0VUQ09ORjoKKworCQkvKgorCQkgKiBNb3N0IG9mIHRoZSBzZXR0 aW5ncyBoYXZlIGJlZW4gbW92ZWQgdG8gdGhlIGdlbmVyaWMgaW9jdGxzCisJCSAqIHRoaXMganVz dCBjb3ZlcnMgZGVidWcgYW5kIGJvYXJkIGlkZW50IG5vdworCQkgKi8KKworCQlpZiAoY2FyZC0+ c3RhdGUgIT0gRlNUX1JVTk5JTkcpIHsKKwkJCXByaW50a19lcnIKKwkJCSAgICAoIkF0dGVtcHQg dG8gY29uZmlndXJlIGNhcmQgJWQgaW4gbm9uLXJ1bm5pbmcgc3RhdGUgKCVkKVxuIiwKKwkJCSAg ICAgY2FyZC0+Y2FyZF9ubywgY2FyZC0+c3RhdGUpOworCQkJcmV0dXJuIC1FSU87CisJCX0KKwkJ aWYgKGNvcHlfZnJvbV91c2VyKCZpbmZvLCBpZnItPmlmcl9kYXRhLCBzaXplb2YgKGluZm8pKSkg eworCQkJcmV0dXJuIC1FRkFVTFQ7CisJCX0KKworCQlyZXR1cm4gc2V0X2NvbmZfZnJvbV9pbmZv KGNhcmQsIHBvcnQsICZpbmZvKTsKKworCWNhc2UgU0lPQ1dBTkRFVjoKKwkJc3dpdGNoIChpZnIt Pmlmcl9zZXR0aW5ncy50eXBlKSB7CisJCWNhc2UgSUZfR0VUX0lGQUNFOgorCQkJcmV0dXJuIGZz dF9nZXRfaWZhY2UoY2FyZCwgcG9ydCwgaWZyKTsKKworCQljYXNlIElGX0lGQUNFX1NZTkNfU0VS SUFMOgorCQljYXNlIElGX0lGQUNFX1YzNToKKwkJY2FzZSBJRl9JRkFDRV9WMjQ6CisJCWNhc2Ug SUZfSUZBQ0VfWDIxOgorCQljYXNlIElGX0lGQUNFX1gyMUQ6CisJCWNhc2UgSUZfSUZBQ0VfVDE6 CisJCWNhc2UgSUZfSUZBQ0VfRTE6CisJCQlyZXR1cm4gZnN0X3NldF9pZmFjZShjYXJkLCBwb3J0 LCBpZnIpOworCisJCWNhc2UgSUZfUFJPVE9fUkFXOgorCQkJcG9ydC0+bW9kZSA9IEZTVF9SQVc7 CisJCQlyZXR1cm4gMDsKKworCQljYXNlIElGX0dFVF9QUk9UTzoKKwkJCWlmIChwb3J0LT5tb2Rl ID09IEZTVF9SQVcpIHsKKwkJCQlpZnItPmlmcl9zZXR0aW5ncy50eXBlID0gSUZfUFJPVE9fUkFX OworCQkJCXJldHVybiAwOworCQkJfQorCQkJcmV0dXJuIGhkbGNfaW9jdGwoZGV2LCBpZnIsIGNt ZCk7CisKKwkJZGVmYXVsdDoKKwkJCXBvcnQtPm1vZGUgPSBGU1RfR0VOX0hETEM7CisJCQlkYmco REJHX0lPQ1RMLCAiUGFzc2luZyB0aGlzIHR5cGUgdG8gaGRsYyAleFxuIiwKKwkJCSAgICBpZnIt Pmlmcl9zZXR0aW5ncy50eXBlKTsKKwkJCXJldHVybiBoZGxjX2lvY3RsKGRldiwgaWZyLCBjbWQp OworCQl9CisKKwlkZWZhdWx0OgorCQkvKiBOb3Qgb25lIG9mIG91cnMuIFBhc3MgdGhyb3VnaCB0 byBIRExDIHBhY2thZ2UgKi8KKwkJcmV0dXJuIGhkbGNfaW9jdGwoZGV2LCBpZnIsIGNtZCk7CisJ fQogfQogCi0KLXN0YXRpYyBpbnQKLWZzdF9vcGVuICggc3RydWN0IG5ldF9kZXZpY2UgKmRldiAp CitzdGF0aWMgdm9pZAorZnN0X29wZW5wb3J0KHN0cnVjdCBmc3RfcG9ydF9pbmZvICpwb3J0KQog ewotICAgICAgICBpbnQgZXJyOworCWludCBzaWduYWxzOworCWludCB0eHFfbGVuZ3RoOwogCi0g ICAgICAgIGVyciA9IGhkbGNfb3BlbiAoIGRldl90b19oZGxjICggZGV2ICkpOwotICAgICAgICBp ZiAoIGVyciApCi0gICAgICAgICAgICAgICAgcmV0dXJuIGVycjsKKwkvKiBPbmx5IGluaXQgdGhp bmdzIGlmIGNhcmQgaXMgYWN0dWFsbHkgcnVubmluZy4gVGhpcyBhbGxvd3Mgb3BlbiB0bworCSAq IHN1Y2NlZWQgZm9yIGRvd25sb2FkcyBldGMuCisJICovCisJaWYgKHBvcnQtPmNhcmQtPnN0YXRl ID09IEZTVF9SVU5OSU5HKSB7CisJCWlmIChwb3J0LT5ydW4pIHsKKwkJCWRiZyhEQkdfT1BFTiwg Im9wZW46IGZvdW5kIHBvcnQgYWxyZWFkeSBydW5uaW5nXG4iKTsKKworCQkJZnN0X2lzc3VlX2Nt ZChwb3J0LCBTVE9QUE9SVCk7CisJCQlwb3J0LT5ydW4gPSAwOworCQl9CisKKwkJZnN0X3J4X2Nv bmZpZyhwb3J0KTsKKwkJZnN0X3R4X2NvbmZpZyhwb3J0KTsKKwkJZnN0X29wX3JhaXNlKHBvcnQs IE9QU1RTX1JUUyB8IE9QU1RTX0RUUik7CisKKwkJZnN0X2lzc3VlX2NtZChwb3J0LCBTVEFSVFBP UlQpOworCQlwb3J0LT5ydW4gPSAxOworCisJCXNpZ25hbHMgPSBGU1RfUkRMKHBvcnQtPmNhcmQs IHYyNERlYm91bmNlZFN0c1twb3J0LT5pbmRleF0pOworCQlpZiAoc2lnbmFscyAmICgoKHBvcnQt Pmh3aWYgPT0gWDIxKSB8fCAocG9ydC0+aHdpZiA9PSBYMjFEKSkKKwkJCSAgICAgICA/IElQU1RT X0lORElDQVRFIDogSVBTVFNfRENEKSkKKwkJCW5ldGlmX2NhcnJpZXJfb24ocG9ydF90b19kZXYo cG9ydCkpOworCQllbHNlCisJCQluZXRpZl9jYXJyaWVyX29mZihwb3J0X3RvX2Rldihwb3J0KSk7 CisKKwkJdHhxX2xlbmd0aCA9IHBvcnQtPnR4cWUgLSBwb3J0LT50eHFzOworCQlwb3J0LT50eHFl ID0gMDsKKwkJcG9ydC0+dHhxcyA9IDA7CisJfQogCi0gICAgICAgIE1PRF9JTkNfVVNFX0NPVU5U OworfQogCi0gICAgICAgIGZzdF9vcGVucG9ydCAoIGRldl90b19wb3J0ICggZGV2ICkpOwotICAg ICAgICBuZXRpZl93YWtlX3F1ZXVlICggZGV2ICk7Ci0gICAgICAgIHJldHVybiAwOworc3RhdGlj IHZvaWQKK2ZzdF9jbG9zZXBvcnQoc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQpCit7CisJaWYg KHBvcnQtPmNhcmQtPnN0YXRlID09IEZTVF9SVU5OSU5HKSB7CisJCWlmIChwb3J0LT5ydW4pIHsK KwkJCXBvcnQtPnJ1biA9IDA7CisJCQlmc3Rfb3BfbG93ZXIocG9ydCwgT1BTVFNfUlRTIHwgT1BT VFNfRFRSKTsKKworCQkJZnN0X2lzc3VlX2NtZChwb3J0LCBTVE9QUE9SVCk7CisJCX0gZWxzZSB7 CisJCQlkYmcoREJHX09QRU4sICJjbG9zZTogcG9ydCBub3QgcnVubmluZ1xuIik7CisJCX0KKwl9 CiB9CiAKIHN0YXRpYyBpbnQKLWZzdF9jbG9zZSAoIHN0cnVjdCBuZXRfZGV2aWNlICpkZXYgKQor ZnN0X29wZW4oc3RydWN0IG5ldF9kZXZpY2UgKmRldikKIHsKLSAgICAgICAgbmV0aWZfc3RvcF9x dWV1ZSAoIGRldiApOwotICAgICAgICBmc3RfY2xvc2Vwb3J0ICggZGV2X3RvX3BvcnQgKCBkZXYg KSk7Ci0gICAgICAgIGhkbGNfY2xvc2UgKCBkZXZfdG9faGRsYyAgKCBkZXYgKSk7Ci0gICAgICAg IE1PRF9ERUNfVVNFX0NPVU5UOwotICAgICAgICByZXR1cm4gMDsKKwlpbnQgZXJyOworCXN0cnVj dCBmc3RfcG9ydF9pbmZvICpwb3J0OworCisJcG9ydCA9IGRldl90b19wb3J0KGRldik7CisJTU9E X0lOQ19VU0VfQ09VTlQ7CisJaWYgKHBvcnQtPm1vZGUgIT0gRlNUX1JBVykgeworCQllcnIgPSBo ZGxjX29wZW4oZGV2X3RvX2hkbGMoZGV2KSk7CisJCWlmIChlcnIpCisJCQlyZXR1cm4gZXJyOwor CX0KKworCWZzdF9vcGVucG9ydChwb3J0KTsKKwluZXRpZl93YWtlX3F1ZXVlKGRldik7CisJcmV0 dXJuIDA7CiB9CiAKIHN0YXRpYyBpbnQKLWZzdF9hdHRhY2ggKCBoZGxjX2RldmljZSAqaGRsYywg dW5zaWduZWQgc2hvcnQgZW5jb2RpbmcsIHVuc2lnbmVkIHNob3J0IHBhcml0eSApCitmc3RfY2xv c2Uoc3RydWN0IG5ldF9kZXZpY2UgKmRldikKIHsKLSAgICAgICAgLyogU2V0dGluZyBjdXJyZW50 bHkgZml4ZWQgaW4gRmFyU3luYyBjYXJkIHNvIHdlIGNoZWNrIGFuZCBmb3JnZXQgKi8KLSAgICAg ICAgaWYgKCBlbmNvZGluZyAhPSBFTkNPRElOR19OUlogfHwgcGFyaXR5ICE9IFBBUklUWV9DUkMx Nl9QUjFfQ0NJVFQgKQotICAgICAgICAgICAgICAgIHJldHVybiAtRUlOVkFMOwotICAgICAgICBy ZXR1cm4gMDsKKwlzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydDsKKwlzdHJ1Y3QgZnN0X2NhcmRf aW5mbyAqY2FyZDsKKwl1bnNpZ25lZCBjaGFyIHR4X2RtYV9kb25lOworCXVuc2lnbmVkIGNoYXIg cnhfZG1hX2RvbmU7CisKKwlwb3J0ID0gZGV2X3RvX3BvcnQoZGV2KTsKKwljYXJkID0gcG9ydC0+ Y2FyZDsKKworCXR4X2RtYV9kb25lID0gaW5iKGNhcmQtPnBjaV9jb25mICsgRE1BQ1NSMSk7CisJ cnhfZG1hX2RvbmUgPSBpbmIoY2FyZC0+cGNpX2NvbmYgKyBETUFDU1IwKTsKKwlkYmcoREJHX09Q RU4sCisJICAgICJQb3J0IENsb3NlOiB0eF9kbWFfaW5fcHJvZ3Jlc3MgPSAlZCAoJXgpIHJ4X2Rt YV9pbl9wcm9ncmVzcyA9ICVkICgleClcbiIsCisJICAgIGNhcmQtPmRtYXR4X2luX3Byb2dyZXNz LCB0eF9kbWFfZG9uZSwgY2FyZC0+ZG1hcnhfaW5fcHJvZ3Jlc3MsCisJICAgIHJ4X2RtYV9kb25l KTsKKworCW5ldGlmX3N0b3BfcXVldWUoZGV2KTsKKwlmc3RfY2xvc2Vwb3J0KGRldl90b19wb3J0 KGRldikpOworCWlmIChwb3J0LT5tb2RlICE9IEZTVF9SQVcpIHsKKwkJaGRsY19jbG9zZShkZXZf dG9faGRsYyhkZXYpKTsKKwl9CisJTU9EX0RFQ19VU0VfQ09VTlQ7CisJcmV0dXJuIDA7CiB9CiAK K3N0YXRpYyBpbnQKK2ZzdF9hdHRhY2goaGRsY19kZXZpY2UgKiBoZGxjLCB1bnNpZ25lZCBzaG9y dCBlbmNvZGluZywgdW5zaWduZWQgc2hvcnQgcGFyaXR5KQoreworCS8qCisJICogU2V0dGluZyBj dXJyZW50bHkgZml4ZWQgaW4gRmFyU3luYyBjYXJkIHNvIHdlIGNoZWNrIGFuZCBmb3JnZXQKKwkg Ki8KKwlpZiAoZW5jb2RpbmcgIT0gRU5DT0RJTkdfTlJaIHx8IHBhcml0eSAhPSBQQVJJVFlfQ1JD MTZfUFIxX0NDSVRUKQorCQlyZXR1cm4gLUVJTlZBTDsKKwlyZXR1cm4gMDsKK30KIAogc3RhdGlj IHZvaWQKLWZzdF90eF90aW1lb3V0ICggc3RydWN0IG5ldF9kZXZpY2UgKmRldiApCitmc3RfdHhf dGltZW91dChzdHJ1Y3QgbmV0X2RldmljZSAqZGV2KQogewotICAgICAgICBzdHJ1Y3QgZnN0X3Bv cnRfaW5mbyAqcG9ydDsKKwlzdHJ1Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydDsKKwlzdHJ1Y3QgZnN0 X2NhcmRfaW5mbyAqY2FyZDsKIAotICAgICAgICBkYmcgKCBEQkdfSU5UUiB8IERCR19UWCwidHhf dGltZW91dFxuIik7CisJcG9ydCA9IGRldl90b19wb3J0KGRldik7CisJY2FyZCA9IHBvcnQtPmNh cmQ7CiAKLSAgICAgICAgcG9ydCA9IGRldl90b19wb3J0ICggZGV2ICk7Ci0KLSAgICAgICAgcG9y dC0+aGRsYy5zdGF0cy50eF9lcnJvcnMrKzsKLSAgICAgICAgcG9ydC0+aGRsYy5zdGF0cy50eF9h Ym9ydGVkX2Vycm9ycysrOwotCi0gICAgICAgIGlmICggcG9ydC0+dHhjbnQgPiAwICkKLSAgICAg ICAgICAgICAgICBmc3RfaXNzdWVfY21kICggcG9ydCwgQUJPUlRUWCApOwotCi0gICAgICAgIGRl di0+dHJhbnNfc3RhcnQgPSBqaWZmaWVzOwotICAgICAgICBuZXRpZl93YWtlX3F1ZXVlICggZGV2 ICk7CisJcG9ydC0+aGRsYy5zdGF0cy50eF9lcnJvcnMrKzsKKwlwb3J0LT5oZGxjLnN0YXRzLnR4 X2Fib3J0ZWRfZXJyb3JzKys7CisJZGJnKERCR19BU1MsICJUeCB0aW1lb3V0IGNhcmQgJWQgcG9y dCAlZFxuIiwKKwkgICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgpOworCWZzdF9pc3N1ZV9j bWQocG9ydCwgQUJPUlRUWCk7CisKKwlkZXYtPnRyYW5zX3N0YXJ0ID0gamlmZmllczsKKwluZXRp Zl93YWtlX3F1ZXVlKGRldik7CisJcG9ydC0+c3RhcnQgPSAwOwogfQogCi0KIHN0YXRpYyBpbnQK LWZzdF9zdGFydF94bWl0ICggc3RydWN0IHNrX2J1ZmYgKnNrYiwgc3RydWN0IG5ldF9kZXZpY2Ug KmRldiApCitmc3Rfc3RhcnRfeG1pdChzdHJ1Y3Qgc2tfYnVmZiAqc2tiLCBzdHJ1Y3QgbmV0X2Rl dmljZSAqZGV2KQogewotICAgICAgICBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZDsKLSAgICAg ICAgc3RydWN0IGZzdF9wb3J0X2luZm8gKnBvcnQ7Ci0gICAgICAgIHVuc2lnbmVkIGNoYXIgZG1h Yml0czsKLSAgICAgICAgdW5zaWduZWQgbG9uZyBmbGFnczsKLSAgICAgICAgaW50IHBpOwotICAg ICAgICBpbnQgdHhwOwotCi0gICAgICAgIHBvcnQgPSBkZXZfdG9fcG9ydCAoIGRldiApOwotICAg ICAgICBjYXJkID0gcG9ydC0+Y2FyZDsKLQotICAgICAgICAvKiBEcm9wIHBhY2tldCB3aXRoIGVy cm9yIGlmIHdlIGRvbid0IGhhdmUgY2FycmllciAqLwotICAgICAgICBpZiAoICEgbmV0aWZfY2Fy cmllcl9vayAoIGRldiApKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgZGV2X2tmcmVlX3Nr YiAoIHNrYiApOwotICAgICAgICAgICAgICAgIHBvcnQtPmhkbGMuc3RhdHMudHhfZXJyb3JzKys7 Ci0gICAgICAgICAgICAgICAgcG9ydC0+aGRsYy5zdGF0cy50eF9jYXJyaWVyX2Vycm9ycysrOwot ICAgICAgICAgICAgICAgIHJldHVybiAwOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogRHJvcCBp dCBpZiBpdCdzIHRvbyBiaWchIE1UVSBmYWlsdXJlID8gKi8KLSAgICAgICAgaWYgKCBza2ItPmxl biA+IExFTl9UWF9CVUZGRVIgKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAgZGJnICggREJH X1RYLCJQYWNrZXQgdG9vIGxhcmdlICVkIHZzICVkXG4iLCBza2ItPmxlbiwKLSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIExFTl9UWF9CVUZGRVIgKTsKLSAg ICAgICAgICAgICAgICBkZXZfa2ZyZWVfc2tiICggc2tiICk7Ci0gICAgICAgICAgICAgICAgcG9y dC0+aGRsYy5zdGF0cy50eF9lcnJvcnMrKzsKLSAgICAgICAgICAgICAgICByZXR1cm4gMDsKLSAg ICAgICAgfQotCi0gICAgICAgIC8qIENoZWNrIHdlIGhhdmUgYSBidWZmZXIgKi8KLSAgICAgICAg cGkgPSBwb3J0LT5pbmRleDsKLSAgICAgICAgc3Bpbl9sb2NrX2lycXNhdmUgKCAmY2FyZC0+Y2Fy ZF9sb2NrLCBmbGFncyApOwotICAgICAgICB0eHAgPSBwb3J0LT50eHBvczsKLSAgICAgICAgZG1h Yml0cyA9IEZTVF9SREIgKCBjYXJkLCB0eERlc2NyUmluZ1twaV1bdHhwXS5iaXRzICk7Ci0gICAg ICAgIGlmICggZG1hYml0cyAmIERNQV9PV04gKQotICAgICAgICB7Ci0gICAgICAgICAgICAgICAg c3Bpbl91bmxvY2tfaXJxcmVzdG9yZSAoICZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzICk7Ci0gICAg ICAgICAgICAgICAgZGJnICggREJHX1RYLCJPdXQgb2YgVHggYnVmZmVyc1xuIik7Ci0gICAgICAg ICAgICAgICAgZGV2X2tmcmVlX3NrYiAoIHNrYiApOwotICAgICAgICAgICAgICAgIHBvcnQtPmhk bGMuc3RhdHMudHhfZXJyb3JzKys7Ci0gICAgICAgICAgICAgICAgcmV0dXJuIDA7Ci0gICAgICAg IH0KLSAgICAgICAgaWYgKCArK3BvcnQtPnR4cG9zID49IE5VTV9UWF9CVUZGRVIgKQotICAgICAg ICAgICAgICAgIHBvcnQtPnR4cG9zID0gMDsKLQotICAgICAgICBpZiAoICsrcG9ydC0+dHhjbnQg Pj0gTlVNX1RYX0JVRkZFUiApCi0gICAgICAgICAgICAgICAgbmV0aWZfc3RvcF9xdWV1ZSAoIGRl diApOwotCi0gICAgICAgIC8qIFJlbGVhc2UgdGhlIGNhcmQgbG9jayBiZWZvcmUgd2UgY29weSB0 aGUgZGF0YSBhcyB3ZSBub3cgaGF2ZQotICAgICAgICAgKiBleGNsdXNpdmUgYWNjZXNzIHRvIHRo ZSBidWZmZXIuCi0gICAgICAgICAqLwotICAgICAgICBzcGluX3VubG9ja19pcnFyZXN0b3JlICgg JmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MgKTsKLQotICAgICAgICAvKiBFbnF1ZXVlIHRoZSBwYWNr ZXQgKi8KLSAgICAgICAgbWVtY3B5X3RvaW8gKCBjYXJkLT5tZW0gKyBCVUZfT0ZGU0VUICggdHhC dWZmZXJbcGldW3R4cF1bMF0pLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgc2tiLT5kYXRhLCBza2ItPmxlbiApOwotICAgICAgICBGU1RfV1JXICggY2Fy ZCwgdHhEZXNjclJpbmdbcGldW3R4cF0uYmNudCwgY252X2JjbnQgKCBza2ItPmxlbiApKTsKLSAg ICAgICAgRlNUX1dSQiAoIGNhcmQsIHR4RGVzY3JSaW5nW3BpXVt0eHBdLmJpdHMsIERNQV9PV04g fCBUWF9TVFAgfCBUWF9FTlAgKTsKKwlzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZDsKKwlzdHJ1 Y3QgZnN0X3BvcnRfaW5mbyAqcG9ydDsKKwl1bnNpZ25lZCBsb25nIGZsYWdzOworCWludCB0eHFf bGVuZ3RoOworCisJcG9ydCA9IGRldl90b19wb3J0KGRldik7CisJY2FyZCA9IHBvcnQtPmNhcmQ7 CisJZGJnKERCR19UWCwgImZzdF9zdGFydF94bWl0OiBsZW5ndGggPSAlZFxuIiwgc2tiLT5sZW4p OworCisJLyogRHJvcCBwYWNrZXQgd2l0aCBlcnJvciBpZiB3ZSBkb24ndCBoYXZlIGNhcnJpZXIg Ki8KKwlpZiAoIW5ldGlmX2NhcnJpZXJfb2soZGV2KSkgeworCQlkZXZfa2ZyZWVfc2tiKHNrYik7 CisJCXBvcnQtPmhkbGMuc3RhdHMudHhfZXJyb3JzKys7CisJCXBvcnQtPmhkbGMuc3RhdHMudHhf Y2Fycmllcl9lcnJvcnMrKzsKKwkJZGJnKERCR19BU1MsCisJCSAgICAiVHJpZWQgdG8gdHJhbnNt aXQgYnV0IG5vIGNhcnJpZXIgb24gY2FyZCAlZCBwb3J0ICVkXG4iLAorCQkgICAgY2FyZC0+Y2Fy ZF9ubywgcG9ydC0+aW5kZXgpOworCQlyZXR1cm4gMDsKKwl9CiAKLSAgICAgICAgcG9ydC0+aGRs Yy5zdGF0cy50eF9wYWNrZXRzKys7Ci0gICAgICAgIHBvcnQtPmhkbGMuc3RhdHMudHhfYnl0ZXMg Kz0gc2tiLT5sZW47CisJLyogRHJvcCBpdCBpZiBpdCdzIHRvbyBiaWchIE1UVSBmYWlsdXJlID8g Ki8KKwlpZiAoc2tiLT5sZW4gPiBMRU5fVFhfQlVGRkVSKSB7CisJCWRiZyhEQkdfQVNTLCAiUGFj a2V0IHRvbyBsYXJnZSAlZCB2cyAlZFxuIiwgc2tiLT5sZW4sCisJCSAgICBMRU5fVFhfQlVGRkVS KTsKKwkJZGV2X2tmcmVlX3NrYihza2IpOworCQlwb3J0LT5oZGxjLnN0YXRzLnR4X2Vycm9ycysr OworCQlyZXR1cm4gMDsKKwl9CiAKLSAgICAgICAgZGV2X2tmcmVlX3NrYiAoIHNrYiApOworCS8q CisJICogV2UgYXJlIGFsd2F5cyBnb2luZyB0byBxdWV1ZSB0aGUgcGFja2V0CisJICogc28gdGhh dCB0aGUgYm90dG9tIGhhbGYgaXMgdGhlIG9ubHkgcGxhY2Ugd2UgdHggZnJvbQorCSAqIENoZWNr IHRoZXJlIGlzIHJvb20gaW4gdGhlIHBvcnQgdHhxCisJICovCisJc3Bpbl9sb2NrX2lycXNhdmUo JmNhcmQtPmNhcmRfbG9jaywgZmxhZ3MpOworCWlmICgodHhxX2xlbmd0aCA9IHBvcnQtPnR4cWUg LSBwb3J0LT50eHFzKSA8IDApIHsKKwkJLyoKKwkJICogVGhpcyBpcyB0aGUgY2FzZSB3aGVyZSB0 aGUgbmV4dCBmcmVlIGhhcyB3cmFwcGVkIGJ1dCB0aGUKKwkJICogbGFzdCB1c2VkIGhhc24ndAor CQkgKi8KKwkJdHhxX2xlbmd0aCA9IHR4cV9sZW5ndGggKyBGU1RfVFhRX0RFUFRIOworCX0KKwlz cGluX3VubG9ja19pcnFyZXN0b3JlKCZjYXJkLT5jYXJkX2xvY2ssIGZsYWdzKTsKKwlpZiAodHhx X2xlbmd0aCA+IGZzdF90eHFfaGlnaCkgeworCQkvKgorCQkgKiBXZSBoYXZlIGdvdCBlbm91Z2gg YnVmZmVycyBpbiB0aGUgcGlwZWxpbmUuICBBc2sgdGhlIG5ldHdvcmsKKwkJICogbGF5ZXIgdG8g c3RvcCBzZW5kaW5nIGZyYW1lcyBkb3duCisJCSAqLworCQluZXRpZl9zdG9wX3F1ZXVlKGRldik7 CisJCXBvcnQtPnN0YXJ0ID0gMTsJLyogSSdtIHVzaW5nIHRoaXMgdG8gc2lnbmFsIHN0b3Agc2Vu dCB1cCAqLworCX0KIAotICAgICAgICBkZXYtPnRyYW5zX3N0YXJ0ID0gamlmZmllczsKLSAgICAg ICAgcmV0dXJuIDA7Ci19CisJaWYgKHR4cV9sZW5ndGggPT0gRlNUX1RYUV9ERVBUSCAtIDEpIHsK KwkJLyoKKwkJICogVGhpcyBzaG91bGRuJ3QgaGF2ZSBoYXBwZW5lZCBidXQgc3VjaCBpcyBsaWZl CisJCSAqLworCQlkZXZfa2ZyZWVfc2tiKHNrYik7CisJCXBvcnQtPmhkbGMuc3RhdHMudHhfZXJy b3JzKys7CisJCWRiZyhEQkdfQVNTLCAiVHggcXVldWUgb3ZlcmZsb3cgY2FyZCAlZCBwb3J0ICVk XG4iLAorCQkgICAgY2FyZC0+Y2FyZF9ubywgcG9ydC0+aW5kZXgpOworCQlyZXR1cm4gMDsKKwl9 CiAKKwkvKgorCSAqIHF1ZXVlIHRoZSBidWZmZXIKKwkgKi8KKwlzcGluX2xvY2tfaXJxc2F2ZSgm Y2FyZC0+Y2FyZF9sb2NrLCBmbGFncyk7CisJcG9ydC0+dHhxW3BvcnQtPnR4cWVdID0gc2tiOwor CXBvcnQtPnR4cWUrKzsKKwlpZiAocG9ydC0+dHhxZSA9PSBGU1RfVFhRX0RFUFRIKQorCQlwb3J0 LT50eHFlID0gMDsKKwlzcGluX3VubG9ja19pcnFyZXN0b3JlKCZjYXJkLT5jYXJkX2xvY2ssIGZs YWdzKTsKKworCS8qIFNjZWhkdWxlIHRoZSBib3R0b20gaGFsZiB3aGljaCBub3cgZG9lcyB0cmFu c21pdCBwcm9jZXNzaW5nICovCisJZnN0X3Ffd29ya19pdGVtKCZmc3Rfd29ya190eHEsIGNhcmQt PmNhcmRfbm8pOworCXRhc2tsZXRfc2NoZWR1bGUoJmZzdF90eF90YXNrKTsKKworCXJldHVybiAw OworfQogCiAvKgogICogICAgICBDYXJkIHNldHVwIGhhdmluZyBjaGVja2VkIGhhcmR3YXJlIHJl c291cmNlcy4KQEAgLTE0NDEsMjU2ICsyMzgyLDMwMiBAQAogICogICAgICBkaXNhYmxlZC4KICAq Lwogc3RhdGljIGNoYXIgKnR5cGVfc3RyaW5nc1tdIF9fZGV2aW5pdGRhdGEgPSB7Ci0gICAgICAg ICJubyBoYXJkd2FyZSIsICAgICAgICAgICAgICAgICAgLyogU2hvdWxkIG5ldmVyIGJlIHNlZW4g Ki8KLSAgICAgICAgIkZhclN5bmMgVDJQIiwKLSAgICAgICAgIkZhclN5bmMgVDRQIgorCSJubyBo YXJkd2FyZSIsCQkvKiBTaG91bGQgbmV2ZXIgYmUgc2VlbiAqLworCSJGYXJTeW5jIFQyUCIsCisJ IkZhclN5bmMgVDRQIiwKKwkiRmFyU3luYyBUMVUiLAorCSJGYXJTeW5jIFQyVSIsCisJIkZhclN5 bmMgVDRVIiwKKwkiRmFyU3luYyBURTEiCiB9OwogCiBzdGF0aWMgdm9pZCBfX2RldmluaXQKLWZz dF9pbml0X2NhcmQgKCBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZCApCitmc3RfaW5pdF9jYXJk KHN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkKQogewotICAgICAgICBpbnQgaTsKLSAgICAgICAg aW50IGVycjsKLSAgICAgICAgc3RydWN0IG5ldF9kZXZpY2UgKmRldjsKLQotICAgICAgICAvKiBX ZSdyZSB3b3JraW5nIG9uIGEgbnVtYmVyIG9mIHBvcnRzIGJhc2VkIG9uIHRoZSBjYXJkIElELiBJ ZiB0aGUKLSAgICAgICAgICogZmlybXdhcmUgZGV0ZWN0cyBzb21ldGhpbmcgZGlmZmVyZW50IGxh dGVyIChzaG91bGQgbmV2ZXIgaGFwcGVuKQotICAgICAgICAgKiB3ZSdsbCBoYXZlIHRvIHJldmlz ZSBpdCBpbiBzb21lIHdheSB0aGVuLgotICAgICAgICAgKi8KLSAgICAgICAgZm9yICggaSA9IDAg OyBpIDwgY2FyZC0+bnBvcnRzIDsgaSsrICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIGNh cmQtPnBvcnRzW2ldLmNhcmQgICA9IGNhcmQ7Ci0gICAgICAgICAgICAgICAgY2FyZC0+cG9ydHNb aV0uaW5kZXggID0gaTsKLSAgICAgICAgICAgICAgICBjYXJkLT5wb3J0c1tpXS5ydW4gICAgPSAw OwotCi0gICAgICAgICAgICAgICAgZGV2ID0gaGRsY190b19kZXYgKCAmY2FyZC0+cG9ydHNbaV0u aGRsYyApOwotCi0gICAgICAgICAgICAgICAgLyogRmlsbCBpbiB0aGUgbmV0IGRldmljZSBpbmZv ICovCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8qIFNpbmNlIHRoaXMgaXMgYSBQ Q0kgc2V0dXAgdGhpcyBpcyBwdXJlbHkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICogaW5mb3JtYXRpb25hbC4gR2l2ZSB0aGVtIHRoZSBidWZmZXIgYWRkcmVzc2VzCi0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAqIGFuZCBiYXNpYyBjYXJkIEkvTy4KLSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICovCi0gICAgICAgICAgICAgICAgZGV2LT5tZW1fc3Rh cnQgICA9IGNhcmQtPnBoeXNfbWVtCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr IEJVRl9PRkZTRVQgKCB0eEJ1ZmZlcltpXVswXVswXSk7Ci0gICAgICAgICAgICAgICAgZGV2LT5t ZW1fZW5kICAgICA9IGNhcmQtPnBoeXNfbWVtCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArIEJVRl9PRkZTRVQgKCB0eEJ1ZmZlcltpXVtOVU1fVFhfQlVGRkVSXVswXSk7Ci0gICAg ICAgICAgICAgICAgZGV2LT5ybWVtX3N0YXJ0ICA9IGNhcmQtPnBoeXNfbWVtCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArIEJVRl9PRkZTRVQgKCByeEJ1ZmZlcltpXVswXVswXSk7 Ci0gICAgICAgICAgICAgICAgZGV2LT5ybWVtX2VuZCAgICA9IGNhcmQtPnBoeXNfbWVtCi0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArIEJVRl9PRkZTRVQgKCByeEJ1ZmZlcltpXVtO VU1fUlhfQlVGRkVSXVswXSk7Ci0gICAgICAgICAgICAgICAgZGV2LT5iYXNlX2FkZHIgICA9IGNh cmQtPnBjaV9jb25mOwotICAgICAgICAgICAgICAgIGRldi0+aXJxICAgICAgICAgPSBjYXJkLT5p cnE7Ci0KLSAgICAgICAgICAgICAgICBkZXYtPnR4X3F1ZXVlX2xlbiAgICAgICAgICA9IEZTVF9U WF9RVUVVRV9MRU47Ci0gICAgICAgICAgICAgICAgZGV2LT5vcGVuICAgICAgICAgICAgICAgICAg PSBmc3Rfb3BlbjsKLSAgICAgICAgICAgICAgICBkZXYtPnN0b3AgICAgICAgICAgICAgICAgICA9 IGZzdF9jbG9zZTsKLSAgICAgICAgICAgICAgICBkZXYtPmRvX2lvY3RsICAgICAgICAgICAgICA9 IGZzdF9pb2N0bDsKLSAgICAgICAgICAgICAgICBkZXYtPndhdGNoZG9nX3RpbWVvICAgICAgICA9 IEZTVF9UWF9USU1FT1VUOwotICAgICAgICAgICAgICAgIGRldi0+dHhfdGltZW91dCAgICAgICAg ICAgID0gZnN0X3R4X3RpbWVvdXQ7Ci0gICAgICAgICAgICAgICAgY2FyZC0+cG9ydHNbaV0uaGRs Yy5hdHRhY2ggPSBmc3RfYXR0YWNoOwotICAgICAgICAgICAgICAgIGNhcmQtPnBvcnRzW2ldLmhk bGMueG1pdCAgID0gZnN0X3N0YXJ0X3htaXQ7Ci0KLSAgICAgICAgICAgICAgICBpZiAoKCBlcnIg PSByZWdpc3Rlcl9oZGxjX2RldmljZSAoICZjYXJkLT5wb3J0c1tpXS5oZGxjICkpIDwgMCApCi0g ICAgICAgICAgICAgICAgewotICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIkNh bm5vdCByZWdpc3RlciBIRExDIGRldmljZSBmb3IgcG9ydCAlZCIKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICIgKGVycm5vICVkKVxuIiwgaSwgLWVyciApOwotICAgICAgICAg ICAgICAgICAgICAgICAgY2FyZC0+bnBvcnRzID0gaTsKLSAgICAgICAgICAgICAgICAgICAgICAg IGJyZWFrOwotICAgICAgICAgICAgICAgIH0KLSAgICAgICAgfQotCi0gICAgICAgIHNwaW5fbG9j a19pbml0ICggJmNhcmQtPmNhcmRfbG9jayApOwotCi0gICAgICAgIHByaW50ayAoIEtFUk5fSU5G TyAiJXMtJXM6ICVzIElSUSVkLCAlZCBwb3J0c1xuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg IGhkbGNfdG9fZGV2KCZjYXJkLT5wb3J0c1swXS5oZGxjKS0+bmFtZSwKLSAgICAgICAgICAgICAg ICAgICAgICAgIGhkbGNfdG9fZGV2KCZjYXJkLT5wb3J0c1tjYXJkLT5ucG9ydHMtMV0uaGRsYykt Pm5hbWUsCi0gICAgICAgICAgICAgICAgICAgICAgICB0eXBlX3N0cmluZ3NbY2FyZC0+dHlwZV0s IGNhcmQtPmlycSwgY2FyZC0+bnBvcnRzICk7Ci19CisJaW50IGk7CisJaW50IGVycjsKKwlzdHJ1 Y3QgbmV0X2RldmljZSAqZGV2OworCisJLyogV2UncmUgd29ya2luZyBvbiBhIG51bWJlciBvZiBw b3J0cyBiYXNlZCBvbiB0aGUgY2FyZCBJRC4gSWYgdGhlCisJICogZmlybXdhcmUgZGV0ZWN0cyBz b21ldGhpbmcgZGlmZmVyZW50IGxhdGVyIChzaG91bGQgbmV2ZXIgaGFwcGVuKQorCSAqIHdlJ2xs IGhhdmUgdG8gcmV2aXNlIGl0IGluIHNvbWUgd2F5IHRoZW4uCisJICovCisJZm9yIChpID0gMDsg aSA8IGNhcmQtPm5wb3J0czsgaSsrKSB7CisJCWNhcmQtPnBvcnRzW2ldLmNhcmQgPSBjYXJkOwor CQljYXJkLT5wb3J0c1tpXS5pbmRleCA9IGk7CisJCWNhcmQtPnBvcnRzW2ldLnJ1biA9IDA7CisJ CWNhcmQtPnBvcnRzW2ldLm1vZGUgPSBGU1RfR0VOX0hETEM7CisKKwkJZGV2ID0gaGRsY190b19k ZXYoJmNhcmQtPnBvcnRzW2ldLmhkbGMpOworCisJCS8qIEZpbGwgaW4gdGhlIG5ldCBkZXZpY2Ug aW5mbyAKKwkJICogU2luY2UgdGhpcyBpcyBhIFBDSSBzZXR1cCB0aGlzIGlzIHB1cmVseQorCQkg KiBpbmZvcm1hdGlvbmFsLiBHaXZlIHRoZW0gdGhlIGJ1ZmZlciBhZGRyZXNzZXMKKwkJICogYW5k IGJhc2ljIGNhcmQgSS9PLgorCQkgKi8KKwkJZGV2LT5tZW1fc3RhcnQgPSBjYXJkLT5waHlzX21l bSArIEJVRl9PRkZTRVQodHhCdWZmZXJbaV1bMF1bMF0pOworCQlkZXYtPm1lbV9lbmQgPSBjYXJk LT5waHlzX21lbQorCQkgICAgKyBCVUZfT0ZGU0VUKHR4QnVmZmVyW2ldW05VTV9UWF9CVUZGRVJd WzBdKTsKKwkJZGV2LT5iYXNlX2FkZHIgPSBjYXJkLT5wY2lfY29uZjsKKwkJZGV2LT5pcnEgPSBj YXJkLT5pcnE7CisKKwkJZGV2LT50eF9xdWV1ZV9sZW4gPSBGU1RfVFhfUVVFVUVfTEVOOworCQlk ZXYtPm9wZW4gPSBmc3Rfb3BlbjsKKwkJZGV2LT5zdG9wID0gZnN0X2Nsb3NlOworCQlkZXYtPmRv X2lvY3RsID0gZnN0X2lvY3RsOworCQlkZXYtPndhdGNoZG9nX3RpbWVvID0gRlNUX1RYX1RJTUVP VVQ7CisJCWRldi0+dHhfdGltZW91dCA9IGZzdF90eF90aW1lb3V0OworCQljYXJkLT5wb3J0c1tp XS5oZGxjLmF0dGFjaCA9IGZzdF9hdHRhY2g7CisJCWNhcmQtPnBvcnRzW2ldLmhkbGMueG1pdCA9 IGZzdF9zdGFydF94bWl0OworCisJCWlmICgoZXJyID0gcmVnaXN0ZXJfaGRsY19kZXZpY2UoJmNh cmQtPnBvcnRzW2ldLmhkbGMpKSA8IDApIHsKKwkJCXByaW50a19lcnIoIkNhbm5vdCByZWdpc3Rl ciBIRExDIGRldmljZSBmb3IgcG9ydCAlZCIKKwkJCQkgICAiIChlcnJubyAlZClcbiIsIGksIC1l cnIpOworCQkJY2FyZC0+bnBvcnRzID0gaTsKKwkJCWJyZWFrOworCQl9CisJfQogCisJc3Bpbl9s b2NrX2luaXQoJmNhcmQtPmNhcmRfbG9jayk7CisKKwlwcmludGtfaW5mbygiJXMtJXM6ICVzIElS USVkLCAlZCBwb3J0c1xuIiwKKwkgICAgICAgaGRsY190b19kZXYoJmNhcmQtPnBvcnRzWzBdLmhk bGMpLT5uYW1lLAorCSAgICAgICBoZGxjX3RvX2RldigmY2FyZC0+cG9ydHNbY2FyZC0+bnBvcnRz IC0gMV0uaGRsYyktPm5hbWUsCisJICAgICAgIHR5cGVfc3RyaW5nc1tjYXJkLT50eXBlXSwgY2Fy ZC0+aXJxLCBjYXJkLT5ucG9ydHMpOworfQogCiAvKgogICogICAgICBJbml0aWFsaXNlIGNhcmQg d2hlbiBkZXRlY3RlZC4KICAqICAgICAgUmV0dXJucyAwIHRvIGluZGljYXRlIHN1Y2Nlc3MsIG9y IGVycm5vIG90aGVyd2lzZS4KICAqLwogc3RhdGljIGludCBfX2RldmluaXQKLWZzdF9hZGRfb25l ICggc3RydWN0IHBjaV9kZXYgKnBkZXYsIGNvbnN0IHN0cnVjdCBwY2lfZGV2aWNlX2lkICplbnQg KQorZnN0X2FkZF9vbmUoc3RydWN0IHBjaV9kZXYgKnBkZXYsIGNvbnN0IHN0cnVjdCBwY2lfZGV2 aWNlX2lkICplbnQpCiB7Ci0gICAgICAgIHN0YXRpYyBpbnQgZmlyc3R0aW1lX2RvbmUgPSAwOwot ICAgICAgICBzdHJ1Y3QgZnN0X2NhcmRfaW5mbyAqY2FyZDsKLSAgICAgICAgaW50IGVyciA9IDA7 Ci0KLSAgICAgICAgaWYgKCAhIGZpcnN0dGltZV9kb25lICkKLSAgICAgICAgewotICAgICAgICAg ICAgICAgIHByaW50ayAoIEtFUk5fSU5GTyAiRmFyU3luYyBYMjEgZHJpdmVyICIgRlNUX1VTRVJf VkVSU0lPTgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiIChjKSAyMDAxIEZhclNp dGUgQ29tbXVuaWNhdGlvbnMgTHRkLlxuIik7Ci0gICAgICAgICAgICAgICAgZmlyc3R0aW1lX2Rv bmUgPSAxOwotICAgICAgICB9Ci0KLSAgICAgICAgLyogQWxsb2NhdGUgZHJpdmVyIHByaXZhdGUg ZGF0YSAqLwotICAgICAgICBjYXJkID0ga21hbGxvYyAoIHNpemVvZiAoIHN0cnVjdCBmc3RfY2Fy ZF9pbmZvICksICBHRlBfS0VSTkVMKTsKLSAgICAgICAgaWYgKGNhcmQgPT0gTlVMTCkKLSAgICAg ICAgewotICAgICAgICAgICAgICAgIHByaW50a19lcnIgKCJGYXJTeW5jIGNhcmQgZm91bmQgYnV0 IGluc3VmZmljaWVudCBtZW1vcnkgZm9yIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAiIGRyaXZlciBzdG9yYWdlXG4iKTsKLSAgICAgICAgICAgICAgICByZXR1cm4gLUVOT01FTTsK LSAgICAgICAgfQotICAgICAgICBtZW1zZXQgKCBjYXJkLCAwLCBzaXplb2YgKCBzdHJ1Y3QgZnN0 X2NhcmRfaW5mbyApKTsKLQotICAgICAgICAvKiBSZWNvcmQgaW5mbyB3ZSBuZWVkKi8KLSAgICAg ICAgY2FyZC0+aXJxICAgICAgICAgPSBwZGV2LT5pcnE7Ci0gICAgICAgIGNhcmQtPnBjaV9jb25m ICAgID0gcGNpX3Jlc291cmNlX3N0YXJ0ICggcGRldiwgMSApOwotICAgICAgICBjYXJkLT5waHlz X21lbSAgICA9IHBjaV9yZXNvdXJjZV9zdGFydCAoIHBkZXYsIDIgKTsKLSAgICAgICAgY2FyZC0+ cGh5c19jdGxtZW0gPSBwY2lfcmVzb3VyY2Vfc3RhcnQgKCBwZGV2LCAzICk7Ci0KLSAgICAgICAg Y2FyZC0+dHlwZSAgICAgICAgPSBlbnQtPmRyaXZlcl9kYXRhOwotICAgICAgICBjYXJkLT5ucG9y dHMgICAgICA9ICggZW50LT5kcml2ZXJfZGF0YSA9PSBGU1RfVFlQRV9UMlAgKSA/IDIgOiA0Owot Ci0gICAgICAgIGNhcmQtPnN0YXRlICAgICAgID0gRlNUX1VOSU5JVDsKLQotICAgICAgICBkYmcg KCBEQkdfUENJLCJ0eXBlICVkIG5wb3J0cyAlZCBpcnEgJWRcbiIsIGNhcmQtPnR5cGUsCi0gICAg ICAgICAgICAgICAgICAgICAgICBjYXJkLT5ucG9ydHMsIGNhcmQtPmlycSApOwotICAgICAgICBk YmcgKCBEQkdfUENJLCJjb25mICUwNHggbWVtICUwOHggY3RsbWVtICUwOHhcbiIsCi0gICAgICAg ICAgICAgICAgICAgICAgICBjYXJkLT5wY2lfY29uZiwgY2FyZC0+cGh5c19tZW0sIGNhcmQtPnBo eXNfY3RsbWVtICk7Ci0KLSAgICAgICAgLyogQ2hlY2sgd2UgY2FuIGdldCBhY2Nlc3MgdG8gdGhl IG1lbW9yeSBhbmQgSS9PIHJlZ2lvbnMgKi8KLSAgICAgICAgaWYgKCAhIHJlcXVlc3RfcmVnaW9u ICggY2FyZC0+cGNpX2NvbmYsIDB4ODAsIlBMWCBjb25maWcgcmVncyIpKQotICAgICAgICB7Ci0g ICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIlVuYWJsZSB0byBnZXQgY29uZmlnIEkvTyBAIDB4 JTA0WFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNhcmQtPnBjaV9jb25mICk7Ci0gICAgICAgICAgICAgICAgZXJyID0gLUVOT0RFVjsKLSAgICAg ICAgICAgICAgICBnb3RvIGVycm9yX2ZyZWVfY2FyZDsKLSAgICAgICAgfQotICAgICAgICBpZiAo ICEgcmVxdWVzdF9tZW1fcmVnaW9uICggY2FyZC0+cGh5c19tZW0sIEZTVF9NRU1TSVpFLCJTaGFy ZWQgUkFNIikpCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBwcmludGtfZXJyICgiVW5hYmxl IHRvIGdldCBtYWluIG1lbW9yeSBAIDB4JTA4WFxuIiwKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGNhcmQtPnBoeXNfbWVtICk7Ci0gICAgICAgICAgICAg ICAgZXJyID0gLUVOT0RFVjsKLSAgICAgICAgICAgICAgICBnb3RvIGVycm9yX3JlbGVhc2VfaW87 Ci0gICAgICAgIH0KLSAgICAgICAgaWYgKCAhIHJlcXVlc3RfbWVtX3JlZ2lvbiAoIGNhcmQtPnBo eXNfY3RsbWVtLCAweDEwLCJDb250cm9sIG1lbW9yeSIpKQotICAgICAgICB7Ci0gICAgICAgICAg ICAgICAgcHJpbnRrX2VyciAoIlVuYWJsZSB0byBnZXQgY29udHJvbCBtZW1vcnkgQCAweCUwOFhc biIsCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjYXJk LT5waHlzX2N0bG1lbSApOwotICAgICAgICAgICAgICAgIGVyciA9IC1FTk9ERVY7Ci0gICAgICAg ICAgICAgICAgZ290byBlcnJvcl9yZWxlYXNlX21lbTsKLSAgICAgICAgfQotCi0gICAgICAgIC8q IFRyeSB0byBlbmFibGUgdGhlIGRldmljZSAqLwotICAgICAgICBpZiAoKCBlcnIgPSBwY2lfZW5h YmxlX2RldmljZSAoIHBkZXYgKSkgIT0gMCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBw cmludGtfZXJyICgiRmFpbGVkIHRvIGVuYWJsZSBjYXJkLiBFcnIgJWRcbiIsIC1lcnIgKTsKLSAg ICAgICAgICAgICAgICBnb3RvIGVycm9yX3JlbGVhc2VfY3RsbWVtOwotICAgICAgICB9Ci0KLSAg ICAgICAgLyogR2V0IHZpcnR1YWwgYWRkcmVzc2VzIG9mIG1lbW9yeSByZWdpb25zICovCi0gICAg ICAgIGlmICgoIGNhcmQtPm1lbSA9IGlvcmVtYXAgKCBjYXJkLT5waHlzX21lbSwgRlNUX01FTVNJ WkUgKSkgPT0gTlVMTCApCi0gICAgICAgIHsKLSAgICAgICAgICAgICAgICBwcmludGtfZXJyICgi UGh5c2ljYWwgbWVtb3J5IHJlbWFwIGZhaWxlZFxuIik7Ci0gICAgICAgICAgICAgICAgZXJyID0g LUVOT0RFVjsKLSAgICAgICAgICAgICAgICBnb3RvIGVycm9yX3JlbGVhc2VfY3RsbWVtOwotICAg ICAgICB9Ci0gICAgICAgIGlmICgoIGNhcmQtPmN0bG1lbSA9IGlvcmVtYXAgKCBjYXJkLT5waHlz X2N0bG1lbSwgMHgxMCApKSA9PSBOVUxMICkKLSAgICAgICAgewotICAgICAgICAgICAgICAgIHBy aW50a19lcnIgKCJDb250cm9sIG1lbW9yeSByZW1hcCBmYWlsZWRcbiIpOwotICAgICAgICAgICAg ICAgIGVyciA9IC1FTk9ERVY7Ci0gICAgICAgICAgICAgICAgZ290byBlcnJvcl91bm1hcF9tZW07 Ci0gICAgICAgIH0KLSAgICAgICAgZGJnICggREJHX1BDSSwia2VybmVsIG1lbSAlcCwgY3RsbWVt ICVwXG4iLCBjYXJkLT5tZW0sIGNhcmQtPmN0bG1lbSk7Ci0KLSAgICAgICAgLyogUmVzZXQgdGhl IGNhcmQncyBwcm9jZXNzb3IgKi8KLSAgICAgICAgZnN0X2NwdXJlc2V0ICggY2FyZCApOwotICAg ICAgICBjYXJkLT5zdGF0ZSA9IEZTVF9SRVNFVDsKLQotICAgICAgICAvKiBSZWdpc3RlciB0aGUg aW50ZXJydXB0IGhhbmRsZXIgKi8KLSAgICAgICAgaWYgKCByZXF1ZXN0X2lycSAoIGNhcmQtPmly cSwgZnN0X2ludHIsIFNBX1NISVJRLCBGU1RfREVWX05BTUUsIGNhcmQgKSkKLSAgICAgICAgewot Ci0gICAgICAgICAgICAgICAgcHJpbnRrX2VyciAoIlVuYWJsZSB0byByZWdpc3RlciBpbnRlcnJ1 cHQgJWRcbiIsIGNhcmQtPmlycSApOwotICAgICAgICAgICAgICAgIGVyciA9IC1FTk9ERVY7Ci0g ICAgICAgICAgICAgICAgZ290byBlcnJvcl91bm1hcF9jdGxtZW07Ci0gICAgICAgIH0KLQotICAg ICAgICAvKiBSZWNvcmQgZHJpdmVyIGRhdGEgZm9yIGxhdGVyIHVzZSAqLwotICAgICAgICBwY2lf c2V0X2RydmRhdGEocGRldiwgY2FyZCk7Ci0KLSAgICAgICAgLyogUmVtYWluZGVyIG9mIGNhcmQg c2V0dXAgKi8KLSAgICAgICAgZnN0X2luaXRfY2FyZCAoIGNhcmQgKTsKLQotICAgICAgICByZXR1 cm4gMDsgICAgICAgICAgICAgICAgICAgICAgIC8qIFN1Y2Nlc3MgKi8KLQotCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogRmFpbHVyZS4gUmVsZWFzZSByZXNvdXJj ZXMgKi8KLWVycm9yX3VubWFwX2N0bG1lbToKLSAgICAgICAgaW91bm1hcCAoIGNhcmQtPmN0bG1l bSApOwotCi1lcnJvcl91bm1hcF9tZW06Ci0gICAgICAgIGlvdW5tYXAgKCBjYXJkLT5tZW0gKTsK LQotZXJyb3JfcmVsZWFzZV9jdGxtZW06Ci0gICAgICAgIHJlbGVhc2VfbWVtX3JlZ2lvbiAoIGNh cmQtPnBoeXNfY3RsbWVtLCAweDEwICk7Ci0KLWVycm9yX3JlbGVhc2VfbWVtOgotICAgICAgICBy ZWxlYXNlX21lbV9yZWdpb24gKCBjYXJkLT5waHlzX21lbSwgRlNUX01FTVNJWkUgKTsKLQotZXJy b3JfcmVsZWFzZV9pbzoKLSAgICAgICAgcmVsZWFzZV9yZWdpb24gKCBjYXJkLT5wY2lfY29uZiwg MHg4MCApOwotCi1lcnJvcl9mcmVlX2NhcmQ6Ci0gICAgICAgIGtmcmVlICggY2FyZCApOwotICAg ICAgICByZXR1cm4gZXJyOwotfQorCXN0YXRpYyBpbnQgZmlyc3R0aW1lX2RvbmUgPSAwOworCXN0 YXRpYyBpbnQgbm9fb2ZfY2FyZHNfYWRkZWQgPSAwOworCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpj YXJkOworCWludCBlcnIgPSAwOworCWludCBpOworCisJaWYgKCFmaXJzdHRpbWVfZG9uZSkgewor CQlwcmludGtfaW5mbygiRmFyU3luYyBXQU4gZHJpdmVyICIgRlNUX1VTRVJfVkVSU0lPTgorCQkg ICAgICAgIiAoYykgMjAwMS0yMDA0IEZhclNpdGUgQ29tbXVuaWNhdGlvbnMgTHRkLlxuIik7CisJ CWZpcnN0dGltZV9kb25lID0gMTsKKwkJZGJnKERCR19BU1MsICJUaGUgdmFsdWUgb2YgZGVidWcg bWFzayBpcyAleFxuIiwgZnN0X2RlYnVnX21hc2spOworCX0KKworCS8qCisJICogV2UgYXJlIGdv aW5nIHRvIGJlIGNsZXZlciBhbmQgYWxsb3cgY2VydGFpbiBjYXJkcyBub3QgdG8gYmUKKwkgKiBj b25maWd1cmVkLiAgQW4gZXhjbHVkZSBsaXN0IGNhbiBiZSBwcm92aWRlZCBpbiAvZXRjL21vZHVs ZXMuY29uZgorCSAqLworCWlmIChmc3RfZXhjbHVkZWRfY2FyZHMgIT0gMCkgeworCQkvKgorCQkg KiBUaGVyZSBhcmUgY2FyZHMgdG8gZXhjbHVkZQorCQkgKgorCQkgKi8KKwkJZm9yIChpID0gMDsg aSA8IGZzdF9leGNsdWRlZF9jYXJkczsgaSsrKSB7CisJCQlpZiAoKHBkZXYtPmRldmZuKSA+PiAz ID09IGZzdF9leGNsdWRlZF9saXN0W2ldKSB7CisJCQkJcHJpbnRrX2luZm8oIkZhclN5bmMgUENJ IGRldmljZSAlZCBub3QgYXNzaWduZWRcbiIsCisJCQkJICAgICAgIChwZGV2LT5kZXZmbikgPj4g Myk7CisJCQkJcmV0dXJuIC1FQlVTWTsKKwkJCX0KKwkJfQorCX0KKworCS8qIEFsbG9jYXRlIGRy aXZlciBwcml2YXRlIGRhdGEgKi8KKwljYXJkID0ga21hbGxvYyhzaXplb2YgKHN0cnVjdCBmc3Rf Y2FyZF9pbmZvKSwgR0ZQX0tFUk5FTCk7CisJaWYgKGNhcmQgPT0gTlVMTCkgeworCQlwcmludGtf ZXJyKCJGYXJTeW5jIGNhcmQgZm91bmQgYnV0IGluc3VmZmljaWVudCBtZW1vcnkgZm9yIgorCQkJ ICAgIiBkcml2ZXIgc3RvcmFnZVxuIik7CisJCXJldHVybiAtRU5PTUVNOworCX0KKwltZW1zZXQo Y2FyZCwgMCwgc2l6ZW9mIChzdHJ1Y3QgZnN0X2NhcmRfaW5mbykpOworCisJLyogVHJ5IHRvIGVu YWJsZSB0aGUgZGV2aWNlICovCisJaWYgKChlcnIgPSBwY2lfZW5hYmxlX2RldmljZShwZGV2KSkg IT0gMCkgeworCQlwcmludGtfZXJyKCJGYWlsZWQgdG8gZW5hYmxlIGNhcmQuIEVyciAlZFxuIiwg LWVycik7CisJCWtmcmVlKGNhcmQpOworCQlyZXR1cm4gZXJyOworCX0KIAorCWlmICgoZXJyID0g cGNpX3JlcXVlc3RfcmVnaW9ucyhwZGV2LCAiRmFyU3luYyIpKSAhPTApIHsKKwkgICAgICAgIHBy aW50a19lcnIoIkZhaWxlZCB0byBhbGxvY2F0ZSByZWdpb25zLiBFcnIgJWRcbiIsIC1lcnIpOwor CQlwY2lfZGlzYWJsZV9kZXZpY2UocGRldik7CisJCWtmcmVlKGNhcmQpOworCSAgICAgICAgcmV0 dXJuIGVycjsKKwl9CisKKwkvKiBHZXQgdmlydHVhbCBhZGRyZXNzZXMgb2YgbWVtb3J5IHJlZ2lv bnMgKi8KKwljYXJkLT5wY2lfY29uZiA9IHBjaV9yZXNvdXJjZV9zdGFydChwZGV2LCAxKTsKKwlj YXJkLT5waHlzX21lbSA9IHBjaV9yZXNvdXJjZV9zdGFydChwZGV2LCAyKTsKKwljYXJkLT5waHlz X2N0bG1lbSA9IHBjaV9yZXNvdXJjZV9zdGFydChwZGV2LCAzKTsKKwlpZiAoKGNhcmQtPm1lbSA9 IGlvcmVtYXAoY2FyZC0+cGh5c19tZW0sIEZTVF9NRU1TSVpFKSkgPT0gTlVMTCkgeworCQlwcmlu dGtfZXJyKCJQaHlzaWNhbCBtZW1vcnkgcmVtYXAgZmFpbGVkXG4iKTsKKwkJcGNpX3JlbGVhc2Vf cmVnaW9ucyhwZGV2KTsKKwkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOworCQlrZnJlZShjYXJk KTsKKwkJcmV0dXJuIC1FTk9ERVY7CisJfQorCWlmICgoY2FyZC0+Y3RsbWVtID0gaW9yZW1hcChj YXJkLT5waHlzX2N0bG1lbSwgMHgxMCkpID09IE5VTEwpIHsKKwkJcHJpbnRrX2VycigiQ29udHJv bCBtZW1vcnkgcmVtYXAgZmFpbGVkXG4iKTsKKwkJcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2KTsK KwkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOworCQlrZnJlZShjYXJkKTsKKwkJcmV0dXJuIC1F Tk9ERVY7CisJfQorCWRiZyhEQkdfUENJLCAia2VybmVsIG1lbSAlcCwgY3RsbWVtICVwXG4iLCBj YXJkLT5tZW0sIGNhcmQtPmN0bG1lbSk7CisKKwkvKiBSZWdpc3RlciB0aGUgaW50ZXJydXB0IGhh bmRsZXIgKi8KKwlpZiAocmVxdWVzdF9pcnEocGRldi0+aXJxLCBmc3RfaW50ciwgU0FfU0hJUlEs IEZTVF9ERVZfTkFNRSwgY2FyZCkpIHsKKwkJcHJpbnRrX2VycigiVW5hYmxlIHRvIHJlZ2lzdGVy IGludGVycnVwdCAlZFxuIiwgY2FyZC0+aXJxKTsKKwkJcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2 KTsKKwkJcGNpX2Rpc2FibGVfZGV2aWNlKHBkZXYpOworCQlpb3VubWFwKGNhcmQtPmN0bG1lbSk7 CisJCWlvdW5tYXAoY2FyZC0+bWVtKTsKKwkJa2ZyZWUoY2FyZCk7CisJCXJldHVybiAtRU5PREVW OworCX0KKworCS8qIFJlY29yZCBpbmZvIHdlIG5lZWQgKi8KKwljYXJkLT5pcnEgPSBwZGV2LT5p cnE7CisJY2FyZC0+dHlwZSA9IGVudC0+ZHJpdmVyX2RhdGE7CisJY2FyZC0+ZmFtaWx5ID0gKChl bnQtPmRyaXZlcl9kYXRhID09IEZTVF9UWVBFX1QyUCkgfHwKKwkJCShlbnQtPmRyaXZlcl9kYXRh ID09IEZTVF9UWVBFX1Q0UCkpCisJICAgID8gRlNUX0ZBTUlMWV9UWFAgOiBGU1RfRkFNSUxZX1RY VTsKKwlpZiAoKGVudC0+ZHJpdmVyX2RhdGEgPT0gRlNUX1RZUEVfVDFVKSB8fAorCSAgICAoZW50 LT5kcml2ZXJfZGF0YSA9PSBGU1RfVFlQRV9URTEpKQorCQljYXJkLT5ucG9ydHMgPSAxOworCWVs c2UKKwkJY2FyZC0+bnBvcnRzID0gKChlbnQtPmRyaXZlcl9kYXRhID09IEZTVF9UWVBFX1QyUCkg fHwKKwkJCQkoZW50LT5kcml2ZXJfZGF0YSA9PSBGU1RfVFlQRV9UMlUpKSA/IDIgOiA0OworCisJ Y2FyZC0+c3RhdGUgPSBGU1RfVU5JTklUOworCWNhcmQtPmRldmljZSA9IHBkZXY7CisKKwlkYmco REJHX1BDSSwgInR5cGUgJWQgbnBvcnRzICVkIGlycSAlZFxuIiwgY2FyZC0+dHlwZSwKKwkgICAg Y2FyZC0+bnBvcnRzLCBjYXJkLT5pcnEpOworCWRiZyhEQkdfUENJLCAiY29uZiAlMDR4IG1lbSAl MDh4IGN0bG1lbSAlMDh4XG4iLAorCSAgICBjYXJkLT5wY2lfY29uZiwgY2FyZC0+cGh5c19tZW0s IGNhcmQtPnBoeXNfY3RsbWVtKTsKKworCS8qIFJlc2V0IHRoZSBjYXJkJ3MgcHJvY2Vzc29yICov CisJZnN0X2NwdXJlc2V0KGNhcmQpOworCWNhcmQtPnN0YXRlID0gRlNUX1JFU0VUOworCisJLyog SW5pdGlhbGlzZSBETUEgKGlmIHJlcXVpcmVkKSAqLworCWZzdF9pbml0X2RtYShjYXJkKTsKKwor CS8qIFJlY29yZCBkcml2ZXIgZGF0YSBmb3IgbGF0ZXIgdXNlICovCisJcGNpX3NldF9kcnZkYXRh KHBkZXYsIGNhcmQpOworCisJLyogUmVtYWluZGVyIG9mIGNhcmQgc2V0dXAgKi8KKwlmc3RfY2Fy ZF9hcnJheVtub19vZl9jYXJkc19hZGRlZF0gPSBjYXJkOworCWNhcmQtPmNhcmRfbm8gPSBub19v Zl9jYXJkc19hZGRlZCsrOwkvKiBSZWNvcmQgaW5zdGFuY2UgYW5kIGJ1bXAgaXQgKi8KKwlmc3Rf aW5pdF9jYXJkKGNhcmQpOworCWlmIChjYXJkLT5mYW1pbHkgPT0gRlNUX0ZBTUlMWV9UWFUpIHsK KwkJLyoKKwkJICogQWxsb2NhdGUgYSBkbWEgYnVmZmVyIGZvciB0cmFuc21pdCBhbmQgcmVjZWl2 ZXMKKwkJICovCisJCWNhcmQtPnJ4X2RtYV9oYW5kbGVfaG9zdCA9CisJCSAgICBwY2lfYWxsb2Nf Y29uc2lzdGVudChjYXJkLT5kZXZpY2UsIEZTVF9NQVhfTVRVLAorCQkJCQkgJmNhcmQtPnJ4X2Rt YV9oYW5kbGVfY2FyZCk7CisJCWlmIChjYXJkLT5yeF9kbWFfaGFuZGxlX2hvc3QgPT0gTlVMTCkg eworCQkJcHJpbnRrX2VycigiQ291bGQgbm90IGFsbG9jYXRlIHJ4IGRtYSBidWZmZXJcbiIpOwor CQkJZnN0X2Rpc2FibGVfaW50cihjYXJkKTsKKwkJCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7 CisJCQlwY2lfZGlzYWJsZV9kZXZpY2UocGRldik7CisJCQlpb3VubWFwKGNhcmQtPmN0bG1lbSk7 CisJCQlpb3VubWFwKGNhcmQtPm1lbSk7CisJCQlrZnJlZShjYXJkKTsKKwkJCXJldHVybiAtRU5P TUVNOworCQl9CisJCWNhcmQtPnR4X2RtYV9oYW5kbGVfaG9zdCA9CisJCSAgICBwY2lfYWxsb2Nf Y29uc2lzdGVudChjYXJkLT5kZXZpY2UsIEZTVF9NQVhfTVRVLAorCQkJCQkgJmNhcmQtPnR4X2Rt YV9oYW5kbGVfY2FyZCk7CisJCWlmIChjYXJkLT50eF9kbWFfaGFuZGxlX2hvc3QgPT0gTlVMTCkg eworCQkJcHJpbnRrX2VycigiQ291bGQgbm90IGFsbG9jYXRlIHR4IGRtYSBidWZmZXJcbiIpOwor CQkJZnN0X2Rpc2FibGVfaW50cihjYXJkKTsKKwkJCXBjaV9yZWxlYXNlX3JlZ2lvbnMocGRldik7 CisJCQlwY2lfZGlzYWJsZV9kZXZpY2UocGRldik7CisJCQlpb3VubWFwKGNhcmQtPmN0bG1lbSk7 CisJCQlpb3VubWFwKGNhcmQtPm1lbSk7CisJCQlrZnJlZShjYXJkKTsKKwkJCXJldHVybiAtRU5P TUVNOworCQl9CisJfQorCXJldHVybiAwOwkJLyogU3VjY2VzcyAqLworfQogCiAvKgogICogICAg ICBDbGVhbnVwIGFuZCBjbG9zZSBkb3duIGEgY2FyZAogICovCiBzdGF0aWMgdm9pZCBfX2RldmV4 aXQKLWZzdF9yZW1vdmVfb25lICggc3RydWN0IHBjaV9kZXYgKnBkZXYgKQorZnN0X3JlbW92ZV9v bmUoc3RydWN0IHBjaV9kZXYgKnBkZXYpCiB7Ci0gICAgICAgIHN0cnVjdCBmc3RfY2FyZF9pbmZv ICpjYXJkOwotICAgICAgICBpbnQgaTsKLQotICAgICAgICBjYXJkID0gcGNpX2dldF9kcnZkYXRh KHBkZXYpOworCXN0cnVjdCBmc3RfY2FyZF9pbmZvICpjYXJkOworCWludCBpOwogCi0gICAgICAg IGZvciAoIGkgPSAwIDsgaSA8IGNhcmQtPm5wb3J0cyA7IGkrKyApCi0gICAgICAgIHsKLSAgICAg ICAgICAgICAgICB1bnJlZ2lzdGVyX2hkbGNfZGV2aWNlICggJmNhcmQtPnBvcnRzW2ldLmhkbGMg KTsKLSAgICAgICAgfQorCWNhcmQgPSBwY2lfZ2V0X2RydmRhdGEocGRldik7CiAKLSAgICAgICAg ZnN0X2Rpc2FibGVfaW50ciAoIGNhcmQgKTsKLSAgICAgICAgZnJlZV9pcnEgKCBjYXJkLT5pcnEs IGNhcmQgKTsKKwlmb3IgKGkgPSAwOyBpIDwgY2FyZC0+bnBvcnRzOyBpKyspIHsKKwkJdW5yZWdp c3Rlcl9oZGxjX2RldmljZSgmY2FyZC0+cG9ydHNbaV0uaGRsYyk7CisJfQogCi0gICAgICAgIGlv dW5tYXAgKCBjYXJkLT5jdGxtZW0gKTsKLSAgICAgICAgaW91bm1hcCAoIGNhcmQtPm1lbSApOwor CWZzdF9kaXNhYmxlX2ludHIoY2FyZCk7CisJZnJlZV9pcnEoY2FyZC0+aXJxLCBjYXJkKTsKIAot ICAgICAgICByZWxlYXNlX21lbV9yZWdpb24gKCBjYXJkLT5waHlzX2N0bG1lbSwgMHgxMCApOwot ICAgICAgICByZWxlYXNlX21lbV9yZWdpb24gKCBjYXJkLT5waHlzX21lbSwgRlNUX01FTVNJWkUg KTsKLSAgICAgICAgcmVsZWFzZV9yZWdpb24gKCBjYXJkLT5wY2lfY29uZiwgMHg4MCApOworCWlv dW5tYXAoY2FyZC0+Y3RsbWVtKTsKKwlpb3VubWFwKGNhcmQtPm1lbSk7CiAKLSAgICAgICAga2Zy ZWUgKCBjYXJkICk7CisJcGNpX3JlbGVhc2VfcmVnaW9ucyhwZGV2KTsKKyNpZiAwCisJcmVsZWFz ZV9tZW1fcmVnaW9uKGNhcmQtPnBoeXNfY3RsbWVtLCAweDEwKTsKKwlyZWxlYXNlX21lbV9yZWdp b24oY2FyZC0+cGh5c19tZW0sIEZTVF9NRU1TSVpFKTsKKwlpZiAoY2FyZC0+ZmFtaWx5ID09IEZT VF9GQU1JTFlfVFhVKSB7CisJCXJlbGVhc2VfcmVnaW9uKGNhcmQtPnBjaV9jb25mLCAweDEwMCk7 CisJfSBlbHNlIHsKKwkJcmVsZWFzZV9yZWdpb24oY2FyZC0+cGNpX2NvbmYsIDB4ODApOworCX0K KyNlbmRpZgorCWlmIChjYXJkLT5mYW1pbHkgPT0gRlNUX0ZBTUlMWV9UWFUpIHsKKwkJLyoKKwkJ ICogRnJlZSBkbWEgYnVmZmVycworCQkgKi8KKwkJcGNpX2ZyZWVfY29uc2lzdGVudChjYXJkLT5k ZXZpY2UsIEZTVF9NQVhfTVRVLAorCQkJCSAgICBjYXJkLT5yeF9kbWFfaGFuZGxlX2hvc3QsCisJ CQkJICAgIGNhcmQtPnJ4X2RtYV9oYW5kbGVfY2FyZCk7CisJCXBjaV9mcmVlX2NvbnNpc3RlbnQo Y2FyZC0+ZGV2aWNlLCBGU1RfTUFYX01UVSwKKwkJCQkgICAgY2FyZC0+dHhfZG1hX2hhbmRsZV9o b3N0LAorCQkJCSAgICBjYXJkLT50eF9kbWFfaGFuZGxlX2NhcmQpOworCX0KKwlmc3RfY2FyZF9h cnJheVtjYXJkLT5jYXJkX25vXSA9IE5VTEw7CiB9CiAKIHN0YXRpYyBzdHJ1Y3QgcGNpX2RyaXZl ciBmc3RfZHJpdmVyID0gewotICAgICAgICBuYW1lOiAgICAgICAgICAgRlNUX05BTUUsCi0gICAg ICAgIGlkX3RhYmxlOiAgICAgICBmc3RfcGNpX2Rldl9pZCwKLSAgICAgICAgcHJvYmU6ICAgICAg ICAgIGZzdF9hZGRfb25lLAotICAgICAgICByZW1vdmU6ICAgICAgICAgX19kZXZleGl0X3AoZnN0 X3JlbW92ZV9vbmUpLAotICAgICAgICBzdXNwZW5kOiAgICAgICAgTlVMTCwKLSAgICAgICAgcmVz dW1lOiAgICAgICAgIE5VTEwsCisJbmFtZTpGU1RfTkFNRSwKKwlpZF90YWJsZTpmc3RfcGNpX2Rl dl9pZCwKKwlwcm9iZTpmc3RfYWRkX29uZSwKKwlyZW1vdmU6X19kZXZleGl0X3AoZnN0X3JlbW92 ZV9vbmUpLAorCXN1c3BlbmQ6TlVMTCwKKwlyZXN1bWU6TlVMTCwKIH07CiAKIHN0YXRpYyBpbnQg X19pbml0CiBmc3RfaW5pdCh2b2lkKQogewotICAgICAgICByZXR1cm4gcGNpX21vZHVsZV9pbml0 ICggJmZzdF9kcml2ZXIgKTsKKwlpbnQgaTsKKworCWZvciAoaSA9IDA7IGkgPCBGU1RfTUFYX0NB UkRTOyBpKyspCisJCWZzdF9jYXJkX2FycmF5W2ldID0gTlVMTDsKKwlzcGluX2xvY2tfaW5pdCgm ZnN0X3dvcmtfcV9sb2NrKTsKKwlyZXR1cm4gcGNpX21vZHVsZV9pbml0KCZmc3RfZHJpdmVyKTsK IH0KIAogc3RhdGljIHZvaWQgX19leGl0CiBmc3RfY2xlYW51cF9tb2R1bGUodm9pZCkKIHsKLSAg ICAgICAgcGNpX3VucmVnaXN0ZXJfZHJpdmVyICggJmZzdF9kcml2ZXIgKTsKKwlwcmludGtfaW5m bygiRmFyU3luYyBXQU4gZHJpdmVyIHVubG9hZGluZ1xuIik7CisJcGNpX3VucmVnaXN0ZXJfZHJp dmVyKCZmc3RfZHJpdmVyKTsKIH0KIAotbW9kdWxlX2luaXQgKCBmc3RfaW5pdCApOwotbW9kdWxl X2V4aXQgKCBmc3RfY2xlYW51cF9tb2R1bGUgKTsKLQorbW9kdWxlX2luaXQoZnN0X2luaXQpOwor bW9kdWxlX2V4aXQoZnN0X2NsZWFudXBfbW9kdWxlKTsKZGlmZiAtdXJOIGxpbnV4LTIuNC4yNy1w cmUxL2RyaXZlcnMvbmV0L3dhbi9mYXJzeW5jLmggbGludXgtMi40LjI3LXByZTEtbmV3L2RyaXZl cnMvbmV0L3dhbi9mYXJzeW5jLmgKLS0tIGxpbnV4LTIuNC4yNy1wcmUxL2RyaXZlcnMvbmV0L3dh bi9mYXJzeW5jLmgJMjAwMy0wNi0xMyAxNTo1MTozNS4wMDAwMDAwMDAgKzAxMDAKKysrIGxpbnV4 LTIuNC4yNy1wcmUxLW5ldy9kcml2ZXJzL25ldC93YW4vZmFyc3luYy5oCTIwMDQtMDQtMjYgMTg6 NTg6MDkuMDAwMDAwMDAwICswMTAwCkBAIC0zMiw4ICszMiwxMyBAQAogICogICAgICBBIHNob3J0 IGNvbW1vbiBwcmVmaXggaXMgdXNlZnVsIGZvciByb3V0aW5lcyB3aXRoaW4gdGhlIGRyaXZlciB0 byBhdm9pZAogICogICAgICBjb25mbGljdCB3aXRoIG90aGVyIHNpbWlsYXIgZHJpdmVycyBhbmQg SSBjaG9zZW4gdG8gdXNlICJmc3RfIiBmb3IgdGhpcwogICogICAgICBwdXJwb3NlIChGYXJTaXRl IFQtc2VyaWVzKS4KKyAqCisgKiAgICAgIEZpbmFsbHkgdGhlIGRldmljZSBkcml2ZXIgbmVlZHMg YSBzaG9ydCBuZXR3b3JrIGludGVyZmFjZSBuYW1lLiBTaW5jZQorICogICAgICAiaGRsYyIgaXMg YWxyZWFkeSBpbiB1c2UgSSd2ZSBjaG9zZW4gdGhlIGV2ZW4gbGVzcyBpbmZvcm1hdGl2ZSAic3lu YyIKKyAqICAgICAgZm9yIHRoZSBwcmVzZW50LgogICovCiAjZGVmaW5lIEZTVF9OQU1FICAgICAg ICAgICAgICAgICJmc3QiICAgICAgICAgICAvKiBJbiBkZWJ1Zy9pbmZvIGV0YyAqLworI2RlZmlu ZSBGU1RfTkRFVl9OQU1FICAgICAgICAgICAic3luYyIgICAgICAgICAgLyogRm9yIG5ldCBpbnRl cmZhY2UgKi8KICNkZWZpbmUgRlNUX0RFVl9OQU1FICAgICAgICAgICAgImZhcnN5bmMiICAgICAg IC8qIEZvciBtaXNjIGludGVyZmFjZXMgKi8KIAogCkBAIC00NSw3ICs1MCw3IEBACiAgKiAgICAg IGhhdmUgaW5kaXZpZHVhbCB2ZXJzaW9ucyAob3IgSURzKSB0aGF0IG1vdmUgbXVjaCBmYXN0ZXIg dGhhbiB0aGUKICAqICAgICAgdGhlIHJlbGVhc2UgdmVyc2lvbiBhcyBpbmRpdmlkdWFsIHVwZGF0 ZXMgYXJlIHRyYWNrZWQuCiAgKi8KLSNkZWZpbmUgRlNUX1VTRVJfVkVSU0lPTiAgICAgICAgIjAu MDkiCisjZGVmaW5lIEZTVF9VU0VSX1ZFUlNJT04gICAgICAgICIxLjA0IgogCiAKIC8qICAgICAg SW9jdGwgY2FsbCBjb21tYW5kIHZhbHVlcwpAQCAtMTAwLDYgKzEwNSw3IEBACiAgICAgICAgIHVu c2lnbmVkIGludCAgIHN0YXRlOyAgICAgICAgICAgLyogU3RhdGUgb2YgY2FyZCAqLwogICAgICAg ICB1bnNpZ25lZCBpbnQgICBpbmRleDsgICAgICAgICAgIC8qIEluZGV4IG9mIHBvcnQgaW9jdGwg d2FzIGlzc3VlZCBvbiAqLwogICAgICAgICB1bnNpZ25lZCBpbnQgICBzbWNGaXJtd2FyZVZlcnNp b247CisgICAgICAgIHVuc2lnbmVkIGxvbmcgIGtlcm5lbFZlcnNpb247ICAgLyogV2hhdCBLZXJu ZWwgdmVyc2lvbiB3ZSBhcmUgd29ya2luZyB3aXRoICovCiAgICAgICAgIHVuc2lnbmVkIHNob3J0 IGxpbmVJbnRlcmZhY2U7ICAgLyogUGh5c2ljYWwgaW50ZXJmYWNlIHR5cGUgKi8KICAgICAgICAg dW5zaWduZWQgY2hhciAgcHJvdG87ICAgICAgICAgICAvKiBMaW5lIHByb3RvY29sICovCiAgICAg ICAgIHVuc2lnbmVkIGNoYXIgIGludGVybmFsQ2xvY2s7ICAgLyogMSA9PiBpbnRlcm5hbCBjbG9j aywgMCA9PiBleHRlcm5hbCAqLwpAQCAtMTEwLDYgKzExNiwzMSBAQAogICAgICAgICB1bnNpZ25l ZCBzaG9ydCBjYWJsZVN0YXR1czsgICAgIC8qIGxzYjogMD0+IHByZXNlbnQsIDE9PiBhYnNlbnQg Ki8KICAgICAgICAgdW5zaWduZWQgc2hvcnQgY2FyZE1vZGU7ICAgICAgICAvKiBsc2I6IExFRCBp ZCBtb2RlICovCiAgICAgICAgIHVuc2lnbmVkIHNob3J0IGRlYnVnOyAgICAgICAgICAgLyogRGVi dWcgZmxhZ3MgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgdHJhbnNwYXJlbnRNb2RlOyAvKiBO b3QgdXNlZCBhbHdheXMgMCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBpbnZlcnRDbG9jazsg ICAgIC8qIEludmVydCBjbG9jayBmZWF0dXJlIGZvciBzeW5jaW5nICovCisgICAgICAgIHVuc2ln bmVkIGNoYXIgIHN0YXJ0aW5nU2xvdDsgICAgLyogVGltZSBzbG90IHRvIHVzZSBmb3Igc3RhcnQg b2YgdHggKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgY2xvY2tTb3VyY2U7ICAgICAvKiBFeHRl cm5hbCBvciBpbnRlcm5hbCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBmcmFtaW5nOyAgICAg ICAgIC8qIEUxLCBUMSBvciBKMSAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBzdHJ1Y3R1cmU7 ICAgICAgIC8qIHVuZnJhbWVkLCBkb3VibGUsIGNyYzQsIGY0LCBmMTIsICovCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLyogZjI0IGY3MiAqLworICAgICAgICB1bnNp Z25lZCBjaGFyICBpbnRlcmZhY2U7ICAgICAgIC8qIHJqNDhjIG9yIGJuYyAqLworICAgICAgICB1 bnNpZ25lZCBjaGFyICBjb2Rpbmc7ICAgICAgICAgIC8qIGhkYjMgYjh6cyAqLworICAgICAgICB1 bnNpZ25lZCBjaGFyICBsaW5lQnVpbGRPdXQ7ICAgIC8qIDAsIC03LjUsIC0xNSwgLTIyICovCisg ICAgICAgIHVuc2lnbmVkIGNoYXIgIGVxdWFsaXplcjsgICAgICAgLyogc2hvcnQgb3IgbG9uIGhh dWwgc2V0dGluZ3MgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgbG9vcE1vZGU7ICAgICAgICAv KiB2YXJpb3VzIGxvb3BiYWNrcyAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICByYW5nZTsgICAg ICAgICAgIC8qIGNhYmxlIGxlbmd0aHMgKi8KKyAgICAgICAgdW5zaWduZWQgY2hhciAgdHhCdWZm ZXJNb2RlOyAgICAvKiB0eCBlbGFzdGljIGJ1ZmZlciBkZXB0aCAqLworICAgICAgICB1bnNpZ25l ZCBjaGFyICByeEJ1ZmZlck1vZGU7ICAgIC8qIHJ4IGVsYXN0aWMgYnVmZmVyIGRlcHRoICovCisg ICAgICAgIHVuc2lnbmVkIGNoYXIgIGxvc1RocmVzaG9sZDsgICAgLyogQXR0ZW51YXRpb24gb24g TE9TIHNpZ25hbCAqLworICAgICAgICB1bnNpZ25lZCBjaGFyICBpZGxlQ29kZTsgICAgICAgIC8q IFZhbHVlIHRvIHNlbmQgYXMgaWRsZSB0aW1lc2xvdCAqLworICAgICAgICB1bnNpZ25lZCBpbnQg ICByZWNlaXZlQnVmZmVyRGVsYXk7IC8qIGRlbGF5IHRocm8gcnggYnVmZmVyIHRpbWVzbG90cyAq LworICAgICAgICB1bnNpZ25lZCBpbnQgICBmcmFtaW5nRXJyb3JDb3VudDsgLyogZnJhbWluZyBl cnJvcnMgKi8KKyAgICAgICAgdW5zaWduZWQgaW50ICAgY29kZVZpb2xhdGlvbkNvdW50OyAvKiBj b2RlIHZpb2xhdGlvbnMgKi8KKyAgICAgICAgdW5zaWduZWQgaW50ICAgY3JjRXJyb3JDb3VudDsg ICAvKiBDUkMgZXJyb3JzICovCisgICAgICAgIGludCAgICAgICAgICAgIGxpbmVBdHRlbnVhdGlv bjsgLyogaW4gZEIqLworICAgICAgICB1bnNpZ25lZCBzaG9ydCBsb3NzT2ZTaWduYWw7CisgICAg ICAgIHVuc2lnbmVkIHNob3J0IHJlY2VpdmVSZW1vdGVBbGFybTsKKyAgICAgICAgdW5zaWduZWQg c2hvcnQgYWxhcm1JbmRpY2F0aW9uU2lnbmFsOwogfTsKIAogLyogInZhbGlkIiBiaXRtYXNrICov CkBAIC0xMzEsMTMgKzE2MiwyMyBAQAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAqLwogI2RlZmluZSBGU1RWQUxfUFJPVE8gICAgMHgwMDAwMDIwMCAgICAgIC8qIHBy b3RvICovCiAjZGVmaW5lIEZTVFZBTF9NT0RFICAgICAweDAwMDAwNDAwICAgICAgLyogY2FyZE1v ZGUgKi8KKyNkZWZpbmUgRlNUVkFMX1BIQVNFICAgIDB4MDAwMDA4MDAgICAgICAvKiBDbG9jayBw aGFzZSAqLworI2RlZmluZSBGU1RWQUxfVEUxICAgICAgMHgwMDAwMTAwMCAgICAgIC8qIFQxRTEg Q29uZmlndXJhdGlvbiAqLwogI2RlZmluZSBGU1RWQUxfREVCVUcgICAgMHg4MDAwMDAwMCAgICAg IC8qIGRlYnVnICovCi0jZGVmaW5lIEZTVFZBTF9BTEwgICAgICAweDAwMDAwN0ZGICAgICAgLyog Tm90ZTogZG9lcyBub3QgaW5jbHVkZSBERUJVRyBmbGFnICovCisjZGVmaW5lIEZTVFZBTF9BTEwg ICAgICAweDAwMDAxRkZGICAgICAgLyogTm90ZTogZG9lcyBub3QgaW5jbHVkZSBERUJVRyBmbGFn ICovCiAKIC8qICJ0eXBlIiAqLwogI2RlZmluZSBGU1RfVFlQRV9OT05FICAgMCAgICAgICAgICAg ICAgIC8qIFByb2JhYmx5IHNob3VsZCBuZXZlciBoYXBwZW4gKi8KICNkZWZpbmUgRlNUX1RZUEVf VDJQICAgIDEgICAgICAgICAgICAgICAvKiBUMlAgWDIxIDIgcG9ydCBjYXJkICovCiAjZGVmaW5l IEZTVF9UWVBFX1Q0UCAgICAyICAgICAgICAgICAgICAgLyogVDRQIFgyMSA0IHBvcnQgY2FyZCAq LworI2RlZmluZSBGU1RfVFlQRV9UMVUgICAgMyAgICAgICAgICAgICAgIC8qIFQxVSBYMjEgMSBw b3J0IGNhcmQgKi8KKyNkZWZpbmUgRlNUX1RZUEVfVDJVICAgIDQgICAgICAgICAgICAgICAvKiBU MlUgWDIxIDIgcG9ydCBjYXJkICovCisjZGVmaW5lIEZTVF9UWVBFX1Q0VSAgICA1ICAgICAgICAg ICAgICAgLyogVDRVIFgyMSA0IHBvcnQgY2FyZCAqLworI2RlZmluZSBGU1RfVFlQRV9URTEgICAg NiAgICAgICAgICAgICAgIC8qIFQxRTEgWDIxIDEgcG9ydCBjYXJkICovCisKKy8qICJmYW1pbHki ICovCisjZGVmaW5lIEZTVF9GQU1JTFlfVFhQICAwICAgICAgICAgICAgICAgLyogVDJQIG9yIFQ0 UCAqLworI2RlZmluZSBGU1RfRkFNSUxZX1RYVSAgMSAgICAgICAgICAgICAgIC8qIFQxVSBvciBU MlUgb3IgVDRVICovCiAKIC8qICJzdGF0ZSIgKi8KICNkZWZpbmUgRlNUX1VOSU5JVCAgICAgIDAg ICAgICAgICAgICAgICAvKiBSYXcgdW5pbml0aWFsaXNlZCBzdGF0ZSBmb2xsb3dpbmcKQEAgLTE1 NSw2ICsxOTYsMTAgQEAKICNkZWZpbmUgVjI0ICAgICAgICAgICAgIDEKICNkZWZpbmUgWDIxICAg ICAgICAgICAgIDIKICNkZWZpbmUgVjM1ICAgICAgICAgICAgIDMKKyNkZWZpbmUgWDIxRCAgICAg ICAgICAgIDQKKyNkZWZpbmUgVDEgICAgICAgICAgICAgIDUKKyNkZWZpbmUgRTEgICAgICAgICAg ICAgIDYKKyNkZWZpbmUgSjEgICAgICAgICAgICAgIDcKIAogLyogInByb3RvIiAqLwogI2RlZmlu ZSBGU1RfSERMQyAgICAgICAgMSAgICAgICAgICAgICAgIC8qIENpc2NvIGNvbXBhdGlibGUgSERM QyAqLwpAQCAtMTg3LDYgKzIzMiw5NyBAQAogLyogImNhcmRNb2RlIiBiaXRtYXNrICovCiAjZGVm aW5lIENBUkRfTU9ERV9JREVOVElGWSAgICAgIDB4MDAwMQogCisvKiAKKyAqIENvbnN0YW50cyBm b3IgVDEvRTEgY29uZmlndXJhdGlvbgorICovCisKKy8qCisgKiBDbG9jayBzb3VyY2UKKyAqLwor I2RlZmluZSBDTE9DS0lOR19TTEFWRSAgICAgICAwCisjZGVmaW5lIENMT0NLSU5HX01BU1RFUiAg ICAgIDEKKworLyoKKyAqIEZyYW1pbmcKKyAqLworI2RlZmluZSBGUkFNSU5HX0UxICAgICAgICAg ICAwCisjZGVmaW5lIEZSQU1JTkdfSjEgICAgICAgICAgIDEKKyNkZWZpbmUgRlJBTUlOR19UMSAg ICAgICAgICAgMgorCisvKgorICogU3RydWN0dXJlCisgKi8KKyNkZWZpbmUgU1RSVUNUVVJFX1VO RlJBTUVEICAgMAorI2RlZmluZSBTVFJVQ1RVUkVfRTFfRE9VQkxFICAxCisjZGVmaW5lIFNUUlVD VFVSRV9FMV9DUkM0ICAgIDIKKyNkZWZpbmUgU1RSVUNUVVJFX0UxX0NSQzRNICAgMworI2RlZmlu ZSBTVFJVQ1RVUkVfVDFfNCAgICAgICA0CisjZGVmaW5lIFNUUlVDVFVSRV9UMV8xMiAgICAgIDUK KyNkZWZpbmUgU1RSVUNUVVJFX1QxXzI0ICAgICAgNgorI2RlZmluZSBTVFJVQ1RVUkVfVDFfNzIg ICAgICA3CisKKy8qCisgKiBJbnRlcmZhY2UKKyAqLworI2RlZmluZSBJTlRFUkZBQ0VfUko0OEMg ICAgICAwCisjZGVmaW5lIElOVEVSRkFDRV9CTkMgICAgICAgIDEKKworLyoKKyAqIENvZGluZwor ICovCisKKyNkZWZpbmUgQ09ESU5HX0hEQjMgICAgICAgICAgMAorI2RlZmluZSBDT0RJTkdfTlJa ICAgICAgICAgICAxCisjZGVmaW5lIENPRElOR19DTUkgICAgICAgICAgIDIKKyNkZWZpbmUgQ09E SU5HX0NNSV9IREIzICAgICAgMworI2RlZmluZSBDT0RJTkdfQ01JX0I4WlMgICAgICA0CisjZGVm aW5lIENPRElOR19BTUkgICAgICAgICAgIDUKKyNkZWZpbmUgQ09ESU5HX0FNSV9aQ1MgICAgICAg NgorI2RlZmluZSBDT0RJTkdfQjhaUyAgICAgICAgICA3CisKKy8qCisgKiBMaW5lIEJ1aWxkIE91 dAorICovCisjZGVmaW5lIExCT18wZEIgICAgICAgICAgICAgIDAKKyNkZWZpbmUgTEJPXzdkQjUg ICAgICAgICAgICAgMQorI2RlZmluZSBMQk9fMTVkQiAgICAgICAgICAgICAyCisjZGVmaW5lIExC T18yMmRCNSAgICAgICAgICAgIDMKKworLyoKKyAqIFJhbmdlIGZvciBsb25nIGhhdWwgdDEgPiA2 NTVmdAorICovCisjZGVmaW5lIFJBTkdFXzBfMTMzX0ZUICAgICAgIDAKKyNkZWZpbmUgUkFOR0Vf MF80MF9NICAgICAgICAgUkFOR0VfMF8xMzNfRlQKKyNkZWZpbmUgUkFOR0VfMTMzXzI2Nl9GVCAg ICAgMQorI2RlZmluZSBSQU5HRV80MF84MV9NICAgICAgICBSQU5HRV8xMzNfMjY2X0ZUCisjZGVm aW5lIFJBTkdFXzI2Nl8zOTlfRlQgICAgIDIKKyNkZWZpbmUgUkFOR0VfODFfMTIyX00gICAgICAg UkFOR0VfMjY2XzM5OV9GVAorI2RlZmluZSBSQU5HRV8zOTlfNTMzX0ZUICAgICAzCisjZGVmaW5l IFJBTkdFXzEyMl8xNjJfTSAgICAgICBSQU5HRV8zOTlfNTMzX0ZUCisjZGVmaW5lIFJBTkdFXzUz M182NTVfRlQgICAgIDQKKyNkZWZpbmUgUkFOR0VfMTYyXzIwMF9NICAgICAgUkFOR0VfNTMzXzY1 NV9GVAorLyoKKyAqIFJlY2VpdmUgRXF1YWxpc2VyCisgKi8KKyNkZWZpbmUgRVFVQUxJWkVSX1NI T1JUICAgICAgMAorI2RlZmluZSBFUVVBTElaRVJfTE9ORyAgICAgICAxCisKKy8qCisgKiBMb29w IG1vZGVzCisgKi8KKyNkZWZpbmUgTE9PUF9OT05FICAgICAgICAgICAgMAorI2RlZmluZSBMT09Q X0xPQ0FMICAgICAgICAgICAxCisjZGVmaW5lIExPT1BfUEFZTE9BRF9FWENfVFMwIDIKKyNkZWZp bmUgTE9PUF9QQVlMT0FEX0lOQ19UUzAgMworI2RlZmluZSBMT09QX1JFTU9URSAgICAgICAgICA0 CisKKy8qCisgKiBCdWZmZXIgbW9kZXMKKyAqLworI2RlZmluZSBCVUZGRVJfMl9GUkFNRSAgICAg ICAwCisjZGVmaW5lIEJVRkZFUl8xX0ZSQU1FICAgICAgIDEKKyNkZWZpbmUgQlVGRkVSXzk2X0JJ VCAgICAgICAgMgorI2RlZmluZSBCVUZGRVJfTk9ORSAgICAgICAgICAzCiAKIC8qICAgICAgRGVi dWcgc3VwcG9ydAogICoKZGlmZiAtdXJOIGxpbnV4LTIuNC4yNy1wcmUxL2luY2x1ZGUvbGludXgv aWYuaCBsaW51eC0yLjQuMjctcHJlMS1uZXcvaW5jbHVkZS9saW51eC9pZi5oCi0tLSBsaW51eC0y LjQuMjctcHJlMS9pbmNsdWRlL2xpbnV4L2lmLmgJMjAwMy0xMS0yOCAxODoyNjoyMS4wMDAwMDAw MDAgKzAwMDAKKysrIGxpbnV4LTIuNC4yNy1wcmUxLW5ldy9pbmNsdWRlL2xpbnV4L2lmLmgJMjAw NC0wNC0yNiAxNzowNToxMy4wMDAwMDAwMDAgKzAxMDAKQEAgLTYyLDYgKzYyLDcgQEAKICNkZWZp bmUgSUZfSUZBQ0VfVDEJMHgxMDAzCQkvKiBUMSB0ZWxjbyBzZXJpYWwgaW50ZXJmYWNlCSovCiAj ZGVmaW5lIElGX0lGQUNFX0UxCTB4MTAwNAkJLyogRTEgdGVsY28gc2VyaWFsIGludGVyZmFjZQkq LwogI2RlZmluZSBJRl9JRkFDRV9TWU5DX1NFUklBTCAweDEwMDUJLyogY2FuJ3QgYmUgc2V0IGJ5 IHNvZnR3YXJlCSovCisjZGVmaW5lIElGX0lGQUNFX1gyMUQgICAweDEwMDYgICAgICAgICAgLyog WC4yMSBEdWFsIENsb2NraW5nIChGYXJTaXRlKSAqLwogCiAvKiBGb3IgZGVmaW5pdGlvbnMgc2Vl IGhkbGMuaCAqLwogI2RlZmluZSBJRl9QUk9UT19IRExDCTB4MjAwMAkJLyogcmF3IEhETEMgcHJv dG9jb2wJCSovCkBAIC03Niw2ICs3Nyw3IEBACiAjZGVmaW5lIElGX1BST1RPX0ZSX0RFTF9FVEhf UFZDIDB4MjAwOQkvKiAgRGVsZXRlIEZSIEV0aGVybmV0LWJyaWRnZWQgUFZDICovCiAjZGVmaW5l IElGX1BST1RPX0ZSX1BWQwkweDIwMEEJCS8qIGZvciByZWFkaW5nIFBWQyBzdGF0dXMJKi8KICNk ZWZpbmUgSUZfUFJPVE9fRlJfRVRIX1BWQyAweDIwMEIKKyNkZWZpbmUgSUZfUFJPVE9fUkFXICAg IDB4MjAwQyAgICAgICAgICAvKiBSQVcgU29ja2V0ICAgICAgICAgICAgICAgICAgICovCiAKIAog LyoKZGlmZiAtdXJOIGxpbnV4LTIuNC4yNy1wcmUxL2luY2x1ZGUvbGludXgvcGNpX2lkcy5oIGxp bnV4LTIuNC4yNy1wcmUxLW5ldy9pbmNsdWRlL2xpbnV4L3BjaV9pZHMuaAotLS0gbGludXgtMi40 LjI3LXByZTEvaW5jbHVkZS9saW51eC9wY2lfaWRzLmgJMjAwNC0wNC0xNCAxNDowNTo0MC4wMDAw MDAwMDAgKzAxMDAKKysrIGxpbnV4LTIuNC4yNy1wcmUxLW5ldy9pbmNsdWRlL2xpbnV4L3BjaV9p ZHMuaAkyMDA0LTA0LTI2IDE3OjAwOjQ4LjAwMDAwMDAwMCArMDEwMApAQCAtMTcxMSw2ICsxNzEx LDE1IEBACiAjZGVmaW5lIFBDSV9WRU5ET1JfSURfUERDCQkweDE1ZTkKICNkZWZpbmUgUENJX0RF VklDRV9JRF9QRENfQURNQTEwMAkweDE4NDEKIAorI2RlZmluZSBQQ0lfVkVORE9SX0lEX0ZBUlNJ VEUgICAgICAgICAgIDB4MTYxOQorI2RlZmluZSBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVDJQICAg ICAgIDB4MDQwMAorI2RlZmluZSBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVDRQICAgICAgIDB4MDQ0 MAorI2RlZmluZSBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVDFVICAgICAgIDB4MDYxMAorI2RlZmlu ZSBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVDJVICAgICAgIDB4MDYyMAorI2RlZmluZSBQQ0lfREVW SUNFX0lEX0ZBUlNJVEVfVDRVICAgICAgIDB4MDY0MAorI2RlZmluZSBQQ0lfREVWSUNFX0lEX0ZB UlNJVEVfVEUxICAgICAgIDB4MTYxMAorI2RlZmluZSBQQ0lfREVWSUNFX0lEX0ZBUlNJVEVfVEUx QyAgICAgIDB4MTYxMgorCiAjZGVmaW5lIFBDSV9WRU5ET1JfSURfQUxUSU1BCQkweDE3M2IKICNk ZWZpbmUgUENJX0RFVklDRV9JRF9BTFRJTUFfQUMxMDAwCTB4MDNlOAogI2RlZmluZSBQQ0lfREVW SUNFX0lEX0FMVElNQV9BQzEwMDEJMHgwM2U5Cg== ------_=_NextPart_001_01C42BAC.3CBC71C8-- From akpm@osdl.org Tue Apr 27 03:23:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 03:23:28 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RANOKO016175 for ; Tue, 27 Apr 2004 03:23:24 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i3RANI217347 for ; Tue, 27 Apr 2004 03:23:18 -0700 Date: Tue, 27 Apr 2004 03:23:02 -0700 From: Andrew Morton To: netdev@oss.sgi.com Subject: Fw: [Bugme-new] [Bug 2602] New: ping with ipsec enviroment causes oops Message-Id: <20040427032302.60e42493.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4942 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: 3051 Lines: 90 Begin forwarded message: Date: Tue, 27 Apr 2004 03:18:19 -0700 From: bugme-daemon@osdl.org To: bugme-new@lists.osdl.org Subject: [Bugme-new] [Bug 2602] New: ping with ipsec enviroment causes oops http://bugme.osdl.org/show_bug.cgi?id=2602 Summary: ping with ipsec enviroment causes oops Kernel Version: 2.6.5 vanilla Status: NEW Severity: blocking Owner: niv@us.ibm.com Submitter: bug@bertera.it Distribution: Debian Woody 3.0 Hardware Environment: # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 532.648 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1046.52 # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a) 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50) 00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) 00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) Software Environment: kame tools for ipsec (backport from sid) Problem Description: I tried to build manual tunnel with manual keying. My ipsec.conf file: flush; spdflush; add 192.168.101.104 192.168.101.54 esp 0x201 -m tunnel -E 3des-cbc 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; add 192.168.101.54 192.168.101.104 esp 0x301 -m tunnel -E 3des-cbc 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df; spdadd 192.168.101.104/32 192.168.101.54/32 any -P in ipsec esp/tunnel/192.168.101.104-192.168.101.54/require; spdadd 192.168.101.54/32 192.168.101.104/32 any -P out ipsec esp/tunnel/192.168.101.104-192.168.101.54/require; Then ping 192.168.101.54 crashes the pinged machine. Oops not available. Steps to reproduce: Build an IPSec tunnel and ping the remote machine. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From okir@suse.de Tue Apr 27 09:17:34 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 09:17:39 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RGHMKO002027 for ; Tue, 27 Apr 2004 09:17:23 -0700 Received: from hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 8C69A4ED838 for ; Tue, 27 Apr 2004 17:35:09 +0200 (CEST) Date: Tue, 27 Apr 2004 17:35:09 +0200 From: Olaf Kirch To: netdev@oss.sgi.com Subject: [PATCH] 2.6: allow CONFIG_NETFILTER=n and CONFIG_XFRM=y Message-ID: <20040427153509.GD6836@suse.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.4i X-archive-position: 4943 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: okir@suse.de Precedence: bulk X-list: netdev Content-Length: 936 Lines: 37 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, the following patch should fix a compile error when setting CONFIG_NETFILTER=n and CONFIG_XFRM=y. Cheers, Olaf -- Olaf Kirch | The Hardware Gods hate me. okir@suse.de | ---------------+ --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=netfilter-config This patch makes sure the kernel can be compiled with CONFIG_XFRM=y and CONFIG_NETFILTER off. --- linux-2.6.5/include/linux/netfilter_ipv4.h.dbg 2004-04-27 13:00:55.000000000 +0200 +++ linux-2.6.5/include/linux/netfilter_ipv4.h 2004-04-27 13:15:24.000000000 +0200 @@ -86,7 +86,7 @@ extern int skb_ip_make_writable(struct sk_buff **pskb, unsigned int writable_len); -#ifdef CONFIG_XFRM +#if defined(CONFIG_XFRM) && defined(CONFIG_NETFILTER) #include #include --HlL+5n6rz5pIUxbD-- From rddunlap@osdl.org Tue Apr 27 10:44:49 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 10:44:55 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RHinKO005666 for ; Tue, 27 Apr 2004 10:44:49 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3RHih224712; Tue, 27 Apr 2004 10:44:43 -0700 Date: Tue, 27 Apr 2004 10:38:07 -0700 From: "Randy.Dunlap" To: netdev Cc: jgarzik , ollie@sis.com.tw Subject: [janitor] sis900: don't use yield() Message-Id: <20040427103807.311caa42.rddunlap@osdl.org> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4944 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 884 Lines: 29 From: maximilian attems thanks to Felipe W Damasio hint rediffed. patch is on top of linux-2.6.6-rc2 yield() removes process from active array into expired array, better just yield the CPU for a bit. tested on my laptop with a sis900. a++ maks Index: linux-266-rc2-kj1/drivers/net/sis900.c =================================================================== --- linux-266-rc2-kj1.orig/drivers/net/sis900.c 2004-04-03 19:36:57.000000000 -0800 +++ linux-266-rc2-kj1/drivers/net/sis900.c 2004-04-21 15:32:56.000000000 -0700 @@ -600,7 +600,8 @@ static int __init sis900_mii_probe (stru if(status & MII_STAT_LINK){ while (poll_bit) { - yield(); + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(HZ/100); poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { -- From rddunlap@osdl.org Tue Apr 27 11:37:18 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 11:37:23 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RIbHKO008273 for ; Tue, 27 Apr 2004 11:37:18 -0700 Received: from dragon.pdx.osdl.net (dragon.pdx.osdl.net [172.20.1.27]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3RIZ5204045; Tue, 27 Apr 2004 11:35:05 -0700 Date: Tue, 27 Apr 2004 11:28:29 -0700 From: "Randy.Dunlap" To: Jeff Garzik Cc: netdev@oss.sgi.com, ollie@sis.com.tw Subject: [janitor] sis900: don't use yield() (v2) Message-Id: <20040427112829.7c5a260a.rddunlap@osdl.org> In-Reply-To: <408EA079.3060604@pobox.com> References: <20040427103807.311caa42.rddunlap@osdl.org> <408EA079.3060604@pobox.com> Organization: OSDL X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: +5V?h'hZQPB9kW Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4945 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: rddunlap@osdl.org Precedence: bulk X-list: netdev Content-Length: 1195 Lines: 40 On Tue, 27 Apr 2004 14:03:37 -0400 Jeff Garzik wrote: | I would rather do schedule_timeout(1), as that's IMO closer to the | intention... From: maximilian attems Subject: [Kernel-janitors] [patch] use schedule_timeout() instead of yield() drivers/net/sis900.c thanks to Felipe W Damasio hint rediffed. patch is on top of linux-2.6.6-rc2 yield() removes process from active array into expired array, better just yield the CPU for a bit. tested on my laptop with a sis900. drivers/net/sis900.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) Index: linux-266-rc2-kj1/drivers/net/sis900.c =================================================================== --- linux-266-rc2-kj1.orig/drivers/net/sis900.c 2004-04-03 19:36:57.000000000 -0800 +++ linux-266-rc2-kj1/drivers/net/sis900.c 2004-04-21 15:32:56.000000000 -0700 @@ -600,7 +600,8 @@ static int __init sis900_mii_probe (stru if(status & MII_STAT_LINK){ while (poll_bit) { - yield(); + set_current_state(TASK_UNINTERRUPTIBLE); + schedule_timeout(1); poll_bit ^= (mdio_read(net_dev, sis_priv->cur_phy, MII_STATUS) & poll_bit); if (time_after_eq(jiffies, timeout)) { -- From willy@w.ods.org Tue Apr 27 12:01:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 12:01:51 -0700 (PDT) Received: from willy.net1.nerim.net (willy.net1.nerim.net [62.212.114.60]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RJ1iKO009501 for ; Tue, 27 Apr 2004 12:01:45 -0700 Date: Tue, 27 Apr 2004 20:57:29 +0200 From: Willy Tarreau To: Parag Nemade Cc: kernerl mail , netdev@oss.sgi.com, linux-net@vger.kernel.org, netfilter Subject: Re: HELP ipt_hook: happy cracking message Message-ID: <20040427185729.GA29913@alpha.home.local> References: <20040426151220.85059.qmail@web41403.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040426151220.85059.qmail@web41403.mail.yahoo.com> User-Agent: Mutt/1.4i X-archive-position: 4946 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: willy@w.ods.org Precedence: bulk X-list: netdev Content-Length: 865 Lines: 25 On Mon, Apr 26, 2004 at 08:12:20AM -0700, Parag Nemade wrote: > hi, > i modified kernel so that it will create > /proc/net/myproc file entry. > the function of this entry is to crate a 16 byte char > string from random no.s > i used net_srandom and net_random and sys_time for > that puspose. the problem is that i write program to > generate string after 120 seconds but it is changing > contents of myproc file every seconds. what can i do? may be you're sleeping for 120 instead of 120*HZ, which means you're really sleeping 1.2s on x86. > Also i am getting ipt_hook: happy cracking. message > again and again why? iptable_mangle.c comment reads 'root is playing with raw sockets' above this message. It means that you're sending too short IP packets (len < 20 bytes) or packets with the IHL field < 5. It's just a harmless message. Regards, Willy From kaber@trash.net Tue Apr 27 14:34:22 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 14:34:26 -0700 (PDT) Received: from gw.localnet (port-195-158-170-17.dynamic.qsc.de [195.158.170.17]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RLYLKO019346 for ; Tue, 27 Apr 2004 14:34:22 -0700 Received: from ws.localnet ([192.168.0.23] helo=trash.net ident=kaber) by gw.localnet with esmtp (Exim 3.36 #1 (Debian)) id 1BIZuM-0002L7-00; Tue, 27 Apr 2004 23:14:26 +0200 Message-ID: <408ED1E9.6060502@trash.net> Date: Tue, 27 Apr 2004 23:34:33 +0200 From: Patrick McHardy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Olaf Kirch CC: netdev@oss.sgi.com Subject: Re: [PATCH] 2.6: allow CONFIG_NETFILTER=n and CONFIG_XFRM=y References: <20040427153509.GD6836@suse.de> In-Reply-To: <20040427153509.GD6836@suse.de> X-Enigmail-Version: 0.83.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4947 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: kaber@trash.net Precedence: bulk X-list: netdev Olaf Kirch wrote: > Hi, > > the following patch should fix a compile error when setting > CONFIG_NETFILTER=n and CONFIG_XFRM=y. This error comes from one of my netfilter+ipsec patches, which are not in mainline yet. I'll add your fix, thanks. Regards Patrick > > Cheers, > Olaf > > > ------------------------------------------------------------------------ > > This patch makes sure the kernel can be compiled with CONFIG_XFRM=y and > CONFIG_NETFILTER off. > > --- linux-2.6.5/include/linux/netfilter_ipv4.h.dbg 2004-04-27 13:00:55.000000000 +0200 > +++ linux-2.6.5/include/linux/netfilter_ipv4.h 2004-04-27 13:15:24.000000000 +0200 > @@ -86,7 +86,7 @@ > extern int skb_ip_make_writable(struct sk_buff **pskb, > unsigned int writable_len); > > -#ifdef CONFIG_XFRM > +#if defined(CONFIG_XFRM) && defined(CONFIG_NETFILTER) > #include > #include > From shemminger@osdl.org Tue Apr 27 16:04:44 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 16:04:49 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RN4gKO021027 for ; Tue, 27 Apr 2004 16:04:44 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3RN4S215643; Tue, 27 Apr 2004 16:04:28 -0700 Date: Tue, 27 Apr 2004 16:04:28 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] tcp_send_skb code pruning Message-Id: <20040427160428.0196fcf3@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4948 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: shemminger@osdl.org Precedence: bulk X-list: netdev The function tcp_send_skb is only called from tcp_fin, and is always called with force_queue=1. Therefore, it no longer needs to be global and the code to send right now can be removed. Because it always queues, change the name as well, and fix up the comment. diff -Nru a/include/net/tcp.h b/include/net/tcp.h --- a/include/net/tcp.h Tue Apr 27 14:37:03 2004 +++ b/include/net/tcp.h Tue Apr 27 14:37:03 2004 @@ -948,7 +948,6 @@ extern void tcp_send_active_reset(struct sock *sk, int priority); extern int tcp_send_synack(struct sock *); extern int tcp_transmit_skb(struct sock *, struct sk_buff *); -extern void tcp_send_skb(struct sock *, struct sk_buff *, int force_queue, unsigned mss_now); extern void tcp_push_one(struct sock *, unsigned mss_now); extern void tcp_send_ack(struct sock *sk); extern void tcp_send_delayed_ack(struct sock *sk); diff -Nru a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c --- a/net/ipv4/tcp_output.c Tue Apr 27 14:37:03 2004 +++ b/net/ipv4/tcp_output.c Tue Apr 27 14:37:03 2004 @@ -314,13 +314,12 @@ } -/* This is the main buffer sending routine. We queue the buffer - * and decide whether to queue or transmit now. +/* This routine just queue's the buffer * * NOTE: probe0 timer is not checked, do not forget tcp_push_pending_frames, * otherwise socket can stall. */ -void tcp_send_skb(struct sock *sk, struct sk_buff *skb, int force_queue, unsigned cur_mss) +static void tcp_queue_skb(struct sock *sk, struct sk_buff *skb) { struct tcp_opt *tp = tcp_sk(sk); @@ -329,17 +328,6 @@ __skb_queue_tail(&sk->sk_write_queue, skb); tcp_charge_skb(sk, skb); - if (!force_queue && tp->send_head == NULL && tcp_snd_test(tp, skb, cur_mss, tp->nonagle)) { - /* Send it out now. */ - TCP_SKB_CB(skb)->when = tcp_time_stamp; - if (!tcp_transmit_skb(sk, skb_clone(skb, sk->sk_allocation))) { - tp->snd_nxt = TCP_SKB_CB(skb)->end_seq; - tcp_minshall_update(tp, cur_mss, skb); - if (tp->packets_out++ == 0) - tcp_reset_xmit_timer(sk, TCP_TIME_RETRANS, tp->rto); - return; - } - } /* Queue it, remembering where we must start sending. */ if (tp->send_head == NULL) tp->send_head = skb; @@ -1120,10 +1108,10 @@ TCP_SKB_CB(skb)->flags = (TCPCB_FLAG_ACK | TCPCB_FLAG_FIN); TCP_SKB_CB(skb)->sacked = 0; - /* FIN eats a sequence byte, write_seq advanced by tcp_send_skb(). */ + /* FIN eats a sequence byte, write_seq advanced by tcp_queue_skb(). */ TCP_SKB_CB(skb)->seq = tp->write_seq; TCP_SKB_CB(skb)->end_seq = TCP_SKB_CB(skb)->seq + 1; - tcp_send_skb(sk, skb, 1, mss_now); + tcp_queue_skb(sk, skb); } __tcp_push_pending_frames(sk, tp, mss_now, TCP_NAGLE_OFF); } From jmoyer@redhat.com Tue Apr 27 19:03:41 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 19:03:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S23cKO027925 for ; Tue, 27 Apr 2004 19:03:41 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3S23cKG004691; Tue, 27 Apr 2004 22:03:38 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3S23bv31557; Tue, 27 Apr 2004 22:03:37 -0400 Received: from segfault.boston.redhat.com (segfault.boston.redhat.com [172.16.65.93]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id i3S23aew028511; Tue, 27 Apr 2004 22:03:36 -0400 Received: from segfault.boston.redhat.com (localhost.localdomain [127.0.0.1]) by segfault.boston.redhat.com (8.12.10/8.12.10) with ESMTP id i3S22B7Y002731; Tue, 27 Apr 2004 22:02:11 -0400 Received: (from jmoyer@localhost) by segfault.boston.redhat.com (8.12.10/8.12.10/Submit) id i3S22Bm8002727; Tue, 27 Apr 2004 22:02:11 -0400 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16527.4259.174536.629347@segfault.boston.redhat.com> Date: Tue, 27 Apr 2004 22:02:11 -0400 To: Carson Gaspar Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc In-Reply-To: <382320000.1082759593@taltos.ny.ficc.gs.com> References: <382320000.1082759593@taltos.ny.ficc.gs.com> X-Mailer: VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? X-archive-position: 4949 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jmoyer@redhat.com Precedence: bulk X-list: netdev >FYI, we see the exact same panic with the tg3 driver using 2.4.25 and >distcc with sendfile(). The bcm5700 driver also panics, but I haven't >captured a panic message to be certain it's the same bug. >kernel BUG at page_alloc.c:98! Andrea fixed this in his tree by deferring the page free to process context instead of BUG()ing on PageLRU(page). -Jeff From davem@redhat.com Tue Apr 27 20:31:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 20:31:06 -0700 (PDT) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S3V1KO001342 for ; Tue, 27 Apr 2004 20:31:02 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx2.redhat.com (8.12.10/8.12.10) with ESMTP id i3S3UFxF019410; Tue, 27 Apr 2004 23:30:15 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3S3Uwv12800; Tue, 27 Apr 2004 23:30:58 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3S3UtKv027951; Tue, 27 Apr 2004 23:30:56 -0400 Date: Tue, 27 Apr 2004 20:29:57 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] tcp_send_skb code pruning Message-Id: <20040427202957.058da584.davem@redhat.com> In-Reply-To: <20040427160428.0196fcf3@dell_ss3.pdx.osdl.net> References: <20040427160428.0196fcf3@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4950 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Tue, 27 Apr 2004 16:04:28 -0700 Stephen Hemminger wrote: > The function tcp_send_skb is only called from tcp_fin, and is always called > with force_queue=1. Therefore, it no longer needs to be global and the code > to send right now can be removed. Because it always queues, change the > name as well, and fix up the comment. Nice cleanup, applied. From dax@gurulabs.com Tue Apr 27 23:37:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 23:37:49 -0700 (PDT) Received: from mail.gurulabs.com ([66.62.77.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S6bhKO008706 for ; Tue, 27 Apr 2004 23:37:43 -0700 Received: from [10.200.1.22] (dax-laptop-home.gurulabs.com [10.200.1.22]) by mail.gurulabs.com (Postfix) with ESMTP id 0E81877AC; Tue, 27 Apr 2004 23:37:20 -0600 (MDT) Subject: 2.6.5, IPSec, NAT funnies From: Dax Kelson To: linux-net@vger.kernel.org Cc: netdev@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain Message-Id: <1083133394.2817.40.camel@mentor.gurulabs.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-1) Date: Wed, 28 Apr 2004 00:38:42 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 4951 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dax@gurulabs.com Precedence: bulk X-list: netdev I have a 2.6 box doing IPSec and MASQUERADing that is borking up TCP port numbers of . /======IPSec ESP SA=====\ [box1]-----------[fw1]-------Internet-------[fw2]-----------[box2] | / \ / \ | .5 10.1.0.1 StaticRealIP DHCPRealIP 10.200.1.1 .22 fw1 = RHEL3 with latest official errata kernel (2.4+2.6ipsec) fw2 = Debian Sarge with 2.6.5-2 kernel from unstable IKE daemon is identical on both boxes -- current OpenSWAN CVS fw1 is SNATing the internal 10.1.0.0/16 network fw2 is MASQUERADing the internal 10.200.1.0/24 network iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE box2 sends a SYN packet to box1. It arrives OK at box1. source TCP port 33763, destination TCP port 3389 So far so good. box1 sends back a SYN/ACK with TCP source port 3389 destination 32834. It leaves fw1 and arrives at fw2 on the external interface (eth0) and gets decrypted OK and unmodified. Here is the problem. When the SYN/ACK packet leaves fw2 out eth1 towards box2 the TCP source port has changed from the correct 3389 to the incorrect 1024. Box2 naturally sends back an ICMP error message--handshake never completes. Packet capture details courtesy of tethereal... arriving and being decrypted on the fw2 external interface (eth0): 0.078883 a.b.c.d -> w.x.y.z ESP ESP (SPI=0x3bb63b4f) 0.078883 10.1.0.5 -> 10.200.1.22 TCP 3389 > 32834 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 leaving the fw2 internal interface (eth1) now borked with the source port changed to 1024: /-- error here 0.229413 10.1.0.5 -> 10.200.1.22 TCP 1024 > 32834 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 If I flush the nat table on fw2 then the borkage disappears and the TCP connection is properly established. The fw2 nat rule is simply this: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Another data point. TCP connections from fw2 itself into the remote network are fine. Dax Kelson Guru Labs From a.kasparas@gmc.lt Tue Apr 27 23:55:35 2004 Received: with ECARTIS (v1.0.0; list netdev); Tue, 27 Apr 2004 23:55:40 -0700 (PDT) Received: from otc.ortopedija.lt (esc.ortopedija.lt [213.190.36.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S6tXKO009503 for ; Tue, 27 Apr 2004 23:55:35 -0700 Received: from host-83 ([10.0.0.83] helo=gmc.lt) by otc.ortopedija.lt with esmtp (Exim 3.36 #1 (Debian)) id 1BIjPS-0007MS-00; Wed, 28 Apr 2004 10:23:10 +0300 Message-ID: <408F5555.3080303@gmc.lt> Date: Wed, 28 Apr 2004 09:55:17 +0300 From: Aidas Kasparas User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: lt, en, ru, fr MIME-Version: 1.0 To: Dax Kelson CC: linux-net@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.5, IPSec, NAT funnies References: <1083133394.2817.40.camel@mentor.gurulabs.com> In-Reply-To: <1083133394.2817.40.camel@mentor.gurulabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4952 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: a.kasparas@gmc.lt Precedence: bulk X-list: netdev Kernel bug. IPSec changes ip headers, but fails to say about this to conntrack. More information http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215980 Patch at http://bugs.debian.org/cgi-bin/bugreport.cgi/ipsec_conntrack.diff?bug=215980&msg=3&att=1 As a workaround insert rule exemting ipsec traffic from masquerade: iptables -t nat -I POSTROUTING 1 -p esp -j ACCEPT Dax Kelson wrote: > I have a 2.6 box doing IPSec and MASQUERADing that is borking up TCP > port numbers of . > > /======IPSec ESP SA=====\ > [box1]-----------[fw1]-------Internet-------[fw2]-----------[box2] > | / \ / \ | > .5 10.1.0.1 StaticRealIP DHCPRealIP 10.200.1.1 .22 > > > fw1 = RHEL3 with latest official errata kernel (2.4+2.6ipsec) > fw2 = Debian Sarge with 2.6.5-2 kernel from unstable > > IKE daemon is identical on both boxes -- current OpenSWAN CVS > > fw1 is SNATing the internal 10.1.0.0/16 network > fw2 is MASQUERADing the internal 10.200.1.0/24 network > > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > box2 sends a SYN packet to box1. It arrives OK at box1. > > source TCP port 33763, destination TCP port 3389 > > So far so good. > > box1 sends back a SYN/ACK with TCP source port 3389 destination 32834. > It leaves fw1 and arrives at fw2 on the external interface (eth0) and > gets decrypted OK and unmodified. > > Here is the problem. > > When the SYN/ACK packet leaves fw2 out eth1 towards box2 the TCP source > port has changed from the correct 3389 to the incorrect 1024. Box2 > naturally sends back an ICMP error message--handshake never completes. > > Packet capture details courtesy of tethereal... > > arriving and being decrypted on the fw2 external interface (eth0): > > 0.078883 a.b.c.d -> w.x.y.z ESP ESP (SPI=0x3bb63b4f) > 0.078883 10.1.0.5 -> 10.200.1.22 TCP 3389 > 32834 [SYN, ACK] Seq=0 > Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 > > leaving the fw2 internal interface (eth1) now borked with the source > port changed to 1024: > /-- error here > 0.229413 10.1.0.5 -> 10.200.1.22 TCP 1024 > 32834 [SYN, ACK] Seq=0 > Ack=1 Win=65535 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 > > If I flush the nat table on fw2 then the borkage disappears and the TCP > connection is properly established. The fw2 nat rule is simply this: > > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE > > Another data point. TCP connections from fw2 itself into the remote > network are fine. > > Dax Kelson > Guru Labs > > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Aidas Kasparas IT administrator GM Consult Group, UAB From paulus@ozlabs.org Wed Apr 28 00:27:24 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 00:27:33 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S7RNKO013469 for ; Wed, 28 Apr 2004 00:27:24 -0700 Received: by ozlabs.org (Postfix, from userid 1003) id 3901C2BD43; Wed, 28 Apr 2004 17:27:17 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16527.23582.316697.56419@cargo.ozlabs.ibm.com> Date: Wed, 28 Apr 2004 17:24:14 +1000 From: Paul Mackerras To: linux-tr@linuxtr.net Cc: netdev@oss.sgi.com Subject: spin_lock_bh() called in irq handler X-Mailer: VM 7.18 under Emacs 21.3.1 X-archive-position: 4953 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: paulus@samba.org Precedence: bulk X-list: netdev We're hitting a bug with the olympic token-ring driver where the driver gets a receive interrupt and calls tr_type_trans. That calls tr_add_rif_info() which does spin_lock_bh(). On our iSeries systems that triggers a BUG() check. Which is reasonable, since using spin_lock_bh() to protect a data structure, and then calling a function that modifies that data structure within an interrupt handler, is clearly a bug. I had a look and found that all of the token-ring drivers call tr_type_trans() at interrupt level. That seems perfectly reasonable to me. To fix the bug, it seems to me that there are two options: either move the tr_add_rif_info() call elsewhere (but I have no idea where) or else use spin_lock_irqsave instead of spin_lock_bh. Which is the more appropriate fix? Thanks, Paul. From felipewd@terra.com.br Wed Apr 28 05:39:31 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 05:39:35 -0700 (PDT) Received: from chiapa.terra.com.br (chiapa.terra.com.br [200.154.55.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SCdUKO026544 for ; Wed, 28 Apr 2004 05:39:31 -0700 Received: from paramonga.terra.com.br (paramonga.terra.com.br [200.154.55.133]) by chiapa.terra.com.br (Postfix) with ESMTP id D784EEC37D; Wed, 28 Apr 2004 09:39:28 -0300 (BRT) Received: from terra.com.br (200-163-191-105.paemt7004.e.brasiltelecom.net.br [200.163.191.105]) (authenticated user felipewd) by paramonga.terra.com.br (Postfix) with ESMTP id 950743C01D; Wed, 28 Apr 2004 09:39:27 -0300 (BRT) Message-ID: <408FA6B3.1000805@terra.com.br> Date: Wed, 28 Apr 2004 09:42:27 -0300 From: Felipe W Damasio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: gmane.linux.kernel To: Andy Lutomirski Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: <20040424050931.14C341D4F@luto.stanford.edu> In-Reply-To: <20040424050931.14C341D4F@luto.stanford.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4954 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: felipewd@terra.com.br Precedence: bulk X-list: netdev Hi Andy, Andy Lutomirski wrote: > +static void rtl8169_set_speed(struct net_device *dev, > + u8 autoneg, u16 speed, u8 duplex) > +{ > + struct rtl8169_private *tp = dev->priv; > + void *ioaddr = tp->mmio_addr; > + unsigned long flags; > + u8 status; > + > + int auto_nego, giga_ctrl; > + > + spin_lock_irqsave(&tp->lock, flags); > + > + status = RTL_R8(PHYstatus); > + if ((status & TBI_Enable) && autoneg == AUTONEG_DISABLE) { > + autoneg = AUTONEG_ENABLE; > + printk(KERN_WARNING PFX > + "%s: ignoring request to force speed in TBI mode\n", > + dev->name); > + } > + > + auto_nego = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); > + auto_nego &= ~(PHY_Cap_10_Half | PHY_Cap_10_Full | > + PHY_Cap_100_Half | PHY_Cap_100_Full); > + giga_ctrl = mdio_read(ioaddr, PHY_1000_CTRL_REG); > + giga_ctrl &= ~(PHY_Cap_1000_Full | PHY_Cap_Null); > + > + if (autoneg == AUTONEG_ENABLE) { > + auto_nego |= (PHY_Cap_10_Half | PHY_Cap_10_Full | > + PHY_Cap_100_Half | PHY_Cap_100_Full); > + giga_ctrl |= PHY_Cap_1000_Full; > + } else { > + if (speed == SPEED_10) > + auto_nego |= PHY_Cap_10_Half | PHY_Cap_10_Full; > + else if (speed == SPEED_100) > + auto_nego |= PHY_Cap_100_Half | PHY_Cap_100_Full; > + > + if (speed == SPEED_1000) > + giga_ctrl |= PHY_Cap_1000_Full; > + else > + giga_ctrl |= PHY_Cap_Null; > + > + if (duplex == DUPLEX_HALF) > + auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); > + } > + > + tp->phy_auto_nego_reg = auto_nego; > + tp->phy_1000_ctrl_reg = giga_ctrl; > + > + if(!(status & TBI_Enable)) { > + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); > + mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); > + } > + > + mdio_write(ioaddr, PHY_CTRL_REG, > + PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); > + > + if (tp->if_up && (giga_ctrl & PHY_Cap_1000_Full)) > + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); > + > + spin_unlock_irqrestore(&tp->lock, flags); > +} > + I think you can use the mii's interface here.. Please look 8139cp's way of doind this. Using that interface is much cleaner and doesn't duplicate code. > +static int rtl8169_get_settings(struct net_device *dev, > + struct ethtool_cmd *cmd) > +{ > + struct rtl8169_private *tp = dev->priv; > + void *ioaddr = tp->mmio_addr; > + u8 status = RTL_R8(PHYstatus); IMHO you should hold the device lock here (tp->lock). > + cmd->supported = SUPPORTED_10baseT_Half | > + SUPPORTED_10baseT_Full | > + SUPPORTED_100baseT_Half | > + SUPPORTED_100baseT_Full | > + SUPPORTED_1000baseT_Full | > + SUPPORTED_Autoneg | > + SUPPORTED_TP; > + > + cmd->autoneg = 1; > + cmd->advertising = ADVERTISED_TP | ADVERTISED_Autoneg; > + if (tp->phy_auto_nego_reg & PHY_Cap_10_Half) > + cmd->advertising |= ADVERTISED_10baseT_Half; > + if (tp->phy_auto_nego_reg & PHY_Cap_10_Full) > + cmd->advertising |= ADVERTISED_10baseT_Full; > + if (tp->phy_auto_nego_reg & PHY_Cap_100_Half) > + cmd->advertising |= ADVERTISED_100baseT_Half; > + if (tp->phy_auto_nego_reg & PHY_Cap_100_Full) > + cmd->advertising |= ADVERTISED_100baseT_Full; > + if (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full) > + cmd->advertising |= ADVERTISED_1000baseT_Full; > + > + if (status & _1000bpsF) cmd->speed = SPEED_1000; > + else if (status & _100bps) cmd->speed = SPEED_100; > + else if (status & _10bps) cmd->speed = SPEED_10; > + > + if (status & _1000bpsF || status & FullDup) > + cmd->duplex = DUPLEX_FULL; > + else > + cmd->duplex = DUPLEX_HALF; > + > + return 0; > +} You should use mii's interface on this. There's no need to duplicate code. Please use mii_ethtool_gset here. Also rtl8169_set_settings should use mii_ethtool_sset. If the card gets a LinkChg interrupt you should treat with mii_check_media at rtl8169_set_settings. Cheers, Felipe From jgarzik@pobox.com Wed Apr 28 08:25:09 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 08:25:14 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SFP8KO010404 for ; Wed, 28 Apr 2004 08:25:09 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BIqvq-0000pm-VA; Wed, 28 Apr 2004 16:25:07 +0100 Message-ID: <408FCCC3.4050704@pobox.com> Date: Wed, 28 Apr 2004 11:24:51 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe W Damasio CC: Andy Lutomirski , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: <20040424050931.14C341D4F@luto.stanford.edu> <408FA6B3.1000805@terra.com.br> In-Reply-To: <408FA6B3.1000805@terra.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4955 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 Felipe W Damasio wrote: > Hi Andy, > > Andy Lutomirski wrote: > >> +static void rtl8169_set_speed(struct net_device *dev, >> + u8 autoneg, u16 speed, u8 duplex) >> +{ >> + struct rtl8169_private *tp = dev->priv; >> + void *ioaddr = tp->mmio_addr; >> + unsigned long flags; >> + u8 status; >> + >> + int auto_nego, giga_ctrl; >> + >> + spin_lock_irqsave(&tp->lock, flags); >> + >> + status = RTL_R8(PHYstatus); >> + if ((status & TBI_Enable) && autoneg == AUTONEG_DISABLE) { >> + autoneg = AUTONEG_ENABLE; >> + printk(KERN_WARNING PFX >> + "%s: ignoring request to force speed in TBI mode\n", >> + dev->name); >> + } >> + >> + auto_nego = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); >> + auto_nego &= ~(PHY_Cap_10_Half | PHY_Cap_10_Full | >> + PHY_Cap_100_Half | PHY_Cap_100_Full); >> + giga_ctrl = mdio_read(ioaddr, PHY_1000_CTRL_REG); >> + giga_ctrl &= ~(PHY_Cap_1000_Full | PHY_Cap_Null); >> + >> + if (autoneg == AUTONEG_ENABLE) { >> + auto_nego |= (PHY_Cap_10_Half | PHY_Cap_10_Full | >> + PHY_Cap_100_Half | PHY_Cap_100_Full); >> + giga_ctrl |= PHY_Cap_1000_Full; >> + } else { >> + if (speed == SPEED_10) >> + auto_nego |= PHY_Cap_10_Half | PHY_Cap_10_Full; >> + else if (speed == SPEED_100) >> + auto_nego |= PHY_Cap_100_Half | PHY_Cap_100_Full; >> + >> + if (speed == SPEED_1000) >> + giga_ctrl |= PHY_Cap_1000_Full; >> + else >> + giga_ctrl |= PHY_Cap_Null; >> + >> + if (duplex == DUPLEX_HALF) >> + auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); >> + } >> + >> + tp->phy_auto_nego_reg = auto_nego; >> + tp->phy_1000_ctrl_reg = giga_ctrl; >> + >> + if(!(status & TBI_Enable)) { >> + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); >> + mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); >> + } >> + >> + mdio_write(ioaddr, PHY_CTRL_REG, >> + PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); >> + >> + if (tp->if_up && (giga_ctrl & PHY_Cap_1000_Full)) >> + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); >> + >> + spin_unlock_irqrestore(&tp->lock, flags); >> +} >> + > > > I think you can use the mii's interface here.. > > Please look 8139cp's way of doind this. Using that interface is much > cleaner and doesn't duplicate code. Unfortunately mii_xxx doesn't do gigabit ethernet and GMII... Jeff From luto@myrealbox.com Wed Apr 28 08:51:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 08:51:21 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SFpFKO011251 for ; Wed, 28 Apr 2004 08:51:15 -0700 Received: from [10.0.0.2] (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i3SFp3pM001424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Apr 2004 08:51:04 -0700 Message-ID: <408FD2CB.6000102@myrealbox.com> Date: Wed, 28 Apr 2004 08:50:35 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.6b (Windows/20040426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Felipe W Damasio , Francois Romieu CC: Andy Lutomirski , netdev@oss.sgi.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection References: <20040424050931.14C341D4F@luto.stanford.edu> <408FA6B3.1000805@terra.com.br> In-Reply-To: <408FA6B3.1000805@terra.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4956 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Felipe W Damasio wrote: >> +static int rtl8169_get_settings(struct net_device *dev, >> + struct ethtool_cmd *cmd) >> +{ >> + struct rtl8169_private *tp = dev->priv; >> + void *ioaddr = tp->mmio_addr; >> + u8 status = RTL_R8(PHYstatus); > > > IMHO you should hold the device lock here (tp->lock). Why? Isn't reading the PHYstatus atomic w.r.t. writing it? I think the lock just needs to be held for writes. Oh -- there is a race if set_settings is called between the PHYstatus read and the rest of the code. I can't imagine that happening, but it wouldn't hurt to take the lock. Francois, do you want a new patch, or should I wait until you finish whatever you're doing? --Andy From romieu@fr.zoreil.com Wed Apr 28 09:52:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 09:52:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SGqhKO012730 for ; Wed, 28 Apr 2004 09:52:44 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i3SFpZuX027961; Wed, 28 Apr 2004 17:51:35 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i3SFpZDj027960; Wed, 28 Apr 2004 17:51:35 +0200 Date: Wed, 28 Apr 2004 17:51:35 +0200 From: Francois Romieu To: Andy Lutomirski Cc: Felipe W Damasio , netdev@oss.sgi.com Subject: Re: [PATCH r8169] ethtool support and sane speed selection/detection Message-ID: <20040428175135.A27651@electric-eye.fr.zoreil.com> References: <20040424050931.14C341D4F@luto.stanford.edu> <408FA6B3.1000805@terra.com.br> <408FD2CB.6000102@myrealbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <408FD2CB.6000102@myrealbox.com>; from luto@myrealbox.com on Wed, Apr 28, 2004 at 08:50:35AM -0700 X-Organisation: Land of Sunshine Inc. X-archive-position: 4957 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Andy Lutomirski : [...] > Francois, do you want a new patch, or should I wait until you finish > whatever you're doing? I have already added some locks. Btw the timer should probably be protected as well. -- Ueimor From dax@gurulabs.com Wed Apr 28 10:44:42 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 10:44:45 -0700 (PDT) Received: from mail.gurulabs.com ([66.62.77.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SHifKO014181 for ; Wed, 28 Apr 2004 10:44:41 -0700 Received: from [10.2.3.98] (dhcp98.glwlan.gurulabs.com [10.2.3.98]) by mail.gurulabs.com (Postfix) with ESMTP id B3A04780D; Wed, 28 Apr 2004 10:44:16 -0600 (MDT) Subject: Re: 2.6.5, IPSec, NAT funnies From: Dax Kelson To: Aidas Kasparas Cc: linux-net@vger.kernel.org, netdev@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <408F5555.3080303@gmc.lt> References: <1083133394.2817.40.camel@mentor.gurulabs.com> <408F5555.3080303@gmc.lt> Content-Type: text/plain Message-Id: <1083174347.2803.9.camel@mentor.gurulabs.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-1) Date: Wed, 28 Apr 2004 11:45:47 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 4958 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dax@gurulabs.com Precedence: bulk X-list: netdev On Wed, 2004-04-28 at 00:55, Aidas Kasparas wrote: > Kernel bug. IPSec changes ip headers, but fails to say about this to > conntrack. More information > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215980 > Patch at > http://bugs.debian.org/cgi-bin/bugreport.cgi/ipsec_conntrack.diff?bug=215980&msg=3&att=1 A 7 month old kernel bug with a patch. Is there any reason why this hasn't been rolled into the Linus tree yet? Is the something objectionable with the patch? Dax Kelson Guru Labs From shemminger@osdl.org Wed Apr 28 10:49:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 10:49:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SHn6KO014640 for ; Wed, 28 Apr 2004 10:49:07 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3SHmr214315; Wed, 28 Apr 2004 10:48:53 -0700 Date: Wed, 28 Apr 2004 10:48:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] netlink functions that can be static (trivial) Message-Id: <20040428104853.229f3d6c@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4959 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 Several internal functions and tables in rtnetlink can be static, and fill functions don't change stat of the net_device. diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c Wed Apr 28 10:44:47 2004 +++ b/net/core/rtnetlink.c Wed Apr 28 10:44:47 2004 @@ -153,7 +153,8 @@ } -static int rtnetlink_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, +static int rtnetlink_fill_ifinfo(struct sk_buff *skb, + const struct net_device *dev, int type, u32 pid, u32 seq, u32 change) { struct ifinfomsg *r; @@ -214,11 +215,11 @@ return -1; } -int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) +static int rtnetlink_dump_ifinfo(struct sk_buff *skb, struct netlink_callback *cb) { int idx; int s_idx = cb->args[0]; - struct net_device *dev; + const struct net_device *dev; read_lock(&dev_base_lock); for (dev=dev_base, idx=0; dev; dev = dev->next, idx++) { @@ -280,7 +281,7 @@ return err; } -int rtnetlink_dump_all(struct sk_buff *skb, struct netlink_callback *cb) +static int rtnetlink_dump_all(struct sk_buff *skb, struct netlink_callback *cb) { int idx; int s_idx = cb->family; @@ -553,7 +554,7 @@ return NOTIFY_DONE; } -struct notifier_block rtnetlink_dev_notifier = { +static struct notifier_block rtnetlink_dev_notifier = { .notifier_call = rtnetlink_event, }; diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Wed Apr 28 10:44:47 2004 +++ b/net/netlink/af_netlink.c Wed Apr 28 10:44:47 2004 @@ -809,7 +809,7 @@ return err ? : copied; } -void netlink_data_ready(struct sock *sk, int len) +static void netlink_data_ready(struct sock *sk, int len) { struct netlink_opt *nlk = nlk_sk(sk); @@ -1126,7 +1126,7 @@ return 0; } -struct seq_operations netlink_seq_ops = { +static struct seq_operations netlink_seq_ops = { .start = netlink_seq_start, .next = netlink_seq_next, .stop = netlink_seq_stop, @@ -1159,7 +1159,7 @@ return notifier_chain_unregister(&netlink_chain, nb); } -struct proto_ops netlink_ops = { +static struct proto_ops netlink_ops = { .family = PF_NETLINK, .owner = THIS_MODULE, .release = netlink_release, @@ -1180,7 +1180,7 @@ .sendpage = sock_no_sendpage, }; -struct net_proto_family netlink_family_ops = { +static struct net_proto_family netlink_family_ops = { .family = PF_NETLINK, .create = netlink_create, .owner = THIS_MODULE, /* for consistency 8) */ From fubar@us.ibm.com Wed Apr 28 10:58:36 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 10:58:43 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SHwTKO015136 for ; Wed, 28 Apr 2004 10:58:35 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i3SHvWIm714690; Wed, 28 Apr 2004 13:57:34 -0400 Received: from death.nxdomain.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i3SHvo6h104116; Wed, 28 Apr 2004 13:57:50 -0400 Received: from death.nxdomain.ibm.com (localhost [127.0.0.1]) by death.nxdomain.ibm.com (8.12.8/8.12.8) with ESMTP id i3SHtXZB020276; Wed, 28 Apr 2004 10:55:34 -0700 Received: from death (fubar@localhost) by death.nxdomain.ibm.com (8.12.8/8.12.8/Submit) with ESMTP id i3SHtX7V020271; Wed, 28 Apr 2004 10:55:33 -0700 Message-Id: <200404281755.i3SHtX7V020271@death.nxdomain.ibm.com> To: Paul Mackerras cc: linux-tr@linuxtr.net, netdev@oss.sgi.com Subject: Re: spin_lock_bh() called in irq handler In-Reply-To: Message from Paul Mackerras of "Wed, 28 Apr 2004 17:24:14 +1000." <16527.23582.316697.56419@cargo.ozlabs.ibm.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Wed, 28 Apr 2004 10:55:33 -0700 From: Jay Vosburgh X-archive-position: 4960 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: fubar@us.ibm.com Precedence: bulk X-list: netdev >I had a look and found that all of the token-ring drivers call >tr_type_trans() at interrupt level. That seems perfectly reasonable >to me. To fix the bug, it seems to me that there are two options: >either move the tr_add_rif_info() call elsewhere (but I have no idea >where) or else use spin_lock_irqsave instead of spin_lock_bh. > >Which is the more appropriate fix? I'm guessing spin_lock_irqsave; would the following be appropriate? I'm not absolutely sure about using spin_(un)lock_irq in rif_seq_start/stop, but it'd be complicated to deal with the flags in that case. I've built this and given it some basic testing, but not really hammered on it. The system doesn't panic when I cat /proc/net/tr_rif, which is a good sign. -J --- -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com diff -urN linux-2.6.5-orig/net/802/tr.c linux-2.6.5/net/802/tr.c --- linux-2.6.5-orig/net/802/tr.c 2004-04-28 10:02:12.000000000 -0700 +++ linux-2.6.5/net/802/tr.c 2004-04-28 10:15:47.000000000 -0700 @@ -250,10 +250,11 @@ unsigned int hash; struct rif_cache_s *entry; unsigned char *olddata; + unsigned long flags; static const unsigned char mcast_func_addr[] = {0xC0,0x00,0x00,0x04,0x00,0x00}; - spin_lock_bh(&rif_lock); + spin_lock_irqsave(&rif_lock, flags); /* * Broadcasts are single route as stated in RFC 1042 @@ -322,7 +323,7 @@ else slack = 18 - ((ntohs(trh->rcf) & TR_RCF_LEN_MASK)>>8); olddata = skb->data; - spin_unlock_bh(&rif_lock); + spin_unlock_irqrestore(&rif_lock, flags); skb_pull(skb, slack); memmove(skb->data, olddata, sizeof(struct trh_hdr) - slack); @@ -336,10 +337,11 @@ static void tr_add_rif_info(struct trh_hdr *trh, struct net_device *dev) { unsigned int hash, rii_p = 0; + unsigned long flags; struct rif_cache_s *entry; - spin_lock_bh(&rif_lock); + spin_lock_irqsave(&rif_lock, flags); /* * Firstly see if the entry exists @@ -377,7 +379,7 @@ if(!entry) { printk(KERN_DEBUG "tr.c: Couldn't malloc rif cache entry !\n"); - spin_unlock_bh(&rif_lock); + spin_unlock_irqrestore(&rif_lock, flags); return; } @@ -419,7 +421,7 @@ } entry->last_used=jiffies; } - spin_unlock_bh(&rif_lock); + spin_unlock_irqrestore(&rif_lock, flags); } /* @@ -429,9 +431,9 @@ static void rif_check_expire(unsigned long dummy) { int i; - unsigned long next_interval = jiffies + sysctl_tr_rif_timeout/2; + unsigned long flags, next_interval = jiffies + sysctl_tr_rif_timeout/2; - spin_lock_bh(&rif_lock); + spin_lock_irqsave(&rif_lock, flags); for(i =0; i < RIF_TABLE_SIZE; i++) { struct rif_cache_s *entry, **pentry; @@ -453,7 +455,7 @@ } } - spin_unlock_bh(&rif_lock); + spin_unlock_irqrestore(&rif_lock, flags); mod_timer(&rif_timer, next_interval); @@ -484,7 +486,7 @@ static void *rif_seq_start(struct seq_file *seq, loff_t *pos) { - spin_lock_bh(&rif_lock); + spin_lock_irq(&rif_lock); return *pos ? rif_get_idx(*pos - 1) : SEQ_START_TOKEN; } @@ -515,7 +517,7 @@ static void rif_seq_stop(struct seq_file *seq, void *v) { - spin_unlock_bh(&rif_lock); + spin_unlock_irq(&rif_lock); } static int rif_seq_show(struct seq_file *seq, void *v) From shemminger@osdl.org Wed Apr 28 11:16:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 11:16:58 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SIGqKO015864 for ; Wed, 28 Apr 2004 11:16:54 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3SIGf217871; Wed, 28 Apr 2004 11:16:41 -0700 Date: Wed, 28 Apr 2004 11:16:41 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] ipv4 use static in several places (trivial) Message-Id: <20040428111641.7e40de54@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4961 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 More functions and data that should be static. diff -Nru a/net/ipv4/devinet.c b/net/ipv4/devinet.c --- a/net/ipv4/devinet.c Wed Apr 28 10:49:55 2004 +++ b/net/ipv4/devinet.c Wed Apr 28 10:49:55 2004 @@ -998,7 +998,7 @@ return NOTIFY_DONE; } -struct notifier_block ip_netdev_notifier = { +static struct notifier_block ip_netdev_notifier = { .notifier_call =inetdev_event, }; diff -Nru a/net/ipv4/tcp.c b/net/ipv4/tcp.c --- a/net/ipv4/tcp.c Wed Apr 28 10:49:55 2004 +++ b/net/ipv4/tcp.c Wed Apr 28 10:49:55 2004 @@ -753,9 +753,6 @@ goto out; } -ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffset, - size_t psize, int flags); - static inline int can_coalesce(struct sk_buff *skb, int i, struct page *page, int off) { @@ -836,7 +833,7 @@ return err; } -ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffset, +static ssize_t do_tcp_sendpages(struct sock *sk, struct page **pages, int poffset, size_t psize, int flags) { struct tcp_opt *tp = tcp_sk(sk); diff -Nru a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c --- a/net/ipv4/tcp_input.c Wed Apr 28 10:49:55 2004 +++ b/net/ipv4/tcp_input.c Wed Apr 28 10:49:55 2004 @@ -1062,7 +1062,7 @@ * which indicates that we should follow the traditional RTO recovery, * i.e. mark everything lost and do go-back-N retransmission. */ -void tcp_enter_frto_loss(struct sock *sk) +static void tcp_enter_frto_loss(struct sock *sk) { struct tcp_opt *tp = tcp_sk(sk); struct sk_buff *skb; From davem@redhat.com Wed Apr 28 12:27:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 12:28:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SJRvKO021171 for ; Wed, 28 Apr 2004 12:27:57 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3SJRsKG027236; Wed, 28 Apr 2004 15:27:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3SJRsv23896; Wed, 28 Apr 2004 15:27:54 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3SJRpKv020868; Wed, 28 Apr 2004 15:27:51 -0400 Date: Wed, 28 Apr 2004 12:26:48 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] ipv4 use static in several places (trivial) Message-Id: <20040428122648.7e13e075.davem@redhat.com> In-Reply-To: <20040428111641.7e40de54@dell_ss3.pdx.osdl.net> References: <20040428111641.7e40de54@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4963 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Apr 2004 11:16:41 -0700 Stephen Hemminger wrote: > More functions and data that should be static. Applied, thanks Stephen. From davem@redhat.com Wed Apr 28 12:26:45 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 12:26:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SJQiKO021022 for ; Wed, 28 Apr 2004 12:26:45 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3SJQfKG026784; Wed, 28 Apr 2004 15:26:41 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3SJQfv23389; Wed, 28 Apr 2004 15:26:41 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3SJQcKv019933; Wed, 28 Apr 2004 15:26:38 -0400 Date: Wed, 28 Apr 2004 12:25:35 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netlink functions that can be static (trivial) Message-Id: <20040428122535.4f30f1b0.davem@redhat.com> In-Reply-To: <20040428104853.229f3d6c@dell_ss3.pdx.osdl.net> References: <20040428104853.229f3d6c@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4962 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Apr 2004 10:48:53 -0700 Stephen Hemminger wrote: > Several internal functions and tables in rtnetlink can be static, and > fill functions don't change stat of the net_device. Some problems here... > -static int rtnetlink_fill_ifinfo(struct sk_buff *skb, struct net_device *dev, > +static int rtnetlink_fill_ifinfo(struct sk_buff *skb, > + const struct net_device *dev, It doesn't start as static in my tree, I think you diffed the wrong revisions in your tree. :-) We export this thing to modules too, how do you know some external module doesn't actually use this thing? I know of no users, but... > - struct net_device *dev; > + const struct net_device *dev; This is wrong, a few lines down we assign it here: > read_lock(&dev_base_lock); > for (dev=dev_base, idx=0; dev; dev = dev->next, idx++) { So marking that 'dev' const cannot be right. Or are you marking the "object pointed to by 'dev'" as const? The rest of the patch seems fine, just clean these two things up. Thanks. From shemminger@osdl.org Wed Apr 28 15:02:28 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 15:02:32 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SM2SKO024323 for ; Wed, 28 Apr 2004 15:02:28 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3SM2G228839; Wed, 28 Apr 2004 15:02:16 -0700 Date: Wed, 28 Apr 2004 15:02:16 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netlink functions that can be static (trivial) Message-Id: <20040428150216.7e7c1432@dell_ss3.pdx.osdl.net> In-Reply-To: <20040428122535.4f30f1b0.davem@redhat.com> References: <20040428104853.229f3d6c@dell_ss3.pdx.osdl.net> <20040428122535.4f30f1b0.davem@redhat.com> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4964 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 Actually it is dump_ifinfo that's exported.. here is a fixed patch. diff -Nru a/net/core/rtnetlink.c b/net/core/rtnetlink.c --- a/net/core/rtnetlink.c Wed Apr 28 15:00:34 2004 +++ b/net/core/rtnetlink.c Wed Apr 28 15:00:34 2004 @@ -280,7 +280,7 @@ return err; } -int rtnetlink_dump_all(struct sk_buff *skb, struct netlink_callback *cb) +static int rtnetlink_dump_all(struct sk_buff *skb, struct netlink_callback *cb) { int idx; int s_idx = cb->family; @@ -553,7 +553,7 @@ return NOTIFY_DONE; } -struct notifier_block rtnetlink_dev_notifier = { +static struct notifier_block rtnetlink_dev_notifier = { .notifier_call = rtnetlink_event, }; diff -Nru a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c --- a/net/netlink/af_netlink.c Wed Apr 28 15:00:34 2004 +++ b/net/netlink/af_netlink.c Wed Apr 28 15:00:34 2004 @@ -809,7 +809,7 @@ return err ? : copied; } -void netlink_data_ready(struct sock *sk, int len) +static void netlink_data_ready(struct sock *sk, int len) { struct netlink_opt *nlk = nlk_sk(sk); @@ -1126,7 +1126,7 @@ return 0; } -struct seq_operations netlink_seq_ops = { +static struct seq_operations netlink_seq_ops = { .start = netlink_seq_start, .next = netlink_seq_next, .stop = netlink_seq_stop, @@ -1159,7 +1159,7 @@ return notifier_chain_unregister(&netlink_chain, nb); } -struct proto_ops netlink_ops = { +static struct proto_ops netlink_ops = { .family = PF_NETLINK, .owner = THIS_MODULE, .release = netlink_release, @@ -1180,7 +1180,7 @@ .sendpage = sock_no_sendpage, }; -struct net_proto_family netlink_family_ops = { +static struct net_proto_family netlink_family_ops = { .family = PF_NETLINK, .create = netlink_create, .owner = THIS_MODULE, /* for consistency 8) */ From davem@redhat.com Wed Apr 28 16:17:26 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 16:17:30 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SNHPKO025962 for ; Wed, 28 Apr 2004 16:17:26 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3SNHNKG021344; Wed, 28 Apr 2004 19:17:23 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3SNHMv03396; Wed, 28 Apr 2004 19:17:22 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3SNHJKv030260; Wed, 28 Apr 2004 19:17:20 -0400 Date: Wed, 28 Apr 2004 16:16:15 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] netlink functions that can be static (trivial) Message-Id: <20040428161615.7623158f.davem@redhat.com> In-Reply-To: <20040428150216.7e7c1432@dell_ss3.pdx.osdl.net> References: <20040428104853.229f3d6c@dell_ss3.pdx.osdl.net> <20040428122535.4f30f1b0.davem@redhat.com> <20040428150216.7e7c1432@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4965 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Wed, 28 Apr 2004 15:02:16 -0700 Stephen Hemminger wrote: > Actually it is dump_ifinfo that's exported.. here is a fixed patch. Applied. From greearb@candelatech.com Wed Apr 28 17:02:21 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 17:02:26 -0700 (PDT) Received: from www.lanforge.com (ns1.lanforge.com [66.165.47.210]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3T02LKO030048 for ; Wed, 28 Apr 2004 17:02:21 -0700 Received: from candelatech.com (evrtwa1-ar2-4-35-049-074.evrtwa1.dsl-verizon.net [4.35.49.74]) (authenticated bits=0) by www.lanforge.com (8.12.8/8.12.8) with ESMTP id i3T05R08005269 for ; Wed, 28 Apr 2004 17:05:27 -0700 Message-ID: <4090460C.1000606@candelatech.com> Date: Wed, 28 Apr 2004 17:02:20 -0700 From: Ben Greear Organization: Candela Technologies User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'netdev@oss.sgi.com'" Subject: tg3 patch to enable GMII test modes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4966 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: greearb@candelatech.com Precedence: bulk X-list: netdev I have been trying to get a GigE adapter to go into the GMII test modes described in section 40 of the 802.3 spec. I was able to get e1000 into those modes, but it was transmitting a 100bt pulse code instead of gigE (according to the guy with the scope). I'm now trying to get the tg3 to use these test modes. I should have confirmation from the scope guy in a few days, but in the mean time I thought I'd run the patch buy you all. If this is something that is desired in the main kernel, I have the rest of the ethtool parts as well, and a user-space application to drive it. Comments welcome. Thanks, Ben --- linux-2.4.25/drivers/net/tg3.h 2003-11-28 10:26:20.000000000 -0800 +++ linux-2.4.25.p4/drivers/net/tg3.h 2004-04-28 15:56:04.000000000 -0700 @@ -1417,6 +1417,13 @@ #define MII_TG3_CTRL_AS_MASTER 0x0800 #define MII_TG3_CTRL_ENABLE_AS_MASTER 0x1000 +/* Hoping these are the same as in the e1000 --Ben */ +#define MII_TG3_1000T_TEST_MODE_NORMAL 0x0000 /* Normal Operation */ +#define MII_TG3_TEST_MODE_1 0x2000 /* Transmit Waveform test */ +#define MII_TG3_TEST_MODE_2 0x4000 /* Master Transmit Jitter test */ +#define MII_TG3_TEST_MODE_3 0x6000 /* Slave Transmit Jitter test */ +#define MII_TG3_TEST_MODE_4 0x8000 /* Transmitter Distortion test */ + #define MII_TG3_EXT_CTRL 0x10 /* Extended control register */ #define MII_TG3_EXT_CTRL_LNK3_LED_MODE 0x0002 #define MII_TG3_EXT_CTRL_TBI 0x8000 @@ -1994,6 +2001,9 @@ struct tg3_hw_stats *hw_stats; dma_addr_t stats_mapping; struct tq_struct reset_task; + + u32 gmii_test; /* See ethtool.h for GMII_TEST_MODE* definitions */ + }; #endif /* !(_T3_H) */ --- linux-2.4.25/drivers/net/tg3.c 2004-02-18 05:36:31.000000000 -0800 +++ linux-2.4.25.p4/drivers/net/tg3.c 2004-04-28 16:54:32.000000000 -0700 @@ -559,6 +559,88 @@ return 0; } + +/** + * e1000_GMII_test_mode - Set various GMII test modes. + * @adapter: + **/ + +static void +tg3_GMII_test_mode(struct tg3 *adapter) +{ + u32 phy_ctrl; + const char* old_mode = NULL; + const char* new_mode = NULL; + + tg3_readphy(adapter, MII_TG3_CTRL, &phy_ctrl); + + if ((phy_ctrl & (MII_TG3_TEST_MODE_3)) == MII_TG3_TEST_MODE_3) { + old_mode = "MODE-3"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_1)) { + old_mode = "MODE-1"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_2)) { + old_mode = "MODE-2"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_4)) { + old_mode = "MODE-4"; + } + else { + old_mode = "NONE"; + } + + /* Initialize them to all off, will enabled as needed below */ + phy_ctrl &= ~(MII_TG3_TEST_MODE_1); + phy_ctrl &= ~(MII_TG3_TEST_MODE_2); + phy_ctrl &= ~(MII_TG3_TEST_MODE_3); + phy_ctrl &= ~(MII_TG3_TEST_MODE_4); + + switch(adapter->gmii_test) { + case GMII_TEST_MODE1: + phy_ctrl |= MII_TG3_TEST_MODE_1; + break; + case GMII_TEST_MODE2: + phy_ctrl |= MII_TG3_TEST_MODE_2; + break; + case GMII_TEST_MODE3: + phy_ctrl |= MII_TG3_TEST_MODE_3; + break; + case GMII_TEST_MODE4: + phy_ctrl |= MII_TG3_TEST_MODE_4; + break; + default: + /* drop through */ + break; + }/* switch */ + + if ((phy_ctrl & (MII_TG3_TEST_MODE_3)) == MII_TG3_TEST_MODE_3) { + new_mode = "MODE-3"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_1)) { + new_mode = "MODE-1"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_2)) { + new_mode = "MODE-2"; + } + else if (phy_ctrl & (MII_TG3_TEST_MODE_4)) { + new_mode = "MODE-4"; + } + else { + new_mode = "NONE"; + } + + if (strcmp(new_mode, old_mode) != 0) { + printk("tg3: %s: Changing GMII Test Mode from: %s to %s (register: 0x%2hx)\n", + + adapter->dev->name, old_mode, new_mode, phy_ctrl); + tg3_writephy(adapter, MII_TG3_CTRL, phy_ctrl); + } + +} /* tg3_GMII_test_mode */ + + + static int tg3_phy_reset_5703_4_5(struct tg3 *tp) { u32 reg32, phy9_orig; @@ -656,6 +738,7 @@ out: tg3_phy_set_wirespeed(tp); + tg3_GMII_test_mode(tp); return 0; } @@ -1996,6 +2079,7 @@ err = tg3_setup_fiber_phy(tp); } else { err = tg3_setup_copper_phy(tp); + tg3_GMII_test_mode(tp); /* Set the GMII test mode as desired. */ } if (tp->link_config.active_speed == SPEED_1000 && @@ -6043,7 +6127,32 @@ return ethtool_op_set_tso(dev, value); } #endif + +static int tg3_set_gmii_test(struct net_device *dev, u32 v) +{ + struct tg3 *tp = dev->priv; + + spin_lock_irq(&tp->lock); + spin_lock(&tp->tx_lock); + + tp->gmii_test = v; + /* printk("Setting gmii_test to: %d\n", v); */ + tg3_setup_phy(tp); + + spin_unlock(&tp->tx_lock); + spin_unlock_irq(&tp->lock); + return 0; +} + +static int tg3_get_gmii_test(struct net_device *dev, u32* v) +{ + struct tg3 *tp = dev->priv; + *v = tp->gmii_test; + /* printk("Getting gmii_test: %d\n", *v); */ + return 0; +} + static int tg3_nway_reset(struct net_device *dev) { struct tg3 *tp = dev->priv; @@ -6285,6 +6394,8 @@ .get_tso = ethtool_op_get_tso, .set_tso = tg3_set_tso, #endif + .set_gmii_test = tg3_set_gmii_test, + .get_gmii_test = tg3_get_gmii_test, }; /* Chips other than 5700/5701 use the NVRAM for fetching info. */ @@ -6608,6 +6719,9 @@ /* Enable Ethernet@WireSpeed */ tg3_phy_set_wirespeed(tp); + /* Enable test modes if desired */ + tg3_GMII_test_mode(tp); + if (!err && ((tp->phy_id & PHY_ID_MASK) == PHY_ID_BCM5401)) { err = tg3_init_5401phy_dsp(tp); } -- Ben Greear Candela Technologies Inc http://www.candelatech.com From jgarzik@pobox.com Wed Apr 28 21:49:03 2004 Received: with ECARTIS (v1.0.0; list netdev); Wed, 28 Apr 2004 21:49:06 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3T4n2KO006804 for ; Wed, 28 Apr 2004 21:49:03 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BJ3Tp-0006Z2-8J for netdev@oss.sgi.com; Thu, 29 Apr 2004 05:49:01 +0100 Message-ID: <40908931.8030406@pobox.com> Date: Thu, 29 Apr 2004 00:48:49 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Netdev Subject: wireless ping? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4967 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 Is this thing on? Anybody know what's up with the HostAP driver? From jgarzik@pobox.com Thu Apr 29 03:13:32 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 03:13:41 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TADVKO018712 for ; Thu, 29 Apr 2004 03:13:32 -0700 Received: from rdu74-153-143.nc.rr.com ([24.74.153.143] helo=pobox.com) by www.linux.org.uk with asmtp (TLSv1:AES256-SHA:256) (Exim 4.22) id 1BIWvv-0005NQ-KC; Tue, 27 Apr 2004 19:03:51 +0100 Message-ID: <408EA079.3060604@pobox.com> Date: Tue, 27 Apr 2004 14:03:37 -0400 From: Jeff Garzik User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Randy.Dunlap" CC: netdev , ollie@sis.com.tw Subject: Re: [janitor] sis900: don't use yield() References: <20040427103807.311caa42.rddunlap@osdl.org> In-Reply-To: <20040427103807.311caa42.rddunlap@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4968 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jgarzik@pobox.com Precedence: bulk X-list: netdev Randy.Dunlap wrote: > From: maximilian attems > > thanks to Felipe W Damasio hint rediffed. > patch is on top of linux-2.6.6-rc2 > > yield() removes process from active array into expired array, > better just yield the CPU for a bit. > tested on my laptop with a sis900. > > a++ maks > > Index: linux-266-rc2-kj1/drivers/net/sis900.c > =================================================================== > --- linux-266-rc2-kj1.orig/drivers/net/sis900.c 2004-04-03 19:36:57.000000000 -0800 > +++ linux-266-rc2-kj1/drivers/net/sis900.c 2004-04-21 15:32:56.000000000 -0700 > @@ -600,7 +600,8 @@ static int __init sis900_mii_probe (stru > > if(status & MII_STAT_LINK){ > while (poll_bit) { > - yield(); > + set_current_state(TASK_UNINTERRUPTIBLE); > + schedule_timeout(HZ/100); I would rather do schedule_timeout(1), as that's IMO closer to the intention... Jeff From dn.tlp@gmx.net Thu Apr 29 05:30:08 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 05:30:12 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TCU7KO012384 for ; Thu, 29 Apr 2004 05:30:08 -0700 Received: (qmail 30090 invoked by uid 65534); 29 Apr 2004 12:30:01 -0000 Received: from pD9E568F8.dip.t-dialin.net (EHLO radix.peter.home) (217.229.104.248) by mail.gmx.net (mp025) with SMTP; 29 Apr 2004 14:30:01 +0200 X-Authenticated: #228032 Date: Thu, 29 Apr 2004 14:30:06 +0200 From: Simon Peter To: netdev@oss.sgi.com Cc: Carl-Daniel Hailfinger Subject: forcedeth received irq with unknown events Message-Id: <20040429143006.4f8b5df0.dn.tlp@gmx.net> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4969 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: dn.tlp@gmx.net Precedence: bulk X-list: netdev Hi there! Since i plugged the DSL-Modem directly to my onboard nForce2 network card (it's a Shuttle AN35-400 Mobo), i constantly get the following messages in my syslog: Apr 29 14:15:02 server kernel: eth0: received irq with unknown events 0x1. Please report Apr 29 14:15:33 server last message repeated 28 times Apr 29 14:15:55 server last message repeated 23 times The message seems to be displaying more frequently the more traffic is on the link. Formerly, the nForce2 board was connected to a 100mbps switch to my LAN and i didn't get any of these messages. If you need any more info to get this fixed, just reply! Great work with the driver! Simon From c-d.hailfinger.kernel.2004@gmx.net Thu Apr 29 06:25:05 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 06:25:11 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TDP4KO013703 for ; Thu, 29 Apr 2004 06:25:05 -0700 Received: (qmail 17441 invoked by uid 65534); 29 Apr 2004 13:24:59 -0000 Received: from stud214015.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.214.15) by mail.gmx.net (mp017) with SMTP; 29 Apr 2004 15:24:59 +0200 X-Authenticated: #21910825 Message-ID: <40910211.40301@gmx.net> Date: Thu, 29 Apr 2004 15:24:33 +0200 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en MIME-Version: 1.0 To: Simon Peter CC: netdev@oss.sgi.com Subject: Re: forcedeth received irq with unknown events References: <20040429143006.4f8b5df0.dn.tlp@gmx.net> In-Reply-To: <20040429143006.4f8b5df0.dn.tlp@gmx.net> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/mixed; boundary="------------040705010704050401040601" X-archive-position: 4970 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------040705010704050401040601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Simon Peter wrote: > Hi there! > > Since i plugged the DSL-Modem directly to my onboard nForce2 network > card (it's a Shuttle AN35-400 Mobo), i constantly get the following > messages in my syslog: > > Apr 29 14:15:02 server kernel: eth0: received irq with unknown events > 0x1. Please report > Apr 29 14:15:33 server last message repeated 28 times > Apr 29 14:15:55 server last message repeated 23 times > > The message seems to be displaying more frequently the more traffic is > on the link. This 0x1 event is a receive error. It seems only users with cable modems have this problem. I've got no idea why it happens with cable modems and nothing else, but it could indeed be crappy hardware on the modem side. What we don't know yet is if the receive error is hard or soft. Soft errors generally can be recovered from, so it would be a shame throwing the packets away. > Formerly, the nForce2 board was connected to a 100mbps switch to my LAN > and i didn't get any of these messages. Your switch didn't let the malformed/incorrect packets through, so you computer didn't see them. > If you need any more info to get this fixed, just reply! Could you please try the attached patch (will create LOTS of debug messages) for a few minutes and mail the relevant part of your /var/log/messages to me privately (it will be >100 kB, so I don't want to burden the list with it). > Great work with the driver! Thanks, Carl-Daniel -- http://www.hailfinger.org/ --------------040705010704050401040601 Content-Type: text/plain; name="forcedeth_0x1event_rx_patch2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_0x1event_rx_patch2.txt" ===== drivers/net/forcedeth.c 1.1 vs edited ===== --- 1.1/drivers/net/forcedeth.c Thu Feb 5 02:11:13 2004 +++ edited/drivers/net/forcedeth.c Tue Mar 2 21:04:06 2004 @@ -120,6 +120,7 @@ #define NVREG_IRQSTAT_MIIEVENT 0x040 #define NVREG_IRQSTAT_MASK 0x1ff NvRegIrqMask = 0x004, +#define NVREG_IRQ_RX_ERR 0x0001 #define NVREG_IRQ_RX 0x0002 #define NVREG_IRQ_RX_NOBUF 0x0004 #define NVREG_IRQ_TX_ERR 0x0008 @@ -129,7 +130,7 @@ #define NVREG_IRQ_TX1 0x0100 #define NVREG_IRQMASK_WANTED_1 0x005f #define NVREG_IRQMASK_WANTED_2 0x0147 -#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) +#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) NvRegUnknownSetupReg6 = 0x008, #define NVREG_UNKSETUP6_VAL 3 @@ -847,7 +848,7 @@ i = np->cur_rx % RX_RING; prd = &np->rx_ring[i]; - dprintk(KERN_DEBUG "%s: rx_process: looking at packet %d, Flags 0x%x.\n", + printk(KERN_INFO "%s: rx_process: looking at packet %d, Flags 0x%x.\n", dev->name, np->cur_rx, prd->Flags); if (prd->Flags & cpu_to_le16(NV_RX_AVAIL)) @@ -880,25 +881,30 @@ len = le16_to_cpu(prd->Length); if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) { + printk(KERN_INFO "%s: rx_process: missed frame\n", dev->name); np->stats.rx_missed_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + printk(KERN_INFO "%s: rx_process: error 1-4\n", dev->name); np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) { + printk(KERN_INFO "%s: rx_process: crc error\n", dev->name); np->stats.rx_crc_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) { + printk(KERN_INFO "%s: rx_process: overflow\n", dev->name); np->stats.rx_over_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) { + printk(KERN_INFO "%s: rx_process: generic error\n", dev->name); /* framing errors are soft errors, the rest is fatal. */ if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) { if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) { @@ -1096,7 +1102,7 @@ spin_unlock(&np->lock); } - if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { + if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_RX_ERR)) { rx_process(dev); if (alloc_rx(dev)) { spin_lock(&np->lock); @@ -1110,6 +1116,10 @@ spin_lock(&np->lock); link_irq(dev); spin_unlock(&np->lock); + } + if (events & (NVREG_IRQ_RX_ERR)) { + printk(KERN_INFO "%s: received irq with events 0x%x. Probably RX fail. Trying to get diagnostics.\n", + dev->name, events); } if (events & (NVREG_IRQ_TX_ERR)) { dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n", --------------040705010704050401040601-- From jm@jm.kir.nu Thu Apr 29 08:08:59 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 08:09:03 -0700 (PDT) Received: from jm.kir.nu (hiss-0.instant802.com [66.93.138.196]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TF8xKO018622 for ; Thu, 29 Apr 2004 08:08:59 -0700 Received: from jm by jm.kir.nu with local (Exim 4.31) id 1BJD8x-0001Zl-4J; Thu, 29 Apr 2004 08:08:07 -0700 Date: Thu, 29 Apr 2004 08:08:07 -0700 From: Jouni Malinen To: Jeff Garzik Cc: Netdev Subject: Re: wireless ping? Message-ID: <20040429150806.GA6052@jm.kir.nu> References: <40908931.8030406@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40908931.8030406@pobox.com> User-Agent: Mutt/1.5.6i X-archive-position: 4971 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jkmaline@cc.hut.fi Precedence: bulk X-list: netdev On Thu, Apr 29, 2004 at 12:48:49AM -0400, Jeff Garzik wrote: > Anybody know what's up with the HostAP driver? Unfortunately, I have been way too busy with other projects during the last weeks. I finally reserved some time to start going through my pending to do list for Host AP yesterday. I'll try to get to the 2.6 cleaning part shortly, but I cannot yet give an estimate on when this will be ready to be submitted. My current plan is to limit to minimal number of changes (i.e., skip CCMP for the time being) to speed this up a bit. -- Jouni Malinen PGP id EFC895FA From marcelo.tosatti@cyclades.com Thu Apr 29 14:08:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 14:08:49 -0700 (PDT) Received: from www.linux.org.uk (IDENT:93@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TL8iKO003218 for ; Thu, 29 Apr 2004 14:08:45 -0700 Received: from [127.0.0.1] (helo=logos.cnet) by www.linux.org.uk with esmtp (Exim 4.22) id 1BJIls-0007ED-9r; Thu, 29 Apr 2004 22:08:40 +0100 Received: by logos.cnet (Postfix, from userid 500) id 83ED1DB7C6; Thu, 29 Apr 2004 18:09:51 -0300 (BRT) Date: Thu, 29 Apr 2004 18:09:51 -0300 From: Marcelo Tosatti To: Jeff Moyer Cc: Carson Gaspar , linux-kernel@vger.kernel.org, netdev@oss.sgi.com, akpm@osdl.org, andrea@suse.de, davem@redhat.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-ID: <20040429210951.GB20453@logos.cnet> References: <382320000.1082759593@taltos.ny.ficc.gs.com> <16527.4259.174536.629347@segfault.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16527.4259.174536.629347@segfault.boston.redhat.com> User-Agent: Mutt/1.5.5.1i X-archive-position: 4972 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: marcelo.tosatti@cyclades.com Precedence: bulk X-list: netdev On Tue, Apr 27, 2004 at 10:02:11PM -0400, Jeff Moyer wrote: > > >FYI, we see the exact same panic with the tg3 driver using 2.4.25 and > >distcc with sendfile(). The bcm5700 driver also panics, but I haven't > >captured a panic message to be certain it's the same bug. > > >kernel BUG at page_alloc.c:98! > > Andrea fixed this in his tree by deferring the page free to process context > instead of BUG()ing on PageLRU(page). Yeap, his fix looks OK. Can you please people seeing the oops try this, from Andrea (on top of 2.4.26): --- a/mm/page_alloc.c.orig 2004-04-29 17:38:14.184021976 -0300 +++ b/mm/page_alloc.c 2004-04-29 17:47:27.906843312 -0300 @@ -46,6 +46,34 @@ int vm_gfp_debug = 0; +static void FASTCALL(__free_pages_ok (struct page *page, unsigned int order)); + +static spinlock_t free_pages_ok_no_irq_lock = SPIN_LOCK_UNLOCKED; +struct page * free_pages_ok_no_irq_head; + +static void do_free_pages_ok_no_irq(void * arg) +{ + struct page * page, * __page; + + spin_lock_irq(&free_pages_ok_no_irq_lock); + + page = free_pages_ok_no_irq_head; + free_pages_ok_no_irq_head = NULL; + + spin_unlock_irq(&free_pages_ok_no_irq_lock); + + while (page) { + __page = page; + page = page->next_hash; + __free_pages_ok(__page, __page->index); + } +} + +static struct tq_struct free_pages_ok_no_irq_task = { + .routine = do_free_pages_ok_no_irq, +}; + + /* * Temporary debugging check. */ @@ -81,7 +109,6 @@ * -- wli */ -static void FASTCALL(__free_pages_ok (struct page *page, unsigned int order)); static void __free_pages_ok (struct page *page, unsigned int order) { unsigned long index, page_idx, mask, flags; @@ -94,8 +121,20 @@ * a reference to a page in order to pin it for io. -ben */ if (PageLRU(page)) { - if (unlikely(in_interrupt())) - BUG(); + if (unlikely(in_interrupt())) { + unsigned long flags; + + spin_lock_irqsave(&free_pages_ok_no_irq_lock, flags); + page->next_hash = free_pages_ok_no_irq_head; + free_pages_ok_no_irq_head = page; + page->index = order; + + spin_unlock_irqrestore(&free_pages_ok_no_irq_lock, flags); + + schedule_task(&free_pages_ok_no_irq_task); + return; + } + lru_cache_del(page); } From akpm@osdl.org Thu Apr 29 14:25:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 14:26:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TLPtKO003728 for ; Thu, 29 Apr 2004 14:25:55 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3TLPe223777; Thu, 29 Apr 2004 14:25:40 -0700 Date: Thu, 29 Apr 2004 14:28:07 -0700 From: Andrew Morton To: Marcelo Tosatti Cc: jmoyer@redhat.com, carson@taltos.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, andrea@suse.de, davem@redhat.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-Id: <20040429142807.1fa4c5ea.akpm@osdl.org> In-Reply-To: <20040429210951.GB20453@logos.cnet> References: <382320000.1082759593@taltos.ny.ficc.gs.com> <16527.4259.174536.629347@segfault.boston.redhat.com> <20040429210951.GB20453@logos.cnet> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4973 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 Marcelo Tosatti wrote: > > > Andrea fixed this in his tree by deferring the page free to process context > > instead of BUG()ing on PageLRU(page). > > Yeap, his fix looks OK. It does. It would be nice to change if (in_interrupt()) to if (in_interrupt() || ((count++ % 10000) == 0)) just to exercise that code path a bit more. From julie.n.fleischer@intel.com Thu Apr 29 14:30:52 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 14:31:23 -0700 (PDT) Received: from caduceus.jf.intel.com (fmr06.intel.com [134.134.136.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TLUqKO004091 for ; Thu, 29 Apr 2004 14:30:52 -0700 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i3TLUkWp024167; Thu, 29 Apr 2004 21:30:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i3TLSm24024077; Thu, 29 Apr 2004 21:29:02 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004042914303320894 ; Thu, 29 Apr 2004 14:30:33 -0700 Received: from orsmsx402.amr.corp.intel.com ([192.168.65.208]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Apr 2004 14:30:33 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: [announce] Carrier Grade Linux v3.0 Standards early draft available Date: Thu, 29 Apr 2004 14:30:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [announce] Carrier Grade Linux v3.0 Standards early draft available Thread-Index: AcQuMTNhn8gjB/VtT8G0EzikvoyaQQ== From: "Fleischer, Julie N" To: , , X-OriginalArrivalTime: 29 Apr 2004 21:30:33.0118 (UTC) FILETIME=[33D663E0:01C42E31] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3TLUqKO004091 X-archive-position: 4974 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: julie.n.fleischer@intel.com Precedence: bulk X-list: netdev I wanted to let this mailing list know about the availability of an early public draft of the Carrier Grade Linux v3.0 Standards specification, available at http://www.osdl.org/docs/carrier_grade_linux_standards_apis_specs_requir ements_definition.pdf. This is an early draft document containing references to useful and necessary existing standards and interface specifications (POSIX, IETF) referenced in other CGL v3.0 section specifications. Past OSDL Carrier Grade Linux technical documents have contained all requirements in a single document. For OSDL CGL v3.0 draft releases, we are releasing them as more granular sections, roughly split on functional boundaries. These boundaries are Standards (this document), Availability, Clustering, Hardware, Performance, Security, and Serviceability. More information on Carrier Grade Linux and the Carrier Grade Linux Working Group can be found at http://osdl.org/lab_activities/carrier_grade_linux/. Feel free to direct any comments on the spec to me directly at julie.n.fleischer@intel.com or to the CGL Discussion mailing list at cgl_discussion@osdl.org. Thanks. - Julie Fleischer **These views are not necessarily those of my employer.** From shemminger@osdl.org Thu Apr 29 14:59:06 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 14:59:10 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TLx5KO005598 for ; Thu, 29 Apr 2004 14:59:06 -0700 Received: from dell_ss3.pdx.osdl.net (dell_ss3.pdx.osdl.net [172.20.1.60]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3TLwr229916; Thu, 29 Apr 2004 14:58:53 -0700 Date: Thu, 29 Apr 2004 14:58:53 -0700 From: Stephen Hemminger To: "David S. Miller" Cc: netdev@oss.sgi.com Subject: [PATCH] more network layer static funcs and data Message-Id: <20040429145853.08c2ea8e@dell_ss3.pdx.osdl.net> Organization: Open Source Development Lab X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i386-redhat-linux-gnu) X-Face: &@E+xe?c%:&e4D{>f1O<&U>2qwRREG5!}7R4;D<"NO^UI2mJ[eEOA2*3>(`Th.yP,VDPo9$ /`~cw![cmj~~jWe?AHY7D1S+\}5brN0k*NE?pPh_'_d>6;XGG[\KDRViCfumZT3@[ Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4975 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 Still more data structures and functions only referenced in the local file. diff -Nru a/net/core/neighbour.c b/net/core/neighbour.c --- a/net/core/neighbour.c Thu Apr 29 14:46:31 2004 +++ b/net/core/neighbour.c Thu Apr 29 14:46:31 2004 @@ -1479,7 +1479,7 @@ #ifdef CONFIG_SYSCTL -struct neigh_sysctl_table { +static struct neigh_sysctl_table { struct ctl_table_header *sysctl_header; ctl_table neigh_vars[17]; ctl_table neigh_dev[2]; diff -Nru a/net/ipv4/route.c b/net/ipv4/route.c --- a/net/ipv4/route.c Thu Apr 29 14:46:31 2004 +++ b/net/ipv4/route.c Thu Apr 29 14:46:31 2004 @@ -144,7 +144,7 @@ static int rt_garbage_collect(void); -struct dst_ops ipv4_dst_ops = { +static struct dst_ops ipv4_dst_ops = { .family = AF_INET, .protocol = __constant_htons(ETH_P_IP), .gc = rt_garbage_collect, @@ -1525,7 +1525,7 @@ * 2. IP spoofing attempts are filtered with 100% of guarantee. */ -int ip_route_input_slow(struct sk_buff *skb, u32 daddr, u32 saddr, +static int ip_route_input_slow(struct sk_buff *skb, u32 daddr, u32 saddr, u8 tos, struct net_device *dev) { struct fib_result res; @@ -1910,7 +1910,7 @@ * Major route resolver routine. */ -int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) +static int ip_route_output_slow(struct rtable **rp, const struct flowi *oldflp) { u32 tos = oldflp->fl4_tos & (IPTOS_RT_MASK | RTO_ONLINK); struct flowi fl = { .nl_u = { .ip4_u = diff -Nru a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c --- a/net/ipv6/af_inet6.c Thu Apr 29 14:46:31 2004 +++ b/net/ipv6/af_inet6.c Thu Apr 29 14:46:31 2004 @@ -539,7 +539,7 @@ .sendpage = sock_no_sendpage, }; -struct net_proto_family inet6_family_ops = { +static struct net_proto_family inet6_family_ops = { .family = PF_INET6, .create = inet6_create, .owner = THIS_MODULE, diff -Nru a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c --- a/net/ipv6/ndisc.c Thu Apr 29 14:46:31 2004 +++ b/net/ipv6/ndisc.c Thu Apr 29 14:46:31 2004 @@ -1418,7 +1418,7 @@ return NOTIFY_DONE; } -struct notifier_block ndisc_netdev_notifier = { +static struct notifier_block ndisc_netdev_notifier = { .notifier_call = ndisc_netdev_event, }; From andrea@suse.de Thu Apr 29 15:49:40 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 15:49:44 -0700 (PDT) Received: from dualathlon.random (ppp-217-133-42-200.cust-adsl.tiscali.it [217.133.42.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TMnaKO010038 for ; Thu, 29 Apr 2004 15:49:40 -0700 Received: by dualathlon.random (Postfix, from userid 500) id 11E6F3AC5D; Fri, 30 Apr 2004 00:49:36 +0200 (CEST) Date: Fri, 30 Apr 2004 00:49:36 +0200 From: Andrea Arcangeli To: Andrew Morton Cc: Marcelo Tosatti , jmoyer@redhat.com, carson@taltos.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-ID: <20040429224936.GT29954@dualathlon.random> References: <382320000.1082759593@taltos.ny.ficc.gs.com> <16527.4259.174536.629347@segfault.boston.redhat.com> <20040429210951.GB20453@logos.cnet> <20040429142807.1fa4c5ea.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040429142807.1fa4c5ea.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 X-archive-position: 4976 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: netdev On Thu, Apr 29, 2004 at 02:28:07PM -0700, Andrew Morton wrote: > just to exercise that code path a bit more. what's the point of exercising that code path more? are you worried that there are bugs in it? From akpm@osdl.org Thu Apr 29 16:24:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 16:24:27 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TNOLKO013858 for ; Thu, 29 Apr 2004 16:24:23 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3TNO5212158; Thu, 29 Apr 2004 16:24:05 -0700 Date: Thu, 29 Apr 2004 16:26:32 -0700 From: Andrew Morton To: Andrea Arcangeli Cc: marcelo.tosatti@cyclades.com, jmoyer@redhat.com, carson@taltos.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-Id: <20040429162632.689fa7fe.akpm@osdl.org> In-Reply-To: <20040429224936.GT29954@dualathlon.random> References: <382320000.1082759593@taltos.ny.ficc.gs.com> <16527.4259.174536.629347@segfault.boston.redhat.com> <20040429210951.GB20453@logos.cnet> <20040429142807.1fa4c5ea.akpm@osdl.org> <20040429224936.GT29954@dualathlon.random> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4977 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 Andrea Arcangeli wrote: > > On Thu, Apr 29, 2004 at 02:28:07PM -0700, Andrew Morton wrote: > > just to exercise that code path a bit more. > > what's the point of exercising that code path more? are you worried that > there are bugs in it? The only application which we know will exercise that code is the distcc server. Making that little change while testing the patch will increase the chance of shaking out any problems. From davem@redhat.com Thu Apr 29 16:28:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 16:28:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TNSAKO014270 for ; Thu, 29 Apr 2004 16:28:11 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3TNS7KG001389; Thu, 29 Apr 2004 19:28:07 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3TNS7v21249; Thu, 29 Apr 2004 19:28:07 -0400 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i3TNS3Kv019259; Thu, 29 Apr 2004 19:28:04 -0400 Date: Thu, 29 Apr 2004 16:26:53 -0700 From: "David S. Miller" To: Stephen Hemminger Cc: netdev@oss.sgi.com Subject: Re: [PATCH] more network layer static funcs and data Message-Id: <20040429162653.18058309.davem@redhat.com> In-Reply-To: <20040429145853.08c2ea8e@dell_ss3.pdx.osdl.net> References: <20040429145853.08c2ea8e@dell_ss3.pdx.osdl.net> X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4978 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev On Thu, 29 Apr 2004 14:58:53 -0700 Stephen Hemminger wrote: > Still more data structures and functions only referenced in the local file. Applied, thanks Stephen. From mcmanus@ducksong.com Thu Apr 29 16:35:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 16:35:59 -0700 (PDT) Received: from adsl.ducksong.com (IDENT:EKDufcciFAlDlx+0yuyuPqpKdk1ZvZvW@pool-68-160-9-252.bos.east.verizon.net [68.160.9.252]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TNZtKO014777 for ; Thu, 29 Apr 2004 16:35:56 -0700 Received: from [192.168.16.10] (book.gruel.limey.net [192.168.16.10]) by adsl.ducksong.com (8.12.10/8.12.9) with ESMTP id i3TMZtAh024076 for ; Thu, 29 Apr 2004 18:35:55 -0400 Subject: Help Me Understand RxDescriptor Ring Size and Cache Effects From: Patrick McManus To: netdev@oss.sgi.com Content-Type: text/plain Message-Id: <1083281777.13465.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 29 Apr 2004 19:36:17 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 4979 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mcmanus@ducksong.com Precedence: bulk X-list: netdev I hope someone can help me better grasp the fundamentals of a performance tuning issue. I've got an application server that is based on a copper gigabit nic that uses the intel e1000 driver on a pentium 4 platform. Periodically the interface will drop a burst of packets. The default Rx Descriptor ring size for my rev of this driver is 80, the chip supports up to 4096. This is about 300Mbit of traffic, with a mix of packet sizes.. I suspect the drops correspond to a burst of SYNs, not surprisingly. Increasing the ring size gets rid of my drops starting around 256 or so.. I also observe a pretty significant performance decrease in my application of about 3% with the ring at its full size.. at 256 I still see a minor performance impact, but much less than 3%. To be clear: I'm not agitating for any kind of change, I'm just trying to understand the principle of what is going on. I've read a few web archives about proper sizing of rings - but they tend to be concerned about wasting memory rather than slower performance. I presume L2 cache effects are coming into play, but I can't articulate quite why that would be with pci coherent buffers.. any pointers? Thanks so much! -Pat From akpm@osdl.org Thu Apr 29 17:00:02 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 17:00:08 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U002KO015414 for ; Thu, 29 Apr 2004 17:00:02 -0700 Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i3TNxu217280; Thu, 29 Apr 2004 16:59:56 -0700 Date: Thu, 29 Apr 2004 17:02:24 -0700 From: Andrew Morton To: netdev@oss.sgi.com Cc: Jan Olderdissen Subject: Fw: Stack sends SYN/ACKs even though accept queue is full Message-Id: <20040429170224.01b7eb4b.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4980 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: netdev Begin forwarded message: Date: Thu, 29 Apr 2004 14:53:36 -0700 From: Jan Olderdissen To: "'linux-kernel@vger.kernel.org'" Subject: Stack sends SYN/ACKs even though accept queue is full Synopsis: When the accept queue of a listening socket is full, the stack will SYN/ACK additional SYNs at a rate of 0.5Hz and put them on the syn queue. Those connections behave in bandwidth wasting ways if the accept queue remains full. In particular, the server resends the SYN/ACK multiple times while the client attempts to communicate thinking it has a valid connection. The client retransmits its data packets and eventually gives up. Packet trace: Time Info 7.381621 1277 > 5555 [SYN] Seq=1955472727 Ack=0 Win=2920 Len=0 7.381712 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 7.381776 1277 > 5555 [ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=0 7.400029 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 7.609149 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 8.029061 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 8.868911 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 10.378517 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 10.379162 1277 > 5555 [ACK] Seq=1955472818 Ack=1971042014 Win=2920 Len=0 10.548510 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 13.907815 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 16.377300 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 16.378034 1277 > 5555 [ACK] Seq=1955472818 Ack=1971042014 Win=2920 Len=0 20.626501 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 28.374887 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 28.375489 1277 > 5555 [ACK] Seq=1955472818 Ack=1971042014 Win=2920 Len=0 34.063710 1277 > 5555 [PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 52.569956 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 52.570129 1277 > 5555 [ACK] Seq=1955472818 Ack=1971042014 Win=2920 Len=0 57.380254 1277 > 5555 [FIN, ACK] Seq=1955472818 Ack=1971042014 Win=2920 Len=0 60.938358 1277 > 5555 [FIN, PSH, ACK] Seq=1955472728 Ack=1971042014 Win=2920 Len=90 100.760213 5555 > 1277 [SYN, ACK] Seq=1971042013 Ack=1955472728 Win=2896 Len=0 100.760347 1277 > 5555 [ACK] Seq=1955472819 Ack=1971042014 Win=2920 Len=0 Other TCP connections, IP addresses and various other superfluous information removed. Code analysis: tcp_v4_conn_request() in tcp_ipv4.c contains the following code: /* Accept backlog is full. If we have already queued enough * of warm entries in syn queue, drop request. It is better than * clogging syn queue with openreqs with exponentially increasing * timeout. */ if (tcp_acceptq_is_full(sk) && tcp_synq_young(sk) > 1) goto drop; A synq entry is considered young when it hasn't timed out yet as the following comment in tcp_timer.c indicates: /* Normally all the openreqs are young and become mature * (i.e. converted to established socket) for first timeout. * If synack was not acknowledged for 3 seconds, it means * one of the following things: synack was lost, ack was lost, * rtt is high or nobody planned to ack (i.e. synflood). * When server is a bit loaded, queue is populated with old * open requests, reducing effective size of queue. * When server is well loaded, queue size reduces to zero * after several minutes of work. It is not synflood, * it is normal operation. The solution is pruning * too old entries overriding normal timeout, when * situation becomes dangerous. * * Essentially, we reserve half of room for young * embrions; and abort old ones without pity, if old * ones are about to clog our table. */ Unfortunately, when a server is really busy and the acceptq remains full, the connections held on the synq will drop incoming ACK (and other) packets without compunction as the code from tcp_v4_syn_recv_sock() in tcp_ipv4.c shows: if (tcp_acceptq_is_full(sk)) goto exit_overflow; Which leads to the strange packet trace outlined above. Because newly accepted connections are considered 'young', two such connections put on the synq will cause additional SYNs to be dropped until young connections age and additional connections are SYN/ACKed , etc. Since the initial TCP timeout is three seconds, you would expect two additional connections to be accepted every three seconds. However, experiments with 2.4.25 show that number to be two connections every four seconds for unclear reasons. In addition to the 2.4.21 sources we mainly work with in our embedded systems, I checked the 2.4.26 and 2.6.5 sources. They don't appear to differ in the sections discussed. The packet trace is from 2.4.25. Conclusion: Unless I'm missing something material, the stack has no business accepting connections for which it doesn't have entries in the accept queue. If it is the intention of the application to have a large number of pending connections, it should have a long accept queue as it is. Accepting two additional connections every four seconds does not materially improve the performance of highly loaded servers. Perhaps someone on the mailing list can enlighten me as to the point of the 'tcp_synq_young(sk) > 1' condition. The intent seems to be to keep a modicum of 'warm' connections in the air at all times in case the app eventually gets around to accepting all the pending connections and an oscillation effect might ensue. However, the implementation doesn't scale and the effect of suggesting to the remote app that it has someone to talk to and then just ignoring all packets it sends appears to be somewhat counterproductive. Thanks go to Thomas Ameling who was instrumental in tracking down this issue. Jan Olderdissen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ From andrea@suse.de Thu Apr 29 17:15:23 2004 Received: with ECARTIS (v1.0.0; list netdev); Thu, 29 Apr 2004 17:15:27 -0700 (PDT) Received: from dualathlon.random (ppp-217-133-42-200.cust-adsl.tiscali.it [217.133.42.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U0FLKO015936 for ; Thu, 29 Apr 2004 17:15:22 -0700 Received: by dualathlon.random (Postfix, from userid 500) id 5831144B6; Fri, 30 Apr 2004 02:15:21 +0200 (CEST) Date: Fri, 30 Apr 2004 02:15:21 +0200 From: Andrea Arcangeli To: Andrew Morton Cc: marcelo.tosatti@cyclades.com, jmoyer@redhat.com, carson@taltos.org, linux-kernel@vger.kernel.org, netdev@oss.sgi.com, davem@redhat.com Subject: Re: kernel BUG at page_alloc.c:98 -- compiling with distcc Message-ID: <20040430001521.GV29954@dualathlon.random> References: <382320000.1082759593@taltos.ny.ficc.gs.com> <16527.4259.174536.629347@segfault.boston.redhat.com> <20040429210951.GB20453@logos.cnet> <20040429142807.1fa4c5ea.akpm@osdl.org> <20040429224936.GT29954@dualathlon.random> <20040429162632.689fa7fe.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040429162632.689fa7fe.akpm@osdl.org> User-Agent: Mutt/1.4.1i X-GPG-Key: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43 X-PGP-Key: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5 X-archive-position: 4981 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: netdev On Thu, Apr 29, 2004 at 04:26:32PM -0700, Andrew Morton wrote: > The only application which we know will exercise that code is the distcc > server. Making that little change while testing the patch will increase > the chance of shaking out any problems. if you're scared it has bugs I think it'd be more useful to change it to "|| 1" and run it under some stress test, and then remove the "|| 1". the aio code in unmap_kvec is also a big user of that. a schedule every 40M of ram freed isn't too nice to my eyes (but I doubt it can be measured). From panemade@indiatimes.com Fri Apr 30 00:40:57 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 00:41:03 -0700 (PDT) Received: from WS0005.indiatimes.com ([203.199.93.15]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U7esKO003158 for ; Fri, 30 Apr 2004 00:40:56 -0700 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id MAA22398; Fri, 30 Apr 2004 12:31:06 +0530 From: "panemade" Message-Id: <200404300701.MAA22398@WS0005.indiatimes.com> To: "Rusty Russell" CC: "kernerl mail", , , "netfilter", Reply-To: "panemade" Subject: Re: Re: HELP ipt_hook: happy cracking message Date: Fri, 30 Apr 2004 13:05:07 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii X-archive-position: 4982 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: panemade@indiatimes.com Precedence: bulk X-list: netdev hello, Because of i increase icmp header by 8 bytes the next layer IP headers are not fully added to skbuff that is they become short and i am repeatedly getting ip_hook : happy cracking message so where can i modify the total size of alloc_skb to satisfy my constraints for icmp header? i got one reference mail that some person has done adding his own header to ping packet and send it to other machine.he actually added that successfully. i am unable to contact him. might be his email address has been changed. regards, parag. "Rusty Russell" wrote: On Tue, 2004-04-27 at 01:12, Parag Nemade wrote: > hi, > i modified kernel so that it will create > /proc/net/myproc file entry. > the function of this entry is to crate a 16 byte char > string from random no.s > i used net_srandom and net_random and sys_time for > that puspose. the problem is that i write program to > generate string after 120 seconds but it is changing > contents of myproc file every seconds. what can i do? > Also i am getting ipt_hook: happy cracking. message > again and again why? You're sending out IP packets which don't even contain the IP header, and you're running connection tracking or some filtering. The message is not serious. Rusty. -- Anyone who quotes me in their signature is an idiot -- Rusty Russell - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From c-d.hailfinger.kernel.2004@gmx.net Fri Apr 30 04:43:56 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 04:44:00 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UBhtKO001519 for ; Fri, 30 Apr 2004 04:43:56 -0700 Received: (qmail 14507 invoked by uid 65534); 30 Apr 2004 11:43:50 -0000 Received: from stud213102.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.102) by mail.gmx.net (mp022) with SMTP; 30 Apr 2004 13:43:50 +0200 X-Authenticated: #21910825 Message-ID: <40923BE3.8060100@gmx.net> Date: Fri, 30 Apr 2004 13:43:31 +0200 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: de, en MIME-Version: 1.0 To: Simon Peter CC: netdev@oss.sgi.com Subject: Re: forcedeth received irq with unknown events References: <20040429143006.4f8b5df0.dn.tlp@gmx.net> <40910211.40301@gmx.net> In-Reply-To: <40910211.40301@gmx.net> Content-Type: multipart/mixed; boundary="------------060009060407000207050208" X-archive-position: 4983 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev This is a multi-part message in MIME format. --------------060009060407000207050208 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Carl-Daniel Hailfinger wrote: > Simon Peter wrote: > >>Hi there! >> >>Since i plugged the DSL-Modem directly to my onboard nForce2 network >>card (it's a Shuttle AN35-400 Mobo), i constantly get the following >>messages in my syslog: >> >>Apr 29 14:15:02 server kernel: eth0: received irq with unknown events >>0x1. Please report >>Apr 29 14:15:33 server last message repeated 28 times >>Apr 29 14:15:55 server last message repeated 23 times >> >>The message seems to be displaying more frequently the more traffic is >>on the link. > > > This 0x1 event is a receive error. It seems only users with cable modems > have this problem. I've got no idea why it happens with cable modems and > nothing else, but it could indeed be crappy hardware on the modem side. > > What we don't know yet is if the receive error is hard or soft. Soft > errors generally can be recovered from, so it would be a shame throwing > the packets away. > > >>Formerly, the nForce2 board was connected to a 100mbps switch to my LAN >>and i didn't get any of these messages. > > > Your switch didn't let the malformed/incorrect packets through, so you > computer didn't see them. > > > >>If you need any more info to get this fixed, just reply! > > > Could you please try the attached patch (will create LOTS of debug > messages) for a few minutes and mail the relevant part of your > /var/log/messages to me privately (it will be >100 kB, so I don't want to > burden the list with it). This time with a patch that actually should apply. (for both 2.4 and 2.6) The previous patch was obsolete since some functions were renamed for better backtraces. Thanks, Carl-Daniel -- http://www.hailfinger.org/ --------------060009060407000207050208 Content-Type: text/plain; name="forcedeth_0x1event_rx_patch3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="forcedeth_0x1event_rx_patch3.diff" ===== drivers/net/forcedeth.c 1.1 vs edited ===== --- 1.1/drivers/net/forcedeth.c Thu Feb 5 02:11:13 2004 +++ edited/drivers/net/forcedeth.c Tue Mar 2 21:04:06 2004 @@ -120,6 +120,7 @@ #define NVREG_IRQSTAT_MIIEVENT 0x040 #define NVREG_IRQSTAT_MASK 0x1ff NvRegIrqMask = 0x004, +#define NVREG_IRQ_RX_ERR 0x0001 #define NVREG_IRQ_RX 0x0002 #define NVREG_IRQ_RX_NOBUF 0x0004 #define NVREG_IRQ_TX_ERR 0x0008 @@ -129,7 +130,7 @@ #define NVREG_IRQ_TX1 0x0100 #define NVREG_IRQMASK_WANTED_1 0x005f #define NVREG_IRQMASK_WANTED_2 0x0147 -#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) +#define NVREG_IRQ_UNKNOWN (~(NVREG_IRQ_RX_ERR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_TX_ERR|NVREG_IRQ_TX2|NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_TX1)) NvRegUnknownSetupReg6 = 0x008, #define NVREG_UNKSETUP6_VAL 3 @@ -847,7 +848,7 @@ i = np->cur_rx % RX_RING; prd = &np->rx_ring[i]; - dprintk(KERN_DEBUG "%s: nv_rx_process: looking at packet %d, Flags 0x%x.\n", + printk(KERN_INFO "%s: nv_rx_process: looking at packet %d, Flags 0x%x.\n", dev->name, np->cur_rx, prd->Flags); if (prd->Flags & cpu_to_le16(NV_RX_AVAIL)) @@ -880,25 +881,30 @@ len = le16_to_cpu(prd->Length); if (prd->Flags & cpu_to_le16(NV_RX_MISSEDFRAME)) { + printk(KERN_INFO "%s: nv_rx_process: missed frame\n", dev->name); np->stats.rx_missed_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_ERROR1|NV_RX_ERROR2|NV_RX_ERROR3|NV_RX_ERROR4)) { + printk(KERN_INFO "%s: nv_rx_process: error 1-4\n", dev->name); np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_CRCERR)) { + printk(KERN_INFO "%s: nv_rx_process: crc error\n", dev->name); np->stats.rx_crc_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_OVERFLOW)) { + printk(KERN_INFO "%s: nv_rx_process: overflow\n", dev->name); np->stats.rx_over_errors++; np->stats.rx_errors++; goto next_pkt; } if (prd->Flags & cpu_to_le16(NV_RX_ERROR)) { + printk(KERN_INFO "%s: nv_rx_process: generic error\n", dev->name); /* framing errors are soft errors, the rest is fatal. */ if (prd->Flags & cpu_to_le16(NV_RX_FRAMINGERR)) { if (prd->Flags & cpu_to_le16(NV_RX_SUBSTRACT1)) { @@ -1096,7 +1102,7 @@ spin_unlock(&np->lock); } - if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF)) { + if (events & (NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_RX_ERR)) { nv_rx_process(dev); if (nv_alloc_rx(dev)) { spin_lock(&np->lock); @@ -1110,6 +1116,10 @@ spin_lock(&np->lock); nv_link_irq(dev); spin_unlock(&np->lock); + } + if (events & (NVREG_IRQ_RX_ERR)) { + printk(KERN_INFO "%s: received irq with events 0x%x. Probably RX fail. Trying to get diagnostics.\n", + dev->name, events); } if (events & (NVREG_IRQ_TX_ERR)) { dprintk(KERN_DEBUG "%s: received irq with events 0x%x. Probably TX fail.\n", --------------060009060407000207050208-- From c-d.hailfinger.kernel.2004@gmx.net Fri Apr 30 08:50:55 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 08:50:59 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UFosKO018080 for ; Fri, 30 Apr 2004 08:50:55 -0700 Received: (qmail 15294 invoked by uid 65534); 30 Apr 2004 15:50:48 -0000 Received: from stud213102.studentenheim.uni-tuebingen.de (EHLO gmx.net) (134.2.213.102) by mail.gmx.net (mp021) with SMTP; 30 Apr 2004 17:50:48 +0200 X-Authenticated: #21910825 Message-ID: <409275C5.8060008@gmx.net> Date: Fri, 30 Apr 2004 17:50:29 +0200 From: Carl-Daniel Hailfinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040114 X-Accept-Language: de, en MIME-Version: 1.0 To: Netdev Subject: dev_kfree_skb{,irq,any} Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 4984 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: c-d.hailfinger.kernel.2004@gmx.net Precedence: bulk X-list: netdev Hi, what are the possible implications of calling dev_kfree_skb_irq from non-interrupt context or calling dev_kfree_skb from interrupt context? Looking at drivers/net, it seems dev_kfree_skb_irq is often called outside an interrupt handler. IIRC, dev_kfree_skb_any is the way to go if a certain routine can be called both from interrupt context and outside it. Regards, Carl-Daniel -- http://www.hailfinger.org/ From niv@us.ibm.com Fri Apr 30 17:10:43 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:10:48 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410AbKO010742 for ; Fri, 30 Apr 2004 17:10:43 -0700 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i410AH87670644; Fri, 30 Apr 2004 20:10:17 -0400 Received: from us.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i410AFAq135688; Fri, 30 Apr 2004 18:10:15 -0600 Message-ID: <4092EAD7.5080207@us.ibm.com> Date: Fri, 30 Apr 2004 17:09:59 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: netdev@oss.sgi.com, Jan Olderdissen , David Miller Subject: [PATCH 2.6.5] Re: Fw: Stack sends SYN/ACKs even though accept queue is full Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4985 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev Andrew Morton wrote: >Begin forwarded message: > >Date: Thu, 29 Apr 2004 14:53:36 -0700 >From: Jan Olderdissen >To: "'linux-kernel@vger.kernel.org'" >Subject: Stack sends SYN/ACKs even though accept queue is full > Attaching a patch which adds a sysctl to turn off this behaviour. Could you test this, please? Patch against 2.6.5 vanilla kernel. If you need a 2.4 version, let me know. >Because newly accepted connections are considered 'young', two such >connections put on the synq will cause additional SYNs to be dropped until >young connections age and additional connections are SYN/ACKed , etc. Since >the initial TCP timeout is three seconds, you would expect two additional >connections to be accepted every three seconds. However, experiments with >2.4.25 show that number to be two connections every four seconds for unclear >reasons. > Normally, I think the expected behaviour was that connections would be short-lived. This is a reasonable expectation for most web-servers etc. In which case, the accept queue would free up frequently, and having the syn request right there would save a full timeout and round trip over the Internet. i.e. useful in the common case. I don't think it is worthwhile for environments where connections are long-lived and turnover is infrequent, added to a heavily congested network. I'd prefer to have this be a tunable option. thanks, Nivedita diff -urN linux-2.6.5/include/linux/sysctl.h linux-2.6.5synq/include/linux/sysctl.h --- linux-2.6.5/include/linux/sysctl.h 2004-04-03 19:37:23.000000000 -0800 +++ linux-2.6.5synq/include/linux/sysctl.h 2004-04-30 15:24:12.000000000 -0700 @@ -323,6 +323,7 @@ NET_IPV4_IPFRAG_SECRET_INTERVAL=94, NET_TCP_WESTWOOD=95, NET_IPV4_IGMP_MAX_MSF=96, + NET_TCP_PRELOAD_SYNQ=97, }; enum { diff -urN linux-2.6.5/include/net/tcp.h linux-2.6.5synq/include/net/tcp.h --- linux-2.6.5/include/net/tcp.h 2004-04-03 19:36:18.000000000 -0800 +++ linux-2.6.5synq/include/net/tcp.h 2004-04-30 13:55:18.000000000 -0700 @@ -583,6 +583,7 @@ extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; extern int sysctl_tcp_westwood; +extern int sysctl_tcp_preload_synq; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; diff -urN linux-2.6.5/net/ipv4/sysctl_net_ipv4.c linux-2.6.5synq/net/ipv4/sysctl_net_ipv4.c --- linux-2.6.5/net/ipv4/sysctl_net_ipv4.c 2004-04-03 19:37:37.000000000 -0800 +++ linux-2.6.5synq/net/ipv4/sysctl_net_ipv4.c 2004-04-30 16:16:57.000000000 -0700 @@ -601,6 +601,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_PRELOAD_SYNQ, + .procname = "tcp_preload_synq", + .data = &sysctl_tcp_preload_synq, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -urN linux-2.6.5/net/ipv4/tcp_ipv4.c linux-2.6.5synq/net/ipv4/tcp_ipv4.c --- linux-2.6.5/net/ipv4/tcp_ipv4.c 2004-04-03 19:36:55.000000000 -0800 +++ linux-2.6.5synq/net/ipv4/tcp_ipv4.c 2004-04-30 15:51:38.000000000 -0700 @@ -78,6 +78,7 @@ extern int sysctl_ip_dynaddr; int sysctl_tcp_tw_reuse; int sysctl_tcp_low_latency; +int sysctl_tcp_preload_synq = 1; /* Check TCP sequence numbers in ICMP packets. */ #define ICMP_MIN_LENGTH 8 @@ -1442,8 +1443,11 @@ * clogging syn queue with openreqs with exponentially increasing * timeout. */ - if (tcp_acceptq_is_full(sk) && tcp_synq_young(sk) > 1) - goto drop; + if (tcp_acceptq_is_full(sk)) { + if (!sysctl_tcp_preload_synq || + (sysctl_tcp_preload_synq && (tcp_synq_young(sk) > 1))) + goto drop; + } req = tcp_openreq_alloc(); if (!req) @@ -2683,4 +2687,5 @@ EXPORT_SYMBOL(sysctl_local_port_range); EXPORT_SYMBOL(sysctl_max_syn_backlog); EXPORT_SYMBOL(sysctl_tcp_low_latency); +EXPORT_SYMBOL(sysctl_tcp_preload_synq); #endif From romieu@fr.zoreil.com Fri Apr 30 17:24:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:24:57 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410OiKO011151 for ; Fri, 30 Apr 2004 17:24:45 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410OduX000504; Sat, 1 May 2004 02:24:39 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410Odbs000503; Sat, 1 May 2004 02:24:39 +0200 Date: Sat, 1 May 2004 02:24:39 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 1/7] 2.6.6-rc3-mm1 - r8169 napi Message-ID: <20040501022439.A500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022308.A32762@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:23:08AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4986 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Napi for r8169 (Jon D Mason ). Both Tx and Rx processing are moved to the ->poll() function. diff -puN drivers/net/r8169.c~r8169-napi drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-napi 2004-05-01 01:46:29.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:29.000000000 +0200 @@ -64,6 +64,14 @@ VERSION 1.2 <2002/11/30> #define dprintk(fmt, args...) do {} while (0) #endif /* RTL8169_DEBUG */ +#ifdef CONFIG_R8169_NAPI +#define rtl8169_rx_skb netif_receive_skb +#define rtl8169_rx_quota(count, quota) min(count, quota) +#else +#define rtl8169_rx_skb netif_rx +#define rtl8169_rx_quota(count, quota) count +#endif + /* media options */ #define MAX_UNITS 8 static int media[MAX_UNITS] = { -1, -1, -1, -1, -1, -1, -1, -1 }; @@ -90,8 +98,9 @@ static int multicast_filter_limit = 32; #define RxPacketMaxSize 0x0800 /* Maximum size supported is 16K-1 */ #define InterFrameGap 0x03 /* 3 means InterFrameGap = the shortest one */ +#define R8169_NAPI_WEIGHT 64 #define NUM_TX_DESC 64 /* Number of Tx descriptor registers */ -#define NUM_RX_DESC 64 /* Number of Rx descriptor registers */ +#define NUM_RX_DESC 256 /* Number of Rx descriptor registers */ #define RX_BUF_SIZE 1536 /* Rx Buffer size */ #define R8169_TX_RING_BYTES (NUM_TX_DESC * sizeof(struct TxDesc)) #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc)) @@ -326,6 +335,7 @@ struct rtl8169_private { struct timer_list timer; unsigned long phy_link_down_cnt; u16 cp_cmd; + u16 intr_mask; }; MODULE_AUTHOR("Realtek"); @@ -344,9 +354,14 @@ static int rtl8169_close(struct net_devi static void rtl8169_set_rx_mode(struct net_device *dev); static void rtl8169_tx_timeout(struct net_device *dev); static struct net_device_stats *rtl8169_get_stats(struct net_device *netdev); +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget); +#endif static const u16 rtl8169_intr_mask = - RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; +static const u16 rtl8169_napi_event = + RxOK | RxUnderrun | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); @@ -836,9 +851,12 @@ rtl8169_init_one(struct pci_dev *pdev, c dev->watchdog_timeo = RTL8169_TX_TIMEOUT; dev->irq = pdev->irq; dev->base_addr = (unsigned long) ioaddr; -// dev->do_ioctl = mii_ioctl; - - tp = dev->priv; // private data // +#ifdef CONFIG_R8169_NAPI + dev->poll = rtl8169_poll; + dev->weight = R8169_NAPI_WEIGHT; + printk(KERN_INFO PFX "NAPI enabled\n"); +#endif + tp->intr_mask = 0xffff; tp->pci_dev = pdev; tp->mmio_addr = ioaddr; @@ -1442,11 +1460,11 @@ static inline int rtl8169_try_rx_copy(st return ret; } -static void +static int rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void *ioaddr) { - unsigned long cur_rx, rx_left; + unsigned int cur_rx, rx_left, count; int delta; assert(dev != NULL); @@ -1455,6 +1473,7 @@ rtl8169_rx_interrupt(struct net_device * cur_rx = tp->cur_rx; rx_left = NUM_RX_DESC + tp->dirty_rx - cur_rx; + rx_left = rtl8169_rx_quota(rx_left, (u32) dev->quota); while (rx_left > 0) { int entry = cur_rx % NUM_RX_DESC; @@ -1494,7 +1513,7 @@ rtl8169_rx_interrupt(struct net_device * skb_put(skb, pkt_size); skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); + rtl8169_rx_skb(skb); dev->last_rx = jiffies; tp->stats.rx_bytes += pkt_size; @@ -1505,13 +1524,15 @@ rtl8169_rx_interrupt(struct net_device * rx_left--; } + count = cur_rx - tp->cur_rx; tp->cur_rx = cur_rx; delta = rtl8169_rx_fill(tp, dev, tp->dirty_rx, tp->cur_rx); - if (delta > 0) - tp->dirty_rx += delta; - else if (delta < 0) + if (delta < 0) { printk(KERN_INFO "%s: no Rx buffer allocated\n", dev->name); + delta = 0; + } + tp->dirty_rx += delta; /* * FIXME: until there is periodic timer to try and refill the ring, @@ -1522,6 +1543,8 @@ rtl8169_rx_interrupt(struct net_device * */ if (tp->dirty_rx + NUM_RX_DESC == tp->cur_rx) printk(KERN_EMERG "%s: Rx buffers exhausted\n", dev->name); + + return count; } /* The interrupt handler does all of the Rx thread work and cleans up after the Tx thread. */ @@ -1547,12 +1570,25 @@ rtl8169_interrupt(int irq, void *dev_ins if (status & RxUnderrun) link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit; */ + status &= tp->intr_mask; RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); if (!(status & rtl8169_intr_mask)) break; +#ifdef CONFIG_R8169_NAPI + RTL_W16(IntrMask, rtl8169_intr_mask & ~rtl8169_napi_event); + tp->intr_mask = ~rtl8169_napi_event; + + if (likely(netif_rx_schedule_prep(dev))) + __netif_rx_schedule(dev); + else { + printk(KERN_INFO "%s: interrupt %x taken in poll\n", + dev->name, status); + } + break; +#else // Rx interrupt if (status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); @@ -1563,6 +1599,7 @@ rtl8169_interrupt(int irq, void *dev_ins rtl8169_tx_interrupt(dev, tp, ioaddr); spin_unlock(&tp->lock); } +#endif boguscnt--; } while (boguscnt > 0); @@ -1576,6 +1613,36 @@ rtl8169_interrupt(int irq, void *dev_ins return IRQ_RETVAL(handled); } +#ifdef CONFIG_R8169_NAPI +static int rtl8169_poll(struct net_device *dev, int *budget) +{ + unsigned int work_done, work_to_do = min(*budget, dev->quota); + struct rtl8169_private *tp = netdev_priv(dev); + void *ioaddr = tp->mmio_addr; + + work_done = rtl8169_rx_interrupt(dev, tp, ioaddr); + rtl8169_tx_interrupt(dev, tp, ioaddr); + + *budget -= work_done; + dev->quota -= work_done; + + if ((work_done < work_to_do) || !netif_running(dev)) { + netif_rx_complete(dev); + tp->intr_mask = 0xffff; + /* + * 20040426: the barrier is not strictly required but the + * behavior of the irq handler could be less predictable + * without it. Btw, the lack of flush for the posted pci + * write is safe - FR + */ + smp_wmb(); + RTL_W16(IntrMask, rtl8169_intr_mask); + } + + return (work_done >= work_to_do); +} +#endif + static int rtl8169_close(struct net_device *dev) { diff -puN drivers/net/Kconfig~r8169-napi drivers/net/Kconfig --- linux-2.6.6-rc3/drivers/net/Kconfig~r8169-napi 2004-05-01 01:46:29.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/Kconfig 2004-05-01 01:46:29.000000000 +0200 @@ -1979,6 +1979,11 @@ config R8169 To compile this driver as a module, choose M here: the module will be called r8169. This is recommended. +config R8169_NAPI + bool "Use Rx and Tx Polling (NAPI) (EXPERIMENTAL)" + depends on R8169 && EXPERIMENTAL + + config SK98LIN tristate "Marvell Yukon Chipset / SysKonnect SK-98xx Support" depends on PCI _ From romieu@fr.zoreil.com Fri Apr 30 17:24:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:24:57 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410OiKO011150 for ; Fri, 30 Apr 2004 17:24:45 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410NAuX000499; Sat, 1 May 2004 02:23:10 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410N83b000498; Sat, 1 May 2004 02:23:08 +0200 Date: Sat, 1 May 2004 02:23:08 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 0/7] 2.6.6-rc3-mm1 - description of the r8169 queue Message-ID: <20040501022308.A32762@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Organisation: Land of Sunshine Inc. X-archive-position: 4987 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev With some delay, the following patches include Jon D Mason's NAPI changes (+ fixes) and code from Andy Lutomirski with minor changes. I have not moved the initialization of the phy timer in the pci probe routine as: - I believe it belongs to the netdevice; - it should work as is without significant change for the user. If someone sees a good reason to move it, just complain (with an axe). The patches apply to 2.6.6-rc3 as well as to 2.6.6-rc3-mm1. All the patches are merged in a single patch against 2.6.6-rc3 available at: http://www.fr.zoreil.com/people/francois/misc/20040501-2.6.6-rc3-r8169.c-test.patch The patches are archived below as well: http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.6-rc3 If the patches prove to behave decently on 2.6, a backport for 2.4.x will be generated. -- Ueimor From romieu@fr.zoreil.com Fri Apr 30 17:28:48 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:28:54 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410SjKO011874 for ; Fri, 30 Apr 2004 17:28:46 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410PruX000544; Sat, 1 May 2004 02:25:53 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410PqAW000543; Sat, 1 May 2004 02:25:52 +0200 Date: Sat, 1 May 2004 02:25:52 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 2/7] 2.6.6-rc3-mm1 - r8169 janitoring Message-ID: <20040501022552.B500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022439.A500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:24:39AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4989 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Spring cleanup - missing ULL qualifier; - unsigned int (u32) should be slightly faster on ppc64 (Jon D Mason); - misc minor de-uglyfication. diff -puN drivers/net/r8169.c~r8169-janitorial drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-janitorial 2004-05-01 01:46:31.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:31.000000000 +0200 @@ -315,10 +315,10 @@ struct RxDesc { }; struct rtl8169_private { - void *mmio_addr; /* memory map physical address */ + void *mmio_addr; /* memory map physical address */ struct pci_dev *pci_dev; /* Index of PCI device */ struct net_device_stats stats; /* statistics of net device */ - spinlock_t lock; /* spin lock flag */ + spinlock_t lock; /* spin lock flag */ int chipset; int mac_version; int phy_version; @@ -326,12 +326,12 @@ struct rtl8169_private { u32 cur_tx; /* Index into the Tx descriptor buffer of next Rx pkt. */ u32 dirty_rx; u32 dirty_tx; - struct TxDesc *TxDescArray; /* Index of 256-alignment Tx Descriptor buffer */ - struct RxDesc *RxDescArray; /* Index of 256-alignment Rx Descriptor buffer */ + struct TxDesc *TxDescArray; /* 256-aligned Tx descriptor ring */ + struct RxDesc *RxDescArray; /* 256-aligned Rx descriptor ring */ dma_addr_t TxPhyAddr; dma_addr_t RxPhyAddr; struct sk_buff *Rx_skbuff[NUM_RX_DESC]; /* Rx data buffers */ - struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Index of Transmit data buffer */ + struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Tx data buffers */ struct timer_list timer; unsigned long phy_link_down_cnt; u16 cp_cmd; @@ -379,11 +379,9 @@ static void mdio_write(void *ioaddr, int for (i = 2000; i > 0; i--) { // Check if the RTL8169 has completed writing to the specified MII register - if (!(RTL_R32(PHYAR) & 0x80000000)) { + if (!(RTL_R32(PHYAR) & 0x80000000)) break; - } else { - udelay(100); - } + udelay(100); } } @@ -408,7 +406,7 @@ static int mdio_read(void *ioaddr, int R static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); strcpy(info->driver, RTL8169_DRIVER_NAME); strcpy(info->version, RTL8169_VERSION ); @@ -515,7 +513,7 @@ static void rtl8169_print_phy_version(st static void rtl8169_hw_phy_config(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; struct { u16 regs[5]; /* Beware of bit-sign propagation */ @@ -583,7 +581,7 @@ static void rtl8169_hw_phy_config(struct static void rtl8169_hw_phy_reset(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; int i, val; @@ -607,7 +605,7 @@ static void rtl8169_hw_phy_reset(struct static void rtl8169_phy_timer(unsigned long __opaque) { struct net_device *dev = (struct net_device *)__opaque; - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); struct timer_list *timer = &tp->timer; void *ioaddr = tp->mmio_addr; @@ -635,7 +633,7 @@ static void rtl8169_phy_timer(unsigned l static inline void rtl8169_delete_timer(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || @@ -649,7 +647,7 @@ static inline void rtl8169_delete_timer( static inline void rtl8169_request_timer(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); struct timer_list *timer = &tp->timer; if ((tp->mac_version <= RTL_GIGA_MAC_VER_B) || @@ -696,7 +694,7 @@ rtl8169_init_board(struct pci_dev *pdev, // enable device (incl. PCI PM wakeup and hotplug setup) rc = pci_enable_device(pdev); if (rc) { - printk(KERN_ERR PFX "%s: unable to enable device\n", pdev->slot_name); + printk(KERN_ERR PFX "%s: enable failure\n", pdev->slot_name); goto err_out; } @@ -708,7 +706,8 @@ rtl8169_init_board(struct pci_dev *pdev, pci_read_config_word(pdev, pm_cap + PCI_PM_CTRL, &pwr_command); acpi_idle_state = pwr_command & PCI_PM_CTRL_STATE_MASK; } else { - printk(KERN_ERR PFX "Cannot find PowerManagement capability, aborting.\n"); + printk(KERN_ERR PFX + "Cannot find PowerManagement capability, aborting.\n"); goto err_out_free_res; } @@ -733,7 +732,8 @@ rtl8169_init_board(struct pci_dev *pdev, rc = pci_request_regions(pdev, dev->name); if (rc) { - printk(KERN_ERR PFX "%s: Could not request regions.\n", pdev->slot_name); + printk(KERN_ERR PFX "%s: could not request regions.\n", + pdev->slot_name); goto err_out_disable; } @@ -937,13 +937,16 @@ rtl8169_init_one(struct pci_dev *pdev, c default: break; } - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, Cap10_100 | (val & 0x1F)); //leave PHY_AUTO_NEGO_REG bit4:0 unchanged + // leave PHY_AUTO_NEGO_REG bit4:0 unchanged + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, + Cap10_100 | (val & 0x1F)); mdio_write(ioaddr, PHY_1000_CTRL_REG, Cap1000); } else { printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", dev->name); - // enable 10/100 Full/Half Mode, leave PHY_AUTO_NEGO_REG bit4:0 unchanged + // enable 10/100 Full/Half Mode + // leave PHY_AUTO_NEGO_REG bit4:0 unchanged mdio_write(ioaddr, PHY_AUTO_NEGO_REG, PHY_Cap_100_Full_Or_Less | (val & 0x1f)); @@ -982,7 +985,7 @@ rtl8169_init_one(struct pci_dev *pdev, c } else { udelay(100); } - } // end for-loop to wait for auto-negotiation process + } // end for-loop to wait for auto-negotiation process } else { udelay(100); @@ -990,7 +993,6 @@ rtl8169_init_one(struct pci_dev *pdev, c "%s: 1000Mbps Full-duplex operation, TBI Link %s!\n", dev->name, (RTL_R32(TBICSR) & TBILinkOK) ? "OK" : "Failed"); - } return 0; @@ -1000,7 +1002,7 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev) { struct net_device *dev = pci_get_drvdata(pdev); - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); assert(dev != NULL); assert(tp != NULL); @@ -1019,7 +1021,7 @@ rtl8169_remove_one(struct pci_dev *pdev) static int rtl8169_suspend(struct pci_dev *pdev, u32 state) { struct net_device *dev = pci_get_drvdata(pdev); - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned long flags; @@ -1060,7 +1062,7 @@ static int rtl8169_resume(struct pci_dev static int rtl8169_open(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); struct pci_dev *pdev = tp->pci_dev; int retval; @@ -1109,7 +1111,7 @@ err_free_irq: static void rtl8169_hw_start(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; u32 i; @@ -1120,8 +1122,7 @@ rtl8169_hw_start(struct net_device *dev) for (i = 1000; i > 0; i--) { if ((RTL_R8(ChipCmd) & CmdReset) == 0) break; - else - udelay(10); + udelay(10); } RTL_W8(Cfg9346, Cfg9346_Unlock); @@ -1132,8 +1133,8 @@ rtl8169_hw_start(struct net_device *dev) RTL_W16(RxMaxSize, RxPacketMaxSize); // Set Rx Config register - i = rtl8169_rx_config | (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset]. - RxConfigMask); + i = rtl8169_rx_config | + (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); RTL_W32(RxConfig, i); /* Set DMA burst size and Interframe Gap Time */ @@ -1144,7 +1145,8 @@ rtl8169_hw_start(struct net_device *dev) RTL_W16(CPlusCmd, tp->cp_cmd); if (tp->mac_version == RTL_GIGA_MAC_VER_D) { - dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0: bit-3 and bit-14 MUST be 1\n"); + dprintk(KERN_INFO PFX "Set MAC Reg C+CR Offset 0xE0. " + "Bit-3 and bit-14 MUST be 1\n"); tp->cp_cmd |= (1 << 14) | PCIMulRW; RTL_W16(CPlusCmd, tp->cp_cmd); } @@ -1169,12 +1171,11 @@ rtl8169_hw_start(struct net_device *dev) RTL_W16(IntrMask, rtl8169_intr_mask); netif_start_queue(dev); - } static inline void rtl8169_make_unusable_by_asic(struct RxDesc *desc) { - desc->addr = 0x0badbadbadbadbad; + desc->addr = 0x0badbadbadbadbadULL; desc->status &= ~cpu_to_le32(OWNbit | RsvdMask); } @@ -1266,7 +1267,7 @@ static inline void rtl8169_mark_as_last_ static int rtl8169_init_ring(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); tp->cur_rx = tp->dirty_rx = 0; tp->cur_tx = tp->dirty_tx = 0; @@ -1320,10 +1321,11 @@ rtl8169_tx_clear(struct rtl8169_private static void rtl8169_tx_timeout(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; u8 tmp8; + printk(KERN_INFO "%s: TX Timeout\n", dev->name); /* disable Tx, if not already */ tmp8 = RTL_R8(ChipCmd); if (tmp8 & CmdTxEnb) @@ -1346,9 +1348,9 @@ rtl8169_tx_timeout(struct net_device *de static int rtl8169_start_xmit(struct sk_buff *skb, struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; - int entry = tp->cur_tx % NUM_TX_DESC; + unsigned int entry = tp->cur_tx % NUM_TX_DESC; u32 len = skb->len; if (unlikely(skb->len < ETH_ZLEN)) { @@ -1400,7 +1402,7 @@ static void rtl8169_tx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void *ioaddr) { - unsigned long dirty_tx, tx_left; + unsigned int dirty_tx, tx_left; assert(dev != NULL); assert(tp != NULL); @@ -1410,7 +1412,7 @@ rtl8169_tx_interrupt(struct net_device * tx_left = tp->cur_tx - dirty_tx; while (tx_left > 0) { - int entry = dirty_tx % NUM_TX_DESC; + unsigned int entry = dirty_tx % NUM_TX_DESC; struct sk_buff *skb = tp->Tx_skbuff[entry]; u32 status; @@ -1476,7 +1478,7 @@ rtl8169_rx_interrupt(struct net_device * rx_left = rtl8169_rx_quota(rx_left, (u32) dev->quota); while (rx_left > 0) { - int entry = cur_rx % NUM_RX_DESC; + unsigned int entry = cur_rx % NUM_RX_DESC; u32 status; rmb(); @@ -1552,7 +1554,7 @@ static irqreturn_t rtl8169_interrupt(int irq, void *dev_instance, struct pt_regs *regs) { struct net_device *dev = (struct net_device *) dev_instance; - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); int boguscnt = max_interrupt_work; void *ioaddr = tp->mmio_addr; int status = 0; @@ -1646,7 +1648,7 @@ static int rtl8169_poll(struct net_devic static int rtl8169_close(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); struct pci_dev *pdev = tp->pci_dev; void *ioaddr = tp->mmio_addr; @@ -1688,7 +1690,7 @@ rtl8169_close(struct net_device *dev) static void rtl8169_set_rx_mode(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned long flags; u32 mc_filter[2]; /* Multicast hash filter */ @@ -1722,10 +1724,8 @@ rtl8169_set_rx_mode(struct net_device *d spin_lock_irqsave(&tp->lock, flags); - tmp = - rtl8169_rx_config | rx_mode | (RTL_R32(RxConfig) & - rtl_chip_info[tp->chipset]. - RxConfigMask); + tmp = rtl8169_rx_config | rx_mode | + (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); RTL_W32(RxConfig, tmp); RTL_W32(MAR0 + 0, mc_filter[0]); @@ -1742,7 +1742,7 @@ rtl8169_set_rx_mode(struct net_device *d */ static struct net_device_stats *rtl8169_get_stats(struct net_device *dev) { - struct rtl8169_private *tp = dev->priv; + struct rtl8169_private *tp = netdev_priv(dev); void *ioaddr = tp->mmio_addr; unsigned long flags; _ From romieu@fr.zoreil.com Fri Apr 30 17:28:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:28:52 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410SjKO011873 for ; Fri, 30 Apr 2004 17:28:46 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410QtuX000549; Sat, 1 May 2004 02:26:55 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410QsjJ000548; Sat, 1 May 2004 02:26:54 +0200 Date: Sat, 1 May 2004 02:26:54 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 3/7] 2.6.6-rc3-mm1 - r8169 register rename Message-ID: <20040501022654.C500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> <20040501022552.B500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022552.B500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:25:52AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4988 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev RxUnderrun status bit renamed to LinkChg (identical to the 8139cp driver). diff -puN drivers/net/r8169.c~r8169-register-rename drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-register-rename 2004-05-01 01:46:33.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:33.000000000 +0200 @@ -203,7 +203,7 @@ enum RTL8169_register_content { SWInt = 0x0100, TxDescUnavail = 0x80, RxFIFOOver = 0x40, - RxUnderrun = 0x20, + LinkChg = 0x20, RxOverflow = 0x10, TxErr = 0x08, TxOK = 0x04, @@ -359,9 +359,9 @@ static int rtl8169_poll(struct net_devic #endif static const u16 rtl8169_intr_mask = - RxUnderrun | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; + LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = - RxOK | RxUnderrun | RxOverflow | RxFIFOOver | TxOK | TxErr; + RxOK | LinkChg | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); @@ -1569,7 +1569,7 @@ rtl8169_interrupt(int irq, void *dev_ins handled = 1; /* - if (status & RxUnderrun) + if (status & LinkChg) link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit; */ status &= tp->intr_mask; @@ -1592,7 +1592,7 @@ rtl8169_interrupt(int irq, void *dev_ins break; #else // Rx interrupt - if (status & (RxOK | RxUnderrun | RxOverflow | RxFIFOOver)) { + if (status & (RxOK | LinkChg | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt _ From romieu@fr.zoreil.com Fri Apr 30 17:28:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:28:55 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410SjKO011872 for ; Fri, 30 Apr 2004 17:28:46 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410S8uX000553; Sat, 1 May 2004 02:28:08 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410S8pO000552; Sat, 1 May 2004 02:28:08 +0200 Date: Sat, 1 May 2004 02:28:08 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 4/7] 2.6.6-rc3-mm1 - r8169 ethtool .set_settings Message-ID: <20040501022808.D500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> <20040501022552.B500@electric-eye.fr.zoreil.com> <20040501022654.C500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022654.C500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:26:54AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4990 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev ethtool set_settings support (Andy Lutomirski ). diff -puN drivers/net/r8169.c~r8169-ethtool-set_settings drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-ethtool-set_settings 2004-05-01 01:46:36.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:36.000000000 +0200 @@ -413,8 +413,68 @@ static void rtl8169_get_drvinfo(struct n strcpy(info->bus_info, pci_name(tp->pci_dev)); } +static void rtl8169_set_speed(struct net_device *dev, + u8 autoneg, u16 speed, u8 duplex) +{ + struct rtl8169_private *tp = netdev_priv(dev); + void *ioaddr = tp->mmio_addr; + int auto_nego, giga_ctrl; + u8 status; + + status = RTL_R8(PHYstatus); + if ((status & TBI_Enable) && (autoneg == AUTONEG_DISABLE)) { + autoneg = AUTONEG_ENABLE; + printk(KERN_WARNING PFX + "%s: ignoring request to force speed in TBI mode\n", + dev->name); + } + + auto_nego = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); + auto_nego &= ~(PHY_Cap_10_Half | PHY_Cap_10_Full | + PHY_Cap_100_Half | PHY_Cap_100_Full); + giga_ctrl = mdio_read(ioaddr, PHY_1000_CTRL_REG); + giga_ctrl &= ~(PHY_Cap_1000_Full | PHY_Cap_Null); + + if (autoneg == AUTONEG_ENABLE) { + auto_nego |= (PHY_Cap_10_Half | PHY_Cap_10_Full | + PHY_Cap_100_Half | PHY_Cap_100_Full); + giga_ctrl |= PHY_Cap_1000_Full; + } else { + if (speed == SPEED_10) + auto_nego |= PHY_Cap_10_Half | PHY_Cap_10_Full; + else if (speed == SPEED_100) + auto_nego |= PHY_Cap_100_Half | PHY_Cap_100_Full; + else if (speed == SPEED_1000) + giga_ctrl |= PHY_Cap_1000_Full; + + if (duplex == DUPLEX_HALF) + auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); + } + + if (!(status & TBI_Enable)) { + mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); + mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); + } + + mdio_write(ioaddr, PHY_CTRL_REG, + PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); +} + +static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct rtl8169_private *tp = netdev_priv(dev); + unsigned long flags; + + spin_lock_irqsave(&tp->lock, flags); + rtl8169_set_speed(dev, cmd->autoneg, cmd->speed, cmd->duplex); + spin_unlock_irqrestore(&tp->lock, flags); + + return 0; +} + static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, + .set_settings = rtl8169_set_settings, }; static void rtl8169_write_gmii_reg_bit(void *ioaddr, int reg, int bitnum, _ From romieu@fr.zoreil.com Fri Apr 30 17:32:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:32:55 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410WjKO012866 for ; Fri, 30 Apr 2004 17:32:46 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410VUuX000691; Sat, 1 May 2004 02:31:30 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410VTj1000690; Sat, 1 May 2004 02:31:29 +0200 Date: Sat, 1 May 2004 02:31:29 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 7/7] 2.6.6-rc3-mm1 - r8169 link handling rework (2/2) Message-ID: <20040501023129.G500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> <20040501022552.B500@electric-eye.fr.zoreil.com> <20040501022654.C500@electric-eye.fr.zoreil.com> <20040501022808.D500@electric-eye.fr.zoreil.com> <20040501022907.E500@electric-eye.fr.zoreil.com> <20040501023045.F500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501023045.F500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:30:45AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4993 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Use rtl8169_set_speed() for link setup in rtl8169_init_one(): - the code whic handles the option checking is isolated; - display (once) a notice message about the deprecated interface; - rtl8169_open() enables the phy timer if the link is not up; - rtl8169_set_speed() checks that the netdevice is actually ready in order to activate the timer. diff -puN drivers/net/r8169.c~r8169-link-10 drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-link-10 2004-05-01 01:46:42.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:42.000000000 +0200 @@ -7,7 +7,7 @@ Feb 4 2002 - created initially by ShuChen . May 20 2002 - Add link status force-mode and TBI mode support. ========================================================================= - 1. The media can be forced in 5 modes. + 1. [DEPRECATED: use ethtool instead] The media can be forced in 5 modes. Command: 'insmod r8169 media = SET_MEDIA' Ex: 'insmod r8169 media = 0x04' will force PHY to operate in 100Mpbs Half-duplex. @@ -432,6 +432,37 @@ static void rtl8169_check_link_status(st spin_unlock_irqrestore(&tp->lock, flags); } +static void rtl8169_link_option(int idx, u8 *autoneg, u16 *speed, u8 *duplex) +{ + struct { + u16 speed; + u8 duplex; + u8 autoneg; + u8 media; + } link_settings[] = { + { SPEED_10, DUPLEX_HALF, AUTONEG_DISABLE, _10_Half }, + { SPEED_10, DUPLEX_FULL, AUTONEG_DISABLE, _10_Full }, + { SPEED_100, DUPLEX_HALF, AUTONEG_DISABLE, _100_Half }, + { SPEED_100, DUPLEX_FULL, AUTONEG_DISABLE, _100_Full }, + { SPEED_1000, DUPLEX_FULL, AUTONEG_DISABLE, _1000_Full }, + { SPEED_1000, DUPLEX_FULL, AUTONEG_ENABLE, 0xff } + }, *p; + unsigned char option; + + option = ((idx < MAX_UNITS) && (idx >= 0)) ? media[idx] : 0xff; + + if ((option != 0xff) && !idx) + printk(KERN_WARNING PFX "media option is deprecated.\n"); + + for (p = link_settings; p->media != 0xff; p++) { + if (p->media == option) + break; + } + *autoneg = p->autoneg; + *speed = p->speed; + *duplex = p->duplex; +} + static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { @@ -491,7 +522,7 @@ static void rtl8169_set_speed(struct net mdio_write(ioaddr, PHY_CTRL_REG, PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); - if (giga_ctrl & PHY_Cap_1000_Full) + if (netif_running(dev) && (giga_ctrl & PHY_Cap_1000_Full)) mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); } @@ -957,8 +988,9 @@ rtl8169_init_one(struct pci_dev *pdev, c void *ioaddr = NULL; static int board_idx = -1; static int printed_version = 0; + u8 autoneg, duplex; + u16 speed; int i, rc; - int option = -1, Cap10_100 = 0, Cap1000 = 0; assert(pdev != NULL); assert(ent != NULL); @@ -1045,91 +1077,11 @@ rtl8169_init_one(struct pci_dev *pdev, c mdio_write(ioaddr, 0x0b, 0x0000); //w 0x0b 15 0 0 } - // if TBI is not endbled - if (!(RTL_R8(PHYstatus) & TBI_Enable)) { - int val = mdio_read(ioaddr, PHY_AUTO_NEGO_REG); - - option = (board_idx >= MAX_UNITS) ? 0 : media[board_idx]; - // Force RTL8169 in 10/100/1000 Full/Half mode. - if (option > 0) { - printk(KERN_INFO "%s: Force-mode Enabled.\n", - dev->name); - Cap10_100 = 0, Cap1000 = 0; - switch (option) { - case _10_Half: - Cap10_100 = PHY_Cap_10_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _10_Full: - Cap10_100 = PHY_Cap_10_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Half: - Cap10_100 = PHY_Cap_100_Half_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _100_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_Null; - break; - case _1000_Full: - Cap10_100 = PHY_Cap_100_Full_Or_Less; - Cap1000 = PHY_Cap_1000_Full; - break; - default: - break; - } - // leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, - Cap10_100 | (val & 0x1F)); - mdio_write(ioaddr, PHY_1000_CTRL_REG, Cap1000); - } else { - printk(KERN_INFO "%s: Auto-negotiation Enabled.\n", - dev->name); - - // enable 10/100 Full/Half Mode - // leave PHY_AUTO_NEGO_REG bit4:0 unchanged - mdio_write(ioaddr, PHY_AUTO_NEGO_REG, - PHY_Cap_100_Full_Or_Less | (val & 0x1f)); - - // enable 1000 Full Mode - mdio_write(ioaddr, PHY_1000_CTRL_REG, - PHY_Cap_1000_Full); - - } - - // Enable auto-negotiation and restart auto-nigotiation - mdio_write(ioaddr, PHY_CTRL_REG, - PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); - udelay(100); + rtl8169_link_option(board_idx, &autoneg, &speed, &duplex); - // wait for auto-negotiation process - for (i = 10000; i > 0; i--) { - //check if auto-negotiation complete - if (mdio_read(ioaddr, PHY_STAT_REG) & - PHY_Auto_Neco_Comp) { - udelay(100); - option = RTL_R8(PHYstatus); - if (option & _1000bpsF) { - printk(KERN_INFO - "%s: 1000Mbps Full-duplex operation.\n", - dev->name); - } else { - printk(KERN_INFO - "%s: %sMbps %s-duplex operation.\n", - dev->name, - (option & _100bps) ? "100" : - "10", - (option & FullDup) ? "Full" : - "Half"); - } - break; - } else { - udelay(100); - } - } // end for-loop to wait for auto-negotiation process - - } else { + rtl8169_set_speed(dev, autoneg, speed, duplex); + + if (RTL_R8(PHYstatus) & TBI_Enable) { udelay(100); printk(KERN_INFO "%s: 1000Mbps Full-duplex operation, TBI Link %s!\n", @@ -1236,6 +1188,8 @@ rtl8169_open(struct net_device *dev) rtl8169_hw_start(dev); rtl8169_request_timer(dev); + + rtl8169_check_link_status(dev, tp, tp->mmio_addr); out: return retval; _ From romieu@fr.zoreil.com Fri Apr 30 17:32:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:32:53 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410WiKO012865 for ; Fri, 30 Apr 2004 17:32:45 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410UjuX000686; Sat, 1 May 2004 02:30:45 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410Ujgj000685; Sat, 1 May 2004 02:30:45 +0200 Date: Sat, 1 May 2004 02:30:45 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 6/7] 2.6.6-rc3-mm1 - r8169 link handling rework (1/2) Message-ID: <20040501023045.F500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> <20040501022552.B500@electric-eye.fr.zoreil.com> <20040501022654.C500@electric-eye.fr.zoreil.com> <20040501022808.D500@electric-eye.fr.zoreil.com> <20040501022907.E500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022907.E500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:29:07AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4992 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev Link handling changes (Andy Lutomirski ): - the LinkChg irq enables the phy timer when the link goes down; - the phy timer is enabled in rtl8169_set_speed() to protect against link negociation failure; - removed rtl8169_hw_phy_reset() and its busy loop; - added spinlocking in timer context for rtl8169_phy_timer to avoid messing with the {set/get}_settings commands issued via ethtool. diff -puN drivers/net/r8169.c~r8169-link-00 drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-link-00 2004-05-01 01:46:40.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:40.000000000 +0200 @@ -41,6 +41,7 @@ VERSION 1.2 <2002/11/30> #include #include #include +#include #include #include #include @@ -333,7 +334,8 @@ struct rtl8169_private { struct sk_buff *Rx_skbuff[NUM_RX_DESC]; /* Rx data buffers */ struct sk_buff *Tx_skbuff[NUM_TX_DESC]; /* Tx data buffers */ struct timer_list timer; - unsigned long phy_link_down_cnt; + unsigned int phy_tried_renegotiate; + unsigned int phy_reset_warned; u16 cp_cmd; u16 intr_mask; int phy_auto_nego_reg; @@ -363,7 +365,7 @@ static int rtl8169_poll(struct net_devic static const u16 rtl8169_intr_mask = LinkChg | RxOverflow | RxFIFOOver | TxErr | TxOK | RxErr | RxOK; static const u16 rtl8169_napi_event = - RxOK | LinkChg | RxOverflow | RxFIFOOver | TxOK | TxErr; + RxOK | RxOverflow | RxFIFOOver | TxOK | TxErr; static const unsigned int rtl8169_rx_config = (RX_FIFO_THRESH << RxCfgFIFOShift) | (RX_DMA_BURST << RxCfgDMAShift); @@ -405,6 +407,31 @@ static int mdio_read(void *ioaddr, int R return value; } + +static inline int rtl8169_phy_reset_pending(void *ioaddr) +{ + return mdio_read(ioaddr, 0) & 0x8000; +} + +static void rtl8169_check_link_status(struct net_device *dev, + struct rtl8169_private *tp, void *ioaddr) +{ + unsigned long flags; + u8 status; + + status = RTL_R8(PHYstatus) & LinkStatus; + + spin_lock_irqsave(&tp->lock, flags); + if (status) { + netif_carrier_on(dev); + tp->phy_reset_warned = 0; + } else { + netif_carrier_off(dev); + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); + } + spin_unlock_irqrestore(&tp->lock, flags); +} + static void rtl8169_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) { @@ -463,6 +490,9 @@ static void rtl8169_set_speed(struct net mdio_write(ioaddr, PHY_CTRL_REG, PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); + + if (giga_ctrl & PHY_Cap_1000_Full) + mod_timer(&tp->timer, jiffies + RTL8169_PHY_TIMEOUT); } static int rtl8169_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) @@ -695,56 +725,56 @@ static void rtl8169_hw_phy_config(struct mdio_write(ioaddr, 31, 0x0000); //w 31 2 0 0 } -static void rtl8169_hw_phy_reset(struct net_device *dev) -{ - struct rtl8169_private *tp = netdev_priv(dev); - void *ioaddr = tp->mmio_addr; - int i, val; - - printk(KERN_WARNING PFX "%s: Reset RTL8169s PHY\n", dev->name); - - val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; - mdio_write(ioaddr, 0, val); - - for (i = 50; i >= 0; i--) { - if (!(mdio_read(ioaddr, 0) & 0x8000)) - break; - udelay(100); /* Gross */ - } - - if (i < 0) { - printk(KERN_WARNING PFX "%s: no PHY Reset ack. Giving up.\n", - dev->name); - } -} - static void rtl8169_phy_timer(unsigned long __opaque) { struct net_device *dev = (struct net_device *)__opaque; struct rtl8169_private *tp = netdev_priv(dev); struct timer_list *timer = &tp->timer; void *ioaddr = tp->mmio_addr; + unsigned long timeout = RTL8169_PHY_TIMEOUT; + unsigned int val; + u8 status; assert(tp->mac_version > RTL_GIGA_MAC_VER_B); assert(tp->phy_version < RTL_GIGA_PHY_VER_G); - if (RTL_R8(PHYstatus) & LinkStatus) - tp->phy_link_down_cnt = 0; - else { - tp->phy_link_down_cnt++; - if (tp->phy_link_down_cnt >= 12) { - int reg; - - // If link on 1000, perform phy reset. - reg = mdio_read(ioaddr, PHY_1000_CTRL_REG); - if (reg & PHY_Cap_1000_Full) - rtl8169_hw_phy_reset(dev); + if (!(tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full)) + return; + + spin_lock_irq(&tp->lock); - tp->phy_link_down_cnt = 0; + if (rtl8169_phy_reset_pending(ioaddr)) { + /* + * A busy loop could burn quite a few cycles on nowadays CPU. + * Let's delay the execution of the timer for a few ticks. + */ + timeout = 2; + goto out_mod_timer; + } + + status = RTL_R8(PHYstatus); + if (status & LinkStatus) { + if (!tp->phy_tried_renegotiate && !(status & _1000bpsF)) { + mdio_write(ioaddr, PHY_CTRL_REG, + BMCR_ANRESTART | BMCR_ANENABLE); + tp->phy_tried_renegotiate = 1; } + goto out_unlock; } - mod_timer(timer, jiffies + RTL8169_PHY_TIMEOUT); + if (tp->phy_reset_warned == 0) { + printk(KERN_WARNING PFX "%s: PHY reset until link up\n", + dev->name); + tp->phy_reset_warned = 1; + } + + val = (mdio_read(ioaddr, 0) | 0x8000) & 0xffff; + mdio_write(ioaddr, 0, val); + +out_mod_timer: + mod_timer(timer, jiffies + timeout); +out_unlock: + spin_unlock_irq(&tp->lock); } static inline void rtl8169_delete_timer(struct net_device *dev) @@ -757,8 +787,6 @@ static inline void rtl8169_delete_timer( return; del_timer_sync(timer); - - tp->phy_link_down_cnt = 0; } static inline void rtl8169_request_timer(struct net_device *dev) @@ -770,8 +798,6 @@ static inline void rtl8169_request_timer (tp->phy_version >= RTL_GIGA_PHY_VER_G)) return; - tp->phy_link_down_cnt = 0; - init_timer(timer); timer->expires = jiffies + RTL8169_PHY_TIMEOUT; timer->data = (unsigned long)(dev); @@ -1684,10 +1710,7 @@ rtl8169_interrupt(int irq, void *dev_ins break; handled = 1; -/* - if (status & LinkChg) - link_changed = RTL_R16 (CSCR) & CSCR_LinkChangeBit; -*/ + status &= tp->intr_mask; RTL_W16(IntrStatus, (status & RxFIFOOver) ? (status | RxOverflow) : status); @@ -1695,6 +1718,9 @@ rtl8169_interrupt(int irq, void *dev_ins if (!(status & rtl8169_intr_mask)) break; + if (status & LinkChg) + rtl8169_check_link_status(dev, tp, ioaddr); + #ifdef CONFIG_R8169_NAPI RTL_W16(IntrMask, rtl8169_intr_mask & ~rtl8169_napi_event); tp->intr_mask = ~rtl8169_napi_event; @@ -1708,7 +1734,7 @@ rtl8169_interrupt(int irq, void *dev_ins break; #else // Rx interrupt - if (status & (RxOK | LinkChg | RxOverflow | RxFIFOOver)) { + if (status & (RxOK | RxOverflow | RxFIFOOver)) { rtl8169_rx_interrupt(dev, tp, ioaddr); } // Tx interrupt _ From romieu@fr.zoreil.com Fri Apr 30 17:32:46 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 17:32:51 -0700 (PDT) Received: from fr.zoreil.com (electric-eye.fr.zoreil.com [213.41.134.224]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i410WiKO012864 for ; Fri, 30 Apr 2004 17:32:45 -0700 Received: from electric-eye.fr.zoreil.com (localhost.localdomain [127.0.0.1]) by fr.zoreil.com (8.12.8/8.12.1) with ESMTP id i410T7uX000631; Sat, 1 May 2004 02:29:07 +0200 Received: (from romieu@localhost) by electric-eye.fr.zoreil.com (8.12.8/8.12.1) id i410T72i000630; Sat, 1 May 2004 02:29:07 +0200 Date: Sat, 1 May 2004 02:29:07 +0200 From: Francois Romieu To: jgarzik@pobox.com Cc: Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: [patch 5/7] 2.6.6-rc3-mm1 - r8169 ethtool .get_settings Message-ID: <20040501022907.E500@electric-eye.fr.zoreil.com> References: <20040501022308.A32762@electric-eye.fr.zoreil.com> <20040501022439.A500@electric-eye.fr.zoreil.com> <20040501022552.B500@electric-eye.fr.zoreil.com> <20040501022654.C500@electric-eye.fr.zoreil.com> <20040501022808.D500@electric-eye.fr.zoreil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040501022808.D500@electric-eye.fr.zoreil.com>; from romieu@fr.zoreil.com on Sat, May 01, 2004 at 02:28:08AM +0200 X-Organisation: Land of Sunshine Inc. X-archive-position: 4991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: romieu@fr.zoreil.com Precedence: bulk X-list: netdev ethtool get_settings() for r8169 (Andy Lutomirski ). The locking does not need to be specially clever. diff -puN drivers/net/r8169.c~r8169-ethtool-get_settings drivers/net/r8169.c --- linux-2.6.6-rc3/drivers/net/r8169.c~r8169-ethtool-get_settings 2004-05-01 01:46:38.000000000 +0200 +++ linux-2.6.6-rc3-fr/drivers/net/r8169.c 2004-05-01 01:46:38.000000000 +0200 @@ -336,6 +336,8 @@ struct rtl8169_private { unsigned long phy_link_down_cnt; u16 cp_cmd; u16 intr_mask; + int phy_auto_nego_reg; + int phy_1000_ctrl_reg; }; MODULE_AUTHOR("Realtek"); @@ -451,6 +453,9 @@ static void rtl8169_set_speed(struct net auto_nego &= ~(PHY_Cap_10_Full | PHY_Cap_100_Full); } + tp->phy_auto_nego_reg = auto_nego; + tp->phy_1000_ctrl_reg = giga_ctrl; + if (!(status & TBI_Enable)) { mdio_write(ioaddr, PHY_AUTO_NEGO_REG, auto_nego); mdio_write(ioaddr, PHY_1000_CTRL_REG, giga_ctrl); @@ -460,6 +465,56 @@ static void rtl8169_set_speed(struct net PHY_Enable_Auto_Nego | PHY_Restart_Auto_Nego); } +static int rtl8169_get_settings(struct net_device *dev, struct ethtool_cmd *cmd) +{ + struct rtl8169_private *tp = netdev_priv(dev); + void *ioaddr = tp->mmio_addr; + unsigned long flags; + u8 status; + + spin_lock_irqsave(&tp->lock, flags); + + status = RTL_R8(PHYstatus); + cmd->supported = SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Full | + SUPPORTED_Autoneg | + SUPPORTED_TP; + + cmd->autoneg = 1; + cmd->advertising = ADVERTISED_TP | ADVERTISED_Autoneg; + /* + * FIXME: the driver should retrieve the values from the registers + * of the rtl8169. + */ + if (tp->phy_auto_nego_reg & PHY_Cap_10_Half) + cmd->advertising |= ADVERTISED_10baseT_Half; + if (tp->phy_auto_nego_reg & PHY_Cap_10_Full) + cmd->advertising |= ADVERTISED_10baseT_Full; + if (tp->phy_auto_nego_reg & PHY_Cap_100_Half) + cmd->advertising |= ADVERTISED_100baseT_Half; + if (tp->phy_auto_nego_reg & PHY_Cap_100_Full) + cmd->advertising |= ADVERTISED_100baseT_Full; + if (tp->phy_1000_ctrl_reg & PHY_Cap_1000_Full) + cmd->advertising |= ADVERTISED_1000baseT_Full; + + if (status & _1000bpsF) + cmd->speed = SPEED_1000; + else if (status & _100bps) + cmd->speed = SPEED_100; + else if (status & _10bps) + cmd->speed = SPEED_10; + + cmd->duplex = ((status & _1000bpsF) || (status & FullDup)) ? + DUPLEX_FULL : DUPLEX_HALF; + + spin_unlock_irqrestore(&tp->lock, flags); + + return 0; +} + static int rtl8169_set_settings(struct net_device *dev, struct ethtool_cmd *cmd) { struct rtl8169_private *tp = netdev_priv(dev); @@ -474,6 +529,7 @@ static int rtl8169_set_settings(struct n static struct ethtool_ops rtl8169_ethtool_ops = { .get_drvinfo = rtl8169_get_drvinfo, + .get_settings = rtl8169_get_settings, .set_settings = rtl8169_set_settings, }; _ From niv@us.ibm.com Fri Apr 30 20:50:11 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 20:50:15 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i413o4KO019832 for ; Fri, 30 Apr 2004 20:50:11 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i413nm8H606420; Fri, 30 Apr 2004 23:49:48 -0400 Received: from us.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i413o307078956; Fri, 30 Apr 2004 23:50:04 -0400 Message-ID: <40931E4B.4070005@us.ibm.com> Date: Fri, 30 Apr 2004 20:49:31 -0700 From: Nivedita Singhvi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Morton CC: netdev@oss.sgi.com, Jan Olderdissen , David Miller Subject: Re: [PATCH 2.6.5] Re: Fw: Stack sends SYN/ACKs even though accept queue is full] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4994 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: niv@us.ibm.com Precedence: bulk X-list: netdev > Attaching a patch which adds a sysctl to turn off this > behaviour. Could you test this, please? Patch against > 2.6.5 vanilla kernel. If you need a 2.4 version, let me > know. Oops, Andrew pointed out that my mailer had done the nasty and wrapped my patch. Resending.. thanks, Nivedita diff -urN linux-2.6.5/include/linux/sysctl.h linux-2.6.5synq/include/linux/sysctl.h --- linux-2.6.5/include/linux/sysctl.h 2004-04-03 19:37:23.000000000 -0800 +++ linux-2.6.5synq/include/linux/sysctl.h 2004-04-30 15:24:12.000000000 -0700 @@ -323,6 +323,7 @@ NET_IPV4_IPFRAG_SECRET_INTERVAL=94, NET_TCP_WESTWOOD=95, NET_IPV4_IGMP_MAX_MSF=96, + NET_TCP_PRELOAD_SYNQ=97, }; enum { diff -urN linux-2.6.5/include/net/tcp.h linux-2.6.5synq/include/net/tcp.h --- linux-2.6.5/include/net/tcp.h 2004-04-03 19:36:18.000000000 -0800 +++ linux-2.6.5synq/include/net/tcp.h 2004-04-30 13:55:18.000000000 -0700 @@ -583,6 +583,7 @@ extern int sysctl_tcp_frto; extern int sysctl_tcp_low_latency; extern int sysctl_tcp_westwood; +extern int sysctl_tcp_preload_synq; extern atomic_t tcp_memory_allocated; extern atomic_t tcp_sockets_allocated; diff -urN linux-2.6.5/net/ipv4/sysctl_net_ipv4.c linux-2.6.5synq/net/ipv4/sysctl_net_ipv4.c --- linux-2.6.5/net/ipv4/sysctl_net_ipv4.c 2004-04-03 19:37:37.000000000 -0800 +++ linux-2.6.5synq/net/ipv4/sysctl_net_ipv4.c 2004-04-30 16:16:57.000000000 -0700 @@ -601,6 +601,14 @@ .mode = 0644, .proc_handler = &proc_dointvec, }, + { + .ctl_name = NET_TCP_PRELOAD_SYNQ, + .procname = "tcp_preload_synq", + .data = &sysctl_tcp_preload_synq, + .maxlen = sizeof(int), + .mode = 0644, + .proc_handler = &proc_dointvec, + }, { .ctl_name = 0 } }; diff -urN linux-2.6.5/net/ipv4/tcp_ipv4.c linux-2.6.5synq/net/ipv4/tcp_ipv4.c --- linux-2.6.5/net/ipv4/tcp_ipv4.c 2004-04-03 19:36:55.000000000 -0800 +++ linux-2.6.5synq/net/ipv4/tcp_ipv4.c 2004-04-30 15:51:38.000000000 -0700 @@ -78,6 +78,7 @@ extern int sysctl_ip_dynaddr; int sysctl_tcp_tw_reuse; int sysctl_tcp_low_latency; +int sysctl_tcp_preload_synq = 1; /* Check TCP sequence numbers in ICMP packets. */ #define ICMP_MIN_LENGTH 8 @@ -1442,8 +1443,11 @@ * clogging syn queue with openreqs with exponentially increasing * timeout. */ - if (tcp_acceptq_is_full(sk) && tcp_synq_young(sk) > 1) - goto drop; + if (tcp_acceptq_is_full(sk)) { + if (!sysctl_tcp_preload_synq || + (sysctl_tcp_preload_synq && (tcp_synq_young(sk) > 1))) + goto drop; + } req = tcp_openreq_alloc(); if (!req) @@ -2683,4 +2687,5 @@ EXPORT_SYMBOL(sysctl_local_port_range); EXPORT_SYMBOL(sysctl_max_syn_backlog); EXPORT_SYMBOL(sysctl_tcp_low_latency); +EXPORT_SYMBOL(sysctl_tcp_preload_synq); #endif From jan@ixiacom.com Fri Apr 30 23:14:16 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 23:14:33 -0700 (PDT) Received: from racerx.ixiacom.com (64-60-75-69.cust.telepacific.net [64.60.75.69]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i416EFKO023202 for ; Fri, 30 Apr 2004 23:14:16 -0700 Received: by racerx.ixiacom.com with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Apr 2004 23:14:44 -0700 Message-ID: <15FDCE057B48784C80836803AE3598D50627AC8B@racerx.ixiacom.com> From: Jan Olderdissen To: "'Nivedita Singhvi'" Cc: netdev@oss.sgi.com, David Miller , Andrew Morton Subject: RE: [PATCH 2.6.5] Re: Fw: Stack sends SYN/ACKs even though accept queue is full Date: Fri, 30 Apr 2004 23:14:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 4995 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: jan@ixiacom.com Precedence: bulk X-list: netdev Nivedita Singhvi wrote: > Attaching a patch which adds a sysctl to turn off this > behaviour. Could you test this, please? Patch against > 2.6.5 vanilla kernel. If you need a 2.4 version, let me > know. We'll be happy to test it. We would prefer a 2.4 kernel patch though. Ideal would be 2.4.21 vanilla which we use in our embedded systems, but we can make other targets work as well. > Normally, I think the expected behaviour was that connections > would be short-lived. This is a reasonable expectation for most > web-servers etc. In which case, the accept queue would free > up frequently, and having the syn request right there would save > a full timeout and round trip over the Internet. i.e. useful in the > common case. I have to disagree. As the code is implemented right now, you get at most two pending young connections in the syn queue in addition to the ones in the accept queue - all others have already had their full timeout. I will argue that in high load conditions it doesn't really matter whether you have one or two warm connections sitting around or not because other new connections are going to come by anyway sooner than you want to have them. If the server is able to keep up, the accept queue is going to be mostly empty anyway. The idea of having warm connections is a good one - that is what the accept queue is for. As long as the accept queue is not full, the syn queue will have warm bodies for you. If the user wanted to achieve a very similar effect, he could simply increase the accept queue size by 2. In the end I don't think the minimal benefit warrants complicating the code and/or adding an option that few would understand or care to know about. Also, the concept of suggesting to the client that there is a receiver and then just dropping all the packets it sends seems a bit rude if not outright non-compliant. Your call, of course. Jan From luto@myrealbox.com Fri Apr 30 23:33:17 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 23:33:34 -0700 (PDT) Received: from smtp-roam.Stanford.EDU (smtp-roam.Stanford.EDU [171.64.10.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i416XEKO023889 for ; Fri, 30 Apr 2004 23:33:17 -0700 Received: from [10.0.0.2] (luto.Stanford.EDU [128.12.71.50]) (authenticated bits=0) by smtp-roam.Stanford.EDU (8.12.11/8.12.11) with ESMTP id i416X0kj027795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Apr 2004 23:33:01 -0700 Message-ID: <4093447B.1010404@myrealbox.com> Date: Fri, 30 Apr 2004 23:32:27 -0700 From: Andy Lutomirski User-Agent: Mozilla Thunderbird 0.6b (Windows/20040426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Romieu CC: jgarzik@pobox.com, Andy Lutomirski , Jon D Mason , netdev@oss.sgi.com Subject: Re: [patch 0/7] 2.6.6-rc3-mm1 - description of the r8169 queue References: <20040501022308.A32762@electric-eye.fr.zoreil.com> In-Reply-To: <20040501022308.A32762@electric-eye.fr.zoreil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4996 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: luto@myrealbox.com Precedence: bulk X-list: netdev Francois Romieu wrote: > With some delay, the following patches include Jon D Mason's NAPI changes > (+ fixes) and code from Andy Lutomirski with minor changes. > I have not moved the initialization of the phy timer in the pci probe > routine as: > - I believe it belongs to the netdevice; > - it should work as is without significant change for the user. > > If someone sees a good reason to move it, just complain (with an axe). I moved the timer because I didn't know about netif_running(). This looks fine. > > The patches apply to 2.6.6-rc3 as well as to 2.6.6-rc3-mm1. > > All the patches are merged in a single patch against 2.6.6-rc3 available at: > http://www.fr.zoreil.com/people/francois/misc/20040501-2.6.6-rc3-r8169.c-test.patch > > The patches are archived below as well: > http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.6-rc3 > > If the patches prove to behave decently on 2.6, a backport for 2.4.x will be > generated. Everything looks fine. I'm recompiling now; I'll let you know if I have any problems. Thanks, Andy > > -- > Ueimor From herbert@gondor.apana.org.au Fri Apr 30 23:50:47 2004 Received: with ECARTIS (v1.0.0; list netdev); Fri, 30 Apr 2004 23:50:51 -0700 (PDT) Received: from arnor.apana.org.au (mail@arnor.apana.org.au [203.14.152.115]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i416ohKO024942 for ; Fri, 30 Apr 2004 23:50:45 -0700 Received: from gondolin.me.apana.org.au ([192.168.0.6] ident=mail) by arnor.apana.org.au with esmtp (Exim 3.35 #1 (Debian)) id 1BJoKJ-0003iG-00; Sat, 01 May 2004 16:50:19 +1000 Received: from herbert by gondolin.me.apana.org.au with local (Exim 3.36 #1 (Debian)) id 1BJoKB-0003lg-00; Sat, 01 May 2004 16:50:11 +1000 Date: Sat, 1 May 2004 16:50:11 +1000 To: "Daniel 'NebuchadnezzaR' Dehennin" , 243084@bugs.debian.org Cc: Bernd Eckenfels , "David S. Miller" , netdev@oss.sgi.com Subject: Re: Bug#243084: net-tools: netstat do not display some ipv6 listening sockets Message-ID: <20040501065011.GA25540@gondor.apana.org.au> References: <20040411211116.GA32025@lina.inka.de> <87smfagpxf.fsf@thorr.asgardr.info> <20040412001011.GB3310@lina.inka.de> <20040412080013.GA24732@gondor.apana.org.au> <87fzb9z8zp.fsf@thorr.asgardr.info> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <87fzb9z8zp.fsf@thorr.asgardr.info> User-Agent: Mutt/1.5.5.1+cvs20040105i From: Herbert Xu X-archive-position: 4997 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 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline tags 243084 pending quit On Mon, Apr 12, 2004 at 02:16:58PM +0200, Daniel 'NebuchadnezzaR' Dehennin wrote: > > I made a little piece of code inspired by my patch to mailutils, it's > dirty code I prefere prevent you ;-) Thanks for the test case. Hi Dave: There is a bug in listening_get_first() which used by /proc/net/tcp* where it wasn't looping through all the sockets in each hash chain. This problem doesn't show up unless the first socket in a chain doesn't match the family that is being looked up. The following patch fixes this by getting rid of listening_get_first() altogether. Cheers, -- Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ ) Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=p Index: net/ipv4/tcp_ipv4.c =================================================================== RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/net/ipv4/tcp_ipv4.c,v retrieving revision 1.4 diff -u -r1.4 tcp_ipv4.c --- a/net/ipv4/tcp_ipv4.c 5 Apr 2004 10:54:54 -0000 1.4 +++ b/net/ipv4/tcp_ipv4.c 1 May 2004 06:22:20 -0000 @@ -2137,46 +2137,6 @@ hlist_entry(tw->tw_node.next, typeof(*tw), tw_node) : NULL; } -static void *listening_get_first(struct seq_file *seq) -{ - struct tcp_iter_state* st = seq->private; - void *rc = NULL; - - for (st->bucket = 0; st->bucket < TCP_LHTABLE_SIZE; ++st->bucket) { - struct open_request *req; - struct tcp_opt *tp; - struct sock *sk = sk_head(&tcp_listening_hash[st->bucket]); - - if (!sk) - continue; - if (sk->sk_family == st->family) { - rc = sk; - goto out; - } - tp = tcp_sk(sk); - read_lock_bh(&tp->syn_wait_lock); - if (tp->listen_opt && tp->listen_opt->qlen) { - st->uid = sock_i_uid(sk); - st->syn_wait_sk = sk; - st->state = TCP_SEQ_STATE_OPENREQ; - for (st->sbucket = 0; st->sbucket < TCP_SYNQ_HSIZE; - ++st->sbucket) { - for (req = tp->listen_opt->syn_table[st->sbucket]; - req; req = req->dl_next) { - if (req->class->family != st->family) - continue; - rc = req; - goto out; - } - } - st->state = TCP_SEQ_STATE_LISTENING; - } - read_unlock_bh(&tp->syn_wait_lock); - } -out: - return rc; -} - static void *listening_get_next(struct seq_file *seq, void *cur) { struct tcp_opt *tp; @@ -2184,6 +2144,12 @@ struct sock *sk = cur; struct tcp_iter_state* st = seq->private; + if (!sk) { + st->bucket = 0; + sk = sk_head(&tcp_listening_hash[0]); + goto get_sk; + } + ++st->num; if (st->state == TCP_SEQ_STATE_OPENREQ) { @@ -2237,7 +2203,7 @@ static void *listening_get_idx(struct seq_file *seq, loff_t *pos) { - void *rc = listening_get_first(seq); + void *rc = listening_get_next(seq, NULL); while (rc && *pos) { rc = listening_get_next(seq, rc); --sm4nu43k4a2Rpi4c--