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